[WIP] MSC4051: Using the create event as the room ID #4051
Conversation
turt2live
added
requires-room-version
Room IDs being splittable into localpart and servername does not have much inherent value and there are proposals like MSC4051¹ that propose changing the format. Relaxing the rules makes Ruma forwards-compatible with those proposals. The server_name accessor is kept because it is used by at least one downstream, but is updated to return an `Option`. ¹ matrix-org/matrix-spec-proposals#4051
Room IDs being splittable into localpart and servername does not have much inherent value and there are proposals like MSC4051¹ that propose changing the format. Relaxing the rules makes Ruma forwards-compatible with those proposals. The server_name accessor is kept because it is used by at least one downstream, but is updated to return an `Option`. ¹ matrix-org/matrix-spec-proposals#4051
Room IDs being splittable into localpart and servername does not have much inherent value and there are proposals like MSC4051¹ that propose changing the format. Relaxing the rules makes Ruma forwards-compatible with those proposals. The server_name accessor is kept because it is used by at least one downstream, but is updated to return an `Option`. ¹ matrix-org/matrix-spec-proposals#4051
Room IDs being splittable into localpart and servername does not have much inherent value and there are proposals like MSC4051¹ that propose changing the format. Relaxing the rules makes Ruma forwards-compatible with those proposals. The server_name accessor is kept because it is used by at least one downstream, but is updated to return an `Option`. ¹ matrix-org/matrix-spec-proposals#4051
Room IDs being splittable into localpart and servername does not have much inherent value and there are proposals like MSC4051¹ that propose changing the format. Relaxing the rules makes Ruma forwards-compatible with those proposals. The server_name accessor is kept because it is used by at least one downstream, but is updated to return an `Option`. ¹ matrix-org/matrix-spec-proposals#4051
|
Seems like a good idea. Event id, being a hash, would uniquely identify a room. |
| A new room version is established to accommodate the event format, redaction, and identifier changes | ||
| from this proposal. | ||
|
|
||
| The `room_id` field is removed from events, and no longer protected from redaction. The create event's |
There was a problem hiding this comment.
room_id is still to be kept in the encrypted payload of E2EE messages, right ? I think it should probably be mentioned in the MSC, perhaps as a security consideration.
There was a problem hiding this comment.
What do you mean? Clients don't encrypt the room id when sending events
There was a problem hiding this comment.
There was a problem hiding this comment.
Ok, then thats probably hidden by the various view source implementations in Element X Android / Android and Web
There was a problem hiding this comment.
Clarification on what the concern is here would be appreciated. I'm having trouble parsing both the original comment and replies.
Links to existing spec are helpful.
There was a problem hiding this comment.
If I understand the proposal right, nowhere in it does it state to keep room_id for events outgoing from the client inside m.room.encrypted, to address:
We include the room ID in the payload, because otherwise the homeserver would be able to change the room a message was sent in.
Link https://spec.matrix.org/v1.11/client-server-api/#mmegolmv1aes-sha2
There was a problem hiding this comment.
This MSC doesn't really operate at that layer, so would not affect encryption. It only affects the federation and room behaviour characteristics.
I can try to make this clearer, but clients should see no material difference before and after this MSC.
There was a problem hiding this comment.
Yea, I would suggest to make it clearer in the MSC exactly which usages of room_id it affects
There was a problem hiding this comment.
With my crypto hat on, since has security implications, I think it would be worth clarifying somewhere that this MSC doesn't affect the encrypted payload.
Rendered