it sounds to me that using http to discover new updates will create heavy stress on the server: tens of social networks each polling for new updates all the time on all the combined users..
I might be missing something here, but if the publishing mechanism in recursive (that is, I subscribe to twitter/user/ABC so I would get any new thing related to ABC, their comments, tweets, presence, whatever) then what will the new announcement mechanism add? The difference between blog world pinging usages and social networking federation is that in the blog world, there's a distinct one to many relationship, or very close to it - many many small blogs updating a few distinct aggregation services, while social federation is different, no? Lior On Sun, Jul 27, 2008 at 12:09 AM, Ralph Meijer <[EMAIL PROTECTED]>wrote: > 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 > -- thanks, Lior Sion Skype: sionlior | GTalk: lior.sion
