Any arguments against separating identity from instance/platform? (single identity across the fediverse)
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?
like this
RmDebArc_5
in reply to matcha_addict • • •matcha_addict
in reply to RmDebArc_5 • • •I agree, but reliance on an instance is already a big issue.
Theoretically, if this gets implemented, it could be possible to federate the ability to sign up elsewhere, or at least make your user downloadable and sign up with it elsewhere
matcha_addict
Unknown parent • • •rglullis
in reply to matcha_addict • • •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.
matcha_addict
in reply to rglullis • • •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.
rglullis
in reply to matcha_addict • • •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?
matcha_addict
in reply to rglullis • • •rglullis
in reply to matcha_addict • • •matcha_addict
in reply to rglullis • • •It will be yes! Right now I only have it locally and its messy, but the idea is like this:
- Your home feed allows customizing the sorting algorithm. There's a sensible chronological-based algorithm, but you can customize it more.
- Content is organized into feeds.
- By default, you have your own personal feed similar to a micro blogging platform.
- but you have the ability to have multiple feeds. For example, maybe you're into both technology and wood working, but not all followers are interested in both. So you have separate feeds, and users can follow one or the other.
- A feed isn't only for one person's posts. For example, I might maintain a woodworking feed, but I'd "share" posts from other wood workers. In essence, I am a sort of "content curator". I pick out the good woodworking content and put it in a single feed for you to follow!
- A feed can be like a Lemmy community or a Facebook Group. So it can allow multiple posters, it can be open to anyone to post, or it can be approval-only (but submitted from anyone). It can also be privat
... show moreIt will be yes! Right now I only have it locally and its messy, but the idea is like this:
In my opinion, this replaces automated algorithms with manual curation. It also replaces moderation, as you might like a community but wish it was differently moderated, there might be another feed that sources the first feed but with extra moderation!
The project is still in its infancy and I don't get too much time to work on it. But since you're interested, I'll try to get it into an open source-able state (albeit far from workable) and let you know when I do!
rglullis
in reply to matcha_addict • • •I might have good news for you: you don't need to drop ActivityPub to do that. Maybe what you are looking for is very close to my idea of a social web browser, i.e, an ActivityPub-based application that is controlled by the client and not the server.
What programming language are you working on?
ericjmorey
in reply to matcha_addict • • •intensely_human
in reply to rglullis • • •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.
rglullis
in reply to intensely_human • • •intensely_human
in reply to rglullis • • •Identity belonging to an instance, changing to identity belonging to the fediverse as a whole.
Identities containing @instance format.
Identities being federated.
rglullis
in reply to intensely_human • • •This is an implementation detail, it's not required by any part whatsoever of the activitypub protocol.
All that AP cares about is that actors have an URL for their inboxes and outboxes. You can have even servers to serve your actor id from a different domain in your instances.
Hell, you can even have no "instance" at all. You can have just a bunch of static files to serve your webfinger queries and bio and even the outbox, regardless of the username that you have.
I think it's fine to have people trying to use a simplified mental model to understand new concepts. But it becomes a problem when people start taking these mental models and try to justify their opinions on incomplete abstractions.
intensely_human
in reply to rglullis • • •rglullis
in reply to intensely_human • • •And web browsers were only meant to be a language for formatting documents, yet software engineers realized it could do a lot more than that.
It's not just because someone design things one way that automatically all other use cases become invalid. This argument makes no sense.
MartianSands
in reply to matcha_addict • • •That's going to be a problem whatever solution you come up with, because of the federated nature of the lemmy system.
There's no central authority to hand out usernames, so if two people sign up to different instances with the same username, any design which didn't attach instance name to each username would fail. The only way around it would be for each instance to contact every other instance which exists, including the ones which haven't federated yet, and negotiate ownership of the new username, and that's just not possible
matcha_addict
in reply to MartianSands • • •Flax
in reply to matcha_addict • • •matcha_addict
in reply to Flax • • •I already talked about why that matters in my post (didn't mention anything about a person's importance), but I'm happy to clarify and expand on it!
To summarize again, this would allow users to follow a person across platforms. Part of the benefit of the fediverse is I can choose to get content from a microblogging platform as well as macro blogging or threaded like lemmy. It would be a good feature for me to be able to follow someone across all federated platforms without having to scavenge for them.
Moreover, it would allow me to use other types of platforms without having to sign up on each one. This would also be useful for instance admins. If instance A trusts instance B, then it can allow instance B users to sign in without having to sign up separately.
This could also mean that instance A could be an identity provider only
Flax
in reply to matcha_addict • • •AbouBenAdhem
in reply to matcha_addict • • •Rooki
in reply to matcha_addict • • •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.
matcha_addict
in reply to Rooki • • •Rooki
in reply to matcha_addict • • •will_a113
in reply to matcha_addict • • •jelloeater - Ops Mgr
Unknown parent • • •maegul (he/they)
in reply to matcha_addict • • •Rednax
in reply to matcha_addict • • •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?
matcha_addict
in reply to Rednax • • •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.
hendrik
in reply to matcha_addict • • •I don't see any technical limitations preventing that. And I think it's a desirable feature. Imagine a world where you don't have to come up with lots of passwords and sign up on dozens of websites, but instead have one identity that's saved in your device and you can access any free software service without signing up and it'll already tell you if your friends are there. It could interconnect content and features...
It's a bit difficult to get it right, though. The identities need to be secure and reliable. Servers can't vanish (or data needs to be distributed) or people will lose everything at once. We need pseudonymous handles, sock puppets and access control. And there is a lot of trust involved. We need to mitigate for spam and trolls...
And agree on one standard that gets everything right for any arbitrary use-case.
Ada
in reply to matcha_addict • • •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.
matcha_addict
in reply to Ada • • •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.
Ada
in reply to matcha_addict • • •matcha_addict
in reply to Ada • • •SorteKanin
in reply to matcha_addict • • •intensely_human
in reply to Ada • • •SorteKanin
in reply to Ada • • •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.
Ada
in reply to SorteKanin • • •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.
SorteKanin
in reply to Ada • • •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.
Jupiter Rowland
in reply to Ada • • •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 t
... show moreThis 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.
Ada
in reply to Jupiter Rowland • • •Jupiter Rowland
in reply to Ada • • •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 priva
... show moreWe'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.
Nate
in reply to matcha_addict • •There are very few drawbacks (assuming it's implemented in a way that doesn't break things). That's why it's part of two of the big three social protocols (Nostr & AT/BlueSky) and Activity Pub might get it soon.
I've written about and participated in discussions about implementing identities not controlled at the instance level and discussed bridges that connect activity pub to other protocols. The one major drawback people tend to bring up is moderation, but moderation is not effected like some people think it could be. Just like a PGP key doesn't force Gmail to host a user's email and a domain doesn't force Dreamhost to host a blog, even if identities are separated from instances an individual instance can still ban a user from participating in that instance or prevent other instances from interacting with your instance. The only difference is that if an instance goes down or bans a user the user can pick up and move to a different instance instead of
... show moreThere are very few drawbacks (assuming it's implemented in a way that doesn't break things). That's why it's part of two of the big three social protocols (Nostr & AT/BlueSky) and Activity Pub might get it soon.
I've written about and participated in discussions about implementing identities not controlled at the instance level and discussed bridges that connect activity pub to other protocols. The one major drawback people tend to bring up is moderation, but moderation is not effected like some people think it could be. Just like a PGP key doesn't force Gmail to host a user's email and a domain doesn't force Dreamhost to host a blog, even if identities are separated from instances an individual instance can still ban a user from participating in that instance or prevent other instances from interacting with your instance. The only difference is that if an instance goes down or bans a user the user can pick up and move to a different instance instead of having their account nuked. As somebody who lost a profile due to a SQL database breaking it would have been really nice to have been able to continue.
Also, in the thread here I heard a few people talking about it negating communities. We already can communicate with remote servers, I'm not fully sure where the argument that independent-from-instance-identities will break communities comes from. If something like nomadic identities are implemented, which again, they may be, your account will still be largely focused on one instance.
Say you're an arborist and join an arborist Mastodon community. You're still a part of the community, and your account is centralized there until you say otherwise. Yes, you can reply to a lemmy post or peertube post by authenticating on one of those instances, but you can already do that (there's just a lot of jank since Activity Pub's monolithic servers often have a hard time understanding each other). Yes, say you reply to a lemmy post about beekeeping that would show up in the local insatance timeline (assuming remotely authenticated posts are allowed to show up in the timeline), but again not only can you already do that, but it's not like you'd expect an aborist focused instance would have ONLY aborist focused discussions.
Lol, I hope I was coherent. I just misinterpreted a bottle of bottle of lime infused liquor as 30 proof instead of 30% ethanol so I consumed a little more than I expected. Anyway, regardless, personally consider identities separated from servers/instances a very big pro, with very little drawbacks (if implemented in a way that does not break existing implementations).
Fediverse reshared this.
SorteKanin
in reply to Nate • • •Nate
in reply to SorteKanin • •Fediverse reshared this.
Jupiter Rowland
in reply to SorteKanin • • •It isn't. (Source: I've been using nomadic stuff since long before any of you has even heard of the Fediverse.)
Nomadic identity always requires one main instance of an "identity container" with a valid Fediverse ID. That Fediverse ID carries in it the domain name of the server on which the main instance of the "identity container" resides. You need something behind the @. The clones have the same Fediverse ID.
So if you have a Hubzilla channel on hub.foo.social, hub.bar.social and hub.baz.social, one instance of that channel has to be the main instance, and the others are the clones. If the instance of the channel on hub.foo.social is defined as the main instance, it's hub.foo.social that defines the idea (e.g. bob@hub.foo.social). From a Hubzilla POV, the clones on hub.bar.social and hub.baz.social are bob@hub.foo.social all the same.
Instance-less would require a fully decentralised, peer-to-peer approach like Briar where (ideally) each user na
... show moreIt isn't. (Source: I've been using nomadic stuff since long before any of you has even heard of the Fediverse.)
Nomadic identity always requires one main instance of an "identity container" with a valid Fediverse ID. That Fediverse ID carries in it the domain name of the server on which the main instance of the "identity container" resides. You need something behind the @. The clones have the same Fediverse ID.
So if you have a Hubzilla channel on hub.foo.social, hub.bar.social and hub.baz.social, one instance of that channel has to be the main instance, and the others are the clones. If the instance of the channel on hub.foo.social is defined as the main instance, it's hub.foo.social that defines the idea (e.g. bob@hub.foo.social). From a Hubzilla POV, the clones on hub.bar.social and hub.baz.social are bob@hub.foo.social all the same.
Instance-less would require a fully decentralised, peer-to-peer approach like Briar where (ideally) each user name only exists exactly once. And with no domain name attached to it.
And peer-to-peer in social networking sounds like an awesome idea until you have to run a full-blown, fully-hardened Web server on your iPhone on a wonky 4G connection, simultaneously sending a message to and receiving hundreds of messages from hundreds of other devices out there because you've got, like, 647 connections on your friends list. And then you wonder why your phone is so hot, and the battery craps off within hours.
SorteKanin
in reply to Jupiter Rowland • • •Jupiter Rowland
in reply to SorteKanin • • •I hope this Join the Fediverse Wiki article can help you. I've written it myself.
It's mostly written to pick up Mastodon users who don't know much about the rest of the Fediverse, so it doesn't really explain how Hubzilla relates to Lemmy. I hope it helps anyway.
SorteKanin
in reply to Jupiter Rowland • • •Rooki
in reply to matcha_addict • • •intensely_human
in reply to matcha_addict • • •My potential argument against it starts with asking where the credentials are stored for authenticating this identity.
Currently the home instance stores the hashed password and performs authentication.
In a way, the identity “belongs to” the place that does authentication, which now happens to be the instance.
If identity is decoupled from an instance, that means authentication decouples from an instance.
If the identity “belongs to” the fediverse as a whole, then that means the fediverse as a whole has an authentication mechanism.
Unless we can come up with a distributed authentication mechanism, that means the fediverse as a whole has some authentication service, as in one, which means centralized.
This therefore breaks decentralization, unless the authentication is somehow handled in a distributed way. Maybe consensus or something on a hashed password? But if those hashed passwords are stored in a distributed manner, then you’d need a super long password to prevent rainbow table attacks on the passwords
... show moreMy potential argument against it starts with asking where the credentials are stored for authenticating this identity.
Currently the home instance stores the hashed password and performs authentication.
In a way, the identity “belongs to” the place that does authentication, which now happens to be the instance.
If identity is decoupled from an instance, that means authentication decouples from an instance.
If the identity “belongs to” the fediverse as a whole, then that means the fediverse as a whole has an authentication mechanism.
Unless we can come up with a distributed authentication mechanism, that means the fediverse as a whole has some authentication service, as in one, which means centralized.
This therefore breaks decentralization, unless the authentication is somehow handled in a distributed way. Maybe consensus or something on a hashed password? But if those hashed passwords are stored in a distributed manner, then you’d need a super long password to prevent rainbow table attacks on the passwords, given the hashed values would essentially be public information.
Maybe public keys are stored in a blockchain? I don’t know this is beyond me in the details.
But to summarize the problem at a data model level, an identity belongs to an instance, because the instance can authenticate them. If the identity now belongs to the whole fediverse, then the whole fediverse needs to be able to authenticate them, which if not handled correctly could lead to centralized authentication, centralized banning, censorship, reddit, etc.
Maestro
in reply to intensely_human • • •hark
in reply to Maestro • • •Maestro
in reply to hark • • •intensely_human
in reply to Maestro • • •Then the identity still has a home.
I’ve implemented Oauth and you still have an identity provider.
SorteKanin
in reply to matcha_addict • • •I don't understand the benefits.
They already don't need to worry about that. Presumably if you could log in with your Lemmy user on Mastodon, your user domain would still refer to your Lemmy instance, just as it does currently. That's besides the fact that I have no idea how this mechanism of logging into different sites would even work.
They can already do that with the current mechanism. It's only a problem with Lemmy not supporting various other forms of social media concepts that prevents you from writing, say, a toot (microblog).
It sounds like what you want is just a more generic ActivityPub instance that supports more forms of social constructs.
Aside from all that, there's what other people have mentioned. Grouping users on instances has all kinds of moderation benefits.
LarmyOfLone
in reply to matcha_addict • • •patrick
in reply to matcha_addict • • •Your last sentence is unclear, is that actually implemented?
I am trying the approach of just making multiple affiliated services, and forcing people to have consistent account names across each. See bestiver.se
Jupiter Rowland
in reply to matcha_addict • • •Separating identity from instance was invented in 2011, first implemented in 2012, and it has been stable since 2013. Zot protocol, Red, Red Matrix, nowadays known as Hubzilla. It is called nomadic identity.
Separating identity from platform is a current WIP: Nomadic identity is to be introduced to ActivityPub and then made project-agnostic. The idea is to be able to clone your Lemmy account to Mastodon and Pixelfed and Mobilizon and Hubzilla and Funkwhale all the same. You won't be able to use all features of everywhere everywhere (go ahead, try to edit a Hubzilla wiki or article or webpage on Lemmy, haha), but it'll be the same identity. Still, it would require one account on each server on which you have an instance of your identity.
But what you're talking about is full, unlimited user write access to over tens of thousands of instances of over 100 projec
... show moreSeparating identity from instance was invented in 2011, first implemented in 2012, and it has been stable since 2013. Zot protocol, Red, Red Matrix, nowadays known as Hubzilla. It is called nomadic identity.
Separating identity from platform is a current WIP: Nomadic identity is to be introduced to ActivityPub and then made project-agnostic. The idea is to be able to clone your Lemmy account to Mastodon and Pixelfed and Mobilizon and Hubzilla and Funkwhale all the same. You won't be able to use all features of everywhere everywhere (go ahead, try to edit a Hubzilla wiki or article or webpage on Lemmy, haha), but it'll be the same identity. Still, it would require one account on each server on which you have an instance of your identity.
But what you're talking about is full, unlimited user write access to over tens of thousands of instances of over 100 projects. Like, visiting any one of these tens of thousands of servers and being able to do absolutely everything a locally registered user can do, no exceptions, right away.
Like it or not, but this will require a local account. Even OpenWebAuth doesn't grant you full local user write access, nor does it allow for drive-by, on-the-spot creation of full-blown local user accounts on any instance, regardless of registration of local user accounts is allowed or not. Like, you can't just visit hub.netzgemeinde.eu and, within a split-second, have a local user account with the same login credentials as on lemy.lol and a nomadic clone of matcha_addict@lemy.lol so it's the exact self-same Fediverse identity on Lemmy and Hubzilla.
So it's either this. Immediate drive-by nomadic cloning of your logged-in Fediverse to any instance that you visit for the first time.
Or every Fediverse user must have a user account on every instance of every project out there, and their Fediverse identity must be nomadic everywhere and cloned to everywhere all the same.
Like, you register an account on lemy.lol. Simultaneously, the same account with the self-same credentials will be created on all other Fediverse instances out there. Immediately afterwards, whatever will contain your identity on Lemmy will automatically be cloned to all these other instances of everything. That way, you can immediately use all instances of all projects of the Fediverse just the same.
Or the Fediverse has only one central login server which controls the credentials for all instances of everything out there. You don't register with lemy.lol, you register with this central behemoth. And all tens of thousands of Fediverse instances connect to this central server for login credentials. And, again, your identity with all your data will have to be cloned and mirrored all across the Fediverse.
By the way, I've cloned Hubzilla and (streams) channels before. One channel from one server to one other server. This can take multiple minutes even with not so much content. Guess how long it'll take to clone one identity container from one Lemmy instance to 20,000++ other instances out there.
SorteKanin
Unknown parent • • •Yea in theory you wouldn't need the password if you have the private key but here the key is only used for signing, maybe not for login. If it also needs to be backwards compatible. In any case, I don't think user-held private keys is viable.
Sharing with trusted parties... I dunno, I think again it's too technical and complicated to do it. And you'd need people on the platform you trust to already be there.
SorteKanin
Unknown parent • • •Normal non-technical people are never going to do this. It needs to be easy as clicking a button, otherwise it will never happen for them. Again, this is a neat technical solution but it completely forgets the human.