Schon seit der ersten Version von Mastodon wollte ich eine Lobeshymne auf OStatus schreiben! Sowas wie „OStatus hat auch nach über 6 Jahren an Relevanz nicht verloren“ oder „selbst nach 6 Jahren, setzen neue Plattformen mit Erfolg auf OStatus“ oder „mein 6 Jahre altes OStatus WordPress Plugin funktioniert mit nur wenigen Anpassungen auch mit Mastodon„…

Das kann ich mir jetzt leider sparen. Eugen Rochko, der Gründer von Mastodon, schrieb schon 2018:

I can’t wait until I can begin removing OStatus-related code from Mastodon. I think GNU social is the last remaining fediverse project that hasn’t yet switched to ActivityPub?

Eugen Rochko auf Mastodon

Über Patreon hat er seinen Plan jetzt nochmal konkretisiert:

[…] OStatus […] has overstayed its welcome in the code […] and now that most of the network uses ActivityPub, it’s time for it to go.

Eugen Rochko auf Patreon

…und der Pull-Request, der PubSubHubbub und Salmon ausbaut, wurde am 6. Juli ge-merged.

🙁

Wie geht’s weiter?

OStatus war wegweisend! Statt ein komplett neues Protokoll zu beschreiben, hat OStatus bestehende De-Facto-Standards in einer Spezifikation zusammen geführt. Für viele Plattformen, war es dadurch relativ einfach, OStatus einzusetzen, da sie in der Regel Teile der Spezifikation sowieso schon betrieben.

Protokoll-Übersicht von the-federation.info (Stand: 23. Juli 2019)

In den letzten Jahren habe ich aber gelernt, nicht zu sehr an Standards, Protokollen oder Technologien fest zu halten. OStatus wurde von ActivityPub eingeholt und aktuell ist GNU.social die einzige Plattform die ausschließlich auf OStatus setzt.

Zeit los zu lassen.

Ist ActivityPub die Zukunft?

Wie gerade schon geschrieben, ist es mir prinzipiell egal, welches Format sich durchsetzen wird. Mir ist nur wichtig dass sich ein Protokoll durchsetzt. Der Trend scheint zwar zu ActivityPub zu gehen… aber wer weiß?!?

Diaspora sieht bisher jedenfalls keinen Grund ActivityPub einzusetzen:

ActivityPub tries to work for everything and everyone. And because of that, they introduced a lot of flexibility and, sadly, a lot of ambiguity. Even though they tried, I found some reasons as for why we, as diaspora* developers, would not be able to build upon this new protocol without using heavily customized objects and activities.

Dennis Schubert in „ActivityPub – one protocol to rule them all?“

und vor ein paar Wochen habe ich außerdem gelesen, dass HubZilla versucht sein Protokoll Zot zu standardisieren:

Join the efforts to standardize the Zot protocol, currently used in Hubzilla and Zap platforms. This is a community initiative to push Zot adoption for federated social web.

fediverse.party

Ich bin gespannt!

— via wedistribute.org

App.net hat endlich alles nachgereicht was Dalton Caldwell vor fast genau einem Jahr versprochen hat. Die Liste kann sich echt sehen lassen:

Mal schauen was sich damit alles basteln lässt, immerhin hab ich im SCREENGUIDE-Magazin (Ausgabe 18) noch groß getönt:

Mit ein paar wenigen Änderungen und dem Support von z. B. Microformats, RSS/Pubsubhubbub, AtomPub oder Pingbacks, wäre App.net kompatibel zu fast allen Blogs oder IndieWeb-Systemen. Das hätte zum Vorteil, dass sich App.net ohne weitere Anpassungen über RSS-Reader konsumieren und über Blogging-Tools befüllen ließe. Außerdem könnten Posts und Kommentare zwischen App.net und z.B. WordPress ausgetauscht werden, ohne auf komplizierte, dezentrale Protokolle im Sinne von Diaspora oder Tent.io zurückgreifen zu müssen.

😉

via Carsten Pötter

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…

Durch einen Artikel auf ReadWriteWeb (5 Great YQL One-Liners) bin ich nach langer Zeit mal wieder auf Yahoos YQL-Plattform gelandet und habe nicht schlecht gestaunt, was die Yahoo Query Language mittlerweile alles leistet (mehr über YQL hier). Ich hatte z.B. keine Ahnung, dass man auch eigene table definition schreiben kann und dass es auch schon eine ziemlich fleißige Community um diese Definitionen gibt.

Meine Favoriten sind:

Microformats

select * from microformats where url='http://wait-till-i.com'Code-Sprache: JavaScript (javascript)

…findet diverse Microformats. » Direct Link

Mehr dazu hier: SELECT * FROM microformats

OpenID

select * from openid.discover where normalizedId="http://www.yahoo.com/"Code-Sprache: JavaScript (javascript)

…klassische OpenID-Discovery. » Direct Link

select * from openid.yadis where uri="http://www.yahoo.com/"Code-Sprache: JavaScript (javascript)

…YADIS-Discovery. » Direct Link

…und es gibt noch ’ne Reihe anderer OpenID Queries… es sollte sogar möglich sein einen kompletten OpenID-Client mit YQL zu bauen.

OAuth

select * from oauth where uri='http://example.com' and consumerKey='asd123' and consumerSecret='zxc456' and callbackUri='http://example.com';Code-Sprache: JavaScript (javascript)

…sendet einen OAuth-Request. » Direct Link

pubsubhubbub

insert into pubsubhubbub.publisher (hub_url, topic_url) values ('http://pubsubhubbub.appspot.com/publish', 'http://developer.yahoo.com')Code-Sprache: JavaScript (javascript)

…sendet ein Update an das angegebene Hub. » Direct Link

Webfinger

select * from webfinger where account='pfefferle@gmail.com'Code-Sprache: JavaScript (javascript)

…Webfinger-Discovery. » Direct Link

OpenSocial

select * from opensocial.peopleCode-Sprache: JavaScript (javascript)

…sendet eine OpenSocial People-Anfrage. » Direct Link

Social Graph API

select * from socialgraph.lookup where q = "notiz.blog" AND edo = "1"Code-Sprache: JavaScript (javascript)

…ermöglicht Zugriff auf Googles Social Graph API. » Direct Link

Atom

select * from atom where url='https://notiz.blog/feed/atom'Code-Sprache: JavaScript (javascript)

…interpretiert Atom-Feeds mit allen möglichen Erweiterungen, beispielsweise der ActivityStreams-Extension. » Direct Link

Vielleicht bekomm‘ ich die Tage ja auch mal eine Query zusammen 🙂