-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC4171: Service members #4171
base: main
Are you sure you want to change the base?
MSC4171: Service members #4171
Conversation
Signed-off-by: Tulir Asokan <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently there was already a doc for this, probably should've looked for that before writing it myself 🙈 https://github.com/element-hq/element-meta/blob/develop/spec/functional_members.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Largely I think the text is fine, I just had a few quibbles.
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. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of note is that this has been in use in Element since July 2021, so it's fairly well battle tested at this point.
## 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if the MSC should explicitly direct servers to filter out these members from the m.heros
selection. As the spec says:
m.heros
-> The users which can be used to generate a room name if the room does not have one. Required if the room’s m.room.name or m.room.canonical_alias state events are unset or empty..
So reasonable to say this is equivalent to the client doing it, and we should probably not have a disagreement between server and client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it would be more technically correct, I'm just not sure if all clients like that. For example, I could imagine clients getting confused and thinking they have the full member list even though a service member was omitted
It also requires implementing more things 🙈
Signed-off-by: Tulir Asokan <[email protected]>
Signed-off-by: Tulir Asokan <[email protected]>
Signed-off-by: Tulir Asokan <[email protected]>
Signed-off-by: Tulir Asokan <[email protected]>
Signed-off-by: Tulir Asokan <[email protected]>
Signed-off-by: Tulir Asokan <[email protected]>
service members from `m.heroes` on the server side, but that may also cause | ||
other issues. | ||
|
||
## Alternatives |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also #4015 I think?
Rendered
Implementations: