RFC 42 – SAFE Launcher API v0.6

General RFCs
,
8

Following a question I raised about unique ids on RFC 41, and considering I understand this right, I’d like to raise the following concern:

With unique IDs and removed sandboxing the LOW_LEVEL_APIs are under high likelihood of being mistakenly misused and that effecting the entire network. Just image any app – not realising what they are doing – writing to the userProfileData ID. Now this can’t be used again by any other app. That’s annoying and for 90% of cases not what the APP author intended. The only way to circumvent that is for them to explicitly adding a app-specific prefix and for single usage data to create crypto-collision-secure UUIDs. Both things easily overlooked by app developers (and lead them to making bad design decision they have live with for very long.)

There I’d propose the following changes to the “external” launcher API (safe_core can IMHO still provide the functions more raw):

  1. We should – by default – auto-prefix IDs given with a app-id given server-side. If an app doesn’t want that or wants to explicitly use a different prefix, they can send a NAMESPACE-HTTP-Header we’d use instead (or, if set to GLOBAL could also discard the prefix entirely).
  2. We should provide an id-less POST /structured-data/ that creates a prefixed (as in 1) and crypto-secure id (without collision) server-side and returns this as part of the header data so the app can store it for future reference – similarly as couchdb does it (a great source for API design BTW!). This lifts the burden of doing something unintentionally stupid from the user and provides a convenient layer that “just works” and in the right way.
3 Likes