That's not true. XMPP can do far more than instant messaging, and it's definitely not complicated (well for a decentralized network and for technical audience of course).
For the record I'm the main developer of a XMPP based "social network" project (Salut à Toi), and we are able to communicate natively with others XMPP projects (e.g. Movim) for years (we can share comments like in the video, it's the basis of common standard).
The "many extensions" thing is commonly misunderstood by non XMPP people thinking that it's making software more complicated or hard to maintain. But it's not true: extensions is a strength of XMPP allowing to concentrate on one feature at a time, evolve it, change it if needed, and there is a very good negotiation mechanism. Software are evolving, and it's normal that different clients/servers have different feature, but even with that they can still communicate together.
The case is common actually: the websites on your browser can test for implemented features in javascript for instance before activating this or that.
XMPP is not a single technology but a base to support many coherent technologies, for many different use cases.
To go back to this ActivityPub, while I'm a bit annoyed that nobody tried to contact us to join our efforts on XMPP, resulting in yet another standard, at least if it's followed by some platforms, it may simplify the creation of gateways. I've looked at the specs, I don't think that putting "like", and "followers" as the main feature of a social network is a good idea. At first sight, it doesn't seem too difficult to translate to XMPP.
The problem I've always had with XMPP is that any time I try to do something
with it, I get lost in an endless sea of RFCs with no idea of which are
important for my use-case (most RFC titles seem fairly jargon-heavy to me).
Then, when I go to read an actual RFC, because of the fact that each RFC has
some interactions with all other RFCs, they're fairly impenetrable. Is there a
document somewhere collecting the most essential XMPP stuff you need to be aware
for different applications (e.g. chat client, XMPP server, XMPP social network
client, bridge between XMPP and other protocols, etc.) and presenting it in a
concise way that doesn't require navigating a vast sea of documents? Do you have
some other recommendation for how to get into the XMPP world?
It depends of what you want to do. In most cases, I would recommend using and existing client/library, this would make the things more easy for you (don't have to start from scratch, something already made in your favorite language).
It's progressively more functional as you implement each of the two RFCs. If you implement the first (6120: Core) you'll be able to process XML streams. The second brings IM, a friend list, and presence. You can then implement XEPs as you need them.
If your development workflow uses sprints in any form, the format of XMPP documentation is perfect. If you want to implement everything at once, good luck.
I'd recommend looking at the Compliance Suites which were designed to address this (disclaimer: I've been the author for the last few years, although I just transitioned out of that role):
I know there's a big scary "Rejected" warning at the top, but in this case it's okay to disregard that. It was rejected for bike-sheddy reasons about it not being perfect yet and is still a good starting place. The warning should go away sometime in the next few weeks (the problems that it was rejected for have been addressed, so the next time the council meets it will likely be accepted).
For the record I'm the main developer of a XMPP based "social network" project (Salut à Toi), and we are able to communicate natively with others XMPP projects (e.g. Movim) for years (we can share comments like in the video, it's the basis of common standard).
The "many extensions" thing is commonly misunderstood by non XMPP people thinking that it's making software more complicated or hard to maintain. But it's not true: extensions is a strength of XMPP allowing to concentrate on one feature at a time, evolve it, change it if needed, and there is a very good negotiation mechanism. Software are evolving, and it's normal that different clients/servers have different feature, but even with that they can still communicate together. The case is common actually: the websites on your browser can test for implemented features in javascript for instance before activating this or that.
XMPP is not a single technology but a base to support many coherent technologies, for many different use cases.
To go back to this ActivityPub, while I'm a bit annoyed that nobody tried to contact us to join our efforts on XMPP, resulting in yet another standard, at least if it's followed by some platforms, it may simplify the creation of gateways. I've looked at the specs, I don't think that putting "like", and "followers" as the main feature of a social network is a good idea. At first sight, it doesn't seem too difficult to translate to XMPP.