Exactly. I think that the specification should assume the most decentralized case, as this is the broadest and the most beneficial case on the open Web. This case is the one in which the publisher, subscriber and hub all belong to different organizations. Assuming that some two of the three are a part of the same organization and that therefore a specification isn't required for the interaction between those two, or that interaction is defined by other non-standardized means, doesn't do much for increasing interoperability on the Web. That's why I'm with Jay.
However, IMO and as Blaine said, this may be just an issue which may be solved by rewording or splitting up the spec. IMO, the spec should state that hubs have two interfaces - the publisher interface and the subscriber interface. Furthermore, the spec should explain that a spec-compliant hub may implement a) only the publisher interface, b) only the subscriber interface, c) both interfaces. In other words, a hub, if it does not want to be open to cross-organizational publishers (with regard to the PSHB spec), may implement only the subscriber interface, as Julien originally suggested. I think we could also come up with use cases in which a hub implements only the publisher interface of the spec, while the subscriber interface is defined by other means (e.g. company hubs that filter received posts before delivering them to employees via XMPP). In both cases, I would say that the hub is spec-compliant with regard to the specific interfaces it implements. If the hub doesn't want to promote the standardized and open usage of its interface - it doesn't have to. But both interfaces should be defined by the specification or extensions of the specification. Best, Ivan On Wednesday, November 23, 2011 4:56:09 PM UTC+1, 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 > > > >
