CRDT challenges

[pgte]

Current CRDT implementations face these issues. Do you have a running plan to address these?

[pgte]

@fritzy ping

[fritzy]

• Snapshotting is a specific optimization that may be untenable without consensus or a single point of authority. This is still an active discussion.
• I have an approach to Identity that I'm currently pursuing with implementations that is described by https://github.com/ipfs/dynamic-data-and-capabilities/issues/12#issuecomment-387818860
• For persitence, is there a way to tell an IPFS node to have affinity for a given DAG tree? Can it follow the websocket peerstar? Do we need to have an always-on CRDT client that keeps up with these? I am not enough of a subject matter expert on the websocket pubsub implementation nor the go-ipfs implementation to contribute much here.
• I am not a subject matter expert on IPLD and this might be tangential to our near-term goals of having IPFS based (peer-crdt based) DApps in time for this summer's conference.
• Garbage collection: if an author has authority, the author could create a new DAG tree that avoids operations that are later undone and that summarizes serial operations as a single operation. I'll mention these ideas in the appropriate issue. This could be a useful and interesting optimization. If user action history is important to the application, then it must be solved a layer up as a separate log/crdt.

Outside of Identity & Persistence, these are all optimization challenges. In order to address an optimization, we must first provide a tool for measuring performance and take a baseline. Then we can evaluate where we are and where we want to be against specific practical goals. In this case, when can peer-crdt be fast enough and long lived enough to provide a suitable replacement for peerpad?

If the answer is that the current performance, according to the measuring tools, are not sufficient for our goals, then we can review proposed optimizations, propose more, implement and test them, and determine if they get us enough closer to our goals to be worth finalizing/merging.

The specific plan for optimizations pertaining to peer-crdt is here https://github.com/ipfs-shipyard/peer-crdt/issues/7

For areas in which I'm not an SME, I ask that I not be given responsibility for them in the near term.

[pgte]

About persistence:

Using peer-crdt it should be very easy to set up a replicating node that follows the CRDT without knowing about the content of the operations by using crdt.replicate(id). This allows a node that follows and replicates the operation data produced by all the other nodes , without having to know how to decrypt the content.

This works because the DAG structure for a CRDT operation leaks the ids of the parents, while encrypting only the content of the operation itself.