[standards-jig] JEP-0060 PubSub: We need privacy lists in PubSub

Ralph Meijer jabber.org at ralphm.ik.nu
Tue Feb 18 08:07:47 UTC 2003

On Mon, Feb 17, 2003 at 04:25:30PM -0500, Bob Wyman wrote:
> Given that multiple publishers can publish to a single node and given
> that some receivers of messages may be only interested in messages from
> some subset of those who are authorized to publish to a node, it would
> be desirable to provide a mechanism for establishing "privacy lists" in
> PubSub that can be used to filter messages based on sender. The logic
> behind this is very much like that which is cited in Section 7 of:
> http://www.ietf.org/internet-drafts/draft-ietf-xmpp-im-02.txt
> i.e.:
>    "Most instant messaging systems have found it necessary to implement
>    some method for users to block communications from specific other
>    users (this is also required by section 2.3.5 of RFC 2779 [2]).  In
>    XMPP this is done using the 'jabber:iq:privacy' namespace by managing
>    one's privacy lists (also called "zebra lists" since they are
>    flexible combinations of blacklists and whitelists)."
> Presence and much of IM is simply a subset of the more general PubSub
> problem. Thus, we should not be surprised to see that a PubSub system
> should evolve to become a proper superset of any IM and/or Presence
> protocol. Personally, I believe that if PubSub had been specified first,
> then IM and Presence would have simply been applications layered on the
> PubSub system. Given this, it is a bit odd to see IM/Presence and PubSub
> being defined at the same time in different, apparently unrelated
> specifications.


I am not totally convinced on this. If you subscribe to someone's presence
you say: I want to receive this bit of information. This should be the
same for the general pub/sub case. If you subscribe to a node, you get
notifications of all published items.

If you want more finegrained control of what notifications reach you, you might
want to implement a filtering pubsub proxy component. This component subscribes
to nodes of 'regular' pubsub systems and notifies its own subscribers based on
arbitrary rules. I can think of filtering based on presence, mood, location,
time of day, etc. Such a component is perfectly ok to create given the current
specification and there are configuration forms to setup the desired filters.
The forms are there for both for the node as for the subscription itself, which
I thought up specifically for this kind of applications.

One note here is that you cannot see who was the publisher of an item in the
notification. You could just set up different nodes for each publisher and let
people subscribe to a node which publishes the actual nodes and their
publishers so you can choose which publishers you want to receive notifications
of. This also makes it possible to discover new publishers as time goes by.



More information about the Standards mailing list