| 8 Mar 2025 |
 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 |
