From c0dd8d22f5d740ccf5cbca2a4153894e4f3df207 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 22 Jul 2025 11:52:31 -0600 Subject: [PATCH] 11th hour review --- proposals/4291-room-ids-as-hashes.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/proposals/4291-room-ids-as-hashes.md b/proposals/4291-room-ids-as-hashes.md index 96e29a80d..79d20ca38 100644 --- a/proposals/4291-room-ids-as-hashes.md +++ b/proposals/4291-room-ids-as-hashes.md @@ -56,12 +56,16 @@ This creates a chicken/egg problem when upgrading rooms because: - The `m.room.tombstone` event needs a `content.replacement_room`. - The `content.replacement_room` ID is now the create event of the new room. - The create event of the new room needs the tombstone event ID in `content.predecessor.event_id`. + - While the spec [does not require](https://spec.matrix.org/v1.15/client-server-api/#server-behaviour-19) + the predecessor event to be the tombstone, there may be more than one "last event" if the DAG + has forward extremities. Prior to sending the tombstone event, servers could heal the DAG using + a dummy event, though this is far from elegant when the tombstone event performs this function. - The `m.room.tombstone` event needs ... Creator chicken egg problem - -To break this cycle, this MSC removes the `content.predecessor.event_id` field from the `m.room.create` event. There appear to be no security +To break this cycle, this MSC deprecates the `content.predecessor.event_id` field from the `m.room.create` event. Clients +MUST NOT expect the field to be set, but SHOULD continue to use it if set. There appear to be no security reasons why this field exists. This field is sometimes used in clients to jump back to the correct part in the old room's timeline when the tombstone occurred, which can be relevant when there are lots of leave events after the tombstone. Clients that wish to preserve this behaviour may instead search the old room state for the `m.room.tombstone` event and then jump to that. @@ -79,6 +83,12 @@ means the server must be joined to the room. In particular, invites/knocks are n room confusion by this proposal alone. The security guarantees of this proposal are enhanced with [MSC4311: Ensuring the create event is available on invites and knocks](https://github.com/matrix-org/matrix-spec-proposals/pull/4311). +Clients which were previously parsing the room ID to identify a server for `via` or similar puporposes +are not able to do so. For `m.space.child` and similar cases, the user's own server may be used to +populate `via` on the event, at least initially. For permalinks, `via` candidates are now more important +when creating links (or the use of aliases). Clients can get their own server name by parsing the +user ID they are operating under. + ### Alternatives #### Keeping the domain suffix