by czx111331 on 1/23/24, 12:40 PM with 47 comments
by jitl on 1/23/24, 2:30 PM
> The REG algorithm excels with its fast local update speeds and eliminate concerns about tombstone collection in CRDTs. For instance, if an operation has been synchronized across all endpoints, no new operations will occur concurrently with it, allowing it to be safely removed from the history.
If you remove these ops from history, does that remove the ability to time travel (per the home page "An antidote to regret, enabling historical edits traversal") or merge branches? How can we be sure an operation is synchronized?
If dropping these ops is necessary for speed/storage optimization but disables time-travel, is it possible to put the removed historical/tombstone ops into a "cold storage" that's optional and only loaded for time-travel use?
by lewisjoe on 1/23/24, 3:10 PM
But I'm surprised why this one too hasn't focussed a lot on rich-text block elements (like lists, tables & sections) as much as it focussed on text attributes (like bold and italics).
by mikebelanger on 1/23/24, 10:52 PM
It sounds like this defaults to the server storing the whole state in their binary format, ditto the client-side portion of it. Nothing wrong with the format, but this is an early project, and nobody wants their data in something that's potentially unstable, or something that might get corrupted.
by rubymamis on 1/23/24, 2:18 PM
1. Fork the text
2. Submit proposal
3. Review
4. Merge/Cancel
EDIT: To slightly expand on this - there are many reasons for this intuition - the main, IMO, is that people like to work on text privately before showing it to people. Also, the mental fear of your text interrupted by someone else. There might be even more reasons.
by erlend_sh on 1/23/24, 9:14 PM
by NeutralForest on 1/23/24, 2:27 PM
by doublerabbit on 1/23/24, 5:38 PM
> Application error: a client-side exception has occurred (see the browser console for more information).