Publisher's callback, track and firehoses
Superfeedr’s hosted hubs come up with a lot of nifty things. We recently introduced a few more : track feeds, fat pings and publisher callbacks.
Track feeds for hosted hubs
Back in July, we introduced track. A nice and easy way to get realtime notifications of keyword mention across all the content that goes thru Superfeedr. Back on August, we improved track, by adding the ability to track boolean expressions and do some geofiltering. In September, we now allow track on hosted hubs. You want any mention of Apple on Tumblr? check this feed.
Fat pings
Several of our publishers complained about the fact that loop between the time they ping the hub and the time the hub polls their feed wasn’t the most efficient. We believe they’re right, and we have now setup a mechanism where publishers can do fat pings to indicate which feed has been updated and the new content of said feed. It’s much more efficient than having us poll the feeds right after they’ve been pinged to us.
Of course, it involves some kind of signature of the content, to prevent anyone from forging your content. You’ll find all the details in your hub’s settings.
Publisher Callbacks
Many publishers want to make their content available… but a lot of them also want to keep control of it. The publisher’s callbacks are a nice way of doing so. In your hub’s settings, if you’re using Superfeedr to make your RSS feeds realtime, you can now register a callback which shall be called upon each subscription request to your content.
Of course, this simple callback lets the publisher decide of their own policy regarding these. For example, a publisher is likely to let everyone subscribe to individual feeds, but may want to control who subscribes to fire-hoses or track feeds for their hub. We also prepared a small AppEngine template for this.
Additionally, these callbacks are smart, as they will echo back the answer to the original subscriber, who can then, take measures to see his subscriptions accepted. For example, a publisher may request for an API key to be submitted as part of the subscriptions parameters, Superfeedr will forward all the params posted to the hub, so the publisher can safely grant access based on their business decisions and own choices.
A PubSubHubbub-Auth pattern
We believe that these subscription callbacks can be the basis for an Authorization pattern (at least for the read part of it). Since the publisher can decide how they want to implement the subscription callback, the publisher may then ask the users if they allow for their content to be published.
Let’s take an example :
- Google Buzz asks Superfeedr (the designated hub) for John’s Gowalla feed,
- Superfeedr asks Gowalla if it’s ok to let Google Buzz access this content,
- Gowalla asks John if it’s ok to send his data to Google Buzz.
- If yes, Gowalla tells Superfeedr to accept the subscription, if not, Gowalla tells Superfeedr to refuse the subscription.
Of course, this cannot be considered as a spec of any kind, but I surely hope we can discuss this with the Open Web community, at FOO Camp, for example. Feel free to share your thoughts. It has the great advantage of letting the publisher and the users decide, rather than imposing them some kind of policy. It also requires that publishers trust the hub which they designate.
By Julien, on 04 Apr 2011
