-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for publishing and fetching key value mappings #2
Comments
a free-for-all flat namespace would obviously not work -- who decides who gets to use the key I'm thinking maybe a two level structure, in which the first level is the digest of an ECDSA public key (similar to how .onion addresses work), then the second level could be an arbitrary string (or maybe even that could be a digest of the string, to avoid having human recognisable elements in the URL). So a full URL to fetch an item may look like
it does not exactly roll off the tongue, but I think it has nice properties, including that the ent server cannot forge such an entry (since it would actually be signed by the private key, which ent would not have) -- the client will also get the signature as additional metadata for verification of course |
As a REST API, I suggest something like: |
Good point about namespacing. So if we want to upload an entry we have to sign it? But it is public, right? Anyone with the digest of the ECDSA public key can do the look up? |
Yes we would sign it. We already have an API key to allow clients to upload entries, this would be an additional secret that we need to give to the client, and each client would get its own, ideally (unless we intentionally want to share the top level namespace across clients). And yes, publishing the public key is out of scope, it can happen in any way. |
More details to come, but this would allow building a sort of namespaced k/v store, in which keys are arbitrary strings, and values are digests of existing ent items
cc @rbehjati @thmsbinder
The text was updated successfully, but these errors were encountered: