5 ms·

Excuse me Sir, but I think you didn't understand what I meant. - With today's technology, you don't need an intermediate online, 3rd party, feedreader. Devices

by antpls 8y ago

Excuse me Sir, but I think you didn't understand what I meant. - With today's technology, you don't need an intermediate online, 3rd party, feedreader. Devices can pull data from the sources. - Not only devices can pull the data, but it's often the only way to get data, since mobile operators block any incoming trafic on HTTP protocol for security reasons. - People don't need to read 1000 pieces of news in real time. - With a source and a RSS reader, there is NO HUB at all. How convenient. - For relatively static content delivery problem, CDN already exists, cache exists since decades and is already part of the base HTTP protocol. - The only thing that protocol enables so far is middle-men that will try to monopolize and control the news ecosystem, while news delivery is already free (for the end user) Bonus point : the traffic of text on internet is ridiculously small compared to video and other data. That argument is not a valid one to justify introducing another 3rd party

krn 8y ago
WebSub is not a RSS replacement, but enhancement. It's not created to be used by the end user directly. Such web feed management providers as FeedBurner[1] are pulling feeds from the origin no more than a few times per hour, causing a delay for the end user. With WebSub, publishers can update their FeedBurner feeds in real-time. [1] https://en.wikipedia.org/wiki/FeedBurner https://en.wikipedia.org/wiki/FeedBurner
- antpls 8y ago
  What makes you think people want news in real time? By the way, we can also have news in real-time by pulling RSS directly from the sources, like every 2 minutes
  - onli 8y ago
    What you are proposing is by definition not real time, it is not scalable (not on the source side, not on the client side, and not traffic wise), and it is not fast enough for things like getting notified of a new chat message where this scheme can be used as well. And people do want real time there, and often enough for news as well.
    - antpls 8y ago
      So basically, this is IRC, but the initial authors were removed, and the whole thing is less efficient because it runs over HTTP. At some point you have to go outside of the HTTP world and look for what already exists rather than reinventing the wheel. Does it solve news delivery ? RSS do that already. Does it solve instant notification and presence notification? Lower protocols already do that with lower overhead.
onli 8y ago
I'll say it straight: You really do not know what this spec is talking about, that is why you are indeed misunderstanding this. And that's the positive interpretation. By now your points amount to nonsense as they support a unsupportable position. Not one of those points has any relevance to this discussion: - This would not change - WebSub has nothing to do with mobile devices - This is not up for you to decide, and the server powering online feed reader or platforms like facebook do have a lot of data sources - That's not a point? For the type of RSS readers you are thinking about that would not change. - A CDN has nothing to do with this. - No. It is a decentralized/federated protocol, no middle man can do that. Your bonus point is invalid: The 3rd party is already there (pubsubhubbub is used in production), this is not primarily about this type of traffic reduction you are thinking about, but yes, the ressources needed to do without websub what can be done with websub on a big scale are enormous. Again, this is about enabling push architectures for server to server communication and a scalable way to achieve real time notifications. The tiny feed reader application on your smartphone is not directly related to any of this. It would not use this protocol, it can't use this protocol, and it would not stop working because of this protocol. Edit: I made this sound a bit nicer than initially. It really feels like you want to misunderstand this spec, this annoys me a bit.
- antpls 8y ago
  Sorry, but the title says "Open distributed protocol for pub sub communication", the only buzzword missing is "federation", which is by the way not used in the proposal. The difference between a proposal like ActivityPub and something like WebSub is that ActivityPub solves an actual problem of social network monopoly. The first products that come up with ActivityPub are free (Mastodon), while the products presented in this thread makes money from that protocol. In my opinion, it's sketchy.
  - VoxPelli 8y ago
    The initial protocol used by Mastodon, OStatus, used Pubsubhubbub (which is the same thing as WebSub) as it’s realtime delivery method. WebSub is a spec from the very same working group that published the ActivityPub spec and WebSub is actively used by eg. the IndieWeb movement that do indeed very much solve social network monopoly as everyone hosts their social profiles themselves there.

by antpls 8y ago

krn 8y ago

WebSub is not a RSS replacement, but enhancement. It's not created to be used by the end user directly. Such web feed management providers as FeedBurner[1] are pulling feeds from the origin no more than a few times per hour, causing a delay for the end user. With WebSub, publishers can update their FeedBurner feeds in real-time. [1] https://en.wikipedia.org/wiki/FeedBurner https://en.wikipedia.org/wiki/FeedBurner

antpls 8y ago
What makes you think people want news in real time? By the way, we can also have news in real-time by pulling RSS directly from the sources, like every 2 minutes
- onli 8y ago
  What you are proposing is by definition not real time, it is not scalable (not on the source side, not on the client side, and not traffic wise), and it is not fast enough for things like getting notified of a new chat message where this scheme can be used as well. And people do want real time there, and often enough for news as well.
  - antpls 8y ago
    So basically, this is IRC, but the initial authors were removed, and the whole thing is less efficient because it runs over HTTP. At some point you have to go outside of the HTTP world and look for what already exists rather than reinventing the wheel. Does it solve news delivery ? RSS do that already. Does it solve instant notification and presence notification? Lower protocols already do that with lower overhead.

onli 8y ago

I'll say it straight: You really do not know what this spec is talking about, that is why you are indeed misunderstanding this. And that's the positive interpretation. By now your points amount to nonsense as they support a unsupportable position. Not one of those points has any relevance to this discussion: - This would not change - WebSub has nothing to do with mobile devices - This is not up for you to decide, and the server powering online feed reader or platforms like facebook do have a lot of data sources - That's not a point? For the type of RSS readers you are thinking about that would not change. - A CDN has nothing to do with this. - No. It is a decentralized/federated protocol, no middle man can do that. Your bonus point is invalid: The 3rd party is already there (pubsubhubbub is used in production), this is not primarily about this type of traffic reduction you are thinking about, but yes, the ressources needed to do without websub what can be done with websub on a big scale are enormous. Again, this is about enabling push architectures for server to server communication and a scalable way to achieve real time notifications. The tiny feed reader application on your smartphone is not directly related to any of this. It would not use this protocol, it can't use this protocol, and it would not stop working because of this protocol. Edit: I made this sound a bit nicer than initially. It really feels like you want to misunderstand this spec, this annoys me a bit.

antpls 8y ago
Sorry, but the title says "Open distributed protocol for pub sub communication", the only buzzword missing is "federation", which is by the way not used in the proposal. The difference between a proposal like ActivityPub and something like WebSub is that ActivityPub solves an actual problem of social network monopoly. The first products that come up with ActivityPub are free (Mastodon), while the products presented in this thread makes money from that protocol. In my opinion, it's sketchy.
- VoxPelli 8y ago
  The initial protocol used by Mastodon, OStatus, used Pubsubhubbub (which is the same thing as WebSub) as it’s realtime delivery method. WebSub is a spec from the very same working group that published the ActivityPub spec and WebSub is actively used by eg. the IndieWeb movement that do indeed very much solve social network monopoly as everyone hosts their social profiles themselves there.