| 6 Mar 2025 |
 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 |
| Cat | The room ID is an opaque string with 0 meaning and no defined algorithm for its creation just a rule about that the origin hs is the same as room creator. | 10:39:12 |
| emily | In reply to @ralith:ralith.com
if anything, having the hs in the id makes that easier since it's predictable but not authenticated in any way okay yeah this is what I was unsure about | 13:08:16 |
| emily | so it's truly pointless | 13:08:40 |
| emily | In reply to @cat:feline.support
The room ID is an opaque string with 0 meaning and no defined algorithm for its creation just a rule about that the origin hs is the same as room creator. I'm surprised people don't use it to put fake vanity domains in | 13:08:41 |
| Cat | The full ruleset for room ids are !*:homeserver and the * represents all legal characters. | 13:16:48 |
| emily | but if the home server isn't authenticated you can put whatever you want there, right? | 13:21:06 |
