|
|
|
|
@ -18,6 +18,10 @@ 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.
|
|
|
|
|
@ -30,10 +34,14 @@ 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 would still include the service members in
|
|
|
|
|
the room name calculation. It may be possible to work around this by excluding
|
|
|
|
|
service members from `m.heroes` on the server side, but that may also cause
|
|
|
|
|
other 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
|
|
|
|
|
|