| 6 Mar 2025 |
 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 |
| f0x | In reply to @emilazy:matrix.org
my understanding was that there was work on getting the homeserver out of room IDs, though? I'm not sure? They were removed from event id's because they were no longer needed there | 03:42:43 |
| @emma:rory.gay | no, the room id is a hash of the create event iirc | 04:25:49 |
| @emma:rory.gay | its just to avoid conflicts between homeservers | 04:26:01 |
 Ralith | In reply to @f0x:pixie.town
rather stuff like a malicious entity claiming they created a (different) room with that id, I think if anything, having the hs in the id makes that easier since it's predictable but not authenticated in any way | 08:28:23 |
| Ralith | it was always a kinda baffling decision | 08:28:34 |
 Cat | In reply to @emma:rory.gay
no, the room id is a hash of the create event iirc It’s not. That’s the proposed solution to make them not have a homeserver in there. | 10:38:02 |
