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. bob wyman On Tue, Nov 22, 2011 at 5:34 PM, Jay R. [dlvr.it] <[email protected]> wrote: > On 11/22/2011 2:13 PM, Julien Genestoux wrote: > > Jay, > > I think the spec should say something like : "The publisher MUST inform > the hub about new content." without which, obviously the protocol won't > work. However the "how" should be left outside the protocol, or may be > something like "the hub MAY implement method X to get notifications". > I think one of the "design" principles of the protocol was that > subscribers should not care which hub a feed is using as their subscription > should work with *any* hub. On the other end, since the publisher > designates a *specific hub*, the hub and the publisher can agree on the > method they want to use without affecting anyone else. > In other words : there should be no coupling between subscribers and hubs, > no coupling between subscribers and publishers, but since there is coupling > (thru the discovery) between the hub and the publisher no matter what, we > should probably not spec it. Does it make sense? > > > Honestly, no - it doesn't make sense to me. The whole point of the > specification is to define expected behaviors universally. If a hub wants > to enable alternate discovery methods outside of the specification, there's > nothing preventing that, but I believe that having this defined is of > significant benefit to publishers. No matter what hub they use, they > always know that whatever software they implemented for notification will > continue to work. The publish method is ubiquitous at that point - there's > no guesswork for anyone involved. If made optional then every hub may > institute different policies which are *not* universal. > > By leaving update discovery methods up to each implementation, you're > enabling user lock-in because they won't want to go through the extra work > required by whatever their new hub might implement. > > I always found it a failing that there was no ability for the publisher to > send a content blob along with their notification. In essence this turns > the publisher into a pseudo-hub, however they're only distributing to the > central hub, not directly to clients (and without adding hub discovery). > This becomes important in situations where publishing content may be behind > a time-delay on file updates. (e.g. a CDN, etc.) In the end, this just > turns toward the discussion of hub chaining (which has never been defined), > not general purpose publishing. > > -- > Jay Rossiter | Jack of All Trades > [email protected] <[email protected]> | Phone: 503.896.6187 | Fax: 503.235.2216 > Website: dlvr.it | RSS: blog.dlvr.it | Support: support.dlvr.it >
