3 ms·

So if #foo:example.com is in use in a cluster of servers and there's a netsplit for some reason and servers in group A lose connection with group B but both gro

So if #foo:example.com is in use in a cluster of servers and there's a netsplit for some reason and servers in group A lose connection with group B but both groups continue using the channel, what happens to the message history when the netsplit is resolved?

q3k 5y ago
All room events (ie. messages) are part of a DAG, with each message indicating the most recent causality source, eg. another message that the client saw when sending this one. Think vector clocks, but more explicit. Any time an event arrives referencing some other missing event, servers and clients can act on that knowing that there's some kind of split happening. Each event is also signed by the homeserver of the originator of the messages, so missing messages (due to partial netsplits) can be routed through third-parties, around the netsplit. For full split-brain scenerios, after a merge, the two DAGs get joined and the effective room state is reconciled. The big picture is that Matrix rooms are best seen as eventually-consisted distributed event log . :) https://matrix.org/docs/spec/#event-graphs https://matrix.org/docs/spec/#event-graphs
Arathorn 5y ago
The scrollback ends up syncing up after the netsplit on both sides of the partition - you see a flood of messages come in from the other side of the split. In the relatively near future the remote side of the split will shown as a thread (if your client supports threads). Technically, every message you send in Matrix is a mini-netsplit which then resolves as soon as it's received by the other server(s). So you don't tend to notice partitions, unless they go on for minutes on end and disrupt the conversation, but even then the history syncs up afterwards.
ryukafalz 5y ago
From the server's perspective, the graph of conversation history from group A and group B merge. From the client's perspective... depends on the client I think, but most seem to display the messages from the other side of the split all at once when they're first received. Clients don't currently make it clear when messages came from the other side of a long netsplit, but the data is there on the server so in principle they could. I think the client API might need some changes before that'd be possible though.

q3k 5y ago

All room events (ie. messages) are part of a DAG, with each message indicating the most recent causality source, eg. another message that the client saw when sending this one. Think vector clocks, but more explicit. Any time an event arrives referencing some other missing event, servers and clients can act on that knowing that there's some kind of split happening. Each event is also signed by the homeserver of the originator of the messages, so missing messages (due to partial netsplits) can be routed through third-parties, around the netsplit. For full split-brain scenerios, after a merge, the two DAGs get joined and the effective room state is reconciled. The big picture is that Matrix rooms are best seen as eventually-consisted distributed event log . :) https://matrix.org/docs/spec/#event-graphs https://matrix.org/docs/spec/#event-graphs

Arathorn 5y ago

The scrollback ends up syncing up after the netsplit on both sides of the partition - you see a flood of messages come in from the other side of the split. In the relatively near future the remote side of the split will shown as a thread (if your client supports threads). Technically, every message you send in Matrix is a mini-netsplit which then resolves as soon as it's received by the other server(s). So you don't tend to notice partitions, unless they go on for minutes on end and disrupt the conversation, but even then the history syncs up afterwards.

ryukafalz 5y ago

From the server's perspective, the graph of conversation history from group A and group B merge. From the client's perspective... depends on the client I think, but most seem to display the messages from the other side of the split all at once when they're first received. Clients don't currently make it clear when messages came from the other side of a long netsplit, but the data is there on the server so in principle they could. I think the client API might need some changes before that'd be possible though.