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

Should adding a canonical alias to a room make it free to join? #317

Open
turt2live opened this issue Nov 14, 2017 · 4 comments
Open

Should adding a canonical alias to a room make it free to join? #317

turt2live opened this issue Nov 14, 2017 · 4 comments
Labels
A-Room-Settings T-Enhancement X-Needs-Product More input needed from the Product team

Comments

@turt2live
Copy link
Member

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:

  • Automatically set the room to public
  • Ask inline if the user would also like to make the room public (my preferred method)
    • Eg: "It looks like you're adding an alias. Would you like to make this room public? [yes] [no]"
  • Ask with a popup

Version information

  • Platform: web (in-browser)
  • Browser: Chrome 62
  • OS: Windows 10
  • URL: riot.im/develop
@turt2live
Copy link
Member Author

For reference, the current conversation flow is a lot like this:

  • A: Please join #mycoolroom
  • B: It's not accessible?
  • A: Oops! I set it to invite only. Try now?

@lampholder
Copy link
Member

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?"

@hex-m
Copy link

hex-m commented Apr 29, 2021

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:

  • Private: invite-only, has no identifier/link, not listed anywhere
  • Public: has a public Address, history is public, free to join
  • Default: has a public Address, not listed in the room directory, anyone who knows the name can knock

This is just a suggestion but the general point is that those settings are too complex.

@Mikaela
Copy link

Mikaela commented Dec 9, 2021

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:

  • Knocking-only rooms
  • Restricted rooms for members of other rooms and spaces

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.

@kittykat kittykat added X-Needs-Product More input needed from the Product team A-Room-Settings and removed P3 Help Wanted Extra attention is needed X-Needs-Design labels Jan 31, 2022
@t3chguy t3chguy transferred this issue from element-hq/element-web May 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Room-Settings T-Enhancement X-Needs-Product More input needed from the Product team
Projects
None yet
Development

No branches or pull requests

6 participants