Nostr
Plattform · die Analyse ist aus den offiziellen Seiten der Plattform selbst und der helfenden Tools.
Siehe auch: wie man die Steckbriefe liest и über die Quellen und über die Methode.
Überblick
Nostr ist keine Plattform, sondern ein Protokoll. Der Name steht für Notes and Other Stuff Transmitted by Relays — «Notizen und anderes, über Relays übertragen». Die Website nostr.com beschreibt es so: «ein freies und offenes Netz, das niemandem gehört und das niemand kontrolliert».
Der Aufbau ist einfach, und alles Weitere ruht darauf. Es gibt Relays — Server, die Nachrichten speichern und ausliefern. Es gibt Clients — Anwendungen, über die Menschen lesen und schreiben. Und es gibt Schlüssel: der öffentliche Schlüssel dient als Benutzername, der private als Passwort; es sind die Schlüssel und nicht ein Unternehmen, die Ihnen das Recht auf Ihre Identität geben. Da die Identität dem Schlüssel gehört und nicht der Anwendung, können Sie zwischen Clients wechseln und dabei Profil, Follower und Beiträge behalten.
Technisch läuft alles auf einen einzigen Objekttyp hinaus. Das Basisdokument des Protokolls hält fest: der einzige existierende Objekttyp ist das «Ereignis» (event), Signaturen und Schlüssel verwenden das Schnorr-Verfahren auf der Kurve secp256k1, und ein Relay stellt nach außen einen Websocket-Endpunkt bereit, an den der Client drei Arten von Nachrichten sendet: EVENT zum Veröffentlichen, REQ zum Abonnieren einer Abfrage und CLOSE, um sie zu schließen.
Für dieses Nachschlagewerk bedeutet das Folgendes: Nostr hat keinen Eigentümer, kein einheitliches Publikum, keinen Werbeaccount, keine Moderationsregeln und kein Auszahlungsprogramm. Im Weiteren wird untersucht, was es stattdessen gibt.
Wer ist hier
Eine Publikumszahl für Nostr existiert nicht — und kann im gewohnten Sinn nicht existieren. Es gibt keinen zentralen Server, der Nutzer zählen würde: es gibt eine Vielzahl unabhängiger Relays, von denen jedes nur die eigenen sieht.
Mittelbar lässt sich nur nach einzelnen Relays urteilen. Der Client auf nostr.com verbindet sich standardmäßig mit sechs Relays und zeigt deren Liste direkt in der Oberfläche: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom und relay.snort.social. Ein Verzeichnis der Relays empfiehlt das Projekt beim fremden Tool Nostr.watch anzusehen, ein Verzeichnis der Clients auf nostrapps.com (Seite über Relays, Seite über Clients).
Eine Aufschlüsselung nach Sprache und Land gibt es nicht und kann es nicht geben: das Protokoll speichert solche Informationen über den Nutzer nicht. Ein Profil enthält standardmäßig nur Name, Beschreibung und Bild.
Wie man beginnt
Eine Registrierung im gewohnten Sinn gibt es nicht: ein Konto ist ein Schlüsselpaar, das die Anwendung erzeugt. Weder eine Bestätigung per E-Mail noch eine Telefonnummer noch eine Prüfung des Antrags.
Daraus folgt das wichtigste Risiko, vor dem das Projekt selbst warnt: der private Schlüssel gibt vollen Zugriff auf das Konto — mit ihm kann man in Ihrem Namen schreiben, das Profil ändern und Nachrichten senden; ist der Schlüssel verloren und existiert keine Kopie, so gibt es keine Schaltfläche «Passwort vergessen». Der praktische Rat des Projekts: fügen Sie den privaten Schlüssel nicht der Reihe nach in jede Anwendung ein — sicherer sind eine signierende Browsererweiterung oder ein entfernter Signierer.
Einen überprüfbaren Namen, ähnlich einem «Häkchen», kann man erreichen: ein eigenes Dokument des Protokolls beschreibt die Bindung eines Schlüssels an eine Domain. Der Client entnimmt dem Profil eine Adresse der Form name@domain, ruft https://domain/.well-known/nostr.json?name=name ab und gleicht den erhaltenen öffentlichen Schlüssel mit dem Schlüssel des Verfassers des Beitrags ab. Für ein Unternehmen ist genau das der Weg zu bestätigen, dass ein Konto tatsächlich ihm gehört: die Bestätigung entsteht aus der Kontrolle über eine Domain und nicht aus der Entscheidung eines Moderators.
Ein gesondertes Geschäftskonto gibt es nicht — ebenso wenig wie ein gewöhnliches. Die Präsenz eines Unternehmens auf Nostr ist ein Schlüssel, der an seine Domain gebunden ist, und auf Wunsch ein eigenes Relay.
Was man veröffentlichen kann
Die Formate werden durch «Arten» von Ereignissen bestimmt, und die Arten sind in eigenen Dokumenten beschrieben — den NIP (Nostr Implementation Possibilities). Ihre Liste wird in einem offenen Repository geführt und umfasst unter anderem: kurze Notizen und Diskussionsstränge, lange Materialien, Bilder und Videos, Livesendungen und «Spaces», Umfragen, Kalenderereignisse, Wikis, Torrents, Listen, Lesezeichen und Zitate (Liste der NIP).
Grenzen für Länge und Größe hat das Protokoll nicht — sie hat das Relay, und das Relay ist verpflichtet, sie bekanntzugeben. Das Dokument über die Angaben zum Relay beschreibt die Felder: max_message_length — die maximale Größe des eingehenden JSON in Bytes (womit faktisch auch die Größe eines Ereignisses begrenzt wird), max_content_length — die maximale Zeichenzahl im Inhaltsfeld, max_event_tags — die maximale Zahl der Markierungen, max_subscriptions — die Zahl gleichzeitiger Abonnements auf einer Verbindung, max_limit — die Obergrenze der Ereigniszahl in der Antwort auf eine einzelne Anfrage.
So sieht das in der Praxis aus. Das Relay relay.damus.io gibt zum Prüfdatum eine Nachrichtengrenze von 1 000 000 Bytes, 200 Abonnements und eine Abfrageobergrenze von 500 Ereignissen an; das Relay nos.lol — 131 072 Bytes, 20 Abonnements, dieselben 500 Ereignisse; das Relay relay.nostr.com — 131 072 Bytes, 200 Abonnements, 500 Ereignisse. Die Zahlen gehören jedem Relay einzeln, und auf einem anderen Relay sind sie andere.
Inhaltliche Verbote kennt das Protokoll nicht. Es gibt eine technische Auszeichnung: ein eigenes Dokument beschreibt die Markierung heikler Inhalte, ein weiteres Beschwerden über Ereignisse, ein drittes die Anfrage zur Löschung. Achten Sie auf das Wort «Anfrage»: eine Löschung ist auf Nostr eine Bitte an die Relays und keine Garantie. Was genau angenommen und gespeichert wird, entscheidet der Betreiber des Relays.
Wie man wächst
Einen algorithmischen Feed kennt das Protokoll nicht. Was dem Nutzer gezeigt wird, entscheidet der Client, und welche Ereignisse ausgeliefert werden, das Relay. Der Client auf nostr.com zeigt das unmittelbar: in seiner Oberfläche gibt es die Feed-Varianten «Abonnements», «global» und «eigener», und darunter eine Liste der verbundenen Relays.
Daraus ergibt sich eine praktische Folge, die das Projekt selbst erklärt: wenn Nostr langsam oder leer erscheint, kann es an den Relays liegen; ein Teil der Relays ist schnell und zuverlässig, ein Teil schaltet ab und antwortet nicht, und das Hinzufügen einiger guter Relays ändert vieles. Wachstum auf Nostr heißt in erster Linie: in jene Relays zu veröffentlichen, wo es tatsächlich Leser gibt.
Einen Werbeaccount gibt es nicht: das Protokoll hat weder eine Plattform, die Einblendungen verkaufen würde, noch einen Mechanismus, sie zu erfassen. Eine eingebaute Statistik gibt es ebenfalls nicht; das Nächstliegende ist die Anfrage COUNT, die das Relay nach Möglichkeit und näherungsweise ausführt.
Als Mittel gegen Spam bietet das Protokoll ein ungewöhnliches an: das Dokument über den Arbeitsnachweis erlaubt dem Relay, von neuen Ereignissen einen vorgegebenen Rechenaufwand zu verlangen. Das zweite Mittel ist Geld: ein Teil der Relays ist kostenpflichtig, und das senkt den Spam, weil der Betrieb eines Relays Geld kostet und die Nutzer einen Grund bekommen, sich anständig zu verhalten.
Weg zur Monetarisierung
Eine Plattform gibt es nicht — also gibt es auch keine Auszahlungen von einer Plattform. Dafür gibt es direkte Zahlungen zwischen Menschen, und sie sind im Protokoll selbst beschrieben.
Der Mechanismus heißt «Zap» (zap) — eine Zahlung über das Lightning-Netz. Das Dokument des Protokolls führt zwei Arten von Ereignissen ein: 9734 — die Zap-Anfrage, also die Anfrage des Zahlenden an die Wallet des Empfängers nach einer Rechnung, und 9735 — die Quittung, die Bestätigung der Wallet des Empfängers, dass die Rechnung bezahlt ist. Der Ablauf ist dieser: der Client entnimmt dem Profil des Empfängers die Adresse seines Zahlungsendpunkts, prüft, dass dieser Nostr unterstützt, sendet dorthin eine signierte Anfrage und erhält eine Rechnung; nach der Zahlung veröffentlicht die Wallet eine Quittung. Der Sinn der Quittung wird ebendort erklärt: sie erlaubt es Clients, Zahlungen direkt im Feed anzuzeigen — zum Vergnügen oder als Mittel gegen Spam.
Eine Provision der Plattform gibt es in diesem Schema nicht — das Geld geht von Wallet zu Wallet. Aber Garantien einer Plattform gibt es ebenso wenig: für die Zustellung der Zahlung stehen das Lightning-Netz und der von Ihnen gewählte Wallet-Anbieter ein.
Außer Zaps enthält die Liste des Protokolls weitere Geldmechanismen: Sammelziele (zap goals), Abzeichen, Cashu-Wallets und «Nutzaps», entfernte Anbindung einer Wallet und Bestellereignisse zwischen Menschen. Jeder davon wird von einem Client nach Belieben umgesetzt.
Tools und Automatisierung
Eine «offizielle API» hat Nostr aus demselben Grund nicht, aus dem es keinen Eigentümer hat: das Protokoll selbst ist die Schnittstelle. Jedes Programm kann einen Websocket zu einem Relay öffnen und unmittelbar damit arbeiten (Basisdokument). Entwicklerschlüssel, Zugangsanträge und eine Prüfung von Anwendungen gibt es nicht.
Bevor Sie ein Tool bauen, lohnt es sich, die Warnung aus der Liste selbst zu lesen: «NIP hier sind keine Prüfliste des Protokolls. Nichts zwingt irgendein Programm, irgendein NIP umzusetzen. Jede Anwendung wählt die Teilmenge, die sie für ihre Aufgabe braucht». Das heißt, man kann sich auf eine Funktion nicht allein deshalb verlassen, weil sie beschrieben ist: man muss prüfen, ob das konkrete Relay sie unterstützt. Eine Prüfmöglichkeit ist vorgesehen: das Relay liefert über HTTP ein Dokument mit der Liste der unterstützten NIP, dem Namen des Programms, der Version, den Kontakten und einem Link zu seinen Nutzungsbedingungen. Die drei oben genannten Relays geben denselben Satz an: alle drei laufen auf der Software strfry und unterstützen NIP 1, 2, 4, 9, 11, 28, 40, 45, 70 und 77.
An fertigen Mitteln nennt das Projekt Browsererweiterungen zum Signieren und entfernte Signierer sowie den eigenen Signierer Pomegranate. Verzeichnisse der Clients und Relays werden außerhalb des Protokolls geführt — auf nostrapps.com und Nostr.watch (Seite über Clients, Seite über Relays).
Beschränkungen und Regeln
- Einheitliche Regeln gibt es nicht. Kein einziges Dokument, das allen Teilnehmern des Netzes irgendetwas verbieten würde, existiert. Die Regeln setzt der Betreiber des Relays; das Protokoll sieht lediglich einen Link zu den Nutzungsbedingungen in den Angaben zum Relay vor.
- Die Grenzen setzt das Relay und gibt sie selbst bekannt: Nachrichtengröße, Länge des Inhalts, Zahl der Markierungen, Zahl der Abonnements, Abfrageobergrenze.
- Ein Relay kann verlangen: Anmeldung nach dem Authentifizierungsprotokoll oder einen Arbeitsnachweis für neue Ereignisse.
- Löschung ist nicht garantiert: das Dokument beschreibt eben eine «Anfrage zur Löschung», und ob sie ausgeführt wird, entscheidet jedes Relay.
- Der Verlust des Schlüssels ist unumkehrbar. Eine Wiederherstellung des Zugangs gibt es nicht.
- Einen rechtlichen Rahmen hat das Netz nicht. Die Verantwortung tragen der Betreiber des Relays und der Verfasser; eine juristische Person, mit der man einen Vertrag schließen könnte, hat das Protokoll nicht. Die Liste der NIP selbst wird im Repository ohne angegebene Lizenz veröffentlicht.
Für wen geeignet
Geeignet für Projekte, denen Unabhängigkeit vom Eigentümer einer Plattform wichtig ist: die Identität gehört dem Schlüssel und nicht einem Unternehmen, ein Konto lässt sich nicht zentral sperren, und bei Unzufriedenheit mit einem Relay genügt es, das Relay zu wechseln. Geeignet für Entwickler: die Anbindung an das Netz erfordert weder einen Anwendungsschlüssel noch eine Genehmigung.
Geeignet für Projekte rund um Bitcoin und Lightning: Zahlungen sind als Zaps in das Protokoll eingebaut, und das ist der am weitesten entwickelte Teil seiner Geldmechanik.
Nicht geeignet, wenn Sie planbare Reichweite und Berichte brauchen: hier gibt es nichts zu messen — weder eine Plattform noch eine Statistik noch einen Werbeaccount. Nicht geeignet für Massenversand und «Promotion»: ein Relay darf Bezahlung, Anmeldung oder einen Arbeitsnachweis verlangen und Sie ohne Erklärung abschalten. Und nicht geeignet, wenn die Organisation einen Vertrag mit einem Dienstleister verlangt: eine solche Gegenseite hat das Protokoll nicht.
Geprüfte Angaben aus der Datenbank
Kurze geprüfte Angaben, auf die sich die Analyse stützt.
Über die Plattform
die Plattform beschreibt sich selbst so: «Nostr is a free and open-source protocol for social media and other things - controlled by users, not platforms.»
Selbstbeschreibung: eine Aussage der Plattform über sich selbst, keine unabhängige Bewertung
Quelle, geprüft 2026-07-28
Nostr (Notes and Other Stuff Transmitted by Relays) wird als freies und offenes Netz beschrieben, das niemandem gehört und das niemand kontrolliert; Relays speichern und verteilen Nachrichten, Clients erlauben es, sie zu lesen und zu schreiben
Das ist ein Protokoll und keine Plattform: Einen Eigentümer, einen Werbeanzeigenmanager und ein Auszahlungsprogramm hat es nicht
Quelle, geprüft 2026-07-28
der einzige Objekttyp ist das Ereignis (event); Signaturen und Schlüssel verwenden das Schnorr-Verfahren auf der Kurve secp256k1; ein Relay stellt einen Websocket-Endpunkt bereit, der Client sendet EVENT zum Veröffentlichen, REQ zum Abonnieren und CLOSE zum Schließen des Abonnements
Grunddokument des Protokolls NIP-01
Quelle, geprüft 2026-07-28
Erste Schritte
die Eintrittsschwelle von nostr hat keinen einzelnen Eigentümer der Regeln: «Nostr (Notes and Other Stuff Transmitted by Relays) is a free and open network that nobody owns or controls»; die Sammlung der Vorschläge zum Protokoll sagt dasselbe über sich selbst: «NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP»
die Zitate sind wörtlich, die Sprache der Quelle ist Englisch. Das zweite stammt aus der README der NIP-Sammlung: https://raw.githubusercontent.com/nostr-protocol/nips/master/README.md. Die praktische Folgerung für den Leser: Einheitliche, für das ganze Netz verbindliche Bedingungen für den Eintritt gibt es nicht; die Bedingungen setzt jedes einzelne Relay und jede einzelne Anwendung, und sie sind unterschiedlich
Quelle, geprüft 2026-08-07
ein Relay darf das Schreiben sperren, eine Anmeldung per Signatur oder einen Arbeitsnachweis verlangen: in der Liste der Einschränkungen nennt NIP-11 «auth_required», «restricted_writes», «min_pow_difficulty», «payment_required»; «Your client should expect that requests exceed these practical limitations are rejected or fail immediately»
Zitate wörtlich, Sprache der Quelle Englisch, Schreibweise der Quelle beibehalten. Bewerbungen, Einladungen oder eine Moderation auf Protokollebene gibt es nicht; alles Genannte sind Eigenschaften des einzelnen Relays, und erfahren lässt es sich, indem man beim Relay dessen Informationsdokument abruft
Quelle, geprüft 2026-08-07
Konto und Zugang
ein Konto ist ein Schlüsselpaar und kein Eintrag beim Eigentümer einer Plattform: «Every account has Nostr keys. Your public key is like your username and can be shared with anyone. Your private key is like your password and must be kept safe. These keys give you ownership of your identity, rather than a company owning it for you»
das Zitat ist wörtlich, die Sprache der Quelle ist Englisch. Weder eine Registrierung noch eine Feststellung der Identität noch eine Freigabe ist nötig, um Schlüssel zu erhalten: Das Schlüsselpaar wird auf dem Gerät erzeugt. Ein freiwilliger überprüfbarer Name der Form Name@Domain ist in einem eigenen NIP-05 beschrieben
Quelle, geprüft 2026-08-07
das Konto hat ein Schlüsselpaar: Der öffentliche dient als Benutzername, der private als Passwort; die Identität gehört dem Schlüssel und nicht der Anwendung, deshalb kann man den Client wechseln und dabei Profil und Follower behalten
Eine Registrierung, eine Bestätigung der E-Mail und eine Moderation des Antrags gibt es nicht
Quelle, geprüft 2026-07-28
bei Verlust des privaten Schlüssels ohne Sicherungskopie gibt es keine Wiederherstellung des Zugangs: eine Schaltfläche «Passwort vergessen» existiert nicht
Das Projekt rät, den privaten Schlüssel nicht in jede Anwendung einzufügen, sondern eine Signierer-Erweiterung oder einen entfernten Signierer zu verwenden
Quelle, geprüft 2026-07-28
ein überprüfbarer Name der Form Name@Domain: Der Client ruft https://домен/.well-known/nostr.json?name=имя ab und gleicht den erhaltenen öffentlichen Schlüssel mit dem Schlüssel des Autors des Eintrags ab
Für ein Unternehmen ist das eine Möglichkeit, das Konto durch die Kontrolle über die Domain zu bestätigen und nicht durch die Entscheidung eines Moderators
Quelle, geprüft 2026-07-28
Was veröffentlicht werden darf
die Liste der NIP beschreibt unter anderem: kurze Notizen und Threads, lange Materialien, Bilder und Videos, Livestreams und Spaces, Umfragen, Kalenderereignisse, Wikis, Torrents, Listen, Lesezeichen und Zitate
Die Liste der NIP ist keine Verpflichtung: Nichts zwingt ein Programm dazu, irgendein NIP umzusetzen
Quelle, geprüft 2026-07-28
Wie hier bezahlt wird
Wer aufgenommen wird. eine Schwelle nach Followern, Aufrufen oder Anzahl der Beiträge gibt es bei den Zahlungen nicht: Zaps gehen direkt von Mensch zu Mensch über das Lightning-Netz, und Bedingung ist allein, dass der Empfänger eine Wallet mit einer lnurl-Adresse hat — «Client calculates a recipient's lnurl pay request url from the zap tag on the event being zapped, or by decoding their lud16 field on their profile»
Zitat wörtlich, Sprache der Quelle Englisch. Schwelle null: weder eine Followerzahl noch Wiedergabestunden noch ein Mindestalter des Kontos verlangt NIP-57. Die Betragsgrenzen legt die Wallet des Empfängers über die Felder «minSendable» und «maxSendable» fest, nicht das Netz
Quelle, geprüft 2026-08-07
eine Netzprovision gibt es nicht, und es gibt auch niemanden, der sie nehmen könnte: das Geld läuft am Protokoll vorbei über die Wallet des Empfängers, und nostr ist an der Abrechnung nicht beteiligt — NIP-57 beschreibt nur zwei Ereignisarten, den Eintrag der Anfrage und den Eintrag der Quittung: «9734 is a zap request… 9735 is a zap receipt, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid»
Zitat wörtlich, Sprache der Quelle Englisch. Eine eigene Gebühr kann die Wallet oder ein Knoten des Lightning-Netzes erheben — das ist bereits nicht mehr nostr, und ihre Höhe ist in NIP-57 nicht festgelegt. Provision, Anteil und Auszahlungsgrenze hat das Netz nicht, weil es keinen Vermittler gibt, der das Geld halten würde
Quelle, geprüft 2026-08-07
Zahlungen zwischen Menschen werden im Protokoll als «Zaps» über das Lightning-Netz beschrieben: Ereignis 9734 — die Anfrage auf einen Zap, Ereignis 9735 — die Quittung der Wallet des Empfängers über die Bezahlung der Rechnung
Eine Provision der Plattform ist in dem Schema nicht vorgesehen: Das Geld geht von Wallet zu Wallet; die Verantwortung für die Zustellung liegt beim Lightning-Netz und beim Anbieter der Wallet
Quelle, geprüft 2026-07-28
die Liste der NIP enthält außerdem Sammelziele (zap goals), Abzeichen, Cashu-Wallets und Nutzaps, die entfernte Verbindung einer Wallet und Bestellereignisse zwischen Menschen
Jeder Mechanismus wird vom Client nach Belieben umgesetzt
Quelle, geprüft 2026-07-28
Preise
das Protokoll selbst verlangt kein Geld, ein einzelnes Relay aber schon: NIP-11 sieht Felder für Gebühren vor — «Relays that require payments may want to expose their fee schedules»: «fees»: «admission» (Zugangsgebühr), «subscription» (Abonnement mit dem Feld «period»), «publication» (Gebühr für die Veröffentlichung, mit Angabe der Ereignisarten); in der Liste der Relay-Einschränkungen steht das Merkmal «payment_required»
Zitate wörtlich, Sprache der Quelle Englisch. Die Zahlen legt jedes Relay selbst fest, daher gibt es netzweit keinen einheitlichen Zugangspreis. Das Beispiel, das NIP-11 selbst als Muster einer Relay-Antwort von nostr.wine anführt: «fees»: «admission»: ({«amount»: 18888000, «unit»: «msats»}) — das ist eine Angabe des Relays im Beispiel des Dokuments, weder unsere Berechnung noch eine Zusage über den aktuellen Preis
Quelle, geprüft 2026-08-07
Grenzen und Beschränkungen
ein Relay gibt seine Beschränkungen im Informationsdokument an: max_message_length (Größe des eingehenden JSON), max_content_length (Zeichen im Inhaltsfeld), max_event_tags, max_subscriptions, max_limit; möglich sind Anforderungen an Authentifizierung und Arbeitsnachweis
Dokument NIP-11; eigene Längen- und Größenbeschränkungen hat das Protokoll nicht
Quelle, geprüft 2026-07-28
das Relay relay.damus.io gibt zum Prüfdatum eine Nachrichtengrenze von 1 000 000 Byte, 200 gleichzeitige Abonnements und eine Abfrageobergrenze von 500 Ereignissen an; Programm strfry
Die Zahl gehört diesem Relay, auf einem anderen ist sie anders
Quelle, geprüft 2026-07-28
das Relay nos.lol gibt eine Nachrichtengrenze von 131 072 Byte, 20 Abonnements und eine Abfrageobergrenze von 500 Ereignissen an
Gemessen durch Abruf des Informationsdokuments über das Relay
Quelle, geprüft 2026-07-28
das Relay relay.nostr.com gibt eine Nachrichtengrenze von 131 072 Byte, 200 Abonnements und eine Abfrageobergrenze von 500 Ereignissen an; angegebene NIP — 1, 2, 4, 9, 11, 28, 40, 45, 70, 77
Denselben Satz an NIP geben damus.io und nos.lol an
Quelle, geprüft 2026-07-28
Beschränkungen
einheitliche Regeln gibt es nicht: Was angenommen und gespeichert wird, entscheidet der Besitzer des Relays; das Protokoll sieht lediglich einen Verweis auf die Nutzungsbedingungen in den Angaben zum Relay vor
Das Löschen wird als «Löschanfrage» beschrieben, die Ausführung ist nicht garantiert
Quelle, geprüft 2026-07-28
Mittel gegen Spam: Ein Relay kann einen Arbeitsnachweis vorgegebener Schwierigkeit oder eine Authentifizierung verlangen; ein Teil der Relays ist kostenpflichtig, was nach der Erklärung des Projekts den Spam verringert
Nostr.watch wird vom Projekt als Verzeichnis der Relays empfohlen, nostrapps.com — als Verzeichnis der Clients
Quelle, geprüft 2026-07-28
die Roboterdatei von nostr.com erlaubt allen Agenten das Crawlen der Website
Gesondert geprüft
Quelle, geprüft 2026-07-28
Rechtliches
das Repository der NIP-Liste ist ohne angegebene Lizenz veröffentlicht
Eine juristische Person, mit der man einen Vertrag schließen könnte, hat das Protokoll nicht
Quelle, geprüft 2026-07-28
API-Zugang
der Client auf nostr.com verbindet sich standardmäßig mit sechs Relays: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom, relay.snort.social
Die Liste ist unmittelbar in der Oberfläche zu sehen
Quelle, geprüft 2026-07-28
eine gesonderte «offizielle API» gibt es nicht: Als Schnittstelle dient das Protokoll selbst, jedes Programm kann einen Websocket zum Relay öffnen; Entwicklerschlüssel und eine Moderation von Anwendungen existieren nicht
Die Unterstützung konkreter Möglichkeiten muss man anhand des Informationsdokuments über das Relay prüfen
Quelle, geprüft 2026-07-28
Sprachen
Oberflächensprache der Startseite: en
Die Sprache stammt aus dem Markup-Attribut, die Versionen aus hreflang
Quelle, geprüft 2026-07-28
Katalogbereich: alle ähnlichen Siehe auch: Katalogverzeichnis · Vergleich der Planungstools · Auswahl nach Situation · Einschränkungen der Plattformen