Warning this post is technical

As you may know, "Salut à Toi" allow to do microbloging with groups access, that mean that you can send post to only a group of your roster (e.g. "family" or "friends"). This feature has been available for a year, but was using a dirty hack (which only works with OpenFire); that was mainly a proof of concept

We need a simple permissions system which can be used beyond microblogging, something generic, which can extend PubSub.
Rather than thinking about tons of pubsub nodes with different access model each time (e.g. a family node, an other one for friends, etc), we need a way to fine tune permissions, by items.

For this reason, I started a pubsub component to validate the concept, and which will be used by SàT to manage microblogging. If the idea proove to be working, I'll talk about it on one of the XSF mailing list, to propose it as a standard.

The way it works is simple: we use exactly the same syntax as for nodes access model (http://xmpp.org/extensions/xep-0060.html#accessmodels), and we apply it to items.
The node access model is applied first, then the ones of items (that mean that an item with an open access model won't be available to somebody which is not in the right roster group if the node has a roster access).
The PubSub component parse the item stanza, apply access model, then save it (without the configuration part).
When somebody wants to get node's items, the pubsub component first check that he is granted to access node (by checking the "access model"), then send him only the items that he can access.

Imagine that Louise has a node with 3 items: 1 with an open access (A), 1 with a roster access, allowed for "family" group (B), and one with a roster access, allowed for "friends" and "coworkers" (C).
Pierre, who is a friend of Louise, will have access to items A and C. Louise's brother will access items A and B.

There a 2 main advantages: first this protocol stay standard compliant (with XEP-0060) - so there is no change to do for an XMPP client to get items -, and secondly the clients have only one node to check by entity that they want to follow.

Some words on test implementation: I use the "Idavoll" PubSub component as a basis, which was made by Ralph Meijer*, and I have slightly modified it for my tests. The main difficuly is that currently components have a very limited access to server, and we can't access entities' roster.
To work around the issue, I use an experimental protocol which allow to access a remote roster. Unfortunately, this protocol only permit to access a part of the roster, so I have patched Prosody's implementation to get the full roster.
Finally, I used some simplifications by saying that node creator, owner and publisher are the same. This is often true for microblogging, but is very limiting when we think about XEP-0060's possibilities.

Anyway it works, but it still need works (and a standardisation) before being a proper way to do.

Below is a server dialog example. We have here Pierre and Louise which are friends, Louise being in "friends" group of Pierre. The later post a microblog as follow**:
<iq from="pierre@example.net/SàT" type="set" id="H_77" to="sat-pubsub.example.net">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <publish node="urn:xmpp:groupblog:pierre@example.net">
      <item id="8f532cc8-be1d-11e1-b5d3-00c0ca4f1546">
        <entry xmlns="">
          <title>G'day my friends !</title>
          <id>8f532cc8-be1d-11e1-b5d3-00c0ca4f1546</id>
          <updated>2012-06-24T18:56:36+02:00</updated>
          <author><name>pierre@example.net</name></author>
        </entry>
        <x xmlns="jabber:x:data" type="submit">
          <field var="FORM_TYPE" type="hidden">
            <value>http://jabber.org/protocol/pubsub#item-config</value>
          </field>
          <field var="pubsub#access_model">
            <value>roster</value>
          </field>
          <field var="pubsub#roster_groups_allowed">
            <value>friends</value>
          </field>
        </x>
      </item>
    </publish>
  </pubsub>
</iq>

After receiving this, the server parse configuration data (the "http://jabber.org/protocol/pubsub#item-config" form***), delete this part of the stanza, save the item with the right permissions (roster access, only for "friends" group), and only send a notification to group's members, so it send one to Louise.

The notification is sent like this:

<message to="louise@example.net" from="sat-pubsub.example.net">
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node="urn:xmpp:groupblog:pierre@example.net">
      <item id="8f532cc8-be1d-11e1-b5d3-00c0ca4f1546">
        <entry xmlns="">
          <title>G'day my friends !</title>
          <id>8f532cc8-be1d-11e1-b5d3-00c0ca4f1546</id>
          <updated>2012-06-24T18:56:36+02:00</updated>
          <author><name>pierre@example.net</name></author>
        </entry>
      </item>
    </items>
  </event>
</message>

There is no way to know on which group Louise is in Pierre's roster (this is a classical notification). Even is an XMPP client doesn't manage the per-item access model, it will receive the notifications and will be able to manage them as usual.

I have sub-licenced the component to AGPL V3, you will find the code in my repository (http://repos.goffi.org/sat_pubsub/). I invite XMPP community's members (authors of clients and servers, or others) to use the code, or to comment the idea

Fine permissions tuning are in my opinion a mandatory feature that XMPP really needs, and they will be more and more used by the "Salut à Toi" project. It was one of the last architecture point of SàT, a new release should follow quickly.

Stay connected :)
Goffi

* Ralph Meijer is also a contributor of Twisted and the author of "Wokkel" library, which are in the heart of SàT, in addition of being one of the authors of PubSub XEP. A huge thank to him for its valuable contributions.
** Normally, microbloging use PEP, but component limitation that I mentionned above forced me to use a custom protocol, which doesn't use PEP.
*** I have used a "jabber.org" namespace instead of "goffi.org", as I should have do for an experimental feature, because I need it so Wokkel's PubSub service could parse it.