Hubs login flows

Proposal for Hubs login flows

There are two planned features which will require being signed into an account:

  • Pinning objects. To pin an object to a room (regardless of if its an upload) you’ll need to sign in. Eventually there will be a page you can go to to manage/remove your pinned objects. As a bonus this will also allow us to provide a list of rooms to you, so you can “bookmark” a room by just pinning something into it.

  • Becoming the host or mod of a room. Hosts can edit room settings and the name of the room, and mods + hosts can kick/mute users.

Logging in will be the same as in Spoke – enter an email address to both sign in or create an account, and you get a loading spinner while you async click on the link, and tab back.

Login status appears in the bottom of the presence list. When logged out it shows a simple “sign in” button. When logged in, it shows “Logged in as gfodor@mozilla.com [sign out]”. The expectation is that the “sign in” flow here will be basically unused, but its needed as an escape hatch for some users to sign in if they accidentally log out, session expired, etc.

We don’t store email addresses on the server. When a user logs in, we store their auth token as well as the email address they used to log in in local storage, so we can display it.

Two primary sign in flows:

  • When you click “pin” on an object when signed out

  • When you click an “edit” or “gear” icon in the lobby panel at the bottom, which would normally pop up the room properties panel where you can rename the room or change room settings. (This prompt will only be available if the room does not yet have a host.)

CTA prompt for login modal should be customized depending on the mechanism which popped it. (Eg “To pin objects and save them to the room, you’ll need to sign in.”)

When linking headsets, we should transfer the token and email info to the device to prevent the need to sign in again. We may want to consider adding an additional character to the code for additional security.

Display name and avatar settings are not stored with the account. The display name and avatar settings will migrate over device linking as usual, but signing in will not automatically set the name and avatar. If a user signs out, we should re-generate a random avatar choice.

Potential idea: when you sign in, if the avatar name has not been customized, set it to the prefix of the email address.

When in VR, tapping the “pin” button will bring you out of immersive mode and show the login prompt. Hitting cancel will re-enter immersive mode. After signing in, the modal will have a “re-enter VR” button at the end that is the only way to proceed which will re-enter immersive mode. For now there is no other way to be prompted to sign in when using VR (beyond using the 2D UI before entering immersive mode.)

I’m surprised Avatar preferences/personalization and name isn’t persisted with an account? At least as an option for those who don’t wish to deal with that every time? Thoughts?

Tl;dr - once we have accounts, users will likely expect similar functionality to what accounts give them on other platforms. If we have [good reasons] not to enable, we should consider offering the option to those users who care.

A couple of reasons:

  • Persisting the name in the db is a big change in privacy in terms of what data we store

  • The current local storage based mechanism, combined with hub.link, works well today because the range of customization is very limited (it’s basically trivial to set your name and avatar choice if you are on a new device.)

  • It’s unclear strategically how we want to tie these things to accounts overall. For example, what model do we use for identifiers, how do those connect to avatar choices, do we give you the option to take on multiple personas, etc.

My expectation is that a new avatar system will roll out with the new accounts system planned next year and by that point we’ll have a solid plan of how we want to save personalized avatars and/or identities into that account. The current accounts are mostly there so we have a way to connect back to resource usage and apply security policies in a safe manner so we can enable pinning and moderation tools. To try to tackle all of this at once seems like a bad idea, since adding more persistent avatar customization options and persistent identity can always be added later, but it is really hard to unwind if we make bad choices in the design today. There are many ways to design this stuff (consider just the choices to be made around username allocation, uniqueness, and display name as one of several facets) so I think we should not block pinning + moderation tools on getting to a point of confidence on those things.

Gotcha, and makes sense. As long as we’re looking ahead at this for next year/new Avatars and Auth, no issues from me!