4 ms·

I think it's important to note that "they do not yet". CRDTs are an active area of research, relatively young, and it is not unreasonable to expect that new dat

I think it's important to note that "they do not yet". CRDTs are an active area of research, relatively young, and it is not unreasonable to expect that new datastructures which DO align to users' mental models will appear in the not-too-distant future.

cryptonector 6y ago
CRDT is very well understood. The basics of the theory is utterly trivial. The only question is whether we can design new monoids that line up better with human understandings of their own intent -- of this I am skeptical because our mental models of what we're doing are not at all monoidal, though because CRDTs are so elegant and so simple, I would be ecstatic if indeed we find/design such monoids.
- dnautics 6y ago
  what do you think of Martin Klepmann's research, e.g: https://martin.kleppmann.com/2020/07/06/crdt-hard-parts-hydra.html https://martin.kleppmann.com/2020/07/06/crdt-hard-parts-hydr...
  - cryptonector 6y ago
    I'll watch it and let you know. Sounds very interesting!
    - cryptonector 6y ago
      I'm part of the way through. Here are some thoughts. - Is there a way to materialize all of the past up to some point, throwing out history in the process, so as to reduce the overhead of CRDT? - Some CRDT algorithms (really, representations of operations) are better at modeling a user's intent -- rather than "insert 'H' at 101, insert 'e' at 102, ..." and so on, it's "insert 'Hello' between ...". As I'm not familiar with OT, I wonder whether this begins to approach OT... In any case, some of the better CRDT algorithms for text editing tend to require more overhead, which is why the preceding thought. - I'm much more interested in CRDTs for distributed relational databases, where it's much easier to reason about intent. "Relational" really means "has a well defined, enforced schema", while "text" means "anything goes" -- it's necessarily easier to reason about the former than the latter! Even so, a set of related updates to a relational database may be the complex result of a simpler abstraction -a simpler operation that the user intended- and eventual consistency semantics may ruin that result. One way to deal with that is to centralize certain kinds of operations, but those had better be less essential to business continuity.
      - dnautics 6y ago
        thanks for those thoughts! - I'm with you on point #1. Obviously could be a source of good research, but also, it probably depends on policy. How many undos do you want to preserve? Even a one-headed VSCode instance only saves so many undos. You could probably hybrid CRDT with a consensus algorithm like raft to perform compactions.
        cryptonector 6y ago
        Right, if it's about undo history, screw that, at some point you don't care anymore -- you might build a sort of VCS into the text editor so you can keep track of changes in a less granular way. If it's about knowing when you have all the history before some point in time, then that's doable. And thanks for the link!

cryptonector 6y ago

CRDT is very well understood. The basics of the theory is utterly trivial. The only question is whether we can design new monoids that line up better with human understandings of their own intent -- of this I am skeptical because our mental models of what we're doing are not at all monoidal, though because CRDTs are so elegant and so simple, I would be ecstatic if indeed we find/design such monoids.

dnautics 6y ago
what do you think of Martin Klepmann's research, e.g: https://martin.kleppmann.com/2020/07/06/crdt-hard-parts-hydra.html https://martin.kleppmann.com/2020/07/06/crdt-hard-parts-hydr...
- cryptonector 6y ago
  I'll watch it and let you know. Sounds very interesting!
  - cryptonector 6y ago
    I'm part of the way through. Here are some thoughts. - Is there a way to materialize all of the past up to some point, throwing out history in the process, so as to reduce the overhead of CRDT? - Some CRDT algorithms (really, representations of operations) are better at modeling a user's intent -- rather than "insert 'H' at 101, insert 'e' at 102, ..." and so on, it's "insert 'Hello' between ...". As I'm not familiar with OT, I wonder whether this begins to approach OT... In any case, some of the better CRDT algorithms for text editing tend to require more overhead, which is why the preceding thought. - I'm much more interested in CRDTs for distributed relational databases, where it's much easier to reason about intent. "Relational" really means "has a well defined, enforced schema", while "text" means "anything goes" -- it's necessarily easier to reason about the former than the latter! Even so, a set of related updates to a relational database may be the complex result of a simpler abstraction -a simpler operation that the user intended- and eventual consistency semantics may ruin that result. One way to deal with that is to centralize certain kinds of operations, but those had better be less essential to business continuity.
    - dnautics 6y ago
      thanks for those thoughts! - I'm with you on point #1. Obviously could be a source of good research, but also, it probably depends on policy. How many undos do you want to preserve? Even a one-headed VSCode instance only saves so many undos. You could probably hybrid CRDT with a consensus algorithm like raft to perform compactions.
      - cryptonector 6y ago
        Right, if it's about undo history, screw that, at some point you don't care anymore -- you might build a sort of VCS into the text editor so you can keep track of changes in a less granular way. If it's about knowing when you have all the history before some point in time, then that's doable. And thanks for the link!