4 ms·

Another reason to not need a CRDT is privacy. A CRDT assumes that every participate has equal rights to all data. I'm biased to simple WebSockets with OT using

Another reason to not need a CRDT is privacy. A CRDT assumes that every participate has equal rights to all data. I'm biased to simple WebSockets with OT using JSON deltas, and I'm building a platform that greatly simplifies how to efficiently build collaborative apps: https://www.adama-platform.com/ https://www.adama-platform.com/

pookha 4y ago
CRDT's can be encrypted end-to-end. Privacy seems to be one of the selling points.
- preseinger 4y ago
  Privacy and encryption are entirely orthogonal to CRDTs vs. alternatives.
CGamesPlay 4y ago
These are orthogonal to one another. For read-protection, encryption is a viable solution: specific paths into your data structure (e.g. certain keys in a map) can be encrypted with a key that isn't provided to all participants. For write-protection, the solution is the same as with any syncing service: when receiving an update, if you don't authorize the sender of the update, you don't accept it.
samwillis 4y ago
> A CRDT assumes that every participate has equal rights to all data. Within a single data structure yes, so within a "room" or "document". If you need to partition right to the data (read/update) then you should use separate structures for each area. Yjs implements this as as "sub documents".
pattrn 4y ago
Is this really the case? While CRDT's are designed to work peer-to-peer, they don't need to be fully connected to all clients. Forcing the synchronization through controlled nodes (a server or cluster) allows adding read/write permissions. Depending on the use case, it may require additional logic for reversing operations before propagating to other clients, or in some cases forcing a client to revert to a snapshot (this can be a bit complex). That's an approach I've used in the past. Have I overlooked something (highly likely)?
- mathgladiator 4y ago
  P2P generally means all clients can read all the data. Even if some data can be encrypted, it can then be deleted via a peer. Admittedly, I am conflating privacy and access control, and core to my point is that CRDTs are limited in many domains.
charles_f 4y ago
That sounds like a weak counter argument to me, 1) crdt is focusing on the conflict resolution part, access control is not in scope so you need to implement on top. 2) if you are already implementing access control, then filtering out what people don't have access to doesn't seem much more complexity. If you go the full client-side way, you can also add a cryptographic layer to whatever needs hiding 3) one thing I don't see in your solution is the offline aspect to it. With a central authority in the middle and online connectivity, conflicts become unlikely and much smaller, but with offline support, documents et can evolve in drastic ways where having a formalized strategy like what crdt offers makes sense
preseinger 4y ago
> A CRDT assumes that every participate has equal rights to all data. This is not true. CRDTs assert properties related to consistency and availability, they don't assert anything related to authentication or authorization.

pookha 4y ago

CRDT's can be encrypted end-to-end. Privacy seems to be one of the selling points.

preseinger 4y ago
Privacy and encryption are entirely orthogonal to CRDTs vs. alternatives.

CGamesPlay 4y ago

These are orthogonal to one another. For read-protection, encryption is a viable solution: specific paths into your data structure (e.g. certain keys in a map) can be encrypted with a key that isn't provided to all participants. For write-protection, the solution is the same as with any syncing service: when receiving an update, if you don't authorize the sender of the update, you don't accept it.

samwillis 4y ago

> A CRDT assumes that every participate has equal rights to all data. Within a single data structure yes, so within a "room" or "document". If you need to partition right to the data (read/update) then you should use separate structures for each area. Yjs implements this as as "sub documents".

pattrn 4y ago

Is this really the case? While CRDT's are designed to work peer-to-peer, they don't need to be fully connected to all clients. Forcing the synchronization through controlled nodes (a server or cluster) allows adding read/write permissions. Depending on the use case, it may require additional logic for reversing operations before propagating to other clients, or in some cases forcing a client to revert to a snapshot (this can be a bit complex). That's an approach I've used in the past. Have I overlooked something (highly likely)?

mathgladiator 4y ago
P2P generally means all clients can read all the data. Even if some data can be encrypted, it can then be deleted via a peer. Admittedly, I am conflating privacy and access control, and core to my point is that CRDTs are limited in many domains.

charles_f 4y ago

That sounds like a weak counter argument to me, 1) crdt is focusing on the conflict resolution part, access control is not in scope so you need to implement on top. 2) if you are already implementing access control, then filtering out what people don't have access to doesn't seem much more complexity. If you go the full client-side way, you can also add a cryptographic layer to whatever needs hiding 3) one thing I don't see in your solution is the offline aspect to it. With a central authority in the middle and online connectivity, conflicts become unlikely and much smaller, but with offline support, documents et can evolve in drastic ways where having a formalized strategy like what crdt offers makes sense

preseinger 4y ago

> A CRDT assumes that every participate has equal rights to all data. This is not true. CRDTs assert properties related to consistency and availability, they don't assert anything related to authentication or authorization.