Skip to content

Clarify the meaning of "public spaces" #2109

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

Johennes
Copy link
Contributor

@Johennes Johennes commented Mar 20, 2025

Depends on: #2104
Relates to: #633

Pull Request Checklist

Preview: https://pr2109--matrix-spec-previews.netlify.app

Relates to: matrix-org#633
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
Comment on lines 22 to 25
and [`m.room.join_rules`](#mroomjoin_rules). Public spaces are encouraged to have
a similar setup to public rooms: `world_readable` history visibility, published
canonical alias, and suitably public `join_rule`. Invites, including third-party
invites, still work just as they do in normal rooms as well.
and [`m.room.join_rules`](#mroomjoin_rules). Canonical aliases and invites, including
third-party invites, still work just as they do in normal rooms as well. Furthermore,
spaces can also be published in the [room directory](#room-directory) to make them
discoverable.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the recommendation because the spec doesn't actually define a "public room". The closest thing is the public_chat preset on /createRoom. This, however, uses a history visibility of shared rather than world_readable which increases the ambiguity further.

It seems to sufficient to me to explain that spaces are governed by the same mechanisms as rooms and, therefore, can be made "public" in several dimensions.

Comment on lines -90 to +92
No state events in the child rooms themselves would be required (though they
can also be present). This allows for users
to define personal/private spaces to organise their own rooms without needing explicit
permission from the room moderators/admins.
No state events in the child rooms themselves would be required (though they can also
be present). This allows for users to define spaces without needing explicit permission
from the room moderators/admins.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spec defines neither "personal" nor "private" for rooms or spaces. The different dimensions of "privacy" seem irrelevant here though. The argument is merely that the state events in child rooms are optional so that you can build spaces without being an admin in all their rooms.

@Johennes Johennes marked this pull request as ready for review March 20, 2025 15:33
@Johennes Johennes requested a review from a team as a code owner March 20, 2025 15:33
@Johennes
Copy link
Contributor Author

The validation job is red because #2104 hasn't landed yet.

Copy link
Member

@anoadragon453 anoadragon453 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent refactoring to remove the "problematic" words. Thanks 😁

@Johennes
Copy link
Contributor Author

CI is green now that #2104 landed (and I made some fixes).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants