ple1n
commented
2 years ago Closing, probably not a part of IPFS
Closed ple1n closed 2 years ago
ple1n
commented
2 years ago Closing, probably not a part of IPFS
I wonder what is the roadmap for mutable IPLD, and I'd propose one partial solution in case you haven't thought of. It would reduce the reliance on the centralized web. Not sure if that should be added to IPFS or created as a separate package, but it needs discussion and the low-level protocol needs to be prepared for this use case anyway. (Ideally IPFS shouldn't be forked #303 )
We know that the latest IPNS implementation uses DHT and Pubsub, and now hypothetically I could change the IPNS so that each IPNS record is a block containing a WASM binary, pointing to the previous IPNS record. The binary validates the next block and deals with branch conflicts, ran by some daemon on every IPFS node, so the IPNS endpoint isn't entirely controlled by the public key. The independence of an IPNS endpoint is quite intriguing in terms of decentralization. The historical records have become the consensus, while the publickey possess less power. Now this is a single-owner IPNS hashchain, with which the owner could, for example, publish an IPNS record to adjust her own permissions, so that only a part of the pointed DAG could be modified or it has to meet certain criteria. The owner could also add moderators, as IPNS links in her hashchain, and set permissions via WASM. However the owner's publickey could be compromised and the chain could be forked, and the original branch could be hidden since the DHT key is changed and not pointing at it, so we introduce a block that contains all the moderators' IPNS publickeys as the entry point, and they are now equal. Let me call it a dweb site. When a user visits the site, the entry block is obtained and all the IPNS records are resolved, via DHT to ensure the 'right' branch is always visible. The 'right' branch is visible as long as one moderator points at it on DHT. If all other moderators forked the hashchain when their permissions have been revoked, as long as the 'right branch' is visible they won't succeed. In case of conflicts, the branch whose records are blocks signed by most moderators is chosen (this behavior could be determined by WASM in a block) Pubsub could be used as a fallback when DHT fails or all moderators have been replaced (better change site address block then).
This might already been used in other protocols, being called append-only logs or something, I'm not sure. As something similar to blockchain, it is more lightweight and decentralized. Users could easily create many such chains, where everyone validates the blocks. It has eventual consistency. With this kind of hashchain, more interesting things could be built upon it in a very decentralized manner. Besides trusting site moderators, it'd be good to introduce https://github.com/ipfs/roadmap/issues/78 too.
Speaking of mutable IPLD, #392 has to be done first
What does it solve ?
Dynamic content problem, #40
Decentralized permission management. It is the starting point of other applications. If I were to use it, I would let the owners use the hashchain to point to some metadata, containing another WASM binary specifying the criteria to include content in that site, and aggregate the content from other users using Pubsub, which is similar to ZeroNet as a whole. Theoretically, it is already more decentralized and dynamic than ZeroNet using this method.
Why is it about mutable IPLD ?
MUTABLE_DATA
We have to define mutability first. DHT is mutable but it doesn't make sense here, so IMO mutability means the content of one single address can be changed, in some ways by some people. IPNS solves the problem of one-to-many, and this chain could solve few-many, for many-to-many problem, it needs WoT or other things.