Transactional IPNS

[apiarian]

Version information: v0.4.3

Type: feature

Priority: P4

Description:

It would be nice if multiple programs could maintain their own namespaced areas under a common single IPNS root object. Until there are multiple IPNS objects per node, this would need to be handled by some sort of locking.

There might be --if-current-is=[hash] optional parameter for updating the IPNS object. The command would fail if the current IPNS hash does not match the one provided.

Another way would be to add commands to lock the IPNS hash and unlock the hash.

I suspect that these two approaches are not mutually exclusive and may both be useful in different situations.

[whyrusleeping]

Hrm... This is interesting. I wonder if we can generalize this to some sort of CRDT op-log type of ipns mode

[wigy-opensource-developer]

I doubt that CRDT is possible with the current sequence-based conflict-resolution. Adding a full history of all previous hashes is a way to go, but that might hurt the privacy of some use-cases (obliterating history is sometimes a useful feature)

[Kubuxu]

CRDT type log should IMO be a third party component, but I would love to have one.

CID + cbor allows us to have transparent link with metadata that is history.

[whyrusleeping]

@wigy-opensource-developer on the contrary, our validity system for ipns is pluggable.

Though its not fully implemented yet, take a read over the records spec: https://github.com/ipfs/specs/tree/master/iprs

[wigy-opensource-developer]

@whyrusleeping Sorry, I always thought that IPNS is a kind of record, where we have a given validation rule and a given conflict resolution rule (selector). So IPNS is an IPRS.

So how would you change the way IPNS records are validated, now that there are old versions of the client around without changing the namespace used in the DHT?

Back to topic, @apiarian needs transactions, because the private key for authenticating changes is shared between the programs and they need at least optimistic locking for updating a single record. As a workaround, each application could use a separate key, since #3472 and other keystore features were added.

[whyrusleeping]

upgrading should be fairly easy, we can switch to using CIDs to refer to new records, and the old QmWhatever hashes can be assumed to be legacy style records.

As for the problem at hand, Heres how i see a crdt style IPNS record working, When publishing you would ideally have the latest record, but thats not a big issue, simply craft your new record as a CRDT update that points to the best known record. When sending this out, if its sent to a node that has a different record, the two could simply be merged (or if they are on the same chain, the best one would be kept). When fetching a record (ipfs name resolve) the dht returns K values, the selector function then picks the value from these that is the 'most' correct. We could implement a selector that selects a record that consists of the final merged CRDT state from among all differing received records.

[wigy-opensource-developer]

That seems to be a good solution for the given problem. The data in the CRDT event and the way conflicts are resolved still needs to be defined to get a solution that can be implemented, BUT:

I doubt the problem itself is valid. A single private key should be "owned" for a purpose. Sharing this key is just a workaround for a limitation that was already removed from IPFS, namely a single node could maintain a single IPNS record. I would rather solve the possibly missing features from the keystore than to work hard on making keys reliably sharable between otherwise unrelated applications.

Everything can be implemented, but the simpler we can keep the whole architecture, the less bugs will creep into the code. (I understand that CRDTs are supercool though :smile: )

[whyrusleeping]

Man, i just love CRDTs.