I made a blog post on my biggest issue in Lemmy and the proposed solutions for it. Any thoughts on this would be appreciated.
I made a blog post on my biggest issue in Lemmy and the proposed solutions for it. Any thoughts on this would be appreciated.
That’s exactly what the third proposal in the article would do. See the proposal its based on for more detail.
Removed by mod
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.
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.
Every fediverse platform already supports following
Actor
s. That’s part of the spec. Handling follows for groups is just as easy as for users.Removed by mod
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 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.
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.
Removed by mod