Honestly Matrix E2EE and federation is a bit like cryptocurrency (without going into all its other social problems).
-
@lina I think someone could even push in this direction this today, without *any* work on their side. They allow 3rd party clients, explicitly. Building one which could remember the credentials for and connect to multiple servers (computers) and display all the servers (chatrooms) and DMs on those (computers) in one UI would be a big step.
Invite links to join other servers (on other servers) could probably be handled client-side too, though handling DMs might be a little hairy.
@lina And of course this would become way simpler with support for portable identity, even something simple like the openID connect we had in 2005-7. That way you wouldn't need to create an account on each new server, you could just tell it "I log in over here."
-
@lina And of course this would become way simpler with support for portable identity, even something simple like the openID connect we had in 2005-7. That way you wouldn't need to create an account on each new server, you could just tell it "I log in over here."
@developing_agent Yup, it could be built on Revolt/Stoat. You need three things though:
- Scoped users (user@domain or whatever format), this does require core changes (more or less depending on how well factored it is)
- Authentication federation (only)
- The multi-server client thingScoped users are important because you don't literally want to register "local" accounts on every server, that's a namespacing problem (you need the accounts but you can't have local *usernames* is the issue). There have to be scopes, there's no way around that for distributed auth (how much or how little you expose them in the UI can vary, but they have to be there)
It's not a massive project but it does need buy-in/coordination with the core team.
-
@developing_agent Yup, it could be built on Revolt/Stoat. You need three things though:
- Scoped users (user@domain or whatever format), this does require core changes (more or less depending on how well factored it is)
- Authentication federation (only)
- The multi-server client thingScoped users are important because you don't literally want to register "local" accounts on every server, that's a namespacing problem (you need the accounts but you can't have local *usernames* is the issue). There have to be scopes, there's no way around that for distributed auth (how much or how little you expose them in the UI can vary, but they have to be there)
It's not a massive project but it does need buy-in/coordination with the core team.
@lina I was actually _literally_ suggesting registering "local" accounts on every server and letting the client manage the credentials. Yes, this is incredibly, incredibly dumb.
100% agree that it would be better to get scoped users and federated authentication going as official parts of the protocol. This was just a thought experiment in "what could we do if we had to go it alone and were willing to break the rules a bit."
-
@lina I was actually _literally_ suggesting registering "local" accounts on every server and letting the client manage the credentials. Yes, this is incredibly, incredibly dumb.
100% agree that it would be better to get scoped users and federated authentication going as official parts of the protocol. This was just a thought experiment in "what could we do if we had to go it alone and were willing to break the rules a bit."
@lina Asking forgiveness instead of permission, so to speak, and going ahead and building a client anyway.
-
@lina Asking forgiveness instead of permission, so to speak, and going ahead and building a client anyway.
@developing_agent Oh yeah I mean, you could totally start with that to build out the client side of the UX. It's just only half the intended puzzle ^^ (and then you'd have to build a migration path towards unified accounts, but I guess you'd kinda need that anyway)
-
@developing_agent Oh yeah I mean, you could totally start with that to build out the client side of the UX. It's just only half the intended puzzle ^^ (and then you'd have to build a migration path towards unified accounts, but I guess you'd kinda need that anyway)
@lina I think it could be done without rethreading history, just changing the user account type so that the server knows to go elsewhere for auth. Then sending new information to the client whenever you're talking about a truly non-local account....
...actually, the hardest might be trying to handle other people who are also running multi-server clients, clientside in the initial bodge-client. Thinking about that makes my head hurt.
-
@lina I think it could be done without rethreading history, just changing the user account type so that the server knows to go elsewhere for auth. Then sending new information to the client whenever you're talking about a truly non-local account....
...actually, the hardest might be trying to handle other people who are also running multi-server clients, clientside in the initial bodge-client. Thinking about that makes my head hurt.
@developing_agent You'd just have to migrate the account to have non local scope (presumably set a scope/domain field). Whether this breaks past mentions depends on whether those are stored by name or by ID... (I hope id)
But the more interesting thing is designing a flow to "take over" a local account and migrate to remote identity without risk of ending up with two unmergeable accounts too easily...
As for multiple clients, an existing legacy client miiiight be able to keep its auth token and stay logged in but there are a lot of asterisks on that. And to log back in you'd need, at minimum, "app passwords" or something.
-
@developing_agent You'd just have to migrate the account to have non local scope (presumably set a scope/domain field). Whether this breaks past mentions depends on whether those are stored by name or by ID... (I hope id)
But the more interesting thing is designing a flow to "take over" a local account and migrate to remote identity without risk of ending up with two unmergeable accounts too easily...
As for multiple clients, an existing legacy client miiiight be able to keep its auth token and stay logged in but there are a lot of asterisks on that. And to log back in you'd need, at minimum, "app passwords" or something.
@lina You mean having two accounts that mutually point to each other as "I log in other there"?
I think it might be an unlikely race condition if it requires manual conversion as exists in mastodon. But I think two problems could be solved at once with a cool-down between pushing the button and actually becoming a non-local account. If servers refuse to become that external authenticator during the cooldown that might fix it, and it ads a guard against hostile takeover.
-
@lina You mean having two accounts that mutually point to each other as "I log in other there"?
I think it might be an unlikely race condition if it requires manual conversion as exists in mastodon. But I think two problems could be solved at once with a cool-down between pushing the button and actually becoming a non-local account. If servers refuse to become that external authenticator during the cooldown that might fix it, and it ads a guard against hostile takeover.
@lina Not sure what you mean by the "multiple clients" case.
-
@lina You mean having two accounts that mutually point to each other as "I log in other there"?
I think it might be an unlikely race condition if it requires manual conversion as exists in mastodon. But I think two problems could be solved at once with a cool-down between pushing the button and actually becoming a non-local account. If servers refuse to become that external authenticator during the cooldown that might fix it, and it ads a guard against hostile takeover.
@developing_agent Nono. What I mean is that if you have a local account, and then federated auth is implemented, any interaction from your home base account in its capacity, with a server you already have a local account in, would end up with a duplicate account situation that's hard to fix (one local, one remote), while what you want is to convert the existing local account to remote.
My gut feeling is the safest solution to this is email matching. If you're already requiring emails for account creation, then they can be used to check for a preexisting local account. You'd have to verify via email confirmation, but it would avoid the risk, and it can also be used for remote account recovery when you lose your home server. The flip side is it exposes your email to all servers, and in fact allows "does this email exist in this server" lookups by alll third parties (modulo rate limits etc), but I feel the advantages outweigh the disadvantages here (though you could still turn the feature off if you know/accept the risks, there's room for more paranoid opt in choices here).
There are subtle tunables here, e.g. you could do a bit of "proof of work" stuff for email lookups to avoid blatant spammer/scraper abuse.
-
@lina Not sure what you mean by the "multiple clients" case.
@developing_agent I mean having a (legacy) client logged in while an account is transitioned from local to remote.
-
@developing_agent I mean having a (legacy) client logged in while an account is transitioned from local to remote.
@lina tbh, I think that's a can of worms you don't want to open if you don't have to. It's already standard practice to log someone out everywhere when their password changes, and this is a much bigger change to their account that that. Maybe if there's a waiting period it only happens at the end of the cooldown when the result finally sticks.
-
What I want is a Discord UI/UX running on top of an IRC bouncer+OAuth provider gateway that connects to a diverse universe of IRC networks (but with all the stored state Discord has).
(And yes, the average instance would co-locate the bouncer/gateway instance and the underlying chat network and the average user would just sign up there and wouldn't even know the difference, they wouldn't be running their own bouncer. But people like me would.)
@lina I think “porting the discord experience” is exactly the issue here. People have suggested matrix to me as an alternative multiple times. The issue is that I don’t think my “non technical” friends and community would enjoy it as much. It’s too complicated for them - and too different. I’m currently checking Stoat since it seems almost like a clone, I’m just a bit worried about how scalable it actually is.
-
@lina tbh, I think that's a can of worms you don't want to open if you don't have to. It's already standard practice to log someone out everywhere when their password changes, and this is a much bigger change to their account that that. Maybe if there's a waiting period it only happens at the end of the cooldown when the result finally sticks.
@developing_agent Yeah... the issue is then, you wouldn't be able to log back in without updating to a federated auth compatible client.
-
@developing_agent Yeah... the issue is then, you wouldn't be able to log back in without updating to a federated auth compatible client.
@lina I suppose that's expected if you've chosen to push that particular button (would it only be possible from such a client?), though it doesn't give people the option to go back obviously.
-
@lina I suppose that's expected if you've chosen to push that particular button (would it only be possible from such a client?), though it doesn't give people the option to go back obviously.
@lina Maybe this isn't an issue at all? If you need a federated-auth client to set up the federated-auth account you're migrating control to, then you can be sure as a server designer that people have such a client by the time they migrate.
-
@lina Maybe this isn't an issue at all? If you need a federated-auth client to set up the federated-auth account you're migrating control to, then you can be sure as a server designer that people have such a client by the time they migrate.
@developing_agent Oh of course, I mean just if a user has multiple logged in clients (and not all are updated) it could be janky UX.
-
@developing_agent Nono. What I mean is that if you have a local account, and then federated auth is implemented, any interaction from your home base account in its capacity, with a server you already have a local account in, would end up with a duplicate account situation that's hard to fix (one local, one remote), while what you want is to convert the existing local account to remote.
My gut feeling is the safest solution to this is email matching. If you're already requiring emails for account creation, then they can be used to check for a preexisting local account. You'd have to verify via email confirmation, but it would avoid the risk, and it can also be used for remote account recovery when you lose your home server. The flip side is it exposes your email to all servers, and in fact allows "does this email exist in this server" lookups by alll third parties (modulo rate limits etc), but I feel the advantages outweigh the disadvantages here (though you could still turn the feature off if you know/accept the risks, there's room for more paranoid opt in choices here).
There are subtle tunables here, e.g. you could do a bit of "proof of work" stuff for email lookups to avoid blatant spammer/scraper abuse.
@lina If it's purely federated-auth, then you would continue to have one and only one account on each server (only method of auth changes), so a remote "homeserver" account and the "local" account would never appear alongside each other.
At the time of the transfer of login authority, the account type on the remote server would undergo some remodelling, so eg. when someone mouses over your profile in posts on remoteserver it says you're "person@otherserver" instead of just "person"
-
@lina If it's purely federated-auth, then you would continue to have one and only one account on each server (only method of auth changes), so a remote "homeserver" account and the "local" account would never appear alongside each other.
At the time of the transfer of login authority, the account type on the remote server would undergo some remodelling, so eg. when someone mouses over your profile in posts on remoteserver it says you're "person@otherserver" instead of just "person"
@lina The homeserver knows what servers you have an account on, and they consult it on login and identity, but under the hood you'd have one account on each server that the client would connect to, to DM* someone there or participate in a chatroom there. You aren't relaying messages and actions through it, at least in my mental model.
*(DMs are actually a thorny issue. whose homeserver is the one hosting?)
-
@lina If it's purely federated-auth, then you would continue to have one and only one account on each server (only method of auth changes), so a remote "homeserver" account and the "local" account would never appear alongside each other.
At the time of the transfer of login authority, the account type on the remote server would undergo some remodelling, so eg. when someone mouses over your profile in posts on remoteserver it says you're "person@otherserver" instead of just "person"
@developing_agent Right but what I mean is that if you have an existing account on a server, and you have a streamlined flow (perhaps 1-click or even 0-click) for federated account registration, then you can easily end up in a situation where you accidentally create a new account instead of transferring the existing one (for example, if the client you're using is not logged in on the old one).
Email matching would provide one safeguard against that (on federated account registration attempt, the email collision would be detected, and you'd be prompted to take over the existing local account instead via password or, if you forgot, email verification flow).
