Key-value store plugin

[theoreticalbts]

This ticket specifies a new plugin which is to eventually replace and deprecate the chain metadata.

The kv_plugin gives each user a key-value store accessible by custom operations, together with some specifications and a little bit of glue, which will allow us to use this kv-store primitive for all of the use cases presently envisioned for json_metadata.

Each value is stored in a space. The space is an integer which specifies special rules for processing an account. Currently two three bits are defined:

• If bit 0 is enabled, then the active authority is required to write to the space (normally posting authority suffices).
• If bit 1 is enabled, then objects in the space cannot be modified after they are created.
• If bit 2 is enabled, then the owner is not used as part of the collision domain (i.e. the first user to write a key claims it and will keep it until deletion; nobody else can write to a claimed key).

The space is considered part of the key, i.e. the actual unique key is (user, space, key).

The following standardized keys are defined for "adding fields to an account" or "adding fields to a post":

• /a/@account/field to add annotations to accounts
• /c/@author/permlink/field to add annotations to comments

[abitmore]

Would it be possible that for example some key-value pair changes require posting authorities, and some require active authorities?

[theoreticalbts]

@abitmore Yes, that's addressed by bit 0. Even-numbered spaces require posting authority, odd-numbered spaces require active authority. So if your application wants to add some metadata which can be updated with posting permissions, you would use space 0. If your application wants to add some metadata which can be updated with active permissions, you would use space 1.

The different spaces are completely separate, so entries written into space 0 don't affect like-named entries in space 1. Most sane applications will only use a single space, so like-named entries in different spaces should be rare in practice (effectively you can think of the space number is part of the field name). Doing things this way is necessary, otherwise you'd be able to deny service to a space you don't have access to by writing to a space you do.

This sounds confusing, but in practice, writing an application with this is simple: Figure out the space which has the semantics your application requires, then use that space exclusively and ignore all others. For many (perhaps most) applications, space 0 is the best choice.

[mvandeberg]

Any such key value store can be implemented using custom ops currently. If we do something like this, it will likely be developed using another service than steemd.