cdata
commented
2 years ago Name publishing & resolution
Here is a rough sketch of how name publishing and resolution may work...
In the beginning, you generated a sphere.
You have a key and the sphere has a key, and the sphere delegates your key the capability to publish with a UCAN.
The name system is managed by your gateway, so to publish a name you tell the server the CID to publish via a REST API and furnish it with a signed UCAN token that proves you were given authorization (ultimately by the sphere) to do so.
Once the request is processed by the gateway, the name system then publishes a key/value pair to the DHT.
The key is the DID of the sphere.
The value is a tuple in this form: (sphere_cid, proof_cid, Signature(sphere_cid + proof_cid))
When someone goes to look up the latest revision from a sphere in their address book, first they resolve the petname to the sphere's DID (which is just a local map lookup).
Then, they can query the DHT by the sphere's DID. They can verify the validity of any DHT result along two axes:
1) Retrieve the UCAN referred to by proof_cid and verify the signature against the UCAN's audience
2) Resolve the proof "chain" in the UCAN and verify that the capability to publish was originally granted by the sphere
One verified, they know that sphere_cid is the latest published revision of the sphere.
gordonbrander
Our plan at this time is to implement a generalized pet name system that enables users to write human-readable names instead of DIDs when addressing other spheres.
This is the tracking issue that covers progress towards our pet name system.
Design notes
The proposed design for this system expects the following:
Spheres already have a key pair generated for them when they are first created. Spheres are already immutable data structures and can be looked up by CID.
The notion of a Sphere is sufficiently developed to encode a name-to-DID mapping, but the field needs to be added and incorporated with our versioning scheme. And, we have yet to implement a DHT.
Errata
In our prototyping phase, we implemented a global, recursive name system using a CosmWasm smart contract. This was an interesting design, but ultimately we decided that a block chain is ill-suited to tracking mutable pointers. A single change could cost multiple pennies (denominated in USD), and recursive name resolution compounds the cost at each "hop" (where a hop is another contract invocation in this case). If every revision to a Sphere - where each individual revision could amount to a very small change - prompted a change to the pointer in the block chain, the cost to publish adds up quickly.