Eventual-consistent hashchain of multiple IPNS endpoints

1

We know that the latest IPNS uses DHT and Pubsub, which enables one publickey to publish a pointer, so we can get a dynamic IPLD owned by one person. Then there are also some ways to extend its functionality.

The first thing I can think of is to introduce a hashchain. (Not sure if it already exists. Theoretically IPNS can work without forming a chain anyway.) For this one-usered IPNS, each change published to IPNS is a block pointing to the previous version of the IPNS pointer. Each block includes a WASM executable, which validates the next block. For the nodes knowing the full history, the executable on the hashchain can limit the permissions of the IPNS owner. Next, we introduce multiple IPNS endpoints, which link each otherā€™s version and forms a single chain when not conflicting by accident. Then thatā€™s a eventual-consistent blockchain, and you know what could be done next.

We then create a block that contains all these IPNS addresses, and when a user visits that dweb site, all addresses are resolved via DHT, and Pubsub, to avoid hidden branches on the chain. (All branches are downloaded before validating. All IPNS endpoints mention the branch they acknowledge. A branch is visible as long as one IPNS endpoint mentions it.) When thereā€™s a conflict, the branch with more addresses (from that block) pointed wins.

This is some kinda small-scale blockchain, without currency. The good thing is that we can have many such chains without too much burden. This is a way of reaching Mutable IPLD that I believe to be quite decentralized.

1 Like
2
1 Like
3

I donā€™t quite understand how it works maybe use images?

Also terminology (Iā€™m guilty of this often)! AFAIK Mutable IPLD is by definition not possible and if you meant (IPFS) DAG still not mutable.

Would multiple signatures in IPNS records not allow multiple key owners by consensus to control the ā€œchainā€?

What is the problem solved by your invention?

Tell us more.

4

Not exactly an invention. Just application of some existing stuff.

AFAIK Mutable IPLD is by definition not possible and if you meant (IPFS) DAG still not mutable.

It depends on your definition. The word IPLD doesnā€™t have an ā€˜immutableā€™ in it. Just pointers.

Would multiple signatures in IPNS records not allow multiple key owners by consensus to control the ā€œchainā€?

Multiple signatures on one IPLD endpoint is asking for problems. Synchronization, etc.

What is the problem solved by your invention?

Intuitively, it creates a multi-owner IPLD, and allows people to vote on it. To use an analogy inappropriately, itā€™s like the smart contract from blockchain. It deals with power, permissions.

5

Threshold signatures would work in this case.

For example 5 of 10 people would need to sign for the IPNS record to be updated.

Iā€™m all for updating IPNS, it need more flexibility. I want to be able to use any signature scheme I want!

6

Threshold signatures

Maybe, in some cases. Hashchain might be more flexible

7

At first glance, this sounds a lot like Ceramic w/ Polywrap integration for running user-defined wasm modules. Or am I missing something, and is this different in some significant ways?

I worked on a very rudimentary prototype of Ceramic + Polywrap here:

NOTE: W.R.A.P. stands for WebAssembly Random Access Protocol. More information can be found here.

8

Take a look at GitHub - freenet/locutus: Declare your digital independence. I think it is a better approach than my proposed architecture for this kind of problems.

1 Like