MSC: Updated semantics for publishing room aliases
Richard van der Hoff
4 years ago
parent
c79ed36fcb
commit
6bd4b3c08a
@ -0,0 +1,225 @@
|
||||
# MSC2432: Updated semantics for publishing room aliases
|
||||
|
||||
This MSC offers an alternative to [MSC2260](https://github.com/matrix-org/matrix-doc/issues/2260).
|
||||
|
||||
## Background
|
||||
|
||||
The [`m.room.aliases`](https://matrix.org/docs/spec/client_server/r0.6.0#m-room-aliases)
|
||||
state event exists to list the available aliases for a given room. This serves
|
||||
two purposes:
|
||||
|
||||
* It allows existing members of the room to discover alternative aliases,
|
||||
which may be useful for them to pass this knowledge on to others trying to
|
||||
join.
|
||||
|
||||
* Secondarily, it helps to educate users about how Matrix works by
|
||||
illustrating multiple aliases per room and giving a perception of the size
|
||||
of the network.
|
||||
|
||||
However, it has problems:
|
||||
|
||||
* Any user in the entire ecosystem can create aliases for rooms, which are
|
||||
then unilaterally added to `m.room.aliases`, and room admins are unable to
|
||||
remove them. This is an abuse
|
||||
vector (https://github.com/matrix-org/matrix-doc/issues/625).
|
||||
|
||||
* For various reasons, the `m.room.aliases` event tends to get out of sync
|
||||
with the actual aliases (https://github.com/matrix-org/matrix-doc/issues/2262).
|
||||
|
||||
## Proposal
|
||||
|
||||
We propose that that room moderators should be able to manually curate a list
|
||||
of "official" aliases for their room, instead of matrix servers automatically
|
||||
publishing lists of all room aliases into the room state. No particular
|
||||
guarantees are offered that this alias list is entirely accurate: it becomes
|
||||
room moderators' responsibilty to keep it so.
|
||||
|
||||
Meanwhile, the aliases that map to a given room on a given server become
|
||||
the ultimate responsibility of the administrators of that server. We give them
|
||||
tools to inspect the alias list and clean it up when necessary, in addition to
|
||||
the current tools which allow restriction of who can create aliases in the
|
||||
first place.
|
||||
|
||||
A detailed list of proposed modifications to the Matrix spec follows:
|
||||
|
||||
* `m.room.aliases` loses any special meaning within the spec. In particular:
|
||||
|
||||
* Clients should no longer format it specially in room timelines.
|
||||
|
||||
* Clients and servers should no longer consider `m.room.aliases` when
|
||||
[calculating the display name for a
|
||||
room](https://matrix.org/docs/spec/client_server/r0.6.0#calculating-the-display-name-for-a-room).
|
||||
|
||||
(Note: servers follow the room display-name algorithm when calculating
|
||||
room names for certain types of push notification.)
|
||||
|
||||
* A future room version will remove the special [authorization
|
||||
rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and
|
||||
[redaction rules](https://matrix.org/docs/spec/client_server/r0.6.0#redactions).
|
||||
|
||||
* [`m.room.canonical_alias`](https://matrix.org/docs/spec/client_server/r0.6.0#m-room-canonical-alias)
|
||||
is extended to include a new `alt_aliases` property. This, if present,
|
||||
should be a list of alternative aliases for the room. An example event might
|
||||
look like:
|
||||
|
||||
```json
|
||||
{
|
||||
"content": {
|
||||
"alias": "#somewhere:localhost",
|
||||
"alt_aliases": [
|
||||
"#somewhere:overthere.com",
|
||||
"#somewhereelse:example.com"
|
||||
]
|
||||
},
|
||||
"room_id": "!jEsUZKDJdhlrceRyVU:example.org",
|
||||
"state_key": "",
|
||||
"type": "m.room.canonical_alias"
|
||||
}
|
||||
```
|
||||
|
||||
It is valid for `alt_aliases` to be non-empty even if `alias` is absent or
|
||||
empty. This means that no alias has been picked out as the 'main' alias.
|
||||
|
||||
(Note: although the spec currently claims that `alias` is mandatory, Synapse
|
||||
generates `m.room.canonical` alias events with no `alias` property when the
|
||||
main alias is deleted. This change would legitimise that behaviour.)
|
||||
|
||||
(For clarity: it is not proposed that the `alt_aliases` be considered when
|
||||
calculating the displayname for a room.)
|
||||
|
||||
* [`PUT /_matrix/client/r0/rooms/{roomId}/state/{eventType}/{stateKey}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-rooms-roomid-state-eventtype-statekey)
|
||||
is extended to recommend that servers validate any *new* aliases added to
|
||||
`m.room.canonical_alias` by checking that it is a valid alias according to
|
||||
the [syntax](https://matrix.org/docs/spec/appendices#room-aliases), and by
|
||||
looking up the alias and and that it corresponds to the expected room ID.
|
||||
|
||||
(Note: Synapse currently implements this check on the main alias, though
|
||||
this is unspecced.)
|
||||
|
||||
(TODO: what error code should be returned if the alias is invalid, or if it
|
||||
points to the wrong room?)
|
||||
|
||||
* Currently, [`PUT /_matrix/client/r0/directory/room/{roomAlias}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-directory-room-roomalias)
|
||||
attempts to send updated `m.room.aliases` events on the caller's
|
||||
behalf. (This is implemented in Synapse but does not appear to be explicitly
|
||||
specced.) This functionality should be removed.
|
||||
|
||||
* Currently, [`DELETE /_matrix/client/r0/directory/room/{roomAlias}`](https://matrix.org/docs/spec/client_server/r0.6.0#delete-matrix-client-r0-directory-room-roomalias),
|
||||
attempts to send updated `m.room.aliases` and/or `m.room.canonical_alias`
|
||||
events on the caller's behalf, removing any aliases which have been
|
||||
deleted. (Again, this is implemented in Synapse but does not appear to be
|
||||
explicitly specced.) The `m.room.aliases` functionality should be removed,
|
||||
and the `m.room.canonical_alias` functionality should be extended to cover
|
||||
`alt_aliases`. As today, no error occurs if the caller does not have
|
||||
permission to send such an event.
|
||||
|
||||
* A new api endpoint, `GET /_matrix/client/r0/rooms/{roomId}/aliases` is
|
||||
added, which returns the list of aliases currently defined on the local
|
||||
server for the given room. The response looks like:
|
||||
|
||||
```json
|
||||
{
|
||||
"aliases": [
|
||||
"#somewhere:example.com",
|
||||
"#somewhereelse:example.com",
|
||||
"#special_alias:example.com"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
This API can be called by any current member of the room (calls from other
|
||||
users result in `M_FORBIDDEN`).
|
||||
|
||||
TODO: should this be tied in with `history_visibilty` to allow peeking from
|
||||
non-members? On the one hand that feels like pointless clutter; on the other
|
||||
it feels like it makes it more consistent with peekable rooms.
|
||||
|
||||
Various APIs are currently subject to implementation-defined access
|
||||
restrictions. No change to the specification is changed in this regard
|
||||
(implementations will continue to be free to impose their own
|
||||
restrictions). Nevertheless as part of this MSC it is useful to consider some
|
||||
proposed changes to Synapse's implementation:
|
||||
|
||||
* No change: `PUT /_matrix/client/r0/directory/room/{roomAlias}`: Synapse
|
||||
only allows access to current members of the room, and also exposes some
|
||||
configuration options which allow restriction of which users are allowed to
|
||||
create aliases in general.
|
||||
|
||||
* `DELETE /_matrix/client/r0/directory/room/{roomAlias}`: in this case,
|
||||
currently Synapse restricts its use to the user that created the alias, and
|
||||
server admins.
|
||||
|
||||
It is proposed to extend this to local users who have a power-level
|
||||
sufficient to send an `m.room.canonical_alias` event in the room that the
|
||||
alias currently points to.
|
||||
|
||||
* [`PUT /_matrix/client/r0/directory/list/room/{roomId}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-directory-list-room-roomid)
|
||||
and the corresponding unspecced `DELETE` api (both of which set the
|
||||
visibility of a room in the public directory): currently Synapse restricts
|
||||
their use to server admins and local users who have a PL sufficient to send
|
||||
an `m.room.aliases` event in the room (ignoring the special auth
|
||||
rules). This will be changed to check against the PL required to send an
|
||||
`m.room.canonical_alias` event.
|
||||
|
||||
It is envisaged that Matrix clients will then change their "Room Settings" user
|
||||
interface to display the aliases from `m.room.canonical_alias` instead of those
|
||||
in `m.room.aliases`, as well as giving moderators the ability to update that
|
||||
list. Clients might also wish to use the new `GET
|
||||
/_matrix/client/r0/rooms/{roomId}/aliases` endpoint to obtain and display the
|
||||
currently-available local aliases, though given that this list may be subject
|
||||
to abuse, it should probably not be shown by default.
|
||||
|
||||
### Future work
|
||||
|
||||
This work isn't considered part of this MSC, but rather a potential extension
|
||||
for the future.
|
||||
|
||||
* It may be useful to be able to query remote servers for their alias
|
||||
list. This could be done by extending `GET
|
||||
/_matrix/client/r0/rooms/{roomId}/aliases` to take a `server_name`
|
||||
parameter, and defining an API in the server_server spec which will expose
|
||||
the requested information, subject to the calling homeserver having at least
|
||||
one user with a right to see it.
|
||||
|
||||
* Similarly, room moderators may wish to be able to delete aliases on a remote
|
||||
server for their room. We could envisage a fedaration API which allows such
|
||||
a request to be made, subject to the calling homeserver having at least one
|
||||
moderator in the room.
|
||||
|
||||
## Potential issues
|
||||
|
||||
The biggest problem with this proposal is that existing clients, which rely on
|
||||
`m.room.aliases` in one way or another, will lose functionality. In particular,
|
||||
they may not know about aliases that exist, or they may look at outdated
|
||||
`m.room.aliases` events that list aliases that no longer exist. However, since
|
||||
`m.room.aliases` is best-effort anyway, these are both problems that exist to
|
||||
some extent today.
|
||||
|
||||
## Alternatives
|
||||
|
||||
We considered continuing to use `m.room.aliases` to advertise room aliases
|
||||
instead of `m.room.canonical_alias`, but the significant changes in semantics
|
||||
made that seem inappropriate.
|
||||
|
||||
We also considered using separate state events for each advertised alias,
|
||||
rather than listing them all in one event. This might increase the number of
|
||||
aliases which can be advertised, and help to reduce races when editing the
|
||||
list. However, the 64KB limit of an event still allows room for hundreds of
|
||||
aliases of any sane length, and we don't expect the list to be changing
|
||||
frequently enough for races to be a practical concern. Ultimately the added
|
||||
complexity seemed redundant.
|
||||
|
||||
A previous suggestion was
|
||||
[MSC2260](https://github.com/matrix-org/matrix-doc/issues/2260), which proposed
|
||||
keeping `m.room.aliases` largely as-is, but giving room moderators tools to
|
||||
control who can send them via room power-levels. We dismissed it for the
|
||||
reasons set out at
|
||||
https://github.com/matrix-org/matrix-doc/pull/2260#issuecomment-584207073.
|
||||
|
||||
## Security considerations
|
||||
|
||||
None currently identified.
|
||||
|
||||
## Unstable prefix
|
||||
|
||||
TBD.
|
||||
Loading…
Reference in New Issue