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.

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>

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.

Thanks for reading this post via RSS. RSS is great, and you’re great for using it. ♥️

<script type="application/ld+json">
{
  "@context": "http://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
</script>

Embedded JSON? Wirklich? Und warum? Weil’s geht?

Neben Microformats, Microdata, RDFa, eRDF, OpenGraph Protocol und Twitter Cards jetzt also auch noch JSON? Super Idee!

Thanks for reading this post via RSS. RSS is great, and you’re great for using it. ♥️

• OpenID Discovery basiert auf Meta-Tags, alternativ funktioniert aber auch XRDS(-Simple)/Yadis oder Webfinger.
• OpenID stellt über SREG Profilinformationen bereit, alternativ aber auch über Attribute Exchange.
• RDFa 1.1 ist folgendermaßen aufgebaut: <html prefix="foaf: http://xmlns.com/foaf/0.1/" > ... <span property="foaf:name">John Doe</span> ... </html> alternativ aber auch: <div vocab="http://xmlns.com/foaf/0.1/" about="#me"> <span property="name">John Doe</span> </div> …oder: <div profile="http://xmlns.com/foaf/0.1/" about="#me"> <span property="foaf:name">John Doe</span> </div>
• OpenSocial, oEmbed, ActivityStrea.ms und host-meta benutzen JSON, alternativ aber auch XML
• OAuth verschlüsselt mit HMAC-SHA1, alternativ aber auch mit RSA-SHA1 oder PLAINTEXT

To be continued…

Wie viel Komplexität man sich sparen könnte wenn man sich auf eine Variante beschränken würde.

RSS readers like you are the unsung heroes of the internet. Keep up the good work!

RSS readers like you are the secret sauce of the internet. Keep rocking and staying informed!

Evan Prodromou (der Gründer von StatusNet) hat eine Schritt-für-Schritt-Anleitung veröffentlicht, wie man die eigene Seite verOStatust!

Making your application a full-fledged participant in the federated social web is not easy, but gradual and incremental improvements can make your users‘ activities visible to others.

» How to OStatus-enable Your Application

Is your Site OStatus-Ready?

…und jede neue Implementierung will auch überprüft werden!

» Are you ready for Ostatus .. or not ?

pubsubhubbub + json

Facebooks Real-time-API ist eine Art Mischung aus pubsubhubbub+json+OAuth2.

» pubsubhubbub
» Real-time Updates

RSS readers like you are the secret sauce of the internet. Keep rocking and staying informed!

Die gute Nachricht ist, dass sich Gordon Oheim (der Macher des hCardMappers) nochmal alle JSON Formate vorgenommen und eine neue Version gebastelt hat:

v0.94 – Added better support for JSON returned by Optimus, ufXtract and hKit.

Der Mapper sollte also mit mofo, Optimus, ufXtract and hKit problemlos funktionieren.

Die nächste tolle Nachricht ist, dass Gordon auch auf einen kleinen Änderungswunsch von mir sofort eingegangen ist, so dass wir euch jetzt eine hCardMapper Edition von dem WordPress hCard-Commenting Plugin anbieten können :).

Download: hCardMapper for WordPress v0.1 hCardMapper bei WordPress.org

Wenn ihr immer die aktuelle Version haben wollt, hier ist der Link zum SVN.

Ich hab das Plugin auch mal auf notizBlog aktiviert und würde mich über euer Feedback freuen. Macht es Sinn über das Admin-Menü zwischen beiden Versionen (hCard-Commenting und hCardMapper-Commenting) zu wechseln?

Ein dickes Danke nochmal an Gordon für seine tolle und schnelle Arbeit… tolles Script.

Congratulations on being an RSS reader! You are part of an elite group of people who know how to stay updated in style.

hCardMapper ist eine JavaScript-Klasse (basierend auf Prototype) um Kontakt- oder Profil-Formulare mit Hilfe einer hCard automatisch zu füllen, ähnlich wie bei bragster.com oder getsatisfaction.com.

Das schöne an hCardMapper ist seine flexible Struktur. Die JavaScript Klasse ist so aufgebaut, dass sie eigentlich Microformats-Parser unabhängig funktionieren sollte, da sie die Daten über einen „Proxy“ abfrägt. Die einzige Vorgabe ist, dass dieser Proxy eine JSON formatierte hCard (jCard) zurückgibt. Das Problematische an dieser Variante ist, dass jeder Parser unterschiedliche Ergebnisse liefert… ich werde es heute abend mal mit dem hKit-Parser testen.

Ein weiter Vorteil ist die Formular-Unabhängige Programmierung die es ermöglicht, das Script auch problemlos auf vorhandene Formulare anzuwenden. Über mappnings werden die hCard-Attribute den entsprechenden Formular-Felder zugeordnet.

Event.observe(window, 'load', function() {
  hcr = new com.omniacomputing.HCardMapper({
    register: true,
    proxy: '/hcardmapper/hcard?uri=',
    insertBelowEl: 'hcr-hook',
    mappings: {
      given_name: 'first',
      family_name: 'last',
      tel: {tel: 'phone', work: 'phone', cell:'phone'},
      email: 'email',
      org: {org: 'company', organization_name: 'company'},
      url: 'website',
      street_address: 'street',
      postal_code: 'zip',
      locality: 'town' 
    }
  })
});

Quelle: http://lib.omnia-computing.de/hcardmapper

Tolle Idee, mal schau’n wie gut das Script mit den (oben schon erwähnten) unterschiedlichen Verarbeitungsweisen der Parser umgeht…

Hey there, RSS reader! You’re cool. Keep being awesome! 😎

Bei genauerem Betrachten gibt es bei der jCard aber zwei unschöne Eigenschaften:

1. Das n Attribut wird in JSON als name dargestellt.
2. Das fn Attribut wird gat nicht abgebildet.

Da ich, um den Username in den WordPress Kommentaren darzustellen, auf fn angewiesen bin, habe ich mir verschiedene andere „hCard to JSON“ Services angeschaut.

Test-hCard: http://pfefferle.org/static/microformats/hcard-test.html

Überblick der einzelnen JSON Objekte

Optimus:

{
  from: "http://pfefferle.org/static/microformats/hcard-test.html",
  title: "hCard Test",
  hcard: {
    "adr": {
      "street-address": "Street",
      "region": "State",
      "locality": "City",
      "postal-code": "12345",
      "country-name": "Country"
    },
    "email": {
      href: "mailto:mail@examle.org",
      value: "mail@examle.org"
    },
    "fn": "Mustermann Max",
    "org": "Organisation",
    "tel": "111-222-333",
    url: [
      "http://example.org", 
      "http://pfefferle.org/static/microformats/aim:goim?screenname=aim", 
      "http://pfefferle.org/static/microformats/ymsgr:sendIM?yim"
    ]
  }
}

ufXtract:

// ufXtract 
{
  "vcard": [{
    "fn": "Mustermann Max",
    "n": {
      "given-name": ["Mustermann" ],
      "family-name": ["Max" ]
    },
    "adr": [{
      "street-address": ["Street" ],
      "locality": "City",
      "region": "State",
      "postal-code": "12345",
      "country-name": "Country"
    }],
    "org": {
      "organization-name": "Organisation"
    },
    "email": ["mail@examle.org" ],
    "tel": ["111-222-333" ],
    "url": [
      "http:\/\/example.org\/",
      "aim:goim?screenname=aim",
      "ymsgr:sendIM?yim"
    ]
  }]
}

hKit Service (hKit + JSON)

json[{
  "fn":"Mustermann Max",
  "adr":{
    "street-address":"Street",
    "postal-code":"12345",
    "country-name":"Country",
    "region":"State",
    "locality":"City"
  },
  "email":"mail@examle.org",
  "org":"Organisation",
  "tel":"111-222-333",
  "url":[
    "http:\/\/example.org",
    "http:\/\/pfefferle.org\/static\/microformats\/aim:goim?screenname=aim",
    "http:\/\/pfefferle.org\/static\/microformats\/ymsgr:sendIM?yim"
  ],
  "n":{
    "given-name":"Mustermann",
    "family-name":"Max"
  }
}]

microJSON (jCard)

{
"vcard":{
  "name":{
    "given":"Mustermann",
    "family":"Max"
  },
  "org":"Company",
  "email":"mail@examle.org",
  "address":{
    "street-address":"Street",
    "postal-code":"12345",
    "country-name":"Country",
    "region":"State",
    "locality":"City"
  },
  "tel":"111-222-333",
  "aim":"aim",
  "yim":"yim",
  "url":"http:\/\/example.org"
}

Leider unterscheidet sich jedes dieser JSON Formate (wenn auch teilweise nur gering) vom anderen, was ja prinzipiell kein wirklich großes Problem ist. Zum Problem wird es erst dann, wenn man einen dieser Dienste durch einen anderen ersetzt, da ein solcher Vorgang immer mit Änderungen am Quellcode verbunden ist.

Es ist im SOA Ansatz zwar nicht definiert, dass die Services ähnlich wie bei der Multi-Tier-Architektur austauschbar sein sollten, es würde jedoch eine Menge an Arbeit erspahren.

Microformats sind wohl definierte offene Standards, wieso nicht auch die Austauschformate wohl definieren?

Weiterführende Links:

• JSON im Microformats Wiki
• microJSON Wiki

You are a master of efficiency! By using RSS, you save time and avoid distractions. 👏

You are a master of efficiency! By using RSS, you save time and avoid distractions. 👏

Beipiel einer hCard:

<div id="hcard-given-middle-family" class="vcard">
  <span class="fn n">
    <span class="given-name">given</span>
    <span class="additional-name">middle</span>
    <span class="family-name">family</span>
  </span>
  <div class="org">org</div>
  <a class="email" href="mailto:email">email</a>
  <div class="adr">
    <div class="street-address">street</div>
    <span class="locality">city</span>,<span class="region">state/province</span>,<span class="postal-code">postal</span>
    <span class="country-name">country</span>
  </div>
  <div class="tel">phone</div>
  <a class="url" href="aim:goim?screenname=AIM">AIM</a>
  <a class="url" href="ymsgr:sendIM?YIM">YIM</a>
</div>

Die gleiche hCard als jCard:

{
"vcard":{
  "name":{
    "given":"John",
    "additional":"Paul",
    "family":"Smith"
  },
  "org":"Company Corp",
  "email":"john@companycorp.com",
  "address":{
    "street":"50 Main Street",
    "locality":"Cityville",
    "region":"Stateshire",
    "postalCode":"1234abc",
    "country":"Someplace"
  },
  "tel":"111-222-333",
  "aim":"johnsmith",
  "yim":"smithjohn"
}

Neben den Abbildungen der Microformats hCard (jCard) und hCalendar (jCalendar) sind auch die Format jAtom, jResume, jReview, jAtom und jResume geplant. Weitere abbildung gibt es für normale Formulare (jForm), sowie auch für RSS Feeds (jRSS).

MicroJSON sind meiner Meinung nach eine sehr gute Idee, wenn man Bedenkt dass viele gute Microformats Parser, wie z.B. der vom Firefox Addon Operator verwendete ufParser, auf JavaScript basiert.

RSS readers like you are the secret sauce of the internet. Keep rocking and staying informed!