No subject
Fri Aug 3 19:33:07 CDT 2007
discovering new services, not new items within existing service.
On Sun, Jul 27, 2008 at 12:17 AM, Lior Sion <lior.sion at gmail.com> 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 <jabber.org at ralphm.ik.nu>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:ralphm at jaiku.com?;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
>
------=_Part_10109_16037572.1217107341531
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div dir="ltr">I think that a more interesting question is what I am subscribing _to_.<br>Is this new service, or new users in known service?<br>That is, is this about getting information about new users in service I trust, or about new services that pop up.<br>
<br>From the description, it sounds like it is something that is aimed at discovering new services, not new items within existing service.<br><br><div class="gmail_quote">On Sun, Jul 27, 2008 at 12:17 AM, Lior Sion <span dir="ltr"><<a href="mailto:lior.sion at gmail.com">lior.sion at gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">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.. <br>
<br>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? <br>
<br>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?<br>
<br>Lior<div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Sun, Jul 27, 2008 at 12:09 AM, Ralph Meijer <span dir="ltr"><<a href="http://jabber.org" target="_blank">jabber.org</a>@<a href="http://ralphm.ik.nu" target="_blank">ralphm.ik.nu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Sat, Jul 26, 2008 at 03:46:51PM -0400, Bob Wyman wrote:<br>
> The results of last week's XMPP Summit are beginning to bleed out as Ralphm<br>
> blogs the first of a promised series of notes on the event.<br>
> See: <a href="http://ralphm.net/blog/2008/07/26/xmpp_summit_5" target="_blank">http://ralphm.net/blog/2008/07/26/xmpp_summit_5</a><br>
> and <a href="http://ralphm.net/blog/2008/07/26/xmpp_social_networks_1" target="_blank">http://ralphm.net/blog/2008/07/26/xmpp_social_networks_1</a><br>
><br>
> Not surprisingly, it seems that those at the Summit agreed that the most<br>
> sensible way to federate XMPP PubSub servers is to have various servers<br>
> subscribe to each other. Thus, if I was running a microblogging service that<br>
> provided open access to "public" posts on my service, I might set up a node to<br>
> which I published all such "public" posts. Other microblogging services, search<br>
> engines, etc. would then subscribe to that node and, by doing so, could mix<br>
> messages published to my service with those published to their own service.<br>
><br>
> This approach of "Federation via Subscription" has some distinct advantages<br>
> over the alernative, "Federation via Publishing", particularly in that it eases<br>
> spam control and management of server resources. However, it has a distinct<br>
> disadvantage in that it makes it somewhat harder to form networks of<br>
> cooperating servers.<br>
<br>
</div>You couldn't wait until the end of the series did you? ;-)<br>
<div><br>
> In a system which relies on Federation via Subscription, all servers that<br>
> receive messages must have knowledge of potential publishers prior to any data<br>
> flowing between them. Given two servers, A and B, no data will flow from A to B<br>
> unless B first becomes aware of A and subsequently subscribes to at least one<br>
> node on A. The interesting question becomes: "How does B become aware of A?".<br>
> Since no data can flow between the two servers until a subscription is<br>
> established, if there are no other mechanisms provided, one must assume that B<br>
> discovers A via "out-of-band" communications such as email messages, phone<br>
> calls, directory lookups, etc. These are, of course, rather crude discovery<br>
> methods and require manual configuration upon discovery to establish federating<br>
> subscriptions.<br>
<br>
</div>The approach we wanted to take was to come up with the simplest possible<br>
thing that could work. The federation via subscription model is actually<br>
pretty much the as how we do federation in Jabber IM settings, and that<br>
seems to work reasonably well, I would say. That said, we didn't stop<br>
just were you seem to assume, although some have suggested it during the<br>
summit. I won't outright dismiss what you suggest here, because I need<br>
to take a better look at it, but we came up with a different way of<br>
discovering pubsub nodes that I think is very natural to how the web<br>
works.<br>
<br>
The solution we came up with is using HTML and/or Atom link elements, on<br>
pages/regular feeds that represent a person's updates, or his and and<br>
his friends, etc. Pretty similar to how such pages currently point to<br>
Atom/RSS feeds, we use a 'rel' of 'xmpp.feed' and the 'href' points to<br>
the XMPP URI of the node, eg. <a href="http://xmpp:ralphm@jaiku.com?;node=updates" target="_blank">xmpp:ralphm at jaiku.com?;node=updates</a>. This<br>
provides for an easy way to have one user on service A to subscribe to<br>
another user on service B: the first user is very likely to know about<br>
the page of the second user at site B. He inputs that URL and the<br>
service can do auto discovery and subscribe all behind the scenes. I'll<br>
expand on it more on my blog, but that seems the gist of it.<br>
<br>
I probably have more thoughts on this but need some sleep first. Cya!<br>
<font color="#888888"><br>
--<br>
Groetjes,<br>
<br>
ralphm<br>
</font></blockquote></div><br><br clear="all"><br></div></div>-- <br>thanks,<br>Lior Sion<br><br>Skype: sionlior | GTalk: lior.sion<br>
</div>
</blockquote></div><br></div>
------=_Part_10109_16037572.1217107341531--
More information about the social
mailing list