In my opinion, there are two big things holding Lemmy back right now:
-
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.
-
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.
It sounds like a moderation nightmare having people come over to your instance with a whole lot of content they’ve created that are now being hosted by your servers. You’ve got to look through the whole thing to make sure it is not breaking TOS of your instance. Doesn’t sound great to me.
There’s many different ways DID could be implemented on top of ActivityPub. I don’t think full content replication (what you’re mentioning) is likely as that’s a fundamentally different style of protocol.
But I can imagine signing in to a different instance with my ID, at which point I subscribe to all my communities from this instance and get notifications if someone replies to one of my comments etc. Just as if I had created an account on this instance and had posted from there. It just means “your” instance can go down and you can continue future interactions mostly uninterrupted from another instance.
And it’s more useful in the case of microblogging, where with DID you can publish posts from any instance and your followers will see them. No need for a manual account migration or anything.
Oh I see, that could be better. I still don’t think it’s necessary, but it’s better.
I don’t see why the content they’ve created would have to go along with. You could keep the content on the server, but have the posting user be offsite, like posting to another service/community. If the user has moved off your server, just alter the local profile to point to their “new” location.
It would be less overhead than moving the physical posts themselves, especially if things get bigger later on.
The most straightforward way of resolving #1 (for those so inclined to resolve it) is to host your own instance. Your “identity” becomes the right-side of the @ rather than the left.