Hey all, Today one of the GitHub guys released a new Node.js library for PuSH. His call for JSON support in the protocol is clear:
http://techno-weenie.net/2010/10/5/nub-nub/ We've been wanting to add JSON support for quite a while, with notable contributions from Mart (http://martin.atkins.me.uk/specs/pubsubhubbub-json) and others. A while ago Monica wrote up this proposal about how to support arbitrary content types in PubSubHubbub: http://code.google.com/p/pubsubhubbub/wiki/ArbitraryContentTypes I worry about option 2, translation to JSON, because I think it dictates what format the JSON payload needs to be in when served by publishers. A big benefit of JSON is making things easier to use and more ad hoc. Dictating the packaging format would harm that. I also don't see Facebook changing their JSON API (http://developers.facebook.com/docs/api/realtime) to match and they shouldn't have to. The core issue with option 1, the REST approach, is security (replay attacks). But I believe I've finally cracked the nut! To explain: Feeds are good formats because they are self describing. Update times and IDs are part of the feed body and individual entries, enabling idempotent synchronization and race-condition tie-breaks. This also means the 'X-Hub-Signature' on the body of PuSH new content notifications is sufficient for security/verification because we can ignore everything besides the body (the other headers are ignored). With the REST approach to arbitrary content types, we *need* to represent the HTTP headers in the new content notifications or else we'll have no idea what order the messages came in (Date), etc. And that's the security problem. If we rely on the headers, then we also need to verify them (to prevent replay attacks). But X-Hub-Signature only signs the body, so we're stuck. Some folks have discussed signing headers too, similar to OAuth1.0, but that lead to a lot of pain nobody wants to repeat. Others have talked about putting headers into the body (using mime multipart), but that's just another world of hurt-- the so-called Turduckin problem (thanks jsmarr for the name). The solution is to borrow from the OAuth2 playbook: Treat the X-Hub-Signature like a password/bearer token and require HTTPS for callbacks. That means for security we have these components: 1. hub.secret used by subscriber to verify the hub is authorized to post content (after delivery) 2. Subscriber's SSL cert used by Hub to verify authenticity of subscriber endpoint (before delivery) 3. SSL connection between Hub and Subscriber is encrypted, protecting the header values and preventing replay attacks (during delivery) Thus, Monica's proposal as-is does the trick. All that's left to work out are details around verbs and Link headers. I hope to bring everyone back together to build out a spec around this proposal now that I think the security issue has been solved. Hopefully we can convince GitHub to be the first implementors of it. Let me know what you think! -Brett
