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.

  • lightingnerd@kbin.social
    4·
    2 years ago

    I think #1 is a great idea, but it would take a lot of work and would probably be a pain to phase-in and phase-out across all platforms, but I do think it’s a good idea, at least to offer as an option. While I am loathe to mention anything cryptocurrency and NFT-related, creating a simplified distributed ledger and smart contract system that would propagate through federated communities seems like an interesting idea. Alternatively, creating a way for users to specify their other usernames on other servers in a small bio in a profile page could be a possible compromise.

    Your point #2 also sounds great, but I don’t think this should be allowed between communities on defederated instances, because there’s laws in many countries that can classify the act of hosting/providing certain content to be criminal. Therefore, if say if server_a resides in country_a, and country_a allows piracy, and server_b in country_b, and country_b considers it a criminal act to propagate certain information about piracy, the server_a/piracy and server_b/piracy might have different restrictions to discuss piracy. However, a less-informed mod may attempt to federate server_a/piracy and server_b/piracy, and insodoing accidentally make the owner/host of server_a unknowingly complicit in a criminal act.

    I’m not a lawyer, and of course this is not intended to be legal advice, but I think that the effort would better be spent on implementing a solution to the decentralized identity problem, than the de-fragmentation of similar communities.

    One other nugget to consider, assuming we were to replace Reddit, and the sum of the users on the fediverse were to achieve similar numbers to Reddit’s glory days–we would definitely be scraped for AI training data. By keeping the communities fractured, that makes it far more difficult for a company to easily scrape all the information needed. While it might be trivial right now, in the ideally decentralized structure that the fediverse would take, it would take a lot more requests for a server to chase out every strand on every network.

    Perhaps in this sense, it might be wise for instances to allow specific community defederation(ie, where server_a and server_b are federated, but server_a does not allow server_b/piracy to propagate(this may already be possible, IDK), but I do not think it would be wise to allow community to community federation.

    TL;DR: #1 is a great idea, OP, and it could be implemented in a simplified distributed ledger that propagates through federated communities, and uses a simplified smart-contract. But, I am worried that #2 could cause legal problems in specific scenarios, rather I think it is more important for any instance to be able to disallow the propagation of specific communities from a federated server (if this isn’t already possible).