Recent searches
Search options
Administered by:
#websub
Question: Is WebSub (formerly PubSubHubBub) still relevant these days? And if so, to what extent?
Edit: I totally forgot to say why I'm asking. I'm cleaning up old blog settings and plugins, and wondering whether it's worth keeping the WebSub support or not.
Personally, I advocate for users directly owning and publishing content to subscribers with optional relay intermediaries, but nobody's asking me.
This would ask more of users, but agency must be seized. It is not given.
#activitypub #bluesky #socialmedia #websub #mastodon #atprotocol
The new poller is humming along nicely, parsing and fetching articles, for all #websub updates.
I've just pushed some additional patches which makes assigning cover images for articles more reliable.
It also includes a patch for correctly assigning the author name when included as a ”`dublinCore` struct.
Several commits later, the new poller service is running live, in production, handling half of all #websub traffic coming to the Elytra servers.
The service is also humming along nicely, using very little resources on the server.
The single server (512MB, 2 v-cores) is now hosting:
- API
- Neptune (Full-text extractor)
- Poller (WebSub only for now)
ActivityPub – The evolution of RSS
Dave Winer (@davew) stellt (sich) auf seinem Blog und auf Mastodon die Frage:
What does ActivityPub does that RSS doesn’t?
und nimmt vorweg:
Off the top of my head, it’s not the ability to syndicate, RSS already does that. I can follow anyone on any server.
Es macht natürlich Sinn, erstmal zu klären was RSS ist und kann, um auf die Vorteile von ActivityPub einzugehen!
Also RSS steht für „Really Simple Syndication“ und ist eine Art „Digitale Einbahnstraße“, so zu sagen der Newsletter oder Podcast für Texte auf Webseiten. Und weil es dem Podcast so ähnlich ist (und eigentlich auch dessen technische Basis) nennt es Dave Winer auch neuerdings „Textcasting„, was ich großartig finde!
Applying the philosophy of podcasting to text.
Und technisch gesehen ist das auch der große Unterschied zu ActivityPub. Während ich bei Textcasting, Texte nur abonnieren kann, habe ich durch ActivityPub auch einen Rückkanal, der mir ermöglicht, die Texte auch zu liken, mit meinen Freunden Followern zu teilen und zu kommentieren!
In den Kommentaren zu Daves Mastodon Post wird auch fast ausschließlich über diese technischen Aspekte diskutiert. Es geht um Push vs. Pull und immer wieder darum, dass RSS ja eigentlich vollkommen ausreichend und viel simpler ist.
@manton fasst es ganz gut zusammen:
I think RSS + Webmention (for sending replies) gets you 90% of the way there. ActivityPub does provide a comprehensive framework for the rest, though, and perhaps follows modern social network conventions more closely, e.g. liking posts, approving follows.
Aber ist die Technik das, was hier wirklich den Unterschied macht?
Die Diskussion erinnert mich sehr an den RSS vs. Atom „War“, von dem @tantek.com in einem IndieWeb Vortrag spricht.
Inhalt von YouTube anzeigenHier klicken, um den Inhalt von YouTube anzuzeigen.
Erfahre mehr in der Datenschutzerklärung von YouTube.
Inhalt von YouTube immer anzeigen
„Tantek Çelik – The once and future IndieWeb“ direkt öffnenI saw the best minds of my time waste our time arguing about syndication formats, arguing about plumbing, user don’t care about plumbing but for some reason we thought that that mattered, we thought that actually really mattered which XML tags to use in RSS versus Atom. […] So we focused on the wrong things we argued about plumbing instead of user experience.
Vielleicht kommt man mit RSS, WebSub und Webmentions auf ein relativ ähnliches Ergebnis und es ist technisch gesehen wahrscheinlich auch etwas einfacher umzusetzen… Aber sind RSS und ActivityPub wirklich so weit auseinander?
Für mich ist ActivityPub einfach nur die logische Weiterentwicklung, oder auch die nächste Generation von RSS. Wer sich die erste Version von ActivityStreams (das Format, welches ActivityPub benutzt um Aktivitäten auszuzeichnen) etwas genauer ansieht, erkennt vielleicht ein alt bekanntes Format.
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:activity="http://activitystrea.ms/spec/1.0/"> <id>tag:photopanic.example.com,2009:photo/4352</id> <title>My Cat</title> <published>2010-11-02T15:29:00Z</published> <link rel="alternate" type="text/html" href="..." /> <activity:object-type>photo</activity:object-type> <activity:verb>post</activity:verb></entry>Code-Sprache: HTML, XML (xml)ActivityStreams wurden 2011 als Namespace für Atom definiert um RSS/Atom Feeds mit Informationen anzureichern, die man aus den sozialen Netzwerken kennt. Das ist hauptsächlich der object-type um neben Texten auch Bilder oder Videos auszuzeichnen, und verb um klar zu machen um was für eine Aktion es sich genau handelt.
OStatus, der Vorgänger von ActivityPub, benutzte übrigens genau dieses Format um Aktivitäten auszuzeichnen!
Erst 6 Jahre später wurde die Version 2.0 als reines JSON Format veröffentlicht, was aber auch Sinn macht, da JSON das Format ist, welches moderne APIs eben sprechen.
Das heißt ActivityStreams ist im Prinzip eine moderne Form von RSS und ActivityPub ist einfach „nur“ ein PubSub System welches drumherum gebaut wurde.
Aber zurück zur Usability!
Die Frage ist für mich nicht RSS oder ActivityPub… Die wesentlich interessantere Frage ist: Feed-Reader oder Mastodon?
Die RSS oder IndieWeb Community (und ich zähle mich zu beiden, es geht hier nicht um Blaming) hat bisher leider kein massentaugliches Tool etabliert, welches mit der Usability und Reichweite von Mastodon (und Mastodon ist hier nur exemplarisch für eine Fediverse Platform… Pixelfed, Misskey und andere machen einen ähnlich guten Job) mithalten kann. Mastodon ermöglicht das dezentrale folgen, abonnieren, kommentieren, liken und sharen in einer simplen Oberfläche. Kein RSS-Reader, den man zum Kommentieren verlassen muss und kein IndieWeb-Reader, der eine eigene Webseite mit diversen Login- und Ping-Mechanismen voraussetzt!
Mastodon zeigt außerdem sehr deutlich dass Technik austauschbar ist, immerhin ging die Plattform 2016 mit OStatus an den Start und schwenkte erst zwei Jahre später auf ActivityPub!
Ich beschäftige mich jetzt seit ungefähr +/-15 Jahren mit dem Thema, welches man heute als Fediverse oder IndieWeb zusammen fassen würde, und habe auch ein gutes Jahrzehnt an Arbeit in diverse IndieWeb Projekte gesteckt, aber Mastodon und ActivityPub sind in ihren Auswirkungen bisher konkurrenzlos!
Dank Mastodon und ActivityPub habe ich wieder bis zu 50 Kommentare auf einen einzigen Blog-Post (Likes und Boosts nicht mit gezählt) während über RSS (gemessen an Kommentaren über das WordPress Formular) und Webmentions vielleicht eine Reaktion im Monat kommt.
Reading for the first time about #WebSub use cases: https://www.w3.org/TR/websub/
Thinking about how this can be useful to implement together with FreshRSS... Looks promising.
@Kye Yes. Protocol-agnostic Federation is certainly the path forward. And now in 2024, there are different “bridge” apps out there that let you publish/subscribe across several protocols.
#BridgyFed is probably the best known and most robust at the moment.
I’m also building a library for #Emissary that makes #RSS and #WebSub look like #ActivityPub to the rest of the app. It’s great, and I’m excited to add more (like #ATProtocol) in the future.
@tchambers Not sure how relevant an activity oriented protocol like #ActivityPub would be for e-commerce sites.
Real time broadcasting through #WebSub + semantic markup like #hProduct / #relPayment = distributed storefront, then ActivityPub to share your purchases?
I also think schema.org already has semantics for this that eg Google digest for its e-commerce search?
RSS/Atom endangered species? https://en.wikipedia.org/wiki/Web_feed If you believe so then move on. I hear #WebSub Rocks! https://websub.rocks
ActivityPub is tops, for all it’s flaws.
Skip #Nostr, too. It’s web3 cryptobros all the way down.
#Scuttlebutt seems interesting, but I haven’t done a deep dive.
I am a fan of #RSS and #WebSub, which give you many #ActivityPub features (except comments) for 5% of the hassle. You could say the same for #IndieWeb APIs, like #WebMentions and #MicroFormats, which are awesome, but the community seems even less organized than the ActivityPub community (if that’s possible)
@hmans Could be that they are lazy fetching it or something
I was quite amazed to see issues like this be totally left to the implementers of #ActivityPub
Especially as #PubSubHubbub / #WebSub which #OStatus and other predecessors use (and the #IndieWeb still use) was specifically designed to avoid thundering herd problems that arise from a lot of subscribers all eagerly fetching content at once upon receiving a ping about new content
@maffeis #ActivityPub is for federation whereas #micropub and #microsub are for interacting with your instance, so they are not really exclusive though.
Micropub is already supported by tools like micro.blog, @ia Writer and such.
Not sure if anyone has implemented it on top of an ActivityPub backend though.
#Webmention, #WebSub and #Microformats would be the more direct #IndieWeb “competitor” to ActivityPub, but eg @snarfed.org and @pfefferle are both showing that the two can be bridged
Just found out about #PubSubHubbub and now I'm outraged the W3C renamed it to #WebSub
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
Podping for notifications of podcast updates? On a blockchain? Noooo!
There is #websub !
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.
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.
