[fiddlerwoaroof]

I think you basically want a partial order for federated chat: messages should arrive after the messages that cause them but not necessarily after messages that didn’t cause them. In the case of a network partition, this allows people on either side of the partition to continue communicating at the cost of non-determinism when the partition is resolved.

[duskwuff]

I'd maintain that an important property is for the system to be eventually consistent with regards to history. You don't want a transient network event to potentially result in two users permanently seeing messages in a different order.

[fiddlerwoaroof]

I don’t think you can prevent that without centralizing on a single server

[lmm]

You can, but it results in the situation the article is complaining about.

During a netsplit, people chatting on opposite sides of the netsplit continue to be able to chat (by design), but will (obviously) see a different history from each other. So when the netsplit heals, you have a dilemma: either you splice the history from the other side in, giving eventual consistency at the cost of changing the history that people have already read, or you keep permanently different histories on servers that were on one side or the other.

[immibis]

You could put the other side into something that looks visually like a thread. Each side will have a different history. They will also have a marker that says the history was split here and click here to view the other side.

[lmm]

If you can come up with a good design for what a client that does that should look like, and what information it would need from the server to do that, please do write it up and publicise it. I think ultimately something like that has to be the solution, but it would have to be actually fleshed out into something that's possible to implement.