Social Spec und Social Browser

So wie Kollege ix sich auf wirres beschreibt, bin auch ich gern ein early adopter und probiere gern neue Dinge aus. Da ich meinem Ghost CMS gerade den Rücken gekehrt und meine Website auf statisches HTML umgestellt habe, bot sich die Gelegenheit, auch gleich mal Social Specs umzusetzen.

Screenshot der Website Social Browser, die es erlaubt durch die Profile der anbietenden Websites zu browsen

Bei der Ge­le­gen­heit habe ich auch gleich die /about und /kon­takt Sei­ten auf­ge­räumt und so auf­ge­baut, dass sie au­to­ma­tisch /.well-known/about.md und /.well-known/cont­act.vcf füt­tern. Ich sollte nun dem Standard entsprechen. Schauen Sie gern selbst, hier.

Die neuen Dateien stehen so nicht im Menü, tauchen in keinem Feed auf und sind trotzdem ziemlich nützlich: Unter /.well-known/ liegen jetzt meine Following-Liste, eine About-Seite und eine Kontaktkarte. Das Ganze heißt SocialSpec und ist der Versuch, Profilinformationen über App- und Plattformgrenzen hinweg mitnehmbar zu machen.

Drei Dateien, drei Antworten

• /.well-known/following.opml – die Feeds, die ich lese, als OPML-Subscription-List. Die Datei wird bei jedem Build aus meiner Blogroll erzeugt, damit sie nicht veraltet.
• /.well-known/about.md – eine kurze About-Seite als Markdown, mit einer Zusammenfassung im Frontmatter.
• /.well-known/contact.vcf – meine öffentliche Kontaktkarte als vCard 4.0.

Dazu kommen -Verweise im , damit Clients die Dateien finden. Und CORS, damit Browser-Anwendungen sie lesen dürfen.

Wofür ist das gut?

Wer heute ein Profil in einer App ansieht, bekommt meist eine HTML-Seite vorgesetzt, die für Menschen gemacht ist. Maschinen müssen raten: Was ist der Name? Welche Links gehören dazu? Wem folgt die Person? SocialSpec dreht das um: Die Informationen liegen in klaren, kleinen Dateien mit definierten Formaten und festen Orten. Ein Reader, ein Social Browser oder ein Tool wie FollowDraw kann daraus eine Profilansicht bauen – ohne Scraping, ohne API-Key, ohne Sonderabsprache. Für mich heißt das: Mein Profil ist nicht an eine Plattform gebunden. Die Following-Liste ist dieselbe, die ich auch auf der Blogroll-Seite pflege. Die About-Seite ist dieselbe, die ich auch hier verlinke. Und die Kontaktkarte ist das, was sonst in einer „Kontakt“-Seite steckt – nur eben auch maschinenlesbar.

Warum strukturierte Daten?

„Strukturierte Daten“ klingt nach großer Datenbank und noch größerem Buzzword. Gemeint ist erst einmal etwas Einfaches: Informationen so ablegen, dass ihre Bedeutung eindeutig ist. Ein Satz wie „Ich folge Daring Fireball“ ist für Menschen klar. Für ein Programm ist erst einmal unklar, ob das ein Name, ein Feed, eine Empfehlung oder ein Zitat ist. In einer OPML-Datei steht dagegen: xmlUrl="https://daringfireball.net/feeds/main". Das ist eindeutig.

Es gibt viele Arten strukturierter Daten. JSON-LD und schema.org kennt man aus der Suchmaschinenoptimierung: Sie helfen Google, Artikel, Personen und Events zu verstehen. SocialSpec macht etwas anderes. Es erfindet kein neues Vokabular, sondern benutzt Formate, die es längst gibt: OPML für Feed-Listen, Markdown für Texte, vCard für Kontakte. Neu ist vor allem der Ort – /.well-known/ – und die Regel, dass jede App sie ohne Anmeldung lesen darf. Das ist weniger Semantic Web als vielmehr praktische Interoperabilität.

Was bedeutet das generell?

Das Web war mal als Sammlung kleiner, verlinkbarer Dokumente gedacht. Große Plattformen haben daraus geschlossene Räume gemacht: Das Profil liegt in der App, die Follower-Liste in der App, die Kontaktdaten in der App. SocialSpec ist ein Gegenentwurf im Kleinen. Es sagt: Ein Profil ist keine Insel. Es besteht aus Daten, die man exportieren, spiegeln und an anderer Stelle wieder anzeigen kann.

Das ist kein Ersatz für RSS oder ActivityPub. Es ist eine Ergänzung: RSS sagt, was neu ist. ActivityPub sagt, wie man miteinander spricht. SocialSpec sagt, wer man ist und wem man folgt – in einer Form, die ein anderes Programm direkt weiterverwenden kann.

Ist das IndieWeb?

Jein. Wenn man IndieWeb als Haltung versteht – eigene Domain, eigene Inhalte, eigene Identität, offene Formate, keine Plattform als Vermittler – dann passt SocialSpec sehr gut dazu. Es folgt demselben Impuls: Die Daten gehören auf meine Seite, nicht in ein Silo.

Wenn man IndieWeb als konkrete Sammlung von Spezifikationen versteht, ist die Antwort vorsichtiger. Die offiziellen IndieWeb-Bausteine sind Dinge wie IndieAuth, Webmention, Micropub, Microsub und microformats2. SocialSpec ist keiner davon. Es ist ein eigenes, junges Community-Projekt, kein W3C-Standard und kein offizieller IndieWeb-Baustein. Es benutzt auch keine Microformats2-Auszeichnung im HTML.

Ich würde es deshalb so sagen: SocialSpec ist IndieWeb im Geist, aber nicht im Buchstaben. Es ist ein weiterer kleiner Baustein für ein Web, in dem Profildaten mitkommen dürfen. Webmentions nutze ich hier ohnehin schon – insofern passt es in dieselbe Werkzeugkiste, auch wenn es ein anderes Werkzeug ist.

Was ich gebaut habe

Technisch ist es unspektakulär, und das ist gut so:

• Ein kleines Python-Skript erzeugt nach dem Hugo-Build public/.well-known/following.opml aus static/assets/blogroll.opml und kopiert about.md und contact.vcf.
• Caddy liefert die Dateien mit den richtigen Content-Types (text/x-opml, text/markdown, text/vcard) und Access-Control-Allow-Origin: * aus.
• Im stehen Discovery-Links auf die drei Dateien.

Das Ergebnis kann man sich zum Beispiel unter https://sodir.org/profile.html?d=herrmontag.de ansehen.

Was noch fehlt

SocialSpec ist jung. Es gibt noch wenige Clients, und die Spezifikationen sind eher RFC als fertiger Standard. Das ist kein Grund, es nicht auszuprobieren. Aber es ist ein Grund, die Erwartungen klein zu halten: Im Moment ist das ein Signal an andere Werkzeuge, kein Massenphänomen. Und natürlich: Alles, was dort steht, ist öffentlich. Die vCard ist eine Visitenkarte, kein Adressbuch. Wer keine öffentliche Kontaktkarte will, sollte keine veröffentlichen.

Fazit

Drei Dateien, ein paar Zeilen Build-Skript und der gottseidank liebste Caddyserver. Viel mehr ist es nicht. Aber es ist ein kleiner Test dafür, ob das Web noch mehr sein kann als eine Ansammlung von Plattformen. Das Profil bleibt auf meiner Domain. Es ist lesbar für Menschen und für Programme. Und es kann mitkommen, wenn jemand es woanders anzeigen will. Ob man das nun IndieWeb nennt oder einfach „offenes Web“ – mir gefällt der Gedanke, dass die Daten nicht in der App bleiben, in der sie zufällig entstanden sind.