I’m not much beyond a beginner either, I started learning about this some weeks ago, so I may be missing something as well . But here’s how I understand it.
I say it is CRDTish because the Solid POD is not a CRDT node, it’s only a “dumb store”. But this same architecture could potentially be used for nodes communicating among themselves, and that would be a proper CRDT. Although that’s not a use-case I’m considering at the moment.
There cannot be any concurrent edits, because even if two operations happen at the same time, Hybrid Logical Clocks take care of making each event unique and sorted chronogically. So the latest operation would win. I’m still a bit fuzzy about the clocks, but worse case scenario I will just use normal timestamps. That’s normally not advisable for real-time collaboration, because you can’t trust the local timestamp of different devices in a distributed system. But for my use-case, I think it’s acceptable.
As I understand it, the main difference is that in Operational Transformations the operations can be transformed after they have been created, usually by a centralized server. With CRDTs, the operations are immutable and there is eventual consistency (a node with the same operations will have the same end state).
I’m tracking everything in the same document because it’s easier, but technically speaking it doesn’t matter in which document the state/operations are stored. They are still linked with urls through semantic properties (
soukai:history in my example). The operations are effectively an append-only log, and the resource (
:it in my example) is the reconstruction of the state through operations, but I need to store it so that other applications understand the data without looking at the operations.
About untracked changes, that’s why I’m using a checksum to see if the current state is the result of all the operations or that something else changed it.