4 ms·

I touch on this in the blog post: I personally believe CRDTs are the future. For some things. It’s possible that developers will need to be selectiv

I touch on this in the blog post: I personally believe CRDTs are the future. *For some things.* It’s possible that developers will need to be selective about their “level” of offline support [example table for a blog post] Perhaps it’s not that important if the title has a “last write wins” strategy, because it’s rarely updated and less likely to have a merge conflict. But it is critical to use a smarter algorithm for the content of the blog post, especially in a team where multiple users are editing a blog post at the same time.

danbruc 4y ago
The C in CRDT is for conflict-free, i.e. there must not be any conflicts between operations. Incrementing and decrementing a counter, the final result will be the same independent of the order of operations. You can almost not get any further away from a CRDT than last write wins. And for more complicated merge strategies you are essentially guessing what the desired result is but you do not know and everything really depends on the quality of your guesses. Like the example with the changed fruits in the list, maybe one or the other should end up in the final result, maybe both, maybe none. The correct conflict resolution strategy is not obvious and highly dependent on the use case, that is why I said that implementations are usually not general or they are only general in the sense that you can plug in any behavior you like. Compare this with a real CRDT like a counter, there there is absolutely no doubt about the desired outcome.
- AlexErrant 4y ago
  It's on the application developer to choose the correct CRDT for the job. Last write wins is there as a CRDT of last resort - there's a trade off between the very general but "weak" LWW and the specific but "powerful" counter. (In my own app, I plan on observing "failed" LWW writes and surfacing them to the user as notifications or something transient.) Ideally one could choose a CRDT where the semantics of an application conflict are the same as CRDT conflicts, but we don't live in an ideal world. I don't think you'll find anyone arguing that CRDTs are a silver bullet.
  - danbruc 4y ago
    Maybe my point is just that those things should not be called CRDTs. There are conflicts in the basic operations and you just decide on a case by case basis how to resolve them which makes the entire construct look superficially like a CRDT but kind of ignores the core characteristic of CRDTs, namely that the operations never conflict.
    - preseinger 4y ago
      LWWRegister does provide the deterministic guarantee that operations never conflict. The "problem" is just that the decision is basically arbitrary.
- jclem 4y ago
  An LWW register is most certainly a CRDT, it just has limited use. I think you’re making a good point about how one must be careful applying CRDTs, but I don’t think it’s accurate to say that a suboptimal merge strategy in terms of user experience means that something does not meet the definition of a CRDT. In other words, the “conflict-free” part of the term refers to the fact that all replicas converge on the same value when all updates have been exchanged. What you’re discussing seems to have more to do with concerns around intention preservation when using CRDTs. In other words, an LWW register on a text field is still a CRDT, but in many applications it is potentially a poor choice in terms of preserving the intent of user-generated operations, but determining this is something done in a case-by-case basis. If the content is a long document which users collaborate on over time, then a register is most certainly a poor choice. If it is a short text field akin to a label, an LWW register isn’t necessarily bad, because user intent is likely to replace the entire value, rather than to perform minute edits on the value.
  - danbruc 4y ago
    I just reread the Wikipedia article on CRDTs and was actually wrong. I only had a subset of CRDTs in mind but they actually encompass a much wider class than I thought. In some way I now understand the fuzz about them even less, they now look almost trivial, but maybe I am still not understanding some important aspect properly. Should maybe read the paper introducing them. But at the very least I should not complain about people calling things CRDTs that actually fall under the actual definition.
    - kiwicopple 4y ago
      > But at the very least I should not complain about people calling things CRDTs that actually fall under the actual definition that's... a very reasonable response. Nice one. I think the fuzz comes from the more esoteric CRDTs, which solve actually hard problems (traditionally solved by Operational Transforms). But I don't think I could have created a simple example in the blog post for one of these.
- jamil7 4y ago
  The point is that they all eventually converge on the same value, and can do that independent of some centralised merging location, rather than the exact way in which they do that, whether that's LLW or anything else.
  - danbruc 4y ago
    Just store all updates - as if you do event sourcing - ordered by a timestamp. The list of updates will eventually converge as will any function of that list, including any function that merges all the updates into a current state. You might have to [partially] reevaluate the function in case a delayed update shows up and has to be inserted into the middle of the list of updates. So I guess there are additional requirements in order to qualify as a CRDT, bounded additional space or bounded amount of computation on updates. But I don't know as it turned out my understanding of what qualifies as a good CRDT was too narrow.
    - jamil7 4y ago
      Yeah event sourcing and what you described is what these libraries are calling delta CRDTs. The appeal is they’re hiding away the actual event log, metadata and rebasing/merging parts and exposing data types that look something like what you’d normally use.
      - melony 4y ago
        And if you tie the conflict resolution logic to the individual delta operations, you get Operational Transforms.

I touch on this in the blog post: I personally believe CRDTs are the future. *For some things.* It’s possible that developers will need to be selectiv

danbruc 4y ago

The C in CRDT is for conflict-free, i.e. there must not be any conflicts between operations. Incrementing and decrementing a counter, the final result will be the same independent of the order of operations. You can almost not get any further away from a CRDT than last write wins. And for more complicated merge strategies you are essentially guessing what the desired result is but you do not know and everything really depends on the quality of your guesses. Like the example with the changed fruits in the list, maybe one or the other should end up in the final result, maybe both, maybe none. The correct conflict resolution strategy is not obvious and highly dependent on the use case, that is why I said that implementations are usually not general or they are only general in the sense that you can plug in any behavior you like. Compare this with a real CRDT like a counter, there there is absolutely no doubt about the desired outcome.

AlexErrant 4y ago
It's on the application developer to choose the correct CRDT for the job. Last write wins is there as a CRDT of last resort - there's a trade off between the very general but "weak" LWW and the specific but "powerful" counter. (In my own app, I plan on observing "failed" LWW writes and surfacing them to the user as notifications or something transient.) Ideally one could choose a CRDT where the semantics of an application conflict are the same as CRDT conflicts, but we don't live in an ideal world. I don't think you'll find anyone arguing that CRDTs are a silver bullet.
- danbruc 4y ago
  Maybe my point is just that those things should not be called CRDTs. There are conflicts in the basic operations and you just decide on a case by case basis how to resolve them which makes the entire construct look superficially like a CRDT but kind of ignores the core characteristic of CRDTs, namely that the operations never conflict.
  - preseinger 4y ago
    LWWRegister does provide the deterministic guarantee that operations never conflict. The "problem" is just that the decision is basically arbitrary.
jclem 4y ago
An LWW register is most certainly a CRDT, it just has limited use. I think you’re making a good point about how one must be careful applying CRDTs, but I don’t think it’s accurate to say that a suboptimal merge strategy in terms of user experience means that something does not meet the definition of a CRDT. In other words, the “conflict-free” part of the term refers to the fact that all replicas converge on the same value when all updates have been exchanged. What you’re discussing seems to have more to do with concerns around intention preservation when using CRDTs. In other words, an LWW register on a text field is still a CRDT, but in many applications it is potentially a poor choice in terms of preserving the intent of user-generated operations, but determining this is something done in a case-by-case basis. If the content is a long document which users collaborate on over time, then a register is most certainly a poor choice. If it is a short text field akin to a label, an LWW register isn’t necessarily bad, because user intent is likely to replace the entire value, rather than to perform minute edits on the value.
- danbruc 4y ago
  I just reread the Wikipedia article on CRDTs and was actually wrong. I only had a subset of CRDTs in mind but they actually encompass a much wider class than I thought. In some way I now understand the fuzz about them even less, they now look almost trivial, but maybe I am still not understanding some important aspect properly. Should maybe read the paper introducing them. But at the very least I should not complain about people calling things CRDTs that actually fall under the actual definition.
  - kiwicopple 4y ago
    > But at the very least I should not complain about people calling things CRDTs that actually fall under the actual definition that's... a very reasonable response. Nice one. I think the fuzz comes from the more esoteric CRDTs, which solve actually hard problems (traditionally solved by Operational Transforms). But I don't think I could have created a simple example in the blog post for one of these.
jamil7 4y ago
The point is that they all eventually converge on the same value, and can do that independent of some centralised merging location, rather than the exact way in which they do that, whether that's LLW or anything else.
- danbruc 4y ago
  Just store all updates - as if you do event sourcing - ordered by a timestamp. The list of updates will eventually converge as will any function of that list, including any function that merges all the updates into a current state. You might have to [partially] reevaluate the function in case a delayed update shows up and has to be inserted into the middle of the list of updates. So I guess there are additional requirements in order to qualify as a CRDT, bounded additional space or bounded amount of computation on updates. But I don't know as it turned out my understanding of what qualifies as a good CRDT was too narrow.
  - jamil7 4y ago
    Yeah event sourcing and what you described is what these libraries are calling delta CRDTs. The appeal is they’re hiding away the actual event log, metadata and rebasing/merging parts and exposing data types that look something like what you’d normally use.
    - melony 4y ago
      And if you tie the conflict resolution logic to the individual delta operations, you get Operational Transforms.