-
-
Notifications
You must be signed in to change notification settings - Fork 115
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
base: main
Are you sure you want to change the base?
Conversation
Relates to: matrix-org#633 Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
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. |
There was a problem hiding this comment.
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.
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. |
There was a problem hiding this comment.
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.
The validation job is red because #2104 hasn't landed yet. |
There was a problem hiding this 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 😁
CI is green now that #2104 landed (and I made some fixes). |
Depends on: #2104
Relates to: #633
Pull Request Checklist
Preview: https://pr2109--matrix-spec-previews.netlify.app