I think the answer is simpler than discovery. Email, SMTP, is a favourite example of mine. Discovery is limited to "who handles the mail for this person, [EMAIL PROTECTED]", and takes the form of a ubiquitous service (DNS) at the lowest levels of the protocol, and thus only requires implementation in core libraries. If I want to share microblogging posts, photos, links, or any "social object" in general, then I can do that. These services have been successful in an asymmetric fashion. Although I'm interested in the BBC's photo stream, it's unlikely they'll be as interested in my photo stream. In that sense, the subscription model works well.
Moreover, It can work exactly like email, but in reverse --- I can tell my grandmother that she can add me, "[EMAIL PROTECTED]", to her photo site (e.g., on facebook) as a friend/family member. In the background, the process works exactly like email, though instead of sending an SMTP message, the server sends a subscription request method. The interaction designers take over, and give me a way to say "YES, I'd like my grandmother, " [EMAIL PROTECTED]" to see my photos." From then on, facebook.com will receive a notification for "[EMAIL PROTECTED]" any time I post a photo. The only discovery required were two DNS lookups to find the XMPP servers. That's it. That enables messaging from one site to another, which in turn enables the rich interaction models that drive my interest in this technology. b. On Sat, Jul 26, 2008 at 12:46 PM, Bob Wyman <[EMAIL PROTECTED]> 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. > > 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. > > An alternative means for facilitating discovery would be to extend the > XEP-0060 PubSub specification to support a means for servers to publish > "Advertisements" which announce the availability of nodes for federation. > Advertisements would specify which nodes are available for federation and > what data will be published over those nodes. In order to reuse as much > existing framework as possible, Advertisements would be published just like > normal events, but they would be published to a "well known node" that is > commonly available on all services that support advertisements. This node > might be named: "http://jabber.org/protocol/pubsub#advertisements"; and > would be like any other pubsub node in that it could be subscribed to, read, > etc. However, it would only support publishing <advertisement/>s not > <event\>s. > > The basic assumption behind federation is that two services will be > publishing data which is similar. For instance, that two micro-blogging > services will both be publishing micro-blogging entries that are formatted > as Atom entries. Agreement on the payload formats is essential to enable > federation. On the other hand, it is unreasonable to insist that all servers > use common node names. Thus, a mechanism is needed to provide a mapping from > some commonly agreed name for a stream of data and the node name that is > used on any particular server. This can be accomplished by having the > Advertisement provide a mapping from commonly understood logical node names > to local concrete names. Thus, those creating micro-blogging standards might > say that the logical node name for publishing public posts is: > http://example.com/PublicMicroBloggingPosts. Then, a server that published > public posts on a node named "987ye879799wwww00" would simply provide both > the local and logical name for the node in the advertisement. > > Given this introduction, an advertisement might look like the following: > (but, use of an xdata form might be more appropriate and more flexible...) > > <iq type='set' > > from='[EMAIL PROTECTED]' > to='old_service.shakespeare.lit' > id='ad1'> > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > > <publish node='http://jabber.org/protocol/pubsub#advertisements'> > <advertisement xmlns='http://jabber.org/protocol/pubsub#advertisements' > > id="*tag:[EMAIL PROTECTED],2008-07-24:1234*"> > <local node='987ye879799wwww00' > format='http://example.com/post_format'\ > <http://example.com/post_format'%5C>> > > <common node='http://example.com/PublicMicroBloggingPosts > <http://www.w3.org/2005/Atom>'\> > <description>All public posts on this server.</description> > > </advertisement> > </publish> > </pubsub> > </iq> > > If the Advertisement node is supported as a normal node, then it should be > possible for others to subscribe to the node and thus monitor advertisements > as they are published. Using filters, subscribers would either subscribe to > all advertisements published to the remote node or only to those > advertisements that are specific to that node. This permits advertisements > to flow to nodes not known to the advertiser as well as to permit servers to > ensure that they are rapidly made aware of changes to servers in which they > have an interest. Additional metadata such as keywords, etc. could be added > to make filtering easier and more effective. > > Of course, "Advertisers" shouldn't expect that the mere act of advertising > will always result in a federating subscription. Server managers will still > often want to moderate the lists of nodes they subscribe to. Nonetheless, > the mechanism a foundation on which automatic subscription will sometimes > reasonably be built. For instance, I might wish to build a microblogging > aggregator that automatically subscribes to all remote services that claim > support for microblogging. Or, I might have a strong trust relationship with > some other service and decide that I would like to have my service subscribe > to anything advertised by the that service -- while manually reviewing > advertisements from other services... Many patterns are possible and > reasonable. > > Those familar with blogging infrastructure will recognize a great deal of > similarity between the idea of Advertisements and that of "pinging." In > fact, within the blogging world, pinging is probably the most common and > useful means available to blog aggregators to discover new blogs. In fact, > it can be argued that the introduction of pinging and its use by blog > aggregators was probably one of the most essential steps in building the > blogging infrastructure as we know it today. Before pinging, the process of > discovering new blogs was horribly difficult, inaccurate and expensive for > service providers. > > Comments? Does this sound reasonable? > > bob wyman > >
