this post was submitted on 22 Jan 2024
4 points (83.3% liked)
Fediverse
28396 readers
188 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to [email protected]!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I just wish threads using the same link and threads that are crossposted shared comments with a link on top of the comment that said the title of the original post.
It sucks when an article is posted to 5 communities and i have to go to each one to read all the comments. I want to read all the comments about the article in one place. If the thread is about something specific and uses the same link I would still understand the context because the comment would include the link/title of the original thread it was posted to.
That's exactly what the third proposal in the article would do. See the proposal its based on for more detail.
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.
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
Actors. That's part of the spec. Handling follows for groups is just as easy as for users.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?
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.
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.
Who determines when a community should follow another? The admin? The user?
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.
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.
Not every developer.