Was ist ein Nostr-Relay? Ein einfacher Leitfaden

Jede Nostr-Nachricht durchläuft ein Relay. Dein Client sendet signierte Events an Relays; die Clients anderer Benutzer holen Events von Relays ab; wiederhole das für jeden Beitrag, Like, Follow und DM. Das Relay ist keine glanzvolle Komponente, aber es ist die Komponente, die das Netzwerk zum Funktionieren bringt.

Dieser Leitfaden behandelt, was ein Relay wirklich ist, was es tut und nicht tut, und wie man darüber nachdenkt, welche Relays für deine Nutzung wichtig sind.

TL;DR. Ein Relay ist ein kleiner Server, der signierte Nostr-Events über WebSocket akzeptiert, speichert und an Abonnenten weiterleitet. Es gibt kein „das" Nostr-Relay; das Netzwerk besteht aus Tausenden unabhängiger Relays, die nicht koordiniert werden. Dein Client verbindet sich gleichzeitig mit mehreren; die Vereinigung ist deine Sicht auf das Netzwerk.

Wenn du bereit bist, sicher dir dein @nostr.blog →

Was ein Relay tut

Drei Aufgaben, alle einfach.

Events akzeptieren. Ein Client öffnet eine WebSocket-Verbindung und sendet eine EVENT-Nachricht mit einem signierten JSON-Objekt. Das Relay verifiziert die Signatur (stimmt sie mit dem behaupteten Pubkey überein), prüft optional gegen Richtlinien (Spam, Ratenlimits, Blocklisten) und akzeptiert oder lehnt ab. Akzeptierte Events gehen in den Speicher.

Events speichern. Relays verwenden eine lokale Datenbank (normalerweise SQLite oder PostgreSQL), die nach Event-ID, Author-Pubkey, Kind und Tag-Werten indiziert ist. Dies ermöglicht es ihnen, effizient auf Abonnementfilter zu reagieren.

Abos bedienen. Ein Client sendet eine REQ-Nachricht mit einem Filter („Gib mir Events von diesen Autoren, dieser Arten, seit diesem Zeitstempel, begrenzt auf 100"). Das Relay fragt seine Datenbank nach übereinstimmenden gespeicherten Events ab, streamt sie, sendet dann EOSE (Ende der gespeicherten Events) und hält das Abo offen. Jeder neue Event, der dem Filter entspricht, wird in Echtzeit an den Client gepusht.

Das ist die vollständige Relay-API, mit kleineren Varianten. Ein Relay tut nichts anderes: kein Ranking, keine Empfehlung, keine Moderation über die eigenen Richtlinien hinaus, keine Relay-übergreifende Koordination.

Was ein Relay nicht tut

Mehrere Dinge, die ein Relay theoretisch tun könnte, aber normalerweise nicht tut.

Mit anderen Relays sprechen. Relays sind unabhängig. Sie synchronisieren sich nicht gegenseitig. Wenn ein Beitrag auf Relay A aber nicht auf Relay B ist, sieht ihn jemand, der nur von B liest, nicht. Die Replikation passiert, weil Clients auf mehreren Relays veröffentlichen, nicht weil Relays sich gegenseitig spiegeln.

Globale Regeln durchsetzen. Jedes Relay hat seine eigenen Regeln. Was der eine ablehnt, akzeptiert der andere. Es gibt keine globale Richtlinienautorität.

Off-Chain-Ansprüche verifizieren. Ein Relay akzeptiert signierte Events; es verifiziert nicht, dass „alice@example.com" in einem NIP-05-Feld tatsächlich dem Pubkey des Events entspricht. Das ist die Aufgabe des Clients.

Als Plattform fungieren. Ein Relay ist keine Website mit einer Startseite, einem Feed oder einer Marke. Es ist ein Backend. Benutzer interagieren niemals direkt mit Relays; Clients tun es.

Warum das Design ungewöhnlich ist

Die meisten Netzwerke haben Server, die viel tun. Eine Mastodon-Instanz ist nicht nur ein Relay; es ist eine vollständige Twitter-ähnliche Webanwendung mit Benutzern, Profilen, Zeitleisten, Moderationstools, Admin-Dashboards. Ein XMPP-Server hat Benutzer, Räume, MUC, Pubsub. Ein Matrix-Homeserver ist eine schwere Software.

Nostrs Relay ist bewusst minimal. Ein Relay kennt seine Benutzer nicht (keine Benutzerkonten auf dem Relay). Ein Relay besitzt seinen Inhalt nicht (die Authentizität des Inhalts kommt von Signaturen, nicht von wem es gespeichert hat). Ein Relay föderiert nicht (keine Koordination auf Protokollebene mit anderen Relays).

Diese Minimalität ist der Grund, warum es so viele Relays gibt. Der Betrieb ist billig, weil ein Relay so wenig tut. Ein VPS im Bereich von 5 $/Monat kann ein Relay mit Hunderten aktiven Benutzern betreiben. Vergleiche das mit dem Betrieb einer Mastodon-Instanz, die in ähnlichem Maßstab erheblich mehr Ressourcen und Wartung erfordert.

Standard-Relays vs. benutzerdefinierte Relays

Jeder Nostr-Client wird mit einer Standard-Liste ausgeliefert. Häufige Einträge ab 2026:

• wss://relay.damus.io (von Damus betrieben, hohes Volumen)
• wss://nos.lol (von der Community betrieben, kostenlos)
• wss://relay.primal.net (von Primal betrieben)
• wss://offchain.pub (Community, stabil)
• wss://relay.nostr.band (Aggregationsfokus)
• wss://nostr.wine (bezahlt, Spam-gefiltert)

Diese funktionieren für die meisten Benutzer. Die ersten drei handhaben den meisten täglichen Datenverkehr. Sie zu ersetzen ist nicht notwendig, es sei denn, du hast einen Grund. (Wenn du dich über nostr.blog angemeldet hast, ist eine kuratierte Standard-Relay-Liste bereits für dich konfiguriert; du kannst sie später in den Einstellungen anpassen.)

Gründe für Anpassung:

• Leistung. Ein Relay, das dir geografisch näher ist, ist schneller. Wenn du in Asien bist, füge ein asiengestütztes Relay hinzu und beschleunige deine Lesevorgänge.
• Datenschutz. Wenn du nicht möchtest, dass ein bestimmtes großes Relay deine Abonnementmuster sieht, verwende unterschiedliche.
• Themenspezialisierung. Einige Relays konzentrieren sich auf bestimmte Themen oder Communities. Die Verbindung mit ihnen erhöht deine Sichtbarkeit für diesen Inhalt.
• Spam-Toleranz. Wenn du von Spam überrannt wirst, könnte sich ein Spam-gefiltertes bezahltes Relay lohnen.

Wie viele Relays solltest du verwenden

Drei oder vier sind normalerweise das Sweet Spot. Mehr ist nicht immer besser.

Zu wenige (1-2). Ein Ausfall eines einzelnen Relays verstummt deine Beiträge vorübergehend. Nicht genug Redundanz.

Genau richtig (3-6). Deine Beiträge erreichen genug Orte, dass Ausfälle keine Rolle spielen. Die Leseleistung ist gut, weil der Client Abfragen über sie rassen kann.

Zu viele (10+). Jedes Relay fügt Latenz und Datenübertragung hinzu. Clients müssen alle abfragen; langsame halten das ganze Feed auf. Akku und Bandbreite gehen ohne proportionalen Nutzen in die Höhe.

Im Zweifelsfall die Standards verwenden. Wenn du etwas Bestimmtes anstrebst, passe schrittweise an.

Relay-Richtlinien sind wichtig

Jedes Relay hat ungeschriebene oder schriftliche Regeln über das, was es akzeptiert. Die meisten sind nachsichtig; einige sind streng. Ein paar häufige Richtlinientypen:

Schreib-offen, Lese-offen. Jeder kann posten, jeder kann lesen. Meiste Community-Relays.

Schreib-bezahlt, Lese-offen. Du zahlst eine kleine Gebühr zum Posten; jeder kann deine Beiträge lesen. Meiste bezahlte Relays. Reduziert Spam dramatisch.

Whitelist. Nur genehmigte Konten können posten. Wird für Unternehmens- oder Community-Relays verwendet.

Themenfilter. Akzeptiert nur Events, die bestimmte Kriterien erfüllen (Hashtag, Kind, Länge).

Geofenced. Akzeptiert nur Benutzer aus bestimmten Regionen. Selten.

Bevor du dich auf ein Relay verlässt, überprüfe seine schriftlichen Richtlinien (normalerweise unter /.well-known/nostr.json oder dem Info-Endpunkt des Relays). Wenn dein Postmuster nicht mit den Richtlinien des Relays übereinstimmt, schlagen Schreibvorgänge lautlos fehl.

Betreibe dein eigenes Relay

Überraschend einfach. Ein grundlegendes Setup:

1. Miete einen VPS (im Bereich von 5 $/Monat ist in Ordnung).
2. Installiere eine Relay-Implementierung. strfry und nostream sind die zwei häufigen Open-Source-Optionen.
3. Öffne Port 443 oder 8080; zeige DNS auf den Server.
4. Starte das Relay.

Gesamtzeit: unter einer Stunde für jemanden, der sich mit Linux auskennt. Keine komplexe Konfiguration erforderlich standardmäßig. Der Betrieb eines Relays für dich selbst oder eine kleine Community erhöht die Ausfallsicherheit des Netzwerks und gibt dir explizite Kontrolle über einen Teil deiner Nostr-Daten.

Ein spezieller Leitfaden dazu ist in run-your-own-relay enthalten.

Relays und Datenschutz

Jedes Relay, mit dem du dich verbindest, sieht:

• Deine IP-Adresse
• Die Filter, auf die du dich abonnierst (welche Pubkeys du liest, welche Hashtags du überwachst)
• Deine Beiträge (ihren Inhalt, da du sie hier veröffentlicht hast)
• Zeitpunkt deiner Aktivität

Relays sehen nicht:

• Inhalt verschlüsselter DMs (nur Chiffretext)
• Deinen privaten Schlüssel

Für Benutzer, die sich um die Minimierung von Relay-Level-Metadatenleckage sorgen:

• Verwende Tor oder ein VPN.
• Verteile deine Lesevorgänge auf viele Relays, damit keiner das ganze Bild sieht.
• Verwende Clients, die Relays für verschiedene Abonnementtypen rotieren.

Die meisten Benutzer brauchen davon nichts. Das Datenschutzmodell des Protokolls geht davon aus, dass Relays halbvertraute, halb-öffentliche Infrastruktur sind; es ist nicht dazu ausgelegt, deine Aktivitätsmuster vor ihnen zu verbergen.

Relays auswählen: eine einfache Regel

Wenn du neu bist: behalte die Standards.

Wenn du über etwas spezifisch frustriert bist (Spam, Geschwindigkeit, Zuverlässigkeit): ändere nur das, das dich frustriert. Füge ein oder zwei Relays hinzu, oder tausche das aus, das dich ärgert.

Wenn du fortgeschritten bist: kuratiere absichtlich. Wähle 4-6 Relays, die deine Anforderungen erfüllen (Geografie, Themen, Vertrauensstufe) und verwalte sie sorgfältig.

Wenn du paranoid bist: verteile auf genug unabhängige Relays, dass kein einzelner Betreiber deine vollständige Aktivität sieht. Verwende Tor. Mische Regionen.

Der falsche Zug ist, Dutzende Relays hinzuzufügen in der Hoffnung, dass mehr besser ist. Langsame Clients und verschwendete Bandbreite sind das Ergebnis, nicht eine bessere Erfahrung.