Willkommen zurück beim Nostr Compass, eurem wöchentlichen Wegweiser für Nostr.

Diese Woche: IndieSats gibt die Schlüsselverwahrung, seine Whitelist und seinen obligatorischen Umsatzanteil auf und startet als offenes Relay, Player und Discovery-Schicht neu, auf der Künstler unter ihren eigenen Schlüsseln veröffentlichen. Nostrord v2.3.0 bringt Gruppenmoderation, Mute-Listen und Onion-Relays in derselben Woche, in der fünf NIP-29-Spec-PRs gemergt werden. Zapstore 1.1.0 führt einen portierbaren verschlüsselten Geräteschlüssel mit Amber-Backup und optionale Hintergrund-Auto-Updates ein. Der Favorite-Follow-Sets-Listen-Kind wird gemergt und erhält innerhalb weniger Tage einen Umnummerierungs-PR. Und die Iris-Projekte liefern nostr-pubsub, die Browser-Runtime fips-ts und nostr-social-graph 2.0 als zusammenhängenden Stack aus Peer-Transport und Identitätsgraph.

Getaggte Releases bringen Amber v6.3.0 mit gruppierten Bunker-Signierungs-Freigaben, Armada v0.37.0 mit einem zweiten Client für Buzz-Workspaces, Divine Mobile 1.0.17 mit dauerhafter NIP-17-Zustellung und strikter TLS-Validierung sowie nak v0.20.2 mit Befehlen für NIP-34-Pull-Requests.

Auf der unveröffentlichten Seite zeichnet Snort durch EOSE belegte Cache-Abdeckung auf, Shopstr schließt zwei Lücken bei der Zahlungsintegrität, Mostr verbindet private ActivityPub-Chats mit Nostr-DMs, nostream mergt den Access-Control-Stack, den der Deep Dive dieser Woche behandelt, und Amethyst erreicht 88 gemergte PRs mit vollständigen NIP-88-Umfragen auf Desktop.

Das NIPs-Repository mergt diese Woche fünf PRs, darunter das NIP-29-Cluster und kind:10011 Favorite Follow Sets, und eröffnet Debatten über NIP-47-Vereinfachung und Trusted Relay Assertions. Der Deep Dive behandelt NIP-42 und NIP-43, das Relay-Access-Control-Paar.

Lead-Storys

IndieSats legt seine Publisher-Rolle ab und startet als offene Nostr-Musikinfrastruktur neu

IndieSats ist eine Nostr-basierte Musikplattform, die bis diese Woche als Publisher agierte: Sie hielt Schlüssel für Künstler, betrieb eine Whitelist und nahm einen obligatorischen Anteil von 2 % der Einnahmen. In einer Pivot-Ankündigung vom 20. Juli gab das Projekt alle drei Rollen auf einmal auf. Die neu gestartete Plattform besteht aus drei Teilen offener Infrastruktur: einem offenen Relay, einem Player und einer Discovery-Schicht. Künstler veröffentlichen Musik nun unter ihren eigenen Nostr-Profilen. Der Plattformanteil von 2 % pro Track ist optional, beim Veröffentlichen aber standardmäßig ausgewählt; Künstler können ihn abwählen und so die vollständige Zahlung behalten. Die Plattform berücksichtigt außerdem NIP-09 kind:5-Löschanfragen, damit Künstler ihre Werke entfernen können. Ein am 21. Juli veröffentlichtes Update auf v1.1.5 stellte die Track-Veröffentlichung auf das Event-Format um, das Amethyst und andere Nostr-Musikclients erwarten, und machte die Relay-Zustellung explizit. Für einen Bereich, der gewöhnlich darüber spricht, wie Protokolle Plattformen ersetzen, ist dies ein praktischer Fall, in dem eine Plattform sich freiwillig in Protokollbausteine zerlegt.

Nostrord v2.3.0 liefert Gruppenmoderation, Mute-Listen und Onion-Relays

Nostrord, der Gruppenchat-Client für Android, iOS, Web und Desktop, lieferte v2.3.0 mit verdrahteten Gruppenmoderations-Aktionen auf allen UIs (PR #192), einwilligungsbasierten Gruppeneinladungen mit Cross-Relay-Erkennung (PR #195), plattformübergreifenden NIP-51-Mute-Listen (PR #188) und Unterstützung für Tor-.onion-Relays. Das Release erscheint in derselben Woche, in der die zugrunde liegende NIP-29-Spec fünf PRs zu Untergruppen, Nachrichten-Pinning, Bannern und Einladungscodes mergte (Details im Protokoll-Abschnitt dieser Woche). Gruppenchat auf Nostr hat damit sowohl eine tiefere Spec als auch einen Client, der den Großteil davon praktisch nutzt, was die Feedbackschleife für alle anderen verkürzt, die auf Relay-Gruppen aufbauen.

Zapstore 1.1.0 macht den Geräteschlüssel portierbar und fügt Hintergrund-Auto-Updates hinzu

Zapstore ist ein Nostr-nativer App-Store, in dem Releases von Entwicklerschlüsseln signiert werden und kein zentraler Betreiber für sie bürgt. Version 1.1.0, das erste hier behandelte Release seit Anfang März, schließt die beiden größten Lücken zu konventionellen App-Stores. Für Updates laufen optionale Hintergrund-Downloads nun über WLAN und werden still oder gestuft installiert, sodass Apps ohne manuelle Gänge durch den Store aktuell bleiben. Identitätskontinuität entsteht durch einen portierbaren verschlüsselten Geräteschlüssel, den Nutzer über Amber via NIP-55, der Android-Signer-Schnittstelle, sichern können, sodass bei einem Handywechsel die Geräteidentität erhalten bleibt. Version 1.1.0 verschiebt außerdem den App-Katalog als gerätesignierte kind:10067-Events auf Relays, fügt aus dem Overflow-Menü NIP-56-verifizierte Meldungen hinzu, damit Nutzer problematische Apps auf eine für andere Clients verwertbare Weise kennzeichnen können, und prüft vor jeder Installation den einem Release beigefügten C1-Proof. Dadurch wird die Verbindung zwischen dem, was ein Entwickler signiert hat, und dem, was ein Gerät ausführt, enger abgesichert.

Der Favorite-Follow-Sets-Listen-Kind mergt und zieht sofort um

Eine Spec-Koordinationsgeschichte spielte sich innerhalb einer einzigen Woche ab. PR #2413 wurde am 15. Juli gemergt und standardisierte unter NIP-51 (Listen) einen ersetzbaren Listen-Kind für Favorite Follow Sets: einen dedizierten Kind für die kuratierten Sets gefolgter Accounts eines Nutzers. Innerhalb weniger Tage stellte sich heraus, dass der zugewiesene kind:10011 bereits anderweitig in Gebrauch war, sodass nun ein Folge-PR #2417 offen ist, um die Liste auf kind:10021 umzunummerieren. Gegen den gemergten Kind ist noch nichts ausgeliefert, was diesen Moment zum günstigen Zeitpunkt für die Umnummerierung macht; sobald Clients anfangen, kind:10011-Events zu veröffentlichen, würde die Kollision teuer aufzulösen. Entwickler, die listenkonsumierende Features bauen, sollten bis zur Klärung dem Umnummerierungs-PR folgen, nicht dem gemergten Text.

Die Iris-Projekte liefern eine Pubsub-Bibliothek, eine Browser-FIPS-Runtime und einen Social Graph 2.0 in einer Woche

Drei Releases aus dem Umfeld von Iris erschienen gemeinsam und greifen ineinander. nostr-pubsub ist eine transportneutrale Publish/Subscribe-Bibliothek für Nostr-Events; ihre ersten erfassten Releases, v0.1.3 bis v0.5.2, liefern einen Browser-Relay-Carrier auf Basis von nostr-tools’ SimplePool, Event-Verifizierung an der Transportgrenze, sodass ungültige Signaturen niemals Subscriber erreichen, und begrenzte historische Abfragen. fips-ts bringt FIPS, den zuvor als Rust-Stack verfügbaren Noise-over-secp256k1-Peer-Transport, als TypeScript-Runtime in den Browser: Die Releases 0.0.24 bis 0.0.30 fügten einen WebRTC-Datachannel-Carrier, Nostr-basiertes Signaling für Peer-Discovery, einen Recent-Peer-Cache und einen IndexedDB-Adapter für Browser-Speicher hinzu; die Runtime ist wire-kompatibel mit der Rust-Referenzimplementierung. Das dritte Element, nostr-social-graph v2.0.0, ist eine neue Hauptversion der Social-Graph-Bibliothek: signierte Roster-Operationen für Nostr-Identitätsgraphen, Device-Approval-Flows, die aus einer kanonischen URI mit drei Feldern gebootstrapt werden, und FIPS-Transport-Identity-Facets mit gemeinsamen Rust- und TypeScript-Testvektoren. Den verbindenden Rahmen bildet der Iris Stack, das Integrationslabor des Projekts, das diese Bibliotheken mit Blossom, Hashtree und verschlüsseltem Messaging verbindet. Zusammen kann eine Web-App nun Peers über Nostr entdecken, einen verschlüsselten FIPS-Kanal zu ihnen öffnen und einen signierten Social Graph pflegen, vollständig in TypeScript.

Getaggte Releases

Amber v6.3.0 gruppiert Bunker-Signierungs-Freigaben und fügt Expert-List-Unterstützung hinzu

Amber ist ein Android-NIP-46-Remote-Signer. v6.3.0 fügt gruppierte Multi-Request-Freigaben hinzu, sodass Nutzer einen Stapel von Bunker-Signaturen auf einmal prüfen und freigeben können. Das Release fügt außerdem Unterstützung für Expert-List- (kind 12022) und Expert-Pack-Events (kind 32022) hinzu, einen Privacy-Modus, der sensible Inhalte auf dem Bildschirm verbirgt, und eine Änderung, die zuerst die NIP-65-Relay-Liste eines Accounts abruft und erst danach dessen Profil-Metadaten, sodass Signer-Flows vom tatsächlichen Relay-Set des Nutzers ausgehen. Dies folgt der v6.2.x-Linie aus der Ausgabe vom 08.07.2026.

Nostrord v2.2.0-Nachtrag

Da v2.3.0 den News-Abschnitt dieser Woche anführt, vermerkt der Tagged-Release-Slot nur, was der Lead nicht abdeckt: v2.3.0 folgt auf die DM-Steuerungen aus v2.2.0, behandelt in #31 — damit ist dies das zweite wöchentliche Release des Clients in Folge.

Armada v0.37.0 öffnet Buzz-Workspaces über einen zweiten Client

Armada, ein Discord-artiger Nostr-Client, veröffentlichte v0.37.0 mit Unterstützung für Buzz-Relays als erweiterten NIP-29-Workspace-Modus, der über die NIP-11-Metadaten des Relays erkannt wird. Der Client stellt Buzz-Forenbeiträge und -Kommentare als kinds 45001 und 45003 dar, integriert Bearbeitungen und Löschungen in Stream-Timelines und fügt Oberflächen für Presence, Workflows, Jobs, Huddles und geteilte Canvas-Flächen hinzu. Sein Projects-Workspace liest NIP-34-Repository-Ankündigungen, Patches, Pull-Requests, Issues und Status-Events direkt vom Relay (Implementierungs-Commit). Damit erhalten Buzz-Workspaces einen zweiten Client für Unterhaltungen und Repository-Arbeit.

Wisp v1.2.0 fügt einen Multi-Account-Wechsler und einklappbare Antwort-Threads hinzu

Wisp ist ein datenschutzorientierter Nostr-Client mit integrierter Wallet-Unterstützung. v1.2.0 fügt einen Multi-Account-Wechsler zum Wechseln zwischen Profilen ohne erneutes Login hinzu, einklappbare Antwort-Threads für lange Unterhaltungen, das Entfernen von Tracking-Parametern aus Note-Links, bevor sie geöffnet werden, und eine Wallet-Transaktionshistorie. Das Release folgt dem Wisp-Update aus der Ausgabe vom 08.07.2026.

Divine Mobile 1.0.17 härtet Relay-Sicherheit und DM-Zustellung

Divine Mobile, ein Nostr-Client für Kurzvideos, veröffentlichte 1.0.17 mit einem persistenten Stop-Motion-Editor und strafferen Nostr-Pfaden. Direktnachrichten warten nun auf OK-Antworten der Relays, werden über eine dauerhafte Queue erneut versucht und über die kind:10050-Inbox-Relay-Listen der Empfänger geleitet (PR #6046); beim NIP-46-Pairing bleiben auth_url-Challenges als wiederaufnehmbare Signer-Schritte erhalten (PR #6151). PR #6278 entfernt die großzügige Zertifikatsakzeptanz aus produktiven Relay-WebSockets und HTTP-Anfragen für NIP-96-Uploads, LNURL und zaps und stellt außerhalb von Debug-Loopback-Verbindungen die TLS-Validierung der Plattform wieder her. Unterbrochene Uploads können außerdem ab dem letzten vom Server bestätigten Offset fortgesetzt werden, sodass eine in den Hintergrund verschobene Veröffentlichung nicht mehr bei null beginnt.

ClipRelay v0.1.2 (neues Projekt) synchronisiert Zwischenablagen über Nostr-Relays zwischen Geräten

ClipRelay ist eine neu gestartete plattformübergreifende App (Android, macOS, Windows, Linux), die deine Zwischenablage zwischen deinen eigenen Geräten synchronisiert: auf einem Rechner kopieren, auf einem anderen einfügen. Der gesamte Verkehr läuft über Nostr-Relays als NIP-44-verschlüsselte Events, die an dich selbst adressiert sind — es gibt also keinen Server zu betreiben und keinen Account zu erstellen; der private Schlüssel bleibt außerhalb der App. v0.1.2 behebt einen subtilen Sync-Fehler, bei dem ein aus dem Ruhezustand erwachender Rechner weiter veröffentlichte, aber still den Empfang einstellte, und verschärft die Relay-Status-Anzeigen, die zuvor tote Subscriptions als gesund meldeten. Dies ist ClipRelays erster Auftritt im Newsletter.

Sonar v0.1-alpha.11 setzt die Alpha-Linie fort

Sonar, die Lead-Story der letzten Woche, schnitt v0.1-alpha.11 mit Arbeit an der Rust-Mesh-Link-Engine, BLE- und Mesh-Fixes sowie Relay-Diagnostik; ein inkrementeller Nachtrag zur in #31 behandelten Alpha-Linie.

nak v0.20.2 fügt Workflows für NIP-34-Pull-Requests hinzu

nak, das Nostr-Kommandozeilenwerkzeug, veröffentlichte v0.20.2 mit Befehlen zum Erstellen, Pullen und Mergen von NIP-34-Pull-Requests sowie zum Pullen einzelner Patches. Pushes sind außerdem möglich, ohne eine Repository-Ankündigung neu zu schreiben. Die Release-Spanne mit elf Commits fügt darüber hinaus die Behandlung von Elterngruppen für NIP-29 hinzu, fragt mehr Outbox-Relays ab, macht Timeouts für Relay-Verbindungen konfigurierbar und behebt die Bunker-Auswahl, wenn nur der Standardwert für --sec vorhanden ist.

Die kleineren Launches der Woche

Vier kleinere Releases verdienen je eine Zeile: noscall v0.6.0, die Nostr-Anruf-App, migrierte ihre Push-Benachrichtigungen auf UnifiedPush und hält das Call-Signaling damit von Googles Push-Infrastruktur fern; nostr-vpn v4.1.3, ein Mesh-VPN, das Nostr für Signaling nutzt, vereinheitlichte seine Exit-DNS-Richtlinie über alle Plattformen und stellt nach WireGuard- oder Private-Exit-Sitzungen nun den ursprünglichen Routing- und DNS-Zustand wieder her; StableKraft v1.3.0, der im April behandelte Nostr-plus-Lightning-Musik- und Podcast-Aggregator, fügte native Android-Steuerungen für Sperrbildschirm und Headset sowie einen auf die Wiedergabe begrenzten Wake Lock hinzu, damit Audio Doze übersteht; und die neue Zapstore-App Hakari sichert einen Gewichts-Logger über verschlüsselte Nostr-Events.

Amethyst liefert v1.13.0-Pre-Release-QA zu Napplet-Isolation und Concord-Authority

Amethyst mergte diese Woche 88 PRs im Vorfeld des v1.13.0-Releases. PR #3650 ist ein Pre-Release-QA-Durchlauf, der Napplet-Account-Isolation, Concord-Authority-Fixes und rund 30 weitere Fixes abdeckt. Die Arbeiten am Ende des Zeitfensters fügen auf Desktop vollständiges Rendern, Erstellen und Abstimmen für NIP-88-Umfragen, das Auszählen auf deklarierten Relays und die Suche nach kind 1068 hinzu (PR #3664); die NIP-50-Suche sortiert Ergebnisse nun nach BM25-Relevanz, während große Tag-Watcher begrenztes Merging verwenden (PR #3663). Ein separater Durchlauf am Relay-Store wählt Query-Indizes nach gemessenen Kosten aus, fügt Tag-Author-Kind-Indizes hinzu und serialisiert jedes Live-Event pro Fanout nur einmal (PR #3660). Angegebene Benchmarks sinken dabei für eine Query-Form von 149 auf 4 Millisekunden und für eine häufige DM-Room-Query von 14,2 auf 0,66 Millisekunden.

Unveröffentlichte Änderungen

Snort schreibt die Query-Synchronisierung rund um EOSE-belegte Abdeckung neu

Snort, ein Nostr-Webclient, schrieb seinen Pfad für Query- und Cache-Synchronisierung in Commit 8a62770 neu. Der Client zeichnet nun auf, welche Query-Zeitfenster EOSE erreicht haben, überspringt anhand dieser Watermarks bereits abgedeckte Cache-Bereiche, zentralisiert die Event-Verteilung hinter einem einzigen Relay-Pool-Listener und sendet Suchfilter nur an Relays, deren NIP-11-Dokumente NIP-50 ausweisen. Folge-Fixes serialisieren gleichzeitige Watermark-Updates und korrigieren inklusive Timeline-Grenzen, während Commit 9d1721b eine Live-Subscription für den in Chunks geladenen Follows-Feed wiederherstellt, damit nach dem Seitenaufbau eintreffende Events nicht außerhalb seiner gecachten Zeitfenster stehen bleiben.

Shopstr bindet die Zahlungsvalidierung an signierte Belege und serverseitige Preise

Shopstr, ein Nostr-Marktplatz-Client, schloss zwei Lücken bei der Zahlungsintegrität. PR #552 lässt Zapsnag bei jedem kind:9735-Beleg die Signatur, den Signer, die eingebettete zap request, Empfänger- und Produkt-Tags, den BOLT11-Betrag und ein optionales Preimage gegen den Payment Hash der Invoice prüfen, bevor er als Kauf behandelt wird. PR #449 verlegt die Erstellung von Cashu-Quotes hinter eine Shopstr-API-Route, die das Listing auflöst und seinen Preis serverseitig neu berechnet, sodass ein im Browser veränderter Betrag nicht die Mint-Invoice bestimmen kann.

Mostr verbindet private ActivityPub-Chats und Nostr-DMs

Mostr, eine ActivityPub-zu-Nostr-Bridge, überträgt nun direkte Pleroma-ChatMessage-Objekte und verschlüsselte Nostr-DMs in beide Richtungen (Commit 36ee547). Private ActivityPub-Chats werden zu kind:4-Events, die an den Nostr-Empfänger adressiert sind, während kind:4-Nachrichten an gebridgte Fediverse-Nutzer entschlüsselt und als ChatMessage-Objekte föderiert werden. Die Bridge begrenzt diese Events auf konfigurierte, durch NIP-42 geschützte DM-Relays und authentifiziert sich mit einem separaten Relay-Schlüssel. Dieser Interoperabilitätspfad verwendet die veraltete NIP-04-Verschlüsselung. NIP-17-Gift-Wrapping bleibt außerhalb dieser Implementierung.

nostream mergt acht PRs, ohne ein Release zu schneiden

nostream, die TypeScript-Relay-Implementierung, mergte diese Woche acht PRs, ohne ein Release zu schneiden. Das Headline-Paar sind PR #702 und PR #676, die Relay-Betreibern zusammen einen funktionierenden Authentifizierungs-plus-Mitgliedschafts-Access-Control-Stack geben; der NIP Deep Dive dieser Woche geht genau diesen Handshake durch. PR #694 behebt generische #e-, #p-, #g- und ähnliche Tag-Filter, die für jede passende Tag-Zeile eine Kopie eines Events zurückgeben konnten, und reduziert damit doppelten Protokollverkehr innerhalb einer Subscription.

FIPS v0.4.1 strafft die Iris-Transportschicht

jmcorgan/fips lieferte v0.4.1, ein Wartungsrelease, das den Antipoison-State deckelt, Convergence- und MTU-Handling behebt und die CPU-Last senkt. Die Browser-TypeScript-Runtime fips-ts aus dem Cluster der Iris-Projekte ist wire-kompatibel mit diesem Rust-Transport, sodass Fixes hier direkt die Browser-Interoperabilität verbessern.

Protokollarbeit und NIP-Updates

Jüngste Änderungen am NIPs-Repository:

Gemergt:

  • NIP-29 (Relay-based Groups): Untergruppen (PR #2319, gemergt 2026-07-16): NIP-29 definiert relay-gehostete Gruppen, in denen Mitgliedschaft, Rollen und Chat-Verlauf auf einem einzelnen Relay als adressierbare kind:39000-Serien-Events leben, mit Moderationsaktionen in kind:9000-Serien-Admin-Events. Dieser PR erlaubt einer Gruppe, sich selbst als Untergruppe zu deklarieren, indem sie ihren Metadaten ein parent-Tag hinzufügt, das auf den d-Identifier einer anderen Gruppe auf demselben Relay zeigt. Untergruppen sind in jeder anderen Hinsicht gewöhnliche Gruppen: Mitgliedschaft kaskadiert nicht (der Beitritt zu einer Elterngruppe gewährt keine Mitgliedschaft in Kindgruppen), Admin-Rollen werden nicht vererbt (die kind:39001-Admins-Liste jeder Untergruppe ist für ihren eigenen Geltungsbereich maßgeblich), und jede Untergruppe behält ihre eigenen unabhängigen kind:9000/kind:9001-Mitglieder-Events. Relays, die die Hierarchie unterstützen, bewerben dies in ihrem NIP-11-Relay-Information-Dokument unter einem nip29-Objekt mit "subgroups": true, sodass Clients die Fähigkeit entdecken können, bevor sie verschachtelte Communities anlegen.

  • NIP-29: Nachrichten-Pinning (PR #2379, gemergt 2026-07-15; PR #2416, gemergt 2026-07-17): Gruppenadmins können nun Nachrichten innerhalb einer Relay-basierten Gruppe anpinnen. Der Mechanismus fügt ein neues Moderations-Event hinzu, kind:9010 update-pin-list, das die vollständige geordnete Pin-Liste als e-Tags mit Verweisen auf reguläre Event-IDs trägt, sowie ein neues optionales gruppenweites Event, kind:39005 group pinned events, das das Relay neu erzeugt, um die zuletzt akzeptierte Pin-Liste zu spiegeln. Jedes kind:9010 ersetzt die gesamte Liste; eine neue Liste drückt daher Pinnen, Entpinnen, Umordnen oder Leeren aus. Der Folge-PR #2416 erweitert das Format, sodass auch a-Tags in der Pin-Liste akzeptiert werden. Admins können damit adressierbare Events wie Longform-Beiträge, Wiki-Seiten und andere parametrisierte ersetzbare Inhalte neben gewöhnlichen Chatnachrichten anpinnen. Relays dürfen die Zahl der Pins begrenzen, und der gemergte Spec-Text empfiehlt, Pins in der Reihenfolge der Tags anzuzeigen.

  • NIP-29: Banner-Tag und Invite-Code-Suffix (PR #2383, gemergt 2026-07-16; PR #2380, gemergt 2026-07-16): Zwei Ergänzungen zu Gruppenmetadaten für Anzeige und Onboarding. PR #2383 fügt dem kind:39000-Gruppenmetadaten-Event ein optionales banner-Tag hinzu, das sich zu den bestehenden Feldern name, picture und about gesellt, damit Clients ein Header-Bild für eine Gruppenseite rendern können. PR #2380 definiert ein Invite-Code-Suffix für Gruppen-Share-Links: Ein Einladungscode darf an den naddr-Identifier der Gruppe als naddr1...?invite=<code> angehängt werden. Da der bech32-Zeichensatz kein ? enthält, bleibt der Teil vor dem Suffix eigenständig ein gültiger naddr, sodass Clients, die die Erweiterung nicht verstehen, die Gruppe trotzdem auflösen können. Clients, die sie verstehen, füllen das code-Tag auf der kind:9021-Beitrittsanfrage vorab aus, was zusammen mit dem bestehenden kind:9009 create-invite-Moderations-Event die Aufnahme in geschlossene Gruppen vereinfacht.

  • NIP-51 (Listen): Favorite Follow Sets, kind:10011 (PR #2413, gemergt 2026-07-15): NIP-51 definiert die Standard-Listen-Kinds, aufgeteilt in ersetzbare kind:10000-Serien-Listen (eine pro Nutzer) und adressierbare kind:30000-Serien-Sets (viele pro Nutzer, per d-Tag adressiert). Dieser PR fügt kind:10011 hinzu, favorite follow sets, eine standardisierte ersetzbare Liste, deren a-Tags auf kind:30000-Follow-Sets zeigen. Als Spiegel von kind:10012 (Relay-Feeds), das a-Tags auf kind:30002-Relay-Sets hält, erlaubt der neue Kind einem Nutzer, benannte Follow-Sets zu bookmarken — etwa kuratierte Listen von Pubkey-Sammlungen, die von ihm selbst oder anderen veröffentlicht wurden — und Clients können sie für Folgen-per-Einmal-Tippen oder Feed-Wechsel anbieten. Beachte, dass diese Kind-Nummer bereits umstritten ist: siehe den offenen Umnummerierungs-PR unten.

  • NIP-46 (Nostr Connect): Leitlinie zu Silent-Timeouts (PR #2375, gemergt 2026-07-15): NIP-46 ist das Remote-Signing-Protokoll, bei dem ein Client verschlüsselte JSON-RPC-artige Anfragen über Relays an einen Signer (bunker) sendet und auf eine verschlüsselte Antwort wartet. Die gemergte Änderung ist ein Satz zum Wire-Verhalten: Anfragen mit unbekannten oder nicht unterstützten Methoden MÜSSEN mit einem Fehler beantwortet werden. Bisher konnte ein Signer, der eine nicht implementierte Methode empfing, einfach nie antworten; der Client hing dann bis zu seinem eigenen Timeout, ohne „nicht unterstützte Methode“ von „Signer offline“ unterscheiden zu können. Die vorgeschriebene Fehlerantwort lässt Clients schnell scheitern und vor dem lokalen Timeout einen aussagekräftigen Fehler anzeigen.

Offene PRs und Diskussionen:

  • Umnummerierung von kind:10011 zu kind:10021 (PR #2417): Verschiebt die frisch gemergte Favorite-Follow-Sets-Liste von kind:10011 nach kind:10021, weil 10011 bereits anderweitig in Gebrauch ist. Der Umnummerierungs-PR war innerhalb weniger Tage nach dem ursprünglichen Merge offen, sodass Clients, die Favorite Follow Sets implementieren, diesem PR folgen und die finale Nummer anvisieren sollten, nicht 10011.

  • NIP-47 (Nostr Wallet Connect): Kernvereinfachung (PR #2419): Schlägt vor, NIP-47, das Wallet-Connect-Protokoll, mit dem Apps Lightning-Zahlungen von einer entfernten Wallet über Nostr anfordern, zu einer kleineren Kern-Spec zu verengen. Optionale und spezialisiertere Funktionalität würde aus 47.md in ein dediziertes Extensions-Repository ausgelagert, nostr-wallet-connect/nwc, wo sich Extension-Specs unabhängig vom Kern weiterentwickeln können. Das erklärte Ziel ist, den Kern klein, stabil und leicht implementierbar zu halten — in der Linie früherer NWC-Calls, eine minimale Wallet-Connect-Schicht von reichhaltigerem optionalem Verhalten zu trennen. Angesichts der breiten Verbreitung von NIP-47 in Wallets und Apps sollte jeder, der NWC spricht, die Restrukturierungsdiskussion verfolgen.

  • Trusted Relay Assertions (Entwurf, noch keine Nummer vergeben) (PR #2418): Schlägt einen Standard zur Veröffentlichung von Vertrauensbewertungen über Nostr-Relays vor — positioniert als die „was wir daraus schließen"-Schicht neben NIP-11 (was ein Relay über sich selbst behauptet) und NIP-66 (was Monitore gemessen haben). Assertion-Anbieter würden Trust-Scores aus beobachteten Metriken, Betreiber-Reputation und Nutzerberichten berechnen; Clients würden diese Assertions abfragen, wenn sie wählen, mit welchen Relays sie sich verbinden. Der Entwurf führt kind:30385 ein (adressierbare Trusted Relay Assertion mit Tags für Score, Zuverlässigkeit, Qualität, Erreichbarkeit, Betreiber, Richtlinie und Jurisdiktion), kind:10385 (ersetzbare Trusted Provider List, die vom Nutzer gewählten Assertion-Anbieter), und nutzt NIP-32-Labels für Relay- und Betreiber-Reports wieder. Noch ist keine NIP-Nummer vergeben; dies ist ein früher Entwurf.

  • AND-Operator für Filter („NIP-91“, vorgeschlagen, Nummer noch nicht im Repo) (PR #2252): Nach NIP-01 sind Tag-Filter reine ODER-Filter: Ein Filter "#t": ["meme", "cat"] matcht Events mit einem der beiden Tags. Dieser Vorschlag fügt einen &-Modifikator für indexierbare Tags hinzu, sodass "&t": ["meme", "cat"] nur Events zurückgibt, die beide Tags tragen. Relays bilden die Schnittmenge serverseitig und liefern ein engeres Ergebnis zurück. Die Kompatibilitätsregeln geben UND Vorrang vor ODER, ignorieren auf unterstützenden Relays UND-Werte im ODER und verlangen von Clients zusätzlich die normalen #-ODER-Tags für Relays ohne diese Erweiterung; die Clients bilden aus diesen breiteren Ergebnissen lokal die Schnittmenge. Dieser PR nimmt einen früheren Vorschlag wieder auf und nennt Relay-Implementierungen, darunter ein nostr-rs-relay-Docker-Image, netstr und ein Snort-Worker-Relay. NIP-91 erscheint nur im PR-Branch und fehlt weiterhin im NIP-Index der Repository-README; die Nummer ist daher vorläufig.

  • Nostr Web Applets („NIP-5D", vorgeschlagen, Nummer noch nicht im Repo) (PR #2303): Definiert ein postMessage-Protokoll, über das sandboxed Web-Anwendungen („Napplets") in iframes oder Webviews mit einer Host-Anwendung („Shell") kommunizieren. Die Spec ist bewusst ein dünner Kern: Sie spezifiziert den Nachrichten-Envelope, Sandbox-Regeln (Napplet-iframes MÜSSEN sandbox="allow-scripts" ohne allow-same-origin verwenden, und Shells DÜRFEN NICHT window.nostr NIP-07 im iframe exponieren), Sender-Identifikation über die unverfälschbare MessageEvent.source-Window-Referenz statt event.origin und manifest-basierte Capability-Aushandlung. Die eigentlichen Protokollnachrichten für Signieren, Relay-Zugriff, Speicher und Napplet-zu-Napplet-Kommunikation werden an NAP-Extension-Specs (Nostr Applet Protocol) delegiert, von denen jede eine Capability-Domäne besitzt; Signieren und Verschlüsselung werden stets von der Shell vermittelt, sodass Schlüssel niemals die Sandbox betreten. Der Vorschlag hängt von der NIP-5A-Napplet-Manifest-Spec ab und ist diese Woche aktuell: Amethysts v1.13.0-Pre-Release-Arbeit umfasst Napplet-Account-Isolation, was clientseitiges Napplet-Hosting zu einem aktiven Implementierungsfeld macht. Wie bei „NIP-91" oben ist die 5D-Nummer vorläufig.

NIP Deep Dive: NIP-42 und NIP-43

Ein Relay zu betreiben, das nicht für alle offen ist, bedeutete früher, alles selbst zu erfinden. Der Betreiber eines bezahlten oder einladungsbasierten Relays musste eine Whitelist out-of-band pflegen — meist eine Textdatei mit über DMs gesammelten Pubkeys — ohne standardisierten Weg, einem verbundenen Client zu sagen „beweise, wer du bist", und ohne standardisierten Weg für einen Nutzer, um Aufnahme zu bitten oder zu wissen, ob er Mitglied war. Jedes Relay, das Lese- oder Schreib-Gates wollte, baute seinen eigenen privaten Mechanismus, und Clients konnten mit keinem davon interagieren. NIP-42 standardisiert die Identitätsnachweis-Hälfte dieses Problems, und NIP-43 standardisiert die Mitgliedschafts-Hälfte. Diese Woche mergte nostream, das TypeScript-Relay, das Paar von Ende zu Ende: PR #702 beschränkt Lesevorgänge verschlüsselter Kinds auf authentifizierte Empfänger, und PR #676 fügt Join- und Leave-Request-Event-Strategien hinzu, beide gemergt am 20. Juli.

NIP-42: Authentifizierung von Clients gegenüber Relays

NIP-42 beantwortet eine Frage: Wer ist auf dieser Verbindung? Ein Relay, das Lese- oder Schreibzugriffe beschränken will, sendet beim Verbindungsaufbau oder bei Bedarf, wenn eine Anfrage Authentifizierung erfordert, eine AUTH-Nachricht mit einem Challenge-String. Ein Client antwortet mit seiner eigenen AUTH-Nachricht, die ein signiertes ephemeres Event des kind 22242 enthält, und das Relay antwortet mit einer OK-Nachricht, genau als wäre das Auth-Event ein gewöhnlicher Schreibvorgang. Die Authentifizierung gilt dann für die Dauer der Verbindung. Eine Folge von AUTH-Nachrichten kann mehrere pubkeys auf einer Verbindung authentifizieren.

Das signierte Auth-Event ist ein kompaktes Objekt aus pubkey, created_at, kind 22242, einem relay-Tag, einem challenge-Tag, leerem content und einer sig über der Event-id. Da kind 22242 ephemer ist — Relays dürfen es niemals speichern oder broadcasten — existiert kein veröffentlichtes Beispiel, das sich einbetten ließe; der Feldweg unten deckt ab, was es trägt.

Der pubkey ist die zu beweisende Identität, da das Relay die sig über der Event-id gegen ihn verifiziert. Kind 22242 liegt im ephemeren Bereich: Das Event ist ein Berechtigungsnachweis auf Verbindungsebene, den Relays niemals speichern oder an andere Clients broadcasten dürfen. Ein relay-Tag bindet die Signatur an eine Relay-URL, sodass ein erbeutetes Auth-Event nicht gegen ein anderes Relay wiedergegeben werden kann, während das challenge-Tag es an den konkreten Challenge-String dieser Verbindung bindet und eine spätere Wiedergabe verhindert. Sein created_at muss nahe an der aktuellen Zeit liegen, innerhalb eines Fensters von ungefähr zehn Minuten, sodass ein veraltetes Auth-Event von selbst abläuft. Ein leeres content-Feld bestätigt, dass nichts veröffentlicht wird.

Die Spec definiert außerdem zwei maschinenlesbare Präfixe, die Gating für Clients sichtbar machen. Ein Relay, das eine Subscription ablehnt, weil sich der Client noch nicht authentifiziert hat, antwortet mit einer CLOSED-Nachricht, die mit auth-required: beginnt, und ein abgelehnter Schreibvorgang erhält ein OK mit demselben Präfix. Ein Client, der authentifiziert ist, aber für die Aktion dennoch keine Berechtigung hat, erhält stattdessen restricted:. Genau auf dieser Unterscheidung baut nostreams PR #702 auf: Lesevorgänge verschlüsselter Kinds können nun mit auth-required: geschlossen werden, bis der anfragende Pubkey beweist, dass er der Empfänger ist.

NIP-43: Relay Access Metadata and Requests

NIP-43 beantwortet die Folgefrage: Jetzt, wo das Relay weiß, wer du bist — was darfst du tun? Wo NIP-42 ein Handshake auf einer bestehenden Verbindung ist, ist NIP-43 ein Satz veröffentlichter Events, die den Mitgliedschaftsstatus beschreiben und Nutzern erlauben, dessen Änderung zu beantragen. Auf der Relay-Seite listet ein kind-13534-Event, signiert vom Pubkey im self-Feld des NIP-11-Dokuments des Relays, ein member-Tag pro Pubkey, mit optionalen Rollenargumenten, die auf als kind 33534 veröffentlichte Rollendefinitionen zeigen. Kind 8000 kündigt das Hinzufügen eines Mitglieds an und kind 8001 das Entfernen, beide signiert vom selben Relay-Schlüssel mit einem p-Tag für das betroffene Mitglied. Auf der Nutzerseite ist kind 28934 eine Beitrittsanfrage, die einen Einladungscode in einem claim-Tag trägt, kind 28935 ist ein ephemeres Invite-Code-Event, das das Relay on-the-fly erzeugt, wenn ein Nutzer einen Claim anfordert, und kind 28936 ist eine Austrittsanfrage.

Eine Beitrittsanfrage ist ein ähnlich kleines Objekt, und bislang implementiert kein öffentliches Relay NIP-43, sodass es kein echtes kind-28934-Event zum Einbetten gibt; der Feldweg unten deckt ab, was es trägt.

Der pubkey ist der Nutzer, der um Aufnahme bittet, und kind 28934 markiert das Event als Beitrittsanfrage. Sein --Tag ist der NIP-70-Protected-Event-Marker und weist Relays an, das Event nur von seinem Autor anzunehmen. Ein claim-Tag trägt den out-of-band erhaltenen Einladungscode, und created_at muss innerhalb weniger Minuten um die aktuelle Zeit liegen, damit eine alte Anfrage nicht wiedergegeben werden kann. Relays beantworten den Claim mit einer OK-Nachricht, verwenden das NIP-42-Präfix restricted: für Fehler wie einen abgelaufenen oder ungültigen Code, aktualisieren die kind:13534-Liste und können ein kind:8000-Add-Member-Event veröffentlichen. Mitgliedschaft wird bewusst nicht aus einem einzelnen Event abgeleitet: Die Spec behandelt die vom Relay signierte Liste als eine Eingabe, und ein Client sollte sowohl kind:13534 des Relays als auch die eigenen Events des Mitglieds heranziehen, um dessen aktuellen Mitgliedschaftsstatus zu bestimmen. Clients dürfen Join-, Invite- oder Leave-Anfragen nur an Relays senden, die dieses NIP im Abschnitt supported_nips ihres NIP-11-Dokuments ausweisen; nostreams PR #676 ist die Relay-seitige Maschinerie, die aus diesen Request-Kinds tatsächliche Mitgliedschaftsänderungen macht.

Geschichte

NIP-42 ist der ältere der beiden, und zwar mit deutlichem Abstand. Er ging am 2. Januar 2023 in Commit c80be21c in das NIPs-Repository ein, wo fiatjaf einen früheren von semisol entworfenen Relay-Auth-NIP drastisch vereinfachte und ein komplexeres Challenge-Schema auf das einzelne signierte ephemere Event reduzierte, das die Spec bis heute verwendet. NIP-43 kam viel später, am 30. Oktober 2025, als hodlbods PR #1079 gemergt wurde und Relay-Access-Metadaten und Requests direkt auf NIP-42s restricted:-Präfix aufsetzte. Die Lücke von zweieinhalb Jahren spiegelt wider, wie lange Betreiber bezahlter und privater Relays Ad-hoc-Whitelists nutzten, bevor die Mitgliedschaftsschicht einen Standard bekam.

Implementierungen

Auf der Relay-Seite liefert nostream nach den Merges dieser Woche nun beide Hälften. strfry implementiert NIP-42, validiert kind-22242-Auth-Events in seinem Ingester und gibt Challenges aus seiner Config heraus. nostr-rs-relay handhabt den AUTH-Handshake in seiner Connection-Schicht mit Tests für Challenge und Zeitstempelfenster. khatru, das Go-Relay-Framework, trackt den authentifizierten Pubkey pro Verbindung, sodass Policies Lesen und Schreiben darauf gaten können. Auf der Client-Seite signiert Amethyst kind-22242-Antworten auf Relay-Challenges, einschließlich Per-Stream-Auth für seine verschlüsselten Concord-Communities. Die beiden NIPs teilen Access Control entlang einer sauberen Linie: NIP-42 ist Identitätsnachweis, begrenzt auf eine Verbindung, eine Challenge und ein paar Minuten Gültigkeit, und sagt nichts über Policy. NIP-43 ist Policy, ausgedrückt als gewöhnliche Relay-Events: wer Mitglied ist, wer hinzugefügt oder entfernt wurde, und wie ein Nutzer diese Übergänge beantragt. Die Lücke, die Implementierer im Blick behalten sollten, ist, dass bislang nichts feiner granulare Berechtigungen über NIP-43s optionale Rollen-Metadaten hinaus standardisiert — jedes Relay, das mehr tut als eine binäre Mitglied/Nicht-Mitglied-Teilung, entwirft diese Schicht also selbst.

Das war’s für diese Woche. Baust du etwas oder hast News zu teilen? Melde dich per NIP-17-DM oder finde uns auf Nostr.