Thread to capture thoughts on accounts.
In order to allow users to upload/store persistent content in Hubs they’ll need to be signed into an account. The account credentials will grant them certain resource utilization privileges as well as give them a context-less, recoverable mechanism to purge any data stored on our servers.
The primary starting use-case for an account will be to upload GLTF scene content from Spoke for permanent storage as well as create a record about the existence of a scene, which will include metadata about the scene such as the name, description, author, and license. A secondary use-case will be to enable the storage of user-tied room state, such as uploaded files or spawned objects in a room that should be persistent across sessions.
Ideally these two use-cases can be enabled by a basic v1 account system in a way that:
- Preserves user privacy
- Defers decisions around user identity, avatars, namespaces, etc
- Does not unnecessarily gate functionality
- Is low friction, particularly in VR
Tenative plan:
The authentication mechanism to start will be a passwordless, email-based approach. From a user’s perspective, to log in or sign up they will go to the same form which asks them for an email address. After entering, they will see a loading spinner and a request to go click on a link in their email. At this point, they can open the link on any device, not just the one they are currently using. (For example, if they are on an Oculus Go, they can lift their headset and click the link on their phone.) Once the link is clicked, the user is authenticated and security credentials are passed down to the originating page.
A few implementation points for a proposed plan:
The mechanism for orchestrating this can be a custom phoenix channel. The contract will be that the originating client will create a new (random) phoenix channel of a certain type (“authenticate”.) Once created this channel will accept (at most one) message that indicates the email of the person who wishes to authenticate.
Once that message is received an email is dispatched with a one-time-use link. This link will contain a token which can be used to look up the phoenix channel and email address. Once clicked, an account is created for that email address if it doesn’t already exist, a new JWT token is generated as credentials for the account, the channel is connected to, and the JWT is broadcasted over the channel.
On the receiver side the JWT is then received, stored in local storage, and can be used for further API calls.
In addition to this basic phoenix channel based authentication system we’ll also need to enhance the upload API. Right now the upload API only accepts “expiring uploads” which are placed in a folder on disk which gets swept every 48 hours and are individually encrypted with a one-time-use secret key which is not stored on disk. For permanent storage, the upload API should be extended:
- A new argument will be passed
durable=true(or something) - If the user is not logged in (or otherwise doesn’t have permission due to resource limits, etc) then access is denied
- The upload is stored on disk encrypted as before but the encryption key is a reticulum config secret. The user is not given an authentication token for the file, since the file is publicly accessible to anyone who knows the URL.
- The sweeper obviously should not delete the file.
- A database record should be kept mapping accounts to files which includes enough metadata to track resource utilization and allow removal of the files if the user requests to do so.
- A DELETE verb should be added to the uploads API. Likely this will schedule the file for deletion (since removing it immediately may not be possible, or the user may be given a grace period to restore it, etc) but will remove it immediately from access from the Internet.
Also, new APIs should be added to:
- allow a user to list their uploaded files
- allow a user to create and delete a scene (which will delete all relevant uploaded files.)
- delete their account (which will delete all their uploaded files and scenes.)