I've decided to implement multi-auth on my #mastodon client https://schizo.social
Currently it lets you auth with one account at a time, and the #oauth token this creates is stored in the session and destroyed when you log out.
I don't want the user to have to re-authenticate all their accounts each time they start a new session.
So I could let them create a new email/pass auth method, and then store their various mastodon tokens in the db. Maybe #passkeys or #webauthn?
...or, whenever a user authenticates I could fetch their account info, and store it in a db along with all the tokens they currently have in their session.
Then later on if the user reauthenticates with *any* of those accounts, I could fetch the tokens for the rest of their accounts from the db to repopulate the new session with old tokens...
It feels a little dangerous to link auths to one another; like there could be edge cases where a user could get confused.
I think I should probably notify the user when they first auth a new account that it will be linked to the previous ones such that if they ever auth with any of them it will load the others.
Also, I'll need to handle if any of the tokens expire, so you may auth once and then be asked to auth with other accounts.
Other Mastodon clients that do multi-account don't do it this way; take Elk.zone for example. You have to authenticate with all your mastodon accounts one every device you use it on. If one of the authentications gets revoked you have to remove the account from elk and re-add it.
What I am suggesting is that if you have a dozen accounts in Elk on one device, then you sign in to *any* of those on another device, you'll be automatically authenticated with all the rest.
There might be a time where one would not want the same accounts on all devices. A social media manager's work computer vs their personal computer, for instance. Will there be a way to disassociate accounts from each other on certain devices?
You may be solving a problem that doesn't really exist. Not to say that you shouldn't. It sounds like a very fun problem to solve.