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
