add support for publishing and fetching key value mappings about ent HOT 5 OPEN

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.

from ent.

As a REST API, I suggest something like: POST /index/insert for inserting a mapping and GET /index/retrieve/{key} for retrieving a mapping. But I am not that attached to the naming, or the use of REST. Although I am not sure how you'd use a gRPC service on command line.

from ent.

cc @conradgrobler @benlaurie

from ent.

a free-for-all flat namespace would obviously not work -- who decides who gets to use the key google, or any other well known and potentially misleading string?

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

http://ent-url/lookup/8tUPjCTg3JigvHP9o4ZnZ51JTkCjjYoHibh5z8VUDg23QtkzvCnWHNWxe8rqbQXdizf9NKiRQgNWbj7Zo2FNongVq8/8tW2YFDxYB3hoxaq112VLLCPFrWN6zMZqY3ppaHF7ZbFWyBFrnpXTbtTsuFxoivFdFjbF2WhfFT3Jb3LoBPDcRhcaM

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

from ent.

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?

from ent.