Here are some of the distinguishing details. The security tradeoffs are modeled after and are extremely similar to chat. This ensures that the server cannot read or forge an entryValue, nor prove any of the metadata it knows about it. EntryValues, however, are signed by the device key of the writer and then encrypted for a specific team. Much of the metadata, including namespaces, entryKeys, as well as database access patterns, is known to the Keybase server. you have two different bots that absolutely need to share and update the same entries concurrently), you can pass in a revision and your Keybase client will use it.įor example, assuming that this entry has not been inserted previously, the following command will insert an entry with revision 1: keybase kvstore api -m '' If, however, you would like to manage your own revisions (e.g. This complexity is hidden from the API because you probably don't need it. When you put a new entry or update an existing one (deleting works this way too), your Keybase client will first run a get for that entry so it knows exactly what revision the server is expecting (e.g. The Keybase server keeps track of the latest revision number for each entry, and it requires the client to specify the correct revision number on every update request. _whatever), it will be undiscoverable from the corresponding list endpoint. If you prepend a namespace or entryKey with double-underscores (e.g. Namespaces and entryKeys are in cleartext, and the Keybase client service will encrypt and sign the entryValue on the way in (as well as decrypt and verify on the way out) so Keybase servers cannot see it or forge it. You cannot fetch old versions of your data if you've put a new revision or deleted it. myawesometeam.passwords)Ī team has many namespaces, a namespace has many entryKeys, and an entryKey has one current entryValue. you plus any list of other keybase users (e.g.Key-value storage exposes a simple API to put, get, list, and delete entries.Įntry values are encrypted for yourself by default (this is probably what you want), but you can also specify a team: We've implemented the key-value storage feature for more lightweight applications storing small blobs of data - maybe you just need to store a session key, or you're building a team password manager. If you're a bot developer who has needed persistent state, you may already be using KBFS for your storage needs. encrypted for yourself (or for anyone in a team you're in).It is a place to store small bits of data that are Keybase has added an encrypted key-value store intended to support security-conscious bot development with persistent state. This section is under development, check back soon for updates! Key-Value Storage Here is the technical documentation for bot development.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |