111
Lemmy Needs to Fix Its Community Separation Problem (popcar.bearblog.dev)
submitted 2 years ago by to c/fediverse@lemmy.world
149 comments fedilink hide all child comments
 

I made a blog post on my biggest issue in Lemmy and the proposed solutions for it. Any thoughts on this would be appreciated.

you are viewing a single comment's thread
view the rest of the comments
[–] 7 points 2 years ago (1 child)

That's exactly what the third proposal in the article would do. See the proposal its based on for more detail.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago (1 child)

    Why couldn't this be solved at the client level? Whenever you go to a thread, the client could check the submission URL and inline comments from matching posts from other subscribed communities.

    Reddit already does that with their "related diacussions" tab. It would be a lot more elegant, requires no extensions in the spec, no changes in the server side and easily prototyped/tested.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 2 years ago (1 child)

    requires no extensions in the spec

    That proposal doesnt require an extension to the spec. It requires a group to follow another group, which is definitively within the ActivityPub spec. The proposal above is written as a FEP (Fediverse Enhancement Proposal) which is the agreed upon way to propose new behavior in an interoperable way.

    no changes in the server side

    But it takes changes on the client side. One is not inherently better than the other. Also, doing it client side means you have to duplicate the work for every client. Doing it server side means it works for everyone.

    easily prototyped/tested

    Every fediverse platform already supports following Actors. That's part of the spec. Handling follows for groups is just as easy as for users.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 2 years ago* (last edited 2 years ago) (1 child)

    Also, doing it client side means you have to duplicate the work for every client.

    Only if you want to force everyone to adopt this behavior. There are tons of people here that are telling you that this is a non-issue to them, why do you think that all clients need that?

    One is not inherently better than the other.

    When it comes to decentralized technologies and systems, it absolutely is better to delegate behavior to the leaf nodes as much as possible. The less things are mandated on the server, the easier it is to build a robust system. Pushing as much functionality as possible to the client is such a good way to follow Postel's Law that is basically second nature to those developing distributed systems.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 2 years ago (1 child)

    Only if you want to force everyone to adopt this behavior

    Did you read the proposal? No one is forcing anyone to do anything. The proposal would allow one community to follow another. Communities don't have to send a follow request and the other community doesn't have to follow back. This works just like users following users/communities. It's all optional.

    There are tons of people here that are telling you that this is a non-issue to them, why do you think that all clients need that?

    There are tons of ppl telling you it is an issue for them. If its not an issue for you, then you lose nothing if this is implemented, but ppl who care have one of their pain points solved.

    it absolutely is better to delegate behavior to the nodes as much as possible... Pushing as much functionality to the client is such a good way to follow Postel’s Law that is basically second nature to those developing distributed systems.

    The nodes are the servers not the clients. Your argument is the exact opposite of what every fediverse developer says. The reason most of the fediverse uses the MastoAPI (or lemmy api for the threadiverse) instead of the ActivityPub Client to Server API is because the C2S expects a more client focused ecosystem but all the developers find it easier to handle logic on the server.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 2 years ago* (last edited 2 years ago)

    The proposal would allow one community to follow another

    Who determines when a community should follow another? The admin? The user?

    If its not an issue for you, then you lose nothing if this is implemented,

    My point is that it a lot easier to implement something that solves the problem that you are describing than asking for a whole change in the implementation of the server.

    The nodes are the servers not the clients. (...) The reason most of the fediverse uses the MastoAPI (...) is because the C2S expects a more client focused ecosystem but all the developers find it easier to handle logic on the server.

    It's a trade-off between speed to deliver the base case vs the lack of flexibility to deliver a more flexible version of it. And the more that we push to the server, the slower it will be to be able to extend it. Case in point: People have been complaining about the lack of algoritmic timelines on Mastodon. The Mastodon developers will find all sorts of excuses to not have to implement it... "Algorithms are bad for people", "People are just too used with how things in Big Tech", "we rather working on moderation and safety"... etc. All of those are bad rationalizations for them to avoid doing work they don't want to do. Which is fine, the devs are not forced to develop anything. The interesting things is that this problem was solved a lot faster by flipping it around and pushing to the client. And it works so well that that people now can even choose what type of algorithm they want to run.

    Your argument is the exact opposite of what every fediverse developer says.

    Not every developer.

  • permalink
  • fedilink
  • source
  • parent