6 ms·

So I read the comments but I still don't understand what problem this specification solves. Does it enable new use cases? Does it enable new trust models? Since

by antpls 8y ago

So I read the comments but I still don't understand what problem this specification solves. Does it enable new use cases? Does it enable new trust models? Since it's only a server protocol, how do final users actually read the content? Edit : I don't understand the downvote. I use RSS daily to fetch news and I don't have problem with it. It's simple and deliver news to the edge (my mobile phone). I'm not saying WebSub is useless, I would like to understand what a 3 entities model brings to the table compared to a simple server-client delivery. What's more, the Subscriber entity cannot be a mobile device with the current network, because mobile internet providers block incoming GET requests. Therefore to fetch news, it has to be a pull model. Why not add a simple rational in the header of the spec, explaining the problem, the existing solutions, and why this new solution? Does it solve a security issue, a scalability issue or a trust issue?

rakoo 8y ago
WebSub is the successor to PubSubHubBub, which was designed to make distribution of RSS items more efficient (ie receive items as they are published on the host): - publisher would send updates, instead of having everyone poll - publisher would be protected from thundering herd if a content suddenly becomes popular - publisher and subscribers wouldn't need to exchange a full "page" of items when only one is needed
- antpls 8y ago
  > distribution of RSS items more efficient RSS is a 500kb static text file which is updated usually at most every hours. The whole file fits in server RAM and can already be served to thousands of people from cache with minimal CPU usage, or from Content Delivery Networks. A "full page of items" is easily compressed with gzip algorithms. Surely, the Internet isn't congested because of RSS...
  - fenwick67 8y ago
    Don't forget about ETags.
- MuffinFlavored 8y ago
  > - publisher would send updates, instead of having everyone poll Publisher still has to send the update to the thundering herd, no?
  - rakoo 8y ago
    No, see the diagram (https://www.w3.org/TR/websub/websub-overview.svg https://www.w3.org/TR/websub/websub-overview.svg): publisher tells the hub "here's the new content", the hub is in charge of contacting each and every subscriber telling them "here's the new content". Only the hub _could_ be overwhelmed, but it works at its own rhythm so it has more control. The thundering herd happens when you have an incontrollable influx of traffic coming in, and you have no way to regulate it.
    - antpls 8y ago
      This is ridiculous. Any big enough palteforms such as Medium or Reuters will already partner with CDN, cloud firewalls, automatic provisioning, etc to handle traffic. For small self-hosted blogs, authors can pay a CDN that will absorb any exceptional loads and almost cost nothing the rest of the time. Eventually the blog will go down for 24h and will be back online when things get calmer. The idea of creating a hub that will be a central point is the opposite of distributed information.
      - deleted 8y ago
        [deleted]
      - VoxPelli 8y ago
        Funny that Medium then decided to buy a company that was built around WebSub and was founded by one of the authors of the spec: https://techcrunch.com/2016/06/02/super-to-medium/ https://techcrunch.com/2016/06/02/super-to-medium/ Seems like they do find some use for it? (As does eg Google who has it as the preferred real-time deliver mechanism for sitemaps.)
        antpls 8y ago
- saurik 8y ago
  This sounds great in principle, but this is 2018... virtually none of the use cases for RSS can be replaced by something which requires the consumer to be online and capable of receiving an HTTP POST (which isn't possible on the web platform at all, so this shouldn't be called WebSub). To the extent to which a "thundering herd" ever existed for RSS, it was from large numbers end users with normal computers behind firewalls constantly checking the feed, which is an environment where this protocol has no hope of ever being applicable. So far, no one on this entire thread has descried a single use case where WebSub actually provides value. Someone mentioned that theoretically a service like Facebook could use this for Facebook, but then they themselves linked to a page on Quora with an explanation from someone at Facebook for why they tested out PubSubHubbub and then gave up on it which stated that he "think[s] the benefits of adopting PubSubHubbub are less clear" for this very issue (that it is inherently a server-to-server protocol, where there wasn't really a problem in the first place).
  - rakoo 8y ago
    Are you saying that webhooks have no purpose in 2018 ? Because while WebSub was created as an effort to help RSS get more realtime, it's a more generic architecture for publishers who have content and need to notify interested subscribers.
    - antpls 8y ago
      What we are saying is : In the attempt at understanding the use cases of this proposal, people said in the thread webhooks were created to replace RSS+GET pull, as an "enhancement". As we are trying to explain : this proposal doesn't cover all use cases of RSS+GET pull, so it should not be considered a replacement of RSS nor an enhancement of it. If WebSub has a purpose (if any), many people fail to explain a valid one. Does it worth wasting the resources of the W3C for such proposal? The "world wide web" is wide, and doesn't only include servers
      - rakoo 8y ago
        > people said in the thread webhooks were created to replace RSS+GET pull That's the root of our misunderstanding then: never was PubSubHubbub _replacing_ RSS+GET pull, it was supposed to _help_ it for people who want notifications, on top of the existing system.
slim 8y ago
If you subscribe to 1000 RSS feeds, it could take a while to update your feeds. Whereas with pubsub it's like all your feeds are merged and you can get a full update in one transaction. It's way more efficient at scale (I.e. when feeds are actual people, like in social networks)
- antpls 8y ago
  > If you subscribe to 1000 RSS feeds I'm subscribed to about 40 RSS feeds on my mobile phone, and I don't even have the time to read everything. > It's way more efficient at scale (I.e. when feeds are actual people, like in social networks) Could you show me basic math to prove that? Firms such as Facebook and Reuters already operates at world scale, and don't need a new protocol to deliver news.
  - onli 8y ago
    They actually already use protocols like this. I did not dive into the differences yet, but so far it just seemed to be a more open spec of pubsubhubbub, and that would be very useful.
    - antpls 8y ago
      No they dont. I use an offline mobile feed reader which pulls RSS feeds directly from the sources and it doesn't require any 3rd parties, like Flipboard, Feedly and others. RSS with a simple pull GET request is actually more OPEN than this proposal.
      - onli 8y ago
        You're just wrong. Platforms like Facebook already use protocols like this for their content propagation. This has nothing to do with your offline mobile feed reader. > RSS with a simple pull GET request is actually more OPEN than this proposal. It is not. Also, Websub does not change anything for clients just directly fetching the RSS feed.
krn 8y ago
WebSub enables real-time web (push instead of pull). Like WebSockets, it's a protocol, not a technology. It's designed to be used in creating new technologies. One such example: https://superfeedr.com/tracker https://superfeedr.com/tracker
- antpls 8y ago
  I'm glad the proposal is useful to actual businesses. However, it now seems WebSub was created to add a middle-man that will a) read all your activities and b) take a transaction fee on every update?
  - onli 8y ago
    Where do you take that from? Everyone can run a hub and pubsubhubbub hubs were generally free. Also, no, it won't read your activity. All a hub sees is that a site published an entry and that a feedreader - which can serve millions of users on its own - wants to be notified of that. Hardly confidential information.
    - antpls 8y ago
      In that context a feedreader (like feedburner) is a Subscriber, right? But then millions of users have still to potentially pull the data from the feedreader, because they can't implement WebSub, because they have limited connectivity and can only pull content. In the end, how is that different than a blog pushing a RSS file to a CDN?
      - onli 8y ago
        Ah, I think I see where your problem comes from. Again, I'm not too deep into WebSub, but I know the predecessor quite well. This spec solves a specific problem. You have one URL resource many clients are interested in, that URL gets occasional updates, many clients want to fetch that new content. Think RSS feeds. so far, every client had to pull, meaning look at the file again and again and see whether there is a new update. Think a bit about that and you see how that is hard to do on client side (comparing content, making sure new stuff is really new and not just reordered, storing the old file, etc). Normally, those clients are servers. That's really important to understand, without that knowledge WebSub makes no sense. Push-based protocols solve that problem with a middleman, the hub. Whenever there is an update the original server sends one single POST to the hub, the hub then sends that notification to all subscribers. And wush, no more polling. The end result is way less traffic on the lines, way easier architecture on the feedreader side (it can be not built on a polling infrastructure, instead it just has one webhook open, and when it gets notified of an update it fetches the source once), less server load on the origin. For blogs for example that really is relevant. This has nothing to do with a CDN.

by antpls 8y ago

rakoo 8y ago

WebSub is the successor to PubSubHubBub, which was designed to make distribution of RSS items more efficient (ie receive items as they are published on the host): - publisher would send updates, instead of having everyone poll - publisher would be protected from thundering herd if a content suddenly becomes popular - publisher and subscribers wouldn't need to exchange a full "page" of items when only one is needed

antpls 8y ago
> distribution of RSS items more efficient RSS is a 500kb static text file which is updated usually at most every hours. The whole file fits in server RAM and can already be served to thousands of people from cache with minimal CPU usage, or from Content Delivery Networks. A "full page of items" is easily compressed with gzip algorithms. Surely, the Internet isn't congested because of RSS...
- fenwick67 8y ago
  Don't forget about ETags.
MuffinFlavored 8y ago
> - publisher would send updates, instead of having everyone poll Publisher still has to send the update to the thundering herd, no?
- rakoo 8y ago
  No, see the diagram (https://www.w3.org/TR/websub/websub-overview.svg https://www.w3.org/TR/websub/websub-overview.svg): publisher tells the hub "here's the new content", the hub is in charge of contacting each and every subscriber telling them "here's the new content". Only the hub _could_ be overwhelmed, but it works at its own rhythm so it has more control. The thundering herd happens when you have an incontrollable influx of traffic coming in, and you have no way to regulate it.
  - antpls 8y ago
    This is ridiculous. Any big enough palteforms such as Medium or Reuters will already partner with CDN, cloud firewalls, automatic provisioning, etc to handle traffic. For small self-hosted blogs, authors can pay a CDN that will absorb any exceptional loads and almost cost nothing the rest of the time. Eventually the blog will go down for 24h and will be back online when things get calmer. The idea of creating a hub that will be a central point is the opposite of distributed information.
    - deleted 8y ago
      [deleted]
    - VoxPelli 8y ago
      Funny that Medium then decided to buy a company that was built around WebSub and was founded by one of the authors of the spec: https://techcrunch.com/2016/06/02/super-to-medium/ https://techcrunch.com/2016/06/02/super-to-medium/ Seems like they do find some use for it? (As does eg Google who has it as the preferred real-time deliver mechanism for sitemaps.)
      - antpls 8y ago
saurik 8y ago
This sounds great in principle, but this is 2018... virtually none of the use cases for RSS can be replaced by something which requires the consumer to be online and capable of receiving an HTTP POST (which isn't possible on the web platform at all, so this shouldn't be called WebSub). To the extent to which a "thundering herd" ever existed for RSS, it was from large numbers end users with normal computers behind firewalls constantly checking the feed, which is an environment where this protocol has no hope of ever being applicable. So far, no one on this entire thread has descried a single use case where WebSub actually provides value. Someone mentioned that theoretically a service like Facebook could use this for Facebook, but then they themselves linked to a page on Quora with an explanation from someone at Facebook for why they tested out PubSubHubbub and then gave up on it which stated that he "think[s] the benefits of adopting PubSubHubbub are less clear" for this very issue (that it is inherently a server-to-server protocol, where there wasn't really a problem in the first place).
- rakoo 8y ago
  Are you saying that webhooks have no purpose in 2018 ? Because while WebSub was created as an effort to help RSS get more realtime, it's a more generic architecture for publishers who have content and need to notify interested subscribers.
  - antpls 8y ago
    What we are saying is : In the attempt at understanding the use cases of this proposal, people said in the thread webhooks were created to replace RSS+GET pull, as an "enhancement". As we are trying to explain : this proposal doesn't cover all use cases of RSS+GET pull, so it should not be considered a replacement of RSS nor an enhancement of it. If WebSub has a purpose (if any), many people fail to explain a valid one. Does it worth wasting the resources of the W3C for such proposal? The "world wide web" is wide, and doesn't only include servers
    - rakoo 8y ago
      > people said in the thread webhooks were created to replace RSS+GET pull That's the root of our misunderstanding then: never was PubSubHubbub _replacing_ RSS+GET pull, it was supposed to _help_ it for people who want notifications, on top of the existing system.

slim 8y ago

If you subscribe to 1000 RSS feeds, it could take a while to update your feeds. Whereas with pubsub it's like all your feeds are merged and you can get a full update in one transaction. It's way more efficient at scale (I.e. when feeds are actual people, like in social networks)

antpls 8y ago
> If you subscribe to 1000 RSS feeds I'm subscribed to about 40 RSS feeds on my mobile phone, and I don't even have the time to read everything. > It's way more efficient at scale (I.e. when feeds are actual people, like in social networks) Could you show me basic math to prove that? Firms such as Facebook and Reuters already operates at world scale, and don't need a new protocol to deliver news.
- onli 8y ago
  They actually already use protocols like this. I did not dive into the differences yet, but so far it just seemed to be a more open spec of pubsubhubbub, and that would be very useful.
  - antpls 8y ago
    No they dont. I use an offline mobile feed reader which pulls RSS feeds directly from the sources and it doesn't require any 3rd parties, like Flipboard, Feedly and others. RSS with a simple pull GET request is actually more OPEN than this proposal.
    - onli 8y ago
      You're just wrong. Platforms like Facebook already use protocols like this for their content propagation. This has nothing to do with your offline mobile feed reader. > RSS with a simple pull GET request is actually more OPEN than this proposal. It is not. Also, Websub does not change anything for clients just directly fetching the RSS feed.

krn 8y ago

WebSub enables real-time web (push instead of pull). Like WebSockets, it's a protocol, not a technology. It's designed to be used in creating new technologies. One such example: https://superfeedr.com/tracker https://superfeedr.com/tracker

antpls 8y ago
I'm glad the proposal is useful to actual businesses. However, it now seems WebSub was created to add a middle-man that will a) read all your activities and b) take a transaction fee on every update?
- onli 8y ago
  Where do you take that from? Everyone can run a hub and pubsubhubbub hubs were generally free. Also, no, it won't read your activity. All a hub sees is that a site published an entry and that a feedreader - which can serve millions of users on its own - wants to be notified of that. Hardly confidential information.
  - antpls 8y ago
    In that context a feedreader (like feedburner) is a Subscriber, right? But then millions of users have still to potentially pull the data from the feedreader, because they can't implement WebSub, because they have limited connectivity and can only pull content. In the end, how is that different than a blog pushing a RSS file to a CDN?
    - onli 8y ago
      Ah, I think I see where your problem comes from. Again, I'm not too deep into WebSub, but I know the predecessor quite well. This spec solves a specific problem. You have one URL resource many clients are interested in, that URL gets occasional updates, many clients want to fetch that new content. Think RSS feeds. so far, every client had to pull, meaning look at the file again and again and see whether there is a new update. Think a bit about that and you see how that is hard to do on client side (comparing content, making sure new stuff is really new and not just reordered, storing the old file, etc). Normally, those clients are servers. That's really important to understand, without that knowledge WebSub makes no sense. Push-based protocols solve that problem with a middleman, the hub. Whenever there is an update the original server sends one single POST to the hub, the hub then sends that notification to all subscribers. And wush, no more polling. The end result is way less traffic on the lines, way easier architecture on the feedreader side (it can be not built on a polling infrastructure, instead it just has one webhook open, and when it gets notified of an update it fetches the source once), less server load on the origin. For blogs for example that really is relevant. This has nothing to do with a CDN.