Private Storage via PEP. Was: Re: [Standards] pubsub/pep auto-creation

Ralph Meijer at
Thu Mar 29 09:31:20 UTC 2007

On Thu, 2007-03-29 at 10:36 +0200, Remko Tronçon wrote:
> > As I understand it, the argument is that if we allow publish+configure
> > then clients can simply replace the line of code where they do IQ-set
> > for "jabber:iq:private" with a line that sends publish+configure. Easy
> > transition.
> Plus, I will never implement iq:private in Psi if I cannot guarantee
> that my node publishing is private. And even without the race
> condition (possibly solved by a transaction system that will be
> standardized and widely implemented by servers and maybe one client
> with enough willpower in a year or 5), I would strongly object to
> implementing a check that the node still is private and change
> configuration every time i want to publish private data. This is just
> against all our principles of keeping everything simple.

I have a few questions on this:

1. What kind of data will you want to store here? I would like concrete
examples. So far, I have seen it being used for client preferences,
roster item annotations, the delimiter for nested roster groups,
bookmark storage.

In Private Storage, the data's namespace was the unique identifier to
store and retrieve the item. I imagine the implementation of Private
Storage via PEP as the creation of a new node for each of the types of
data. So one node for the bookmarks, one node for roster annotations,
etc. Each of these nodes would need to be created using the
pubsub#access_model of 'whitelist', only allowing the owner to publish
and subscribe.

2. Why would the configuration of nodes change? If the answer is,
because of faulty clients, I say: what about rogue clients allowing new
presence subscriptions to be automatically accepted? What about them
sending of a copy of all your messages to some remote entity? I want to
be aware of the exact threat model here.

3. As for changing configurations, like in the Council meeting, I want
to point to Examples 133 and 134 of XEP-0060. They show how to notify
subscribers of node configuration changes. I know this does not
completely solve atomicity, but it does allow you to find out about
things going wrong.

4. What if we would create a special node configuration flag for private
nodes? That is, once a node is configured to be private, you cannot
revert that. Maybe until the node has been deleted explicitely.

> To me, the situation sounds like this:
> - publish+configure+auto-create solves bugs and problems

This is actually what the debate is about. I do not agree and I think it
is premature to pose that as a fact. It could be that it may
prevent /certain/ bugs and problems, and introduce others at the same

> - Client implementors want this *a lot*

What I sense from the general discussion is that some client
implementers want a drop-in replacement for Private Storage, using PEP.
This brings other requirements than for the Personal Eventing concept
PEP was initiated for.

As I see it, PEP is for publishing nuggets of information to (certain)
contacts. One of the drivers behind the design of PEP is that it should
be easy to find out what someone is publishing (by tying the nodes to
your account), provide a very simple way of automatically subscribing to
those types of data you are interested in (using Entity Capabilities)
and ease of publishing.

Private Storage is similar in that the data is tied to you, and
dissimilar in that you only want yourself to have access to it, and that
you are not necessarily interested in the actual notifications that are
the basic idea behind the observer design pattern publish-subscribe is
based on.

> - It sounds to me that this involves only 10 extra lines of code for
> server implementations
> Why are we still discussing this?!

Those 10 extra lines you are suggesting are probably a very low
estimate. On top of that, at least in my code, it requires a fair number
of additional and/or updated unit tests.

Another thing I brought up in the discussion is that error handling, on
both sides of the wire is particularly undefined and at least more
complicated. For example, a client could mess up both the configuration
form and the payload that is send as part of the publish request. Both
yield a bad-request stanza error. XEP-0060 defines application specific
errors you can include in the iq-error, but the RFCs only allow one of



More information about the Standards mailing list