You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
100 lines
3.9 KiB
Markdown
100 lines
3.9 KiB
Markdown
2 years ago
|
# MSC3905: Application services should only be interested in local users
|
||
|
|
|
||
|
|
Application services receive events that they are "interested" in.
|
||
|
|
|
||
|
|
The [current language in the spec](https://spec.matrix.org/v1.4/application-service-api/#registration)
|
||
|
|
describes it like this:
|
||
|
|
|
||
|
|
> An application service is said to be "interested" in a given event if one of the IDs
|
||
|
|
> in the event match the regular expression provided by the application service
|
||
|
|
> [registration]. [...] the application service is said to be interested in a given
|
||
|
|
> event if one of the application service's namespaced users is the target of the event,
|
||
|
|
> or is a joined member of the room where the event occurred.
|
||
|
|
|
||
|
|
This language is ambiguous around which users it should match against though. Should it
|
||
|
|
be all members of the room including remote users from other homeservers or just the
|
||
|
|
local users where the application service lives? It could be assumed either way and
|
||
|
|
naively applied to all members of the room which is still valid with the current
|
||
|
|
language and even what Synapse does.
|
||
|
|
|
||
|
|
But matching against remote users is merely a footgun because an application service may
|
||
|
|
assume that it'll receive all events sent by that remote user, even though it will only
|
||
|
|
receive events in rooms that are shared with a local user. This leaves us with a
|
||
|
|
behavior mismatch between remote and local users.
|
||
|
|
|
||
|
|
|
||
|
|
## Proposal
|
||
|
|
|
||
|
|
Therefore the proposal is that the `users` namespace regex should only be applied
|
||
|
|
against local users of the homeserver.
|
||
|
|
|
||
|
|
A basic implementation of this would look like:
|
||
|
|
|
||
|
|
```js
|
||
|
|
const isLocalUser = sender.endsWith(":" + homeserver.domain);
|
||
|
|
const isInterestingUser = isLocalUser && sender.matches(regex);
|
||
|
|
```
|
||
|
|
|
||
|
|
```js
|
||
|
|
const localRoomMembers = getLocalRoomMembers(roomId);
|
||
|
|
const interestingUsers = localRoomMembers.filter((localRoomMember) => localRoomMember.matches(regex));
|
||
|
|
```
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
To avoid confusion, please note that the `rooms` and `aliases` namespaces are not
|
||
|
|
affected. You can still match whatever rooms and aliases to listen to all events
|
||
|
|
that occur in them.
|
||
|
|
|
||
|
|
|
||
|
|
## Potential issues
|
||
|
|
|
||
|
|
There are use cases like moderation where an application service wants to hear all
|
||
|
|
messages from remote users in rooms but these are also covered by the `rooms`
|
||
|
|
namespace where all events in a matched room are considered "interesting".
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
## Alternatives
|
||
|
|
|
||
|
|
The alternative is to clarify that the `users` namespace should be matched against all
|
||
|
|
users (local and remote). This still leaves us with the behavior-difference footgun.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
## Security considerations
|
||
|
|
|
||
|
|
Since we're reducing the surface area, there doesn't seem to be any additional security
|
||
|
|
considerations introduced.
|
||
|
|
|
||
|
|
With this MSC, an application service will be receiving less events than before.
|
||
|
|
|
||
|
|
|
||
|
|
## Historical context
|
||
|
|
|
||
|
|
According to @turt2live (SCT member), "the spec intended to [originally] say the
|
||
|
|
namespace can make an appservice interested in remote users, though there's obviously no
|
||
|
|
ability for the server to call `/user` on remote users (it's not like the appservice can
|
||
|
|
create them)." (https://github.com/matrix-org/synapse/pull/13958#discussion_r988369446)
|
||
|
|
|
||
|
|
This intention goes back further than `r0` (or `v1.0` in marketing versions speak) but
|
||
|
|
this history is lost to time since there isn't really anything concrete to point to
|
||
|
|
beyond the original spec
|
||
|
|
[issue](https://github.com/matrix-org/matrix-spec-proposals/issues/1307) and
|
||
|
|
[PR](https://github.com/matrix-org/matrix-spec-proposals/pull/1533) which don't mention
|
||
|
|
these details.
|
||
|
|
|
||
|
|
Since we're unable to come up with any valid use cases nowadays, it's unclear to
|
||
|
|
outsiders from that time whether the original intention is actually true. In any case,
|
||
|
|
we're clarifying it here and making an MSC to change it explicitly.
|
||
|
|
|
||
|
|
|
||
|
|
## Unstable prefix
|
||
|
|
|
||
|
|
While this MSC is not considered stable, appservices can opt-in to this behaviour in
|
||
|
|
either of two ways:
|
||
|
|
|
||
|
|
1. Specifying a regex which includes the local homeserver's domain in the regex (eg:
|
||
|
|
`@_irc.*:example.org`)
|
||
|
|
1. Adding `"org.matrix.msc3905": true` to the root level of their registration file
|