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

[inventor2525]

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)

(Not sure atm if this should go in IPFS notes, here, or libp2p specs)

[Stebalien]

This should probably go on the discussion forums for wider visibility. But I'm not sure if I understand why IPNS isn't enough. Are you trying to allow arbitrary parties to modify/annotate files? In that case, I'd expect some form of overlay protocol with a concept of "friends".

[inventor2525]

Essentially yes, but it's more than modify or annotate.

IPNS facilitates a author/owner changing their file, while you know it's them doing it. -- This would be more like forking, in git.

Any peer could just reply with any content relations they approve of or know of. Such content relations could be as far branching as social media posts. (Also without having to download the whole DAG for a 'repo' clone.)

Unless an IPNS record is monitored, if you come to a file via IPNS, all you know is that you have the newest version, not what it's version history is. Author could tell you of course, but this would formalize that for them, and for others in a way that lets the user find their forks without having to scrap outside the swarm for that original address. (Not sure how efficient this is atm, or if it somehow breaks peer discovery, but I would think it would only bolster the original if they follow the rules, or could be filtered out normally if they didn't.)

This would be more useful if you wanted to for instance, have a wiki that many people edit, without a necessary owner. A user could still filter it as you say by some concept of "friends", asking too for the signature of any forks they find (or receiving it preemptively), but it would be based on what peers they ask for content relationships, rather than who can actually edit or fork.

I'm starting to think you might be right about an overly protocol, but it seems such a small wide reaching useful message, even in torrent, I wanted to at least see if it'd ever been considered.