On Thu, May 20, 2010 at 11:14 PM, Bob Wyman <[email protected]> wrote: > Right. As Julien says, the silliness with light-pings to the hub followed by > polling for updates on the feed is only there in order to make it harder for > people to spoof the system. There are a variety of alternatives to this > approach, but a light-ping and fetch method it is certainly the simplest to > implement and thus probably always needs to be supported even if more > complex approaches are used.
Agreed. Definitely not advocating that light-pings not be included. > Personally, I hope that we'll one day be able to see support for fat-pings > using something like the signed entries that Salmon produces. (Actually, I > would prefer if people would just use the DSig stuff that is defined in > Atom, but the reality is that that approach simply seems too hard for many > developers and I've given up on trying to convince anyone to use it. There > are all sorts of problems with getting certificates, the canonicalization is > hard, many elements are confusing, etc... The intent of Salmon's Magic > Signatures is to make signing stuff as simple as conceivably possible > without loosing too much of what a signature is supposed to do for you. I > think it succeeds and I think Magic Sigs, with just a few minor extensions > and support from WebFinger, will be able to handle the vast majority of > signature needs -- although not all.) Having implemented dsig and encryption support for Atom in Abdera, I don't buy the argument that it's too complicated. The tooling support for XML-DSig's isn't great, but any solution that adequately secures Atom docs is going to suffer from many of the same fundamental issues. Sure, we might be able to simplify the problem in various ways, but in so doing we end up building a less secure system. That said... the ability to digitally sign HTTP requests/responses independently of Atom could likely make this a whole lot easier as it would move those details out of the data format and keep us from having to muck around with the XML at all. > If "signed" fat-pings are too complex, there are all sorts of mechanisms by > which publishers and the hub could pass secrets back and forth to convince > each other that they knew who they were talking to... > There should be no question that a fat-ping approach would have real > benefits. Heck, in various forums, a number of us have been working on > fat-ping proposals of one kind or another for something like seven or eight > years now... (Do you remember "FeedMesh?") Eventually, we'll figure it out. > bob wyman Oh yeah, definitely not a new idea, lol, but one that qualifies for It's-About-Friggen-Time-We-Make-This-Work. - James > On Fri, May 21, 2010 at 1:36 AM, Julien Genestoux > <[email protected]> wrote: >> >> James, >> The "fat" ping from a publisher is definitely doable. Superfeedr does that >> with some of its publishers, but we need ways to enforce that nobody is >> actually trying to forge the relationship. It's doable, but on a per >> publisher basis, so I think the protocol is right to define a way that >> _always_ work. >> For the rest of the post, I'm not so competent, so I won't comment :D >> Cheers! >> On Thu, May 20, 2010 at 8:20 PM, James M Snell <[email protected]> wrote: >>> >>> Posted some thoughts here: >>> http://www.snellspace.com/wp/2010/05/pubsubhubbub-thoughts >>> >>> DeWitt requested that I also post here to make sure it was seen. >>> Hopefully the comments are useful. >>> >>> - James >> > > -- - James Snell http://www.snellspace.com [email protected]
