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

Spec does not describe what the visibility conditions for a space or room in /hierarchy are #1402

Closed
reivilibre opened this issue Jan 13, 2023 · 4 comments
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@reivilibre
Copy link
Contributor

reivilibre commented Jan 13, 2023

Link to problem area: https://spec.matrix.org/v1.5/client-server-api/#get_matrixclientv1roomsroomidhierarchy

Issue
From this description I can't find out what I need to do in order to ensure that a space I create will be visible to non-members in its parent space.
Or further, as a homeserver implementer I would have no idea what the conditions should be and I'd have to study Synapse source code I guess.

@reivilibre reivilibre added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Jan 13, 2023
reivilibre added a commit to matrix-org/synapse that referenced this issue Jan 13, 2023
@reivilibre
Copy link
Contributor Author

In matrix-org/synapse#14834 I dug up Synapse's definition:

Calculate whether the room should be shown to the requester.

It should return true if:

  • The requesting local user is joined or can join the room (per MSC3173) — this typically means join_rules of public or knock; or
  • The requesting remote homeserver has any user that is joined or can join the room; or
  • The history visibility is set to world readable.

It's not clear how {guest_access: "can_join"} interacts here but the issue I'm working on — matrix-org/conference-bot#142 — suggests that it is needed in the space for things to work properly...

@clokep
Copy link
Member

clokep commented Jan 13, 2023

Duplicate of #1184.

To my memory this is not related to guest_access at all, but I might be forgetting something!

@clokep
Copy link
Member

clokep commented Jan 13, 2023

this typically means join_rules of public or knock; or

Or that the user fulfills one of the restricted join rule checks.

@turt2live
Copy link
Member

Duplicate of #1184

@turt2live turt2live marked this as a duplicate of #1184 Jan 13, 2023
@turt2live turt2live closed this as not planned Won't fix, can't repro, duplicate, stale Jan 13, 2023
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

3 participants