I think that a more interesting question is what I am subscribing _to_. Is this new service, or new users in known service? That is, is this about getting information about new users in service I trust, or about new services that pop up.
>From the description, it sounds like it is something that is aimed at discovering new services, not new items within existing service. On Sun, Jul 27, 2008 at 12:17 AM, Lior Sion <[EMAIL PROTECTED]> wrote: > 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 >
