> How does Matrix deal with netsplits and partial-netsplits? > How are highly diverged histories (e.g. a long netsplit in an active room) supposed to be merged

> How does Matrix deal with netsplits and partial-netsplits? > How are highly diverged histories (e.g. a long netsplit in an active room) supposed to be merged? So the cool thing with the federation in matrix is that all the messages (and state changes like room memberships) are part of a directed acyclic graph (DAG), so any new messages that are sent reference the previous ones. (Very much like git). That way a server can tell if it is missing any messages as long as it can talk to a server in the room. Since everything is signed by the originating servers, servers can pull in missing messages from third parties! Thus partial-netsplits are fine, as all the messages will eventually propagate through to all servers :) When a full netsplit happens you effectively get two separate branches in the graph, each group of servers happily talking to each other. When a netsplit is resolved, one of the servers will realise they can talk to one of the other servers, at which point one of the them will send an event that references both branches (in effect merging them). All the other servers will then realise what they are missing and pull the branches in. At that point a certain amount of state resolution needs to happen (e.g. if people joined and left on the different branches) to ensure that all the servers have a consistent view of the state of the room. The really difficult problem we've found is how you communicate to the clients about the netsplits, and how the clients should display the netsplits (although this is more of a UX issue, but still important). Since the messages in the room are stored as a DAG, the servers can see what messages were part of which netsplit and so that information can be made available to the clients. > Does the protocol require O(N^2) connections for N users? (The number of users in some IRC rooms is measured in thousands.) Can it be more efficient? Currently the protocol uses full mesh to distribute the messages to all the servers (which in practice are going to be fewer than the number of users in the channel), though since it uses HTTP the servers don't need to maintain active connections to all other servers. We really want to come up with new distribution models for really large rooms at some point, but we haven't quite gotten that far yet :) > How are rooms administered? The user that created the room gets admin rights to the room and given a "power level". The admin can set the power level required to do different things, (e.g. kick, ban, set the name of the room etc), as well as whether you need an invite to join the room or not. They can also grant (and revoke) power levels to other members of the room. Now, if a remote server intentionally ignores these rules then other servers in the room will simply not accept the dodgy actions. All actions, whether message sending or banning someone requires the server be able to prove that they had permission to do that by supplying a list of events along the lines: "I can ban because I have power level X, which was assigned by Y, who could do that because...". (I'm part of the matrix team ftr.)