- Nostr ist ein offenes Kommunikationsprotokoll ohne zentrale Kontrolle und als Architektur dafür ausgelegt, Informationen über verschiedene Kombinationen aus Clients und Relays frei zu verbreiten
- Nutzer sichern ihre Identität und die Echtheit von Nachrichten über persönliche Schlüssel und Signaturen, während Clients sich gleichzeitig mit mehreren Relays verbinden, um verteilte Verbreitung und Abfragen durchzuführen
- Das Protokoll hat keinen Eigentümer, aber jeder Relay-Betreiber legt nach eigenen Richtlinien Maßstäbe für Zensur und Sperren fest, und Nutzer wählen selbst aus, welche Relays sie lesen
- Über Twitter-artiges Microblogging hinaus erweitert sich das Ökosystem mit Sub-Protokollen wie geschlossenen Gruppen (NIP-29), Marktplätzen, dezentralen Wikis sowie Code-Zusammenarbeit/Torrents/Live-Streaming
- Es ist noch eher ein Stadium, das Beteiligung von Entwicklern und Early Adopters erfordert, als ein fertiges Produkt; Herausforderungen wie Spam, Skalierung und Auffindbarkeit werden derzeit mit Strategien zur Kombination von Clients und Relays angegangen
An open protocol with a chance of working
- Nostr zielt auf einen öffentlichen Kommunikationsraum unabhängig von politischer Ausrichtung und definiert als einfacher Standard, den jeder implementieren und nutzen kann, eine skalierbare Client/Server-Architektur
- Es wird nicht von einem bestimmten Unternehmen oder Staat kontrolliert und greift die offene, chaotische Sensibilität des frühen Internets auf, in der verschiedene Clients dieselbe Informationsebene aus unterschiedlichen Perspektiven zeigen
- Die Website zeigt echte Screenshots von Clients und betont die Vielfalt des Ökosystems sowie seine Ausrichtung auf reale Nutzung
Many clients, many servers
- Anders als bei zentralisierten Diensten verbinden sich Nostr-Clients mit mehreren Relays gleichzeitig
- Jedes Relay ist ein WebSocket-basierter Server und fungiert als verteiltes Speicher-Repository für Beiträge, in dem interessante Events abgefragt und abonniert werden können
- Da kein einzelnes Relay als einzige Vertrauensquelle dient, wird das Risiko von Zensur und Shadowbans verteilt
- Über verlinkte Referenzmaterialien werden die Unterschiede zum bisherigen Modell als Lernmaterial erläutert
A new paradigm for communication
- Die Nutzeridentität wird durch einen geheimen Private Key dargestellt, und alle Nachrichten enthalten eine digitale Signatur, sodass sich die Authentizität des Autors auch ohne Autoritätsinstanz prüfen lässt
- Diese auf Kryptografie basierende Vertrauensgrundlage ermöglicht zensurresistentes Broadcasting
- Ein Link zu einem leicht verständlichen Erklärvideo senkt die Einstiegshürde
The protocol is ownerless, relays are not
- Das Protokoll ist eigentümerlos, Relays hingegen sind in privater Hand, sodass jeder Betreiber eigene Kriterien für Annahme und Ablehnung festlegen kann
- Nutzer können frei wählen, welche Relays sie lesen, sodass Vielfalt des Ausdrucks und Wahlfreiheit beim Zugang nebeneinander bestehen
- Statt einer simplen Dichotomie aus „für oder gegen Zensur“ stehen pluralistische Regeln je Server und die Wahl der Nutzer im Mittelpunkt
Freedom of association
- Da der Netzwerkeffekt nicht an eine einzelne Organisation gebunden ist, ist die Struktur so angelegt, dass bestimmte Nutzergruppen anderen nur schwer strukturell schaden können
- Ein verlinktes Video betont die Freiheit zur Assoziation und Trennung
Your own piece of Nostr
- Programmierer können problemlos ein eigenes Relay betreiben und dabei eigene Regeln anwenden
- Ein Verweis auf Relay-Implementierungs-Repositories ermutigt zu Beiträgen und Experimenten
New Ideas — Exploring the commons
- Über Twitter-artiges Microblogging hinaus unterstützt Nostr viele Datentypen wie Videos/Langtexte/Bilder/Sprachnotizen
- Experimente mit Sub-Protokollen für geschlossene Gruppen, dezentrales Wikipedia, Couchsurfing, Marktplätze und Web-Anmerkungen sind aktiv im Gange
- Versuche laufen, Nostr als Entdeckungs- und Koordinationsschicht für git-basierte dezentrale Code-Zusammenarbeit, Dateihosting, Torrent-Sharing und Video-Livestreams zu nutzen
- Über die Sammlung von Standardvorschlägen NIP sollen Funktionsausbau und Interoperabilität vorangetrieben werden
Ecosystem — Still under construction
- Es gibt Open-Source-Software und eine große Nutzerbasis, doch noch ist das System kein ausgereiftes Endprodukt
- Die Beteiligung von frühen Nutzern und Entwicklern ist wichtig für den Ablauf des Protokolls und die Verbesserung der UX
Microblogging — The outbox model
- Das Outbox-Modell wird als Standardansatz für die Implementierung zensurresistenter Clients vorgestellt, doch die Parameter bleiben variabel
- Der Implementierungsleitfaden erklärt, wie Relays wie Speicher behandelt werden und welche Strategien für Abonnement und Veröffentlichung sinnvoll sind
Relay-based groups — NIP-29
- NIP-29 beschreibt eine effiziente relay-basierte Umsetzung von Forum-/Chat-artigen geschlossenen Gruppen
- Es zeigt eine Struktur, die die Abhängigkeit von einem einzelnen Relay verringert und zugleich Zensurresistenz aufrechterhält
How Nostr works
- Ziel ist es, auch unter widrigen Bedingungen echte Freiheit zu bieten, indem die Verbindung zwischen Nutzern und Publikum erhalten bleibt
- Mehrere Relays, lokales Indexing und selektives Lesen sollen dauerhafte Zugänglichkeit sicherstellen
FAQ — zentrale Fragen und Antworten
-
Was ist ein „Protokoll“
- Es ist eine gemeinsame Sprache, mit der verschiedene Software miteinander kommuniziert, und bedeutet wie bei e-mail/HTML/HTTP Interoperabilität, die nicht an eine bestimmte App gebunden ist
- Mehrere Apps, die dieselbe Sprache teilen, können sich gegenseitig ersetzen und sich dennoch in Ausdruck und UI unterscheiden
-
Wie wird mit Spam und unerwünschten Inhalten umgegangen
- Der Standard-Feed lädt nur Informationen von Personen, denen ich folge, wodurch Push-Spam schwer wird
- Offene Abfragen wie das Anzeigen von Kommentaren können Spam ausgesetzt sein; daher kommen Strategien zur Verringerung der Angriffsfläche wie Beschränkung auf Kontakte zweiten Grades, Whitelist vertrauenswürdiger Relays und kostenpflichtige/verifizierte Relays zum Einsatz
- Es gibt keine perfekte Lösung, aber Nostr ist mit Blick auf Resilienz entworfen
-
Ist Skalierung bei breiter Einführung möglich
- Die Grundlage ist eine Client-Server-Architektur, und da sich Nutzer natürlich über Hunderte von Relays verteilen, ist Lastverteilung bereits eingebaut
- Viele Relay-Verbindungen mögen bedenklich wirken, doch Menschen folgen meist Gruppen von Accounts mit ähnlichen Interessen, wodurch Relays auf natürliche Weise gemeinsame Schnittmengen bilden
- Native Apps können Hunderte von WebSockets bewältigen und sichern Leistung über lokale Datenbanken und Batch-Anfragen
-
Wie wird auf Online-Belästigung reagiert
- Ähnlich wie bei Spam sind unerwünschte Beiträge möglich; mit Blockieren, geteilten Sperrlisten und Relays mit eingeschränktem Lesekreis lässt sich die Exposition minimieren
- Schutzfunktionen wie nur für Freunde sichtbar können über Relay-Richtlinien emuliert werden
-
Warum nicht Mastodon/Fediverse
- Wegen des Fehlens von Kryptografie ist Multi-Master nicht möglich, was zu Problemen mit servergebundener Identität und übertragenem Vertrauen zwischen Servern führt
- Es erfordert übermäßiges Vertrauen in Serverbetreiber, zudem werden Abhängigkeiten von Domain und DNS als Problem genannt
- Nostr ermöglicht mit serverungebundener Identität und Relay-Auswahl die Bildung echter Communities auf Relay-Ebene
-
Warum nicht Bluesky/ATProto
- Durch die Zentralisierung der Identität auf PLC-Basis und den Fluss eines einzigen maßgeblichen Bestands über Relay-AppView-Client ist das Risiko von Zensur, Neuordnung und Shadowbans hoch
- Verbesserungen durch mehrere Quellen wären möglich, würden dann aber faktisch auf eine Nostr-ähnliche Struktur hinauslaufen
-
Sind die Anreize für den Betrieb von Relays ausgerichtet
- Die Betriebskosten von Servern sind niedrig, und Communities/Einzelpersonen/Organisationen/Hosting-Anbieter können Relays günstig bereitstellen
- Da Nutzer jederzeit woanders hingehen können, werden verschiedene wirtschaftliche Akteure aufeinander abgestimmt
-
Kann man sämtliche Inhalte sehen, die über mehrere Relays verteilt sind
- So wie man auch nicht alles auf der Welt sehen kann, ist Beobachtung nur innerhalb des Bereichs von Fokus und erlaubtem Zugang möglich
- Das ist eine natürliche Begrenzung durch Aufmerksamkeit und die Wahl der Relays
-
Wie funktioniert die Suche
- Im Kern ist nur suchbar, was bereits gesehen wurde; für öffentliche Suche müssen Crawler/Indexer das Netzwerk daher selektiv einsammeln
- Clients können Inhalte, die ich gesehen habe oder mit denen ich interagiert habe, über lokale Speicherung schnell per lokaler Suche finden
- Themen-Relays können durch eigenes Indexing nützliche Bereichssuchen anbieten
-
Wie entdeckt man ohne Algorithmus neue Inhalte
- Die Erkundung des Interaktionsgrafen der gefolgten Accounts ist der Standard, und auch Nostr kann lokale/relay-basierte/AI-gestützte Algorithmen haben
- Im Client lokal sind Highlights/Wiederentdeckung früherer Inhalte möglich, auf Relay-Seite etwa Kurationsmechanismen als unterschiedliche Mechanismen zur Auffindbarkeit
-
Welche Beziehung gibt es zu Bitcoin
- Es teilt kryptografische Prinzipien und stammt aus der Bitcoin-Community, hat aber keine Abhängigkeit davon
- Zaps sind ein von einigen Clients implementierter Bitcoin-Tipp-Standard und vollständig optional
1 Kommentare
Hacker-News-Meinungen
Man sollte wissen, dass die Kryptografie von Nostr gravierende Schwächen hat
Die in diesem Paper vorgestellten Hauptprobleme sind folgende:
Das Event-Protokoll authentifiziert keine öffentlichen Schlüssel, daher sind symmetrische Signaturen nur Formsache
Zwei wichtige Clients wie Damus und Iris verifizieren die Signaturen selbst gar nicht
DMs im System nutzen unauthentifizierte CBC-Verschlüsselung, sodass Angreifer den Inhalt per Bit-Flipping verändern können
Da Apps automatisch Link-Previews erzeugen, ist der alte EFAIL-Angriff wieder möglich
Im System gibt es keine Schlüsseltrennung, sodass Nutzer dazu gebracht werden können, Session-Keys falsch zu verwenden
Insgesamt sind das elementare Fehler auf dem Niveau der Mitte der 2000er
Nostr mag andere Vorteile haben, aber für End-to-End-Sicherheit ist es keine geeignete Plattform
Ich bin seit Langem in der Nostr-Community aktiv und habe auch eine Erweiterung für Safari gebaut
Ich habe das Paper nicht gelesen, aber ich glaube, dass die angesprochenen Punkte auf Missverständnissen oder Fehlannahmen über das Nostr-Protokoll selbst beruhen
Bei Nostr fungiert der öffentliche Schlüssel selbst als Identität
Kryptografisch ist eine auf öffentlichen Schlüsseln basierende Identität nicht fälschbar, Implementierungsfehler einmal ausgenommen
Aus UX-Sicht ist die Verifikation der realen Identität des Besitzers eines öffentlichen Schlüssels schwierig, aber das ist ein anderes Thema als kryptografische Sicherheit
Die Behauptung, das Event-Protokoll authentifiziere keine öffentlichen Schlüssel, ist völliger Unsinn
Die meisten Clients und Relays prüfen Signaturen tatsächlich
Als Autor von Damus kann ich sagen: Das bezieht sich auf eine alte Version — das Problem wurde behoben
Anfangs wurde nur mit vertrauenswürdigen Relays verbunden, und diese Relays verifizierten Signaturen
Für optimierte Signaturprüfung wurde sogar eine Embedded-DB namens nostrdb gebaut
Auch die Behauptung, DMs seien wegen unauthentifiziertem CBC angreifbar, ist falsch
Die komplette Note wird durch secp256k1-Signaturen abgedeckt
Automatische Link-Previews, Bilder usw. lassen sich an- und abschalten, und wenn man besorgt ist, empfiehlt sich ein VPN
Ich habe versucht herauszufinden, welcher Schlüsselalgorithmus in Nostr verwendet wird, aber in der Dokumentation wird das nirgends direkt angegeben
Bei der Suche landet man nur bei Blech32, also der Bitcoin-Schlüsselcodierung
In der Einführung auf hellonostr.dev sieht man, dass die Kodierung selbst Versionsinformationen enthält
Im Format
npub1abcxyz...istnpubder Header,1die Version und der Rest der SchlüsselSiehe die entsprechenden Dokumente
Die genannten Probleme sind in Wirklichkeit entweder implementierungsabhängig (Apps, die nicht signieren, was dem Wesen des Protokolls widerspricht)
oder gehen auf frühe provisorische Verschlüsselungsverfahren zurück (inzwischen durch NIP44 usw. ersetzt und unabhängig auditiert)
Derzeit gibt es keine fatalen oder praktisch dringend zu behebenden Probleme
Ich weiß nicht, warum ich davon jetzt zum ersten Mal höre
Das sollte schnell diskutiert werden
Mich würde interessieren, ob aus Protokollsicht Bluesky (AT Protocol) oder das Fediverse die sicherere föderierte Plattform ist
Viele Leute glauben fälschlicherweise, dass Nostr-Relays föderiert sind und Nachrichten untereinander austauschen
Das ist tatsächlich nicht so
Wenn man einen Twitter-Klon baut, muss die Client-App mehrere Relays direkt durchsuchen und direkt dorthin posten
Wenn man keine gemeinsamen Relays nutzt, sieht man die Nachrichten der anderen nicht
Nutzt man nur ein einziges Relay, wird es vollständig zentralisiert,
nutzt man mehrere Relays, ist es langsam und umständlich, sodass Nutzer selbst wissen müssen, welche Relays sie verbinden sollen
Auch die NIP-Dokumente waren ein Durcheinander, was die Wartung erschwerte
Relays können ebenfalls föderieren
Das Nostr-Protokoll sagt lediglich nichts dazu aus, ob Föderation stattfindet
Ich betreibe einen Indexer (Relay), und dieser Indexer interagiert mit anderen Relays
Wie bei einem ActivityPub-Relay kann sich jeder Client mit dem Indexer verbinden, bootstrapen und Event-Metadaten durchsuchen
Auch ohne Verbindung zum selben Relay können Clients auf verschiedene Weise Informationen austauschen
Ich halte das für eine sehr interessante harte Aufgabe
Wenn man wie in NIP65 Lese- und Schreib-Relays in den Profilmetadaten angibt,
können Clients alle relevanten Inhalte leicht finden
Darüber hinaus werden noch mehrere andere Ideen erprobt
Ich denke, das ist lösbar
Relays besitzen keine nutzergenerierten Inhalte, daher brauchen sie eigentlich keine Föderation
Clients stützen sich in der Regel auf ein vom Nutzer selbst ausgewähltes Set von Relays
Trotzdem speichern viele größere Relays auch Events anderer Relays, also eine Art Föderation
Beispiele: Primal, TheForrest, nostr.land
nostr.land ist ein kostenpflichtiges Relay, das sich vor allem auf Spamfilterung und das Aggregieren von Notes aus mehreren öffentlichen Relays konzentriert
Wer das nicht will, kann andere Relays wählen
Die meisten Nutzer können in der aktuellen Relay-Föderation wohl mehr als 99 % der Notes sehen, auch wenn sich das nicht verifizieren lässt
Einige Clients und Signer speichern Notes privat,
und wenn ein Relay Notes zensiert, kann man als Gegenmaßnahme jederzeit auf andere Relays reposten
Tatsächlich merkt man bei beliebten kostenpflichtigen Relays schnell bei drei von vier Schreib-Events die Warnung „bereits bei einem anderen Relay registriert“
Schließlich können Relays auch selbst als Clients fungieren, was als Cache praktisch ist, wenn Mobilfunk oder Netzwerk langsam sind
Das Outbox-Modell hat zwar Probleme, aber Client-Entwickler können Optionen anbieten,
sodass es sich flexibel von föderierten Modellen bis hin zu P2P erweitern lässt
Die meisten Clients unterstützen Outbox, daher muss man nicht dieselben Relays verwenden
Jeder Nutzer kann separate Inbox- und Outbox-Relays haben
In den NIP-Dokumenten gab es zwar seltsame Stellen,
aber die meisten NIPs werden gut verbessert,
und mit offiziellen regelmäßigen Releases wäre das ein eher kleines Problem
Viele Entwickler reagieren sehr schnell
Es wäre gut, wenn solche Projekte Anwendungsfall, Philosophie und Implementierung klarer voneinander trennen würden
Am Anfang erkennt man nicht, ob das ein soziales Netzwerk oder ein Protokoll ist
„Ist das auf Zensur ausgerichtet? Muss ich Blogartikel lesen?“
Bei Scuttlebutt, Mastodon, ActivityPub, Diaspora usw. ist es genauso
Was genau ist eigentlich „anders als E-Mail“ und „besser als Twitter“?
Bevor man das versteht, ist schon unklar, ob es sich um eine technische Implementierung, ein Produkt, eine Website oder eine App handelt
Wahrscheinlich gibt es auch nicht viele Menschen, die Urbit präzise erklären können
Trotzdem ist es aus meiner Sicht besser als „Web3“
Bluesky und Gemini sind in diesem Punkt recht klar
Nostr ist eine Kompromisslösung zwischen einer P2P-Struktur und der Web-Architektur
Es nutzt Webserver und passt sich damit dem Fluss des Internets an,
während Nutzer ihre Abhängigkeit von Servern verringern und Identität sowie Datenauthentifizierung durch öffentliche Schlüssel und Signaturen stärken
Daraus ergibt sich für Nutzer eine Art „credible exit“ und damit mehr Handlungsmacht
Deshalb wird es eher als „neues Internet“ denn als neuer Use Case bezeichnet
Es gibt also nutzerzentrierte statt plattformzentrierte Trade-offs, einschließlich anderer UX-Muster
Weil es ähnliche Werte wie bestehende soziale Netzwerke mit Zensurresistenz bietet,
scheint es viele gesellschaftliche Anwendungsfälle zu geben
Du solltest so eine Website selbst bauen
Dass in der ersten Zeile der Produktbeschreibung das Wort „apolitical“ steht, wirkt sehr seltsam
Gleichzeitig taucht dort auch „open“ auf, was hier im Kern ebenfalls politisch ist
Ich erinnere mich nicht mehr genau, ob Nostr eine Verbindung zu Kryptowährungen hatte, aber irgendetwas daran war verwirrend
Nostr hat weder eine „nostr coin“ noch On-Chain-Aktionen
Das gefällt mir sehr
Gerade weil sich Nostr und die Krypto-Community für mich fast vollständig zu überschneiden schienen
Es gibt viele Nutzer, die hauptsächlich Bitcoin verwenden
Rechte haben eine lange Geschichte darin, sich selbst als „apolitical“ zu bezeichnen
Bei föderierten/dezentralen Diensten wie Nostr, Mastodon oder Discord ließe sich ein wirklich dezentrales soziales Netzwerk nur dann verwirklichen, wenn die Client-App selbst ihr eigenes Relay eingebaut hätte, sodass alle Nutzer auch Server betreiben
Klassische P2P-Software hat genau das schon lange getan und es funktioniert tatsächlich gut
Wenn Nutzer allerdings beliebige Daten hosten, die sie nicht selbst erhalten haben,
entsteht ein Problem mit strafbaren Inhalten, ähnlich wie bei Fällen, in denen man am Flughafen mit illegalen Drogen erwischt wird
Wegen dieses Risikos braucht die nächste Generation von P2P-Strukturen KI-basiertes Filtern illegaler Inhalte, etwa von CSAM oder Filmen
Oder man macht alles zu einer vollständig geschlossenen Community,
sodass im Problemfall nur innerhalb der Community Verantwortung getragen werden muss
Letztlich ist ein Modell, in dem alle Clients auch Server sind, das beste dezentrale soziale Modell
Das Projekt iroh funktioniert so
„Relays“ dienen dort nur dazu, Verbindungen zwischen zwei Clients zu vermitteln
Siehe die Erklärung unter iroh concepts relay
Klingt cool, aber echte P2P-Strukturen funktionieren in der Praxis nicht gut
Selbst iroh ist intern auf Relays angewiesen
Nostr gibt Relays bewusst die Befugnis zur Durchsetzung von Regeln, ohne dass man das separat hineinpatchen muss
Schön, Nostr ganz oben auf HN zu sehen
Es ist noch früh, aber Nostr ermöglicht auch „zaps“ (sofortige Mikrozahlungen auf Basis von Bitcoin Lightning)
Damit entsteht ein dezentrales werbefreies SNS-Modell, bei dem Kreative direkt per Mikrozahlungen vergütet werden können,
ganz ohne Werbung oder Algorithmus-Probleme
Auch Arbeit an PRs für Nostr-Clients kann per zaps vergütet werden
Siehe dieses Bounty-Beispiel
Bitcoin ist bereits stark reguliert
Wenn ich solche Kommentare lese, bekomme ich Lust, mich anzumelden, aber auf der eigentlichen Explore-Seite
fand ich beeindruckend, dass Menschen dort echte Produkte handeln (Maschinen, Kakao, alternative Bildung usw.)
Es ist nicht einfach nur „mein Tagebuch veröffentlichen und um Geld bitten“
Es ist eine Plattform für reale Produkte oder Dienstleistungen und für Kreative
Nostr existiert mindestens seit fünf Jahren
Schon während der Pandemie wechselten viele Menschen von Twitter zu Nostr
Daher fällt es mir schwer, der Formulierung zuzustimmen, es sei gerade erst in einer frühen Phase
Vorstellung verschiedener Nostr-Apps
openux.app - Alternative zu Mobbin
kinostr.com - Echtzeit-Filmchat
zap.stream - Live-Streaming im Twitch-Stil
dtan.xyz - Torrent
zapstore.dev - erlaubnisfreier App-Store
nostrnests.com - Audio-Room-Chat
zapmeacoffee.com - ähnlich wie Buy Me A Coffee
asknostr.site
So ermöglicht ein dezentrales soziales Protokoll viele verschiedene Anwendungsfälle,
und die Vorteile auf Nutzerseite sind
Nostr muss nicht nur als Microblogging-Dienst verwendet werden, sondern kann auch auf unteren Ebenen vielfältig eingesetzt werden
Beispiel: Trystero
nutzt Nostr, um ohne zentralen Server P2P-WebRTC-Verbindungen herzustellen
(MIT-Lizenz)
Ich habe auch schon über zensurresistente Multi-Channel-Broadcasts mit Nostr, Bittorrent DHT, Mastodon usw. nachgedacht
Das Ziel wäre, dass es erst dann zu einem Netzwerkausfall kommt, wenn wirklich alle Methoden scheitern
In ähnlicher Weise habe ich mich gefragt, ob Nostr oder ATProto
auch als „Offline-Nachrichtenspeicher“ für P2P-Instant-Messenger genutzt werden könnten
Die Nutzung für den Verbindungsaufbau ist auf jeden Fall ein origineller Ansatz
Wirklich eine großartige Idee
Ich wollte selbst etwas Ähnliches machen, aber es spart mir Zeit, dass jemand anders es schon gebaut hat
Ich verstehe nicht, warum solche technisch geprägten sozialen Netzwerke nicht wie das frühe Web
auf verknüpfte persönliche Homepages setzen
und stattdessen zu separaten accountbasierten Plattformen werden
Abseits von RSS frage ich mich, ob es keine Netzwerke gab, die den Betrieb persönlicher Websites fördern
und zusätzlich zentrale Social-Media-Funktionen wie Chats oder Feeds darüberlegen
Mit „Account“ ist hier im Grunde ein öffentliches/privates Schlüsselpaar gemeint
Man kann auch sein eigenes Relay betreiben,
und denselben öffentlichen Schlüssel auf beliebigen Relays verwenden
Posts lassen sich an alle gewünschten Relays broadcasten
Wenn man will, kann man sogar für jeden Post neue Schlüssel erzeugen
Bei Mastodon usw. ist der Account an einen Server gebunden, daher sind Mobilität und Freiheit geringer
Ein Problem ist allerdings, dass es überhaupt keine Möglichkeit zur Account-Wiederherstellung gibt
Ein Blick auf RSDS (Really Simple Decentralized Syndication) könnte sich lohnen
Im Großen und Ganzen ist nostr genau so aufgebaut
nur dass statt Websites der Datentyp „Note“ und statt Servern nur „Relays“ verwendet werden
Ich frage mich, warum du es ausdrücklich für einen Dienst für Techniker hältst
Unterstellst du damit nicht zu viel über das Denken der Gründer?
Im Kern kann man schon heute durch die Kombination verschiedener Technologien
eigene Systeme für persönliche Homepages, Chats und Feeds bauen
Das praktische Problem solcher Hybridmodelle ist jedoch
Wenn man all das gleichzeitig lösen will, entstehen zwangsläufig Kompromisse
Vollständige Dezentralisierung wird mit Auffindbarkeits- und Zugänglichkeitsproblemen erkauft
Auch die Behauptung, „man brauche keine Accounts mehr“, ist mit Fragen multipler Online- und Offline-Identitäten verknüpft
Letztlich ist das eine Frage der Werte, und viele experimentelle dezentrale Dienste, die bei Technikern beliebt sind (z. B. Mastodon, Nostr, Smolweb),
tragen das Mindset des frühen Internets in sich: Gegenkultur, Offenheit, Standardisierung und Kombinierbarkeit
Da es keinen Weg gibt, der alle zufriedenstellt,
denke ich, dass die eigentlichen Werte des Internets in Vielfalt, Standardisierung und Offenheit liegen
„apolitical communication commons“
Manche weisen darauf hin, dass schon das Etikett „unpolitisch“
selbst eine politische Aussage und eine Machtposition ist
Ich frage mich, warum die Angst vor „Politik“ so groß ist
Als Beispiel wird das Grundprinzip des antiken Griechenlands genannt, dass politische Teilhabe als Bürger eine selbstverständliche Pflicht sei
Tatsächlich leitet sich das Wort „idiot“ etymologisch von einer unpolitischen Person ab
Das Konzept „apolitical“
wird in autoritären Regimen oft als stillschweigende Unterstützung des bestehenden Systems verstanden
In Diktaturen wie Russland ist das ein direkter Weg zu Unterdrückung und Repression
Dienste wie Nostr wurden bereits dadurch blockiert, dass Regierungen den Betrieb von Relays für illegal oder kriminell erklärten
„Wenn alles politisch ist, dann ist nichts politisch“
Der Autor scheint einfach nichttechnische Debatten vermeiden zu wollen
„apolitical“ kann man auch so lesen, dass jeder willkommen ist
Die einzige Zugangshürde ist eine Internetverbindung
Wahrscheinlich war es im Kontext einer Gegenreaktion auf den Zensurtrend in sozialen Medien der letzten zehn Jahre gemeint
Manche sagen auch, man solle die Privilegien einer bestimmten Position nutzen, um anderen zu helfen
Das ließe sich auch hier anwenden