Imagine two editors preparing an expedition schedule while their laptops are disconnected. One changes the departure to Tuesday. The other changes the transport note to say that the boat only runs on Wednesday. When the machines reconnect, both edits survive. Every laptop displays exactly the same document. The expedition is still in trouble.
That small invented example exposes a distinction that gets lost in enthusiasm for collaborative software. Agreement between machines is a valuable achievement. Agreement between the statements in a document is a different achievement, and agreement between the people responsible for it is different again. A system can deliver the first while leaving the other two entirely unsettled.
What the machinery actually promises
Conflict-free replicated data types, usually shortened to CRDTs, give independently edited replicas rules for combining updates. The attractive property is convergence: replicas that receive the relevant changes can reach the same state under the system's rules. The word conflict in the name refers to a technical merging problem. It does not certify the resulting document as sensible.
Automerge's documentation on conflicts makes that boundary unusually concrete. Concurrent assignments to the same property produce a deterministic visible winner, while alternative values remain available through its conflict interface. The internal ordering uses operation identifiers rather than a simple comparison of human wall clocks. A value appearing in the ordinary object therefore need not be a value everyone deliberately approved.
For our imagined schedule, that means the application designer needs to decide what a departure date is. A plain property can hold one selected date. A review object can additionally record two proposals and their reasons. These are different models of the same human situation. Choosing the simpler representation is a product decision with consequences for what the interface can explain later.
The documented merge rules also distinguish maps, lists, text, and counters. A counter can combine independent increments; a list uses element identities to locate operations. Those rules do useful work because the data model supplies structure. They cannot infer that an increase in the number of passengers requires another life jacket unless somebody represents and enforces that relationship.
Preserving a keystroke is only one kind of respect
It would be a mistake to dismiss automatic merging because it cannot arrange an expedition. Having to reconstruct another person's lost paragraph is a miserable use of human attention. A tool that preserves work and produces a consistent shared view removes a real obstacle to collaboration.
But preservation is not exhausted by retaining characters. Consider an editor who adds a warning to a paragraph while another editor removes the paragraph because it describes a rejected plan. Depending on the representation and operations, the resulting state might be mechanically correct while surprising one or both editors. The interesting design question is how they learn what happened and what they can do about it.
The Peritext research studies this problem at the level of rich text. Concurrent formatting and insertion require decisions about which new characters inherit a mark, and incompatible formatting can require a deterministic choice. The authors explicitly acknowledge that merging cannot always recover human intent. Their examples show why making formatting a deliberate model is better than hoping plain-text merging will accidentally produce the desired document.
A bold span is a modest example, but it reveals a general habit worth keeping: specify the expected behavior at the boundary. Where does a comment attach after an insertion? What happens to a link when text arrives at its edge? Which surprises are acceptable, and which need an explanation? These questions belong in design discussions before a confusing merged document reaches a reader.
The review surface is part of the system
For the fictional expedition application, I would want a small review surface around changes that affect commitments. This is a design proposal, rather than a claim about any existing library. It could show that the departure date changed independently of the boat note and invite someone to reconcile them. It would avoid interrupting ordinary spelling corrections with the same ceremony.
The difference matters. An interface that announces every concurrent operation will quickly teach people to ignore its warnings. An interface that announces none turns an implementation's tie-breaking rule into an invisible editor. The useful middle ground depends on the domain: dates and approvals may deserve treatment that a paragraph's punctuation does not.
Review also needs a stopping condition. After someone inspects the competing proposals and chooses a departure, the application should record that decision as a new act, with enough context to distinguish deliberate acceptance from an arbitrary visible winner. Otherwise the next reader inherits a tidy page without knowing whether anybody resolved the contradiction.
This is where local-first ambitions become more demanding and more interesting. The original local-first essay connects collaboration with ownership, offline work, and long-term access. Those goals invite software that respects a person's ability to work independently. Independence creates moments when people make reasonable decisions from different information. A respectful application must help them meet again afterward.
Test the conversation as well as the merge
A useful design exercise is to write down two reasonable stories before testing a merge. In the schedule example, one editor has a weather forecast and another has the transport operator's timetable. Neither person behaves foolishly. Both changes are locally sensible. The merged document should make their differing information easier to reconcile.
Then inspect more than the final JSON. Ask what each editor sees after reconnecting, whether either can find the competing value, and how a third colleague recognizes a reviewed decision. These are proposed evaluation questions, not measured findings. They expose shortcomings that a test asserting equal replica states cannot see.
The most humane collaborative software gives automation a precise job and gives people a legible place to exercise judgment. Let the machinery gather the edits and maintain a common state. Let the interface reveal the disagreements that still matter. A synchronized departure date is a good beginning. Somebody still has to check when the boat leaves.
A thought worth keeping?
