CIRCLE WITH A DOT

@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.

@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 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 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 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"

@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 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 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.

@ktims @lina

E2EE is a solved problem for *DMs* (see signal)

E2EE is still very much a moonshot for large chat platforms, and matrix is an early attempt that blew up on the launch pad.

@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.

@lina I think people tell themselves that sunk cost fallacies are valid in social media because of "network effects" ie. that we *have* to push the solution that has the most users because it's the only thing that stands a chance.

But something badly designed that makes new users recoil will never grow. It will not attract the *next* million, or thousand, or hundred users and has already peaked.

@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 Asking forgiveness instead of permission, so to speak, and going ahead and building a client anyway.

@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 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 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 I've asked myself for years if revolt (now stoat) could be molded into something like that. People have been pushing them for *ages* to "add federation" but the limiting factor has always been that the team is a tiny group of volunteers.