From 2534644decaac348c034f16f4ee17c1c365c3861 Mon Sep 17 00:00:00 2001 From: Doug <6060466+pixlwave@users.noreply.github.com> Date: Sun, 12 May 2024 20:24:47 +0100 Subject: [PATCH] MSC4132: Deprecate Linking to an Event Against a Room Alias (#4132) * Deprecate Linking to an Event Against a Room Alias * Pin the spec links Co-authored-by: Travis Ralston * Address feedback. * Address comments about via and the URIs that should be used. * Rewording. --------- Co-authored-by: Travis Ralston --- ...4132-deprecate-event-on-room-alias-uris.md | 58 +++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 proposals/4132-deprecate-event-on-room-alias-uris.md diff --git a/proposals/4132-deprecate-event-on-room-alias-uris.md b/proposals/4132-deprecate-event-on-room-alias-uris.md new file mode 100644 index 000000000..607c66110 --- /dev/null +++ b/proposals/4132-deprecate-event-on-room-alias-uris.md @@ -0,0 +1,58 @@ +# MSC4132: Deprecate Linking to an Event Against a Room Alias. + +## Introduction + +The spec supports 2 types of URI, the [Matrix scheme](https://spec.matrix.org/v1.10/appendices/#matrix-uri-scheme) +and [matrix.to](https://spec.matrix.org/v1.10/appendices/#matrixto-navigation) links which allow deep linking to +Matrix users, rooms and events. Event URIs can be constructed against either a room ID or a room alias the latter of +which is fragile issue as a room's alias is mutable and so event links may be broken by changes to the alias. Users +expect deep links to continue working so that older links continue to show the correct content. Therefore it is proposed +to deprecate event links against a room alias. + + +## Proposal + +As room IDs are immutable, event URIs built against these will continue to work for as long as the room is reachable by +the homeserver. In contrast, event URIs built against a room alias can break under the following circumstances: +- The room is upgraded, resulting in the alias pointing to the new room, which won't contain any events from the + ancestor. +- The alias is removed/changed resulting in a dead link that can't be resolved. + +The proposal would [deprecate](https://spec.matrix.org/v1.10/#deprecation-policy) the 2 following URIs: +- Link to `$event` in `#somewhere:example.org`: `matrix:r/somewhere:example.org/e/event` +- Link to `$event` in `#somewhere:example.org`: `https://matrix.to/#/%23somewhere:example.org/%24event%3Aexample.org` + +Specifically this means it would be marked in the spec as not to be used in future and clients should: +1. Stop making new event URIs with room aliases, generating the examples above as the following respectively: + - `matrix:roomid/opaqueid:example.org/e/event?via=example.com` + - `https://matrix.to/#/!opaqueid%3Aexample.org/%24event%3Aexample.org?via=example.com` +2. Continue to accept them as it will take time for other clients to update and legacy events will continue to exist. + +It is worth nothing that this change would require clients to always add the `via=` fields when building event URIs as +these are expected for URIs that reference a room ID. + + +## Potential issues + +Whilst most clients do take the sensible route and generate event URIs against a room ID (even when it has an alias), as +it is part of the spec these kinds of links likely exist somewhere in room history and on the World Wide Web. This would +mean that after deprecation clients may still want to handle these URIs when received. + +Additionally, whilst not a new problem some clients don't always update the `via` fields, which poses a problem for +rooms that have lots of single user homeservers: A single user leaving can result in the `via` to become non functional +which over time can result in unreachable room IDs (this is essentially the equivalent of the alias being removed). + + +## Alternatives + +An alternative would be to leave things as they are, although this wouldn't be the best choice for the user. + + +## Security considerations + +It is unlikely that accepting this change would introduce any security considerations. + + +## Dependencies + +N/A