| 16 Jul 2025 |
 Zhaofeng Li | but B cannot know the servers keys of A (by policy) | 20:12:03 |
| Zhaofeng Li | and if A goes down forever, no newly-joined homeservers can ever know its keys | 20:12:23 |
 K900 | Most homeservers will trust keys fetched from matrix.org | 20:12:48 |
| K900 | Which are cached ~forever on matrix.org | 20:12:54 |
| K900 | You can configure other servers to be trusted relaying parties for keys | 20:13:38 |
| Zhaofeng Li | In reply to @k900:0upti.me
Most homeservers will trust keys fetched from matrix.org Ah, so this is the part that I'm missing | 20:13:45 |
| K900 | But if a certain server is configured to not trust anyone else | 20:14:14 |
| K900 | And can't reach the origin server of the event | 20:14:14 |
| K900 | It will see an inconsistent state of the room | 20:14:15 |
| Zhaofeng Li | But if A explicitly blocks matrix.org by policy and a newly-joined homeserver doesn't configure additional trusted servers, the room will still be (partly) unusable, right? | 20:15:57 |
| K900 | Kinda | 20:16:50 |
| K900 | It depends on how you even join the room | 20:16:57 |
| K900 | Because you need to talk to another server to join a room | 20:17:11 |
| K900 | So if you just can't federate, you can't do that either | 20:17:26 |
| Zhaofeng Li | In reply to @k900:0upti.me
Because you need to talk to another server to join a room let's say the newly-joined homeserver can talk to all homeservers including B and matrix.org (both blocked by A) | 20:18:20 |
| K900 | Can they talk to A though? | 20:18:42 |
| K900 | If they can talk to A, they'll fetch the keys directly | 20:18:47 |
| K900 | So B and the new server will be on different sides of the split | 20:19:17 |
| Zhaofeng Li | In reply to @k900:0upti.me
Because you need to talk to another server to join a room * let's say the newly-joined homeserver can talk to all homeservers including B and matrix.org (both blocked by A) except for A which is down forever | 20:19:55 |
| K900 | Like fundamentally Matrix room state is not consensus, it's CRDT | 20:21:49 |
| K900 | So different participants seeing different states is expected | 20:22:02 |
| K900 | And ideally everything gets reconciled in the end | 20:22:17 |
| Zhaofeng Li | In reply to @k900:0upti.me
Like fundamentally Matrix room state is not consensus, it's CRDT right, it makes sense, but practically it's... unproductive? | 20:22:37 |
| K900 | It is | 20:23:44 |
| Zhaofeng Li | any participating homeserver can become load-bearing and make the room unusable (for many common use cases) | 20:24:35 |
| K900 | I don't think there's a solution for achieving this that is actually good | 20:24:57 |
| K900 | Any sort of consensus algorithm is susceptible to 51% attacks | 20:25:16 |
| K900 | And CRDTs are susceptible to splits | 20:25:28 |
 @magic_rb:matrix.redalder.org | 51% is a fun one, ive long been fascinates by distributed systems, but any system you come up with which is based on consensus can be taken over by the 51% thing | 20:30:40 |
| K900 | The only thing I can think of is doing some kind of roughtime thing | 20:31:15 |
