Mutable namespace using "Mutex blocks"

[Gozala]

Note: I'm forking this from #256 as it clearly does not belong there. I am also referring to ipns prefix here as I envisioned it as a successor to IPNS, however it could have it's own different prefix if that makes more sense.

Idea

What if instead of basing mutable namespace on the public key we based it on mutex block (genesis block) CID which:

1. Used designated multicodec code (so it can be clearly distinguished)
2. Encoded rules for updating it which can vary (few examples top of my head)
   1. List of public keys that can submit signed update records
   2. DID for a UCAN that can grant update capabilities.

More broadly mutex blocks could be pretty open ended similar to how multi-codecs are to allow extending them via domains specific matadata e.g:

1. peer ids of nodes that are likely to have latest record.
2. DNS alias(es)

This could also neatly combine IPFS and IPNS namespaces where /ipfs/$cid represents content at creation while /ipns/$cid could represent content now. If $cid in /ipns/$cid/ not a mutex CID it will be identical to /ipfs/$cid/ because it's content is immutable so content at creation matches content now. However if $cid is for a mutex it would resolve to the latest known value that was published in accordance to rules encoded in /ipfs/$cid block.

Another side benefit this could afford us is clean integration into IPLD stack. Given that mutexs are just CIDs DAGs with them could also be queried for state at creation or state now.

[aschmahmann]

IIUC the "mutex blocks" are basically just encoding a set of "rules" and making the name of the key equal to the "rules" (or a CID of the rules).

This seems like an interesting area for exploration and might help be a good umbrella for some of the existing schemes people have come up with so far.

Bare in mind https://github.com/ipfs/specs/issues/256#issuecomment-969217984. If we use a DHT (or some key-value store) to store the mapping from identifier -> latest then the storer of the record needs to be able to verify that the record is good.

This means:

1. The record store (e.g. all DHT server nodes) need to understand the codes for new record types
2. New record types need to be sufficiently verifiable (e.g. saying "check rando-chain for state" doesn't work unless everyone has a "rando-chain" client)

We can start walking down a road of mult-writer systems, or at least systems with multiple proposers, but that needs to come with some thought around the associated models such that we reduce the attack surface from things like DoS.

This doesn't necessarily stop us from coming up with a spec for interoperability, mostly just flagging that it's not necessarily as simple as "just chuck these new record types in the DHT".

[Gozala]

Bare in mind #256 (comment). If we use a DHT (or some key-value store) to store the mapping from identifier -> latest then the storer of the record needs to be able to verify that the record is good.

Absolutely!

I should stated goals here, that are:

1. Decoupling name from the publisher key - Right now this is serious limitation of IPNS making it unfit for use cases beyond single publisher. While those could be addressed in specific ways I think it would be good to enable users to choose.
2. Extensiblility - Just like some (multi)codecs are widely deployed and available, I expect we could end up with handful of mutability rules to get similar adoption. While still enable plugging domain specific ones that could be deployed at smaller scale.

[Gozala]

Bare in mind #256 (comment). If we use a DHT (or some key-value store) to store the mapping from identifier -> latest then the storer of the record needs to be able to verify that the record is good.

I wonder if encoding DHT PUT capability as a UCAN could provide a sufficiently general system on which various things can be layered. I imagine genesis token itself could be encoded as UCAN e.g.

{
   // self issued capability to publish this record
   issuer: `did:key:${key.pub}`
   audience: `did:key:${key.pub}`,
   capabilities: [{
     cid: "*",
     cap: "UPDATE"
   }]
}

Which would imply:

1. Any update with valid UCAN (that is ucan derived from the one above) could publish a new CID.
2. Holder of a key could grant update capabilities to various actors for limited time frame.
3. Second layer consensus can be implemented in user space, where actor(s) given derived UCANs with UPDATE capabilities can verify update requests and publish signed UPDATE only when all requirements are met.