78 lines
3.7 KiB
Markdown
78 lines
3.7 KiB
Markdown
# MSC4171: Service members
|
|
Matrix has lots of bots for different use cases: simple chat bots, bridge bots,
|
|
administration bots, etc. Currently, such bots can't be added to DMs without
|
|
messing up the automatic room name and avatar calculation. [Canonical DMs] may
|
|
solve the issue eventually, but implementing those will likely take quite a
|
|
while due to the complexity of the system. This proposal is an intermediate
|
|
solution for bots before canonical DMs are fully implemented.
|
|
|
|
[Canonical DMs]: https://github.com/matrix-org/matrix-spec-proposals/pull/2199
|
|
|
|
## Proposal
|
|
The proposed solution is a new state event: `m.member_hints`. The state event
|
|
has no state key and contains a field called `service_members` which is a list
|
|
of user IDs.
|
|
|
|
Any users (service members) listed there should not be considered when
|
|
computing the room name or avatar based on the member list. If the room only
|
|
has two non-service members, then any additional DM-specific treatment should
|
|
be applied as well (for example, using 1:1 semantics for VoIP calls).
|
|
|
|
Servers SHOULD omit service members from the `m.heroes` section in `summary`
|
|
when calculating `/sync` responses. Clients MUST NOT expect that `m.heroes` is
|
|
the full list of users even when there are less than 5 members listed.
|
|
|
|
To prevent hiding encrypted message recipients, service members MUST still be
|
|
visible in the member list and membership events they send MUST be rendered if
|
|
other users' membership events are rendered.
|
|
|
|
Clients may include some special label for service members in the member list
|
|
and/or other places in the room to make it clearer why they're not included in
|
|
the room name.
|
|
|
|
Any listed users who are not room members can be safely ignored. Simply being
|
|
on the list without actually being a room member has no special behavior.
|
|
|
|
## Potential issues
|
|
Clients that don't support this MSC may still include the service members in
|
|
the room name calculation if they don't trust the `m.heroes` generated by the
|
|
server.
|
|
|
|
Clients that expect `m.heroes` to be a complete list for rooms with less than
|
|
5 members may be confused when the server omits service members. However, the
|
|
spec never mandated providing all members in small rooms, so this is not
|
|
technically a breaking change.
|
|
|
|
## Alternatives
|
|
### Inverted user list
|
|
The state event could be inverted to list real members instead of service
|
|
members. This approach was not chosen for backwards-compatibility reasons: if
|
|
a user is invited with a client that doesn't know about this MSC, it's better
|
|
for bots to show up in the name than it is for real users to be hidden from the
|
|
name.
|
|
|
|
While the use case in this MSC is primarily for DMs and small groups, an
|
|
inverted user list would completely prevent using the same event in larger
|
|
rooms, as the list would need to be updated on every join/leave. A list of bots
|
|
could be used for other purposes even in big rooms.
|
|
|
|
### Canonical DMs
|
|
The use cases of this proposal would be solved by canonical DMs. For example,
|
|
[MSC2199] defines "unimportant" users which would be excluded from room name
|
|
calculation and behave similar to service members in this proposal. However,
|
|
canonical DMs are much more complicated, while this proposal is relatively
|
|
simple to implement.
|
|
|
|
[MSC2199]: https://github.com/matrix-org/matrix-spec-proposals/pull/2199
|
|
|
|
## Security considerations
|
|
This MSC hides encrypted message recipients to some extent. However, as long as
|
|
the requirement to still show the members in the member list is followed, the
|
|
situation is no different than "hiding" members by injecting room name/avatar
|
|
events.
|
|
|
|
## Unstable prefix
|
|
Due to existing implementations, `io.element.functional_members` should be used
|
|
as the event type until this MSC is accepted. The field name (`service_members`)
|
|
is kept as-is.
|