"ActivityPub not suitable for implementation as the base federation layer in diaspora" : fediverse

[–] sab@kbin.social 43 points 1 year ago* (last edited 1 year ago) (3 children)

Well, one thought is that this blog post is from January 2019, and that a lot has changed since then. Among them is that a lot of different ActivityPub implementations have become a lot more mainstream than Diaspora.

The author's stance might of course not have changed, but it seems to me this post is a bit too outdated to enter into a current discussion. Interoperability between ActivityPub services is working fine, at least in my opinion.

[–] p03locke@lemmy.dbzer0.com 8 points 1 year ago

The article's age invalidates any other discussion, IMO. Far far too much has changed, including all of the new implementations, and it needs another good re-assessment.

[–] warmaster@lemmy.world 4 points 1 year ago

I wonder what would he think of the Nostr.

[–] cerevant@lemmy.world 36 points 1 year ago (2 children)

I'm not sure ActivityPub is suitable for implementation of Lemmy/Kbin. ActivityPub seems to be a push (with retry) protocol, where if a message gets lost, the protocol doesn't seem to have a means to recover synchronization. Theoretically, instances could verify synchronization on a periodic basis, but that would be a massive increase in traffic.

[–] lackthought@lemmy.sdf.org 6 points 1 year ago (1 children)

I haven't looked at the specs but it is similar to UDP vs TCP?

[–] cerevant@lemmy.world 8 points 1 year ago (2 children)

Kind of. My observed behavior of Lemmy, combined with comments from some developers (I haven't read the code):

Post goes up on community hosted on instance A, Message goes out to B and C: "here's a new post"

User x@B comments on post. Message goes from B to A saying "here's a new comment". A adds the comment, then sends a message to C "here's a new comment"

User y@C upvotes the comment. Message goes from C to A, then A sends a message to C.

Each of those messages are confirmed by the recipient, and there are timed retries. However, there have been plenty of cases where one of those messages get lost, and the communities get out of sync. As I understand it, the message traffic is only changes. They don't talk to each other to see what the current state of the content is. So whenever a sync break happens, it is permanent. New content/changes are fine, but stuff that gets lost in transit is lost for good.

[–] lackthought@lemmy.sdf.org 5 points 1 year ago

that makes sense

federation between kbin.social and my instance lemmy.sdf.org seems to be awful and I couldn't tell where the breakdown was occurring because the issue is intermittent/partial federation

I'm not a web developer so I can't really say what solutions are best, but I have faith there are people smarter than me working on robust solutions

[–] redcalcium@c.calciumlabs.com 4 points 1 year ago (1 children)

At least for Lemmy, you can "force" it to sync a particular post or comment by pasting the url into your instance's search bar.

[–] cerevant@lemmy.world 3 points 1 year ago

Interesting - TIL. I wonder how Lemmy resolves the post #, since it is different between instances, and if it re-syncs comments when you do that. The post # thing is annoying, btw, because it makes it impossible to use relative links in posts/comments.

[–] Swedneck@discuss.tchncs.de 5 points 1 year ago

Agreed, matrix seems like a far more sensible protocol for federated forums.

[–] sciawp@lemm.ee 27 points 1 year ago (1 children)

This was a good read and it’s something I’ve wondered about. The fediverse is sorta built on this promise that everyone will be able to interact across any implementation of ActivityPub.

But that’s not really true. The different types of social media have wildly different implementations, where we have to rely on developers communicating and cooperating with other implementations for everything to work even a little bit

[–] kenbw2@lemmy.world 23 points 1 year ago (5 children)

Yea probably similar to how Lemmy and Kbin are theoretically compatible. ActivityPub doesn't guarantee that, it's only because they happen to use ActivityPub in the same way. If one of them changes their implementation, compatibility breaks.

I do often wonder how much it matters that all these platforms use ActivityPub

[–] sciawp@lemm.ee 16 points 1 year ago (2 children)

I think it might be good to create specific protocols in the ActivityPub documentation for the various types of social media to ensure interoperability.

No hard rules, but a guideline for how to ensure you are maximizing compatibility, maybe.

[–] r00ty@kbin.life 6 points 1 year ago

There at least needs to be some extensions. I'm thinking of methods of secure migration (both instance: domain to domain and user: instance to instance) and a method for adopting a community that existed on a now offline instance.

[–] Aidan@lemm.ee 4 points 1 year ago

In about a year we’ll probably have that anyway. Practices like that will emerge as people get more experience running fediverse servers, and then they’ll get adopted by people trying to do what’s known to work

[–] Blaze@iusearchlinux.fyi 9 points 1 year ago (1 children)

If one of them changes their implementation, compatibility breaks.

And that's why you want a healthy spread of users across both (and even a third one, one day) platforms. That way they have to keep compatibility with each other to not lose a major share of the userbase

[–] sab@kbin.social 4 points 1 year ago

You'd also break compatibility with the previous version of your software, so your users wouldn't be able to see any threads posted on any server that wasn't updated.

If you had a really good reason to make this change, chances are this reason would apply to both services and they would move together. If either developer does it out of spite, nobody is going to upgrade their instance and the project would be forked.

And if they were the type to break ActivityPub integration of their service out of spite, why would they use it in the first place? It just makes no sense. I'm not particularly worried.

[–] ChoppyPorkupine@kbin.social 7 points 1 year ago (1 children)

As a kinda layman, I am still flipping between kbin and lemmy(.world) alot, kbin also because it has no released mobile app (yet), and I just read a post complaining that kbin is missing a lot of content from lemmy, so there is definitely still "federation issues" there

[–] CMLVI@kbin.social 5 points 1 year ago

From what I understand, stuff from lemmy won't pop up in the All feed until someone subscribes to that sub from lemmy. It won't just pull every post from lemmy on its own, it has to be requested. That isn't a federation an issue, but an interest issue.

[–] cerevant@lemmy.world 5 points 1 year ago

A better analogy is how Lemmy and Mastodon are theoretically compatible. Yeah, you can get federated content, but it really isn't usable.

Kbin is just a different implementation of Lemmy, intended to be compatible (not coincidentally compatible through the protocol).

[–] mrmanager 4 points 1 year ago* (last edited 1 year ago)

It doesn't really matter what they use. As long as it's open source and decentralized, avoiding big tech running the servers, it's a huge win.

There is no peaceful existence with big tech when it comes to this. They will turn it into ads and tracking and that's not compatible with the moral values of the open source community.

It's Microsoft culture vs Linux culture.

[–] some_guy@kbin.social 16 points 1 year ago (1 children)

Just off the top of my head, my initial reaction is that it really seems like activitypub is just not suitable for implementation as the base layer in diaspora.

[–] sarsaparilyptus@discuss.online 7 points 1 year ago

Or at least it wasn't four years ago

[–] etrotta@kbin.social 15 points 1 year ago

Their arguments still hold up pretty well as far as I can tell. If anything "improved" since then, you could argue that what the biggest platforms decided to use (Mastodon, Lemmy) became the de-facto dialect in use, but you still have to explicitly refer to how certain projects do things if you want to implement ActivityPub, which can be pretty demotivating for developers, and doesn't makes the user experience any better.

...and nothing prevents new apps such as Threads from using ActivityPub differently, being incompatible with existing apps and further dividing the space

[–] Sanctus@lemmy.world 3 points 1 year ago (1 children)

I might have to look at ActivityPub after this. I mean I saw framework mentioned enough where it sounds like we should have built something using ActivityPub as a framework to ensure compatibility in the fediverse. Or am I reading that wrong? Very interesting article. I would expect we all need to get comfortable with changing and questioning things if we want to build something truly decentralized and truly connected.

[–] Perhyte@lemmy.world 10 points 1 year ago

We did build stuff on ActivityPub: Lemmy, Kbin, Mastodon etc. are all based on that underlying protocol.

[–] blazera@kbin.social 2 points 1 year ago (2 children)

Theres definitely been an awful record of interoperability that ive experienced

[–] sab@kbin.social 6 points 1 year ago (2 children)

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?

[–] effingjoe@kbin.social 3 points 1 year ago (1 children)

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.

[–] sab@kbin.social 2 points 1 year ago (1 children)

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.

[–] effingjoe@kbin.social 4 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] sab@kbin.social 1 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] effingjoe@kbin.social 2 points 1 year ago (1 children)

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".

[–] e569668@fedia.io 1 points 1 year ago (1 children)

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.

[–] effingjoe@kbin.social 1 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] e569668@fedia.io 1 points 1 year ago* (last edited 1 year ago)

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.

[–] blazera@kbin.social 2 points 1 year ago (1 children)

posts from smaller communities on other instances not showing up for me

[–] Coelacanth@feddit.nu 3 points 1 year ago (2 children)

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.

[–] blazera@kbin.social 1 points 1 year ago (1 children)

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

[–] Coelacanth@feddit.nu 1 points 1 year ago

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.

[–] Kaldo@kbin.social 1 points 1 year ago* (last edited 1 year ago)

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).

[–] r00ty@kbin.life 1 points 1 year ago

This is going to be true of any open standard used by multiple vendors. As all the software matures this will be less of an issue. I think in terms of adoption it's still early days yet.

Fediverse

Rules