atomic-server
atomic-server copied to clipboard
sign-up endpoint: create a new Drive and a new Agent in one request
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
/signUpendpoint 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.
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.
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.
Subdomains like joep.atomicdata.com?
Subdomains like joep.atomicdata.com?
Exactly