-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Consider whether to remove config option room_prejoin_state #8807
Comments
This feels like something that should be specced instead of a config option in Synapse -- i.e. it should be standard so servers and clients can agree on what's available in this case. |
Definitely. At the moment it is specced as a recommendation: https://matrix.org/docs/spec/server_server/r0.1.4#put-matrix-federation-v2-invite-roomid-eventid |
We introduced this option in this PR to mirror room_knock_invite_types, but ended up questioning the worth of both, and ultimately decided that neither were very useful. Context: https://github.com/matrix-org/synapse/pull/6739/files#r527027645 and matrix-org#8807
This option was renamed to |
I suspect with the changes in #9700 we don't want to remove this anymore now that you can more easily control this? |
If you agree then maybe it's better to close this issue and open a new one on matrix-doc stating as such. |
I think that for most users it isn't really something that they should customize, so it probably shouldn't really matter? Note that matrix-org/matrix-spec-proposals#3173 makes a recommendation about what should be available. 🤷 |
Hmm, I think I see. So the option is mainly available for the purpose of adding extra (perhaps custom) state event types to the room pre-join state. And in this case, it makes sense to configure on a per-homeserver basis, rather than a per-room one. The usecase for rooms to share more of less information about the room is secondary and something that ideally shouldn't really be user-configurable. It just happens to be possible through this option. Is that correct? |
Well it isn't really possible through this option if there are other servers in your room. So this would need to be a completely separate proposal to be controlled via room state or something. I don't think anyone is exploring this, although I don't immediately see a use-case. I'd be in favor of closing this for now. |
It would need to be a separate MSC yes, and I agree the possible usecases are minimal. Closing this then as |
When a user is invited to a room, that user receives some state to help them identify the room while their invite is pending. For example, sending the room's name and avatar will allow that user's client to display an invite with a room's name and avatar in their room list (rather than just the ID of the room they were invited to). Additional state that is recommended to send is a canonical alias, the room's encryption state and the room's join rule.
The
room_invites_state_types
config option in Synapse allows the sysadmin to control which state events are sent during this process. While it may at first seem unclear as to why this should be configurable, a justification lies in the PR that introduced it, #598, and a JIRA bug that it links to.TL;DR This was an easy way for users to get arbitrary state from a room when they were invited. Peeking over federation could be used as an alternative solution here - and one that may be viable soon - but wasn't there yet.
Removing options from this list could result in poor UX in clients of users that have been invited to the room. I'm wondering if:
This originally came up during a discussion for the knocking implementation, which has a similar feature of sending limited room state to users that knock on a room they are not in.
The text was updated successfully, but these errors were encountered: