Just noticed all my superfeedr #websub subscriptions just stop sending updates, and all the Wordpress feeds using pushpress have a broken websub implementation that hasn't been fixed for years now.
If you have a protocol that to all intents and purposes only Google uses, is it officially on life support?
Almost done: https://source.toby3d.me/toby3d/hub
The websub.rocks tests are passed, all that remains is to add #SQLite3 storage, since the #WebSub hub currently stores all its subscriptions in memory.
The plan is to add a statistics page for topics and softer delivery of stuck subscriptions not every second, but with delays in steps twice as long as the previous one.
I couldn't sleep, I wanted to bring boredom by programming. I ended up staying up all night and all day, completely rewriting my #WebSub hub and am ready to roll it out this week. why
So...is #websub worth it? There are 3 things it aimed to achieve:
1. More accurate than polling
2. More efficient than polling
3. More efficient than fetching
2. fails, because if a publisher does not ping you, you don't know if it's down or there aren't feeds. You need to poll anyway to be sure.
3. fails, for reasons I've given above. You can't rely on fat pings being accurate so you need to fetch anyway to be sure.
Only 1. succeeds, occasionally giving an up-to-date "ping".
...
However, a full fetch may also miss items, b/c items are often removed from the feed (sometimes they want to paywall older feeds, sometimes there's a legal reason e.g. DMCA takedown).
The #websub spec does not tell us how we can identify between a full fat ping and a diff fat ping. This is a huge flaw IMHO, as it makes all fat pings unreliable: we could accidentally delete items. The only canonical source is the full content from the topic URL.
Back to trying to figure out #websub fat vs thin pings.
So...the point of fat pings is to avoid "thundering herds" i.e. all subscribers get a notification and fetch from the source at the same time.
But, when looking at websub POSTs the full RSS/Atom content would be missing items sometimes, b/c the publisher is sending just latest items. (cont....)
Looking further into WebSub: It's very unclear how the fat vs thin pings works - if a "thin" ping, just send an empty body, and let the subscriber fetch from the topic URL, a "fat" ping should be the Atom/RSS doc.
That's all good, but then I noticed some feeds just send a "diff" of the latest item...which confuses things a lot, because many publishers want to indicate which items are to be removed from the feed (deleted or behind paywall etc) so how can we tell?
So...pubsubhubbub - the largest websub hub - does not follow the w3c spec:
"If the hub URL supports WebSub and is able to handle the subscription or unsubscription request, it MUST respond to a subscription request with an HTTP [RFC7231] 202 "Accepted" response to indicate that the request was received"
According to the spec, any client error should return a 4**.
Instead it returns a 200, with no verification callback sent...
Podping for notifications of podcast updates? On a blockchain? Noooo!
There is #websub !
#websub #pc20 #podcasting #fosdem
One thing I love about working in #golang is the tremendous set of high-quality libraries already out there. My design philosophy for emissary.social has been to build to every standard and protocol out there. That is only possible because I don’t have to write #SSE, #MicroFormats, #WebSub, #WebMentions, etc all from scratch.
#golang #sse #microformats #websub #webmentions
Maybe I should be looking into #ActivityPub's relationships with #WebSub (formerly #PubSubHubBub) and whether major platforms like Mastodon support it both as a hub and as a subscriber. I'm wondering if this could be used as a strategy you reduce bandwidth, number of connections and possibly server load, by preparing static files that subscriber servers could fetch instead of getting one update per action pushed by the hub.
#pubsubhubbub #websub #activitypub
@benbrown @anildash Not really *needs*, the original model of RSS is that the reader polled direct. You only need a hub if you want all your readers/clients synced. Some get around this by using cloud storage for subscription lists and read markers, but there’s no interoperable for that method.
#WebSub (formerly #PubSubHubBub, a/k/a #PuSH) addresses this by providing hubs to ping that send callbacks to subscribers.
@anildash Still hoping for a grand #ActivityPub + #WebSub + #Webmention unification so All Are One.
#activitypub #websub #webmention
@rysiek@mastodon.technology https://fed.brid.gy/ (#websub) I tested it, I was able to subscribe at my site via that address @hugo.soucy.cc
I'm still stuck looking at #websub, and also #jsonfeed, trying to work out if they're sensible to apply for moving data around.
WebSub, and JSON Feed both heavily give blogs as examples, I think technically, WebSub should be great for moving data between services, providing you take a loose interpretation of the standard...
Anyone had any experience with #websub? I'm thinking about trying to use it to connect some web services in a somewhat standard way.
RT @t@twitter.com
#WebSub is now a @W3C Recommendation!
https://www.w3.org/TR/2018/REC-websub-20180123/
Supported by @Google@twitter.com @WordPress@twitter.com etc. #implementnow
Congrats @Julien51 @aaronpk!
So stop polling so much,
start SUBscribing to WEB pages for changes!
#openweb #indieweb #webstandards… http://tantek.com/2018/024/t4/websub-recommendation
#websub #implementnow #openweb #indieweb #webstandards
به نظر میرسه یکی از بزرگترین تغییرات مثبتی که #ماستدون در دنیای کامپیوتر ایجاد کرد این بود که باعث شد نام پروتکل PubSubHubbub تغییر پیدا کنه به WebSub. دستکم الان اگه کسی بخواد براتون بگه که نوتیفیکیشنهای ماستدون بر اساس چه پروتکلی کار میکنن، شما فکر نخواهید کرد که یارو دیوانه است.
https://en.wikipedia.org/wiki/WebSub
#Mastodon #WebSub