Here’s a short write-up about proposed access controls for rooms.
Currently rooms are accessible to anyone who has the link. The only exception are bound rooms, which are only possible to create via our discord integration. (Which incidentally will not be available initially to Hubs Cloud instances.)
There are a variety of use-cases where people need to be able to have finer grained control over who has access to a room. Some examples are below in the “Use-Cases” section.
Within this, there is the need to also control who has access to the lobby vs room entry.
New Room Access Control Settings
Here are the proposed new settings I think we should add for un-bound rooms, under a Access Control tab in the Room Settings dialog:
Public: Public rooms will be visible on the homepage.
- By default, only admins can set rooms to public. Additionally, there is a site-wide config admins can enable to allow anyone to make their room public.
- Private (default): The current model, where anyone with the link can join.
- Invite-only: A more privacy-focused model, where the room creator can generate invite links, which have a limited number of uses and an expiration time. (Similar to Discord.) Visitors who have not accessed the room via the invite link (which will flip a bit in their local storage + account) will be denied access.
- Public: Public rooms will be visible on the homepage.
- Open (default): Anyone with access to the room, can enter the room.
- Invite-only: Only those given invite links can enter the room.
The UI which lets you create invite links will have the following options:
- Number of uses
- Recipient can enter the lobby
- Recipient can enter the room
- Recipient is promoted to moderator role
The following additional options seem like a good idea to add to fully enable a variety of audience-centric use cases:
- Enable/disable chat from the lobby
- Enable/disable ability for full fly mode controls from the lobby
- When in spectator mode, ability to enter VR mode and fly around if flying is enabled
Other concepts which were suggested that seem less critical relative to the above:
- Password-based access control
- Seems less useful and harder to use vs expiring secret invite links
- Email whitelists
- Invite links seem better, and less brittle since often email addresses are easy to mistype, often unknown, or not the preferred method for contacting someone.
- Additional new binding contexts (eg Twitter)
- Seems complex insofar as these do not mirror discord semantics. Twitter’s asymmetric links for example are a unique structure vs the symmetric, closed network of Discord. However, expanding our binding targets to similar platforms like Slack and Matrix still seem like a great idea.
The following use cases show how these configuration options can be tweaked
I am hosting a highly private gathering and want more certainty that unauthorized visitors will not get access due to a URL leak
- Room Access: Invite-only, Room Entry: Open (invite-only entry is meaningless here)
A bad actor has entered a previously public room and I’d like to lock it down
- Flip Room Access and Room Entry to invite-only, and kick the person. Share the invite link in the chat with others who are in the room. Subsequent access will require invite links.
I am running an event with VIPs in the room and want a large passive audience who can spectate
- Room Access: Public or Private, Entry Access: Invite-only. Disable lobby chat, enable lobby locomotion. Send invite links to the VIPs.
I am planning an event or gathering and have a few moderators who I want to be sure have moderation controls
- Previously, you’d promote them in-room. Under this model, you can send them via email an invite link which will let them promote themselves beforehand
Beyond this, there may be a need once these are implemented to further enable the various ‘large audience’ use cases:
- Ability to “knock” to be permitted to enter the room by a room owner/moderator, live
- Ability to temporarily grant access to the room for a short duration (for Q&A, etc)