aaronaxvig
5 years ago
committed by
GitHub
commit
5da5d5eeb9
@ -0,0 +1 @@
|
|||||||
|
Remove the unused ``query_auth`` API per `MSC2451 <https://github.com/matrix-org/matrix-doc/pull/2451>`_.
|
||||||
@ -0,0 +1,39 @@
|
|||||||
|
# MSC2422: Allow `color` as attribute for `<font>` in messages
|
||||||
|
|
||||||
|
Currently the spec recommends that you to use `data-mx-color` instead of the standard
|
||||||
|
`color` html attribute for the `<font>` tag. This is probably done to make it
|
||||||
|
consistent with `<span>`, where you may not want to allow a generic style tag for.
|
||||||
|
|
||||||
|
On the other hand the /rainbow command on almost every client just uses the
|
||||||
|
`color` attribute of the `<font>` tag. While some clients support
|
||||||
|
`data-mx-color` (i.e. Riot Web), most clients don't. Most clients support
|
||||||
|
rendering `color` however.
|
||||||
|
|
||||||
|
It would probably be for the best to allow or even prefer `color` on the
|
||||||
|
`<font>` tag.
|
||||||
|
|
||||||
|
## Proposal
|
||||||
|
|
||||||
|
Add the `color` attribute to the allowed attributes of `<font>` in section
|
||||||
|
13.2.1.7. No changes to the allowable values from the HTML spec are made here.
|
||||||
|
|
||||||
|
## Potential issues
|
||||||
|
|
||||||
|
- We now have a redundant attribute in the spec. While it matches what the
|
||||||
|
clients currently do, it may be better to fix each client instead.
|
||||||
|
- Clients may not sanitize the color attribute and will let other color values
|
||||||
|
through, increasing compatibility issues again.
|
||||||
|
- Clients may never support the data-mx-* attributes now.
|
||||||
|
- Old messages could loose their color
|
||||||
|
- This proposal doesn't touch span at all, maybe it should?
|
||||||
|
|
||||||
|
## Alternatives
|
||||||
|
|
||||||
|
- fix the clients
|
||||||
|
-> This currently seems not feasible. Multiple clients started using color first (i.e. RiotX, Gomuks) and if it isn't spelled out explicitly in the spec, this will probably continue.
|
||||||
|
- remove the `data-mx-color` and `data-mx-bg-color` attributes entirely, leaving us just with `color` for `<font>`
|
||||||
|
-> This would break old messages and can be done independently of this proposal at a later date, if it is deemed useful.
|
||||||
|
- Add a section to tell the clients to prefer `color` over `mx-data-color`
|
||||||
|
-> I don't really know, why mx-data-* was chosen, but I assume there was a reason, so I don't want to change that.
|
||||||
|
- Spec an entirely different format for messages (that would probably not make this proposal obsolete)
|
||||||
|
-> This wouldn't fix the issue, where some client may choose to remove the color tag, since it is discouraged in the spec. Migration would probably also take a while, so this proposal is a quick solution, that doesn't prevent other solutions at a later date.
|
||||||
@ -0,0 +1,247 @@
|
|||||||
|
# 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' responsibility 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.)
|
||||||
|
|
||||||
|
The following error codes are specified:
|
||||||
|
|
||||||
|
* HTTP 400, with `errcode: M_INVALID_PARAMETER` if an attempt is made to add
|
||||||
|
an entry which is not a well-formed alias (examples: too long, doesn't
|
||||||
|
start with `#`, doesn't contain a `:`).
|
||||||
|
|
||||||
|
* HTTP 400, with `errcode: M_BAD_ALIAS` if an added alias does not point at
|
||||||
|
the given room (either because the alias doesn't exist, because it can't
|
||||||
|
be resolved due to an unreachable server, or because the alias points at a
|
||||||
|
different 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`.
|
||||||
|
|
||||||
|
The behaviour if the calling user has permission to delete the alias but
|
||||||
|
does not have permission to send `m.room.canonical_alias` events in the room
|
||||||
|
(for example, by virtue of being a "server administrator", or by being the
|
||||||
|
user that created the alias) is implementation-defined. It is *recommended*
|
||||||
|
that in this case, the alias is deleted anyway, and a successful response is
|
||||||
|
returned to the client.
|
||||||
|
|
||||||
|
* 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`). For rooms with `history_visibility` set to
|
||||||
|
`world_readable`, it can also be called by users outside the room.
|
||||||
|
|
||||||
|
Servers might also choose to allow access to other users such as server
|
||||||
|
administrators.
|
||||||
|
|
||||||
|
Various APIs are currently subject to implementation-defined access
|
||||||
|
restrictions. No change to the specification is introduced 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 federation 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
|
||||||
|
|
||||||
|
While this feature is in development, the following names will be in use:
|
||||||
|
|
||||||
|
| Proposed final name | Name while in development |
|
||||||
|
| --- | --- |
|
||||||
|
| `GET /_matrix/client/r0/rooms/{roomId}/aliases` | `GET /_matrix/client/unstable/org.matrix.msc2432/rooms/{roomId}/aliases` |
|
||||||
|
|
||||||
|
Servers will indicate support for the new endpoint via a non-empty value for feature flag
|
||||||
|
`org.matrix.msc2432` in `unstable_features` in the response to `GET
|
||||||
|
/_matrix/client/versions`.
|
||||||
@ -0,0 +1,56 @@
|
|||||||
|
# MSC2451: Remove the `query_auth` federation endpoint
|
||||||
|
|
||||||
|
This API was added without sufficient thought nor testing. The endpoint isn't
|
||||||
|
used in any known implementations, and we do not believe it to be necessary
|
||||||
|
for federation to work. The only known implementation (in Synapse) was not fully
|
||||||
|
fleshed out and is broken.
|
||||||
|
|
||||||
|
For background, the idea behind this endpoint was that two homeservers would be
|
||||||
|
able to share state events with the hope of filling in missing state from one
|
||||||
|
of homeservers allowing state resolution to complete. This was to protect
|
||||||
|
against a joining server not providing the full (or providing stale) state.
|
||||||
|
|
||||||
|
In addition to the ideas above not coming to fruition, it is unclear whether the
|
||||||
|
current design of this endpoint would be sufficient. If this state negotiation
|
||||||
|
feature is needed in the future it should be redesigned from scratch via the MSC
|
||||||
|
proposal process.
|
||||||
|
|
||||||
|
## Proposal
|
||||||
|
|
||||||
|
Remove the following endpoint:
|
||||||
|
|
||||||
|
* [POST `/_matrix/federation/v1/query_auth/{roomId}/{eventId}`](https://matrix.org/docs/spec/server_server/r0.1.3#post-matrix-federation-v1-query-auth-roomid-eventid)
|
||||||
|
|
||||||
|
## Potential issues
|
||||||
|
|
||||||
|
Removing this endpoint impacts backwards compatibility, in practice removing
|
||||||
|
this endpoint should have minimal impact as it was an unused error path in
|
||||||
|
Synapse. The federation client code to call this endpoint was removed in Synapse
|
||||||
|
v1.5.0rc1.
|
||||||
|
|
||||||
|
There is no evidence of other homeserver implementations having implemented this
|
||||||
|
endpoint.
|
||||||
|
|
||||||
|
### History
|
||||||
|
|
||||||
|
This endpoint (and the federation client code) to call it was initially
|
||||||
|
added in Synapse v0.7.0 (see [#43](https://github.com/matrix-org/synapse/pull/43)).
|
||||||
|
The federation client code was heavily modified for v1.0.0rc1 (see
|
||||||
|
[#5227](https://github.com/matrix-org/synapse/pull/5227/)),
|
||||||
|
|
||||||
|
The federation client code to call this endpoint was removed in v1.5.0rc1 of
|
||||||
|
Synapse (see [#6214](https://github.com/matrix-org/synapse/pull/6214). After
|
||||||
|
that point this endpoint is not called).
|
||||||
|
|
||||||
|
During removal it was noted that the code to call this endpoint was already
|
||||||
|
unreachable. It seems that this code was never reachable and was meant for an
|
||||||
|
error situation which was never built out (see `git log -S NOT_ANCESTOR`, the
|
||||||
|
error condition is never assigned).
|
||||||
|
|
||||||
|
## Alternatives
|
||||||
|
|
||||||
|
The endpoint could be deprecated and removed in a future version of the specification.
|
||||||
|
|
||||||
|
## Security considerations
|
||||||
|
|
||||||
|
None.
|
||||||
Loading…
Reference in New Issue