Ho well... if everybody thinks it's a bad idea. Let's keep that in the spec.
It's just a bummer to see that very few (like less than 3%) of the feeds on the superfeedr hosted hubs are actually pinged using the light ping method described in the curent spec. I'd love to know the numbers for the Google hosted hub, but I feel it's going to be in the same ball park. Also, and I wanted to point this in a later post. I think it can help ease things out in the context of private feeds for which the Publisher -> Hub pings are probably going to be fat pings as it's probably easier than handling credentials... Maybe we can re-open this thread in the future :) Julien On Mon, Dec 5, 2011 at 11:20 PM, Justin Richer <[email protected]> wrote: > I would argue that for the second case, the "publish" mechanism is still > necessary, though I would also like to see a fat-ping version of this from > publisher to hub. > > I completely disagree with Julien's original thesis that publisher->hub > should be out of scope. It's a small standardization that can vastly > simplify deployments across many data sets. Basically, how else does the > publishes tell the hub "hey, I've got more stuff now"? > > -- Justin > > > On 11/23/2011 10:56 AM, Blaine Cook wrote: > >> It seems to me that there's a philosophical rift in this conversation. >> >> There are two kinds of hubs we're talking about: >> >> 1. Public service hubs, that will provide real-time distribution for >> any RSS/Atom feed on the web (Google's hub falls into this category). >> >> and >> >> 2. Private or trustred hubs, that provide real-time distribution for >> specific feeds (Superfeedr and in-house hubs fall into this category). >> >> For the first kind pings are essential and magic signatures go a long >> way towards providing trusted delivery. For the second, both of these >> are unnecessary. >> >> Perhaps another way to approach this problem would be to fork off some >> of the PSHB spec that deals with "public hubs" into its own spec, so >> that there isn't confusion when people try to repurpose PSHB for >> private distribution? >> >> b. >> >> On 22 November 2011 23:03, Jay R. [dlvr.it]<[email protected]> wrote: >> >>> On 11/22/2011 2:55 PM, Bob Wyman wrote: >>> >>> On Tue, Nov 22, 2011 at 5:34 PM, Jay R. >>> [dlvr.it]<[email protected]> wrote: >>> >>> I always found it a failing that there was no ability >>>> for the publisher to send a content blob along >>>> with their notification. >>>> >>> There is a general issue with "fat-pings" that prevents its use in many >>> contexts -- including this one. The problem is that if you allow >>> injection >>> of un-validated content into the stream, you're opening yourself up for >>> spammers and all sorts of malicious behaviors. As long as a hub *only* >>> pulls >>> data from feeds, it can have some confidence of the binding between some >>> bit >>> of data and its source. But, if data is pushed to the hub, the hub needs >>> to >>> find some alternative means to believe that what it has received was >>> really >>> published by whomever it is that claims to have published it. (i.e. that >>> it >>> *would* be found in the identified feed *if* the hub were to look there.) >>> Typically, "fat-pings" only work today in contexts where there is some >>> out-of-band means for publishers and hubs/aggregators to make private >>> arrangements such as passwords or other authentication methods. However, >>> that isn't the only way to do this: >>> This is precisely one of the reasons that I have argued for signed >>> content, >>> as with Magic Signatures, in this and similar contexts. The signatures >>> provide a means to authenticate the publisher (signer) without needing to >>> read the source feed. As such, they not only make a variety of >>> applications >>> possible (i.e. "offers") but also make it reasonable to provide fat-pings >>> that do, in fact, provide content without specific publisher/hub private >>> relationships being necessary. >>> >>> This is exactly why I said that it strays into the idea of hub chaining, >>> which has never been officially defined. Hub-to-hub communication is no >>> different than hub-to-subscriber (since one hub is a subscriber of the >>> other), where security via signatures has been defined for some time. >>> Salmon is certainly another method of obtaining the same behavior, but so >>> would any form of public key authentication. S/MIME, or PGP signatures, >>> or >>> ... >>> >>> -- >>> Jay Rossiter | Jack of All Trades >>> [email protected] | Phone: 503.896.6187 | Fax: 503.235.2216 >>> Website: dlvr.it | RSS: blog.dlvr.it | Support: support.dlvr.it >>> >>> >
