3.7 KiB
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.
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.
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.