Mutable & Replyable Storage (Novel? IPNS/DNSLink alternative?)

(Copied from ipfs specs here, per @stebalien suggestion, though I did reply there.)

Has anyone explored just requesting related content id’s from a peer hosting an origin piece of content, post peer discovery?

It seems they could just tell you of addresses to new versions, signatures, replies, previous versions, etc. Been mulling on this trying to figure out whats wrong with it; Ideas (new to this area)?

I know it converts this into a peer trust & filtering problem, but it seems the opportunities (content id augmented outward indexing, & social media) outweigh any difficulty there. Also (assuming good idea), not sure if this would be better served in something like libp2p, Bep-0005 (to make mutable everything), or as a separate protocol parallel to IPNS as shown here. Seems too this could facilitate peer to peer git vs federated server client (just set git to Sha-256, throw all objects into IPFS, and respond to a set of relationship requests as a peer), would make web archival (better? - a breeze?).

Using this to point to mutable IPFS based URI tables or DNS like structures would then also be trivial.

Full proposal wip here (written for those less aware of DHTs, Merkle DAGs, etc)

I call this problem, “anchoring”, changing a DAG is trivial even if it links TBs of data, but how to share this new root?

For my social media protocol, I use a mix of IPNS and blockchain but I haven’t found any elegant solution yet.

I like the ENS & IPNS combo, you get human readable name with a mutable link to some CID.

You can also take a look at Ceramic streams

There is no single root requirement in a DAG though.

There is a reason DNS is still implemented with any number of name servers: Mine? Does not actually agree with yours! (And they shouldn’t!)

Blockchains are rather good at reaching consensus for a small amount of data. This is important for things like transactions, but for naming?

Forgetting entirely the problems with mob rule (little different than single corrupt entities, just harder to reach consensus, not impossible), drowning of minority voices, lacking cheep interoperability between chains, a failure to meet the ‘interplanetary’ aspiration by speed of light constraints breaking consensus, and the comparatively huge amount of extra protocol complexity to try and heal some of those consensus problems (see LBRY): blockchains as a naming service completely fail the private naming requirement. How do I create a intranet on a blockchain? You need multiple, with a capacity to add more. Sure you could encrypt private records instead, but why? It slows response and takes more energy.

That’s why I say, just ask the peers for their view of graph connectivity.

That works very well for the internet, but with content addresses augmenting that, you get discoverability by content connections. My citation of your research paper? Makes me a peer so no one as likely looses it, and makes me discoverable, by you.

Nothing stops any peer from using a blockchain to track and reach consensus on their version of things. But it could then be many chains… or even private records, like an intranet, behind a single simple protocol.