Hey everyone,

I’ve been thinking about how the Fediverse handles user accounts and logins for a while now, and I had a question.


Right now, users have to create accounts on specific instances on various platforms, which works but can sometimes feel a bit fragmented—especially when someone wants to interact across multiple instances or migrate to a new one.

Would it make more sense for the Fediverse to adopt a login system based on encrypted keys, like how NOSTR operates (or something similar)?

In such a system, users could have a single “universal” private key that serves as their identity across the network.


Here are some potential benefits I see:

  • Single Identity Across Instances: Users wouldn’t need to create multiple accounts for each instance, making it easier to interact across the Fediverse.
  • Seamless Migration: If your home instance shuts down or you switch to another one, your identity and data could remain intact since it’s tied to your key, not the instance.
  • Decentralization Boost: It might make the Fediverse feel even more decentralized, as user identities wouldn’t depend on a specific instance’s infrastructure.
  • Improved Privacy: Keys could also enable stronger controls over data sharing and access at the individual level.

Of course, there are likely challenges to this approach, such as handling lost keys, onboarding non-technical users, or ensuring compatibility with existing protocols.

But it seems like a conversation worth having.

What does the community think?

Are there reasons this wouldn’t work for the Fediverse, or could this idea help address some existing pain points?

Looking forward to hearing your thoughts.


EDIT:

I suggested this over on r/Fediverse and a Redditor gave me this:

https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md

https://microformats.org/wiki/rel-me

So I guess that it is being worked on Fediverse - wise.


https://nostr.com/get-starthtml

https://www.nostr-ruby.com/core/keys.html

  • Blaze (he/him)@feddit.org
    link
    fedilink
    English
    arrow-up
    11
    ·
    11 hours ago

    The Fediverse is already difficult enough to get as it is, add key management to the mix and we’ll be a few hundreds instead of 42000 monthly active users

  • Ada@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    3
    ·
    8 hours ago

    There are upsides and downsides to such an approach.

    We admin several instances for example, because we are trying to create safe spaces for queer folk and want to foster those communities. We pay out of our own pockets to do so.

    I’ve got no interest in running a generic piece of network infrastructure that can be used by bigots just as readily as the people that they harass.

    The people that do want to run that are “free” speech types, which is how you end up with nostr

  • catloaf@lemm.ee
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    10 hours ago

    I don’t see how this proposal makes any changes. Your account is already unique and usable across the fediverse.

    A key used for authentication is really just a long password, anyway.

    If you mean you should be able to log into server A with your account registered on server B, that doesn’t need key auth. Password auth would be fine, it’s just not implemented (at least on Lemmy or any other fediverse platform I’m aware of). Authentication isn’t federated, only content.

  • originalucifer@moist.catsweat.com
    link
    fedilink
    arrow-up
    8
    arrow-down
    1
    ·
    11 hours ago

    account portability is high on the list of needed features, and there have been lots of suggested solutions… that said, i dont think nostr is a shining example of… well, anything.

    lack of moderation is one of the biggest pain points. nostr is a cesspool of trolls

  • Lung@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    10 hours ago

    I guess it doesn’t really work as described. The data that’s valuable is your content history & unique username. There’s no way around having to migrate/store this somewhere, and it shouldn’t have to be replicated by every node. So basically we just need a solution for porting account data from one instance to another securely and accurately