4 ms·

Also, if the monoids used in a CRDT implementation do not align with the mental model users have for what they're doing (hint: they do not), then the result wil

Also, if the monoids used in a CRDT implementation do not align with the mental model users have for what they're doing (hint: they do not), then the result will be artifacts the users don't like. Single user text editing is amenable to using ropes and monoids internally because none of that leaks into the UI/UX, but multi-user text editing is not amenable to representation as monoidal interactions because in the multi-user case the monoidal interactions will become evident and confusing. Or at least that's the lesson I took from all the xi blogs I've read.

hinkley 6y ago
This is a problem we need to solve with code editors and version control as well. Patches are always a little bit garbage, and can cause extra problems with 3 way merges because of it.
- Chris2048 6y ago
  In feel this is probably a language-level problem, and solving it only at editor/VC level will be complicated. At the same time, changes to the lang level would require changes at editor/VC level too. As en example: a MIX type syntax can separate classes and class-methods into different files, and combine them back again. This way moving a class method around in a class won't be seen as removing a method and creating a new one: the file give the specific method an identity, and a method of differentiating between code movement and code alteration.
dnautics 6y ago
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.

hinkley 6y ago

This is a problem we need to solve with code editors and version control as well. Patches are always a little bit garbage, and can cause extra problems with 3 way merges because of it.

Chris2048 6y ago
In feel this is probably a language-level problem, and solving it only at editor/VC level will be complicated. At the same time, changes to the lang level would require changes at editor/VC level too. As en example: a MIX type syntax can separate classes and class-methods into different files, and combine them back again. This way moving a class method around in a class won't be seen as removing a method and creating a new one: the file give the specific method an identity, and a method of differentiating between code movement and code alteration.

dnautics 6y ago

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.