This is how the XMPP protocol as been designed.
It is very powerful and most of all extensible, most likely thanks to the use of XML.
If something is not in the protocol, you can add it for your own need.
The problem with XMPPs pubsub is that they don't have a clever multicast strategy. All they it does unicast, twitter something to your 200 friends @ example.com? 200 unicast messages to example.com. (See http://www.xmpp.org/extensions/xep-0060.html 1.2.)
That's not true.
We have implemented multicast during the Google summer of Code (See for example of the related patch: https://support.process-one.net/browse/EJAB-329).
It being test and optimised but works today if you apply the patch. It will be in ejabberd 2.1.
It is implemented in the server for multiple things, including pubsub and multi-user chat.
That's an improvement, however, after looking at it I must say that that's not multicast. This is multiple recipients for a message.
You shouldn't need to address the recipients, presence already involves people subscribing to your "presence channel". Thus your homeserver should know how to distribute the efficiently - for example by multicast. XEP-0033 just adds redundancy.
Multicast only works on either something as esoteric as the MBONE or on a local LAN/WAN. It isn't out there on the general internet, it requires too much state in the routers, so it never took off.
The original comment was not on transport level multicast, but on application level multicast. This is the one implement in ejabberd patches and thus works over Internet, not only LAN/WAN.
Transport-level mcast requires special routers..
Ah! No wonder I couldn't get the MBone videoconferencing stuff to work with Trumpet Winsock, years ago
The server knows how to distribute the message to multiple recipient and does that by itself. The client has of course nothing to do.
ejabberd does that automatically for presence, but also for Multi-user chat and pubsub.
