To make it personal, and to make it drupal-connected, I make blog posts and have configured my Drupal sites with the twitter module(s) such that every post is tweeted. There's a little subform on the node/add form that contains the tweet letting me customize it for this given posting (or even to disable the tweet). It's really convenient but if someone posts a followup tweet, or if when the tweet makes it to buzz or facebook, it would be really cool if responses on those other services made their way back to my blog as a comment upon that posting.
In the past there were trackback and pingback protocols meant to serve part of this issue. Their use case seemed to be other bloggers who blogged a response to another's blog post. That would be very convenient but in my experience trackback became a magnet for spammers and I eventually disabled the trackback module.
This talk will cover how PubSubHubbub enables developers to produce and consume real-time content across the net. I will detail how the next generation of social sites will build on standard components like ActivityStreams, WebFinger, and Salmon. Come see how your site can become part of the new decentralized web.
Immediately prior to this was a talk, Aggregate and import with Feeds!, which included a demonstration of immediate aggregation of posts using PubSubHubbub as the mechanism. What PubSubHubbub does is advertise a software subscription mechanism that lets PubSubHubbub hubs subscribe to updates on a feed, and then turn around and notify others of the updates. It envisions that the PubSubHubbub hub infrastructure will be able to optimize for the demands of serving out feeds to the zillions of people who want feeds. Certainly a subscribe/notification pattern is better than the continual poll pattern, because of lower overall computation/network/bandwidth cost. And the lower network impact on the services we deploy, the lower the amount of overall computer infrastructure is required to run the Internet, and the lower the negative environmental impact of running the Internet.
Obviously Feeds provides support for being a client in the PubSubHubbub universe. AFAICT there isn't existing support for Drupal as a publisher in the PubSubHubbub universe, however the protocol work required looks to be small. And in the Feeds talk the guy demonstrated having a module or to which would enable a Drupal site to publish into PubSubHubbub.
The next piece is ActivityStreams which they describe as an extension to the Atom feed format to express what people are doing around the web. This doesn't appear to be related to the "Activity Stream" module (and.. for the record, I'm currently using FeedAPI to perform the function described on the Activity Stream project page). There would again be two parts to ActivityStreams, one being the elements required to publish ActivityStreams data, and something to pick up ActivityStreams data that's available on the net. ActivityStreams fit into Atom feeds which may mean changing Drupal to produce a different feed format than the RSS we've been traditionally producing.
The next piece is WebFinger which in turn relies on RFC 5785: Defining Well-Known Uniform Resource Identifiers (URIs). The latter defines a service that publishes "well known" snippets of information one of which is the "WebFinger" which is a modern equivalent to "finger david" which we did a lot of in the 1980's. It involves having some software answering at "example.com/.well-known/host-meta", providing a snippet of XML that describes various services, and then another bit of software for WebFinger that provides another smidgeon of XML describing a specific user. A few simple modules should be capable of publishing these smidgeons of data and for WebFinger the data source is obviously the user profile. Additionally we want user profiles in Drupal to be capable of linking to the users existing WebFinger data.
The last is Salmon Protocol or: "As updates and content flow in real time around the Web, conversations around the content are becoming increasingly fragmented into individual silos. Salmon aims to define a standard protocol for comments and annotations to swim upstream to original update sources -- and spawn more commentary in a virtuous cycle. It's open, decentralized, abuse resistant, and user centric. In other words this specific project would fulfill the pain point I identified in the introduction.
It's even better: Salmon is intended to be Activity Stream-compatible. Salmon endpoints should be able to accept Activity Stream activities as well as generic Atom formatted comments -- in fact a generic Atom formatted comment is also a valid activity in the current AS spec. Liking, rating, and linking to content all contributes to conversations.
Waaaay cool..