from Hacker News

CRDTs: Convergence without coordination

by 0xKelsey on 10/16/25, 3:00 PM with 31 comments

  • by Arcuru on 10/23/25, 5:04 PM

    Shameless plug: I'm betting that a lot of applications could use some form of CRDT as a Database, which would allow a fully decentralized backend/database for local-first apps. So I've been building one.

    Still working on good blog posts to explain and introduce it though.

    https://github.com/arcuru/eidetica

  • by cbm-vic-20 on 10/23/25, 2:39 PM

    The article sets up a scenario where two people are editing a document, but have conflicting changes: "If Alice fixes a missing letter in a word while Bob removes the whole word, that’s a conflict."

    The article then goes into some examples of CRDTs and their merge operation, and the examples are pretty straightforward: take the maximum of two values, or take one with a more recent timestamp, etc.

    But what about the motivating example? What should a merge function do with the inputs "change the third word from 'affect' to 'effect'" and "delete the third word"? In other words, how does the function know which of these operations "wins"? It could ask a user for a manual resolution, but is there a reasonable way for a function to make this determination itself? Maybe deletes are more powerful than word changes, so the delete wins.

  • by deepanwadhwa on 10/23/25, 4:27 PM

    Does anyone know if there is anything like CRDT with end to end encryption?

  • by fellowniusmonk on 10/23/25, 3:01 PM

    Loro is the open source project I am most excited about, their documentation is also stellar as an intro to the subject.

    As an aside, I find FugueMax to be amazing to solve interleaving issues.

    I've found for collaborative editing fuguemax for resolving intraline edits and h-lseq for the lines themselves has been amazing.

    https://loro.dev/blog/crdt-richtext

  • by iwontberude on 10/23/25, 5:14 PM

    The toy example with two nodes incrementing and decrementing likes independently and then sharing the delta with each other would require an increasing amount of backend requests (n^2) for every like. If you had 10000 nodes and they were all sending 9999 requests to eachother for a single request, obviously that's not the best model. It did somewhat remind me of MySQLs active-active replication scheme but that has some locking to make sure drift isn't too bad. MySQL Group Sync also doesn't scale beyond 9 nodes.