[Standards] +notify and +filter? (was: Re: XEP-0060 + "Atom over XMPP" as base for Open Twitter?)

Peter Saint-Andre stpeter at stpeter.im
Wed May 14 22:40:29 UTC 2008


On 05/08/2008 3:36 AM, Ralph Meijer wrote:
> On Wed, 2008-05-07 at 11:32 -0600, Peter Saint-Andre wrote:
>> On 05/05/2008 2:07 PM, Peter Saint-Andre wrote:
>>> On 05/05/2008 8:34 AM, Bob Wyman wrote:
>>>> In case you haven't seen it, consider reading Michael Arrington's TechCrunch
>>>> post calling for a decentralized Twitter.
>>>> (http://www.techcrunch.com/2008/05/05/twitter-can-be-liberated-heres-how/)
>>>> As noted by many of the commenters, and as should be obvious to anyone in
>>>> the Jabber community, the solution they are looking for is probably XMPP +
>>>> XEP-0060 + "Atom over XMPP".
>>> +1. Just had a chat with Joe Hildebrand about that. I'll start working
>>> on a spec about it tonight. Should be pretty straightforward.
>> http://www.xmpp.org/extensions/inbox/microblogging.html
> 
> Good start, but I have a number of comments and questions to this
> proposal:
> 
> For clarity, is the assumption that there is a microblogging service
> that exposes an XMPP interface in the form of JIDs for every user and
> PEP nodes tied to it, or that the server is a generic XMPP IM server
> with Personal Eventing capabilities? I am assuming the former.
> 
> This spec limits its scope to microblogging. Why? It is kind of
> arbitrary whether a blog is micro, mini, macro or whatever. In the end
> it is usually just a blog, albeit with smaller pieces of text. Size and
> payload type (plain text vs. (x)html) are not enforced are they? Or
> would a publish request fail, depending on the service's configuration?
> I suppose that the <not-acceptable/> stanza error would be appropriate,
> but this is not referred to in XEP-0060 (Publish-Subscribe).
> 
> Tied in to the previous item, because you use a fixed node id, you can
> only have one microblog tied to your account. I suppose that works for
> microblogging services, but this is pretty limiting for aggregating all
> your stuff at your own JID.
> 
> The example of the usage of Entity Capabilities for automatic
> subscription to microblog updates is flawed in relation to how this is
> specified in XEP-0060. Section 10 there describes Filtered Notifications
> in combination with Automatic Subscription based on presence. The
> mechanics are as follows:
> 
> Depending on the 'root' node's configuration, a contact that sends
> presence to a user with an account that has PEP support on its server,
> will be automatically subscribed to that 'root' node with a subscription
> type of 'items'. However, the items sent to you are filtered by using
> Entity Capabilities, if the service provides that feature. To tell the
> service what payloads to send, Service Discovery on the contact's
> resource that sent presence will yield Service Discovery features that
> are namespaces plus '+notify'. E.g. to get moods, you would advertise
> the feature 'http://jabber.org/protocol/mood+notify', and you would get
> all items that have a payload of which the root element is in the
> 'http://jabber.org/protocol/mood' namespace.
> 
> This protoxep, however, shows that the payload is an Atom entry
> document, so the payload of the namespace is
> 'http://www.w3.org/2005/Atom'. Advertising 'urn:xmpp:tmp:microblog
> +notify' as a disco feature, thus should not yield any notifications.
> 
> Please note that I think that this is not a broken design. Having the
> filtering mechanism as-is, allows for multiple nodes that send around
> data as Atom entry documents. If this protoxep is implemented as an
> interface to an existing microblogging service, you would probably want
> to get all Atom entries anyway. So advertising
> 'http://www.w3.org/2005/Atom+notify' would do the trick. Also note that
> this means that the node id itself is no longer relevant. A client could
> discover the user's nodes and use the node's meta data to detect the
> type of node and possibly allow the user to pick on, if there are
> multiple. I could imagine a meta data field that specifies the intended
> usage (blogging versus pictures versus yet another social object) next
> to the one for denoting the namespace of the payload. Note that the Atom
> Publishing protocol does something similar with Service Documents.

I think we need to rethink this design a bit.

In particular, I think it is useful to have two different filtering
mechanisms:

1. Filter on NodeID

2. Filter on payload namespace

Why? Because this provides a way to receive only the particular
notifications you are interested in.

Atom is a good example. Given that Atom is the new XML, everyone and
their uncle will provide an enormous range of information using Atom.
Not just blog feeds (what we traditionally think of as Atom) but, via
Atom extensions, potentially everything that we've defined as separate
payload namespaces for PEP (tune, mood, geolocation, and all the rest).
If I advertise http://www.w3.org/2005/Atom+notify then I will receive
everything that is published using Atom as a container.

Now, that might be desirable sometimes. But sometimes I just want to
receive your blog feeds, or your microblog posts, or whatever.

There are at least two possible approaches here (and perhaps others):

1. Wrap (some) Atom payloads in a wrapper element qualified by a special
namespace (one for microblogs, one for geoloc, etc.).

2. Define +notify as "match NodeID" and a new suffix (+filter?) as
"match payload namespace".

This way, we can define urn:xmpp:microblog as a specialized usage of
Atom (and that's what it is, no?), and people who want to receive only
my microblogs (but not everything else that I might publish in the Atom
format) can do so.

Thoughts?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080514/b36b7166/attachment.bin>


More information about the Standards mailing list