search

w3c / websub

WebSub Spec in Social Web Working Group
https://w3c.github.io/websub/
285 stars 50 forks source link

Alternative protocols for callbacks #153

Closed crholm closed 5 years ago

crholm commented 5 years ago

I see great potential in websub for standardizing subscription through posthooks in a self describing way. What I'm curios about is if any thought has been put into alternative protocols for callbacks, and if so what the reasoning is behind only allowing HTTP POST?

I see WebSub potential in describe and manage subscriptions in general, and not only for post hooks. E.g. a lot of news agencies uses FTP as there primary way to ingest data.

Allowing hub.callback to contain different protocols would probably be beneficial, hub.callback=ftp://user:password@ftp.example.com. A similar case could be made for Email, hub.callback=smtp://user@example.com.

For this to work, my understanding is that, Link: <https://hub.example.com/>; rel="hub" would have to provide a way to describe what protocols would be acceptable as callbacks. This along with specification for verification steps for each supported protocol.

edit: I do realize that validation of subscription outside HTTP is outside w3 scope, but allowing to define protocols in Link would allow for surrounding standards for specific protocols, e.g. Link: <https://hub.example.com/>; rel="hub"; protocols="http,https,ftp,smtp"

dissolve commented 5 years ago

With SMTP / FTP how would you propose to handle a validation of intent? You can't really use the fact that the login credentials worked, as those could be compromised passwords.

The case of news organizations I could the hub accepting published updates / new articles via FTP or some other mechanism. The spec specifically avoids this to allow for that type of system, but for the subscribers to use FTP would mean that readers of the content would need an FTP server, and I don't think that's reasonable.

If you are talking about sending from a hub to a news organization, I can see them setting up their own spec outside of websub, but it was certainly not the intended use.

crholm commented 5 years ago

No sure i'm staring myself blind on my own use case here..

With SMTP / FTP how would you propose to handle a validation of intent?

As I mentioned above, the validation of intent for callback protocols, other then HTTP, should probably not be within the w3c specification, as i understand things. However validation of intent for a email subscriber would probably consist of email sent to said address with a link, as header and/or in body, referencing the hub and containing parameters callback email, topic and some random nonce generated by the hub. In regards to FTP i realize that just user/password authentication would be sub optimal. I would have to do some research in regards to this before proposing something specific.

In regards to news organisations. What I mean is that it is not uncommon that news desks have readers that ingests news from different sources and these readers are often backed by a FTP server triggering events on file uploads. Using an FTP server backed by logic on uploads is, in example, a quite common practice with in the financial industry, a old school version of posthooks.

There are many ways a subscriber might want to ingest data being pushed to it. I think what I'm getting at is that it would be have been nice to allow for other protocols within the specification and/or point to other specification for defining validation of intent and other protocol specific parts. A clear way to extend websub.

dissolve commented 5 years ago

There are many ways a subscriber might want to ingest data being pushed to it. I think what I'm getting at is that it would be have been nice to allow for other protocols within the specification and/or point to other specification for defining validation of intent and other protocol specific parts. A clear way to extend websub.

I think the general idea, though never written out, is that anything that happens after a subscriber receives the content would be the way to extend this. If there is a need for the subscriber to receive via FTP, email, or some other method, there needs to be a interim system which just takes the post request and bundles it up in to a format / protocol that the subscriber needs behind the scenes. That would keep the spec clean from having to deal with any other protocols. And would avoid conflicts of exact format of how to put it on the FTP server, file names, any other security consideration, etc.

crholm commented 5 years ago

I see your point. Putting use case of different types of callbacks outside the standard makes it cleaner. However if i'm building a something that need to support multiple types of callbacks, I can adhere to WebSub for post hooks but have to roll my own for other type that would be unique for the system. This arguable does not making things that much better off if post hooks is a minority use case for the system in question. I guess I just see how the abstract idea of a self describing way to subscribe to things as the really powerful idea, not the specifics of posthooks.