[Standards-JIG] proto-JEP: Smart Presence Distribution

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Wed May 17 21:59:43 UTC 2006

It would be very pretentious of me to make predictions about XMPP survival
if we do not follow your recommendation to enhance s2s presence broadcast
(i.e. simultaneously send the same message to multiple recipients). So I
would abstain commenting.

Let me just point out that the discussion threads from last February were
related to MUC originally and to PubSub at some points. Not presence.

I have followed this previous discussion without jumping in, because I was
not in agreement with many of its conclusions. Simplifying, in the case of
PubSub, it is common practice to allow inter-broker subscriptions in order
to push the fine grained notifications as near as possible to the
subscribers. That in turn entails using subscription covering to
canonicalize subscriptions between brokers. Doing this over XMPP is not a
matter of changing the protocol, but a matter of PubSub implementation. If
an implementation is designed as a distributed PubSub, the location of the
publication can be anywhere in the brokers network. Each broker is the
multicast group you are looking for, and the existing protocol is adequate.
As the subscriptions are canonicalized between broker, their scope is wider
than the individual subscriptions, but the advantage is that you can leave
the ACLs at the final broker level. This is usually referred to as an
overlay pubsub network, and it is known to really scale. XMPP has most of
the protocol bricks to build such a network; it is more a matter for the
developers to think outside their traditional IM mindset.  

In the case of MUC, instead of thinking 'hub and spoke' as most
implementations do, you could easily achieve what you are looking for by
providing chat rooms delegation amongst several servers. Same idea, bring
the fine grained messages closest to the room user. Imagine for example
having a distributed Jdev room. Instead of all the users connecting to the
jabber.org MUC server, every user will connect to a local JDev room hosted
on their home server. French user on a French server, US users on an
American server, and Argentineans on an Argentinean server. To achieve your
multicast, these distributed rooms would be registered in the jabber.org
JDev room. So whenever a message is posted in the original JDev room, it is
sent to every directly connected users, and only one instance will be sent
to each of the delegated rooms in France, US and Argentina. Again this is
not a matter of protocol, but a matter of architecture and implementation.

Presence is a different ballgame. And for many reasons, some of which have
been put forward already. I am not denying the fact s2s presence broadcasts
are far from optimized. This is not the point and my opening statement was
to recognize the idea as interesting. Beyond the inherent issues linked to
making sure rosters are kept in synch, and that proper level of trust could
be guaranteed, I have other interrogations. From this discussion, I have a
strong feeling you are quickly taking for granted delicate matters linked to
privacy and security. If these are real concerns or not is not for us to
decide. The end user is the ultimate judge on this matter. We just have to
make sure the protocol comes close to its expectations, without shortcuts.
In the proposed presence multicast JEP, besides breaking the protocol, you
have so far failed to convince me you have taken these matters into proper
consideration. This is just my opinion.    


More information about the Standards mailing list