Moreover it is not just a bandwidth issue, but
the real added value of XMPP is the possibility to tune delivery
accordingly to presence or resources, thus tuning the feed to the
specific context use.
Yes this is a great feature of the pubsub node. There is a configuration on
both side. On the publishing side, the publisher/creator configure the
default options of the node. On the subscriber side, you can either accept
default options or choose your own (so if you do not want the payload, but
just a notification for instance; or even if you don't want any notification
at all, just subscribing to a service without being pinged, etc.).
However each time you start using these features
you also have to give away little bits of your privacy. The good thing
about XMPP is that you always have control about about who you have in
your roster and, if privacy in such services becomes a real problem
there could be technical solutions (e.g. a local pubsub service which
anonimously subscribes to remote nodes and relays them)
That's a nice idea. This way you can subscribe without giving your real jid
(the redirection is managed by your trusted server). And if the service
tries to use a jid a bad way, it may enable to trace which pubsub service it
was (if the service had generated some specific jid for each subscription
for instance?).
Jehan
