Comment

Comment on "ActivityPub not suitable for implementation as the base federation layer in diaspora"

sab@kbin.social ⁨1⁩ ⁨year⁩ ago

I think it is great for users. Ernest, the developer of kbin, actively wanted not to federate downvotes because he thought it would be better for the user experience. It is of course open for debate, but it's a decision made with users in mind, not related to the ease of development.

Of course, there is a dimension if the critique that rings true. If I talk to someone using Firefish they might respond to me using a emoji response, which I will of course not see over at kbin. I just can't think of a devastating real world example.

Regarding EEE, nobody owns the right to any specific implementation. Sure, Threads could use activitypub but use a different logic for favourites than Mastodon does, and they wouldn't be able to communicate favourites with each other. We could imagine the entire fediverse jumping after Meta, desperate to see the hearts added by Threads users. And then... what exactly? The extinguish step is a bit unclear to me.

source

Sort:hotnew top

effingjoe@kbin.social ⁨1⁩ ⁨year⁩ ago

he thought it would be better for the user experience

Is this articulated somewhere because I was under the impression that everything was federated, and this plays right into the point. Why should this be up to the devs? Or, perhaps better worded, what information does the "ActivityPub" label actually tell an end user, right now? Seemingly nothing at all, from a functional standpoint. It's possible for two ActivityPub-labeled implementations to be completely incompatible, right? Does that sound good for users?

I just can't think of a devastating real world example.

Why is this your chosen metric? Wouldn't "this might make the users confused" be a better metric?

The extinguish step is a bit unclear to me.

Once they're the de facto standard they abandon it altogether and the users, who care little about the nuts and bolts of this, get frustrated and make an account on Threads (using your example).

It's worth keeping in mind that we're not talking about normal software. A hypothetical technically perfect solution is still a failure if there isn't a critical mass of users to make it "social".

source
- e569668@fedia.io ⁨1⁩ ⁨year⁩ ago
  There's some relevant discussion here and in the thread linked by ernest in that post here. I don't want to give any wrong information, but I don't think activitypub has a spec for downvotes/reduces/dislikes, just likes and shares (boosting). So on mastodon dislikes definitely aren't federated. I believe for lemmy, they federate between lemmy instances that have them enabled, but for kbin they are local to your instance.
  
  source
  - effingjoe@kbin.social ⁨1⁩ ⁨year⁩ ago
    I appreciate the additional information, however, a link found in the codeberg link you provided leads to this comment from earnest:
    
    The up arrow is the equivalent of a boost on Mastodon, adding to favorites is represented by a star. The down arrow is equivalent to the Dislike button on Lemmy and Friendica, Mastodon probably doesn't have an equivalent (Dislike will be federated this week). Compared to Lemmy, it works a little differently, as the up arrow there is the equivalent of a favorite.
    
    The comment activity can be checked by expanding the "more" menu and selecting "activity"
    
    This seems to imply that downvotes (reduces) are federated. (And notably, upvotes are now "stars" "boosts" are, uh, "boosts".
    
    Or am I totally missing something? That's always and option.
    
    source
    e569668@fedia.io ⁨1⁩ ⁨year⁩ ago
    He did say it would be "federated this week" but in the next comment he made he said that changed "but it turns out it's not easy, and I wouldn't want to make such a big change hastily". I don't think anything has happened since. I definitely almost never see any reduces over here on a different kbin, so I think it's still the same. There is still some discussion in that issue, someone just posted they have a PoC of doing it in a fork for instance.
    
    source