I think the link blog post author’s point isn’t that there can’t be interoperability, only that there’s no standard for that. You have to seek out each implementation and ensure that your implementation interoperates with theirs, on a case by case basis for every implementation.
Which is of course true - if you want to develop an activitypub service that works with the fediverse at large, you’ll have to look around and see how it could integrate with other services.
The dilemma of boosts vs. favourites for upvotes in the threadiverse is a good example. In kbin, boosts used to be preferred: they are used to promote visibility in Mastodon and similar microblogging services, and the counts are spread through the fediverse to a greater degree than what favourites are. On the other hand, people are more trigger-happy dealing out favourites, it matches the intent of an upvote, and, importantly, it fits the implementation that was already in place over at Lemmy.
In theory, downvotes could be matched with a specific emoji response in Firefish and other services that support the technology. They don’t however, and I’m not sure anyone would really want them to either.
While these questions and challenges exist for the developers of Fediverse platforms, it just doesn’t seem to be much of a problem. There are several ways of doing things, and sometimes you might not even want a feature to be interoperable. Last time I checked downvotes in kbin are not federated at all, by design. Lemmy users cannot boost content at all as far as I’m aware, and it’s not holding them back. Developers are completely capable of looking to past implementations and make informed decisions about interoperability in whatever way they see best fit. You don’t have to look to every implementation - you might just be interested in text and favourites, in which case you can feel pretty comfortable using the same implementation as Mastodon (or anyone else).
It’s like David Hume’s point about norms and the state of nature. At some point everyone will begin driving on the same side of the road even without some authority enforcing it, just because it benefits everyone.
Maybe this wasn’t clear in 2019, but in 2023 I’m communicating with people on kbin without having any idea which of many ActivityPub implementation the person on the other end is using.
Last time I checked downvotes in kbin are not federated at all, by design. Lemmy users cannot boost content at all as far as I’m aware, and it’s not holding them back. Developers are completely capable of looking to past implementations and make informed decisions about interoperability in whatever way they see best fit
As I understand it, this is the exact complaint from the blog post. This is great for devs; it’s not great for users. I am referencing this part:
Putting the ActivityPub logo on a project’s website and writing “we support ActivityPub” announcement posts makes technically versed people very happy, and people supporting open standards will read them with shining eyes. However, there is a secondary effect: these announcements carry over something to non-technical users as well. It tells users that this piece of software is compatible with other pieces of software that carry the same logo. But it is not. In another recent discussion, when someone asked me why diaspora* does not support ActivityPub yet, I claimed the project has two options here, which has a direct impact to how we can explain the compatibility with users on other networks:
Sorry, Alice, Bob is using software that is not compatible with us, so you can’t communicate with Bob here.
Yes, you can communicate with Bob, but since he is using ExampleNet, please be aware that Bob will not receive your photo albums and will be unable to interact with those. Carol will see your photos, though, but unfortunately, she will not be able to see your geo-location updates. Moreover, because of technical limitations, Dan can comment on your posts, but we cannot make sure that Carol and Bob see those, because we cannot redistribute Dan’s comments.
I, perhaps foolishly, assumed that ActivityPub was more structured than it actually is. Though, to be fair, as you point out, this is an older blog post, so there’s some chance that things have improved on that front-- I admit I’m no expert on ActivityPub-- but notably, “there are only a few different implementations, so it’s easy to dig around and make your new implementation compatible” isn’t an improvement. It doesn’t scale. It’s practically begging for the now infamous EEE to happen to it, because whatever is the most popular implementation sort of becomes the standard.
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. A good example how things work out alright is seen in posts from kbin and (I assume) Lemmy over at Mastodon: They show up with their headlines, hashtags and some text and pictures, but as the format is too rich for the platform they also contain a simple link to the post. That way that nothing is lost, and Alice can sleep well at night.
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.
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”.
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.
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”; this was changed since the linked comment was made)
Or am I totally missing something? That’s always and option.
He did say it would be “federated this week” but in the next comment in that issue 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.
The problem is most likely that those communities aren’t connected to Kbin yet. Content doesn’t get federated automatically, a community only starts sending updates to your instance after the first person from your instance subscribes to that community. What is most likely the case is that nobody from Kbin has subscribed to those communities yet.
This is not to say this is the only issue, we’ve certainly seen some federation issues the past month, but they do seem to have gotten markedly better after the last round of backend updates.
That’s fair, it wasn’t clear to me that you meant communities you were already subscribed to, as opposed to them appearing empty when you first search them up on Kbin.
Nah, the servers are just failing sometimes. I’ve made comparisons between same threads on both kbin and lemmy instances and almost every time they’d miss some comment (chains) completely and it had nothing to do with defederation or blocking. Syncs just fail or are incomplete, missing up to 40% of comments in some threads. Maybe it’s improved now if the traffic stabilized but it seems to me like the foundation is still very unreliable and prone to failures, and the devs didn’t implement any backup plans for it (like later reattempts at resyncing or sth).
What is your experience?
Your very comment is an example of interoperability working well between kbin and Lemmy, so one would think it cannot be that bad?
I think the link blog post author’s point isn’t that there can’t be interoperability, only that there’s no standard for that. You have to seek out each implementation and ensure that your implementation interoperates with theirs, on a case by case basis for every implementation.
Which is of course true - if you want to develop an activitypub service that works with the fediverse at large, you’ll have to look around and see how it could integrate with other services.
The dilemma of boosts vs. favourites for upvotes in the threadiverse is a good example. In kbin, boosts used to be preferred: they are used to promote visibility in Mastodon and similar microblogging services, and the counts are spread through the fediverse to a greater degree than what favourites are. On the other hand, people are more trigger-happy dealing out favourites, it matches the intent of an upvote, and, importantly, it fits the implementation that was already in place over at Lemmy.
In theory, downvotes could be matched with a specific emoji response in Firefish and other services that support the technology. They don’t however, and I’m not sure anyone would really want them to either.
While these questions and challenges exist for the developers of Fediverse platforms, it just doesn’t seem to be much of a problem. There are several ways of doing things, and sometimes you might not even want a feature to be interoperable. Last time I checked downvotes in kbin are not federated at all, by design. Lemmy users cannot boost content at all as far as I’m aware, and it’s not holding them back. Developers are completely capable of looking to past implementations and make informed decisions about interoperability in whatever way they see best fit. You don’t have to look to every implementation - you might just be interested in text and favourites, in which case you can feel pretty comfortable using the same implementation as Mastodon (or anyone else).
It’s like David Hume’s point about norms and the state of nature. At some point everyone will begin driving on the same side of the road even without some authority enforcing it, just because it benefits everyone.
Maybe this wasn’t clear in 2019, but in 2023 I’m communicating with people on kbin without having any idea which of many ActivityPub implementation the person on the other end is using.
As I understand it, this is the exact complaint from the blog post. This is great for devs; it’s not great for users. I am referencing this part:
I, perhaps foolishly, assumed that ActivityPub was more structured than it actually is. Though, to be fair, as you point out, this is an older blog post, so there’s some chance that things have improved on that front-- I admit I’m no expert on ActivityPub-- but notably, “there are only a few different implementations, so it’s easy to dig around and make your new implementation compatible” isn’t an improvement. It doesn’t scale. It’s practically begging for the now infamous EEE to happen to it, because whatever is the most popular implementation sort of becomes the standard.
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. A good example how things work out alright is seen in posts from kbin and (I assume) Lemmy over at Mastodon: They show up with their headlines, hashtags and some text and pictures, but as the format is too rich for the platform they also contain a simple link to the post. That way that nothing is lost, and Alice can sleep well at night.
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.
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?
Why is this your chosen metric? Wouldn’t “this might make the users confused” be a better metric?
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”.
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.
I appreciate the additional information, however, a link found in the codeberg link you provided leads to this comment from earnest:
This seems to imply that downvotes (reduces) are federated. (And notably, upvotes are now “stars” “boosts” are, uh, “boosts”; this was changed since the linked comment was made)
Or am I totally missing something? That’s always and option.
He did say it would be “federated this week” but in the next comment in that issue 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.
posts from smaller communities on other instances not showing up for me
The problem is most likely that those communities aren’t connected to Kbin yet. Content doesn’t get federated automatically, a community only starts sending updates to your instance after the first person from your instance subscribes to that community. What is most likely the case is that nobody from Kbin has subscribed to those communities yet.
This is not to say this is the only issue, we’ve certainly seen some federation issues the past month, but they do seem to have gotten markedly better after the last round of backend updates.
why do you think I know their posts aren’t showing up on kbin? I’ve been subscribed, several people have, that’s not what I am talking about
That’s fair, it wasn’t clear to me that you meant communities you were already subscribed to, as opposed to them appearing empty when you first search them up on Kbin.
Nah, the servers are just failing sometimes. I’ve made comparisons between same threads on both kbin and lemmy instances and almost every time they’d miss some comment (chains) completely and it had nothing to do with defederation or blocking. Syncs just fail or are incomplete, missing up to 40% of comments in some threads. Maybe it’s improved now if the traffic stabilized but it seems to me like the foundation is still very unreliable and prone to failures, and the devs didn’t implement any backup plans for it (like later reattempts at resyncing or sth).