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.

@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

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