ipfs / ipfs/specs

Mutable namespace using "Mutex blocks"

Open
#258 3 comments 0 reactions 0 assignees View on GitHub
need/triage
Dominant language
HTML
Stars
1.2k
Forks
247
Avg merge
5d 21h
Merged PRs (30d)
4

Description

*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](https://github.com/fission-suite/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_.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.