In my opinion, there are two big things holding Lemmy back right now:

  1. Lemmy needs DIDs.

    No, not dissociative identity disorder, Decentralized Identities.

    The problem is that signing up on one instance locks you to that instance. If the instance goes down, so does all of your data, history, settings, etc. Sure, you can create multiple accounts, but then it’s up to you to create secure, unique passwords for each and manage syncing between them. Nobody will do this for more than two instances.

    Without this, people will be less willing to sign up for instances that they perceive “might not make it”, and flock for the biggest ones, thus removing the benefits of federation.

    This is especially bad for moderators. Currently, external communities that exist locally on defederated instances cannot be moderated by the home-instance accounts. This isn’t a problem of moderation tooling, but it can be (mostly*) solved by having a single identity that can be used on any instance.

    *Banning the account could create the same issue.

  2. Communities need to federate too.

    Just as instances can share their posts in one page, communities should be able to federate with other, similar communities. This would help to solve the problem of fragmentation and better unify the instances.

Obviously there are plenty of bugs and QoL features that could dramatically improve the usage of Lemmy, but these two things are critical to unification across decentralized services.

What do you think?

EDIT: There’s been a lot (much more than I expected) of good discussion here, so thank you all for providing your opinions.

It was pointed out that there are github issues #1 and #2 addressing these points already, so I wanted to put that in the main post.

  • 1- You mean something along the lines of Hubzilla’s nomadic identities? or how?

    Nomadic Identity: The ability to authenticate and easily migrate an identity across independent hubs and web domains. Nomadic identity provides true ownership of an online identity, because the identities of the channels controlled by an account on a hub are not tied to the hub itself. A hub is more like a “host” for channels. With Hubzilla, you don’t have an “account” on a server like you do on typical websites; you own an identity that you can take with you across the grid by using clones. Channels can have clones associated with separate and otherwise unrelated accounts on independent hubs. Communications shared with a channel are synchronized among the channel clones, allowing a channel to send and receive messages and access shared content from multiple hubs. This provides resilience against network and hardware failures, which can be a significant problem for self-hosted or limited-resource web servers. Cloning allows you to completely move a channel from one hub to another, taking your data and connections with you.

    2- This is a good Idea. But I’m not sure how posible it is as of now