Hallo allerseits!
Wie woanders bereits “versprochen” will ich in diesem Post die Technologie Nostr kurz vorstellen und evaluieren, wie sie vielleicht in einem “GCS” zur Anwendung kommen könnte. Ich stimme mit Marcus’ neueren Texten darin überein, dass nicht ein monolithisches System oder gar eine offizielle App erstellt werden sollte, sondern auf das Zusammenspiel existierender Anwendungen mittels gemeinsamer Standards und Vokabularen (z.B. ValueFlows) gesetzt werden sollte. Nostr könnte für einige dieser Funktionen vielleicht geeignet sein.
Nostr ist ein dezentrales Messaging-System und damit ein Konkurrent von Technologien wie ActivityPub (z.B. Mastodon), Diaspora, ATProto (Bluesky), ZOT (Hubzilla) oder auch SSB (Secure Scuttlebutt). Die Abkürzung Nostr steht für “Notes and other Stuff transmitted by Relays.” Nachrichten werden “Notes” oder “Events” genannt.
Die Kernidee: Jede Identität ist nur an ein Schlüsselpaar geknüpft, nicht an einen Server wie bei ActivityPub. Nachrichten werden mit dem eigenen Schlüssel signiert. Es ähnelt damit von den erwähnten Systemen am ehesten SSB, aber ohne ein chronologisches “Log”, was Vorteile und Nachteile hat (s.u.), außerdem ist es nur mit einem eigenen Relay wirklich P2P (SSB ist dies per Default). Die Identitäten/Konten können beliebig viele Server, sogenannte Relays, auswählen und über diese mit dem Rest des Netzwerks kommunizieren.
Die bisherigen Anwendungen reichen von Sozialen Netzwerken bzw. Microblogging (die Kernfunktion), über “Longtext”-Blogs und Frage-Antwort-Foren bis hin zu Videokonferenzen, Kleinanzeigenportalen und Marktplätzen, auch ein dezentrales Wiki ist möglich. Es bietet bereits nativ abgesehen vom “Following” eine Art Vertrauenssystem sowie Möglichkeiten, Identitäten mit anderen Netzwerken und Technologien zu verknüpfen (Identitätscluster). Auch gibt es Brücken ins Fediverse.
Nostr ist bisher eher in libertären als in linken Kreisen verbreitet und viele Nutzende haben eine enge Beziehung zur Bitcoin- und Krypto-Szene (richtige “Rechte” habe ich bisher aber selten gesehen). Das mag einige auf dem ersten Blick abschrecken, sollte aber für die Funktionalität nicht wichtig sein, und einige Solarpunk-affine Communities haben sich z.B. schon auf Nostr gegründet.
Vor- und Nachteile im Vergleich zu Konkurrenten:
Vorteile:
- Geht ein Server offline, kann schnell ein weiteres “Relay” eingestellt werden. Dabei bleibt die Identität gleich, es ist also kein aufwändiges Backup notwendig.
- Es hat weniger den Charakter eines “Netzwerks von Foren”, jedes mit einer eigenen Moderationspolitik usw., sondern eher den eines “monolithischen”, traditionellen sozialen Netzwerks. Dennoch moderieren Relays natürlich bei Bedarf, etwa bei Spam/Hatespeech-Attacken, und moderierte Foren sind möglich.
- Es ist schwieriger zu “zensieren”, da man, wenn man von einem Relay geblacklistet wird, einfach neue Relays auswählen kann. Solange man nichts komplett Verwerfliches oder gar Illegales tut, sollte sich immer ein Relay finden.
- Auch Regierungen haben es schwerer zu zensieren, da die Relays schneller entstehen können und nicht unbedingt Domains brauchen (wie etwa bei ActivityPub) die man zensieren könnte.
- Im Gegensatz zu SSB sind die Nachrichten ungeordnet. Das macht es einfacher möglich, einzelne Nachrichten zu löschen (aber weniger einfach als bei ActivityPub, und wirkliches Editieren ist nicht möglich). Durch das Signieren ist trotzdem keine Fälschung der Nachrichten möglich, jedenfalls solange das Schlüsselpaar nicht kompromittiert wurde. (Theoretisch wären sicher auch signierte “Logs” möglich.)
- Eine Identität kann sehr einfach auf mehreren Geräten gespeichert/genutzt werden (anders als bei reinen P2P-Technologien).
- Relativ einfach zu verstehendes und simples System.
- Es werden meist Standard-Libraries verwendet, anders als etwa bei SSB.
- Mit einem eigenen Relay (auf dem eigenen Rechner) kann Nostr in einer P2P-Struktur genutzt werden.
Nachteile:
- Spam-Management und Moderation ist wesentlich komplexer als bei ActivityPub. Durch den anonymeren Charakter der Relays im Vergleich z.B. zu Mastodon-Servern gibt es weniger psychologische Hürden, und Spammer und andere maliziöse User können die Relays einfach austauschen. Moderierte Foren sind möglich, dafür sind aber spezielle Clients notwendig.
- Auch als Konsequenz des Spamproblems sind einige Relays kostenpflichtig (meistens zahlbar über Kryptowährungen) oder nutzen Proof of Work (PoW) um die Kommunikation künstlich zu verlangsamen, indem ein Arbeitsbeweis wie ein Hash für jeden Post gefordert wird. PoW-Relays sind allerdings keine schlechte Idee für ein GCS. Im GCS werden zwar potenziell viele Nachrichten verarbeitet, aber eher wenige pro Person. Für eine Person stellt somit ein PoW pro Nachricht, das vielleicht einige Sekunden Rechenzeit erfordert, keine große Hürde dar.
- Etwas höhere technische Eintrittsbarrieren als bei ActivityPub. Zum Nutzen von Web-Apps ist eine Signing Extension nötig, die Schlüssel sicher verwahrt. Es gibt gute Mobile Apps, die Desktop-Apps (grafikbasiert wohl eigentlich nur Gossip) sind aber etwas enttäuschend.
- Timestamps von Nachrichten können anders als bei SSB gefälscht werden. Das macht es Spammern und Betrügern einfacher, eine Timeline zu verändern.
- Die erste Euphorie von ca. 2021/22 scheint vorüber, einige Apps wurden eingestellt (das ist allerdings auch bei vielen Konkurrenten so)
- Anders als bei anderen Konkurrenten habe ich bisher keine ValueFlows-Implementation gefunden. Die aber wahrscheinlich recht einfach zu realisieren wäre.
- Bilder und Videos müssen entweder selbst oder bei Drittanbietern gehostet werden (Relays verbreiten sie normalerweise nicht). Es gibt Vorschläge (wie NIP-71), Relays mit der Fähigkeit auszustatten, kleine Dateien bis hin zu kurzen Videos zu verarbeiten.
- Für ein wirklich sicheres offline-first ist ein eigenes Relay notwendig. Das ist technisch noch relativ anspruchsvoll. Gängige Clients speichern Nachrichten lokal, das macht aber das Nutzen auf mehreren Geräten komplizierter.
- Clients übernehmen einen großen Teil der Filterung der Nachrichten (“smart clients, dumb servers”), wodurch sie technisch mehr leisten müssen.
- Direktnachrichten werden verschlüsselt, aber öffentlich verbreitet (Broadcast).
- Suchfunktionen sind recht langsam und unzuverlässig, weil es davon abhängt welche Relays durchsucht werden können. Man könnte sich allerdings auf ein Set bestimmter Relays einigen, und diese als “autoritative Quellen” betrachten.
Um es kurz zu machen: Trotz einiger Nachteile scheint mir Nostr sehr interessant für einige der GCS-Aufgaben zu sein. Siehe dazu mehr unten.
Nostr-Ressourcen:
- https://nostr.org - Webprojekt
- Github für das Protokol
- NIPs - Standards und Verbesserungsvorschläge
- Awesome-Nostr - Anwendungen und Ressourcen
- Nostr and ATProto - Sehr guter Vergleich mit ATProto, aber auch ActivityPub und SSB
Interessante bereits bestehende Erweiterungen und Vorschläge:
für Mittel- und Ressourceneinsatz/Planung
- NIP-15: Ein “Marketplace”. Man könnte dieses Protokoll auf Basis von ValueFlows abwandeln mit mehr Kategorien.
- NIP-99: Classified Listings (“Kleinanzeigenportale”). Weniger strukturiert als NIP-15.
- NIP 52: Calendar Events - Events können in Kalender eingetragen und gelöscht werden)
- NIP 54: Dezentrales Wiki (allerdings wohl ziemlich rudimentär.)
für Identitätsmanagement
- NIP-58: Badges. Funktionieren ähnlich wie OpenBadges: Nutzerkonten können anderen ein Badge verleihen.
- NIP-39: externe Identitäten. (“Identitätscluster”, s. Meindel Kap. 3.15) Damit kann eine “neue” Person die im GCS aktiv werden will Hinweise darauf geben, dass sie eine reale Person ist. Gibt auch eine Möglichkeit einen Beweis zu verlinken.
- eventuell NIP 85: Trusted Assertions (Vertrauens-Provider): Wenn ich das richtig verstehe, kann hier eine vertrauenswürdige “Autorität” definiert werden. So könnte ein Projekt bestimmen, dass eine Person vertrauenswürdig ist, ohne komplizierte Web-of-Trust-Kalkulationen.
für Kommunikation und Entscheidungsfindung:
