Skip to content
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

User directory definition of "public room" #1022

Open
timokoesters opened this issue Apr 2, 2022 · 3 comments
Open

User directory definition of "public room" #1022

timokoesters opened this issue Apr 2, 2022 · 3 comments
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@timokoesters
Copy link

The spec says

[...] the homeserver MUST at a minimum consider the users the requesting user shares a room with and those who reside in public rooms (known to the homeserver).

https://spec.matrix.org/v1.2/client-server-api/#post_matrixclientv3user_directorysearch

It is unclear what is meant by "public room". Does it have to be published to the room directory? Does it have to have join_rules=public? How about knock? And history_visibility?

If this is left as an implementation detail, then that should be explicit. Currently the spec uses the term "public room" without giving a definition.

@ShadowJonathan
Copy link
Contributor

Considering that some more features are starting to rely on this (such as MSC2666), it'd be useful to have a concrete spec definition, so that clients know what to expect.

@turt2live turt2live transferred this issue from matrix-org/matrix-spec-proposals Apr 6, 2022
@turt2live turt2live added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label May 28, 2022
@richvdh
Copy link
Member

richvdh commented Jan 3, 2023

This is really a duplicate of #633, but in this case I know the answer: it is specifically rooms with join_rules=public, which is to say that anyone could join the room if they wanted.

But frankly it's unclear why we have chosen that definition here, rather than (say):

  • extending it to rooms with world_readable history_visibility, or
  • extending the directory search to cover rooms that the calling user could join (either because they have an invite, or because it has restricted join rules where the calling user meets the restrictions, cf stripped state)

If this is left as an implementation detail, then that should be explicit.

Agreed.

@richvdh
Copy link
Member

richvdh commented Jan 3, 2023

ok, turns out I don't know the answer in this case. Per https://github.com/matrix-org/synapse/blob/v1.74.0/synapse/storage/databases/main/user_directory.py#L281 and https://github.com/matrix-org/synapse/blob/774e20b57047b9f8700e62e7f4689717f4fa094c/synapse/storage/databases/main/user_directory.py#L457-L474, Synapse considers a room to be public if it has join_rules=public or it has history_visibility=world_readable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

No branches or pull requests

4 participants