[protocol] Simple and fast key-value store (or "light items")

[tasn]

The items at the moment are optimised for large files that are long-lived and retain a change history. This is great for what they do, but it's not always what we want. For example for fast changing data or very small data it makes sense to have a simple key-value store that doesn't retain a history.
This can be solved by having "light items", though a better abstraction would potentially be a simple key-value store.

Example use-cases:

• Trust store: the key name could be the username or public key (for easy fetching), the content can be the trust level and etc.
• Location data: store your device's geographical location and keep on updating the location as they move.
• Counters: some sort of counters.

Implementation thoughts

• UID:
  • We can use the deterministically encrypted key for efficient fetching (and getting the name when listing) - also pad the UID the same way we do for collection types. We can alternatively use the hmac of the key, though we then won't be able to get back the key name unless we store it elsewhere (immutable) in the item.
• The key value stores should not
• We want them to live in collections, along with items, and preferably be able to use them interchangeably in transactions and batches. Though I guess listing should be separate as we don't want the API to return objects for which we will need to do instance_of in order to use.
  • How does it looks though with etag and transactions? So knowing we don't override changes? I guess we can also have a longer form version that enforces that? We can for example have an item instance that's fetched and then we can modify and push?

Example API: