Honestly Matrix E2EE and federation is a bit like cryptocurrency (without going into all its other social problems).
-
@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).
-
@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).
@lina Ah, I see what you mean. That is a bit of a "training the user" sort of footgun, getting them to turn their existing account into a remote-auth account rather than make a new account. Maybe it's mostly solvable with good menu design that nudges them in the right direction.
-
@lina Ah, I see what you mean. That is a bit of a "training the user" sort of footgun, getting them to turn their existing account into a remote-auth account rather than make a new account. Maybe it's mostly solvable with good menu design that nudges them in the right direction.
@lina If you have an existing mechanism to turn local accounts into remote-auth accounts, *maybe* it's not too far to have an option or admin tool that merges two accounts into one, which gets ownership of both accounts' messages. This would probably(?) work out ok for public chatroom messages, but merging two different DM threads would be....odd. and this is a new implementation yak to shave.
I wouldn't want to go there if I didn't have to, but at least the problem is confined to one server.
-
@lina If you have an existing mechanism to turn local accounts into remote-auth accounts, *maybe* it's not too far to have an option or admin tool that merges two accounts into one, which gets ownership of both accounts' messages. This would probably(?) work out ok for public chatroom messages, but merging two different DM threads would be....odd. and this is a new implementation yak to shave.
I wouldn't want to go there if I didn't have to, but at least the problem is confined to one server.
@lina DM threads that share the same other person you were talking to from both accounts*
Maybe in practice this isn't so bad, since there was only actually ever one human being, and so DMs threads are likely to be chronologically non-overlapping and can be safely merged. (just like with public messages)
-
@lina DM threads that share the same other person you were talking to from both accounts*
Maybe in practice this isn't so bad, since there was only actually ever one human being, and so DMs threads are likely to be chronologically non-overlapping and can be safely merged. (just like with public messages)
@lina 4-way merging (2 and 2) also works I think, as long as merging is serialized (or only operates on accounts that do not share an edge in the server's social graph at any one moment?) but this is getting into the weeds.
-
Honestly Matrix E2EE and federation is a bit like cryptocurrency (without going into all its other social problems).
It's clever, it's an impressive technical achievement that it works at all... and it completely ignores all the practical reasons why server-centric systems exist.
You don't solve Visa and Mastercard censorship with crypto, you solve it with payment platform diversity. And you don't solve Discord with Matrix, you solve it with something with a design closer to IRC or XMPP.
(Reposted & lightly edited from a DM reply I wrote)
@lina honestly, I do think that if you extend XMPP the right way (add something similar to matrix spaces, allow for editing more then just the last message, and like 1 or 2 more small improvements) and wrote a client to support that and present it in a way that is kind of analogous to how discord and slack present their servers it would be a good option.
XMPP has pretty good message delivery and OMEMO is easy enough to understand and use that with a bit of explanation you could get a lot of people from discord over.
at the very least it is not the UI mess that is trying to verify another matrix client from element. -
R relay@relay.infosec.exchange shared this topic
