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. 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. -- Groetjes, ralphm
