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.

https://micro.blog/manton/34864514

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.

Hier klicken, um den Inhalt von YouTube anzuzeigen.
Erfahre mehr in der Datenschutzerklärung von YouTube.

I 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.

Tantek Çelik – The once and future IndieWeb

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.

Es scheint wohl zum guten Ton zu gehören, dieser Tage einen Newsletter zu betreiben… und da ich das immerhin schon seit 2005 tue, dachte ich, ich mache auch mal etwas Werbung dafür!

Und ja, ich hatte schon einen Newsletter, lange bevor Newsletter cool waren!!!

Das Thema ist natürlich das „open, portable, interoperable, small, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted and federated social web“, was auch sonst.

Das Archiv mit alten Veröffentlichungen findet ihr hier und abonnieren könnt ihr ihn hier.

Viel Spaß beim Lesen 😉

Aber jetzt im Ernst: Warum sollte man einen Newsletter starten, wenn man schon ein Blog hat? Was ist der Unterschied außer die Art der Distribution?

In deutsch zu bloggen war eine bewusste Entscheidung!

Der Austausch über das „open, portable, interoperable, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted und federated social web“ findet hauptsächlich in englischer Sprache statt, und mir ist wichtig, das Thema speziell in Deutschland voranzutreiben.

Ich bin bisher aber nie wirklich davon ausgegangen, dass meine „Artikel“ auch für anders sprechende interessant sein könnten, bis Ray mir folgendes in die Kommentare schrieb:

For those of you like me who can’t read German but want to follow your blog via RSS, I found a way to have an RSS feed translated on the fly to whatever language you prefer:

https://www.labnol.org/internet/google-translate-rss-feeds/5110/

I can confirm it works following the steps listed within — Feedbin pulls in your RSS feed in english for me now! : )

Thanks for all you do,
Ray

Und was soll ich sagen… Seine Idee is großartig und super simpel… Einfach einen kleinen Service über Google Scripts bauen, der die Texte aus dem Feed automatisch übersetzt und dann wieder als Feed bereit stellt! Die Anleitung findet ihr auf labnol.org und mein etwas angepasstes Skript auf GitHub.

Ihr könnt meinen (notiz)Blog jetzt also auch auf Englisch abonnieren: https://notiz.blog/en/feed/ 😍

(Ich hab dazu auch eine Seite gebaut, die ihr unter „(en)“ im Menü findet.)

Danke Ray!

Wir haben ein kleines Weihnachtsgeschenk für euch:

Matthias Pfefferle und Marcel Weiß sprechen über (fast) alle Aspekte von RSS und warum (nicht nur) für sie Feedreader und das Ökosystem rund um RSS immer noch wichtig ist.

Hier klicken, um den Inhalt von share.transistor.fm anzuzeigen

‚Hier & Jetzt‘ kann man per RSS-Feed abonnieren und findet man natürlich auch bei Apple Podcast und in jeder Podcast-App.

RSS funktioniert am besten, wenn man nicht genau wissen muss wie es funktioniert und wenn man nicht lange nach einem Feed suchen muss.

Ich hab mal drei (vermeintliche) Verbesserungen ausprobiert um die Feeds auf meinem Blog etwas sichtbarer und nutzbarer zu gestalten.

Discovery

WordPress Posts lassen sich über diverse Mechanismen kategorisieren, sei es über Tags, Kategorien oder über Post-Formats. Gerade bei Blogs auf denen viel und zu unterschielichsten Themen geschrieben wird, kann es sinnvoll sein, nicht den kompletten Blog zu abonnieren.

Um das zu verbessern hab ich in meinem Theme zwei Dinge gemacht:

  1. Ich hab Feeds für die verschienen Post-Formats (Quote, Video, Audio, Artikel, …) gebaut.
  2. Ich hab rel-alternate Links gebaut, die die verschiedenen Feeds eines Posts (Tag-Feeds, Kategorie-Feeds und Post-Formal-Feeds) verlinken.

Wenn ihr versucht, die entsprechende Post/Blog-URL in einem gängigen Feed-Reader zu abonniert, sollten euch diese Links in einem dropdown oder ähnlichem vorgeschlagen werden.

HTML-Feeds

Chris Aldrich hat sich in einem Kommentar gefragt, ob es nicht möglich ist, den SubToMe Button, auch direkt in einem Feed zu nutzen:

This [How to style RSS feed] seems like quite a clever way of adding some human readable styling to RSS feeds. While it seems like yet another side-file, it could be a useful one. I think if I were implementing it I’d also want to include a SubToMe universal follow button on it as well

How to style RSS feed – Let’s create a beautiful RSS feed UI for human before its dead in next year again.

Also hab ich mir mal die Mühe gemacht, meinen RSS-Feed mit XSLT und CSS zu „stylen“ um dann einen SubToMe Button mit einzubauen. Mal gespannt ob es hilft!?!

/follow

Marcus Herrmann hat vor ein paar Monaten vorgeschlagen eine /feeds URL zu etablieren:

Personal website owners – what do you think about collecting all of the feeds you are producing in one way or the other on a /feeds page? You can put your blog feed there, but also RSS generated from your Twitter account (via RSS Box), Mastodon updates, or even the starred items of the feeds you consume (if you happen to use Feedbin).

Making RSS more visible again with a /feeds page

Ich finde die Idee prinzipiell gut, bevorzuge aber /follow.

Also schaut mal auf /feeds oder /follow vorbei!

Ich hoffe das hilft ein bisschen.

Falls ihr Feedback habt, ich würde mich sehr über eure Ideen freuen!

Letzte Woche war WordCamp Europe. Mit weit über 8000 Teilnehmern war es das bisher größte online WordCamp! Bei der Größe ist es klar, dass man auch eine ganze Menge neuer und interessanter Leute trifft. Also schnell auf Twitter und allen folgen!

Ich war auf dem größten online Event, von dem wohl am meisten verbreiteten Indie/OpenSource CMS und ich habe Personen, die ich dort kennen gelernt habe, über Twitter kontaktiert!

Warum?

Warum kam ich auf die Idee, Twitter zu benutzen, anstatt ihre Blogs zu abonnieren?

Auch auf den WordCamp Badges taucht lediglich das Twitter Handle auf und es wird nirgends das eigene Blog erwähnt.

WordCamp Badges mit Twitter Handle und ohne Blog-URL

Eigentlich ist die Antwort klar… Twitter ist ein soziales Netwerk dessen Kern-Kompetenz das Folgen anderer User ist. Außerdem findet der ganze Prozess an einer Stelle statt (twitter.com) und den Twitter-Handle kann man sich zudem leicht merken. Keine komplizierte Domain… keine Feed-URL… keine E-Mail Adresse… einfach nur @username

Wie sieht das Folgen oder Befreunden bei Blogs aus? Ist es das Abonnieren des Feeds? Das heraussuchen der E-Mail Adresse über das Impressum? Das Bookmarken der Kontakt-Seite?

Es gibt leider keine einfache Alternative um einem Blog zu „folgen“.

Aber gehen wir mal davon aus, das Abonnieren des Feeds käme dem am nächsten… Wie bekomme ich die richtige Feed URL heraus? Bei WordPress ist das noch relativ einfach, da die URLs standardisiert sind, aber wie sieht es mit anderen Systemen aus?

Marcus Herrmann will dazu eine /feeds URL etablieren, ähnlich wie /about, /now oder /contact.

People create more content than ever before – but siloed away in the Facebooks, Twitters, Instagrams and Mediums of the world. RSS is considered as something that can’t be monetized in our attention economy and is therefore on its way out. Even when personal blogs offer a feed, it is not obvious anymore in the browser user interface. When I stumble over an interesting blog and want to subscribe to it, I open the dev tools of my browser (which is kind of a knee jerk reaction in my profession anyway) and search the source code for a subscribable URL.

[…]

Personal website owners – what do you think about collecting all of the feeds you are producing in one way or the other on a /feeds page?

Ich mag die Idee, aber ich glaube nicht dass sie das oben beschriebene Problem löst. Es mag sein, dass es durch eine /feeds Seite einfacher ist, den richtigen Feed zu finden, es setzt aber auch voraus, dass man weiß was ein Feed, was RSS, oder was Atom ist.

Was wir eigentlich brauchen ist aber eine Art Indie-Follow oder Indie-Subscribe Button.

Chris Aldrich spricht in seiner Antwort auf Markus‘ Blogpost ein paar wichtige Punkte an.

Worse, suppose I click over to a /feeds page, as an average person I’m still stuck with the additional burden of knowing or learning about what a feed reader is, why I’d need or want one, and then knowing what RSS is and how I might use that. I might see a one click option for Twitter or Mastodon, but then I’m a mile away from your website and unlikely to see you again in the noise of my Twitter feed which has many other lurking problems.

Chris erwähnt SubToMe als bisher einzige offene Alternative, die einem Indie-Follow Button noch am nächsten kommt.

One of the best solutions I’ve seen in the past few years is that posited by SubToMe.com  which provides a single, customizable, and universal follow button. One click and it automatically finds the feeds hidden in the page’s code and presents me with one or more options for following it in a feed reader.

Damit hat er leider recht!

Hier ein SubToMe Beispiel-Button: Follow!

Es gab in den letzten 10 Jahren diverse Ideen, die ein dezentrales „Follow“ ermöglicht hätten: XAuth, WebIntents, Custom-Schemes, WebActions und Rel-Subscribe. Leider hat sich aber keines dieser Format durchgesetzt. Die Gründe dafür reichen von einem Extrem zum anderen.

Mit WebIntents wollte man die eierlegende Wollmilchsau entwickeln:

We didn’t specifically solve a single use case well other than connecting apps. The broad verb-space meant that a lot of developers wanted to design their own actions. I believe that this diluted the message of intents, and is something that if I had researched the Android ecosystem more effectively at the time, I would have probably constrained the verb eco-system to a couple of small but well defined cases.

Mozilla dagegen, hat beim Thema RSS (in meinen Augen) etwas zu schnell klein begegeben:

Die Prüfung der Nutzungsdaten und der Anforderungen zur technischen Wartung dieser Funktionen (unter Berücksichtigung der Tatsache, dass Ihnen bereits alternative Reader für RSS/Atom-Formate zur Verfügung stehen) brachte die Erkenntnis, dass die Funktionen einen unverhältnismäßig großen Aufwand in Bezug auf Wartung und Sicherheit im Verhältnis zu ihrer Anwendung erfordern.

Auf der anderen Seite hat Mozilla schon 2010 einen Artikel über „RegisterProtocolHandler Enhancing the Federated Web“ geschrieben, in dem sie aufzeigen, wie ein dezentraler Follow-Button für das Fediverse funktionieren könnte und theoretisch auch immernoch funktioniert!

Ich verstehe bis heute nicht, warum sich web+custom://scheme nicht durchgesetzt hat… Vielleicht sollte man (ich) mal einen zweiten Anlauf für ActivityPub/Mastodon starten

Vor ein paar Wochen hab ich über das titellose (Micro)Bloggen lamentiert und wie grausam es in meinem Feedreeder aussieht…

…dabei nutze ich wahrscheinlich einfach nur das falsche Tool?

NetNewsWire stellt Texte ohne Titel echt schön dar und ich könnte mir auch gut vorstellen den Reeder zu ersetzen…

ABER leider bietet NNW noch keine Möglichkeit über die Fever bzw. die Tiny Tiny RSS API zu syncen.

Mal schauen ob ich Glück habe…

Note: In NetNewsWire 5.0, Feedbin is the only sync service supported. Additional services will be supported in future 5.x releases.

ranchero.com

Die Art wie wir kommunizieren hat sich verändert. Die Flut an Informationen wird immer größer und wir nehmen uns immer weniger Zeit zum lesen und schreiben. Aus E-Mail wurde Messaging, aus Bloggen wurde Microbloggen und wir nutzen Emojis, Hashtags und andere Abkürzungen um die, so schon kurzen Texte, noch weiter zu „optimieren“.

Das ist prinzipiell auch nichts schlimmes, da sich mit jeder neuen Kommunikationsform in der Regel auch das Medium, mit dem ich es konsumiere, ändert. Messaging-Texte lese ich in Telegram und E-Mails kann ich weiterhin in meiner Mail-App lesen.

Komisch wird es aber, wenn sich Medien vermischen, oder wenn Tools versuchen unterschiedliche Medien zu normalisieren. 2011 versuchte Facebook, beispielsweise E-Mails und Messaging/Chat zu verheiraten und über eine Oberfläche nutzbar zu machen.

There are no subject lines, no cc, no bcc, and you can send a message by hitting the Enter key. We modeled it more closely to chat and reduced the number of things you need to do to send a message.

Facebook: See the Messages that Matter

Auf Facebook hat das Vorhaben auch gut funktioniert, aber über die klassiche Mail-App sah ein „Discussion-Thread“ nicht wirklich hübsch aus, weshalb das Projekt auch (zum Glück) wieder eingestellt wurde.

Aber wie komme ich auf das Thema?

Aktuell sieht es in meinem Feed-Reader folgendermaßen aus:

Reeder (RSS-Reader) auf dem iPhone

Keine Überschriften, komische Überschriften, nur das Datum oder sogar der ganze Text als Überschrift. Schuld daran ist, die Verschmelzung von Blogging und Microblogging. Oder besser: Die Nutzung eines Feed-Readers um Microblogs zu lesen.

Micro.blog ist ein Microblogging-Dienst, der 2017 über eine Kickstarter-Kampangne finanziert wurde. Micro.blog orientiert sich stark an der IndieWeb Community und unterstützt viele IndieWeb-Protokolle, wie z.B. Webmentions und Micropub. Der Service unterstützt außerdem das abonnieren von klassischen Blogs wie z.B. WordPress über das gute alte RSS Format. Und hier vermischen sich die beiden Themen.

Aus der WordPress Doku von Micro.blog:

Part of indie microblogging is getting back to the simplicity of title-less posts. When you’re writing a microblog post in WordPress, just leave the title blank, and if necessary update the post template to not include the title in HTML or the RSS feed.

Durch die IndieWeb Community veröffentlichen viele Personen in meinem Umfeld alle Arten von Texten und anderen Medien auf ihren eigenen Webseiten. Ein signifikanter Anteil von ihnen nutzt dafür WordPress und ein Teil davon wiederum meine Themes. Das heißt ich bin letztendlich sogar dreifach von diesem „Trend“ betroffen: als Konsument, als Entwickler und als Publisher.

Ich verstehe den Ansatz, den Micro.blog verfolgt durchaus:

You may find that some feed readers don’t gracefully handle posts without titles, often inserting “Untitled” for the title because they expect something to be there. If you see this, the best solution is to email the developer and ask for them to address it. Working around the issue with fake titles — dates, numbers, or portions of the text — will only ensure that client developers never improve their apps to handle title-less posts.

Apple macht es ganz ähnlich, wenn sie bei neuen iPhones die Kopfhörer-Buchse weg lassen oder bei Laptops nur noch USB-C Anschlüsse verbauen. Man könnte argumentieren, dass es der einzige Weg sei um den Fortschritt voran zu treiben, aber ich bin von den Änderungen meistens eher genervt! Ich bin nämlich derjenige der wieder neue Kopfhörer und einen &%$?§ voll Adapter braucht.

Ein ähnliches Gefühl habe ich gerade bei Microblogging über WordPress und Micro.blog. Nicht die RSS-Reader werden gezwungen sich anzupassen, sondern ich muss schauen, wie ich meine Lese- bzw. Schreibgewohnheiten verändere. Ich „muss“ mein Theme anpassen, ich „muss“ meine Schreibgewohnheiten anpassen und ich „muss“ schauen wie ich meinen Feed-Reader wieder „sauber“ bekomme.

Ich würde mir wünschen wenn Micro.blog nicht so restriktiv mit dem Interpretieren von RSS wäre und wenn es einen fließenderen Übergang gäbe.

Ich würde mich freuen, wenn ich weiterhin Titel schreiben dürfte, denn Titel sind gut für den Feed-Reader, für die sprechenden Permalinks oder einfach nur damit ich meine Artikel über die WordPress Oberfläche schneller wieder finde.

Ich würde mir wünschen, dass Micro.blog einfach immer den Text oder die Summary nutzen würde und den Titel nur als Fallback. Von mir aus auch abhängig vom Post-Type.

Aktuell gibt es für mich aber nur zwei Möglichkeiten:

  • Ich lasse den Titel weg -> Micro.blog zeigt den vollen Text an und im Feed-Reader sieht’s scheiße aus
  • Ich schreibe einen Titel -> Micro.blog zeigt nur den Titel an, aber im Feed-Reader siehts gut aus

Es gibt natürlich auch noch andere Lösungen, aber die sind immer mit Arbeit verbunden: HTTP Agent auslesen und nur für Micro.blog den Titel ausblenden, extra Feed für Micro.blog, …

Am Schluss ist Micro.blog aber nur exemplarisch für eine generelle Entwicklung in der IndieWeb Community.

Peter Molnar hat in einem ähnlichen Zusammenhang etwas sehr passendes dazu geschrieben:

If I look at my wall, my timeline, or any other stream, it’s a mess which I’m not proud of. It’s a never-ending scroll of things, without structure, without separating the less important from the more important, without me, without focus. “regaining focus” is becoming much of a buzzterm but there is truth behind it.

I want the blogs back


Wahrscheinlich sind es nicht die fehlenden Titel die mich aufregen, sondern die Flut an unstrukturierten, zusammenhanglosen Microblogposts, die ich eigentlich gar nicht in meinem Feed-Reader haben will.

…aber das ist eine andere Geschichte.

In den letzten Wochen bin ich über ein paar tolle Artikel über das Bloggen und über RSS gestolpert… Vielleicht kommt bloggen ja doch wieder in Mode und dann kann ich endlich auch mal sagen: Ich hab schon gebloggt bevor es hip war! Ich habe schon gebloggt, als es vor Jahren mal hip war, dann wieder nicht und jetzt wieder!

René Walter hat es auf seinem Blog (nerdcore.de) wunderschön auf den Punkt gebracht:

Das Problem waren schon immer und sind immer noch überfüllte Plattformen, auf denen sich die Menschen zu dicht gedrängelt um Aufmerksamkeit streiten. Lieber wieder Piratenschiffe bauen, eine Trillionbillion davon, alle anders, alle gleich.

Der andere Blogpost, den ich empfehlen möchte, ist von Brent Simmons (der übrigens auch (mal wieder) an einem großartigen Feed-Reader für den Mac arbeitet).

[…] if you think of the years 1995-2005, you remember when the web was our social network: blogs, comments on blogs, feed readers, and services such as Flickr, Technorati, and BlogBridge to glue things together. Those were great years […]

Herrlich nostalgisch 🙂

pubsubhubbub-logo

Seit ein paar Wochen scheint die Version 0.4 von PubSubHubbub relativ stabil zu sein… immerhin so stabil, dass Google und Superfeedr ihre Hubs an die neue Spec angepasst haben.

Die wesentlichen Unterschiede zu der Vorgängerversion sind:

  • Alle Datentypen werden unterstützt: Neben RSS/Atom können jetzt auch vCards, beliebige XML oder JSON Datein oder auch Bilder ge-push-t werden
  • Statt HTML/Atom-Links werden HTTP-Link-Header benutzt
  • Der Pubslisher-Prozess ist nicht mehr über die Spezifikation definiert

Für die zwei großen Hubs sollte es reichen wenn ihr eure Feed-<link />s („hub“ und „self“):

<?xml version="1.0"?>
<atom:feed>
  <link rel="hub" href="http://myhub.example.com/endpoint" />
  <link rel="self" href="http://publisher.example.com/happycats.xml" />
</atom:feed>Code-Sprache: HTML, XML (xml)

…zusätzlich über die HTTP-Header ausliefert:

HTTP/1.1 200 OK
Date: Tue, 03 Apr 2012 08:02:19 GMT
Content-Type: text/html
Content-Length: 11261
Link: <http://http://myhub.example.com/endpoint>; rel="hub"
Link: <http://publisher.example.com/happycats.xml>; rel="self"Code-Sprache: HTTP (http)

Leider ist die Version 0.4 aber nicht 100% abwärts-kompatibel… Die wahrscheinlich größte (und für mich enttäuschendste) Änderung ist das bewusste Weglassen des Publisher-Prozesses:

The publisher MUST inform the hubs it previously designated when a topic has been updated. The hub and the publisher can agree on any mechanism, as long as the hub is eventually able send the updated payload to the subscribers.

Auf der einen Seite kann das ein enormer Vorteil für Publisher sein, da Hubs in Zukunft auch per E-Mail, SMS, Pingbacks/Trackbacks oder XMPP über Updates informieren werden könnten. Auf der anderen Seite ist es aber auch sehr Wahrscheinlich, dass man für jedes v0.4 Hub eine individuelle Implementierung benötigt. Bisher unterstützen beide großen Hubs (Google und Superfeedr) aber weiterhin das alte Verfahren, also kein Grund sich jetzt schon Sorgen zu machen…

Alles in allem finde ich die Änderungen aber ganz nett und hoffe dass „Polling“ bald der Vergangenheit angehört…