| 6 Mar 2025 |
 emily | (and do some permissions-fiddling) | 18:28:09 |
 artemist | Oh, so the room ID would have to be on another server? | 18:29:06 |
| emily | yes, but room IDs are ~irrelevant | 18:31:54 |
| emily | homeservers don't actually own rooms at all | 18:31:58 |
| emily | room IDs are opaque identifiers that happen to encode one homeserver for no real good reason | 18:32:07 |
| artemist | oh god why is matrix like this | 18:32:15 |
| emily | then on top of that you can have aliases which can be on the NixOS server etc. | 18:32:17 |
| artemist | If the encoded server goes down does the room still work? | 18:32:41 |
| emily | like this room is !GsmxjHfeAYLsTEQmjS:nixos.org | 18:32:43 |
| emily | but it's also #matrix-discussion:nixos.org | 18:32:47 |
| emily | you can have a bunch of aliases like the latter on various servers | 18:32:53 |
| emily | yes. rooms are completely distributed across homeservers, no one homeserver has authority in it | 18:33:04 |
| emily | except I guess that it gets to specify the initial state in terms of privileged users? | 18:33:14 |
| emily | not sure how that works | 18:33:21 |
| emily | anyway, the room ID is just the !sdjfkdsjf thing. | 18:33:44 |
| emily | #foo:nixos.org is an alias, and can be added after the fact, and the servers do not need to match the room ID | 18:33:56 |
| artemist | Yeah, I'm thinking about if I have !randomblah:mildlyfunctional.gay as a room key and stop running matrix on mildlyfunctional.gay | 18:35:04 |
| emily | yes, that's fine | 18:39:44 |
| emily | like I said, it's totally opaque | 18:39:45 |
| emily | your homeserver couldn't even take over the room if it wanted to | 18:39:56 |
| emily | state resolution is completely distributed | 18:40:00 |
| 7 Mar 2025 |
|  Qyriad changed their display name from Qyriad to qyriad. | 16:42:15 |
| 8 Mar 2025 |
 @emma:rory.gay | if you want federation traffic to cease you still need to leave all rooms for all users | 01:46:32 |
 f0x | In reply to @emilazy:matrix.org
room IDs are opaque identifiers that happen to encode one homeserver for no real good reason well, so the server that created it can guarantee global uniqueness | 03:34:15 |
| emily | because if you were just relying on 128 bits of good old-fashioned entropy you could have two starved VMs that accidentally create the same room? | 03:35:26 |
| emily | seems like you'd run into cryptography problems in such a setting anyway | 03:36:10 |
| f0x | In reply to @emilazy:matrix.org
because if you were just relying on 128 bits of good old-fashioned entropy you could have two starved VMs that accidentally create the same room? rather stuff like a malicious entity claiming they created a (different) room with that id, I think | 03:38:06 |
| emily | I guess I don't understand the protocol well enough to grok the threat model. (I don't really know how room creation works at all) | 03:38:49 |
| emily | my understanding was that there was work on getting the homeserver out of room IDs, though? | 03:39:01 |
| emily | (and out of user IDs but I think that stalled) | 03:39:06 |
