[Standards] XEP-0060 + "Atom over XMPP" as base for Open Twitter?
stpeter at stpeter.im
Thu May 8 22:19:22 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.
>>>> 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
Thanks for the review. You probably know more about this stuff than
anyone else here. :)
> 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.
I assume so as well.
> This spec limits its scope to microblogging. Why?
Because that is the topic du jour. But you are correct that this spec
need not be limited to microblogs.
> 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?
Well I'd think that a particular service might enforce size limits on
posts, e.g. by truncating the text at 140 characters.
> 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).
No, it's not. We need to add that to the error flows.
> 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.
Ah, you mean as in aggregating (say) my Twitter and Jaiku streams at my
JID? I think that aggregation use case is a bit different from natively
pushing out your [micro]blog posts via your JID. Maybe it is my bias for
decentralization, but I think that people who blogged recently about
building a kind of decentralized Twitter are interested in the ability
to microblog from your own domain, as you can do with Jabber by running
your own IM server or with a blog by running your own instance of
Wordpress or whatever. Then if other people want to take what you
publish at your own domain and aggregate that somehow, they can. But the
aggregation moves from you outward, not from silo'd services back to
you. This makes you the center of your [micro]blogging universe, not
some service. If that makes sense. :)
> 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 will reply to the +notify stuff in a separate message. :)
> 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.
Agreed. If you and I (1) both have bidirectional subscriptions to each
other's presence and (2) both ask for blog notifications, then we'll see
each other's replies. But if either of those is not true, we're out of
luck. In an IM context that may not matter.
> 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.
Yes, that is true. I meant that is is easier for the client if the
service fills that stuff in, because then it doesn't need to worry about
generating unique IDs and all that. But then you can't use a stock
PEP/pubsub service, because such a service is not going to muck around
with what's in the payload -- it just routes it on its way. So what you
are proposing is a layer above pubsub. Which is fine, as long as we
clearly describe it as such.
I have a related note to mention (about ItemIDs), but I will start a
separate thread about that.
> 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.
Agreed. When I quickly wrote the proposal I had not checked the Atom
RFCs. Perhaps this belongs in XEP-0060 -- can a pubsub service change
the ItemID you provide?
> 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 don't care what the XSLT is from Atom <entry/> to XMPP <body/>, but I
want to make it clear that *some* kind of XSLT would be very helpful
here (and in other PEP cases), because I think that including a body
will help us bootstrap to wider pubsub support in clients. AFAIK, few
people are aware of the rather obscure "pubsub#body_xslt" config option,
or the fact that a pubsub service could have default XSLTs for various
payload types, so I'm trying to make that more known.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards