Skip to main content


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?

in reply to matcha_addict

IMO, if you choose a common username (except for alt accounts) for all your platforms (in my case, dch82) it's fairly easy to find all the accounts. If you want to, you can also link your other platforms in the bio.
in reply to dch82

If you choose a username, and I sign up with your same username before you do, then now you're screwed. So I agree this is a solution, but it is not without faults. No one prevents someone from signing up with your username (either maliciously or they just liked the same name)
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

This entry was edited (1 month ago)
in reply to MartianSands

That's fine. I may be matcha_addict@lemy.lol someone else might be matcha_addict@someOtherInstance.com, but I am the only matcha_addict@lemy.lol and anytime someone sees that full ID, they know for a fact it's me. But if they see matcha_addict@mastodon.social, they cannot know for sure.
in reply to dch82

You can also setup a little linktree page and just have all your profiles link to that so you don't have to update 10000 links on every profile.
in reply to matcha_addict

AFAIK you can already sign into pixelfed with your mastodon account. It is a good idea, I think the only problem would be you would be completely reliant on Instance and if that goes down everything is gone
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

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.

in reply to rglullis

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.

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?

in reply to rglullis

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).
in reply to 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?

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.

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.

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.

This entry was edited (1 month ago)
in reply to rglullis

The vast majority of people who use lemmy have not read the activitypub protocol, and signed up to use lemmy as it exists today
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.

in reply to matcha_addict

Why does it actually matter? If you're that important, you should have your own domain and instance
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

This entry was edited (1 month ago)
in reply to matcha_addict

AFAIK, the only practical thing in the way of having a separate server that just hosts identity accounts for all types of fediverse content (while the content itself is hosted on other servers) is that your host server is responsible for presenting the interface through which you view the rest of the fediverse, and the interfaces are specialized for a particular content type. You could have a server running a variety of fediverse software (mastodon, lemmy, etc.) which automatically generates similar accounts for each user on each service, so users could sign up once and then switch interfaces; but I think the rest of the fediverse would still treat them as separate identities.
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.

in reply to Rooki

PGP signing is cool but it does not grant the benefits I was talking about unfortunately :(
in reply to matcha_addict

Yeah what you are directly talking is some sort of SSO login for each software.
in reply to matcha_addict

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”
in reply to matcha_addict

I would think that it’s naturally an opt-in feature and therefore essentially fine with only a practical upside.
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?

in reply to Rednax

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.

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.

This entry was edited (1 month ago)
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.

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.

in reply to matcha_addict

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.
in reply to Ada

This white listing will not impact regular federation, so smaller communities will still get the same benefit they get now. They will only not get identity (for logins) federation until they gain trustworthiness
in reply to matcha_addict

What do you mean by "federates identities with"? I mean users are already federated, you can see my profile on your own instance. What is the mechanism you're talking about?
in reply to Ada

Maybe failover identities that consume the primary identity’s activities as a log. The failover identity (let’s call them jump clones for fun eh?) can be stood up as primary if the primary goes down (gets banned, instance dies, etc)
in reply to Ada

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.

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.

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.

in reply to SorteKanin

Why would you need a password if you already have a private key?

Also, one possible way to manage private keys is to split the key (and the risk/burden) using shamir's secret sharing and use that process for key recovery if you ever lose it. For example you split it among 6 people you trust and to recover the key, 4 of them need to give you a fragment of it.

en.m.wikipedia.org/wiki/Shamir…

in reply to Omniraptor

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.

in reply to SorteKanin

No, the key fragment is just a bit of text you can send to them by whatever secure side channel you want down to handing them a flash drive. Then when you need to recover the key you ask for it back
in reply to Omniraptor

a bit of text you can send to them by whatever secure side channel you want down to handing them a flash drive


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.

in reply to Ada

in reply to Jupiter Rowland

Yep, it was one of his posts referring to implementing his existing approach to AP that I was thinking off!
in reply to Ada

in reply to matcha_addict

Fediverse reshared this.

in reply to Nate

I don't think a nomadic identity is the same as an instance-less identity. I could definitely see users migrating from one instance to another but that's very different from a user not being associated with any particular instance at any given time, which is what I think the OP is suggesting.
in reply to SorteKanin

I know above he mentioned creating an account and then using it on anther platform like creating one on lemmy and then using it with something like Mastodon or Writefreely. If that was all he was asking about then Nomadic Identities would make that possible, though yeah if I just misinterpreted what he asked and we're talking completely disassociated (private key only instead of Zot's private key underneath a domain based username) then yeah nomadic identities wouldn't be quite what he was looking for.

Fediverse reshared this.

in reply to SorteKanin

in reply to Jupiter Rowland

How does Hubzilla work? I haven't really heard much about it, just heard the name.
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.

in reply to Jupiter Rowland

Seems very technically oriented haha. But sounds like a cool project.
in reply to matcha_addict

in reply to intensely_human

That's a solved problem from a technical perspective. Use OAuth. Just look at "sign in with google/facebook/github/etc"
in reply to Maestro

Who is the OAuth provider in this case? The instance you sign up on? That's already the case.
in reply to hark

Yes, the instance you signed up on would be the identity provider
in reply to Maestro

Then the identity still has a home.

I’ve implemented Oauth and you still have an identity provider.

in reply to matcha_addict

I don't understand the benefits.

users don’t have to scratch their head on if I am the same person or not across these platforms


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.

theoretically, someone following my feed can get updates on what I do on multiple platforms


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.

This entry was edited (1 month ago)
in reply to matcha_addict

So if every users would spin up their own instance or "email server" like "me@matcha_addict.com", could that actually work? Or would that break the activity pub protocol with too many instances?
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

in reply to matcha_addict