media.ccc.de im Fediverse

Ich war vor einer Woche auf dem diesjährigen Berliner FediDay und hatte im Rahmen des dortigen Barcamps auch einen Projektbericht zum Thema media.ccc.de im Fediverse angeboten. Dabei war jemand so nett die Session mitzuschreiben, anbei dieser Bericht etwas aufbereitet:

 

Die Software hinter media.ccc.de nennt sich voctoweb, die Planung + Analyse dafür findet sich dort unter anderem in folgenden Issues:

Ziel

ActivityPub wird als fester Bestandteil von media.ccc.de implementiert, anstatt zu PeerTube zu migrieren. Trotzdem soll es dann aber auch mit der PeerTube und anderen Fediverse-Apps nutzbar werden.

Das Torrent-Element von PeerTube spielt für media.ccc.de keine große Rolle, weil Traffic-Bedarf in der Regel durch eigene Mirrors + Sponsoring abgedeckt und nicht der Flaschenhals ist. Die Vision ist media.ccc.de als Brücke für Konferenzen mit schedule.xml/json ins Fediverse.

cdn.media.ccc.de nutzt MirrorBrain, vergleichbar mit den Mirror-Netzen von Linux-Distributionen. Anfragen werden auf einen nahegelegenen Mirror umgeleitet, Prüfsummen erlauben die Verifikation der heruntergeladenen Datei. Die Mirrors sind auf der About-Seite samt Zusatzinformationen gelistet.

Stand der Umsetzung

Der Schwerpunkt der bisherigen Arbeit lag auf Metadaten: Personen liegen inzwischen als eigene Entitäten in der Datenbank – nicht mehr nur als String-Array, damit wird bessere Suchbarkeit und Verknüpfung möglich werden. Bei Personen gibt es eine primäre GUID plus Alias-GUIDs, falls dieselbe Person anderswo unter einer weiteren Identität auftaucht.

Das aktuelle Konzept sieht als nächster Schritt ist einen gesonderten Zugang für Vortragende auf media.ccc.de vor – aber komplett ohne Passwort: Du gibts eine Mailadresse oder Fediverse Handle ein und loggst dich dann per OICD/OAuth2 bei deiner Instanz/IdP ein bzw. bekommst eine Mail mit Einmal-Login-Link. Anstatt dem VOC eine Mail schreiben zu müssen, kannst du als Speaker dann beispielsweise deine Metadaten selbst editieren – also z.B. die verschiedene GUIDs zusammen führen, einen Fediverse Account hinzufügen oder den Anzeigenamen bearbeiten.

Die media.ccc.de bzw. voctoweb Codebasis benutzt aktuell Rails 7.2 – einzelne Aufgaben wie z.B. Evaluation was uns Fediverse Auxiliary Service Provider (FASP) bringen könnte, was wir mit dem fasp_client Rails Plugin testen könnten, hängen am Upgrade auf Rails 8.0 – das aber auch schon relativ weit ist.

Datenmodell – Wie sieht die ActivityPub-Repräsentation aus? (#735)

Bisher hatte voctoweb primär Conference + Event.

Es gibt die Idee diese beiden Entites im nach außen exposten Datenmodell auf Grouping + Item umzustellen zu auf Basis von Schema.org Typen zu abstrahieren:

  • Ein Grouping dann eine Conference, eine Vortragsreihe bei einem (Hack-)Space (OpenChaos, Datengarten, Hackfriday, etc.), eine Konferenzserie (als Klammer um die Einzelausgaben der jeweiligen Conference), … sein kann.
  • Items sind dann Vorträge, Workshops, Dokus, Filme, …

Teilweise ist dabei noch offen wer/wie diese neuen Metadaten dann „redaktionell“ gepflegt werden: Die Events/Items und Basis-Metadaten der Sammlung lassen sich aus schedule.xml bzw. schedule2.json für alle CCC Konferenzen der letzten 10-20 Jahre importieren, aber die Strukturdaten sind Handarbeit. Aktuelle Idee ist dies über ein Git-Repo in Terraform abzubilden, in der Hoffnung das sich das dadurch ein Teil des Pflegeaufwands an die Community croudsourcen lässt.

Die alte REST API behält dabei natürlich ihre bisherige Semantik, so das bestehende Clients dieser API weiterhin funktionieren.

Architektur / Implementierungsweg (#853)

Grundsätzlich gibt es für die Umsetzung zwei Hauptpfade: Entweder man integriert den ActivityPub Server komplett in seine Web-App in dem man bei Rails z.B. fedipub als Engine direkt in voctoweb einbaut, oder man delegiert die Benachrichtigung / Verwaltung der Abos an einen eigenen Dienst, wie Ghost es für seinen ActivityPub-Dienst getan hat.
Aktuell gehen wir den zweiten Weg und setzen unter social.media.ccc.de einen eigenen Dienst dafür auf, die Metadaten der einzelnen Entites sollen aber weiterhin aus voctoweb selbst kommen, ohne das sie permanent dupliziert werden, vgl. Beispiel-Ausschnitt aus #735:

{
  "type": "Video",
  "id": "https://media.ccc.de/v/37c3-12142-breaking_drm_in_polish_trains",
  "uuid": "68160267-a6a5-4a41-8a51-d8735c8aa338",
  "to": ["https://www.w3.org/ns/activitystreams#Public"],
  "cc": ["https://social.media.ccc.de/accounts/37c3/followers"],

  "name": "Breaking \"DRM\" in Polish trains",
  "attributedTo": [
    {"type": "Person", "name": "Redford", "id": "acct:redford@dragonsector.pl"},
    {"type": "Person", "name": "q3k", "id": "acct:q3k@hackerspace.pl"},
    {"type": "Person", "name": "MrTick"},
    {"type": "Group",  "name": "Dragon Sector", "id": "https://dragonsector.pl"}
  ],
  "mediaType": "text/markdown",
  "content": "We've all been there: the trains you're servicing for a customer suddenly brick themselves and the manufacturer claims that's because you've interfered with a security system.\n\nThis talk will tell the story of a series of Polish EMUs (Electric Multiple Unit) that all refused to move a few days after arriving at an “unauthorized” service company. We'll go over how a train control system actually works, how we reverse-engineered one and what sort of magical “security” systems we actually found inside of it.\n\nReality sometimes is stranger than the wildest CTF task. Reality sometimes is running `unlock.py` on a dozen trains.\n\nThe talk will be a mix of technical and non-technical aspects of analysis which should be understandable for anyone with a technical background. We’ll briefly explain how modern EMUs look like inside, how the Train Control & Monitoring System works, and how to analyze TriCore machine code.",
  "duration": "PT3705S",
  …

Weitere Hinweise & Diskussionen in der Session

Wie lässt sich die Interoperabilität sinnvoll testen, bevor neue Features auf PROD ausgerollt werden?

Als Möglichkeit zum Inspizieren und Debuggen von ActivityPub-Objekten wurde ⁠BrowserPub genannt. Am liebsten wäre mir hier automatisierte Tests zwischen Voctoweb neue Federation-Features sinnvoll und reproduzierbar testen lassen – also z.B. wie zeigt ein Mastodon/PeerTube/etc. Server/Client die Entities verarbeitet oder anzeigt.

Was sind etablierte Best Practices für das lokale bzw. isolierte Testen von Federation?

Ein weiterer Aspekt ist die Gefahr, sich durch fehlerhafte Federation-Requests bzw. -Zustände eine Domain bzw. Instanz für weitere Tests zu „verbrennen“. Bei der Verwendung von Fedify sollte dies grundsätzlich kein großes Problem darstellen. Kritischer könnten jedoch Fehlerzustände wie Deadlocks oder inkonsistente Zustände sein, bei denen es schwierig wird, den ursprünglichen Status sauber zurückzusetzen. Das scheint insbesondere dann relevant zu sein, wenn ein zweiseitiger State zwischen den beteiligten Instanzen entsteht. Bei rein einseitigen Interaktionen dürfte das Zurücksetzen bzw. Wiederholen von Tests wesentlich unkomplizierter sein.

In Nachgang kam die Idee auf die Testinstanzen bei Fedihub/Anoxinon für entsprechende Tests zu verwenden – von denen eh auch schon einzelne Mitglieder im VOC aktiv sind.

Wenn ihr euch für den Fortschritt bei dem Projekt interessiert folgt gerne @saerdnaer@chaos.social oder @c3voc@chaos.social bzw. meldet euch bei mir oder in #voc-media wenn ihr Interesse habt bei dem Projekt mitzuarbeiten – egal ob als Entwickler, Tester, etc.