In einer Zeit, in der sich das digitale soziale Leben zunehmend in geschlossenen, einzigartig gestalteten Anwendungen abspielt, bietet ein neues Forschungsframework namens Graffiti eine radikal andere Vision: Jeder kann seine eigene soziale Anwendung erstellen, die genau den Bedürfnissen seiner Community entspricht, ohne dabei bestehende Kontakte oder seine Daten zu verlieren. Es handelt sich um eine Kommunikations- und Datenschicht, die für die einfache Erstellung personalisierter sozialer Werkzeuge mit typischen Front-End-Technologien (HTML, CSS, JavaScript) konzipiert ist, mit integrierter Interoperabilität zwischen verschiedenen Anwendungen und dem Eigentum der Nutzer an Daten, die auf einer dezentralen Infrastruktur gespeichert sind.

Warum personalisierte soziale Anwendungen überhaupt existieren sollten

Stellen wir uns einen unabhängigen Konzertclub vor, der ein lokales Publikum um neue Künstler versammeln möchte: Austausch von Empfehlungen, kurze Ausschnitte aus Proben, schnelle Umfragen vor dem Programm, Setlisten nach dem Auftritt… All das passt in eine spezialisierte soziale Anwendung, die auf die Mikro-Community zugeschnitten ist. Das Problem entsteht in dem Moment, in dem das Publikum – um dieser Personalisierung willen – auf einen neuen Dienst „umziehen“ und dort sein soziales Netzwerk neu aufbauen muss, während die Entwickler der Anwendung ein komplexes Back-End beherrschen und warten müssen. Graffiti durchbricht diesen Teufelskreis auf zwei Arten: Es vereinfacht die Entwicklung, indem es eine gemeinsame Hintergrundschicht bietet, auf die alle Anwendungen zugreifen, und garantiert gleichzeitig, dass Beiträge und soziale Verbindungen in jeder kompatiblen Anwendung gesehen und genutzt werden können, ohne dass die Kontinuität zwischen den Menschen verloren geht.

Die Schlüsselidee: Interoperabilität ohne Zustimmung des Plattformbesitzers

Im Gegensatz zu herkömmlichen sozialen Netzwerken, in denen die Interoperabilität normalerweise auf APIs beschränkt ist, die vom Plattformbesitzer definiert werden, schlägt Graffiti eine Protokollebene vor, auf der alle sozialen Aktionen in Daten „umgewandelt“ werden, die in verschiedenen Client-Anwendungen gelesen, geteilt und interpretiert werden können. Diesen Ansatz nennen die Autoren totale Reifikation: Jede Interaktion – vom Beitrag und der Antwort bis zum Like, Blockieren, Melden oder Moderieren – wird als separates Datenartefakt aufgezeichnet. Die Anwendungen entscheiden dann nach ihren eigenen Regeln, wie sie diese Artefakte anzeigen (oder ignorieren), wodurch unterschiedliche Richtlinien und Designphilosophien gleichzeitig auf demselben sozialen Graphen umgesetzt werden können.

In der Praxis bedeutet das, dass Gemeinschaften ihre eigenen Moderatoren und ihre eigenen Regeln wählen können, während sie trotzdem „im selben Netzwerk“ mit anderen bleiben. Wenn eine Anwendung beschließt, Beiträge zu verbergen, die eine bestimmte Person als unangemessen markiert hat, kann eine andere Anwendung denselben Satz von Metadaten nur für eine Warnung oder für ein Ranking verwenden. Die Moderation entwickelt sich so von einem monolithischen, zentralisierten Eingriff zu einem Wettbewerb von Richtlinien und Werkzeugen, die die Nutzer wählen.

Lösung des „Kontextkollapses“ durch Kanäle

Interoperabilität hat auch eine dunkle Seite: Inhalte, die für ein Publikum erstellt wurden, können vor einem völlig anderen landen. Dieses Phänomen, in der Literatur als Kontextkollaps (engl. context collapse) bekannt, kann zu Missverständnissen und sozialem Schaden führen, wenn eine Nachricht aus ihrem gewünschten Rahmen gerissen wird. Graffiti adressiert dies mit dem Konzept der Kanäle. Ein Kanal ist ein flexibler „Zaun“ um eine Nachricht (oder einen ganzen Thread), der einen bestimmten Kontext repräsentiert – eine Person, eine Anwendung, eine Organisation, einen Ort, ein Ereignis oder eine thematische Einheit. In einem Kanal sichtbare Beiträge müssen nicht automatisch in einen anderen „durchsickern“; der Autor kann das Publikum feiner definieren und so eine unerwünschte Vermischung von Kontexten verhindern.

Front-End-Entwicklung ohne schweres Back-End

Eine der attraktiven Ambitionen des Frameworks ist es, die Einstiegshürde für die Entwicklung sozialer Anwendungen zu senken. Da die Speicherung von Inhalten und der Datenaustausch über eine gemeinsame, verteilte Infrastruktur laufen, betonen die Autoren, dass es möglich ist, funktionale soziale Clients nur mit Front-End-Tools zu erstellen: HTML, CSS, Komponentenbibliotheken oder populären Frameworks wie Vue. Anstatt dass Teams ihre eigenen Server schreiben und warten, standardisiert Graffiti die Art und Weise, wie reifizierte Ereignisse gespeichert und abgerufen werden, und ermöglicht es so, die Energie auf die Benutzererfahrung, clientseitige Sicherheitsrichtlinien und die schnelle Iteration neuer Funktionen zu lenken.

Dateneigentum und portable Identität

Das zentrale Versprechen dezentraler sozialer Netzwerke lautet: Nutzer behalten ihre Daten und ihre Identität, auch wenn sie die Anwendung wechseln. Graffiti operationalisiert dies, indem die Daten nicht dem Client „gehören“, sondern sich in einem verteilten Speicher befinden, mit dem sich verschiedene Clients verbinden können. Identität und soziales Netzwerk werden dadurch portabel, sodass ein Wechsel der Anwendung nicht mehr den Verlust von Verbindungen bedeutet. Eine solche Architektur steht im Einklang mit breiteren Trends im dezentralen sozialen Web, das seit Jahren erforscht, wie man der Gefangenschaft in Silos entgehen kann – vom ActivityPub-Standard, der das Fediverse antreibt, bis hin zu neueren Ansätzen wie dem AT Protocol, auf dem eine Reihe interoperabler Anwendungen entsteht.

Wie sich Graffiti von bestehenden dezentralen Protokollen unterscheidet

ActivityPub (eine W3C-Empfehlung von 2018) stützt sich auf eine Föderation von Servern, die Aktivitäten im ActivityStreams-2.0-Format austauschen; es wird von Mastodon und anderen Diensten des Fediverse genutzt. Das AT Protocol, das hinter einem wachsenden Ökosystem von Anwendungen steht, bietet portable Identitäten und die Trennung von Speicherung und Clients sowie flexible algorithmische Feeds und offene Moderationswerkzeuge. Graffiti teilt mit ihnen das Ziel der Portabilität von Identität und Daten, zeichnet sich aber gerade durch die totale Reifikation sozialer Aktionen und ein universelles, anwendungsagnostisches Datenmodell aus, bei dem selbst die Moderation als Datum aufgezeichnet wird. Diese Repräsentationsebene erleichtert das Nebeneinander widersprüchlicher Regeln und ermöglicht es verschiedenen Gemeinschaften, auf demselben Graphen gleichzeitig ihre eigenen Sichtbarkeits- und Verhaltensrichtlinien durchzusetzen.

Anwendungsbeispiele: von Kulturszenen bis zu Arbeitsteams

Die Autoren haben bereits mehrere auf dem Framework basierende Anwendungen demonstriert – von einer Microblogging-Schnittstelle, die „klassischen“ sozialen Netzwerken ähnelt, bis hin zur gemeinsamen Bearbeitung von Inhalten im Stil einer Enzyklopädie, dem Echtzeitaustausch kurzer Nachrichten und dedizierten Anwendungen für lokale Gemeinschaften. Im konkreten, scheinbar bescheidenen Beispiel des Konzertclubs ermöglicht Graffiti dem Publikum, thematische Kanäle zu eröffnen (z. B. nach Genres, Künstlern oder Veranstaltungsorten), Ausschnitte und Playlists zu teilen, und Moderatoren – die von der Gemeinschaft selbst gewählt werden – legen Sichtbarkeitsregeln fest, ohne befürchten zu müssen, dass diese Festlegungen die Profile der Nutzer außerhalb des Kontextes des Musikkanals „überfluten“.

Es ist gleichermaßen in professionellen Umgebungen anwendbar: Teams können ein minimales Werkzeug für die schnelle Koordination mit Threads pro Projekt zusammenstellen, während Verhaltensweisen wie „Liken“, „Pingen“ oder „Eskalieren“ als Daten aufgezeichnet werden, die andere Clients in ihre eigenen UI-Muster übersetzen können. Das Ergebnis ist ein Mosaik kompatibler Anwendungen unterschiedlicher Ästhetik und Tiefe, aber mit demselben sozialen „Reservoir“.

Moderation als Dienstleistungsmarkt, nicht als zentraler Befehl

Ein häufiger Einwand gegen dezentrale Systeme betrifft die Durchsetzung von Regeln: Wer „entfernt“ illegale oder schädliche Inhalte? Graffiti bietet keine einheitliche Inhaltspolizei, sondern ermöglicht es konkurrierenden Moderationsdiensten, über denselben sozialen Datenbestand zu agieren. Nutzer – oder ganze Gemeinschaften – wählen einen oder mehrere Dienste, wobei Entscheidungen (Tags, Sperren, Warnungen) als reifizierte Ereignisse aufgezeichnet werden. Die Anwendungen interpretieren diese Ereignisse dann nach ihren eigenen Regeln. Dies vermeidet einen einheitlichen Standard, der für vielfältige kulturelle und rechtliche Kontexte zwangsläufig zu starr ist, wirft aber auch ernsthafte Forschungsfragen über die Grenzen des persönlichen und kollektiven Schutzes auf.

Sicherheit, Datenschutz und die Grenzen der Interoperabilität

Wie auch immer man an die Interoperabilität herangeht, es bleibt eine ungelöste Spannung zwischen Offenheit und der Verhinderung der Verbreitung von Inhalten über das beabsichtigte Publikum hinaus. Kanäle helfen, aber sie entbinden die Designer von Clients und die Verwalter von Gemeinschaften nicht von der Verantwortung, vernünftige Standardeinstellungen für die Sichtbarkeit, die Möglichkeit, Threads in geschlossenere Räume zu „verzweigen“, sowie klare Kontextindikatoren zu definieren. Darüber hinaus erzeugt die Reifikation von Sperren und Beschwerden Metadaten, die – wenn sie nicht geschützt werden – Muster sozialer Beziehungen aufdecken können. Die Stärkung der Privatsphäre erfordert daher kryptografische Mechanismen, „Selective Disclosure“-Ansätze und strenge Richtlinien zur Datenaufbewahrung, was die Autoren als zukünftige Entwicklungsrichtung angekündigt haben.

Forschungsstatus und Anerkennungen

Die Arbeit, die das Konzept und die Implementierung von Graffiti systematisch vorstellt, wurde auf der jährlichen Konferenz UIST 2025 präsentiert, die vom 28. September bis 1. Oktober 2025 in Busan stattfand. Im Konferenzprogramm wird genau diese Publikation mit der Unterschrift von Theia Henderson, David R. Karger und David D. Clark aufgeführt, und die Arbeit wurde auch unter die preisgekrönten Arbeiten der Konferenz aufgenommen. Ein begutachtetes Manuskript ist ebenfalls im Open Access verfügbar.

Der Forschungskontext selbst fügt sich in die mehrjährigen Bemühungen akademischer und technologischer Gemeinschaften ein, dezentrale Informationssysteme zu schaffen, die den Nutzern die Kontrolle über ihre Daten und ihre Identität zurückgeben – eine Tradition, die am MIT symbolisch auch durch die Arbeit von Gruppen repräsentiert wird, die sich dezentralen Web-Paradigmen widmen.

Vergleich von Design-Paradigmen: was ein „komponierbares“ soziales Web bedeutet

Im semantischen Web gab es bereits eine Reihe von Versuchen, die Kommunikation über generische Objekte und Aktivitäten zu standardisieren (z. B. ActivityStreams). Graffiti bringt diesen Geist auf die Client-Seite zurück und macht ihn für den Bau von Anwendungen praktikabel: Anstatt uns an eine „Haupt“-Anwendung anzupassen, die vorschreibt, wie ein Beitrag, eine Antwort oder eine Meldung aussieht, standardisiert Graffiti die Repräsentation von Ereignissen, während die Benutzeroberfläche, die Abläufe und die Interpretationsregeln eine Frage der Wahl bleiben. Daraus ergibt sich eine unerwartete Konsequenz: Es ist einfacher, „Brücken“ zwischen Protokollen zu bauen (z. B. zum Fediverse oder zum Ökosystem des AT-Protokolls), da die Übersetzung auf der Ebene der Ereignisse erfolgt und nicht durch das erzwungene Klonen der gesamten Plattformlogik.

Was das für Content-Ersteller und kleine Organisationen bedeutet

Für lokale Medien, Kulturorganisationen, Schulen, Vereine und Startups war die bisher größte Hürde die Kombination aus technischer Komplexität und dem Risiko des „leeren Raums“. Wenn die Gemeinschaft ihr bestehendes Netzwerk verlassen muss, kommt das Projekt schwer in Gang. Graffiti packt dieses Problem an, indem es drei praktische Vorteile bietet: (1) die Erstellung eines MVP nur mit dem Front-End, (2) die Portabilität von Identität und Daten ohne „Zurücksetzen“ sozialer Verbindungen und (3) native Interoperabilität, die es ermöglicht, dass Beiträge aus einer Anwendung in einer anderen sichtbar sind – ohne Zwang zu einem einheitlichen Design oder zentralisierten Regeln.

Beispielszenarien und Nutzungsmuster

• Mikroblog für Stadtteile: Kanäle nach Stadtvierteln und Themen (Veranstaltungskalender, Freiwilligenaufrufe, Fundbüro); in jedem Kanal unterschiedliche Moderationsregeln, die die Gemeinschaft durch „Abonnieren“ von Moderationsdiensten wählt.


• Redaktionskooperative: Bearbeitung von Texten in Form von „Wiki-Threads“, bei denen Änderungen, Rezensionen und Qualitätskennzeichnungen ebenfalls reifizierte Ereignisse sind; ein anderer Client kann dieselben Daten als klassischen Peer-Review-Fluss anzeigen.


• Musikszene: Beiträge von Proben, Setlisten und Aufnahmen von Auftritten wandern durch die Kanäle von Künstlern, Clubs und Promotern; das Publikum wählt einen Client mit Fokus auf Audio, jemand anderes einen Client mit Forum-Threads – alle teilen denselben Datenbestand.


• Arbeitsteams: einfache Integrationen mit anderen Protokollen und Diensten: die Identität ist portabel, sodass der Wechsel zu einem neuen Client das Kontaktnetzwerk nicht stört; Moderationsrichtlinien können „Code-Review“-Muster nachahmen.

Das große Ganze: der Wettlauf um eine interoperable soziale Schicht

Die letzten zwei Jahre haben eine Flut von Initiativen hervorgebracht, die die Abhängigkeit von einem einzigen Unternehmen vermeiden wollen: das auf ActivityPub basierende Fediverse expandiert durch verschiedene Software und Integrationen, während das auf dem AT-Protokoll basierende Ökosystem ein Wachstum der Anzahl von Anwendungen und Nutzern sowie Kampagnen verzeichnet, die „öffentliche Interessen“ und die Neukonfiguration des Eigentums an Infrastrukturen betonen. Graffiti fügt sich in diese Landschaft als Forschungsvorschlag ein, der die Clients maximal befreit – Entwickler können auf der Ebene der Erfahrung und der Funktionen innovieren, ohne dabei die Interoperabilität zu beeinträchtigen.

Offene Fragen und zukünftige Entwicklung

Wie weit kann die „persönliche“ Moderation gehen, bevor sie gegen organisierten Missbrauch unwirksam wird? Wie kann verhindert werden, dass reifizierte Ereignisse (insbesondere solche, die auf soziale Konflikte hinweisen) als Werkzeug für Doxxing oder gezielte Belästigung verwendet werden? Was sind die minimalen Sicherheitsstandards für Kanäle, die erforderlich sind, um die Rekonstruktion privater Netzwerke aus Metadaten zu vermeiden? Und schließlich, wo zieht man die Grenze zwischen Gestaltungsfreiheit und Verantwortung gegenüber den schutzbedürftigsten Nutzergruppen? Die Autoren des Projekts haben bereits weitere technische Verbesserungen angekündigt – von Werkzeugen zur grafischen Erstellung von Clients bis hin zu stärkeren Mechanismen zum Schutz der Privatsphäre und Sicherheit – aber auch Längsschnittstudien zu den Auswirkungen auf das Verhalten von Gemeinschaften.

Für wen Graffiti schon heute gedacht ist

Den größten unmittelbaren Nutzen können Organisationen und Kreative ziehen, die eine schnelle, thematisch ausgerichtete soziale Interaktion ohne den Aufbau eines Back-Ends und ohne das „Aussiedeln“ ihres Publikums wünschen: lokale Medien und Kultureinrichtungen, Bildungsgemeinschaften, Open-Source-Teams und Vereine. Mit etwas Front-End-Wissen und einer klaren Vorstellung von Kanälen und Regeln können sie ihren eigenen Client zusammenstellen, sich in bestehende Inhaltsströme einklinken und dabei das Eigentum an dem behalten, was sie produzieren. Für eine breitere Anwendung – von massenhaften öffentlichen Diskussionen bis hin zu sensiblen Themen – wird die Qualität der Moderationsdienste, die Ergonomie der Clients und die von der Gemeinschaft vereinbarten Datenschutzstandards entscheidend sein.

Wie man anfängt: Design-Richtlinien für ein erstes Experiment

1. Definieren Sie Kanäle und Publikum: Bevor Sie die Benutzeroberfläche erstellen, kartieren Sie die Kontexte (Personen, Teams, Orte, Ereignisse) und entscheiden Sie, wo welcher Inhalt erscheinen darf, um einen Kontextkollaps zu vermeiden. Führen Sie klare visuelle Kontextmarkierungen und Standard-Datenschutzeinstellungen ein.


2. Modellieren Sie Interaktionen als Daten: Entscheiden Sie, welche Aktionen reifiziert werden (Qualitätskennzeichnungen, Rollen, Sperren, Meldungen, Eskalationen) und wie Ihre Anwendung sie interpretieren wird. Planen Sie die Möglichkeit ein, dass ein anderer Client dieselben Ereignisse anders interpretiert.


3. Wählen Sie Moderationsdienste: Beginnen Sie mit mindestens zwei unabhängigen Diensten, um das Nebeneinander verschiedener Richtlinien zu testen. Fügen Sie eine klare Anzeige der Quelle von Moderationsentscheidungen in der Benutzeroberfläche hinzu.


4. Sorgen Sie für eine portable Identität: Planen Sie Integrationen mit Protokollen, die die Migration und den Erhalt des sozialen Graphen erleichtern, und geben Sie den Nutzern an, wo ihre Daten gespeichert werden.


5. Iterieren Sie mit den Nutzern: Da die Erstellung von Clients einfach ist, nutzen Sie schnelle Prototyping-Zyklen; beobachten Sie die Auswirkungen auf die Kommunikationskultur, insbesondere über Kanalgrenzen hinweg.