Im Fediverse sehe ich in Bezug auf die individuelle Datenhoheit derzeit das Problem, dass die überwiegende Mehrheit der User*innen dort nur eine begrenzte Verfügung über ihre Daten hat. Es geht dabei zum einem um das banale Bedürfnis, dass ich als gewöhnliche*r User*in mich komplett (im Sinne von den gesamten Inhalt meines Social Graphs, also auch die Posts) auf eine andere Instanz umziehen können sollte. Zum anderen geht es um einen Ausweg für Worst-Case-Szenarien z. B. die Instanz geht plötzlich unerwartet offline, die Instanz schließt die Umzugsmöglichkeit oder deföderiert sich vom Rest des Fediverse. Wie können sich User*innen in so einem Fall migrieren und zwar so, dass sie alle ihre Daten mitnehmen und gleichzeitig die Authentizität ihrer Identität gewährleistet bleibt? 2/11

Hier im Fediverse wird dazu ein Lösungsansatz unter dem Namen "Nomadic Identity" diskutiert, den Hubzilla bereits im eigenen Zot/Nomad-Protokoll umgesetzt hat, und inwiefern diese auch in das ActivityPub-Protokoll (also für alle Fediverse-Anwendungen) übernommen werden kann. Am Nomad-Protokoll wird parallel unter dem Namen "Streams" als eigenständige ActivityPub-basierte Server-Applikation gearbeitet. Aktuell befinden sich jedoch eine deutlich überwiegende Mehrheit der Menschen auf Mastodon-Instanzen und dort ist eine Migration weder offline noch unter Mitnahme aller Inhalte möglich (siehe offene Mastodon Issues zu "Multihoming" 19924, "Support Post Migration" 12423, "Integrate Zot Protocol" 9666). De facto sind im Fediverse derzeit die Instanz-Administrator*innen die Einzigen, die eine gewisse Hoheit über ihre Daten für sich reservieren können (abgesehen von einem minimalen Prozentsatz an Hubzilla/Zap-User*innen). 3/11

Nostr wiederum verschlüsselt (im Gegensatz zu ActivityPub) grundsätzlich alle Inhalte mit einem Public-Private-Key-Verfahren, verlagert die Datenhoheit auf die Betreibenden von Relays und gibt die Schlüssel zur Entschlüsslung der Inhalte in die Hände der User*innen, die über diese Relays kommunizeren. Leider zeigt die fehlende Adaption von E-Mail-Verschlüsselung in der breiten Bevölkerung, wie schwer es auch grundsätzlich ist, das Public-Private-Key-Paradigma zu vermitteln. Wir sollten aber auch meiner Meinung nach an den Vermittlungsbemühungen festhalten, weil dezentrale Public-Key-Infrastrukturen (DPKI) immer noch eine der solidesten Lösungen für sichere Kommunikation sind, die wir momentan haben. Und ich denke, Nostr als eines von vielen Beispielen zeigt ganz gut, wie intuitiv bedienbare DPKI-Oberflächen aussehen können. 4/11

Aber wie im Fediverse sind auch bei Nostr de facto wieder die Server-Administrator*innen (der Relays) im Vorteil, weil diese sowohl über die relayten Daten verfügen als auch eine Art Gatekeeper-Funktion haben. User*innen, die nicht im Stande sind, sich einen eigenen Relay aufzusetzen, sind zwar idealerweise mit mehreren Relays gleichzeitig verbunden, aber geben die Hoheit über ihre Daten an die Betreibenden der Relays ab und müssen diesen vertrauen. Damit stehen die User*innen vor dem selben Vertrauensproblem, wie bei der Instanzwahl im Fediverse und bei Nostr ist die Möglichkeit für einen offline Datenexport bzw. eine lokale Ablage der Daten im Fall eines Relay-Shutdowns noch weniger fortgeschritten als im Fediverse. Beim Gatekeeping stehen die Nostr-Relay-Betreibenden aktuell auch vor der selben Herausforderung, die sich im Fediverse bei der Moderation von Instanzen stellt: Es müssen sinnvolle Mechanismen eingebaut werden, um Spam, illegale Inhalte und bösartige Akteure (wie auch immer diese Begriffe definiert sein mögen) abzuwehren. 5/11

Die Implementierung von Ende-zu-Ende-Verschlüsselung (E2EE) ist im Fediverse schon lange in der Diskussion und es gibt einige Ansätze, vor allem aus der Mastodon-Community (siehe Mastodon E2EE proposal von soatok, Mastodon Issues "Add end-to-end encryption API" 13820 und "support zero-knowledge encryption for toots/DMs" 19565), aber keiner davon ist bisher produktionsreif. Nostr ist da schon weiter: Dort werden im Gegensatz zu ActivityPub die Inhalte der DMs Ende-zu-Ende-verschlüsselt. Hier offenbart sich aber das Problem, dass trotzdem nicht die Wahrung der Privatsphäre der User*innen gewährleistet ist. Alle Interaktionen (Events) der User*innen bei Nostr, also wer mit wem wann kommuniziert (= die Metadaten), sind öffentlich abrufbar, eingeschlossen DMs. Im NIP-04 weisen die Nostr-Entwickler selbst darauf hin, dass der Standard hinter DMs nicht den gängigen Konventionen der verschlüsselten Kommunikation entspricht. 6/11

Wer sich mal mit der Wirkmächtigkeit von Metadaten und Tracking auseinandergesetzt hat, weiß, wie einfach sich aus solchen Daten Verhaltensmuster von Leuten ablesen und intime Personenprofile erstellen lassen, und das ohne die Inhalte zu kennen. Noch kritischer wird es dann, wenn Zahlungsverkehr dazu kommt und den gibt es bei Nostr auch (Zaps aka Bitcoin-Lightning-Zahlungen). Weil momentan jede Nostr-Entität gleichzeitig einem Public Key entspricht sind alle Interaktionen auch eindeutig einer Identität (= Person*en hinter dem PubKey) zuordenbar. Für eine ernstzunehmende E2EE-Implementierung bei einem Sozialen-Netzwerk-Protokoll ist es entsprechend von kritischer Relevanz, auch die Metadaten zu verschlüsseln. 7/11

Weiter ist bei einem Ende-zu-Ende-verschlüsselten sozialen Netzwerk fraglich, ob es klug ist, dass die Identitäten eines*einer / jeden*jeder Nutzers*in allein an einem Public-Private-Key-Paar hängt, wie es bei Nostr der Fall ist. Nicht nur, dass die Identität futsch ist, wenn der Private Key verloren geht oder gestohlen wird, sondern damit ist auch kein vernünftiges Key-Management möglich. Mit vernünftig meine ich die Möglichkeiten, Schlüssel zu revoken und zu wechseln, idealerweise auch eine Backup-Möglichkeit. Auch sollte der verwendeten kryptografische Algorithmus eine gewissen Interoperabilität, Performance und Rehashing-Kapazitäten aufweisen. Nur bei solch einer gegebenen kryptografischen Portabilität und Interoperabilität wird ein DPKI-System integrierbar, skalierbar und bleibt zukunftstauglich. 8/11

Gemeinsam haben sowohl das Fediverse als auch Nostr aktuell das Problem, dass sie sich auf Web-/DNS-basierte Dienste verlassen, um die Authentizität der Identität ihrer User*innen herzustellen. Das gesamte Fediverse basiert auf Instanzen, die ausschließlich per DNS (Web-Domain) erreichbar sind und User*innen greifen zur Verleihung der Authentizität ihrer Identität nicht selten auf die Verknüpfung ihres Profils mit ihrer eigenen DNS-basierten TLD-Domain oder zentralisierten Diensten wie GitHub, Twitter, Discord etc. zurück. Nostr-User*innen greifen ebenfalls entweder auf einen Nachweis per DNS-basierter Web-Domain (NIP-05) oder die selben zentralen Identitätsprovider zurück, um ihrer Identität Legitimität zu verleihen. Dazu werden auch Web Key Directories (WKDs) betrieben, auf denen Nostr-User*innen freiwillig ihre Identität und die Nachweise hinterlegen können. 9/11

Zum einen sollte aber der Ausgangspunkt sein, dass sich nicht alle 8 Milliarden Menschen auf der Welt eine eigene Web-Domain leisten können und daher auf eine günstige Methode für ihre digitale Identität angewiesen sind. Zum anderen hat uns die Vergangenheit gezeigt, dass Web-Domains und WKDs kompromittierbar sind und auch wie anfällig die zentralen Identitätsprovider für Leaks, Hacks, Ausfälle und Übernahmen sind, eben weil sie so viele Nutzer*innendaten akkumulieren. Aus diesem Grund haben sich im Feld der dezentralen Identitätslösungen über die vergangenen Jahre Menschen zusammengefunden und Gedanken zu einer Erneuerung des Web of Trust gemacht, woraus u. a. Self-Souvereign Identity (SSI), Trust Over IP (ToIP) und die W3C-Standards Verifiable Credentials (VCs) und Decentralized Identifiers (DIDs) hervorgegangen sind. 10/11

Ich bin daher guter Dinge, dass wir in Zukunft mit DIDs eine die verschiedenen Akteuere vereinende Komponente für dezentrale Protokolle haben werden, z. B. gibt es bereits mit did:orb eine DID-Methode, die mit ActivityPub arbeitet und mit Chatter Net genauso eine ActivityPub-Anwendung, die mit einer DID-Methode (did:key) arbeitet. Aktuell ist Bluesky mit dem AT-Protokoll das einzige dezentrale soziale Netzwerk, das DIDs in einer Form nutzt, um die von mir in diesem Thread beschriebenen Probleme zu lösen (siehe ATP Specs und did:plc). Das muss aber nicht so bleiben. In der Nostr- und ActivityPub-Community werden DID-Methoden bereits diskutiert. Wer bis zu diesem Ende gelesen hat, weiß jetzt ein paar Anhaltspunkte, um sich weiter in die Materie einzuarbeiten. 11/11