-
Notifications
You must be signed in to change notification settings - Fork 12
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
Should adding a canonical alias to a room make it free to join? #317
Comments
For reference, the current conversation flow is a lot like this:
|
Your preferred method is my preferred method - sensibly prompting the user to confirm their intention to make the room public sounds good to me. "It looks like you're adding an alias" is a little bit Clippy for me 😁 - we could try "This room is currently invite only - would you like to make it public?" |
The relationship between "Make this room public", set a published address, "Publish this room to the public in the room directory", "Anyone can read the history" and "Anyone how know the room's link can access it" is still confusing me after months of using Element. With knocking coming up I would suggest there should be three basic types of Rooms:
This is just a suggestion but the general point is that those settings are too complex. |
I disagree with automatic publishing as there are currently at least two cases where it's desirable to have aliases while not allowing public joining:
Those also need a method to be discoverable and I don't think they necessarily need to be hidden under spaces, especially I don't think knocking and spaces currently have a connection. |
Description
I see (and make) the mistake of having the room invite-only despite adding an alias for people to join quite a lot. A possible solution may be to also set the room to be accessible as part of the canonical alias being added.
Some possible solutions are:
Version information
The text was updated successfully, but these errors were encountered: