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 >
