On Sat, Jul 26, 2008 at 03:46:51PM -0400, Bob Wyman wrote: > The results of last week's XMPP Summit are beginning to bleed out as Ralphm > blogs the first of a promised series of notes on the event. > See: http://ralphm.net/blog/2008/07/26/xmpp_summit_5 > and http://ralphm.net/blog/2008/07/26/xmpp_social_networks_1 > > Not surprisingly, it seems that those at the Summit agreed that the most > sensible way to federate XMPP PubSub servers is to have various servers > subscribe to each other. Thus, if I was running a microblogging service that > provided open access to "public" posts on my service, I might set up a node to > which I published all such "public" posts. Other microblogging services, > search > engines, etc. would then subscribe to that node and, by doing so, could mix > messages published to my service with those published to their own service. > > This approach of "Federation via Subscription" has some distinct advantages > over the alernative, "Federation via Publishing", particularly in that it > eases > spam control and management of server resources. However, it has a distinct > disadvantage in that it makes it somewhat harder to form networks of > cooperating servers.
You couldn't wait until the end of the series did you? ;-) > In a system which relies on Federation via Subscription, all servers that > receive messages must have knowledge of potential publishers prior to any data > flowing between them. Given two servers, A and B, no data will flow from A to > B > unless B first becomes aware of A and subsequently subscribes to at least one > node on A. The interesting question becomes: "How does B become aware of A?". > Since no data can flow between the two servers until a subscription is > established, if there are no other mechanisms provided, one must assume that B > discovers A via "out-of-band" communications such as email messages, phone > calls, directory lookups, etc. These are, of course, rather crude discovery > methods and require manual configuration upon discovery to establish > federating > subscriptions. The approach we wanted to take was to come up with the simplest possible thing that could work. The federation via subscription model is actually pretty much the as how we do federation in Jabber IM settings, and that seems to work reasonably well, I would say. That said, we didn't stop just were you seem to assume, although some have suggested it during the summit. I won't outright dismiss what you suggest here, because I need to take a better look at it, but we came up with a different way of discovering pubsub nodes that I think is very natural to how the web works. The solution we came up with is using HTML and/or Atom link elements, on pages/regular feeds that represent a person's updates, or his and and his friends, etc. Pretty similar to how such pages currently point to Atom/RSS feeds, we use a 'rel' of 'xmpp.feed' and the 'href' points to the XMPP URI of the node, eg. xmpp:[EMAIL PROTECTED];node=updates. This provides for an easy way to have one user on service A to subscribe to another user on service B: the first user is very likely to know about the page of the second user at site B. He inputs that URL and the service can do auto discovery and subscribe all behind the scenes. I'll expand on it more on my blog, but that seems the gist of it. I probably have more thoughts on this but need some sleep first. Cya! -- Groetjes, ralphm
