Consider whether to remove config option room_prejoin_state

[anoadragon453]

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:

1. The ability to specify arbitrary state here is actually useful to anyone. Is anyone actually changing this option?
2. If so, is peeking over federation a better alternative when it lands?

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.

[clokep]

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.

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.

[anoadragon453]

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

[anoadragon453]

This option was renamed to room_prejoin_state in #9700.

[clokep]

I suspect with the changes in #9700 we don't want to remove this anymore now that you can more easily control this?

[anoadragon453]

room_prejoin_state is much more usable. Though, I think it's still a little weird that this is controlled per-homeserver and not per-room...

If you agree then maybe it's better to close this issue and open a new one on matrix-doc stating as such.

[clokep]

room_prejoin_state is much more usable. Though, I think it's still a little weird that this is controlled per-homeserver and not per-room...

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. 🤷

[anoadragon453]

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?

[clokep]

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.

[anoadragon453]

It would need to be a separate MSC yes, and I agree the possible usecases are minimal. Closing this then as room_prejoin_state is useful in certain scenarios for emitting custom state to users.