STP057: ActivityPub

Wieder einmal ein von langer Hand vorbereitetes Thema. Hier kulminiert der Inhalt der beiden vorangegangenen Folgen zu einem Blick in den Maschinenraum von z.B. Mastodon. Außerdem sprechen wir ein weiteres Mal über unseren persönlichen Blick und Umgang mit diesem Thema.<h2>Shownotes</h2>Klaus schreibt per Mail:
<blockquote>
Hallo timeless und Xyrill,
bin Anfang des Jahres irgendwo auf euren Podcast gestoßen und dort eingestiegen, wo ihr damals gerade wart, Folge 49 Schadcode und dann die weiteren.
Diese haben mir so gut gefallen, dass ich alle Folgen mit Antennapod abgeholt habe und dabei bin euren Podcast von hinten aufzurollen.
Großes Kompliment an Euch! Phantastische Serie! Freue mich auf jede neue und für mich neue-alte Folge.
Bin zwar vom Fach, aber lerne immer was Neues oder andere Blickwinkel kennen. HERRLICH!
<hr>
Eine kleine Bemerkung von mir zu den Folgen 13 und 14, Textkodierung und Textdarstellung.
Ich bevorzuge so wie Xyrill auch die Verwendung von kombinierenden diakritischen Zeichen.
Die meisten der für mich nützlichen davon (u.a. für DE, FR, NL, CN-Pinyin) <a href="en.wikipedia.org/w/index.php?title=Combining_c… an der Hex-Adresse U+0300 ff.</a>
Leicht zu merken und praktisch, wenn man ständig mit anderen Tastaturbelegungen zu tun hat.
Worauf ich aber hinaus möchte, ist folgendes:
Diese diakritischen Zeichen werden sowohl am Schirm als auch im Druck gleich dargestellt, obwohl ihnen andere Byte-Folgen zugrunde liegen. Hat Xyrill alles beschrieben. Hab ja zugehört. Für Textprogramme, etc. ist das kein Problem, in Datenbanken aber schon.
Es macht dann leider doch einen gravierenden Unterschied, ob diakritische Zeichen wie en "ä" aus U+00E4 oder aus der Kombination von U+0061 + U+0308 entstehen.
<ul>
<li>Tastaturen, die diese Zeichen direkt kodieren, verwenden nur die Version mit 1 Codepunkt.</li>
<li>Bei Längenbestimmungen von Zeichenketten ergeben sich Unterschiede. Die Zeichenketten sehen gleich aus, sind aber nicht gleich lang, obwohl sie auch gleich lang aussehen!</li>
<li>Eingabeformulare fangen das nicht immer gut ab. Gleich aussehender Begriff, aber doch nicht derselbe.</li>
<li>Idem bei Suchanfragen.</li>
<li>etc.</li>
</ul>
Ich empfehle daher immer in Datenbanken Strings so zu standardisieren, dass nur die Version mit 1 Codepunkt verwendet wird, so wie eben Muttersprachler diesen Text auf ihrer sprachspezifischen Tastatur eingeben würden.
Viele Grüße aus Belgien!
Klaus
</blockquote>
Nun zum eigentlichen Thema:
<ul>
<li>
Ausgangssituation
<ul>
<li><a href="de.wikipedia.org/w/index.php?title=Soziale_Med… Medien</a>: "digitale Medien bzw. Plattformen, die es Nutzern ermöglichen, sich im Internet zu vernetzen, [...] untereinander auszutauschen und mediale Inhalte einzeln, in einer definierten Gemeinschaft oder offen in der Gesellschaft zu erstellen, zu diskutieren und weiterzugeben"</li>
<li>aber: alles zentralisiert (siehe STP056) und nicht interoperabel (siehe STP055)</li>
<li><a href="de.wikipedia.org/w/index.php?title=ActivityPub…;: der zurzeit wahrscheinlich aussichtsreichste Versuch, soziale Medien dezentral zu modellieren</li>
<li>erste Anfänge in den frühen 2010ern mit <a href="activitystrea.ms/specs/atom/1.0/">Acti… Streams 1.0</a>, dann in 2016-2018 Entwicklung von <a href="w3.org/TR/activitystreams-core/">Activ… Streams 2.0</a> und darauf aufbauend <a href="w3.org/TR/activitypub/">ActivityPub<…;
<li>Xyrill sieht zwei wesentliche Design-Einflüsse im ActivityPub-Protokoll</li>
</ul>
</li>
<li>
Einfluss: <a href="de.wikipedia.org/w/index.php?title=Representat… (Representational State Transfer)</a>
<ul>
<li>HTTP kennt man allgemein als Protokoll zum Abruf von Webseiten (siehe STP002)</li>
<li>neben <code>GET</code> gibt es in HTTP-Anfragen aber noch viele andere Verben</li>
<li><code>POST</code>: Ursprung in HTML für Abschicken ausgefüllter Formulare</li>
<li><code>PUT</code>, <code>PATCH</code>, <code>DELETE</code> etc.: für Hochladen und Verwalten von Dateien</li>
<li>REST: Modellierung von APIs unter Einsatz dieser HTTP-Verben und unter Modellierung der Datensätze entlang von URLs (z.B. in einem Webshop <code>PATCH /products/23</code>, um Produkt Nr. 23 zu bearbeiten; oder in einem Blog <code>GET /articles/hello-world/comments</code>, um die Kommentare zu dem Post namens "Hello World" aufzurufen)</li>
</ul>
</li>
<li>
Einfluss: <a href="de.wikipedia.org/w/index.php?title=E-Mail&…;
<ul>
<li>entworfen in einer Zeit, als die meisten Verknüpfungen im Internet nicht durchgehend verfügbar waren</li>
<li>Mails werden nicht sofort an den Empfänger zugestellt, sondern landen erstmal auf dem Mail-Server des Absenders in einer Outbox (analog dem Postbriefkasten)</li>
<li>Zustellung an den jeweils nächsten Server in der Kette bei Verfügbarkeit der Leitung (heutzutage unverzüglich und immer direkt an den Zielserver), dann Ablage in der Inbox des Empfängers (analog dem Hausbriefkasten)</li>
<li>Problem bei ActivityPub: E-Mail ist Unicast (Nachrichten gehen immer an eine bestimmte Adresse bzw. eine bestimmte Liste von Adressen), aber soziale Medien können auch Broadcast sein (z.B. Tweets oder Blogposts sind global sichtbar)</li>
</ul>
</li>
<li>
ActivityPub: Inbox und Outbox wie bei E-Mail, aber bidirektional
<ul>
<li>Direktnachricht von Alice an Bob: Alice postet in ihre eigene Outbox, Server leitet weiter in Bobs Inbox, Bob ruft aus seiner Inbox ab</li>
<li>öffentliche Nachricht von Alice: Alice postet in ihre eigene Outbox, Bob ruft aus Alices Outbox ab; bei Followern sendet Alices Server in deren Inbox</li>
<li>Nachrichten verbleiben bis zu ihrer eventuellen Löschung in der Outbox und bilden einen Feed aller Nachrichten dieser Person</li>
<li>REST-Einfluss: Inbox erlaubt <code>GET</code> durch den Inhaber und <code>POST</code> durch andere Server, Outbox erlaubt <code>POST</code> durch den Inhaber und <code>GET</code> durch alle</li>
<li>vgl. Bilder in <a href="w3.org/TR/activitypub/">Kapitel 1 der ActivityPub-Spezifikation</a></li>
<li>wesentliche Implementationen von ActivityPub: Kurznachrichtendienst <a href="joinmastodon.org/">Mastodon</a>;, Linkaggregator <a href="join-lemmy.org/">Lemmy</a>;, Bildplattform <a href="pixelfed.org/">Pixelfed</a>;, Videoplattform <a href="joinpeertube.org/">PeerTube</a>&…;
<li>Anekdote: Xyrill hatte überlegt, die Podcast-Seite mit ActivityPub auszustatten, und ist davon wieder abgekommen</li>
</ul>
</li>
<li>
Beobachtung bzw. Rückbezug zu STP056: föderierte Netzwerke haben einen starken Drang zur (Re-)Zentralisierung
<ul>
<li>Anschauungsbeispiel: <a href="en.wikipedia.org/w/index.php?title=ActivityPub… der Nutzerzahlen zwischen verschiedenen ActivityPub-Implementationen</a> -> Mastodon macht 99% der Nutzerbasis aus</li>
<li>innerhalb von Mastodon initial starke Konzentration bei <code>mastodon.social</code>; seit einiger Zeit ist beim Anlegen eines Nutzerkontos kein Server mehr voreingestellt</li>
<li>vgl. auch Matrix: schätzungsweise etwa 50% der Nutzer bei <code>matrix.org</code></li>
<li>absolut subjektiver Eindruck: Mastodon-Entwickler dominieren die Weiterentwicklung von ActivityPub als ganzes</li>
</ul>
</li>
<li>
Vergleich mit dem AT-Protokoll von BlueSky
<ul>
<li><a href="web.archive.org/web/20200111021337/twitter.com…;: Trennung des Zustellpfades von "dem Algorithmus" (Inhaltsvorschläge und Moderation), um letztere austauschbar zu gestalten</li>
<li>modulare/dezentrale Moderation (mit den daraus folgenden Konsequenzen, z.B. …

Kapitelklicken springt direkt hin

Shownotes