From 37ad074e0946d4197c88692c14439ed32df29db3 Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Fri, 9 Dec 2022 00:56:42 -0600 Subject: [PATCH 1/9] Add MSC for dynamic predecessor --- proposals/0000-dynamic-predecessor.md | 85 +++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 proposals/0000-dynamic-predecessor.md diff --git a/proposals/0000-dynamic-predecessor.md b/proposals/0000-dynamic-predecessor.md new file mode 100644 index 00000000000..1844b5769db --- /dev/null +++ b/proposals/0000-dynamic-predecessor.md @@ -0,0 +1,85 @@ +# MSC0000: Dynamic room predecessor + +Currently, the only way to specify the predecessor of a room is during room creation in +the `m.room.create` state event which can't be changed after the room is created +(the `m.room.create` event is immutable and can't be changed retrospectively). + +This is in contrast to specifying the successor of a room via the `m.room.tombstone` +state event in the `replacement_room` content field which can be sent at any time to +update the state. + +Traditionally, the predecessor use case has only been necessary for room upgrades where +one room is replaced by another and since the old room exists at the time of the new +room being created, it can easily be specified in the `m.room.create` event of the new +room. + +But in history import cases like +[MSC2716](https://github.com/matrix-org/matrix-spec-proposals/pull/2716), specifying the +predecessor after the fact becomes important because the new historical room wasn't +available to reference when the current room was originally created. It's important to +note that history import is more than just +[MSC2716](https://github.com/matrix-org/matrix-spec-proposals/pull/2716) since people +can use [MSC3316 timestamp +massaging](https://github.com/matrix-org/matrix-spec-proposals/pull/3316) `?ts=123` +query parameter to send messages back in time, in general servers can craft events at +any time which are accepted over federation. + +Replacing the predecessor of a room is also nice if you make a mistake in the import +process and only notice after the fact. You can easily create a new historical room with +the mistake corrected and splice it into the predecessor/successor chain as necessary. + + +## Proposal + +Add a `m.room.predecessor` state event type where you can specify the room predecessor. +This allows the predecessor state to be updated as necessary. + +Event type: State event +State key: A zero-length string. + +**`m.room.predecessor` event `content` field definitions:** + +key | type | value | description | required +--- | --- | --- | --- | --- +`predecessor_room_id` | string | Room ID | A reference to the room that came before and was replaced by this room | yes + +The presense of `m.room.predecessor` state in the room should take priority over the +`predecessor` specified in the `m.room.create` event. + + +## Potential issues + +*None surmised so far* + + +## Alternatives + +One possible alternative is to allow sending the `m.room.create` multiple times but this +would require extensive [authorization +rule](https://spec.matrix.org/v1.5/rooms/v10/#authorization-rules) changes and +considerations. + +It would also be good to consider whether `predecessor` should be part of the +`m.room.create` at all. Maybe we should consider removing it in favor of this new event +type. + + +## Security considerations + +`m.room.predecessor` is a state event that falls under the same power-level state +restrictions/permissions as other state events so there shouldn't be any additional +considerations here. + +Room upgrades are a known hairy area of Matrix and how clients deal with them (or lack +of) but this doesn't change any of the existing semantics of predecessors. This is just +a way to change the predecessor of where people should point to instead. + + +## Unstable prefix + +While this feature is in development, the `m.room.predecessor` state event can be used +as `org.matrix.msc0000.room_predecessor`. + +Clients can choose to honor the unstable event type at their discretion. + + From 16bd625d0efca94a7d9cf0699e200f169346119e Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Fri, 9 Dec 2022 00:58:36 -0600 Subject: [PATCH 2/9] Specify MSC number --- ...000-dynamic-predecessor.md => 3946-dynamic-predecessor.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename proposals/{0000-dynamic-predecessor.md => 3946-dynamic-predecessor.md} (97%) diff --git a/proposals/0000-dynamic-predecessor.md b/proposals/3946-dynamic-predecessor.md similarity index 97% rename from proposals/0000-dynamic-predecessor.md rename to proposals/3946-dynamic-predecessor.md index 1844b5769db..83f24858e3d 100644 --- a/proposals/0000-dynamic-predecessor.md +++ b/proposals/3946-dynamic-predecessor.md @@ -1,4 +1,4 @@ -# MSC0000: Dynamic room predecessor +# MSC3946: Dynamic room predecessor Currently, the only way to specify the predecessor of a room is during room creation in the `m.room.create` state event which can't be changed after the room is created @@ -78,7 +78,7 @@ a way to change the predecessor of where people should point to instead. ## Unstable prefix While this feature is in development, the `m.room.predecessor` state event can be used -as `org.matrix.msc0000.room_predecessor`. +as `org.matrix.msc3946.room_predecessor`. Clients can choose to honor the unstable event type at their discretion. From e9ff87bcee02fd5d5b3dd0446a91acd16d19de09 Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Fri, 9 Dec 2022 01:02:54 -0600 Subject: [PATCH 3/9] Small langauge tweak --- proposals/3946-dynamic-predecessor.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3946-dynamic-predecessor.md b/proposals/3946-dynamic-predecessor.md index 83f24858e3d..775d6831aed 100644 --- a/proposals/3946-dynamic-predecessor.md +++ b/proposals/3946-dynamic-predecessor.md @@ -21,8 +21,8 @@ note that history import is more than just [MSC2716](https://github.com/matrix-org/matrix-spec-proposals/pull/2716) since people can use [MSC3316 timestamp massaging](https://github.com/matrix-org/matrix-spec-proposals/pull/3316) `?ts=123` -query parameter to send messages back in time, in general servers can craft events at -any time which are accepted over federation. +query parameter to send messages back in time and in general servers can craft events to +appear as being sent at any timestamp which are accepted over federation. Replacing the predecessor of a room is also nice if you make a mistake in the import process and only notice after the fact. You can easily create a new historical room with From af2193778d9601859f309ba3c67e9236ffa2f2b5 Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Fri, 9 Dec 2022 01:06:29 -0600 Subject: [PATCH 4/9] Fix presence typo --- proposals/3946-dynamic-predecessor.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3946-dynamic-predecessor.md b/proposals/3946-dynamic-predecessor.md index 775d6831aed..2ba685b2885 100644 --- a/proposals/3946-dynamic-predecessor.md +++ b/proposals/3946-dynamic-predecessor.md @@ -43,7 +43,7 @@ key | type | value | description | required --- | --- | --- | --- | --- `predecessor_room_id` | string | Room ID | A reference to the room that came before and was replaced by this room | yes -The presense of `m.room.predecessor` state in the room should take priority over the +The presence of `m.room.predecessor` state in the room should take priority over the `predecessor` specified in the `m.room.create` event. From 03223616f370f4ff93722900fc47c2e71efd9ea5 Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Tue, 10 Jan 2023 13:17:57 -0600 Subject: [PATCH 5/9] Document Gitter use case See https://github.com/matrix-org/matrix-spec-proposals/pull/3946#discussion_r1066191258 --- proposals/3946-dynamic-predecessor.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/proposals/3946-dynamic-predecessor.md b/proposals/3946-dynamic-predecessor.md index 2ba685b2885..efb49828b55 100644 --- a/proposals/3946-dynamic-predecessor.md +++ b/proposals/3946-dynamic-predecessor.md @@ -28,6 +28,12 @@ Replacing the predecessor of a room is also nice if you make a mistake in the im process and only notice after the fact. You can easily create a new historical room with the mistake corrected and splice it into the predecessor/successor chain as necessary. +For the Gitter import case specifically (personal use case), we're using the single +`/send?ts=123` endpoint with timestamp massaging. We're creating a separate historical +room, importing the message history one by one, tombstoning to point to the "live" room +and want to use this MSC to have the "live" room's predecessor point back to the +historical room. + ## Proposal From 945c26d99775caa1eae9d130debf7667d647427b Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Tue, 10 Jan 2023 13:49:07 -0600 Subject: [PATCH 6/9] Use "retroactively" because action is being taken See https://github.com/matrix-org/matrix-spec-proposals/pull/3946#discussion_r1062691863 Co-authored-by: Denis Kasak --- proposals/3946-dynamic-predecessor.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3946-dynamic-predecessor.md b/proposals/3946-dynamic-predecessor.md index efb49828b55..deffe31a52e 100644 --- a/proposals/3946-dynamic-predecessor.md +++ b/proposals/3946-dynamic-predecessor.md @@ -2,7 +2,7 @@ Currently, the only way to specify the predecessor of a room is during room creation in the `m.room.create` state event which can't be changed after the room is created -(the `m.room.create` event is immutable and can't be changed retrospectively). +(the `m.room.create` event is immutable and can't be changed retroactively). This is in contrast to specifying the successor of a room via the `m.room.tombstone` state event in the `replacement_room` content field which can be sent at any time to From 44ab2aeb5a46710ac71c3346cb864cdc9754b621 Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Thu, 9 Feb 2023 11:06:20 -0600 Subject: [PATCH 7/9] Add via_servers field to make the predecessor room ID routable As suggested by @t3chguy and @justjanne, see https://github.com/matrix-org/matrix-spec-proposals/pull/3946#discussion_r1100250867 --- proposals/3946-dynamic-predecessor.md | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/3946-dynamic-predecessor.md b/proposals/3946-dynamic-predecessor.md index deffe31a52e..82b227217e3 100644 --- a/proposals/3946-dynamic-predecessor.md +++ b/proposals/3946-dynamic-predecessor.md @@ -48,6 +48,7 @@ State key: A zero-length string. key | type | value | description | required --- | --- | --- | --- | --- `predecessor_room_id` | string | Room ID | A reference to the room that came before and was replaced by this room | yes +`via_servers` | [string] | List of server names | The servers to attempt to join the room through. These servers should be participating in the room to be useful. This option is necessary since room ID's are not routable on their own. The presence of `m.room.predecessor` state in the room should take priority over the `predecessor` specified in the `m.room.create` event. From e47c86da80f4d1578ba63e7a2733a4f10f2b8ed3 Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Thu, 9 Feb 2023 11:10:59 -0600 Subject: [PATCH 8/9] Comment on current state of via servers in m.room.create As explained in https://github.com/matrix-org/matrix-spec-proposals/pull/3946#discussion_r1100250867 --- proposals/3946-dynamic-predecessor.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/3946-dynamic-predecessor.md b/proposals/3946-dynamic-predecessor.md index 82b227217e3..a483bf049f7 100644 --- a/proposals/3946-dynamic-predecessor.md +++ b/proposals/3946-dynamic-predecessor.md @@ -53,6 +53,10 @@ key | type | value | description | required The presence of `m.room.predecessor` state in the room should take priority over the `predecessor` specified in the `m.room.create` event. +An additional note is that since via servers are not specified alongside the +`predecessor` in a `m.room.create` event, the `m.room.create` usage should probably be +phased out in favor of this new event. + ## Potential issues From 3e2713b656f9a04ca05f9f66b625da94f1aa2c1d Mon Sep 17 00:00:00 2001 From: Eric Eastwood Date: Fri, 10 Feb 2023 09:46:29 -0600 Subject: [PATCH 9/9] Add more context for predecessor in create event should be phased out See https://github.com/matrix-org/matrix-spec-proposals/pull/3946#discussion_r1102561011 --- proposals/3946-dynamic-predecessor.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/3946-dynamic-predecessor.md b/proposals/3946-dynamic-predecessor.md index a483bf049f7..5e679e63b2b 100644 --- a/proposals/3946-dynamic-predecessor.md +++ b/proposals/3946-dynamic-predecessor.md @@ -55,7 +55,10 @@ The presence of `m.room.predecessor` state in the room should take priority over An additional note is that since via servers are not specified alongside the `predecessor` in a `m.room.create` event, the `m.room.create` usage should probably be -phased out in favor of this new event. +phased out in favor of this new event. Even if the via servers were specified in the +`m.room.create` event, they'd quickly go out of date, as the `m.room.create` event is +immutable. Whenever via servers change, the dynamic room predecessor event can be +updated with new via information ## Potential issues