I am sure it was discussed here before, but I can’t find a good way to search this community.
Are there any arguments against having a user’s identity federate, and be compatible across platforms?
For example, let us say I sign up with my instance, matcha_addict@lemy.lol
But what if I go on mastodon, and I want to have my own micro blog. Or maybe go to write freely and post some blog posts. I’d have to make a different account on each one.
What if mastodon or write freely could just let me log in with my lemmy account (or lets call it federated account). This has several benefits:
- users don’t have to scratch their head on if I am the same person or not across these platforms
- theoretically, someone following my feed can get updates on what I do on multiple platforms
Now I understand this would be difficult to implement and iron out all the edge cases, but am I missing anything on why it wouldn’t be a desirable feature, given it is implemented?
This is a controversial issue.
Some people don’t care about having an unique identity and actually favor creating multiple accounts on each service, to present themselves with different avatars depending on who they are interacting with. They are not “attached” to their identities and see this an opportunity to stay pseudonymous online and protect their “real” identity.
Some people think that the instance you join should be also somewhat indicative of your tribe and that they should be able to filter out who they talk about by checking the domain. This view is especially favored by the Mastodon crowd.
And then some other people (I think I would include myself) would like to be able to not just “use” a single identity, but to have portable identity in the Fediverse as a way to ensure that we can remain sovereign over our online presence. I would personally love for Communick customers to be able to use their personal domain, because that would mean that if even if I closed down things tomorrow, they would be able to migrate easily and without depending on me.
Some […] favor creating multiple accounts on each service
That’s fine, this feature wouldn’t prevent them!
What you mentioned in your last paragraph is in line with what I want, but maybe more of a next step from there.
So far, the only Fediverse project that lets users with different domains (and identities) under the same server is Takahe, but its development is a bit stalled and it is only supporting Mastodon.
Are you asking all these questions out of mere curiosity or are you willing to commit some type of effort and/or resources to see this happening?
It is regarding something I’m working on, but you may not find it interesting as it is not ActivityPub based (but a bridge will be implemented).
At a more abstract level, inviting a bunch of people to play a game, and then changing the rules of the game, is a shitty thing to do.
The fediverse has rules built into it. It has a way that it works. Changing that makes it something else.
Identity belonging to an instance, changing to identity belonging to the fediverse as a whole.
Identities containing @instance format.
Identities being federated.
We host instances for trans and gender diverse folk, to provide a space that explicitly puts their safety first.
Take away the idea of an instance as a community/identity/distinct space, and the goal for these places existing is gone. Instead of a community and a safe space, we become a generic bit of hardware that enables transphobes as much as trans folk.
That’s not something I’d be keen to keep sinking my own funds in to to support.
What I’d much rather see is instance based accounts, however, with the ability to take over/migrate them from other instances, so that if an instance goes down, people can still keep their identity. It would also allow instances focused on protecting minority communities to keep doing that.
This is a very valid concern and I should clarify a bit about the mechanism I have in mind.
An instance admin can decide which instances it federates identities with, similar to how regular federation is done (but maybe these would have separate lists)
So, in your case, you would only federate identity with instances you trust to have done proper vetting. It wouldn’t be by default that having a federated instance means you have access to login the entire fediverse.
White listing encourages centralisation because it makes it really hard for new communities/instances to develop the trust they need to be included in existing white list circles.
What I’d much rather see is instance based accounts, however, with the ability to take over/migrate them from other instances, so that if an instance goes down, people can still keep their identity. It would also allow instances focused on protecting minority communities to keep doing that.
This exists right now. It has existed for longer than Mastodon, much less Lemmy.
Established by Mike Macgirvin in 2011 when he invented nomadic identity. First implemented in his Zot protocol from 2012 and a Friendica fork named Red, later Red Matrix, known as Hubzilla since 2015. Also available on (streams).
Not just a vague concept or an experiment, but daily-driven on stable servers since over a decade.
Nomadic identity goes even further than migration. Nomadic identity allows you to have the same Fediverse identity with everything in it (name, posts, connections, settings, files etc. etc. pp.) on multiple servers simultaneously. Not dumb copies. Bidirectional, near-real-time, live, hot backups. Whatever happens on one instance of a channel will be sync’d to all others almost immediately.
One of the clones goes down, doesn’t matter. The main instance goes down, doesn’t matter, you can use the clones just the same. The main instances goes down and stays down, doesn’t matter, you make one of the clones your new main instance. All your nomadic connections are automagically changed to your new identity based on your new main instance. Yes, even on remote servers.
Even migration is based on the same concept. If you move from one server to another, first a clone is created, then the clone is declared the new main instance, thus demoting the original instance to clone, then the old original instance is deleted and the account with it. Not only can you move with absolutely literally everything, but you don’t leave any rubbish behind on the old instance.
Only downside: It does not work on ActivityPub. Yet. It requires a special protocol, either Zot (Hubzilla) or Nomad ((streams)). ActivityPub-based projects don’t even understand nomadic identity. So when you move, you have to reconnect all your non-nomadic followers.
ActivityPub implementation is being worked on, at least in theory. But the guy behind all this has, well, apparently not fully quit, but dramatically slowed down.
Yep, it was one of his posts referring to implementing his existing approach to AP that I was thinking off!
We’ll see what comes out of this.
Mike has already implemented FEP-ef61 on (streams), and it seemed to have worked well under lab conditions. But then he rolled it out to release in July. Channels created on accounts registered after that point have decentralised IDs already. And surprisingly, it caused tons of bugs to the point of these channels not properly federating with anything. And since he’s the only (streams) developer, he had to iron everything out himself. And quickly so because a few dozen people use (streams) as a daily driver.
In mid-August, he forked Forte from the streams repository. It was his vision of “the Fediverse of 2030”: basically (streams), but only supporting ActivityPub anymore, with both (streams)’ own Nomad and Hubzilla’s Zot6 ripped out. Guess the idea was to have something with no extra protocols standing in the way of straightening FEP-ef61 and nomadic identity via ActivityPub. But this caused even more of a workload.
On August 31st, Mike sent a private post to his immediate connections (his channel is set up to send private posts by default) that said that he quits. He wanted to stop developing for the Fediverse because it got too much. The community could carry on if they want.
Trouble is, there’s nobody among the few dozen (streams) users who has got what it takes, namely both the time and especially the skills to take over as a lead dev. One guy is ambitious, but he has only recently taught himself git just to make his own pre-FEP-ef61 branch for personal use. Then there are a few people who do know git, who may also know how to code, but who don’t have the time.
We got one offer by a guy who wanted to rewrite (streams) from scratch. He had taken a look at the (streams) code, and he said that some of it is very old and crufty and mouldy. Of course, a lot of code probably still dates back to 2012 when Mike forked Red from Friendica to implement nomadic identity and rewrote the entire backend against Zot. Problem was, I think that guy came from Mastodon, he probably hadn’t even seen Friendica in action, much less Hubzilla or even (streams), and he described himself as “thick”, so we’d have to explain everything to him. Nobody even reacted.
Luckily, Mike is still Mike. He can’t keep his fingers off improving the Fediverse. Every couple days, we see commits to the streams repository and/or Forte. It’s just that things are moving forward very slowly now. The community is trying to figure out what and where the bugs can be by examining log files and whatnot, but nobody can track them down in the source, much less fix them and submit a PR, and that isn’t talking about merging the PR.
the ability to take over/migrate them from other instances, so that if an instance goes down, people can still keep their identity
I can definitely see user migration from one ActivityPub server to another being a possibility, but I really don’t see how that can happen if one of the servers is down. That’s too late then. If you could migrate a user from a server that is down, what prevents you from migrating a user from a server that is still up and doesn’t want to do the migration? You could just pretend that it is down and do the migration anyway? I have no idea how that would work.
The proposal I saw was basically a way of “signing” your posts, and then when they federate somewhere else, you can create an account on another instance and “claim” the posts that have federated there as yours, with your private key.
Obviously, you couldn’t access posts that never federated to the instance in the first place, but even with some lost content, it would let you edit, and post new content.
And as I understood this proposal, basically, you could have multiple active accounts, all of which are “you”, and allow you to control your content with the same permissions.
Yea that could in theory be possible - the big problem is that it requires people to hold their own private key and manage that, both securely and conveniently. And well… tbh I just don’t see that happening. If you need to keep your own private key and also keep your own password, I really don’t see any non-techie people ever using the fediverse.
There’s also the issue that if that private key is leaked, there is no going back. Your identity is stolen and you can do nothing to take it back. This is different from if your password gets leaked - in that case, an admin could in principle step in and reset your password and you could regain control of your account. This happens all the time when people’s Facebook accounts get “hacked”. They report it to Facebook and get their account back. This is impossible if it relies on a user-held private key.
It’s a neat technical solution that unfortunately forgets the human, as is often the case.
It is a matter of responsibility. If you can log into any lemmy instance or mastodon server with the same account, then which server takes responsibility for your actions in the fediverse?
I have seen instances be defederate from because of their lax account creation requirements, or because of harrasment from users from a specific instance.
If an account can log into any instance, then who is responsible for banning the account?
It is a matter of responsibility. If you can log into any lemmy instance or mastodon server with the same account, then which server takes responsibility for your actions in the fediverse?
This is a good point and I should clarify: in this model, you wouldn’t get open access to any instance. The instance has to explicitly trust (white list) instances from which it will accept log ins. It would be like federation is done today, but the lists would be separate ideally.
Another model is it could do it on a case-by-case basis on the user level instead of instance level. But it would still enable the user to keep their dame ID and original domain.
It will be difficult to implement and pretty much at the end of the list for the software you want to implement.
Users most of the time dont want to get identified ( some are here because of the privacy ) and if you want to get identified you can just use PGP signing.
PGP signing is cool but it does not grant the benefits I was talking about unfortunately :(
It would be ideal If the big activitypub platform stacks like mastodon, Lemmy, etc could agree on some standard like a federated OIDC or DID approach for all authx/authn functions. then fediverse users could get cross-platform and even cross-instance logins “for free”