CRDT's anyone?

Initiating this topic as a general discussion thread for anyone looking into bringing CRDT’s in some form or another to the Fediverse.

Kicking off with an interesting resource I just found via the Solid forum Application of CRDTs to Solid discussion:

Which was earlier discussed on Hacker News

With some caveats, ActivityPub is already a pair of CRDTs. The federated protocol is a state based CRDT and C2S is an operation based CRDT. The caveats are:

  1. We have a suggestion on how to assure that the recipient can determine whether update and move are received in order, but it probably hasn’t been implemented on any server yet
  2. A federated move can guarantee consistent state and an atomic move for the object referenced, but guaranteeing a consistent state for the collections referenced could be problematic
1 Like

Pleroma update activities will be a reply to the activity that produced the version they modify. This does not change meta data on the object itself:

As for federated move, I think this is an issue unlike any other CRDTs may have encountered because they have distributed documents, but the document hierarchies are local to each participant. At some point, ActivityPub will be mixing shared document hierarchies with personal ones. When that happens, the author of a move will have to decide whether to list or simply identify source and target collections and whether to munge the move activity, itself, to avoid leaking metadata about collections the actor isn’t sharing

1 Like

The openEngiadina project is research CRDTs as underlying data structures for ActivityPub.

We have an inital write-up of the idea:

Next step is to implement this in a ActivityPub backend and gain more experience.

1 Like