[Standards] XEP-0060 + "Atom over XMPP" as base for Open Twitter?
jabber.org at ralphm.ik.nu
Thu May 8 09:36:43 UTC 2008
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.
Good start, but I have a number of comments and questions to this
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
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.
Then on to replying to posts. Do I understand correctly that replies go
to your own node, not on the node of the original poster? While probably
a good model, your comments are under your own control, this makes it
difficult to find replies. The Atom Threading extension allows for
embedding links to replies in the Atom entry document of the post, but
well, we already sent out the thing, so that would only work if we would
send an update for each post when a reply is discovered. Discovery would
be straight-forward when the two actors are in the same service, but
becomes a bit harder for distributed services. So I guess we need to
think about that.
On publishing, I see that the note that publishing via non-XMPP
protocols is easier. That seems odd to me. If this protocol is provided
as an interface into an existing microblogging service, I don't see any
reason why the service couldn't fill in parts of the data before sending
out notifications. The publish request could leave of the item ID, and
all elements that use that item id to form links and the Atom <id/>
element. You can also leave off the source and provided dates, probably.
The service would fill that all in, and send out notifcations as shown.
I am aware that this would mean sending Atom entry documents that don't
have all the required fields, so maybe that would be an issue. The Atom
Publishing protocol examples do not do this, they show that the
publisher must provide an <id/> element, and the value is a UUID urn,
and an <updated/> element, but:
A server MAY change the values of various elements in the Entry,
such as the atom:id, atom:updated, and atom:author values, and MAY
choose to remove or add other elements and attributes, or change
element content and attribute values.
I think that something matching that would be very nice, you just
provide some <id/> and <updated/> element, and the service would be free
to change that. Not having to provide all the other stuff makes
publishing a lot easier.
I am not so happy with the suggestion for the <body/> character data
being identical to the entry's title. That is quite limiting in terms of
providing context. It would be nice, for example, to include a link to
an HTTP URI to retrieve the HTML rendering of the entry, if that exists,
and possibly (part of) the description. It is also probably up to a
service how it should look exactly, but providing more context is
generally a good idea if you want to provide a fall back rendering.
I think I wrote more prose than the spec, so I'll stop for now.
More information about the Standards