After careful consideration I've decided that stratus are shitty clouds. They're grey and amorphous, can be low-flying, and are aesthetically unpleasing. In a not-unrelated vein I am pondering a thing that might serve as an IOT-friendly key:value datastore.

High-level requirements / goals:

1. Easy to add to existing code. Minimal boilerplate, minimal RAM/CPU overhead.
2. reasonably secure; an endpoint (IOT device) should be reasonably confident that it's getting unmolested data
   1. note that this shouldn't protect against MITM or anything sophisticated
   2. note also that you shouldn't use this for anything important like heart monitors
3. dead-ass simple. IOT devices suck and have limited CPU/RAM/connectivity resources
   1. unfortunately this pretty much eliminates active crypto
   2. hard-coded & configurable API keys would be just fine tho
   3. shared-secret check bits might work ok (actually they'd be great with a decent hashing algo)
4. massively tolerant of failure
5. self-configurable / zero bootstrap

So here's a starting place, read-only:

• some ideas are stupid, but I don't want to forget that they're stupid
• hosted via simple static/flat text file with key: value\n pairs
  • build static config files offline, signed
• simple strnpos (or similar) to identify key and end-of-key "\n", substr() to extract it
• "API key" as an n-bit hex value
  • this is nontrivial. IOT code is distributed en masse, per-device configs are infeasible
  • each host can have a GUID (MAC address or derived from)
• host the static text file in a web space under that key, making it hard to find
  • /df/0xDEADBEEF.txt
• Use a key like "where my config should live". If you need to move it for any reason, just update that key and the thing would next pull from the new location. This key should mostly be self-referential tho (duh)
• Use a key for the API key too, in case you have to migrate that for any reason
• an IOT device should also check for its own GUID as a key, possibly indicating a new config location
  • to let one retroactively split off some clients, or per-client config specialization
• Other self-referential config things should include update frequency and debug / logging levels

If done correctly one could debug production device(s), ship them, disable debugging, and later re-enable it -- without requiring a code push / OTA.

#include "stratus.h"
Stratus stratus("http://austindavid.com:80/df/df.txt", "secret key");

...
setup () {
    // networking setup happens
    stratus.update();
}

loop() {
    static int variable = 1;
    EVERY_N_SECONDS(stratus.get("refresh interval", 300)) {
      stratus.update();
      variable = stratus.get("variable", variable);
    }
}

Doing a little better (potential TODO):

• implement a pub-sub; URL -> MQ, GUID + secret for authorization & authentication
• for more arbitrary-sized objects (beelobs), http get a single key / retrieve a single (biggish) value?
• use the datastore -- http post a key + value pub
• have clients pump a checkin value to indicate they last successfully read sub