sign-up / register endpoint: create a new Drive and a new Agent in one request

[joepio]

Creating a new user / Agent is currently always done using Invites. That flow doesn't make a lot of sense for most usecases: users will probably want their own workspace / Drive, and not join some existing one.

So how should that work?

• I think we need a /signUp endpoint that takes a public key + username and creates a drive + agent.
• A custom view is warranted, since the client still needs to generate the key (and that should happen at the touch of some button)
• We should check for name collissions. Every username must be unique, as we'll use that for the URL.

Front end:

• Use /register and /confirm-email endpoints
• User can Register using one button
• Create new drives the new way
• Remove / change old invite system. Maybe it still should work, but it needs a refactor at least. We at least want users to create a Drive from an agent without an e-mail address.

PR Checklist:

• Link to related issue closes Update URL usage - root URL should be /  #640 closes open menu keyboard command opens multiple dropdowns #641
• Add changelog entry linking to issue
• Added tests (if needed)
• (If new feature) added in description / readme

[AlexMikhalev]

There should be one user owner of the atomic data go gets keys from logs and then invite others. Sign up can be callback from existing services like Oauth2.

[joepio]

I'm currently trying subdomains for every agent. I aethetically really like subdomains, they feel far more personal than paths.

However, they do pose a challenge. Notably, all origin related state (cookies, localstorage) is lost when going to a different subdomain.

Some strategies to deal with this:

• Instruct the user to safely store their secret, then use it in their new subdomain. I think this is pretty decent. We make sure the users stores their secret. However, this won't transfer some other localstorage things (e.g. dark mode)
• Stay on the atomicdata.dev domain. We can send cross-domain requests, so it would work, but the user won't get their 'hey this is really my space' feeling.
• Subdomain-less cookies. We could store everything there, probably. But these are sent over HTTP on every request, as far as I know.
• iframe hacks. Send private key from old to new.

[AlexMikhalev]

Subdomains like joep.atomicdata.com?

[joepio]

Subdomains like joep.atomicdata.com?

Exactly