Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Consider whether to remove config option room_prejoin_state #8807

Closed
anoadragon453 opened this issue Nov 24, 2020 · 9 comments
Closed

Consider whether to remove config option room_prejoin_state #8807

anoadragon453 opened this issue Nov 24, 2020 · 9 comments
Labels
z-question (Deprecated Label)

Comments

@anoadragon453
Copy link
Member

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.

@anoadragon453 anoadragon453 added the z-question (Deprecated Label) label Nov 24, 2020
@clokep
Copy link
Member

clokep commented Nov 24, 2020

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
Copy link
Member Author

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 added a commit to Sorunome/synapse that referenced this issue Nov 24, 2020
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
@anoadragon453 anoadragon453 changed the title Consider whether to remove config option room_invite_state_types Consider whether to remove config option room_prejoin_state Jun 2, 2021
@anoadragon453
Copy link
Member Author

This option was renamed to room_prejoin_state in #9700.

@clokep
Copy link
Member

clokep commented Jun 2, 2021

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

@anoadragon453
Copy link
Member Author

anoadragon453 commented Jun 2, 2021

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
Copy link
Member

clokep commented Jun 2, 2021

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
Copy link
Member Author

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
Copy link
Member

clokep commented Jun 2, 2021

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
Copy link
Member Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
z-question (Deprecated Label)
Projects
None yet
Development

No branches or pull requests

2 participants