On Tue, Aug 5, 2008 at 1:02 PM, Bob Wyman <[EMAIL PROTECTED]> wrote: > What is the status of the protoxep > http://www.xmpp.org/extensions/inbox/microblogging.html ? > Is this going to be made a formal XEP anytime soon? Given that we've already > got "microblogging" systems like Identi.ca, Jaiku, and Twitter (when > running) that are being built and deployed, if we're going to have a > standard here, we're probably going to have to get it agreed fairly > soon.Otherwise, implementations will get so far entrenched that it won't > really be possible to make any real changes to them... > > I may not be reading the proposal correctly... Please help me with a few > points of potential confusion: > > The protoxep makes a fairly significant assumption that PEP/PubSub is > supported. This comes out most clearly in the assumption that the way one > publishes an item is by forming an XML stanza that targets a specific node. > While that is fine, it doesn't map to reality. Today, people are becoming > used to microblogging via XMPP by sending bare chat messages to a bot such > as [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], etc. This simple > chat message method has the advantage of being something that can be used > with a simple chat client. Using the methods of PEP/PubSub to publish would > require that more complex client software be used to form the messages.
This isn't entirely true. It simply requires that user interface to the pupsub system be proxied through a bot. This can be rather easily accomplished with a component bot that ties into the underlying pubsub/pep system. It's been a while since I looked at the microblogging spec, but I recall feeling a little dismayed while reading it. Here's some of my points. 1) it's all just pubsub Blaine drilled this into me at the summit and he's right. Twitter, Jaiku, identi.ca are all pubsub systems. Pubsub in the general sense but still just pubsub. So first let's dispense with the word microblogging, that's not the problem we're solving. The problem that needs solving here, is creating easy tools to distribute and interact with pubsub systems. It's a communication problem and that is a place that XMPP has a real chance. 2) The user interface is important. Right now clients don't have good support for viewing and interacting with pubsub messages, so Bob's comment about thinking about this ui is important. That being said, I don't think that it belongs in a talk about the specifications. We have tools to handle this and I'll discuss some options below. So let's look at a simple use case. Service1 is a pubsub service (like twitter). Their users have local user accounts ([EMAIL PROTECTED]). They expose PEP nodes for each of their users. Service2 is also a pubsub service. Their users also have local user accounts ([EMAIL PROTECTED]). They expose PEP nodes for each of their users. In terms of the backend implementation, to federate the systems [EMAIL PROTECTED] simply has to subscribe to [EMAIL PROTECTED]'s PEP node and service1 will begin to receive updates from [EMAIL PROTECTED] At that point you already have a system that's capable of exposing a web interface to users. But there's been a lot of talk here about the importance of an IM interface, this however does not complicate the scenario all that much. In that system we have one more Service, which is an xmpp server. Service3 is an xmpp server (like gtalk). Their users have local user accounts ([EMAIL PROTECTED]). if [EMAIL PROTECTED] want's to interface with his account at service1, he can subscribe to their bot ([EMAIL PROTECTED], or similarly register online). At this point [EMAIL PROTECTED] can send [EMAIL PROTECTED] all the updates entering the system. This is a system we've all seen, but I think we needlessly complicate it when it comes to federation. If [EMAIL PROTECTED] want's to follow another user on service1, he can tell the bot "follow user2" (local name is implied), if he wants to follow a user on service2 he can tell the bot "follow [EMAIL PROTECTED]" and if he wants to follow a JID that is registered at service2 he can tell the bot "follow [EMAIL PROTECTED] via service2.com". This is all do able, but what's important to recognize is that what the user sees doesn't need to be standardized, it's just a UI into a pubsub system that's already speced to hell and back. ~ Anders > Similarly, the common practice today is for XMPP bots to implement textual > "command line" interfaces for doing things like setting up "follow," > "track," listing subscriptions, search, etc. Of course, each service > implements a slightly different syntax and it isn't always obvious how one > maps the various functions to what is defined in the protoxep. > > The protoxep recommends that microblogging publishers should include a > <body/> element in what they publish in order to enable simple clients to > work as though they were receiving simple chat messages. However, it would > appear that one shouldn't publish messages to a simple client unless it > advertises support for the "urn:xmpp:tmp:microblog+notify" capability or has > an explicit PubSub subscription. But, a simple client is not likely to have > met either of these conditions... So, why would something that conforms to > this protoxep ever publish anything to a simple client? > > I admit that I may be totally confused in not understanding how we get from > here to there... > > bob wyman > >
