Question about style conflicts

[gaborsar]

If it is not a big problem, I would have a small question about the CRDT of the editor: How did you solve attribute update conflicts?

Scenario:

1. User A and user B both offline.
2. User A makes atom X bold.
3. User B makes atom X bold.
4. User B makes atom X non-bold.
5. User A and user B both go online.
6. User A have to following operations for atom X: (bold) + (bold + not-bold) => (not-bold)
7. User B have to following operations for atom X: (bold + not-bold) + (bold) => (bold)
8. User A and user B have a different version of atom X after they have received every operation.

[rocketraman]

@gaborsar Actually the underlying CRDT remains consistent. The underlying CRDT will update based on LWW, where "last" is determined on the lamport timestamp of the operation (with the current implementation).

However, I just tested this with the demo @ http://demo-ritzy.rhcloud.com/ and you're right that the editor does get out of sync, even though the underlying CRDT is correct. The editor is not getting the event notification from the CRDT data structure that something has changed, which is probably a bug in the current CRDT implementation (swarm).

You can confirm that the CRDT is correct by selecting the text, and printing the CRDT to the console, and checking the attributes of the atom of interest. You'll also likely see that if you make an edit on that line, the attributes will "fix themselves" since the edit forces the editor to re-read the CRDT state.

[gaborsar]

@rocketraman Is not the timestamp attached to the char itself?

[rocketraman]

@gaborsar Yes, and since the attribute is attached to the char also, it inherits the timestamp.

[gaborsar]

@rocketraman I see, but if that is true, than a format operation supposed to remove the character and insert a new that is a formatted copy of the original one?

[rocketraman]

@gaborsar I'm working off of memory here, but you may have been right before -- the attributes are set on a char with a particular timestamp (id). Needs further investigation... replacing chars is not a good idea because we don't want a format operation to conflict with a concurrent insertion inside the formatted area. Its possible the attributes for a char should be their own CRDT.

[gaborsar]

@rocketraman So you mean that the attributes object under the hood is a CRDT list and each formatting update appends a new updated version on the top of it?
Something like this (WOOT in this case)?:

const text = [{
  ID: 'U1-C1',
  prev: '',
  next: '',
  visible: true,
  value: 'x',
  attributes: [{
    ID: 'U1-A1',
    prev: '',
    next: 'U1-A2',
    value: null
  }, {
    ID: 'U1-A2',
    prev: 'U1-A1',
    next: 'U1-A3',
    value: {
      bold: true
    }
  }, {
    ID: 'U1-A3',
    prev: 'U1-A2',
    next: '',
    value: {
      bold: false,
      italic: true
    }
  }]
}]

[rocketraman]

@rocketraman So you mean that the attributes object under the hood is a CRDT list

No, I meant that it probably should be, not that it is :-)

[gaborsar]

@rocketraman Ah OK :). I did check and the CRDT is consistent. I guess I going to check in Swarm how does it work. :) Thank you for your help!