Here's the "final" comment on #ActivityPub by the informal spokesperson on inter-operationg from the #Diaspora project:
https://schub.io/blog/2019/01/13/activitypub-final-thoughts-one-year-later.html
ActivityPub - Final thoughts, one year later. - Dennis Schubert

Random thoughts, articles and projects by Dennis Schubert.

I agree with two points Dennis Schubert of Diaspora raises here;
* we must design with end users in mind. Smooth #UX is key if we ever want federated social networking to win in our revolution against centralized #DataFarms
* work on public standards needs to happen at public standards bodies. Specifying a standard for inter-operation protocols is pointless if every implementer has to talk to every other implementer to get things to work properly.
However, his comparison with #XMPP is mind-blogging. Yes, the #XMPPFoundation has developed a good process for formalizing extensions to the base standard (#XEPs). Yes, this is something #ActivityPub folks could learn from. But the XMPP spec was first published in 2004. The final AP 1.0 standard was only published last year, give it time!
Also, despite it's robust XEP processes, XMPP has a *terrible* #UX when it comes to inter-operation across services. The only basic chat function that works reliably across all XMPP implementations is realtime text chat (not file-sharing, or voice/ video, or screen-sharing or numerous other functions modern chat users consider essential).
In that respect, it's an example for AP folks of how *not* to run a federation of federated networks.
One thing I think Dennis really underestimates though, is the important of #NetworkEffect to the #UX of federated social apps. The most important way for a network comms technology to serve its users is to help them to communicate with as many others as possible. This is especially true in #SocialMedia, when the user's goal is to publish a message they consider important, to as many people as they can. But it's still important in #SocialNetworks, when users want to find their friends.
Implementing #ActivityPub in some form, would allow Diaspora users to connect with about 3 times as many users as they can using only the Diaspora protocol standard. That's with a number of apps/ instances not yet rolling out AP support that's in the works. Regardless of how good the Diaspora UI might be for existing users, denying them such a massively increased network reach is poor #UX design.
Implementing AP on Diaspora, in the right from, would also allow Diaspora users to comment on #WordPress blogs that use AP plug-ins like #Pterotype. So that's a whole different set of users Diaspora users are being denied the ability to interact with:
https://getpterotype.com/
Pterotype

Welcome to the Fediverse

Pterotype
@strypey Offline text messaging works if one interacts through servers and clients that support the most recent compliance suites (2018: XEP-0387, https://jmp.chat/suggested_servers.html ), and optionally XEP-0077 In-Band Registration ( https://xmpp.org/extensions/xep-0077.html ) to ease users registration without requiring a web browser. To see a short list with such providers, see https://jmp.chat/suggested_servers.html (last paragraph links to more details. Also comment or share this: https://libreplanet.org/wiki/XMPP
JMP - Suggested XMPP Servers

@adfeno @strypey

The reason I stopped using XMPP last year is that the offline text messaging was acting up on my Prosody server. Also I would like to get message delivery confirmations. I didn't find the solution to implement that.
@neoncipher @strypey #Prosody doesn't need to support XEP-0184, only clients do, see https://prosody.im/doc/xeplist .
XMPP Extensions (XEPs) supported in Prosody – Prosody IM