Here’s an idea to make Lemmy even better: true account portability.
Right now, your Lemmy account and all your content are tied to one server. Moving instances or having one shut down means losing your digital presence. Frankly, the server controls your online identity.
But what if you controlled your identity?
I’ve opened a discussion on the Lemmy dev GitHub about integrating Decentralized Identifiers (DIDs). Think of a DID as a permanent, global ID you own, independent of any server.
Why DIDs are a game-changer for Lemmy:
- Real Account Portability: Move your entire account – posts, comments, followers – to any new instance seamlessly. Your identity travels with you.
- More User Control: Your online presence becomes resilient, managed by an ID you control, not governed by a single server’s policies.
- Proven Tech: It works. Protocols like ATProto (Bluesky) successfully use DIDs for portable user identities.
- Full Fediverse Compatibility: We can add DIDs to Lemmy while staying fully interoperable with Mastodon, Kbin, and all other ActivityPub platforms. No breaking changes, just a powerful upgrade.
This is a big step towards a more decentralized and user-controlled fediverse. If you’re interested in more control over your digital self, check out the discussion:
[GitHub Issue: https://github.com/LemmyNet/lemmy/issues/5942]
If you’re on other ActivityPub platforms, consider pushing for similar solutions! The more platforms that adopt truly portable identity, the stronger the fediverse becomes.
Somehow, this remembers me of Nostr. How much is this different from Nostr? (insofar an user generates their own pair of public and private keys that they use to publish content anywhere within the Nostr ecossystem, at least it’s as far as I remember about Nostr, as it’s been a long while since I don’t use Nostr anymore after it went down the cryptobro road)
FEP-ef61: Portable Objects describes how to use DIDs with ActivityPub. Here’s a slightly less technical introduction: https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md
It’s not easy, though. Adding this feature to an existing project will require a lot of work, especially if you don’t want to share signing keys with servers. This was discussed in #3100, Lemmy devs are not opposed to FEP-ef61, but they don’t plan to work on it.
Also, I don’t recommend copying solutions from ATProto, their
did:plcanddid:webare not really “decentralized”.As someone with DID (Dissociative Identity Disorder) please pick a different name/acronym
DID as a permanent, global ID you own, independent of any server
So there would have to be another server, hosting my identity? Would identities somehow be federated between identity instances?
Did can be served by your own server as just a json blob or federated between multiple identity servers or on the blockchain. A did is did:source:publickey and their are multiple different sources u can use.
Real Account Portability: Move your entire account – posts, comments, followers – to any new instance seamlessly. Your identity travels with you.
This is nice in theory but comes with edge cases that are hard to account for. Like, what if you have a post and your new instance defeds the instance the post’s community is on? You either have to allow banned content onto the instance or the user loses data, neither of which are acceptable.
This is part of why ATProto’s decoupling of user data from app logic is kinda genius and the direction we should go in if we want portable actors in Lemmy/thredi.
Full Fediverse Compatibility: We can add DIDs to Lemmy while staying fully interoperable with Mastodon, Kbin, and all other ActivityPub platforms. No breaking changes, just a powerful upgrade.
Not really, every fediverse platform that people use expects an
Object’sidto be a https URI it can just fetch the resource from. This is part of why FEP-ef61 specifies a way of translating a DID to a https URI. That’s not to mention that moving existing actors from their current ID to a DID will cause all sorts of interop problems.Edit: Also, is this AI-generated? It has all the tells of Gemini output, especially the the issue on Github.
So we’re filing LLM slop for Lemmy issues now? Also that’s a pretty poor choice for a name.
DIDs are cool and all but I would trash your proposal because that is clearly llm bullshit. Put effort into it, seriously.
Oh and also, for big changes like these, you need to make a new RFC: https://github.com/LemmyNet/rfcs
I did put effort into it I just got an LLM to write it. I’ll see what the devs say and might make an rfc if needed. And yes I’ll get an LLM to write that as well.
This could be easily solved with domain name and certificates
what by having all users exist on a centralised server? That sounds like vendor lock in which is exactly what federation was trying to avoid.
