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

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.

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.
I wonder what would he think of the Nostr.
Diaspora is now part of the Fediverse. https://fediverse.party/

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.

I haven't looked at the specs but it is similar to UDP vs TCP?
- 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.
Agreed, matrix seems like a far more sensible protocol for federated forums.

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

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

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

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.

Or at least it wasn't four years ago

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.

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

Theres definitely been an awful record of interoperability that ive experienced

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.
- posts from smaller communities on other instances not showing up for me
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.