Newsletter on Nostr Compass

Nostr Compass #34

Wed, 05 Aug 2026 00:00:00 +0000

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

Diese Woche: Sandstr lässt Neulinge simulierte Nostr-Clients erkunden, ohne Schlüssel zu erstellen oder eine App zu installieren. nostr-mill führt eine Signierzustimmung pro Event und eine clientübergreifende Schlüsselwiederherstellung ein, während nostrord relay-gehostete Gruppen, Signer, Moderation, Uploads und Highlights erweitert. Die Protokollarbeit umfasst Nostr-Eventformate, Wallet-Verbindungen, Relay-Discovery, Napplets, Marmot und Concord; die Deep Dives erklären relay-gestützte Suche und portable Highlights.

Top-Storys

nostr-mill 1.6.0 bringt Signierzustimmung und Kontowiederherstellung in den Browser

nostr-mill 1.6.0 ist ein einbettbarer Browser-Kontowähler und -Signer. Er fragt nun pro Event-Kind um Zustimmung und zeigt decodierte Inhalte und Tags vor dem Signieren an, mit zeitlich begrenzten Freigaben und einem Berechtigungsmanager. Das Release behebt außerdem einen Fehler in der ersten Sitzung, der Kategorien, die für eine Abfrage bei jedem Mal konfiguriert waren, ohne Nachfrage signieren ließ. Das optionale Google-Onboarding kann einen bestehenden nsec importieren, speichert den Schlüssel verschlüsselt im App-Daten-Ordner des Nutzers auf Drive, unterstützt mehrere Identitäten und kann einen ncryptsec im NIP-49-Format (verschlüsseltes Private-Key-Format) exportieren.

Das experimentelle Relay-Backup leitet eine starke Wiederherstellungsphrase mit scrypt und HKDF ab, verpackt den Schlüssel als ncryptsec, verifiziert abgerufene Events und verlangt vor der Wiederherstellung ein Relay-Quorum. Der NIP-55-Login (Android-Signer-Intents) nutzt jetzt Ambers Zwischenablage-Rückweg, und NIP-46-Verbindungen (relay-vermitteltes Remote-Signing) sind standardmäßig leise. Branding-Steuerungen und responsive Berechtigungsbildschirme runden das Release ab, ohne bestehende Integrationen zu ändern, sofern ein Betreiber nicht aktiv zustimmt.

nostrord 2.5.0 verleiht Relay-Gruppen stabile, relay-spezifische Identitäten

nostrord 2.5.0 ist ein plattformübergreifender Client für relay-gehostete Communities. Er leitet nun eine NIP-29-Identität (relay-verwaltete Gruppen) aus Gruppen-ID und Host-Relay ab, begrenzt Mitgliedschaft und Admin-Abzeichen auf dieselbe Weise, akzeptiert Gruppen-naddr-Deep-Links und synchronisiert private Gruppen-Threads zwischen Geräten.

Das Release fügt außerdem einen NIP-56-Moderations-Posteingang (Report-Events) hinzu, Amber-Login über NIP-55, Rate-Limit-Backoff für NIP-46-Signer-Verkehr, NIP-84-Rendering (portable Highlights) mit Wiederholungsversuchen für unaufgelöste Referenzen sowie Medien-Uploads über Blossom oder NIP-96 (HTTP-Dateispeicherung). Der Google-Login sichert den Schlüssel jetzt vor der Kontoerstellung und bestätigt Trennungen. Thread-Antworten erhalten reichhaltigere Inhalte und Admin-Löschungen, während Korrekturen am Desktop-Schlüsselbund und an der mobilen Tastatur diese Protokollfunktionen nutzbar halten.

Primal Android 3.5.25 aktualisiert Remote-Signing und Follow-Listen-Filterung

Primal Android 3.5.25 ist ein mobiler Nostr-Client mit Feeds, Suche und Remote-Signing. Er aktualisiert seinen Remote-Signer auf das aktuelle Protokollverhalten, fügt eine Stummschaltungsliste für Gefolgte hinzu, öffnet die Suche aus Explore, repariert blockierte Relay-Verbindungen automatisch, legt Anfrage-Timeouts in der Oberfläche offen, weist ungültige Follow-Listen-Einträge zurück und aktualisiert die Fallback-Relay-URLs. Feed-Prefetching, geringerer Speicherverbrauch und eine 100-MB-Cache-Obergrenze senken die Kosten für die Aktualität dieser Feeds. Notizen mit einem einzelnen Bild nutzen nun die volle Inhaltsbreite, und Profilsteuerungen sowie Medien-Vorladen erhalten kleinere Interaktions- und Sortierkorrekturen.

Nostur 1.30.2 erweitert private Antworten und Medien in Direktnachrichten

Nostur 1.30.2 ist ein Nostr-Client für Apple-Plattformen. Er blendet die Aktion für private Antworten jetzt immer ein, fügt DM-Medien-Caches pro Unterhaltung mit Limits und Löschsteuerungen hinzu, verbessert die Namen- und Tag-Vervollständigung in Beiträgen und Chats, zeigt referenzierte Nachrichten im Live-Chat an und nimmt den Raumtitel in Chat-Benachrichtigungen auf. Korrekturen an der Feed-Paginierung und an verschachtelten Antworten beheben Rückschritte beim Abruf und beim Rendern von Unterhaltungen.

Chama 5.7.0 führt Schlichter-Einträge und gecachte Handelswiederherstellung ein

Chama 5.7.0 koordiniert Peer-Handel und Schlichtung über signierte Nostr-Event-Ketten. Es zeigt den gesperrten Betrag eines Schlichters, die Laufzeit seiner Kaution und seinen Finanzierungs-Outpoint an; verzeichnet, wann ein Ersatz einen abwesenden Schlichter ersetzt hat; und definiert ruhende Fehler-Attestierungen des Kinds 38136, die die Signaturen beider Parteien erfordern. Eine explizite Reparatur wiederholt unvollständige Relay-Historien gegen den dauerhaften Geräte-Cache und veröffentlicht wiederhergestellte Events erneut, während fehlgeschlagene Veröffentlichungen für die nächste Verbindung in die Warteschlange gehen. Das Release verhindert außerdem geräteübergreifend doppelte Schlichter-Prämienzahlungen, indem es das Kind-38113-Event des Autors als Zahlungsnachweis behandelt.

Auditable Voting 0.1.165 stellt die Zustellung delegierter Stimmzettel wieder her

Auditable Voting 0.1.165 führt verifizierbare Abstimmungen durch und trennt dabei Wähler-Credentials vom Stimmzettelinhalt. Es stellt die delegierte Ausstellung blinder Stimmzettel über authentifizierte Delegationszustellung und Kontroll-DM-Nachträge wieder her, belässt Direktnachrichten mit blinden Credentials auf den konfigurierten privaten Relays und aktualisiert den Audit-Proxy auf 0.1.52.

Sandstr lässt Neulinge Nostr-Clients mit Mock-Daten ausprobieren

Sandstr bietet interaktive Browser-Simulationen von Nostr-Clients, damit Neulinge deren Oberflächen vergleichen können, bevor sie einen installieren oder ein Schlüsselpaar erstellen. Der Launch vom 3. August umfasst referenzverifizierte Nachbildungen von Damus, Amethyst, Primal, Snort, YakiHonne, Coracle und Wisp sowie klar gekennzeichnete frühe Vorschauen von Gossip, Keychat und Olas. Alles läuft lokal gegen Mock-Daten, sodass die Simulationen weder Schlüssel erzeugen noch sich mit Relays verbinden. Jede Simulation verlinkt auf die Website und das Quell-Repository des echten Clients und macht Sandstr damit zu einem Onboarding- und Interface-Vergleichswerkzeug statt zu einem weiteren Nostr-Client. Es zeigt, wie sich Feeds, Profile, Threads, Direktnachrichten, Suche, Zaps und Relay-Steuerungen anfühlen, ohne von einem Erstnutzer vorab eine Identitäts- oder Sicherheitsentscheidung zu verlangen.

mineracks signer kombiniert eine Browser-Erweiterung mit einem Desktop-Bunker

mineracks signer bietet zwei Signier-Oberflächen aus demselben Projekt. Seine Browser-Erweiterung implementiert NIP-07, damit Webanwendungen Signaturen anfordern können, ohne den privaten Schlüssel zu erhalten, während die Desktop-Anwendung einen NIP-46-Remote-Signer für Clients bereitstellt, die über Relays kommunizieren.

Das Desktop-Release 0.1.0 des Projekts speichert Schlüsselmaterial mit der NIP-49-Verschlüsselungscodierung und hält den entschlüsselten Schlüssel im Rust-Prozess, statt ihn an die Oberfläche weiterzugeben. Jede Anfrage zeigt die aufrufende Anwendung und die angeforderte Aktion, während die automatische Genehmigung pro Anwendung optional und widerrufbar ist. Der erste Desktop-Build unterstützt Apple Silicon, aber keine Intel-Macs.

Releases

Jumble 26.8.1 führt Proof-of-Work-Steuerungen und Kommentar-Vorschauen ein

Jumble 26.8.1 ist ein Web- und Desktop-Nostr-Client. Er merkt sich die Proof-of-Work-Schwierigkeit für das Veröffentlichen, zeigt Abzeichen für verifizierte Arbeit an, zeigt Vorschauen verlinkter Kommentare über externen Inhalten, speichert Bilder aus dem Vollbild-Viewer und klappt lange Profil-Biografien bei Bedarf aus. Reaktions-Benachrichtigungen verwerfen jetzt nicht unterstützte Event-Kinds, Hinweise auf Relay-Trennungen sind weniger aufdringlich, die Standard-Relays wurden aktualisiert und ein Konflikt bei der Medien-Autowiedergabe wurde behoben.

nostr-calendar 2.1.0 stellt die Signer-Bindung bei privaten Formularen wieder her

nostr-calendar 2.1.0 veröffentlicht Kalender, Events und Formularantworten als Nostr-Daten. Es bindet Einreichungen privater Formulare an den aktiven Signer, speichert beabsichtigte doppelte Events auf Relays, behebt den Relay-Abruf, parst Kalenderdaten in lokaler Zeit und fügt App-Benachrichtigungen sowie einen iOS-Client hinzu. Die Signer-Korrektur verhindert, dass eine veraltete Identität eine unbrauchbare verschlüsselte Antwort erzeugt.

Manent 2.0.0 führt Tagging und Suche für gespeicherte Notizen ein

Manent 2.0.0 ist ein persönliches Archiv für signierte Nostr-Notizen. Es fügt lokale Tags und Suche hinzu, sodass Leser gespeicherte Events organisieren und abrufen können, ohne deren signierte Inhalte zu verändern.

nosvelte 0.6.1 schließt leere Abonnements nach EOSE

nosvelte 0.6.1 stellt reaktive Svelte-Komponenten und -Hooks für Relay-Daten bereit. Leere Suchen kommen jetzt mit dem End of Stored Events zum Abschluss, ein Abbruch schließt das zugrunde liegende REQ, Wiederholungen räumen veraltete Fehler ab, und Listen-Hooks geben ihren dokumentierten Leerwert zurück. Es erkennt außerdem adressierbare Events unabhängig davon, wo ihr d-Tag steht, ersetzt überholte Metadaten und Artikel, dedupliziert Reaktionen nach Event-ID und behält jedes Event aus dem ersten Batch eines Relays.

Unveröffentlichte Änderungen

NMP bindet die Relay-Zulassung an Deklarationen und erweitert Gruppenabfragen

NMP ist ein TypeScript-Toolkit zum Bauen von Nostr-Anwendungen und relay-gestützten Gruppen-Oberflächen. PR #1254 lässt die Relay-Zulassung dem Eigentümer der autorisierenden Deklaration folgen und hält die Berechtigungsentscheidung so an den signierten Nostr-Zustand gebunden. PR #1255 verallgemeinert NIP-29-Abfragen relay-verwalteter Gruppen, statt eine einzige enge Abfrageform anzunehmen. Beide Änderungen sind gemergt, aber noch nicht in einem getaggten Release erschienen.

Mosaico leitet die Identität verwalteter Gruppen aus Relay-Einträgen ab

Mosaico ist ein Nostr-Client zum Durchsuchen und Verwalten relay-verwalteter Communities. PR #758 leitet die Identität einer verwalteten Gruppe vom Relay ab, das ihre maßgeblichen Einträge hostet. PR #757 beobachtet den veröffentlichten Eintrag der Gruppe bei der Auflösung des Administrationsstatus. So bleiben zwei gleichnamige Gruppen auf unterschiedlichen Relays unterscheidbar, und Clients erhalten eine relay-gestützte Quelle für ihre Verwaltungsmetadaten.

Divine isoliert langsame Relays bei Multi-Relay-Abfragen

Divine ist ein mobiler Kurzvideo-Client, der Videos über Nostr veröffentlicht und abruft. PR #6673 gibt jeder Relay-Abfrage ihr eigenes Timeout, statt eine blockierte Verbindung das Zeitbudget einer gesamten Anfrage aufbrauchen zu lassen. Ergebnisse antwortender Relays können so eintreffen, während der langsame Endpunkt unabhängig aufgegeben wird. Die Änderung verbessert den Abruf, ohne ein Relay als maßgeblich für das kombinierte Ergebnis zu behandeln.

rust-nostr härtet Verschlüsselung, Hashes und Reconciliation

rust-nostr ist eine Rust-Bibliothek und ein Toolkit für Nostr-Clients, -Relays und Protokollimplementierungen. PR #1421 reduziert Allokationen im versionierten NIP-44-Verschlüsselungspfad, während PR #1423 typisierte Hashes einführt, die das versehentliche Vermischen inkompatibler Digest-Werte erschweren. Commit 21e31c2 verhindert, dass eine fehlerhafte NIP-77-Negentropy-Nachricht zur Mengenabgleichung das lokale Relay trennt. Die gemergte Arbeit verschärft sowohl den Umgang mit verschlüsselten Nutzdaten als auch das Fehlerverhalten bei der Reconciliation vor dem nächsten Release.

Zeus serialisiert NWC-Zahlungen vor der Belastung von Ausgabenbudgets

Zeus ist eine mobile Bitcoin- und Lightning-Wallet, die Wallet-Operationen über Nostr Wallet Connect bereitstellen kann. PR #4305 rechnet ausstehende Zahlungen auf ein NIP-47-Budget (Nostr Wallet Connect) an, statt auf die Abwicklung zu warten. PR #4303 serialisiert die Zahlungsabwicklung, damit gleichzeitige Anfragen nicht dasselbe Autorisierungslimit überrennen können. Das gemergte Paar schließt eine Lücke bei der Budgetdurchsetzung auf der Nostr-Kontrolloberfläche der Wallet.

Nostr Components teilt einen einzigen Relay-Verbindungsversuch

Nostr Components ist eine wiederverwendbare Web-Component-Bibliothek, um Nostr-Daten und -Interaktionen in Anwendungen einzubinden. PR #105 lässt gleichzeitig gemountete Komponenten einen laufenden Relay-Verbindungsversuch teilen. Jeder Nutzer erhält weiterhin die resultierende Verbindung, aber gleichzeitige Mounts öffnen keine doppelten Sockets mehr, während der erste Handshake noch aussteht. Die Änderung reduziert vermeidbare Relay-Last in Anwendungen, die aus mehreren unabhängigen Komponenten zusammengesetzt sind.

NIP-Updates und Protokoll-Spezifikationsarbeit

Nostr-Eventformate und Discovery

NIP-PR #2430 schlägt Sticker-Packs als adressierbare Kind-30031-Definitionen und die installierten Packs eines Nutzers als ersetzbares Kind 10031 vor. Jeder Sticker-Tag trägt einen Shortcode, einen SHA-256-Hash und einen MIME-Typ; das Bild verbleibt auf einem NIP-B7-Server (Blossom-Blob-Speicher). Der offene Entwurf standardisiert damit Pack-Identität und -Installation, ohne Bildbytes in Events abzulegen.

NIP-PR #2429 schlägt adressierbare Gopher-Dokumente des Kinds 31436 vor. Jedes Event enthält einen UTF-8-Text- oder Menüknoten, und signierte Knoten unter einer Pubkey bilden ein Gopherhole, das jede relay-gestützte RFC-1436-Bridge ausliefern kann. Der offene Vorschlag nutzt den gewöhnlichen Speicher adressierbarer Events, statt die Veröffentlichung an einen einzelnen Gopher-Hostnamen zu binden.

NIP-PR #2428 schlägt private Gruppen mit Epochen-Tickets vor. Eine Gruppe rotiert Mitgliedschafts-Credentials zwischen Epochen, und Clients legen das Ticket der aktuellen Epoche vor, um teilzunehmen. Der Entwurf zielt auf privaten Chat ab, ohne von einem Relay zu verlangen, ein permanentes Bearer-Token als lebenslange Mitgliedschaft zu behandeln.

NIP-PR #2425, letzte Woche als Vorschlag behandelt, hat nun eine URI-Klarstellung in NIP-B0 (adressierbare Web-Lesezeichen) gemergt. Er unterscheidet weggelassene HTTPS-Präfixe von expliziten URI-Schemata, wenn ein Lesezeichen sein Ziel im d-Tag speichert, und verhindert so, dass Clients ein mehrdeutiges Ziel rekonstruieren.

Zahlungen und Wallet-Verbindungen

NIP-PR #2419, in der Ausgabe vom 22. Juli als Vorschlag behandelt, hat nun einen kleineren NIP-47-Kern (Nostr Wallet Connect) gemergt. Verbindungs-URIs, verschlüsselter Relay-Transport, Capability-Discovery, Verschlüsselungsaushandlung und gängige Methoden bleiben im NIP; Benachrichtigungen, Hold-Invoices, Keysend, Transaktionshistorie, Metadaten und Deep-Link-Pairing wandern in ein eigenes Erweiterungs-Repository. Bestehende Verbindungen bleiben kompatibel, während Wallets die optionalen Verträge unabhängig implementieren können.

NWC-PR #2, letzte Woche als Vorschlag behandelt, hat nun BIP-321-Zahlungsmethoden in jenes Erweiterungs-Repository gemergt. BIP-321 stellt einen gemeinsamen Bitcoin-Zahlungs-URI bereit, der verschiedene Rails tragen kann, sodass NWC-Aufrufer eine Zahlung anfordern oder senden können, ohne für jeden zugrunde liegenden Anweisungstyp einen neuen Kern-RPC hinzuzufügen.

Napplet-Host-Fähigkeiten

NAP-PR #95 schlägt Katalog-Discovery für über Nostr verteilte Sandbox-Anwendungen vor. Ein Napplet fragt seinen Host, welche Anwendungen und Fähigkeiten verfügbar sind, und der Host liefert policy-gefilterte Metadaten, statt seine gesamte lokale Umgebung offenzulegen. Der Vertrag unterstützt Startentscheidungen, ohne während der Discovery Ausführungsrechte zu gewähren.

NAP-PR #33 schlägt shell-vermittelte Datei- und Blob-Uploads vor. Ein Napplet liefert Bytes und Absicht; der Host wählt einen NIP-96- oder Blossom-Rail, signiert die Autorisierung, meldet den Fortschritt und gibt URLs, Hashes, MIME-Daten und anhängfertige NIP-94-Tags (Datei-Metadaten) zurück. Speicher-Credentials und HTTP-Autorität gelangen niemals in das Napplet.

Marmot-verschlüsselte Gruppen

Marmot-PR #410 hat Konvergenz- und Deferred-Input-Regeln gemergt. Clients unterscheiden ein Objekt, dem eine aktuelle Epochen-Abhängigkeit fehlt, von veralteter oder ungültiger Eingabe, halten es nach einer Ressourcenverweigerung für einen erneuten Abruf berechtigt und versuchen es erneut, wenn ein anderer Commit den Entschlüsselungskontext ändert. Ein domänensepariertes State-Commitment gibt Konformitätstests ein gemeinsames Konvergenz-Orakel, ohne ein Produktions-Wire-Feld hinzuzufügen.

Concord-Community-Ebenen

Concord-PR #14 hat CORD-08-Disappearing-Messages gemergt. Ein Community-Metadatenwert legt die Lebensdauer fest; Chat-Rumors und verschlüsselte Wraps tragen einen NIP-40-Tag (Event-Ablauf), während Lösch-Events und der Timer-Hinweis des Kinds 1740 ausgenommen sind. Der signierte Timer reist mit dem Community-Zustand, wobei das Relay-Löschen weiterhin eine Aufbewahrungsanfrage und keine kryptografische Löschgarantie bleibt.

Concord-PR #13 hat rotierungsfestes Pinnen in CORD-04 gemergt. Jeder Kanal hat eine vollständig ersetzende Pin-Liste auf der Kontrollebene; Einträge tragen das ursprüngliche signierte Siegel plus NIP-44-Expansionsschlüssel pro Nachricht, sodass ein neues Mitglied Autor und Klartext verifizieren kann, ohne einen alten Epochenschlüssel zu erhalten. Private Listen können an eine Kanal-Epoche versiegelt bleiben, Obergrenzen begrenzen die Listengröße, und Autoren-Löschungen entfernen Pins, ohne die Kontrolebenen-Kette zu forken.

NIP Deep Dive

Suchfähigkeit (NIP-50)

NIP-50, definiert in der primären Spezifikation, fügt einen optionalen Suchfilter für Relays hinzu. Gewöhnliche Nostr-Filter funktionieren, wenn ein Client bereits einen Autor, ein Event-Kind, eine Kennung oder einen Tag kennt; NIP-50 adressiert die Discovery, wenn die Eingabe eine menschliche Anfrage wie best nostr apps ist.

Das NIP-50-Wire-Format fügt einem normalen Filter innerhalb einer REQ-Nachricht einen search-String hinzu. Eine Anfrage kann dieses Feld mit kinds, authors, ids, Tag-Filtern und limit kombinieren, und ein REQ kann mehrere unabhängige Filter tragen. Ein unterstützendes Relay sollte primär gegen den Event-content matchen, darf andere Felder nutzen, wenn das Event-Kind dies sinnvoll macht, und sollte nach seinem eigenen Relevanz-Score sortieren, bevor es das limit anwendet. Diese Reihenfolge unterscheidet sich vom üblichen Neueste-zuerst-Eventstream.

Der Query-String kann die key:value-Erweiterungen der Spezifikation enthalten. Sie nennt include:spam, domain:, language:, sentiment: und nsfw:; ein Relay sollte Erweiterungen ignorieren, die es nicht implementiert. Clients erkennen die deklarierte Unterstützung über das supported_nips-Feld des Relays in NIP-11, können den Filter aber trotzdem an andere Relays senden, wenn sie bereit sind, nicht passende Antworten zu verwerfen.

Die NIP-50-Spezifikation standardisiert bewusst weder Tokenisierung, Stemming, Ranking, Spracherkennung, Sentiment-Analyse noch Spam-Klassifizierung. Zwei konforme Relays können für dieselbe Anfrage unterschiedliche Events und unterschiedliche Reihenfolgen liefern. Das macht das Relay zu einem Index- und Ranking-Anbieter, nicht zu einer Wahrheitsquelle. Die Spezifikation empfiehlt, mehrere unterstützende Relays abzufragen, zu prüfen, ob die zurückgegebenen Events dem Anwendungsfall des Clients genügen, und Relays mit schlechter Präzision fallen zu lassen.

Das unterscheidet sich vom exakten NIP-01-Filtern. Ein authors- oder #t-Filter hat deterministische Match-Semantik, die ein Client direkt verifizieren kann, während ein Suchtreffer von einem Index und einem opaken Score abhängen kann. NIP-50 behält den signierten Event-Umschlag und den Relay-Transport von NIP-01 bei, akzeptiert aber Variationen bei Recall und Reihenfolge, um offene Abfragen zu ermöglichen.

Das folgende Event ist ein echtes Suchergebnis, das ein NIP-50-Suchrelay für eine Relay-Discovery-Abfrage zurückgegeben hat, mit den sieben NIP-01-Event-Feldern und einer gültigen Signatur.

{
 "id": "2943d6b43bcbf0ee4a8b4cac912111be0309607b8bb435ae40529989bea7f6c5",
 "pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
 "created_at": 1785771175,
 "kind": 1,
 "tags": [],
 "content": "I've been working on a customizable client (mostly relay feeds, but a ton of other things and subtle details too). It's called Hallway for reasons I don't remember and it's a fork of Fevela which is a fork of Jumble, but very rewritten for speed and simplicity...",
 "sig": "5b058b89dab9bd09d81bdc10eff95536125b87fbcbbc97f08d835c1272b2a3190cc3d340e42f54acb0d7e0e4b00355ab91292d0305c84a2d73b538319c0da12c"
}

Aktuelle Clients nutzen denselben Filter in unterschiedlichen Discovery-Oberflächen. Nostria sendet NIP-50-Suchen an dedizierte Such-Relays, Ditto sucht Events über seinen Relay-Pool, und NoorNote koordiniert relay-gestützte Suchen für das Longform-Lesen. Ihre unterschiedliche Ergebnisbehandlung spiegelt den Spielraum wider, den NIP-50 Relays und Clients lässt.

Highlights (NIP-84)

NIP-84, definiert durch seine primäre Spezifikation, weist einem Highlight das Kind 9802 zu. Es verwandelt eine ausgewählte Passage oder eine Referenz auf nicht-textuelle Medien in ein signiertes Event, das zwischen Lese-, Social- und Annotations-Clients wandern kann.

Der content des Events enthält den ausgewählten Text und kann leer sein, wenn die Quelle Audio, Video oder ein anderes nicht-textuelles Medium ist. Ein Highlight verweist mit einem a-Tag auf ein adressierbares Event oder mit einem e-Tag auf ein gewöhnliches Event als Nostr-Quelle; ein r-Tag identifiziert eine Web-URL. URL-erzeugende Clients sollten Tracking- und andere nutzlose Query-Parameter vor dem Veröffentlichen entfernen, damit kosmetische URL-Varianten Referenzen auf dieselbe Quelle nicht fragmentieren.

Optionale p-Tags attribuieren die Quelle einer oder mehreren Nostr-Pubkeys. Ihr vierter Wert kann eine Rolle wie author oder editor angeben, und ein context-Tag kann umgebenden Text bewahren, wenn die Auswahl allein unklar wäre. Ein Quote-Highlight fügt stattdessen einen comment-Tag hinzu, statt eine zweite Kind-1-Notiz zu veröffentlichen: Der r-Tag der Quelle erhält die Markierung source, während im Kommentar erwähnte Pubkeys oder URLs mention tragen, sodass Renderer Attribution von der Antwort des Nutzers unterscheiden können.

Die Kind-9802-Definition macht ein Highlight zu einem regulären statt einem ersetzbaren Event. Das Wiederholen oder Korrigieren einer Auswahl erzeugt ein weiteres signiertes Event, und das Entfernen hängt vom normalen Löschanfrage-Fluss und der Aufbewahrungspolitik des Relays ab. Die Spezifikation definiert keine Byte-Offsets, Selektoren oder einen kanonischen Dokumenten-Snapshot, sodass ein Client eine Passage nach einer Änderung ihrer Web-Quelle möglicherweise nicht wiederfindet. Öffentliche Highlights offenbaren außerdem Leseinteressen; private Annotation erfordert ein separates Verschlüsselungs- und Sharing-Design.

NIP-84 unterscheidet sich von einem NIP-23-Longform-Event, das einen ganzen Artikel als Kind 30023 veröffentlicht; ein Highlight zitiert oder zeigt in Material, das anderswo verbleiben kann. Es unterscheidet sich auch von einem NIP-51-Lesezeichen-Set, das eine ersetzbare Sammlung von Referenzen speichert. NIP-84 macht jede Auswahl unabhängig signiert, attribuierbar, auffindbar und diskutierbar.

Das folgende Highlight ist ein echtes Kind-9802-Event, das aus Primals iOS-Client veröffentlicht und aus öffentlichen Relays wiederhergestellt wurde. Es trägt die sieben NIP-01-Event-Felder mit gültiger Signatur, einen a-Tag, der auf ein NIP-23-Langform-Event zeigt, einen p-Tag zur Nennung des Artikelautors und einen context-Tag mit der umgebenden Passage.

{
 "id": "0d57c07cfdfe8ec00711e2af88a666b61fc35c167b90b02dfb5db7ffba7b794a",
 "pubkey": "07367baec8e73c076b14e47fba3b0d5c014d559d7986a7172a79a8a64419d7c2",
 "created_at": 1785797755,
 "kind": 9802,
 "tags": [
 ["context", "Quantum computers will break secp256k1 which nostr relies on for its public private key pair. This means that given an npub, a quantum computer will be able to derive your nsec, read all your encrypted data and sign events as you."],
 ["alt", "This is a highlight created in https://primal.net iOS application"],
 ["a", "30023:1ec454734dcbf6fe54901ce25c0c7c6bca5edd89443416761fadc321d38df139:nostr-quantum-preparation"],
 ["p", "1ec454734dcbf6fe54901ce25c0c7c6bca5edd89443416761fadc321d38df139", "", "mention"]
 ],
 "content": "Quantum computers will break secp256k1 which nostr relies on for its public private key pair. This means that given an npub, a quantum computer will b",
 "sig": "219f3c1e572d1a087d667dc0d3a5443c77c0db3a5d42ce4e630604901ac63d2c879a86269d81e220bb77fd48b1579adafc333075e53c6eb0a108791fdd4a1622"
}

Das Format überschreitet bereits Client-Grenzen. nostrord 2.5.0 hat diese Woche NIP-84-Rendering hinzugefügt, NoorNote rendert Highlight-Events in seinem Longform-Client, und Ditto veröffentlicht sie aus ausgewählten Inhalten. Diese Implementierungen decken Lesen, Erstellen und Social-Rendering ab, ohne dass ein einzelner Dienst die Annotation besitzen muss.

Sende eine NIP-17-DM, um ein Projekt oder eine Nachricht über das Nostr-Compass-Projekt zu teilen.

Nostr Compass #33

Wed, 29 Jul 2026 00:00:00 +0000

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

Diese Woche: Amethyst 1.13.1 folgt auf den Start der Nostr-Apps in Version 1.13.0 und bringt NIP-29-Authentifizierung beim Host-relay sowie authentifizierte Wiederholungsversuche für Blossom-Downloads. Code Call hält Remote-Coding-Sitzungen vom Smartphone aus in Gang, GitWorkshop koordiniert Maintainer und die Synchronisierung von Repositories, und Mosaico stellt Coding-Agenten eine gemeinsame Nostr-Schicht für Statusinformationen bereit. Nostrology kartiert, wie Profile Lese- und Schreibaufgaben auf ihre veröffentlichten relay-Listen verteilen. Android-Releases von Mafrend, Hanami und Cordn führen die Releases mit Versions-Tag an, während FIPS eine Zugriffsschicht für OpenWrt ergänzt und ein offener PR eine Portierung auf FreeBSD vorschlägt. Die Protokollberichterstattung behandelt NIPs, BUDs, NAPs, Marmot, Gamma Markets, Concord und NWC, während Sechs Jahre Nostr im Juli die Änderungen im Juli von der frühen Domainauflösung bis zum Zustand von relay-Gruppen nachzeichnet.

Top-Storys

Amethyst 1.13.1 ergänzt nach dem Start seiner Nostr-Apps authentifizierten Zugriff auf Gruppen und Blossom

Amethyst 1.13.0, am 28. Juli für den Android- und Multiplattform-Nostr-Client veröffentlicht, öffnet napplets und NIP-5A-nsites in einem isolierten Browserprozess ohne Schlüsselzugriff. Eine durch Zustimmung freigegebene window.nostr-Brücke kann über das aktive Konto signieren und ausgewählte Funktionen nutzen, während Berechtigungsansichten pro Website und pro Konto Nutzern erlauben, diese Freigaben zu prüfen oder zu widerrufen. Bevorzugte Apps können an der unteren Leiste angeheftet bleiben, ohne Cookies, Anmeldestatus oder Freigaben zwischen Konten zu teilen.

Dasselbe Release 1.13.0 ergänzt Git-Repository-Bäume, Issues und Pull Requests sowie Concord-Communities, NIP-29-relay-Gruppen, Buzz-Gruppenchats, Wiki-Seiten und RSS-Feeds. Über diese Oberflächen kann ein Nutzer unter derselben Nostr-Identität zwischen Code, Community, Publikationen und sozialen Ansichten wechseln.

Auch Zahlungen und Identitätsfunktionen wurden in Version 1.13.0 erweitert. Amethyst kann BOLT12-Angebote erstellen und bezahlen, Remote-Signer-Konten automatisch starten, Blossom-Fallback-Server hinzufügen und die Web-of-Trust-Steuerung für Badges, Communities und relay-Gruppen ausbauen. Das Folgerelease 1.13.1 vom 29. Juli ergänzt ein CORD-02-Auflösungssiegel, die Löschung von Gruppen und Kanälen mit kind 9008, NIP-29-Authentifizierung beim Host-relay und authentifizierte BUD-01-Wiederholungsversuche für zugriffsbeschränkte Blossom-Downloads.

Code Call 0.2.68 ergänzt einen Browser für Worker-Ordner, nachdem 0.2.66 eine Aufholfunktion eingeführt hatte

Code Call 0.2.68, eine Android-Fernsteuerung für Coding-Sitzungen auf einem Computer, ersetzt die bisherige, auf Sonderfälle zugeschnittene Workspace-Liste durch einen Ordnerbrowser, der im Worker-Verzeichnis beginnt. Nutzer können zu verschachtelten zulässigen Ordnern navigieren, einen davon für eine OpenCode-Sitzung auswählen und zu übergeordneten Ordnern zurückkehren; Version 0.2.67 öffnet diesen Browser beim Erstellen einer Sitzung.

Das frühere Release 0.2.66 kann einen zuständigen Worker um eine knappe Zusammenfassung des Stands seit der neuesten Smartphone-Nachricht bitten. Weitere Releases derselben Woche halten mehrere Sitzungen voneinander unabhängig, akzeptieren Antworten nur vom erwarteten Absender und halten den Posteingang für die Zustellung im Hintergrund mit jedem konfigurierten Worker-relay verbunden. Anfragen und Antworten werden als NIP-17 (Private Direktnachrichten) übertragen, während lokal verschlüsselte Blossom-Anhänge nach der Entschlüsselung ihren ursprünglichen Dateityp behalten.

GitWorkshop koordiniert Maintainer und hält die Repository-Synchronisierung unabhängig

GitWorkshops signiertes Release vom 27. Juli ergänzt die Android-Anmeldung über NIP-55 (Android-Signer-Anwendung) für die browserbasierte NIP-34-Forge (git stuff). Das Quell-Repository koordiniert jetzt leitende Maintainer rekursiv, bewahrt die relay-Hinweise jedes Maintainers und hält die Repository-Synchronisierung unabhängig von der Annahme einer Einladung. Repository-übergreifende Verweise auf Arbeitselemente verbinden zusammengehörige Arbeit in verschiedenen Repositories, während GRASP Repository-Daten zu ausgewählten Git-Endpunkten kopiert, ohne diese Übertragung an die Zustellung einer Einladung zu koppeln. Das von einem Entwickler signierte Update 3.1.1 korrigiert die Zustellung von Android-Signer-Intents, die rekursive Auflösung von Maintainern und Repository-Links unter Beibehaltung des Pfads.

Mosaico 0.1.2 lässt Coding-Agenten ihren Status über Nostr teilen

Mosaico 0.1.2 ermöglicht Sitzungen von Coding-Agenten in Claude Code, Codex, Goose, Hermes, OpenCode und Grok, kurze Statusmeldungen über NIP-29 (relay-basierte Gruppen) zu veröffentlichen. Sitzungen können zusammengehörige aktive Arbeiten über Hosts hinweg finden, ohne ihre Transkripte oder ihren Kontext zu teilen.

Die Erkennung benannter Codex-Profile und Gooses Ansicht Top Of Mind machen diese gemeinsamen Statusinformationen in beiden Agentenwerkzeugen sichtbar (PR #618, PR #619). Das Release ermöglicht gehosteten Agenten wieder den Beitritt zur öffentlichen Schicht für Statusinformationen, und die Einrichtung erfordert nun die ausdrückliche Auswahl eines relay (PR #626, PR #629). Mosaico bleibt eine Schicht für Statusinformationen und ist weder Agenten-Host noch Orchestrator oder Werkzeug zur Zusammenführung von Transkripten.

Nostrology kartiert die Konzentration von relay-Listen aus veröffentlichten NIP-65-events

Nostrologys relay-Observatorium leitet seinen Datensatz aus dem neuesten NIP-65-event (Metadaten für relay-Listen) mit kind 10002 jedes Profils ab und folgt dabei der veröffentlichten Spezifikation. Es trennt Lese-, Schreib- und kombinierte relay-Rollen, stellt grafisch dar, wie viele relays jedes Profil aufführt, und zeigt die zugrunde liegenden Zahlen in einer sortierbaren Tabelle. Bei der Veröffentlichungsprüfung am 29. Juli enthielt die Seite 34.430 verschiedene relay-URL-Werte und ordnete 520.468 Profile genau einem aufgeführten relay zu, verglichen mit 150.657 Profilen bei drei und 60.710 bei vier relays.

Derselbe Nostrology-Snapshot zeigt Überschneidungen in der Konzentration: relay.momostr.pink ist in 298.859 Profilen eingetragen, relay.damus.io in 287.181, nos.lol in 279.468 und relay.primal.net in 225.336. Diese Zahlen messen veröffentlichte Einträge in relay-Listen und nicht die Verfügbarkeit: Die Rohdatentabelle kann fehlerhafte URLs und lokale Adressen enthalten, während die NIP-65-Spezifikation Routing-Metadaten definiert und den Zustand von relays nicht prüft. Das Observatorium macht Probleme bei Verbreitung und Datenqualität sichtbar, ohne ein aufgeführtes relay als aktives relay zu behandeln.

Releases mit Versions-Tag

Kairos 0.1.1 ergänzt Erinnerungen und eine lokale Anweisung für Astraea

Kairos 0.1.1 ergänzt Erinnerungen an Fälligkeitstermine, eine ausdrückliche lokale Anweisung für Astraea sowie eine strengere Behandlung von relays und URLs. Das signierte Release 0.1.0 führte den Offline-First-Aufgabenmanager ein, dessen optionale Synchronisierungsschicht mit NIP-44 (Verschlüsselte Nutzdaten) verschlüsselte Datensätze auf vom Nutzer ausgewählte relays schreibt. Kairos verwendet deterministische Aufgabenkoordinaten und verschlüsselte Tombstones mit Löschanfragen nach NIP-09 (Anfrage zur event-Löschung), während rein lokale Aufgaben das Gerät nie verlassen.

Bray 2.3.0 erweitert sein CLI um allgemeines Gift Wrapping und eine lokale Blossom-Testoberfläche

Bray 2.3.0, ein Nostr-SDK und Kommandozeilen-Werkzeugpaket, kann beliebige events über NIP-59 (Gift Wrap) verpacken und auspacken, wobei das Signieren über NIP-46 (Nostr Connect) geleitet wird, wenn ein Bunker den Schlüssel verwahrt. PR #75 versieht außerdem das mitgelieferte Test-relay mit Herausforderungen nach NIP-42 (Authentifizierung von Clients bei relays) und stellt die verbleibenden Blossom-Client-Befehle bereit. PR #77 ergänzt einen speicherinternen BUD-01/02-Server, dessen signierte Autorisierung jeden Upload oder jede Löschung an genau einen Blob bindet, während PR #76 benannte event-kinds, Kurzformen für tags und Flags für den ID-Abgleich nach NIP-77 ergänzt, damit events, die ein Aufrufer bereits besitzt, nicht erneut heruntergeladen werden.

Buzz Desktop 0.5.0 verschärft Einladungen, Suche und Aktualisierungen der relay-Identität

Nach der Berichterstattung der vergangenen Woche über den Workspace von Armada und Buzz ergänzt Buzz Desktop 0.5.0 Einladungslinks mit begrenzter Nutzungszahl (PR #3141) und Suchfilter für Autor, Kanal und Zeitgrenzen (PR #2871). PR #2862 ruft Beitrittsrichtlinien über die native Netzwerkschicht der Desktop-App ab, und PR #2607 veröffentlicht den Identitätsdatensatz eines Agenten erneut, nachdem die Umbenennung einer Persona das relay erreicht hat. Das Release aktualisiert außerdem seine Nostr-Abhängigkeit wegen eines Hinweises auf Remote-Denial-of-Service in NIP-44 und korrigiert die Wiederherstellung des lokalen Speichers, die Positionierung in Threads, die Wiederverbindung zu relays sowie Laufzeitpfade unter Linux und Windows.

Shosho 1.0.0 erweitert seinen Marktplatz für Livestreams

Shosho 1.0.0 gestaltet den Marktplatz für Livestreams rund um Kreative, Live-Sitzungen, Clips und Produkte neu, die Nutzer über eine konfigurierbare relay-Suche finden können. Ein einheitlicher Benachrichtigungs-Feed sammelt nun Erwähnungen, Reaktionen, Reposts und zaps und unterstützt Antworten, ohne den Feed zu verlassen. Zuschauer können Clips aus Livestreams oder Wiederholungen veröffentlichen; außerdem verbessert das Release Thread-Chats, Antworten auf Clips, das Laden von Profilen und die Netzwerknutzung.

Mafrend v1.0 gibt einen Ausblick auf ortsbezogene Nostr-Chats unter Android

Mafrend v1.0 ist die erste öffentliche Android-Alpha einer geplanten App für ortsbezogene Nostr-Chats. Die Projektseite bezeichnet den Funktionsumfang als noch in aktiver Entwicklung und beschreibt jeden Kartenort als eigenen Chatraum für Gespräche rund um einen Ort. Ein öffentliches Release-Repository enthält das installierbare Zapstore-Paket, während die Haupt-App privat bleibt.

Hanami 0.1.0 bietet Blossom-Servern einen durch Signer vermittelten Android-Zugang

Hanami 0.1.0, eine Android-Begleit-App für Blossom-Server, ermöglicht Anmeldung, Upload und Download per Smartphone. Die App verwendet NIP-55 (Android-Signer-Anwendung) für ein Signieren mit Bestätigung und einen nativen Handshake nach NIP-98 (HTTP-Authentifizierung) für die Serversitzung. Hanami beschränkt seine Web-Shell und Signierbrücke auf den Ursprung des ausgewählten Servers, sodass die Zugangsdaten beim Signer verbleiben, während die bestehende Weboberfläche des Servers das Nutzungserlebnis bereitstellt. Das erste öffentliche Release erfordert Android 8 oder neuer, einen erreichbaren Hanami-Server und eine kompatible Signer-App.

Cordn startet seinen Gruppenchat mit Nostr-Identität unter Android

Cordn, ein Client für private Gruppennachrichten, bietet Android-Nutzern nun einen Einstieg mit Nostr-Identität, Profilverknüpfungen über NIP-05 (Zuordnung von Nostr-Schlüsseln zu DNS-basierten Internetkennungen) und verifizierte Links, die Cordn-Ziele in der App öffnen. Das am 24. Juli veröffentlichte Release 0.2.1 führt diese native Produktlinie neben dem bestehenden Webclient ein. Nachrichten verwenden MLS, ein Protokoll zur Gruppenverschlüsselung, mit durch einen Koordinator unterstützter Zustellung, sodass Gruppen geordnete verschlüsselte Unterhaltungen behalten, ohne eine E-Mail-Adresse oder Telefonnummer zu benötigen.

Nostur 1.30.1 korrigiert Threads und doppelte Beiträge, nachdem 1.30.0 die Freigabefunktionen erweitert hatte

Nostur 1.30.1, ein Nostr-Client für iPhone, iPad und Mac, lässt Nutzer durch verschachtelte Antwort-Threads navigieren, ohne dass die Fehler beim Auf- und Zuklappen auftreten, die das neue Layout beeinträchtigt hatten. Es verhindert außerdem, dass derselbe Entwurf zweimal veröffentlicht wird, auch wenn Callbacks beim Medien-Upload wiederholt eintreffen. Das Release folgt auf 1.30.0, das verschwindende Direktnachrichten und einen Weg über das Teilen-Menü ergänzt hatte, um Medien an Nostr zu senden. Damit verbindet die App neue Wege für Nachrichten und Veröffentlichungen mit Korrekturen an den alltäglichen Abläufen für Threads und Beiträge.

Formstr Drive 0.0.2 verbindet Nostr-Dateimetadaten mit Blossom-Blobs

Formstr Drive 0.0.2, ein Nostr-nativer Dateimanager, bietet Nutzern Vorschauen in der App und die Option, Office-Dokumente in Nostr Docs zu öffnen. Im Hintergrund speichert er große Dateien als in Stücke aufgeteilte Blossom-Blobs und löscht den entfernten Blob, wenn ein Nutzer eine Datei entfernt. Ein lokales relay hält die Nostr-Metadaten der App in unmittelbarer Nähe, während Blossom die Dateidaten verwahrt. Dies trennt die Dateiorganisation von den großen Datenmengen selbst.

NoorNote 1.3.1

NoorNote 1.3.1, ein Nostr-Client für Web, Desktop und Android, ergänzt Timer für verschwindende Nachrichten und konfiguriert funktionierende Standard-DM-relays für neu erstellte Konten. Es filtert globale Artikel ohne Titelbild und leitet Repost-Benachrichtigungen in die Artikelansicht. Das vorherige Release 1.3.0 ergänzte Karten für NIP-53 (Live-Aktivitäten), Personen-tags für NIP-68 (Bildorientierte Feeds), einen Soft Mute über NIP-78 (Anwendungsdaten) und einen relay-seen-Status für Notizen.

algia 0.0.133

algia 0.0.133, ein Go-Kommandozeilen-Client für Nostr, folgt auf 0.0.132, das Auflistung, Timelines, Beiträge, Reaktionen, Löschungen sowie Beitritts- und Austrittsabläufe für NIP-29 (relay-basierte Gruppen) ergänzte. Dasselbe Release fügte eine Vorabauthentifizierung nach NIP-42 (Authentifizierung von Clients bei relays) für relays hinzu, die dies laut Konfiguration erfordern. Version 0.0.133 ergänzte anschließend die Befehle für reguläre, Kanal- und Gruppenbeiträge um Uploads lokaler Bilder und hängt die resultierenden URLs sowie tags nach NIP-92 (Medienanhänge) an jedes event an. Auch reine Bildbeiträge funktionieren, und Gruppenbeiträge verwenden standardmäßig den Medienspeicher des Gruppen-relay, während andere Beiträge konfigurierte Dateiserver nutzen.

swift-nostr 0.7.0

Für Swift-Anwendungen ermöglicht swift-nostr 0.7.0, eine Nostr-Bibliothek für Apple-Plattformen, dass ein NIP-46-Remote-Signer über ihre Signierabstraktion sämtliche Client-Funktionen bedient. Das Release ergänzt Unterstützung für NIP-98 (HTTP-Authentifizierung) und NIP-29 (relay-basierte Gruppen), einschließlich Abläufen für Gruppenbeitritt, Beiträge und Moderation. Es validiert außerdem das Padding von NIP-44 (Verschlüsselte Nutzdaten, versioniert) anhand der offiziellen Vektoren und weist Nutzdaten zurück, die einen gültigen MAC für nicht kanonisches Padding enthalten.

lawallet-nwc 2.0.0

LaWallet NWC 2.0.0, ein mit Nostr verbundenes Wallet und ein Dienst für NIP-47 (Nostr Wallet Connect), ergänzt eine Passkey-Anmeldung, die den Nostr-Signierschlüssel im Browser mit der WebAuthn-PRF-Erweiterung ableitet. Der Server erhält dieses Geheimnis nie, und derselbe Passkey kann denselben Schlüssel auf einem anderen synchronisierten Gerät wiederherstellen. Konten können nun mehrere Nostr-pubkeys verknüpfen und zusammenführen, während der optionale Listener-Dienst Wallet-Connect-events weiterleitet und die Webhook-Zustellung nach einem nicht erreichbaren Endpunkt erneut versucht.

MDK 0.9.10

MDK 0.9.10, die Rust-Implementierung des Marmot-Protokolls, bewahrt ausstehende Sendevorgänge, solange ein Transport inaktiv ist, und überwacht die Weiterleitung von relay-Benachrichtigungen, sodass die eingehende Zustellung nach Verzögerung, Panic oder Schließung wiederhergestellt wird. PR #1159 ergänzt einen dauerhaften, paginierten Gesprächsverlauf und den vollständigen Antwortkontext für lokale Agenten, und PR #1167 veröffentlicht das aktuelle signierte KeyPackage-event erneut, statt einen Ersatz zu erzeugen. Das Release bewahrt außerdem die manuelle Chat-Reihenfolge, unterstützt die endgültige Auflösung von Gruppen und erweitert die nach Web of Trust gewichtete Suche, relay-Richtlinien-APIs und Sprachbindungen.

pakstr 0.3.1

pakstr 0.3.1 ermöglicht Webteams, die einen Nostr-Client für Android paketieren, Laufzeitkonfiguration und einen API-Proxy bereitzustellen, ohne die App-Shell neu zu bauen. Seine Release-Serie vom selben Tag ergänzte eine Amber-Signer-Brücke, Ver- und Entschlüsselung nach NIP-44 (verschlüsselte Nutzdaten) und korrigierte die Einfügung von Android-Berechtigungen vor der Arbeit an der Laufzeitkonfiguration in 0.3.x. Das Grundgerüst hält gebündelte Web-Assets lokal, während bereitstellungsspezifische Einstellungen zur Laufzeit bereitgestellt werden, und der Proxy bietet der verpackten App einen kontrollierten Weg für API-Anfragen neben ihren gewöhnlichen relay-Verbindungen.

Ditto 2.34.2

Ditto 2.34.2, ein anpassbarer sozialer Nostr-Client, stellt Nutzerstatus als Karten in Feeds, Detailseiten und eingebetteten Zitaten dar, einschließlich benutzerdefinierter Emojis, Ablaufzeit und optionaler Linkvorschau. Zaps mit Kommentaren erscheinen nun als Antworten unter dem referenzierten Beitrag. Das Release behält außerdem den optionalen Globus-Button auf Profilen aus 2.34.1 für Betreiber bei, die eine Stamm-Website nach NIP-5A (Website-Manifest) veröffentlichen, und korrigiert die Navigation auf der Startseite, die Livestream-Suche, die Behandlung externer Links und fehlerhafte benutzerdefinierte Emojis.

Earthly 0.0.9

Earthly 0.0.9, ein kollaborativer, auf Nostr aufgebauter Karteneditor, hält Likes nun sichtbar, wenn sich die Seitenleiste eines Kartenobjekts schließt, erneut öffnet oder aktualisiert. Sein Ablauf für NIP-57 (Lightning-zaps) sendet gültiges JSON für zap-Anfragen, damit Lightning-Anbieter verifizierte Belege über öffentlich erreichbare relays veröffentlichen können, auch während der lokalen Entwicklung. Erzeugte Rechnungen bleiben beim Wechsel zwischen Objektansichten sichtbar, und die App zeigt eine Bestätigung, sobald ein verifizierter Beleg eintrifft.

In Entwicklung

Keep ergänzt kind-bezogenes Signieren mit NIP-44 v3 und verschärft die Bestätigungsrichtlinie

Keep hat fünf Änderungen am Android-Signer gemergt, die Anfragen zur Ver- und Entschlüsselung mit NIP-44 (Verschlüsselte Nutzdaten) v3 sowohl durch die Transporte nach NIP-55 (Android-Signer-Anwendung) als auch durch seinen NIP-46 (Nostr Connect)-Bunker leiten. PRs #451, #452 und #453 halten Freigaben für v3 von v2 getrennt, begrenzen sie nach event-kind, weisen fehlende oder ungültige kinds zurück und bewahren Bestätigungsanfragen, die aus Benachrichtigungen geöffnet wurden. PRs #454 und #455 behandeln die Basic-Signierrichtlinie nicht mehr als Auto und verschieben die globale Auswahl in den verschlüsselten Speicher des Kerns. Die Maintainer von Keep mergten alle fünf Änderungen nach dem jüngsten getaggten Android-Release.

Routstrd ändert nach einer nicht authentifizierten Offenlegung seine standardmäßige Netzwerkbindung

Routstrd PR #56 ändert die standardmäßige Bind-Adresse des lokalen Nostr-Inferenzrouters von allen Netzwerkschnittstellen zu 127.0.0.1. Der frühere Standard machte Endpunkte für Wallet-Guthaben, Verlauf, Zugriff, Senden, Rückerstattung, API-Schlüssel, Anbieter, Client, Nutzung und Daemon-Stopp ohne Authentifizierung für jeden Host zugänglich, der den Port erreichen konnte. Betreiber können weiterhin ausdrücklich eine nicht lokale Bindung konfigurieren, aber die gemergte Änderung beschränkt eine neue Bereitstellung standardmäßig auf den lokalen Rechner und ist noch nicht in einem Release mit Versions-Tag erschienen.

Imwald Android verdeutlicht den Status von Offline-Veröffentlichungen

Imwald Android, ein Android-Nostr-Client, behandelt die Bestätigung eines lokalen relay nun nur dann als abgeschlossene Veröffentlichung, wenn jedes konfigurierte Ziel lokal ist. Seine Korrektur für Offline-Veröffentlichung und Outbox lässt die Remote-Zustellung ausstehend, wenn ein lokales relay das event angenommen hat, die konfigurierten entfernten relays jedoch noch nicht. Dadurch unterscheidet der Veröffentlichungsbericht zwischen der gerätelokalen Speicherung und der Zustellung an relays.

FIPS ergänzt eine OpenWrt-Zugriffsschicht; eine Portierung auf FreeBSD wird weiterhin geprüft

Das Nostr-native Free Internetworking Peering System ermöglicht einem OpenWrt-Router nun über den gemergten PR #126, ein offenes !FIPS-Zugangsnetzwerk bereitzustellen. Der parallele, weiterhin offene FreeBSD-PR #129 schlägt die Portierung des Daemons, des TUN-Datenpfads, der Namensauflösung für .fips, der Dienstverwaltung und des nativen Paketbaus vor. Der OpenWrt-Merge erweitert den Zugriff bereits heute, während die FreeBSD-Arbeit ihn auf ein weiteres universelles Betriebssystem ausdehnen würde.

Ein FIPS-Projektupdate vom 26. Juli meldete mehr als 300 Knoten in seinem öffentlichen UDP-Overlay und ein breiteres Mesh, das sich 2.000 Knoten nähert. Das FIPS-Repository härtete in derselben Woche parallele Netzwerktests, die Kontinuität beim Schlüsseltausch, das Verhalten von Hop-Limits, Firewall-Prüfungen und die Isolation des NAT-Labors. Die Arbeit am Repository stellt Betreibern reproduzierbare Prüfungen für diese Verhaltensweisen bereit, während das Netzwerk wächst.

Zap Cooking plant Beiträge und bindet Scanner-Anfragen

Zap Cooking, eine Nostr-App zum Teilen von Rezepten und Planen von Mahlzeiten, kann einen geplanten Beitrag nun im verschlüsselten Speicher halten und ihn bei Fälligkeit über eine periodische Abfrage von relays veröffentlichen (PR #566, PR #569). So erhalten Nutzer einen Weg zur geplanten Veröffentlichung, ohne unsignierte Beitragsinhalte in der Datenbank des Schedulers offenzulegen.

Der Kühlschrankscanner authentifiziert nun den genauen Anfragekörper mit HTTP-Authentifizierung nach NIP-98, sodass Mitgliedschaftsprüfungen auf dem Schlüssel beruhen, der die Scananfrage signiert hat, und nicht auf einem im Anfragekörper angegebenen pubkey (PR #599).

Citrine macht ein Android-Gerät zu einem verwaltbaren relay

Citrine, ein auf Android gehostetes Nostr-relay, kann gespeicherte events nun an externe relays senden und bietet Betreibern damit eine Möglichkeit, den lokalen Verlauf erneut zu übertragen (PR #179). Es ergänzt außerdem Befehle nach NIP-86 (relay-Verwaltungs-API), damit kompatible Clients das relay verwalten können (PR #150).

Gruppenbetreiber können relay-basierte Gruppen nach NIP-29 per Amber-Signatur in PR #178 verwalten, während PR #174 die Tor-gestützte relay-Konfiguration und den Lebenszykluszustand über Neustarts hinweg im Einklang hält.

Wired stellt vollständige Unterhaltungen im Browser wieder her

Wired, ein browserbasierter Nostr-Client, verfolgt Feed-Wurzeln, Antworten und referenzierte events nun bis zum Abschluss, anstatt bei festen Grenzwerten für Suchbreite oder Ergebniszahl anzuhalten (PR #148, PR #147, PR #146). Nutzer können dadurch tiefere Threads und Feed-Kontext wiederherstellen, wenn die relevanten events über ihre relays verfügbar sind.

Der Browser bewahrt außerdem relay-Hinweise an referenzierten events und verwendet sie nur für weiterhin fehlenden Kontext. Damit stellt er Unterhaltungen wieder her, die konfigurierte relays nicht enthalten (PR #145, PR #144). Ein unvollständiger Abruf bleibt von einem abgeschlossenen Snapshot getrennt, sodass eine Teilantwort die vorherige zwischengespeicherte Ansicht nicht überschreibt.

Protokoll- und Spezifikationsarbeit

NIPs: Hosting-Grenze von NIP-34, Gruppenmigration und drei aktive Entwürfe

In dieser Woche wurden zwei Spezifikationsänderungen gemergt. NIP-34-Commit 6d2979b entfernt GRASP-Hosting-Anweisungen aus der Pull-Request-Beschreibung für kind:1618, sodass Hosting- und Fallback-Verhalten außerhalb des event-Vertrags bleiben. NIP-29-Commit db5fe3d definiert, wie Metadaten von relay-Gruppen zu einem anderen relay migrieren und wie Clients einen gültigen Umzug von einem unabhängig fortbestehenden Fork unterscheiden.

PR #2424 schlägt gegenseitige Deklarationen von Schlüsselsätzen mit kind:10045 vor. Das Erfordernis der Gegenseitigkeit würde verhindern, dass eine Identität einseitig einen anderen Schlüssel zuordnet. PR #2421 schlägt BOLT12-zap-Absichten und Zahlernachweise vor, die Clients anhand von Ziel, Betrag, Angebot und abgeschlossener Zahlung validieren können, ohne von einem vom Empfänger betriebenen Belegserver abhängig zu sein.

PR #2425 würde NIP-B0-Lesezeichen erlauben, neben Web-URLs auch Nicht-HTTP-Schemata wie nostr: beizubehalten. Dadurch blieben native Nostr-Kennungen, Zahlungsanfragen und andere Anwendungsschemata in denselben privaten oder öffentlichen Lesezeichenlisten erhalten, die bereits Webadressen enthalten.

Mill implementiert einen Entwurf zur Schlüsselsicherung über Cloud-Konten

Mill kündigte einen implementierten Entwurf zur Schlüsselsicherung über Cloud-Konten an, der die Kennung eines Google-OIDC-Kontos mit einer Passphrase hoher Entropie kombiniert, um einen temporären Sicherungsschlüssel abzuleiten. Seine Referenzimplementierung verschlüsselt den echten Schlüssel des Nutzers als ncryptsec nach NIP-49 (Verschlüsselung privater Schlüssel) und speichert ihn anschließend in einem vorläufigen, parametrisiert ersetzbaren event mit kind 30049 auf konfigurierten relays. Das Projekt hat den Sicherungsablauf in main gemergt, doch kein Release nach v1.0.0 enthält ihn, und der Sicherungsablauf bleibt deaktiviert, sofern ein Betreiber keine eigenen backupRelays angibt. Ein versionierter relay-Satz bleibt vorläufig, und der Entwurf warnt davor, dass veröffentlichter Geheimtext für Offline-Versuche zum Erraten der Passphrase verfügbar bleibt. Leser sollten das Design als implementiertes Experiment behandeln, das von einer Passphrase hoher Entropie abhängt.

BUDs: Blossom-Server können unbekannte Uploads anhand ihrer Bytes identifizieren

BUD-02 PR #110 schlägt vor, eine serverseitige MIME-Erkennung zu empfehlen, wenn ein Uploader Content-Type auslässt oder application/octet-stream sendet. Ein Blossom-Server würde die ersten Bytes mit einer gepflegten Bibliothek zur Dateityperkennung untersuchen, einen spezifischen vom Client angegebenen Typ beibehalten und auf den generischen Binärtyp zurückfallen, wenn die Erkennung scheitert. Damit blieben Bilder, Audio-, Video- und von Agenten erzeugte Dateien darstellbar, ohne Byte-Sniffing für jeden Upload vorzuschreiben.

NAPs: Konventionen ersetzen nummerierte Reihen, während sich Verträge für Aufnahme und Dateisystem entwickeln

PR #87 entfernt die nummerierte, Napplet-übergreifende Protokollreihe und hält Laufzeitfunktionen unter benannten Verträgen, während sich Anwendungsnachrichten auf Konventions-URIs nach dem Muster napplet:<archetype>/<intent> zubewegen. Die gemergte Änderung der Themenidentität trennt einen stabilen Konventionspfad ohne Query-Parameter von Nutzdaten einzelner Nachrichten, und PR #90 wendet diese Transpositionsregel auf Erkennungs- und Handler-Metadaten an.

Zwei NAP-Entwürfe erweitern die Vertrauensgrenze der Shell. NAP-CAPTURE PR #94 hält die Zustimmung zur Mikrofonnutzung, Plattformberechtigung, Grenzen, Aufbewahrung und Beendigung in der Laufzeitumgebung, während ein begrenztes Medienartefakt an ein Napplet in einer Sandbox zurückgegeben wird. NAP-FS PR #88 ist der parallele Vorschlag für ein virtuelles Dateisystem mit richtliniengebundenen Handles anstelle uneingeschränkter Host-Pfade.

Marmot: Die Spezifikation definiert einen endgültigen Gruppenzustand

Marmot PR #409 ergänzt einen authentifizierten, unumkehrbaren Zustand Disbanded, da MLS selbst keine Operation zur Gruppenlöschung besitzt. Ein autorisierter Admin-Commit verschiebt eine Gruppe aus Active, verhindert ihre Wiederbelebung durch alte Zweige, Nachrichten und Welcomes und bietet bestehenden Gruppen einen ausdrücklichen Kompatibilitätspfad, bevor sie sich auflösen können. Die vorangegangene Überarbeitung von Spezifikations-Issues brachte außerdem die Autorität über Gruppenzustände, Konvergenz, Key Packages, Bestätigungen, Medienregeln, Registry-Sprache und 200 erfasste Spezifikations-Issues in Einklang.

Gamma Markets: Keine öffentlichen Spezifikationsänderungen veröffentlicht

Das Spezifikations-Repository von Gamma Markets verzeichnete vom 21. bis zum 28. Juli keine öffentlichen Commits oder Pull-Request-Aktivitäten. Seine veröffentlichten Dokumente zu Aufträgen, Abwicklung und Marktdaten bleiben die aktuelle Grundlage; dieser Eintrag ohne Änderungen hält Gamma in der wöchentlichen Spezifikationsübersicht sichtbar.

Concord: Lese- und Schreibfunktionen könnten innerhalb einer Plane getrennt werden

Concord PR #12 bleibt ein offener Entwurf für Planes, in denen nicht alle Leser auch schreiben dürfen. Er entwickelt die Control Plane in Richtung getrennter Berechtigungen für Lese- und Schreib-Streams weiter und skizziert Kanäle mit eingeschränktem Schreibzugriff, Einladungen und Bereiche für die Schlüsselneuvergabe. Der Schreibschlüssel dient im Entwurf als Spam-Schranke, während signierte innere Akteure und Prüfungen der Mitgliederliste weiterhin Autorität vermitteln.

NWC: Eine Wallet-Methode kann zwischen BOLT11 und BOLT12 wählen

NWC PR #2 schlägt optionale Methoden pay und receive für BIP-321-Zahlungs-URIs vor. Ein Wallet-Dienst kann Unterstützung ankündigen, eine kompatible BOLT11-Rechnung oder ein BOLT12-Angebot aus einem URI auswählen, vor der Zahlung ein abweichendes Bitcoin-Netzwerk zurückweisen und melden, welchen Anweisungstyp er verwendet hat. Der Vorschlag bleibt außerhalb des NWC-Kerns, sodass Wallets ohne Unterstützung für BIP-321 oder BOLT12 ihn nicht implementieren müssen.

Sechs Jahre Nostr im Juli

Diese Juli-Chronik verfolgt wiederkehrende Probleme von Nostr: lesbare Kennungen, relay-Filterung, portable Anwendungsdaten, Datenschutz und Interoperabilität. Über sechs Jahre hinweg verwandelt jede Schicht eine punktuelle Korrektur in gemeinsam genutzte Infrastruktur: Namen werden zu Profilen, Filter zu Anwendungsverträgen, und der über relays transportierte Zustand weitet sich von Notizen auf Live-Räume und Gruppen aus. Sie beginnt mit der ersten Implementierung von NIP-05 und endet mit dem Merge dieses Monats zur adressierbaren Erkennung. Anschließend untersucht sie die Änderungen im Juli, die diese Themen weiterentwickelt haben.

Juli 2021

Am 19. Juli 2021 ergänzte der nostr-tools-Commit 1ce00bd ein Modul nip05.js und hob das Paket auf Version 0.5.0 an. Seine Funktion keyFromDomain erzeugte eine DNS-TXT-Anfrage für _nostrkey.<domain>, sendete die binäre Anfrage an einen von acht rotierenden DNS-over-HTTPS-Anbietern und gab den ersten Schlüssel in der Antwort zurück. Ein Browser-Client konnte dadurch eine von Menschen kontrollierte Domain einem öffentlichen Schlüssel zuordnen, ohne einen DNS-Resolver zu betreiben oder von einem fest eingestellten Anbieter abhängig zu sein.

Dieser erste Ansatz löste die Zuordnung eines Schlüssels, unterstützte jedoch keine Namen innerhalb einer Domain, und seine Vertrauensgrenze lag im DNS sowie beim ausgewählten Resolver. Die moderne NIP-05-Spezifikation verlagerte die Erkennung zu /.well-known/nostr.json, wo eine Domain lokale Namen pubkeys zuordnet und relay-Hinweise anfügen kann. Der Code von 2021 dokumentiert den früheren Gestaltungsdruck: Öffentliche Schlüssel waren portabel, doch Menschen benötigten weiterhin Kennungen, die sie lesen, verifizieren und zwischen Clients übertragen konnten.

Juli 2022

Am 10. Juli beschränkte der NIP-12-Commit 3771186 generische relay-Anfragen auf tags mit einem einzelnen Buchstaben. Diese Entscheidung machte Filter wie #r, #g und #t für URL-Verweise, Geohashes und Hashtags nützlich, ohne relays aufzufordern, jeden beliebigen Metadatenschlüssel zu indizieren. Zehn Tage später nutzte der erste NIP-20-Entwurf für Webkommentare dieses Abfragemodell direkt: Ein Kommentar mit kind 34 enthielt eine normalisierte Webseiten-URL in einem r-tag, sodass eine Website und unabhängige Clients dieselbe Diskussion aus relays abrufen konnten.

Es folgten relay-Richtlinien und soziale Rückmeldungen. Der ursprüngliche NIP-22-Commit erlaubte relays, events zurückzuweisen, deren Zeitstempel created_at unplausibel alt war, und Commit 8bef0e9 nahm zukünftige Zeitstempel in dieselbe Richtlinie auf. Am 30. Juli definierte der NIP-25-Commit dcbd504 Reaktionen mit kind 7 und Ziel-tags e und p; der nächste Commit wies - einer negativen Reaktion zu, und Commit 6903ff5 machte + zum ausdrücklichen allgemeinen Like. Zusammen spezifizierten diese Commits die Zurückweisung von relay-Zeitstempeln, den Abruf anhand von tags, Webkommentare und Reaktions-tags für Clients, die diese Entwürfe übernahmen.

Juli 2023

Im Juli 2023 ging die Koordination über kurze Notizen hinaus. Der NIP-37-Entwurf für verlorene Schlüssel untersuchte die unumkehrbare Stilllegung von Schlüsseln, Schwellenwerte für soziale Wiederherstellung und vorab festgelegte Ersatzschlüssel, lehnte es aber ausdrücklich ab, das Ergebnis als universelle Schlüsselrotation zu bezeichnen. Fünf Tage später führte NIP-53 adressierbare Live-Aktivitäten mit kind 30311 und Chatnachrichten mit kind 1311 ein und gab Streams, Bühnen und Live-Räumen ein gemeinsames event-Modell für Hosts, Teilnehmer, Status und Unterhaltung.

Anwendungen begannen außerdem, Arbeit und Handel anzukündigen. Der erste Data-Vending-Machine-Entwurf beschrieb Auftragsanfragen mit kind 68001, Ergebnisse mit kind 68002, Gebote, Ablaufzeiten, Verkettung und konkurrierende Anbieter für Aufgaben wie Transkription, Zusammenfassung und Übersetzung. Am 13. Juli ergänzte der Entwurf für Kleinanzeigen adressierbare Angebote mit kind 30402 und Metadaten für Titel, Zusammenfassung, Preis, Ort und Status. Diese Entwürfe wurden später zu NIP-90 und NIP-99, doch bereits ihre Fassungen vom Juli trennten eine Anfrage oder Anzeige vom Server, der sie darstellte.

Auch das Zahlungsrouting wurde kombinierbar. Der NIP-57-Merge für zap-Aufteilungen vom 31. Juli änderte ein einzelnes zap-Ziel in eine gewichtete Liste aus pubkeys von Empfängern und relay-Hinweisen. Ein Client konnte einen zap auf Mitwirkende aufteilen, Empfänger ohne Gewichtung auslassen, wenn Gewichtungen vorhanden waren, und die Aufteilung vor der Zahlung anzeigen. Die Änderung standardisierte eine Darstellung durch signierte events für gewichtete zap-Empfänger und relay-Hinweise, sodass kompatible Clients die Aufteilung vor der Zahlung darstellen konnten.

Juli 2024

Am 4. Juli ergänzte der NIP-29-Commit c60ca88 die relay-Moderationsaktion kind:9007 zum Erstellen einer Gruppe. Sechs Tage später definierte NIP-70 geschützte events: Ein --tag weist ein relay an, die Veröffentlichung nur vom authentifizierten Autor des event anzunehmen. Eine Änderung gab relays einen ausdrücklichen Übergang des Gruppenzustands; die andere erlaubte Autoren, Dritte daran zu hindern, ansonsten gültige signierte events erneut in relays einzuspielen.

Am 16. Juli führte ein Commit zur Cashu-Spezifikation sowohl NIP-60-Wallets als auch NIP-61-nutzaps ein. NIP-60 legte Wallet-Metadaten in kind 37375, nicht ausgegebene Nachweise in verschlüsselten events mit kind 7375 und einen optionalen Transaktionsverlauf in kind 7376 ab. NIP-61 verband die Präferenzen des Empfängers für Mint und relays aus kind 10019 mit durch P2PK gesperrten nutzaps mit kind 7337. Wallet-Zustand und Inhabertoken konnten nun durch relays übertragen werden, während die Einlösung weiterhin von Nachweisen der Cashu-Mint und der sorgfältigen Verhinderung doppelter Ansprüche abhing.

Zwei Änderungen Ende Juli präzisierten den deterministischen Zustand. NIP-01-Commit 9c54549 schrieb event-IDs als Entscheidungskriterium nach gleichen created_at-Zeitstempeln vor, sodass Clients identische Ergebnismengen auf dieselbe Weise sortieren konnten. Der NIP-09-Merge zur Löschung stellte klar, dass Anfragen mit kind 5 auf event-IDs oder adressierbare Koordinaten zielen dürfen und k-tags enthalten sollten, welche die kinds angeben, die relays löschen sollen. Beide Änderungen verringerten die Stellen, an denen zwei korrekte Implementierungen andernfalls zu unterschiedlichen Ergebnissen kommen konnten.

Juli 2025

Die Ecash-Erkennung erhielt am 16. Juli ein eigenes soziales Verzeichnis. NIP-87-Commit 1afb6da definierte Cashu-Mint-Datensätze mit kind 38172, Fedimint-Datensätze mit kind 38173 und Empfehlungen mit kind 38000, die mit relay-Hinweisen auf diese Datensätze verweisen können. Wallets konnten Empfehlungen vertrauenswürdiger Autoren abfragen, bevor sie sich mit einer Mint verbanden, während die Spezifikation davor warnte, dass ungefilterte globale Erkennung Nutzer zu böswilligen Betreibern lenken könnte.

Eine Woche später spezifizierte ein Entwurf portable Nostr-event-Datensätze für Sprachnachrichten. Der erste NIP-A0-Commit wies dem Root-event einer Sprachnachricht kind 1222 und einer Antwort kind 1244 zu; beide enthielten eine Audio-URL zusammen mit Medienmetadaten. Die Formataktualisierung vom 27. Juli empfahl Opus in einem Ogg-Container und standardisierte eine komprimierte Wellenform. Clients konnten kurze Audiodateien austauschen, ohne sich auf ein einziges Aufnahmeprogramm, einen einzigen Host oder eine Darstellung der Wellenform zu einigen.

Private Nachrichten und Wallet-Verbindungen ergänzten danach Protokollzustände für Lesefortschritt, Verschlüsselungsauswahl und Zahlungsfortschritt. NIP-17-Commit 3d76da3 definierte einen ersetzbaren Datensatz mit kind 30016, dessen geordnete seen-tags einem Client erlauben, zwischen gelesenen Nachrichten und Lücken zu unterscheiden, die auf möglicherweise verpasste Nachrichten hinweisen. Am 31. Juli ermöglichte die Aushandlung der Verschlüsselung in NIP-47 Wallet-Diensten, NIP-44 v2 oder das ältere NIP-04 anzukündigen, während der Commit zum Transaktionszustand die Zustände pending, settled, accepted, expired und failed ergänzte. Zustellung, Verschlüsselung und Zahlungsfortschritt wurden zu ausdrücklichen Protokolldaten statt lokaler Schlussfolgerungen.

Juli 2026

Dieser Juli begann damit, gewöhnliche Webadressen mit relay-Anfragen zu verbinden. Der Commit 2f4b093 zur adressierbaren Erkennung definiert eine Abfrage unter /.well-known/nostr.json?ad=<path>, deren Antwort einen Nostr-Filter und eine relay-Liste enthält. Ein normaler Browser kann die ursprüngliche URL weiterhin als HTML öffnen, während ein Nostr-Client den entsprechenden Endpunkt /.well-known/nostr.json?ad=<path> nach einem Filter und einer relay-Liste abfragen kann, die die Adresse einer Gruppe, einer nsite, einem Feed, einem event oder einem anderen nativen Objekt zuordnen. Das Muster greift das Problem von 2021 zur Zuordnung einer Domain zu einem Schlüssel auf einer breiteren Ebene erneut auf: Eine einzelne menschenlesbare URL kann nun sowohl eine Identität als auch eine Abfrage bezeichnen.

NIP-29 entwickelte sich anschließend von flachen relay-Gruppen zu strukturierten Räumen. Der Untergruppen-Commit vom 16. Juli ergänzte Beziehungen zu übergeordneten Gruppen und geordneten Untergruppen; benachbarte Commits ergänzten Suffixe für Einladungscodes, Banner, geordnete Pin-Snapshots und Pins für adressierbare events. Am 22. Juli definierte die Klarstellung zu Migration und Fork, wann Metadaten eine Gruppe rechtmäßig zu einem anderen relay verschieben und wann ein weiterhin aktiver Zweig einen unabhängigen Fork bildet. Die Gruppenkennung blieb einfach, während Hierarchie, Darstellung und relay-Änderungen als ausdrücklicher Zustand abgebildet wurden.

Zwei kleinere Änderungen verdeutlichten die Grenzen der Implementierung. NIP-46-Commit f0af204 verlangt von einem Remote-Signer, bei unbekannten oder nicht unterstützten Methoden einen Fehler zurückzugeben, statt einen Client ohne Antwort in ein Timeout laufen zu lassen. NIP-34-Commit 6d2979b entfernt GRASP-spezifische Hosting-Anweisungen aus der Beschreibung des Pull-Request-event. Eine Änderung gibt Aufrufern eine abschließende Antwort; die andere verhindert, dass ein portables Git-event stillschweigend ein einzelnes Serverprotokoll übernimmt.

Sendet eine NIP-17-DM, um ein Projekt oder eine Nachricht über das Projekt Nostr Compass zu teilen.

Nostr Compass #32

Wed, 22 Jul 2026 00:00:00 +0000

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.

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.

Nostr Compass #31

Wed, 15 Jul 2026 00:00:00 +0000

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

Diese Woche: Vector v0.4.0 ersetzt Marmot als Standard-Transport für Group Chats zugunsten von Concord, einem offenen, MIT-lizenzierten Community-Protokoll, das auch von Soapbox’ Armada verwendet wird, und liefert vier Tage später Concord v2 mit einem Slash-Command-Picker für Bots, einem Selbstzerstörungs-Timer und NIP-58-Badges. Amethyst mergt seine eigene Clean-Room-, drahtkompatible Concord-Implementierung in derselben Woche. Sonar spaltet sich von Bitchat ab mit einer plattformübergreifenden Alpha und ist die zitierte Spezifikationsquelle für den Sticker-Pack-Kinds-Vorschlag dieser Woche. Divine Mobile 1.0.16 liefert einen tieferen Video-Editor, At-Rest-Verschlüsselung und ProofMode-Provenienz, die wasserzeichenmarkierte Clip-Downloads überlebt. Bitchat v1.7.0 fügt Live-Push-to-Talk-Sprachübertragung für DMs und signiertes Push-to-Talk auf dem öffentlichen Mesh hinzu. MDK v0.9.4 begrenzt External-Signer-Login und fügt Draft-Persistenz hinzu, während Vector in derselben Woche die Spezifikation für Gruppen-Chat verlässt.

Getaggte Releases bringen n_cord v1.1 mit NSEC-Bunker-Unterstützung, cdk v0.17.3 mit NIP-47-Wallet-Service-Unterstützung über cdk, cdk-nwc und cdk-ffi, Coop Mobile v0.2.4 mit verbessertem Nostr Connect und ncryptsec1-Import, Nmail v0.14.0 auf macOS mit geplantem Senden, Nostrord v2.2.0 mit einem DM-Master-Toggle, Nostr WoT 0.3.86 mit gehärteten Schlüssel-Backups im NIP-49-Format, Keep Android v1.1.8 mit First-Run-FROST-Onboarding, Noscall v0.6.0 mit einem Cashu-Wallet und relay-basierten Push-Benachrichtigungen, Kubo mit Tablet-Modus und Gruppen-Chat-Fotos und Nostr Codex Phone v0.2.9 mit git-, diff- und read-file-Helper-Requests.

Auf der unveröffentlichten Seite lässt Amethyst Accounts Kontakte mit verschlüsselten NIP-85-Karten benennen, über 54 gemergte PRs. Zap Cooking liefert My Kitchen Phase 3 und behebt einen NDK-Pool-Quorum-Bug. Kehto streamt Outbox-Reads vor Abschluss der Relay Discovery. Wired und TAO fügen NIP-57-Creator-Revenue-Sharing hinzu. Conduit Mono baut seinen Händler-Bestelleingang um ephemeres Guest Checkout um. Buzz härtet Channel-Creator-Provisioning über 240 gemergte PRs. Und Nostr Docs übernimmt einen NIP-49-Signer mit Multi-Account und QR-Pairing. Neu getrackt diese Woche: OpenDiscord v1.0.1, Auditable Voting v0.1.140 und Discovery-Pick Cambium v0.3.2, ein schlüsselloser NIP-55-Signer, der an einen Heartwood-Hardware-Companion weiterleitet.

Das NIPs-Repository mergt in der letzten Woche nichts und öffnet sechs Vorschläge: kind:10011 Favorite Follow Sets, ein privates verschlüsseltes Laufwerk als Erweiterung von NIP-4E, NIP-DA permissioned private data sharing, Sticker-Pack-Kinds 10031 und 30031, NIP-29 Message Pinning und eine NIP-66-Relay-Discovery-Umstrukturierung. Der Deep Dive behandelt NIP-99 und die Gamma-Markets-Commerce-Erweiterung.

Leitgeschichten

Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later

Vector ist ein Nostr-Messenger, der auf einem Single-Binary-, datenschutzorientierten Client für DMs und Gruppen-Chats aufbaut. Vector v0.4.0 schreibt die Messaging-Engine der App in eine gemeinsame vector-core-Bibliothek um und ersetzt im selben Release Marmot (MLS-over-Nostr) als Standard-Transport für Group Chats durch Concord, ein Ende-zu-Ende-verschlüsseltes Community-Protokoll; bestehende Marmot-Gruppenverläufe werden nicht übernommen, und die Release Notes empfehlen, alle Marmot-Gruppendaten vor dem Upgrade zu sichern. Vectors eigene Release Notes beschreiben Concord als „our custom messaging protocol", aber die zugrunde liegenden CORD-01- bis CORD-07-Spezifikationen werden separat veröffentlicht, sind MIT-lizenziert und bereits außerhalb von Vector implementiert: Soapbox’ Discord-artiger Client Armada baut sein Communities-Feature auf derselben Concord-Spezifikation auf, und einen Tag später mergte Amethyst seine eigene Clean-Room-, drahtkompatible Concord-Implementierung, die weiter unten vollständig behandelt wird. Dasselbe Vector-Release fügt optionales Tor-Routing für allen Datenverkehr, NIP-46 Remote-Signer-Login per QR oder eingefügter Bunker-URI, mehrere Accounts mit einem In-App-Switcher und benutzerdefinierte Emoji-Packs hinzu, die clientübergreifend geteilt werden. Das Löschen von Nachrichten entfernt eine Nachricht für beide Seiten in DMs und Gruppen-Chats, und Vector behält bewusst den ephemeren Signaturschlüssel, anstatt dem Standard-NIP-17-Löschablauf zu folgen, eine datenschutzmotivierte Abweichung, die das Projekt explizit in den Release Notes hervorhebt. Vier Tage später liefert v0.4.1 Concord v2, das wichtige Datenschutz- und Stabilitätsverbesserungen für Communities bringt, bei gleichzeitiger Kompatibilität bestehender Communities, zusammen mit einem Discord-artigen Slash-Command-Picker für Bots mit typisierten Parametern, einem Pro-Chat-Selbstzerstörungs-Timer und einem NIP-58-Badge-System für Bug Hunter. Der Wechsel weg von Marmot für Gruppen-Chat erfolgt in derselben Woche, in der MDK v0.9.4 unten weiterhin in die Spezifikation investiert.

Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities

Amethyst ist ein funktionsreicher Android- und Multiplattform-Nostr-Client. PR #3566 fügt eine vollständige Implementierung von Concord (CORD-01 bis CORD-07) hinzu, die serverlose, Ende-zu-Ende-verschlüsselte Communities abdeckt: Gift-Wrapped Control-, Chat- und Guestbook-Ebenen über gewöhnliche Relays, vom Eigentümer verwurzelte Rollen- und Ban-Durchsetzung, die jeder Client lokal verifiziert, anstatt einem Server zu vertrauen, und Rekeying zum Ausschluss entfernter Mitglieder. Protokoll- und Krypto-Code liegt in quartz/, State und View Models in commons/, und Screens und Navigation in amethyst/ für Android, mit schlanken CLI-Verben unter cli/; es gibt noch keine Desktop-UI, da die gemeinsame Logik in quartz/commons liegt, damit Desktop sie später übernehmen kann. Die Implementierung ist Clean-Room: aus den öffentlichen CORD-Spezifikationen und beobachteten Wire-Konstanten gebaut, unter Amethysts eigener MIT-Lizenz, getrennt von Armadas AGPL-3.0-Codebasis. Armadas eigene Test-Vector-Werte wurden in Quartz’ Unit-Tests portiert, um zu bestätigen, dass die beiden Clients tatsächlich auf der Leitung interoperieren, was Concord innerhalb von Tagen drei unabhängige Implementierungen gibt: Vector liefert zuerst, Armada als Soapbox’ Referenz-Client, und nun Amethysts Aus-der-Spezifikation-Build.

Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec

Sonar ist ein Bluetooth-Mesh-plus-Nostr-Messenger und Wallet, gewachsen aus Bitchat, mit Marmot-Gruppen-DMs, die mit White Noise interoperieren. Code liegt unter hedwig-corp/bitchat-to-sonar. v0.1-alpha.7 fügt Signal-artiges begrenztes Transcript-Windowing hinzu, damit Open- und Scroll-Performance local-first bleibt, synchronisiert Nearby-Discovery-State über Peers und behebt Blossom-Medien-Uploads, die bei Content-Type und HTTP-Status-Handling fehlschlugen; das vorangehende alpha.6 leerte Live-Marmot-Events für schnellere Chat-Aktualisierung und schloss Android-zu-iOS-Feature-Parity-Lücken über Anrufe, Messaging, Wallet und Push. Sonar ist auch die zitierte Spezifikationsquelle für PR #2410, die Sticker-Pack-Event-Kinds unter der eigenen „Sonar Stickers"-Spezifikation des Projekts registriert, was diesem Launch eine direkte Hub-Verbindung zur Protokollarbeit dieser Woche gibt.

Divine Mobile 1.0.16 ships a deeper video editor, at-rest encryption, and ProofMode provenance

Divine ist ein Kurzvideo-Client, der auf Nostr mit Web-of-Trust-Feed-Kuratierung aufbaut. v1.0.16, das erste getaggte Release seit #30, fügt dem Video-Editor Clip-Übergänge, Rückwärtswiedergabe, einen Voice-Over-Recorder und Timeline-Beat-Marker hinzu, zusammen mit einem Feed-Tuning-Control, das einem Nutzer ermöglicht, durch Wischen die Empfehlungen direkt anzupassen, anstatt sie opaken Engagement-Signalen zu überlassen. Das Release aktiviert auch At-Rest-Verschlüsselung für lokale Daten, fügt Hintergrund-Uploads hinzu, die das Suspendieren der App überleben, und führt ProofMode-Provenienzdaten weiter, wenn ein wasserzeichenmarkierter Clip heruntergeladen wird, damit die Attestierung menschlicher Herkunft beim Transit nicht entfernt wird. Divine liefert auch neue Schutzmaßnahmen für Accounts unter 16 Jahren und erweitert die Lokalisierung auf 17 Sprachen und 284 übersetzte Strings.

Bitchat v1.7.0 adds live push-to-talk voice for DMs and the public mesh

Bitchat ist eine Bluetooth-Mesh-Chat-App mit einem optionalen Gateway auf Nostr-Relays. v1.7.0, veröffentlicht am Abend der Veröffentlichung von #30, fügt Live-Push-to-Talk-Sprachübertragung in PR #1403 hinzu, die Audio streamt, während der Sender die Taste hält, und bei Abbruch des Streams auf eine Sprachnotiz zurückfällt, plus signiertes öffentliches Mesh-Push-to-Talk in PR #1406, sodass Live-Sprach-Bursts auf dem gemeinsamen Mesh-Kanal Sender-Authentifizierung tragen. Das Release heilt auch Peer-ID-Rotation durch erneutes Binden des Links bei einem verifizierten Re-Announce, wobei derselbe Peer unter seiner neuen ID erkannt wird (PR #1401), und Direktnachrichten an einen derzeit nicht erreichbaren Peer werden jetzt mit Store-and-Forward-Zustellung in die Warteschlange gestellt, anstatt direkt fehlzuschlagen (PR #1415). Dies setzt direkt die Berichterstattung von #30 über v1.6.0’s NIP-13 Proof-of-Work und Mesh-to-Nostr-Gateway-Arbeit fort.

MDK ist das Referenz-SDK für das Marmot-Protokoll, die MLS-over-Nostr-Messaging-Schicht, deren Spezifikation #30 als übernommen behandelte. v0.9.4 begrenzt die Advisory-Directory-Schritte, die ein Client beim External-Signer-Login durchläuft, in PR #793, und verhindert eine unbegrenzte Retry-Schleife, wenn ein Remote Signer langsam oder nicht erreichbar ist. Dasselbe Release fügt Draft-Message-Persistenz und Profil-Website-Bindings in PR #812 hinzu und setzt den inkrementellen Härtungsdurchgang fort, den MDK seit dem Schneiden von v0.9.0 durchführt.

Getaggte Releases

n_cord v1.1 adds NSEC Bunker support

n_cord ist ein Nostr-basierter Chat-Client, inspiriert von Discord und IRC. v1.1 fügt NIP-46 NSEC-Bunker-Unterstützung hinzu, zusammen mit einem Reply-Handling-Bug-Fix.

cdk v0.17.3 adds NIP-47 wallet-service support across cdk, cdk-nwc, and cdk-ffi

cdk ist ein Cashu Development Kit; dieses Release ist in den meisten Aspekten rein Bitcoin/Lightning, aber v0.17.3 fügt NIP-47 (Nostr Wallet Connect) Service-Unterstützung mit einem dedizierten NWC-Service-Crate, Wallet-Integration, FFI-Bindings für cdk-ffi und End-to-End-Testabdeckung hinzu, was auf cdk aufbauenden Cashu-Wallets eine standardmäßige Nostr-Wallet-Connect-Oberfläche gibt.

Coop Mobile v0.2.4 improves Nostr Connect and adds ncryptsec1 import

Coop Mobile ist ein NIP-17 Private-Messaging-Client für mobile Plattformen. v0.2.4 verbessert den NIP-46 Nostr-Connect-Ablauf, behebt einen Ladeindikator, der bei manchen Verbindungen permanent hängen blieb, und fügt Import-Unterstützung für das NIP-49 ncryptsec1-verschlüsselte-Schlüssel-Format hinzu, zusammen mit einem umgestalteten Identitätsimport-Bildschirm.

Nmail v0.14.0 ships on macOS with scheduled send and push notifications

Nmail ist ein auf Nostr aufbauender Mail-Client; v0.14.0 bringt die App auf macOS, fügt geplantes Senden mit einem dedizierten Scheduled-Postfach für wartende Nachrichten und Push-Benachrichtigungen hinzu. Das Release stellt auch die Adressbuch-Nostr-Identifier-Auflösung auf NDKs NIP-05-Resolver um, anstelle einer maßgeschneiderten Implementierung.

Nostrord v2.2.0 adds a DM master toggle and richer direct messages

Nostrord ist ein NIP-29 relay-basierter Gruppen-Chat-Client für Android, iOS, Web und Desktop. v2.2.0 fügt einen Master-Toggle zum gleichzeitigen Deaktivieren aller Direktnachrichten-Funktionen hinzu (PR #175) und liefert „reichere Direktnachrichten" (PR #186), fortgesetzt nach der Berichterstattung in #30 über das Release, das den Relay-Pool faltete und Zombie-WebSockets erkannte.

Nostr WoT 0.3.86 hardens key backups and signing prompts

Nostr WoT ist eine Browser-Erweiterung, die eine Nostr-Identität mit einem Lightning-Wallet koppelt. v0.3.86 verschiebt verschlüsselte Schlüssel-Backups in das standardmäßige NIP-49-Format, lässt Signatur-Prompts das vollständige Event und alle Tags anzeigen anstatt einer Zusammenfassung, verifiziert Relay-Daten gegen deren Signatur und stoppt das Offenlegen der aktiven Identität beim Kontowechsel. Die Erweiterung entfernt auch die ungenutzte scripting-Browser-Berechtigung.

Keep Android v1.1.8 adds first-run FROST onboarding

Keep ist ein Android-Signer, der auf FROST-Threshold-Key-Shares aufbaut. v1.1.8 fügt einen First-Run-Ablauf hinzu, der FROST-Key-Shares erklärt und einem neuen Nutzer ermöglicht, eine Signatur-Richtlinie (Manual, Basic oder Auto) zu wählen, bevor die erste Signaturanfrage eintrifft, das erste Android-seitige Onboarding für das Threshold-Signing-Modell des zugrunde liegenden keep-mobile-Crate.

Noscall v0.6.0 adds a Cashu wallet and relay-based push notifications

Noscall ist eine sichere Audio- und Videoanruf-App, die auf Nostr aufbaut. v0.6.0 fügt ein kontobezogenes Cashu-Wallet mit Multi-Mint-Salden, ecash-Senden und -Empfangen und Lightning-Zahlen und -Empfangen mit Quote-Persistenz hinzu. Das Release migriert Android-Push-Benachrichtigungen auch weg von Firebase Cloud Messaging auf einen Nostr-relay-basierten Zustellpfad über UnifiedPush und verbessert die iOS-VoIP- und APNs-Push-Zuverlässigkeit bei Login-Wiederholungsversuchen.

Kubo ships tablet mode and group-chat photos

Kubo ist eine kindersichere Nostr-Videoplattform mit Web-of-Trust-Feed-Kuratierung. kubo-v2026.07.05 fügt ein optionales Tablet-Grid-Layout für den Kinder-Feed und Unterstützung für das Anhängen von Fotos an Gruppen-Chat-Nachrichten hinzu, plus Fixes für den Anmeldeknopf, der sich auf Android hinter der Bildschirmtastatur versteckt.

Nostr Codex Phone v0.2.9 adds git/diff/read-file helper requests

Nostr Codex Phone ist eine mobile Steuerungsoberfläche für einen lokalen Coding-Assistant-Worker, der über verschlüsselte Nostr-DMs kommuniziert. v0.2.9 fügt mobile OpenCode-Tool-Aktionen hinzu, darunter git-, diff-, read-file-, status- und history-Helper-Requests, Session-Pin- und Suchverbesserungen sowie eine Task-Stop-Steuerung, neben einem verschlüsselten Blossom-Upload-Wrapper, der im vorangegangenen v0.2.8 geliefert wurde.

GitWorkshop v3.0.3 fixes newly announced refs in the repo explorer, and ships its first Android build

GitWorkshop ist eine git-over-Nostr-Web-UI zum Durchsuchen und Reviewen von NIP-34-Repositories. v3.0.3 behebt das Fehlschlagen der Branches-, Tags-, Commits- und Code-Browsing-Ansichten beim Auflösen eines Refs, den ein Repository ankündigt, nachdem der Explorer es bereits geladen hat, zusammen mit CI-Workflow-Timing-Bereinigung, direkt gegen den Tag und die Commit-Historie bestätigt. In derselben Woche veröffentlichte GitWorkshop seinen ersten nativen Android-Build im Zapstore, startend bei v3.0.0 und innerhalb von Stunden v3.0.3 erreichend; die Web-UI bleibt das primäre Interface, und das Android-Paket bringt dasselbe NIP-34-Repository-Browsing zum ersten Mal auf ein Telefon.

Bitcoin-Safe reaches Flathub, spotlighting its Nostr Sync & Chat plugin

Bitcoin-Safe ist ein Self-Custody-Bitcoin-Wallet, das auf Hardware-Signer-Workflows aufbaut. Das Projekt hat ein Flathub-Paket veröffentlicht in dieser Woche, sein erster Eintrag in einem Mainstream-Linux-App-Store. Das Flathub-Release bringt Bitcoin-Safes Sync-&-Chat-Plugin vor ein breiteres Publikum: Das Plugin verwendet NIP-17 Direktnachrichten über die projekteigene bitcoin-nostr-chat-Bibliothek, um Wallet-Labels zwischen den Geräten eines Nutzers zu synchronisieren und PSBTs für Remote-Multisig-Co-Signing zwischen vertrauenswürdigen Teilnehmern zu senden und zu empfangen. Die Nostr-Schicht selbst wurde früher ausgeliefert, in 2.0.0 (2026-06-29), das das Transaktionssignieren um einen „Share via Chat & Sync"-Verbindungstyp neben QR, USB und Bluetooth umgestaltete. Die Nachricht dieser Woche ist das Flathub-Packaging, das dieses bestehende Feature zum ersten Mal einem Mainstream-Linux-Publikum zugänglich macht.

Unveröffentlichte Änderungen

Amethyst lets accounts nickname contacts with encrypted NIP-85 cards

Neben der oben behandelten Concord-Implementierung mergte Amethyst in der letzten Woche 54 weitere PRs. Das Highlight darunter ist PR #3548, das einem Account ermöglicht, jeden anderen Nutzer mit einem Spitznamen zu versehen, indem es seine eigene kind-30382-NIP-85-Kontaktkarte über ihn veröffentlicht. Der Petname, eine private Notiz und beliebige benutzerdefinierte NIP-30 Emoji-Shortcode-Zuordnungen befinden sich im NIP-44-verschlüsselten Inhalt der Karte, sodass nur der signierende Account sie lesen kann, und Karten synchronisieren über das erweiterte Outbox-Relay-Set des Accounts bei Login und danach inkrementell. Feeds, Chats und Erwähnungen rendern den Petname anstelle des öffentlichen Anzeigenamens, mit einer antippbaren Spitznamenkarte auf der Profilseite oberhalb des echten Namens des Nutzers.

Zap Cooking ships My Kitchen Phase 3 and fixes an NDK pool quorum bug

Zap Cooking ist eine Rezept-Sharing- und Koch-Community-App, die auf Nostr aufbaut. Sie mergte 43 PRs, die ihr „My Kitchen"-Mahlzeitenplanungs-Feature fortsetzen, mit Einkaufslisten-Generierung, einem Rezept-Picker und einem Planer-Wochenraster in dieser Phase. Dieselbe Reihe von Änderungen behebt einen NDK (Nostr Development Kit) Connection-Pool-Quorum-Readiness-Bug, der Relay-Reads warten lassen konnte, nachdem ein Quorum von Relays bereits geantwortet hatte.

Kehto streams outbox reads before relay discovery

Kehto ist eine frühe webbasierte Laufzeitumgebung für NIP-5D Nostr Applets, oder „Napplets". Sie mergte 26 PRs. PR #193 behebt Outbox-Reads, die zuvor auf das Laden der NIP-65 Relay-Liste warteten, bevor überhaupt ein Relay geöffnet wurde, sodass ein Relay-Liste-Load, der nie abschloss, sowohl Event-Zustellung als auch Query-Timeouts blockieren konnte; der Fix öffnet validierte Relay-Hints sofort und streamt Ergebnisse, während Write-Relays entdeckt werden. Eine zweite Änderung (PR #196) richtet die Identitäts-Audit-Seite des Projekts an NAP-SHELL aus, dem Lifecycle-Contract der Napplet-Plattform, Teil derselben Protokoll-Alignment-Arbeit, die anderswo im napplet/web-Release dieser Woche sichtbar ist.

Wired und TAO sind Zwillings-Free-Speech-fokussierte Social-Clients, die auf Nostr aufbauen und dieselbe PR-Liste teilen; beide mergten PR #121, das NIP-57 Creator Revenue Sharing implementiert, sodass an einen Post gesendete Zaps automatisch an Beitragende über den ursprünglichen Poster hinaus aufgeteilt werden können. Dies setzt die Berichterstattung von #30 über das Paar fort, das sein Proof-of-Work-Signal auf 21 Bit als unveröffentlichte Arbeit erhöht hat.

Conduit Mono rebuilds the merchant orders inbox around ephemeral guest checkout

Conduit Mono ist ein Marktplatz-Protokoll neben NIP-99 Classified Listings. PR #174 fügt Guest Checkout mit einem browserseitig generierten ephemeren Schlüssel hinzu: Der Gast sendet eine verschlüsselte Bestellung und einen Zahlungsbericht an den Händler unter Verwendung dieses Einmalschlüssels, und der Händler folgt außerhalb des Bands per Telefon oder E-Mail auf, sodass der Käufer nie eine dauerhafte Inbox-Identität benötigt. PR #175 baut den Händler-Bestelleingang um ein einzelnes gemeinsames Bestellstatus-Modell um, trennt Käufer- und Händlerrollen und verlangt einen Tracking-Code und Carrier, bevor eine physische oder gemischte Bestellung auf „versandt" wechseln kann. Der Checkout-Ablauf des Projekts baut auf NIP-17 Private Messages, NIP-44 Verschlüsselung und NIP-59 Gift Wrap auf. Der NIP Deep Dive dieser Woche behandelt die Gamma Markets-Konventionen, auf die dasselbe Bestellstatus-Problem hinarbeitet.

Buzz hardens channel-creator provisioning around kind 39002

Buzz ist eine Hive-Mind-Kommunikationsplattform, die KI-Agenten und Menschen über Nostr verbindet. Sie mergte 240 PRs in der letzten Woche und setzte ihren Relay-Schicht-Härtungsbogen fort, nach der Berichterstattung von #30 über kind-44200-Agent-Turn-Metriken. Der Fix dieser Woche (PR #1830) behandelt den Creator eines Channels als Mitglied, bevor die kind-39002-Channel-Provisioning-Logik ausgeführt wird, und schließt eine Race Condition, bei der der eigene Channel des Creators ihn während des Setups ablehnen konnte.

Nostr Docs adopts a NIP-49 signer with multi-account and QR pairing

Nostr Docs ist eine Nostr-native kollaborative Dokumentenanwendung. Sie mergte 5 PRs, der bemerkenswerte (PR #50) übernimmt das @formstr/signer-Paket für vollständige NIP-49-Authentifizierung mit Multi-Account-Switching und QR-Pairing und ersetzt einen früheren maßgeschneiderten Signaturpfad.

Ebenfalls ausgeliefert

Kleinere Signer-Interop- und Zuverlässigkeits-Fixes landeten in der letzten Woche über mehrere getrackte Projekte hinweg, ohne genug neue Oberfläche für eigene Absätze: ngit-cli, ein Kommandozeilen-Client für eine Nostr-basierte GitHub-Alternative, liefert v2.6.3, das ngit init umsetzbare Setup-Anleitung statt wiederholter nsec-Abfragen gibt; Manent, eine private verschlüsselte Notizen-und-Dateien-App auf Nostr, liefert v1.4.1 mit einem Fix für defektes Android-Signer-Login, wenn Amber einen Hex-pubkey zurückgibt, und verbessertem Bunker-Login-Scrolling; NoorNote, ein schlanker, Google-Service-freier Nostr-Client, liefert v1.2.8 mit einem Fix für verpasste Nostrord-Gruppen-Benachrichtigungen und einem Self-Post-Alert-Toggle; Bray, ein vertrauensbewusster Nostr-MCP-Server für KI-Agenten und Menschen, liefert v1.34.0, das Client-Name-Metadaten bei NIP-46 Bunker Connect sendet; Lumilumi, ein Nostr-Web-Client, cachet NIP-65 Relay-Listen im lokalen Speicher für Offline-Fallback; Earthly, eine Nostr-basierte lokale Stadt- und Community-App, fügt NIP-50 Geo-Suche hinzu; und lnbits, ein freies und Open-Source-Lightning-Wallet- und Kontensystem, liefert PR #3925, das send_nostr_dm nicht-blockierend innerhalb eines ansonsten Lightning-fokussierten Releases veröffentlicht.

Neu getrackt und entdeckt

OpenDiscord v1.0.1 launches as a Discord-style client on Nostr

OpenDiscord ist ein Discord-artiger Server-und-Channel-Client, der auf Nostr mit rollenbasierten Berechtigungen und WebRTC/SFU-Sprach-Lobbies aufbaut. v1.0.1 ist das erste getaggte Installer-Release des Projekts.

Auditable Voting v0.1.140 aligns organiser, voter, and audit-proxy roles

Auditable Voting ist eine Client-only-Nostr-Abstimmungs-Shell. v0.1.140 richtet die Organiser-, Voter- und Audit-Proxy-Rollen am exakten vom Organiser signierten öffentlichen Questionnaire-Definition-Event aus und schließt eine Lücke, bei der ein Audit-Proxy auf veralteten generierten Accounts oder State operieren konnte, der von einem anderen Worker oder Organiser stammte.

Cambium v0.3.2 pairs with Heartwood as a keyless NIP-55 signer

Cambium ist der Discovery-Pick dieser Ausgabe: ein Android-NIP-55-Signer, der selbst kein privates Schlüsselmaterial hält und jede Signaturanfrage über NIP-46 an einen Heartwood-Hardware-Signer-Companion weiterleitet. Das Projekt teilt die forgesworn-GitHub-Org mit dem getrackten Projekt Bray, und Heartwood selbst wurde in #30 behandelt, als es die Relay-to-Serial-Signing-Bridge auslieferte, mit der Cambiums Android-Seite nun kommuniziert. v0.3.2 poliert das Genehmigungsblatt, um live zu warnen, wenn die gewählte Identität von der bestehenden Bindung der App abweicht, und verschiebt Activity-Log-Schreibvorgänge in eine einzelne nicht-blockierende Warteschlange.

Ebenfalls diese Woche gestartet: echoes, Dispatch und Linky

Drei weitere Launches verdienen eine Erwähnung diese Woche. echoes ist eine Offline-First-, Ende-zu-Ende-verschlüsselte Notizen-App, die privat über Nostr synchronisiert. Dispatch ist ein Local-First-Reiseorganizer, bei dem jede Speicherung NIP-44-verschlüsselt und über Nostr unter einem dedizierten, nicht verlinkbaren Schlüssel gesichert wird, und sein v0.3.0-Release fügt Amber-NIP-55-Login hinzu, damit die App den privaten Schlüssel des Nutzers nie direkt berührt. Linky kombiniert Nostr-Kontakte und DMs mit Lightning- und Cashu-Zahlungen in einer einzigen Progressive Web App.

Protokollarbeit und NIP-Updates

Keine PRs wurden in der letzten Woche in das NIPs-Repository gemergt. Sechs Vorschläge wurden geöffnet.

Open: kind:10011 favorite follow sets

PR #2413, von fiatjaf, fügt kind:10011 Favorite Follow Sets hinzu. Es spiegelt das bestehende Muster, bei dem kind:10012 (Favorite Relay Sets) a-Tags enthält, die auf kind:30002 Relay Sets zeigen, und erweitert denselben Favorisierungsmechanismus auf kind:30000 Follow Sets, damit ein Client eine kuratierte Follow-Liste als Lesezeichen speichern kann, ohne seine eigene Kontaktliste zu ersetzen.

Open: private encrypted drive extends NIP-4E

PR #2412, vom Form*-Team, schlägt ein generisches Metadata-Event vor, kind 34578, unterschieden durch einen d-Identifier-Tag und einen t-Sub-Type-Tag, zusammen mit einem privaten verschlüsselten Dateisystem, das darauf aufbaut und bereits in Form*’s eigenem, noch experimentellem Form* Drive Client implementiert ist. Ein Datei-Datensatz ist ein Metadata-Event mit t=files: Datei-Blobs liegen auf Blossom-Servern, während nur ein verschlüsselter Index auf Relays sitzt, und jeder Datei-Chunk erhält sein eigenes ephemeres Schlüsselpaar mit NIP-44 v2 HKDF-abgeleiteter Verschlüsselung. Ein begleitendes Decoupled Encryption Key Event hält einen laufwerkweiten symmetrischen Schlüssel, gegen den jede Datei ihre Metadaten entschlüsselt, und baut explizit auf NIP-4E auf, fiatjafs noch offenem Storage-Abstraction-Entwurf (PR #1647, offen seit Dezember 2024).

Dieser einzelne laufwerkweite Schlüssel bedeutet, dass ein durchgesickerter Schlüssel die Metadaten jeder Datei im Laufwerk offenlegt, nicht nur einer Datei, da die pro-Datei ephemeren Schlüsselpaare nur den Chunk-Verschlüsselungsschlüssel variieren, nicht den Metadaten-Entschlüsselungsschlüssel; es gibt noch keinen Rotations- oder Widerrufspfad außer dem Veröffentlichen eines neuen Metadata-Events mit der Warnung, dass ältere Events verloren gehen können. Ein zweiter, engerer Vorschlag greift dieselbe zugrunde liegende NIP-4E-Idee aus einem anderen Blickwinkel auf: PR #2361, von fiatjaf, entkoppelt Identitäts- und Verschlüsselungsschlüssel speziell innerhalb von NIP-17 Messaging, offen seit 1. Juni. Beide PRs sind nicht gemergt, was dies zu einer aktiven, umstrittenen Ecke des Designraums macht. Form* sagt, der Drive Client sei experimentell und ein Update komme bald.

PR #2411, von JAFairweather, ist ein neuer NIP-DA-Entwurf für genehmigungsbasiertes privates Datenteilen über scoped Data Grants. Jeder Nutzer hält einen verschlüsselten, autoritativen Datensatz pro Scope auf Relays, und Zugang wird gewährt, indem der symmetrische Schlüssel dieses Scopes privat innerhalb eines NIP-59 Gift Wraps zugestellt wird, sodass Relays nur Ciphertext speichern und nie erfahren, wer wem Zugang gewährt hat; ein Widerruf ist einfach eine Schlüsselrotation, ohne jeden Consumer-Kopie neu schreiben zu müssen. Der Autor positioniert es als distinkt von NIP-17 DMs (die einen Daten-Snapshot transportieren können, aber keine Live-Updates oder Widerrufe) und von NIP-51 Private Lists (die kein Schlüsselmaterial transportieren), und zitiert zwei unabhängige Implementierungen, eine JavaScript-Referenzbibliothek und eine Go-CLI auf go-nostr, kreuzgetestet gegen relay.damus.io, nos.lol und relay.primal.net.

Open: sticker pack kinds 10031 and 30031

PR #2410, von vincenzopalazzo, registriert kind 30031 (adressierbare Sticker Packs) und kind 10031 (die Sticker-Pack-Liste eines Nutzers) in der Event-Kinds-Tabelle, spezifiziert durch das „Sonar Stickers"-Format, das Sonar diese Woche ausliefert. Die Kinds liegen bewusst einen Slot über den NIP-30 Custom-Emoji-Kinds 30030 und 10030, damit ein Client ein Sticker Pack nicht mit einem Emoji-Set verwechseln kann; Sticker-Bild-Bytes liegen auf HTTPS-Blossom-kompatiblen Servern, und gesendete Sticker-Referenzen tragen einen Klartext-Hash, damit ein bearbeitetes adressierbares Pack nicht stillschweigend das Aussehen von Stickern ändern kann, die bereits in alten Nachrichten gesendet wurden. Ein begleitender PR registriert dieselben Kinds im separaten registry-of-kinds-Projekt.

Open: NIP-29 message pinning with kind:9010 and kind:39005

PR #2379, von Anderson-Juhasc, fügt Message Pinning zu NIP-29 relay-basierten Gruppen hinzu: kind:9010 update-pin-list ist ein Moderations-Event, das die vollständige Liste der angepinnten Events als e-Tags in Anzeigereihenfolge trägt, sodass ein einzelnes Event pinnen, entpinnen, umsortieren oder die angepinnte Menge leeren kann, und kind:39005 ist ein relay-generierter Spiegel, der die zuletzt akzeptierte Liste offenlegt. Das Design ersetzt einen früheren Add/Remove-Paar-Ansatz aus PR #1163 nach Review-Feedback und wählt Kind-Nummern 9010/39005, weil 9009 und 39003 inzwischen von create-invite und Gruppenrollen beansprucht wurden. Anderson-Juhasc pflegt auch Nostrord, dessen v2.2.0 in derselben Woche ausgeliefert wird.

Open: NIP-66 relay discovery restructure

PR #2241, von VincenzoImp, ist eine umfassende Umstrukturierung von NIP-66 Relay Discovery. Es ersetzt die lose „Other tags include"-Prosa durch einen strukturierten Indexed-Tags-Abschnitt, fügt einen W-Tag hinzu, der NIP-11s attributes-Feld für Relay-Discovery-Filterung spiegelt, fügt einen l-Label-Tag mit standardisierten Namespaces (ISO-639-1, ISO-3166-1, IANA-asn, IANA-tz, nip66.label.city) hinzu und organisiert RTT-, SSL/TLS-, Netzwerk-, Geo-, DNS- und HTTP-Tags in dedizierte Abschnitte neben einer neuen Check-Types-Tabelle. Es behebt auch fehlerhafte Beispiel-Events mit falschen Feldnamen, einem fehlenden kind und ungültigen Check-Type-Namen und schließt Issue #2171 ab. Alle Änderungen bleiben abwärtskompatibel, da jeder hinzugefügte Tag optional ist.

NIP Deep Dive: NIP-99 und die Gamma-Markets-Commerce-Erweiterung

NIP-15, die ursprüngliche Nostr Marketplace-Spezifikation, ist inzwischen Legacy: Sie modellierte einen Merchant Stall (kind 30017) mit Produkten (kind 30018) darunter, und die Clients, die einst darauf liefen, Shopstr unter ihnen, sind seitdem zu NIP-99 Classified Listings als aktiver Spezifikation gewechselt. NIP-99 selbst ist ein einzelnes adressierbares Event, kind 30402 für ein aktives Listing oder kind 30403 für einen Entwurf, ohne zuerst einen Stall erstellen zu müssen. Es lässt alles nach dem Listing undefiniert: Versandkosten, Bestellstatus, Quittungen, Bewertungen und eine Möglichkeit, mehrere Listings unter einem Schaufenster zu gruppieren, genau die Teile von NIP-15, die nie übernommen wurden. Gamma Markets füllt diese Lücke und ist die moderne Commerce-Schicht, die es heute zu verstehen lohnt.

Die Lücke, die NIP-99 offen lässt

Das content-Feld eines NIP-99-Listings trägt eine Markdown-Beschreibung, price und location sitzen direkt auf dem Event, und t-Tags machen es als gewöhnlichen Hashtag-Content durchsuchbar. Da es auf dem pubkey-, kind- und d-Tag-Tupel adressierbar ist, bearbeitet ein Verkäufer ein Listing direkt, indem er eine neue Version mit demselben d-Tag veröffentlicht:

{
 "kind": 30402,
 "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.",
 "tags": [
 ["d", "keyboard-mx-blue-01"],
 ["title", "Vintage Mechanical Keyboard"],
 ["summary", "Cherry MX Blue, barely used"],
 ["published_at", "1752537600"],
 ["location", "NYC"],
 ["price", "100", "USD"],
 ["t", "electronics"]
 ]
}

Das ist die gesamte Spezifikation: eine signierte, aktualisierbare Kleinanzeige. Jeder Client, der NIP-99 für echten E-Commerce implementiert, über eine einmalige Kleinanzeige hinaus, musste seine eigenen privaten Konventionen für Versand, Bestellnachrichten und Bewertungen erfinden. Zwei NIP-99-Clients konnten jeweils ein Listing korrekt darstellen und hatten trotzdem keinen gemeinsamen Weg, einen Checkout zwischen ihnen abzuschließen.

Gamma Markets: Standardisierung dessen, was NIP-99 ausließ

Gamma Markets ist der Name, den eine Arbeitsgruppe von Nostr-Marktplatz-Entwicklern, die Teams hinter Shopstr, Cypher, Plebeian Market und Conduit Market, einem gemeinsamen Satz von E-Commerce-Konventionen gab, die auf NIP-99s bestehendem kind-30402-Event aufbauen. Die Spezifikation ist vom kanonischen NIP-99-Dokument über PR #1784 verlinkt und wird in ihrem eigenen Repository gepflegt, GammaMarkets/market-spec.

Gamma Markets fügt zwei eigenständige listing-angrenzende Kinds hinzu. Kind 30405 gruppiert mehrere Listings in eine Produktsammlung und referenziert jedes über ein explizites a-Tag:

{
 "kind": 30405,
 "content": "Summer sale picks",
 "tags": [
 ["d", "summer-picks"],
 ["title", "Summer Sale"],
 ["a", "30402:<merchant-pubkey>:keyboard-mx-blue-01"],
 ["shipping_option", "30406:<merchant-pubkey>:standard-regional"]
 ]
}

Kind 30406 definiert eine Versandoption mit länderspezifischer Preisgestaltung und optionalen gewichts- oder entfernungsbasierten Kostenregeln:

{
 "kind": 30406,
 "content": "Standard Regional Shipping",
 "tags": [
 ["d", "standard-regional"],
 ["title", "Standard Shipping"],
 ["price", "5.99", "USD"],
 ["country", "US"],
 ["service", "standard"],
 ["duration", "24", "72", "H"],
 ["weight-max", "30", "kg"]
 ]
}

Bestellerstellung, Zahlungsanforderungen, Status- und Versand-Updates und Zahlungsbelege laufen alle als gewöhnliche NIP-17 Gift-Wrapped Private Messages, aufgeteilt auf drei Kinds nach Rolle, nicht durch erneutes Wrapping des Transports: kind 14 transportiert freie Käufer/Händler-Kommunikation, kind 16 transportiert jeden Bestellstatus-Übergang (ein type-Tag von 1 bis 4 markiert Bestellerstellung, Zahlungsanforderung, Statusupdate oder Versandupdate), und kind 17 transportiert den Zahlungsbeleg des Käufers. Eine Bestellerstellungsnachricht sieht vor dem Gift-Wrapping so aus:

{
 "kind": 16,
 "content": "Please leave the package with the doorman.",
 "tags": [
 ["p", "<merchant-pubkey>"],
 ["subject", "New order"],
 ["type", "1"],
 ["order", "order-8f21"],
 ["amount", "115000"],
 ["item", "30402:<merchant-pubkey>:keyboard-mx-blue-01", "1"],
 ["shipping", "30406:<merchant-pubkey>:standard-regional"]
 ]
}

Die Bewertung eines abgeschlossenen Kaufs ist ein separater adressierbarer Kind, 31555, der auf das bewertete Listing zurückverweist:

{
 "kind": 31555,
 "content": "Arrived fast, exactly as described.",
 "tags": [
 ["d", "a:30402:<merchant-pubkey>:keyboard-mx-blue-01"],
 ["rating", "1", "thumb"],
 ["rating", "1.0", "quality"],
 ["rating", "0.9", "delivery"]
 ]
}

Bestellnachrichten auf NIP-17 aufzusetzen bedeutet, dass ein Gamma-Markets-Checkout denselben Private-Message-Transport nutzt, den Clients bereits für DMs ausliefern, anstatt einen eigenen Bestellnachrichten-Kind zu erfinden.

Die zentrale Designentscheidung der Spezifikation ist, dass nichts kaskadiert. Ein Listing, das zu einer Sammlung gehört, referenziert diese explizit mit einem a-Tag, anstatt die Versandoptionen oder Beschreibung der Sammlung automatisch zu erben, und eine Versandoption, die ein Listing verwendet, wird auf dieselbe explizite Weise referenziert. Das ist eine bewusste Umkehrung von NIP-15s Stall-Modell, bei dem ein Produkt stillschweigend die Währung und Versandtabelle seines übergeordneten Stalls erbte. Der Kompromiss ist mehr explizites Tagging auf jedem Listing, im Austausch dafür, dass die vollständige Konfiguration eines Listings immer aus dem Event selbst lesbar ist, ohne ein übergeordnetes Objekt zuerst auflösen zu müssen.

Wo das in der Praxis auftaucht

Die Conduit Mono-Arbeit dieser Woche liegt im selben Bestellnachrichten-Territorium, das Gamma Markets standardisiert: PR #174’s ephemerer Schlüssel-Guest-Checkout und PR #175’s Händler-Bestelleingang-Umbau lösen beide das Käufer/Händler-Bestellstatus-Problem, das Gamma Markets’ kind-14-, 16- und 17-Nachrichten formalisieren; Conduit Mono betreibt sein eigenes Bestellstatus-Modell neben diesen Kinds, ohne sie direkt zu übernehmen. Shopstr, eines der vier Projekte, die die Spezifikation verfasst haben, hat seine eigene Commerce-Infrastruktur in der letzten Woche ebenfalls vorangetrieben: PR #568 extrahiert duplizierte NIP-17-Gift-Wrap-Logik in ein gemeinsames Modul, und PR #567 bringt seinen NIP-98 HTTP-Auth-Parser auf vollständige Testabdeckung, Wartung an genau den Messaging- und Auth-Schichten, von denen ein Gamma-Markets-Bestellablauf abhängt, um einen Käufer und Händler sicher zu erreichen.

NIP-15 verlor die Storefront-Rolle, indem es einen Stall und ein Produkt standardisierte und dann Zahlungen, Versand, Bewertungen und Bestellstatus als Anwendungsproblem beließ. Gamma Markets füllt den größten Teil dieser fehlenden Oberfläche, ohne NIP-99s Single-Listing-Form zu verändern, und baut auf Nostrs bestehendem DM-Stack, NIP-17, auf, anstatt eine neue Messaging-Schicht zu erfinden.

Das war’s für diese Woche. Baut ihr etwas oder habt Neuigkeiten zu teilen? Meldet euch per NIP-17-DM oder findet uns auf Nostr.

Nostr Compass #26

Wed, 10 Jun 2026 00:00:00 +0000

Die Marmot-Protocol-Organisation öffnet drei neue Repos für einen v2-Protokollentwurf und eine native Client-Linie: ein Rust-Workspace namens darkmatter, eine SwiftUI iOS-App darkmatter-ios und eine Kotlin/Compose Android-App darkmatter-android. Das ursprüngliche Flutter-Whitenoise wird archiviert. Chama komprimiert siebzehn Releases in eine Woche und überschreitet bei v3.0.0 die Standalone-App-Linie, bevor v3.1.0 eine vollständige Trade-Room-UI-Neugestaltung und Per-Verkäufer-Storefronts liefert, aufbauend auf Holder-only Shamir-Shares, Arbiter-Substitution, weltweitem Community-Routing und End-to-End-Trade-Benachrichtigungen. Coracle startet einen kostenpflichtigen Hosted-Relay-Dienst, gestützt auf den Open-Source-Caravel- und zooid-Stack, mit tiefer Flotilla-Integration in Planung. Angor stellt in v0.2.30 standardmäßig auf mainnet um und landet einen 3-User-UAT-Funding-Test in v0.2.29. Amethyst landet 41 unveröffentlichte PRs, die die NIP-32-/NIP-F4-/Tor-Arbeit der letzten Woche fortsetzen. NIP-67 (EOSE Completeness Hint) und NIP-50 Autocomplete werden gemerged und schließen zwei langbestehende Korrektheitslücken im Kern-Relay-Protokoll. NIP-GART schlägt ein datenschutzfreundliches Wire-Format für Notfallwarnungen vor, und NIP-46 erhält eine Logout-Methode.

Top-Stories

Marmot v2 (Dark Matter): Protokoll-Neuentwurf, native Clients, archivierte Flutter-App

Drei neue Repos tauchten diese Woche unter der marmot-protocol GitHub-Organisation auf und bilden zusammen die frühe Fortschrittsform eines Marmot-v2-Protokollentwurfs und einer nativen Client-Linie, die die Flutter-App-Linie ablöst. darkmatter (Rust, erstellt am 13. Mai, vierunddreißig Commits in den letzten sieben Tagen) hält den v2-Protokollentwurf in spec/, eine OpenMLS-basierte CGKA-Engine in crates/cgka-engine, einen Konformanz-Simulator mit Property-Tests und ein formales Tamarin-Modell für Konvergenzbeweise. darkmatter-ios (Swift, erstellt am 25. Mai) ist ein SwiftUI-Client, gestützt auf ein aus dem Rust-Workspace generiertes MarmotKit-UniFFI-xcframework. darkmatter-android (Kotlin/Jetpack Compose, erstellt am 25. Mai) sitzt auf denselben Rust-Bindings. Das ursprüngliche Flutter-Whitenoise wurde als whitenoise-archive markiert (“ARCHIVED: This was the original White Noise Flutter app”); ein neues whitenoise Dart-Repo trägt die aktive Flutter-Linie parallel weiter.

Lies das als frühen Fortschritt in Richtung eines zuverlässigeren Marmot, nicht als abgeschlossenen Pivot. Das darkmatter-README bezeichnet sich selbst als “Candidate Marmot v2 protocol draft, CGKA engine, and conformance workspace” und sagt direkt: “MDK remains the deployed Rust protocol implementation until this draft and engine are adopted.” Innerhalb des Workspaces ist der cgka-engine-Crate mit 0.1.0 getaggt, “single internal consumer, not semver-stable.” Jede Spec-Seite trägt “Status: draft for internal review”. Drei Sterne auf dem Workspace-Repo und null auf den iOS- und Android-Apps bestätigen, dass die Arbeit vor der Ankündigung steht. Richtung, Umfang und Disziplin sind hier das Signal; Produktionsreife ist nicht der Anspruch.

Der Protokollentwurf macht die v1-zu-v2-Deltas konkret. MIP-01s monolithische marmot_group_data MLS-Erweiterung, die seit Beginn von Marmot Gruppenname, Beschreibung, Admin-pubkeys, Nostr-Group-Routing-ID, Relay-Liste, Gruppenbilddaten und Disappearing-Message-Einstellungen unter einem Dach getragen hat, wird in versionierte App-Komponenten aufgeteilt: marmot.group.profile.v1 für Name und Beschreibung, marmot.group.admin-policy.v1 für Admin-pubkeys, marmot.transport.nostr.routing.v1 für die zufällige nostr_group_id und die kanonische Relay-Liste, marmot.group.blossom.image.v1 für Bild-Hash, Verschlüsselungsschlüssel, Nonce und Upload-Schlüssel und marmot.group.message-retention.v1 für Disappearing-Message-Sekunden. Jede Komponente besitzt ihre exakten Bytes und ihren eigenen Versionierungspfad, sodass ein zukünftiges Feature eine Komponente überarbeiten kann, ohne den Rest des Gruppenzustands zu zwingen, MLS-Extension-Konsens noch einmal zu durchlaufen. MIP-00-Credentials erhalten außerdem ein neues Foundation-Dokument account-identity-proof-v1.md, hervorgehoben als “new in v2 and breaking”. Der Identitätsbeweis lebt jetzt auf seiner eigenen Oberfläche, getrennt von der KeyPackage-Konstruktion.

Die Bibliotheks-Deltas stützen die Spec-Überarbeitung. cgka-engine ist die neue lokale Gruppen-State-Machine: sie wrappt OpenMLS, besitzt die Epoch-Zustände Stable, PendingPublish, Merging und Recovering, übersetzt Absichten in MLS-Commits, gibt typisierte IngestOutcome- und GroupEvent-Werte für jede eingehende Transport-Hülle zurück und liefert explizit keinen Transport und keine Persistenz. Ein TransportPeeler-Trait trennt Nostr von der Engine, und ein StorageProvider-Trait trennt SQLite (über storage-sqlite, SQLCipher-basiert) von der Engine. Heutiges MDK packt all das zusammen; das Aufteilen der Schichten lässt eine Engine jetzt unter einem Nostr-Relay-Transport sitzen und später auch unter den ebenfalls ausgelieferten QUIC-Stream- und Broker-Transports, ohne Neufassung des Konvergenzmodells. Die Konvergenz selbst ist als distributed-convergence.md dokumentiert und in einem Tamarin-Modell bewiesen, das deterministische Branch-Auswahl, policy-gated Eligibility, Retained-Anchor-Replay, Stale-Branch-Rejection, Delivery-Reordering, Duplikation, App-Output-Invalidation, Welcome/Commit-Handoff, Proposal-Konsum und Outbound-Gating während Sync abdeckt. Rust-Property-Tests prüfen dann, dass die Engine dieselben Regeln mit echten OpenMLS-Objekten und dem Simulator-Harness einhält. Formal-Methods-Zuverlässigkeitsarbeit dieses Umfangs fehlt im aktuellen Marmot-Stack.

Beide nativen Clients verwerfen Flutter zugunsten plattformnativer UI-Toolkits. darkmatter-ios ist reines SwiftUI mit einer Notification Service Extension, die MIP-05-Push-Wakes auf dem Gerät entschlüsselt, vendort ein generiertes MarmotKit Swift-Paket, das aus dem Rust-Workspace gebaut wurde, und registriert sich unter der dev.ipf.darkmatter Bundle-ID und App-Gruppe. darkmatter-android ist Kotlin und Jetpack Compose, mit einem just-getriebenen Build, der ein signiertes arm64-v8a APK erzeugt und Telemetrie-Endpunkte aus local.properties liest. Das Android-README formuliert das architektonische Prinzip direkt: “Dark Matter owns protocol data and stores it in SQLite. The Android app should render that data, manage Android platform behavior, and keep UI lifecycle state. The Android app should not become a second database for Dark Matter data.” Das spiegelt die Grenz-Disziplin, die das cgka-engine-README in der Rust-Schicht durchsetzt, angewendet auf die UI-Schicht.

Native Clients sind für Marmot wichtig, weil die meistgenannte Schwäche des Protokolls die mobile Zuverlässigkeit unter ungleichmäßigen Zustellbedingungen war: verpasste Deadline-Notification-Wakes, MLS-Commit-Races während Netzwerk-Flaps, Background-Fetch-Limits, die Epoch-Fortschritte stranden lassen. SwiftUI und Compose geben den Clients direkten Zugriff auf plattformnahe Hintergrundverarbeitungs-Primitive, die Flutter durch eine Plugin-Brücke erreicht, und der UniFFI-Binding-Pfad hält Protokoll-Logik in einem Rust-Workspace, der auf beiden Plattformen als statische Bibliothek ausgeliefert wird. Die Flutter-Whitenoise-Linie setzt sich im nicht archivierten whitenoise-Repo fort, sodass die Ankündigung additiv ist: eine neue native Client-Linie läuft parallel zur Flutter-App, während die v2-Spec konvergiert. Der Produktions-Cutover von MDK oder der aktuellen Whitenoise-App wartet, bis Entwurf, Engine und Clients produktionsreife Releases erreichen.

Chama v2.0.0 bis v3.1.0: Standalone-P2P-Escrow in einer Woche

Der in Newsletter #25 bei v1.3.0 eingeführte Nostr-native P2P-Escrow-Client hat in den letzten sieben Tagen siebzehn getaggte Releases ausgeliefert und endete am 9. Juni bei v3.1.0 mit einer Trade-Room-UI-Neugestaltung und Per-Verkäufer-Storefronts. Die Versionsspur erzählt die Geschichte: v2.0.0 ist die BREAKING-Basis, dann schließen v2.0.1, v2.0.2 und v2.0.3 Fedi-WebView-Funding-Rail-Lücken; v2.1.0, v2.2.0, v2.3.0 und v2.3.1 härten die Arbiter-Schicht; v2.4.0, v2.5.0 und v2.6.0 fügen Self-Custody-Oberflächen und weltweites Community-Routing hinzu; v2.7.0, v2.8.0, v2.9.0 und v2.10.0 schichten Plain-English-Key-Copy, Gruppen-Anwendungen, Dispute-Deadline-Arbitrierung und Reputation ein. v3.0.0 verbindet das Paket mit End-to-End-Trade-Benachrichtigungen, und v3.1.0 am 9. Juni zeichnet den Trade-Screen rund um ein Reserved → Locked → Settled Fortschritts-Rückgrat, rollen-farbige Aktions-Karten und eine Per-Verkäufer-Storefront-Listing-Klasse (kuratierte Swaps, Loanbooks und Rechnungen) neu.

Der architektonische Pivot lebt in v2.0.0. Das Escrow-LOCK-Format hat sich geändert, sodass jeder Share eines 2-von-3 Shamir-Splits nur an seinen Holder verschlüsselt wird (sharePolicy holder-only-v1). Das Bearer-Ecash der Föderation lässt sich nicht mehr von einem einzelnen Teilnehmer allein rekonstruieren, was einen Pfad schließt, auf dem eine böswillige Partei mit ihrem eigenen Share und einem Föderations-gehaltenen Share den Trade ohne Zustimmung abschließen konnte. Pre-2.0-Clients scheitern laut mit “can’t find your share”; der Trade kann auf einem veralteten Client nicht abgeschlossen werden, und im Prozess gehen keine Gelder verloren. Ein v2.0-Lock erfordert, dass jede Partei auf v2.x abwickelt. v2.0.0 fügte außerdem Multi-Unit-Storefronts und eine Sats-only Market-Ansicht hinzu.

v2.1.0 führte die Arbiter-Substitution ein: der Arbiter-Share bei Shamir-Index 2 wird jetzt an eine deterministische Prioritätsordnung über den Community-Arbiter-Pool verschlüsselt, sodass ein abwesender Arbiter ersetzt werden kann, ohne den Trade zu stranden. v2.2.0 bewies, dass die Substitution in freier Wildbahn bei einem ₿121-Trade funktioniert, und fügte Healing-Substitution-Backups hinzu. v2.3.0 schloss die letzte Arbiter-Front-Running-Lücke, indem die Listing-Arbiter-Community-Mitgliedschaft zur Lock-Zeit geprüft wird, und v2.3.1 schloss den Geschwister-Race, bei dem ein automatisch zugewiesener Arbiter-Slot eine Vorschau war, bis der Lock ihn einsetzte.

Die Self-Custody-Oberflächen kamen in v2.4.0 (BIP-39 Recovery-Phrase für die Fedimint-Ecash-Wallet, verschlüsselt auf Nostr gespeichert) und v2.5.0 (Master-nsec-Backup, das die Nostr-Identität und den Wallet-Seed besitzt). v2.6.0 überarbeitete das Onboarding rund um einen globalen Community-Picker, sodass Nutzer in Ländern ohne lokales Chama zur nächstgelegenen Föderation geleitet werden; frühere Builds warfen den Nutzer ohne Fallback zurück. v2.7.0 schrieb den Recovery-Key-Screen in Plain English um (“the only key to your account and the money in it; Chama never sees it and can’t reset it; if you lose it, no one can get your account back”). v2.8.0 fügte Gruppen-Anwendungen, Dark/Light-Theming und zwei neue Event-kinds hinzu (38120 Roster, 38121 Application). v2.9.0 änderte die Dispute-Auflösung bei Deadline: umkämpfte Trades, die ihren Ablauf erreichen, werden jetzt per Arbiter-Urteil aufgelöst; vorheriges Verhalten war Auto-Refund. Das Release ist als COORDINATED markiert, sodass alle Parteien in einer Auseinandersetzung updaten müssen. v2.10.0 fügte Per-Trade Daumen-hoch/Daumen-runter-Bewertungen als neues Event-kind 38123 hinzu.

v3.0.0 ist der Meilenstein, ab dem die App keine koordinierende Community mehr zum Betrieb braucht. End-to-End-Trade-Benachrichtigungen pingen den Nutzer nur bei handlungsrelevanten Zustandsübergängen: die Gegenpartei hat die Sats gesperrt, Auszahlung bereit zur Beanspruchung, Streit erfordert das Urteil des Nutzers als Arbiter, oder Trade abgeschlossen oder abgelaufen. Ein Toggle im Me-Screen schaltet Benachrichtigungen an oder aus, und der Berechtigungs-Prompt feuert nur, wenn der Toggle aktiviert ist. Die Fire-once-Dedup verhindert, dass ein Zustandsreload einen Alert-Sturm auslöst. Ein Wrong-Chama-Guardrail-Bug wurde ebenfalls in PR #103 geschlossen, wo frühere Versionen ein Listing mit dem Label eines Chamas, aber der Föderation eines anderen Chamas stempeln konnten. Windows- und Linux-Desktop-Bundles werden mit dem Release ausgeliefert; das macOS-dmg wird zurückgehalten, bis Signierung und Notarisierung landen.

Chama gesellt sich jetzt zu Mostro und Shopstr als Nostr-nativer Marktplatz, unterschieden durch serverlose Architektur, Fedimint-gestützten 2-von-3 Shamir-Escrow, Holder-only-Share-Verschlüsselung und als einziger der drei, der einen self-contained Desktop- und Mobile-Client ohne koordinierende Community ausliefert.

Coracle Hosting: kostenpflichtiger Relay-Dienst plus Open-Source-Caravel-Stack

Am 3. Juni kündigte Hodlbod Coracle Hosting an unter hosting.coracle.social, einen gehosteten Community-Relay-Dienst, der wiederkehrende Lightning-Zahlungen per NWC oder Karte akzeptiert. Der Dienst wird von Caravel angetrieben, Coracles Abrechnungs- und Provisionierungs-Frontend, und zooid, einer Relay-Runtime, die viele virtuelle Relays auf einer einzigen Maschine hostet. Beide sind Open Source auf Coracles selbstgehostetem gitea. Caravel wird mit optionaler livekit- und Blossom-Integration ausgeliefert, die Betreiber pro Relay umschalten können. Ein Free-Tier mit Mitglieder-Limits lässt Betreiber den Dienst evaluieren, bevor sie Zahlungsdetails hinterlegen.

Hodlbod ist offen zum Geschäftsmodell: Open Source monetarisieren, indem eine gehostete Version eines Stacks verkauft wird, den jeder andere ebenfalls betreiben kann. Der Wettbewerbsvorteil ist die Flotilla-Integration, der nächste geplante Schritt. Flotilla besitzt die Nutzeroberfläche, sodass die aus Flotilla heraus servierte Hosted-Option zum Standard-Pfad für jeden Nutzer wird, der verwaltete Infrastruktur bevorzugt. Hodlbod bot an, andere Caravel-Betreiber zu Flotillas Alternative-Hosting-Picker hinzuzufügen, wenn sie sich melden, und hält die Tür zu einem föderierten Hosting-Markt offen.

Caravel gesellt sich zu relay.tools als öffentliche Nostr-Relay-Provisionierungs-Plattform mit kostenpflichtigen Mitglieder-Tiers. relay.tools ist älter als Caravel und liefert heute als dominanter Relay-Ersteller-Dienst aus, mit einem eigenen Verzeichnis von Community-Relays und Paid-Member- oder Moderator-Join-Flows. Caravels Unterscheidungsmerkmal ist der koordinierte Stack: die Relay-Runtime (zooid), das Abrechnungs- und Provisionierungs-Frontend (Caravel selbst) und der clientseitige Picker (Flotilla-Integration, noch in Arbeit) werden als ein Design ausgeliefert. Das andere Unterscheidungsmerkmal ist zooids Many-Relays-per-Process-Dichte, bei der Kunden-Relays einen einzigen Host-Prozess teilen, sodass der Betreiber Hosting-Kosten über viele kleine Communities amortisiert. Das ist dasselbe Dichte-Argument, das gemeinsames Web-Hosting Anfang der 2000er tragfähig machte, angewendet auf Nostrs Relay-Schicht.

Releases

Angor v0.2.29 und v0.2.30: mainnet-Standard und 3-User-UAT-Funding-Test

Angor v0.2.29 am 4. Juni und v0.2.30 am 8. Juni sind die zwei Releases dieser Woche für das dezentrale Bitcoin-und-Nostr-Funding-Protokoll. Die Schlagzeilen-Änderung von v0.2.30 ist PR #893, der das Standard-Netzwerk auf mainnet umstellt. Angor wird immer noch als instabiles Alpha-Release ausgeliefert, aber der Default-mainnet-Wechsel signalisiert, dass das Protokoll die testnet-only-Phase für die Desktop- und Mobile-Clients hinter sich gelassen hat. v0.2.30 landet außerdem einen One-Tap-Mobile-Create-Project-Flow mit Bild-Upload und Scroll-Reset (PR #889) und löst eine Race-Condition, bei der der Lightning-Invoice-Spinner hängen konnte (PR #890).

v0.2.29 fügte in PR #881 einen End-to-End-UAT-Test hinzu, der 3-User-Send-Funds über 10 Runden mit unbestätigten Ausgaben abdeckt, den ersten Multi-User-Funding-Flow-Test in der Angor-Test-Suite. Das Release fügte außerdem einen Implementierungsplan für eine Angor-CLI und einen MCP-Server hinzu (PR #792), mit CLI-Verbesserungen für den MCP-Test-Workflow in PR #880. PR #885 von DavidGershony behob eine Boltz-Lightning-Invoice, die nach einem Runtime-Netzwerk-Switch das falsche Netzwerk verwendete, ein Bug, der nach dem v0.2.30-mainnet-Standard in der Produktion aufgetreten wäre. Die Einstellungen bieten jetzt einen optionalen Recovery-Wallet-Datei-Purge während des Data-Wipe (PR #883).

Sprout v0.3.15: TTL-Refresh für ephemere Kanäle und ACP-Slash-Commands

Sprout v0.3.15, veröffentlicht am 10. Juni, ist das achte Release in einem Lauf, der am 2. Juni mit v0.3.7 begann. Newsletter #25 behandelte den Lauf v0.3.1 bis v0.3.6 mit der mesh-llm-Integration und der Kanalabschnitt-Arbeit; v0.3.7 bis v0.3.15 sind downstream davon, fokussiert auf Politur und einige nutzerorientierte Ergänzungen. Die für Nutzer sichtbarste Änderung ist ein TTL-Refresh für ephemere Kanäle in PR #902: wenn ein Nutzer einen ephemeren Kanal wieder aktiviert, verlängert Sprout die Time-to-Live des Kanals, sodass das Unarchive nicht sofort unter dem ursprünglichen Ablauf-Timer wieder archiviert wird. Mobile Custom Emojis kommen in PR #906 neben einem Settings-Redesign an, und Reaktionszähler animieren jetzt bei Änderung (PR #904).

PR #905 behebt eine langbestehende Lücke, in der Multi-Word-Display-Namen brachen und die NIP-27 nostr:npub-Mention-Extraktion still fallen ließ. Eine verzeichnis-gestützte Team-UI für Desktop kommt in PR #912 mit Install-, Sync- und Reveal-Commands. Slash-Commands werden jetzt an ACP-Konnektoren in PR #919 durchgereicht, sodass Sprout /help-artige Commands direkt an Agent-Runtimes weiterleitet, während die Sprout-UI aus dem Pfad bleibt.

Wisp v1.1.1: Spark-Wallet-Integration und nsec-Paste-Guard

Wisp v1.1.1, veröffentlicht am 5. Juni, landet einen zweistufigen Wallet-Connect-Screen mit Spark-Sub-Screen in PR #548 und Dashboard-Parität mit der iOS-Wallet-UI in PR #549. Das Release enthält einen systemweiten nsec-Paste-Guard, der einen nsec1-präfigierten Paste-Vorgang irgendwo in der App erkennt und das Feld blockiert, es zu akzeptieren, was eines der meistzitierten Footguns in der Nostr-UX schließt. QR-Scan-Login plus ein Watch-only-Modus für npub und nprofile kommt in PR #552 und lässt einen Nutzer ein Profil nur zum Lesen durchsuchen. Zap-Nachrichten rendern jetzt als Mini-Posts im Engagement-Drawer (PR #559), sodass Zap-Notes ihren Text zusammen mit dem Sat-Betrag tragen. Ein Web-of-Trust-Filter für Thread-Antworten kommt in PR #583 und lässt Nutzer Reply-Spam von Konten außerhalb ihres Follow-Graphen ausblenden.

Nostria v3.1.46 und nospeak 1.1.3: Notification-Überarbeitung und ICE-Restart

Nostria v3.1.46 am 7. Juni beendet einen Drei-Release-Lauf, der den Notification-Counter so überarbeitete, dass nur neue Benachrichtigungen seit der letzten Ansicht gezählt werden, was eine langbestehende Inflation beseitigt, bei der das Scrollen zu älteren Benachrichtigungen den Badge-Zähler nach oben trieb. Nostria v3.1.45 behob einen Split-Payment-Bug, der Lightning- und QR-Code-Zahlungen betraf, und verwarf ein zuvor geplantes transluzentes UI als auf Androids Compositor nicht umsetzbar.

nospeak v1.1.3 am 4. Juni fügt ICE-Restart im FAILED-Zustand für 1-zu-1-Sprachanrufe hinzu. Standard-WebRTC-Verhalten wirft einen Anruf, wenn ICE-Kandidaten ohne alternativen Pfad zeitüberschreiten; der ICE-Restart-Pfad verhandelt Kandidaten neu, sodass der Anruf sich von vorübergehenden NAT- oder Netzwerkänderungen erholt. Android-Anrufe halten jetzt den Bildschirm während Videoanrufen an.

Unveröffentlichte Änderungen

Amethyst: 41 PRs setzen die NIP-32 / NIP-F4 / Tor-Spur fort

Amethyst mergte diese Woche 41 PRs ohne einen Release-Tag zu schneiden, zusätzlich zu den 52 PRs der letzten Woche und der NIP-32 Hashtag-Labeling- und NIP-F4 Podcast-Arbeit, die in Newsletter #25 behandelt wurde. Der aktive Branch sammelt weiterhin Features für das nächste getaggte Release und schichtet Politur auf die Schlagzeilen-Ergänzungen der letzten Woche: Hashtag-Labeler-Discovery, Podcast-Screen, Musiktracks und Playlists, Tor-Self-Heal-Watchdog, ephemere Signer für anonyme Uploads und Onchain-Zaps mit NIP-05-Filterung. Amethysts PR-Durchsatz bleibt der höchste jedes Nostr-Clients, und die unveröffentlichte Warteschlange ist die de-facto-Roadmap dafür, was andere Android-Nostr-Clients erreichen müssen.

Damus: Relay-Tracking aus OK-Nachrichten und v1.17-Changelog

Damus PR #3786, gemerged am 3. Juni, fügt erfolgreiche OK-Nachrichten von einem Relay zur Post-Relay-Liste hinzu. Frühere Damus-Builds befüllten die Seen-Relays-Liste nur beim Empfang einer generischen Nachricht vom Relay, was bedeutete, dass ein Relay, das den Post bestätigte, aber keine Events zurücklieferte, für den Nutzer unsichtbar war. Die Änderung ist wichtig für Nutzer, die bestätigen möchten, dass ihr Post auf ihrem bevorzugten Outbox-Relay landete. PR #3796 behebt einen AttributeGraph-Zyklus auf der Profile-Ansicht, und PR #3725 landet den v1.17-Changelog vor dem nächsten getaggten Release.

Shopstr: NIP-34 Dual-Publishing

Shopstrs shopstr-Repo auf ngit wurde diese Woche auf Nostr als NIP-34 Git-Repo angekündigt und tritt ngits getrackten Repos bei. Das GitHub-Repo des Shop-Clients bleibt die primäre Entwicklungsoberfläche; die NIP-34-Ankündigung macht einen parallelen Git-über-Nostr-Kollaborationspfad verfügbar. Dies ist das zweite große Nostr-Marketplace-Projekt, das nach Mostro doppelt zu NIP-34 veröffentlicht, und setzt die schrittweise Migration von Projekt-Metadaten auf Nostrs Git-Transport fort.

Hermes-Marmot: KI-Agent-Gateway über MLS

hermes-marmot, ein Plugin für den Hermes Agent, verbindet die Messaging-Oberfläche eines KI-Agenten mit Marmot (MLS-über-Nostr) Gruppen unter Verwendung von mdk-python, den Python-Bindings zum Rust-Marmot-Development-Kit. Das Plugin lässt einen Nutzer einem KI-Agenten aus jedem Nostr-Client, der kind 445 MLS-Nachrichten spricht, eine DM schicken, einschließlich Whitenoise. Eingehende DMs verwenden NIP-59 Gift-Wrap-Unwrapping über nostr-sdk Python-Bindings, und eingehende Welcomes fließen durch UnwrappedGift.from_gift_wrap zu mdk.process_welcome und mdk.accept_welcome. Die Zugriffskontrolle läuft über MARMOT_ALLOWED_USERS (eine kommagetrennte npub-Allowlist) oder MARMOT_ALLOW_ALL_USERS=true für offenen Entwicklungszugriff.

Das Repo ist neu (letzte Aktualisierung am 27. Mai) und klein. Seine Bedeutung ist architektonisch: es ist die erste öffentliche Brücke zwischen einer LLM-Agent-Runtime und einem MLS-verschlüsselten Nostr-Messaging-Kanal und der erste Produktions-Einsatz von mdk-python über Whitenoise selbst hinaus. Das Muster deutet auf Agent-zu-Agent-Kommunikation hin, bei der beide Endpunkte MLS-Schlüssel halten und das Relay nur Chiffretext sieht.

NIP-Updates und Protokoll-Spec-Arbeit

NIP-67 EOSE Completeness Hint (PR #2317) gemerged

PR #2317 von mattn wurde am 6. Juni gemerged und fügt NIP-67 dem Protokoll hinzu. Das NIP erweitert die EOSE-Relay-Nachricht um ein optionales drittes Element: ["EOSE", <subscription_id>, "finish"] signalisiert, dass jedes zum Filter passende gespeicherte Event ausgeliefert wurde, während ein blankes ["EOSE", <subscription_id>] keinen Vollständigkeitsanspruch trägt. Ein Relay, das den Hinweis auslässt, sagt dem Client, dass möglicherweise mehr da ist; ein Relay, das die NIP-67-Ankündigung in NIP-11 auslässt, behält das heutige Verhalten unter der bestehenden Legacy-Heuristik. Die Änderung ist in beide Richtungen abwärtskompatibel: Legacy-Clients ignorieren das nachfolgende Array-Element, und Legacy-Relays lassen es weg.

Die Motivation in der gemergten Spec ist zweifach. Erstens, stiller Datenverlust: ein Client fragt die letzten 500 Notes gegen ein Relay mit einer 300-Event-Internal-Cap ab, das Relay gibt 300 Events zurück, und der Client (unter Verwendung der Standard-received < limit-Heuristik) schlussfolgert, dass das Ergebnis vollständig ist. Die 201sten bis Nsten ältesten passenden Notes bleiben auf dem Relay ungelesen, wobei der Client blind für diese Tatsache ist. Zweitens, obligatorische verschwendete Round-Trips: wenn ein Relay Antworten auf 300 Events deckelt, erfordert jede Subskription, die den Cap ausschöpft, ein zweites REQ mit until=<oldest_created_at> rein zur Bestätigung des Abschlusses, selbst wenn der Filter zufällig genau 300 Events matcht. Beide Fehlermodi werden von jedem Client bei jeder cap-erschöpften Subskription bezahlt. Der "finish"-Hinweis ist ein optionaler String auf einer bestehenden Nachricht und eliminiert beide Kosten.

NIP-50 Autocomplete-Erweiterung (PR #2357) gemerged

PR #2357 von Alex Gleason wurde am 6. Juni gemerged und fügt ein autocomplete:true/false-Token zur NIP-50 Suche hinzu. Die Erweiterung lässt einen Client eine Anfrage als Typeahead-Lookup markieren, sodass das Relay Prefix-Matching verwendet, mit Volltext-Suche als Standard für Anfragen ohne das Token. Dittos Relay implementiert es für Follow Packs, Listen und jedes Event mit einem title-Tag und gibt Matches gegen den Titel-Präfix zurück; der Standard-Suchpfad läuft mit Volltext-Scoring. Ohne dieses Token hatten Autocomplete-artige UIs keine Möglichkeit, die Prefix-Search-Absicht zu kommunizieren, und Relays mussten aus der Anfrageform raten. Das Token ist ein Per-Search-Hinweis, keine relay-weite Capability, sodass ein Relay es für eine Event-Klasse (Titel) implementieren kann, ohne allgemeine Autocomplete-Unterstützung zu beanspruchen.

NIP-GART Notfallwarnungen und Location-Broadcasts (PR #2374)

PR #2374 von disinqa, geöffnet am 9. Juni, definiert ein datenschutzfreundliches Wire-Format auf Nostr für Notfallwarnungen und Location-Broadcasts, die an eine Gruppe vertrauenswürdiger Empfänger adressiert sind. Das angegebene Designziel ist, Sender-Identität, Gruppenmitgliedschaft und Payload vor Relay-Betreibern zu verbergen, während die Events end-to-end replay-safe und signatur-verifizierbar bleiben. Die NIP-Nummer steht noch aus, der Vorschlag ist Frühentwurf. Der Use Case ist das Standard-Notfallwarn-Muster: ein Nutzer unter Bedrohung broadcastet einen Location-Ping, den nur eine vorab geteilte Gruppe vertrauenswürdiger Kontakte entschlüsseln kann, wobei das Relay blind für Sender, Empfänger-Set und Payload ist. Wire-Format-Details leben im PR und werden sich wahrscheinlich weiterentwickeln, während Maintainer prüfen.

NIP-46 Logout-Methode (PR #2373)

PR #2373 von hzrd149, geöffnet am 8. Juni, fügt eine logout-Methode zu NIP-46 hinzu, sodass ein Client einem Bunker explizit sagen kann, dass die Session beendet ist. Bis jetzt war die einzige Möglichkeit, eine Bunker-Session zu beenden, auf den Session-Timeout zu warten oder aufzuhören, die Verbindung zu nutzen, wobei beides den Bunker mit Session-State für einen Client zurücklässt, der weg ist. Der Vorschlag ist kurz (eine neue Methode) und die Art von Housekeeping-Änderung, die langlebige Bunker-Integrationen sauberer macht.

NIP-95 Hybrid-Relay-P2P-Vorschlag als Long-Form zirkuliert

Eine Long-Form-NIP-95-Spezifikation zirkulierte als kind:30023-Post von npub 91bea5cd9361504c409aaf459516988f68a2fcd482762fd969a7cdc71df4451c am 4. Juni unter dem Titel Protocolo Híbrido Relay-P2P via WebRTC. Das portugiesischsprachige Dokument definiert ein hybrides Peer-to-Peer-Relay-Protokoll, bei dem Nostr-Clients sich für Live-Messaging direkt über WebRTC verbinden, während sie weiterhin Relays für Stored-Event-Retrieval und Offline-Zustellung verwenden. Der Autor formulierte die Spec explizit als “LLM-ready”, und lieferte Nachrichten-Definitionen, logische Flows, Datenschemata und Zustandsregeln in einem Detailgrad, der einem KI-Modell erlaubt, funktionierenden Client- oder Server-Code zu generieren. Der Vorschlag ist noch nicht als NIP-PR gelandet; die Zirkulation über kind:30023 ist der übliche Vorläufer eines formalen nostr-protocol/nips Pull Requests.

NIP-44 v3 gewinnt einen zweiten Signer: Clave portiert die Spec

Ambers v6.2.0-NIP-44-v3-Rollout von letzter Woche wurde vor jedem gemergten NIPs-PR ausgeliefert und ließ v3 als Amber-spezifische Erweiterung zurück, die andere Clients spiegeln mussten, um zu interoperieren. Dieses Single-Implementation-Framing änderte sich diese Woche. Clave, der push-basierte iOS-NIP-46-Remote-Signer, landete am 3. und 4. Juni über acht Commits einen unabhängigen NIP-44-v3-Port. Kryptografische Primitive kommen in drei Commits: HKDF + ECDH keys layer, der v3-Padding-Algorithmus und eine Top-Level-Public-API plus Verschlüsselungs-Context. Darauf folgt die NIP-46-Oberfläche in RPC-Dispatch-Verdrahtung innerhalb LightSigner und einem PendingRequest-Schema, das den v3-Kontext (kind plus scope) trägt, sodass der Signer aufzeichnen kann, für welches Event-kind und welchen Anwendungsfall die v3-Payload genehmigt wurde.

Clave weicht auf der nutzerorientierten Oberfläche von Amber ab. Ein Berechtigungserteilungs-Schema mit Sensitivity-Tiers lässt Nutzer v3-Verschlüsselung für ein bestimmtes Event-kind und einen bestimmten Scope auf einer gewählten Sensitivity-Stufe erteilen. Bei erster Begegnung führen v3-context-aware Approval-Prompts mit einer einmaligen Explainer-Card v3 den Nutzern vor. Die Arbeit ist in main und ist in das Xcode-Projekt verdrahtet, aber unveröffentlicht; der jüngste getaggte Build ist v0.2.0-build79 vom 12. Mai.

Zwei unabhängige Implementierungen landen NIP-44 v3 in Produktionspfaden, bevor der NIPs-PR merged, was den Fall für das zugrunde liegende Wire-Format stärkt, das der Protokoll-PR formalisieren wird. Cross-Implementation-Interop-Tests werden jetzt der Pfad zur Spec-Konvergenz, mit Ambers Android-Approval-Oberfläche und Claves iOS-Sensitivity-Tier-Modell als den zwei Referenzpunkten. Weitere Remote-Signer, die v3 verdrahten (nsec.apps noauth ist seit Mai 2025 dormant, und andere Bunker haben keine v3-Arbeit angekündigt), würden den Konsens weiter festigen.

NIP-34-Aktivität: Iris übernimmt den Stack mit einem neuen Hashtree-Transport

Iris veröffentlichte NIP-34 Repo-Ankündigungen für hashtree am 8. Juni und für iris-apps, iris-drive und iris-chat-rs am 9. Juni, und wirbt für Clone-URLs unter einem neuen htree://-Schema, das von wss://temp.iris.to bedient wird. Der Hashtree-Transport ist eine content-adressierte Alternative zu GRASP-gerouteten Clones, und diese vier Ankündigungen sind seine ersten öffentlichen Verwendungen. Die Repos tragen leere Beschreibungen und die architektonischen Details entstehen noch, aber die Wahl, über NIP-34-Ankündigung zu veröffentlichen (statt einem benutzerdefinierten Iris-internen Manifest), signalisiert, dass Iris sich zum breiteren NIP-34-Git-über-Nostr-Stack bekennt.

NIP Deep Dive: NIP-67 (EOSE Completeness Hint)

NIP-67 schließt eine der langbestehenden Korrektheitslücken in NIP-01. Die ursprüngliche Spec definiert EOSE als die Grenze zwischen gespeicherten Events und Live-Subscription-Events für ein REQ, aber sie spezifizierte nie, ob das Relay die Auslieferung aller gespeicherten Matches beendet oder wegen einer internen Deckelung auf halbem Weg gestoppt hatte. Jedes Relay erzwingt eine Per-Subscription-Deckelung (üblicherweise 300 bis 1000 Events) unabhängig vom limit des Clients, und Clients hatten keine Möglichkeit, diese Deckelung zu beobachten.

Der Standard-Workaround war, den empfangenen Count gegen das angeforderte limit zu vergleichen. Wenn received < limit, behandle das Ergebnis als vollständig; sonst paginiere mit until=<oldest_created_at>. Beide Branches sind kaputt. Der received < limit-Branch trunkiert still: ein Client, der 500 Notes gegen ein auf 300 gedeckeltes Relay abfragt, sieht 300 Events, schlussfolgert, dass das Ergebnis vollständig ist, weil 300 < 500, und holt den Rest nie ab. Auf dem Relay gehaltene Events können “mehr verfügbar” durch keine bestehende Nachricht signalisieren. Paginierung als zweiter Branch ist verschwenderisch: ein Filter, der genau die Deckelung matcht, erfordert ein zweites REQ zur Bestätigung der Vollständigkeit, das null Events zurückgibt, während ein voller Filter-Scan auf dem Relay konsumiert wird.

NIP-67s Fix ist ein optionaler String auf der EOSE-Nachricht:

["EOSE", "<sub_id>", "finish"] // explicit: all stored events delivered
["EOSE", "<sub_id>"] // no completeness claim

Ein Relay, das NIP-67 in NIP-11 supported_nips bewirbt und ein blankes EOSE aussendet, sagt dem Client, dass es mehr gibt. Ein Relay, das die Ankündigung auslässt, behält das heutige Verhalten, und der Client fällt auf die bestehende Heuristik zurück. Legacy-Clients ignorieren das nachfolgende Array-Element. Abwärtskompatibilität hält in beide Richtungen, ohne neue Verben oder Event-kinds.

Was NIP-67 der Untersuchung wert macht, ist der Umfang, den es bewusst einschränkt. Die Spec definiert keinen Cursor oder Paginations-Token, sodass until-basierte Paginierung der Mechanismus bleibt. Relay-Deckelungen bleiben, wo sie sind, und das NIP verlangt keine Offenlegung davon. NIP-67 bewahrt die Bedeutung von EOSE als die Stored-to-Live-Grenze und fügt nur ein Yes-or-No-Signal an der Grenze hinzu: “Ich habe mehr für dich” gegen “das ist alles.” Diese minimale Oberfläche ist der Grund, warum der PR nach einem relativ kurzen Review-Zeitraum für eine NIP-01-Erweiterung merged, und warum mattn im PR explizit anmerkt, dass KI-Übersetzung für den englischen Text verwendet wurde. Die Änderung ist klein genug, dass die Übersetzungs-Unsicherheit keine Rolle spielt.

Beispiel eines NIP-67-bewussten Austauschs zwischen einem Client und einem cap-erzwingenden Relay. NIP-11-Ankündigung vom Relay:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 11,
 "tags": [],
 "content": "{\"supported_nips\":[1,11,50,67]}",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Der Wire-Level-Austausch, der folgt:

→ ["REQ", "abc", {"kinds":[1],"limit":500}]
← [...300 EVENT messages...]
← ["EOSE", "abc"] // no "finish": cap hit, more available
→ ["REQ", "def", {"kinds":[1],"limit":300,"until":1780900000}]
← [...178 EVENT messages...]
← ["EOSE", "def", "finish"] // explicit complete

Die 178-Event-Antwort hätte zuvor ein drittes REQ zur Bestätigung des Abschlusses ausgelöst. Mit NIP-67 stoppt der Client dort.

NIP-67 ist auch bemerkenswert als NIP-01-Änderung, die mit seltenem Konsens landet. Die meisten NIP-01-Änderungen ziehen lange Debatten-Threads an, weil die winzige Oberfläche des Protokolls für jede Implementierung tragend ist. NIP-67 wurde nach einem erweiterten Review-Zeitraum gemerged (etwa sieben Wochen von Öffnung bis Merge), was nahelegt, dass wenn eine NIP-01-Änderung klein genug ist und der Fehlermodus konkret genug ist (stiller Datenverlust, obligatorischer verschwendeter Round-Trip), die Maintainer des Protokolls bereit sind, das Kern-Nachrichten-Vokabular zu erweitern.

NIP Deep Dive: NIP-50 (Suche)

NIP-50 definiert das search-Filterfeld in REQ-Nachrichten, wodurch Clients ein Relay bitten können, Events per Volltext-Match gegen einen Query-String zu filtern. Die gemergte Basis-Spec ist bewusst minimal: das search-Feld ist ein String, jedes Relay entscheidet seine eigene Such-Semantik (welche Felder indexiert werden, wie Scoring funktioniert, ob Stemming angewendet wird), und Relays bewerben NIP-50-Unterstützung in ihrem NIP-11-Dokument. Clients kontrollieren den Suchalgorithmus nur durch den Query-String selbst.

Dieser Minimalismus ist sowohl NIP-50s Stärke als auch seine Einschränkung. Die Stärke ist, dass jedes Relay Suche auf jeder Qualitätsstufe implementieren kann: ein einfacher Substring-Scan erfüllt die Spec, und ein Relay, das Elasticsearch oder Meilisearch betreibt, erfüllt sie gleichermaßen. Die Einschränkung ist, dass Clients keine Möglichkeit haben, Suchabsicht auszudrücken. Eine Profile-Mention-Typeahead-UI möchte Prefix-Matching gegen Display-Namen; eine Volltext-Content-Suche möchte tokenisiertes Volltext-Scoring über den Note-Body. Dasselbe search-Feld trägt beides, und das Relay muss aus der Anfrageform raten.

PR #2357 fügt das erste NIP-50-Erweiterungs-Token hinzu: autocomplete:true oder autocomplete:false, eingebettet in die Such-Anfrage, signalisiert, welchen Modus der Client möchte. Dittos Relay implementiert das Token für Follow Packs, Listen und jedes Event mit einem title-Tag und wechselt zu Prefix-Matching, wenn autocomplete:true vorhanden ist. Das Token lebt inline in der Anfrage (separate Filter-Felder bleiben unberührt), sodass es mit dem Such-String reist und keinen Wire-Protokoll-Bump erfordert:

search: "fiat autocomplete:true"

Token-förmige Hinweise wie dieser sind, wie NIP-50 immer schon relay-spezifische Dialekte gehandhabt hat. Relays unterstützten bereits Tokens wie language:en und domain:example.com. Jedes bleibt relay-spezifisch, wobei jedes Relay seinen eigenen Dialekt dokumentiert. NIP-50s PR #2357 hebt autocomplete von einem relay-privaten Token zu einem spec-gesegneten und ebnet den Weg für Typeahead-bewusste Suche über Relays hinweg.

Beispiel eines NIP-50 REQ mit dem Autocomplete-Token, gerichtet auf ein Relay, das kind 0 Profil-Titel indexiert:

{
 "id": "b7c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 1,
 "tags": [
 ["client", "example-mention-picker"]
 ],
 "content": "Sent search: kinds=[0], search=\"fiat autocomplete:true\", limit=10",
 "sig": "12d3e4f5061728394a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5e6f7081a2b3c4d5e6f708192"
}

Der tatsächliche Wire-Level-REQ:

["REQ", "mention-picker", {"kinds":[0],"search":"fiat autocomplete:true","limit":10}]

Ein Relay, das das Token nicht erkennt, behandelt autocomplete:true als Teil des wörtlichen Such-Strings und fällt auf Volltext-Matching zurück und gibt korrekte (wenn auch anders gerankte) Ergebnisse zurück. Die grazile Degradation macht das Token sicher, es bedingungslos einzuschließen für Clients, die Prefix-Matching bevorzugen, wenn verfügbar.

Die nächste wahrscheinliche NIP-50-Erweiterung ist Per-kind-Ranking-Kontrolle: ein Hinweis, der sagt “rank by created_at descending” gegen den Standard-Relevance-Score. Mehrere Relays akzeptieren bereits sort:newest als relay-privates Token, und derselbe Aufwertungspfad, der autocomplete in die Spec brachte, gilt. Suche bleibt eines der wenigen Nostr-Primitive, bei denen Relays um Ergebnisqualität konkurrieren; die Zuverlässigkeit der Zustellung ist bei allen konformen Relays gleich. Inkrementelle Tokens lassen Clients diese Qualitätskonkurrenz nutzen, ohne Relays zu zwingen, eine schwergewichtige neue Spec auszuliefern.

Nostr Compass #25

Wed, 03 Jun 2026 00:00:00 +0000

Amber 6.2.0 liefert NIP-44 v3 Verschlüsselung vor der Spezifikation aus. Mostro landet über acht PRs das Fundament für Cashu-abgewickelten Escrow und wrappt das bestehende Cashu Development Kit als zweites Settlement-Backend neben Lightning. NIP-F4 Podcasts wird nach 27 Monaten Debatte gemerged. fiatjaf öffnet einen umstrittenen NIP-17-Key-Decoupling-Vorschlag, der das Bunker-gegen-Marmot-Architekturargument wieder öffnet. Amethyst landet NIP-32 Hashtag-Labeling, einen dedizierten Podcast-Screen und Onchain-Zaps über 52 unveröffentlichte PRs.

Top-Stories

Amber 6.2.0: NIP-44 v3 Verschlüsselung ausgeliefert

Amber v6.2.0, veröffentlicht am 1. Juni, fügt NIP-44 v3 Verschlüsselungsunterstützung mit einem dedizierten Zustimmungs-Screen, Intent-Vorschau, Bunker-Vorschau, History-Logging und Auto-Reject für ungültige Anfragen hinzu. Das Release registriert außerdem NIP-44 v3 ContentProvider-Authorities, sodass andere Android-Apps v3-Verschlüsselung neben dem bestehenden v2-Pfad anfordern können. NIP-44 selbst ist die versionierte Encrypted-Payload-Spezifikation, die von NIP-17 privaten DMs, NIP-46 Bunker-Verkehr und anderen Nostr-Primitiven verwendet wird; v3 in Amber ist ein Opt-in neben v2, signalisiert durch eine separate Signer-Methode, sodass empfängerseitige Clients den Algorithmus explizit aushandeln können. Der entsprechende NIPs-PR ist noch nicht gelandet, sodass Amber v3 vor dem Protokoll-Konsens ausrollt, wobei das Wire-Format und die ContentProvider-Authority für die Downstream-Client-Integration registriert sind.

NIP-46-Sitzungen akzeptieren jetzt automatisch Ping-Anfragen beim Verbinden und entfernen den Prompt beim ersten Round-Trip nach dem Pairing. Die sign_message-Signer-Methode wurde vollständig entfernt, nachdem sie deprecated und ungenutzt war.

Da Amber der dominante Android-Signer ist, muss jeder Downstream-Client, der v3 möchte, Ambers Wire-Format anvisieren, bis der NIPs-PR landet. Das gibt Amber implizites Mitspracherecht bei der endgültigen v3-Spezifikation, bis das Protokoll aufholt. Der Trade ist real: v3 in Produktion lässt Amber Implementierungs-Feedback für das schließliche NIP sammeln, zum Preis eines temporären Single-Implementation-Referenzpunkts, an den sich andere Clients jetzt anpassen müssen.

Mostro: Cashu-Escrow-Integration per CDK

grunch landete diese Woche acht PRs über MostroP2P, die Cashus bestehende P2PK-Multisig-Primitive (NUT-10 und NUT-11) als zweites Settlement-Backend neben Lightning auf dem Nostr-koordinierten P2P-Bitcoin-Exchange integrieren. Die kryptografischen Primitive sind Cashus; die Arbeit ist Integrations-Scaffolding und ein neuer Escrow-Backend-Trait. Mostro core v0.12.0, veröffentlicht am 30. Mai, fügt die Protokoll-Typen für 2-von-3-Multisig-Escrow, Per-Proof P_M-Signaturen hinzu und erlaubt Escrow-Events durch die Response-Validierung. Die Architektur ist in PR #756 dokumentiert und verwendet Per-Order-Trade-Keys, geklärt in PR #757.

Die Implementierung wurde über sechs Follow-up-PRs an einem einzigen Tag ausgerollt. F2 (PR #758) fügte die Konfiguration, den Escrow-Modus und den bedingten Boot hinzu. Die nächste Scheibe, F3 (PR #760), definierte einen EscrowBackend-Trait mit einer Lightning-Implementierung und einem Cashu-Stub, sodass Mostro Settlement-Backends wechseln kann, ohne die Order-State-Machine zu ändern. F4 (PR #759) wrappte CDK (das Cashu Development Kit) für Mint- und Wallet-Operationen. Datenbankarbeit in F5 (PR #761) fügte Compare-and-Swap-Escrow-Locks und Active-Locked-Queries hinzu. F6 (PR #762) baute ein containerisiertes Mint in einem dedizierten CI-Job für End-to-End-Escrow-Tests. Der Mostro-Flow verwendet bereits NIP-59 gift-wrapped DMs zur Order-Koordination über das Relay, sodass Cashu-Escrow als zweite Settlement-Option neben Lightning einrastet, ohne das Wire-Protokoll zu berühren.

Releases

ngit v2.5.0: GRASP-Fallback und lazy Git-Fetches

ngit v2.5.0 ändert das Standardverhalten von git push pr/<branch> und ngit send, um bei neuen Vorschlägen ein PR-kind zu erzeugen, wenn im Repository mindestens ein GRASP-Server registriert ist. Zuvor wurde dies nur bei übergroßen Commits über 60 KB oder Commits mit Submodulen ausgelöst. Wenn ein PR nicht an die GRASP-Server des Repositorys gepusht werden kann, fällt ngit jetzt auf GRASP-06-Routing über die deklarierten Server zurück. Das ngit send --git-server-Flag oder git push -o git-server=<url> erlaubt es Beitragenden, eine benutzerdefinierte Git-URL oder einen GRASP-Server explizit anzuvisieren.

ngit init Republishes bewahren jetzt unbekannte Tags aus bestehenden Ankündigungen, sodass Tags, die von einer zukünftigen ngit-Version oder einem Drittanbieter-Tool hinzugefügt wurden, den Republish überleben. Eine gelbe Warnung listet die übertragenen Tags, und --clean entfernt sie auf Anfrage. ngit pr apply, ngit pr checkout und ngit pr list konsultieren Git-Server lazy und teilen sich einen einzigen Fetch-Helper, sodass Checkout nicht mehr bedingungslos fetcht, wenn der Commit bereits lokal ist. ngit pr checkout probiert auch vom Einreicher gelieferte Clone-URLs aus dem PR-Event als Fallback, wenn die deklarierten Git-Server des Repos die PR-Spitze nicht tragen, und passt so das bestehende Verhalten in ngit pr apply an. ngit ist die Referenz-NIP-34-Implementierung für Git-Zusammenarbeit über Nostr, und v2.5.0 macht GRASP zum First-Class-Pfad für neue Beitragende.

Jumble v26.5.7: EXIF-Stripping und validierte Zap-Zählungen

Jumble v26.5.7 fügt zwei Änderungen hinzu, die die Privatsphäre und Datenintegrität der Nutzer direkt betreffen. EXIF-Standort- und Kamera-Identifikatoren werden jetzt vor dem Verlassen des Clients aus Bild-Uploads entfernt, was eine langbestehende Metadata-Leak-Oberfläche schließt, die jedes von Jumble gepostete Bild betraf. Zap-Zählungen werden jetzt nur aus kryptografisch validierten Quittungen berechnet, was aufgeblähte Zählungen aus fehlgeformten Zap-Events behebt, die Angreifern erlaubten, Zap-Gesamtwerte an Notes zu übertreiben. Das Release fügt außerdem Sender-Identity-Verifikation für NIP-17-DMs hinzu, was eine Spoofing-Oberfläche schließt, in der ein Absender seinen pubkey im Seal fälschen konnte.

nostr-calendar v1.6.0: RSVP und Duplikat-Teilnehmer-Handling

nostr-calendar v1.6.0 landet Formstrs RSVP-Flow (PR #169) und verhindert Duplikat-Teilnehmer in Event-Einladungen (PR #168). Die waitForAll-Option in der Publish-Funktion ist jetzt standardmäßig false, sodass die UI nicht bei langsamen Relays blockiert (PR #170). PR #157 lieferte Formstrs zwei NIP-Vorschlagsentwürfe für Terminplanung und Reservierungen.

Sprout 0.3.6: Sprout × mesh-llm und Kanalabschnitte

Sprout v0.3.6 ist die Schlagzeile eines Sechs-Release-Laufs von v0.3.1 bis v0.3.6 diese Woche. In-Process Sprout × mesh-llm Integration landet in PR #798 und lässt Sprout mesh-llm-Nodes über Relay-Zulassung bereitstellen und konsumieren. Benutzerdefinierte Kanalabschnitte synchronisieren über Geräte hinweg über Nostr in PR #792, und Kanalabschnitte kommen mit Relay-Sync auf Mobile in PR #800. Thread-bewusste Benachrichtigungen mit veränderlichen Follow- und Mute-Kontrollen kommen in PR #761 an.

Anhänge beliebiger Dateitypen mit Download-Karten kamen in PR #810 an und erweiterten Sprout über reine Bild-Anhänge hinaus. Mobile gewann einen Pulse-Social-Feed-Tab (PR #772) und Pulse-Politur über Feed-, Compose- und Filter-Oberflächen hinweg (PR #796).

NostrBotKit v0.5.0: Marmot-Gruppenchat in einem Rust-Bot-Framework

NostrBotKit v0.5.0, veröffentlicht am 24. Mai auf Codeberg, fügt Marmot-Unterstützung (MLS-über-Nostr, NIP-104) zum selbstgehosteten Rust-Bot-Framework hinzu. Wenn marmot: true gesetzt ist, veröffentlicht der Bot seine MLS-Key-Packages (kind 443, 30443, 10051), akzeptiert Gruppeneinladungen automatisch und lauscht auf Nachrichten in beigetretenen Gruppen. Zwei neue Command-Typen, dm_marmot und dm_marmot_npub, lassen Bots Nachrichten in benannte Marmot-Gruppen oder 1:1 Marmot-Chats per Cron-Jobs oder Webhooks senden. Um Feedback-Loops mit anderen Bots zu verhindern, antworten NostrBotKit-Bots nur auf Nachrichten, die explizit an sie adressiert sind, per /command oder @botname/command. Verschlüsselte Anhänge, die MIP-04 verwenden, werden automatisch entschlüsselt und per Blossom oder NIP-96 neu hochgeladen, und die MLS-Zustandsdatenbank wird mit einem aus dem privaten Schlüssel des Bots abgeleiteten Schlüssel verschlüsselt. NostrBotKit ist das erste Rust-Framework, das NIP-104-Bot-Unterstützung ausliefert und Marmot-verschlüsseltes Bot-Deployment einem anderen Operator-Profil öffnet als dem bestehenden TypeScript-Pfad.

noscrypt v0.1.14: signiertes Kryptografie-Bibliotheks-Release

noscrypt v0.1.14 ist ein Security-Release der C-Kryptografie-Bibliothek, die von mehreren Nostr-Clients für secp256k1-, NIP-04- und NIP-44-Primitive verwendet wird. Das Release wird mit PGP-signierten Downloads ausgeliefert, die gegen den Public Key des Maintainers verifizierbar sind. Downstream-Clients, die noscrypt bundeln, sollten die Signatur vor der Integration validieren.

Chama v1.3.0: neuer Nostr-nativer P2P-Escrow mit Fedimint

Chama v1.3.0, veröffentlicht am 1. Juni, ist die Schlagzeile eines Vier-Release-Laufs für einen neuen Nostr-nativen P2P-Escrow-Client, der Fedimint-Ecash und 2-von-3 Shamir-Secret-Sharing für Settlement verwendet. Das Projekt läuft unter getchama.app und funktioniert ohne Server. v1.3.0 führt “Heal that Sticks” ein (erfolgreiches Re-Broadcasten und Trade-Healing, das Session-Neustarts überlebt) und Pay-Rail-Matching, bei dem US-orientierte Chamas US-Zahlungsschienen zuerst anzeigen. Multi-Unit-Storefront-Grundlagen landeten über v1.2.11 (Multi-Unit-Schema) und v1.2.12 (Storefront-Stock-Accountant + native Fedimint-Bridge-Recovery-Härtung). Chama gesellt sich zu Mostro und Shopstr in der Nostr-Marketplace-Kategorie, unterschieden durch seine serverlose Architektur und Fedimint-basierte Escrow-Abwicklung.

Unveröffentlichte Änderungen

Amethyst: NIP-32 Hashtag-Labeling, Podcast-Screen, Musiktracks

Amethyst mergte diese Woche 52 PRs und 411 Commits, ohne einen Release-Tag zu schneiden. Die größte funktionale Ergänzung ist PR #3111, der NIP-32 Hashtag-Labeling und einen Label-basierten Hashtag-Feed mit kind 1985 Events mit L-Namespace- und l-Label-Tags implementiert. Dies ersetzt den brüchigen Text-Match-#tag-Mechanismus durch ein labeler-basiertes Discovery-Modell, in dem Nutzer bestimmten Labeler-npubs so folgen können, wie sie Content-Erstellern folgen. PR #3105 fügt einen dedizierten Podcast-Screen mit Episodenliste und Inline-Player hinzu, und landet innerhalb von Tagen nach dem Merge der NIP-F4 Podcast-Spec. PR #3071 fügt einen Software-Apps-Feed mit Follow-List-Filterung hinzu, und PR #3067 fügt Unterstützung für Musiktracks und Playlists über NIP-51 Sets hinzu.

Ephemere Signer für anonyme Post-Uploads landen in PR #3123 und lassen Nutzer anonym posten, ohne ihren Identity-Key an Upload-Services preiszugeben. Ein Tor-Self-Heal-Watchdog mit Integrationstests gegen Arti v2.3.0 kommt in PR #3053 an und stärkt Amethysts Tor-Routing bei vorübergehenden Netzwerkausfällen. Onchain-Zaps und ein NIP-05-Filter für zurückkehrende Nutzer aus Gemini landen in PR #3052 und erweitern die Zap-Oberfläche über Lightning hinaus auf Onchain-Bitcoin-Zahlungen.

Shopstr: OpenGraph-Preview-URL-Validierung

PR #504 validiert OpenGraph-Preview-URLs vor dem Rendern in Marketplace-Listings und schließt eine potenzielle XSS-Oberfläche, in der böswillige Verkäufer skriptbaren Content über gefertigte OG-Metadaten einbetten konnten. Shopstr-gehostete Shops zeigen OG-Vorschauen für externe Links, und unvalidierte URLs erlaubten einem Angreifer, beliebigen Inhalt in die Shop-UI zu injizieren.

NIP-Updates und Protokoll-Spec-Arbeit

NIP-F4 (Podcasts) nach zwei Jahren gemerged

PR #1093 wurde am 28. Mai gemerged, zwei Jahre und drei Monate nachdem fiatjaf den ursprünglichen Entwurf geöffnet hatte. NIP-F4 definiert Podcast-Episoden als kind 54 Events mit imeta Tags für Audio-Datei-Metadaten (URL, MIME-Typ, ISO-Sprachcode, Fallback-URLs, NIP-96 Service-Flag, Bitrate, Dauer), einem title Tag, optionalen image und description Tags sowie t Tags für Topic-Labels. Die Spec behält bewusst RSS als Source of Truth: Episoden können ein i Tag tragen, das auf die RSS-Podcast-GUID verweist, wodurch Nostr-Clients zu bestehenden Podcast-Feeds verlinken können, ohne Audio-Hosting zu duplizieren. Die lange Debatte im PR-Thread (mit dem Podcast-Namespace-Co-Autor Dave Jones, Alex Gleason und Mike Terenzio) einigte sich auf ein Koexistenz-Modell, in dem Nostr die soziale Schicht auf RSS bereitstellt, während RSS die Verteilungsschicht behält. Amethysts PR #3105 Podcast-Screen landet innerhalb von Tagen nach dem Spec-Merge, und Jumbles GIF-Picker-Arbeit enthält auch frühes Podcast-Attachment-Scaffolding.

NIP-17-Key-Decoupling (PR #2361)

fiatjaf öffnete PR #2361 am 1. Juni und schlug vor, dass NIP-17 den Identity-Key vom Encryption-Key trennt. Empfänger kündigen ihren Encryption-Key in einem neuen kind 10044 Event an, und Sender verwenden diesen angekündigten Key (falls vorhanden) für das Gift-Wrap-Inner-Seal und fallen nur dann auf den Identity-Key des Empfängers zurück, wenn die Ankündigung fehlt. Der PR fügt außerdem ein n Tag zum Seal hinzu, das den Encryption-pubkey des Senders trägt, sodass Empfänger den korrekten Konversationsschlüssel ableiten können, ohne Trial-Decryption gegen jeden ausrangierten Key durchführen zu müssen. Die erklärte Motivation ist Bunker-UX: unter dem aktuellen Design muss ein Bunker-Nutzer jede empfangene DM zum Entschlüsseln über den Signer roundtrippen, da der Encryption-Key der Signer-gehaltene Identity-Key ist. Die Entkopplung lässt den Client den Encryption-Key lokal halten, während der Identity-Key im Bunker für Signaturen bleibt.

Der Vorschlag zog das umstrittenste Review der Woche an. Cody Tseng (Jumble) unterstützt ihn als den einfachsten Weg zu Cross-Client-DM-Interop. Vitor Pamplona (Amethyst) hat zwei Einwände: Er fügt ein neues langlebiges Entschlüsselungs-Geheimnis außerhalb des Bunkers hinzu, und Clients, die es nicht ausliefern, werden Nachrichten von Clients, die es tun, stillschweigend nicht mehr entschlüsseln, ohne Degradations-Pfad, weil der Bruch auf der Seal-Ebene liegt. Pamplona argumentiert, dass das Problem bereits korrekt durch Marmots Key-Packages und Epoch-Rotation gelöst ist, und dass das nachträgliche Einbauen der Key-Trennung in die Basis-NIP-17-Spec die Art von Interop-Fehler erzeugt, um die Marmot zwei Jahre lang engineeren musste. fiatjafs Gegenrede hat drei Teile: Entkopplung ist optional pro Empfänger, der n-Tag-Fix adressiert die Trial-Decryption-Sorge, und die Alternative ist, Bunker-UX kaputt zu halten, während Telegram den Messaging-Use-Case frisst. Der Thread bleibt ohne Merge-Entscheidung offen und ist die meistbeobachtete NIP-Diskussion des Quartals.

NIP-Silent-Payments Payment-Flow (PR #2362)

silentius-satoshi öffnete PR #2362 am 1. Juni als Begleiter zum breiteren Nostr Silent Payments NIP-Entwurf (PR #2355). Das Payment-Flow-NIP definiert kind 8352 für Silent-Payment-Empfangsbenachrichtigungen (ausgeliefert per NIP-59 Gift Wrap, damit der Empfangslink nicht öffentlich beobachtbar ist) und kind 10353 für einen verschlüsselten UTXO-Cache, der über Geräte für dieselbe Silent-Payments-Wallet synchronisiert. Das Paar zusammen lässt einen Zahler eine Zahlung an eine Silent-Payments-Adresse mit Nostr-nativen Primitiven signalisieren, ohne den On-Chain-Link auf der offenen Relay-Ebene preiszugeben.

NIP-PIP Perfect IP Packets (PR #2364)

RandyMcMillan öffnete PR #2364 am 1. Juni als Entwurf. Er führt einen Paket-Baum-Transport mit drei neuen adressierbaren kinds ein: 39078 trägt das Manifest, 39079 trägt einzelne Slices, und 39080 trägt Reparatur-Anfragen. Die Spec definiert ein Wire-Format, in dem große Dateien in adressierbare Slices zerlegt werden, mit Manifesten, die den Slice-Baum beschreiben, und Reparatur-Anfragen, die Empfängern erlauben, fehlende Slices anzufordern. Frühentwurfsstatus gilt, und der Vorschlag hat noch keine Maintainer-Review angezogen.

NIP-29 Audio/Video Live Spaces (PR #2238)

PR #2238 wurde am 28. Mai gemerged und erweitert NIP-29 relay-basierte Gruppen um Audio- und Video-Live-Space-Unterstützung. Gruppen können jetzt auf eine aktive Live-Space-Session verweisen, wodurch NIP-53-artige Live-Activity-Events in einem NIP-29-Gruppenkontext verankert werden können.

NIP-71 Video Multiple Audio Tracks (PR #2255)

PR #2255 wurde am 28. Mai gemerged und fügt Audio-Track-imeta Tags zu NIP-71 Video-Events hinzu. Das neue Format trägt URL, Hash, MIME-Typ, Sprach-Tag (mit ISO-639-1 plus Original-Version-Flag), Fallback-URLs, NIP-96 Service-Signal, Bitrate und Dauer. Das ermöglicht Audio-only Streaming (Video-Podcasts), Auflösungswechsel mit stabilem Audio, mehrere Sprachtracks und reduzierten Speicher, wenn Server Audio nicht direkt in Video-Dateien einbetten. Clients sollten die Audio-Track-Verfügbarkeit prüfen, bevor sie Single-Track-Verhalten annehmen.

NIP-59 Ephemeral Gift Wrap (PR #2245)

PR #2245 wurde am 28. Mai gemerged und fügt kind 21059 als ephemeres Gegenstück zum bestehenden kind 1059 Gift Wrap hinzu. Die Semantik entspricht dem Standard-NIP-59-Wrap, folgt aber ephemeren Event-Regeln gemäß NIP-01 (Relays lassen sie nach dem Broadcast fallen und persistieren sie nicht). Damit können Apps Persistenz basierend auf Anforderungen wählen: Tipp-Indikatoren und Presence-Pings profitieren von Ephemeral, während DM-Historie Persistenz braucht.

NIP-78 Application-Specific Kind (PR #2292)

PR #2292 wurde am 28. Mai gemerged und klassifiziert NIP-78 anwendungsspezifische Daten neu als normales adressierbares kind, wobei der vorherige separate Bereich aufgegeben wird. Dies vereinfacht die Replaceability-Semantik und richtet NIP-78 mit dem adressierbaren Event-Modell aus, das von anderen Anwendungszustand-NIPs verwendet wird.

NIP-85-Klärungen (PR #2304)

PR #2304 wurde am 28. Mai gemerged, mit kleinen Verbesserungen der Sprache rund um mehrere Keys und Relays pro Service-Provider in NIP-85 Trusted Assertions, und klärt den Operator-Key-Rotation-Pfad für Relay-Assertion-Services.

NIP-01 Relay-Connection-Management-Einzeiler (PR #2307)

PR #2307 wurde am 28. Mai gemerged und fügt einen einzigen Satz zu NIP-01 darüber hinzu, wie Clients Relay-Verbindungs-Lebensdauern handhaben sollen. Der Fix adressiert eine langlaufende Lücke, in der Clients uneinig waren, ob WebSocket-Verbindungen nach dem Fetchen offen bleiben sollten, was zu stillem Nachrichtenverlust auf Relays führte, die Idle-Verbindungen fallen lassen.

NIP-C7 Kind 9 Chat-Beschränkung (PR #2310)

PR #2310 wurde am 28. Mai gemerged und beschränkt NIP-C7-Chat-Ansichten auf ausschließlich kind 9 Nachrichten. Das trennt ephemeren Chat von kind 1 Timeline-Posts in Clients, die NIP-C7-artige Chat-Oberflächen implementieren.

NIP-55-Vereinfachung (PR #2363)

PR #2363 von greenart7c3, geöffnet am 1. Juni, vereinfacht die Android-Signer-Anwendungsspec. Vitor Pamplona gab “Looks good” als Zustimmung, und fiatjaf fragte, ob er bereit zum Mergen ist. Die Änderung ebnet den Weg für die NIP-44 v3 ContentProvider-Authority-Registrierung, die Amber diese Woche ausgeliefert hat.

NIP-44 v3 (Amber-Implementierung vor der Spec)

Amber lieferte NIP-44 v3 in v6.2.0 mit acht Commits aus, die das Verschlüsselungs-Upgrade und die ContentProvider-Authority-Registrierung implementieren, aber der NIPs-Repo-Spec-PR ist noch nicht gelandet. NIP-44 selbst definiert ein versioniertes Encrypted-Payload-Format, das innerhalb signierter Events verwendet wird; das bestehende v2 (seit 2024 in Produktion) verwendet secp256k1 ECDH, HKDF, Padding, ChaCha20, HMAC-SHA256 und base64. Das v3-Wire-Format fügt ein neues Versions-Byte (0x03) vor der Nonce hinzu, wodurch Empfänger-Clients den Algorithmus explizit aushandeln können. Ambers Implementierung enthält Auto-Reject für ungültige v3-Anfragen, einen dedizierten Zustimmungs-Screen, der sich von v2-Zustimmungen unterscheidet, und Per-Direction-Klartext-Logging für die History. Bis der NIPs-PR merged, steht v3 als Amber-spezifische Erweiterung. Behandle es als vorwärtsblickendes Signal, nicht als stabile protokollweite Signalisierung.

NIP Deep Dive: NIP-32 (Labeling)

NIP-32 definiert eine strukturierte Möglichkeit für jeden Nostr-Akteur, Events, pubkeys, Relays, URLs oder Topics mit adressierbaren kind 1985 Events unter Verwendung eines namespaced Label-Vokabulars zu labeln. Die Spec führt zwei neue Tags ein: L bezeichnet einen Label-Namespace, und l bezeichnet ein Label innerhalb dieses Namespaces. Label-Ziel-Tags (e, p, a, r oder t) spezifizieren, was gelabelt wird. Die Namespace-Anforderung verhindert, dass mehrere Label-Systeme kollidieren: ein spam-Label in nip28.moderation trägt eine andere Semantik als ein spam-Label in relay-report.

Die Designentscheidung, die NIP-32 über Moderation hinaus nützlich macht, ist, dass Labels Behauptungen sind, keine Protokoll-Level-Wahrheit. Ein kind 1985 Event sagt nur, dass ein bestimmter pubkey ein bestimmtes Ziel in einem bestimmten Namespace gelabelt hat. Das Vertrauensmodell wird an den Client delegiert: jeder Client wählt, welchen Labelern er glaubt, welche Namespaces er liest und welche UI-Affordance er jedem Label gibt. Dasselbe Primitiv trägt Content-Warnungen, Lizenzzuweisung, ISO-639-1-Sprach-Tags auf kind 1 Notes, ISO-3166-2-geografische Tags, Content-Klassifizierung, verteilte Moderations-Vorschläge und Reputations-Scores.

Amethysts PR #3111 diese Woche ist das bislang größte Deployment. Er fügt Hashtag-Labeling über NIP-32 und einen Label-basierten Hashtag-Feed hinzu, wodurch Nutzer nach Labels, die von vertrauenswürdigen Labelern zugewiesen wurden, browsen können. Der frühere #tag Text-Match-Mechanismus, der Hashtag-Discovery auf Nostr ursprünglich antrieb, bleibt als Fallback für ungelabelte Notes. Das Hashtag-als-Label-Modell bedeutet, dass dieselbe Note unter mehreren Labels, die von verschiedenen Labelern zugewiesen wurden, entdeckbar sein kann, und Nutzer können bestimmte Labeler muten oder boosten, ohne die zugrunde liegenden Notes zu beeinflussen.

Self-Labeling wird ebenfalls unterstützt. Ein Autor kann L und l Tags direkt an seine eigenen kind 1 Notes anhängen, um Sprache, Standort und Thema zu deklarieren. Eine Note, die mit ["L", "ISO-639-1"], ["l", "en", "ISO-639-1"] getaggt ist, identifiziert sich selbst als Englisch und kann von sprach-bewussten Clients ohne Drittanbieter-Labeling-Infrastruktur gefiltert werden.

Beispiel eines NIP-32 Label-Events, das eine kind 1 Note als Englisch taggt und ihr einen Moderations-Tag zuweist:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748908800,
 "kind": 1985,
 "tags": [
 ["L", "ISO-639-1"],
 ["l", "en", "ISO-639-1"],
 ["L", "nip28.moderation"],
 ["l", "approve", "nip28.moderation"],
 ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3", "wss://relay.example.com"]
 ],
 "content": "Labeled as English-language content approved for NIP-28 chat moderation",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Der Amethyst-Rollout kombiniert mit der jüngsten Trusted-Relay-Assertions-Arbeit legt nahe, dass NIP-32 zum Standard-Substrat für jedes “user-driven assertion about a target”-Muster auf Nostr wird. Der nächste Test ist, ob die Labeler selbst Vertrauens-Hierarchien entwickeln: ob Nutzer bestimmten Labeler-npubs so folgen werden, wie sie Content-Erstellern folgen.

NIP Deep Dive: NIP-F4 (Podcasts)

NIP-F4 wurde diese Woche gemerged, zwei Jahre und drei Monate nachdem fiatjaf den ursprünglichen Entwurf geöffnet hatte (PR #1093). Das F-Präfix ist einfache Hex-Nummerierung: NIP-F0 bis NIP-FF nutzen denselben 1-Byte-Hex-Raum wie NIP-0A bis NIP-0D, wobei der obere Hex-Bereich als Überlauf dient, jetzt wo sich der Dezimalbereich 01–99 füllt. NIP-F4 definiert, wie Podcasts Episoden und Metadaten als Nostr-Events veröffentlichen, während RSS als ergänzende Schicht für die Audio-Datei selbst erhalten bleibt.

Die zentrale architektonische Entscheidung ist, dass jeder Podcast sein eigenes Nostr-Keypair ist. Die Spec eröffnet mit dieser Aussage direkt: “each podcast is its own Nostr keypair”. Das lässt Podcasts ihre Podcasting-Präsenz mit einer normalen kind 0 / kind 1 Microblogging-Präsenz kombinieren und lässt einen Podcast den Besitz über die Zeit hinweg über Key-Übergabe oder MuSig2-artiges geteiltes Signieren wechseln. Vier Event-kinds tragen die Publishing-Schicht:

kind:10154: replaceable Podcast-Metadaten. Trägt title, image, description, optionale website Tags und optionale p Tags, die Autoren mit einer role von host, cohost oder editor markieren.
kind:10164: Autoren-Gegenbehauptung. Das Beispiel in der Spec verwendet kind 10064 (ein Typo, der zur Korrektur offen ist), aber die Überschrift und der umliegende Text identifizieren es als kind:10164. Nutzer listen die Podcast-pubkeys, die sie authoren, sodass Clients die p Tags in kind:10154 gegen eine äquivalente Behauptung des vermeintlichen Autors verifizieren können. Ohne dies könnte ein Podcast fälschlicherweise jeden als Host taggen.
kind:54: Episoden-Events, die direkt vom Podcast-pubkey authored werden. Tags umfassen title, optionales image, description und eine oder mehrere audio Tags. Jedes audio Tag ist ["audio", "<audio-url>", "<optional_media_type>"]. Die Spec notiert “other important fields to be specified here later after further discovery”, und die gemergte Form ist bewusst minimal.
kind:10054: eine NIP-51-artige Favorite-Podcasts-Liste, mit der Nutzer markieren können, welchen Podcasts sie folgen.

Die Thread-Debatte rund um den Merge beinhaltete den Podcasting-2.0-Co-Autor Dave Jones, Alex Gleason, Mike Terenzio, Pablo F7z und staab. Jones argumentierte stark gegen jeden Versuch, RSS zu ersetzen: “It’s been tried many times and always fails”, und zitierte JSONfeed, XMPP, AMP, Twitters API und Spotifys gescheiterte Migration. Terenzio formulierte den Vorschlag als soziale Schicht auf RSS um, wobei RSS selbst die Verteilungsschicht bleibt. fiatjaf stimmte zu, zurückzutreten und den Vorschlag reifen zu lassen: “I agree with everything you said but I still think we can pull it off, let’s stop here for a while”. Zwei Jahre später landet die gemergte Spec näher an Koexistenz als an Ersatz.

Drei Designfragen bleiben in der gemergten Spec explizit:

Der kind:10164-Typo (Beispiel zeigt 10064) muss abgeglichen werden, bevor Clients sicher interoperieren können.
Episoden-Level-Discovery ohne RSS-GUID-Linking bleibt offen. Die gemergte Spec hat kein i Tag, kein podcast:item:guid-Format und keinen RSS-Bridging-Mechanismus. Clients, die einen bestehenden RSS-Katalog in kind 54 Events überbrücken wollen, müssen die Bridge-Konvention selbst definieren.
Der “other important fields”-Stub auf der kind:54-Definition lässt Bitrate, Dauer, Sprache, Transkript-Pointer, Kapitel und Per-Segment-Metadaten als offenes Territorium für Follow-up-Vorschläge.

Amethysts PR #3105 landet einen dedizierten Podcast-Screen mit Episodenliste und Inline-Player innerhalb von Tagen nach dem Merge, die erste große Client-Implementierung. Jumble lieferte frühes Podcast-Attachment-Scaffolding neben seinem GIF-Picker aus. Wavlake bleibt die größte Nostr-native Podcast-Plattform und muss entscheiden, ob es seine bestehenden kind 31337 Musiktrack-Events mit NIP-F4s kind 54 Episoden-Modell in Einklang bringt.

Beispiel eines NIP-F4 kind 54 Episoden-Events, passend zum minimalen Tag-Set der gemergten Spec:

{
 "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748995200,
 "kind": 54,
 "tags": [
 ["title", "Episode 42: Why RSS Won"],
 ["image", "https://podcast.example.com/ep42-cover.jpg"],
 ["description", "Dave Jones and fiatjaf on protocol coexistence and the social layer."],
 ["audio", "https://podcast.example.com/audio/ep42.mp3", "audio/mpeg"]
 ],
 "content": "In this episode we discuss the two-year journey of NIP-F4 from draft to merge, and why coexistence with RSS turned out to be the right architectural choice.",
 "sig": "abc123def456789012345678901234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567"
}

PR #1093 war 27 Monate offen, weit über der Median-Offenzeit für gemergte NIPs-PRs. Der nächste Test für NIP-F4 ist, ob der kind 10164-Typo abgeglichen wird, ob Episoden-Discovery- und RSS-Bridge-Konventionen von den Implementierern entstehen und ob die großen Podcast-Hosts unter Per-Podcast-Keypairs veröffentlichen, wie die Spec empfiehlt.

Nostr Compass #24

Thu, 28 May 2026 00:00:00 +0000

Amethyst v1.11.0 landet eine vollständige NIP-52-Kalender-Implementierung mit Erinnerungen, On-Chain-Bitcoin-Zap-Splits und Marmot-Gruppenantwort-Unterstützung. White Noise v2026.5.22 liefert iOS-Push-Benachrichtigungen über eine Notification Service Extension, dazu eine Block-UX und einen “Mitglieder hinzufügen”-Button. Vector v0.4.0 landet eine umfassende Neufassung von vector-core, One-Click-Tor mit Bridges, NIP-46-Remote-Signer, vollständige Negentropy-MLS-Gruppensynchronisation und einen 21-Tool-MCP-Server für KI-Agenten. Applesauce v6.1.0 führt NIP-51-Lookup-Relay-Listen (kind 10086) und einen kompletten NIP-34-Git-Cast-Factory-Satz ein. MDK fügt NIP-40 verschwindende Nachrichten über iOS und Android durch eine einheitliche UniFFI-Oberfläche hinzu, und Mostro v0.17.4 schließt die Anti-Abuse-Bond-Schleife mit Phase-3-Auszahlungen von geslashten Bonds an den Gewinner. Notedeck merged vollständige NIP-77-Negentropy-Reconciliation für Giftwraps und Thread-Backfill, Cordn erscheint als koordinatorvermittelter MLS-Messenger, der eine Single-Point-Availability-Abhängigkeit gegen strengere Epochen-Ordnung und ein einfacheres Betriebsmodell tauscht, eine NIP-B0-Referenzimplementierung namens deepmarks liefert einen kurator-monetarisierten Bookmark-Client, und das Formstr-Team öffnet vier koordinierte Kalender-NIP-Vorschläge, die Selbst-Entfernung von Teilnehmern, private Events, Wiederholung und dezentrale Terminplanung abdecken.

Top-Stories

Amethyst v1.11.0: Kalender, On-Chain-Zap-Splits und Marmot-Antworten

Amethyst, der Nostr-Client für Android, gepflegt von Vitor Pamplona, lieferte v1.11.0 aus. PR #2994 fügt eine NIP-52 Kalender-Event-Implementierung mit einer dedizierten UI und einem Erinnerungssystem hinzu, sodass Kalender-Events jetzt in ihrer eigenen Timeline-Kategorie rendern, getrennt von der generischen kind-30023 Long-Form-Ansicht. PR #3018 erweitert On-Chain-Bitcoin-Zaps um Split-Unterstützung und verteilt eine einzelne Bitcoin-Transaktion auf mehrere Empfänger gemäß dem bestehenden Zap-Split-Tag, sodass sich eine On-Chain-Zahlung genauso verhält wie ein Lightning-Split. PR #2974 fügt einen paginierten On-Chain-Transaktions-Historien-Screen hinzu, der jeden abgewickelten Zap mit Block-Bestätigungsstatus zeigt.

Gruppen-Messaging erhält Parität mit Eins-zu-eins-Chat: PR #2995 fügt Antwort-Unterstützung für Marmot/MLS-Gruppennachrichten hinzu, sodass Threads innerhalb verschlüsselter Gruppen jetzt mit derselben Parent-Reference-UI wie öffentliche Notes rendern. PR #2984 härtet die NIP-57 Zap-Quittungs-Validierung, indem geprüft wird, dass der LNURL-Provider zur angegebenen lud16 des Empfängers passt, was eine Klasse von Fälschungen schließt, bei denen ein Dritt-LNURL eine Quittung für eine nie eingegangene Zahlung erzeugen könnte. PR #2968 akzeptiert Fließkomma-Dimensionen in NIP-92 imeta Tags und richtet Amethyst mit Clients aus, die gebrochene Pixel-Density-Werte von Geräten wie dem iPhone Retina Display veröffentlichen. Das Release verdrahtet außerdem Payment Targets, ein neues replaceable-Event-Multi-Rail-Trinkgeldglas, das im Protokollabschnitt unten behandelt wird.

White Noise v2026.5.22: iOS-Push, Block-UX und Mitglieder hinzufügen

White Noise, der Marmot-Protokoll-Gruppen-Messenger, lieferte v2026.5.22 mit iOS-Push-Benachrichtigungen als Hauptfeature aus. PR #673 implementiert eine iOS Notification Service Extension (NSE), die MLS-Nachrichten innerhalb des Extension-Prozesses entschlüsselt und sie als System-Benachrichtigungen anzeigt, sodass iPhone-Nutzer die App nicht mehr im Vordergrund brauchen, um Nachrichten zu empfangen. Android-Push-Token-Plumbing routet durch dieselbe Backend-Pipeline, wobei die plattformspezifische NSE Chiffretext vom Broker fernhält.

PR #676 fügt eine vollständige Block- und Unblock-UX mit Bestätigungs-Flows und Kontaktlisten-Filterung hinzu. PR #679 fügt den lange geforderten “Mitglieder hinzufügen”-Button zum Gruppen-Info-Screen hinzu und schließt eine UX-Lücke, in der Gruppen-Admins auf Share-Links zurückgreifen mussten. PR #688 führt einen dedizierten iOS-Benachrichtigungseinstellungs-Screen ein, und PR #687 verdrahtet Share-per-Long-Press für Medien und Nachrichten.

MDK fügt NIP-40 verschwindende Nachrichten plattformübergreifend hinzu

Das Marmot Development Kit, der geteilte Rust-Core, den White Noise iOS, White Noise Android und jeder zukünftige Marmot-Client verwenden, mergte PR #306, um Validierung für verschwindende Nachrichten und NIP-40 Ablauf-Handling über die UniFFI-Brücke zu exponieren. Der PR ist der zweite einer dreiteiligen Serie. iOS und Android teilen sich jetzt eine Rust-Implementierung der Ablauf-Logik; die Timing-Regeln leben in einem einzigen geprüften Code-Pfad, der von beiden Plattformen über UniFFI konsumiert wird. PR #307 begrenzt die gespeicherte Länge von Welcome-Fehlergründen und bereinigt sie vor der Persistierung, ein separater Härtungsdurchgang, der die letzte Woche ausgelieferte Welcome-Event-Behandlung ergänzt.

Verschwindende Nachrichten in MLS sind nicht nur ein UI-Feature. Der Ablauf-Tag wird mit der verschlüsselten Nachrichten-Hülle veröffentlicht, sodass bei einem Empfänger, der die Nachricht nie öffnet, der zugrundeliegende Chiffretext trotzdem auf Relay-Ebene abläuft, zusammen mit jeder gecachten Kopie im empfangenden Client. Da MDK den Validierungs-Pfad besitzt, bleibt das Verhalten über Clients hinweg konsistent: jede konforme Marmot-Implementierung setzt dieselbe Ablauf-Semantik durch, sodass es kein Portabilitäts-Risiko mehr ist, dass ein Client Ablauf respektiert, während ein anderer für immer cached.

Mostro v0.17.4: Phase 3 schließt die Slashed-Bond-Schleife

Mostro, das Peer-to-Peer-Bitcoin-Exchange-Protokoll auf Basis von Nostr, lieferte Phase 3 seines Anti-Abuse-Bond-Rollouts in v0.17.4 aus. PR #738 landet den Payout-Flow für geslashte Bonds, nimmt das verfallene Collateral des Verlierers und verteilt es an den Dispute-Gewinner. PR #743 fügt Phase 3.5 hinzu, eine explizite Payout-Bestätigungsnachricht an den Gewinner, damit er weiß, dass die geslashten Sats abgewickelt sind, wobei das Bestätigungs-Event auf derselben Nostr-Sitzung ankommt wie die Dispute-Auflösung. Phase 2, letzte Woche behandelt, führte Slashing als Admin-Aktion ein; Phase 3 ist der Unterschied zwischen dem Androhen und dem Durchsetzen einer Strafe.

PR #746 lässt den Daemon Disputes finalisieren, denen eine Solver-Zeile fehlt, ein Sonderfall, der zuvor die Auflösung bei Legacy-Disputes ins Stocken brachte. PR #748 toleriert Null-Raten in Yadios /exrates/BTC-Antwort, sodass ein kurzer Yadio-Ausfall Mostros Fiat-Konvertierungs-Pfad nicht mehr bricht. PR #745 dokumentiert die Spezifikation für Multi-Source-Preisanbieter, die Grundlage dafür, Yadio als Single Point of Failure zu entfernen. Der Mostro Mobile-Client verdrahtete den passenden Phase-3-Claim-Pfad in PR #596.

Applesauce v6.1.0: Lookup-Relays und NIP-34-Git-Casts

Applesauce, das modulare Nostr-Toolkit, das Coracle, noStrudel und Pablo F7z’ Stack antreibt, veröffentlichte v6.1.0 über seine Pakete hinweg. Das Release fügt erstklassige NIP-51 Lookup-Relay-Listen-Unterstützung hinzu: kind 10086 Events lassen einen Benutzer signalisieren “frag diese Relays, wenn du mich finden willst”, und ergänzen NIP-65 Outbox-Listen als Discovery-Primitiv. Anwendungen auf Basis von applesauce-core erhalten ein reaktives User.lookupRelays$ Observable und einen passenden Loader in applesauce-relay.

NIP-34 Git-Cast-Factories kommen in applesauce-factory an und geben jedem auf Applesauce basierenden Client einen Ein-Zeilen-Pfad zum Veröffentlichen von Repo-Ankündigungen (kind 30617), Patches (kind 1617) und Issues (kind 1621). Die reaktiven Eigenschaften User.favoriteGitRepos$, User.gitAuthors$ und User.graspServers$ lassen Anwendungen die gefolgten Repos, Repo-Maintainer und konfigurierten GRASP-Server eines Benutzers direkt aus demselben User-Objekt auflisten. Das Release behebt auch Pool-Manual-Methoden, die offline Relays in PR #73 stillschweigend fallen ließen.

Notedeck merged NIP-77-Negentropy für Giftwraps und Thread-Backfill

Notedeck, Damus’ nativer Multi-Column-Desktop-Client, mergte am 25. Mai PR #1459, um vollständige NIP-77 Negentropy-Reconciliation in den geteilten Outbox-Pfad zu verdrahten. Der PR fügt NIP-77 Client- und Relay-Frames, relay-lokale Negentropy-Sessions und einen Outbox-Full-History-Tracker hinzu, der Local-Set-Reconciliation und Missing-Event-Fetches antreibt. Messages-Giftwraps erhalten Negentropy-Reconciliation, sodass Private-Message-Hüllen von den Read-Relays des ausgewählten Kontos wiederhergestellt werden können. Thread-Ansichten sind nicht mehr durch das Live-Subscription-Antwort-Limit gedeckelt. Dave PNS ersetzt seine Dave-lokale Negentropy-Implementierung durch den geteilten Outbox-Pfad und behält dabei sein bestehendes Bounded-History-Verhalten bei.

Live-Subscriptions und Negentropy verwenden jetzt separate Filter. Ein Flow kann eine kleine Live-Anfrage aufrechterhalten, während er einen breiteren Negentropy-Filter erlässt, um zu reconcilen, was das Relay bereits hat. Der PR aktiviert absichtlich keine breite Negentropy-Synchronisation für Home- oder Profil-Timelines, was die Kaltstart-Kostencharakteristik ändern würde. Testabdeckung wurde für Reconciliation, Giftwrap-Zustellung, Thread-Backfill, Dave-PNS-Restore, Konto-Wechsel, Relay-Retargeting, Fetch-Retries und NIP-77-Relay-Verhalten hinzugefügt.

Vector v0.4.0: vector-core-Neufassung, Tor, NIP-46, Full-Negentropy-MLS und eine MCP-Agent-Oberfläche

Vector, der auf NIP-17-DMs und Marmot-Gruppen basierende plattformübergreifende, datenschutzorientierte Messenger, lieferte v0.4.0 als bislang größtes Release aus. Die Schlagzeile ist eine grundlegende Engine-Neufassung: Vectors gesamte Logik lebt jetzt in einem einzigen entkoppelten Crate, vector-core, geteilt über Desktop, Android und jeden zukünftigen Client, mit über 440 Tests im Kern selbst und der Anwendungshülle um tausende Zeilen abgespeckt. Die Neufassung ist die Grundlage für eine Vector-CLI, Bots und SDKs, die denselben Protokollcode wie die GUI antreiben.

Die Tor-Integration wird mit One-Click-Traffic-Routing und Bridge-Unterstützung zur Zensurumgehung ausgeliefert. Multi-Account-Unterstützung landet mit einem In-App-Switcher. Remote-Signer-Login kommt über NIP-46 mit Bunker-Pairing per QR oder eingefügtem URI, sodass Benutzer sich anmelden können, ohne jemals ihren nsec preiszugeben. Delete-for-Everyone funktioniert sowohl in NIP-17 DMs als auch in Marmot Gruppen-Chats, wobei Vector den ephemeren Signing-Key als bewusste Spec-Divergenz behält, die die Release Notes explizit hervorheben: “eine Abweichung von den traditionellen NIP-17/Marmot-Specs für verbesserte User-Privacy-Kontrollen.” Der behaltene ephemere Key gibt Vector-Clients lokalen Beweis, dass eine Löschung vom ursprünglichen Absender sanktioniert wurde, aber er bedeutet auch, dass jeder andere Vector-berührende Client eine andere Lösch-Verifizierbarkeits-Oberfläche sieht als Baseline-NIP-17/Marmot-Clients.

MLS-Gruppen-Sync wird jetzt vollständig über NIP-77 Negentropy reconciled, dieselbe Richtung, die Notedeck diese Woche für Giftwraps und Threads eingeschlagen hat. Der Blossom-Uploader macht Failover über mehrere Server, lernt die Fähigkeiten jedes Servers und synchronisiert die Serverliste über Geräte. Custom Emoji Packs sind benutzererstellbar, teilbar und kompatibel mit anderen Nostr-Clients. Der SQLite-Speicherverbrauch fiel von etwa 308MB auf 5MB. Das Emoji-Panel öffnet aus Disk-Cache und Discord-Style-Shortcodes (:smile:) plus Unicode-Frequenz-Ranking bringen den richtigen Glyph zuerst an die Oberfläche.

Die neuartigste Ergänzung ist vector-agent, ein MCP-Server (Model Context Protocol), der 21 Tools exponiert, damit KI-Agenten Vector antreiben können: DMs senden, Gruppen verwalten, Dateien hochladen, Profile bearbeiten. Dies ist das zweite Nostr-Projekt diese Woche (neben Shopstr), das eine MCP-Oberfläche ausliefert, und die erste Messenger-Klasse-Anwendung, die das tut. Zusammen mit AgentNoise (letzte Woche behandelt) bewegt sich das Muster von agent-gesteuerten Nostr-Clients von einmaligen Experimenten zu einer bewussten Plattform-Richtung.

Cordn erscheint als koordinatorvermittelter MLS-Messenger

Cordn (Web-Client unter cordn.net, Repos bei Cordn-msg/cordn und Cordn-msg/cordn-web) ist ein neuer MLS-Messenger, der einen anderen architektonischen Kurs einschlägt als Marmot. Während Marmot vollständig relay-basiert ist ohne privilegierten Koordinator (jedes Gruppenmitglied schreibt direkt an Relays und jedes konforme Relay kann den Verkehr tragen), führt Cordn eine Per-Group-Koordinatorrolle ein, implementiert als ContextVM-Service. Der Koordinator ordnet MLS-Commits und übernimmt die Welcome-Verteilung.

Cordns Argument, formuliert auf seiner /why-Seite, ist, dass MLS, wie es in Produktions-Messengern eingesetzt wird, “nicht koordinationsfrei” ist und dass “schwach geordnete öffentliche Verbreitung” die Konvergenz des Gruppenzustands “viel schwieriger” macht ohne einen starken Koordinationspunkt. Ein koordinatorvermitteltes Design bietet vorhersehbaren Epoch-Fortschritt und einfachere Auflösung gleichzeitiger Commits. Teilnehmer verbinden sich mit dem Koordinator über ephemere Keys, sodass der Koordinator die Group-ID und das Timing von Commit-Verkehr erfährt, aber nicht welche langfristigen pubkeys Mitglieder sind. Jede Partei, die Relays für eine Marmot-Gruppe abfragt, kann bereits dieselbe Oberfläche sehen: Gruppenaktivität nach Group-ID, mit aus dem Event-Eintreffen ableitbarem Timing. Cordn erkennt auch an, dass “Availability-Trust bestehen bleibt” beim Selbst-Hosting: ein selbstgehosteter Koordinator vermeidet die Zentralisierungsbedenken auf Betreiber-Ebene, führt aber einen Single Point of Failure für die Gruppen-Liveness ein. Marmot vermeidet diesen Single Point, indem die Ordnung MLS selbst überlassen wird (Epochs und Commit-Nachrichten übernehmen die Ordnung innerhalb des Protokolls) und Welcome-Events über NIP-59 Gift Wrap verteilt werden, zum Preis von Admin-seitiger Disziplin: Admins müssen auf die Relay-Bestätigung eines Commits warten, bevor sie das passende Welcome senden, und Clients müssen gleichzeitige Commits reconcilen, wenn die Relay-Zustellung mit einem Zustandsübergang um die Wette läuft.

Der Kontrast ist es wert, für jedes Team, das einen Private-Messaging-Stack auswählt, herausgearbeitet zu werden. Marmot tauscht etwas Implementierungskomplexität gegen ein relay-agnostisches Deployment ohne privilegierten Akteur im Pfad. Cordn tauscht eine Single-Point-Availability-Abhängigkeit gegen strengere Ordnung und ein einfacheres Betriebsmodell. Beide Projekte bauen auf MLS auf und verwenden Nostr als Identity- und Transportschicht. Die Meinungsverschiedenheit betrifft, wo die Koordinationskosten liegen. Die cordn-msg-Repos zeigen stetige Commit-Kadenz, wobei der Koordinator-Service über ContextVM implementiert ist und die MLS-Schicht auf ts-mls aufbaut.

deepmarks: NIP-B0-Bookmarks mit kurator-monetarisierter Veröffentlichung

deepmarks-public ist ein Referenz-Client für die vorgeschlagene NIP-B0-Bookmark-Spec (kind 39701), mit einer Drei-Box-Architektur (Kurator, Indexer, Viewer) und einem Tier-System, finanziert durch direkte Kurator-NIP-57-Zaps. Der Client implementiert NIP-B0, NIP-07, NIP-46, NIP-57, NIP-44, NIP-98, NIP-65 und Blossom BUD-01 und BUD-04 für Dateispeicherung. Ein 21.000-Sat-Lifetime-Tier wandelt zahlende Leser in wiederkehrende Zap-Empfänger für den Kurator um. Der Kurator veröffentlicht Bookmark-Events, der Indexer reichert sie mit maschinenlesbaren Metadaten an, und der Viewer rendert den Feed; jede Rolle ist ein separater deploybarer Service.

Releases

Amber v6.1.0 GA: verschlüsseltes Per-Account-Backup

Amber wechselte diese Woche von v6.1.0-pre3 zu GA v6.1.0. PR #444 liefert verschlüsseltes Backup und Restore für die Anwendungs-Berechtigungs-Datenbank, und PR #446 teilt das Backup per Account, sodass Benutzer mit mehreren Nostr-Identitäten jeden Satz von App-Grants unabhängig sichern und wiederherstellen können. Die letzte Woche behandelte PSBT-Signing-Arbeit ist im GA-Cut enthalten.

Citrine: Per-Relay-Subscriptions und Onion-URL-Leak-Prävention

Citrine, das On-Device-Personal-Relay, das mit Amethyst ausgeliefert wird, brachte diesen Zyklus zwei Fixes. PR #157 wechselt von einer einzigen globalen Subscription zu Per-Relay-getaggten Subscriptions, sodass zwei Quell-Relays, die einen kinds: [1] Filter teilen, auf der Aggregator-Seite nicht mehr kollidieren. PR #162 filtert Onion-Relay-URLs, wenn der ausgehende Tor-Proxy deaktiviert ist, und verhindert, dass Onion-Adressen auf den Clearnet-Routing-Pfad lecken.

Angor v0.2.27 und v0.2.28: Relay-Zuverlässigkeit und Boltz-Reconnect

Angor lieferte v0.2.27 und v0.2.28 aus. PR #874 behebt einen Relay-Dedup-Bug, bei dem nur ein Relay gleichzeitig verbunden war, eine Regression, die die Zuverlässigkeit für Projekte mit mehreren Relay-Endpunkten stillschweigend verschlechterte. PR #876 fügt WebSocket-Reconnect-Logik für Boltz-Submarine-Swap-Überwachung hinzu, sodass ein kurzer Verbindungsabbruch einen Swap nicht mehr in unbekanntem Zustand lässt.

Nostrord v1.1.0: NIP-57-Zaps und NIP-29-Rollenunterscheidung

Nostrord veröffentlichte v1.1.0 mit NIP-57 Lightning-Zap-Unterstützung für Nachrichten und Profile (PR #98) und einer ordentlichen Unterscheidung im Aktivitäts-Feed zwischen NIP-29 Rollen-Änderungen und Member-Adds (PR #92), die früher identisch gerendert wurden und verschleierten, wer befördert und wer eingeladen worden war.

ぬるぬる v1.5.x: SQLCipher MLS-Keystore und Epoch-Catch-up

ぬるぬる (nurunuru, von tami1A84), ein japanischsprachiger Nostr-Client, der MLS-Gruppen-Messaging (kind 443) neben NIP-44, NIP-50 Advanced Search, NIP-55 und NIP-70 implementiert, lieferte diese Woche fünf Releases aus. PR #184 führt SQLCipher-Verschlüsselung für den MLS-Keystore in der Rust-Engine-Schicht ein. PR #187 und PR #188 erweitern SQLCipher auf Android bzw. iOS, mit einem Legacy-Plaintext-Purge-Schritt und CI-Guards. PR #189 und PR #191 fügen MLS-Peer-Epoch-Catch-up mit einem Replay-Cache und einem Recovery-Banner auf beiden Plattformen hinzu, sodass ein Client, der bei Gruppen-Commits ins Hintertreffen gerät, sich erholen kann, ohne die Konversation zu verlieren. ぬるぬる ist ein Marmot-Client auf Basis von mdk-core, mdk-sqlite-storage und mdk-storage-traits aus marmot-protocol/mdk, sodass die SQLCipher- und Epoch-Catch-up-Arbeit im selben MDK-Runtime landet, das White Noise verwendet.

Bitcredit Core v0.5.10: Nostr-verwurzelter Block-Propagations-Fix

Bitcredit Core veröffentlichte v0.5.10 mit einem Fix für ein fehlendes Nostr-Node-ID-Feld während der Block-Propagation, das Company-Creation-Flows mit Identity-Upload brach. Bitcredit ist ein E-Bill-Protokoll, das Nostr-Identitäten als Vertrauenswurzel für Company- und Bill-Propagations-Events nutzt.

Unveröffentlichte Änderungen

Jumble öffnete PR #797 für Google-Login über den Pomegranate-Threshold-Signer, was einem Benutzer erlaubt, seinen Nostr-Key auf mehrere Parteien aufzuteilen, sodass kein einzelner Signer das vollständige Geheimnis hält. Dies ist ein bedeutender Schritt jenseits von Bunker- oder nsec-Import-Flows: ein Benutzer kann sein Konto wiederherstellen, auch wenn eine Signer-Partei kompromittiert ist, ohne dass diese Partei jemals den vollständigen Private Key gehalten hätte.

Shopstr öffnete PR #492, der einen MCP-Server (Model Context Protocol) initialisiert, mit PR #494, der die unterstützende Infrastruktur baut (Relay-Fetch, Parser, Validation, Errors, Dedup, Audit-Logging) und PR #472, der eine Relay-Allowlist für den MCP-Relay-Manager hinzufügt. Das macht Shopstr zum ersten Nostr-Marktplatz, der sich als MCP-Server exponiert, sodass KI-Agenten NIP-99-Listings als strukturiertes Tool durchsuchen und mit ihnen agieren können.

Keydex, der Shamir-Secret-Sharing-Vault, öffnete eine substantielle Migration in PR #226, die die benutzerdefinierten kinds 1337-1345 in den Bereich 713-721 verschiebt, neben PR #239, der AEAD über Shamir-Shares hinzufügt, und PR #234, der zu GF256-Arithmetik migriert. Die Kind-Range-Migration richtet Keydex mit der Art aus, wie das NIPs-Repo benutzerdefinierte kinds alloziert, und rückt weg von einem selbst beanspruchten Bereich.

Mill (nostr-mill) ist eine neue Drop-in-Nostr-Signer-UI von OceanSlim (Maintainer des grain Go-Relays), ausgeliefert als Single-Script-Tag Web Component auf npm und jsDelivr. Ein <script>-Tag gibt einer Web-App alle sechs gängigen Signer-Einstiegspunkte hinter einer einheitlichen UI: NIP-07 Browser-Extension, NIP-46 Bunker (URL-Einfügen oder QR-Pairing mit benutzerspezifizierbaren Relays, ungewöhnlich unter In-Page-Bunker-Integrationen), NIP-55 Amber über Android-Intents, verschlüsselter nsec, gespeichert in sessionStorage per AES-256-GCM mit PBKDF2, Read-Only npub und In-Browser-Keypair-Generierung. Die Komponente ist über 29 CSS Custom Properties themebar, die auf das Shadow DOM beschränkt sind, und exponiert eine kleine SemVer-getrackte API (MILL.open, mill:connected / mill:disconnected Events, benannte Theme-Exporte). Die Motivation des Maintainers ist, dass Bunker-Login-Flows in Nostr eine Web-App nach der anderen neu implementiert wurden. Das Konsolidieren auf einer geteilten Komponente lässt Clients auf die Frage konvergieren, wie sich Signer-UX verhalten soll, und macht optionale Flows (wie Delegated-Key-Login durch Threshold-Signer, was Wisps oben behandelten Pomegranate-basierten Google-Login spiegelt) zu einer wiederverwendbaren Oberfläche, die jede App einbinden kann. Mill ist bei npm v1.5.0, Single-Maintainer, Alpha-Stadium, mit grain als geplantem ersten Integrator.

moStard, ein Monero-first-Fork von noStrudel von roguehashrate, erreichte diese Woche v1.0.1 mit einem abgespeckten Feature-Satz und einer Monero-themed Identität, geschichtet auf demselben Applesauce + Worker-Relay-Stack. Diese Woche landete Rendering für Zapstores kind 32267 Software-Application-Events (Embed-Karten in der Timeline mit App-Name, Icon, Screenshots, Plattform, Lizenz und einem Launch-Link zu zapstore.dev/apps/<d-tag>), Umfragen per kind 20 und kind 21, NIP-A3 Payment-Targets-basiertes Tipping mit Per-Methode-QR-Codes, Markdown-Rendering in Notes, GIF-Picker-Unterstützung für externe GIF-Keyboards und Amber-Signer-Pairing-Fixes. Der Monero-Rahmen erstreckt sich auf den Trinkgeld-Flow: NIP-A3 payto-Einträge für monero-Adressen erhalten erstklassige Buttons in derselben UI neben lightning und bitcoin. Der Client ist Single-Maintainer und Alpha-Stadium, aber die Arbeit vom 27. Mai zeigt einen Builder, der NIP-A3 aus den Protokoll-Spec-Ankündigungen dieser Woche innerhalb von Tagen direkt in einen ausliefernden Fork zieht.

NIP-Updates und Protokoll-Spec-Arbeit

Kalender-NIP-Stack: vier Vorschläge vom Formstr-Team

Ix2 (@geralt-debugs) öffnete am 17. Mai vier koordinierte NIP-PRs, die alle auf die calendar.formstr.app-Implementierung verweisen, die bereits vom selben Autor ausgeliefert wird. PR #2350 schlägt kind 84 als generalisiertes “Participant-Self-Removal”-Event vor: ein getaggter Teilnehmer bei jedem Event kann ein kind 84 veröffentlichen, das über e, a und k Tags auf das Original verweist, um Opt-out zu signalisieren. Relays müssen validieren, dass der Signer von kind 84 in einem p Tag des referenzierten Events auftaucht, bevor die Entfernung geehrt wird, und eine kind 5 Löschung hat immer Vorrang. Der PR generalisiert ein Muster, das zuvor nur im NIP-52-Kalender-Kontext beschrieben wurde, sodass kind 84 zum Standardweg für Nicht-Autoren wird, sich aus jedem Teilnehmer-Event zurückzuziehen.

PR #2351 ist das Fundament des Kalender-Stacks: NIP-52E für private Kalender-Events (kinds 32678 zeitbasiert, 32681 Tages-Event, 32123 private Kalender-Liste, 31926 Busy-Liste, 1052 Gift Wrap, 52 Rumor) und NIP-52R für wiederkehrende Events. Im architektonischen Kern liegt das View-Key-Muster: ein zufällig erzeugtes Keypair verschlüsselt Event-Inhalte mit NIP-44, und die geheime Hälfte (bech32-kodiert als nsec) wird per Gift Wrap an jeden Teilnehmer geliefert. Der Signierer hält nur den öffentlichen d Tag; alles andere lebt in verschlüsseltem content. Die Entkopplung der Inhaltsverschlüsselung von der Identität auf diese Weise bedeutet, dass das Bearbeiten eines Events kein Re-Keying der Empfänger erfordert. NIP-52R definiert zwei optionale Tags auf den bestehenden kinds 31923 und 31922 zur Deklaration von Wiederholung mit reinen RFC-5545-RRULE-Werten, wobei D-Tages-Index optional wird, wenn RRULE vorhanden ist. Forward Secrecy fehlt explizit: ein geleakter View-Key offenbart alle vergangenen und zukünftigen Versionen des Events unter demselben d Tag.

PR #2352 baut auf NIP-52E mit einer dezentralen Terminplanungs-Spec auf, die die PR-Beschreibung “eine Drop-in-Alternative zu Calendly/Cal.com ohne zentralen Vermittler” nennt. Kind 31927 kündigt eine Scheduling-Seite mit verschlüsselten Verfügbarkeitsfenstern an; kind 32680 ist ein host-seitiges selbstverschlüsseltes Recovery-Record für den View-Key; kinds 1057 und 1058 sind die gift-wrapped Booking-Anfrage und -Antwort. Der clevere Mechanismus: der Buchende generiert sowohl den d Tag als auch den View-Key für das zukünftige private Event, bevor er die Anfrage sendet, sodass der Buchende den Termin mit dem korrekten Key sofort in seinen eigenen Kalender aufnehmen kann und der Host nie einen Key zurückschicken muss. Booking-Antworten tragen einen unverschlüsselten status Tag auf dem äußeren Wrap, sodass Relays ohne Entschlüsselung filtern können.

Eine Referenzimplementierung ist bereits live unter calendar.formstr.app und als Calendar-Android-App auf Zapstore. PR #2351 schließt PR #2027 zu seinen Gunsten und konsolidiert einen früheren Private-Calendar-Vorschlag, der seit Anfang des Jahres offen war.

Payment Targets und Silent Payments

Zwei weitere NIP-Vorschläge zirkulierten diese Woche in kind:30023 Long-Form-Dokumenten.

Ein Payment-Targets-Vorschlag (NIP-A3 / payto) definiert ein replaceable kind 10133 Event, das einen oder mehrere ["payto", "<type>", "<authority>"] Tags trägt, die auf RFC 8905 payto: URIs abbilden. Unterstützte Typen umfassen bitcoin, lightning, ethereum, monero, nano, cashme, revolut und venmo. Die Absicht ist es, ein Multi-Rail-Trinkgeldglas zu standardisieren, das lud16-basierte NIP-57-Zaps ergänzt (nicht ersetzt). Amethyst v1.11.0 ist der erste Implementierer; gemergte PRs #2953 und #3009 liefern die Subscription- und Observation-Oberfläche aus, und PR #3011 verdrahtet die UI für PaymentTargetsEvent.

Zwei konkurrierende Silent-Payments-Vorschläge kamen von verschiedenen Autoren. Die erste Variante leitet BIP-352 Silent-Payment-Scan- und -Spend-Keys aus nsec über öffentliche additive Tweaks ab, sodass jeder Absender eine sp1q...-Adresse aus einem npub ohne Setup konstruieren kann. Die Autorenwarnung ist in der Spec explizit: “bscan und bspend MÜSSEN mit genau derselben Sorgfalt wie nsec behandelt werden”, weil der Scan-Key den nsec offenbart. Eine zweite Variante nimmt den umgekehrten Ansatz und fügt ein sp_address-Feld zu kind 0 Profilmetadaten hinzu, das eine standardmäßige BIP-352 Silent-Payment-Adresse enthält, deren Keys unabhängig von der Nostr-Identität gehalten werden. Variante zwei ist strukturell sicherer. Beide Vorschläge zogen einen durchdachten Review-Thread an; erskingardner (Marmot-Lead) postete einen detaillierten Kommentar auf dem trbouma-Gist, der den Vorschlag verfolgt. Sein zentrales Anliegen ist, dass Variante 1 den Scan-Private-Key aus nsec plus einem öffentlich berechenbaren Tweak ableitet, was bedeutet, dass jeder, der den Scan-Key hält (einschließlich eines Third-Party-Scanning-Service, an den der Benutzer in der Praxis delegieren muss), den vollständigen nsec durch Subtraktion dieses Tweaks wiederherstellen kann. Derselbe Key, der einem Remote-Service erlaubt, eingehende Zahlungen für dich zu scannen, erlaubt diesem Service auch, deine Identität und alle daraus abgeleiteten Gelder zu stehlen.

Auf der NIP-34 Git-über-Nostr-Seite veröffentlichte hzrd149 2 Patches auf schemata. gitworkshop.dev selbst zog zwei Issue-Reports an: einer flaggte, dass Login-Sitzungen bei Seiten-Refresh verloren gehen, wenn ein NIP-46 Remote-Signer verwendet wird, der andere bat um deutliches Link-Styling in README-Vorschauen.

Sechs Jahre Nostr-Maies

Der letzte Newsletter des Mai 2026 tritt einen Schritt zurück von den Releases der Woche, um den Monat Mai durch Nostrs Geschichte zu begleiten. Jedes Jahr hatte einen anderen Schwerpunkt: 2021 war ein einzelner Commit, 2022 war die Formation des NIPs-Repos selbst, 2023 war die Protokoll-Spec-Explosion, 2024 war der Konsolidierungszyklus, 2025 war das Jahr, in dem Negentropy gemerged wurde und Damus’ Notedeck zu Beta aufstieg, und 2026 ist der Monat, der in dieser und den drei vorhergehenden Ausgaben behandelt wird.

Mai 2021

Nostr war sechs Monate alt. Der einzige Nostr-Code lebte in fiatjaf/nostr, und der gesamte Monat brachte genau einen Commit hervor, aber dieser Commit wurde zu einem der am meisten genutzten Teile des Protokolls. Am 22. Mai widmete fiatjaf NIP-02 um als das Contact-List-NIP. Die Commit-Nachricht lautet: “repurpose NIP-02 and add NIP authorship”, und die explizite Anerkennung geht an PR #16 von arcbtc (Ben Arc von LNbits), geöffnet am 9. Februar und am Tag vor fiatjafs Aufnahme der Idee in NIP-02 geschlossen. arcbtcs Pitch war klein: ein kind zum “Senden der Follower-Liste an Relays”, das “nützlich zum Wiederherstellen von Konten und zum Empfehlen von Public Keys zum Folgen” sein würde. fiatjaf verallgemeinerte es in ein einzelnes kind:3 Event, dessen Tags gleichzeitig drei Zwecken dienen. Sie sind eine Follow-Liste (der soziale Graph), ein Petname-Store (lokale Spitznamen für Freunde) und eine Relay-Empfehlungsquelle (welche Relays ein Follow nutzt). Dasselbe Event, replaceable pro Autor, wurde zur kanonischen Antwort auf “wem folgt diese Person”, “wie nennt sie sie” und “wo liest sie”. Jeder in den nächsten fünf Jahren gebaute Client liest kind:3. Die Konvention, die im selben Commit hinzugefügt wurde, dass jedes NIP seinen Autor benennt, ist der Grund, warum jede Spec heute Bylines hat.

Mai 2022

Der Monat, in dem das NIPs-Repo zu einem Community-Projekt wurde. Am 1. Mai migrierte fiatjaf die Specs von fiatjaf/nostr in ein dediziertes nostr-protocol/nips Repo und fügte am 2. Mai formale Akzeptanzkriterien hinzu. Zwei Tage später öffnete Robert C. Martin (Uncle Bob) PR #1, den ersten externen Pull Request, der Threading-Konventionen für e und p Tags vorschlug. Der PR war ursprünglich als NIP-13 nummeriert, dann zu NIP-10 umbenannt, um Platz für Proof-of-Work zu schaffen. Drei der ersten sechs NIPs sind von Uncle Bob: NIP-10 (Threading-Marker), NIP-14 (der Subject-Tag) und der Commit vom 21. Mai, der kind:1 als das kanonische Short-Text-Note-kind festlegte. Am 5. Mai machte William Casarin seine ersten NIP-Commits: NIP-13 Proof of Work und das kind:2 Recommend-Relay-Event. Am nächsten Tag veröffentlichte fiatjaf NIP-07 window.nostr, zwanzig Zeilen Markdown, die die noch heute genutzte Browser-Extension-Signer-Schnittstelle definierten. Die CORS-Warnung von NIP-05 von David A. Harding und NIP-01s filter.limit landeten in derselben Woche. nostr-tools lieferte seinen ersten browser-importierbaren ESM-Build am 8. Mai aus. Semisol entwarf NIP-15 (End Of Stored Events) und NIP-16 (Event-kind-Ranges) zum Monatsende, die Dokumente, die immer noch die Relay-Sync-Semantik und die Regular-vs-Replaceable-vs-Ephemeral-Klassifikation regeln.

Mai 2023

Die Protokoll-Spec-Explosion. In diesem Monat wurden vierundsechzig NIP-PRs eröffnet, mit mehreren der Vorschläge, die Nostrs Oberfläche für die nächsten zwei Jahre definierten, alle in 31 Tagen landend, und die größte Finanzierungsankündigung, die Nostr je erhalten hatte, landete am 4. Mai mit dem OpenSats 10-Millionen-Dollar-Grant von Jack Dorseys #startsmall, dem Geld, das jede Nostr-Grant-Welle seither trug. NIP-47 (Nostr Wallet Connect) wurde am 2. Mai gemerged und brachte Albys Wallet-Connect-Spec in das Haupt-Protokoll. Zwei Tage später schlug Vitor Pamplona NIP-53 Live Activities vor mit kind:30311 Räumen und kind:1311 Chat-Nachrichten, dem Fundament für jede darauf folgende Nostr-Livestreaming-Oberfläche. Pablo Fernandez öffnete NIP-84 Highlights am 5. Mai und NIP-89 Recommended Application Handlers am 14. Mai. v0l (Kieran Babich, Snort-Autor) schlug NIP-98 HTTP Auth am 8. Mai vor, das Authentifizierungs-Primitiv, auf das sich später sowohl NIP-96 als auch Blossom stützten. Jonathan Staab schlug NIP-32 Labels am 15. Mai vor, und NIP-30 Custom Emoji wurde am selben Tag gemerged. Arthur Franca schlug NIP-96 HTTP File Storage Integration am 21. Mai vor. Zwei Tage später fügte Vitor Zap-Splits zu NIP-57 hinzu, und verbiricha fügte kind:30024 Long-Form-Drafts zu NIP-23 hinzu, die Spec, die zum Fundament moderner Nostr-Long-Form-Authoring-Workflows in Habla, YakiHonne und Highlighter wurde. fiatjaf schlug NIP-29 Simple Groups am 28. Mai vor, die erste relay-verwaltete Gruppen-Spec, die kind:9000 bis kind:9020 Moderations-Events abdeckte. Der Monat schloss mit Paul Miller, der die NIP-44-Konversation am 31. Mai eröffnete, ein XChaCha20-basiertes verschlüsseltes DM-Design, das NIP-04 ersetzen sollte. Die Client-Seite bewegte sich ebenso schnell: Damus lieferte NWC, Zap Pool und Pending Zaps über den Zeitraum 10. bis 15. Mai; Snort launchte Zap Pool und L402-paywalled Media; Amethyst lieferte im Laufe des Monats etwa dreißig versionierte Releases aus, von v0.40.1 am 1. Mai bis zum v0.55.x-Bereich zum Monatsende, mit Zap-Splits in v0.45.0 und NIP-32-Labels in v0.46.0; das Primal-Android-Repo wurde am 16. Mai erstellt; rust-nostr v0.22.0 fügte NIP-47 und NIP-58 hinzu. Am 1. Mai lieferte strfry seine Negentropy-Integration aus, die erste Relay-Implementierung von Doug Hoytes Set-Reconciliation-Protokoll, das später zu NIP-77 werden sollte. Der Monat schloss mit Forbes, das am 30. Mai ein Long-Form-Portrait von fiatjaf veröffentlichte, einer der ersten Mainstream-Presse-Deep-Dives über Nostrs anonymen Gründer.

Mai 2024

Der Konsolidierungszyklus. Weniger auffällige Vorschläge, mehr Ausliefern. NIP-54 Dezentrale Wikis wurde am 2. Mai gemerged mit kind:30818 Artikeln und case-normalisierten d Tags. Drei Tage später wurde NIP-56 erweitert, sodass Missbrauchsberichte digitale Bedrohungen (Malware, Phishing) neben Content-Only-Kategorien flaggen konnten. Am 6. Mai wurden NIP-25 Reaktionen vereinfacht, um den gesamten Reply-Thread nicht mehr als e-Tags einzuschließen. Arthur Franca schlug NIP-22 Comment vor am 12. Mai und führte kind:1111 ein, sodass Antworten auf Nicht-kind:1-Events (Artikel, Dateien, Produkte) eine strukturierte Möglichkeit zum Threading erhalten. Am 19. Mai überholte fiatjaf NIP-46, um NIP-04 vollständig aufzugeben und den gesamten Bunker-Verkehr auf NIP-44-Verschlüsselung umzustellen, der Deprecation-Zug, der jede Bunker-Implementierung seither geprägt hat. Am 20. Mai wurde NIP-71 Video Events mit kind:21 und kind:22 gemerged, und NIP-10 fügte das optionale pubkey-Argument bei e Tags hinzu, sodass Clients Thread-Autoren auflösen können, ohne zuerst das referenzierte Event zu holen. Kieran Walshs NIP-35 Torrents wurde am 22. Mai gemerged, und am 24. Mai referenzierte die NIPs-README erstmals CIP-01 als Off-Repo-Vorschlag, was den Start des “NIPs als eines von mehreren Vorschlags-Venues”-Musters signalisierte. Am 25. Mai entfernte ein Cleanup-PR den aes-256-gcm-Tag aus NIP-71, bevor Downstream-Implementierungen ihn einfroren. NIP-96 fügte list files hinzu und verwarf die Transform-Anforderung am 27. Mai. Am 28. Mai schlug Jonathan Staab vor, die NIP-Akzeptanzhürde anzuheben, sodass mindestens zwei interoperierende Implementierungen erforderlich sind, bevor ein Entwurf aufsteigen kann. Client-Seite: Damus taggte v1.7.2 und v1.8 plus ein v1.9 mit vollem NIP-10 Marker-Handling am 9.–10. Mai, landete NIP-98-Authentifizierung für Push-Benachrichtigungen und lieferte volle NIP-10 Marker-Unterstützung aus. Amethyst machte NIP-17 zum DM-Standard-Modus am 14. Mai, baute NIP-65 Outbox-Model-Relay-Management aus, fügte NIP-96 Server-Auswahl hinzu und lieferte NIP-06 BIP-32/BIP-39 Key-Ableitung aus. Primal Android 0.99.2 am 10. Mai fügte User-Tagging und External-Wallet-NWC hinzu, gefolgt von 0.99.4. Pablo Fernandez landete einen NDK-Optimistic-Update-Cluster über den Zeitraum 24.–31. Mai. Snort fügte NIP-96 Server-Auswahl hinzu, und cashu-ts trennte seine Crypto-Primitive in @cashu/crypto ab.

Mai 2025

Der Monat, in dem NIP-77 (Negentropy Syncing) am 27. Mai gemerged wurde, fiatjafs und Doug Hoytes Spec für das Wire-Protokoll, das Brute-Force-REQ-Filter durch logarithmisch aufwändige Differenzberechnung ersetzt. Dies war dieselbe Negentropy, die strfry zwei Jahre zuvor als relay-seitiges Feature ausgeliefert hatte, jetzt als Client-Relay-Protokoll formalisiert, und der README-Eintrag landete am selben Tag. Die Woche davor definierte NIP-23 Long-Form, wie sich HTML-Dokumente durch einen <link> Tag am 24. Mai mit Nostr-Entitäten assoziieren, das kanonische Web-Copy-Primitiv. NIP-25 fügte Reaction-Target-Relay-Hints am 22. Mai hinzu und verwarf die Emoji-zu-Like/Dislike-Empfehlung, womit Emojis als eigenständige semantische Einheiten behandelt wurden. NIP-52 wurde am 14. Mai vereinfacht, um sich auf die kinds zu konzentrieren, die Clients in der Produktion auslieferten, der Zuschnitt, der die Formstr-Kalender-Erweiterungen ein Jahr später einfacher aufpfropfbar machte. Am 9. Mai betraten Follow Packs (kind 39089 kuratierte Follow-Listen) und Favorite Relays (eine neue replaceable-Liste unter NIP-51) am selben Tag die README. Der Marmot-Protokoll-Bogen hatte noch nicht begonnen: nur das whitenoise-rs Repo existierte (erster Commit am 9. September 2024), und der Mai 2025 war seine Svelte+Tauri-Prototyp-Phase, wobei der Commit vom 14. Mai Tauri-spezifischen Code entfernte, als das Projekt auf seine aktuelle Architektur schwenkte. Der dedizierte MDK-Rust-Core (12. September 2025), das Marmot-Spec-Repo (19. September 2025) und die Flutter-UI (2. Dezember 2025) kamen alle später im Jahr. Auf Client-Seite lieferte Damus’ Notedeck v0.4.0 am 5. Mai als erstes Beta aus, aufgestiegen aus dem Alpha, mit Volltextsuche, dem Dave AI-Assistenten, Zaps über NWC, GIFs, User-Tagging und Mute-Listen. Zwei Tage später überschritt hodlbods Flotilla 1.0.0 die Public-Launch-Grenze als NIP-29-basierter Gruppen-Chat-Client, neben Coracle 0.6.12, dem ersten von sechs Coracle-Releases, die bis zu 0.6.17 am 14. Mai liefen. Amber v3.4.0 am 12. Mai wechselte von deprecateten Android Autofill- und ClipboardManager-APIs weg und migrierte von verschlüsselten Shared Preferences zu DataStore. Primal Android 2.2.20 am 20. Mai fügte den Redeem-Code-Flow für Primal Premium und eine überarbeitete Bildgalerie hinzu. nak v0.14.0 am 21. Mai veröffentlichte ein Minor der kanonischen CLI in derselben Woche wie die Coracle-, Flotilla- und Notedeck-Releases. OpenSats erhielt seine bislang größte Nicht-Bitcoin-Treasury-Spende, als die Reynolds Foundation 2 Millionen Dollar spendete am 22. Mai.

Mai 2026

Der Monat, der in Newsletter #21, #22, #23 und dieser Ausgabe behandelt wird. Der bestimmende Faden ist MLS-auf-Nostr, das Multi-Client-Produktion erreicht: MDK 0.8.0 lieferte MIP-05 Leaf-Index-Primitive und adressierbare Key Packages aus, gefolgt von PR #306, der NIP-40-Validierung für verschwindende Nachrichten über iOS und Android durch eine geteilte UniFFI-Oberfläche hinzufügt. White Noise v2026.5.22+25 lieferte iOS-Push durch eine Notification Service Extension aus, die MLS-Chiffretext innerhalb des Extension-Prozesses entschlüsselt, sodass der Broker niemals Klartext sieht, und zwei neue Marmot-Clients erschienen: Scramble (ein .NET/Avalonia-Desktop- und Android-Client mit Multi-Device-KeyPackage-Slots) und Cordn (eine alternative MLS-Architektur mit einem Per-Group-Koordinator über ContextVM). Angor migrierte sein verschlüsseltes Messaging von NIP-04 zu NIP-44 in PR #860 und schloss den Deprecation-Bogen, der mit Paul Millers NIP-44-Vorschlag im Mai 2023 eröffnet wurde. Das Formstr-Team öffnete die größte koordinierte NIP-Einreichung der jüngeren Erinnerung am 17. Mai, mit PR #2350 für Selbst-Entfernung von Teilnehmern, PR #2351 für private Kalender-Events und Wiederholung (NIP-52E und NIP-52R) und PR #2352 für dezentrale Terminplanung, wobei calendar.formstr.app bereits die Referenzimplementierung ausliefert. Amethyst v1.11.0 renderte NIP-52-Kalender als Timeline-Kategorie und erweiterte On-Chain-Bitcoin-Zaps auf Split-Verteilungen. Ein Jahr nachdem NIP-77 im Mai 2025 gemerged wurde, lieferten drei unabhängige Implementierungen im selben Fenster Negentropy-Adoption aus: Notedeck PR #1459 verdrahtete es in Damus’ Desktop-Client für Giftwrap und Thread-Backfill, Vector v0.4.0 nutzte vollständige Negentropy-MLS-Synchronisation als Teil seiner grundlegenden vector-core-Neufassung neben One-Click-Tor und einer 21-Tool-MCP-Agent-Oberfläche, und Citrine v3.0.0-pre1 fügte es dem Android-nativen Relay neben eingebautem Tor und Multi-Relay-Aggregation hinzu. Mostro v0.17.4 schloss die Anti-Abuse-Bond-Schleife mit Phase-3-Slashed-Bond-Payouts in PR #738 und setzte durch, was das Protokoll zuvor nur androhte. Drei Jahre von “sollen wir NIP-04 ersetzen” zu “sollen wir NIP-44 mit vollem MLS-Gruppenzustand ersetzen”.

Wenn du diskutieren möchtest, DM uns auf Nostr.

Nostr Compass #23

Thu, 21 May 2026 00:00:00 +0000

Primal 3.5 liefert eine überarbeitete Android-Shell aus, Amethyst fügt Onchain-Bitcoin-Zaps hinzu, White Noise erhält Markdown-Rendering und Deep Links, Keycast besteht ein Security-Audit, und AgentNoise ermöglicht die Steuerung lokaler KI-Coding-Agenten über Marmot-verschlüsselten Chat. Hostr startet eine P2P-Vermietungsplattform auf Nostr mit vier NIP-Entwürfen für Listings, Reservierungen und EVM-basierten Escrow. Angor migriert verschlüsseltes Messaging von NIP-04 zu NIP-44, Dart NDK fügt NIP-77 und einen Web-Signer hinzu, Alby js-sdk v8 liefert nativen NWC-Multi-Relay-Reconnect, und KeyChat schließt eine Forward-Secrecy-Lücke im Signal One-Time-Prekey-Löschen. Auf Protokollseite erreicht Mostros Anti-Abuse-Bond Phase 2, Wisp liefert private Antworten und gift-wrapped Reaktionen, und eine Welle von Namecoin-NIP-05-Implementierungen berührt in einer einzigen Woche ein halbes Dutzend Clients.

Top-Stories

Primal 3.5 für Android

Primal, der Social-Client, gestützt auf seine eigene Caching-Relay-Infrastruktur, lieferte diese Woche 3.5.9 mit einer überarbeiteten Anwendungs-Shell aus. Das Redesign ersetzt die vorherige Navigationsstruktur mit einem aktualisierten Layout und einem neuen Explore-Screen, der der Haupt-Discovery-Oberfläche ein eigenes dediziertes Zuhause gibt. Das Release fügt Audio-Wiedergabe für Link-Vorschauen hinzu, sodass in Notes eingebettete Audiodateien inline abgespielt werden, ohne den Feed zu verlassen. NIP-05-Verifizierungs-Badges erscheinen jetzt inline auf Profilen und machen die Identitätsbestätigung auf einen Blick sichtbar. Die Notification-Filterung wurde überarbeitet und lässt Benutzer eingrenzen, welche Event-Typen ihre Notification-Liste erreichen. Der Editor erhielt besseres Event-Link-Handling, und die zugrunde liegende Datenbankschicht erhielt Stabilitäts-Fixes.

White Noise: Markdown, Deep Links und Audio-Metadaten

White Noise, die Marmot-verschlüsselte Gruppen-Messaging-App, gebaut auf Nostr und MLS (RFC 9420), hatte eine der bisher geschäftigsten Wochen sowohl in Frontend- als auch Backend-Repositories.

Im Frontend fügt PR #665 vollständiges Markdown-Rendering für Chat-Nachrichten hinzu, sodass fett, kursiv, Code-Blöcke und Links jetzt nativ in der Nachrichtenansicht gerendert werden. PR #675 aktiviert den Leave-Group-Flow, der zuvor für Nicht-Letzt-Admins blockiert war, und PR #661 fügt native Deep-Link-Unterstützung für whitenoise:// und whitenoise-staging:// URIs für Benutzer, Chats und Einstellungen hinzu, ohne HTTP-Redirect-Infrastruktur zu benötigen.

Im Backend in whitenoise-rs sorgt PR #835 dafür, dass die Key-Package-Rotation korrekt funktioniert, indem der d_tag-Slot für kind:30443 Veröffentlichungen wiederverwendet wird, was NIP-33 Replaceable-Event-Semantik ermöglicht, sodass aufeinanderfolgende Key-Package-Rotationen das vorherige Event auf Relays ersetzen und nur das aktuelle Key-Package behalten. PR #833 erweitert FileMetadata um optionale duration_ms- und waveform-Felder für Audio-Anhänge, koordiniert mit MDKs PR #300, der dieselben Felder zu MIP-04-Medien-Tags hinzufügt. Ein neuer whitenoise-markdown-Crate (PR #836) ersetzt den vorherigen nostr-sdk-Token-Parser durch eine dedizierte Markdown-Rendering-Bibliothek.

Die Marmot-Protokollspezifikation selbst erhielt einen Security-Fix in PR #68, der ein Sicherheitsproblem schließt, indem HKDF-SHA256 für Bildschlüsselableitungen in MIP-01 explizit spezifiziert wird, wodurch Ambiguität entfernt wird, die zu Implementierungs-Divergenz führen könnte. In MDK bereinigt PR #307 Welcome-Fehlerbegründungen und begrenzt die gespeicherte Länge, was einen separaten Sicherheitsbefund schließt.

Amethyst v1.10.0: Onchain-Bitcoin-Zaps

Amethyst lieferte diese Woche vier Releases aus, wobei v1.10.0 die Schlagzeile war. Das Release fügt Unterstützung für NIP-BC Onchain-Bitcoin-Zaps hinzu und ermöglicht Benutzern, Zaps direkt onchain über Bitcoin-Transaktionen zu senden, zu empfangen und anzuzeigen. Frühere Releases in der Reihe behoben die Blossom-Blob-Erkennung, um nicht-konforme Dateinamen abzulehnen (v1.09.2), patchten ProGuard-Regeln für Desktop-Builds und mergten PR #2977, um Onchain-Bitcoin-Zapper als dedizierte ₿-Zeile in der erweiterten Reaktionen-Galerie anzuzeigen. Ein in Arbeit befindlicher On-Chain-Transaktions-Historien-Screen mit Paginierung landete in PR #2974.

AgentNoise: Coding-Agenten über White Noise steuern

AgentNoise von nvk ist ein Rust-nativer Desktop-Helper, mit dem man ein White-Noise-Telefon als Steuerungsoberfläche für lokale Codex- und Claude-Coding-Agent-Sessions verwenden kann. Das Tool lauscht auf einen oder mehrere White-Noise-Chats, authentifiziert Absender über einen First-Pairing-PIN-Flow und startet lokale Coding-Agenten über den konfigurierten Launcher. Das Senden von /claude <prompt> vom Telefon öffnet eine neue White-Noise-Arbeitssession, benannt nach dem Maschinen-Hostname und einer kurzen Prompt-Zusammenfassung, und streamt dann Fortschrittsupdates und die endgültige Ausgabe zurück in diesen Chat. Es ist bewusst Rust-first gehalten und hält Node aus dem vertrauenswürdigen Bridge-Pfad heraus. Das Projekt erreichte diese Woche v0.1.24 und fügte kürzere Telefon-lesbare Antworten, Job-Referenzen per kurzem eindeutigem Präfix und einen optionalen lokalen Session-Watcher hinzu. AgentNoise treibt die wn- und wnd-CLIs aus marmot-protocol/whitenoise-rs als Subprozesse an, sodass es seinen Nostr-Transport mit dem White-Noise-Client selbst teilt.

Keycast-Security-Audit abgeschlossen

Keycast, der teamorientierte NIP-46-Remote-Signing-Server, der Nostr-Private-Keys verschlüsselt at rest in SQLite speichert, hat im Mai 2026 ein Security-Audit abgeschlossen. Der Härtungsdurchgang adressierte Auth-, Berechtigungs-, Datenintegritäts- und Abhängigkeitsprobleme, und die Ergebnisse sind in AUDIT.md dokumentiert. Änderungen umfassen: NIP-98 HTTP-Auth erfordert jetzt genau einen u Tag und einen method Tag, lehnt veraltete Zeitstempel ab und validiert payload-Hashes; die ALLOWED_PUBKEYS-Allowlist wird exakt geparst und serverseitig durchgesetzt; leere Policies verweigern jetzt standardmäßig Sign/Encrypt/Decrypt-Anfragen; Foreign-Key-Enforcement ist auf SQLite-Verbindungen aktiviert; und verschachtelte App-Routen wie /teams/:id sind serverseitig geschützt. Eine SQL-Migration normalisiert alte Allowed-Kinds-Berechtigungs-JSON beim Start. Das Projekt befindet sich noch in einem frühen Stadium, und das Audit nennt Restpunkte, die vor dem Vertrauen mit echten Teamschlüsseln zu erledigen sind.

Scramble: Marmot-Client für Desktop und Android

Scramble (früher OpenChat) ist ein .NET/Avalonia-Desktop- und Android-Client für das Marmot-Protokoll, das MIPs 00-04 implementiert: KeyPackage-Veröffentlichung (kind:30443), Gruppen-Metadaten mit der NostrGroupData-MLS-Erweiterung, NIP-59 gift-wrapped Welcome-Events (kind:444), ChaCha20-Poly1305 verschlüsselte Nachrichten (kind:445) und Blossom verschlüsselte Medien-Anhänge. Es ist vollständig interoperabel mit White Noise und jedem anderen Marmot-kompatiblen Client.

Das Projekt lieferte diese Woche 13 Releases aus, mit Multi-Device-Unterstützung als Hauptfeature. Jedes Gerät generiert einen eindeutigen KeyPackage-Slot (ein d-Tag auf kind:30443). Beim Start holt Scramble die eigenen KeyPackages des Benutzers von Relays, erkennt Peer-Device-Slot-IDs und fügt sie automatisch bestehenden MLS-Gruppen über den Staged-Commit-Flow hinzu. Auto-Add ist auf Gruppen beschränkt, in denen der aktuelle Benutzer Admin ist; Nicht-Admin-Gruppen werden übersprungen, mit dem Hinweis, den Gruppen-Admin zu fragen. Ein Forward-Secrecy-Disclosure-Banner informiert neu verknüpfte Geräte, dass alte Nachrichten nicht verfügbar sind. Ein Slot-ID-Reconciliation-Durchgang (TryReconcileSlotId) verarbeitet Geräte, die von Pre-Multi-Device-Versionen migriert wurden, indem Relay-KeyPackage-Bytes gegen lokales Schlüsselmaterial abgeglichen werden, um das korrekte d-Tag zu übernehmen. External-Signer-Reconnect für Amber- und NIP-46-Benutzer wurde ebenfalls behoben: der IsConnected-Guard, der den eingebauten Auto-Reconnect von ExternalSignerService blockierte, wurde an allen neun Aufrufstellen in NostrService entfernt.

Hostr: P2P-Vermietungsplattform auf Nostr

Hostr (Quelle) ist eine Peer-to-Peer-Vermietungsplattform, die vollständig auf Nostr aufgebaut ist. Sie deckt den gesamten Airbnb-artigen Flow ab (Suche und Auflistung von Immobilien, Verhandlung von Reservierungen und Zahlungsabwicklung) mithilfe von vier NIP-Entwürfen, die das Projekt parallel zur Anwendung entwickelt.

Das Accommodation-NIP erweitert NIP-99 Classified Listings (kind:30402 aktiv, kind:30403 Entwurf) um unterkunftsspezifische Tags für Typ (room, house, apartment, villa, hotel, hostel, resort), Check-in/Check-out-Zeiten, Mindestaufenthalt und H3-Geospatial-Cell-Indexes für standortbasierte Suche in konfigurierbarer Präzision. Das Reservation-NIP definiert ein vollständiges Verhandlungs- und Lebenszyklus-Protokoll: kind:32122 replaceable Reservierungs-Events tragen eine d Trade-ID, einen Listing-Anker a Tag und Teilnehmer-p-Tags mit Rollen (buyer, seller, escrow); kind:1327 strukturierte Message-Rumors liefern private negotiate-stage Gegenangebote per NIP-59-Gift-Wraps, sodass die Verhandlung von öffentlichen Relays fernbleibt; kind:1326 Append-Only-Transitions-Events erstellen einen öffentlichen Audit-Trail, sobald eine Reservierung committed. Käuferprivatsphäre wird durch temporäre Nostr-Keys pro Trade bewahrt, die über verschlüsselte participant_proof-Tags an die reale Identität des Käufers gebunden sind. Das Escrow-NIP definiert kind:30303 Escrow-Service-Ankündigungen und kind:17388 User-Trust-Deklarationen; die Referenzimplementierung nutzt EVM-Smart-Contracts auf Rootstock, wobei contractBytecodeHash es Clients erlaubt zu verifizieren, dass der deployte Contract mit einer bekannten geprüften Implementierung übereinstimmt. Das Marketplace-Listing-NIP definiert generische Tags, die von allen NIP-99-Marketplace-Profilen geteilt werden, einschließlich instantBook, negotiable, quantity, securityDeposit, cancellationPolicy und maxDisputePeriod. Diese Woche bereitete das Projekt seine App-Store-Einreichung vor und mergte MCP-Client-Identity-Unterstützung für agent-basierte Automatisierung.

Zwei neue Einträge erschienen diese Woche auf der Shakespeare-MiniApps-Plattform: InkPress, ein KI-Magazin-Generator, der strukturierte magazinartige Inhalte als Nostr-Events veröffentlicht, und PressStr, eine Schreib- und Publishing-Plattform für den Soapbox-Stack.

Diese Woche ausgeliefert

ngit v2.4.4

ngit lieferte v2.4.4 aus und fügte ngit sync --trust-server (-t) für Fälle hinzu, in denen ein Git-Server dem Nostr-Zustand voraus ist. Wenn diese Situation erkannt wird, meldet sync die betroffenen Refs und verlangt das Flag, um ein aktualisiertes State-Event zu signieren und zu veröffentlichen; eine nostr.trust-server-domains Git-Config-Einstellung bietet eine mit Semikolon getrennte Allowlist für Server, denen automatisch ohne das Flag vertraut werden soll.

Amber v6.1.0-pre3 fügt PSBT-Signierung hinzu

Amber veröffentlichte v6.1.0-pre3 mit verbessertem Layout für neue App-Verbindungen, Crash-Fixes und einer Select/Deselect-All-Option auf dem Berechtigungs-Screen. PR #438 fügt PSBT-Signing-Unterstützung sowohl über den Intent-basierten als auch über den NIP-46 Relay-basierten Pfad hinzu und erlaubt Amber, Partially Signed Bitcoin Transactions zu signieren, ohne die nsec der anfragenden App preiszugeben.

Wisp v1.1.0 liefert private Antworten und verwirft Amber-Unterstützung

Wisp veröffentlichte v1.1.0 mit privaten Antworten per NIP-17-Gift-Wrap (PR #540), gift-wrapped Reaktionen und DIP-03-Zaps auf private Antworten (PR #543), Auto-Übersetzung für Notes (PR #523) und einer Register-artigen Fiat-Eingabe im Zap-Dialog. PR #541 migriert private Zaps von einem hausgemachten DM-Relay-Klartext-Schema zu DIP-03 mit korrektem DM-Relay-Routing. Derselbe Release-Zyklus entfernte die NIP-55-Remote-Signer-Unterstützung (PR #531), verwarf Amber und andere externe Signer-Integrationen und entfernte das gebündelte lokale Relay (PR #533). Wisp ist ein Nostr-Social-Client für Android.

Calendar by Formstr v1.5.4 behebt Gift-Wrap für neue Teilnehmer

Calendar by Formstr lieferte v1.5.4 aus (das neueste in einer v1.5.2 → v1.5.4 Sequenz). PR #160 behebt einen Bug, bei dem das Bearbeiten eines privaten Kalender-Events mit neuen Teilnehmern das aktualisierte Event mit den neuen pubkeys in p Tags veröffentlichte, aber nie Gift-Wrap-Einladungen an diese Teilnehmer erstellte oder auslieferte, was den Einladungs-Flow für Last-Minute-Ergänzungen brach. PR #156 fügt Fehlerbehandlung rund um die Private-Event-Entschlüsselung hinzu, sodass Clients nicht mehr bei unentschlüsselbaren Events werfen, und PR #138 korrigiert wiederkehrende Event-Zeiten, die über Zeitzonen drifteten.

Applesauce v6.1.0 fügt NIP-34-Git-Casts und NIP-51-Lookup-Relays hinzu

Applesauce veröffentlichte v6.1.0 über seine Pakete hinweg mit signifikanter NIP-34-Unterstützung (Git-über-Nostr): applesauce-common fügt neue GitRepository-, GitGraspList- und FavoriteGitRepos-Casts plus passende Factories hinzu und exponiert User.favoriteGitRepos$, User.gitAuthors$ und User.graspServers$ als reaktive Eigenschaften, sodass Anwendungen die gefolgten Git-Repos, Repo-Maintainer und konfigurierten GRASP-Server eines Benutzers direkt aus demselben User-Objekt auflisten können. Dasselbe Release fügt Unterstützung für NIP-51 kind 10086 Lookup-Relay-Listen hinzu, eine jüngste Ergänzung zur Relay-List-Familie, die verwendet wird, um herauszufinden, wo bestimmte Daten zu finden sind. applesauce-core gewinnt replaceableAddress auf EventCast für NIP-01 Replaceable-Address-Lookup, plus pointer, kind und einen getReplaceableAddressForEvent-Helper und fügt eine timeline$()-Methode zum Basis-User-Cast hinzu. PR #73 behebt Pool-Manual-Methoden, die offline Relays stillschweigend fallen ließen.

Sprout v0.0.16 liefert Sprig-Binary und Huddle-Protokoll v2

Sprout von Block, ein selbstgehosteter Nostr-Relay-basierter Team-Workspace, in dem Menschen und KI-Agenten dieselben Räume und Event-Logs teilen, lieferte v0.0.16 der Desktop-App zusammen mit Rolling Builds des neuen Sprig-All-in-One-Binaries (PR #605) aus, das den ACP-Harness, den Agenten und das Developer-MCP in ein einzelnes Busybox-artiges Binary bündelt, für einfaches Deployment. Das --no-memory-Flag, hinzugefügt in PR #611, erlaubt Betreibern, die NIP-AE-Core-Memory-Injection für den ACP-Harness zu deaktivieren. Auf der Echtzeit-Seite erweitert PR #609 das Huddle-Voice-Protokoll auf einen v2 Frame-Header, der bis zu 10 gleichzeitige Peers unterstützt.

Nostrord v1.0.3 fügt OS-Keychain und Multi-Account hinzu

Nostrord veröffentlichte v1.0.3 mit lokaler Schlüsselspeicherung, gehärtet über OS-Keychain und Passphrase-Fallback, Multi-Account-Unterstützung und einem tappbaren Bunker-QR-Code, der die Signer-App auf Android öffnet.

Angor migriert zu NIP-44 und liefert Security-Hardening aus

Angor, die Bitcoin-Crowdfunding-App auf Basis von Nostr und Taproot, lieferte diese Woche drei instabile Releases aus (v0.2.24, v0.2.25 und v0.2.26) mit einer Reihe von Security-Hardening- und Nostr-Integrations-Änderungen. PR #860 migriert das verschlüsselte Nostr-Messaging von NIP-04 zu NIP-44 und ersetzt das deprecatete XOR-basierte Schema durch ChaCha20-Poly1305-Verschlüsselung. PR #861 erlaubt Blossom-Medien-Uploads ohne ausgewählte Wallet, indem ein ephemerer Nostr-Auth-Key verwendet wird, wodurch Uploads für Benutzer entsperrt werden, die noch keine Wallet verbunden haben. Die Security-Serie adressierte mehrere gehärtete Kategorien: PR #854 fügt Typsicherheit für AngorKey und Mnemonic-Memory-Schutz hinzu, PR #856 erzwingt Protokoll-Level-Validierung für Timelocks, Fee-Rates, Dust-Schwellenwerte und Penalty-Regeln, und PR #851 wendet Non-Breaking-Hardening über acht Kategorien mittleren und niedrigen Schweregrads an. PR #859 behebt GrapheneOS-Kompatibilität, indem AOT-Kompilierung aktiviert und Runtime-Code-Generierung entfernt wird, und PR #855 verhindert Wallet-Verlust bei Android-Swipe-Kill, indem der Wallet-Zustand persistiert wird, bevor das OS den Prozess beendet.

Alby js-sdk v8.0 liefert NWC-Multi-Relay-Reconnect

Alby js-sdk veröffentlichte die v8.0-Linie (v8.0.1 bis v8.0.3) mit NWC-Multi-Relay-Subscription-Unterstützung. PR #516 aktualisiert die nostr-tools-Abhängigkeit und aktiviert nativen Auto-Reconnect über mehrere Relays, ersetzt den vorherigen Polling-Ansatz durch relay-native Reconnection-Logik. PR #542 ersetzt alle console.debug-Aufrufe durch eine injizierbare Logger-Schnittstelle, sodass Anwendungsentwickler SDK-Diagnosen durch ihre eigene Logging-Infrastruktur routen können. Das Release verwirft den WebSocket-Polyfill und erfordert Node.js 22 oder höher für serverseitige Konsumenten. v8.0.2 fügte einen Fix für einen Utils-Crypto-Import-Bug hinzu, der bestimmte Bundler brach.

KeyChat v1.41.1 behebt Forward Secrecy

KeyChat, eine Messaging-App, die das Signal-Protokoll mit Nostr-Relay-Transport kombiniert, veröffentlichte v1.41.1+6513. Der Schlagzeilen-Fix erzwingt Forward Secrecy, indem Signal-One-Time-Prekeys unmittelbar nach einer erfolgreichen Entschlüsselung gelöscht werden, was eine Lücke schließt, in der ein zurückbehaltener Prekey verwendet werden könnte, um vergangene Nachrichten zu entschlüsseln, falls das Gerät später kompromittiert wird. Das Release fügt außerdem URL-Vorschau für Nachrichten hinzu, die aus einem einzelnen Link bestehen, zentralisiert Medien-Auto-Download unter einem neuen FileDownloadManager mit einem 20-MB-Auto-Schwellenwert und refaktoriert das NIP-11-Relay-Info-Fetching, um beim Kaltstart einen Force-Refresh zu erzwingen, sodass Paid-Relay-Fee-Konfigurationen immer korrekt geladen werden.

In Entwicklung

Citrine mergte PR #151 und implementierte NIP-70-Enforcement: das Android-Relay blockiert jetzt Reposts, die geschützte Event-Inhalte einbetten, wie die Spezifikation es verlangt. PR #149 fügt Anzeige- und Kopieraktionen für mehrere Verbindungsadressen, Localhost, lokales WLAN und Tor, vom Relay-Einstellungs-Screen aus hinzu. PR #141 fügt NIP-42 AUTH-Challenge-Handling über externe Signer-Integration mit Amber hinzu.

Mostro erreichte Phase 2 seines Anti-Abuse-Bond-Rollouts. PR #737 landet Solver-directed Dispute-Slash-Logik: Admin-Handler konsumieren jetzt die BondResolution-Payload von mostro-core, wodurch ein Admin bei der Auflösung eines Disputes den Bond einer der Parteien slashen kann. Phase 1.5, gemerged in PR #736, führte eine dedizierte PayBondInvoice-Aktion und einen WaitingTakerBond-Status ein und trennte die Anti-Abuse-Bond-Zahlung des Takers vom Trade-Payout des Käufers. Der Mobile-Client fügte die vollständige Phase-1.5-UX in PR #592 hinzu. Mostro ist ein Peer-to-Peer-Bitcoin-Exchange-Protokoll auf Basis von Nostr.

Damus mergte PR #3773 und stellte den Relay-Signal-Indikator wieder her, und PR #3775 behebt Relays, die sich nach einem anfänglichen Verbindungsfehler nicht wieder verbanden.

rust-nostr mergte PR #1358 und fügte Event-Finalization-Traits und NIP-spezifische Event-Builder hinzu, was es einfacher macht, korrekt typisierte Events für bestimmte Protokollfunktionen zu konstruieren. PR #1363 portiert einen Fix zurück, der sicherstellt, dass der NIP-46-Signer Notifications abonniert, bevor er die Connect-Antwort sendet, was eine Race-Condition schließt, bei der Client-Nachrichten, die unmittelbar nach Connect eintrafen, verpasst werden konnten.

dart-nostr mergte PR #44 und fügte einen Namecoin-.bit-Relay-Resolver und TLSA-Pin-Records hinzu, was Flutter-Anwendungen erlaubt, wss://example.bit/-Relay-URLs über Namecoin-DNS zu ihren tatsächlichen WebSocket-Adressen aufzulösen.

Dart NDK (das Dart/Flutter-Nostr-Development-Kit, jetzt bei relaystr/ndk) mergte PR #464 und implementierte NIP-77, das Offline-Event-Signing-Protokoll. Auf Signer-Seite fügen PR #602 und PR #601 einen web-spezifischen Event-Signer und eine PlatformEventVerifier-Abstraktion hinzu, sodass Flutter-Web-Apps den Plattform-Signer ohne separaten Codepfad nutzen können; PR #604 führt eine Event-Signer-Factory für Runtime-Signer-Auswahl ein. PR #608 fügt getDmRelays() zum Abrufen einer NIP-17-DM-Relay-Liste eines Benutzers (kind:10050) hinzu, und PR #600 behebt die NIP-46 Signed-Field-Preservation, sodass Remote-Signer keine Felder beim Round-Trip verlieren.

Pages by Form* (Repo), Formstrs Nostr-natives kollaboratives Dokument-App, gehostet auf pages.formstr.app, mergte diese Woche vier PRs, die die Encrypted-Attachment- und Dokument-Management-Flows straffen. PR #37 behebt fehlende Bilder in DOCX-, HTML- und PDF-Exports, indem verschlüsselte Anhänge inline eingebunden werden: es holt <encrypted-file>-Blobs von Blossom-Servern, entschlüsselt sie mit AES-GCM 256-Bit unter Verwendung des gespeicherten Schlüssels und Nonce, validiert den Bild-MIME-Typ und konvertiert sie in Base64-Data-URLs, sodass Exports Bilder erhalten, die nur auf Blossom in verschlüsselter Form existieren. PR #39 fügt einen lokalen Dokument-Suchmechanismus hinzu, PR #38 räumt den Rename-Flow auf, und PR #40 behebt Shared-Backup-Handling.

Zap Cooking mergte PR #396, die erste Phase einer Feed-Überarbeitung, die Feed-Rendering-Primitive legt, ohne noch benutzersichtbare Änderungen. Der PR führt einen NIP-92 imeta Tag-Parser ein, der die Slots url, m (MIME), dim (Dimensionen), blurhash, alt, x (File-Hash) und fallback liest, plus einen handportierten kanonischen Blurhash-Decoder (~200 LOC), der PNG-Data-URLs per Canvas mit einem SSR-sicheren Null-Fallback erzeugt. Wenn imeta-Tags fehlen, greift der Parser auf das Extrahieren roher Bild- und Video-URLs aus dem Event-Inhalt zurück und nutzt dieselben Heuristiken, die der aktuelle Feed bereits verwendet.

Nurunuru (ぬるぬる, tami1A84/null--nostr), ein Nostr-Client mit nativen Android-, iOS- und Web-Varianten, die eine Rust-FFI-Engine teilen, mergte seinen v1.5.0 Native → Web Sync in PR #176. Der Sync bringt mehrere Feature-Ergänzungen zum Web-Build, die auf Android v1.4.9 und iOS 1.0.4 bereits ausgeliefert waren: das NotificationModal zeigt jetzt Geburtstagsbenachrichtigungen, Mutual-Follow-Zap-Erkennung und benutzerdefinierte Emoji-Reaktions-Benachrichtigungen; der Reaction-Picker verwirft die Unicode-Default-Reactions-Quick-Row und zentriert die UX auf benutzerdefinierte Emoji; die Empfehlungsmaschine in lib/recommendation.js filtert Benutzer ohne Icons oder Display-Names heraus und priorisiert Following-Einträge, während Recommended im Hintergrund lädt. Spracheingabe ist das eine Feature, das in die andere Richtung geht: der Web-Build verwendet bereits ElevenLabs-Scribe-Streaming, und v1.5.0 synchronisiert die Native-Seite teilweise zum OS-Standard SpeechRecognizer (Android) und SFSpeechRecognizer + AVAudioEngine (iOS), während die vollständige Native-Scribe-Integration auf v1.6 verschoben wird.

Protokoll- und Spezifikationsarbeit

PR #2251 verschärft die NIP-70-Protected-Events-Spezifikation: es wird jetzt explizit festgelegt, dass Reposts, die den vollen Inhalt eines geschützten Events einbetten, von Relays abgelehnt werden müssen. NIP-70 definiert den - Tag, der signalisiert, dass ein Note-Autor der Republikation seiner Note nicht zustimmt. Die ursprüngliche Spezifikation deckte das Verhalten der Relay-Filterung ab, ließ den Repost-Fall aber mehrdeutig. Dieser PR schließt diese Lücke. Citrines PR #151 implementiert die Durchsetzung auf Relay-Seite in derselben Woche.

PR #1653 schlägt ein Drafts-NIP zum Speichern und Synchronisieren privater Draft-Events vor. Der Vorschlag verwendet replaceable Events mit einem draft-Status und NIP-44-Verschlüsselung an den eigenen Key des Autors, wodurch Clients Work-in-Progress-Werke auf Relays speichern können, ohne dass diese Events für irgendjemanden anderes sichtbar sind. Das Draft-Event trägt das vollständige, zur Veröffentlichung vorgesehene Event als verschlüsselten Inhalt, einschließlich seines schließlichen kinds und seiner Tags.

Snapshots (PR #2279) ist ein offener Vorschlag, ein unveränderliches Snapshot-Event zur Bewahrung einer exakten Version eines replaceable Nostr-Events zu definieren. Das Snapshot-Event trägt den vollständigen Inhalt des replaceable Events zu einem bestimmten Zeitpunkt, mit einem a Tag, der zurück zur Adresse des replaceable Events verlinkt, sodass alle historischen Versionen zusammen abgefragt werden können. Das macht es möglich für Beobachter, historischen Zustand zu inspizieren, selbst nachdem Relays alte Versionen nicht mehr aufbewahren.

Namecoin-NIP-05-Welle: Diese Woche gab es einen koordinierten Vorstoß, .bit NIP-05-Auflösung zu Nostr-Clients hinzuzufügen. Der NIP-Diskussions-Feed erfasste Open-Source-PRs gegen Aegis (#14, der Sign-Time-Verifikation beim Signer hinzufügt), nostter (#2128) und dart-nostr (#44), neben einem Upstream-NIP-Entwurf (PR #2349). Der Aegis-PR ist bemerkenswert dafür, die Verifikation auf die Producer-Seite zu setzen: der Signer prüft die Namecoin-Chain, bevor er ein kind:0-Event signiert, das eine .bit-Identität beansprucht, und warnt den Benutzer bei Nichtübereinstimmung, wodurch das Problem erkannt wird, bevor das Event ein Relay erreicht.

NIP Deep Dive: NIP-07 (window.nostr für Web-Browser)

NIP-07 definiert die window.nostr-Schnittstelle, die Browser-Erweiterungen für Webanwendungen bereitstellen. Es ist die am weitesten verbreitete Signer-Schnittstelle im Web, implementiert von Erweiterungen wie Alby, nos2x, Flamingo und horse.

Die Schnittstelle hat zwei erforderliche und mehrere optionale Methoden. window.nostr.getPublicKey() gibt den Public Key des Benutzers als Hex-String zurück, ohne dass der Private Key jemals an die aufrufende Seite freigegeben wird. window.nostr.signEvent(event) nimmt ein partielles Event mit created_at, kind, tags und content entgegen und gibt das vollständige signierte Event zurück, mit hinzugefügtem id, pubkey und sig. Der wichtige Punkt ist, dass der Private Key niemals den isolierten Kontext der Erweiterung verlässt; die Webanwendung reicht ein unsigniertes Event ein und erhält ein signiertes zurück.

Die optionalen Methoden decken Verschlüsselung ab: window.nostr.nip04.encrypt und window.nostr.nip04.decrypt für das ältere NIP-04-Schema (jetzt deprecated) und window.nostr.nip44.encrypt und window.nostr.nip44.decrypt für das aktuelle NIP-44-Schema. Erweiterungen, die NIP-44 unterstützen, können daher sowohl Direct-Message-Verschlüsselung als auch jede andere Anwendung, die pubkey-gebundene Verschlüsselung benötigt, verarbeiten, ohne dass die aufrufende Seite den nsec sieht.

Die Spezifikation enthält auch eine Empfehlung an Erweiterungs-Autoren: Skripte mit "run_at": "document_end" im Erweiterungs-Manifest zu laden, sodass window.nostr synchron verfügbar ist, wenn die Seite lädt, wodurch Race-Conditions vermieden werden, bei denen ein Client window.nostr prüft, bevor die Erweiterung es injiziert hat.

Ein wichtiges Beispiel für NIP-07 in Aktion ist das oben behandelte Keycast-Projekt. Das Keycast-Web-Frontend nutzt NIP-07, um NIP-98-HTTP-Auth-Events zu signieren: die SvelteKit-App handhabt den nsec des Benutzers nie direkt. Sie ruft window.nostr.signEvent auf, um den Auth-Header zu erzeugen, und sendet diesen Header dann an die Keycast-API. Diese Architektur bedeutet, dass das Schlüsselmaterial während des gesamten Team-Key-Management-Flows in der Browser-Erweiterung bleibt.

{
 "id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 1,
 "tags": [],
 "content": "Hello from a NIP-07 signed event",
 "sig": "0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2cdd"
}

NIP Deep Dive: NIP-39 (externe Identitäten in Profilen)

NIP-39 definiert, wie ein Nostr-Benutzer die Kontrolle über externe Plattform-Identitäten in seinem Profil deklarieren kann. Jede Deklaration verwendet einen i Tag innerhalb eines kind:10011-Events und behauptet den Besitz eines bestimmten Kontos auf einer anderen Plattform zusammen mit einem Beweis, der unabhängig verifiziert werden kann.

Jedes Tag folgt dem Format ["i", "platform:identity", "proof"], wobei platform:identity den Plattformnamen und den Benutzernamen mit einem Doppelpunkt-Separator kombiniert (github:semisol, twitter:semisol_public). proof zeigt auf ein verifizierbares Artefakt auf der Plattform selbst.

Für GitHub ist der Beweis eine Gist-ID. Der Benutzer erstellt aus seinem GitHub-Konto einen öffentlichen Gist, der den Text Verifying that I control the following Nostr public key: npub1... enthält. Ein Client, der die Behauptung verifiziert, holt https://gist.github.com/<identity>/<proof> und prüft, dass der Gist vom beanspruchten GitHub-Benutzernamen verfasst wurde und den erwarteten pubkey enthält. Für Twitter ist der Beweis eine Tweet-ID, für Mastodon eine Post-ID und für Telegram eine Nachrichten-Referenz in einer öffentlichen Gruppe.

Der Identitätsanbieter-Name darf nur a-z, 0-9 und die Zeichen ._-/ enthalten und darf : nicht enthalten. Identitätsnamen sollten auf Kleinbuchstaben normalisiert werden, wobei der primäre Alias verwendet wird, wenn mehrere existieren.

Die diese Woche stattfindende Namecoin-.bit-NIP-05-Diskussion zeigt die Rolle von NIP-39 im breiteren Identity-Stack: es bietet einen standardisierten, relay-agnostischen Weg, einen Nostr-Key mit einer etablierten Identität andernorts zu kreuzverweisen, ohne eine zentrale Verifikationsstelle zu benötigen. Ein Client kann den Beweis unabhängig verifizieren, indem er ein öffentliches Artefakt auf der benannten Plattform holt, und der Beweis ist an den spezifischen Nostr-pubkey im Gist- oder Tweet-Text gebunden, nicht an eine generische Plattform-Credential.

{
 "id": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 10011,
 "tags": [
 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
 ["i", "twitter:semisol_public", "1619358434134196225"],
 ["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"]
 ],
 "content": "",
 "sig": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3eff"
}

Das war’s für diese Woche. Wenn du an etwas baust oder Neuigkeiten zu teilen hast, DM uns auf Nostr oder finde uns unter nostrcompass.org.

Nostr Compass #22

Wed, 13 May 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, Ihrem wöchentlichen Leitfaden zur Nostr-Protokollentwicklung.

Diese Woche: Nostr VPN liefert acht Releases in sieben Tagen von einem neu gestalteten Geräte-Pairing-Flow über einen FIPS-AEAD-Tausch, der den TCP-Durchsatz ungefähr verdoppelt. Marmot Protocol (die Grundlage für White Noise) liefert ein Frontend-Release, das das Benutzer-Blockierungsfeature abschließt, und 31 fusionierte PRs über MDK und Backend. Grain liefert v0.6.0 mit vier neuen NIP-Implementierungen in einem Meilenstein. Citrine liefert v3.0.0-pre1 mit eingebautem Tor und Relay-Aggregation. Amber liefert v6.1.0-pre2 mit Verbindungsflow- und Signierungsverbesserungen. Alby Hub liefert v1.22.2 mit einer KI- und Agents-Seite und Core-Lightning-Integration. Mostro liefert gleichzeitige Taker-Bonds und mostro-core v0.11.0. Jumble liefert fünf Releases mit Suchverlauf und Account-Daten-Persistenz-Fixes. Nostrord liefert drei Releases mit Gruppen-Share-Modals und Arch-Linux-Paketen. Flotilla liefert 1.8.0 mit Videoanrufen, E-Mail-Rendering und Raum-Erwähnungen. Calendar by Formstr liefert v1.5.1 mit Terminplanung und Android-Kalendersync. Tamagostrich startet ein dezentralisiertes NIP-78-Tamagotchi mit Sats-Belohnungen.

Top-Geschichten

Nostr VPN liefert acht Releases, gipfelnd in v4.0.10

Nostr VPN, das Rust-basierte dezentralisierte Mesh-VPN, das Nostr für Peer-Discovery und ein FIPS-gestütztes Noise-Protokoll für die Datenebene verwendet, lieferte acht Releases von v4.0.1 bis v4.0.10 über macOS, Linux, Windows und Android diese Woche.

Die Hauptänderung ist in v4.0.8: Das AEAD wurde vom RustCrypto-chacha20poly1305-Soft-Backend auf BoringSSLs ChaCha20-Poly1305 in ring 0.17 getauscht, das hand-abgestimmtes NEON auf aarch64 und AVX2/AVX-512 auf x86_64 verwendet. Docker-Benchmarks auf identischer Hardware zeigten, dass der 2-Node-Direkt-TCP-Durchsatz von 437 auf 1097 Mbps sprang. Das Drahtformat ist unverändert.

Früher in der Woche baute v4.0.1 den Geräte-Pairing-Flow mit Exit-Node-Leckschutz, einem einheitlichen WireGuard-Konfigurationsblock unter Exit-Nodes und signierten/notarisierten macOS-Artefakten neu. v4.0.9 fügte sendmmsg(2)-Batching auf dem UDP-Sendepfad hinzu, amortisierte Pro-Paket-sendto-Syscalls über 8-Paket-Batches und schob TCP Single-Stream von 1066 auf 1548 Mbps (1,45×).

Marmot / White Noise liefert blockierungskomplettes Frontend und 31 fusionierte PRs über MDK und Backend

White Noise, die private Gruppen-Messaging-App, die auf dem Marmot-MLS-basierten Protokoll aufgebaut ist, lieferte v2026.5.7+24 am 7. Mai als das Frontend-Release, das das Blockierungsfeature-Set abschließt. Das vorherige Release lieferte Stummschalten, Suche und Archivierung; dieses vollendet die Blockierung. Ein blockierter Benutzer ist jetzt aus Einladungen, Chat-Vorschauen, Nachrichtenzeitlinien, Suchergebnissen und Benachrichtigungen ausgeblendet, und seine Nachrichten zählen nicht mehr zu ungelesenen Abzeichen. Video-Anhänge funktionieren Ende-zu-Ende über Geräte hinweg.

Die unterstützende Arbeit umfasst 31 fusionierte PRs über MDK und das Backend. MDK landete PR #258 mit dem Extension-v3-Drahtformat und disappearing_message_secs-Schema, was die Grundlage für verschwindende Nachrichten legt.

Grain v0.6.0 fügt NIP-40, NIP-50, NIP-70 und NIP-45 hinzu

Grain, die Go-basierte Nostr-Relay- und Client-Bibliothek, lieferte v0.6.0 am 6. Mai mit vier neuen NIP-Implementierungen und einem Produktionshärtungs-Pass. Der v0.6-Meilenstein fügt NIP-40-Event-Ablauf, NIP-50-Volltextsuche, NIP-70-geschützte Events und NIP-45-Event-Zählungen hinzu.

Event-Ablauf über NIP-40 lässt Publisher einen Ablaufzeitstempel setzen, damit der Relay Events nach ihrem Ablauf verwirft, in der Praxis für ephemere Präsenz-Events und zeitlich begrenzte Ankündigungen verwendet. NIP-50-Volltextsuche lässt Clients search-Filter in REQ-Nachrichten ausgeben und den Relay die Abgleicharbeit machen. Geschützte Events über NIP-70 verhindern, dass Relays Events ohne die ausdrückliche Erlaubnis des Autors weitergeben. NIP-45-Zählabfragen lassen Clients einen Relay fragen, eine Anzahl übereinstimmender Events zurückzugeben.

Lieferungen dieser Woche

Citrine v3.0.0-pre1 bringt eingebauten Tor und Relay-Aggregation

Citrine, die Android-App, die ein Telefon in einen Nostr-Relay-Knoten verwandelt, lieferte v3.0.0-pre1 als Pre-Release diese Woche. Die Hauptzusätze sind eingebaute Tor-Unterstützung für datenschutzerhaltenden Relay-Zugang und Relay-Aggregation, bei der Citrine Events von mehreren Upstream-Relays abrufen und lokalen Clients bereitstellen kann. PR #139 fügt NIP-77 (Negentropy-Abgleich)-Unterstützung für effizienten set-reconciliation-basierten Event-Sync hinzu.

Amber v6.1.0-pre2 verbessert neuen App-Verbindungsflow

Amber, die Android-Signer-App für NIP-55 (Android Signer Application) und NIP-46, lieferte v6.1.0-pre2. Die Hauptfixes: Der Signer-Dialog schließt sich jetzt korrekt nach dem Akzeptieren einer Bunker-Anfrage, fehlerhafte Bunker-Anfragen zeigen einen Invalid-Request-Bildschirm, und Rate-Limiting wird für intentbasierte Signieranfragen hinzugefügt.

Alby Hub v1.22.2 fügt KI- und Agents-Seite und Core-Lightning-Unterstützung hinzu

Alby Hub, der selbstverwahrende Lightning-Knoten und Nostr-Wallet-Connect-Server, lieferte v1.22.2 mit mehreren wichtigen Zusätzen. Die neue KI- und Agents-Seite legt Alby Hubs Lightning- und NWC-Fähigkeiten für KI-Agents und MCP-kompatible Tools frei. Das meistgewünschte Feature seit dem Launch wurde geliefert: Core Lightning (CLN) ist jetzt ein unterstütztes Backend neben LND und LDK.

Mostro liefert gleichzeitige Taker-Bonds und mostro-core v0.11.0

Mostro, das Peer-to-Peer-Bitcoin-Handelsprotokoll auf Nostr, fusionierte 11 PRs diese Woche und advance das Taker-Bond-Feature, das Griefing verhindert, indem beide Parteien Mittel sperren müssen, bevor ein Handel fortschreitet. PR #733 implementiert gleichzeitige Taker-Bonds, bei denen mehrere Taker gleichzeitig Bond-Rechnungen einreichen können und der erste, der sperrt, gewinnt.

mostro-core lieferte v0.11.0 mit den passenden Bibliothekszusätzen, und mostro-cli lieferte v0.15.0.

Jumble liefert fünf Releases mit Zuletzt-Gesucht und Account-Persistenz

Jumble, der relay-zentrische Nostr-Client als Web-App und Electron-Desktop-App, lieferte fünf Releases diese Woche: v26.5.2 bis v26.5.6. v26.5.5 fügt Suche-zuletzt-Verlauf hinzu. Ein kritischer Persistenz-Bug ist in v26.5.6 behoben: Accounts und gecachte Daten überleben jetzt einen vollständigen App-Neustart.

Nostrord, ein Nostr-Client für NIP-29-relay-basierte Gruppen, lieferte v1.0.0, v1.0.1 und v1.0.2 diese Woche. v1.0.1 liefert Arch-Linux-Pakete über AUR als nostrord-bin mit PGP-signierten .pkg.tar.zst-Artefakten, und v1.0.2 fügt Gruppen-Sharing über PR #49 mit einem Share-Modal hinzu, das sowohl einen nostr:naddr-URI als auch einen webfreundlichen nostrord.com/open/-Link generiert.

FIPS v0.3.0 liefert plattformübergreifende Reichweite, Nostr-Peer-Discovery und ein Gateway für unmodifizierte LANs

FIPS (Free Internetworking Peering System), das Nostr-native Mesh-Netzwerk-Projekt, lieferte v0.3.0 diese Woche als wichtigen Meilenstein, der das Projekt von Linux-only auf Linux, macOS, Windows und OpenWrt erweitert. Der Hauptzusatz ist Nostr-vermittelte Peer-Discovery mit STUN-unterstützter UDP-NAT-Traversal. Knoten veröffentlichen jetzt signierte Overlay-Adverts als kind:37195-parametrisierte ersetzbare Events auf öffentlichen Nostr-Relays.

Flotilla 1.8.0 liefert Videoanrufe, E-Mail-Rendering und Raum-Erwähnungen

Flotilla, die NIP-29-relay-basierte Gruppen-Chat-App von hodlbod, lieferte 1.8.0 diese Woche mit mehreren bemerkenswerten Zusätzen. Sprach-Räume unterstützen jetzt Video: Teilnehmer können Kameras einschalten oder ihren Bildschirm während eines Anrufs teilen. E-Mail-Rendering kommt über ein Update der welshman-Bibliothek: Flotilla kann jetzt Nachrichten empfangen, die eingebettete HTML-E-Mail-Inhalte enthalten, und rendert das HTML inline.

Calendar by Formstr liefert v1.5.1 mit Terminplanung und Android-Kalendersync

Calendar by Formstr, eine Nostr-native Kalender-App, lieferte v1.5.0 am 10. Mai und v1.5.1 am 11. Mai. Terminplanung kommt in PR #89, das Benutzern erlaubt, buchbare Zeitfenster in ihrem Kalender zu erstellen. Schreibgeschützte Android-Kalender-Integration in PR #123 synchronisiert Nostr-Events mit dem Gerätekalender.

In Entwicklung

Amethyst fügt geplante Beiträge, NIP-9A-Community-Regeln und ein Desktop-Local-Relay hinzu

Amethyst, der funktionsreiche Android-Client, fusionierte 78 PRs diese Woche über mehrere wichtige Feature-Bereiche. Geplante Beiträge landen auf Android in PR #2765: Benutzer können eine Notiz verfassen und eine zukünftige Veröffentlichungszeit setzen. Ein Desktop-Build erhält ein eingebettetes lokales Relay mit SQLite-Event-Persistenz in PR #2841.

Shopstr fügt MCP-Audit-Protokollierung und Sitzungssicherheit hinzu

Shopstr, der dezentralisierte Marktplatz auf Nostr, fusionierte fünf PRs diese Woche. Audit-Protokollierung für die MCP-Tool-Schicht landet in PR #456, und Sitzungssicherheit wird in PR #477 verschärft.

Dart NDK fügt Web-Unterstützung und Seal-Signatur-Verifizierung hinzu

Dart NDK, die Dart-Bibliothek für Nostr-Protokollentwicklung, fusionierte sechs PRs diese Woche. Web-Unterstützung kommt in SembastCacheManager über PR #571, und Seal-Signatur-Verifizierung landet in PR #595 für den NIP-59 (Gift Wrap)-Flow.

Neue Projekte

Tamagostrich startet ein dezentralisiertes NIP-78-Tamagotchi mit Sats-Belohnungen

Tamagostrich ist ein browser-basiertes virtuelles Haustierspiel, das beim IDENTITY Hackathon 2026 gestartet wurde, bei dem ein Baby-Strauß, Nori, sich durch deine Nostr-Social-Aktivität entwickelt. Der Haustierstatus lebt in einem NIP-78-kind:30078-Event, damit er über jedes Gerät synchronisiert wird, das dasselbe Schlüsselpaar teilt. Meilenstein-Belohnungen zahlen automatisch in Sats über NIP-47 (Nostr Wallet Connect) aus: 50 Sats auf Level 5, 210 Sats auf Level 10 und 420 Sats auf dem maximalen Level 21.

Protokoll- und Spezifikationsarbeit

Das NIPs-Repository fusionierte PR #2338, das README-Referenzlinks für Marmot-Event-Kinds und den Geocaching-Kind 37516 behebt. Fünf neue Vorschläge wurden diese Woche eröffnet:

PR #2331 schlägt NIP-9A: Verifizierbare Community-Regeln vor, das kind:34551 einführt, ein parametrisiertes ersetzbares Event, das einem Community-Eigentümer erlaubt, ein maschinenlesbares, kryptografisch signiertes Regelwerk zu veröffentlichen.

PR #2335 schlägt Reservierungs-Events für Nostr-Marktplätze vor, das kind:32122 (parametrisierte ersetzbare Reservierungs-Events), kind:1326 (Append-only-Übergangs-Audit-Records) und kind:32124 (Post-Trade-Bewertungen) definiert.

PR #2334 schlägt Treuhandservices für Nostr-Marktplätze vor, das kind:30303 für Treuhandoperatoren verwendet, um ihre EVM-Vertragsadresse und Gebührenplan zu deklarieren.

PR #2333 schlägt Unterkunftslisten-Profile für NIP-99-Marktplatz-Listings vor, das NIP-99-klassifizierte Listings mit H3-Geospatial-Index-g-Tags erweitert.

PR #2332 schlägt NIP-BC: Onchain-Zaps (kind 8333) vor, das eine direkte Identität zwischen Nostr-Schlüsseln und Bitcoin-Taproot-Adressen ausnutzt: Ein Nostr-Pubkey ist ein 32-Byte-x-only-secp256k1-Schlüssel, und so ist auch ein BIP-341-P2TR-interner Schlüssel.

NIP-Tieftauchgang: NIP-78 (App-spezifische Daten)

NIP-78 definiert eine Standardmethode für Anwendungen, beliebige private oder öffentliche Daten im Namen eines Benutzers über Nostr-Events zu speichern. Der zentrale Event-Kind ist 30078, ein parametrisiertes ersetzbares Event, bei dem der d-Tag eine anwendungsdefinierte Bezeichner-Zeichenfolge ist.

{
 "id": "<64-char hex>",
 "pubkey": "<64-char hex>",
 "created_at": 1747180800,
 "kind": 30078,
 "tags": [
 ["d", "tamagostrich-pet-state"]
 ],
 "content": "{\"level\":7,\"xp\":1420,\"happiness\":82,\"energy\":61}",
 "sig": "<128-char hex>"
}

Die primäre Motivation ist die geräteübergreifende Synchronisation ohne zentralen Server. Jeder Client, der den öffentlichen Schlüssel eines Benutzers und den d-Tag der Anwendung kennt, kann den aktuellen Zustand aus dem Relay-Set des Benutzers abrufen. Für private Anwendungsdaten können NIP-78-Events den Inhaltsbereich mit NIP-44 (Versionierte Verschlüsselung) oder dem älteren NIP-04 verschlüsseln.

Primäre Quellen:

NIP-78-Spezifikation
Tamagostrich: Produktionsimplementierung diese Woche

Siehe auch:

NIP-Tieftauchgang: NIP-98 (HTTP-Auth)

NIP-98 definiert ein HTTP-Authentifizierungsschema, das Nostr-Schlüsselpaaren erlaubt, Anfragen an HTTP-Server zu autorisieren, ohne Benutzernamen, Passwörter oder OAuth-Token zu benötigen. Ein Client erstellt ein kurzlebiges Nostr-Event von kind 27235, signiert es mit seinem privaten Schlüssel, base64-kodiert das JSON und sendet es in einem Authorization: Nostr <base64>-HTTP-Header.

{
 "id": "<64-char hex>",
 "pubkey": "<64-char hex>",
 "created_at": 1747180800,
 "kind": 27235,
 "tags": [
 ["u", "https://files.example.com/upload"],
 ["method", "POST"],
 ["payload", "<sha256-hash-of-request-body>"]
 ],
 "content": "",
 "sig": "<128-char hex>"
}

Das Kind-27235-Event enthält die HTTP-Methode in einem method-Tag, die vollständige Anfrage-URL in einem u-Tag und einen created_at-Zeitstempel. Der Server validiert die Signatur, prüft, dass die Methode und URL mit der tatsächlichen Anfrage übereinstimmen, und verifiziert, dass der Zeitstempel aktuell ist (innerhalb weniger Minuten), um Replay-Angriffe zu verhindern.

NIP-98 wird in Blossom (BUD-01) zur Authentifizierung von Blob-Uploads und -Downloads verwendet. Routstr verwendet es für HTTP-API-Zugriffskontrolle auf Pro-Anfrage-Basis. Sprout verwendet es für Git-Transport-Auth und REST-Relay-Zugang.

Primäre Quellen:

Siehe auch:

NIP-96: HTTP-Dateispeicher-Integration

Das war es für diese Woche. Wenn du etwas baust oder Neuigkeiten zu teilen hast, sende uns eine DM auf Nostr oder finde uns auf nostrcompass.org.

Nostr Compass #21

Wed, 06 May 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, Ihrem wöchentlichen Leitfaden zu Nostr.

Diese Woche: Marmot Protocol liefert MDK 0.8.0 mit den ersten MIP-05-Benachrichtigungs-Primitiven, adressierbaren NIP-51 (Listen)-Schlüsselpaketen und einem verschärften Sicherheitsreview. LaWallet NWC liefert v0.10.0 als größten Release seit der OpenSats-Finanzierung mit einem vollständigen Admin-Dashboard, End-User-Wallet, End-to-End-Aktivitätsprotokoll und einem neuen LightningAddress 1→N- und NWCConnection-Schema. Amethyst bringt einen Nests-Stabilitätssprint mit Audio-Gap-Beseitigung beim JWT-Refresh, lebenszyklusbewussten Schlüsseldatenabonnements, Relay-Keep-Alive-Wiederverbindung und einem animierten Sprecher-Teilnehmer-Indikator. ngit liefert v2.4.2 und v2.4.3 zur Behebung der GRASP-Server-Erkennung bei PR-Einreichungen und der Multi-Remote-State-Event-Filterung. GRAIN liefert v0.5.4 mit Produktionshärtung und einem stillen Datenverlust-Fix im Docker-Quickstart. Mostro Core liefert v0.10.1 mit PGP-signierten Release-Artefakten als Nachfolger des v0.10.0 P2P-Chat-Protokollmoduls der letzten Woche. Clave startet v0.2.0 mit Multi-Account-Unterstützung unter iOS.

Hauptgeschichten

MDK 0.8.0 fügt MIP-05-Benachrichtigungs-Primitive und adressierbare Schlüsselpakete hinzu

MDK, die Rust-Kernbibliothek für das Marmot-Protokoll, lieferte v0.8.0 am 4. Mai. Dieses Release bringt die ersten MIP-05-Benachrichtigungs-Bausteine, verschiebt MIP-00-Schlüsselpakete zu adressierbaren Events, damit das Schlüsselpaket eines Benutzers an Ort und Stelle ersetzt werden kann, verbessert die gemischte Versionskompatibilität der Gruppe, erweitert die UniFFI-Abdeckung für mobile Bindungen und verschärft Validierungspfade rund um Admin-Aktionen, Commits, Speicherung, Verschlüsselungsgrenzen und Replay-Behandlung. MIP-05-Primitive umfassen Blattindex-Helfer, die in PR #235 hinzugefügt wurden und nachgelagerten Clients genug Informationen geben, um pro-Empfänger-Push-Benachrichtigungen zu liefern, ohne die Gruppenstruktur preiszugeben. Operative Fixes landen ebenfalls: PR #273 stellt die mdk-core crates.io-Veröffentlichung wieder her, und PR #269 legt das test_util-Modul hinter einem test-utils-Cargo-Feature frei, damit externe Client-Suiten Marmots Test-Harness teilen können. Für Client-Teams ist die wichtigste praktische Änderung das adressierbare Schlüsselpaket: Die MIP-00-Ankündigung eines Benutzers ist jetzt ein Kind, das an Ort und Stelle ersetzt wird, sodass das Rotieren zu einem frischen Schlüsselpaket keine veralteten Events mehr über Relays verteilt.

LaWallet NWC v0.10.0 liefert das vollständige Monorepo und End-User-Wallet

LaWallet NWC, die NIP-47-Nostr-Wallet-Connect-Implementierung des LaWallet-Teams, lieferte v0.10.0 am 30. April. Dies ist der größte Release seit der OpenSats-Finanzierung des Projekts. Er liefert das vollständige Monorepo, das komplette Admin-Dashboard, ein End-User-Wallet, ein End-to-End-Aktivitätsprotokoll, dynamisches Branding und das neue LightningAddress 1→N- und NWCConnection-Schema, das pro-Adresse-NWC-Routing freischaltet, wo eine Lightning-Adresse an mehrere NWC-Verbindungen unter verschiedenen RBAC-Rollen weitergeleitet werden kann. Das benutzerorientierte Wallet, das in PR #191 geliefert wurde, deckt Onboarding, Home, Senden/Empfangen, Scan, Währungen, einen Aktivitätsfeed und einen Offline-Cache ab. PR #192 verbindet den First-Run-Flow mit confirm-root, Community-Auto-Import und Setup-now-CTAs. PR #196 fügt eine Live-OpenAPI-3.1-Referenz hinzu, die durch Scalar mit rollenbasierter Zugriffskontrolldokumentation gerendert wird, und PR #193 bringt vollständige JSDoc-Abdeckung für die öffentliche lib/-Oberfläche, damit Editor-Tooltips die Wallet-API korrekt bei Integrationsarbeiten anzeigen.

Amethyst stabilisiert Nests mit Keep-Alive, JWT-Resilienz und Lebenszyklus-Abonnements

Amethyst, der funktionsreiche Android-Client, setzte die NIP-53-Nests-Audio-Raum-Arbeit aus Newsletter #20 mit einem Stabilitätssprint fort, der sich auf die Fehlermodi konzentrierte, die Anrufe in der Produktion unterbrachen. Der Audio-Gap-Fix in PR #2733 überschneidet den neuen Anmeldeinformationserwerb mit dem aktiven Stream während des JWT-Refreshs, sodass der Hörer keinen Ausfall hört, wenn das Token rotiert. Ein neuer Keep-Alive-Mechanismus in PR #2730 verbindet getrennte Relays wieder, ohne eine manuelle Benutzeraktion zu erfordern, und PR #2728 ersetzt das Legacy-KeyDataSourceSubscription durch LifecycleAwareKeyDataSourceSubscription, das die Abonnementlebensdauer an den Android-Activity-Lebenszyklus bindet, damit Hintergrundtabs keine offenen Abonnements durchsickern lassen. Androids 12+ ForegroundServiceStartNotAllowedException wird jetzt über PR #2727 graceful behandelt, und PR #2726 fügt den lebenszyklusbewussten Abonnements eine Schonfrist hinzu, damit ein kurzes Ausschalten des Bildschirms den Anruf nicht abbricht. Hörer erhalten einen neuen visuellen Hinweis aus PR #2724, einen animierten Außenring-Indikator, der den sprechenden Teilnehmer in Multi-Sprecher-Sitzungen hervorhebt.

ngit v2.4.2 und v2.4.3 beheben GRASP-Server-Erkennung und Multi-Remote-State-Events

ngit, das Kommandozeilen-Tool und git-Plugin für NIP-34-Kollaboration, lieferte v2.4.2 am 28. April und v2.4.3 am 1. Mai. v2.4.2 behebt einen URL-Normalisierungs-Mismatch, bei dem repo_grasps normalisierte Hostnamen hielt, aber der Vergleich gegen vollständige Clone-URLs gemacht wurde. Die leere Kandidatenserverliste bedeutete, dass jede PR-Einreichung stillschweigend auf den Fork-Erstellungspfad auf einem persönlichen GRASP-Server fiel, wenn der korrekte Pfad ein direkter Push zum eigenen GRASP-Server des Repositorys war. v2.4.3 behebt eine State-Event-Ambiguität, die auftrat, wenn ein Repository mehrere nostr://-Remotes mit demselben Bezeichner hat: Relays konnten State-Events zurückgeben, die von Maintainern des anderen Remotes erstellt wurden, und ohne Filterung gewann das neueste Event unabhängig vom Autor und zeigte Refs auf die falschen Commits. State-Event-Kandidaten in run_list werden jetzt auf Maintainer der Repo-Ankündigung des aktuellen Remotes gefiltert, damit der richtige State gewinnt.

GRAIN v0.5.4 bringt Produktionshärtung und einen stillen Datenverlust-Fix

GRAIN, die Go-basierte Nostr-Relay- und Client-Bibliothek, lieferte v0.5.4 am 30. April. Das Release fasst sechs akkumulierte Fixes seit v0.5.3 zusammen, darunter einen stillen Datenverlust-Bug im Docker-Quickstart, der zuvor Events bei Neustart des Containers verlor, einen Speicherschicht-Korrektheitsbug bei adressierbaren Event-Lesevorgängen, bei dem falsches Tag-Handling Event-Lesevorgänge nach dem Neustart unterbrach, und zwei Verbindungsverfolgungsbugs, die beim Debuggen der v0.5.0-zu-v0.5.3-Sperrkette aufgedeckt wurden. Das Produktionshärtungspaar, das v0.5.3 ursprünglich angestrebt hatte, ist jetzt vorhanden: ein Pro-IP-Ratenlimit und eine IP-Blacklist, beide konfigurierbar.

Mostro Core v0.10.1 fügt PGP-signierte Release-Artefakte hinzu

Mostro Core, die Rust-Bibliothek für Peer-to-Peer-Funktionalität für den Mostro-Daemon und andere nachgelagerte Anwendungen, lieferte v0.10.1 am 28. April als Nachfolger des v0.10.0 P2P-Chat-Protokollmoduls der letzten Woche. Das neue Release fügt PGP-signierte Release-Artefakte und einen verify-release-Flow hinzu, damit nachgelagerte Packager die Artefaktherkunft bestätigen können, bevor sie die Bibliothek vertreiben.

Getaggte Releases

Clave v0.2.0 startet Multi-Account unter iOS mit NIP-46 (Nostr Connect) Signierung

Clave, die iOS-NIP-46-Remote-Signierungsapp, die APNs für Push-Zustellung verwendet (behandelt in #20), lieferte v0.2.0 am 5. Mai. Das bisher größte Update führt Multi-Account-Unterstützung ein: Clave kann jetzt bis zu vier Accounts auf einem Gerät halten, mit einem Ein-Tipp-Wechsler und Pro-Account-Isolation. Die iOS-Klempner und das Entwicklermenü für Multi-Account landen in PR #23, und PR #22 fügt dem APNs-Payload ein signer_pubkey-Feld hinzu, damit das Gerät weiß, zu welchem Account eine Remote-Signierungsanfrage gehört. Aktivitätsdetails beschreiben jetzt, was signiert wurde, und verlinken auf njump (PR #19). Der Cold-Start-Zustellungs-Bug, bei dem das APNs-Token registriert war, aber das iOS-Benachrichtigungscenter veraltete leere Slots hatte, die die Zustellung verhinderten, ist in PR #16 behoben.

Wisp liefert v1.0.3 → v1.0.5 Stabilitätsarbeit

Wisp, der Android-Client, der in #20 aus der Beta graduierte, lieferte v1.0.3, v1.0.4 und v1.0.5 am 4. Mai mit Stabilitätsarbeit. PR #506 fügt Thumbhash für verschwommene Bildvorschauen hinzu, während vollständige Medien laden, und PR #514 reduziert Ruckeln beim Wechsel der unteren Tabs. PR #515 reduziert Start- und Feed-Rendering-Arbeit, und PR #516 verhindert, dass die App beim Wechsel der unteren Navigation veraltete Tab-Back-Stacks wiederherstellt.

Amber 6.1.0-pre1 liefert Layout- und Stabilitätsfixes

Amber, die Android-Signer-App für NIP-55 (Android Signer Application) und NIP-46, lieferte v6.1.0-pre1 mit einem Layout-Pass beim neuen App-Verbindungsflow und mehreren gemeldeten Crash-Fixes. PR #416 behebt ActivityStatsBar-Layout- und Textüberlaufprobleme, PR #412 verbessert die Benachrichtigungsberechtigungsbehandlung und Fehlerresilienz, und PR #411 stellt sicher, dass SignerActivity nach der Behandlung einer Anfrage immer schließt.

Routstr Core v0.4.3 verbessert Zahlung, Rückerstattung und Nutzungsberichte

Routstr Core, die dezentrale Inferenzschicht, lieferte v0.4.3 als Pre-Release am 1. Mai. Das Release verbessert Zahlungs- und Rückerstattungshandling, schärft Kostenverfolgung und Nutzungsberichte und liefert mehrere Fixes rund um API-Key-Anzeige, Nachrichtenhandling und Modellvalidierung.

Nostria v3.1.37 bis v3.1.41 fügen Web-Lesezeichen und ein Auto-Theme hinzu

Nostria, der Multi-Plattform-Nostr-Client, lieferte v3.1.37 bis v3.1.41 am 30. April und 4. Mai. Die Releases fügen NIP-B0 (Web Bookmarks)-Unterstützung, ein “Auto”-Theme, das den Geräteeinstellungen folgt, In-App-PDF-Ansicht, Layout-Fixes für den Mediaplayer im Vollbildmodus und einen verbesserten Artikel- und Notizeditor hinzu.

NoorNote v0.8.9 behebt leeren Startbildschirm auf Desktop

NoorNote, der plattformübergreifende Nostr-Client, lieferte v0.8.9 am 28. April und behebt einen Leerbildschirm-Bug beim ersten Start der Desktop-App, bei dem der Willkommens- und Anmeldebildschirm nicht gerendert wurde.

Kubo v0.3.4 bis v0.4.1 liefert eine kindersichere Nostr-Videoplattform mit elterlicher Kontrolle und Web-of-Trust-Feed-Kuration

Kubo, eine kindersichere Videoplattform auf Nostr, die Eltern ermöglicht, die Inhaltswelt ihres Kindes durch Web-of-Trust-Filter zu kuratieren, lieferte v0.3.4, v0.3.5, v0.4.0 und v0.4.1 am 4. und 5. Mai. Die Plattform ist ein Soft-Fork von Ditto, der für den Familien-und-Kinder-Anwendungsfall umbenannt wurde. Jedes Kind erhält ein separates Nostr-Schlüsselpaar und einen videozentrierten Feed, wo Eltern Zeitlimits (15 bis 180 Minuten täglich), erlaubte Zeitfenster und andere Aspekte der Feed-Steuerung kontrollieren.

Nicht veröffentlichte Änderungen

Sprout liefert Desktop v0.0.4 und v0.0.5 neben NIP-OA-Agent-Authentifizierung und dem Pair-Relay-Sidecar

Sprout, Blocks Nostr-Client mit eingebautem Relay, lieferte Sprout Desktop v0.0.4 am 5. Mai und v0.0.5 am 6. Mai, neben ungefähr 80 zusammengeführten PRs, die einen großen NIP-OA-, NIP-43- und NIP-AB-Pairing-Pass abdecken. Die Hauptänderung in PR #471 verbindet NIP-OA-Agent-Authentifizierung mit dem NIP-43-Mitgliedschaftsflow des Relays über WebSocket-, REST- und Git-Transporte, sodass ein autonomer Agent beweisen kann, dass ein bestimmter menschlicher Pubkey seine Aktionen autorisiert hat, bevor das Relay Zugang gewährt. Ein neues ephemeres Sidecar-Relay für NIP-AB-Gerätepairing kommt in PR #467 als sprout-pair-relay.

nostream fügt Marmot-Relay-Unterstützung und NIP-25-Reaktionen hinzu

nostream, die Node.js-Relay-Implementierung, fusionierte eine produktive Woche von Protokollzusätzen. Marmot Protocol Relay-Unterstützung für MIPs 00 bis 03 landet in PR #602. Die kleineren Protokollzusätze: NIP-25-Reaktionsunterstützung in PR #589, Geohash-Präfix-Matching für #g-Filter in PR #586 und eine verschärfte maxlimit-Prüfung für Abonnement-Event-Anfragen in PR #600.

strfry fügt Pro-Verbindungs-Observierbarkeit hinzu und reduziert nofiles-Decke

strfry, das C++-Nostr-Relay, fusionierte 14 PRs, die auf Observierbarkeit und operative Hygiene abzielen. Die Hauptänderung ist PR #218, das Pro-Verbindungs-ausstehende Ausgangs-Observierbarkeit und eine konfigurierbare Backpressure-Kappe hinzufügt. Auf der Performance-Seite entfernt PR #224 std::function-Heap-Allokationen aus dem Pro-Event-Monitor-Fanout.

Damus ersetzt Tenor GIFs durch einen Purple-Proxy und liefert Kompaktierungs-UX

Damus, der iOS-Nostr-Client, fusionierte PR #3737, der die Tenor-GIF-Integration durch einen Damus Purple-Proxy ersetzt, bei dem Damus’ gehosteter Abonnementdienst GIF-Anfragen im Namen des Clients weiterleitet.

Primal Android poliert Explore, Benachrichtigungen und das NIP-05-Verifizierungsabzeichen

Primal Android fusionierte PR #1043, der ein flackerndes NIP-05 (Domain-Verifizierung)-Verifizierungsabzeichen für Benutzer mit _@domain-Bezeichnern behebt.

Alby Hub fügt NWC-Zahlungen von App-Verbindungen hinzu

Alby Hub fusionierte PR #2267, der Zahlungen von App-Verbindungen erlaubt, und PR #2268, der die Onchain-Empfangsrouting-Logik vereinfacht, beide über Alby Hubs NIP-47 (Nostr Wallet Connect)-Oberfläche geliefert.

routstrd-auth: ein dockerisierter Routstrd für Teams mit NIP-98-Auth und npub-RBAC

routstrd-auth, am 27. April vom Routstr-Team erstellt, ist eine dockerisierte Variante von Routstrd für Multi-User-Team-Deployments. Die Hauptänderung ist ein granulares npub-basiertes rollenbasiertes Zugriffskontrollsystem mit admin- und user-Rollen und Client-Endpunkten, die NIP-98-HTTP-Authentifizierung mit Eigentumsnahverfolgung übernehmen.

Routstrd integriert Hermes für Daemon-Clients und Remote-Modus

Routstrd, der lokale Daemon, der Routstr-Inferenz-Clients orchestriert, fusionierte PR #22 und fügt Integration mit Hermes Agent hinzu, sodass die Konfigurationsdatei des Agents mit den Modellanbietern und API-Keys gefüllt wird, die Routstrd über Nostr entdeckt.

diVine liefert NIP-07-Web-Anmeldung und 16-Locale-Schlüsselparität

diVine, der Video-Client, lieferte diese Woche zwei iOS-Releases neben 139 fusionierten PRs. PR #3994 fügt NIP-07 (Browser-Extension-Signer)-Anmeldung für den Web-Build hinzu, PR #3992 übersetzt 16 nicht-englische Locales auf vollständige Schlüsselparität.

whitenoise-rs liefert Pro-Account-Datenbankirsolierung und Vorschlagsupgrades

whitenoise-rs, die Rust-Kernbibliothek für den White-Noise-Messenger, fusionierte PR #796, das Nachrichtenprojektionstabellen in Pro-Account-Datenbanken verschiebt, und PR #791, das Vorschlagsupgrades hinzufügt, damit Gruppen ihre Funktionalität mit neuen Vorschlagstypen erweitern können.

Angor 0.2.21 liefert kompakte App-Flows neben Key-Provider- und Netzwerkwechsel-Härtung

Angor, die Bitcoin-Crowdfunding-Plattform mit Nostr-veröffentlichten Gründerprofilen, lieferte Angor 0.2.21 am 6. Mai und fasst eine Woche mobiler und Integrationsarbeit zusammen.

Neu verfolgt und entdeckt

BitMacro Signer: ein selbst-hostbarer NIP-46-Bunker mit clientseitiger Schlüsselverschlüsselung

BitMacro Signer ist ein selbst-hostbares Nostr-Signing-Tool, das private Schlüssel mit dem NIP-46-Bunker-Modell verwaltet. Der Signer verschlüsselt Schlüssel auf dem Client vor der Speicherung, sodass die Serverseite niemals Klartext hält.

Die NIP-34-Repo-Entdeckung dieser Woche brachte 26 neue Repository-Ankündigungen hervor, von denen vier herausragen.

gnostr: eine Git-Implementierung direkt auf Nostr aufgebaut

gnostr ist eine Git-Implementierung, die direkt auf Nostr aufgebaut ist und sich von git-remote-nostr dadurch unterscheidet, dass sie eigene Working-Tree-Befehle als von Grund auf native Nostr-Versionskontroll-Client liefert.

nostr-archive: eine inhaltsadressierte Archivspezifikation auf Nostr und Blossom

nostr-archive ist eine Entwurfsspezifikation und Referenzimplementierung für inhaltsadressierte Archive auf Nostr und Blossom.

flower-cache: ein lokaler Blossom-Cache-Server

flower-cache ist ein lokaler Blossom-Cache-Server, nützlich für Clients, die einen heißen lokalen Spiegel eines Remote-Blossom-Server-Blob-Sets ohne Round-Trip zum Upstream wünschen.

micro-vpn-ansible: Ansible-Playbooks für VPN-Deployment über NIP-34

micro-vpn-ansible ist eine kleine Ansible-Playbook-Sammlung für das Deployment eines Micro-VPN, gehostet als NIP-34-Repository.

Protokollarbeit

NIP-Updates

Ein brokerfreier Hashrate-Markt über Nostr (Entwurfsvorschlag): Anonymer NIP-Entwurf aus einem Nostr-Langformbeitrag, der argumentiert, dass die aktuellen Hashrate-Marktakteure (Braiins, Nicehash, Mining Rig Rentals) alle verwahrende Broker sind, die Benutzer KYC unterziehen. Der Vorschlag skizziert einen Peer-to-Peer-Hashrate-Markt auf Nostr-Events.
Curated Feeds: eine einfachere Alternative zu DVM-Feeds (Entwurfsvorschlag): Ein Entwurf argumentiert, dass NIP-90 Data Vending Machines als allgemeiner Rechenmarktplatz konzipiert wurden und das Anfrage/Antwort-Modell schwerer ist als notwendig, wenn ein Client nur eine adressierbare Liste von Event-IDs möchte.
Profile Colors: deterministische visuelle Identität (Entwurfsvorschlag): Ein neues NIP-Entwurf zur Ableitung deterministischer, lesbarer Farben aus einem Nostr-Pubkey für konsistente visuelle Identität über Clients hinweg.
Namecoin-Track NIPs: Verankern von Identität, Relays, TLS und Reputation (Entwurfscluster): Ein trennbarer Cluster von NIP-Entwürfen, der Teile des bestehenden Nostr-Stacks in Namecoin-verankerte Records verschiebt.

NIP-Tieftauchgang: NIP-34 (git stuff)

NIP-34 definiert Event-Kinds für das Hosting von Git-Repositories, Patches, Pull-Requests, Issues und Merge-Status auf Nostr-Relays. Es ist der Standard, der Nostr zu einer Koordinationsschicht für Code-Kollaboration macht: Die Repository-Daten leben weiterhin auf einem Git-Server (GitHub, eine selbst-gehostete Forge oder ein GRASP-Server), während Ankündigungs-Events, Patches, PRs, Issues und Status-Updates auf Relays laufen.

Ein Repository wird als kind-30617-adressierbares Event angekündigt, dessen d-Tag ein Kebab-Case-Bezeichner (typischerweise der Projektname) ist und dessen Body name, description, eine oder mehrere clone-URLs, optionale web-URLs, einen relays-Tag mit Relays, die der Maintainer überwacht, und einen maintainers-Tag mit zusätzlichen Pubkeys zur Verwaltung des Projekts enthält.

Patches verwenden kind 1617 und tragen git format-patch-Ausgabe im Content-Body. Pull-Requests verwenden kind 1618 und sind für Changesets größer als 60 KB gedacht. Issues verwenden kind 1621 mit Markdown-Inhalt. Status-Events verschieben einen Thread zwischen Open (1630), Applied/Merged oder Resolved (1631), Closed (1632) und Draft (1633).

Die NIP-34-Geschichte dieser Woche ist dieselbe wie die GitWorkshop-v2-Einführung der letzten Woche: Der In-Browser-PR-Merge-Button funktioniert, weil GRASP-Server, ngit und das nostr://-Clone-URL-Schema zusammen die Schleife einer vollständig dezentralisierten Forge schließen.

NIP-Tieftauchgang: NIP-53 (Live Activities)

NIP-53 definiert die Standardereignisoberfläche für Live-Aktivitäten auf Nostr: Live-Streams, persistente Meeting-Räume, geplante Konferenzereignisse, Hörer-Präsenz und den Live-Chat-Kanal, der Chat-Nachrichten an einen bestimmten Live-Aktivitätsdatensatz bindet.

Ein Live-Stream wird als kind-30311-adressierbares Event angekündigt. Sein d-Tag ist der stabile Bezeichner, der streaming-Tag zeigt auf die Wiedergabe-URL, und der status-Tag trägt einen von planned, live oder ended. NIP-53 trennt den persistenten Raum vom geplanten Event, das darin stattfindet. Eine kind-30312-Meeting-Space definiert einen Raum, und ein kind-30313-Konferenz-Event repräsentiert ein geplantes oder laufendes Meeting in diesem Raum.

Der Nostr-Live-Aktivitäts-Stack ist absichtlich dünn: NIP-53 kündigt die Aktivität an, während andere NIPs angrenzende Belange handhaben. Zaps für Live-Streams verwenden NIP-57 (Zaps)-Zap-Quittungen, Spendensammelziele verwenden NIP-75 (Zap Goals)-Zap-Ziele, und Videoaufzeichnungen können als NIP-71 (Video Events)-Video-Events erneut veröffentlicht werden.

Das war es für diese Woche. Wenn du etwas baust oder Neuigkeiten zu teilen hast, sende uns eine DM auf Nostr oder finde uns auf nostrcompass.org.

Nostr Compass #20

Wed, 29 Apr 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Leitfaden zu Nostr.

Diese Woche: GitWorkshop macht Git-über-Nostr zu einer vollständigeren Code-Review-Oberfläche mit einem In-Browser-PR-Merge-Button, Stars und Repository-Following, einem bandbreiteneffizienten Git-Explorer, kind 1111 Inline-Review-Kommentaren und verschlüsseltem Multi-Device-Notification-State. Routstrd startet einen lokalen Daemon, der Modellanbieter über Nostr kind 38421 Ankündigungen entdeckt und sie mit Cashu bezahlt. Getaggte Releases umfassen ngit v2.4.2, Wisp v1.0.0, grain v0.5.2 und v0.5.3, Mostro Core v0.10.0 und Mostro Mobile v1.2.5, marmot-ts v0.5.0, CruxCoach v0.1.3, Meiso v1.3.0, NoorNote, Nostria, Nostr Calendar, nos2x-fox, applesauce, nostr-double-ratchet und mehr. Unveröffentlichte Änderungen umfassen Amethyst Nests, nostream NIP-65 und NWC, FIPS Nostr-basierten udp:nat-Bootstrap, strfry-Observability, Sprout Owner-Attestierungen und Zap Cooking Recipe Packs. Neu getrackte Projekte umfassen Nostrord, Clave, Treasures.

Leitartikel

GitWorkshop liefert In-Browser-PR-Merge, Repository-Following und einen bandbreiteneffizienten Git-Explorer

GitWorkshop, Dan Conways webbasierte Kollaborationsschicht für NIP-34 Git-über-Nostr, hat diese Woche ein großes Release veröffentlicht, das den Workflow deutlich näher an das heranbringt, was Entwickler von GitHub oder GitLab erwarten, während Kommentare, Repository-Listen und Benachrichtigungen weiterhin in signierten Nostr-Events liegen.

Die wichtigste Neuerung ist ein lange erwarteter In-Browser-PR-Merge-Button für Repositories, die GRASP-Relays nutzen. Das Release fügt außerdem Stars und Repository-Following hinzu, die auf Reaktionen und NIP-51 Listen basieren, wobei angepinnte Repository-Sets als kind 10617 Events veröffentlicht werden, die über geordnete a Tags auf kind 30617 Repo-Ankündigungen zeigen. Profilseiten können jetzt eine portable Liste von Repositories präsentieren.

Ein bandbreiteneffizienter Git-Explorer ersetzt den vorherigen In-Browser-Shallow-Clone. Der neue Explorer stützt sich auf das zugrunde liegende Git-Client/Server-Protokoll, auf dem GRASP aufbaut, sodass er große Repositories verarbeiten kann, ohne den Browser zu zwingen, ein vollständiges Pack zu laden. Die Suche deckt jetzt Benutzernamen und Repository-Metadaten ab, angetrieben von NIP-50 und einer ngit-indexer Relay-Implementierung, die Repository-Ankündigungen im Netzwerk entdeckt und synchronisiert. Ein In-Browser-Workflow zur Repository-Erstellung rundet den Entdeckungs- und Onboarding-Pfad ab.

Das Review-Tooling wurde rund um einen Files-Changed-Tab, einen Per-Patch-Diff-Viewer und eine Reihe experimenteller neuer Primitive neu aufgebaut. Inline-Code-Review-Kommentare verwenden kind 1111, aufgebaut auf NIP-22: jeder Kommentar zeigt auf einen Dateipfad (f Tag), einen Commit-SHA (c Tag) und einen ausgewählten Zeilenbereich (line Tag), sodass ein Client den Kommentar an der korrekten Position in einem Diff rendern kann. Eine zweite Stufe experimenteller Primitive ist auf Autor und Repo-Maintainer beschränkt und nutzt NIP-32 Labels: einen Issue- oder PR-Betreff nach der Einreichung umbenennen, nachträglich Hashtags hinzufügen, eine versionskontrollierte CoverNote als bearbeitbare Zusammenfassung an die Spitze eines PR oder Issue heften und Inline-Code-Diskussions-Subthreads als erledigt markieren. Verdict-Events und suggestion Blöcke bleiben im Entwurfsstadium und wurden noch nicht ausgeliefert.

Der Notification-State über Geräte hinweg wird ebenfalls über Nostr synchronisiert, allerdings mit einem datenschutzfreundlichen Kniff. GitWorkshop generiert ein dediziertes Notifications-Keypair, verschlüsselt diesen nsec und speichert ihn in einem kind 30078 Event. Der Notifications-nsec signiert dann die tatsächlichen Notification-State-Events. Diese Indirektion verhindert, dass der Haupt-Signer des Benutzers mit häufigen Verschlüsselungs- und Entschlüsselungsanfragen für jede Lese- oder Archivierungsaktion überschwemmt wird, und sie hindert außenstehende Beobachter daran, leicht zu sehen, wann ein Benutzer seinen Notification-State berührt. Ein Benutzer kann Lese- und Archivierungsstatus über Geräte hinweg synchronisieren; Relays sehen nur verschlüsselte Blobs.

Routstrd startet einen lokalen Router für Inferenz über Nostr

Routstrd ist ein neuer TypeScript-Daemon, der lokalen Werkzeugen einen OpenAI-kompatiblen Endpunkt bietet und jede Anfrage an einen konkurrierenden Routstr Provider routet. Der Daemon entdeckt Provider durch Nostr kind 38421 Ankündigungen, die in Routstrs RIP-02-Spezifikation definiert sind. Er bewertet Provider dann nach Preis, Vertrauen und jüngster Leistung unter RIP-06 und sendet jede Anfrage an die aktuell beste Option.

Die Zahlung läuft über eine lokale Cashu-Wallet, die von cocod verwaltet und mit Lightning gefundet wird. Das gibt dem Client einen in Sats denominierten Abrechnungspfad, während die Provider-Entdeckung öffentlich und permissionless über Nostr-Relays bleibt. Wenn ein Provider während einer Session ausfällt, kann Routstrd auf den nächstplatzierten Knoten zurückfallen. Der Installationspfad ist bun install -g routstrd, gefolgt von routstrd onboard für Wallet- und Relay-Setup.

Die breitere Routstr-Org pflegt den Daemon, die Python-Node-Software (routstr-core), eine Chat-UI und Protokollspezifikationen. Für Benutzer wird der lokale Port zur stabilen Schnittstelle: bestehende OpenAI-kompatible Werkzeuge zeigen auf Routstrd, während der Daemon Provider-Entdeckung, Routing und Zahlung übernimmt.

Getaggte Releases

ngit v2.4.2 behebt GRASP-Relay-Erkennung für PR-Einreichungen

ngit hat v2.4.2 mit einem Fix für die Repository-GRASP-Server-Erkennung veröffentlicht, wodurch PR-Einreichungen auf dem Happy Path bleiben, wenn ein Vorschlag das PR-kind verwendet. Beachte, dass ngit derzeit standardmäßig das Patch-kind für die meisten Änderungen verwendet, sofern sie nicht groß sind; der Maintainer arbeitet daran, den Standard zu ändern. v2.4.1, das früher in der Woche veröffentlicht wurde, behob fatal Fehler während Clone und Fetch, wenn die Git-Daten eines offenen PR auf den festgelegten Git-Servern des Repositorys nicht verfügbar waren.

Wisp v1.0.0 verlässt die Beta

Wisp, ein Kotlin- und Jetpack-Compose-Android-Client mit Fokus auf Relay-Routing, Datenschutz und einer schlanken nativen UI, veröffentlichte v1.0.0 und folgte mit v1.0.2. Der 1.0.0-Meilenstein sammelt den Normie-Mode Fiat-Denominierungsschalter, den For-You-Feed, die NIP-29 relay-basierte Gruppenkonfiguration und das NIP-65 Relay-List-Broadcasting, die in Newsletter #19 behandelt wurden. v1.0.2 fügt Unterstützung für Android 15 16-KB-Seitengröße, einen QR-Scan-Tab im Drawer-Sheet, einen Download-Button für Inline-Video-Kontrollen und Fixes für die Performance der Notification-Liste hinzu.

grain v0.5.2 behebt WebSocket-Lockup, v0.5.3 setzt Politur fort

grain, das Go-Relay von 0ceanSlim, veröffentlichte v0.5.2 als kritischen Hotfix für ein WebSocket-Lockup, das in v0.5.0 eingeführt wurde, und folgte dann mit v0.5.3. Das Lockup führte dazu, dass Verbindungen unter bestimmten Filter- und WebSocket-Pfaden hingen, sodass Betreiber auf v0.5.1 oder v0.5.0 upgraden sollten. grain trackt alle wichtigen Nostr-Event-Kategorien, stellt NIP-11 Relay-Informationen bereit, unterstützt Whitelist/Blacklist-Zugriffskontrolle, Per-kind-Rate-Limits, ein Web-Dashboard und eine Go-Client-Bibliothek, die in der v0.5.x-Linie hinzugefügt wurde.

Mostro Core v0.10.0 und Mostro Mobile v1.2.5 übernehmen NIP-59 Dual-Key Gift Wrap

Mostro Core v0.10.0 fügt das neue NIP-59 Gift-Wrap-Modul mit getrennten Identity- und Trade-Keys hinzu. Frühere Transportcode verwendete einen einzigen Identity-Key sowohl für Trade-Identity als auch für Gift-Wrapping. v0.10.0 trennt die stabile Trade-Identity vom ephemeren Wrapping-Key, sodass jeder Trade einen frischen Transport-Key verwenden kann, während die für das Trade-Protokoll benötigte Identity erhalten bleibt. Die Daemon-Integration landet über Mostro PR #718, und mostro-cli PR #165 bringt dieselbe Migration in den Command-Line-Client.

Mostro Mobile v1.2.5 wird zusammen mit der Protokollarbeit ausgeliefert. PR #581 lässt Taker Angebote nach dem Kontoalter des Makers filtern und gibt Benutzern eine Möglichkeit, neu erstellte Maker-Accounts im Orderbuch zu vermeiden. PR #580 korrigiert Rollen-Labels bei den Details stornierter Aufträge, und PR #576 räumt die Buttons für die kooperative Stornierung auf.

marmot-ts v0.5.0 liefert adressierbare KeyPackages

marmot-ts veröffentlichte @internet-privacy/marmot-ts@0.5.0, das erste geplante Breaking-Change-Release für den TypeScript-Marmot-Client. PR #68 fügt Unterstützung für adressierbare KeyPackages hinzu: KeyPackageManager kann jetzt sowohl legacy kind 443 als auch neue kind 30443 KeyPackage-Events verarbeiten. Das Release entfernt KeyPackageStore und die Group-State-Storage-Klassen und ersetzt sie durch generische Key-Value-Stores, die an KeyPackageManager und MarmotGroup übergeben werden. Es verschiebt außerdem Einladungs- und Gruppenverwaltung auf MarmotClient.invites und MarmotClient.groups, sodass direkte Embedder vor dem Upgrade Konstruktor- und Storage-Änderungen benötigen.

CruxCoach v0.1.3 liefert verschlüsseltes Backup für Kletterdaten mit Nostr und Blossom

CruxCoach ist eine neue Open-Source-Android-App für Kilter-Board-Kletterer. Das Kilter Board ist eine interaktive Trainingswand, deren Griffe über Bluetooth aufleuchten, um Routen anzuzeigen. Die App wurde am 14. April veröffentlicht und erreichte am 26. April v0.1.3.

v0.1.3 fügt ein optionales verschlüsseltes Cloud-Backup hinzu. Das CruxCoach-Konto eines Benutzers ist ein Nostr-Keypair, und der private Schlüssel dient gleichzeitig als Eingabe für den lokalen Backup-Verschlüsselungsschlüssel. Die App verschlüsselt Kletterdaten auf dem Gerät und spiegelt den Chiffretext auf Blossom-Storage-Server (blossom.primal.net und nostr.download). Delete-Remote-Aktionen rufen den Blossom-Cleanup-Pfad auf. Über das Backup hinaus verwendet CruxCoach NIP-46 Remote-Signing für Amber-Unterstützung, NIP-17 private DMs für den In-App-Entwicklerkontakt, NIP-65 Relay-Listen zur Relay-Entdeckung und Vitor Pamplonas Quartz-Bibliothek für Nostr-Plumbing. Benutzer können sie über Zapstore oder direkte Codeberg-APKs installieren.

Meiso v1.3.0 fügt Subtasks, Blossom-Anhänge und NIP-89-Tagging hinzu

Meiso ist ein minimalistischer Flutter-Task-Manager für Android, der Aufgaben als NIP-44 verschlüsselte kind 30078 Anwendungsdaten auf Nostr-Relays speichert. v1.3.0, veröffentlicht am 6. April, fügt Subtasks mit Eltern-Kind-Beziehungen, Task-Links für blocks/blocked-by/related-to/duplicate-of, Bildanhänge über Blossom und NIP-96 HTTP-File-Upload-Endpunkte, einen NIP-89 client Tag für empfohlene Anwendungen bei veröffentlichten Events und ein Go-Command-Line-Sync-Tool hinzu. v1.3.0 behebt außerdem das Cold-Start-Relay-Verhalten und die Wiederverwendung des Amber-Clients.

NoorNote, Nostria, Nostr Calendar, nos2x-fox und Bibliotheks-Releases

NoorNote veröffentlichte v0.8.7, v0.8.8 und v0.8.9. Diese Releases beheben das Handling von Bild- und Video-Klicks in zitierten Reposts, fügen Lightbox-Unterstützung für Bilder in Long-Form-Artikeln hinzu und beheben den leeren Desktop-Startbildschirm. Nostria veröffentlichte v3.1.29, v3.1.30 und v3.1.31, die Bildkompression im Artikel-Editor, einen Wallet-USD-Schalter, Promotional-Card-Kontrollen, PDF-Unterstützung und Politur des Mobile-Layouts hinzufügen.

Nostr Calendar v1.4.1 entkoppelt die Kalender-Event-Veröffentlichung von der Kalender-Listen-Verwaltung und behebt das Einladungs-Tracking. nos2x-fox v1.19.0 fügt benutzerdefinierte Autorisierungszeiträume für Firefox NIP-07 Browser-Signing-Grants hinzu. nostr-double-ratchet v0.0.97 liefert neue Binaries. nostr-wot-sdk 0.9.0 mountet NostrSessionProvider standardmäßig, und nostr-tools PR #535 fügt Multi-Relay-Parsing-Unterstützung für NIP-47 Wallet-Connect-Strings hinzu.

Spät in der Woche veröffentlichte Amber v6.1.0-pre1 ein Pre-Release mit einem verbesserten Connect-New-App-Layout, Signer-Dialog-Fixes, verbessertem Handling der Benachrichtigungsberechtigungen und einer überarbeiteten Kontoauswahl. nostr-vpn v0.3.14 veröffentlichte einen frischen Build mit macOS Apple Silicon, Linux und Windows Artefakten. Bitcredit Core v0.5.7-hotfix-1 und v0.5.8 lieferten Back-to-Back-Fixes für ein Validierungsproblem verwaister Blöcke. Surveil v0.1.6 brachte Politur für die mobile UI und eine überarbeitete About-Seite; das Projekt selbst wird unten vorgestellt.

applesauce 6.0.0 entfernt Legacy-Event-Factories und fügt Blossom-URI-Parsing hinzu

applesauce, hzrd149s TypeScript-Nostr-Toolkit, veröffentlichte einen 6.0.0-Release-Train über das Monorepo hinweg. applesauce-core@6.0.0 entfernt die Legacy-Klasse EventFactory und die alten Helpers buildEvent, modifyEvent und createEvent und drängt Aufrufer zu den neueren Factory-Klassen in applesauce-core/factories und applesauce-common. Es fügt außerdem IP-Adressen- und Localhost-Handling zum Link-Parsing hinzu, BUD-10 Blossom-URI-Regular-Expressions und neue Observable-Helpers wie timeoutWithIgnore, combineLatestBy, combineLatestByIndex und combineLatestByKey.

Paket-Level-Releases füllen die Nostr-spezifischen Teile aus. applesauce-content@6.0.0 fügt BUD-10 Blossom-URI-Nodes für Text und Markdown hinzu und gibt Renderern eine erstklassige Möglichkeit, Blossom-Referenzen in Inhalten zu parsen. applesauce-actions@6.0.0 fügt Basis-Factory-Klassen für NIP-51 Listen für Relays, Benutzer und Items hinzu und macht die Listenkonstruktion weniger ad hoc. applesauce-wallet-connect@6.0.0 exponiert WalletConnect.connectURI, sodass Apps direkt auf eine bestehende NIP-47 Wallet-Connect-URI zugreifen können.

Unveröffentlichte Änderungen

Amethyst treibt Nests-Audio-Räume mit MoQ-Interop-Tests voran

Amethyst mergte diese Woche mehrere Nests-fokussierte PRs, die auf dem Media over QUIC Audio-Room-Stack der letzten Woche aufbauen. PR #2622 fügt ein Cross-Client-Interop-Harness hinzu, das den Amethyst-MoQ-Client gegen die Referenz-Web-Implementierung ausführt. Ziel ist es, Android/Browser-Wire-Level-Divergenzen zu erkennen, bevor sie Benutzer treffen. PR #2625 verbessert Picture-in-Picture-Sprecher-Fokus und Verbindungsstatus, während PR #2620 Avatare, Mute-Status und Speaking-Status im Teilnehmer-Grid klärt. Spät in der Woche behebt PR #2634 IME-Padding und Window-Insets in der Full-Screen-Nest-Ansicht und PR #2635 fügt presence-basierte Frische-Filterung zum Nests-Feed hinzu. Separat entfernt PR #2627 Amethysts benutzerdefinierte C-secp256k1-Implementierung und migriert zu libschnorr256k1.

nostream fügt NIP-65 Relay-Listen-Unterstützung und NWC-Zahlungen hinzu

nostream mergte drei bemerkenswerte PRs nach dem 53-PR-Relay-Sprint der letzten Woche. NIP-65 Relay-Listen-Metadaten-Unterstützung landet in PR #585, sodass das Relay kind 10002 Relay-Listen-Events indexieren und ausliefern kann. Ein Nostr-Wallet-Connect-Zahlungsprozessor folgt in PR #539 und fügt einen Pay-to-Relay-Pfad hinzu. Das Verbindungs-Cleanup verbessert sich in PR #438, der einen Dead-Connection-Bug schließt, bei dem Sockets mit aktiven Subskriptionen nicht abgeräumt wurden, was zu einer Drift der Subskriptionszahlen auf lang laufenden Instanzen führte.

FIPS fügt Nostr-basierten udp:nat-Bootstrap hinzu

FIPS, das Free Internetworking Peering System, das zuvor in Newsletter #6 und Newsletter #10 behandelt wurde, mergte PR #53 mit Nostr-basiertem udp:nat-Bootstrap. Die Änderung lässt Nodes Nostr-Adverts veröffentlichen, verschlüsselte Offer/Answer-Signaling austauschen, öffentliche Adressen über STUN entdecken, UDP-Hole-Punching durchführen und den gepunchten Socket in den normalen FIPS-Transport-Stack übergeben. Die Implementierung bindet Signal-Payload-Identitäten an den tatsächlichen Nostr-Sender, fragt konfigurierte DM- und Advert-Relays für den Inbox-Lookup ab und rollt fehlgeschlagene adoptierte Traversal-Übergaben zurück, sodass verwaiste UDP-Transporte nicht am Leben bleiben. Dies ist die Nostr-Ankündigungs- und NAT-Traversal-Arbeit, die im kanonischen Repo jmcorgan/fips zu verfolgen ist.

strfry fügt Per-Connection-Observability hinzu

strfry mergte PR #214 und fügt Per-Connection-Observability und Verbindungs-Level-Metriken hinzu, die über Prometheus exportierbar sind. PR #204 normalisiert Prometheus-Labels, und PR #215 fügt einen Community-Integrations-Abschnitt zur Dokumentation hinzu, der Namecoin-Identity-Projekte abdeckt, die auf strfry aufbauen.

Sprout fügt Owner Attestation und Multi-Workspace-Unterstützung hinzu

Sprout, Blocks Nostr-Client, mergte PR #406 und implementiert NIP-OA (Owner Attestation). Das Feature gibt einem autonomen Agenten einen kryptografischen Beweis, dass ein spezifischer menschlicher pubkey seine Aktionen autorisiert hat. PR #409 fügt Multi-Workspace-Unterstützung zur Desktop-App hinzu, PR #411 fügt #channel-Autocomplete zum mobilen Compose hinzu, und PR #410 schließt ein Race-Fenster, das aktive Channel-Nachrichten fallenlassen konnte. PR #413 führt NIP-RS für die Cross-Device-Read-State-Synchronisation ein, und die Follow-up-PRs PR #420 und PR #422 verdrahten diesen Read-State in die mobilen Unread-Badges.

Zap Cooking mergte eine produktive Woche der Rezeptveröffentlichungsarbeit. NIP-09 Lösch-Anfragen für die eigenen Recipe Packs eines Benutzers landen in PR #367. Die Veröffentlichungszuverlässigkeit verbessert sich durch PR #366, der jedes neue Rezept auf das Garden-Relay zwingt und eine Retry-Queue für das gemeinsame Rezept-Set hinzufügt. One-Click-authored Pack-Publishing landet in PR #365, und PR #331 fügt NIP-46 Bunker-Login-Unterstützung hinzu.

Whitenoise-rs verschlüsselt seine lokale Datenbank

whitenoise-rs mergte PR #758 und fügt SQLCipher-Verschlüsselung für die On-Disk-Whitenoise-Datenbank hinzu. Das schließt eine langbestehende At-Rest-Sicherheitslücke für den Marmot-Daemon-Stack. PR #775 exponiert die erforderlichen Gruppenfähigkeiten, PR #772 migriert Gruppen-Medien-Operationen auf sessionbesessene MediaOps, und PR #773 extrahiert einen SharedServices-Holder als Teil des Session-Ops-Refactors. Auf der mobilen Seite aktiviert whitenoise PR #577 Boot-Auto-Restart für den Android-Foreground-Service und behebt den Fall, dass der Daemon nach einem Geräteneustart nicht zurückkommen würde.

Neu getrackt und entdeckt

Nostrord: ein NIP-29-Client mit Kotlin Multiplatform und WASM

Nostrord ist ein neuer NIP-29 Gruppen-Chat-Client, der auf den Discord-Ersatz-Anwendungsfall abzielt. Gruppen leben auf Nostr-Relays mit relay-erzwungener Mitgliedschaft, Rollen, Moderation und Zugriffskontrolle, sodass der Gruppenzustand vom ausgewählten NIP-29-Relay gehostet wird. Der Client-Entwickler kontrolliert keine separate Anwendungsdatenbank für diese Gruppen. Die Web-App läuft unter web.nostrord.com und ist mit Kotlin Multiplatform gebaut, das zu WebAssembly kompiliert, mit nativen Android-, iOS- und Desktop-Builds in Entwicklung. Nostrord ist ein OpenSats Grant-Empfänger und interoperiert mit denselben NIP-29-Relays, die von Flotilla, Chachi und 0xChat verwendet werden.

Clave bringt NIP-46 Remote-Signing per APNs auf iOS

Clave ist ein iOS-Remote-Signer in der Beta, der Nostr-Events signiert, wenn die App nicht geöffnet ist. Der private Schlüssel bleibt im iPhone-Keychain. Wenn ein Client eine NIP-46 Remote-Signing-Anfrage sendet, liefert ein serverseitiger Proxy eine Apple Push Notification aus und weckt eine Notification Service Extension für bis zu 30 Sekunden. Diese Extension entschlüsselt die Anfrage mit NIP-44 Verschlüsselung, signiert mit dem Keychain-Schlüssel und veröffentlicht die Antwort. Die Device-Token-Registrierung nutzt NIP-98 HTTP-Auth, um Token-Hijacking zu verhindern. Clave unterstützt bunker:// und nostrconnect:// Pairing, Per-Client-Vertrauensstufen, Per-kind-Overrides und wurde mit Nostur und noStrudel getestet.

Treasures: dezentrales Geocaching auf Nostr

Treasures ist eine Geocaching-Plattform, bei der Caches und Funde signierte Nostr-Events sind. Cache-Ersteller veröffentlichen adressierbare kind 37516 Events mit GPS-Koordinaten. Finder loggen die Entdeckung, indem sie einen QR-Code scannen, der am physischen Cache angebracht ist; der Code kodiert den Ersteller-pubkey, den d Tag des Caches und einen Verifikations-Private-Key, der als Beweis des physischen Besuchs dient. NIP-57 Zaps können von Findern zu Cache-Erstellern fließen, und die Live-App ist unter treasures.to erreichbar.

smesh v0.5.1: selbstgehostetes Nostr-Relay, Client und Signer in einem Stack

smesh ist ein selbstgehosteter Nostr-Stack, geschrieben in Moxie, einer benutzerdefinierten Sprache, die von mleku aus Go und TinyGo abgeleitet wurde. Der Stack liefert eine native Relay-Binary mit HTTP-, WebSocket-, AUTH-, Such- und Blossom-Unterstützung; sm3sh, einen Web-Client, der zu ES-Modulen kompiliert wird; und eine Browser-Signer-Erweiterung mit NIP-07 Browser-Signing plus NIP-04 und NIP-44 Verschlüsselungsunterstützung. Jüngste Arbeit umfasst MLS (RFC 9420) Gruppen-Messaging in v0.5.0, negentropy Set-Reconciliation für Relay-Sync und eine Web-of-Trust-Graph-Engine. Der Code liegt in mlekus selbstgehosteter Forge auf git.smesh.lol, gebaut mit seinem eigenen git-web-Tool. Das verwandte gitea-nostr-auth Repo ist eine OAuth2/OIDC-Brücke für Gitea: Benutzer authentifizieren sich mit einem NIP-07 Browser-Signer, die Brücke entdeckt Relays über NIP-65 und Gitea erhält standardmäßige OIDC-Identity-Claims.

Surveil: ein Magic: The Gathering Deckbauer auf Nostr

Surveil ist ein Nostr-Client für Magic: The Gathering Spieler, mit dem Benutzer Karten suchen, Decks bauen, Papierkarten auf Android mit On-Device-ML-Kit-OCR scannen und Decks im Netzwerk teilen können. Decks werden als adressierbare kind 37381 Events veröffentlicht, und die Deck-Event-Spezifikation ist in der NIP.md des Projekts dokumentiert. Die soziale Schicht ist aus standardmäßigen Nostr-Primitiven aufgebaut: NIP-22 (kind 1111) Threaded-Comments, die auf jedes Deck beschränkt sind, NIP-25 (kind 7) Reaktionen, NIP-78 (kind 30078) Profildaten für Spieler-Homes, kind 3 Follow-Feeds und Forks, die einen a Tag zurück zum Original-Deck tragen. v0.1.6 wurde diese Woche mit Politur der mobilen UI, Verbesserungen des Life Counters, einer überarbeiteten About-Seite und einer Relay-Pille am Deck-Hero-Banner ausgeliefert. Die Web-App läuft überall dort, wo statisches HTML ausgeliefert wird, der Android-Build wird über Zapstore ausgeliefert, und kind 37381 Events werden auch nativ von Ditto als Magic-Decks indexiert. Das Repo liegt auf GitLab unter chad.curtis/surveil.

Kleinere Ergänzungen: Fundstr, Nod City, deploy-nsite-to-pages und null–nostr

Fundstr ist eine Creator-Funding-Plattform auf Nostr, die Cashu-Ecash für einmalige und wiederkehrende Zusagen verwendet, mit Creator-Tier-Definitionen und Nostr-DMs. Nod City ist eine Bitcoin-Service-Bewertungsseite, auf der Bewertungen signierte Nostr-Events sind und Rezensenten Zaps empfangen können; ein öffentliches Quellcode-Repo wurde nicht gefunden. deploy-nsite-to-pages ist eine GitHub Action, die eine nsite über nsyte download auf GitHub Pages spiegelt, mit Unterstützung für root kind 15128 und named kind 35128 nsites. null–nostr, ebenfalls in den NIP-34-Daten dieser Woche entdeckt, ist der Client, der in der jüngsten OpenSats-Welle als Nurunuru behandelt wurde; er unterstützt MLS-Gruppen-Messaging, Amber, NIP-50-Suche, NIP-70 geschützte Posts, ProofMode-Badges und Zapstore-Distribution.

FIPS ist kein neues Projekt für Compass. Es wurde in Newsletter #6 und Newsletter #10 behandelt. Die Datenbank zeigt jetzt auf das korrekte kanonische Repo, jmcorgan/fips, und die NIP-34-Entdeckung dieser Woche brachte auch verwandte Git-über-Nostr-Mirrors wie fips und awesome-fips ans Licht.

Protokollarbeit

NIP-Updates

Jüngste Vorschläge und Diskussionen im NIPs-Repository:

Diese Woche gemerged:

NIP-34 Git-Repositories: ungenutzte refs-Tag-Erweiterung entfernen (PR #2325): Entfernt eine refs Tag-Erweiterung aus NIP-34, die definiert, aber ungenutzt war. Das Cleanup reduziert die Implementierungsambiguität für Git-über-Nostr-Tools.
NIP-34 Git-Repositories: falschen NIP-09-Anspruch entfernen (PR #2326): Entfernt einen falschen Anspruch, dass NIP-09 Lösch-Events den Repository-Zustand zurücksetzen können. NIP-09-Löschung ist eine clientseitige Event-Lösch-Anfrage, kein Repository-State-Machine. Die Korrektur verhindert, dass NIP-34-Implementierer Lösch-Hinweise als autoritativ für Repo-Resets behandeln.

Offene und implementierungsgetriebene Arbeit:

GitWorkshop kind 1111 Inline-Review-Kommentare: Das Inline-Code-Review-Kommentar-kind ist in der NIP.md von GitWorkshop dokumentiert und jetzt aktiv im Einsatz, wurde aber noch nicht als formales NIP vorgeschlagen. Verdict-Events (kind 7321) und suggestion Blöcke bleiben im Entwurf und wurden noch nicht ausgeliefert. Implementierungsfeedback von GitWorkshop und ngit wird bestimmen, ob die Formen ein eigenständiges Git-Review-NIP werden oder eine Anwendungskonvention bleiben, die auf NIP-34 aufgesetzt ist.
Nostr Mail Core und Nostrmon: Zwei neue benutzerdefinierte NIP-Entwürfe zirkulierten diese Woche. Nostr Mail Core schlägt kind 1301 für RFC-2822-E-Mail-Inhalte vor, umschlossen von NIP-59 für private Zustellung und über NIP-05-aufgelöste Bridge-pubkeys mit Legacy-E-Mail verbunden. Nostrmon skizziert adressierbare Event-kinds für Regionen, Karten, Kreaturen, NPCs, Spieler-Saves und Items. Beide bleiben benutzerdefinierte Entwürfe, keine gemergten NIPs.
NIP-67: EOSE Completeness Hint (PR #2317): Der Vorschlag iteriert weiter über das Hinzufügen eines positiven Completeness-Markers zu EOSE, wodurch Relays “gespeicherte Events vollständig ausgeliefert” von Legacy-EOSE-Fällen unterscheiden können, in denen das Relay keinen Completeness-Anspruch erhebt.

Sechs Nostr-Aprile

Der April gibt einen sauberen Querschnitt des Nostr-Entwicklungspfads: das Protokolldokument in 2021, frühe Client-Arbeit in 2022, die Post-Damus-Anwendungswelle in 2023, private Nachrichten und Git-über-Nostr-Arbeit in 2024, Blossom und Relay-Listen-Cleanup in 2025 und adoptionsfokussierte Client-Grants in 2026.

April 2021: das Protokolldokument vor dem NIPs-Repo

Fiatjaf veröffentlichte den ursprünglichen Nostr-Artikel, “Notes and Other Stuff Transmitted by Relays”, am 20. November 2020. Dieser erste Text enthielt bereits die Kernform, die das Protokoll immer noch definiert: Benutzer signieren Events mit Schlüsseln, veröffentlichen sie an Relays und lesen von Relays ihrer Wahl. Das nostr-protocol/nostr Commit-Log zeigt keine Commits zwischen dem 1. und 30. April. Aktivität liegt auf beiden Seiten: Commits vom März 2021 fügten frühe “nostwitter”-Links und einen kind-Filter hinzu, während der Mai 2021 NIP-02 umwidmete und die NIP-Autorenschaft hinzufügte.

Im April 2021 gab es keinen öffentlichen Client-Markt, kein sichtbares Relay-Netzwerk und kein NIPs-Repo. Das Protokoll lebte immer noch als kleines Dokument und ein paar Experimente. Nostr war noch kein soziales Netzwerk oder eine Entwicklungsplattform geworden. Es war immer noch ein Relay/Key/Event-Modell, das auf seine erste nachhaltige Contributor-Welle wartete.

April 2022: NIPs lebten noch im Haupt-Repo

Der April 2022 war der letzte Monat, bevor NIPs aus dem Haupt-Repo nostr-protocol/nostr ausgegliedert wurden. Da die Aufteilung noch nicht stattgefunden hatte, hatte das dedizierte nostr-protocol/nips Repo keine April-Pull-Request-Historie. Im Haupt-Repo landeten drei April-Commits: “Update readme to add nip12” am 8. April von goswami1999, “add kinds list” am 25. April von jb55 und “add js formatting to sample code” am 28. April von steliosrammos.

Auch die Client-Arbeit begann Gestalt anzunehmen. Damus-Commits aus April 2022 fügten frühes Chatroom-Verhalten, Profil-Handling und App-Icons hinzu, während nostr-tools zum JavaScript-Bibliothekspfad für frühe Clients und Experimente wurde. Auf der Protokollseite gab NIP-12 Generic-Tag-Queries der Tag-Suche einen dokumentierten Platz, die kinds-Liste bewegte Nostr in Richtung eines Registry-Modells, und bessere JavaScript-Beispiele machten die Spezifikation für Client- und Bibliotheksautoren einfacher zu implementieren. Am 1. Mai verschob fiatjaf die NIPs in das dedizierte Repo. Der April 2022 war der letzte Monat der ursprünglichen Single-Repo-Ära.

April 2023: Post-Damus-Anwendungsexpansion

Der April 2023 kam drei Monate nachdem Damus am 31. Januar 2023 im iOS App Store gestartet war und nachdem Jack Dorsey seinen Nostr Public Key gepostet hatte. Das Netzwerk hatte gerade seine erste große öffentliche Wachstumswelle absorbiert. Clients wie Damus, Snort, Iris, Coracle und Amethyst waren aktiv, während Relay-Betreiber lernten, was ein größerer sozialer Graph mit den Annahmen zu Bandbreite, Spam, Suche und Moderation machte.

Der April 2023 hatte einen gemergten NIPs-PR: PR #456, gemerged am 17. April, der NIP-19 bech32-Entity-Links zur NIP-21-URI-Behandlung hinzufügte. Die umliegenden Commits zeigen den Anwendungsdruck hinter der Protokollarbeit. Der April 2023 sah Arbeit an NIP-45 COUNT, event-spezifischen Zap-Markern, NIP-15 Marketplace, NIP-26 Delete-Delegation-Semantik, NIP-94 File-Metadaten, NIP-47 Wallet-Connect-Error-Handling und NIP-30 Custom Emoji. Die Contributor-Liste hatte sich erweitert und umfasste fiatjaf, staab, pablof7z, Semisol, CodyTseng, sethforprivacy, mikedilger, AsaiToshiya, alexgleason, martindsq, frbittencourt und arkin0x.

Damus, Snort, Iris, Coracle und Amethyst waren keine Demos rund um eine Spezifikation mehr; sie waren Produktionsclients, die sich mit Onboarding, Feeds, Spam, Zaps, Medien und Relay-Auswahl beschäftigten. Die Protokollarbeit vom April 2023 liest sich wie das Backlog, das diese Clients erstellt haben: Zaps, Marketplaces, File-Metadaten, Counting, Emoji und Identity-Links haben die Spezifikation alle über einfache Notes und Follows hinausgeschoben.

April 2024: private Nachrichten, Git-über-Nostr und Maintainer-Support

Der April 2024 hatte zwei NIP-PR-Merges. PR #1167, gemerged am 10. April, behob verwirrende Terminologie in NIP-46 Remote-Signing, wo Clients und Signer eine exakte Sprache für angefragte und autorisierte Aktionen benötigen. PR #1108, gemerged am 17. April, erweiterte NIP-34 Git-Repositories mit Status-Events, Klärungen, optionalen Maintainern, Repo-Identifikatoren und Discoverability-Tags. Dieser Schritt machte Git-über-Nostr für ngit und später GitWorkshop praktikabler.

NIP-17, früher NIP-24, landete am 24. April als sealed gift-wrapped Nachrichten für private DMs und kleine Gruppen-Chats. Client- und Bibliotheksarbeit lief parallel: Amethyst, Primal, Gossip, nostr-tools, NDK und rust-nostr waren alle im selben Zeitraum aktiv.

OpenSats kündigte im April 2024 auch langfristige Unterstützung für Nostr-Entwickler an: PabloF7z am 9. April, Stuart Bowman am 12. April und hzrd149 am 15. April. Diese Grants verschoben die Finanzierung von isolierten Projekt-Grants hin zu nachhaltiger Wartung von Relays, Bibliotheken und Client-Infrastruktur.

April 2025: dichte NIP-Bereinigung und Blossom-Formalisierung

Der April 2025 war der dichteste Protokollmonat in dieser Retrospektive, mit sechzehn gemergten NIPs-PRs. Der Monat begann mit PR #1846, der Blockchain-Transaktionen und -Adressen zu NIP-73 hinzufügte, und PR #1865, der NIP-C0-Tags zur Tabelle der standardisierten Tags hinzufügte. Er ging weiter mit PR #1801 und PR #1889, die beide die Anleitung zur Republikation von kind 10002 Relay-Listen verbesserten, und PR #1879, der NIP-65 verkleinerte und klärte.

PR #1822 fügte NIP-B7 für Blossom-Interaktion hinzu und gab Nostr-Clients und Blossom-Servern nach mehr als einem Jahr informeller Praxis eine kanonische Koordinationsschicht. PR #1051 deprecatete NIP-26, die Spezifikation zur delegierten Event-Signierung. NIP-26 war schwierig sicher zu implementieren gewesen und war weniger attraktiv geworden, als NIP-46 und andere Signer-Muster reifer wurden.

Der Rest des Monats kombinierte Bereinigung mit Anwendungserweiterung: PR #1882 fügte Datenschutzrichtlinien- und Nutzungsbedingungsfelder zu NIP-11 hinzu, PR #1849 erweiterte kind 39701 Web-Bookmarks unter NIP-B0, PR #1891 fügte dieses Bookmark-kind zur README hinzu, und PR #1895 fügte NIP-B0 standardisierte Tags hinzu. OpenSats kündigte am 16. April seine elfte Welle der Nostr-Grants an und finanzierte Swae, HAMSTR, Vertex, Nostr Double Ratchet und Nostr Game Engine. Primal, Coracle, noStrudel, nostr-tools, NDK und rust-nostr lieferten in diesem Zeitraum ebenfalls aus, sodass die Protokollbereinigung neben aktiver Client- und Bibliotheksarbeit stand.

April 2026: NIP-34-Härtung, Badges und adoptionsfokussierte Grants

Der April 2026, der Monat, mit dem diese Ausgabe abschließt, hatte vier gemergte NIPs-PRs. Der erste war PR #2276, gemerged am 1. April, der NIP-58 Profile Badges auf kind 10008 änderte und kind 30008 Badge-Sets hinzufügte, wodurch Badge-Zuweisung und Badge-Sammlungen komponierbarer wurden. Eine zweite Usability-Änderung für Git-über-Nostr kam in PR #2312, gemerged am 10. April, die nostr:// Clone-URL-Semantik zu NIP-34 hinzufügte. Die Bereinigungen vom 25. April, PR #2325 und PR #2326, entfernten ungenutzte und falsche NIP-34-Sprache.

Verwandte Commits schärfen dieselben Oberflächen. Am 22. April fügte fiatjaf eine Blossom-Server-Liste zu NIP-51 hinzu und passte die NIP-29-Metadaten-Bearbeitung an das PUT-Style-Verhalten von Flotilla an. Am 26. April benannte er NIP-5A zur Klarheit um. Der April 2026 konzentrierte sich darauf, bereits genutzte Protokolloberflächen einfacher zu implementieren und schwerer fehlzuinterpretieren zu machen.

OpenSats kündigte am 8. April seine sechzehnte Welle der Nostr-Grants an und unterstützte Amethyst Desktop, Nostr Mail, Nostrord, Nurunuru (null–nostr) und eine HAMSTR-Erneuerung: Desktop-Clients, E-Mail-ähnliches Messaging, Gruppen-UX, japanisches Onboarding und Off-Grid-Konnektivität.

Danke fürs Lesen von Nostr Compass #20. DM uns auf Nostr mit Tipps, Korrekturen oder neuen Projekten, die wir behandeln sollen.

Nostr Compass #19

Wed, 22 Apr 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Amethyst liefert einen großen Schwung an Marmot-, Community- und MoQ-Audio-Rooms-Arbeit aus, TollGate stabilisiert Pay-per-use-Internetzugang über Nostr und Cashu in v0.1.0, und nostream schließt eine Woche Relay-Arbeit rund um NIP-45, NIP-62, Kompression, Query-Härtung und vollständige NIP-11-Parität ab. Forgesworn startet einen kompletten Signing-, Identity- und Paid-API-Stack für Nostr. ShockWallet treibt Nostr-native Lightning-Wallet-Flows weiter voran. Die Formstr-Suite bringt Security-Härtung in Pollerama, i18n in Forms und RRULE-Support in Nostr Calendar. StableKraft, Keep, topaz, WoT Relay, Flotilla und NipLock runden die Releases ab. Die Deep Dives behandeln NIP-72 und NIP-57.

Shipping This Week

Primal Android liefert Explore-Tab, NIP-05-Verifikation und Audio-Player

Primal Android pushte 11 gemergte PRs auf den Feed-Redesigns der Vorwoche aufbauend. PR #1021 bringt einen neuen Explore-Tab, PR #1015 einen Feed-Editor mit Primal-DSL, PR #994 NIP-05-Verifikation für Profile und PR #997 einen In-Feed-Audio-Player. PR #1018 ergänzt NIP-46 nostr-connect-Pairing über den Wallet-QR-Scanner.

strfry fügt Prometheus-Write-Path-Metriken hinzu und behebt NIP-42-AUTH-Envelope

strfry veröffentlichte mehrere operator-orientierte Verbesserungen. PR #194 fügt einen dedizierten Prometheus-Exporter für den Write Path hinzu, PR #197 loggt Bytes up und down sowie Kompressionsraten, und PR #192 macht das Filter-Tag-Limit zur Laufzeit konfigurierbar. PR #201 korrigiert die NIP-42-AUTH-Failures vom NOTICE-Format auf das im NIP spezifizierte OK-Envelope.

Shopstr härtet Storefront-Sicherheit über 13 PRs

Shopstr mergte 13 PRs, dominiert von Security-Fixes. Dazu gehören die Schließung einer Stored-JavaScript-Lücke in Storefront-Links, Escaping für HTML-Rendering, Absicherung von API-Endpunkten hinter Auth und Fixes für SSRF-Funde. Funktional wurden ein Replay-sicherer Failed-Relay-Publish-Queue, ein Fix für Wallet-Events-Fetches und Revalidierung gespeicherter Cart-Discounts ergänzt.

Nostria v3.1.22 bis v3.1.28 fügen Hintergrund-Musikwiedergabe auf Android hinzu

Nostria veröffentlichte sechs Releases von v3.1.22 bis v3.1.28. Die zentrale Änderung in v3.1.26 ist Hintergrund-Musikwiedergabe auf Android mit Steuerung in Benachrichtigungsleiste und Lockscreen. Die nachfolgenden Releases härten diesen neuen Media-Service-Pfad.

Wisp v0.18.0-beta fügt Normie Mode, For You Feed und NIP-29-Gruppenkonfiguration hinzu

Wisp veröffentlichte v0.18.0-beta am 16. April. PR #462 ergänzt einen Normie Mode mit Fiat-Beträgen, PR #464 überarbeitet das Onboarding, und PR #469 fügt einen For You Feed hinzu. Auf der Protokollseite ergänzt PR #471 NIP-29-Gruppenkonfiguration für Flags, Invites, Rollen und AUTH-Prompts.

NoorNote v0.8.4 fügt geplante Beiträge und Livestream-Zaps hinzu

NoorNote veröffentlichte v0.8.4 und v0.8.5. v0.8.4 bringt ein Scheduled-Posts-Add-on, bei dem die App ein vollständig signiertes Event an ein NoorNote-Relay übergibt, das es zum geplanten Zeitpunkt veröffentlicht. Derselbe Release ergänzt One-Tap-Zapping aus Livestream-Karten, wobei die sats im Chat-Overlay des Streams über NIP-53 erscheinen.

topaz v0.0.2 liefert ein Nostr-Relay für Android aus

topaz, ein neues Nostr-Relay für Android-Telefone von fiatjaf, veröffentlichte v0.0.2 am 17. April. Das Projekt ist Kotlin-first und positioniert das Smartphone als stets verfügbares persönliches Relay.

StableKraft v1.0.0 liefert den ersten stabilen PWA-Release für Musik und Podcasts aus

StableKraft ist eine Next.js-PWA zum Entdecken, Organisieren und Streamen von Musik aus Podcast-Feeds, mit Nostr für Auth und soziale Features und Lightning für V4V-Zahlungen. Das Projekt erreichte v1.0.0 am 18. April. Dieselbe Woche brachte Feed-Ingestion-Härtung und ein kleineres Reparse-Fenster, damit neu hinzugefügte Feeds schneller selbst heilen.

NipLock liefert einen auf NIP-17 basierenden Passwortmanager aus

NipLock ist ein Passwortmanager, der Zugangsdaten über NIP-17 Gift-Wrapped Direct Messages zwischen Geräten speichert und synchronisiert. Jede Passwort-Zeile ist eine NIP-17-DM vom Schlüssel des Nutzers an sich selbst, sodass dieselben Events auf jedes Gerät replizieren, das sich mit demselben Schlüssel authentifiziert. Signing funktioniert mit nsec, Browser Extensions wie nos2x oder Amber via NIP-46.

flotilla-budabit poliert seine NIP-34-Repo-Oberfläche

Die Budabit-Community-Fork von Flotilla, flotilla-budabit, lieferte mehrere Fixes für ihren NIP-34-Git-over-Nostr-Workflow aus, darunter wiederhergestellte Repo-Diskussionssteuerung, sichtbare Sticky-Tabs, Laden von Repo-Announcements aus gespeicherten GRASP-Relays und Synchronisierung des durch Maintainer gesetzten Patch-Status.

rx-nostr 3.7.2 bis 3.7.4 fügen Default-Verifier und optionale Constructor-Argumente hinzu

rx-nostr veröffentlichte 3.7.2, 3.7.3 und 3.7.4. PR #192 ergänzt einen standardmäßigen Schnorr-Signaturverifier, und PR #195 macht die Argumente von createRxNostr() optional.

Keep Android v1.0.0 liefert mit reproducible builds und null Trackern aus

Keep veröffentlichte v1.0.0 am 21. April nach mehreren Hardening-PRs. Dazu gehören reproducible builds mit fixierter Toolchain, der Wechsel von Google ML Kit zu ZXing und ein Exodus Privacy scan, der null Tracker auf dem v1.0.0-Build zeigt.

Flotilla 1.7.3 und 1.7.4 fügen kind-9-Wrapping für reichere NIP-29-Räume hinzu

Flotilla, hodlbods NIP-29-Client, veröffentlichte 1.7.3 und 1.7.4. Die wichtigste Protokolländerung ist kind-9-Wrapping für Nicht-Chat-Inhaltstypen, angekündigt in hodlbods Release-Note und verknüpft mit NIP PR #2310.

WoT Relay v0.2.1 migriert den Eventstore auf LMDB

WoT Relay veröffentlichte v0.2.1 am 22. April. PR #97 migriert den Eventstore auf LMDB, PR #99 aktualisiert golang.org/x/crypto, und PR #100 aktualisiert die beworbene NIP-11-Software-URL und Versionszeichenkette.

Formstr suite: Pollerama-Security-Pass, Forms-i18n, Calendar-RRULE-Support

Die Formstr-Suite mergte 26 PRs über Pollerama, Formstr Forms und Nostr Calendar hinweg. Pollerama härte sein Key-Handling, indem gecachte Direct Messages beim Logout verfallen, lokale Keys in sichere Browser-Storage wandern und JSON.parse von kind-0-Profilen auf allen Login-Pfaden abgesichert wird. Formstr ergänzte Audio- und Video-URLs, i18n und einen Google-Forms-Importer. Nostr Calendar by Formstr veröffentlichte v1.3.0 und v1.4.0 mit RRULE-Unterstützung, UTC-Korrektur für Floating-Dates und überarbeitetem Login- und Loading-Pfad.

Also shipped: notedeck, nostr.blue, cliprelay, Captain’s Log

Mehrere Clients veröffentlichten kleinere iterative Releases ohne große Headlines. notedeck brachte v0.10.0-beta.4 mit Column-Rendering- und Relay-Pool-Fixes, nostr.blue v0.8.6 zog Dioxus 0.7.5 nach und reparierte den Android-Build, cliprelay veröffentlichte Desktop v0.0.3 und Android v0.0.4, und Captain’s Log lieferte Alpha-Builds mit Liveness Detection für Sync-Relays.

In Development

whitenoise-rs refaktoriert zu session-scoped Account-Views

whitenoise-rs, der Rust-Daemon unter dem Marmot-Client, mergte 15 PRs, die einen mehrphasigen Refactor von globalen Singletons zu account-spezifischen AccountSession-Views voranbringen. PR #743 schuf das Grundgerüst, Folgephasen migrierten Relay-Handles, Drafts, Settings, Message-Ops, Gruppenfunktionen, Push Notifications und KeyPackage-Reads, und PR #770 verlegt nun auch den Event-Dispatch in die Session.

White Noise fügt Block/Unblock-UI, Leave-Group und Offline-Hinweise hinzu

White Noise ergänzte fehlende Group-Lifecycle-Steuerung. PR #578 liefert die Block- und Unblock-UI, PR #571 und PR #572 verkabeln clear_chat, delete_chat und leave_and_delete_group aus der Rust-Seite in die App, und PR #569 plus PR #576 ergänzen Offline-Hinweise in Chat- und Settings-Screens.

MDK fügt Mixed-Version-Invite-Support und SelfUpdate-Konvergenz hinzu

MDK mergte sieben PRs. Die wichtigste Korrektur ist PR #261, die RequiredCapabilities einer Gruppe als LCD der Invitee-Fähigkeiten berechnet und damit Mixed-Version-Invites zwischen Amethyst und White Noise freischaltet. PR #264 vereinheitlicht das SelfUpdate-Wire-Format, weitere PRs härten Invitee-KeyPackage-Parsing, Admin-Depletion-Validierung und In-Memory-Storage.

nostter fügt NIP-44-Verschlüsselung für People Lists, Bookmarks und Mutes hinzu

nostter mergte 10 PRs. PR #2088 ergänzt NIP-44 für Mute-Listen, PR #2089 für Bookmarks und PR #2090 für People Lists. Damit wandert die App dort, wo es passt, von NIP-04 ab.

zap.cooking liefert Nourish-Scoring und wiederverwendbaren Comment Thread

zap.cooking mergte 20 PRs. Das zentrale Feature ist ein neues Nourish-Rezeptbewertungsmodul, dazu kommt ein vierstufiger Refactor, der das Comments-Modul zu einem wiederverwendbaren CommentThread macht.

ridestr extrahiert gemeinsamen Rider Coordinator

ridestr mergte 10 PRs, refaktorierte Compose-Screens in fokussierte Komponenten und extrahierte Protokolllogik für Rider und Driver in ein gemeinsames :common-Coordinator-Modul. PR #60 ergänzt einen kind-3189-Driver-Ping-Receiver.

Blossom entwirft einen BUD-01-Sunset-Header für Blob-Expiration

Blossom eröffnete PR #99, um einen Sunset-Header zu BUD-01 hinzuzufügen. Ein Server könnte damit einen zukünftigen Timestamp ankündigen, ab dem ein Blob nicht mehr ausgeliefert wird.

New Projects

Forgesworn veröffentlicht ein 29-Repos-umfassendes kryptographisches Toolkit für Nostr

Forgesworn veröffentlichte in fünf Tagen 29 Open-Source-Repositories für Signing, Identity, Attestations, Web of Trust und Paid-API-Discovery auf Nostr. Zum Signing-Stack gehören nsec-tree, Heartwood, Sapwood und nsec-tree-cli. Auf der Identity-Seite erreichte Signet v1.6.0, nostr-attestations definiert ein einheitliches kind-31000-Event, und nostr-veil baut ein privacy-preserving Web of Trust auf LSAG-Ring-Signaturen.

Die Monetisierungsseite deckt bezahlte APIs über Lightning und Nostr ab. toll-booth ist ein L402-Middleware-Layer für mehrere Frameworks, toll-booth-dvm exponiert die API als NIP-90 Data Vending Machine, und 402-announce publiziert kind-31402-Events für HTTP-402-Service-Discovery auf Nostr.

ShockWallet liefert Nostr-nativen Lightning-Wallet-Sync und Multi-Node-Verbindungen aus

ShockWallet ist eine Lightning-Wallet, die Nostr als Transport für die Verbindung zu selbstverwahrten Lightning-Nodes nutzt. Die App koppelt sich über ein nprofile an einen oder mehrere Lightning.Pub-Nodes und signiert Payment-Autorisierungen Ende zu Ende zwischen Wallet und Node. Das Team lieferte PR #608 mit einer neuen Channels-Dashboard-UI aus, dazu kamen ein Admin-Invite-Link-QR-Flow und Verbesserungen für das Metrics-Dashboard.

ShockWallet nutzt NIP-78 application-specific data events für Multi-Device-Wallet-State-Sync, sodass die Wallet-Sicht über Browser und Smartphone konsistent bleibt, ohne einen zentralen Sync-Server.

Nostrability-Issues wechseln nach GitHub-Zensur zu Git over Nostr

Nostrability, elsats Interoperabilitäts-Tracker für Nostr-Clients und Relays, verlagert seinen Issue-Workflow auf Git over Nostr, nachdem die GitHub-Organisation Nostrability entfernt wurde und zwei Wochen lang keine Antwort vom GitHub-Support kam.

nowhere codiert vollständige Websites in URL-Fragmente und routet Bestellungen über Nostr

nowhere serialisiert eine komplette Website in den URL-Fragmentteil nach #, komprimiert sie und kodiert sie base64url. Weil Browser Fragmente nicht an Server senden, sieht der Host, der die Seite ausliefert, den eigentlichen Inhalt nie. Fünf der acht Site-Typen sind statisch, für Store, Forum und Petition läuft die Live-Kommunikation über Nostr-Relays und NIP-44-verschlüsselte Events mit Wegwerf-Schlüsseln.

Kleine neue Flächen: relayk.it und Brainstorm Search

Zwei kleine Projekte verdienen ohne großes Changelog eine Erwähnung. relayk.it ist ein mit Shakespeare gebauter Relay-Discovery-Client komplett im Browser. Brainstorm Search ist eine Single-Page-Nostr-Suche mit Fokus auf Inhalte im gesamten Netzwerk.

Protocol and Spec Work

NIP Updates

Aktuelle Vorschläge und Diskussionen im NIPs repository:

Open PRs and Discussions:

NIP-67: EOSE Completeness Hint (PR #2317): Schlägt ein optionales drittes Element für EOSE vor, damit ein Relay explizit signalisieren kann, ob alle passenden gespeicherten Events geliefert wurden.
NIP-5D: Nostr Applets (PR #2303): Schlägt einen neuen kind für interaktive Applets auf Nostr vor, zwischen NIP-5A und NIP-5C.
NIP-29: Subgroups spec (PR #2319): Erweitert NIP-29 um eine Subgroup-Hierarchie für mehrere Channels innerhalb einer Gruppe.
NIP-29: Explicit role permissions on kind 39003 (PR #2316): Definiert ein explizites Berechtigungsschema für Rollen in NIP-29.
NIP-11: access_control field for gated-relay discovery (PR #2318): Schlägt ein neues optionales access_control-Objekt im NIP-11 Relay Information Document vor.
NIP-63a: Minimal Payment Gateway Descriptor (PR #2315): Wird seit Newsletter #18 weiter ausgearbeitet.
NIP-XX: Agent Reputation Attestations (Kind 30085) (PR #2320): Schlägt ein addressable Event für signierte Attestierungen über autonome Agenten und Services auf Nostr vor.
NIP-TPLD: Transient Private Location Data (PR #2309): Iteriert weiter am kind-20411-Modell und der NIP-44-Verschlüsselungsform pro Empfänger.
marmot-ts 0.5.0 release PR (PR #70): Bündelt die ersten geplanten Breaking Changes im TypeScript-Marmot-Client.

NIP Deep Dive: NIP-72 (Moderated Communities)

NIP-72 definiert ein Modell für themenbasierte Communities auf Nostr, in dem Moderatoren eine Leseansicht über sonst unbeschränkte Schreibrechte kuratieren. Anders als bei NIP-29-Gruppen liegt die Autorität nicht bei einem einzelnen Relay. Eine NIP-72-Community lebt in normalen Nostr-Events, und jedes Relay, das die relevanten Kinds trägt, kann sie ausliefern.

Eine Community wird durch ein addressable kind-34550-Event definiert. Das d-Tag ist ihr stabiler Slug, name, description, image und rules tragen Darstellungsmetadaten, und p-Tags mit Marker moderator listen die pubkeys auf, deren Freigaben zählen. Nutzer reichen Beiträge ein, indem sie ein beliebiges gewöhnliches Event veröffentlichen und ein a-Tag mit der Community-Koordinate hinzufügen. Die Freigabe erfolgt über ein separates kind-4549-Event eines Moderators, das die Einreichung referenziert und eine stringifizierte Kopie davon in content cached.

Das Modell hat drei wichtige Eigenschaften: Moderationsentscheidungen sind transparent, weil jede Freigabe ein signiertes Nostr-Event ist; Moderation ist nicht exklusiv, weil derselbe Beitrag von mehreren Communities freigegeben werden kann; und sie ist auf Leseschicht umkehrbar, weil ältere Freigaben eines entfernten Moderators in Clients nicht mehr zählen müssen. Der Tradeoff bleibt, dass Einreichungen von Anfang an öffentlich sind. NIP-72 verbirgt unfreigegebene Beiträge auf Rendering-Ebene, hält sie aber nicht vom Wire fern.

NIP Deep Dive: NIP-57 (Zaps)

NIP-57 definiert zaps, also die Verknüpfung von Lightning-Zahlungen mit Nostr-Identitäten und Inhalten. Ein Zap beweist, dass ein bestimmter Sender einen bestimmten Betrag an einen bestimmten Empfänger für ein bestimmtes Ziel bezahlt hat und dass dieser Nachweis von jedem Nostr-Client gelesen werden kann. Das NIP verbindet LNURL, Lightning und Nostr in einem gemeinsamen Ablauf.

Der Sender entdeckt zuerst den LNURL-Endpoint des Empfängers aus dessen Profil oder einem zap-Tag auf dem Ziel-Event. Danach signiert der Client ein kind-9734-Zap-Request-Event und sendet es an den LNURL-Callback, nicht an Relays. Nach Zahlung veröffentlicht der Wallet-Server des Empfängers ein kind-9735-Zap-Receipt auf den Relays, die im Request angegeben wurden. Das Receipt enthält den stringifizierten Zap-Request im description-Tag, die bezahlte Invoice im bolt11-Tag und einen preimage-Nachweis.

Die Sicherheitsgarantie entsteht erst durch Validierung. Ein Client sollte die Signatur des Receipts gegen den nostrPubkey aus der LNURL-Antwort prüfen, die bolt11-Amount gegen den amount-Tag vergleichen, den Description-Hash gegen den eingebetteten Request validieren und das preimage gegen den payment_hash der Invoice prüfen. Ohne diese Prüfungen ist ein Receipt nur eine Behauptung. NIP-57 trägt außerdem NIP-75 Zap Goals, bei denen beliebige Zap Receipts auf das Fortschrittsziel eines kind-9041-Events angerechnet werden.

Das war’s für diese Woche. Wenn du etwas baust oder Neuigkeiten teilen willst, schreib uns auf Nostr oder schau bei nostrcompass.org vorbei.

Nostr Compass #18

Wed, 15 Apr 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Amethyst mergt 29 PRs, darunter Desktop-Tor-Support, eine eigene C-secp256k1-Implementierung, ein vollständiges WebRTC-Calls-System für NIP-AC, RFC-9420-MLS-Compliance für Marmot und Multi-Wallet-NIP-47. nstrfy startet als Android-Push-App, die Firebase durch Nostr-Relays und kind 7741 ersetzt. HAMSTR fügt Reticulum hinzu und bringt Nostr über LoRa-Mesh ohne Internetanbindung. Bloom startet mit v0.1.0 als Desktop-App mit integriertem Blossom-Server und Relay. WaveFunc debütiert als Nostr-Internetradio auf Basis von NIP-53. Botburrow startet als self-hosted Bot-Plattform für Marmot-Gruppenchats. Snort liefert v0.5.0 bis v0.5.3 mit Security-Audit und Performance-Überarbeitung, und Primal Android gestaltet seinen Feed neu.

Shipping This Week

Bloom v0.1.0 liefert self-hosted Blossom-Server und Relay aus

Bloom veröffentlichte seinen ersten Release, v0.1.0, am 9. April. Bloom wird mit Tauri v2 und React 19 gebaut und bündelt einen vollständigen Blossom-Medienserver, BUD-00 bis BUD-10, und ein Nostr-Relay in einer einzigen Desktop-Anwendung für macOS, Windows und Linux. Nutzer erhalten souveräne Dateispeicherung mit SHA-256-Content-Addressing, NIP-94-Dateimetadaten und blossom://-Auflösung, ohne eigene Server-Infrastruktur betreiben zu müssen.

WaveFunc v0.1.0 und v0.1.1 starten Nostr-Internetradio

WaveFunc veröffentlichte v0.1.0 und v0.1.1 am 13. April. Der Dienst startet als auf Nostr basierendes Internetradio-Verzeichnis und Player. Die Datenstruktur nutzt eigene Event-Kinds: kind 31237 für Senderlisten, kind 30078 für Favoritenlisten, kind 1311 für Live-Chat und kind 1111 für Senderkommentare. Ein Khatru-Relay-Backend liefert SQLite-Speicherung und Bluge-Volltextsuche mit NIP-50.

WaveFunc bringt außerdem eine NIP-60-Cashu-Wallet und nutzap-Support mit, migrierte von NDK zu applesauce-core und ergänzte in v0.1.1 Genre-Karussells, Lightning-Donations, Senderverwaltung für eingeloggte Nutzer und einen Zapstore-Eintrag.

Snort liefert v0.5.0 bis v0.5.3 mit Security-Härtung und Performance-Überarbeitung

Snort veröffentlichte drei Releases von v0.5.0 bis v0.5.3. v0.5.0 ist der größte Schritt und bringt ein umfassendes Security-Audit, echte Schnorr-Signaturprüfung, gehärteten Schutz für NIP-46 gegen gefälschte Relay-Nachrichten, verbesserte PIN-Verschlüsselung und das Ende des Vertrauens in unbestätigte NIP-26-Delegation. Performance-Gewinne kommen durch gebündelte WASM-Verifikation, lazy-geladene Routen und einen neu geschriebenen Priority-Profile-Loader.

Die Release-Linie ergänzt außerdem die Anzeige von kind-7000-Payment-Required-Invoices für NIP-90 DVMs. PR #620 überarbeitet zusätzlich das Messaging-System und ersetzt eine O(n²)-Berechnung der Chat-Liste durch einen einzelnen Map-basierten Durchlauf.

Primal Android liefert 3.0.21 und gestaltet das Feed-Layout neu

Primal Android veröffentlichte v3.0.21 mit Fixes für Poll-Zap-Stimmen, Wallet-Multi-Account-Sharing und Auto-Reconnect für Remote Signer und Wallet-Service. Danach folgten sieben gemergte PRs. PR #1008 vereinheitlicht das Main-Screen-Layout, PR #1010 führt ein neues Feed-Card-Design mit größeren Avataren ein, und PR #1009 ergänzt Video-Support und Portrait-Layout für Media-Cards.

Nostria v3.1.19 bis v3.1.21 fügen lokale AI-Bildgenerierung hinzu

Nostria veröffentlichte drei Releases von v3.1.19 bis v3.1.21 mit mehr als 80 Commits. Die wichtigste Neuerung ist lokale Bildgenerierung mit Janus Pro und WebGPU-Beschleunigung, sodass Nutzer Bilder direkt auf dem Gerät ohne externe API erzeugen können. Dazu kommen Cloud-Bildgenerierung, multimodaler Chat, ONNX-Runtime-Support, eine AI-Prompt-Bibliothek und AI-Cache-Management.

TubeStr v1.0.3 liefert Feed- und Studio-Updates aus

TubeStr veröffentlichte v1.0.3 am 13. April. Der Release verbessert Feed und Studio. PR #3 überarbeitet das Onboarding, PR #2 behebt einen Fehler beim Videoexport. Die App nutzt NDK und MDK für verschlüsselte Medienfreigabe im Familienkontext und plant Blossom für die Medienspeicherung.

In Development

Botburrow beginnt die Entwicklung als Marmot-Bot-Plattform

Botburrow ist ein neues Projekt des Marmot-Teams, gestartet am 3. April. Es ist eine self-hosted Bot-Management-Plattform, auf der jeder Bot eine eigene Nostr-Identität erhält, Marmot-verschlüsselten Gruppen per Welcome-Nachrichten beitritt und Ende-zu-Ende-verschlüsselte Nachrichten sendet und empfängt. Das Dashboard ist mit Rails 8.1 gebaut und spricht über einen Unix-Socket mit einem einzelnen whitenoise-rs-Daemon.

Nostr Archives entwickelte seine Rust-API und das Next.js-Frontend weiter. PR #118 ergänzt Time-Range-Filterung für das Client-Leaderboard, PR #117 fügt Engagement-Zähler für Reply-Events hinzu. Auf der Frontend-Seite löst PR #85 Nostr-Entities direkt aus URL-Pfaden auf, und PR #86 fügt eine API-Dokumentationsseite hinzu.

Damus behebt die Favorites-Timeline

Damus mergte PR #3708, das subscribe_to_favorites() mit In-Place-Filtering, neuer Deduplizierung und persistierter Tab-Auswahl neu schreibt.

Nostur fügt private zaps und benutzerdefinierte Emoji-Anzeige hinzu

Nostur pushte zehn Commits und ergänzte private zaps, Anzeige benutzerdefinierter Emoji, einen Fix für animiertes .webp-Rendering und Erkennung des Audioformats für Sprachmemos.

Amber liefert v6.0.1 bis v6.0.3 mit WebDAV-Backups und Relay-Reconnect-Fixes

Amber, die Android-NIP-55-Signer-App, veröffentlichte drei Releases. v6.0.1 fügt WebDAV- und Google-Drive-Backups hinzu, implementiert Exponential Backoff für Relay-Reconnects und aktualisiert Quartz. v6.0.2 ergänzt eine Account-Index-Option bei Seed-Wörtern, und v6.0.3 behebt leere Request-IDs beim Empfangen von Intents.

Plektos v0.6.0 gestaltet mit Ditto-Themes neu

Plektos, die auf NIP-52 basierende Meetup- und Event-Plattform, veröffentlichte v0.6.0 und v0.6.1. Das Update bringt Ditto-artige Community-Themes, konfigurierbare Avatar-Formen und eine UI-Überarbeitung.

Shadow fügt Nostr OS API und Cashu-Wallet-App hinzu

Shadow pushte in zwei Tagen über 30 Commits. Commit 88cbda5 fügt eine Cashu-Wallet-App innerhalb der Shadow-Runtime hinzu, Commit 865c415 ergänzt einen Podcast-Player-Demo. Die Runtime exponiert Shadow.os.nostr und Shadow.os.audio als erstklassige OS-APIs.

Lief veröffentlichte Build v2026.04.12 und behebt ein Amber-Signer-Login-Problem auf Android, vereinfacht den Signer-Nudge-Flow, aktualisiert nostrify und ergänzt Zapstore-Integration.

Espy veröffentlichte ebenfalls Build v2026.04.12. Das Update überarbeitet den Color Picker, ersetzt den Grayscale-Toggle durch einen gekrümmten Sättigungsbogen, behebt Flicker-Bugs im Hue-Ring und fügt Easter-Egg-Charaktere hinzu. Außerdem kommt derselbe Amber-Login-Fix wie in Lief.

Jumble fügt Kind-Filter pro Feed und einen Artikel-Tab hinzu

Jumble pushte 13 Commits und ergänzte Kind-Filter pro Feed, einen Articles-Tab, Sync des Notification-Read-Status mit einer privacy-preserving Option, einen Avatar-Hide-Modus und einen Fix für einen Race-Condition beim Account-Wechsel.

Primal Web liefert acht Versionssprünge

Primal Web veröffentlichte in einer Woche die Versionen 3.0.93 bis 3.0.101 mit 21 Commits. Die Arbeit konzentrierte sich auf Verbesserungen im Livestream-Chat, Mention-Boundary-Fixes, Bookmark-Pagination, Verhinderung doppelter Likes und Relay-Proxy-Fixes.

Protocol and Spec Work

NIP Updates

Aktuelle Änderungen im NIPs repository:

Merged:

NIP-34 (Git Stuff): Add nostr:// clone URLs (PR #2312): Der PR fügt ein nostr://-Clone-URL-Format für Git-over-Nostr-Repositories hinzu. Definiert werden direkte naddr-Referenzen sowie menschenlesbare Formen über npub oder NIP-05. Die Änderung ist bereits in Shakespeare, ngit, GitWorkshop.dev und NostrHub.io sichtbar und verschärft zugleich das d-Tag-Format für Repository-Identifiers.

Open PRs and Discussions:

NIP-63a: Minimal Payment Gateway Descriptor (PR #2315): Schlägt ein neues replaceable kind-10164-Event vor, mit dem Content-Creator Payment Gateways, Preisstufen und Subscription-Regeln für bezahlte Inhalte deklarieren können.
NIP-XX: Relay Self-Declaration Manifest and Retention Horizon (PR #2314): Schlägt kind 10100 für gossippbare Relay-Selbsterklärungen sowie eine neue Relay-zu-Client-Nachricht HORIZON vor, die dem Client vor EOSE mitteilt, ab welchem Timestamp das Relay überhaupt Daten hält.
NIP-TPLD: Transient Private Location Data (PR #2309): Schlägt kind 20411 für verschlüsselte Geolokationsdaten an ausgewählte Empfänger vor, mit ttl-Tag und per Empfänger verschlüsselten NIP-44-Payloads.
NIP-5C (Scrolls): WASM programs update (PR #2281): Führt die Spezifikation für WebAssembly-Programme auf Nostr weiter aus und verfeinert Event-Format und Runtime-Interface für Scrolls.
NIP-44 large payload support (PR #1907): Schlägt abwärtskompatible Unterstützung für Payloads vor, die größer als 65.535 Byte sind, vor allem relevant für große NIP-46-Antworten wie umfangreiche Contact Lists.
NIP-C7: Restrict kind 9 to chat views (PR #2310): Präzisiert, dass Clients in Chat-Ansichten nur kind-9-Events abrufen sollen, damit Chat-Nachrichten nicht ohne Kontext in allgemeine Feeds geraten.

NIP Deep Dive: NIP-29 (Relay-based Groups)

NIP-29 definiert ein Modell für Gruppenkommunikation, bei dem das Relay selbst Mitgliedschaft und Moderation verwaltet. Gruppen leben auf einem bestimmten Relay und das Relay setzt durch, wer schreiben darf. Das ist eine andere Architektur als Marmot oder NIP-17 Gruppenchats: Bei NIP-29 ist das Relay die Autorität, kann die Nachrichten lesen und moderiert auf Relay-Ebene.

Eine Gruppe wird durch <host>'<group-id> identifiziert, etwa groups.nostr.com'abcdef. Nutzer-Events tragen ein h-Tag mit der Gruppen-ID, und das optionale previous-Tag wirkt als Mechanismus zur Tamper-Erkennung. Clients fügen die ersten acht Hex-Zeichen kürzlich gesehener Events bei, und Relays lehnen Events ab, deren previous-Referenzen sie nicht in ihrer Datenbank finden. Das ist keine vollständige Chain of Custody, macht aber Kontextverluste und Replay in Relay-Forks erkennbar.

Mitgliedschaft wird über eine Reihe von Moderations-Events im Bereich 9000-9020 verwaltet. Ein Nutzer tritt über kind 9021 bei, das Relay akzeptiert oder verweigert die Anfrage nach eigener Policy. Admins können Nutzer mit Rollen hinzufügen, entfernen, Gruppenmetadaten ändern und Events löschen. Die Gruppe veröffentlicht ihren Zustand als addressable Events, etwa kind 39000 für Metadaten und kind 39003 für Rollen und Fähigkeiten. Der entscheidende Tradeoff bleibt: NIP-29 ist einfach und praktisch für öffentliche Communities, aber das Relay ist ein Vertrauensanker und kein neutraler Transport.

NIP Deep Dive: NIP-90 (Data Vending Machines)

NIP-90 definiert ein Protokoll für On-Demand-Compute über Nostr. Ein Kunde veröffentlicht einen Job-Request, Service-Provider konkurrieren um die Ausführung, und Resultate kommen als Nostr-Events zurück. Die Spezifikation reserviert kinds 5000-5999 für Requests, 6000-6999 für Resultate und kind 7000 für Feedback. Ein Result- kind ist immer genau 1000 höher als der passende Request-kind.

Requests nutzen i-Tags für Input, output für das erwartete Format, bid für eine Preisobergrenze und param für job-spezifische Parameter. Resultate referenzieren den Original-Request, nennen den pubkey des Kunden und können über das amount-Tag eine Lightning-Rechnung mitliefern. Feedback-Events mit kind 7000 erlauben Statusmeldungen wie payment-required, processing, error oder success, bevor das Endergebnis vorliegt.

Wichtig ist, dass NIP-90 auch Job Chaining erlaubt. Ein nachgelagerter Job kann den Output eines früheren Jobs über einen i-Tag vom Typ job referenzieren. Damit entstehen Pipeline-artige Abläufe, etwa Audio transkribieren, den Text zusammenfassen und das Ergebnis übersetzen. Für Privacy können i- und param-Daten verschlüsselt in content verschoben werden, was Relay-Beobachtern die Eingaben verbirgt, aber die Auswahl eines bestimmten Providers voraussetzt.

Das war’s für diese Woche. Wenn du etwas baust oder Neuigkeiten teilen willst, schreib uns auf Nostr oder schau bei nostrcompass.org vorbei.

Nostr Compass #17

Wed, 08 Apr 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Amethyst liefert v1.08.0 mit Arti-Tor-Integration und einer neu gestalteten Shorts-UI aus und integriert zugleich reine Kotlin-Implementierungen von MLS und Marmot in seine Quartz-Bibliothek. Nostur liefert v1.27.0 mit Videoaufnahme, animierten GIF-Profilen und privaten Antworten. Shosho startet v0.15.0 mit Shows, also benutzerdefinierten Livestream-Infos mit OBS-Anbindung, und einem TikTok-artigen vertikalen Video-Karussell. Nymchat nimmt Marmot zurück und liefert erweiterte NIP-17-Gruppenchats aus, die rotierende ephemeral keys nutzen. Nostr VPN liefert exit node-Support und Umbrel-Paketierung über sechs Releases hinweg. Amber springt auf v6.0.0-pre1 mit NIP-46-signing keys pro Verbindung und In-App-Updates über Zapstore. Notedeck erreicht v0.10.0-beta mit APK-Self-Update via Zapstore, und NIP-58 (Badges) erhält eine kind-Migration. Zwei NIP-Deep Dives behandeln NIP-17 (Private Direct Messages) und NIP-46 (Nostr Remote Signing).

Neuigkeiten

Amethyst liefert Arti Tor und integriert reines Kotlin MLS und Marmot

Amethyst, der von vitorpamplona gepflegte Android-Client, lieferte vier Releases von v1.07.3 bis v1.08.0 aus und mergte ein großes Paket noch unveröffentlichter Arbeit in seine Quartz-Bibliothek, also das gemeinsame Kotlin-Multiplatform-Nostr-Modul. Das Hauptrelease ist v1.08.0 “Arti Tor”, das die Tor-Anbindung der App von der C-basierten Tor-Bibliothek auf Arti, die Rust-Implementierung des Tor Project, umstellt. Die Migration behebt zufällige Abstürze, die unter den bisherigen C-Tor-Bindings auftraten. Arti ist der langfristige Ersatz des Tor Project für die C-Codebasis, von Grund auf in Rust geschrieben für Memory Safety und async I/O.

Der Release v1.07.3 gestaltet die Shorts-UI neu und ersetzt das seitenbasierte Design durch randlose Feeds für Bilder, Shorts und lange Videos. Derselbe Release migriert Badges auf kind 10008 und Bookmarks auf kind 10003 und richtet sich damit an der NIP-58-kind-Migration aus, die diese Woche gemergt wurde. v1.07.4 behebt ein Problem bei der Secret-Verarbeitung in Nostr Wallet Connect, und v1.07.5 behebt einen Absturz beim Bild-Upload.

Auf main, aber noch nicht in einem getaggten Release, hat das Team eine vollständige Kotlin-Implementierung sowohl von MLS als auch des Marmot-Protokolls geschrieben und damit den Bedarf an nativen C/Rust-Bibliotheks-Bindings ersetzt. PR #2147 fügt die zentrale Marmot-MLS-Schicht für Gruppennachrichten hinzu, PR #2149 fügt die Gruppenchat-UI hinzu, PR #2146 fügt eingehende und ausgehende Message-Processor mit Subscription-Manager hinzu, PR #2141 fügt Persistenz für MLS-Gruppenstatus und KeyPackage-Rotationsverwaltung hinzu, PR #2150 fügt eine vollständige MLS-Testsuite mit verbessertem GroupInfo-Signing hinzu, und PR #2158 fügt Tracking für den Veröffentlichungsstatus von KeyPackages hinzu. PR #2166 fügt eine reine Kotlin-secp256k1-Implementierung für Nostr-Kryptographieoperationen hinzu und ersetzt damit die Abhängigkeit von der nativen C-Bibliothek. Zusammen mit der Kotlin-MLS-Implementierung kann Quartz Nostr-Signing und Marmot-Gruppennachrichten ohne jegliche native Bindings ausführen, was den Weg für Kotlin-Multiplatform-Ziele einschließlich iOS öffnet.

Das Team baut außerdem Unterstützung für NIP-AC (P2P Voice and Video Calls): PR #2143 fügt eine vollständige Testsuite für die NIP-AC-Call-State-Machine hinzu, und PR #2164 verhindert, dass veraltete Call Offers nach einem App-Neustart erneut ausgelöst werden.

Nostur v1.27.0 fügt Videoaufnahme und private Antworten hinzu

Nostur, der iOS-Nostr-Client, lieferte v1.27.0 am 2. April aus. Der Release fügt Videoaufnahme direkt in der App mit Zuschneiden vor dem Upload hinzu, sodass Nutzer kurze Clips aufnehmen, auf Länge schneiden und veröffentlichen können, ohne den Client zu verlassen. Die Unterstützung für animierte GIFs erstreckt sich nun auch auf Profil- und Bannerbilder, zusätzlich kam Rendering für animierte WebP-Dateien hinzu. Eine neue Shortcuts-Integration erlaubt es Nutzern, Nostr-Posts aus Apple-Shortcuts-Automationen zu senden. Der Release fügt außerdem private Antworten hinzu und behebt DM-Kompatibilitätsprobleme, die die Zustellung zwischen Nostur und anderen Clients beeinträchtigten.

Shosho v0.15.0 startet Shows und ein vertikales Video-Karussell

Shosho, die Nostr-Livestreaming-App, lieferte v0.15.0 und v0.15.1 am 7. April aus. Das Hauptfeature ist Shows: Streamer können vor dem Start eines Livestreams eigene Show-Informationen anlegen und ihre Show mit OBS oder einem anderen externen Encoder verbinden. Dadurch wird die Metadatenfrage “Was streame ich?” vom eigentlichen Go-Live getrennt, sodass Streamer Titel, Beschreibungen und Produkte vorbereiten können, bevor sie senden. Derselbe Release fügt außerdem ein TikTok-artiges vertikales Video-Karussell zum Durchwischen von Lives, Clips und Replays in einem Vollbild-Feed hinzu sowie Quick Add zum Veröffentlichen von Videoclips und Hinzufügen von Produkten direkt von einer Profilseite. v0.15.1 behebt einen Fehler, bei dem die Tastatur das Chat-Eingabefeld des Livestreams verdeckte.

Releases

Notedeck v0.10.0-beta liefert Zapstore-Self-Update aus

Notedeck, der Desktop- und Mobile-Client des Damus-Teams, lieferte v0.10.0-beta.1 und v0.10.0-beta.2 als Test-Prereleases für APK-Self-Update aus. PR #1417 fügt APK-Self-Update über den Nostr/Zapstore-Updater auf Android hinzu und baut auf der Nostr-nativen Release-Erkennung aus Newsletter #14 auf. Der Update-Flow entdeckt neue Releases über Nostr-Events, die an Relays veröffentlicht werden, lädt dann das APK dort herunter, wo der Entwickler es hostet, also etwa bei GitHub Releases, einem Blossom-CDN oder anderen Quellen, verifiziert den SHA-256-Hash gegen das signierte Nostr-Event und installiert es. PR #1438 behebt einen Fehler im Welcome Screen, bei dem Login- und CreateAccount-Buttons sofort wieder zurücknavigierten, und PR #1424 behebt Textüberlauf in der Agentium-AI-Session-Ansicht.

Amber v6.0.0-pre1 fügt signing keys pro Verbindung für NIP-46 hinzu

Amber, die NIP-55 (Android Signer Application) Signer-App, lieferte v6.0.0-pre1 am 4. April aus. Die wichtigste Änderung sind signing keys pro Verbindung für das NIP-46 (Nostr Remote Signing) Bunker-Protokoll. Statt ein einziges Schlüsselpaar für alle Bunker-Verbindungen zu verwenden, erzeugt Amber nun für jeden verbundenen Client einen eigenen Schlüssel. Wird die Verbindung eines Clients kompromittiert, kann ein Angreifer den Signer nicht gegenüber anderen Clients imitieren.

PR #377 fügt In-App-Prüfung und Installation von Updates via Zapstore hinzu und folgt damit Notedeck bei der Einführung Nostr-nativer App-Distribution. PR #375 behandelt AndroidKeyStore-Fehler robust, indem eine Warnung angezeigt wird statt die App abstürzen zu lassen, und PR #371 fügt Datenbankbereinigung mit Größenlimits und Inhaltskürzung hinzu, um unbegrenztes Speicherwachstum zu verhindern. Das Prerelease trägt außerdem die NIP-42-Relay-Auth-Whitelist und Mnemonic-Recovery-Phrase-Login aus dem v5.0.x-Zyklus, den wir letzte Woche behandelt haben.

Nostria liefert native Mobile-App aus

Nostria, der von SondreB gepflegte plattformübergreifende Nostr-Client, veröffentlichte eine native Mobile-App für Android mit acht Releases von v3.1.11 bis v3.1.18. Die wichtigste neue Fähigkeit ist native Unterstützung für lokale Signer wie Amber und Aegis. Desktop-Installer für Linux, macOS und Windows sind ebenfalls verfügbar. PR #610 senkt den Speicherdruck im Feed mit adaptiven Runtime-Limits und Bereinigung von Preview-URLs. v3.1.14 behebt die Integration mit Brainstorm, einem Anbieter für Web of Trust. v3.1.15 konzentriert sich auf Musik-Verbesserungen. Die neue Android-App ist auf Zapstore verfügbar.

diVine 1.0.8 liefert fortsetzbare Uploads und DMs aus

diVine, der Kurzform-Video-Client, lieferte 1.0.8 mit 87 gemergten PRs aus. Fortsetzbare Uploads erlauben es Creatorn, unterbrochene Uploads Chunk für Chunk wiederaufzunehmen, statt bei instabiler Verbindung von vorn zu beginnen. Der Release fügt Einstellungen für Videoqualität und Bitrate, Double-Tap zum Liken und DM-Verbesserungen hinzu. PR #2722 fügt ein macOS-Kamera-Plugin für Desktop-Videoaufnahme hinzu, und PR #2820 migriert das Benachrichtigungssystem auf eine BLoC-Architektur mit Anreicherung und Gruppierung. Das Team ersetzte außerdem AI-generierte Sticker und Kategorie-Grafiken durch OpenMoji-SVGs (PR #2844, PR #2842).

Manent v1.3.0 fügt Unschärfe für sensible Notizen und NIP-42-Auth hinzu

Manent, die private App für verschlüsselte Notizen und Dateispeicherung, lieferte v1.3.0 am 2. April aus. Nutzer können Notizen nun als sensibel markieren, damit sie in der Listenansicht unscharf dargestellt werden und private Inhalte beim beiläufigen Scrollen verborgen bleiben. Der Release fügt außerdem Unterstützung für NIP-42 (Authentication of Clients to Relays) hinzu, sodass Manent sich bei Relays authentifizieren kann, die dies verlangen, bevor sie Events annehmen. Manent speichert alle Daten verschlüsselt auf Nostr-Relays unter Verwendung des Schlüsselpaares des Nutzers, daher erweitert NIP-42 die Menge an Relays, die es für die Speicherung nutzen kann.

Wisp v0.17.0 bis v0.17.3 fügen Livestream-Zaps und Wallet-Backup hinzu

Wisp, der Android-Nostr-Client, lieferte sechs Releases von v0.16.2-beta bis v0.17.3-beta mit 44 gemergten PRs aus. Der Release v0.17.0 fügt Sicherheitsabfragen für Wallet-Backups und Verbesserungen an der Zap-UX hinzu. v0.17.1 fügt plattformübergreifende Sichtbarkeit des Livestream-Chats und Livestream-Zap-Funktionalität hinzu. PR #423 fügt automatisches Suchen von Profilen, eine Zap-Erfolgsanimation und Verbesserungen bei Nutzerstatus hinzu. PR #426 behebt einen Out-of-Memory-Absturz in computeId bei Events mit großen Tag-Listen. Die v0.16.x-Releases fügten Emoji-Shortcode-Autocomplete, Verbesserungen an der Gruppenchat-UI und Filterung blockierter Nutzer über alle Benachrichtigungspfade hinweg hinzu.

Mostro liefert Deep Links, Nostr-Wechselkurse und einen Fix für doppelte Zahlungen aus

Mostro, die auf Nostr basierende Peer-to-Peer-Bitcoin-Börse, sah diese Woche Updates sowohl am Server-Daemon als auch am Mobile-Client. Auf der Serverseite verhindert PR #692, dass veraltete Order-Schreibvorgänge doppelte Zahlungen verursachen, also ein Fehlerbild, bei dem ein Verkäufer für denselben Trade zweimal bezahlt werden könnte. PR #693 nutzt gezielte Updates für dev_fee-Schreibvorgänge statt vollständiger Order-Überschreibungen.

Mostro Mobile, der Flutter-Client, lieferte v1.2.3 am 3. April aus. Der Release behandelt Deep Links von unterschiedlichen Mostro-Instanzen, sodass Nutzer Links antippen können, die zum richtigen Exchange-Server führen. PR #498 erkennt Admin- und Dispute-DMs in der Hintergrund-Benachrichtigungspipeline, und die App holt Wechselkurse nun von Nostr mit HTTP/Cache-Fallback. PR #560 behebt einen blockierenden Relay-Verbindungsfehler, der die App unter bestimmten Netzwerkbedingungen daran hinderte, Relays zu erreichen.

Unfiltered v1.0.12 fügt Hashtags und Kommentare hinzu

Unfiltered, ein Nostr-Client mit Fokus auf bildzentrierte Inhalte, lieferte v1.0.12 aus. PR #69 fügt Unterstützung für Hashtags hinzu, und PR #72 fügt die Möglichkeit hinzu, Kommentare zu Beiträgen zu schreiben und anzuzeigen. PR #71 behebt Navigationsprobleme bei Beiträgen mit mehreren Bildern.

Primal, der Android-Nostr-Client, lieferte am 7. April einen Release aus. Das Update fügt Wallet-Multi-Account-Sharing sowie ein Overflow-Menü mit Wallet-Löschung in den Dev Tools hinzu. Der Remote Signer verbindet sich nun bei Verbindungsabbrüchen automatisch neu, und auch der Wallet-Service erhielt eine eigene Auto-Reconnect-Logik. Zu den Fixes gehören, dass Poll-Zap-Stimmen nicht länger als Top Zaps erscheinen, leere Poll-Optionen keinen Absturz mehr auslösen, Wallet-Guthaben verborgen wird, wenn keine Wallet existiert, und WalletException-Typen in NWC-Antworten auf Fehlercodes abgebildet werden.

Titan v0.1.0 startet nativen nsite://-Browser mit Bitcoin-Namensregistrierung

Titan, ein nativer Desktop-Browser für das Nostr-Web, lieferte v0.1.0 am 7. April aus. Titan löst nsite://-URLs auf, indem es menschenlesbare, auf Bitcoin registrierte Namen nachschlägt, Nostr-Relays nach den Content-Events der Website abfragt und Seiten rendert, die von Blossom-Servern geladen werden. Das Ergebnis ist ein Browser-Erlebnis ohne DNS, ohne TLS-Zertifikate und ohne Hosting-Anbieter. Namen werden über eine Weboberfläche registriert, die mit Bitcoin-Transaktionen verknüpft ist. Der erste Release kommt als macOS-.dmg für ARM, mit Rosetta-2-Unterstützung für Intel, und enthält Unterstützung für Nix-Entwicklungsumgebungen.

Bikel v1.5.0 liefert nativen Foreground Service für de-Googled Phones aus

Bikel, ein dezentraler Fahrrad-Tracker, der Fahrten über Nostr in öffentliche Infrastrukturdaten verwandelt, lieferte v1.5.0 am 4. April aus. Der Release migriert von dem von GMS abhängigen Expo TaskManager zu einem benutzerdefinierten nativen Foreground Service und sorgt damit für zuverlässiges Ride-Tracking im Hintergrund auf LineageOS, GrapheneOS und anderen de-Googled-Android-Varianten. Der Bikel Bot erhielt eine Dual-Pocket-Architektur mit autonomer eCash-Einsammlung via Cashu nutzaps. v1.4.3 und v1.4.2 beheben die Synchronisierung des Hintergrund-Trackings für nicht standardisierte Android-Umgebungen, und die App fügt Schalter für OSM-Fahrradständer-Kartenpunkte hinzu.

Sprout fügt NIP-01-, NIP-23- und NIP-33-Unterstützung hinzu

Sprout, eine Kommunikationsplattform von Block mit eingebautem Nostr-relay, lieferte desktop/v0.1.0-rc7 am 6. April aus. Diese Woche fügte das Team Unterstützung für NIP-23 (Long-form Content) Artikel mit kind 30023, NIP-33 parametrisierbare ersetzbare Events mit d-Tag-basierter Ersetzung sowie NIP-01/NIP-02 Textnotizen mit kind 1 und Follow-Listen mit kind 3 hinzu. Der Release fügt außerdem ein adaptives IDE-Theme-System mit 54 Themes, UX-Politur für Workflow- und Agent-Run-Historie sowie eine Bereinigung der Mitglieder-Sidebar hinzu.

mesh-llm v0.56.0 liefert verteiltes Config-Protokoll aus

mesh-llm, ein verteiltes LLM-Inferenzsystem, das Nostr-Schlüsselpaare für Node-Identität nutzt, lieferte v0.56.0 am 7. April aus. Der Release fügt ein verteiltes Config-Protokoll mit Ownership-Semantik, asymmetrische KV-Cache-Quantisierung mit Q8_0-Keys und Q4-Werten zur Reduzierung des Speicherverbrauchs, OS-Keychain-Speicherung für Identity-Keystores, flüssiges Chat-Streaming mit Message-Queueing sowie Fixes für Fullscreen-Layout und KV-Cache-Splitting mit Flash Attention hinzu.

Nostr VPN liefert exit node-Support und Umbrel-Paketierung aus

Nostr VPN, ein Peer-to-Peer-VPN, das Nostr-Relays für Signalisierung und WireGuard für verschlüsselte Tunnel nutzt, lieferte diese Woche sechs Releases von v0.3.0 bis v0.3.6 aus. Der v0.3.x-Zyklus fügt exit node-Support auf Windows und macOS hinzu, sodass Peers Internetverkehr durch andere Nodes im Netzwerk leiten können. Invite- und Alias-Propagation synchronisieren nun über Nostr, sodass Nutzer Netzwerkzugang teilen können, ohne sich außerhalb des Protokolls abzustimmen. Die Releases fügen Umbrel-Paketierung für Self-Hosting-Deployments, NAT-Punch-Through mit gemerkten öffentlichen Endpunkten, automatische Bereinigung veralteter exit nodes und eine veröffentlichte Protokollspezifikation hinzu. Das Projekt stabilisierte außerdem die Routenbehandlung auf macOS mit selbstheilenden Default Routes und Underlay-Reparatur und fügte einen Android-Build via Tauri hinzu. Builds sind für macOS, Apple Silicon und Intel, Linux, AppImage und .deb, Windows und Android verfügbar.

Nymchat nimmt Marmot zurück und liefert erweiterte NIP-17-Gruppenchats aus

Nymchat, der MLS-fähige Chat-Client, lieferte 14 Releases von v3.56.261 bis v3.58.274 aus. Die bedeutendste Änderung ist ein Protokollwechsel: v3.57.261 fügte Marmot-MLS-Gruppenchats hinzu, aber v3.58.268 kehrte zu NIP-17 zurück, weil die Multi-Device-Unterstützung von Marmot noch nicht fertig ist, was Probleme bei der Synchronisierung des Gruppenchatzustands über Geräte hinweg verursachte. v3.58.271 führt erweiterte NIP-17-Gruppenchats mit rotierenden ephemeral keys für alle Nachrichten ein, die Timing- und Korrelationsangriffe verhindern sollen. Die Woche brachte außerdem ein Friends-System mit granularer Kontrolle über Einstellungen (v3.58.262), MLS-Gruppenchat-Nachrichtensynchronisierung in verschlüsselten App-Einstellungen und mehrere Fixes für Relay-Konnektivität.

nak v0.19.5 fügt Blossom-Multi-Server und Outbox-Publishing hinzu

nak, fiatjafs Kommandozeilen-Nostr-Toolkit, lieferte v0.19.5 aus. Der blossom-Befehl akzeptiert nun mehrere --server-Flags, um in einem Aufruf auf mehrere Blossom-Server hochzuladen. Ein neuer key-Befehl erweitert partielle Schlüssel durch Linkspadding mit Nullen. Der event-Befehl erhält ein --outbox-Flag zum Veröffentlichen von Events über das Outbox-Modell, und fetch beendet sich nun mit einem Fehlercode, wenn kein Event zurückgegeben wird.

In Entwicklung

White Noise fügt thumbhash-Vorschauen und Push-Registration-Bridge hinzu

White Noise, der private Messenger auf Basis des Marmot-Protokolls, mergte fünf PRs. PR #549 ersetzt blurhash-Bildvorschauen durch thumbhash, einen neueren Algorithmus, der schärfere Platzhalterbilder mit kleinerer Payload-Größe erzeugt, typischerweise unter 30 Byte statt blurhashs etwa 50 bis 100 Byte, und dabei Seitenverhältnis und Farbverteilung des Originalbilds bewahrt. Blurhash bleibt als Fallback für ältere Inhalte erhalten. PR #548 aktualisiert whitenoise-rs und fügt die MIP-05 Push-Registration-Bridge hinzu, die die Push-Benachrichtigungsspezifikation der letzten Woche mit dem Client verbindet. PR #493 fügt cursor-basierte Pagination für Chat-Nachrichten hinzu und ersetzt die bisherige Ladestrategie durch einen scrollgesteuerten Ansatz.

Route96 fügt dynamische Label-Konfiguration und Zero-Egress-Bereinigung hinzu

Route96, der Blossom-Medienserver von v0l, mergte drei PRs. PR #80 fügt dynamische Konfiguration des Label-Modells über die Admin-API hinzu, sodass Betreiber Content-Klassifizierungsmodelle ohne Neustart des Servers austauschen können. PR #82 fügt Felder zur Label-Konfiguration der Admin-UI hinzu. PR #79 fügt eine Zero-Egress-Dateibereinigungsrichtlinie hinzu, die Dateien, die nie heruntergeladen wurden, automatisch entfernt und so die Speicherkosten für Betreiber senkt.

Snort liefert Sicherheitshärtung und DVM-Zahlungsrechnungen aus

Snort, der Web-Client, lieferte diese Woche zwei Releases zusammen mit einem umfassenden Sicherheitsaudit aus. Zu den Fixes gehören Schnorr-Signaturprüfung, Schutz vor Relay-Message-Forgery in NIP-46, also vor Angriffen, bei denen kompromittierte Relays Signing-Anfragen einschleusen könnten, Verbesserungen bei der PIN-Verschlüsselung und die Entfernung des Vertrauens in NIP-26-Delegation. Performance-Gewinne kommen durch gebündelte Schnorr-Verifikation in WASM, lazy-geladene Routen, vorkompilierte Übersetzungen und den Wegfall doppelter Verifikation pro Event. PR #618 fügt die Anzeige von zahlungspflichtigen Rechnungen für NIP-90 (Data Vending Machine) kind 7000 hinzu, sodass Snort die Lightning-Rechnung direkt im Feed rendert, wenn eine DVM eine Zahlungsanforderung zurückgibt.

Damus verbessert LMDB-Kompaktierung

Damus, der iOS-Client, mergte PR #3719, das automatische LMDB-Kompaktierung nach Zeitplan hinzufügt und damit verhindert, dass die lokale Datenbank unbegrenzt wächst. PR #3663 verbessert die BlurOverlayView, sodass sie schützend statt kaputt wirkt.

Captain’s Log fügt Tag-Indizierung und Notiz-Sync hinzu

Captain’s Log (Comet), das Nostr-native Langform-Schreibwerkzeug von Nodetec, mergte diese Woche vier PRs. PR #156 fügt Tag-Indizierung und Sync-Unterstützung über Notizen hinweg hinzu, PR #157 refaktoriert Notiz-Sync und Tag-Verarbeitung, und PR #159 behebt den Sync gelöschter Notizen, damit entfernte Notizen auf allen Geräten gelöscht bleiben.

Relatr v0.2.x gestaltet das Plugin-System mit Nostr-nativem Validator-Marktplatz neu

Relatr, eine Web of Trust-Scoring-Engine, die Vertrauensrankings aus Distanz im sozialen Graphen und konfigurierbaren Validatoren berechnet, lieferte die v0.2.x-Familie mit einer vollständigen Neugestaltung des Plugin-Systems aus. Validatoren werden nun in Elo geschrieben, einer portablen funktionalen Ausdruckssprache, die geforkt wurde, um mehrstufige, host-orchestrierte Fähigkeiten zu unterstützen, darunter Nostr-Abfragen, Social-Graph-Lookups und NIP-05-Auflösung. Plugins werden als Nostr-Events mit kind 765 veröffentlicht und machen die Distribution damit nativ für das Relay-Netzwerk. Ein neuer Plugin-Marktplatz erlaubt es Betreibern, Validatoren im Browser zu entdecken, zu installieren und zu gewichten, ergänzt durch eine CLI namens relo für lokales Authoring und Publishing. Die Architektur ist sandboxed: Plugins können nur Fähigkeiten aufrufen, die der Host ausdrücklich bereitstellt, sodass ein bösartiger Validator seinen definierten Scope nicht verlassen kann. Relatr-Instanzen lassen sich nun von der Website aus verwalten, mit voller Transparenz darüber, welche Plugins den Scoring-Algorithmus zusammensetzen und welches einzelne Gewicht sie haben.

Shopstr, der Nostr-native Marktplatz für Kauf und Verkauf mit Bitcoin, pushte diese Woche 158 Commits über seine Haupt-App und das Begleitprojekt Milk Market. Zu den Fixes gehören Verbesserungen am Community-Layout auf Mobilgeräten, das Schließen von Menüs bei Navigation und automatisches Schließen von Dropdowns. Geschützte Routen lassen sich nicht mehr per direkter URL ohne Anmeldung aufrufen, und die Slug-Matching-Logik behandelt mehrere exakte Treffer nun korrekt.

Pollerama fügt Benachrichtigungen, Filmsuche und Rating-UI hinzu

Pollerama, eine auf Nostr basierende Umfrage-, Survey- und Social-Rating-App, fügte Thread-Benachrichtigungen, eine Filmsuche und eine überarbeitete Rating-UI hinzu. Der Release behebt außerdem Ladeprobleme im Feed und hebt Abhängigkeitsversionen an.

Purser baut Nostr-nativen Zahlungs-Daemon mit Marmot-Verschlüsselung

Purser, ein Nostr-nativer Zahlungs-Daemon als Ersatz für Zaprite, mergte diese Woche neun PRs zum Ausbau seiner Kernarchitektur. Das Projekt nutzt Marmot MLS über MDK für verschlüsselte Händler-Kunden-Kommunikation, mit Strike und Square als Zahlungsanbietern. Diese Woche landeten Konfigurations- und Katalogladen, Message-Schema-Validierung, die MDK-Kommunikationsschicht, Implementierungen für Strike und Square, eine Polling-Engine, Anti-Spam-Rate-Limiting, Persistenz ausstehender Zahlungen und die Order-Processing-Pipeline. Alle 99 Tests verwenden nun echte mdk-core-MLS-Operationen, nachdem das Team Mock-MLS zugunsten realer Verschlüsselung im lokalen Modus entfernt hat.

Vector refaktoriert DM-Anhänge und fügt Profilbearbeitung hinzu

Vector, der mit Tauri gebaute datenschutzorientierte Nostr-Messenger, mergte PR #55, das das Frontend refaktoriert. Entschlüsselung und Speichern von DM-Anhängen wurden in die vector-core-Bibliothek verschoben, und die App unterstützt nun Profilbearbeitung. Das Upload-Cancel-Flag ist jetzt korrekt durch TauriSendCallback verdrahtet, und ungenutzte Callbacks für Attachment-Vorschauen wurden entfernt.

Protokoll- und Spezifikationsarbeit

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

Gemergt:

NIP-58 (Badges): Profile Badges wechseln zu kind 10008, Badge Sets zu kind 30008 (PR #2276): Migriert Profile Badges von kind 30008 zu kind 10008, also einem ersetzbaren Event, eines pro pubkey, und führt kind 30008 für Badge Sets ein. Zuvor nutzten Profile Badges denselben kind 30008 wie Badge-Definitionen und waren damit parametrisierbare ersetzbare Events mit einem d-Tag als Schlüssel. Der neue kind 10008 ist ein einfaches ersetzbares Event, eines pro pubkey, ohne benötigten d-Tag. Clients fragen damit ein einzelnes ersetzbares Event pro Nutzer ab, statt parametrisierbare ersetzbare Events zu scannen. Amethyst v1.07.3 liefert diese Migration bereits aus.
NIP-34 (Git Stuff): Git-bezogene Follow-Listen hinzufügen (PR #2130): Fügt Konventionen für Follow-Listen zur Repository- und Issue-Verfolgung in NIP-34 hinzu. Nutzer veröffentlichen kind-30000-Follow-Sets mit d-Tags wie git-repos oder git-issues, die a-Tag-Referenzen auf Repositories enthalten, kind 30617, die sie verfolgen möchten. Clients können diese Follow-Sets abonnieren, um Repository-Aktivität im Feed eines Nutzers anzuzeigen, ähnlich wie kind-3-Kontaktlisten für pubkeys funktionieren.

Offene PRs und Diskussionen:

NIP-AC: P2P Voice and Video Calls over WebRTC (PR #2301): Erweitert das ursprüngliche NIP-100, umgesetzt von 0xChat, um drei Änderungen: Migration auf NIP-44-Verschlüsselung, verpackt in NIP-59 gift wraps, um Metadatenlecks zu eliminieren, einen spezifizierten WebRTC-Workflow für Sprach- und Videoanrufe, also Offer, Answer und ICE Candidates, und ein Mesh-Modell für Gruppenanrufe, bei dem jeder Peer eine direkte WebRTC-Verbindung zu jedem anderen Peer aufbaut. Die Spezifikation ist nicht abwärtskompatibel zu NIP-100. Amethyst baut bereits dagegen, mit einer Testsuite für die Call-State-Machine (PR #2143) und dem Handling veralteter Call Offers (PR #2164), die diese Woche landeten.
NIP-340 (FROST Quorum) (PR #2299): Schlägt Konventionen für Threshold-Signing mit FROST (Flexible Round-Optimized Schnorr Threshold) auf Nostr vor. FROST erlaubt es einer Gruppe von Signern, gemeinsam eine Nostr-Identität zu kontrollieren, bei der beliebige t-von-n-Mitglieder Events signieren können, ohne den vollständigen privaten Schlüssel zu rekonstruieren. Das NIP definiert, wie Signing-Runden koordiniert, Key Shares verteilt und threshold-signierte Events veröffentlicht werden, aufbauend auf der Igloo-Signer-Arbeit aus dem FROSTR-Projekt.
NIP-5D (Nostr Web Applets) (PR #2303): Definiert ein postMessage-Protokoll für sandboxed Webanwendungen, sogenannte “napplets”, die in iframes laufen und mit einer hostenden Anwendung, der “shell”, kommunizieren. Die shell stellt dem napplet Nostr-Signing, Relay-Zugang und Nutzerkontext über eine strukturierte Message-API bereit, während die iframe-Sandbox direkten Zugriff auf Schlüssel verhindert. Das erweitert das Hosting-Modell für statische Websites aus NIP-5A in Richtung interaktiver Anwendungen, die Nostr-Events lesen und schreiben können. Das NIP ist in aktiver Entwicklung und hat bereits eine funktionierende Runtime-Implementierung.
NIP-5C (Scrolls) (PR #2281): Wurde gegenüber dem früheren Vorschlag NIP-A5 umbenannt. Definiert Konventionen für das Veröffentlichen und Entdecken von WebAssembly-Programmen auf Nostr. WASM-Binaries werden als Nostr-Events gespeichert, und Clients können sie in einer sandboxed Runtime herunterladen und ausführen. Eine Demo-App zeigt Scrolls, die im Browser laufen, mit Beispielprogrammen, die als Nostr-Events veröffentlicht sind und von jedem Client geladen und ausgeführt werden können.
NIP-85 (Trusted Assertions): Klarstellungen (PR #2304): Präzisiert die Spezifikationssprache rund um mehrere Schlüssel und Relays pro Service-Provider und klärt, wie Clients mit Assertions von Anbietern umgehen sollten, die über mehrere pubkeys oder Relay-Endpunkte arbeiten.
NIP-24 (Extra Metadata Fields): published_at für ersetzbare Events (PR #2300): Verallgemeinert den published_at-Tag aus NIP-23 (Long-form Content) auf alle ersetzbaren und adressierbaren Events. Der Tag dient nur der Darstellung: Wenn published_at gleich created_at ist, zeigen Clients das Event als “created” zu diesem Zeitpunkt an, und wenn sie sich unterscheiden, weil das Event aktualisiert wurde, können Clients stattdessen “updated” anzeigen. Dadurch können Profile mit kind 0 ein “joined at”-Datum anzeigen, und andere ersetzbare Events behalten ihren ursprünglichen Veröffentlichungszeitpunkt über Updates hinweg. Ein komplementärer Vorschlag für NIP-51 (PR #2302) fügt denselben Tag zu Listen-Events hinzu.
NIP-59 (Gift Wrap): Ephemeral gift wrap kind (PR #2245): Fügt kind 21059 als ephemeres Gegenstück zum bestehenden gift wrap mit kind 1059 hinzu. Ephemere Events, kinds 20000 bis 29999, folgen der Semantik von NIP-01: Relays müssen sie nicht speichern und können sie nach der Zustellung verwerfen. Dadurch können Anwendungen gift-wrapped Messages senden, die nach der Zustellung von Relays verschwinden, was die Speicheranforderungen für volumenstarke Nachrichten reduziert und dabei dasselbe Drei-Schichten-Verschlüsselungsmodell wie normale NIP-17 DMs beibehält.

OpenSats kündigt sechzehnte Welle von Nostr-Grants an

OpenSats kündigte am 8. April seine sechzehnte Welle von Nostr-Grants an und finanziert damit vier Erstförderungen und eine Verlängerung. Amethyst Desktop erhält Förderung für den Contributor Robert Nagy, um auf Basis der Quartz- und Commons-Module eine eigenständige Desktop-App zu bauen, die das Feature-Set des Android-Clients auf mausgesteuerte Oberflächen mit persistenten Relay-Verbindungen bringt. Nostr Mail erhält Förderung für den Bau eines vollständigen E-Mail-Systems auf Nostr unter Verwendung von kind-1301-Events, verpackt in NIP-59 gift wraps, mit einem Flutter-Client und SMTP-Bridge-Servern für Gmail- und Outlook-Kompatibilität. Nostrord erhält Förderung für einen Kotlin-Multiplatform-Gruppenclient auf Basis von NIP-29 und Relay-basierten Gruppen, mit Discord-artigen Gruppenchats, Moderation und Threads. Nurunuru erhält Förderung für eine native iOS-Version des auf Japan fokussierten Nostr-Clients, modelliert an der vertrauten LINE-Oberfläche, mit passkey-basierter biometrischer Anmeldung für das Onboarding. HAMSTR erhielt eine Förderverlängerung, erstmals gefördert in der elften Welle.

NIP Deep Dive: NIP-17 (Private Direct Messages)

NIP-17 definiert den aktuellen Standard für private Direktnachrichten auf Nostr. Es ersetzt das ältere Schema NIP-04 (Encrypted Direct Messages), das Metadaten leckte, also Absender, Empfänger und Zeitstempel waren auf Relays sichtbar, und eine schwächere Verschlüsselungskonstruktion nutzte. NIP-17 kombiniert NIP-44 (Encrypted Payloads) für die Verschlüsselung mit NIP-59 (Gift Wrap) für den Schutz von Metadaten und schafft damit ein Dreischichtensystem, in dem Relays nicht sehen können, wer mit wem spricht.

Das Protokoll verwendet drei ineinander verschachtelte Event-Kinds. Die innerste Schicht ist die eigentliche Nachricht, ein unsigniertes Event mit kind 14:

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744108800,
 "kind": 14,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef", "wss://inbox.example.com"],
 ["subject", "Project update"]
 ],
 "content": "The new relay config is deployed. Let me know if you see any issues.",
 "sig": ""
}

Das Event mit kind 14 ist absichtlich unsigniert, also mit leerem sig. Die Spezifikation beschreibt das als Deniability, aber in der Praxis ist dieser Schutz begrenzt. Das Siegel mit kind 13, das das rumor umhüllt, ist mit dem echten Schlüssel des Absenders signiert. Ein Empfänger kann das signierte Siegel einem Dritten zeigen und damit beweisen, dass der Absender mit ihm kommuniziert hat, auch ohne den Nachrichteninhalt offenzulegen. Mit Zero-Knowledge-Proofs kann ein Empfänger sogar den exakten Nachrichteninhalt beweisen, ohne seinen eigenen privaten Schlüssel offenzulegen. Das unsignierte rumor ist wie ein unsignierter Brief in einem signierten Umschlag: Die Signatur auf dem Umschlag verbindet den Absender mit dem Inhalt. Echte Deniability würde symmetrische Authentifizierung erfordern, wie HMACs bei Signal, was mit Nostrs dezentralem Relay-Modell unvereinbar ist, weil Nachrichten selbstauthentifizierend sein müssen. Die eigentlichen Stärken von NIP-17 sind Privatsphäre bei Metadaten und Geheimhaltung des Inhalts, nicht Deniability.

Diese unsignierte Nachricht wird dann in ein Siegel mit kind 13 verpackt, das vom tatsächlichen Absender signiert und mit NIP-44 für den Empfänger verschlüsselt wird:

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744022400,
 "kind": 13,
 "tags": [],
 "content": "<nip44-encrypted kind 14 payload>",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

Das Siegel hat keine Tags, daher würde es selbst nach einer Entschlüsselung den Empfänger nicht offenlegen. Das Siegel ist mit dem echten Schlüssel des Absenders signiert, was dem Empfänger erlaubt, die Nachricht zu authentifizieren, indem er prüft, dass der pubkey des Siegels mit dem pubkey des inneren kind-14-Events übereinstimmt.

Das Siegel wird anschließend in ein gift wrap mit kind 1059 verpackt, signiert von einem zufälligen Wegwerf-Schlüssel und an den Empfänger adressiert:

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744065600,
 "kind": 1059,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef"]
 ],
 "content": "<nip44-encrypted kind 13 payload>",
 "sig": "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210"
}

Der pubkey des gift wrap ist ein zufälliger Schlüssel, der nur für diese Nachricht erzeugt wurde, und created_at wird um bis zu zwei Tage in die Vergangenheit randomisiert. Das ist die äußerste Schicht, die Relays tatsächlich sehen: eine Nachricht von einem unbekannten pubkey an den Empfänger, mit einem Zeitstempel, der nicht widerspiegelt, wann die Nachricht tatsächlich gesendet wurde. Der randomisierte Zeitstempel schützt vor nachträglicher Analyse gespeicherter Events, aber ein Angreifer, der aktiv mit Relays verbunden ist, kann weiterhin beobachten, wann das gift wrap erstmals auftaucht, daher ist diese Verteidigung auf passive Beobachter beschränkt, die Relay-Daten später abfragen. Weil der pubkey zufällig und der Zeitstempel gefälscht ist, können Relays den echten Absender nicht bestimmen. Um die Nachricht zu lesen, entschlüsselt der Empfänger das gift wrap mit seinem eigenen Schlüssel und dem zufälligen pubkey, findet darin das Siegel, entschlüsselt das Siegel mit seinem eigenen Schlüssel und dem pubkey des Absenders aus dem Siegel und findet darin die Nachricht mit kind 14.

NIP-17 bietet keine forward secrecy. Alle Nachrichten werden mit dem statischen Nostr-Schlüsselpaar verschlüsselt, über die Schlüsselableitung von NIP-44 aus den Schlüsseln von Absender und Empfänger. Wird ein privater Schlüssel kompromittiert, kann jede vergangene und zukünftige Nachricht entschlüsselt werden, die an diesen Schlüssel verschlüsselt wurde. Das ist ein bewusster Tradeoff: Weil die Verschlüsselung nur vom nsec abhängt, kann ein Nutzer, der seinen nsec sichert, seine gesamte Nachrichtenhistorie von jedem Relay wiederherstellen, das die gift wraps noch speichert. Protokolle wie MLS, wie es von Marmot genutzt wird, bieten forward secrecy durch rotierendes Schlüsselmaterial, aber um den Preis von notwendiger State-Synchronisierung und der Unmöglichkeit, historische Nachrichten nach einer Schlüsselrotation wiederherzustellen.

NIP-17 definiert außerdem kind 15 für verschlüsselte Dateinachrichten. Dieser fügt die Tags file-type, encryption-algorithm, decryption-key und decryption-nonce hinzu, damit der Empfänger eine angehängte Datei entschlüsseln kann, die vor dem Upload auf einen Blossom-Server mit AES-GCM verschlüsselt wurde. kind 10050 wird genutzt, um die bevorzugte DM-Relay-Liste des Nutzers zu veröffentlichen, damit Absender wissen, wohin sie gift wraps zustellen sollen. Die Menge aus pubkey- und p-Tags in einer Nachricht definiert einen Chatraum, und das Hinzufügen oder Entfernen eines Teilnehmers erzeugt einen neuen Raum mit sauberer Historie.

Implementierungen decken die meisten großen Clients ab. nospeak nutzt NIP-17 für sämtliche Eins-zu-eins-Nachrichten. Flotilla nutzt NIP-17 für seine Proof-of-Work-DMs. Amethyst, Primal, Nostur, Damus, noStrudel und Coracle implementieren NIP-17 alle als ihr primäres DM-Protokoll. Die Spezifikation unterstützt auch verschwindende Nachrichten durch Setzen eines expiration-Tags im gift wrap.

NIP Deep Dive: NIP-46 (Nostr Remote Signing)

NIP-46 definiert ein Protokoll, das den privaten Schlüssel des Nutzers von der Client-Anwendung trennt. Statt einen nsec in eine Web-App einzufügen, betreibt der Nutzer einen Remote Signer, auch “bunker” genannt, der den privaten Schlüssel hält und über Nostr-Relays auf Signing-Anfragen antwortet. Der Client sieht den privaten Schlüssel nie. Das reduziert die Angriffsfläche: Ein kompromittierter Client kann Signaturen anfordern, den Schlüssel selbst aber nicht extrahieren.

Das Protokoll nutzt kind 24133 sowohl für Requests als auch für Responses, verschlüsselt mit NIP-44 (Encrypted Payloads). Ein Client erzeugt für die Session ein Wegwerf-client-keypair und kommuniziert mit dem Remote Signer über NIP-44-verschlüsselte Nachrichten, die mit den pubkeys des jeweils anderen getaggt sind. Hier ist eine Signing-Anfrage von einem Client an einen Remote Signer:

{
 "id": "aa11bb22cc33dd44ee55ff6677889900aabbccdd11223344556677889900aabb",
 "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
 "created_at": 1744108800,
 "kind": 24133,
 "tags": [
 ["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]
 ],
 "content": "<nip44-encrypted JSON-RPC request>",
 "sig": "1122334455667788990011223344556677889900aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff0011223344556677"
}

Das verschlüsselte content enthält eine JSON-RPC-ähnliche Struktur:

{
 "id": "random-request-id-1",
 "method": "sign_event",
 "params": ["{\"kind\":1,\"content\":\"Hello from remote signing\",\"tags\":[],\"created_at\":1744108800}"]
}

Der Remote Signer entschlüsselt die Anfrage, legt sie dem Nutzer zur Freigabe vor, oder genehmigt sie automatisch auf Basis konfigurierter Berechtigungen, signiert das Event mit dem privaten Schlüssel des Nutzers und gibt das signierte Event in einer Response zurück:

{
 "id": "bb22cc33dd44ee55ff6677889900aabb11223344556677889900aabbccddeeff",
 "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
 "created_at": 1744108801,
 "kind": 24133,
 "tags": [
 ["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]
 ],
 "content": "<nip44-encrypted JSON-RPC response>",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Verbindungen können von beiden Seiten initiiert werden. Ein Remote Signer stellt eine bunker://-URL bereit, die seinen pubkey und Relay-Informationen enthält. Ein Client stellt eine nostrconnect://-URL mit seinem Client-pubkey, Relays und einem Secret zur Verbindungsüberprüfung bereit. Der Parameter secret verhindert Connection-Spoofing: Nur die Partei, die die URL außerhalb des Protokolls erhalten hat, kann den Handshake abschließen.

Acht Methoden sind definiert: connect zum Aufbau der Session, sign_event zum Signieren von Events, get_public_key zum Abrufen des pubkeys des Nutzers, ping für Keepalive, nip04_encrypt und nip04_decrypt für Legacy-Verschlüsselung, nip44_encrypt und nip44_decrypt für aktuelle Verschlüsselung sowie switch_relays für Relay-Management. Relay-Migration wird vom Remote Signer behandelt, der die Verbindung im Lauf der Zeit auf neue Relays verschieben kann, ohne die Session zu unterbrechen.

Clients fordern beim Verbindungsaufbau spezifische Fähigkeiten über ein Berechtigungssystem an. Ein Berechtigungsstring wie nip44_encrypt,sign_event:1,sign_event:14 fordert Zugriff auf NIP-44-Verschlüsselung und Signing-Rechte nur für Events mit kind 1 und kind 14 an. Der Remote Signer kann diese Berechtigungen akzeptieren, ablehnen oder verändern. Das bedeutet, dass ein Web-Client zum Lesen und Posten von Notizen vielleicht nur sign_event:1 erhält, während ein DM-Client zusätzlich sign_event:14 und nip44_encrypt bekommen kann.

Amber implementiert NIP-46 auf Android, und v6.0.0-pre1 dieser Woche fügt signing keys pro Verbindung hinzu, um Clients voneinander zu isolieren. nsec.app, früher Nostr Connect, bietet einen webbasierten bunker. nostr-tools enthält BunkerSigner für JavaScript-Clients, und PR #530 der letzten Woche fügte skipSwitchRelays für manuelles Relay-Management hinzu. Das Protokoll unterstützt außerdem Auth-Challenges: Wenn ein Remote Signer zusätzliche Authentifizierung benötigt, also Passwort, Biometrie oder Hardware-Token, antwortet er mit einer auth_url, die der Client in einem Browser öffnet, damit der Nutzer den Vorgang abschließen kann.

Das war’s für diese Woche. Baust du etwas oder hast Neuigkeiten zu teilen? Schreib uns eine DM auf Nostr oder finde uns auf nostrcompass.org.

Nostr Compass #16

Wed, 01 Apr 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Amethyst liefert v1.07.0 mit angepinnten Notizen, Relay-Management über NIP-86 und NIP-62 Request-to-Vanish-Unterstützung. NIP-5A (Static Websites) wird ins NIPs-Repository gemergt und definiert, wie Websites unter Nostr-Schlüsselpaaren mit Blossom-Speicher gehostet werden. Flotilla liefert v1.7.0 mit Voice Rooms, Email/Password-Login und Proof-of-Work-DMs. White Noise behebt Relay-Churn in v2026.3.23, nospeak startet sein 1.0.0 als Messenger ohne Anmeldung. Nymchat übernimmt Marmot für MLS-verschlüsselte Gruppenchats mit NIP-17-Fallback. Calendar by Form* erreicht v1.0.0 mit privaten Kalenderlisten und ICS-Import, Amber fügt Mnemonic-Recovery und NIP-42-Relay-Auth-Whitelisting hinzu, und die Marmot-Spezifikation verschiebt KeyPackages zu adressierbaren Events und verschärft das MIP-05-Push-Benachrichtigungsformat.

Neuigkeiten

Amethyst liefert angepinnte Notizen, Relay-Management und Request to Vanish

Amethyst, der Android-Client gepflegt von vitorpamplona, lieferte sechs Releases in drei Tagen, von v1.07.0 bis v1.07.5. Das Hauptfeature-Set umfasst sechs Protokolloberflächen: angepinnte Notizen, einen dedizierten Polls-Feed-Bildschirm, NIP-62 (Request to Vanish) Unterstützung für das Anfordern vollständiger Event-Löschung von Relays, NIP-86 (Relay Management API) innerhalb des Clients, NIP-66 (Relay Discovery and Liveness Monitoring) Assessments im Relay-Info-Bildschirm und NIP-43 (Relay Access Metadata and Requests) Anzeige von Mitgliedsinformationen.

NIP-86 definiert eine JSON-RPC-Schnittstelle für Relay-Betreiber, die Clients ermöglicht, administrative Befehle wie das Sperren von Pubkeys, das Erlauben von Pubkeys und das Auflisten gesperrter Nutzer über eine standardisierte API zu senden. Amethyst stellt dies nun direkt in seiner Relay-Management-UI bereit, sodass Nutzer, die ihre eigenen Relays betreiben, sie aus demselben Client verwalten können, den sie zum Posten verwenden. PR #2039 ersetzt den alten Hex-Input-Dialog für gesperrte und erlaubte Pubkeys durch einen interaktiven Nutzersuchdialog.

v1.07.2 fügte GIF-Keyboard-Uploads hinzu und behob eine Signing-Regression, bei der Amber-Ablehnungsantworten falsch gelesen wurden, weil ältere Amber-Versionen einen leeren String für das rejected-Feld zurückgaben (PR #2042). v1.07.5 behebt einen Absturz beim Bild-Upload. Die Releases v1.06.2 und v1.06.3 früher in der Woche fügten einen Poll-Typ-Selektor für Einzel- versus Mehrfachauswahl-Polls, Drag-to-Seek auf Video-Fortschrittsleisten und Verbesserungen beim anonymen Posten hinzu.

NIP-5A wird gemergt und bringt statische Websites auf Nostr

NIP-5A (Static Websites) wurde über PR #1538 gemergt und definiert, wie statische Websites unter Nostr-Schlüsselpaaren gehostet werden. Die Spezifikation verwendet zwei Event-Kinds: Kind 15128 für eine Root-Site, eine pro Pubkey, und Kind 35128 für benannte Sites, die durch einen d-Tag identifiziert werden. Jedes Manifest ordnet URL-Pfade SHA256-Hashes zu, mit optionalen server-Tags, die auf Blossom-Speicher-Hosts zeigen, auf denen die eigentlichen Dateien liegen.

Das Hosting-Modell funktioniert so: Ein Seitenautor baut eine statische Site, lädt die Dateien zu einem oder mehreren Blossom-Servern hoch und veröffentlicht dann ein signiertes Manifest-Event, das Pfade auf Content-Hashes abbildet. Ein Host-Server empfängt Web-Anfragen, löst den Pubkey des Autors aus der Subdomain auf, ruft das Manifest aus der NIP-65 Relay-Liste des Autors ab und liefert Dateien aus, indem er die passenden Blobs von Blossom herunterlädt. Die Site bleibt unter Kontrolle des Autors, weil nur dieser Schlüssel ein aktualisiertes Manifest signieren kann. Der Host-Server ist austauschbar, weil jeder Server, der NIP-5A versteht, dieselbe Site aus demselben Manifest ausliefern kann.

Die Spezifikation baut auf Infrastruktur auf, die bereits existiert. nsite, die NIP-5A-Referenz-Host-Implementierung von lez, und nsite-manager, hzrd149s Management-UI, liefen bereits, bevor das NIP gemergt wurde. Der Merge macht die Event-Kinds und URL-Auflösungsregeln offiziell und gibt zweiten und dritten Implementierungen ein stabiles Ziel.

White Noise behebt Relay-Churn und erweitert Client-Kontrollen

White Noise, der private Messenger auf Basis des Marmot-Protokolls, lieferte v2026.3.23 am 25. März. Die Hauptarbeit betrifft Relay-Stabilität. Login wartet nicht mehr darauf, dass jede Relay-List-Publikation abgeschlossen ist, weil Relay-List-Publishing nun Quorum-Logik verwendet und den Rest im Hintergrund wiederholt. Einmalige Fetches und Publishes verwenden abgegrenzte ephemere Relay-Sessions, statt im langlebigen Pool zu verbleiben, wiederhergestellte Sessions holen nach dem Start ihren Group-Refresh-Pfad wieder ein, und die App stellt nun Relay-Diagnostik und Relay-State-Inspektion über PR #495 und PR #502 bereit.

Dasselbe Release ändert auch das Verhalten von Konversationen. PR #468 fügt NIP-C7-Reply-Threading mit q-Tags und nostr:nevent-Referenzen hinzu, PR #471 und PR #512 lassen gelöschte Nachrichten als gelöschte Platzhalter sichtbar statt sie still zu entfernen, PR #478 fügt einen In-App-Bugreport-Flow mit NIP-44 (Encrypted Payloads) anonymen Berichten hinzu, und PR #486 fügt Support-Chat direkt im Client hinzu. Nutzerseitige Nachrichtenkontrollen landeten im selben Zeitfenster: PR #532 archiviert Chats, PR #541 fügt Mute und Unmute mit konfigurierbaren Dauern hinzu, und PR #535 fügt Benachrichtigungseinstellungen hinzu. PR #539 ist vorbereitende Push-Registrierungsarbeit und verdrahtet APNs-Registrierung auf iOS und Play-Services-Erkennung auf Android, damit Registrierung darauf aufbauen kann. Auf der Backend-Seite fügte das MDK (Marmot Development Kit) MIP-05-Push-Benachrichtigungsprimitiven und einen Notification-Request-Builder hinzu (PR #235, PR #238), während whitenoise-rs Persistenz für Push-Benachrichtigungsregistrierung (PR #688), Fixes für Hintergrund-Task-Abbrüche (PR #696) und Key-Package-Recovery beim Start (PR #693) hinzufügte.

Nostr VPN erreicht v0.3.0 mit Roster-Sync und Invite v2

Anschließend an die Launch-Berichterstattung der letzten Woche, nostr-vpn, das Peer-to-Peer-VPN, das Nostr-Relays zur Signalisierung und WireGuard für verschlüsselte Tunnel nutzt, setzte sein schnelles Release-Tempo fort und lieferte Releases bis v0.3.3. Der Versionssprung bringt zwei Breaking Changes: Das Invite-Format wechselt auf v2 (0.3.0 kann weiterhin v1-Invites importieren, ältere Builds können aber keine v2-Invites importieren), und admin-signierter Roster-Sync wurde dem Signalisierungsprotokoll hinzugefügt. Peers mit gemischten Versionen können sich auf der Mesh-Ebene weiterhin verbinden, aber ältere Peers nehmen nicht an der Roster-Synchronisierung teil.

Die Ergänzung des Roster-Syncs beginnt die Bewegung in Richtung eines verwalteten Netzwerks. Ein Admin-Node kann nun Mitgliedschaftsänderungen an alle Peers pushen, sodass das Hinzufügen oder Entfernen eines Geräts aus dem Mesh nicht verlangt, dass jeder Peer seine Konfiguration manuell aktualisiert. Die v0.2.x-Releases derselben Woche adressierten spezifische Deployment-Probleme: v0.2.22 bis v0.2.28 beheben Windows-Service-Management, fügen Android-Build-Skripte hinzu und verfeinern den LAN-Pairing-Flow.

nospeak startet als 1.0-Private-Messenger

nospeak, ein privater Messenger auf Nostr-Basis, lieferte seinen 1.0.0-Release am 27. März. Das Projekt umfasst Eins-zu-eins- und Gruppenkonversationen, Kontaktmanagement und eine selbst hostbare Architektur. Eins-zu-eins-Chats nutzen NIP-17 (Private Direct Messages), das NIP-59 (Gift Wrap) mit NIP-44 (Encrypted Payloads) kombiniert, um den Absender vor Relays zu verbergen. Für Medien werden Dateien client-seitig mit AES-256-GCM verschlüsselt, bevor sie zu Blossom-Servern hochgeladen werden. Der Release kommt auch als Container-Image für Self-Hosting.

Flotilla, hodlbods Discord-artiger NIP-29 (Relay-based Groups) Client rund um das Modell „Relays as groups“, lieferte v1.7.0 und v1.7.1 am 30. und 31. März. Das Hauptfeature sind Voice Rooms, beigesteuert von mplorentz. Nutzer können nun Voice Calls innerhalb von Gruppenchannels beitreten, mit einem Join-Dialog (PR #109), der ihnen erlaubt, ein Audio-Eingabegerät auszuwählen und zu entscheiden, ob sie dem Voice Call beitreten oder nur den Text-Chat sehen wollen. Der Dialog löst ein UX-Problem der vorherigen Iteration: Das Betreten eines Voice-fähigen Raums aktivierte zuvor das Mikrofon zwangsweise, selbst wenn der Nutzer nur Nachrichten lesen oder Raumeinstellungen prüfen wollte.

Dasselbe Release fügt Email-und-Passwort-Login als Alternative zu Nostr-Schlüssel-basierter Auth hinzu, Proof-of-Work auf DMs, DM-Editing, neu gestaltetes Relay-Onboarding und Einstellungen, Blossom-Support-Erkennung über supported_nips, verbesserte Benachrichtigungs-Badges, Android-Push-Benachrichtigungs-Fallback und File-Upload-Fixes auf Android. v1.7.1 folgt mit einem Fix für Pomade-Registrierungs-Fallback bei Verwendung eines Offline-Signers.

Hodlbod baut auch Caravel, einen Hosting-Manager und ein Dashboard für zooid-Relays, das diese Woche 40 Commits in der frühen Entwicklung verzeichnete.

Nymchat liefert Marmot-basierte Gruppenchats

Nymchat (auch bekannt als NYM, Nostr Ynstant Messenger), der ephemere Chat-Client mit Bitchat-Bridge, kündigte an, dass alle neuen Gruppenchats nun das Marmot-Protokoll für MLS-verschlüsselte Nachrichten verwenden. Die Integration nutzt die Kinds 443, 444 und 445 für Key Packages, Welcome Messages und Gruppennachrichten und liefert Forward Secrecy, Post-Compromise Security und null Metadaten-Leckage. Wenn ein Empfänger MLS nicht nutzen kann, fällt Nymchat auf seinen früheren NIP-17 (Private Direct Messages) Gruppenchats-Pfad zurück, der weiterhin Ende-zu-Ende verschlüsselt ist, aber nicht die Ratchet-Tree-Eigenschaften von MLS besitzt.

Die Serien v3.55 und v3.56 konzentrierten sich diese Woche auf Randfälle bei Gruppenchats: Laden auf neuen Geräten, Leave-Verhalten, Notification-Routing und Unread-Badge-Zähler. Derselbe Zyklus patchte auch eine XSS-Schwachstelle durch unescaped HTML und fügte Keyword- und Phrase-Blocking hinzu, das auch auf Nutzernamen ausgeweitet wurde. Das macht Nymchat zu einem weiteren Marmot-Client neben White Noise und OpenChat und erweitert die Menge an Apps, die MLS-verschlüsselte Gruppennachrichten über dasselbe Protokoll austauschen können.

Releases

Calendar by Form* v1.0.0

Calendar by Form*, die dezentrale Kalender-App auf Basis von NIP-52 (Calendar Events), erreichte v1.0.0 am 29. März. Der Release fügt private Kalenderlisten mit verschlüsselten Nostr-Events (Kind 32123) und NIP-44 (Encrypted Payloads) Self-Encryption hinzu, sodass Nutzer Events in privaten Sammlungen organisieren können, ohne die Gruppierung Relays preiszugeben. Derselbe Release fügt ICS-Intent-Behandlung zum Import von Kalenderdaten aus anderen Anwendungen und Invitation Requests zum Teilen von Events zwischen Nutzern hinzu.

Amber v5.0.2 bis v5.0.4

Amber, die NIP-55 (Android Signer Application) Signer-App, lieferte drei Punkt-Releases: v5.0.2, v5.0.3 und v5.0.4. Die sichtbarste Ergänzung ist Mnemonic-Recovery-Phrase-Login (PR #358), das Nutzern erlaubt, ihren Signer aus einer BIP39-Seed-Phrase wiederherzustellen, statt den rohen nsec- oder ncryptsec-String zu benötigen. PR #357 fügt eine NIP-42 Relay-Auth-Whitelist hinzu, sodass Nutzer einschränken können, welche Relays Client-Authentifizierung anfordern dürfen. PR #353 fügt Encryption-Scope-Auswahl für Decrypt-Berechtigungen hinzu, sodass Nutzer NIP-04-only- oder NIP-44-only-Decrypt-Zugriff statt einer pauschalen Berechtigung gewähren können. v5.0.4 behebt einen Bug, bei dem Ablehnung Scoped-Encrypt- und -Decrypt-Berechtigungen nicht respektierte, und verbessert die Performance beim Empfang mehrerer Bunker-Requests.

Aegis v0.4.0

Aegis, der plattformübergreifende Signer, lieferte v0.4.0 am 26. März. Der Release fügt Full- und Selective-Authorization-Modi in den Einstellungen hinzu und behebt mehrere QR-Scanning-Probleme. Folge-Commits d4f799f, 3313af9, 3b214e4 und e4f40b6 setzen dieselbe Arbeit fort mit Batch-Select-Kontrollen, wiederverwendbaren Batch-Selection-Statistiken, Set-All-Groups-Selection-APIs und Pro-Berechtigung-Nutzungsstatistiken auf der App-Permissions-Seite.

Schemata v0.2.7 bis v0.3.0

Schemata, die JSON-Schema-Definitionen zur Validierung von Nostr-Event-Kinds, lieferte vier Releases von v0.2.7 bis v0.3.0 mit 21 gemergten PRs. Der Release v0.3.0 bringt Pattern-Consistency-Fixes über Relay-URLs, Hex-IDs, MIME-Typen und BOLT-11-Strings hinweg (PR #126), zentralisierte Relay-URL-Patterns (PR #117), NIP-19 Bech32-Basistyp-Schemas (PR #118) und Validierung für Kind-777-Spell-Events (PR #125). Die Release-Pipeline veröffentlicht nun bei jedem Release eine Kind-1-Notiz auf Nostr (PR #120), sodass das Projekt sich selbst über das Protokoll ankündigt, das es validiert. Schemata unterstützt nun ein Dutzend Sprachen jenseits des kanonischen JS/TS-Pakets: Rust, Go, Python, Kotlin, Java, Swift, Dart, PHP, C#/.NET, C++, Ruby und C.

Neben Schemata veröffentlichte das Team schemata-codegen, einen experimentellen Codegenerator, der ein anderes Vorgehen für dasselbe Validierungsproblem verfolgt. Während Schematas Validator-Pakete eine JSON-Schema-Runtime-Abhängigkeit benötigen, portiert schemata-codegen Schemas direkt in typisierte native Sprachkonstrukte (typisierte Tag-Tupel, Kind-Interfaces und Runtime-Validatoren) und entfernt die Notwendigkeit einer Validator-Bibliothek zur Laufzeit. Der Vergleich codegen-vs-validators dokumentiert, wann welcher Ansatz passt.

BigBrotr v6.5.0 bis v6.5.4

BigBrotr, die Relay-Analyseplattform, lieferte fünf Releases von v6.5.0 bis v6.5.4. Der Release v6.5.0 zentralisiert Relay-URL-Validierung mit einer parse_relay_url()-Factory-Funktion und fügt URL-Längenprüfung und Pfad-Sanitization hinzu. Die Monitoring-Infrastruktur erhielt ebenfalls Fixes: Announcement-Events enthalten nun Geohash-Location-Tags (in Anlehnung an NIP-52), und Timeout-Schutz wurde zu den Geo/Net-NIP-66 Metadaten-Tests hinzugefügt, die zuvor keine Deadline hatten und unbegrenzt hängen konnten. PR #410 aktualisiert PostgreSQL von 16 auf 18, was das Async-I/O-Subsystem und verbesserten WAL-Durchsatz zur Relay-Analyse-Pipeline bringt.

Vertex-Lab-Relay fügt NIP-50-Profilsuche hinzu

Vertex Lab, das Team hinter npub.world und der Vertex Web-of-Trust-Engine, kündigte an, dass wss://relay.vertexlab.io nun NIP-50 (Search) für Profilabfragen unterstützt. NIP-50 erweitert den Standard-Nostr-REQ-Filter um ein search-Feld und erlaubt Clients, Volltextsuchanfragen an Relays zu senden, die Indizierung unterstützen. Das Hinzufügen von Profilsuche zu einem Relay, das bereits Web-of-Trust-Daten ausliefert, bedeutet, dass Clients, die mit relay.vertexlab.io verbunden sind, Nutzer per Name oder Beschreibung finden können, ohne einen separaten Suchdienst zu benötigen.

Hashtree v0.2.17 und v0.2.18 liefern WebRTC-Mesh und Iris Desktop

Hashtree, mmalmis content-addressiertes Blob-Speichersystem, das Merkle-Wurzeln auf Nostr veröffentlicht, lieferte v0.2.17 und v0.2.18 am 31. März. Die beiden Releases krönen einen 30-Commit-Sprint, der drei unterschiedliche Fähigkeiten hinzufügt. Erstens fügt das hashtree-webrtc-Crate (in v0.2.18 in hashtree-network umbenannt) WebRTC-basierten Peer-to-Peer-Blob-Transport mit einheitlicher Mesh-Signalisierung über Rust-CLI, Simulation-Harness und TypeScript-Client hinweg hinzu. Zweitens baut die Release-Pipeline nun Windows-Artefakte (CLI-Zip und Iris-Installer) und bringt plattformübergreifende Abdeckung für macOS, Linux und Windows. Drittens bündeln beide Releases Iris Desktop 0.1.0, mmalmis Nostr-Social-Client, als AppImage-, .deb- und Windows-Installer-Assets neben der Hashtree-CLI. Hashtree wurde erstmals in Newsletter #10 behandelt, als es als filesystem-basierter Blossom-kompatibler Store startete. Die WebRTC-Schicht ist der erste Schritt zu Peer-to-Peer-Content-Distribution ohne Abhängigkeit von zentralisierten Blossom-Servern.

Nostr Mail Client v0.7.0 bis v0.7.2

Nostr Mail Client, der Flutter-Mail-Client auf Basis von Nostr-Identitäten, lieferte v0.7.0, v0.7.1 und v0.7.2 in drei Tagen. Die sichtbare Produktarbeit konzentrierte sich auf Onboarding (PR #9) und Profilbearbeitung (PR #10), beides grundlegende Teile für jeden Client, der Nostr als Postfach präsentieren will. Die späteren Punkt-Releases paketierten diese Arbeit in neue Android- und Linux-Builds.

Wisp v0.14.0 bis v0.16.1

Wisp, der Android-Nostr-Client, lieferte 13 weitere Releases von v0.14.0-beta bis v0.16.3-beta. Die Arbeit diese Woche umfasst NIP-17-Rumor-JSON-Fixes (PR #385), Repost-Badges auf Galerie-Karten (PR #383), ausklappbare Reaktionsdetails (PR #382), persistente Emoji-Sets (PR #381) und Video-Autoplay-Kontrollen (PR #380). Das neueste v0.16.3-beta behebt außerdem benutzerdefinierte Emoji-Shortcodes mit Bindestrichen und fehlende Emoji-Tags.

Primal Android 3.0.17

Primal Android lieferte 3.0.17 am 24. März. PR #1000 ordnet WalletException-Typen Fehlercodes in NWC-Antworten zu und gibt NIP-47 Clients strukturierte Fehlerinformationen statt generischer Fehler. PR #995 behebt, dass Poll-Zap-Stimmen als Top Zaps erscheinen, und PR #998 blendet Wallet-Guthaben und Aktionsbuttons aus, wenn keine Wallet konfiguriert ist.

OpenChat v0.2.4 bis v0.3.0

OpenChat, der Avalonia-basierte Chat-Client auf dem Marmot-Stack, lieferte sechs Releases von v0.2.4 bis v0.3.0 in vier Tagen. Das Commit-Log erzählt die Geschichte eines Clients, der die Lücken zwischen „Marmot funktioniert“ und „jemand kann das tatsächlich täglich nutzen“ schließt. NIP-42 Relay-Authentifizierung landete, gefolgt von einer Relay-Picker-UI mit Duplicate-Event-Filtering. Voice Messages erhielten Pause, Resume, Seek und Zeitanzeige. Der Signer-Pfad wurde gehärtet: Amber-Verbindungen wurden mit einem aktualisierten NIP-46 URI-Format behoben, der WebSocket reconnectet nun automatisch vor dem Senden von Requests, und doppelte Amber-Requests werden jetzt durch Prüfung auf replizierte Antworten abgefangen. Auf der Speicherseite erhielten Linux und macOS AES-256-GCM Secure Storage mit file-backed keys, und das Abrufen von User-Metadaten nutzt nun NIP-65 Relay-Discovery und cached Ergebnisse in einer lokalen Datenbank.

Igloo Signer 1.1

Igloo, der iOS-FROST Threshold-Signer des FROSTR-Projekts, lieferte v1.1 am 28. März. FROST (Flexible Round-Optimized Schnorr Threshold) Signaturen erlauben einer Gruppe von Signern, gemeinsam ein Nostr-Schlüsselpaar zu kontrollieren, wobei beliebige t-von-n-Teilnehmer ein Event signieren können, ohne dass eine einzelne Partei den vollständigen privaten Schlüssel hält. Igloo ist eine der ersten mobilen Implementierungen dieses Ansatzes für Nostr.

nak v0.19.3 und v0.19.4

nak, fiatjafs Kommandozeilen-Nostr-Toolkit, lieferte v0.19.3 und v0.19.4 am 26. und 30. März. Beide Releases beheben Panic-Zustände: PR #118 ersetzt strings.Split durch strings.Cut, um einen potenziellen Out-of-Bounds-Zugriff zu verhindern, und PR #119 verhindert dieselbe Klasse von Panic bei der Curl-Flag-Parsing-Logik.

Flora v0.3.0

Flora, eine Chrome-Erweiterung für dezentrale Bildschirmaufnahme und -teilung auf Nostr, lieferte v0.3.0. Der Release fügt private verschlüsselte Video-Freigabe mit öffentlichen, ungelisteten und privaten Modi hinzu. Private Aufnahmen werden mit AES-256-GCM verschlüsselt und via NIP-17 (Private Direct Messages) an Empfänger ausgeliefert, sodass die Aufnahme niemals im Klartext einen Server berührt.

YakiHonne Mobile 2.0.3

YakiHonne, der mobile Nostr-Client, lieferte 2.0.3 mit Relay-Reviews und Join-Requests, erweiterten verschachtelten Antworten, Auto-Übersetzung für Notizen und NWC-Multi-Relay-Unterstützung.

Projekt-Updates

Zap Cooking fügt Zap-Polls und Branta-Zahlungsverifizierung hinzu

Zap Cooking, die Rezept- und Content-Plattform, mergte diese Woche 11 PRs mit Fokus auf interaktive Inhalte und Zahlungsflüsse. PR #277 fügt Zap-Polls (Kind 6969) hinzu, bei denen Nutzer durch das Senden von sats abstimmen und Wählerlisten mit Profilbildern sehen können. PR #274 gestaltet die Poll-UX neu, sodass die Abstimmungsoberfläche natürlicher im Feed sitzt.

PR #276 fügt kamera-basiertes QR-Scanning zum Send-Payment-Flow hinzu und integriert Branta, einen Verifizierungsdienst, der prüft, ob ein Zahlungsziel legitim ist, bevor gesendet wird. Branta prüft Zahlungsziele vor dem Senden auf Phishing, Address Swaps und Man-in-the-Middle-Abfangen. In Zap Cookings Implementierung erscheinen ein Branta-verifizierter Plattformname und ein Logo direkt im Zahlungsfluss, und Branta-fähige QR-Codes können branta_id- und branta_secret-Parameter tragen, sodass die Wallet das Ziel direkt aus dem gescannten Code verifizieren kann.

diVine legt die Grundlage für einheitliche Suche und härtet Video-Auslieferung

diVine, der Kurzform-Video-Client, verbrachte die Woche damit, Suche, Feed-Navigation, Playback-Recovery und Upload-Verhalten zu verschärfen. PR #2540 legt die Grundlage für einen einheitlichen Suchbildschirm mit gruppierten Abschnitten für Videos, People und Tags. PR #2623 härtet Pagination über Profil-Feeds, Inbox, Benachrichtigungen, Discover-Listen, klassische Vines, Suche und die composable Grid-Feeds, indem sie auf einen gemeinsamen Pagination-Controller verschoben werden.

Auch die Video-Auslieferung erhielt mehrere konkrete Fixes. PR #2643 wiederholt Divine-gehostete Derivatquellen der Reihe nach und fällt auf den rohen Blob zurück, bevor ein Playback-Fehler angezeigt wird, sodass transiente Fehler an einer Quelle die Wiedergabe nicht sofort beenden. PR #2634 hält resumable Uploads auf dem Divine-eigenen Pfad, wenn Capability-Probing transient fehlschlägt, und reduziert dadurch defekte Uploads durch kurze Netzwerkfehler. PR #2637 ändert außerdem das Sensitive-Content-Gate, sodass Videos nur bei tatsächlichen Warning-Labels hart blockiert werden, nicht bloß bei vom Creator gelieferten Content-Warning-Labels.

Shopstr fügt benutzerdefinierte Storefronts hinzu und Milk Market liefert weiter Marktplatz-Arbeit aus

Shopstr, der Nostr-basierte Marktplatz, mergte PR #245 und fügt benutzerdefinierte Storefronts hinzu. Das gibt Verkäufern eine deutlichere Home-Oberfläche, statt jedes Listing in dieselbe generische Darstellung zu zwingen.

Milk Market, ein dedizierter Marktplatz für Milch, setzte die Arbeit mit Storefront-Optimierungen (PR #18), Account-Recovery (PR #17), Beef-Splits (PR #15) und MCP-Tool-Typing-Fixes (PR #16) fort.

Notedeck fügt Soundeffekte hinzu und erweitert seinen Updater-Pfad in Richtung Android

Notedeck, der Desktop-Client des Damus-Teams, mergte PR #1412, die ein Soundeffekt-Subsystem mit UI-Interaktionsgeräuschen via rodio hinzufügt, und PR #1399 mit Agentium-Updates einschließlich eines CLI-Title-Flags und einklappbarer Session-Ordner. Ein offener PR #1417 schlägt APK-Self-Update via Nostr/Zapstore auf Android vor und baut auf Notedecks Nostr-nativer Updater-Arbeit aus Newsletter #14 auf.

Nostria fügt Repost-Relay-Hints und NIP-98-Ausrichtung hinzu

Nostria mergte PR #583 und fügt NIP-18 (Reposts) Relay-Hints zu Repost-e-Tags für Kind-6- und Kind-16-Events hinzu, PR #582 richtet Brainstorm-HTTP-Auth (Kind 27235) an den von NIP-98 (HTTP Auth) geforderten Tags aus, und PR #576 fügt Schemata-Schema-Validation-Tests hinzu. Die NIP-98-Änderung bedeutet, dass Nostria sich gegenüber externen Diensten mit demselben HTTP-Auth-Format authentifizieren kann, das andere Clients verwenden.

Nostr-Doc fügt Desktop-Paketierung und Offline-First-Arbeit hinzu

Nostr-Doc, der kollaborative Editor von Form*, hatte eine arbeitsreiche Woche mit Paketierung und Editor-Arbeit. Commit fcdc00a fügt eine Desktop-App hinzu, Commit 3977a8e startet Native-App-Arbeit, und Commit 413a030 drängt die App in Richtung Offline-First-Verhalten. Auf der Editor-Seite fügt Commit 1855ce8 Ctrl+S-Speichern, Save-Warnungen, Link-Preview-Fixes und korrigiertes Strikethrough-Rendering hinzu.

rust-nostr optimiert NIP-21-Parsing und fügt Relay-seitige NIP-62-Unterstützung hinzu

rust-nostr mergte acht PRs. Der bemerkenswerteste ist PR #1308, der NIP-21 URI-Parsing in PublicKey::parse optimiert, indem es an die Performance des Standard-Bech32-Parsings angeglichen wird. Zuvor brauchten NIP-21-URIs ungefähr doppelt so lange zum Parsen wie rohe Bech32-Schlüssel. Das Projekt hat außerdem vier offene PRs, die Relay-spezifische NIP-62 (Request to Vanish) Unterstützung über die Memory-, LMDB-, SQLite- und Datenbank-Test-Backends hinzufügen (PR #1315, PR #1316, PR #1317, PR #1318).

nostr-tools fügt Bunker-Relay-Kontrolle hinzu und behebt NIP-47-Multi-Relay-Parsing

nostr-tools mergte PR #530 und fügt skipSwitchRelays zu BunkerSignerParams für manuelles Relay-Management hinzu, und PR #529 behebt NIP-47 (Nostr Wallet Connect) Connection-String-Parsing, um mehrere Relays zu unterstützen, wie es die Spezifikation erlaubt.

Nostrability integriert Sherlock-Audit-Daten und veröffentlicht Schemata-Überblick

Nostrability, der Interoperability-Tracker für Nostr-Clients, mergte 14 PRs. PR #306 integriert Sherlock-Scan-Statistiken in das Dashboard. Sherlock ist Nostrabilitys automatisiertes Audit-Tool, das sich mit Nostr-Clients verbindet, die von ihnen veröffentlichten Events erfasst und jedes Event gegen die Schemata-JSON-Schema-Definitionen validiert, um Spec-Verstöße zu erkennen. Das Dashboard zeigt nun schema fail rates pro Client (PR #315), sodass Entwickler sehen können, bei welchen Event-Kinds ihr Client Fehler macht. PR #323 überarbeitet den Nostr-Publish-Workflow, sodass Release-Ankündigungen als separater Job laufen, der nicht durch frühere CI-Schritte abgebrochen werden kann.

elsat veröffentlichte außerdem am 30. März Schemata for nostr devs, das beschreibt, wie schemata, schemata-codegen und Sherlock zusammenpassen, und aktuelle Abdeckungszahlen nennt: 179 Event-Kind-Schemas über 65 NIPs, 154 Tag-Schemas, 13 Protokollnachrichten und 310 Beispiel-Events.

Nalgorithm fügt Digest-Generierung und lokales Score-Caching hinzu

Nalgorithm, ein neues relevance-geranktes Nostr-Feed-Projekt, startete diese Woche die öffentliche Entwicklung. Commit cf6c501 legt die initiale Web-App an, die Posts von Follows lädt und sie gegen einen nutzerdefinierten Präferenz-Prompt bewertet. Commit 8e931b6 fügt ein CLI-Digest-Tool hinzu, das Top-gerankte Posts in eine gesprochene Zusammenfassung verwandelt, während Commit 4cb9c63 file-basiertes Score-Caching und inkrementelle Learned-Prompt-Evolution aus jüngsten Likes hinzufügt. Commit c2edfb8 stoppt außerdem das Caching von Fallback-Scores aus fehlgeschlagenen Batches, sodass ein transienter Scoring-Fehler nicht dauerhaft das Ranking eines Posts abflacht.

TENEX fügt RAG-Vector-Store und gezielten MCP-Start hinzu

TENEX, das Nostr-native Agent-Framework, das AI-Agenten über Telegram mit Nostr-Channels verbindet, mergte diese Woche sieben PRs. PR #101 fügt eine austauschbare Vector-Store-Abstraktion mit SQLite-vec-, LanceDB- und Qdrant-Backends hinzu und gibt Agenten Retrieval-Augmented Generation, ohne auf eine einzelne Vector-Datenbank festgelegt zu sein. PR #102 macht den MCP-Start gezielt: Es werden nur die MCP-Server gestartet, deren Tools ein Agent tatsächlich nutzt, statt alle Server beim ersten Lauf eager zu starten. PR #100 fügt ein send_message-Tool hinzu, sodass Agenten mit Telegram-Channel-Bindings Nachrichten proaktiv pushen können, statt nur auf eingehende zu antworten. PR #106 vermeidet einen Subprozess-Spawn, der eine 9GB-Bun/JSC-Pre-Allocation von Speicher auslöste, indem .git/HEAD direkt gelesen wird, statt git branch auszuführen.

Dart NDK verschiebt Amber-Signer und fügt Alby Go 1-Click hinzu

Dart NDK, das Flutter Nostr Development Kit, lieferte 11 gemergte PRs. PR #525 verschiebt Amber-Signer-Unterstützung in das ndk_flutter-Paket, und PR #552 fügt Alby-Go-One-Click-Wallet-Verbindung zur Sample-App hinzu. PR #502 fügt ein install.sh-Skript für die CLI hinzu, und PR #523 entfernt die Rust-Verifier-Abhängigkeit zugunsten nativer Asset-Behandlung.

Protokoll- und Spezifikationsarbeit

Marmot verschiebt KeyPackages zu adressierbaren Events und verschärft Push-Benachrichtigungen

Die Marmot-Spezifikation mergte vier PRs, die ändern, wie das Protokoll Schlüsselmaterial und Gruppenmitgliedschaft handhabt. PR #54 migriert KeyPackage-Events von regulärem kind:443 zu adressierbarem kind:30443 mit einem d-Tag und eliminiert damit die Notwendigkeit von NIP-09 Event-Löschung während der Schlüsselrotation. Addressable Events überschreiben sich an Ort und Stelle, wodurch Rotation in sich geschlossen wird. PR #57 erlaubt Nicht-Admin-Nutzern, SelfRemove-Proposals (freiwilliger Gruppenaustritt) zu committen, und PR #62 verlangt von Admins, vor der Nutzung von SelfRemove ihren Admin-Status aufzugeben, um zu verhindern, dass ein Admin verschwindet, während er noch erhöhte Rechte hält.

PR #61 verschärft das MIP-05 Push-Benachrichtigungsformat, indem Single-Blob-Base64-Kodierung, Versionierung, Token-Wire-Format und X-only-Key-Verwendung explizit gemacht werden. Der Effekt ist eine definierte Wire-Repräsentation für Token-Blobs und X-only-Keys über Spezifikation, Client-Bibliotheken und App-Backends hinweg. Die Implementierung dieser Spec-Änderungen landete diese Woche im White-Noise-Stack und wird im White Noise v2026.3.23-Abschnitt oben behandelt.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

Gemergt:

NIP-5A: Static Websites (PR #1538): Definiert Kind 15128 (Root Site) und Kind 35128 (Named Site) Manifest-Events zum Hosting statischer Websites unter Nostr-Schlüsselpaaren mit Blossom-Speicher. Siehe den Deep Dive unten.
NIP-30 (Custom Emoji): Bindestriche in Shortcodes erlauben (PR #2297): Aktualisiert die Shortcode-Beschreibung, um Bindestriche einzuschließen. Bindestrichhaltige Shortcodes werden in der Praxis seit Einführung des NIPs verwendet, daher dokumentiert die Spezifikation nun die aktuelle Nutzung.

Offene PRs und Diskussionen:

NIP-C1: Agent-TUI-Messages (PR #2295): Schlägt ein strukturiertes Nachrichtenformat vor, mit dem Agenten interaktive UI-Elemente über verschlüsselte DMs senden können, einschließlich typisierter text-, buttons-, card- und table-Payloads. Der Entwurf hält alles innerhalb bestehender NIP-17 und NIP-04 Direktnachrichten-Inhalte als JSON. Er definiert keinen neuen Event-Kind und verwendet ein einfaches Callback-String-Format für Button-Antworten.
NIP-95: Hybrid Peer-to-Peer Relay Protocol (PR #2293): Schlägt ein hybrides Relay-Modell vor, bei dem Relays autoritativ bleiben, aber auch Peer-to-Peer-Verteilung jüngerer Events über WebRTC koordinieren können. Der Entwurf führt Relay-Messages wie PEER_REGISTER, PEER_REQUEST und PEER_OFFER ein, mit stabilen Clients als Super Peers und dem Relay als Seed Node und Fallback.
NIP-B9: Zap-Poll-Events (PR #2284): Öffnet die alte NIP-69-Zap-Poll-Idee erneut, jetzt da NIP-88 (Polls) freie Umfragen abdeckt. Der Entwurf nutzt Kind 6969 Poll-Definitionen und Kind 9734 Zaps als Stimmen und macht daraus ein bezahltes Poll-System mit ökonomischer Sybil-Resistenz. Es ergänzt freie One-Key-One-Vote-Polls.
NIP-AD: Super Zap (PR #2289): Schlägt eine Konvention vor, bei der Zaps, die an den Pubkey eines Relays oder Clients gesendet werden, als spezialisierte Werbenotizen angezeigt werden, wodurch Zap-Quittungen faktisch zu einer Anzeigenfläche werden. Relay-Betreiber und Clients würden Profile mit lud16 veröffentlichen, diese Quittungen abrufen, eingebettete Inhalte aus Zap-Beschreibungen extrahieren und optional Minimum-sats-Schwellen setzen, um Spam zu unterdrücken.
NIP-XX: Agent Reputation Attestations (PR #2285): Schlägt Kind 30085 als parametrisierbares ersetzbares Event für strukturierte Reputations-Assertions über Nostr-Agenten vor. Der Entwurf vermeidet einen einzelnen globalen Score, indem Reputation beobachterabhängig gemacht wird, fügt zeitlichen Decay hinzu, damit alte Assertions verblassen, unterstützt negative Bewertungen mit Evidenzanforderungen und skizziert sowohl einfaches gewichtetes Scoring als auch Graph-Diversity-Scoring für bessere Sybil-Resistenz.
NIP-XX: Paid API Service Announcements (PR #2291): Schlägt Kind-31402-Addressable-Events zum Bewerben bezahlter HTTP-APIs vor, wobei Nostr Discovery und HTTP-402-Handhabung die Zahlung übernimmt. Der Entwurf ist tags-first, sodass Relays nach Zahlungsmethoden, Preisen und Fähigkeiten filtern können, ohne JSON-Inhalt zu parsen, und erlaubt optionale Request- und Response-Schemas, sodass Clients oder Agenten Aufrufe automatisch generieren können.
NIP-XX: Key Derivation from LNURL-auth via SplitSig (PR #2294): Schlägt vor, ein Nostr-Schlüsselpaar aus einer LNURL-auth-ECDSA-Signatur kombiniert mit einer client-seitigen zufälligen Nonce abzuleiten. Die Ableitungsformel ist nsec = SHA256(ecdsa_signature || nonce). Der Server sieht die ECDSA-Signatur (inhärent im LNURL-auth-Handshake), aber niemals die Nonce, und der Browser generiert die Nonce, kontrolliert aber nicht die Signatur. Keine der beiden Komponenten allein kann den nsec ableiten. Das beabsichtigte Ergebnis ist, dass dieselbe Lightning-Wallet über Geräte hinweg denselben Nostr-Schlüssel produziert, mit der Wallet als Recovery-Anker und ohne dass ein Server den privaten Schlüssel rekonstruieren kann.
NIP-55: rejected-Feld dokumentieren (PR #2290): Dokumentiert das rejected-Feld für intent-basierte Signer-Antworten und formalisiert damit das Verhalten, das Amethysts v1.07.x-Fix umgehen musste.

NIP Deep Dive: NIP-5A (Static Websites)

NIP-5A definiert, wie statische Websites unter Nostr-Schlüsselpaaren gehostet werden, wobei zwei Event-Kinds und bestehende Blob-Speicher-Infrastruktur genutzt werden, um signierte Events in ausgelieferte Webseiten zu verwandeln. Die Spezifikation wurde am 25. März über PR #1538 gemergt.

Das Modell nutzt Kind 15128 für eine Root Site, eine pro Pubkey, und Kind 35128 für benannte Sites, die durch einen d-Tag identifiziert werden. Jedes Manifest ordnet absolute URL-Pfade SHA256-Hashes zu. Hier ist ein Root-Site-Manifest:

{
 "id": "5324d695ed7abf7cdd2a48deb881c93b7f4e43de702989bbfb55a1b97b35a3de",
 "pubkey": "266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5",
 "created_at": 1743465600,
 "kind": 15128,
 "tags": [
 ["path", "/index.html", "186ea5fd14e88fd1ac49351759e7ab906fa94892002b60bf7f5a428f28ca1c99"],
 ["path", "/about.html", "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456"],
 ["path", "/favicon.ico", "fedcba0987654321fedcba0987654321fedcba0987654321fedcba0987654321"],
 ["server", "https://blossom.primal.net"],
 ["title", "My Nostr Site"],
 ["description", "A static website hosted on Nostr"],
 ["source", "https://github.com/lez/nsite"]
 ],
 "content": "",
 "sig": "f4e4a9e785f70e9fcaa855d769438fea10781e84cd889e3fcb823774f83d094cf2c05d5a3ac4aebc1227a4ebc3d56867286c15a6df92d55045658bb428fd5fb5"
}

Der Serving-Flow arbeitet in drei Schritten. Ein Host-Server empfängt eine HTTP-Anfrage, extrahiert den Pubkey des Autors aus der Subdomain (entweder ein npub für Root Sites oder ein base36-kodierter Pubkey für benannte Sites), ruft die Relay-Liste des Autors über NIP-65 ab und fragt nach dem Site-Manifest. Sobald das Manifest gefunden ist, löst der Server den angeforderten Pfad in einen Content-Hash auf, lädt den passenden Blob vom Blossom-Server oder den Blossom-Servern herunter, die in den server-Tags aufgelistet sind, und gibt ihn zurück.

Das DNS-Subdomain-Format ist eng spezifiziert. Root Sites verwenden den Standard-npub als Subdomain. Benannte Sites verwenden eine 50-Zeichen-Base36-Kodierung des rohen Pubkeys gefolgt vom d-Tag-Wert, alles in einem einzigen DNS-Label. Weil DNS-Labels auf 63 Zeichen begrenzt sind und die Base36-Kodierung immer 50 Zeichen benötigt, ist der d-Tag auf 13 Zeichen begrenzt. Die Spezifikation verlangt außerdem, dass d-Tags zu ^[a-z0-9-]{1,13}$ passen und nicht mit einem Bindestrich enden, um Mehrdeutigkeiten bei der DNS-Auflösung zu verhindern.

Die Verwendung von Content-Hashes bedeutet, dass dieselbe Site von verschiedenen Host-Servern ausgeliefert werden kann und die Datei-Integrität überprüfbar ist, ohne dem Server zu vertrauen. Ein Host-Server muss keine Dateien selbst speichern. Er lädt sie bei Bedarf von Blossom anhand der Hashes im Manifest. Das bedeutet, der Autor kontrolliert, was ausgeliefert wird, der Blossom-Server speichert die rohen Dateien, und der Host-Server verbindet nur beides. Jede dieser drei Komponenten kann unabhängig ersetzt werden.

Bestehende Implementierungen umfassen nsite, den Host-Server, der Manifeste auflöst und Dateien ausliefert, und nsite-manager, eine UI zum Erstellen und Veröffentlichen von Manifesten. Die Spezifikation fügte auch einen source-Tag zum Verlinken des Source-Code-Repositories einer Site hinzu, und das separat gemergte README-Update in PR #2286 registrierte sowohl Kind 15128 als auch 35128 im NIP-Kind-Index.

NIP Deep Dive: NIP-62 (Request to Vanish)

NIP-62 definiert Kind 62 als Anfrage an Relays, alle Events des anfragenden Pubkeys zu löschen. Die Spezifikation ist rechtlich motiviert: In Jurisdiktionen mit Right-to-be-Forgotten-Gesetzen gibt eine standardisierte, signierte Löschanfrage Relay-Betreibern ein klares Signal zum Handeln.

{
 "id": "a7b8c9d0e1f23456789012345678901234567890abcdef1234567890abcdef12",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1743465600,
 "kind": 62,
 "tags": [
 ["relay", "wss://relay.example.com"]
 ],
 "content": "Requesting deletion of all events from this relay.",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

Die Spezifikation trennt gezielte und globale Vanish-Anfragen. Eine gezielte Anfrage enthält spezifische relay-Tags, die identifizieren, welche Relays handeln sollen. Eine globale Anfrage verwendet den Literal-String ALL_RELAYS als relay-Tag-Wert und fordert jedes Relay, das das Event sieht, auf, alle Events dieses Pubkeys zu löschen. Relays, die dem folgen, müssen außerdem sicherstellen, dass gelöschte Events nicht wieder in das Relay zurückgesendet werden können, sodass die Löschung sticky wird.

NIP-62 geht in Umfang und Absicht über NIP-09 (Event Deletion) hinaus. NIP-09 erlaubt das Löschen einzelner Events, und Relays MAY folgen. NIP-62 fordert die Löschung von allem, und die Spezifikation sagt, dass Relays MUST folgen, wenn ihre URL getaggt ist. Sie bittet Relays außerdem, NIP-59 (Gift Wrap) Events zu löschen, die den anfragenden Pubkey mit p getaggt haben, was bedeutet, dass eingehende DMs zusammen mit den eigenen Events des Nutzers aufgeräumt werden. Das Veröffentlichen einer NIP-09-Löschung gegen eine NIP-62-Vanish-Anfrage hat keinen Effekt: Sobald du vanished bist, kannst du das Verschwinden nicht rückgängig machen, indem du die Vanish-Anfrage löschst.

Diese Woche lieferte Amethyst v1.07.0 client-seitige NIP-62-Unterstützung und ermöglicht Nutzern, Vanish-Anfragen aus der App heraus zu initiieren. Auf der Relay-Seite hat rust-nostr vier offene PRs, die NIP-62-Unterstützung über die Memory-, LMDB-, SQLite- und Datenbank-Test-Backends hinzufügen (PR #1315, PR #1316, PR #1317, PR #1318). Das bringt Client- und Relay-Unterstützungsarbeit in dieselbe Woche.

Das Protokolldesign wirft eine praktische Spannung auf. Nostrs Wertversprechen umfasst Zensurresistenz, was bedeutet, dass Relays die Veröffentlichung nicht verhindern sollten. NIP-62 führt einen Fall ein, in dem ein Relay MUST die Wiederveröffentlichung eines bestimmten Pubkeys verhindern. Die beiden Eigenschaften koexistieren, weil die Anfrage selbstgerichtet ist: Du bittest um Löschung deiner eigenen Events, nicht der von jemand anderem. Die Zensurresistenz-Eigenschaft bleibt für alle intakt außer für die Person, die sich explizit dagegen entschieden hat.

Das war’s für diese Woche. Wer etwas baut oder Neuigkeiten zu teilen hat: Per NIP-17 (Private Direct Messages) DM erreichbar oder auf Nostr findbar.

Nostr Compass #15

Wed, 25 Mar 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Primal Android folgt seinem 3.0-Wallet-Release mit Follow Packs, Zap-Anreicherung und primalconnect://-Deep-Links. BigBrotr veröffentlicht eine nsec-Leak-Analyse, die 41 Millionen Events über 1.085 Relays scannt und 16.599 gültige private Schlüssel findet, während npub.world in derselben Woche Leak-Warnungen in Profilseiten integriert. Martti Malmi startet nostr-vpn, eine Tailscale-Alternative, die über Nostr-Relays signalisiert und WireGuard-Tunnel erstellt, und liefert 11 Releases in sieben Tagen. Das Vector-Team veröffentlicht P2P-DOOM als Open Source über Nostr, FIPS liefert v0.2.0, und Nostrability Schemata expandiert in einer Woche auf sechs Sprachen.

Neuigkeiten

Primal fügt Follow Packs, Zap-Anreicherung und Deep Links hinzu

Anschließend an die 3.0.7-Berichterstattung der letzten Woche, Primal Android arbeitete diese Woche an Post-Release-Arbeit rund um Onboarding, Composer-UX und Wallet-Kontext. Neu gestaltetes Onboarding führt Follow Packs ein (PR #949), ein nativer GIF-Button kommt in den Notiz-Composer, ein Zap-Anreicherungsdienst (PR #979) annotiert Wallet-Transaktionen mit Zap-Kontext, und ein primalconnect://-Deep-Linking-Protokoll (PR #969) ermöglicht app-übergreifende Navigation.

Primal iOS liefert dieselbe Arbeit parallel über TestFlight, wobei der Wallet-Wechsel (PR #191), die Poll-Implementierung und der Onboarding-Umbau im selben Zeitfenster landen.

BigBrotr kartiert exponierte private Schlüssel im Relay-Netzwerk

BigBrotr, die Nostr-Relay-Analyseplattform, veröffentlichte eine detaillierte Analyse exponierter privater Schlüssel im Relay-Netzwerk. Die Studie scannte 41 Millionen Events von 1.085 Relays und suchte nach gültigen nsec-Strings in Event-Inhalten, wobei 16.599 gültige private Schlüssel gefunden wurden. Diese Zahl sieht alarmierend aus, bis man einen Bot namens “Mr.nsec” herausfiltert, der 92 % der Treffer ausmacht. Nach Entfernung des Bot-Traffics hatten nur 38 echte Accounts mit mehr als 21.000 kombinierten Followern exponierte Schlüssel, und keiner zeigte Anzeichen dafür, dass er wusste, dass seine Schlüssel öffentlich waren.

Das Team baute einen nsec-Leak-Checker als NIP-90 (Data Vending Machine) Dienst, der Nutzern ermöglicht zu prüfen, ob ihr privater Schlüssel irgendwo im gescannten Datensatz auftaucht, ohne den Schlüssel dem Prüfer preiszugeben. npub.world integrierte die Leak-Daten in derselben Woche und zeigt Warnbanner auf Profilseiten, auf denen exponierte Schlüssel erkannt wurden. Die Kombination gibt dem Netzwerk sowohl eine programmatische Schnittstelle für DVMs und Agenten als auch eine menschenlesbare Warnung für reguläre Nutzer. Der zugrundeliegende Datensatz speist auch BigBrotr v6.4.0, das ersetzbare und adressierbare Event-Materialized-Views und einen Synchronizer-Idle-Timeout-Fix hinzufügt.

Nostr VPN startet als Tailscale-Alternative

Martti Malmi (mmalmi), Schöpfer von Iris, baute und lieferte nostr-vpn, ein Peer-to-Peer-VPN, das Nostr-Relays für Signalisierung und WireGuard (via boringtun) für verschlüsselte Tunnel verwendet. Die Motivation war direkt: “Got annoyed by Tailscale requiring 3rd party accounts, so created Nostr VPN.” Das Tool erstellt Mesh-Netzwerke zwischen Geräten unter Verwendung von Nostr-Schlüsselpaaren als Identität, ohne zentralen Koordinationsserver.

Das Projekt lieferte 11 Releases in sieben Tagen, von v0.2.2 bis v0.2.13. Dieser Sprint fügte Windows-Unterstützung, LAN-Pairing für lokale Netzwerkerkennung und einen Android-Sidecar für mobile Geräte hinzu. Die Architektur ist einfach: Zwei Geräte tauschen Verbindungsmetadaten über Nostr-Relays aus, dann bauen sie einen direkten WireGuard-Tunnel auf. Nostr übernimmt Discovery und NAT-Traversal-Signalisierung. WireGuard übernimmt den eigentlichen Traffic. Identität ist ein Nostr-Schlüsselpaar.

Malmi trieb auch nostr-double-ratchet weiter voran, eine Signal-artige sichere Messaging-Channel-Bibliothek, und lieferte sechs Releases von v0.0.86 bis v0.0.93 in derselben Woche.

Open-Source-DOOM läuft Peer-to-Peer über Nostr

Das Vector-Team veröffentlichte eine Peer-to-Peer-Multiplayer-DOOM-Implementierung als Open Source, die Nostr für Peer-Discovery, Marmot für Ende-zu-Ende-Verschlüsselung und Iroh, die QUIC-Networking-Bibliothek von n0, für Gossip-Transport verwendet. Das Spiel kommt als 4,2 MB WebXDC-Datei, die innerhalb von Chat-Nachrichten gesendet werden kann, ohne dass Server zum Hosten oder Koordinieren eines Matches nötig sind.

Der technische Ansatz ersetzt den originalen 1993er Lockstep-Netcode durch ein Echtzeit-Hybrid-Sync-Modell. Spieler entdecken sich gegenseitig durch Nostr-Relay-Abfragen, verhandeln Sessions durch Marmot-verschlüsselte Kanäle und übergeben dann an Irohs QUIC-Gossip-Layer für den latenzarmen Spiel-Traffic. Der Stack verwendet Nostr für Discovery, Marmot für Verschlüsselung und Iroh für Transport.

Vector lieferte auch Sicherheitshärtung diese Woche. Der Release fügt einen speichergehärteten Key Vault mit Anti-Debug-Schutz und Zeroize für sensibles Schlüsselmaterial hinzu, User-Blocking mit vollständiger DM- und Gruppennachrichten-Filterung sowie WebXDC-Realtime-Channel-Fixes für Mini Apps.

FIPS v0.2.0 liefert Tor-Transport, reproduzierbare Builds und Sidecar-Beispiele

FIPS, das Free Internetworking Peering System und Nostr-angrenzendes Mesh-Networking-Projekt, lieferte v0.2.0. Der Release fügt Tor-Transport-Unterstützung für anonymisierte Mesh-Links, reproduzierbare Builds, ein Sidecar-Beispiel das sich über ein Nostr-Relay verbindet und Nostr-Release-Publishing im OpenWrt-Paket-Workflow hinzu. Der Release behebt auch Post-Rekey-Jitter-Spikes, die durch Drain-Window-Frames verursacht wurden. Das Wire-Format hat sich gegenüber v0.1.0 geändert, sodass bestehende v0.1.0-Nodes nicht mit v0.2.0 interoperieren können, ohne zu aktualisieren.

Nostrability Schemata wird mehrsprachig

Das Nostrability Schemata-Projekt, das JSON-Schema-Definitionen zur Validierung von Nostr-Event-Kinds pflegt, expandierte in einer Woche von JavaScript-only auf sechs Sprachen. Neue Pakete für Rust, Go, Dart, Swift und Python wurden veröffentlicht, jeweils mit sowohl einem Datenpaket als auch einem Validator. v0.2.6 fügte auch 17 neue Event-Kind-Schemas hinzu.

Der Nostrability-Interop-Tracker erhielt eine parallele Überarbeitung. Ein neuer What’s-New-Tab veröffentlicht Updates sowohl über einen Atom-Feed als auch über ein Nostr-Event, App-Kategorie-Filterung erlaubt Besuchern, in bestimmte Client-Typen einzutauchen, und der Tracker erkennt nun automatisch Programmiersprachen aus GitHub-Repository-Metadaten. Nostrability hat auch nun einen eigenen npub, was das Projekt selbst über das Protokoll auffindbar macht, das es dokumentiert. Für Bibliotheksautoren, die über Sprachen hinweg arbeiten, bedeuten die mehrsprachigen Schema-Pakete, dass dieselben Event-Kind-Definitionen als native Imports verfügbar sind, anstatt dass jedes Projekt seine eigene Schema-Kopie pflegen muss.

Releases

Amethyst v1.06.0 und v1.06.1

Amethyst, der Android-Client gepflegt von vitorpamplona, lieferte v1.06.0 und v1.06.1 am 23. März. Das Hauptfeature ist Poll-Unterstützung mit NIP-85 (Trusted Assertions) Daten für gewichtetes Voting, mit neu gestalteten Poll- und Zap-Poll-Karten. Das neue Rendering gibt sowohl Standard-Polls als auch Zap-gewichteten Polls ein saubereres visuelles Layout. v1.06.1 folgt mit Concurrent-Modification-Crash-Fixes, die Stabilitätsregressionen im Poll-Rendering-Pfad adressieren.

Amber v5.0.0 und v5.0.1

Amber, die NIP-55 (Android Signer Application) Signer-App, beförderte ihre jüngste 4.1.x-Pre-Release-Arbeit mit v5.0.0 am 18. März in Stable. Dieser Stable-Release trägt die NIP-42 Relay-Auth-, eingebaute Tor-, inhaltstypspezifische Berechtigungs- und verschlüsselte PIN-Speicher-Änderungen, die letzte Woche behandelt wurden. v5.0.1 entfernt dann die Internet-Berechtigung aus dem Offline-Build-Flavor, sodass dieser Build auf Android-Berechtigungsebene keine Netzwerkanfragen mehr stellen kann.

Mostro v0.17.0 und Mostro Mobile v1.2.2

Mostro, die Peer-to-Peer-Bitcoin-Börse auf Nostr, lieferte v0.17.0 am 18. März. Der Server-Release setzt die Dispute- und Rating-Arbeit aus dem v0.16.x-Zyklus fort und fügt vollständigere Handels-Reputationsdaten für Käufer und Verkäufer als Nostr-Events hinzu. Mostro Mobile, der Flutter-Client, folgte mit v1.2.2 am 23. März und hält die mobile Oberfläche synchron mit den neuesten Protokolländerungen.

Shosho v0.14.0

Shosho, die Nostr-Livestreaming-App, lieferte v0.14.0 am 19. März mit dem Launch von Shosho Shop. Der Release fügt einen Shop-Tab auf Profilen, Shop in Browse und einen In-Live-Shop-Button auf Lives und Clips hinzu. Die Release-Notes sagen, dass bestehende “Nostr-Produkte” automatisch erscheinen und Käufer zur Plebeian-Market-Seite des Verkäufers durchklicken. Shoshos Release-Notes identifizieren den Listing-Event-Kind nicht, daher lässt sich noch nicht bestätigen, ob Shosho Shop dieselben NIP-99 Kleinanzeigen liest, die Shopstr explizit in seinem README unterstützt.

Applesauce v5.2.0

Applesauce, hzrd149s Sammlung von Helper-Paketen für den Bau von Nostr-Anwendungen, lieferte v5.2.0 am 22. März. Der Release umfasst sechs Pakete. Das SQLite-Paket behebt eine UNIQUE-Constraint-Kollision bei Event-Tags, die doppelte Inserts verursachte. Das Signers-Paket fügt AndroidNativeSigner hinzu, der die NIP-55 native Android-Signer-Schnittstelle umhüllt, sodass WebView-basierte Apps hardwaregestütztes Signing ohne benutzerdefinierten Bridge-Code nutzen können. Das Relay-Paket fügt ein challenge-Feld zu Relay- und Pool-Status-Objekten hinzu, das den NIP-42 Auth-Status verfolgt, sodass Apps erkennen können, wann ein Relay Authentifizierung anfordert und programmatisch reagieren können. Das Core-Paket erhält isEventPointerSame- und isAddressPointerSame-Methoden zum Deduplizieren von Event-Referenzen, und das Common-Paket fügt user.blossomServers$ zum Auflösen der Blossom-Medienserver eines Nutzers hinzu. Applesauce betreibt noStrudel, Satellite und mehrere andere Web-Clients, sodass sich diese Fixes über die Web-Client-Schicht verbreiten.

Wisp liefert 16 Releases in einer Woche

Wisp, der Android-Nostr-Client, lieferte 16 Releases von v0.9.3-beta bis v0.13.1-beta diese Woche. Die Feature-Ergänzungen umfassen Multi-Account-Unterstützung, einen Zen-Benachrichtigungsmodus für reduzierte Unterbrechungen, Entwürfe und geplante Beiträge, Sicherheits-Content-Filter und ein neues Flammen-Icon.

Manent v1.2.0

Manent, die private verschlüsselte Notizen- und Dateispeicher-App, lieferte v1.2.0 am 20. März. Der Release fügt Kameraaufnahme direkt aus der App, Bildgrößenanpassung vor dem Upload zur Reduzierung der Speicherkosten und Pinch-to-Zoom zum Betrachten gespeicherter Bilder hinzu. Manent speichert Notizen und Dateien verschlüsselt auf Nostr-Relays unter Verwendung des Nutzer-Schlüsselpaars und macht das Telefon oder die Desktop-App zu einem Thin Client, der seinen vollständigen Zustand aus Relay-Daten rekonstruieren kann.

diVine 1.0.7

diVine, der Kurzform-Video-Client, lieferte 1.0.7 am 21. März mit einem Video-Wiedergabe-Watchdog, der ins Stocken geratene Videos automatisch fortsetzt. Nach der E2E-Testinfrastruktur und dem direkten MP4-Laden in v1.0.6 zielt dieser Release auf den verbleibenden Wiedergabe-Fehlerpfad: Videos, die mitten im Stream stoppen, ohne einen Fehler zu werfen.

Alby Extension v3.14.2

Alby Extension, die NIP-07 (Browser Extension Signer) Browsererweiterung, lieferte v3.14.2 am 18. März mit Lightning-Adress-QR-Code-Anzeige und Schnorr-Signatur-Unterstützung. Die Schnorr-Ergänzung bringt die Browsererweiterung in Einklang mit dem secp256k1-Signaturschema, das Nostr nativ verwendet.

NoorNote v0.6.5 bis v0.6.11

NoorNote, die Notiz-App, lieferte sieben Releases von v0.6.5 bis v0.6.11. Die Hauptergänzung sind Follow Packs: kuratierte Bündel von Accounts, die Nutzer durchsuchen und in großen Mengen abonnieren können, ähnlich wie Twitter-Listen, aber für Onboarding konzipiert. Nutzer können Follow Packs mit benutzerdefinierten Titeln, Beschreibungen und Coverbildern erstellen, bearbeiten und teilen. Die Serie aktualisiert auch die zugrundeliegende Nostr-Bibliothek von NDK v2 auf v3, was verbesserte Relay-Verbindungsbehandlung und Subscription-Management bringt. Bildnotizen und ein neu gestaltetes Relay-Verbindungserlebnis runden die Serie ab.

nak v0.19.1 und v0.19.2

nak, fiatjafs Kommandozeilen-Nostr-Toolkit für die Interaktion mit Relays, das Kodieren und Dekodieren von NIP-19 (Bech32-Encoded Entities) Identifikatoren, das Signieren von Events und das Abfragen von Relay-Daten, lieferte v0.19.1 und v0.19.2 am 17. und 20. März. Die beiden Punkt-Releases folgen der v0.19.0 Gruppen-Forum-UI-Ergänzung der letzten Woche.

Calendar by Form* v0.2.1

Calendar by Form*, die dezentrale Kalender-App auf Basis von NIP-52 (Calendar Events), lieferte v0.2.1 am 20. März. Der Release behebt ein Benachrichtigungsvorlagen-Problem, das Event-Erinnerungen betraf. Calendar speichert Events als Nostr kind 31922 (datumsbasiert) und kind 31923 (zeitbasiert) Events, sodass jeder Nostr-Client Kalenderdaten rendern kann, wenn er die Kinds unterstützt. Die App wird vom Formstr-Team gebaut, das auch Formstr (dezentrale Formulare) und Pollerama (Umfragen) pflegt.

NYM v3.50 bis v3.53

NYM, der leichtgewichtige ephemere Chat-Client mit Bitchat-Bridge, lieferte 28 Releases von v3.50 bis v3.53 (die Patch-Versionen inkrementieren schnell). Das bemerkenswerteste Feature ist Nymbot, ein eingebauter Chat-Bot, der auf @nymbot-Erwähnungen in Kanälen reagiert und Relay-Status- und Management-Funktionen bietet. Ein “Hardcore-Modus” generiert für jede gesendete Nachricht ein frisches Schlüsselpaar, was Konversationsthreads auf Identitätsebene unverknüpfbar macht. Der Kompromiss ist klar: Man verliert persistente Identität, gewinnt aber Pro-Nachricht-Anonymität. Die Relay-Proxy-Schicht erhielt ebenfalls Arbeit, mit Sharded-Relay-Proxy-Workern für bessere Konnektivität, Geohash-Channel-Unterstützung und Clock-Skew-Toleranz für Nodes mit ungenauen System-Uhren.

Projekt-Updates

Ditto fügt Bluesky-Bridge und Wikipedia-Integration hinzu

Ditto, der anpassbare Nostr-Social-Client des Soapbox-Teams, verzeichnete diese Woche über 300 Commits über drei verschiedene Feature-Tracks. Der erste ist eine Bluesky-Bridge (19 Commits), die Bluesky-Posts inline als vollständige Feed-artige Threads rendert, Sidebar-Navigation zu einer Bluesky-Discovery-Seite mit dem offiziellen Discover-Feed (whats-hot) hinzufügt und Aktionsbuttons für Kommentieren, Teilen, Reagieren und Link-Kopieren verdrahtet. Wenn ein Nutzer von innerhalb Ditto auf einen Bluesky-Post antwortet, zeigt das Compose-Modal einen Disclaimer-Hinweis, der auf die protokollübergreifende Natur der Interaktion hinweist. NIP-73 (External Content IDs) kind-17-Reaktionen treiben das protokollübergreifende Modell an: Ein Nostr-Nutzer reagiert auf einen Bluesky-Post, und die Reaktion wird als Standard-Nostr-Event gespeichert, das den externen Content-Identifier referenziert. Dies ist dasselbe NIP-73-Muster, das Reaktionen auf jeden externen Inhalt brücken könnte, von Bluesky-Posts über YouTube-Videos bis zu Webseiten.

Der zweite Track ist eine Wikipedia-Integration (9 Commits). Ditto rendert nun reichhaltige Wikipedia-Artikelinhalte auf Detailseiten statt generischer Link-Vorschauen, fügt Such-Autocomplete mit Artikel-Thumbnails hinzu und bietet eine /wikipedia-Seite, die Featured Content von der Wikipedia-API zieht. Wikipedia- und Archive.org-Ergebnisse erscheinen auch im allgemeinen Such-Autocomplete-Dropdown. Der dritte Track ist iOS-Plattformunterstützung via Capacitor, mit einem Remote-Build-Skript und Plattformkonfiguration, die neben einer UI-Überarbeitung (55 Commits) landet, die Backdrop-Blur-Header durch ein neues Arc-basiertes Navigationsdesign über jede Seite in der App ersetzt. Die 314 Commits bewegen Ditto von einem Nostr-Only-Client zu einem Multiprotokoll-Aggregator, der Bluesky und Wikipedia als erstklassige Inhaltsquellen neben dem Nostr-Feed behandelt.

Pika baut eine NIP-34-Forge-CI-Pipeline

Pika, die Marmot-basierte verschlüsselte Messaging-App, mergte 33 PRs diese Woche, fokussiert auf eine selbst-gehostete NIP-34 Forge mit Pre-Merge-CI. Die Forge ist eine Git-Hosting-Schicht, die Patches als NIP-34-Events empfängt, CI-Prüfungen vor dem Merge durchführt und strukturierten Status über Nostr-Events zurückmeldet. PR #701 fügt Lane-basierte Pre-Merge- und Nightly-CI hinzu, wobei jeder Code-Pfad (Rust, TypeScript, Apple-Builds) in seiner eigenen Lane mit unabhängigem Pass/Fail-Status läuft. PR #715 schneidet verwaltete CI-Agenten auf Incus-OpenClaw-Container für Isolation, und PR #733 fügt eine ph forge-CLI für die Interaktion mit der gehosteten Forge von der Kommandozeile hinzu. Unterstützende PRs behandeln Repo-Schreibberechtigungen für Merges (PR #736), strukturierte CI-Metadaten mit Live-Status-Badges (PR #722), Apple-Nightly-Build-Splits (PR #738) und Forge-Auth- und Branch-Lookup-Fixes (PR #734). Dies ist eines der ersten funktionierenden CI/CD-Systeme, die auf NIP-34-Git-Events aufgebaut sind, und bewegt Nostr-basiertes Source-Code-Hosting über einfachen Patch-Austausch hinaus in Richtung des Merge-und-Test-Workflows, den Entwickler von GitHub oder GitLab erwarten.

Nostria fügt Communities, Code-Snippets und Voice-Event-Behandlung hinzu

Nostria, der plattformübergreifende Nostr-Client gepflegt von sondreb, erweiterte diese Woche die App-Oberfläche über die in #14 behandelte Web-of-Trust-Filterung hinaus. Die Hauptergänzung ist eine vollständige NIP-72 (Moderated Communities) Implementierung mit Community-Erstellung, Moderator- und Relay-Konfiguration, Post-Approval-Tracking mit Bildvorschauen und einer dedizierten Community-Seite mit Posts- und Moderatoren-Tabs.

Derselbe Arbeitszeitraum fügt auch Code-Snippet-Rendering und -Bearbeitung mit einem syntaxhervorgehobenen Editor, Voice-Event-Reply-Unterstützung für Audio-Konversationen, Chat-Relay-Einstellungen für Direktnachrichten, Channel-Sharing über die Web Share API, ein Toolbar-Docking-System für den Media Player, In-App-Anmeldung für den neuesten Brainstorm Web-of-Trust-Dienst, Geld-Sende- und -Empfangsflows in DMs über NWC und BOLT-11-Invoices, Nostr-native GIF-Behandlung und einen stärkeren RSS-Import-Pfad für Musiker hinzu, der bestehende Lightning-Splits aus Podcast-Feeds übernehmen kann.

nostr-vpn schnelle Iteration

Über den initialen Launch hinaus zeigt das nostr-vpn Commit-Log die spezifischen Probleme, die beim echten Deployment auftraten. v0.2.3 bis v0.2.5 fügten das initiale Installer-Skript und die plattformübergreifende CLI hinzu. v0.2.6 und v0.2.7 brachten Windows-Unterstützung, was UAC-Pfad-Quoting für Config-Writes und Daemon-eigene Config-Updates erforderte. v0.2.8 bis v0.2.10 behob Windows-GUI-Service-Aktionen, CLI-Subprozess-Behandlung und maschinen-bezogene Service-Konfiguration. v0.2.12 ersetzte LAN-Discovery durch zeitgesteuertes LAN-Pairing, einen nutzer-initiierten Flow, bei dem sich zwei Geräte im selben lokalen Netzwerk ohne Relay-Signalisierung pairen. Das Muster ist lehrbuchmäßiges Frühphasen-Feld-Testing: Jeder Release zielt auf einen bestimmten Deployment-Fehler, die Nutzerbasis ist klein genug für tägliche Iteration, und der Entwickler nutzt das Tool persönlich zwischen den Releases.

Comet automatisierte Builds

Comet (ehemals Captain’s Log), das Nostr-native Langform-Schreibtool von Nodetec, produzierte diese Woche über 40 automatisierte Alpha-Builds. Comet ist eine Desktop-App zum Schreiben und Veröffentlichen von NIP-23 (Long-form Content) Artikeln, mit lokaler Entwurfsspeicherung, Markdown-Bearbeitung und Ein-Klick-Publishing zum Relay-Set des Nutzers. Die automatisierte Build-Pipeline generiert einen getaggten Release für jeden Commit auf den Main-Branch, was die rohe Release-Anzahl als Maß für Feature-Velocity irreführend macht. Was die 40 Builds zeigen, ist, dass die App unter täglicher aktiver Entwicklung steht, wobei jeder Commit getestet, paketiert und innerhalb von Minuten zum Download bereitgestellt wird.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository im Zeitfenster 17.-24. März:

Zwischen dem 18. und 24. März wurden keine NIPs gemergt.

Offene PRs und Diskussionen, die im Zeitfenster aktualisiert wurden:

NIP-AA: Autonome Agenten auf Nostr (PR #2259): Schlägt Konventionen für autonome Agenten vor, die im Nostr-Netzwerk operieren. Der PR definiert, wie Agenten sich identifizieren, Dienste entdecken und sich mit anderen Agenten und Menschen über Nostr-Events koordinieren.
NIP-50 (Search): Sortierungserweiterungen (PR #2283): Fügt Sortierparameter zu NIP-50-Suchabfragen hinzu, einschließlich top, hot, zaps und new. Das würde Clients ermöglichen, gerankte Ergebnisse von Relays anzufordern, die Volltextsuche unterstützen, anstatt client-seitig zu sortieren.
NIP-A5: WASM-Programme (PR #2281): Schlägt eine Konvention für das Veröffentlichen und Entdecken von WebAssembly-Programmen auf Nostr vor. WASM-Binaries könnten als Nostr-Events verteilt werden, wobei Relays als Discovery-Schicht für portablen ausführbaren Code dienen.
NIP-CF: Combine Forces interoperable napps (PR #2277): Definiert eine Konvention für interoperable Nostr-Anwendungen (“napps”), die Funktionalität über verschiedene Clients und Dienste hinweg zusammensetzen können.
Snapshots-NIP (PR #2279): Schlägt einen Mechanismus für Relay-Status-Snapshots vor, für Relay-Synchronisation und Backup.
Checkpoints-NIP (PR #2278): Schlägt Checkpoint-Events zum Markieren bekannt-guter Relay-Zustände vor, komplementär zum Snapshots-Vorschlag.
NIP-58 (Badges): Badge-Sets-Refactor (PR #2276): Restrukturiert, wie Badge-Sammlungen organisiert und referenziert werden.
NIP-11 (Relay Information Document): Erweiterungen (PR #2280): Fügt zusätzliche Felder zum Relay-Informationsdokument für reichhaltigere maschinenlesbare Relay-Metadaten hinzu.

Fünf Jahre Nostr im März

Der Newsletter des letzten Monats behandelte, wie Nostrs Februare vom NIP-01 (Basic Protocol Flow) Rewrite über die Damus-App-Store-Welle bis zu Mesh-Networking und Agenten-Vorschlägen fortschritten. Dieser Rückblick zeichnet nach, was in jedem März von 2021 bis 2026 geschah.

März 2021: Zwei Commits

Vier Monate nach seiner Entstehung produzierte Nostrs März genau zwei Commits zum Protokoll-Repository, beide am 4. März. fiatjaf fügte Links zu Nostwitter-Instanzen hinzu, die frühe Besucher auf funktionierende Deployments verwiesen, und fügte Kind zur grundlegenden Filterdefinition hinzu. Dieser zweite Commit ist aufschlussreich: Im März 2021 konnte man Nostr-Events noch nicht nach Kind filtern. Das Protokoll war so primitiv. Zwei oder drei Relays bedienten das Netzwerk. Die Telegram-Gruppe war der einzige Koordinationskanal. Das NIPs-Repository existierte noch nicht; Protokollvorschläge lebten als Dateien im Haupt-Nostr-Repository. fiatjaf war der einzige Committer in diesem Monat. Der gesamte März-2021-Output dessen, was fünf Jahre später ein Protokoll werden würde, das VPNs, Multiplayer-Spiele und Mesh-Networking unterstützt, passt in einen einzigen Git-Diff.

März 2022: Pre-Damus-Aufbau

Das Haupt-Protokoll-Repository erhielt im März 2022 null Commits. Die Entwicklung hatte sich vollständig auf Tool-Repositories verlagert. Branle, fiatjafs Vue.js-Web-Client und zu dieser Zeit die primäre Nostr-Oberfläche, erhielt 5 Commits einschließlich Docker-Deployment-Unterstützung und NIP-05 (DNS-Based Verification) Anzeigenamen-Fixes, die das _@-Präfix aus Verifizierungsbadges entfernten. Robert C. Martins more-speech, der Clojure-Desktop-Client, verzeichnete 13 oder mehr Commits mit Threading, Tastaturnavigation und einem Bearbeitungsfenster. Der berühmteste Software-Autor, der in diesem Monat aktiv auf Nostr baute, war kein Krypto-Entwickler, sondern die Person, deren “Clean Code” Millionen Exemplare verkauft hat, die einen Nostr-Client in Clojure schrieb, einer Sprachwahl, die alles über die frühe Community verrät: Das waren eigenwillige Programmierer, die für sich selbst bauten.

Das Relay-Netzwerk hatte sich auf etwa 15 Relays mit einer aktiven Nutzerbasis im Hunderte-Bereich erweitert. Damus existierte noch nicht und würde erst im April 2022 erstellt werden. Nostream war ebenfalls noch nicht erschienen. Die Arbeit des Monats war Infrastruktur: Die bestehenden Tools zuverlässiger machen für die kleine Community, die sie bereits täglich nutzte.

März 2023: Post-Explosions-Infrastruktur

Einen Monat nach der Damus-App-Store-Welle und dem Anstieg über 300.000 öffentliche Schlüssel ging es im März 2023 darum, das Wachstum aufzunehmen. Das NIPs-Repository mergte 28 Pull Requests, die zweithöchste monatliche Anzahl in der Protokollgeschichte. NIP-51 (Lists) wurde gemergt und gab Clients strukturierte Follow-, Mute- und Bookmark-Sammlungen. NIP-39 (External Identities in Profiles) landete, NIP-78 (Application-Specific Data) lieferte einen allgemeinen Speicher-Kind für Apps, die privaten Zustand brauchten, und ein Rewrite von NIP-57 (Lightning Zaps) (PR #392) konsolidierte den Zap-Flow und klärte die Terminologie. Der meistdiskutierte PR des Monats war ein alternativer Mention-Handling-Vorschlag (PR #381) mit über 50 Kommentaren.

Das folgenreichste neue Projekt war NDK (Nostr Development Kit), die TypeScript-Bibliothek für Relay-Verbindungen, Event-Signing, Caching und Subscription-Management. pablof7z machte den ersten Commit am 16. März 2023, schrieb es 11 Tage später am 27. März von Grund auf neu (“basically another initial commit”) und hatte am 31. März LNURL- und Zap-Unterstützung am Laufen. NDK ging in 15 Tagen von nichts zu Zap-fähig. Fünf Tage nach NDKs Erstellung, am 21. März, erstellte das Alby-Team NWC (Nostr Wallet Connect), die Referenzimplementierung von NIP-47, die Lightning-Wallets mit Nostr-Anwendungen verband. Die beiden Projekte, die die nächsten drei Jahre webbasierter Nostr-Entwicklung untermauern würden, wurden im selben 30-Tage-Fenster geboren. OpenSats hatte seinen Nostr-Fonds noch nicht gestartet; die erste Welle kam erst im Juli 2023, vier Monate nach NDKs Erstellung.

Weitere bemerkenswerte Kreationen in diesem Monat waren NostrGit, NostrChat, ein nostr-signing-device-Projekt von LNbits und nostrmo. Gossip, der Rust-Desktop-Client mit Fokus auf intelligente Relay-Auswahl, lieferte drei Releases. Das Protokoll war im Build-Modus, und die im März 2023 erstellten Tools sind drei Jahre später noch in Gebrauch.

März 2024: Protokollreifung

Im März 2024 ging es um die Härtung des Protokolls für Langzeitnutzung. Das NIPs-Repository mergte 12 Pull Requests. Der bedeutendste war NIP-34 (Git Stuff), PR #997, der am 5. März nach über 130 Kommentaren und 44 Tagen Review gemergt wurde. Der Diskussionsthread ist eine Zeitkapsel der Community, die debattiert, wie man ein dezentrales GitHub baut. jb55 zog Parallelen zu git send-email, Giszmo schlug vor, Root-Commit-Hashes für Cross-Fork-Discovery zu verwenden (“something GitHub doesn’t do and we could”), mikedilger schlug NIP-98 (HTTP Auth) Event-signierte Authentifizierung anstelle von SSH-Schlüsseln vor, und fiatjaf wies die Notwendigkeit von Versionskontroll-Allgemeinheit brüsk zurück: “not for each version control system, just for git. No one uses the others.” Innerhalb von Stunden nach Öffnung des PRs hatte fiatjaf bereits nak, go-nostr und gitstr umgestellt, um Patches über Nostr zu akzeptieren. DanConwayDev, dessen ngit bereits OpenSats-Grantee war, gehörte zu den aktivsten Beitragenden in der Diskussion. Ein Bot-Feld für Profil-Metadaten wurde ebenfalls gemergt, das Clients eine maschinenlesbare Möglichkeit gibt, automatisierte Accounts von menschlichen zu unterscheiden.

Amethyst lieferte v0.85.0 mit Git-Event-Unterstützung, Wiki-Artikeln, medizinischem Daten-Rendering und Content-Editing in einem einzigen Release. Mostro erreichte v0.10.0. Nosflare, ein serverloses Nostr-Relay auf Cloudflare Workers, bewies, dass Relay-Logik am Edge laufen kann. OpenSats erteilte einen Long-Term-Support-Grant an Bruno Garcia für nachhaltige Beiträge zum Amethyst-Client.

März 2025: Infrastruktur-Expansion

Der März 2025 produzierte 10 gemergte NIPs. Die Schlagzeile war NIP-66 (Relay Discovery and Liveness Monitoring), PR #230, der am 3. März nach einer 25-monatigen Reise gemergt wurde. dskvr schlug Relay-Monitoring erstmals im Februar 2023 vor, bekam zu hören, es könnte client-seitig gemacht werden, erklärte, warum das Verbinden zu Tausenden von Relays gleichzeitig für einzelne Clients unpraktisch war, durchlief sieben vollständige Entwürfe, baute Monitoring-Nodes über acht geografische Regionen (Northeast US, Brasilien, US-West, US-East, Australien, Indien, Korea, Südafrika) und wartete darauf, dass das Relay-Tooling aufholte. Als es gemergt wurde, existierten bereits Implementierungen in nostr.watch, relaypag.es, monitorlizard, Snort, noStrudel und Jumble. Die NIP-66-Daten würden später die Nostrability-Outbox-Benchmarks speisen, die in Newsletter #12 behandelt wurden. NIP-C0 (Code Snippets) wurde ebenfalls gemergt (PR #1852, 63 Kommentare) und fügte kind-1337-Events zum Teilen von Quellcode hinzu.

Die ersten MCP-Server für Nostr erschienen in diesem Monat. nostr-mcp-server erschien am 23. März und nwc-mcp-server am 14. März, nur vier Monate nachdem Anthropic das Model Context Protocol im November 2024 angekündigt hatte. Diese frühen Bridges gingen dem vollständigen ContextVM SDK und der Agenten-Commerce-Arbeit voraus, die Ende 2025 und Anfang 2026 folgte.

Gossip lieferte v0.14.0. Coracle, hodlbods Web-Client mit Relay-bewusstem Feed-Management, lieferte drei Releases. OpenSats kündigte seine zehnte Welle von Nostr-Grants an und setzte die Finanzierungspipeline fort, die seit Mitte 2023 lief.

März 2026: Konvergenz

Die Aktivität vom März 2026 stammt aus Nostr-Compass-Ausgaben #12 bis #15 (diese Ausgabe).

März 2026 ist der Monat, in dem verschiedene Stränge zu funktionierenden Systemen konvergierten. Das Marmot Development Kit lieferte seinen ersten öffentlichen Release mit verschlüsselten Medien, Multi-Language-Bindings und einer ChaCha20-Poly1305-Migration, die koordinierte Updates über Spec, Rust und TypeScript erforderte. Shopstr und Milk Market fügten MCP-Commerce-Oberflächen für agentengesteuerten Einkauf hinzu. NIP-42 Relay-Auth landete gleichzeitig in Amber, strfry und OAuth Bunker und schloss die Schleife zwischen Signer-, Relay- und Bunker-Software. Notedeck lieferte Nostr-native Software-Updates unter Verwendung von NIP-94 (File Metadata) Release-Events.

Diese Woche scannte BigBrotr das gesamte Relay-Netzwerk nach geleakten privaten Schlüsseln und veröffentlichte sowohl die Analyse als auch einen DVM-Checker. Nostr VPN bewies, dass Nostrs Schlüsselmodell für Netzwerkinfrastruktur funktioniert, nicht nur für soziale Medien. DOOM demonstrierte, dass Nostr-Discovery, Marmot-Verschlüsselung und QUIC-Transport ein Echtzeit-Multiplayer-Spiel betreiben können. Amber sprang auf v5.0.0. Wisp lieferte 16 Releases in sieben Tagen. 25 oder mehr getaggte Releases kamen von großen Projekten in einer einzigen Woche.

Sieben NIPs wurden in den ersten 24 Tagen des Monats gemergt. Das Protokoll fügte NIP-54 (Wiki) Djot-Markup, NIP-19 (Bech32-Encoded Entities) Eingabegrenzen, NIP-91 (AND Operator for Filters) boolesche Abfragelogik und NIP-85 (Trusted Assertions) Web-of-Trust-Assertions hinzu. Offene Vorschläge reichten von autonomen Agenten (NIP-AA) über WASM-Programme (NIP-A5) bis zu Such-Sortierungserweiterungen für NIP-50.

Ausblick

Fünf Märze Nostr zeichnen einen klaren Bogen. 2021 machte eine Person zwei Commits an ein Protokoll, das Events noch nicht nach Kind filtern konnte. Bis 2023 wurden NDK und NWC fünf Tage auseinander geboren, um die Post-Damus-Explosion aufzufangen. Bis 2024 debattierte ein 141-Kommentar-PR-Thread, wie Git-Zusammenarbeit auf einem sozialen Protokoll funktionieren sollte. Bis 2025 wurde eine Relay-Monitoring-Spezifikation, die geduldig sieben Mal über 25 Monate umgeschrieben worden war, endlich gemergt. 2026 wurde jemand genervt davon, dass Tailscale einen Account verlangt, und baute ein VPN mit Nostr-Schlüsselpaaren, während jemand anderes Multiplayer-DOOM lieferte, das Peers über Nostr-Relays entdeckt und Gameplay über Marmot verschlüsselt. BigBrotrs Scan von 41 Millionen Events über 1.085 Relays gibt ein konkretes Maß dafür, wie weit das Netzwerk gewachsen ist. Die Protokolloberfläche im März 2026 wäre für den März 2021 unerkennbar gewesen, aber das zugrundeliegende Modell, Events signiert mit secp256k1-Schlüsseln und verteilt über Relays, hat sich nicht geändert.

Das war’s für diese Woche. Wer etwas baut oder Neuigkeiten zu teilen hat: Per NIP-17 (Private Direct Messages) DM erreichbar oder auf Nostr findbar.

Nostr Compass #14

Wed, 18 Mar 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Amethyst landet volle NIP-47 (Nostr Wallet Connect) Methodenunterstützung, Alby Hub fügt Multi-Relay-Unterstützung in v1.21.6 hinzu, Amber liefert v4.1.3 mit eingebautem Tor und feineren Signer-Berechtigungen, und Zeus entfernt einen riskanten NWC-Keysend-Pfad in PR #3835. Notedeck liefert einen signierten Updater in v0.8.0-rc2, der Releases über NIP-94 (File Metadata) Events entdeckt, während Damus veralteten NIP-65 (Relay List Metadata) Zustand behebt, Nostrability Outbox seine Benchmark-Ergebnisse mit korrigierten Daten überarbeitet, und Primal iOS direkte Relay-Subscriptions für DMs testet. Primal Android liefert 3.0.7, Route96 liefert v0.6.0, OpenChat verbessert weiter die Marmot-Interoperabilität in v0.1.0-alpha.11, Pika konsolidiert seine Runtime in pika/v1.1.1, und Nostria fügt NIP-85 (Trusted Assertions) Web-of-Trust-Filterung hinzu. Das NIPs-Repository mergt NIP-54 (Wiki) Djot-Markup und eine 5000-Zeichen-Eingabebegrenzung für NIP-19 (Bech32-Encoded Entities), während offene Vorschläge von .nostrkey-Datei-Backups für NIP-49 (Private Key Encryption) bis zu einem NIP-222 Share-Intent-URI reichen. Die NIP Deep Dives dieser Woche behandeln NIP-94 (File Metadata) und NIP-54.

Neuigkeiten

Wallet-Connect-Unterstützung wird breiter, und Wallet-Clients verschärfen Fehlerpfade

Amethyst, der Android-Client gepflegt von vitorpamplona, mergte PR #1828, der seine NIP-47-Implementierung nahe an die vollständige Protokollabdeckung bringt. Der Patch fügt make_invoice, lookup_invoice, list_transactions, get_balance, get_info, Hold-Invoice-Methoden, Keysend-Unterstützung mit TLV-Records, Capability-Discovery über Kind 13194 und Benachrichtigungs-Events auf Kind 23197 mit NIP-44 (Encrypted Payloads) hinzu. Das gibt dem Client eine viel breitere NWC-Oberfläche, ohne auf App-spezifische Erweiterungen angewiesen zu sein.

Der umgebende Wallet-Stack bewegte sich in dieselbe Richtung. Alby Hub, der selbstverwahrende Lightning-Node und Wallet-Dienst hinter vielen NWC-Deployments, lieferte v1.21.6 mit Multi-Relay-Unterstützung und einfacheren Verbindungs- und Swap-Flows. Zeus, die mobile Lightning-Wallet, mergte PR #3835, der NWC-Keysend-Unterstützung entfernt, nachdem ein stiller Fund-Drain-Pfad in diesem Flow identifiziert wurde, und behob gleichzeitig Pending-Event- und Cashu-Activity-Behandlung. Wallet-Konnektivität auf Nostr wird breiter, und Implementierer entfernen Flows, die schwer abzusichern sind.

Notedeck verlagert Release-Erkennung auf Nostr

Anschließend an die Notedeck-Berichterstattung der letzten Woche, Notedeck, der native Desktop-Client des Damus-Teams, lieferte v0.8.0-rc2 nach dem Mergen von PR #1326. Der neue Updater abonniert signierte kind-1063-Release-Events, gleicht die lokale Plattform ab, lädt die referenzierte Binärdatei herunter und verifiziert deren SHA256-Hash vor der Installation. Release-Metadaten müssen nicht mehr von der GitHub-API oder einer Projektwebsite kommen. Ein vertrauenswürdiger Release-Pubkey und eine Relay-Verbindung reichen aus.

Derselbe Patch fügt eine notedeck-release-CLI hinzu, die diese Events aus GitHub-Release-Artefakten veröffentlicht, was bedeutet, dass die Release-Pipeline nun sowohl einen Nostr-nativen Veröffentlichungspfad als auch einen Nostr-nativen Erkennungspfad hat. Es bringt auch das Damus- und Notedeck-Updater-Modell viel näher an Zapstores Relay-veröffentlichten signierten Release-Flow: Zapstores zsp-Tooling behandelt bereits Software-Assets als kind-1063- oder 3063-Events, sodass dieser Pfad nicht an einen Client oder einen Publisher gebunden ist. Der Rest des Release-Kandidaten ist praktische Desktop-Arbeit: Follow-Spalten, Profil-“View As User”, NIP-59 (Gift Wrap) Unterstützung, Echtzeit-Note-Statistiken und NIP-11 (Relay Information Document) Limitation-Handling, aber der Updater ist der Teil, der diesen einen Release-Zyklus wahrscheinlich überdauert.

Relay-Zustand rückt näher an Laufzeitverhalten

Damus mergte PR #3665, der eine veraltete gespeicherte Relay-Listen-Event-ID durch eine direkte Datenbankabfrage für das neueste kind-10002-Event ersetzt. Wenn der alte Wert veraltet war, konnten Relay-Hinzufügen- und -Entfernen-Operationen auf Bootstrap- oder jahresalte Listen zurückfallen, was einige Relay-Änderungen als erfolgreich erscheinen ließ, während der aktive Zustand unverändert blieb. PR #3690 behebt einen zweiten Fehlerpfad, indem veralteter lock.mdb-Zustand während der LMDB-Kompaktierung gelöscht wird, damit die App beim nächsten Start nicht mit SIGBUS abstürzt.

Primal iOS eröffnete PR #194, der direkt die NIP-04 (Encrypted Direct Messages) Write-Relays eines Chatpartners abonniert, während eine Konversation geöffnet ist, wobei der Cache-Server als Fallback dient. Nostur eröffnete PR #53, der randomisiertes Relay-Scoring, NIP-66 Liveness-Filterung von nostr.watch und Thompson-Sampling kombiniert, um die Relay-Auswahl von einer festen Heuristik in eine gelernte Policy umzuwandeln. Clients haben Relay-Auswahl lange als Setup-Daten behandelt. Mehr Apps behandeln sie nun als Live-Zustand, der Mess- und Reparaturlogik benötigt.

Releases

Primal Android 3.0.7

Primal Android, der Android-Client von Primal, lieferte 3.0.7 mit einem neuen Poll- und Wallet-Zyklus. PR #945 fügt Zap-basiertes Poll-Voting hinzu, PR #948 paginiert das Laden von Stimmen, damit größere Umfragen nutzbar bleiben, und PR #965 ruft Zap-Quittungen für alle Transaktionen ab. Dasselbe Release taggt unterstützte Events auch mit NIP-89 (Recommended Application Handlers) Client-Metadaten in PR #968, was nachgelagerten Clients hilft, Event-Ursprünge sauberer zuzuordnen.

Amber v4.1.3

Anschließend an die Amber-Berichterstattung der letzten Woche, Amber, die Android-Signer-App für NIP-55 Flows, lieferte v4.1.3. Der Release baut auf der jüngsten NIP-42 Relay-Auth-Arbeit auf mit weiterer operationeller Härtung: PR #327 fügt eingebautes Tor neben Orbot-Unterstützung hinzu, PR #324 ersetzt grobe NIP-basierte Verschlüsselungsberechtigungen durch inhaltstypspezifische Regeln, und PR #336 entfernt Netzwerkberechtigungen aus dem Offline-Flavor, während PR #335 CI-Prüfungen hinzufügt, um das so beizubehalten. PR #322 verschiebt auch die PIN-Speicherung in verschlüsselten DataStore.

Dieser Release verschärft die Signer-Grenze selbst. Das ist nützlich für jeden Android-Flow, der echte Schlüssel oder Relay-Auth-Entscheidungen an Amber übergibt, denn der schwierige Teil ist nicht nur, was der Signer kann. Es ist auch, wie eng er eingegrenzt werden kann.

Route96 v0.6.0

Anschließend an die Route96-Berichterstattung der letzten Woche, Route96, der Medienserver, der Blossom und NIP-96 (HTTP File Storage) unterstützt, veröffentlichte v0.6.0. Der Release verschiebt Konfiguration und Whitelist-Zustand in die Datenbank mit Hot Reload und fügt Aufbewahrungsrichtlinien für kalte oder alternde Dateien hinzu. Er fügt auch einen reichhaltigeren GET /user/files-Endpunkt plus Datei-Statistik-Tracking für Downloads und Egress hinzu, was Betreibern mehr Einblick gibt, wie ihr Speicherserver genutzt wird.

OpenChat v0.1.0-alpha.11

Anschließend an die OpenChat-Berichterstattung der letzten Woche, OpenChat, der Avalonia-basierte Chat-Client auf dem Marmot-Stack, lieferte v0.1.0-alpha.11 nach einer Woche schneller Protokollarbeit. Commit c33895d verpackt Welcome-Events in NIP-59 Gift Wrap und entfernt alte MIP-00-Tag-Normalisierungs-Shims, Commit 2738ff4 vervollständigt das MIP-02-Compliance-Audit, und Commit 8e470cf tut dasselbe für MIP-03-Gruppennachrichtenverschlüsselung. Commit 129ca37 konsolidiert auch die NIP-44-Behandlung auf die gemeinsame marmot-cs-Implementierung, was das Risiko client-seitiger Krypto-Drift reduziert.

nak v0.19.0 und v0.19.1

nak, fiatjafs Kommandozeilen-Nostr-Toolkit, lieferte v0.19.0 und v0.19.1. Die 0.19-Serie fügt eine Gruppen-Forum-UI in Commit 5f4efdb hinzu, wechselt Gruppen-Metadaten-Edits auf einen vollständigen Replace-Flow in Commit da0b753, und ersetzt die ältere no-text-Behandlung durch supported_kinds in Commit bef67d3. Für Gruppen-Implementierer hält das die CLI im Einklang mit der Richtung, in die sich Gruppen-Specs und -Clients bewegen.

Projekt-Updates

Amethyst

Anschließend an die Amethyst-Berichterstattung der letzten Woche, Amethyst, der Android-Client mit einer der breitesten Protokolloberflächen in Nostr, baute nach dem NIP-47-Patch weiter an seiner Wallet- und Relay-Arbeit. PR #1853 fügt NIP-45 (Event Counting) COUNT-Abfragen über Relay-Management-Bildschirme hinzu, sodass Nutzer sehen können, wie viele Events jedes Relay tatsächlich für Home-Feed, Benachrichtigungen, DMs und Index-Daten vorhält. PR #1849 fügt verschlüsselte Datei-Uploads für NIP-17 (Private Direct Messages) Chats hinzu, mit einem Retry-Pfad für unverschlüsselte Uploads, wenn ein Speicher-Host die verschlüsselte Version ablehnt.

PR #1791 bringt auch vollständigen NIP-46 (Nostr Connect) Desktop-Bunker-Login mit einem Heartbeat-Indikator, was wichtig ist, weil Remote-Signing-Fehler von der Nutzerseite oft wie zufällige UI-Ausfälle wirken. Der Client zeigt, ob der Signer aktiv ist und wie kürzlich er geantwortet hat, und macht gleichzeitig deutlich, wenn die aktuelle Sitzung einen Bunker verwendet.

Nostria

Nostria, der Multiplattform-Client mit einem Local-First-Stack, mergte PR #561 und fügt Web-of-Trust-Filterung für Feeds und Thread-Antworten hinzu. Das Feature nutzt die bestehenden Trust-Service-Rang-Daten und stellt sie sowohl als Feed-Filter als auch als Antwort-Filter zur Verfügung, wobei Autoren ausgeblendet werden, deren Rang den Schwellenwert nicht erreicht, während die Thread-Struktur erhalten bleibt, wenn vertrauenswürdige Nachfolger vorhanden sind. Das gibt Nutzern eine Zwischenschicht zwischen “alle anzeigen” und fest codierter listenbasierter Kuration.

Dieselbe Woche brachte auch PR #563, der Content-Filterung und Repost-Unterstützung zur Zusammenfassungsseite hinzufügt. Außerhalb der getrackten PR-Liste hat Nostria auch mehr seiner Power-User-Oberfläche gefüllt. Es unterstützt nun den neuesten Brainstorm Web-of-Trust-Dienst mit In-App-Anmeldung, zusammen mit Geld-Sende- und -Empfangsflows in DMs über NWC und BOLT-11-Invoices. Es fügt auch Nostr-native GIF-Behandlung über das Emoji-NIP und einen stärkeren RSS-Import-Pfad für Musiker hinzu, der bestehende Lightning-Splits aus Podcast-Feeds übernehmen kann. Nostria behandelt Ranking, Medien, Zahlungen und Publishing als eine verbundene App-Oberfläche.

Nostur

Nostur, der iOS-Client gepflegt von nostur-com, eröffnete PR #53, um Outbox-Routing von einem festen Plan in eine bewertete Policy umzuwandeln. Der Patch fügt randomisiertes Relay-Scoring, NIP-66 Relay-Liveness-Filterung mit einem gecachten nostr.watch-Feed und Thompson-Sampling hinzu, sodass Relay-Erfolgs- und -Fehlerdaten zukünftige Auswahlen ändern. Das Design behält ein Sicherheitsventil bei, wenn zu viele Relays herausgefiltert würden, und bewahrt .onion-Relays. Dies ist eines der klarsten aktuellen Beispiele dafür, wie ein Client Relay-Auswahl als adaptives System behandelt.

Nostrability Outbox

Anschließend an den früheren Outbox-Benchmark-Bericht, Nostrability Outbox, das Benchmark- und Analyseprojekt für NIP-65 und NIP-66 Client-Routing, verbrachte die Woche damit, seine eigenen Behauptungen zu verschärfen. PR #35 ersetzt aufgeblähte Thompson-Sampling-Ergebnisse durch einen vollständigen Re-Benchmark über 1.511 Durchläufe und empfiehlt die CG3-Variante für NDK-artiges Routing. PR #43 fügt Decay- und Anwendungsfall-Vergleiche hinzu, behebt einen 0 follows-Cache-Poisoning-Bug und führt dann das Telluride-Dataset nach dem Pinnen von Cache-TTLs erneut aus.

Das ist keine Produktarbeit im üblichen Sinne, aber es ist wichtig für Client-Autoren, weil die Zahlen des Projekts nun schärfer und weniger schmeichelhaft an den Stellen sind, an denen sie zuvor zu viel beansprucht hatten. Das korrigierte Ergebnis ist trotzdem nützlich. Randomisierte Auswahl schlägt weiterhin rein deterministische Routing-Verfahren in den Fällen, die Outbox interessieren, Thompson-artiges Lernen kann die Abdeckung materiell verbessern, wenn Clients nützliche Relay-Historie persistieren, und NIP-66 Liveness-Filterung spart verschwendete Zeit bei toten Relays. Die Arbeit mündet auch in konkrete Implementierungsvorschläge, darunter NDK #387, Nostur #53, Amethyst #1833, rust-nostr #1282, welshman #53 und applesauce #54 plus applesauce #55.

White Noise Backend

whitenoise-rs, das Rust-Backend, das von White Noise und anderem Marmot-Tooling verwendet wird, mergte zwei Boundary-Härtungs-Patches rund um Blossom-Medienbehandlung. PR #637 erzwingt HTTPS auf Blossom-URLs und fügt ein Upload-Timeout hinzu, während PR #642 Blob-Downloads auf 100 MiB begrenzt, um übergroße Medienabrufe daran zu hindern, sich in einen Denial-of-Service-Pfad zu verwandeln. Für Private-Messaging-Software sind Medien-URLs eine der schärfsten Schnittstellen zwischen verschlüsselter Anwendungslogik und nicht vertrauenswürdiger Netzwerkinfrastruktur. Diese Woche hat das Team diese Kante verschärft.

rust-nostr

rust-nostr, die Rust-Protokollbibliothek, mergte PR #1280, der Convenience-Konstruktoren für LocalRelayBuilderNip42 hinzufügt. Die neuen Read- und Write-Helper geben eingebetteten Relay- und Test-Setups einen klareren Weg, NIP-42 Auth-Policy in Code umzusetzen. Dies ist ein kleiner Bibliotheks-Patch, aber er ist wichtig für Teams, die lokale oder App-gebündelte Relays bauen, die Auth eingeschaltet brauchen, ohne jedes Mal Boilerplate zu wiederholen.

Pika

Anschließend an die frühere Pika-Berichterstattung, Pika, die Marmot-basierte Messaging-App, lieferte pika/v1.1.1 und pikachat-v1.1.1 mit einem Release-Zyklus, der auf Runtime-Konvergenz fokussiert ist. PR #542 führt eine gemeinsame Marmot-Runtime-Fassade für CLI und Sidecar ein, wobei der App-Host auf dieselbe Oberfläche migriert. PR #556 verschärft den OpenClaw-Agenten-Lebenszyklus und Provisioning-Zustand, während PR #600 Restore-from-Backup und strengere Recovery-Sicherheit für verwaltete Umgebungen hinzufügt.

Die direkte nutzerfreundliche Oberfläche ist hier kleiner als im letzten Pika-Bericht, aber die architektonische Änderung ist bedeutsam. Gruppen-, Medien-, Call- und Session-Logik hinter eine gemeinsame Runtime zu ziehen, reduziert die Chance, dass App und Daemon auseinanderdriften, während der Marmot-Stack wächst.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

Gemergt:

NIP-54 (Wiki): Wechsel von Asciidoc zu Djot (PR #2242): Wiki-Inhalte auf Kind 30818 verwenden nun Djot als kanonisches Markup-Format. Der gemergte Text fügt explizites Wikilink-Verhalten, Merge-Request-Beispiele für Kind 818, Redirect-Beispiele für Kind 30819 und Normalisierungsbeispiele für nicht-lateinische Schriften bei d-Tags hinzu. Das gibt Implementierern ein saubereres Parse-Ziel als Asciidoc und entfernt einen weiteren Spec-Pfad, der auf einer Ruby-zentrierten Toolchain basierte.
NIP-19 (Bech32-Encoded Entities): Eingabegrenze hinzufügen (PR #2264): Die Spezifikation empfiehlt nun eine Begrenzung von Bech32-kodierten Entity-Strings auf 5000 Zeichen. Dies ist eine kleine Änderung mit echtem Parser-Wert, weil NIP-19-Strings mittlerweile in QR-Flows, Deep-Links, Share-Sheets und nutzereingefügter Eingabe über viele Clients erscheinen.

Offene PRs und Diskussionen:

Nostr-Key-Datei für NIP-49 (Private Key Encryption) (PR #2269): Schlägt ein .nostrkey-Dateiformat für passwort-verschlüsselten Schlüsselexport und -import vor. Bei einem Merge würde es Clients einen normaleren dateibasierten Backup-Pfad geben, als rohe ncryptsec-Strings herumzukopieren.
Mitgliedschaftsstatus-Konsistenz für NIP-43 (Relay Access Metadata and Requests) (PR #2267): Fügt einen Abschnitt hinzu, der klarstellt, dass Relays einen autoritativen Mitgliedschaftsstatus pro Pubkey führen sollten. Das würde die Gruppen-Client-Logik rund um Mitgliedschaftsänderungen und replizierte Historie vereinfachen.
Löschungsanleitung für NIP-17 (Private Direct Messages) (PR #2260): Schlägt einen konkreten Pfad für das Bearbeiten und Löschen privater Nachrichten durch Gift-Wrapped-Delete-Events vor. Die Arbeit ist noch offen, aber Client-Autoren brauchen hier eine Antwort, wenn NIP-17 ältere DM-Flows vollständig ersetzen soll.
Share-Intent-URI für NIP-222 (PR #2266): Der Entwurf würde standardisieren, wie mobile und Desktop-Apps geteilte Inhalte an einen Nostr-Client übergeben. Das ist eine der rauesten Interop-Kanten in aktuellen App-zu-App-Flows.

NIP Deep Dive: NIP-94 (File Metadata)

NIP-94 definiert Kind 1063 als erstklassiges Metadaten-Event für eine Datei. Die Spezifikation gibt dem Event einen eigenen menschenlesbaren content plus maschinenlesbare Tags für Download-URL, MIME-Typ, Hashes, Dimensionen, Vorschauen, Fallbacks und Speicherdienst-Hinweise. Das ist wichtig, weil die Datei auf Relays als eigenes Objekt abfragbar wird. Ein Client muss keine Metadaten aus umgebendem Inhalt herausparsen, um zu verstehen, was die Datei ist.

{
 "id": "6a92ef8d7c3a1b5d4e8f9a0b1c2d3e4f567890abcdef1234567890abcdef1234",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1742342400,
 "kind": 1063,
 "tags": [
 ["url", "https://downloads.example.org/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["m", "application/gzip"],
 ["x", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["ox", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["size", "48392011"],
 ["dim", "0x0"],
 ["magnet", "magnet:?xt=urn:btih:00112233445566778899aabbccddeeff00112233"],
 ["i", "00112233445566778899aabbccddeeff00112233"],
 ["blurhash", "LEHV6nWB2yk8pyo0adR*.7kCMdnj"],
 ["thumb", "https://downloads.example.org/notedeck/v0.8.0-rc2/thumb.png", "bbccddeeff00112233445566778899aabbccddeeff0011223344556677889900"],
 ["image", "https://downloads.example.org/notedeck/v0.8.0-rc2/screenshot.png", "ccddeeff00112233445566778899aabbccddeeff001122334455667788990011"],
 ["summary", "Signed macOS release artifact for Notedeck v0.8.0-rc2"],
 ["alt", "Notedeck desktop release archive"],
 ["fallback", "https://mirror.example.net/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["service", "nip96"]
 ],
 "content": "Notedeck macOS universal build",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

Die Tags leisten mehr, als sie zunächst erscheinen. x identifiziert die ausgelieferte Datei, während ox die Originaldatei vor jeder serverseitigen Transformation identifiziert. Die Vorschau-Tags erlauben Clients, durchsuchbare Datei-Indizes zu erstellen, ohne das vollständige Asset herunterladen zu müssen, und summary kann daneben einen kurzen Auszug tragen. fallback gibt eine zweite Quelle, wenn die Haupt-URL ausfällt, und service weist auf das Speicherprotokoll hinter der Datei hin, wie NIP-96 oder einen anderen Host. NIP-94 sitzt daher unterhalb von Social Posting und oberhalb von Roh-Speicher. Es beschreibt die Datei, nicht die Konversation um die Datei.

Deshalb ist der Notedeck-Updater dieser Woche interessant. PR #1326 verwendet signierte kind-1063-Events für Software-Release-Erkennung und verifiziert dann die heruntergeladene Binärdatei gegen den veröffentlichten SHA256. Dieselbe Event-Form kann ein Software-Artefakt oder einen Medien-Upload beschreiben. NIP-94 ist alt genug, um stabil zu sein, hat aber noch Raum zum Wachsen, weil mehr Projekte Metadaten-Events als Transport für Maschinen behandeln, nicht nur als Dekoration für Menschen.

NIP Deep Dive: NIP-54 (Wiki)

NIP-54 definiert Kind 30818 als Wiki-Artikel-Event. Die Spezifikation behandelt den d-Tag als das normalisierte Artikelthema und erlaubt vielen Autoren, Einträge für dasselbe Thema zu veröffentlichen. Der Artikelkörper lebt in content, während Tags normalisierte Identität, Anzeigetitel, Zusammenfassungen und Referenzen zu früheren Versionen handhaben. Das bedeutet, NIP-54 ist nicht nur ein Inhaltsformat. Es ist auch ein Abruf- und Ranking-Problem, weil jeder Client immer noch entscheiden muss, welche Artikelversion er anzeigt.

{
 "id": "8c94e5d1f2a300112233445566778899aabbccddeeff00112233445566778899",
 "pubkey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
 "created_at": 1742342400,
 "kind": 30818,
 "tags": [
 ["d", "nostr-wiki"],
 ["title", "Nostr Wiki"],
 ["summary", "Djot-formatted reference article about Nostr wiki events"],
 ["a", "30818:11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff:nostr-wiki", "wss://relay.example.org", "fork"],
 ["e", "11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff", "wss://relay.example.org", "fork"]
 ],
 "content": "Nostr is a [protocol][] for carrying events across relays.\n\n[protocol]: nostr:nevent1example",
 "sig": "33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889900112233cc44dd55ee66ff77889900aabbccddeeff00112233445566778899001122"
}

Der Merge dieser Woche ändert das kanonische Markup von Asciidoc zu Djot in PR #2242. Das ist wichtig für Implementierer, weil Djot eine straffere eigenständige Spezifikation und einfachere Parser-Geschichte über Sprachen hinweg hat. Der gemergte Text klärt auch, wie referenzbasierte Wikilinks aufgelöst werden, wie Merge-Requests Kind 818 verwenden, wie Weiterleitungen Kind 30819 verwenden und wie sich die d-Tag-Normalisierung für nicht-lateinische Schriften verhalten sollte. Das sind die Teile, die zwei unabhängige Clients dazu bringen, sich einig zu sein, auf welchen Artikel ein Link zeigt.

NIP-54 sitzt auch an einem ungewöhnlichen Ort im Protokoll. Ein Wiki-Client braucht Content-Rendering, aber er braucht auch Ranking-Policy. Reaktionen, Relay-Listen, Kontaktlisten und explizite Deference-Signale fließen alle in die Frage ein, welcher Artikel für ein bestimmtes Thema gewinnt. Der Djot-Wechsel löst dieses Ranking-Problem nicht, aber er entfernt eine der Parser-Mehrdeutigkeiten, die darunter lagen. Deshalb ist der Merge jetzt wichtig: Die Änderung handelt weniger von hübscherer Prosa-Formatierung und mehr davon, Multi-Client-Wiki-Verhalten konsistenter implementierbar zu machen.

Wer etwas baut oder möchte, dass wir darüber berichten: Per NIP-17 DM erreichbar auf Nostr unter npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.

Nostr Compass #13

Wed, 11 Mar 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Shopstr und Milk Market bauen MCP-Oberflächen für agentengesteuerten Handel, während OAuth Bunker, Amber und strfry NIP-42 (Authentication of Clients to Relays) Relay-Auth und Protected-Event-Unterstützung quer durch App-, Signer- und Relay-Software ergänzen. Route96 veröffentlicht zwei Releases rund um KI-Kennzeichnung, Moderationswarteschlangen, Perceptual Hashing und maschinenlesbare Server-Dokumentation. Samizdat, bereits im Web live, veröffentlicht sein erstes Android-Alpha und ergänzt später NIP-55 (Android Signer Application) Signer-Unterstützung. Formstr fügt Registrierung per NIP-49 (Private Key Encryption) hinzu, Amethyst liefert Namecoin-basierte NIP-05 (Domain Verification) Auflösung, Mostro veröffentlicht v0.16.4, und das NIPs-Repository merged NIP-91 (AND Operator for Filters) sowie defensive Hinweise für NIP-66 (Relay Discovery and Liveness Monitoring).

Neuigkeiten

Shopstr und Milk Market öffnen MCP-Handelsoberflächen

Shopstr, der Peer-to-Peer-Marktplatz mit Lightning- und Cashu-Zahlungen, mergte PR #234 (Commit 94ef7d1) und fügte damit einen MCP-Server mit API-Key-Authentifizierung für agentenbasiertes Account-Management hinzu. Die Änderung ergänzt .well-known/agent.json für Agent-Erkennung, MCP-Onboarding- und Status-Endpunkte, Routen für Bestellerstellung und Zahlungsprüfung, dedizierte Kauf- und Lesetools sowie einen Einstellungsbildschirm für API-Keys. PR #236 erweitert das um Seller-seitige Aktionen für Nachrichten, Adressen, Bestell-Updates und Produktspezifikationsauswahl. Ein Sicherheitsfix in PR #235 ersetzt Single-Iteration-SHA-256 beim Hashing der API-Keys durch gesalzenes PBKDF2 mit 100.000 Iterationen.

Agenten können NIP-99 (Classified Listings) Listings lesen und sich mit den bestehenden Zahlungsflüssen aus NIP-47 (Nostr Wallet Connect) und NIP-60 (Cashu Wallet) bis zum Checkout bewegen, ohne Seiten zu scrapen oder Client-Verhalten rückwärts zu analysieren.

Milk Market, ein Lebensmittel-Marktplatz auf Nostr unter milk.market, übernahm dieselbe MCP- und API-Key-Basis in Commit da6c0b4. PR #10 fügt Abo-Bestellungen, Änderungen der Lieferadresse nach dem Kauf sowie Multi-Merchant- und Multi-Währungs-Checkout für Stripe und andere Fiat-Zahlungswege hinzu. Ein nachfolgender PR #11 behebt einen Initialisierungsfehler der Datenbank beim Start, bei dem auf frischen Installationen die Tabelle für fehlgeschlagene Relay-Publishes nicht angelegt wurde und dadurch beim ersten Laden 500-Fehler entstanden. Die agentenseitige Schnittstelle funktioniert mit Bitcoin-nativem Checkout bei Shopstr oder gemischtem Fiat- und Bitcoin-Checkout bei Milk Market.

NIP-42-Relay-Auth in Bunker, Signer und Relay

OAuth Bunker, ein NIP-46 (Nostr Connect) Bunker, der OAuth-Provider mit Nostr-Signing verbindet, ergänzte Login per NIP-07 (Browser Extension Signer), automatische Auswahl einer einzelnen Identität und Aufräumlogik für gelöschte Identitäten (Commit f0c7683). Wenn nur eine Identität existiert, wählt der Bunker sie jetzt automatisch aus, statt nachzufragen. Wird eine Identität gelöscht, entfernt der Bunker auch ihre verwaisten Zuordnungen und Verbindungen. Commit 6b8796c ergänzt außerdem einen Konfigurationspfad ALWAYS_ALLOWED_KINDS für zugewiesene Nutzer, standardmäßig für kind 30078 app-spezifische Daten, damit delegierte Identitäten in app-spezifischen Speicher schreiben können, ohne pro Event eine Freigabe zu brauchen.

Amber, der wichtigste NIP-55 Signer für Android, veröffentlichte v4.1.3-pre4 mit vier Pre-Releases innerhalb einer Woche. PR #317 ergänzt NIP-42 Relay-Authentifizierung für kind-22242-Anfragen. Die Implementierung fügt eine neue Datenbankspalte für relay-spezifische Berechtigungen mit einem eindeutigen Index auf (pkKey, type, kind, relay) hinzu. Nutzer sehen einen dedizierten Auth-Bildschirm, auf dem sie Berechtigungen pro Relay oder für alle Relays per Wildcard-* gewähren oder verweigern und diese Entscheidung dauerhaft speichern können. Wildcard-Berechtigungen löschen alle relay-spezifischen Einträge für einen Kind. PR #318 räumt danach Multi-Event-Anfragebildschirme auf und zeigt Details inline mit Composable Cards statt per Navigation auf einen separaten Screen. Das Release aktualisiert außerdem die Standard-Profil-Relays, ergänzt eine Bottom-Sheet-Darstellung für Anfragen und behebt einen Absturz auf MediaTek-Geräten, indem StrongBox-Keystore deaktiviert wird.

Auf Relay-Seite implementiert strfry PR #156 NIP-42-Auth für NIP-70 (Protected Events), und PR #176 lehnt Reposts ab, die geschützte Events einbetten.

Notedeck ergänzt NIP-11-Relay-Limits und Agentium-Funktionen

Notedeck, der native Desktop-Client des Damus-Teams, mergte diese Woche 14 PRs. PR #1316 ergänzt das Abrufen von NIP-11 (Relay Information Document) Relay-Limits, sodass alle Outbox-Relays nun max_message_length und max_subscriptions aus dem Relay-Info-Dokument berücksichtigen. Die Implementierung umfasst Hintergrundjob-Verarbeitung, exponentielles Backoff mit Jitter für Verbindungswiederholungen und benutzerdefinierte HTTP-Accept-Header. PR #1312 behebt einen Fehler, bei dem DMs nach dem Account-Wechsel gelegentlich nicht geladen wurden, und PR #1333 ergänzt einen Backoff-Mechanismus für die Multicast-Relay-Kommunikation, um Broadcast-Spam bei Fehlern zu vermeiden.

Das Agentium-Subsystem, Notedecks eingebaute UI für Coding-Agenten, intern “Dave” genannt, erhielt Einfügen von Bildern aus der Zwischenablage, benannte Run-Konfigurationen, die über kind-31991-Events geräteübergreifend synchronisieren (NIP-33 (Parameterized Replaceable Events)), einen Git-Worktree-Ersteller und einen Model-Picker zur Auswahl von Backends pro Sitzung (PR #1336). PR #1338 integriert egui_kittest für headless UI-Tests, und PR #1339 ergänzt eine Dashboard-Karte, die neue Kontaktlistenerstellungen nach Client verfolgt. Ein offener PR #1314 portiert Amethysts Namecoin-NIP-05-Auflösung nach Notedeck, inklusive ElectrumX-Lookups, SOCKS5-Tor-Routing und Suchleisten-Integration.

diVine veröffentlicht v1.0.6 mit E2E-Testinfrastruktur und NIP-49-Import

diVine, der Shortform-Looping-Video-Client zur Wiederherstellung von Vine-Archiven unter divine.video, veröffentlichte v1.0.6 mit 127 gemergten PRs. Das Release ergänzt NIP-49 Account-Import, externe NIP-05 Unterstützung, Multi-Account-Handhabung, macOS- und experimentelle Linux-Builds sowie eine neu gestaltete Entwurfs- und Clip-Bibliothek auf Basis lokaler Speicherung.

Auf Engineering-Seite ergänzt PR #1928 eine vollständige E2E-Integrationstest-Infrastruktur mit Patrol für native UI-Automatisierung gegen einen Docker-Backend-Stack aus Relay, API, Blossom, Postgres, Redis und ClickHouse. Fünf Tests für Auth-Journeys decken Registrierung, Verifizierung, Passwort-Reset, Session-Ablauf und Token-Refresh ab. PR #2105 stellt das Laden von Videos von HLS-first auf direktes MP4 mit automatischem HLS-Fallback um und verkürzt die Ladezeit damit von 30-60 Sekunden auf nahezu sofort. PR #2076 cached die Home-Feed-API-Antwort in SharedPreferences, damit sie bei Cold Starts sofort angezeigt werden kann. PR #2104 erzwingt, dass ai-generated-Inhaltskennzeichnungen in Feeds ausgeblendet werden, und PR #2100 ergänzt eine Sicherheitseinstellung, die nur von diVine gehostete Videos anzeigt. Die Migration des Profil-Caches von Hive zu Drift läuft weiter über PR #1881, PR #1883 und PR #1903 und ersetzt rund 1.074 Zeilen Hive-Code durch Drift-DAOs.

Vector v0.3.2 bringt NIP-77-Negentropy-Sync und MLS-Verbesserungen

Vector, ein datenschutzorientierter Desktop-Messenger mit MLS-Gruppenverschlüsselung sowie NIP-17 (Private Direct Messages) und NIP-44 (Encrypted Payloads), veröffentlichte v0.3.2. Die wichtigste Änderung ist NIP-77-Negentropy für die MLS-Gruppensynchronisierung (Commit b06adf4), das verpasste Nachrichten per Parallel Boot deutlich schneller nachholt. Das Release ergänzt außerdem eine neu aufgebaute Audio-Engine mit voller Linux-Unterstützung, Bild-Spoiler mit weichgezeichneten Vorschauen, anklickbare Hyperlinks mit Rich-Link-Previews, @mention-Pings mit @everyone für Gruppenadmins, Emoji-Shortcode-Autocomplete, Gruppenstummschaltung, Tap-to-React auf bestehende Reaktionen und abbrechbare Datei-Uploads. Vector filtert explizit NIP-17-Gruppenchat-Events heraus (Commit 2179a51) und verwendet MLS ausschließlich für Gruppenverschlüsselung.

Releases

Route96 v0.5.0 und v0.5.1

Route96, ein Medienserver mit Unterstützung für Blossom und NIP-96 (HTTP File Storage), veröffentlichte v0.5.0 und v0.5.1. v0.5.0 ergänzt automatisierte KI-Kennzeichnung, rückwirkendes Backfill für unmarkierte Uploads, Moderationswarteschlangen für markierte Dateien, EXIF-basierte Datenschutzablehnung und den Umgang mit gebannten Hashes.

v0.5.1 ergänzt Perceptual Image Hashes, Locality-Sensitive Hashing zur Suche nach ähnlichen Bildern, Batch-Admin-Endpunkte und ein veröffentlichtes SKILL.md, das die Blossom- und NIP-96-API-Oberfläche des Servers für Agent-Tooling beschreibt. PR #58 verschiebt Hintergrund-Worker auf vollständig asynchrone Tokio-Tasks, und Commit 97b00a3 ergänzt Backoff, um Hot Loops zu vermeiden.

Samizdat v1.0.0-alpha

Samizdat, ein Longform-Reader und Publisher unter samizdat.press, veröffentlichte mit v1.0.0-alpha seinen ersten Android-Build. Die App startet mit einer kuratierten Press-Seite für lange Nostr-Artikel und einer unteren Tab-Navigation für Press, Feed, Gespeichert und Schreiben. Der Android-Build ergänzt native Schlüsselspeicherung per Android-Keystore-Verschlüsselung mit biometrischer Entsperrung, verarbeitet nostr:-URIs und samizdat.press-Deep-Links und unterstützt die Übergabe an Signer per Android-App-Chooser, Amber, Primal und andere, statt einen direkten Schlüsselimport zu verlangen. Pull-to-Refresh, Safe-Area-Handhabung über verschiedene Bildschirmgrößen hinweg sowie native Share-, Clipboard-, Haptik- und Splash-Screen-Integrationen sind nun Teil der Android-Hülle statt des Web-Wrappers.

Commit d17308f ergänzt intentbasiertes NIP-55 Signing für Amber- und Primal-Flows, und Commit e29dab8 ersetzt einen JavaScript-Bridge-Workaround durch ein natives Capacitor-Plugin mit startActivityForResult. Die App setzt Android 7.0+ (API 24) voraus, wird in diesem Alpha als Debug-APK ausgeliefert und hat noch keine Push-Benachrichtigungen. Das Veröffentlichen hängt derzeit von einer Signer-App ab, während nsec-Login lokales Lesen und Account-Zugriff abdeckt.

Calendar by Form* v0.2.0

Calendar by Form*, eine dezentrale Kalender-App mit NIP-59 (Gift Wrap) für private Event-Freigabe unter calendar.formstr.app, veröffentlichte v0.2.0 mit PR #38. Das Release erweitert die Behandlung wiederkehrender Events für NIP-52 (Calendar Events) und geht damit über das Einzelevent-Fundament von v0.1.0 hinaus. Die zugrunde liegenden Änderungen betreffen außerdem lokale Eventspeicherung, Signer-Handhabung und Android-Benachrichtigungslogik. Es ist die zweite aktive Anwendung der Formstr-Organisation nach der Repository-Migration im vergangenen Monat.

Mostro v0.16.4

Mostro, die Peer-to-Peer-Bitcoin-Börse auf Nostr, veröffentlichte v0.16.4. Die Wiederherstellung von Dispute-Sessions (PR #599) und die Auto-Close-Fixes (PR #606), die wir vergangene Woche behandelt haben, sind enthalten. Neu in diesem Release: PR #625 ergänzt ein days-Feld für User-Rating-Events vom Kind 38384, PR #612 fügt ein Ablaufdatum für diese Rating-Events hinzu, und PR #614 stellt Order-Events auf konfigurierte Ablaufwerte statt auf ein hart kodiertes 24-Stunden-Fenster um. PR #622 ergänzt eine Idempotenzprüfung, um doppelte Auszahlungen von Development Fees zu verhindern.

Mostro Mobile v1.2.1

Mostro Mobile, der Flutter-Client für die Mostro-P2P-Börse, veröffentlichte v1.2.1 mit 11 neuen Features und 11 Bugfixes. Das Release ergänzt die Darstellung verschlüsselter Multimedia-Inhalte im Dispute-Chat (PR #514), automatisches Schließen der Dispute-UI, sobald Orders einen Endzustand erreichen (PR #503), QR-Scanning für NWC-Wallet-Import (Commit 12eaee4), französische Übersetzungen und FCM-Push-Benachrichtigungen. PR #496 behebt einen Padding-Bug bei Schnorr-Signaturen, indem die bip340-Abhängigkeit auf v0.2.0 festgelegt wird.

0xchat v1.5.4

0xchat, der Telegram-artige Messaging-Client mit Cashu-Unterstützung, veröffentlichte v1.5.4, fokussiert auf Linux-Desktop-Fixes: AppImage-Dock-Icons, Emoji-Rendering, Freezes im Kontextmenü und Hänger bei Reply- und Copy-UI. Das Release behebt außerdem Probleme beim Bild-Upload und der npub.cash-Integration. PR #49 eliminiert unnötige UI-Rebuilds, indem ein 3-Sekunden-Polling-Timer entfernt wird, der glasartige Repaints auslöste, ohne etwas zu tun, und entblockt die Login-Initialisierung, indem der Event-Cache parallel geladen wird, statt Relay-, Kontakt- und Channel-Start zu blockieren.

Keep v0.6.0

Keep, ein FROST-Threshold-Signer für Android mit Unterstützung für NIP-55 und NIP-46, veröffentlichte v0.6.0 und v0.6.1. v0.6.0 ergänzt Koordination und UI für Wallet-Deskriptoren, einen Backup-/Restore-Flow mit biometrischer Authentifizierung (PR #184), nsec-Recovery aus Threshold-Shares (PR #187), plattformübergreifende Erzeugung animierter QR-Rahmen via Rust UniFFI (PR #188) sowie einen Signing-Audit-Trail mit Chain-Verifikation (PR #189). v0.6.1 stellt die Lizenz von AGPL-3.0 auf MIT um (PR #191).

njump v0.3.0

njump, das statische Gateway zum Anzeigen von Nostr-Inhalten unter njump.me, veröffentlichte v0.3.0 mit einer Breaking Change beim Parsen von note1-Codes und einem Update der zugrunde liegenden nostr-Bibliothek.

Roadstr v0.1.1

Roadstr, eine dezentrale App zur Meldung von Straßenereignissen auf Nostr, veröffentlichte ihre erste Demo-Version v0.1.1. Die App zeigt Straßenereignisse auf einer Karte an und verwendet dazu Vector Tiles von openfreemap.org.

Bitcredit v0.5.3

Bitcredit, eine E-Bill-Anwendung mit Nostr-Transportebene und eigenem Relay unter bit.cr, veröffentlichte v0.5.3. PR #846 ergänzt payment_actions- und bill_state-Felder in der API für Zahlungs- und Annahmestatus, und PR #849 behebt die Behandlung von Signing-Adressen für anonyme Signer.

OpenChat v0.1.0-alpha.3

OpenChat, eine Chat-Anwendung auf den .NET-MLS- und C#-Bibliotheken des Marmot-Protokolls, veröffentlichte v0.1.0-alpha.3. Das Release ergänzt externe Signer-Unterstützung für Amber- und NIP-46-Flows (Commit e568d97), verlagert die Persistenz des MLS-Zustands in den MLS-Service, um Datenverlustfenster bei Abstürzen zu beseitigen (Commit 4720bc8), und veröffentlicht Windows-, Linux- und Android-Builds über eine neue CI-Pipeline.

OpenSignal v1.0.0

OpenSignal, ein Kotlin-Multiplatform-Trading-Copilot für Nostr, veröffentlichte v1.0.0. Das Release bündelt geteilte KMP-Module für Domain-Logik, Chart-Rendering, Nostr-Authentifizierung und -Publishing, Blossom-NIP-96 Upload-Unterstützung sowie ONNX-basierte KI-Inferenz-Hooks über Desktop- und Android-Shells hinweg. Die veröffentlichte Architektur umfasst außerdem einen FastAPI-KI-Service zur Analyse von Chart-Screenshots, Model-Training-Pipelines und eine Risk-Engine, die strukturierte Trade-Pläne mit Sizing und Warnungen erzeugt. Der Login unterstützt entweder rohe nsec-Keys oder externe Signer, und der Output-Fluss endet beim Publizieren von Nostr-Events statt bei rein lokaler Analyse.

Projekt-Updates

Formstr

Formstr, die Google-Forms-Alternative auf Nostr, mergte PR #434 (Commit e9c4fd5) und ergänzt damit einen Registrierungsflow mit NIP-49 verschlüsselten privaten Schlüsseln. Vor dieser Änderung brauchten Nutzer entweder eine NIP-07 Browser-Erweiterung oder ein eingefügtes rohes nsec, um Formstr zu nutzen. Der neue Flow erzeugt das Schlüsselpaar clientseitig, verschlüsselt den privaten Schlüssel mit einem vom Nutzer gewählten Passwort nach NIP-49 mit scrypt + XChaCha20-Poly1305 und speichert die daraus entstehende ncryptsec-Zeichenkette. Nutzer können sich dann später mit ihrem Passwort wieder anmelden, ohne eine Signer-Erweiterung zu installieren. Das Schlüsselmanagement bleibt während des gesamten Prozesses clientseitig.

Amethyst

Amethyst, der funktionsreiche Android-Client, mergte vier PRs, die die Namecoin-gestützte NIP-05 Auflösung ausliefern, die letzte Woche noch offen war. PR #1734 ergänzt zensurresistente NIP-05-Verifizierung über ElectrumX für .bit-, d/- und id/-Identifikatoren. Wenn Amethyst eines dieser Suffixe in einem NIP-05-Feld erkennt, fragt es einen ElectrumX-NMC-Server nach der Transaktionshistorie des Namens ab, parst das NAME_UPDATE-Script aus dem neuesten Output, um den Nostr-Pubkey zu extrahieren, und lehnt Namen ab, die älter als 36.000 Blöcke sind, das Ablauf-Fenster von Namecoin. ElectrumX-Verbindungen laufen über SOCKS5, wenn Tor aktiviert ist, und die Serverauswahl wechselt dynamisch zwischen Clearnet- und .onion-Endpunkten. Ein LRU-Cache mit einer Stunde TTL verhindert wiederholte Blockchain-Abfragen.

PR #1771 behebt Race Conditions und verbessert die Korrektheit des Resolvers in diesem Flow. PR #1785 erlaubt neuen Nutzern, beim Signup eine Follow-Liste entweder aus gewöhnlichen NIP-05-Identifikatoren oder aus Namecoin-basierten zu importieren. PR #1786 ergänzt benutzerdefinierte ElectrumX-Servereinstellungen, sodass Nutzer auswählen können, welcher Server ihre Lookups bearbeitet.

nostr-idb

nostr-idb, eine Bibliothek mit Hilfsmethoden zum Speichern von Nostr-Events in IndexedDB, mergte PR #6 und ergänzt damit Unterstützung für NIP-91 AND-Tag-Filter. Die Änderung fügt der clientseitigen Filterlogik Schnittmengen-Semantik hinzu, sodass IndexedDB-Abfragen alle aufgelisteten Tag-Werte statt nur einen davon verlangen können. PR #8 aktualisiert die Bibliothek auf die neueste NIP-DB-Schnittstelle, und ein nachfolgender Commit b49b3d3 behebt einen Subscribe-Deadlock und entfernt nostr-tools als Produktionsabhängigkeit.

Pensieve

Pensieve, ein archive-first Nostr-Indexer mit ClickHouse-Analytics, mergte PR #8 und ergänzt damit Durchsetzung von Cache-TTL pro Eintrag sowie Miss-Coalescing pro Schlüssel, um CPU-Spitzen in der API zu reduzieren. Die teuersten Time-Series-Endpunkte, Engagement-Statistiken, stündliche Aktivität und Aktivität pro Kind, verwenden nun serverseitige TTLs von zehn Minuten, statt synchronisierte Neuberechnungsstürme auszulösen.

Blossom

Blossom, das dezentrale Medienhosting-Protokoll und der zugehörige Server-Stack, mergte zwei BUD-11-Autorisierungsupdates. PR #91 verschiebt optionale Autorisierung in einen eigenen BUD und präzisiert die Rolle der Tags x und server. PR #93 räumt endpoint-spezifisches Auth-Verhalten auf und formalisiert den Header X-SHA-256 zur Upload-Verifikation. Die beiden PRs konsolidieren die Auth-Logik in BUD-11 und entfernen Unklarheiten beim Hashing von Requests für Upload-, Delete- und Medienverwaltungsflüsse.

NIP-Updates

Aktuelle Änderungen im NIPs-Repository:

Gemergt:

NIP-91 (AND Operator for Filters) (PR #1365): Fügt Schnittmengen-Semantik für Tag-Filter hinzu, sodass Relays Abfragen beantworten können, die alle aufgelisteten Tag-Werte statt nur eines davon verlangen. Das reduziert clientseitiges Post-Filtering und Bandbreite bei taglastigen Abfragen.
NIP-66 (Relay Discovery and Liveness Monitoring): Defensive Measures (PR #2240): Nach der Outbox-Benchmark-Arbeit aus der vergangenen Woche ergänzt die Spezifikation nun Warnhinweise für schwierige Pfade bei Relay-Monitoring-Daten. Clients dürfen kind-30166-Monitoring-Events nicht voraussetzen, um zu funktionieren. Ein Monitor kann falsch, veraltet oder böswillig sein. Clients sollen Quellen gegeneinander prüfen und nicht auf Grundlage eines einzelnen Feeds große Teile des Relay-Graphs eines Nutzers abschneiden.
NIP-39 (External Identities in Profiles): kind 10011 Registry Cleanup (PR #2256): Ergänzt die Referenz auf kind 10011 direkt in der Spezifikation und richtet sie damit an Amethysts Implementierung aus, die wir vergangene Woche behandelt haben.

Offene PRs und Diskussionen:

NIP-70 (Protected Events): Reject reposts that embed protected events (PR #2251): Wenn ein Relay NIP-70 für das Original-Event durchsetzt, aber Reposts mit demselben Inhalt akzeptiert, hat das --Tag praktisch keine Wirkung. Dieser PR ergänzt daher die Regel, dass Relays auch Reposts der Kinds 6 und 16 von geschützten Events ablehnen müssen. strfry PR #176 implementiert das bereits.
NIP-71 (Video Events): Multiple Audio Tracks (PR #2255): Ergänzt Audio-imeta-Tags für alternative Tonspuren, Sprachvarianten und reine Audio-Streams. Ein Client könnte damit dieselbe Videodatei behalten und nur die Audiosprache wechseln oder Audio als separate Spur für podcastartige Inhalte ausliefern.
NIP-11 (Relay Information Document) und NIP-66 Relay Attributes (PR #2257): Ergänzt ein strukturiertes attributes-Feld in Relay-Informationsdokumenten und gibt Clients sowie Discovery-Tools damit maschinenlesbare Metadaten zusätzlich zur bisherigen Freitextbeschreibung.

NIP Deep Dive: NIP-49 (Private Key Encryption)

NIP-49 definiert, wie ein Client einen privaten Schlüssel mit einem Passwort verschlüsselt und das Ergebnis als ncryptsec-bech32-Zeichenkette kodiert. Formstr verwendet NIP-49 in seinem neuen Registrierungsflow.

Das Format ist nicht an einen speziellen Event-Kind gebunden. Ein Client startet mit dem rohen 32-Byte-secp256k1-Privatschlüssel, leitet per scrypt aus dem Passwort einen symmetrischen Schlüssel ab, verschlüsselt den Schlüssel mit XChaCha20-Poly1305 und verpackt das Ergebnis anschließend in eine bech32-ncryptsec-Zeichenkette. Ein Ein-Byte-Flag speichert, ob der Schlüssel vor der Verschlüsselung irgendwann bekanntermaßen unsicher behandelt wurde.

{
 "id": "4d47f4f0a6f6edbc1bbd7f4e2a45ec68f27cba91d6c6ab5cf28d8d87b0f3d57e",
 "pubkey": "1f8b4c3e7b0f9451d4f9b8a7c6e5d4c3b2a1908f7e6d5c4b3a29181716151413",
 "created_at": 1741699200,
 "kind": 30078,
 "tags": [
 ["d", "encrypted-key-backup"],
 ["format", "ncryptsec"],
 ["encryption", "nip49"]
 ],
 "content": "ncryptsec1qgg9947rlpvqu76pj5ecreduf9jxhselq2nae2kghhvd5g7dgjtcxfqtd67p9m0w57lspw8gsq6yphnm8623nsl8xn9j4jdzz84zm3frztj3z7s35vpzmqf6ksu8r89qk5z2zxfmu5gv8th8wclt0h4p",
 "sig": "6a8f6e4b2d1901735f0ad4b6e8c1f3a579d0e2b4c6f8a1d3e5f7091b2c3d4e5f11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff"
}

Das obige JSON-Event ist ein Anwendungsbeispiel, keine Anforderung von NIP-49. Der NIP standardisiert das Format des verschlüsselten Schlüssels. Ein Client kann das ncryptsec lokal speichern, über app-spezifischen Speicher synchronisieren oder als Backup-String exportieren. Passwörter werden vor der Schlüsselableitung nach Unicode NFKC normalisiert, damit dasselbe Passwort über Clients und Plattformen hinweg konsistent entschlüsselt wird.

Für das Ein-Byte-Flag zur Schlüsselsicherheit sind drei Werte definiert: 0x00 bedeutet, dass die Behandlungshistorie des Schlüssels unbekannt ist, 0x01 bedeutet, dass der Schlüssel bekanntermaßen unsicher behandelt wurde, zum Beispiel als Klartext in ein Webformular eingefügt, bevor er verschlüsselt wurde, und 0x02 bedeutet, dass der Schlüssel in einem sicheren Kontext erzeugt und verschlüsselt wurde und nie offengelegt war. Clients können diese Information nutzen, um beim Import von Schlüsseln mit bekannter unsicherer Historie Warnungen anzuzeigen.

NIP-49 schützt Schlüssel besser als ein Klartext-nsec-Export, aber die Verschlüsselung ist nur so stark wie das Passwort und der konfigurierte scrypt-Kostenfaktor. Höhere LOG_N-Werte erschweren Offline-Erraten, verlangsamen aber auch legitime Entschlüsselungsvorgänge. Die Spezifikation warnt davor, verschlüsselte Schlüssel auf öffentliche Relays zu veröffentlichen, weil Angreifer davon profitieren, Ciphertext für Offline-Cracking zu sammeln. Zum Vergleich vermeidet NIP-46 Remote-Signing die Exposition von Schlüsseln vollständig, und NIP-55 Android-Signing hält Schlüssel innerhalb einer dedizierten Signer-App. NIP-49 besetzt einen anderen Platz: portables verschlüsseltes Backup für Nutzer, die ihre Schlüssel selbst verwalten.

Implementierungen umfassen Formstr PR #434 für den Signup, Amber für ncryptsec-Backup und -Restore, diVine v1.0.6 für den Account-Import, Keep v0.6.0 für den Export von FROST-Shares sowie Key-Management-Tools wie nsec.app und Alby.

NIP Deep Dive: NIP-70 (Protected Events)

NIP-70 definiert geschützte Events. Wenn ein Event das Tag ["-"] trägt, muss ein Relay es ablehnen, sofern das Relay nicht NIP-42 Authentifizierung verlangt und der authentifizierte Pubkey mit dem Autor des Events übereinstimmt.

Der NIP-42-Auth-Flow läuft so ab: Das Relay sendet eine AUTH-Challenge mit einem zufälligen String, und der Client antwortet mit einem signierten kind-22242-Event, dessen Tags die Relay-URL und die Challenge enthalten. Das Relay prüft die Signatur und verifiziert, dass der Pubkey im Auth-Event dem Pubkey im zu publizierenden geschützten Event entspricht. Stimmen die Pubkeys nicht überein, lehnt das Relay das Event mit einem restricted-Präfix in der Fehlermeldung ab.

Der Event-Inhalt kann weiterhin öffentlich sein. Das --Tag steuert nur, wer das Event zu einem Relay veröffentlichen darf, das dieses Tag respektiert. Das deckt NIP-29 (Simple Groups) halbgeschlossene Feeds, Relay-Räume nur für Mitglieder und andere Kontexte ab, in denen der Autor die Weiterverbreitung über den Relay-Graphen begrenzen will. NIP-70 ist eine Ein-Tag-Konvention, kein neuer Event-Kind, daher kann jeder bestehende Event-Kind das --Tag tragen.

{
 "id": "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1707409439,
 "kind": 1,
 "tags": [
 ["-"]
 ],
 "content": "hello members of the secret group",
 "sig": "fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"
}

Selbst wenn ein Relay die Veröffentlichung des Original-Events durch Dritte blockiert, kann jemand den Inhalt in einem Repost erneut veröffentlichen. PR #2251 adressiert das, indem Relays auch Reposts der Kinds 6 und 16 von geschützten Events ablehnen müssen. strfry PR #156 ergänzt NIP-42-Auth für geschützte Events, und strfry PR #176 blockiert Reposts, die geschützte Inhalte einbetten.

NIP-70 steuert Relay-Verhalten. Ein Empfänger kann den Inhalt trotzdem anderswo kopieren, und die Spezifikation sagt das auch ausdrücklich. Das --Tag gibt Relays ein maschinenlesbares Signal, die Wiederveröffentlichung zu verweigern. Zum Vergleich bittet NIP-62 (Request to Vanish) Relays, Daten nachträglich zu löschen, während NIP-70 unautorisierte Veröffentlichung bereits bei der Annahme verhindert. Beide ergänzen sich: Ein Autor kann Events als geschützt markieren, um ihre Verbreitung zu begrenzen, und später zusätzlich Löschung verlangen, wenn Inhalte von Relays entfernt werden sollen, die sie bereits akzeptiert hatten.

Das war es für diese Woche. Baust du etwas oder hast du Neuigkeiten, die wir kennen sollten? Melde dich per NIP-17 DM oder finde uns auf Nostr.

Nostr Compass #12

Wed, 04 Mar 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Das Marmot Development Kit liefert seinen ersten öffentlichen Release mit verschlüsselten Medien und Multi-Language-Bindings. Nostrability veröffentlicht Outbox-Modell-Benchmarks über 14 Relay-Auswahl-Algorithmen. Wisp geht in acht Tagen von der ersten Alpha zur Beta mit Tor und NIP-55 (Android Signer Application) Signing. NIP-91 (AND-Filter) wird gemergt. Vector v0.3.1 liefert negentropy-Sync mit 15-facher Leistungssteigerung. Diese Ausgabe enthält außerdem den Rückblick Fünf Jahre Nostr im Februar, der das Protokoll von einer Spec-Neufassung für drei Relays über die Damus-App-Store-Explosion bis zu Mesh-Networking und KI-Agenten-Vorschlägen nachzeichnet.

Neuigkeiten

Outbox-Modell unter der Lupe

Nostrability veröffentlichte eine Reihe von Outbox-Modell-Benchmarks, die testen, wie gut verschiedene Relay-Auswahl-Algorithmen Events aus dem dezentralen Relay-Netzwerk abrufen. Das Projekt mergte 16 PRs und 76 Commits in zehn Tagen und produzierte die möglicherweise gründlichste empirische Analyse von NIP-65 (Relay List Metadata) Implementierungsstrategien bisher.

Die Benchmarks testen 14 Relay-Auswahl-Algorithmen gegen reale Follow-Listen über 15 Clients und Bibliotheken in fünf Sprachen. Ein Baseline-Ansatz, der nur populäre Relays abfragt, ruft etwa 26 % der Events ab. Greedy Set-Cover mit Thompson Sampling erreicht 80-90 % Recall. Das Hinzufügen einer latenzbewussten Variante mit hyperbolischer Diskontierung und EWMA-Relay-Latenz-Tracking steigerte die Vollständigkeit von 62-80 % auf 72-96 % bei der 2-Sekunden-Marke über sechs Testprofile.

NIP-66 (Relay Monitoring) Dead-Relay-Filterung erwies sich als folgenreich. Die Vorfilterung von Relay-Kandidaten gegen nostr.watch-Liveness-Daten entfernte 40-64 % der toten Relays und verdoppelte die Relay-Erfolgsraten von 30 % auf 75-85 %. Feed-Ladezeiten sanken um 39 % (von 40 auf 24 Sekunden über 10 Profile). Eine EOSE-Race-Simulation ergab, dass das Warten auf EOSE plus eine 200-ms-Toleranzperiode die Vollständigkeit gegenüber dem Stoppen beim ersten fertigen Relay verbesserte.

Für Clients, die ihr Relay-Routing nicht vollständig umschreiben können, fügt ein „Hybrid-Outbox-Enrichment"-Ansatz pro Autor Outbox-Abfragen auf bestehende fest codierte App-Relays hinzu. Dieser Hybrid erreichte 80 % Ein-Jahres-Event-Recall gegenüber der 26 %-Baseline und bietet einen Migrationspfad für Clients mit Legacy-Relay-Architekturen.

ContextVM öffnet MCP-NIP und liefert ephemere Gift Wraps

ContextVM, das Protokoll, das Nostr mit dem Model Context Protocol verbindet, eröffnete diese Woche zwei Vorschläge im NIPs-Repository. PR #2246 formalisiert CVM als Konvention für den Transport von MCP-JSON-RPC-Nachrichten über Nostr mittels ephemerer kind-25910-Events. PR #2245 erweitert NIP-59 (Gift Wrap) um eine ephemere Variante (kind 21059), die NIP-01 (Basic Protocol Flow) ephemere Semantik folgt und Relays erlaubt, gewrappte Nachrichten nach der Zustellung zu verwerfen.

Die ephemere Gift-Wrap-Konvention wurde als CEP-19 in der ContextVM SDK v0.6.x Release-Familie veröffentlicht. Die SDK-Implementierung fügt ein GiftWrapMode-Enum mit drei Einstellungen hinzu: OPTIONAL (beide Kinds akzeptieren und Peer-Fähigkeit automatisch erkennen), EPHEMERAL (nur kind 21059) und PERSISTENT (nur kind 1059). Für KI-Tool-Aufrufe vermeidet der ephemere Modus die Speicherung von Zwischen-Request-Response-Traffic auf Relays und reduziert sowohl Speicherkosten als auch Datenschutz-Exposition.

Neue öffentliche MCP-Server erschienen im Netzwerk von unabhängigen Betreibern, darunter ein Wolfram-Alpha-Abfrageserver. Das ContextVM-Team veröffentlichte CEP-15 (Common-Tools-Schema) und CEP-17 (Server-Relay-Liste-Publikation) neben dem v0.6.x Release-Zyklus.

Marmot Development Kit liefert ersten öffentlichen Release

MDK (Marmot Development Kit), die Rust-Bibliothek hinter Marmot-verschlüsseltem Messaging in Pika und White Noise, lieferte v0.6.0 als ersten öffentlichen Release. Über 200 PRs wurden in diese Version gemergt, mit sechs neuen Mitwirkenden.

Der Release umfasst verschlüsselte Medienunterstützung (MIP-04) mit HKDF-Seed-Ableitung (MIP-01 v2), deterministische Commit-Race-Resolution (MIP-03), verschlüsselten lokalen Speicher, Admin-Autorisierungsvalidierung für Marmot-Commits und -Proposals sowie GREASE-Unterstützung für Protokollerweiterbarkeit. Bindings werden für Kotlin, Python, Ruby und Windows bereitgestellt, zusammen mit Android-Cross-Compilation. Die Bibliothek aktualisiert auf OpenMLS 0.8.0 mit Security-Advisory-Fixes und einem Secret<T>-Typ, der sensible Werte im Speicher nullt.

Eine begleitende Protokolländerung (MIP-03) ersetzte NIP-44 (Encrypted Payloads) Verschlüsselung durch ChaCha20-Poly1305 für kind-445-Nachrichten. NIP-44 erforderte laut Spezifikation UTF-8-String-Eingabe, was es unmöglich machte, rohe Marmot-Nachrichtenbytes durch Standard-TypeScript-Nostr-Bibliotheken zu leiten. Der Ersatz leitet Schlüssel direkt vom Marmot-Exporter-Secret ab. Diese Breaking Change erforderte koordinierte Updates über die Core-Spezifikation, MDK und das TypeScript SDK.

marmot-ts, die TypeScript-Implementierung gepflegt von hzrd149, mergte vier PRs mit eigenen Breaking-API-Änderungen. Ein Omnibus-Update fügte einen Key-Package-Manager für den Create/Publish/Rotate-Lebenszyklus hinzu, eine sendChatMessage-Convenience-Methode, Einladungsvorschau ohne Beitritt (readInviteGroupInfo), Self-Update für Forward-Secrecy-Rotationen und strukturiertes Debug-Logging. Gruppen-Entschlüsselungs-APIs wurden von readGroupMessage zu decryptGroupMessage umbenannt, mit reichhaltigeren Ergebnisvarianten (processed/skipped/rejected/unreadable). gzuuus steuerte Beispiel-Bereinigung mit NIP-65-Relay-Unterstützung und Last-Resort-Key-Package-Handling gemäß MIP-00 bei.

Die White Noise CLI (wn), das Rust-Backend hinter der mobilen App und der neuen TUI, mergte 16 PRs in zehn Tagen. Die Signer-Lifecycle-Behandlung erhielt Abbruchsicherheit durch einen RAII-Scope-Guard (PR #538), der eine Klasse von Bugs behebt, bei der abgebrochene Operationen Signer-Zustand leaken konnten. Login blockiert nun, wenn erforderliche Relay-Listen (kind 10002/10050/10051) fehlen (PR #515), und Giftwrap-Subscriptions fallen auf NIP-65-Relays zurück, wenn Inbox-Listen fehlen (PR #518). Ein Debug-Modus (PR #528) zeigt Datenbankabfragen und MLS-Ratchet-Tree-Inspektion als JSON-Ausgabe. Weitere Fixes betrafen Subscription-Recovery nach Signer-Neuregistrierung, Welcome-Message-Catch-up-Timing, Relay-Filter-Validierung und Nutzersuch-Radius-Limits.

Marmot verzeichnete diese Woche eine bedeutende Expansion über den Rust-Kernstack hinaus. White Noise TUI, eine terminalbasierte Oberfläche für den White-Noise-Messaging-Stack, startete am 3. März. Sie umhüllt die wn-CLI als Subprozess und rendert deren JSON-Ausgabe durch eine Elm-inspirierte unidirektionale Architektur, die Multi-Konversations-Navigation mit Ungelesen-Indikatoren, Gruppenerstellung und Mitgliedersuche, Echtzeit-Nachrichten-Streaming und Emoji-Reaktionen vom Terminal aus bietet.

DavidGershony veröffentlichte einen vollständigen C#-Marmot-Stack, der die geschichtete Architektur des Rust-Toolchains spiegelt. dotnet-mls implementiert kryptografische MLS-RFC-9420-Primitive in C#. marmot-cs baut darauf auf und fügt Nostr-Relay-Transport hinzu, als C#-Äquivalent von MDK. OpenChat, eine plattformübergreifende Desktop-App mit .NET 9 und Avalonia UI, verbindet beides zu einem funktionierenden Chat-Client mit NIP-44-DMs, Marmot-Gruppenverschlüsselung, NIP-46 (Nostr Connect) Remote-Signing und Multi-Relay-Statusindikatoren.

MDK PWA Reference stellt eine Progressive-Web-App-Vorlage für den Bau von Marmot-verschlüsselten Anwendungen bereit, mit experimenteller Unterstützung für KI-Agenten-Teilnahme in Gruppenchats und Bitcoin-Zahlungen über Arkade-Wallet-Infrastruktur.

Wisp: Von Alpha zu Beta

Wisp ist ein neuer Android-Nostr-Client, der vom ersten Alpha am 24. Februar zu v0.3.4-beta am 3. März gelangte und dabei 19 Releases, 115 gemergte PRs und 276 Commits in acht Tagen produzierte.

Die Feature-Entwicklung deckt Terrain ab, für das die meisten Clients Monate brauchen. v0.1.0 startete mit Outbox/Inbox-Relay-Modell-Unterstützung und Onboarding-Flows. Ab v0.1.3 verfügte der Client über NIP-55 Intent-basiertes Signing für Amber, einen eingebetteten Tor-SOCKS5-Proxy für .onion-Relay-Konnektivität und NIP-47 (Nostr Wallet Connect). v0.2.0 stieg zur Beta auf mit Mute-List-Filterung und Custom-Emoji-Unterstützung, während v0.2.4 Content-Warning-Overlays hinzufügte. Die v0.3.x-Serie führte NIP-13 Proof-of-Work für Notes ein, Background-PoW-Mining mit persistenten Einstellungen, .onion-Relay-Speicher und Mute-Thread-Benachrichtigungen.

Gerätebasierte Übersetzung über Google ML Kit läuft lokal ohne Netzwerkzugang nach dem ersten Modell-Download. Eine interaktive soziale Graphvisualisierung nutzt eine Velocity-Verlet-Physiksimulation bei ungefähr 30fps mit Pinch-to-Zoom-Navigation und Profilinspektion.

Releases

Vector v0.3.1

Vector, die Marmot-verschlüsselte Messaging-App, lieferte v0.3.1 mit Gruppenmanagement-Verbesserungen und Performance-Arbeit. Multi-Admin-Gruppen, Masseneinladungen, Einladung per npub und Gruppenavare erweitern die Kollaborationsfunktionen. Android-Hintergrundbenachrichtigungen unterstützen nun Inline-Antwort- und Gelesen-Markieren-Aktionen.

Negentropy-basierter deterministischer Sync ruft den vollständigen Gesprächsverlauf ab, einschließlich Nachrichten, die während Offline-Perioden verpasst wurden. Voice-to-Text wurde mit GPU-Beschleunigung auf Android neu aufgebaut. Die Dateianhang-Behandlung wurde überarbeitet mit Download-Fortschritt, Retry-Zuständen, Verzeichnis-Zip-und-Senden und Live-Fortschrittsanzeigen durchgängig. Die Leistung verbesserte sich über 15-fach bei Boot-Zeit, Bildverarbeitung, Audio-Wiedergabe und allgemeiner UI-Reaktionsfähigkeit. Die App-Installationsgröße sank um mehr als ein Drittel, wobei das Frontend um ungefähr die Hälfte reduziert wurde. 32-bit-ARM-Android-Unterstützung wurde hinzugefügt.

Alby Hub v1.21.5

Alby Hub, der selbst-verwahrende Lightning-Node mit Nostr Wallet Connect (NIP-47) Unterstützung, lieferte v1.21.5. Ein zweites Relay wurde zur Standard-NWC-Konfiguration hinzugefügt, was die Zuverlässigkeit bei Relay-Neustarts verbessert. Ein Fix für ungültige Zap-Daten in der Transaktionsliste behebt ein Anzeigeproblem mit fehlerhaften NIP-57 (Lightning Zaps) Events. Neue App-Store-Einträge umfassen Alby CLI und LNVPS.

nospeak v0.12.x

nospeak, der textbasierte Nostr-Messaging-Client, lieferte drei Releases im Berichtszeitraum. v0.12.0 fügte einen PIN-App-Lock mit 4-stelligem Tastenfeld und über 15 neue Sprachübersetzungen hinzu, darunter Bengali, Thai, Vietnamesisch, Hindi, Arabisch, Hebräisch, Urdu, Türkisch, Japanisch, Chinesisch, Koreanisch, Niederländisch, Polnisch, Russisch und Persisch mit RTL-Unterstützung. v0.12.1 führte ein Cypher-Theme mit reinem Schwarz und Cyan-Akzenten ein, dazu Android-Video-Poster-Generierung. v0.12.2 fügte Chat-Export und „Profil anzeigen" in Kontaktmenüs hinzu.

Citrine v2.0.0-pre2

Citrine, das Android-Personal-Relay von greenart7c3, lieferte v2.0.0-pre2 mit Relay-Performance-Verbesserungen durch neue Datenbankindizes und umstrukturierte Kotlin-Coroutinen. Jede gehostete Web-App startet nun auf einem eigenen Port. Volltextsuche und ein neu gestalteter Events-Bildschirm mit Event-Erweiterung runden die Änderungen ab.

NoorNote v0.5.x

NoorNote, eine Nostr-basierte Notiz-Anwendung, lieferte 8 Releases von v0.5.0 bis v0.5.7. Der v0.5.0-Launch auf Android fügte NIP-55 Amber-Signer-Unterstützung und NIP-71 (Video Events) Note-Publishing hinzu. Eine neu gestaltete Willkommensseite in v0.5.1 enthielt öffentliche Timeline-Vorschauen und reduzierte das APK auf 15 MB. Der Relay Browser in v0.5.2 ermöglicht das Durchsuchen öffentlicher Relay-Timelines über teilbare URLs, zusammen mit Medien-Download und NIP-30 Custom-Emoji-Reaktionen. Nachfolgende Releases bis v0.5.7 beheben Sync-Race-Conditions im kollaborativen „Tribes"-Notiz-Sharing-System.

NosCall v0.5.1

NosCall, die Nostr-Voice- und Video-Calling-App, lieferte v0.5.1 mit Sprachnachrichten-Unterstützung, einem optimierten Desktop-Erlebnis mit Gruppeneintritt, Kontakt-Favoriten auf dem Desktop, Kontaktnotizen und Filterung, Datenexport- und Bereinigungsoptionen sowie Unterstützung für Systemschriftgrößen-Barrierefreiheit.

Shosho v0.13.0

Shosho, die Nostr-Livestreaming-App, lieferte v0.13.0 mit MP4-Replay-Downloads aus Stream-Card-Menüs und NIP-05 (DNS-Based Verification) für Profile. Der RTMP-Publisher migrierte zur Expo Modules API. Die Streaming-Leistung bei niedrigerer Bandbreite verbesserte sich, und Abstürze auf älteren Geräten sowie iOS-Streaming zu Zap.Stream wurden behoben.

nostr-java v2.0.0

nostr-java lieferte v2.0.0 mit konfigurierbaren WebSocket-Puffergrößen, die Anwendungen die Verarbeitung größerer Nostr-Events ohne Abschneidung ermöglichen. Der Major-Version-Bump spiegelt Breaking Changes an der Verbindungs-API wider.

Prism 1.1.0

Prism lieferte 1.1.0 mit Langform-Inhaltsunterstützung (kind-30023-Artikel) und einem Markdown-Editor zum direkten Verfassen in der App, gefolgt von einem 1.1.1 Bugfix-Release.

Angor v0.2.6

Angor, die Bitcoin-Crowdfunding-Plattform, lieferte v0.2.6 mit Boltz-Integration und einem 1-Klick-Invest-Flow. Sowohl Invest- als auch Fund-Projekttypen funktionieren End-to-End im Testnet. Das Team gibt an, dass die UI zu etwa 70 % fertiggestellt ist.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

Gemergt:

NIP-91: AND-Operator für Filter: Fügt AND-Filter-Semantik für Tag-Arrays in Relay-Subscriptions hinzu. Derzeit gleicht die Angabe mehrerer Werte in einem Tag-Filter (z.B. mehrere p-Tags) Events ab, die einen davon enthalten. NIP-91 ermöglicht Clients, Events zu verlangen, die alle angegebenen Tag-Werte gleichzeitig erfüllen, was Bandbreite reduziert und schnellere Index-Operationen ermöglicht. Mehrere Relay-Implementierungen existieren bereits, darunter nostr-rs-relay, satellite-node, worker-relay und applesauce. Früher als NIP-119 nummeriert.
NIP-30: Emoji-Set-Adresse in Tags: Custom-Emoji-Tags in NIP-30 können nun eine optionale Emoji-Set-Adresse enthalten. Das Klicken auf ein Emoji in einem Client kann das zugehörige Set zum Speichern oder Durchsuchen öffnen. Entstanden aus dem Chachi-Client.
NIP-29: unallowpubkey und unbanpubkey hinzufügen: Zwei neue Admin-Befehle für NIP-29 Group Chat. unallowpubkey entfernt einen pubkey von der Erlaubnisliste, ohne ihn zu bannen. unbanpubkey hebt einen Bann auf, ohne den pubkey wieder zur Mitgliederliste hinzuzufügen. Zuvor bannte die einzige Möglichkeit, jemanden von der Erlaubnisliste zu entfernen, die Person gleichzeitig, und das Aufheben eines Banns erforderte das erneute Hinzufügen als Mitglied.

Offene PRs und Diskussionen:

NIP-A7: Spells (eröffnet 27. Feb): Vorgeschlagen von purrgrammer, sind Spells portable gespeicherte Nostr-Abfragen, die als kind-777-Events veröffentlicht werden. Ein Spell kodiert einen REQ- oder COUNT-Filter in strukturierten Tags (k für Kinds, authors für Pubkeys, tag für beliebige Tag-Filter) mit Laufzeitvariablen: $me löst sich zum pubkey des eingeloggten Nutzers auf, $contacts expandiert zur kind-3-Follow-Liste des Nutzers. Relative Zeitstempel (7d, 2w, 1mo) ermöglichen Spells, rollende Zeitfenster ohne fest codierte Daten zu definieren. Bereits in nak und Grimoire implementiert, erlauben Spells Nutzern, kuratierte Feeds zu erstellen, zu teilen und zu abonnieren, die clientübergreifend transportiert werden.
NIP-59: Ephemeral Gift Wrap (kind 21059) (eröffnet 27. Feb): Fügt eine ephemere Variante von NIP-59 Gift Wraps hinzu. Kind 21059 folgt NIP-01-ephemerer Semantik, sodass Relays Events nach der Zustellung verwerfen. Vorgeschlagen von ContextVM für MCP-Transport, wo Nachrichtenpersistenz unnötig ist.
ContextVM: MCP JSON-RPC über Nostr (eröffnet 27. Feb): Spezifiziert den Transport von Model-Context-Protocol-Nachrichten über Nostr mittels ephemerer kind-25910-Events mit p- und e-Tags für Adressierung und Korrelation. Absichtlich schlank gehalten, delegiert Protokolldetails an die ContextVM-Spezifikation.
NIP-29: Audio/Video Live Spaces (eröffnet 25. Feb, Entwurf): fiatjafs Entwurf erweitert NIP-29-Gruppen um Live-Audio und -Video. Der Vorschlag fügt optionale livekit- und no-text-Tags zu Gruppenmetadaten-Events hinzu. Wenn ein Nutzer einem Voice-Space beitreten möchte, fordert der Client ein JWT vom Relay unter /.well-known/nip29/livekit/{groupId} an. Das Relay prüft die Gruppenmitgliedschaft und stellt ein Token mit dem Hex-Pubkey des Nutzers als sub-Claim aus, das an LiveKit für den Medientransport übergeben wird. Voice-Room-Zugang erbt das bestehende Berechtigungsmodell der Gruppe, sodass relay-seitige Mitgliedschaftsregeln bestimmen, wer sprechen kann. Wird in Pyramid und Chachi getestet.
Collaborative Event Ownership (eröffnet 24. Feb): pablof7z schlägt ein Pointer-Event (kind 39382) vor, das einen kollaborativen Raum deklariert, indem Miteigentümer-Pubkeys in p-Tags und ein Ziel-Event-Kind in einem k-Tag aufgelistet werden. Jeder aufgeführte Eigentümer kann Events dieses Kinds mit demselben d-Tag veröffentlichen, und Clients lösen den aktuellen Zustand auf, indem sie alle Eigentümer abfragen und das neueste Event nehmen. Koautoren-Attribution wird nur angezeigt, wenn ein verifizierbares a-Tag auf den Pointer zurückverweist und der Autor in dessen p-Tags erscheint, was gefälschte Ansprüche verhindert. Dies ermöglicht geteilte Wiki-Seiten und gemeinsam verfasste Ressourcen, ohne die Kontrolle einem einzelnen Schlüsselpaar zuzuweisen.
NIP-09: Kaskadenlöschung von Reposts (eröffnet 24. Feb): Wenn ein Originalautor eine Notiz löscht, sollten Relays auch alle kind-6- oder kind-16-Reposts löschen, die darauf verweisen. Motiviert durch Datenschutzbedenken: Reposts können versehentlich preisgegebene Informationen erhalten, nachdem der Autor die Quelle gelöscht hat. Die Änderung betrifft nur die Relay-Seite und erfordert keine Client-Modifikationen.
NIP-07: peekPublicKey (eröffnet 23. Feb): Fügt eine peekPublicKey()-Methode zu NIP-07 Browser-Erweiterungen hinzu. Anders als getPublicKey() gibt sie den aktuellen pubkey zurück, ohne eine Nutzerbestätigung anzufordern, und ermöglicht stummes Auto-Login, wenn der Nutzer Auto-Login aktiviert hat.
NIP-BB: Book (eröffnet 28. Feb, Entwurf): Definiert vier adressierbare Event-Kinds (30300-30303) für strukturiertes Buchpublishing auf Nostr. Ein Cover-Event enthält Wurzel-Metadaten einschließlich Titel, Coverbild, Lizenz via NIP-32 (Labeling) Labels und Sprachcode. Ein Index-Event ordnet jedes Kapitel seiner Position zu mittels Base62-Fractional-Indexing, das Autoren erlaubt, neue Kapitel zwischen bestehende einzufügen, ohne umzunummerieren. Chapter-Events fungieren als strukturelle Überschriften mit optionalen Bildern, während Episode-Events den eigentlichen Prosatext tragen, begrenzt auf 30.000 Zeichen mit positionierten Bild-Tags. Rezensionen verwenden Zaps auf Cover-Events mit der Zap-Beschreibung als Rezensionstext.
NIP-54: Wechsel von Asciidoc zu Djot (eröffnet 26. Feb): Nach dem d-Tag-Internationalisierungsfix im Dezember schlägt dieser PR vor, das NIP-54 Wiki-Asciidoc-Markup-Format durch Djot zu ersetzen, und fügt einen Begründungsabschnitt und Wikilink-Beispiele für nicht-lateinische Schriften hinzu.
NIP-66: Defensive Measures (eröffnet 26. Feb): Basierend auf Erkenntnissen aus den nostrability/outbox-Benchmarks, fügt explizite Hinweise für NIP-66 Grenzfälle hinzu. Ein begleitender PR #2241 definiert Output-Tags für SSL, Geolokation, Netzwerk- und Konnektivitätsprüfungen.
NIP-C1: Cryptographic Identity Proofs (Wiki-Eintrag, kind 30817): Schlägt kind-30509-Events vor, die APK-Signaturzertifikate kryptografisch mit Nostr-Profilen verknüpfen. Der Nachweis funktioniert durch Signierung einer kanonischen Nachricht, die den Nostr-Pubkey enthält, mit dem privaten Schlüssel des Zertifikats (unterstützt ECDSA, RSA PKCS1v15, Ed25519 und andere Standardalgorithmen), und anschließende Veröffentlichung der Signatur in einem kind-30509-Event, das mit dem Nostr-Schlüssel signiert ist. Verifizierer können bestätigen, dass die Person, die ein Android-Signaturzertifikat einer App kontrolliert, auch den Nostr-Pubkey kontrolliert, der die Veröffentlichung beansprucht. Nachweise verfallen standardmäßig nach einem Jahr und können explizit widerrufen werden. Implementiert in der Zapstore-Toolchain.
NIP-31402: SARA Revenue Share Offering Registry (Wiki-Eintrag, kind 30817): Definiert kind-31402 adressierbare Events für die Veröffentlichung von Simple Autonomous Revenue Agreement (SARA) Angeboten auf Nostr-Relays. Emittenten bewerben Lightning-abgerechnete Revenue-Share-Konditionen einschließlich Pool-Anteil-Prozentsatz, Auszahlungsauslöser, Schwellenwert in sats, Laufzeit und gestaffelter Preisgestaltung. Agenten und Menschen können Angebote über Relays entdecken und autonom ohne zentrale Plattform abonnieren. Die Kind-Nummer spiegelt kind 30402 (L402 Service Registry, vom selben Autor als begleitender Wiki-Eintrag veröffentlicht), da SARA die Rückseite der L402-Zahlungsbeziehung darstellt.

Offene PRs und Projekt-Updates

Damus: NIP-89 (Recommended Application Handlers)

PR #3337 implementiert NIP-89-Client-Tag-Unterstützung für Damus. Die App sendet nun einen Client-Tag auf allen Posting-Pfaden (Haupt-App, Share-Extension, Highlighter, Entwürfe) und zeigt „via ClientName" neben Zeitstempeln an, wenn andere Apps ihre Tags mitliefern. Ein Datenschutz-Toggle in den Darstellungseinstellungen ermöglicht das Deaktivieren der Tag-Emission. PR #3652 fügt einen Speicherbereich in den Einstellungen mit einem interaktiven Kreisdiagramm hinzu, das NostrDB- und Kingfisher-Cache-Speichernutzung mit Exportunterstützung aufschlüsselt.

Offen: PR #3657 fügt NIP-65 Relay-Fallback für zitierte Notizen hinzu. Wenn ein Inline-nevent einen Autor-Pubkey aber keine Relay-Hints enthält und die Notiz im Pool des Nutzers fehlt, ruft Damus die kind-10002-Relay-Liste des Autors ab und versucht es erneut von dessen Write-Relays.

Amethyst: NIP-39 (External Identities), NIP-C0, NIP-66

Amethyst mergte eine Welle von NIP-Implementierungen über 28 PRs. Externe Identitätsansprüche werden nun als dedizierte kind-10011-Events unter NIP-39 (PR #1747) veröffentlicht, was soziale Identität von kind-0-Metadaten mit abwärtskompatibler Rückfalloption trennt. Code-Snippet-Unterstützung via NIP-C0 (PR #1744) fügt kind-1337-Events mit Accessoren für Sprache, Erweiterung, Runtime, Lizenz und Abhängigkeiten hinzu. Die NIP-66 Relay-Monitoring-Implementierung (PR #1742) deckt beide Event-Kinds mit vollständigem Tag-Parsing für RTT-Metriken, Netzwerktyp, unterstützte NIPs und Geohash ab.

Verschlüsselte DMs kamen auf Amethyst Desktop (PR #1710) mit einem Split-Pane-Chat-Layout, das sowohl NIP-04 (Encrypted Direct Messages) als auch NIP-17 (Private Direct Messages) unterstützt. Ein neuer Relay-Feed-Bildschirm (PR #1733) ermöglicht das Durchsuchen von Beiträgen eines bestimmten Relays mit Follow/Unfollow-Funktionalität. Offen: Zensurresistente NIP-05-Verifizierung (PR #1734) fügt einen parallelen Verifizierungspfad für .bit-Identifikatoren hinzu, der gegen die Namecoin-Blockchain statt HTTP-DNS auflöst. Wenn Amethyst ein .bit-Suffix in einem NIP-05-Feld erkennt, fragt es einen ElectrumX-NMC-Server nach der Transaktionshistorie des Namens ab, parst das NAME_UPDATE-Skript aus dem neuesten Output, um den Nostr-Pubkey zu extrahieren, und lehnt Namen ab, die älter als 36.000 Blöcke sind (Namecoins Ablaufzeitraum). ElectrumX-Verbindungen werden über SOCKS5 geroutet, wenn Tor aktiviert ist, mit dynamischer Serverauswahl zwischen Clearnet- und .onion-Endpunkten. Ein LRU-Cache mit einer Stunde TTL verhindert wiederholte Blockchain-Abfragen.

Notedeck: Outbox-Architektur

PR #1303 migriert Notedeck von Ad-hoc-Relay-Pool-Management zu einem zentralisierten Outbox-Modell mit Account-bezogenen Subscriptions. Das Messages-Modul veröffentlicht nun eine Standard-DM-Relay-Liste, falls keine existiert, und routet DMs zu den bevorzugten Relays der Empfänger gemäß kind 10050.

Pika: Gruppenspezifische Profile und Tutorial-Feed

Pika, die Marmot-verschlüsselte Messaging-App für iOS und Android mit Desktop-Build, erhielt gruppenspezifische Profile (PR #368). Nutzer können nun für jeden Gruppenchat einen separaten Anzeigenamen und ein Bild festlegen, zusammen mit einer benutzerdefinierten Bio. Diese Profile werden als verschlüsselte kind-0-Events innerhalb der Marmot-Gruppe veröffentlicht, unsichtbar für jeden außerhalb, mit Rückfall auf das globale Nostr-Profil des Nutzers, wenn kein gruppenspezifisches Profil gesetzt ist. Wenn neue Mitglieder beitreten, sendet der Admin alle gespeicherten Gruppenprofile erneut und jedes Mitglied veröffentlicht seines bei Commit neu. Profilbilder werden vor dem Blossom-Upload Marmot-Media-verschlüsselt. Der PR enthält 16 neue Unit-Tests und macht die Funktion sowohl über einen CLI-Befehl (update-group-profile) als auch die UI zugänglich.

Eine neue pika-news-Web-App (PR #401) überwacht Pikas eigene GitHub-PRs und generiert automatisch Schritt-für-Schritt-Tutorial-Walkthroughs aus PR-Diffs, die als server-gerenderte Seiten mit NIP-07 Authentifizierung veröffentlicht werden. Nutzer können bestimmte Tutorials in Echtzeit über Nostr-authentifizierten Chat diskutieren.

diVine: Einbettbare Widgets und Video-Antworten

diVine, die Nostr-native Video-Sharing-Plattform, mergte 132 PRs in zehn Tagen. Einbettbare Iframe-Widgets (PR #1843) bieten eine eigenständige /embed?npub=...-Seite, die Nutzerprofil und neueste Videos rendert. Video-Antwort-Funktionalität (PR #1915), hinter einem Feature-Flag geschützt, verwendet Kind-1111-Comments (NIP-22) mit NIP-92 (Media Attachments) imeta-Metadaten. Bluesky-inspirierte dreistufige Inhaltsfilter (PR #1797) bieten Show/Warn/Hide-Steuerungen über 17 NIP-32 Content-Warning-Kategorien.

strfry: REQ-Filter-Validierung

PR #163 fügt konfigurierbare REQ-Filter-Validierung zu strfry hinzu, dem C++-Nostr-Relay. Betreiber können maximale Filter pro REQ, erforderliche Autoren- oder Tag-Präsenz, erlaubte Kind-Whitelists und pro Filter Kind-Limits festlegen. Die Funktion zielt auf NWC-Relay-Deployments, die strenge Filter-Durchsetzung benötigen. Offen: PR #173 fügt optionale zstd-Kompression für Event-Payloads bei der Aufnahme hinzu.

rust-nostr: NIP-62 Request to Vanish

rust-nostr, die Rust-Nostr-Protokollbibliothek, fügte NIP-62 (Request to Vanish) Unterstützung über alle drei Datenbank-Backends hinzu: LMDB, SQLite und In-Memory. Die LMDB-Implementierung enthält konfigurierbare Optionen zum Aktivieren oder Deaktivieren von NIP-09 und NIP-62-Durchsetzung pro Deployment.

NDK: Collaborative Events und NIP-46-Timeout

NDK, das Nostr Development Kit für JavaScript/TypeScript, mergte PR #380 mit NDKCollaborativeEvent für Mehrautorendokumente mittels eines adressierbaren Pointer-Events (kind 39382), das autorisierte Autoren definiert. Ein konfigurierbarer Timeout für NDKNip46Signer (PR #381) verhindert, dass NIP-46 Remote-Signing-Operationen endlos hängen, wenn ein Bunker nicht antwortet.

TENEX: Agenten-Kategorisierung und Pubkey-Gating

TENEX, die Nostr-native KI-Agenten-Orchestrierungsplattform, mergte zwei sicherheitsbezogene PRs. TIP-01 rollenbasierte Agenten-Kategorisierung (PR #91) ordnet Agentenkategorien (Principal, Orchestrator, Worker, Advisor, Auditor) automatisierten Tool-Beschränkungen über eine Denied-Tools-Map zu. Front-Door-Pubkey-Gating (PR #87) stellt sicher, dass nur Events von Whitelisted- oder Backend-signierten Pubkeys zusammen mit bekannten Agenten geroutet werden; unbekannte Pubkeys werden stillschweigend mit OpenTelemetry-Spans für Audit verworfen.

Zap Cooking: Mitgliedschafts-Dashboard

Zap Cooking, die Nostr-basierte Rezeptteilungsplattform, mergte 25 PRs und 85 Commits in zehn Tagen. Ein Mitgliedschafts-Dashboard (PR #228) zeigt den Abonnementstatus mit Ablaufdaten und Verwalten/Upgrade-Optionen, reaktiviert Feature-Gates für Sous-Chef- und Zappy-Stufen mit client- und serverseitigen Prüfungen und standardisiert Stufennamen über 26 Dateien. Zweiphasiges Gruppen-Nachrichten-Laden (PR #227) bietet einen schnellen 3-Tage-Initial-Fetch für sofortige Anzeige, gefolgt von einem 40-Tage-Backfill im Hintergrund.

Wallet-Mnemonic-Speicher wechselte von pubkey-abgeleiteter Verschlüsselung zu NIP-44 Encrypt-to-Self (PR #224), was eine Schwachstelle behebt, bei der das alte Schema seinen Schlüssel aus SHA-256(pubkey) ableitete, was praktisch unverschlüsselt ist, da Pubkeys öffentlich sind. Bestehende Wallets werden beim ersten Laden stillschweigend migriert. NIP-29 Group Chat erhielt Ungelesen-Indikatoren mit roten Punkt-Badges und Einladungszugang mit kind-9009-Einladungscodes (PR #213). Link-Vorschauen und Nostr-Event-Einbettungen werden nun in DMs und Gruppennachrichten gerendert (PR #218). Ein Nostr-Backup-Bereich in den Einstellungen (PR #210) speichert Follows und Mute-Listen via NIP-78 (Application-specific Data) verschlüsseltem Speicher mit rotierender 3-Slot-Versionierung. Startperformance verbesserte sich durch verzögerte Benachrichtigungsdienste, Lazy-DOM-Rendering via IntersectionObserver (Reduktion der DOM-Knoten von ~15.000 auf ~3.000 bei einem 200-Event-Feed) und erweiterte Outbox-Cache-TTLs (PR #208). Ein anpassbares Rezeptdruck-Modal (PR #205) ermöglicht das Umschalten der einzuschließenden Abschnitte mit Live-Vorschau. Branta SDK Integration (PR #222) fügt Verifizierungs-Guardrails für POST- und GET-Anfragen hinzu.

Keep: Rust-gesteuerte Zustandsmigration

Keep, der Nostr-basierte Private-Key-Manager für Android, mergte PR #178, der vier Kotlin-Konfigurationsspeicher zugunsten von Rust-gesteuertem Shared State aus der keep-mobile-Schicht löscht. Eine 10-Sekunden-Polling-Schleife wurde durch Push-basiertes KeepStateCallback aus Rust ersetzt. PR #179 fügt verschlüsseltes Backup und Restore mit Passphrase-Schutz hinzu.

Mostro Mobile: Dispute-Chat-Verschlüsselung

Mostro Mobile, der mobile Client für die Mostro P2P-Bitcoin-Handelsplattform, lieferte eine zweiphasige Migration der Dispute-Chat-Verschlüsselung. Der erste Schritt (PR #495) wechselt von mostro-spezifischem Wrapping zu Shared-Key-Verschlüsselung, die vom pubkey des Admins abgeleitet wird. Darauf aufbauend vereinheitlicht PR #501 das Nachrichtenmodell mit NostrEvent und speichert Gift-Wrap-Events verschlüsselt auf der Festplatte, konsistent mit dem Peer-to-Peer-Chat-Muster. Ein BIP-340-Signaturfix (PR #496) überschreibt die bip340-Abhängigkeit auf 0.2.0 und behebt einen bigToBytes()-Padding-Bug, der 1-2 % der Schnorr-Signaturen ungültig machte und 100 % Fehlerrate für Schlüssel verursachte, deren öffentlicher Schlüssel mit 0x00 beginnt. Bestelldetails zeigen nun menschenlesbare Status-Labels statt roher Protokollwerte, lokalisiert in Englisch, Spanisch, Italienisch und Französisch (PR #502). HalCash wurde hinzugefügt und SEPA als Zahlungsmethode entfernt (PR #493), da SEPA-Überweisungen 24 Stunden überschreiten können (SEPA Instant bleibt).

Auf der Serverseite behebt Mostro die Wiederherstellung von Dispute-Sitzungen, um das Initiator-Feld einzuschließen (PR #599), und schließt nun automatisch aktive Disputes, wenn ein Verkäufer Gelder freigibt, wobei ein Settled-Nostr-Event veröffentlicht wird, damit Admin-Clients die Auflösung sehen (PR #606).

Fünf Jahre Nostr im Februar

Der Newsletter des letzten Monats zeichnete Nostrs Januar-Meilensteine von der frühen Entwicklung über den Damus-Durchbruch bis zur Sicherheitsinfrastruktur im Jahr 2026 nach. Dieser Rückblick behandelt, was in jedem Februar von 2021 bis 2026 geschah.

Februar 2021: Die Neufassung

Drei Monate nach seiner Entstehung brachte Nostrs Februar die folgenreichste frühe Änderung des Protokolls hervor. Am 14.-15. Februar schrieb fiatjaf NIP-01 um und ersetzte das ursprüngliche Nachrichtenformat durch das EVENT/REQ/CLOSE-Modell, das das Protokoll bis heute verwendet. Vor dieser Neufassung kommunizierten Clients und Relays über eine einfachere Struktur. Die Trennung von Event-Veröffentlichung (EVENT) und Subscription-Management (REQ/CLOSE) ermöglichte relay-seitige Filterung, die sich als wesentlich für die Skalierung erweisen sollte.

NIP-04 kam im selben Monat hinzu und fügte verschlüsselte Direktnachrichten über Shared Secrets aus Diffie-Hellman-Schlüsselaustausch über secp256k1 hinzu. Die Verschlüsselung war grundlegend (AES-256-CBC) und wurde später durch die geprüfte Kryptografie von NIP-44 ersetzt, gab aber der Handvoll früher Nutzer ihren ersten privaten Kommunikationskanal auf dem Protokoll.

Das Tooling expandierte mit noscl, einem Go-Kommandozeilen-Client für terminalbasierte Relay-Interaktion, und futurepaul startete nostr-rs, eine frühe Rust-Implementierung. Das gesamte Netzwerk lief auf zwei oder drei Relays, koordiniert über eine Telegram-Gruppe, mit ungefähr sieben aktiven Mitwirkenden.

Februar 2022: Aufbau von Momentum

Der Hacker-News-Beitrag vom 31. Dezember 2021 zog weiterhin Entwickler bis in den Februar hinein an. Das nostr-protocol/nostr-Repository (das formale NIPs-Repository existierte erst ab Mai 2022) erhielt im Februar sechs Pull Requests, darunter NIP-13 (Proof of Work) von vinliao, NIP-14 (Reputation) von fiatjaf, NIP-15 (Resource Relations) von Cameri und NIP-17 (Git Updates Over Nostr) von melvincarvalho. Die NIP-Nummer wurde später Private Direct Messages zugewiesen; Git-Zusammenarbeit auf Nostr wurde separat fortgesetzt durch das, was gitworkshop.dev wurde.

Greg Heartsfields nostr-rs-relay war das Arbeitspferd des Monats mit 34 Commits und drei Releases. Version 0.5.0 am 12. Februar fügte NIP-05 verifizierte Nutzer-Publishing-Limits hinzu. Die Versionen 0.5.1 und 0.5.2 folgten in den nächsten zwei Wochen, und das Relay bewältigte den Großteil des Netzwerk-Traffics allein.

Robert C. Martin (Uncle Bob) baute more-speech, einen Clojure-Desktop-Client, und verzeichnete 69 Commits zwischen dem 18. Januar und Ende Februar. Sein Engagement brachte Aufmerksamkeit aus der breiteren Software-Engineering-Community. fiatjafs nos2x Browser-Erweiterung lieferte NIP-04 Decrypt-Unterstützung und Relay-Preference-Policies im Februar und implementierte das window.nostr-Interface (NIP-07), das Web-Clients noch heute für Key-Delegation nutzen.

Branle, weiterhin der primäre Web-Client, erhielt am 13. Februar web+nostr-Protokoll-Handler-Registrierung, ein früher Versuch des Deep-Linking zwischen Nostr-Anwendungen. nostr-tools verschärfte die NIP-05-Validierung. go-nostr fügte NIP-04-Encrypted-DM-Unterstützung und NIP-12 (Generic Tag Queries) Parsing über 11 Commits hinzu. Das Netzwerk lief auf ungefähr 7-15 Relays mit einer aktiven Nutzerbasis wahrscheinlich in den niedrigen Hunderten. Damus und Nostream existierten noch nicht und würden erst im April 2022 erscheinen.

Februar 2023: Internationale Aufmerksamkeit

Februar 2023 brachte Nostr seine größte Welle öffentlicher Aufmerksamkeit. Damus, der iOS-Client von William Casarin, war am 31. Januar im Apple App Store zugelassen worden nach wiederholten Ablehnungen. Am 1. Februar erreichte er die Top 10 im Bereich US Social Networking. Zwei Tage später, am 2. Februar, entfernte Apple Damus aus Chinas App Store, Berichten zufolge auf Antrag der Cyberspace Administration of China.

Große Medien wie TechCrunch und CoinDesk berichteten über die Entfernung und verstärkten das Bewusstsein sowohl für die App als auch für das Protokoll. Einzigartige öffentliche Schlüssel mit Metadaten auf nostr.directory überschritten am 3. Februar 300.000. Alle Relays wurden von Enthusiasten betrieben, die aus eigener Tasche zahlten, und die Infrastruktur kämpfte, die Last zu bewältigen. Etwa 289 Relays wurden Anfang Februar erfasst, eine Zahl, die weiter anstieg.

Das NIPs-Repository verzeichnete in diesem Monat 29 gemergte Pull Requests, die höchste Einzelmonatszahl in der Geschichte des Protokolls bis dahin. NIP-57 (Lightning Zaps) und NIP-23 (Long-form Content) wurden beide am 13. Februar gemergt und fügten Bitcoin-Mikrozahlungen hinzu und erweiterten Nostr an einem einzigen Tag über kurze Beiträge hinaus. NIP-65 (Relay List Metadata) wurde eine Woche zuvor am 7. Februar gemergt und ermöglichte das darauffolgende Outbox-Modell. NIP-46 (Nostr Connect) und NIP-58 (Badges) landeten ebenfalls vor Monatsende.

Die Human Rights Foundation vergab 50.000 US-Dollar an William Casarin für Nostr- und Damus-Entwicklung am 21. Februar, einer der ersten institutionellen Grants für ein Nostr-Projekt. OpenSats hatte seinen Nostr-Fonds noch nicht gestartet (das kam im Juli 2023).

Februar 2024: Protokollbeständigkeit

Februar 2024 verlagerte den Fokus von Wachstum auf Protokollbeständigkeit. NIP-17 (Private Direct Messages), seit dem vergangenen Juli offen, arbeitete auf einen Ersatz für die alternde NIP-04 Verschlüsselung mit NIP-44s geprüfter Kryptografie und NIP-59 Gift-Wrapping hin. NIP-04 leckte Metadaten an Relay-Betreiber, die Sender-Empfänger-Paare sehen konnten. NIP-17 verbirgt die Absenderidentität hinter Einmal-Schlüsselpaaren und wurde im Frühjahr nach einer letzten Überprüfungsrunde im März gemergt.

NIP-29 (Simple Groups) wurde am 28. Februar gemergt nach monatelanger Diskussion und definiert, wie Relays moderierte Gruppenchats mit Admin-Rollen und Zugangskontrolle hosten können. NIP-92 (imeta-Tags) wurde am 1. Februar gemergt und standardisiert, wie Clients Bilddimensionen und Blurhash-Vorschauen an Medien-Events anhängen.

Am 16. Februar fügte das NIPs-Repository BREAKING.md hinzu, eine Datei zur Verfolgung rückwärtskompatibler Änderungen an der Protokollspezifikation. Ihre Erstellung bestätigte, dass Nostr einen Reifegrad erreicht hatte, bei dem Breaking Changes formale Dokumentation erforderten.

Zweiundzwanzig Pull Requests wurden in diesem Monat gemergt. npub.cash startete als Lightning-Adressdienst, der jedem npub den Empfang von Zahlungen ermöglicht, ohne einen Server zu betreiben. Ein akademisches Paper, veröffentlicht am 8. Februar, stellte fest, dass 95 % der kostenlosen Relays die Betriebskosten nicht durch Spenden decken konnten, wobei 35 % der kostenpflichtigen Relays Zugangsgebühren unter 1.000 sats (damals ungefähr 0,45 US-Dollar) erhoben.

Februar 2025: Infrastrukturwachstum

Februar 2025 brachte 28 gemergte Pull Requests für das NIPs-Repository. Ein Right to Vanish-NIP wurde am 19. Februar gemergt und definiert, wie Nutzer die Löschung ihrer Daten von Relays anfordern können, als Reaktion auf regulatorische Fragen zu Datenportabilität und Nutzerkontrolle.

NIP-60 (Cashu Wallet) und NIP-61 (Nutzaps) erhielten Vereinfachungs-Updates, die das Ecash-Token-Speicherformat strafften. Ein q-Tag (Quote-Tag) Rollout setzte sich über mehrere NIPs fort und standardisierte, wie Events andere Events für Zitierung und Threading referenzieren.

Client-Releases markierten stetigen Fortschritt. Notedeck v0.3.0 Alpha erschien am letzten Januartag, mit fortgesetzter Adoption im Februar. Primal v2.1 folgte am 7. Februar, und GRAIN v0.3.0, eine Go-Relay-Implementierung, am 21. Februar.

NOSTRLDN v5 brachte die Londoner Nostr-Community zu ihrem fünften Meetup zusammen. Eine DVMCP-Bridge verband Nostrs Data Vending Machines (NIP-90) mit dem Model Context Protocol und deutete die KI-Agenten-Integrationsarbeit an, die im folgenden Monat kam.

Die Aktivität vom Februar 2026 stammt aus Nostr-Compass-Ausgaben #8 bis #11.

Februar 2026 brachte das breiteste Spektrum an Application-Layer-Entwicklung in einem einzelnen Nostr-Monat. Mostro lieferte seine erste öffentliche Beta für dezentralen Peer-to-Peer-Bitcoin-Handel, und Zapstore erreichte 1.0 Stable nach Monaten in der Release-Candidate-Testphase. White Noise v0.3.0 lieferte Echtzeit-Marmot-verschlüsseltes Messaging mit Amber-Signer-Unterstützung und über 160 gemergten Verbesserungen.

Konkurrierende KI-Agenten-Vorschläge von pablof7z (NIP-AE für Agenten-Workflows, NIP-AD für MCP-Server-Ankündigungen) und joelklabo (AI Agent Messages) kamen zusammen mit einem DVM Agent Coordination-Vorschlag, der NIP-90 erweitert. ContextVM lieferte SDK-Verbesserungen, die das Model Context Protocol mit dem Nostr-Transport verbinden. Burrow fügte Marmot-verschlüsseltes Messaging sowohl für KI-Agenten als auch für Menschen hinzu und erweiterte Nostrs Identitäts- und Relay-Infrastruktur in die Machine-to-Machine-Kommunikation.

FIPS lieferte eine funktionierende Rust-Implementierung von Nostr-nativem Mesh-Networking, die secp256k1-Schlüsselpaare als Knotenidentitäten mit transport-agnostischem Routing über UDP, Ethernet, Bluetooth oder LoRa-Radio verwendet. Sein Design zeigte, dass Nostrs Schlüsselmodell über Social Media hinaus in physische Netzwerkinfrastruktur reicht.

OpenSats kündigte seine fünfzehnte Welle von Nostr-Grants an und finanzierte Projekte wie ContextVM und Nostube. Protokolländerungen umfassten NIP-47 Hold-Invoice-Unterstützung für Nostr Wallet Connect und NIP-45 (Counting Results) HyperLogLog für relay-seitige Zählschätzung. NIP-85 (Trusted Assertions) Service-Provider-Auffindbarkeit für Web-of-Trust-Bewertung wurde ebenfalls gemergt. rust-nostr begann ein vollständiges API-Redesign, während Nostria 3.0 und Frostr (iOS TestFlight) beide erschienen. Blossoms lokale Cache-Schicht adressierte die Medienverfügbarkeit über Relays.

Ausblick

Fünf Februare Protokollgeschichte zeigen eine konsistente Progression von grundlegender Arbeit zu Application-Layer-Diversifizierung, mit dem Nutzerzustrom 2023 als Wendepunkt. 2021 arbeiteten sieben Mitwirkende über drei Relays. Bis 2026 unterstützte dasselbe Protokoll Mesh-Networking und autonome Agenten-Vorschläge auf Produktionsinfrastruktur.

Das war’s für diese Woche. Wer etwas baut oder Neuigkeiten zu teilen hat: Per NIP-17 DM erreichbar oder auf Nostr findbar.

Nostr Compass #11

Wed, 25 Feb 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: White Noise v0.3.0 bringt Echtzeit-Messaging und Amber-Signer-Unterstützung mit über 160 gemergten Verbesserungen. diVine 1.0.5 behebt Video-Wiedergabeprobleme und fügt Kind-22236-View-Events für Creator-Analytics hinzu. Pika, Ridestr und Unfiltered liefern Updates. FIPS veröffentlicht eine funktionierende Rust-Implementierung von Nostr-nativem Mesh-Networking. Notecrumbs erhält Stabilitäts-Fixes für damus.io-Link-Vorschauen. ContextVM verbindet Nostr mit dem Model Context Protocol. Neue Projekte umfassen Burrow für MLS-verschlüsseltes Messaging zwischen KI-Agenten und Menschen sowie Nostria Signer für browserbasierte Vault- und Identitätsverwaltung. Die Deep Dives dieser Woche behandeln NIP-55 Android-Signing und NIP-60 Cashu-Wallet-Synchronisierung.

Neuigkeiten

Notecrumbs Stabilitätsverbesserungen

Notecrumbs, der Nostr-API- und Webserver, der damus.io-Link-Vorschauen antreibt, erhielt eine Reihe von Fixes für Zuverlässigkeitsprobleme.

Ein Nebenläufigkeits-Fix ersetzte den Inflight-Deduplizierungsmechanismus durch Watch-Channels. Zwei Aufrufer, die dieselbe Notiz anforderten, konnten beide zu Fetchern werden, was zu einem Deadlock führte, wenn einer abschloss, bevor der andere die Benachrichtigung abonniert hatte. Watch-Channels mit atomaren Operationen stellen sicher, dass nur ein Fetcher läuft, während andere auf das Ergebnis warten.

Rate-Limiting implementiert eine zweischichtige Verteidigung gegen Relay-Hammering. Wenn Nutzer wiederholt auf dieselbe Notiz zugreifen, entprellt das System nun Relay-Anfragen mit einem 5-Minuten-Cooldown-Fenster. Dieser Schutz erstreckt sich auf alle NIP-19-Typen und Profil-Feeds und verhindert proportionalen Spam an Relays bei starkem Traffic.

Performance-Verbesserungen verlagerten sekundäre Datenabrufe in Hintergrund-tokio-Tasks. Seiten rendern nun sofort mit gecachten Daten, statt bei sequenziellen Relay-Timeouts zu blockieren, die bis zu 7,5 Sekunden aufaddieren konnten. Ein Upgrade auf nostrdb 0.10.0 begleitete diese Fixes.

ContextVM: MCP über Nostr

ContextVM ist eine Suite von Werkzeugen, die Nostr und das Model Context Protocol (MCP) verbindet. Aktuelle Commits führten die neue CEP-8-Spezifikation ein, die Zahlungen ermöglicht, und trieben im Februar SDK-Verbesserungen voran.

Das SDK stellt TypeScript-Client- und Server-Transports für MCP über Nostr bereit. Entwickler können MCP-Server über das Nostr-Netzwerk exponieren, und Clients verbinden sich mit ihnen, während Relays als blinder Nachrichtenbus verschlüsselte Events weiterleiten. Clients ohne native Nostr-Unterstützung kommen über eine Proxy-Schicht hinein. Die Bibliothek übernimmt Relay-Management und kryptografisches Signing für Event-Authentifizierung und funktioniert sowohl in Node.js- als auch in Browser-Umgebungen.

CVMI stellt ein CLI für Server-Discovery und Methoden-Aufruf bereit. Relatr berechnet personalisierte Vertrauenswerte aus sozialer Graphdistanz kombiniert mit Profilvalidierung.

ContextVM positioniert sich als Brückenschicht: Bestehende MCP-Server gewinnen Nostr-Interoperabilität und behalten dabei ihre konventionellen Transports.

White Noise dokumentiert dezentrale Nutzersuche

Ein Blogbeitrag von jgmontoya erläutert, wie White Noise die Nutzersuche über das dezentrale Relay-Netzwerk handhabt.

Die Verteilung von Profilen schafft die Herausforderung: Anders als zentralisierte Messenger mit einheitlichen Datenbanken verteilen sich Nostr-Profile über Dutzende von Relays ohne zentralen Index. White Noise löst dies durch eine Producer-Consumer-Architektur, die parallel läuft.

Ein Producer-Prozess erweitert kontinuierlich den sozialen Graphen ausgehend von den Follows des Nutzers, ruft Follow-Listen in zunehmenden Abständen ab und stellt entdeckte pubkeys zur Profilauflösung in die Warteschlange. Der Consumer löst Treffer durch fünf zunehmend aufwändigere Stufen auf: lokale Nutzertabelle (schnellste), gecachte Profile aus vorherigen Suchen, verbundene Relays, Nutzer-Relay-Listen gemäß NIP-65 und direkte Abfragen an nutzerdeklarierten Relays (langsamste).

Kalte Suchen dauern etwa 3 Sekunden, während warme Suchen aus dem Cache auf rund 10 Millisekunden fallen. Für neue Nutzer ohne etablierte soziale Graphen injiziert das System gut vernetzte Bootstrap-Knoten, um die Suchfunktion sicherzustellen. Gruppenmitgliedschaft liefert ein implizites soziales Signal neben expliziten Follows.

Instrumentierung erwies sich laut Autor als entscheidend für die Optimierung. Ohne Metriken war Verbesserung reines Raten.

FIPS: Nostr-natives Mesh-Networking

FIPS (Free Internetworking Peering System) ist eine funktionierende Rust-Implementierung eines selbstorganisierenden Mesh-Netzwerks, das Nostr-Schlüsselpaare (secp256k1) als Knotenidentitäten verwendet. Die Design-Dokumentation begleitet funktionalen Code.

Das Protokoll adressiert Infrastruktur-Unabhängigkeit: Knoten entdecken sich automatisch ohne zentrale Server oder Zertifizierungsstellen. Ein Spanning-Tree bietet koordinatenbasiertes Routing, während bloom filter Erreichbarkeitsinformationen verbreiten und Knoten Weiterleitungsentscheidungen mit rein lokalem Wissen treffen lassen. Transport-Agnostizismus bedeutet, dass dasselbe Protokoll über UDP, Ethernet, Bluetooth, LoRa-Radio oder jedes datagrammfähige Medium funktioniert.

Zwei Verschlüsselungsschichten schützen den Traffic. Link-Layer-Verschlüsselung (Noise-IK-Muster) sichert Hop-für-Hop-Kommunikation zwischen Nachbarn mit gegenseitiger Authentifizierung und Forward Secrecy. Session-Layer-Verschlüsselung (Noise-XK-Muster) bietet Ende-zu-Ende-Schutz gegen Zwischenrouter, wobei nur das Ziel die Nutzlast entschlüsseln kann. Dies spiegelt wider, wie TLS HTTP-Traffic schützt, auch wenn er nicht vertrauenswürdige Netzwerke traversiert.

Die Architektur verwendet einen “Greedy Embedding”-Spanning-Tree für das Routing. Jeder Knoten erhält Koordinaten basierend auf seiner Position relativ zur Baumwurzel und dem Elternknoten. Pakete werden gierig zu Koordinaten weitergeleitet, die dem Ziel näher sind, wobei bloom filter erreichbare Endpunkte bekannt machen. Wenn gieriges Routing versagt (lokale Minima), können Knoten auf baumbasierte Pfade zurückfallen.

Die Rust-Implementierung umfasst bereits UDP-Transport mit bloom-filter-basierter Discovery. Zukünftige Arbeit zielt auf Nostr-Relay-Integration für Peer-Bootstrapping.

Releases

Diese Woche brachte Releases bei Relay-Infrastruktur und Client-Anwendungen, wobei auch neue Projekte in den Bereich eintraten.

HAVEN v1.2.0

HAVEN, das All-in-One-Persönlichkeitsrelay, das vier Relay-Funktionen mit einem Blossom-Medienserver bündelt, lieferte v1.2.0. Dieser Release verlässt die RC-Phase, die letzte Woche behandelt wurde.

Multi-npub-Unterstützung erlaubt es einer einzigen HAVEN-Instanz, mehrere Nostr-Identitäten durch Whitelisting zu bedienen, mit neuer Blacklisting-Funktionalität für Zugangskontrolle. Das Backup-System wurde neu geschrieben: Es verwendet das portable JSONL-Format, und ein haven restore-Befehl importiert Notizen aus diesen Dateien. Cloud-Storage-Integration fügt --to-cloud- und --from-cloud-Flags für Remote-Backup-Management hinzu.

Web-of-Trust-Verbesserungen umfassen konfigurierbare Tiefenebenen für Vertrauensberechnungen und automatische 24-Stunden-Aktualisierungsintervalle mit Lock-freier Optimierung zur Reduzierung des Speicher-Overheads. Nutzeragent-Konfiguration für Relay-Anfragen und konfigurierbare Blastr-Timeout-Einstellungen runden den Release ab, zusammen mit Datenexport in komprimiertes JSONL.

White Noise v0.3.0

White Noise, die MLS-basierte verschlüsselte Messaging-App, die das Marmot-Protokoll implementiert, lieferte v0.3.0 mit über 160 gemergten Verbesserungen.

Dieser Release bringt Echtzeit-Messaging durch Streaming-Verbindungen statt Polling, sodass Nachrichten sofort ankommen. Amber-Unterstützung (NIP-55) bedeutet, dass private Schlüssel die App nie berühren müssen. Bild-Sharing funktioniert nun mit Upload-Fortschrittsanzeige und Blurhash-Platzhaltern während des Ladens. Vollbild-Anzeige unterstützt Pinch-to-Zoom.

Gruppen-Messaging erhielt Zuverlässigkeitsverbesserungen mit Chat-Listen, die Absendernamen anzeigen, und MLS-Verschlüsselung stellt Forward Secrecy sicher. Die Nutzersuche erweitert sich von Follows bis zu vier Trennungsgraden, mit Ergebnissen, die beim Auffinden eingestreamt werden.

Eine Breaking-Change setzt bei einem Upgrade alle lokalen Daten zurück aufgrund von Marmot-Protokolländerungen und dem Wechsel zu verschlüsseltem lokalen Speicher. Nutzer sollten nsec-Schlüssel vor dem Upgrade sichern.

diVine 1.0.5

diVine, der Kurzform-Looping-Video-Client auf der Basis restaurierter Vine-Archive, lieferte 1.0.5 mit umfangreichen Video-Wiedergabe-Fixes und einem neuen dezentralen Analytics-System.

Video-Wiedergabeprobleme dominierten die Fixes: Phantom-Pause, doppelter Ton zwischen Videos, schwarzer Blitz zwischen Thumbnails und ersten Frames sowie Abstürze durch verworfene Player sind alle behoben. Ein gepoolter Video-Player übernimmt nun den Home-Feed für konsistente Wiedergabe.

Kind-22236-ephemere View-Events ermöglichen Creator-Analytics und Empfehlungen. Das System verfolgt Traffic-Quellen (Home, Discovery-Varianten, Profil, Share, Suche) und Loop-Zählungen und filtert dabei Eigenaufrufe heraus. Lokale Dateipfad-Leaks in Nostr-Event-imeta-Tags werden mit kanonischen Blossom-URLs behoben, die clientseitig gemäß BUD-01-Spezifikation konstruiert werden.

NIP-46-Remote-Signer-Verbesserungen umfassen parallelisierte Relay-Verbindungen und Callback-URL-Unterstützung. Android stellt WebSocket-Verbindungen beim App-Resume nach Signer-Genehmigung wieder her.

Coracle 0.6.30

Coracle, der webbasierte Nostr-Client mit Fokus auf Relay-Management und Web-of-Trust-Moderation, lieferte 0.6.30 mit Video-Thumbnail-Unterstützung, was das Medien-Browsing in Feeds verbessert. Ebenfalls aktualisiert:

Nostur v1.26.0

Nostur, der iOS-Nostr-Client, lieferte v1.26.0 mit einem neuen Live-Streams-Feed-Bereich und einem neu gestalteten Einstellungsbildschirm. GIFs können nun auf Blossom-Medienservern gehostet werden, was die Abhängigkeit von zentralisierten Diensten reduziert. Klipy-GIFs-Integration bietet einen Fallback, wenn Tenor nicht verfügbar ist. Jahresüberschriften in DM-Gesprächen und Anzeige der Erwähnungsanzahl runden die nutzerseitigen Änderungen ab.

Entwickler-Werkzeuge und CLI-Apps erhielten diese Woche ebenfalls Updates.

nak v0.18.5

nak, fiatjafs Kommandozeilen-Schweizer-Taschenmesser für Nostr, lieferte v0.18.5 mit einem neuen nak profile-Unterbefehl zum Abrufen und Anzeigen von Nutzerprofilen. Der git clone-Befehl unterstützt nun NIP-05-Namen in nostr://-URIs und ermöglicht das Klonen von Repositories über menschenlesbare Identifikatoren. Zwei weitere Projekte lieferten ebenfalls Releases:

Pika v0.5.3

Pika, der MLS-verschlüsselte Messenger für iOS, Android und Desktop, der auf dem Marmot-Protokoll aufgebaut ist, lieferte v0.5.3. Aktuelle Commits fügen Datei-Upload und Drag-and-Drop-Medienunterstützung für die Desktop-App hinzu, neben Cloudflare-Workers-Deployment-Fixes.

Pika verwendet einen Rust-Kern, der die gesamte Geschäftslogik besitzt, während iOS (SwiftUI) und Android (Kotlin) als schlanke UI-Schichten fungieren, die Zustands-Snapshots rendern. MDK (Marmot Development Kit) stellt die MLS-Implementierung bereit. Das Projekt weist auf Alpha-Status hin und warnt vor dem Einsatz für sensible Workloads.

Ridestr v0.2.6

Ridestr, die dezentrale Mitfahrplattform mit Cashu-Zahlungen, lieferte v0.2.6. Dieser Release behebt TalkBack-Barrierefreiheitsprobleme und löst Bugs, bei denen Fahrer von der Nearby-Liste verschwanden, wenn sie die Zahlungsmethode wechselten, oder bei denen ausgewählte Fahrerzählungen nicht aktualisierten, wenn Fahrer offline gingen.

Das “Send to All”-Feature heißt nun “Broadcast RoadFlare” mit Fixes für stille Fehler bei frischen Fahrer-Installationen. Ridestr implementiert HTLC-Escrow für vertrauenslose Fahrtbezahlungen und NIP-60-Wallet-Sync über Geräte hinweg.

Unfiltered v1.0.6

Unfiltered, die Instagram-ähnliche Foto-Sharing-App für Android, lieferte v1.0.6 mit verbesserter Nutzersuche und automatischer Relay-Wiederverbindung alle 60 Sekunden.

Mit Kotlin und Jetpack Compose gebaut, verwendet Unfiltered rust-nostr-Bindings und Blossom-kompatible Server für Bild-Hosting. Amber-Integration (NIP-55) übernimmt sicheres Schlüsselmanagement. Die App zeigt Beiträge von gefolgten Accounts in chronologischer Reihenfolge ohne Algorithmen oder Werbung.

Diese Woche starteten auch zwei neue Messaging- und Signing-Projekte.

Burrow: MLS-Messaging für KI-Agenten

Burrow ist ein Messenger, der das Marmot-Protokoll für MLS-verschlüsselte Kommunikation ohne Telefonnummern oder zentralisierte Server implementiert. Sowohl menschliche Nutzer als auch KI-Agenten können teilnehmen.

Ein reiner Rust-CLI-Daemon mit JSONL-Ausgabemodus übernimmt die Integration mit automatisierten Systemen. Eine Flutter-Cross-Platform-App deckt Android, iOS, Linux, macOS und Windows ab. Medienanhänge werden zusammen mit Nachrichten verschlüsselt, und WebRTC übernimmt Audio- und Videoanrufe mit konfigurierbaren TURN-Servern.

Burrow schichtet MLS-Verschlüsselung auf Nostr-Infrastruktur. Identität verwendet Nostr-Schlüsselpaare (secp256k1), während MLS-KeyPackages als kind-443-Events veröffentlicht werden. Nachrichten verschlüsseln mit NIP-44 als kind-445-Events, und Willkommenseinladungen verwenden NIP-59-Gift-Wrapping.

OpenClaw-Integration ermöglicht KI-Agenten-Beteiligung mit vollem Werkzeugzugang. Zugangskontrolllisten mit Audit-Logging verwalten Kontakt- und Gruppenberechtigungen. Diese Kombination positioniert Burrow für Agent-zu-Agent- und Agent-zu-Mensch-Messaging-Szenarien, die Signal-Level-Verschlüsselung auf dezentraler Infrastruktur erfordern.

Nostria Signer Extension

Nostria Signer ist eine Chromium-basierte Browser-Erweiterung, die Vault- und Identitätsverwaltung für Nostr-Nutzer bietet.

Mehrere Vaults mit mehreren Accounts erlauben Nutzern, Identitäten für verschiedene Kontexte zu organisieren. Internationalisierung umfasst RTL-Sprachunterstützung. Mit Angular und TypeScript gebaut (79,2 % des Codebases), funktioniert sie sowohl als Browser-Erweiterung als auch als Progressive Web App.

Nostria Signer implementiert NIP-07 für Browser-Extension-Signing und ermöglicht webbasierten Nostr-Clients, Event-Signaturen anzufordern, ohne direkt auf private Schlüssel zugreifen zu müssen. Automatisierte Wallet-Migration übernimmt Updates, die über den Chrome Web Store verteilt werden. Nutzer können auch aus dem dist/extension-Ordner sideloaden.

Entwickler betonen den experimentellen Status: Nutzer müssen ihre eigenen geheimen Wiederherstellungsphrasen verwalten, da die Entwickler keinen Zugang zu verlorenen Schlüsseln wiederherstellen können.

Projekt-Updates

Formstr zieht in neue Organisation um

Formstr, die Google-Forms-Alternative auf Nostr, migrierte sein Repository von abh3po/nostr-forms zur formstr-hq-Organisation. Dieser OpenSats-Stipendienempfänger setzt die Entwicklung am neuen Standort fort.

Bemerkenswerte offene PRs

Laufende Arbeiten in Nostr-Projekten:

Damus Outbox-Modell (PR #3602): Implementierungsplan für das Gossip-/Outbox-Relay-Modell auf iOS. Diese Architekturänderung verbessert die Nachrichtenübermittlung durch Veröffentlichung an die Relays, auf denen Empfänger tatsächlich lesen.
Notedeck plattformübergreifende Benachrichtigungen (PR #1296): Natives Benachrichtigungssystem für den Damus-Desktop-Client, das Android FCM, macOS und Linux abdeckt.
NDK Cashu v3 Upgrade (PR #370): Aktualisiert die Wallet-Integration des Nostr Development Kit auf cashu-ts v3.
Zeus Cashu Offline (PR #3742): Offline-Ecash-Senden und -Empfangen für die Zeus-Lightning-Wallet.
Shopstr Encrypted Digital Delivery (PR #231): Fügt verschlüsselte Lieferung für digitale Güter mit dynamischer Gewichtsunterstützung für physische Artikel hinzu.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

Diese Woche gemergt:

NIP-85 Service-Provider-Auffindbarkeit: Die NIP-85-Spezifikation enthält nun Hinweise dazu, wie Clients vertrauenswürdige Assertion-Provider entdecken. Wenn ein Client Web-of-Trust-Scores oder andere berechnete Metriken benötigt, kann er Relays nach kind-30085-Ankündigungen von Providern abfragen, denen der Nutzer bereits folgt oder vertraut.
NIP-29 entfernt unverwaltete Gruppen: Die NIP-29-Gruppen-Chat-Spezifikation strich die Unterstützung für unverwaltete Gruppen (bei denen jedes Mitglied andere hinzufügen konnte). Alle NIP-29-Gruppen erfordern nun relay-seitiges Management mit expliziten Admin-Rollen, was Implementierungen vereinfacht und Spam-Vektoren reduziert.
NIP-11 entfernt veraltete Felder: NIP-11-Relay-Informationsdokumente enthalten nicht mehr die veralteten software- und version-Felder. Implementierungen sollten diese aus ihren Antworten entfernen.
NIP-39 verschiebt Identity-Tags: Externe Identitätsansprüche (NIP-39 i-Tags für GitHub, Twitter usw.) wurden von kind-0-Profilen in dedizierte kind-30382-Events verschoben. Dies trennt Identitätsverifizierung von Profil-Metadaten.

KI-Agenten-NIPs: Fortschritt:

Vier KI-fokussierte NIPs befinden sich weiterhin in aktiver Entwicklung. Seit der Berichterstattung der letzten Woche:

NIP-AE: Agents (aktualisiert 19. Feb): Definiert Agenten-Identität mit kind 4199 für Agenten-Definitionen und kind 4201 für Prompting (“Nudges”). Agenten können NIP-94-Datei-Metadaten für erweiterte Beschreibungen referenzieren.
NIP-XX: AI Agent Messages (aktualisiert 18. Feb): Standardisiert konversationelles Messaging mit sieben ephemeren Event-Kinds (25800-25806) für Status, Streaming-Deltas, Prompts, Antworten, Tool-Aufrufe, Fehler und Abbrüche, wobei kind-31340-“AI-Info”-Events Agenten erlauben, unterstützte Modelle und Fähigkeiten anzukündigen.
NIP-AC: DVM Agent Coordination (geöffnet 18. Feb): Erweitert NIP-90 für autonome Agenten-Workflows mit Heartbeats für Agenten-Discovery, Job-Reviews für Qualitätsverfolgung, Daten-Escrow für Ergebnisverpflichtung, Workflow-Ketten für mehrstufige Pipelines und Swarm-Bidding für wettbewerbliche Provider-Auswahl. Eine Referenzimplementierung läuft unter 2020117.xyz.
NIP-AD: MCP Server Announcements (geöffnet 12. Feb): Standardisiert die Ankündigung von Model-Context-Protocol-Servern und Skills auf Nostr. Bereits auf der TENEX-Plattform im Einsatz.

Weitere offene PRs:

NIP-144: Service Authorization Protocol: Definiert, wie Clients Identität und Berechtigungen gegenüber Dienstanbietern auf Nostr nachweisen.
NIP-DC: Nostr Webxdc: alexgleason schlägt die Integration von Webxdc (dezentralisierte Webanwendungen) mit Nostr-Events vor.

NIP Deep Dive: NIP-55 (Android Signer Application)

NIP-55 definiert, wie Android-Nostr-Clients kryptografische Operationen von dedizierten Signer-Anwendungen anfordern. Da White Noise v0.3.0 und Unfiltered v1.0.6 diese Woche beide Amber-Unterstützung hinzufügten, ist das Android-Signing-Protokoll eine nähere Betrachtung wert.

Kommunikationskanäle:

NIP-55 ermöglicht App-übergreifendes Signing durch zwei Mechanismen. Intents bieten manuelle Nutzergenehmigung mit visuellem Feedback für einmalige Operationen. Content-Resolver ermöglichen automatisiertes Signing, wenn Nutzer dauerhafte Berechtigungen erteilen, und lassen Apps im Hintergrund signieren ohne wiederholte Aufforderungen.

Die Kommunikation verwendet das benutzerdefinierte nostrsigner:-URI-Schema. Ein Client initiiert Kontakt mit:

nostrsigner:<base64-encoded-event>?type=sign_event&callbackUrl=myapp://callback

Unterstützte Operationen:

Die Spezifikation definiert sieben kryptografische Methoden: Event-Signing (sign_event), Public-Key-Abruf (get_public_key), NIP-04-Verschlüsselung/-Entschlüsselung, NIP-44-Verschlüsselung/-Entschlüsselung und Zap-Event-Entschlüsselung (decrypt_zap_event).

Berechtigungsmodell:

Clients rufen get_public_key einmal auf, um eine Vertrauensbeziehung herzustellen, und erhalten den Paketnamen des Signers und den pubkey des Nutzers. Die Spezifikation schreibt vor, dass Clients diese Werte speichern und get_public_key nie wieder aufrufen, um Fingerprinting-Angriffe zu verhindern.

Für Signing-Anfragen können Nutzer einmalig genehmigen oder “Meine Wahl merken” für Hintergrundoperationen erteilen. Wenn Nutzer Operationen konsistent ablehnen, gibt der Signer einen “abgelehnt”-Status zurück und verhindert wiederholte Aufforderungen.

Implementierungen:

Amber ist der primäre NIP-55-Signer für Android. Clients mit NIP-55-Unterstützung umfassen Amethyst, White Noise, Unfiltered und andere. Webanwendungen können Signer-Antworten nicht direkt empfangen und müssen Callback-URLs oder Zwischenablagen-Operationen verwenden.

Verhältnis zu anderen Signing-NIPs:

NIP-55 ergänzt NIP-07 (Browser-Erweiterungen) und NIP-46 (Remote-Signing über Relays). Während NIP-07 Desktop-Browser und NIP-46 geräteübergreifendes Signing abdeckt, bietet NIP-55 native Android-Integration mit minimaler Latenz.

NIP Deep Dive: NIP-60 (Cashu Wallet)

NIP-60 definiert, wie Cashu-Ecash-Wallets Zustände auf Nostr-Relays speichern und damit anwendungsübergreifende Wallet-Synchronisierung ermöglichen. Da Ridestr v0.2.6 NIP-60 für Wallet-Sync über Geräte nutzt, verdient das Protokoll eine Betrachtung.

Event-Kinds:

NIP-60 verwendet vier Event-Typen. Das ersetzbare kind 17375 speichert Wallet-Konfiguration einschließlich Mint-URLs und eines dedizierten privaten Schlüssels für den Empfang von P2PK-Ecash-Zahlungen. Token-Events (kind 7375) enthalten unverbrauchte kryptografische Beweise, während Ausgabenhistorie (kind 7376) Transaktionen für Nutzertransparenz aufzeichnet. Ein optionales kind 7374 verfolgt Mint-Zahlungsquotes.

Wallet-Architektur:

Der Wallet-Zustand lebt auf Relays und ist damit über Anwendungen hinweg zugänglich. Das Wallet-Event eines Nutzers enthält verschlüsselte Referenzen auf Cashu-Mints und einen wallet-spezifischen privaten Schlüssel, der vom Nostr-Identitätsschlüssel des Nutzers getrennt ist. Diese Trennung ist wichtig: Der Wallet-Schlüssel übernimmt Ecash-Operationen, während der Nostr-Schlüssel soziale Funktionen übernimmt.

{
 "kind": 17375,
 "content": "<nip44-encrypted-wallet-config>",
 "tags": [["d", "cashu-wallet"]]
}

Proof-Management:

Cashu-Beweise sind Inhaberinstrumente. Einmal ausgegeben, wird ein Beweis ungültig. NIP-60 verwaltet dies durch einen Rollover-Mechanismus: Beim Ausgeben erstellen Clients ein neues Token-Event mit verbleibenden unverbrauchten Beweisen und löschen das Original via NIP-09. Gelöschte Token-IDs kommen in ein del-Feld für Zustandsverfolgung.

Clients sollten Beweise regelmäßig gegen Mints validieren, um zuvor ausgegebene Anmeldeinformationen zu erkennen. Mehrere Token-Events pro Mint sind zulässig, und Ausgabenhistorie-Events helfen Nutzern, Transaktionen zu verfolgen, obwohl sie optional sind.

Sicherheitsmodell:

Alle sensiblen Daten verwenden NIP-44-Verschlüsselung. Der private Wallet-Schlüssel erscheint nie im Klartext. Da Relays verschlüsselte Blobs speichern, ohne deren Inhalt zu verstehen, bleibt der Wallet-Zustand auch auf nicht vertrauenswürdigen Relays privat.

Implementierungen:

Wallets mit NIP-60-Unterstützung umfassen Nutsack und eNuts. Clients wie Ridestr verwenden NIP-60 für geräteübergreifenden Sync und ermöglichen Nutzern, auf dem Desktop aufzuladen und vom Mobilgerät aus auszugeben, ohne manuelle Überweisungen.

Das war’s für diese Woche. Wer etwas baut oder Neuigkeiten zu teilen hat: Per NIP-17 DM erreichbar oder auf Nostr findbar.

Nostr Compass #10

Wed, 18 Feb 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Eine Blossom-Local-Cache-Schicht nimmt Gestalt an, da unabhängige Projekte auf Offline-Medienzugriff für Android konvergieren. Alby startet eine NWC-Entwickler-Sandbox zum Erstellen und Testen von Nostr Wallet Connect-Integrationen ohne echte Mittel zu riskieren. Konkurrierende Vorschläge für KI-Agenten-Kommunikation auf Nostr erscheinen in derselben Woche von zwei Autoren. fiatjaf entfernt ungenutzte Felder aus NIP-11 und streicht Aufbewahrungsrichtlinien, Ländercodes, Datenschutzrichtlinien und Community-Präferenz-Tags, die Relay-Betreiber nie übernommen haben. NIP-85 mergt Hinweise zur Service-Provider-Auffindbarkeit für Trusted Assertions. Ein neuer D-Tag in NIP-52 ermöglicht tagesgranulares Timestamp-Indexing von Kalender-Events. Neue Projekte umfassen Mapnolia für dezentrale Kartenkachel-Verteilung, Pika für MLS-verschlüsseltes Messaging, Keep für FROST-Threshold-Signing auf Android, Hashtree für inhaltsadressierten Speicher mit Nostr-Integration und Prism zum Teilen von Inhalten auf Nostr aus jeder Android-App. Primal Android mergt 11 NWC-PRs mit Dual-Wallet-Unterstützung und automatischem Service-Lebenszyklus. Mostro Mobile liefert eine eingebaute Lightning-Wallet durch NWC-Integration. Notedeck bereitet die Veröffentlichung im Android App Store vor, während HAVEN v1.2.0-rc3 mit Multi-npub-Unterstützung und Cloud-Backup erreicht. Die Deep Dives dieser Woche behandeln NIP-85s Trusted Assertions-System zur Delegation von Web-of-Trust-Berechnungen an Service Provider sowie NIP-52s Kalender-Events-Protokoll nach dem tagesgranularen Indexierungs-Update.

Neuigkeiten

Blossom Local Cache Layer entsteht

Mehrere unabhängige Projekte konvergieren auf dasselbe Problem: Offline-Zugriff auf Blossom-Medien auf Mobilgeräten.

Morganite, eine neue Android-App von greenart7c3 (dem Entwickler hinter Amber und Citrine), implementiert clientseitiges Caching für Blossom-Medien. Nutzer können zuvor angezeigte Bilder und Dateien ohne Netzwerkverbindung aufrufen.

Aerith lieferte v0.2 mit Bildmarkierung, Massen-Mirror-/Tag-/Löschoperationen, Filterung nach Bezeichnung und Dateityp sowie erster lokaler Blossom-Cache-Unterstützung. Aerith ist eine Verwaltungsoberfläche für Nutzer, die Medien über mehrere Blossom-Server verteilt speichern und ihre Blobs organisieren und spiegeln müssen.

Ein neuer Leitfaden zur lokalen Cache-Implementierung in der Blossom-Spezifikation dokumentiert clientseitigen Blob-Speicher, während Prism (vom selben Entwickler wie Aerith) Blossom-Upload-Integration in seinen Android-Share-to-Nostr-Ablauf integriert. Vier unabhängige Projekte konvergierten diese Woche auf dasselbe Problem: eine dedizierte Caching-App, ein Medienmanager, eine Referenzspezifikation und ein Share-Tool mit Blossom-Integration – alle implementieren persistenten lokalen Speicher über einfaches Upload-und-Abrufen hinaus.

Alby NWC-Entwickler-Sandbox

Alby hat eine Sandbox-Umgebung für Entwickler gestartet, die mit Nostr Wallet Connect (NIP-47) arbeiten. Die Sandbox bietet einen gehosteten NWC-Wallet-Dienst, mit dem Entwickler Testverbindungen erstellen und simulierte Zahlungen senden können, ohne eine echte Lightning-Wallet anzubinden – und dabei den vollständigen Request-Response-Zyklus von NWC-Events in Echtzeit beobachten können. Entwickler erzeugen einen nostr+walletconnect://-Verbindungsstring aus der Sandbox und übergeben ihn an ihren Client. Die Sandbox zeigt dann die resultierenden kind-23194-Request- und kind-23195-Response-Events an, während sie zwischen Client und Wallet-Dienst fließen.

Dies senkt die Einstiegshürde für neue NWC-Integrationen. Bisher erforderte das Testen entweder eine persönliche Lightning-Wallet oder einen selbst gehosteten NWC-Dienst. Die Sandbox abstrahiert das weg und gibt Entwicklern eine sofortige Feedback-Schleife für die Implementierung von pay_invoice, get_balance, make_invoice, lookup_invoice und list_transactions gegen einen Live-NWC-Endpunkt.

KI-Agenten-NIPs erscheinen

Vorschläge für KI-Agenten-Kommunikation auf Nostr erschienen innerhalb weniger Tage voneinander und nähern sich dem Problem aus verschiedenen Blickwinkeln.

NIP-XX: AI Agent Messages von joelklabo definiert ein vollständiges Protokoll für KI-Agenten-Interaktion: Event-Kinds für Prompts, Antworten, Streaming-Deltas, Status-Updates, Tool-Telemetrie, Fehler, Abbrüche und Fähigkeits-Erkennung. Ein ai.info-Discovery-Event (kind 31340, ersetzbar) ermöglicht Agenten, ihre unterstützten Modelle, Tools mit Schemata, Streaming-Unterstützung und Rate-Limits anzukündigen. joelklabos Vorschlag umfasst Run-Korrelation via Prompt-ID, Session-Management, Stream-Abgleich mit Sequenzordnung und NIP-59-Hinweise für Metadaten-Privatsphäre.

NIP-AE: Agents von pablof7z verfolgt einen anderen Ansatz und definiert Kinds für Agenten-Instanziierung: Definitionen und Lektionen. Das sind die Event-Typen, die pablof7z in TENEX verwendet, dem autonomen Lernsystem auf Nostr. Ein Begleitvorschlag, NIP-AD: MCP Server and Skill Announcements, ebenfalls von pablof7z, definiert Events zur Ankündigung von Model Context Protocol-Servern und Skills auf Nostr. NIP-22-Kommentare werden unterstützt, sodass die Community MCP-Server direkt auf Nostr diskutieren und bewerten kann.

NIP-XX deckt vollständige Agenten-Kommunikation ab, während NIP-AE und NIP-AD Identität und Tool-Discovery adressieren. Diese Vorschläge könnten zu einem einheitlichen Standard konvergieren oder als komplementäre Schichten koexistieren.

Releases

HAVEN v1.2.0-rc3

HAVEN, das All-in-One-Persönlichkeitsrelay, das vier Relay-Funktionen mit einem Blossom-Medienserver bündelt, erreichte v1.2.0-rc3. Dieser Release-Kandidat fügt Unterstützung für mehrere npubs hinzu und ermöglicht es einer einzigen HAVEN-Instanz, mehrere Nostr-Identitäten zu bedienen. Frühere RCs fügten --from-cloud- und --to-cloud-Flags für Cloud-Backup hinzu (RC2) und behobenen einen Web-of-Trust-Doppelzählungsfehler (RC1).

Mostro Mobile v1.2.0: Eingebaute Lightning-Wallet

Mostro Mobile, der Mobile-Client für die Mostro P2P-Bitcoin-Börse (v1.1.0 letzte Woche behandelt), lieferte v1.2.0 mit einer eingebauten Lightning-Wallet durch vollständige NWC (NIP-47)-Integration. Käufer und Verkäufer müssen nicht mehr zwischen Apps wechseln, um Rechnungen zu bearbeiten. Die App erkennt Hold-Invoices für Verkäufer und bezahlt sie automatisch über die verbundene Wallet, während Käufer automatische Rechnungserstellung erhalten. Dem Release folgte v1.1.1 aus früherer Woche, das Multi-Mostro-Node-Unterstützung mit einem kuratierten Register vertrauenswürdiger Instanzen, kind-0-Metadaten-Abruf für Node-Anzeige, benutzerdefiniertes Node-Management per pubkey und automatischen Fallback bei Offline-Nodes hinzufügte.

Serverseitig landete Mostro v0.16.2 mit Fixes für doppelte Dev-Fee-Zahlungen, Rate-Limiting am Passwortvalidierungs-RPC-Endpunkt und ordentliches Dispute-Cleanup bei kooperativem Abbruch.

Ein neues Begleitprojekt, mostro-skill, ermöglicht Agenten den Handel auf Mostro über Nostr.

Aerith v0.2

Aerith, der Blossom-Bildmanager, lieferte v0.2 mit Bildbezeichnungen zur Medienorganisation, Massen-Mirror-/Tag-/Löschoperationen über Server hinweg, Filterung nach Bezeichnung und Dateityp sowie erster lokaler Cache-Unterstützung. Siehe Neuigkeiten-Abschnitt für den Kontext zum übergreifenden Local-Cache-Trend.

Mapnolia: Dezentrale Kartenkacheln über Nostr

Mapnolia ist ein neuer Geodaten-Server, der PMTiles-Kartenarchive in geografische Regionen unterteilt und sie über Nostr zur dezentralen Auffindbarkeit ankündigt. Er veröffentlicht kind-34444-parametrisierte ersetzbare Events an Nostr-Relays, die einen vollständigen Index von Kartenkachel-Chunks mit Layer-Metadaten, Geohash-Regionen, Dateireferenzen und Blossom-Server-Details enthalten.

Clients entdecken und rufen Kartendaten über das Nostr-Netzwerk ab statt über zentralisierte Kachel-Server, wobei Ankündigungs-Events genug Metadaten tragen, um nur die benötigten geografischen Regionen von aufgeführten Blossom-Servern anzufordern. Mapnolia ist das erste Projekt, das Geodaten-Verteilung zu Nostr bringt und Möglichkeiten für offline-fähige Kartenanwendungen eröffnet.

Pika: Marmot-basiertes verschlüsseltes Messaging

Pika ist eine neue Ende-zu-Ende-verschlüsselte Messaging-App für iOS und Android, die das Marmot-Protokoll nutzt, das Messaging Layer Security (MLS) über Nostr-Relays schichtet. Die Architektur trennt Zuständigkeiten in einen Rust-Kern (pika_core), der MLS-Zustandsverwaltung und Nachrichten-Verschlüsselung/-Entschlüsselung über Nostr-Relays übernimmt, mit schlanken nativen UI-Schalen in SwiftUI (iOS) und Kotlin (Android). Der Zustand fließt unidirektional: die UI versendet Aktionen an den Rust-Actor, der den Zustand mutiert und Snapshots mit Revisionsnummern per UniFFI- und JNI-Bindungen zurück an die UI emittiert.

Pika reiht sich in ein wachsendes Feld von MLS-on-Nostr-Messengern ein, neben White Noise, Vector und 0xchat. Alle nutzen Nostr-Relays als Transportschicht für MLS-verschlüsselten Ciphertext und halten Relay-Betreiber davon fern, Nachrichteninhalte zu lesen. Pika verwendet das Marmot Development Kit (MDK) für seine MLS-Implementierung und nostr-sdk für Relay-Konnektivität.

Keep: FROST-Threshold-Signing für Android

Keep ist eine neue Android-Anwendung für FROST-Threshold-Signing, bei dem kein einzelnes Gerät den vollständigen privaten Schlüssel hält. Es implementiert NIP-55 (Android Signer) und NIP-46 (Remote-Signing), sodass kompatible Nostr-Clients Signaturen anfordern können, während das Schlüsselmaterial über Geräte verteilt bleibt. Die Standardkonfigurationen sind 2-von-3 und 3-von-5, wobei jeder t-von-n-Schwellenwert unterstützt wird.

Keeps verteilte Schlüsselgenerierung (DKG) läuft über Nostr-Relays mit benutzerdefinierten Event-Kinds: kind 21101 für Gruppenankündigungen, kind 21102 für Round-1-Commitment-Polynome (öffentlich übertragen) und kind 21103 für Round-2-Geheimschlüsselanteile (NIP-44 verschlüsselt Punkt-zu-Punkt zwischen Teilnehmern). Der private Gruppenschlüssel-Skalar wird während des DKG nirgends berechnet oder zusammengesetzt. Jedes Gerät hält nur seinen Polynomauswertungs-Anteil, und jede t-Anteile können durch ein Zwei-Runden-Commit-then-Sign-Protokoll eine gültige Schnorr-Signatur erzeugen. Die resultierende 64-Byte-Signatur ist von einer Single-Signer-Schnorr-Signatur nicht zu unterscheiden. Intern verwendet Keep die frost-secp256k1-tr-Crate der Zcash Foundation mit Taproot-Tweaking, sodass der Gruppen-Public-Key direkt als Nostr-npub funktioniert.

Keep reiht sich in die Frostr-Projektfamilie ein, neben Igloo Desktop, Igloo für Android, Frost2x und Igloo für iOS, und erweitert die Optionen für Threshold-Key-Management auf Nostr.

Prism: Alles von Android aus auf Nostr teilen

Prism ist eine neue Android-App (Kotlin/Jetpack Compose, API 26+), die sich als System-Share-Ziel registriert und Nutzern ermöglicht, Text, URLs, Bilder und Videos aus jeder App auf ihrem Telefon auf Nostr zu veröffentlichen. Geteilte URLs durchlaufen einen Tracking-Parameter-Stripper, bevor sie zu Notizen komponiert werden. Prism ruft OpenGraph-Metadaten ab, um reichhaltige Link-Vorschauen zu generieren, und rendert native Nostr-Referenzen (note1, nevent1) inline.

Die Scheduling-Engine verwendet einen hybriden AlarmManager/WorkManager-Ansatz, um Android-Batterieoptimierungen zu umgehen: AlarmManager übernimmt präzises Aufweck-Timing, während expedited WorkManager-Tasks die Zustellung sicherstellen, mit exponentiellem Backoff-Retry für Offline-Szenarien. Medien-Uploads laufen über konfigurierbare Blossom-Server mit Thumbnail-Generierung für Bilder und Video-Frames. Das gesamte Event-Signing wird an NIP-55-externe Signer wie Amber delegiert, mit Multi-Account-Unterstützung zum Wechseln zwischen Identitäten. Prism unterstützt auch NIP-84 (Highlights)-Posts. Vom selben Entwickler wie Aerith.

Hashtree: Inhaltsadressierter Speicher mit Nostr-Integration

Hashtree ist ein dateisystembasiertes inhaltsadressiertes Blob-Speichersystem, das Merkle-Wurzeln auf Nostr veröffentlicht, um veränderbare npub/Pfad-Adressen zu erzeugen. Das System verwendet „dumb storage", das mit jedem Key-Value-Store funktioniert und Inhalte in 2-MB-Blöcke unterteilt, die für Blossom-Uploads optimiert sind. Anders als BitTorrent wird keine aktive Merkle-Proof-Berechnung benötigt – Blobs werden einfach per Hash gespeichert und abgerufen.

Die Nostr-Integration ermöglicht Git-Remote-URLs wie htree://npub.../repo-name zum Klonen von Repositories, mit Befehlen wie htree publish mydata <hash> zum Veröffentlichen von Inhalts-Hashes unter npub.../mydata-Adressen. Das umfassende CLI unterstützt verschlüsselte (Standard) und öffentliche Speichermodi, Content-Pinning, Push zu Blossom-Servern und Verwaltung von Nostr-Identitäten. Jedes gespeicherte Element ist entweder rohe Bytes oder ein Baumknoten und bietet eine Grundlage für dezentrale Inhaltsverteilung über Nostrs Relay-Netzwerk.

Espy: Farbpaletten-Erfassung auf Shakespeare

Espy, aufgebaut auf der Shakespeare-Plattform, ermöglicht Nutzern die Erfassung von Farbpaletten aus Fotos und deren Teilen als Nostr-Events. Shakespeare ist ein KI-gestützter App-Builder, der Nutzer über NIP-07-Browser-Erweiterungen authentifiziert und eingebaute Nostr-Relay-Konnektivität bietet, sodass Entwickler Apps ohne eigene Schlüsselverwaltung oder Relay-Pool ausliefern können. Espy extrahiert dominante Farben aus Kamerainput in teilbare Palettenkarten, die über Standard-Nostr-Feeds auffindbar sind.

Flotilla 1.6.4

Flotilla, hodlbods Discord-ähnlicher Nostr-Client, der Relays als Gruppen organisiert, lieferte 1.6.4. Die Coracle-Projektfamilie ist von GitHub auf eine selbst gehostete Gitea-Instanz umgezogen. Dieses Release fügt Push-Benachrichtigungen via NIP-9a und einen Wallet-Empfangsablauf hinzu, sowie klassifizierte Einträge und Space-URL-Unterstützung. Verbesserungen der Oberfläche umfassen aufgeräumte Modals und Benachrichtigungs-Handling. Raum-Stummschaltung und sichere Bereichs-Einfügungen auf Mobilgeräten runden die Änderungen ab, begleitet von Fixes für Safari-Bild-Uploads und Kalender-Event-Details.

Shosho v0.12.0

Shosho, die mobile Live-Streaming-App mit Nostr-Integration, lieferte v0.12.0. Dieses Release fügt Video-Clips mit In-Player-Antworten und benutzerdefinierter Emoji-Integration hinzu. Thread-Schutz blockiert indirekten Erwähnungs-Spam, und eine neue QR-Teilen-Funktion ermöglicht Nutzern den Offline-Profilaustausch. Ein neuer horizontaler Wiedergabemodus gibt Streams eine Twitch-ähnliche Betrachtungserfahrung, und der Stöbern-Bildschirm zeigt nun Creator-Clips neben Live-Streams.

Granary v10.0

Granary, eine Social-Web-Übersetzungsbibliothek, die Daten zwischen Nostr, Bluesky, ActivityPub und anderen Plattformen in ein gemeinsames Format konvertiert, lieferte v10.0 mit Breaking Changes. Das Release wechselt Nostrs Standard-ActivityStreams-1-IDs von bech32 zu Hex und fügt erweiterte Nostr-Unterstützung hinzu, einschließlich NIP-27-Erwähnungs-Parsing und Artikel-Tags. Eine neue Mehrfach-Ausgabe-Option über Konverter hinweg ermöglicht Entwicklern die Massenübersetzung zwischen Protokollen.

Nostr MCP Server v3.0.0

Nostr MCP Server, ein Model Context Protocol-Server, der KI-Agenten die Interaktion mit dem Nostr-Netzwerk ermöglicht, lieferte v3.0.0. Dieses Major-Release fügt soziale Aktionen (Follows, Reaktionen, Reposts, Antworten) und Relay-Listen-Management mit NIP-65-Unterstützung plus optionaler NIP-42-Authentifizierung hinzu. Direktnachrichten via NIP-17 und NIP-44 sind ebenfalls neu. Das Release ergänzt die dieswöchigen KI-Agenten-NIP-Vorschläge als praktisches Tooling für Agenten auf Nostr.

Aegis v0.3.8

Aegis, der plattformübergreifende Nostr-Signer, lieferte v0.3.8 mit mehrsprachiger UI-Unterstützung und einem inkrementellen Update-Manager für seinen eingebauten Nostr-App-Browser. Der neue Update-Mechanismus vergleicht inkrementell gegen den lokalen Zustand und hält das In-App-Verzeichnis der Nostr-Web-Apps mit geringerem Bandbreitenverbrauch aktuell. Das Release führt außerdem 5-Minuten-Schlüsselmaterial-Caching ein, um Datenbank-Round-Trips beim Signieren mehrerer Events in Folge zu reduzieren.

SNSTR v0.3.1

SNSTR (Secure Nostr Software Toolkit for Renegades), eine TypeScript-Bibliothek für das Nostr-Protokoll, lieferte v0.3.1. Das Release fügt Paketverifizierungs-Guards hinzu, die sicherstellen, dass alle Einstiegspunkte in npm-Tarballs enthalten sind, mit CI-Durchsetzung auf Node und Bun. v0.3.0 erschien in derselben Woche.

Citrine v2.0.0-pre1

Citrine, das Android-Nostr-Relay von greenart7c3, veröffentlichte v2.0.0-pre1 mit Performance-Verbesserungen durch optimierte Datenbankindizes und besseres Kotlin-Coroutine-Handling. Das Release verbessert außerdem die Unterstützung für das Hosting von Web-Apps, wobei jede App nun auf einem eigenen Port läuft.

Projekt-Updates

Primal Android: NWC-Infrastrukturausbau

Primal Android mergte diese Woche 11 NWC-bezogene PRs und setzt den Ausbau fort, der vor zwei Wochen begonnen wurde. Dieser Batch fügt Dual-Wallet-NWC-Unterstützung hinzu, automatischen Service-Start/Stopp gekoppelt an Backend-Benachrichtigungen, Verbindungsrouting nach Wallet-Typ und ordentliche Datenbereinigung bei Wallet-Löschung. Der NWC-Dienst verwaltet nun seinen eigenen Lebenszyklus basierend auf dem Wallet-Verbindungsstatus und reduziert manuellen Benutzereingriff.

Notedeck: Android-App-Store-Vorbereitung

Notedeck, der plattformübergreifende Nostr-Client vom Damus-Team, mergte diese Woche die Vorbereitung für die Android-App-Store-Veröffentlichung. Der PR fügt einen UGC (User Generated Content)-Compliance-Plan hinzu, der von Google Play gefordert wird, einschließlich eines Nutzungsbedingungs-Akzeptanzbildschirms, Nutzerblockierung über Kontextmenüs und Einstellungen, NIP-56 (Meldungen)-Funktionalität, die Report-Events an Relays veröffentlicht, und eines Abschnitts für Inhalts- und Sicherheitseinstellungen. Build-Infrastruktur wurde für die Generierung signierter Release-APKs und AABs (Android App Bundles) via neue Makefile-Ziele hinzugefügt. Ein EULA-Dokument legt eine Altersanforderung von 17+ und Nostr-spezifische Haftungsausschlüsse über dezentrale Inhalte fest. Die Compliance-Features selbst erscheinen in Follow-up-PRs; dieser Merge legt die Dokumentations- und Signierungsgrundlage.

Auf der Damus-iOS-Seite landete ein Fix für eine endlos drehende Lade-Spinner-Regression, bei der der Spinner unbegrenzt weiter lief, nachdem Inhalte bereits geladen waren.

Nostria: Discovery-Relays und DM-Fixes

Nostria, der plattformübergreifende Nostr-Client mit Fokus auf globale Skalierung, mergte diese Woche 9 PRs. Der bemerkenswerteste fügt Auto-Initialisierung von Discovery-Relays für Profil-Lookup hinzu und gibt neuen Nutzern funktionierende Relay-Konnektivität ohne manuelle Konfiguration. Weitere Fixes adressieren DM-Textarea-Umbruch, Vollbild-Video-Viewport-Füllung, Artikel-Metadaten-Extraktion in Repost-Vorschauen und nostr:-URI-Auflösung in Benachrichtigungen.

Camelus: Riverpod-v3-Migration

Camelus, der Flutter-basierte Nostr-Client, mergte diese Woche 5 PRs, die auf eine Riverpod-v3-API-Migration und ein generisches Feed-Refactoring zentriert sind. Ein eingebetteter Notizen-Cache vermeidet redundante Relay-Abrufe für zitierte Notizen.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

Gemergt:

NIP-85: Service-Provider-Auffindbarkeit: vitorpamplona fügte Hinweise zur Client-Discovery von NIP-85 Trusted Assertions-Service-Providern hinzu, einschließlich Relay-Hints und algorithmusspezifischer Service-Schlüssel. Siehe den Deep Dive unten für vollständige Berichterstattung.
NIP-11: Relay-Informations-Bereinigung: fiatjaf entfernte privacy_policy, das retention-Array, relay_countries und den Community-Präferenz-Block aus NIP-11. Relay-Betreiber befüllten diese Felder selten, und Clients handelten nicht danach.
NIP-52: Tagesgranularer Timestamp-Tag: staab fügte einen erforderlichen D-Tag zu NIP-52 zeitbasierten Kalender-Events (kind 31923) hinzu, der den tagesgranularen Unix-Timestamp darstellt, berechnet als floor(unix_sekunden / 86400). Mehrere D-Tags decken mehrtägige Events ab und ermöglichen effizientes temporales Indexing ohne Parsing vollständiger Timestamps.
NIP-47: Vereinfachung: Der Vereinfachungs-PR in Newsletter #9 diskutiert mergte diese Woche und entfernte multi_pay_invoice und multi_pay_keysend aus NIP-47 (Nostr Wallet Connect). Siehe Newsletter #8 für den vollständigen NWC-Protokoll-Deep-Dive.

Offene PRs und Diskussionen:

NIP-74: Podcasts: In Newsletter #8 behandelt, erlebte dieser Podcast-Spezifikationsvorschlag diese Woche hitzige Diskussionen. staab wies darauf hin, dass mindestens drei konkurrierende Podcast-Standards bereits in freier Wildbahn existieren, und derekross verwies auf eine bestehende sechsmonatige Implementierung mit aktiven Apps und Podcasts. Der Weg nach vorne erfordert Konvergenz zwischen Implementierungen, bevor eine NIP-Nummer zugewiesen werden kann.
NIP-XX: KI-Agenten-Nachrichten: joelklabo schlägt ein vollständiges KI-Agenten-Kommunikationsprotokoll mit Event-Kinds für Prompts, Antworten, Streaming, Tool-Telemetrie, Fehler und Fähigkeits-Discovery vor. Siehe Neuigkeiten-Abschnitt für Berichterstattung zu allen KI-Vorschlägen dieser Woche.
NIP-PNS: Privater Notizen-Speicher: jb55s privates Notizen-System definiert kind-1080-Events zur Speicherung verschlüsselter persönlicher Notizen auf Relays, ohne preiszugeben, wer sie geschrieben hat. Das Schema leitet ein deterministisches pseudonymes Schlüsselpaar aus dem nsec des Nutzers via HKDF ab: pns_key = hkdf_extract(ikm=device_key, salt="nip-pns"), dann wird ein secp256k1-Schlüsselpaar aus diesem abgeleiteten Schlüssel generiert. Eine zweite Ableitung produziert einen symmetrischen Verschlüsselungsschlüssel: pns_nip44_key = hkdf_extract(ikm=pns_key, salt="nip44-v2"). Innere Notizen werden mit NIP-44 v2 mit diesem Schlüssel verschlüsselt und unter dem pseudonymen pubkey veröffentlicht, sodass Relays kind-1080-Events von einer Identität sehen, die nicht mit dem Hauptschlüssel des Nutzers verknüpft ist. Anders als NIP-59 Gift Wraps ist PNS nicht spam-anfällig (der pseudonyme Schlüssel ist deterministisch, nicht zufällig) und trägt keine öffentlichen Metadaten (keine p-Tags erforderlich, da es keinen Empfänger gibt). Diese Woche veröffentlichte jb55 Erkenntnisse aus der PNS-Implementierung in Notedecks Rust-Backend (enostr::pns-Modul). Er identifizierte, dass der hkdf_extract-Aufruf der Spezifikation mehrdeutig ist, weil RFC-5869-HKDF zwei Phasen (Extract und Expand) hat, die unterschiedliche Ausgaben produzieren, und die meisten Bibliotheken beide erwarten. Er stellte klar, dass pns_nip44_key NIP-44s normalen ECDH-Schlüsselaustausch umgeht und direkt als Konversationsschlüssel verwendet wird – ein Detail, das Implementierer kennen müssen, da die meisten NIP-44-Bibliotheken standardmäßig ECDH verwenden. Er flaggte auch eine undefinierte Variable in der Referenzimplementierung in TypeScript. Der PR, ursprünglich aus April 2025, wird nun aktiv implementiert.
NIP-AE: Agents: pablof7z definiert vier Event-Kinds für Agenten-Identität auf Nostr, aus seiner Arbeit an TENEX herleitet. Die Basisvorlage ist kind 4199 (Agent Definition), mit Titel, Rollenbeschreibung, Systemanweisungen, Tool-Deklarationen und Version. Verhaltensmodifikatoren leben in kind 4201 (Agent Nudge), das only-tool-, allow-tool- und deny-tool-Tags für Laufzeit-Fähigkeitskontrolle verwendet. Agenten veröffentlichen, was sie lernen, als kind-4129 (Agent Lesson)-Events, kategorisiert und zurückverknüpft zur übergeordneten Definition via e-Tags, verfeinerbar durch NIP-22-Kommentar-Threads. Eigentümerschaftsverifikation verwendet kind 14199, ein ersetzbares Event, bei dem menschliche Betreiber ihre Agenten-pubkeys auflisten und damit eine bidirektionale Kette etablieren, wenn sie mit dem p-Tag des kind-0-Profils des Agenten abgeglichen werden.
NIP-AD: MCP-Server- und Skill-Ankündigungen: pablof7z definiert Events zur Ankündigung von Model Context Protocol-Servern und einzelnen Skills auf Nostr. MCP-Server-Ankündigungen tragen die Endpunkt-URL und die unterstützte Protokollversion zusammen mit einer Liste verfügbarer Tools mit ihren Eingabe-Schemata. NIP-22-Kommentare werden auf Server-Ankündigungen unterstützt, sodass die Community MCP-Server direkt auf Nostr diskutieren und bewerten kann.
NIP-73: OSM-Tag-Kind: DestBro schlägt vor, OpenStreetMap-Identifikatoren zu NIP-73 (Externe Inhalts-IDs) hinzuzufügen, das standardisiert, wie Nostr-Events externe Inhalte wie Bücher (ISBN), Filme (ISAN), Podcast-Feeds (GUID), Geohashes und URLs via i- und k-Tags referenzieren. Der vorgeschlagene OSM-Kind würde Events ermöglichen, spezifische Kartenfunktionen (Gebäude, Straßen, Parks) durch ihre OpenStreetMap-Knoten- oder Weg-ID zu referenzieren und Nostr-Inhalte mit der offenen geografischen Datenbank zu verbinden.
NIP-XX: Responsive Image Variants: woikos schlägt vor, NIP-94-Dateimetadaten-Events um Tags für responsive Bildvarianten in verschiedenen Auflösungen zu erweitern. Clients könnten die geeignete Variante basierend auf Displaygröße und Netzwerkbedingungen auswählen und so die Bandbreite für mobile Nutzer reduzieren, die hochauflösende Bilder auf Blossom-Servern betrachten.

NIP Deep Dive: NIP-85 (Trusted Assertions)

NIP-85 definiert ein System zur Delegation aufwändiger Berechnungen an vertrauenswürdige Service Provider, die signierte Ergebnisse als Nostr-Events veröffentlichen. Web-of-Trust-Scores und Engagement-Metriken erfordern das Crawlen vieler Relays und die Verarbeitung großer Event-Mengen – Arbeit, die auf Mobilgeräten nicht praktikabel ist. Der dieswöchige Merge fügte Hinweise zum Client-Discovery-Prozess für diese Provider hinzu.

Delegation:

Die Berechnung des Web-of-Trust-Scores eines Nutzers erfordert das Crawlen von Follow-Graphen mehrere Hops tief über viele Relays hinweg, und die Berechnung genauer Follower-Zahlen bedeutet Deduplizierung über das gesamte Relay-Netzwerk. Mobilgeräte und Browser-Clients können diese Operationen nicht durchführen, doch die Ergebnisse sind für Spam-Filterung und Inhalts-Ranking unerlässlich. NIP-85 überbrückt diese Lücke, indem Nutzern ermöglicht wird, vertrauenswürdigen Providern die Berechnungen zu übertragen, die die Ergebnisse als Standard-Nostr-Events veröffentlichen.

Protokoll-Design:

NIP-85 verwendet vier Event-Kinds für Aussagen über verschiedene Subjekttypen. Nutzer-Aussagen (kind 30382) tragen Follower-Anzahl, Post-/Antwort-/Reaktions-Zähler, Zap-Beträge, normalisierten Rang (0-100), häufige Themen und aktive Stunden:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30382,
 "tags": [
 ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"],
 ["rank", "89"],
 ["followers", "4521"],
 ["first_created_at", "1609459200"],
 ["post_cnt", "1283"],
 ["reply_cnt", "647"],
 ["reactions_cnt", "8920"],
 ["zap_amt_recd", "850000"],
 ["zap_amt_sent", "320000"],
 ["zap_cnt_recd", "412"],
 ["zap_cnt_sent", "198"],
 ["zap_avg_amt_day_recd", "1150"],
 ["zap_avg_amt_day_sent", "430"],
 ["reports_cnt_recd", "2"],
 ["reports_cnt_sent", "0"],
 ["t", "nostr"],
 ["t", "bitcoin"],
 ["active_hours_start", "14"],
 ["active_hours_end", "22"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Event-Aussagen (kind 30383) bewerten einzelne Notizen mit Kommentarzahl, Zitatanzahl, Reposts, Reaktionen und Zap-Daten:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30383,
 "tags": [
 ["d", "<target event id>"],
 ["rank", "72"],
 ["comment_cnt", "45"],
 ["quote_cnt", "12"],
 ["repost_cnt", "89"],
 ["reaction_cnt", "310"],
 ["zap_cnt", "23"],
 ["zap_amount", "125000"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Für adressierbare Events (Langform-Artikel, Wiki-Seiten) wendet kind 30384 dieselben Engagement-Metriken kollektiv auf alle Versionen an. Kind 30385 bewertet externe Identifikatoren (Bücher, Filme, Websites, Orte, Hashtags), die über NIP-73 (Externe Inhalts-IDs) referenziert werden und standardisiert, wie Nostr-Events externe Inhalte via i- und k-Tags referenzieren:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30385,
 "tags": [
 ["d", "isbn:9780765382030"],
 ["k", "isbn"],
 ["rank", "94"],
 ["comment_cnt", "67"],
 ["reaction_cnt", "203"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Jede Aussage ist ein ersetzbares adressierbares Event, bei dem der d-Tag das Subjekt enthält: einen pubkey, eine Event-ID, eine Event-Adresse oder einen NIP-73-Identifikator. Service Provider signieren diese Events mit ihren eigenen Schlüsseln, und Clients bewerten sie basierend auf Vertrauensbeziehungen.

Provider-Discovery:

Nutzer erklären, welchen Assertion-Providern sie vertrauen, indem sie kind-10040-Events veröffentlichen. Jeder Eintrag spezifiziert den Assertion-Typ mit dem Provider-pubkey und Relay-Hint sowie optionalen Algorithmusvarianten:

{
 "id": "<event hash>",
 "pubkey": "<user pubkey>",
 "created_at": 1739836800,
 "kind": 10040,
 "tags": [
 ["30382:rank", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30382:rank", "3d842afe...", "wss://nostr.wine"],
 ["30382:zap_amt_sent", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30383:rank", "4fd5e210...", "wss://nip85.nostr.band"]
 ],
 "content": "",
 "sig": "<user signature>"
}

Nutzer können die Tag-Liste in .content mit NIP-44 verschlüsseln, um ihre Provider-Präferenzen privat zu halten. Clients erstellen eine Provider-Liste, indem sie prüfen, welchen Providern ihre gefolgten Accounts vertrauen, und schaffen so eine dezentrale Reputationsschicht für die Assertion-Provider selbst.

Sicherheitsmodell:

Provider müssen für unterschiedliche Algorithmen verschiedene Service-Schlüssel verwenden und einen eindeutigen Schlüssel pro Nutzer, wenn Algorithmen personalisiert sind, um Kreuz-Korrelation von Anfragen über Nutzer hinweg zu verhindern. Jeder Service-Schlüssel erhält ein kind-0-Metadaten-Event, das das Verhalten des Algorithmus beschreibt und Nutzern Transparenz darüber gibt, wem sie vertrauen. Assertion-Events sollten nur aktualisiert werden, wenn sich die zugrunde liegenden Daten tatsächlich ändern, um unnötigen Relay-Traffic zu verhindern und Clients zu ermöglichen, Ergebnisse zuverlässig zu cachen.

Aktuelle Adoption:

NIP-85 formalisiert ein Muster, das informell bereits entsteht. Primals Cache-Server berechnet Engagement-Metriken und Web-of-Trust-Scores. Antiprimal, in Newsletter #9 behandelt, überbrückt diese Berechnungen zu Standard-Nostr-Clients mittels NIP-85 Event-Kinds. Nostr.band betreibt das wss://nip85.nostr.band-Relay, das in den Beispielen der Spezifikation selbst referenziert wird, und stellt Assertion-Events für seine Suchindex-Daten bereit. Auf der Client-Seite hat Amethyst (verfasst von vitorpamplona, der auch dieses NIP schrieb) experimentelle Trusted-Assertions-Unterstützung in seiner quartz-Bibliothek, die Assertion-Events und Service-Provider-Deklarationen parst. Vertex berechnet ähnliche Web-of-Trust-Metriken, wählte jedoch einen anderen Ansatz, eine direkte API statt NIP-85-Events, unter Berufung auf das Discovery-Problem und den Berechnungsaufwand assertion-basierter Architekturen. Mit NIP-85 kann jeder Client Aussagen von jedem Provider durch ein Standard-Event-Format konsumieren, und Provider konkurrieren auf Genauigkeit, während Nutzer wählen, wem sie vertrauen.

NIP Deep Dive: NIP-52 (Kalender-Events)

NIP-52 definiert Kalender-Events auf Nostr und gibt Clients eine standardisierte Möglichkeit, Ereignisse zu bestimmten Zeitpunkten oder zwischen Zeitpunkten darzustellen und zu entdecken. Der dieswöchige D-Tag-Merge fügte tagesgranulares Indexing hinzu und schloss eine fehlende Lücke in der Abfrage-Infrastruktur der Spezifikation.

Zwei Event-Typen:

NIP-52 trennt Kalender-Events in zwei Kinds basierend auf zeitlicher Präzision. Datumsbasierte Events (kind 31922) repräsentieren ganztägige Ereignisse wie Feiertage oder mehrtägige Festivals. Sie verwenden ISO-8601-Datumsstrings in ihren start- und optionalen end-Tags ohne Zeitzonen-Berücksichtigung:

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1735689600,
 "kind": 31922,
 "content": "Annual celebration of Bitcoin's genesis block",
 "tags": [
 ["d", "bitcoin-independence-day-2026"],
 ["title", "Bitcoin Independence Day"],
 ["start", "2026-01-03"],
 ["end", "2026-01-04"],
 ["location", "Worldwide"],
 ["g", "u4pruydqqv"],
 ["t", "bitcoin"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["r", "https://bitcoinindependenceday.com"]
 ],
 "sig": "<event creator signature>"
}

Zeitbasierte Events (kind 31923) repräsentieren spezifische Momente mit Unix-Timestamps in ihren start- und optionalen end-Tags sowie IANA-Zeitzonen-Identifikatoren (start_tzid, end_tzid) für die Darstellung. Beide Kinds sind parametrisiert ersetzbare Events, sodass Veranstalter Details aktualisieren können, indem sie ein neues Event mit demselben d-Tag veröffentlichen.

Kalender und RSVPs:

Kind-31924-Events definieren Kalender als Sammlungen und referenzieren Events via a-Tags, die auf kind-31922- oder kind-31923-Events durch ihre Adresskoordinaten zeigen:

{
 "id": "<event hash>",
 "pubkey": "<calendar owner pubkey>",
 "created_at": 1739836800,
 "kind": 31924,
 "content": "Nostr community events worldwide",
 "tags": [
 ["d", "nostr-community-calendar"],
 ["title", "Nostr Community Events"],
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["a", "31922:<organizer-pubkey>:bitcoin-independence-day-2026"]
 ],
 "sig": "<calendar owner signature>"
}

Nutzer können mehrere Kalender pflegen (persönlich, Arbeit, Community), und Clients können Kalender von spezifischen pubkeys abonnieren. Kalender-Events können einen a-Tag enthalten, der einen Kalender referenziert, um die Aufnahme anzufordern, und ermöglichen so kollaboratives Kalender-Management, bei dem mehrere Nutzer Events zu Kalendern beitragen, die ihnen nicht gehören.

RSVPs verwenden kind 31925, bei dem Nutzer ihren Teilnahme-Status zusammen mit einem optionalen Frei-/Belegt-Indikator veröffentlichen:

{
 "id": "<event hash>",
 "pubkey": "<attendee pubkey>",
 "created_at": 1739836800,
 "kind": 31925,
 "content": "Looking forward to it",
 "tags": [
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["e", "<kind 31923 event id>", "wss://relay.example.com"],
 ["d", "<unique-rsvp-id>"],
 ["status", "accepted"],
 ["fb", "busy"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com"]
 ],
 "sig": "<attendee signature>"
}

Gültige status-Werte sind “accepted”, “declined”, “tentative”, und der optionale fb-Tag markiert den Nutzer als frei oder belegt für diesen Zeitraum. RSVP-Events referenzieren den a-Tag des Kalender-Events und tragen den p-Tag des Veranstalters, sodass der Client des Veranstalters Antworten über Relays hinweg aggregieren kann.

Die D-Tag-Ergänzung:

Vor dem dieswöchigen Merge mussten Clients, die Events in einem Datumsbereich abfragen wollten, alle Events eines pubkeys oder Kalenders abrufen und clientseitig filtern. Der neue erforderliche D-Tag auf zeitbasierten Events (kind 31923) enthält einen tagesgranularen Unix-Timestamp, berechnet als floor(unix_sekunden / 86400). Mehrtägige Events tragen mehrere D-Tags, einen pro Tag. Relays können Events nun nach Tag indexieren und auf gefilterte Anfragen effizient antworten und verwandeln damit ein clientseitiges Filterproblem in eine relay-seitige Index-Abfrage.

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1739836800,
 "kind": 31923,
 "content": "Monthly meetup for Nostr developers in Austin",
 "tags": [
 ["d", "nostr-meetup-2026"],
 ["title", "Nostr Developer Meetup"],
 ["summary", "Talks and demos from local Nostr builders"],
 ["image", "https://example.com/meetup-banner.jpg"],
 ["start", "1740067200"],
 ["end", "1740078000"],
 ["start_tzid", "America/New_York"],
 ["end_tzid", "America/New_York"],
 ["D", "20139"],
 ["location", "Bitcoin Commons, Austin TX"],
 ["g", "9v6knb2pg"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["p", "<speaker-pubkey>", "wss://relay.example.com", "speaker"],
 ["t", "nostr"],
 ["t", "meetup"],
 ["r", "https://bitcoincommons.com"]
 ],
 "sig": "<event creator signature>"
}

Der D-Wert 20139 entspricht floor(1740067200 / 86400) und platziert dieses Event auf den 20. Februar 2025. Clients, die „alle Events diese Woche" abfragen, senden einen Filter mit dem entsprechenden D-Bereich, und Relays geben nur passende Events zurück.

Design-Entscheidungen:

NIP-52 lässt wiederkehrende Events bewusst weg. Die Spezifikation lässt Wiederholungsregeln (RRULE aus iCalendar) vollständig aus und delegiert diese Komplexität an Clients. Ein Veranstalter veröffentlicht individuelle Events für jedes Vorkommen und hält das relay-seitige Datenmodell einfach. Teilnehmer-Tags tragen optionale Rollen (“host”, “speaker”, “attendee”), und Standort-Tags können Geohash-g-Tags für räumliche Abfragen neben menschenlesbaren Adressen enthalten.

Implementierungen:

Flockstr ist der primäre Kalender-Client, der auf NIP-52 aufgebaut ist. Coracle zeigt Kalender-Events in seinem sozialen Feed an. Die D-Tag-Ergänzung dieser Woche ermöglicht relay-seitiges temporales Indexing, das beide Clients nutzen können, um die Bandbreite beim Abfragen von Events in einem bestimmten Datumsbereich zu reduzieren.

Das war’s für diese Woche. Wer etwas baut, Neuigkeiten hat oder sein Projekt vorgestellt sehen möchte, kann sich per NIP-17 DM an uns wenden oder uns auf Nostr finden.

Nostr Compass #9

Wed, 11 Feb 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Mostro liefert seine erste öffentliche Beta nach drei Jahren Entwicklung und bringt P2P-Bitcoin-Handel auf Mobilgeräte via Nostr. OpenSats vergibt seine sechzehnte Welle von Bitcoin-Grants, wobei Minibits Wallet eine Erneuerung für sein Nostr-integriertes Cashu-Wallet erhält. Zapstore erreicht den stabilen 1.0-Release, was die Reifung des dezentralisierten Android-App-Stores markiert. Coracle 0.6.29 fügt Themen und Highlight-Kommentare hinzu. Igloo Desktop v1.0.3 liefert umfangreiche Sicherheitshärtung für Frostr Threshold-Signierung. Amber v4.1.2-pre1 migriert zur Flow-Architektur. Angor erreicht v0.2.5 mit überarbeiteter Funding-UI und NIP-96-Bildserver-Konfiguration. NostrPress startet als Tool, das Nostr-Profile in statische Blogs umwandelt. Antiprimal liefert ein standardkonformes Gateway, das Primals proprietären Cache-Server mit Standard-Nostr-NIPs verbindet. Primal Android mergt 18 PRs, die die NWC-Infrastruktur mit Dual-Wallet-Unterstützung, Audit-Logging und der lookup_invoice-Methode erweitern. diVine liefert API-First Video-Feeds. Marmots TypeScript SDK lagert seine Referenz-Chat-App in ein eigenständiges Repo aus und beginnt die Migration zu ts-mls v2. Im NIPs-Repository wird HyperLogLog Approximate Counting für NIP-45 gemergt und Identitäts-Tags werden aus kind 0 extrahiert. Vorschläge von vitorpamplona beginnen systematisch kind 0 Metadaten-Events zu verschlanken. Neue Protokollvorschläge umfassen Nostr Relay Connect für NAT-Traversierung und Nostr Web Tokens für signierte Web-Claims. In den Deep Dives dieser Woche geht es um NIP-45s neues HyperLogLog Approximate Counting für relay-übergreifende Event-Metriken und NIP-96s HTTP-Dateispeicherungsprotokoll, das nun zugunsten von Blossom als veraltet markiert ist, während Projekte den Übergang zwischen den beiden Medienstandards vollziehen.

Neuigkeiten

Mostro liefert erste öffentliche Beta

Mostro, die Peer-to-Peer-Bitcoin-Börse auf Nostr, hat ihre Mobile App v1.1.0 veröffentlicht, die erste öffentliche Beta des Projekts nach drei Jahren Entwicklung. Nutzer können Bitcoin direkt handeln, wobei Nostr für Auftragskoordination und Lightning für Abwicklung sorgt, ganz ohne treuhänderischen Vermittler.

Enthalten sind Push-Benachrichtigungen mit verbesserter Hintergrundzuverlässigkeit auf Android, ein optionales Logging-System zur Erfassung und Weitergabe von Diagnosedaten bei auftretenden Problemen, sanftere Relay-Updates durch additive Initialisierung und Phase-2-UI-Verfeinerungen mit Internationalisierungsunterstützung. Verfügbar auf Zapstore und als direkter GitHub-Download.

Mostro reiht sich neben Shopstr und Plebeian Market als Nostr-native Commerce-Anwendung ein, mit dem Unterschied, dass es sich auf Fiat-zu-Bitcoin-Börsenkoordination konzentriert. Order-Matching und Streitbeilegung laufen über Nostr-Relays via den zugrunde liegenden Mostro-Daemon.

OpenSats sechzehnte Welle von Bitcoin-Grants

OpenSats kündigte Grants für 17 Open-Source-Projekte an. Nostr-relevantes Highlight: Minibits Wallet, das Android-Cashu-Wallet mit NIP-60 Wallet-Event-Unterstützung und Nutzap-Integration, erhielt einen Erneuerungsgrant. Minibits verwendet Nostr-Events zur Speicherung des ecash-Token-Zustands, was Wallet-Backups per Relay-Sync geräteübergreifend portabel macht.

NostrPress: Nostr-Profil zum statischen Blog

NostrPress (blog.besoeasy.com) wandelt ein Nostr-Profil in einen vollständig statischen Blog um, der überall bereitgestellt werden kann. Artikel werden auf Nostr veröffentlicht, und NostrPress generiert daraus eine eigenständige Website, inklusive lokaler Medienspeicherung und RSS-Feeds.

Auf Nunjucks-Templating und JavaScript aufbauend, produziert NostrPress Seiten ohne Plattform-Lock-in. Die generierte Ausgabe ist reines HTML/CSS, das auf jedem statischen Dateiserver, GitHub Pages, Netlify oder einem persönlichen VPS laufen kann. Neben Npub.pro und Servus bietet sich das Tool als weitere Option an, Nostr-Inhalte in traditionelle Websites zu verwandeln.

Antiprimal: Standardkonformes Gateway zu Primals Cache

antiprimal (antiprimal.net), von Alex Gleason und dem Soapbox-Team entwickelt, ist ein WebSocket-Gateway, das Primals proprietären Cache-Server mit Standard-Nostr-Protokollnachrichten verbindet. Primal bietet Funktionen wie Event-Statistiken, Inhaltssuche und Web-of-Trust-Berechnungen per wss://cache.primal.net/v1, setzt aber ein proprietäres Nachrichtenformat mit einem nicht-standardmäßigen cache-Feld voraus, das Standard-Nostr-Clients nicht verwenden können. Antiprimal übersetzt Standard-NIP-Anfragen in Primals Format und konvertiert Antworten zurück.

Unterstützt werden NIP-45 COUNT-Abfragen (Reaktionen, Antworten, Reposts, Zap-Zähler, Follower-Zahlen), NIP-50 Suche, NIP-11 Relay-Informationen und NIP-85 Trusted Assertions. Zusätzlich veröffentlicht ein Begleit-Bot NIP-85 kind 30382 (Benutzerstatistiken) und kind 30383 (Event-Engagement) Events. In TypeScript auf Bun mit der Nostrify-Bibliothek gebaut, hat das Projekt seit seiner Erstellung am 6. Februar bereits 53 Commits und ist live unter antiprimal.net.

Ikaros: KI-Agent-Messaging-Gateway für Signal und Nostr

Ikaros, vom Soapbox-Team entwickelt, ist ein Messaging-Gateway, das KI-Agenten die Kommunikation per Signal und Nostr-verschlüsselten DMs ermöglicht. Via Agent Client Protocol (ACP) verbindet die Bridge jeden ACP-kompatiblen KI-Codierassistenten mit echten Messaging-Netzwerken. Drei Pull Requests bilden den initialen Build des Projekts diese Woche.

PR #1 implementiert einen vollständigen NIP-04 Encrypted-DM-Adapter mit Sende-/Empfangsunterstützung, Antwort-Pufferung mit explizitem Flush bei Abschluss, nsec- und Hex-Private-Key-Formaten, Multi-Relay-Publishing mit automatischer Wiederverbindung und einem interaktiven Setup-Wizard. Verwendet werden nostr-tools v2.23.0 und das ACP SDK v0.14.1.

In PR #2 wird ein stiller Nachrichtenverlust durch Session-Update-Race-Condition behoben: eingehende Benachrichtigungen, die vor Registrierung der Session in der Map eintrafen, gingen still verloren, und der Fix puffert sie nun zum Replay nach Abschluss der Registrierung. PR #3 fügt Signal-Nutzer- und Gruppennamen-/UUID-Metadaten zu Agenten-Interaktionen hinzu, sodass der KI-Agent weiß, mit wem er spricht und in welcher Gruppe. Damit eröffnet sich ein neuer Designraum: KI-Agenten, die per Nostr-DMs erreichbar sind und auch von Signal aus kontaktiert werden können, und umgekehrt.

Kind-0-Schlankheitskampagne

vitorpamplona eröffnete diese Woche PRs, die systematische Extraktion von Daten aus kind 0 (Benutzer-Metadaten) Events in dedizierte Event-Kinds vorschlagen. Adressiert wird ein wachsendes Problem: kind 0 Events haben im Laufe der Zeit Felder angesammelt, die meisten Clients nicht verwenden, was die Größe jedes Profil-Abrufs aufbläht.

PR #2216 (gemergt) verschiebt Identitäts-Tags (i-Tags) von kind 0 zu einem neuen kind 10011, da die Adoption minimal war. PR #2213 schlägt vor, NIP-05-Verifizierung nach kind 10008 zu verschieben, was mehrere NIP-05-Identifikatoren pro Nutzer und Filterung nach NIP-05-Adresse ermöglichen würde. PR #2217 zielt darauf ab, Lightning-Adressen (lud06/lud16) in einen neuen kind zu extrahieren, sodass nicht mehr alle kind 0 Nutzer Zap-bezogene Felder mitführen, die nur bei Lightning-Integration relevant sind.

Wiederbelebt wurde damit auch die Diskussion um die breitere Frage der kind 0 Struktur, einschließlich PR #1770, dem langjährigen Vorschlag, stringifiziertes JSON in kind 0 Inhalten durch strukturierte Tags zu ersetzen.

NIP-70-Relay-Unterstützung entscheidend für verschlüsselte Nachrichten

White Noise, die Implementierung des Marmot-Protokolls, hat eine kritische Lücke identifiziert in der Relay-Unterstützung von NIP-70 (Protected Events) und NIP-42 (Authentifizierung). Tests ergaben, dass große öffentliche Relays wie Damus, Primal und nos.lol geschützte Events mit blocked: event marked as protected-Fehlern direkt ablehnen, statt die erforderliche Authentifizierungs-Challenge einzuleiten.

Gebrochen wird dadurch ein zentrales Sicherheitsfeature: NIP-70 ermöglicht das sichere Löschen verbrauchter MLS KeyPackages und verhindert „harvest now, decrypt later"-Angriffe. Verschlüsselte Messaging-Protokolle können Nutzer nicht vor zukünftiger Schlüsselkompromittierung schützen, solange Relays dies nicht unterstützen. White Noise hat NIP-70 als Reaktion standardmäßig deaktiviert und behält ein optionales Flag bei.

Aufruf an Relay-Betreiber: Implementiert den vollständigen NIP-42-Authentifizierungsablauf. Fordert bei geschützten Events zur Eigentümerschaftsbestätigung auf und akzeptiert dann validierte Schreibvorgänge. Geschützte Events ohne Authentifizierung abzulehnen bricht Protokoll-Sicherheitsgarantien, auf die verschlüsselte Messaging-Anwendungen angewiesen sind.

Releases

Coracle 0.6.29

Coracle (coracle.social), hodlbods Web-Client, hat 0.6.29 veröffentlicht. Neu sind Anzeige von Themen und Kommentaren zu kind 9802 Highlights sowie ein Listen-Navigationselement, das schnellen Zugriff auf benutzerkuratierte Listen aus der Haupt-UI bietet. Unter der Haube wurde Coracle auf eine neue Version von Welshman aktualisiert, der gemeinsamen Nostr-Bibliothek für Relay-Management und Event-Handling. Aktualisiert wurde auch die Standard-Relay-Liste, und Glitchtip-Error-Tracking wurde entfernt.

Igloo Desktop v1.0.3

Igloo Desktop, die FROST-basierte Threshold-Signer- und Schlüsselverwaltungsanwendung, hat v1.0.3 mit umfangreicher Sicherheitshärtung veröffentlicht. IPC-Validierung, Electron-Isolation und SSRF-bewusste Relay-Prüfungen wehren Server-Side-Request-Forgery ab. Hinzu kommen ein neuer Onboarding- und Share-Import-Flow zur Vereinfachung der Schlüsselverteilung, Relay-Planung mit Normalisierung und Prioritäts-Merging, und eine Preload-basierte Electron-API-Architektur zur Verbesserung der Sicherheitsgrenze zwischen Renderer und Hauptprozess. Stabilität bei Threshold-Signing-Sessions gewährleistet ein Signer-Keep-Alive-System, und Recovery-UX-Verbesserungen reduzieren die Reibung bei der Schlüsselwiederherstellung.

Amber v4.1.2-pre1

Amber, der Android Event-Signer, hat v4.1.2-pre1 veröffentlicht. Behoben werden die fehlende Relay-Trust-Score-Anzeige aus v4.1.1 und JSON-Parsing-Probleme bei Nicht-Nostr-Verschlüsselungs-/Entschlüsselungsanfragen. Migriert wurde das Account-Modell von LiveData zu Flow, Bunker-Secrets wechseln zu vollständigen UUIDs, und Gradle Plugin 9 kommt als Upgrade hinzu.

Mostro Mobile v1.1.0 und Daemon v0.16.1

Im Neuigkeiten-Abschnitt oben findet sich die vollständige Berichterstattung zum Mobile-Release. Serverseitig hat der Mostro-Daemon v0.16.1 veröffentlicht, mit automatischem Publishing von NIP-01 kind 0 Metadaten beim Start (PR #575), sodass der Daemon seine Identität im Netzwerk ankündigt. Ebenfalls aktualisiert wurde die Dokumentation zur Dev-Fee-Berechnung (PR #571).

Angor v0.2.5

Angor (angor.io), das dezentralisierte P2P-Funding-Protokoll auf Bitcoin und Nostr, hat v0.2.5 mit drei gemergten PRs veröffentlicht. PR #649 redesignt den Funds-Management-Bereich (V2) und ersetzt das bisherige Layout durch ein neues Interface zur Verfolgung einzelner UTXOs und Investitionspositionen. PR #651 überarbeitet die InvoiceView: aktualisierte Button-Styles, schließbare Dialoge, „Copy Address"-Befehl, Abbruchunterstützung und verbessertes Investment-Flow-Handling. Konfigurierbare NIP-96 (Spec) Bildserver in den Einstellungen kommen via PR #652, sodass Nutzer ihren Media-Upload-Endpunkt wählen können. In der Vorwoche wurde v0.2.4 veröffentlicht.

Ridestr v0.2.2 und v0.2.3

Ridestr, die dezentralisierte Rideshare-Plattform, letzte Woche vorgestellt, setzte die schnelle Iteration mit v0.2.2 (Bridge Payment Hotfix) und v0.2.3 nach dem v0.2.0 „RoadFlare Release" fort. Im v0.2.2-Hotfix wird ein Bug behoben, bei dem Cross-Mint-Cashu-Bridge-Zahlungen Fahrten automatisch stornierten, während die Zahlung noch verarbeitet wurde oder letztendlich erfolgreich gewesen wäre, was vorzeitige Fahrtenstornierung bei langsameren Abwicklungen verhindert. Ebenfalls behoben wurden UI-Flackern und defekte Touch-Hitboxen beim „Mein Standort"-Button. v0.2.3 liefert weitere Bugfixes. Beide Releases enthalten separate APKs, jeweils eine Ridestr-Fahrgast-App und eine Drivestr-Fahrer-App.

Nostr PHP 1.9.4

Nostr PHP (nostr-php.dev), die PHP-Hilfsbibliothek, hat 1.9.4 veröffentlicht und fügt eine konfigurierbare timeout-Eigenschaft zur Request-Klasse hinzu (PR #106). Entwickler können damit benutzerdefinierte Timeout-Dauern für Relay-Verbindungen und Nachrichtenanfragen setzen, um endloses Hängen zu verhindern.

Zapstore v1.0.0

Zapstore (zapstore.dev), der erlaubnisfreie Android-App-Store auf Nostr, hat diese Woche seinen stabilen 1.0-Release-Meilenstein erreicht nach Monaten von Release-Kandidaten.

Wichtige Stabilitätsverbesserungen sind enthalten: Install-Button-Zustandshandling, das sicherstellt, dass „Löschen" sofort nach Abschluss der Installation erscheint, nutzerfreundliche Fehlermeldungen mit aufklappbaren technischen Details und ein „Problem melden"-Button, der verschlüsselte DMs via Nostr mit ephemeren Schlüsseln sendet. Hinzu kommen neuer Update-Bildschirm mit Polling und Batch-Tracking, besserer Download-Watchdog, dynamische parallele Download-Limits basierend auf Geräteleistung, häufigere Synchronisierung installierter Pakete und verbesserte Versionsvergleichslogik. Gelöst wurde ein kritisches flutter_secure_storage-Problem, und die Package-Manager-Behandlung von Grenzfällen wurde verbessert.

Dieser Meilenstein repräsentiert die Reifung von Nostrs erster dedizierter App-Distributionsplattform, die Entwicklern ermöglicht, Android-Anwendungen direkt an Nutzer zu veröffentlichen, frei von zentralisiertem App-Store-Gatekeeping.

ZSP v0.3.1

ZSP, das Go CLI-Tool vom Zapstore-Team, ersetzt Zapstores bisheriges Publishing-Tooling zum Signieren und Hochladen von Android-Apps und hat v0.3.1 veröffentlicht. ZSP übernimmt APK-Beschaffung von GitHub, GitLab, Codeberg, F-Droid oder lokalen Dateien, parst dann Metadaten, signiert Nostr-Events (via privatem Schlüssel, NIP-46 Bunker oder NIP-07 Browser-Erweiterung) und lädt Artefakte auf Blossom-Server hoch. Neu sind vollständiger Offline-Modus zum Keystore-Linking, Content-Digest-Header bei Blossom-Uploads, verbesserte arm64-v8a APK-Erkennung aus F-Droid-Repositories, GitLab Trailing-Query-Parameter-Fixes und vollständige .env-Dateiunterstützung.

Damus iOS 1.17

Damus, der iOS Nostr-Client, wurde auf Version 1.17 aktualisiert (PR #3606). Behoben wird ein RelayPool-Problem, bei dem Verbindungen nach ephemerer Lease-Freigabe geschlossen wurden (PR #3605), was dazu führen konnte, dass Subscriptions unerwartet abbrachen. Gelöst wird außerdem ein Bug bei der Favoriten-Timeline, die keine Events anzeigte, sobald zwischen Tabs gewechselt wurde (PR #3603).

nak v0.18.3

nak, das Nostr Army Knife CLI, hat v0.18.3 mit drei Stabilitätsfixes veröffentlicht: Verhinderung eines Panics bei nil oder zu kurzen AUTH-Challenge-Tags, Prüfung von Dateparser-Fehlern vor Verwendung des geparsten Werts und Behandlung von Cashu-Mint-URLs, denen der ://-Separator fehlt.

Mi: Browserbasiertes lokales Relay

Mi (mi.shakespeare.wtf), eine Shakespeare MiniApp, ist ein browserbasiertes lokales Relay, das Nostr-Events in IndexedDB archiviert. Mi ruft Profile (kind 0), Kontaktlisten (kind 3), Relay-Listen (kind 10002) und Wallet-Events von verbundenen Relays ab und speichert sie lokal, was Offline-Zugriff auf eigene Daten ermöglicht. Aufgebaut mit React und nostr-tools 2.15.0.

Agora v1.0.2

Agora (agora.spot), die dezentralisierte Aktivismus- und Fundraising-Plattform des Soapbox-Teams, hat v1.0.2 mit Android-APK zum direkten Installieren veröffentlicht. Dies ist die erste Compass-Erwähnung von Agora, das am 17. Januar mit einem Leitbild startete: „Join the global movement for freedom. Send support to activists on the ground internationally and take part in local actions."

Im Zentrum steht eine Weltkarte, auf der Nutzer nach Land durchsuchen, standortgetaggte „Aktionen" erstellen (Proteste, Kampagnen, Community-Organisation) und diese durch verschachtelte Kommentare diskutieren können. Alle Inhalte werden via Nostr-Relays verbreitet, sodass kein zentraler Server abgeschaltet werden kann, um Koordination zum Schweigen zu bringen. Agora unterstützt mehrere Sprachen mit CI-erzwungener Übersetzungsparität, integriert Blossom-Medienserver und bietet Suche, Hashtag-Browsing mit globalem/regionalem Toggle, Profile und Reaktionssysteme. Als aktueller Android-Build ist v1.0.2 als direkter APK-Download verfügbar.

xonos v0.1.6

xonos, der experimentelle 3D-Nostr-Client auf Basis der Bevy Game Engine, hat v0.1.6 veröffentlicht. xonos rendert Nostr-Events in einer räumlichen 3D-Umgebung mit Text-to-Speech-Fähigkeiten und erforscht, wie soziale Protokolldaten außerhalb konventioneller 2D-Interfaces funktionieren könnten.

Projekt-Updates

Primal Android erweitert NWC-Infrastruktur

Primal Android mergte 18 PRs diese Woche und setzt den NWC-Ausbau fort, der letzte Woche begonnen wurde. PR #883 fügt NWC-Verbindungen für beide Wallets (Spark und extern) hinzu, und PR #879 implementiert die lookup_invoice-NWC-Methode zur Überprüfung des Zahlungsstatus.

NWC-Request-Response-Audit-Logging zur Fehlersuche bei Wallet-Interaktionen bringt PR #880. Multi-Account-Unterstützung in PrimalNwcService kommt via PR #877, sodass Nutzer mit mehreren Profilen separate Wallet-Verbindungen pflegen können. PR #882 implementiert periodische Bereinigung abgelaufener Budget-Holds und verhindert, dass veraltete Zahlungsreservierungen Wallet-Operationen blockieren.

UI-Arbeit umfasst Wallet-Upgrade-Bildschirm-Redesigns (PR #889), Wallet-Upgrade-FAQ (PR #885), Lightning-Adress-Einstellung beim Onboarding (PR #888) und einen Fix, der Zap-Transaktionen korrekt von regulären Zahlungen bei Nicht-Lightning-Typen unterscheidet (PR #887).

diVine liefert API-First Video-Feeds

diVine, der Kurzform-Video-Client, mergte 19 PRs diese Woche und verlagert sich zu einer API-First-Architektur. PR #1468 führt API-First Video-Feeds ein, und PR #1466 ergänzt Trending-, Recent- und Home-API-Endpunkte. Spezifische Video-Controller zum effizienten Feed-Rendering werden in PR #1433 indiziert.

Profilhandling verbesserte sich mit PR #1440, der ein Cache-plus-Fresh-Pattern implementiert, was Ladezeiten reduziert und gleichzeitig Datenaktualität sicherstellt. Geliefert wurden auch Benachrichtigungs-Fixes (PR #1437), Kommentar-Flow-Refactoring (PR #1431) und Tab-Swiping auf dem Benachrichtigungsbildschirm (PR #1388).

White Noise: Keyring-Vereinheitlichung und Suche

Das White Noise Backend des Marmot-Protokolls mergte 4 PRs diese Woche. Zwei PRs verbesserten das Keyring-Handling: PR #468 macht den Keyring-Service-Identifier per WhitenoiseConfig konfigurierbar, und PR #475 vereinheitlicht die Implementierung auf ein einzelnes keyring-core-Crate mit plattformnativen Stores. Suchfunktionalität kommt separat in PR #470 hinzu.

Marmot TS extrahiert Referenz-Chat-App

Das Marmot TypeScript SDK (marmot-ts) mergte PR #40, der die eingebaute Referenz-Chat-Anwendung entfernt und in ein eigenständiges Repo auslagert: marmots-web-chat. Am 6. Februar erstellt, ist das neue Repo eine Referenzimplementierung mit eigener CI-Pipeline, Tabbed-Chat-View und unabhängigem Build-System. So kann sich das SDK auf Bibliotheksbelange konzentrieren, während die Chat-App die UX unabhängig weiterentwickelt.

Offen ist PR #41, der marmot-ts zu ts-mls v2.0.0 migriert und eine überarbeitete API mit vereinheitlichten Kontextobjekten, neuen Nachrichtenbehandlungs-Utilities (Event-Erstellung, Lesen, Deserialisierung), KeyPackage-Metadaten-Helfern und Löschungs-Event-Unterstützung bringt.

Alby Hub Updates

Alby Hub mergte 5 PRs diese Woche. PR #2049 fügt ein Alby CLI zum App-Store-Interface hinzu. Ungültige Zap-Daten in der Transaktionsliste behandelt PR #2033, und PR #2046 entfernt die ungenutzte ListTransactions-Methode aus dem LNClient-Interface.

Notedeck liefert Dashboard und Agentium

Notedeck, der plattformübergreifende Nostr-Client von Damus, mergte 6 PRs diese Woche. PR #1247 fügt eine initiale Dashboard-App hinzu. Agentium, die Multi-Agent-Entwicklungsumgebung, die den Dave-KI-Assistenten in ein System mit dualen KI-Modi und szenenbasiertem Agenten-Management verwandelt, kommt in PR #1293. Mehrzeiliger Nachrichtenkomposer mit Signal-artigen Tastenkombinationen folgt in PR #1276, und PR #1278 bringt Medienperformance-Verbesserungen. Bemerkenswerte offene PRs umfassen Outbox-Infrastruktur und NIP-34 Git-App-Planung.

Agora liefert großes UI-Overhaul

Agora mergte 7 PRs diese Woche neben dem v1.0.2-Release. Am umfangreichsten ist PR #106, der 11 UI-Aufgaben in den Bereichen Einstellungen, Profilbearbeitung, Karteninteraktionen, Suchergebnisse, Kommentarfilterung und Blossom-Server-Management abschließt. Reaktionsbuttons wurden deaktiviert, damit nicht-authentifizierte Nutzer keine stillen Fehler mehr erhalten. Zudem wurden Date-Line-Kartenschwenken und fette Übereinstimmungstexte in Suchergebnissen ergänzt.

Kommentarzähler unter Feed-Beiträgen und Thread-Seiten kommen in PR #108. Automatische Wiederholung bei Event-Ladefehlern mit explizitem Neulade-Button fügt PR #107 hinzu. PR #104 ändert Hashtag-Browsing auf standardmäßig globalen Scope, da länderspezifischer Standard oft null Ergebnisse lieferte.

PR #109 prüft per CI-Schritt die Übersetzungsparität und lässt den Build fehlschlagen, falls Werte fehlen. PR #110 kürzt große Notizen in Feeds zum Erhalt des Scroll-Rhythmus, und PR #111 behebt iOS-Mobile-Zoom beim Kommentieren von Aktionen, verursacht durch kleine Schriftgrößen.

Clawstr liefert CLI und Lightning-Zap-Buttons

Clawstr, die Reddit-inspirierte Plattform, auf der KI-Agenten Communities auf Nostr erstellen und verwalten, mergte 3 PRs diese Woche. In PR #11 werden alle manuellen nak-Befehle in den KI-Agenten-Skill-Definitionen durch das neue @clawstr/cli-Paket (npx -y @clawstr/cli@latest) ersetzt, manuelle JSON-Event-Konstruktion zugunsten von CLI-Befehlen eliminiert und Wallet-Operationen (init, balance, zap, npc) sowie NIP-50 Volltextsuche hinzugefügt.

PR #13 bringt eine „For Humans"-Dokumentationsseite und eine ProfileZapDialog-Komponente. Auf Profilseiten erscheint der Zap-Button, sobald eine Lightning-Adresse konfiguriert ist, und funktioniert ohne Login per LNURL-pay mit voreingestellten sats-Beträgen und QR-Code-Anzeige. In PR #12 wird der wallet sync-Befehl dokumentiert und erklärt, wie Zahlungen an Lightning-Adressen von NPC gehalten werden, bis Agenten ihre Wallets explizit synchronisieren.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

Gemergt:

NIP-45: HyperLogLog Relay Response - NIP-45 (Event-Zählung) unterstützt jetzt HyperLogLog (HLL) Approximate Counting. Relays können 256-Byte HLL-Registerwerte zusammen mit COUNT-Antworten zurückgeben. Durch Zusammenführen dieser Register von mehreren Relays berechnen Clients approximative Kardinalitäten, ohne vollständige Event-Sets herunterladen zu müssen. Primärer Anwendungsfall sind Follower- und Reaktionszähler, ohne auf ein einzelnes Relay als autoritative Quelle angewiesen zu sein. Schon zwei Reaktions-Events verbrauchen mehr Bandbreite als die 256-Byte-HLL-Payload. HyperLogLog++-Korrekturen verbessern die Genauigkeit bei kleinen Kardinalitäten.
NIP-39: Identitäts-Tags aus Kind 0 verschoben - NIP-39 Identitätsanspruchs-Tags (i-Tags) wurden aus kind 0 Metadaten-Events in ein neues dediziertes kind 10011 extrahiert. Begründung: fast keine Clients unterstützen diese Tags, sodass sie jedem kind 0 Abruf Größe hinzufügen, ohne Mehrwert zu bieten. Dies ist der erste in einer Reihe von Kind-0-Extraktions-PRs von vitorpamplona (siehe Neuigkeiten-Abschnitt).

Offene PRs und Diskussionen:

NIP-XX: Nostr Relay Connect (NRC) - woikos schlägt ein Protokoll zum Zugriff auf Nostr-Relays durch verschlüsseltes Tunneling via öffentliches Rendezvous-Relay vor. Ermöglicht wird damit der Zugang zu Relays hinter NAT oder Firewalls, einschließlich persönlicher Relays auf Heimservern oder Mobilgeräten. Verwendet werden kind 24891/24892 Events mit NIP-44-Verschlüsselung. Praktische Anwendung: jeder Nostr-Client kann lokalen Speicher (IndexedDB, SQLite) als Relay-Endpunkt für geräteübergreifende Synchronisation bereitstellen. Standard NIP-01 Semantiken (REQ, EVENT, CLOSE, COUNT) passieren den Tunnel transparent. Referenzimplementierungen existieren in Go (ORLY Relay) und TypeScript (Smesh).
Nostr Web Tokens (NWT) - pippellia-btc schlägt Nostr Web Tokens vor, ein Nostr-Event-Format zur Übermittlung signierter Claims zwischen Web-Parteien, inspiriert von JSON Web Tokens (JWTs). NWT kann sowohl NIP-98 (HTTP Auth) als auch Blossom-Autorisierungs-Events repräsentieren und gibt Clients Flexibilität in Bezug darauf, wie und wie lange Tokens gültig bleiben. Verfügbar ist eine Go-Referenzbibliothek. Verlinkt im PR sind eine Video-Erklärung und ein detaillierter Vergleich mit NIP-98 und Blossom Auth.
NIP-47-Vereinfachung - rolznz schlägt vor, die multi_-Methoden aus NIP-47 (Nostr Wallet Connect) zu entfernen, da sie komplex zu implementieren waren und keine Adoption fanden. Reduziert wird auch Duplizierung in Verschlüsselungs- und Abwärtskompatibilitäts-Handling, was die Spec nach der Hold-Invoice-Ergänzung letzte Woche bereinigt.
NIP-05: Verschiebung in eigenen Event-Kind - vitorpamplona schlägt vor, NIP-05-Verifizierung von kind 0 in ein neues kind 10008 zu verschieben, was mehrere NIP-05-Identifikatoren pro Nutzer und Filterung nach NIP-05-Adresse ermöglicht. Teil der Kind-0-Schlankheitskampagne.
NIP-57: Lightning-Adressen aus Kind 0 - vitorpamplona schlägt vor, lud06/lud16 (Lightning-Adressen) aus kind 0 in einen dedizierten Event-Kind gemäß NIP-57 zu extrahieren, und setzt die Kind-0-Schlankheitsbemühung fort.
Profil-Hypercustomization - fiatjaf schlägt erweiterte Profilanpassungsfähigkeiten vor, die weit hinaus gehen, was kind 0 derzeit unterstützt.

NIP Deep Dive: NIP-45 (Event-Zählung) und HyperLogLog

NIP-45 (Spec) definiert, wie Clients Relays bitten können, Events zu zählen, die einem Filter entsprechen, ohne die Events selbst zu übertragen. Mit dem Merge von HyperLogLog-Unterstützung diese Woche kommt eine probabilistische Datenstruktur hinzu, die ein grundlegendes Problem löst: wie zählt man Dinge sicher, die auf mehreren unabhängigen Relays verteilt liegen.

Das Problem:

Events auf einem einzelnen Relay zu zählen ist einfach: COUNT-Anfrage senden, Zahl zurückbekommen. Netzwerkübergreifend ist es schwieriger. Meldet Relay A 50 Reaktionen und Relay B 40, ergibt das nicht 90, da viele Events auf beiden Relays existieren. Die wahre Zählung lässt sich nicht ermitteln, ohne alle Events herunterzuladen und zu deduplizieren.

HyperLogLog:

HyperLogLog (HLL) ist ein probabilistischer Algorithmus, der die Anzahl eindeutiger Elemente in einer Menge mit festem Speicherbedarf schätzt. In NIP-45 kommen 256 Register mit je einem Byte zum Einsatz, was genau 256 Bytes verbraucht, unabhängig von der Anzahl gezählter Events. Funktionieren tut der Algorithmus, indem er die Binärdarstellung jeder Event-ID untersucht und die Position der führenden Nullen verfolgt. Events, deren IDs mit vielen Nullen beginnen, sind statistisch selten, sodass ihr Auftreten auf eine große Menge hinweist.

Wie es in NIP-45 funktioniert:

Antwortet ein Relay auf eine COUNT-Anfrage, kann es ein hll-Feld mit base64-kodierten Registerwerten einschließen:

["COUNT", "<subscription_id>", {"count": 4527, "hll": "<base64 encoded 256 bytes>"}]

HLL-Werte von mehreren Relays sammelt der Client und führt sie zusammen, indem er den Maximalwert an jeder Registerposition übernimmt. Dieses zusammengeführte HLL repräsentiert die Vereinigungsmenge aller Event-Sets und behandelt Deduplizierung automatisch. Aus den zusammengeführten Registern wird dann die endgültige Kardinalitätsschätzung berechnet.

Genauigkeit:

Bei 256 Registern beträgt der Standardfehler ungefähr 5,2%. Liegt die tatsächliche Zählung bei 1.000, fällt die Schätzung typischerweise zwischen 948 und 1.052. Konstant bleibt der relative Fehler auch bei größeren Zählungen: 100.000 wird auf ungefähr 94.800-105.200 geschätzt. HyperLogLog++-Korrekturen verbessern die Genauigkeit bei kleinen Kardinalitäten (unter ca. 200), wo der Basisalgorithmus zur Überschätzung neigt.

Warum es wichtig ist:

Soziale Metriken (Follower-Zahlen, Reaktionszahlen, Repost-Zahlen) sind Kernfunktion von Social-Media-Clients. Relays einzeln abzufragen zentralisiert die Zählung, alle Events von allen Relays herunterzuladen verschwendet Bandbreite. HLL ermöglicht gute ungefähre Zählungen von mehreren Relays mit nur 256 Bytes Overhead pro Relay, unabhängig von der tatsächlichen Zählung. Schon zwei Reaktions-Events verbrauchen mehr Bandbreite als eine vollständige HLL-Payload.

Fixiert ist die Registeranzahl auf 256 zur Interoperabilität. Alle Relays produzieren zusammenführbare HLL-Werte, unabhängig von der verwendeten Implementierung. Einmal implementiert, profitieren Clients von jedem Relay, das HLL unterstützt.

Aktueller Status:

Von fiatjaf eröffnet, war der PR mehrere Monate in Diskussion, bevor er diese Woche gemergt wurde. Relay-Implementierungen müssen HLL-Berechnung zu ihren COUNT-Handlern hinzufügen, Client-Implementierungen brauchen HLL-Zusammenführung in ihrer Zählaggregationslogik.

NIP Deep Dive: NIP-96 (HTTP-Dateispeicherung) und der Übergang zu Blossom

NIP-96 (Spec) definierte, wie Nostr-Clients Dateien auf HTTP-Medienservern hochladen, herunterladen und verwalten. Inzwischen als „nicht empfohlen" zugunsten von Blossom (BUD-basiertes Medien-Hosting) markiert, bleibt NIP-96 diese Woche relevant, weil Angor v0.2.5 NIP-96-Serverkonfiguration hinzugefügt hat und ZSP v0.3.1 auf Blossom-Server hochlädt, was einen Protokollübergang in Aktion zeigt.

Wie NIP-96 funktioniert:

Fähigkeiten eines Dateiservers erkennt der Client durch Abruf von /.well-known/nostr/nip96.json, das API-URL, unterstützte Inhaltstypen, Größenlimits und verfügbare Medientransformationen zurückgibt:

{
 "api_url": "https://file-server.example/api",
 "download_url": "https://cdn.example/files",
 "content_types": ["image/jpeg", "video/webm", "audio/*"],
 "plans": {
 "free": {
 "is_nip98_required": true,
 "max_byte_size": 10485760,
 "media_transformations": {
 "image": ["resizing"]
 }
 }
 }
}

Zum Hochladen sendet der Client einen multipart/form-data POST an die API-URL mit einem NIP-98-Autorisierungs-Header (ein signiertes Nostr-Event, das die Identität des Uploaders beweist). Zurück kommt eine NIP-94 Dateimetadaten-Struktur mit Datei-URL, Original- und transformierten SHA-256-Hashes, MIME-Typ und Abmessungen:

{
 "status": "success",
 "nip94_event": {
 "tags": [
 ["url", "https://cdn.example/files/<hash>.png"],
 ["ox", "<original-file-hash>"],
 ["x", "<transformed-file-hash>"],
 ["m", "image/png"],
 ["dim", "800x600"]
 ]
 }
}

Downloads verwenden GET-Anfragen an <api_url>/<sha256-hash>, mit optionalen Abfrageparametern wie Bildgrößenänderung (z.B. Breite 320). Löschung erfolgt per DELETE mit NIP-98-Auth, und nur der ursprüngliche Uploader kann seine Dateien löschen. Paginierte Ergebnisse der Uploads lassen sich per Dateilistungs-Endpunkt abrufen.

Zur Deklaration bevorzugter Upload-Server veröffentlichen Nutzer kind 10096 Events, sodass Clients den richtigen Server automatisch auswählen.

Warum es als veraltet markiert wurde:

NIP-96 band Datei-URLs an bestimmte Server. Fiel files.example.com aus, verlor jede Nostr-Notiz, die darauf verwies, ihre Medien. Fragil war die Adresse, weil der Server selbst die Adresse war.

Blossom (Blobs Stored Simply on Mediaservers) kehrt dies um, indem der SHA-256-Hash des Dateiinhalts zur kanonischen Kennung wird. Jede Blossom-URL enthält den Hash (https://blossom.example/<sha256>.png), aber jeder Blossom-Server, der dieselbe Datei hostet, liefert sie unter demselben Hash-Pfad. Verschwindet ein Server, fragen Clients einen anderen nach demselben Hash ab. Content-Adressierung macht Daten standardmäßig serverübergreifend portabel.

Blossom vereinfacht auch die API. NIP-96 verwendete Multipart-Form-Uploads mit JSON-Antworten, Transformationsrichtlinien und einem Discovery-Endpunkt. Blossom setzt auf einfachen PUT, GET und signierte Nostr-Events (statt HTTP-Header) zur Autorisierung. Aufgeteilt ist die Blossom-Spezifikation in modulare Dokumente: BUD-01 (Server-Protokoll, Autorisierung, Abruf), BUD-02 (Blob-Upload), BUD-03 (Nutzerserver) und BUD-04 (Spiegelung zwischen Servern).

Im September 2025 erfolgte die Markierung als veraltet via PR #2047, der NIP-96 im NIPs-Index als „nicht empfohlen" kennzeichnete.

Der Übergang in der Praxis:

Server wie nostr.build und void.cat unterstützten NIP-96 und haben Blossom-Endpunkte hinzugefügt oder dorthin migriert. In unterschiedlichen Stadien befinden sich die Clients: Angors v0.2.5-Release diese Woche fügte NIP-96-Serverkonfiguration hinzu, während ZSPs v0.3.1-Release Artefakte ausschließlich auf Blossom-Server mit Content-Digest-Headern hochlädt. Amethyst und Primal unterstützen Blossom-Uploads. Fortbestehen wird die Koexistenz wahrscheinlich, bis die verbleibenden NIP-96-Implementierungen ihre Migration abschließen.

Was übernommen wird:

Kind 10096 Server-Präferenz-Events bleiben nützlich. NIP-94-Dateimetadaten (kind 1063 Events) beschreiben Dateieigenschaften weiterhin unabhängig vom verwendeten Upload-Protokoll. Zur Grundlage von Blossoms Content-Adressierung wurde das SHA-256-Hashing, das NIP-96 nutzte. NIP-96s Design informierte, was Blossom vereinfacht hat: Medien-Hosting in einem dezentralisierten Netzwerk erfordert inhaltsadressierten Speicher, um der Zensurresistenz der Relay-Schicht zu entsprechen.

Das war’s für diese Woche. Wer etwas baut, Neuigkeiten hat oder sein Projekt vorgestellt sehen möchte, kann sich per NIP-17 DM an uns wenden oder uns auf Nostr finden.

Nostr Compass #8

Wed, 04 Feb 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: rust-nostr liefert ein großes API-Redesign mit 21 PRs, die die SDK-Architektur überarbeiten. Nostria 3.0 startet mit Dual-Pane-Navigation, Listenverwaltung und einer kompletten UI-Überarbeitung. Vector fügt SIMD-Beschleunigung hinzu und erreicht 65x-184x Geschwindigkeitssteigerungen sowie liefert Marmot-Protokollunterstützung für verschlüsselte Gruppennachrichten. Frostr bringt Threshold-Signierung zu iOS via TestFlight. Damus implementiert NIP-19 (Bech32 Kodierte Entitäten) Relay-Hinweise für Cross-Relay-Inhaltsentdeckung. Primal Android fügt NWC-Verschlüsselung und Wallet-Transaktionsexporte hinzu. nostr-tools und NDK erhalten Zuverlässigkeitsverbesserungen. NIP-82 (Software-Anwendungen) erweitert sich auf 98% der Geräteplattformen. Das NIPs-Repository merged Hold-Invoice-Unterstützung für NIP-47 (Nostr Wallet Connect). Neue Protokollvorschläge umfassen NIP-74 für Podcasting, NIP-DB für Browser-Event-Datenbanken und eine TRUSTed-Filters-Suite für dezentralisierte Inhaltskuration. Neue Projekte umfassen Instagram to Nostr v2 für Content-Migration, Pod21 startet einen dezentralisierten 3D-Druck-Marktplatz, Clawstr führt KI-Agenten-verwaltete Communities ein, und Shosho und NosCall erweitern Live-Streaming- und Videoanruf-Fähigkeiten.

Neuigkeiten

rust-nostr liefert großes API-Redesign

Das rust-nostr SDK durchlief diese Woche eine signifikante Architekturüberarbeitung mit 21 gemergten PRs, die Breaking Changes in der gesamten Bibliothek einführen. Das Redesign betrifft Kern-APIs, auf die sich die meisten Rust-Entwickler verlassen.

PR #1245 redesignt Notification-APIs, während PR #1244 RelayNotification::Shutdown durch RelayStatus::Shutdown für sauberere Zustandshandhabung ersetzt. Die Signer-APIs sind jetzt via PR #1243 an andere SDK-Muster angeglichen. Client- und Relay-Methoden erhielten Cleanup in PR #1242, und Client-Optionen verwenden jetzt ein Builder-Pattern (PR #1241).

Message-Sending-APIs wurden in PR #1240 redesignt, REQ-Unsubscription in PR #1239 und Relay-Entfernung in PR #1229. Ein offener PR #1246 fügt Unterstützung für blockierende APIs hinzu, um das Redesign abzurunden.

Die Änderungen bringen Konsistenz in das SDK, werden aber Migrationsaufwand von bestehenden Projekten erfordern. Entwickler, die auf rust-nostr aufbauen, sollten den Changelog sorgfältig prüfen, bevor sie upgraden.

Instagram to Nostr v2 ermöglicht Content-Migration

Ein neues Tool ermöglicht es Kreativen, ihre bestehenden Inhalte von zentralisierten Plattformen zu Nostr zu migrieren. Instagram to Nostr v2 unterstützt den Import von Instagram, TikTok, Twitter und Substack, ohne Zugang zu den privaten Schlüsseln des Benutzers zu benötigen.

Das Tool adressiert eine häufige Onboarding-Barriere: Benutzer, die zögern, auf einer neuen Plattform von vorne anzufangen, können jetzt ihre Inhaltshistorie bewahren. Es unterstützt auch das Verschenken von Nostr-Konten an neue Benutzer oder das Vorschlagen von Inhalten an bestehende Konten, was es nützlich macht, anderen beim Übergang zum Protokoll zu helfen.

Pod21: Dezentralisiertes 3D-Druck-Netzwerk

Pod21 (pod21.com) verbindet 3D-Drucker-Betreiber mit Käufern unter Verwendung von Nostr für Marktplatz-Koordination. Die Plattform enthält einen NIP-17 (Private Direktnachrichten)-kompatiblen DM-Bot, der Marktplatz-Interaktionen handhabt und es Käufern ermöglicht, Drucke anzufordern und mit Herstellern durch verschlüsselte Direktnachrichten zu verhandeln.

Hersteller listen ihre Druckkapazität und Fähigkeiten; Käufer durchsuchen Listings und initiieren Bestellungen über den Bot. Die Architektur folgt einem ähnlichen Muster wie andere Nostr-Commerce-Anwendungen: Relay-basierte Entdeckung, verschlüsselte Nachrichten für Bestellkoordination und Lightning für Abwicklung. Pod21 reiht sich neben Ridestr und Shopstr als Nostr-Anwendung ein, die reale Transaktionen durch das Protokoll koordiniert.

Clawstr: KI-Agenten-Sozialnetzwerk

Clawstr startet als Reddit-inspirierte Plattform, auf der KI-Agenten Communities auf Nostr erstellen und verwalten. Die Plattform ermöglicht es autonomen Agenten, thematische Communities zu etablieren, Inhalte zu kuratieren und mit Benutzern zu interagieren. Communities funktionieren wie Subreddits, aber mit KI-Moderatoren und Kuratoren, die Diskussionen leiten. Die Architektur nutzt Nostrs offenes Protokoll für Agent-zu-Agent- und Agent-zu-Mensch-Interaktionen und etabliert ein neues Modell für Community-Bildung in dezentralisierten sozialen Medien.

Releases

Ridestr v0.2.0: RoadFlare Release

Ridestr lieferte v0.2.0, genannt der “RoadFlare Release”, der persönliche Rideshare-Netzwerke einführt. Die Funktion lässt Fahrgäste Lieblingsfahrer zu einem vertrauenswürdigen Netzwerk hinzufügen. Fahrer genehmigen Follower und teilen verschlüsselte Standorte, sodass Fahrgäste sehen können, wann vertrauenswürdige Fahrer online und in der Nähe sind. Fahrtanfragen gehen direkt an bekannte Fahrer.

Die Zahlungszuverlässigkeit verbesserte sich mit automatischer Escrow-Wiederherstellung, besserer Wallet-Synchronisierung über Geräte hinweg und schnellerer Zahlungsverarbeitung durch progressives Polling. PR #37 fügt die Phase 5-6 Infrastruktur hinzu, die diese Features unterstützt. v0.2.1 folgte mit Hotfixes für Zahlungsdialog-Bugs und den “Zu Favoriten hinzufügen”-Flow nach der Fahrt.

Nostria 3.0

Nostria, sondrebs plattformübergreifender Client für globale Skalierung, lieferte Version 3.0 mit einer kompletten UI-Überarbeitung, neuem Logo und Hunderten von Fixes. Das Release repräsentiert einen intensiven sechswöchigen Entwicklungszyklus.

Dual-Pane-Navigation ist die größte UX-Änderung, die es Desktop-Benutzern ermöglicht, Kontextwechsel beim Navigieren zwischen Listen, Details und Threads zu reduzieren. Ein neuer Home-Bereich bietet einen Überblick über alle verfügbaren Funktionen, und alle Bildschirme teilen eine vereinheitlichte Toolbar, Layout und Funktionalität.

Listenverwaltung ist das bedeutendste Feature-Update, das durch die gesamte Anwendung integriert ist. Benutzer können Profillisten verwalten und Inhalte in jeder Funktion filtern: Streams, Musik oder Feeds. Genervt von Spam in Threads? Filtern nach Favoriten, um nur deren Antworten zu sehen. Quick Zaps fügt Ein-Tap-Zapping mit konfigurierbaren Werten hinzu. Copy/Screenshot generiert Zwischenablage-Screenshots zum Teilen von Events überall. Stummgeschaltete Wörter filtert jetzt nach Profilfeldern (name, display_name, NIP-05), was es Benutzern ermöglicht, alle gebridgten Profile mit einem einzelnen gebannten Wort zu blockieren. Einstellungen wurden durchsuchbar für schnellere Konfigurationsänderungen.

Das Release fügt BOLT11- und BOLT12-Zahlungsanforderungs-Rendering, Textgröße- und Schriftauswahl sowie “Notiz-an-sich-selbst”-Nachrichten im Nachrichten-Bereich mit Rendering von referenzierten Inhalten wie Artikeln und Events hinzu. Der neue Teilen-Dialog ermöglicht schnelles Teilen per E-Mail, Websites oder Direktnachrichten an mehrere Empfänger. Zusätzliche Features umfassen benutzerdefinierte Emoji-Sets, Interessen (Hashtag-Listen als dynamische Feeds), Lesezeichen, öffentliche Relay-Feeds und vollständige Menüanpassung einschließlich welche Option das Nostria-Icon öffnet.

Verfügbar auf Android, iOS, Windows und im Web unter nostria.app.

Applesauce v5.1.0

hzrd149s Applesauce-Bibliothekssuite veröffentlichte v5.1.0 für alle Pakete. applesauce-signers fügt Unterstützung für switch_relays- und ping-Methoden auf Nostr Connect Remote-Signern hinzu, nützlich für die programmatische Verwaltung von Signer-Verbindungen. applesauce-loaders führt loadAsyncMap für paralleles asynchrones Laden ein. applesauce-react fügt Padding-Argumente zu useAction().run() hinzu. applesauce-core aktualisiert Event-zu-Store-Mapping, um Strings direkt ohne onlyEvents zu handhaben.

nak v0.18.3

fiatjafs nak (Nostr Army Knife) erreichte v0.18.3 mit Stabilitätsfixes von mattn. Das Release verhindert Panics, wenn Mint-URLs den ://-Separator nicht haben, validiert Dateparser-Fehler vor Verwendung von Datumswerten und handhabt Grenzfälle beim AUTH-Challenge-Tag-Parsing. Diese defensiven Fixes machen die CLI robuster beim Verarbeiten fehlerhafter Eingaben.

Aegis v0.3.7

Aegis, der plattformübergreifende Desktop-Signer, lieferte v0.3.7 mit Nostr App Browser-Unterstützung mit NIP-07 (Browser-Erweiterungs-Interface)-Signierung. Das Release zeichnet NIP-04 (Verschlüsselte Direktnachrichten)- und NIP-44 (Versionierte Verschlüsselung)-Verschlüsselungs-Events auf, was es Benutzern ermöglicht zu verfolgen, welche Anwendungen Verschlüsselungsoperationen anfordern. Das Browser-Segment filtert jetzt nach Plattform, um nur Web-Apps anzuzeigen.

Bitchat v1.5.1 (iOS)

Bitchat, die offline-fähige Messaging-App mit Nostr und Bluetooth-Mesh, veröffentlichte v1.5.1 mit iOS-Sicherheitshärtung. PR #1012 validiert Nostr-Event-Signaturen vor der Verarbeitung, lehnt ungültige Giftwraps und eingebettete Pakete ab, begrenzt übergroße Payloads und blockiert gefälschte BLE-Announce-Sender-IDs. PR #998 behebt iOS BLE-Mesh-Authentifizierung durch Bindung von Sender-IDs an Verbindungs-UUIDs, was Identitätsfälschung im Mesh-Netzwerk verhindert. PR #972 fügt Benachrichtigungs-Ratenbegrenzung hinzu, um Peer-Discovery-Fluten zu verhindern, wenn mehrere Mesh-Geräte in der Nähe sind.

KeyChat v1.39.2

KeyChat veröffentlichte v1.39.2 mit NIP-47 Nostr Wallet Connect-Unterstützung via PR #148. Benutzer können jetzt externe Lightning-Wallets für Zahlungen innerhalb der Messaging-App verbinden. Das Release fügt auch macOS-Desktop-Benachrichtigungen hinzu.

Nostrmo v3.5.0

Nostrmo, der plattformübergreifende Flutter-Client, lieferte v3.5.0 mit Überarbeitung seines Feed-Systems. Das Update ersetzt feste Feeds durch anpassbare Alternativen: General Feed, Mentioned Feed und Relay Feed, jeweils konfigurierbar durch neue Bearbeitungsseiten. Das Release implementiert Outbox-Modell-Unterstützung für besseres Event-Routing und erweitert lokale Relay-Funktionalität mit konfigurierbaren Größenlimits und Subscription-Unterstützung.

Shosho v0.11.1

Shosho, die Live-Streaming-App für Nostr, veröffentlichte v0.11.1 mit Aufnahme- und VOD-Fähigkeiten. Das Update fügt Raum-Präsenzindikatoren hinzu, die zeigen, wer Streams schaut, Thread-Chat-Konversationen für bessere Diskussionsorganisation und Nostr Connect-Unterstützung auf iOS via NIP-46. Streamer können jetzt ihre Übertragungen für späteres Ansehen speichern, während sie Echtzeit-Chat-Interaktionen mit ihrem Publikum aufrechterhalten.

NosCall v0.5.0

NosCall, die Audio- und Videoanruf-App für Nostr, lieferte v0.5.0 mit Kontaktgruppen zur Organisation von Anrufen nach Kategorie, Relay-Management für Verbindungsoptimierung und konfigurierbaren ICE-Server-Einstellungen für verbesserte NAT-Traversierung. Das Release fügt auch Dark-Mode-Unterstützung hinzu. NosCall verwendet Nostr für Anrufsignalisierung und -koordination und ermöglicht Peer-to-Peer-Anrufe ohne zentralisierte Server.

diVine 1.0.4

diVine, rabbles Kurzform-Loop-Video-Client, veröffentlichte 1.0.4 als Android-Pre-Release-Alpha vor seiner Zapstore-Einreichung. Das Release konzentriert sich auf das Testen von Nostr-Schlüsselverwaltung, einschließlich nsec-Import, NIP-46 (Nostr Connect) Remote-Signierung mit nsecBunker und Amber sowie nostrconnect://-URL-Handling. Das Team bittet um Feedback zu Relay-Kompatibilität und Video-Interoperabilität mit anderen Clients. PR #1265 behebt iOS-Dateipfad-Handling, das dazu führte, dass Videoclips nach App-Updates unbrauchbar wurden, indem relative Pfade statt absoluter Container-Pfade gespeichert werden. PR #1251 behebt Navigationsprobleme beim Anzeigen von Profilen aus Kommentaren.

Zeus v0.12.2

Zeus lieferte v0.12.2 als stabiles Release und konsolidiert die NWC-Fixes aus vorherigen Ausgaben.

Frostr Igloo iOS TestFlight

Frostr (frostr.org) startete Igloo für iOS auf TestFlight und erweitert Threshold-Signierung auf Apple-Geräte. Frostr verwendet FROST (Flexible Round-Optimized Schnorr Threshold)-Signaturen, um nsec-Schlüssel in Shares aufzuteilen, die über Geräte verteilt werden, was k-von-n-Signierung mit Fehlertoleranz ermöglicht. Benutzer, die im “Demo-Modus” beitreten, nehmen an einem Live-2-von-2-Threshold-Signatur-Experiment teil, das die Echtzeit-Koordinationsfähigkeiten des Protokolls demonstriert. Das iOS-Release schließt sich Igloo für Android (v0.1.2) an, das im Dezember mit NIP-55 (Android Signer)-Unterstützung für App-übergreifende Signierungsanfragen geliefert wurde. Beide mobilen Clients ergänzen Igloo Desktop und die Frost2x-Browser-Erweiterung.

Projekt-Updates

Damus implementiert NIP-19 Relay-Hinweise

Damus mergte PR #3477 und implementiert NIP-19 Relay-Hinweis-Verarbeitung für Event-Abruf. Die Funktion ermöglicht das Anzeigen von Notizen auf Relays, die nicht im konfigurierten Pool des Benutzers sind, indem Hinweise aus NIP-10 (Antwort-Threads), NIP-18 (Reposts) und NIP-19-Referenzen extrahiert werden. Die Implementierung verwendet ephemere Relay-Verbindungen mit referenzgezähltem Cleanup, was permanente Relay-Pool-Erweiterung vermeidet.

Zusätzliche Fixes umfassen Lightning-Invoice-Parsing (PR #3566), Wallet-View-Loading (PR #3554), Relay-List-Timing (PR #3553) und Profil-Preloading zur Reduzierung von visuellem “Popping” (PR #3550). Ein Entwurfs-PR #3590 zeigt NIP-17-Private-DM-Unterstützung in Arbeit.

Primal Android liefert NWC-Verschlüsselung

Primal Android hatte eine sehr aktive Woche mit 18 gemergten PRs, fokussiert auf Wallet-Infrastruktur. Die App integriert jetzt mit Spark, Lightspars selbstverwahrendes Lightning-Protokoll. PR #874 fügt NWC-Verschlüsselungsunterstützung hinzu, während PR #872 NWC-Info-Events sendet, wenn Verbindungen hergestellt werden.

PR #870 ermöglicht CSV-Export für Wallet-Transaktionen, nützlich für Buchhaltung und Steuerzwecke. PR #716 fügt einen lokalen Account-Switcher im Note-Editor hinzu. Mehrere Wallet-Restore-Fixes (PR #876, PR #875, PR #873) adressieren Grenzfälle für Benutzer mit Nicht-Spark-Wallet-Konfigurationen.

Marmot TypeScript SDK fügt Nachrichtenverlauf hinzu

Die TypeScript-Implementierung des Marmot-Protokolls entwickelt sich weiter. PR #38 von hzrd149 implementiert Nachrichtenverlaufs-Persistenz mit Paginierung für die Referenz-Chat-Anwendung, während PR #39 die Bibliotheks-Ergonomie verbessert.

Auf der Rust-Seite implementiert PR #161 wiederholbares Zustandshandling zur Bewahrung des Nachrichtenkontexts bei Fehlern, und PR #164 wechselt zu std::sync::Mutex, um tokio-Panics mit SQLite zu vermeiden. Das whitenoise-rs-Backend fügt Amber-Integration (PR #418) hinzu, Upgrades auf MDK und nostr-sdk 0.44 (PR #467) und führt Echtzeit-Benachrichtigungs-Streaming via PR #460 mit NewMessage- und GroupInvite-Event-Typen ein.

HAVEN fügt periodische WoT-Aktualisierung hinzu

HAVEN, das persönliche Relay, mergte PR #108 mit periodischer Web of Trust-Aktualisierung. Die Funktion stellt sicher, dass Vertrauensbewertungen aktuell bleiben, während sich die sozialen Graphen der Benutzer entwickeln, was die Spam-Filtergenauigkeit im Laufe der Zeit verbessert.

nostr-tools

nostr-tools, die Kern-JavaScript-Bibliothek, erhielt diese Woche mehrere Verbesserungen. Commits umfassen einen Fix für Hashtag-Parsing nach Zeilenumbrüchen in NIP-27 (Textnotiz-Referenzen)-Erwähnungen, automatisches Pruning von kaputten Relay-Objekten mit Idle-Tracking für Verbindungs-Cleanup, Message-Queue-Entfernung für Single-Threaded-Leistungsoptimierung und Source-File-Exports für bessere TypeScript-Imports.

NDK

NDK lieferte beta.71 mit einem Fix für Reconnection nach Geräte-Sleep/Wake-Zyklen und Stale-Connection-Handling, der Zuverlässigkeitsprobleme für mobile Anwendungen adressiert.

Notedeck

Notedeck, der Desktop-Client des Damus-Teams, hat einen offenen PR #1279, der einen NIP-34 (Git-Zusammenarbeit)-Viewer hinzufügt. Dies würde das Durchsuchen von Git-Repositories, Patches und Issues ermöglichen, die auf Nostr-Relays veröffentlicht wurden, direkt innerhalb des Clients, was Notedeck zu einem potenziellen Frontend für ngit-basierte Workflows macht.

njump

njump, das Nostr-Web-Gateway, fügte Unterstützung für zwei NIP-51 (Listen)-Event-Typen via PR #152 hinzu. Das Gateway rendert jetzt kind:30000 Follow Sets, die kategorisierte Gruppierungen von Benutzern sind, die Clients in verschiedenen Kontexten anzeigen können, und kind:39089 Starter Packs, die kuratierte Profilsammlungen sind, die für Teilen und Gruppen-Following konzipiert sind. Diese Ergänzungen lassen njump community-kuratierte Listen anzeigen, wenn Benutzer nevent-Links teilen.

Amethyst

Amethyst, der Android-Client, behob einen Bug, der das Teilen von Videos aus der Player-Ansicht verhinderte (PR #1695). Die “Video teilen”-Option erschien nicht, weil der Content-Parameter nicht an die Control-Buttons-Komponente übergeben wurde. Benutzer können jetzt Nostr-Video-Inhalte direkt aus dem Player an andere Apps teilen. PR #1693 behebt Jackson-JSON-Deserialisierungs-Crashes, die beim Parsen bestimmter fehlerhafter Events auftraten.

Jumble

Jumble, der Web-Client fokussiert auf Relay-Feed-Browsing, fügte Audio-Datei-Uploads via Zwischenablage in PR #743 hinzu. Benutzer können jetzt Audio-Dateien direkt in den Post-Editor einfügen, der sie zu konfigurierten Medienservern hochlädt und die URL in der Notiz einbettet. Die Funktion spiegelt bestehende Bild-Einfüge-Funktionalität wider.

Flotilla

Flotilla, hodlbods NIP-29 (Relay-basierte Gruppen)-Communities-Client, lieferte Benachrichtigungen via PR #270. Das Update refaktoriert das Alert-System von Anchor-basiertem Polling zu lokalen Pull-Benachrichtigungen für Web und Push-Benachrichtigungen für Mobile. Die Architektur implementiert den vorgeschlagenen NIP-9a-Standard (siehe PR #2194 unten), bei dem Benutzer Webhook-Callbacks bei Relays registrieren und verschlüsselte Event-Payloads erhalten, wenn Filter matchen.

Formstr

Formstr, die Nostr-native Formular-Anwendung, fügte Formular-Import und verschlüsselte Formular-Unterstützung in PR #422 hinzu. Benutzer können jetzt bestehende Formulare über einen Antwort-Link oder aus anderen Formstr-Instanzen importieren. Die Verschlüsselungsfunktion erlaubt Formularerstellern, Antworten einzuschränken, sodass nur bestimmte Empfänger Einsendungen lesen können, nützlich für Umfragen, die sensible Informationen sammeln.

Pollerama

Pollerama (pollerama.fun), aufgebaut auf nostr-tools, fügte NIP-17-DM-Teilen für Umfragen via PR #141 und PR #142 hinzu. Benutzer können jetzt Umfragen direkt an Kontakte durch verschlüsselte Direktnachrichten teilen.

Nostrability Schemata

Nostrability schemata, die JSON-Verifizierungsschema-Sammlung für Nostr-Events, fügte NIP-59 (Gift Wrap)-Abdeckung via PR #59 hinzu. Das Update enthält Schemata für kind 13 (seal) und kind 1059 (gift wrap) Events, die die bestehende NIP-17-Schema-Abdeckung ergänzen.

Vector

Vector, der datenschutzfokussierte Desktop-Messenger mit NIP-17, NIP-44 und NIP-59 für Zero-Metadata-Verschlüsselung, mergte PR #39 mit SIMD-beschleunigten Leistungsoptimierungen. Hex-Encoding läuft 65x schneller, Bildvorschau-Generierung bis zu 38x schneller und Nachrichtensuchen 184x schneller durch Binary-Search-Indexierung. Der PR fügt ARM64 NEON Intrinsics für Apple Silicon und x86_64 AVX2/SSE2 mit Runtime-Erkennung für Windows und Linux hinzu. Der Speicherverbrauch sank mit Message-Structs, die von 472 auf 128 Bytes reduziert wurden, und npub-Speicherung um 99,6% durch Interning gekürzt.

Vector v0.3.0 (Dezember 2025) integrierte MDK (Marmot Development Kit) für MLS-Protokoll-basierte Gruppennachrichten und brachte Ende-zu-Ende-verschlüsselte Gruppen mit Forward Secrecy zum Client. MIP-04-Dateifreigabe handhabt jetzt imeta-Anhänge für MLS-Gruppen, konzipiert für Interoperabilität mit White Noise. Das Release führte auch eine Mini-Apps-Plattform mit WebXDC-basierten P2P-Multiplayer-Spielen ein, einen dezentralisierten App-Store namens The Nexus, PIVX-Wallet-Integration für In-App-Zahlungen, Nachrichtenbearbeitung mit vollständiger Verlaufsverfolgung und 4x Speicherreduktion während Bild-Uploads.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

Gemerged:

NIP-47: Hold-Invoice-Unterstützung - NIP-47 (Nostr Wallet Connect) unterstützt jetzt Hold-Invoices und ermöglicht fortgeschrittene Zahlungsworkflows, bei denen Empfänger Zahlungen explizit abwickeln oder stornieren müssen. Der PR fügt drei neue RPC-Methoden hinzu: make_hold_invoice erstellt eine Hold-Invoice unter Verwendung eines vorgenerierten Preimage und Payment-Hash, settle_hold_invoice beansprucht Zahlung durch Bereitstellung des originalen Preimage, und cancel_hold_invoice lehnt Zahlung unter Verwendung seines Payment-Hash ab. Eine neue hold_invoice_accepted-Benachrichtigung feuert, wenn ein Zahler Zahlung sperrt. Dies ermöglicht Anwendungsfälle wie Pay-to-Unlock-Inhalte, Marktplatz-Escrow-Systeme und Payment-Gating. Implementierungen sind bereits in Arbeit in Alby Hub, Alby JS-SDK und dart NDK.
NIP-05: Kleinschreibungsanforderung - NIP-05 (Domain-Verifizierung) erfordert jetzt explizit Kleinschreibung für sowohl Hex-Public-Keys als auch lokale Namen in der nostr.json-Datei. Dies war implizit in der Spezifikation, aber nicht angegeben, was Interoperabilitätsprobleme verursachte, wenn einige Implementierungen gemischte Groß-/Kleinschreibung verwendeten, während andere auf Kleinschreibung normalisierten. Clients, die NIP-05-Identifikatoren validieren, sollten jetzt alle nostr.json-Antworten ablehnen, die Großbuchstaben in Schlüsseln oder Namen enthalten.
NIP-73: Ländercodes - NIP-73 (Geotags) unterstützt jetzt ISO 3166-Ländercodes als Alternative zu Geohashes. Events können ["g", "US", "countryCode"]-Tags enthalten, um Standort auf Länderebene anzuzeigen, ohne präzise Koordinaten zu erfordern. Dies ermöglicht länderbasierte Inhaltsfilterung und -entdeckung für Anwendungen, bei denen exakter Standort unnötig oder unerwünscht ist. Der PR fügte auch ein fehlendes Geohash-Beispiel zur Spec-Dokumentation hinzu.

Offene PRs und Diskussionen:

NIP-82: Software-Anwendungen - franzap kündigte ein großes Update dieser Entwurfsspezifikation an, die definiert, wie Software-Anwendungen über Nostr mit kind 30063 Release-Events verteilt werden. Das Update deckt jetzt ungefähr 98% der Geräteplattformen global ab, einschließlich macOS, Linux, Windows, FreeBSD, WASM-Umgebungen, VS Code-Erweiterungen, Chrome-Erweiterungen und Web Bundles/PWAs. Das Team fokussiert sich als nächstes auf Android-, PWA- und iOS-Unterstützung und lädt Entwickler ein, sich auf diesen gemeinsamen Standard zu einigen. Zapstore plant, in den kommenden Wochen auf das neue Format zu migrieren.
NIP-74: Podcasts - Definiert adressierbare Events für Podcast-Shows (kind 30074) und Episoden (kind 30075). Shows enthalten Metadaten wie Titel, Beschreibung, Kategorien und Cover-Bilder. Episoden referenzieren ihre Eltern-Show und enthalten Enclosure-URLs, Dauern und Kapitelmarker. Die Spec integriert sich mit Podcasting 2.0-Metadaten-Standards und enthält Value-Tags für V4V (Value-for-Value)-Monetarisierung via Lightning. Plattformen wie transmit.fm, eine Nostr-native Podcast-Publishing-Plattform, können direkt zu Relays mit diesem Format publizieren, was Podcastern ermöglicht, Inhalte ohne Intermediäre zu verteilen.
NIP-FR: Friends-Only Notes - Schlägt einen Mechanismus vor, um Notizen nur für eine benutzerdefinierte Freundesliste sichtbar zu veröffentlichen, unter Verwendung eines gemeinsamen symmetrischen Schlüssels namens ViewKey. Der Autor verschlüsselt Notizen (kind 2044) mit dem ViewKey mittels NIP-44. Der ViewKey selbst wird jedem Freund einmalig über NIP-59 (Gift Wrap) zugestellt. Freunde, die den ViewKey besitzen, können die Notizen entschlüsseln und lesen; alle anderen sehen nur Chiffretext. Wenn der Autor einen Freund entfernt, wird der ViewKey rotiert: Ein neuer Schlüssel wird generiert und über Gift Wrap an alle verbleibenden Freunde neu verteilt, sodass der entfernte Freund den Zugriff auf zukünftige Beiträge verliert. Dieser Ansatz trennt Inhaltsverschlüsselung (symmetrisch, effizient) von Schlüsselverteilung (asymmetrisch, pro Freund) und hält das Protokoll leichtgewichtig, während eine häufig angefragte Datenschutzfunktion ermöglicht wird.
NIP-DB: Browser Nostr Event Database Interface (spec) - Schlägt ein Standard-window.nostrdb-Interface für Browser-Erweiterungen vor, die lokalen Nostr-Event-Speicher bereitstellen. Die API enthält Methoden zum Hinzufügen von Events, Abfragen nach ID oder Filter, Zählen von Treffern und Abonnieren von Updates. Web-Anwendungen können dieses Interface verwenden, um aus lokal gecachten Events zu lesen, ohne Relay-Anfragen zu machen, was Bandbreite und Latenz reduziert. hzrd149s nostr-bucket-Browser-Erweiterung bietet eine Referenzimplementierung und injiziert das Interface in alle Browser-Tabs. Eine begleitende Polyfill-Bibliothek implementiert dieselbe API mit IndexedDB für Umgebungen ohne die Erweiterung.
TRUSTed Filters - Eine Suite von fünf verwandten Vorschlägen für dezentralisierte Inhaltskuration, aufbauend auf vitorpamplonas merged Trusted Assertions PR #1534. Die Kernspezifikation führt kind 17570 Events zum Deklarieren von Trust-Provider-Präferenzen ein, was Benutzern ermöglicht zu spezifizieren, welchen Diensten sie für Event-Filterung und -Ranking vertrauen. Trust-Provider veröffentlichen Assertions (kind 37571), Statistiken (kind 37572) und Rankings (kind 37573), die Clients abonnieren können. Das System verwendet eine Plugin-Architektur mit W/w-Tags zur Spezifizierung von Filter-Typen und -Transformationen. Dies ermöglicht rechenintensive Operationen wie Spam-Erkennung, Reputationsbewertung und Inhalts-Ranking auf dedizierter Infrastruktur laufen zu lassen, während Benutzer Kontrolle darüber behalten, welchen Providern sie vertrauen. Die Suite enthält separate Specs für Filter-Presets, Benutzer-Rankings, vertrauenswürdige Events und Plugin-Definitionen.
NIP-9a: Push-Benachrichtigungen - hodlbod schlägt einen Standard für Relay-basierte Push-Benachrichtigungen mit kind 30390 Registrierungs-Events vor. Benutzer erstellen eine Registrierung, die Filter für Events enthält, die sie empfangen möchten, und eine Webhook-Callback-URL. Die Registrierung wird an den pubkey des Relays verschlüsselt (aus seinem NIP-11 self-Feld). Wenn passende Events auftreten, POSTen Relays zum Callback mit der Event-ID (Klartext zur Deduplizierung) und dem Event selbst (NIP-44-verschlüsselt an den Benutzer). Diese Architektur lässt Relays Benachrichtigungen pushen, während Event-Inhalte vor intermediären Push-Servern geschützt werden. Flotillas PR #270 implementiert diesen Standard.
Catallax - Schlägt ein dezentralisiertes Vertragsarbeitsprotokoll mit Escrow unter Verwendung von kind 33400 Events vor. Das System definiert drei Rollen: Schlichter kündigen Verfügbarkeit und Bedingungen an, Auftraggeber erstellen finanzierte Aufgaben mit gesperrtem Bitcoin, und freie Agenten erledigen Arbeit, um Zahlung zu beanspruchen. Schlichter lösen bei Bedarf Streitigkeiten. Das Protokoll ermöglicht vertrauenslose Freelance-Arbeitskoordination, bei der Mittel gesperrt sind, bis Lieferungen akzeptiert oder Schlichtung abgeschlossen sind.

NIP Deep Dive: NIP-47 (Nostr Wallet Connect)

NIP-47 definiert Nostr Wallet Connect (NWC), ein Protokoll für Remote-Lightning-Wallet-Steuerung unter Verwendung von Nostr als Kommunikationsschicht. Mit der Hold-Invoice-Unterstützungs-Ergänzung dieser Woche deckt NWC jetzt das volle Spektrum von Lightning-Operationen ab.

Das Protokoll funktioniert durch einen einfachen Austausch. Eine Wallet-Anwendung veröffentlicht ein “Wallet-Info”-Event (kind 13194), das ihre Fähigkeiten beschreibt. Client-Anwendungen senden verschlüsselte Anfragen (kind 23194), die das Wallet bitten, Operationen wie das Bezahlen von Invoices, Erstellen von Invoices oder Prüfen von Salden durchzuführen. Das Wallet antwortet mit verschlüsselten Ergebnissen (kind 23195).

NWC verwendet NIP-44-Verschlüsselung zwischen Client und Wallet mit einem dedizierten Schlüsselpaar für Wallet-Operationen, das von der Hauptidentität des Benutzers getrennt bleibt. Diese Trennung bedeutet, dass das Kompromittieren einer NWC-Verbindung die Nostr-Identität des Benutzers nicht offenlegt.

Unterstützte Methoden:

Die Spec definiert Methoden für Kern-Lightning-Operationen: pay_invoice sendet Zahlungen, make_invoice generiert Invoices zum Empfangen, lookup_invoice prüft Zahlungsstatus, get_balance gibt das Wallet-Guthaben zurück, und list_transactions liefert Zahlungshistorie. Das neu gemergte pay_keysend ermöglicht Zahlungen ohne Invoices, und hold_invoice unterstützt bedingte Zahlungen.

Beispiel-Events:

Der Wallet-Dienst veröffentlicht ein Info-Event (kind 13194), das seine Fähigkeiten bewirbt:

{
 "kind": 13194,
 "pubkey": "<wallet service pubkey>",
 "content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions notifications",
 "tags": [
 ["encryption", "nip44_v2"],
 ["notifications", "payment_received payment_sent"]
 ],
 "created_at": "<unix timestamp>",
 "id": "<event hash>",
 "sig": "<wallet service signature>"
}

Ein Client sendet eine verschlüsselte Anfrage (kind 23194), um eine Invoice zu bezahlen:

{
 "kind": 23194,
 "pubkey": "<client ephemeral pubkey from connection URI secret>",
 "content": "<NIP-44 encrypted: {\"method\": \"pay_invoice\", \"params\": {\"invoice\": \"lnbc50n1...\"}}>",
 "tags": [
 ["p", "<wallet service pubkey>"],
 ["encryption", "nip44_v2"]
 ],
 "created_at": "<unix timestamp>",
 "id": "<event hash>",
 "sig": "<client ephemeral key signature>"
}

Der Wallet-Dienst antwortet (kind 23195) mit dem Zahlungsergebnis:

{
 "kind": 23195,
 "pubkey": "<wallet service pubkey>",
 "content": "<NIP-44 encrypted: {\"result_type\": \"pay_invoice\", \"result\": {\"preimage\": \"...\"}, \"error\": null}>",
 "tags": [
 ["p", "<client ephemeral pubkey>"],
 ["e", "<request event id>"]
 ],
 "created_at": "<unix timestamp>",
 "id": "<event hash>",
 "sig": "<wallet service signature>"
}

Der e-Tag in der Antwort referenziert die ursprüngliche Anfrage, was Clients ermöglicht, Antworten ihren Anfragen zuzuordnen.

Hold Invoices:

Der PR #1913 dieser Woche fügte Hold-Invoice-Unterstützung hinzu und ermöglicht Escrow-artige Zahlungen. Im Gegensatz zu Standard-Invoices, bei denen der Empfänger Zahlung sofort durch Freigabe des Preimage beansprucht, lassen Hold-Invoices den Empfänger diese Entscheidung aufschieben. Wenn ein Zahler an eine Hold-Invoice sendet, sperren sich Mittel entlang der Zahlungsroute. Der Empfänger wählt dann entweder abwickeln (Preimage freigeben und Mittel beanspruchen) oder stornieren (Zahlung ablehnen, Mittel an den Zahler zurückgeben). Wenn keine Aktion erfolgt, läuft die Zahlung ab und Mittel kehren automatisch zurück. Der PR fügt drei NWC-Methoden hinzu: make_hold_invoice, settle_hold_invoice und cancel_hold_invoice, plus eine hold_invoice_accepted-Benachrichtigung. Dieser Mechanismus treibt Anwendungen wie Ridestrs Rideshare-Escrow und Marktplatz-Streitbeilegung an.

Aktuelle Implementierungen:

Große Wallets unterstützen NWC: Zeus, Alby und Primal (ab dem PR #874 dieser Woche) implementieren alle Wallet-seitige Unterstützung. Auf der Client-Seite können Damus, Amethyst und die meisten großen Nostr-Clients sich mit NWC-Wallets für Zapping und Zahlungen verbinden.

Das Protokoll ermöglicht eine Trennung der Zuständigkeiten: Benutzer können ihr Wallet auf einem Gerät betreiben, während sie von einem anderen mit Nostr interagieren, wobei Nostr-Relays als Kommunikationskanal dienen. Diese Architektur bedeutet, dass mobile Clients Mittel nicht direkt halten müssen, was die Sicherheit verbessert, indem Wallet-Infrastruktur von sozialen Clients getrennt bleibt.

Sicherheitsüberlegungen:

NWC-Verbindungen sollten als sensitiv behandelt werden. Während die Verschlüsselung Nachrichteninhalte schützt, müssen Wallet-pubkey und Verbindungsgeheimnis geschützt werden. Anwendungen sollten Benutzern ermöglichen, Verbindungen zu widerrufen und Ausgabelimits zu setzen. Das Protokoll unterstützt Fähigkeitsbeschränkungen, sodass Wallets limitieren können, welche Operationen eine bestimmte Verbindung durchführen kann.

NIP Deep Dive: NIP-59 (Gift Wrap)

NIP-59 definiert ein Protokoll zum Einkapseln beliebiger Nostr-Events in mehrere Verschlüsselungsschichten, das die Identität des Absenders vor Relays und Beobachtern verbirgt. Die Vorschläge dieser Woche für Friends-Only Notes (NIP-FR) und Push-Benachrichtigungen (NIP-9a) verlassen sich beide auf Gift Wrapping, was es zu einem grundlegenden Datenschutz-Primitiv macht, das es wert ist, verstanden zu werden.

Die drei Schichten:

Gift Wrapping verwendet drei verschachtelte Strukturen:

Rumor (unsigniertes Event): Der ursprüngliche Inhalt als Nostr-Event ohne Signatur. Der Rumor kann nicht direkt an Relays gesendet werden, weil Relays unsignierte Events ablehnen.
Seal (kind 13): Der Rumor wird mit NIP-44 verschlüsselt und in ein kind 13 Event platziert. Der Seal IST vom tatsächlichen Schlüssel des Autors signiert. Dies ist der kryptographische Beweis der Autorschaft.
Gift Wrap (kind 1059): Der Seal wird verschlüsselt und in ein kind 1059 Event platziert, das von einem zufälligen, einmaligen Schlüsselpaar signiert ist. Der Gift Wrap enthält einen p-Tag für das Routing zum Empfänger.

Ein häufiges Missverständnis: Abstreitbarkeit

Die Spec erwähnt, dass unsignierte Rumors “Abstreitbarkeit” bieten, aber das ist irreführend. Die Seal-Schicht IST vom echten Autor signiert. Wenn der Empfänger den Gift Wrap und dann den Seal entschlüsselt, hat er kryptographischen Beweis, wer die Nachricht gesendet hat. Der Empfänger könnte sogar einen Zero-Knowledge-Proof konstruieren, der die Identität des Absenders offenlegt, ohne seinen eigenen privaten Schlüssel preiszugeben.

Was Gift Wrap tatsächlich bietet, ist Absender-Privatsphäre vor Beobachtern: Relays und Dritte können nicht bestimmen, wer die Nachricht gesendet hat, weil sie nur den Gift Wrap sehen, der von einem zufälligen Schlüssel signiert ist. Aber der Empfänger weiß es immer und kann es beweisen.

Beispiel-Events:

Hier ist die vollständige Drei-Schichten-Struktur aus der Spec (Senden von “Gehst du heute Abend zur Party?”):

Der Rumor (unsigniert, kann nicht an Relays veröffentlicht werden):

{
 "created_at": 1691518405,
 "content": "Are you going to the party tonight?",
 "tags": [],
 "kind": 1,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "id": "9dd003c6d3b73b74a85a9ab099469ce251653a7af76f523671ab828acd2a0ef9"
}

Der Seal (kind 13, vom echten Autor signiert, enthält verschlüsselten Rumor):

{
 "kind": 13,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "content": "AqBCdwoS7/tPK+QGkPCadJTn8FxGkd24iApo3BR9/M0uw6n4RFAFSPAKKMgkzVMo...",
 "created_at": 1703015180,
 "tags": [],
 "id": "28a87d7c074d94a58e9e89bb3e9e4e813e2189f285d797b1c56069d36f59eaa7",
 "sig": "02fc3facf6621196c32912b1ef53bac8f8bfe9db51c0e7102c073103586b0d29..."
}

Der Gift Wrap (kind 1059, von zufälligem ephemerem Schlüssel signiert, enthält verschlüsselten Seal):

{
 "kind": 1059,
 "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c",
 "content": "AhC3Qj/QsKJFWuf6xroiYip+2yK95qPwJjVvFujhzSguJWb/6TlPpBW0CGFwfuf...",
 "created_at": 1703021488,
 "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]],
 "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac",
 "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df7..."
}

Beachten: der pubkey des Seals ist der echte Autor (611df01...), während der pubkey des Gift Wraps ein zufälliger Einmal-Schlüssel ist (18b1a75...). Relays sehen nur den Gift Wrap, sodass sie die Nachricht nicht dem echten Autor zuordnen können.

Was jede Schicht schützt:

Der Rumor ist unsigniert und kann nicht direkt an Relays veröffentlicht werden. Der Seal ist vom echten Autor signiert und beweist Autorschaft gegenüber dem Empfänger. Der Gift Wrap ist von einem zufälligen Einmal-Schlüssel signiert und verbirgt den echten Autor vor Relays und Beobachtern. Nur der Empfänger kann durch beide Schichten entschlüsseln, um zum ursprünglichen Inhalt zu gelangen und die Signatur des Autors auf dem Seal zu verifizieren.

Aktuelle Anwendungen:

NIP-17 (Private Direktnachrichten) verwendet Gift Wrap für verschlüsselte DMs und ersetzt das ältere NIP-04-Schema. Das vorgeschlagene NIP-FR (nur für Freunde sichtbare Notizen) verwendet Gift Wrapping zur Verteilung von ViewKeys an Freunde, die dann damit verschlüsselte Notizen entschlüsseln. NIP-9a (Push-Benachrichtigungen) verschlüsselt Benachrichtigungs-Payloads unter Verwendung von Gift-Wrap-Prinzipien.

Metadaten-Schutz:

Zeitstempel sollten randomisiert werden, um Timing-Analysen zu vereiteln. Relays sollten AUTH anfordern, bevor sie kind 1059 Events ausliefern, und sie nur an den markierten Empfänger liefern. Beim Senden an mehrere Empfänger separate Gift Wraps für jeden erstellen.

Das war’s für diese Woche. Baust du etwas? Hast du Neuigkeiten zu teilen? Möchtest du, dass wir über dein Projekt berichten? Kontaktiere uns per NIP-17 DM oder finde uns auf Nostr.

Nostr Compass #7

Wed, 28 Jan 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: Ridestr bringt dezentralisierte Mitfahrgelegenheiten zu Nostr mit Cashu-Zahlungen und verschlüsselter Standortfreigabe. Pomade führt E-Mail-basierte Wiederherstellung für Multisig-Unterzeichner ein. Damus liefert negentropy für zuverlässige DM-Synchronisierung. Amethysts Desktop-App fügt Suche, Lesezeichen und Zaps hinzu. Amber v4.1.1 zeigt Relay-Vertrauensbewertungen an. Marmot merged MIP-03 und entwickelt eine TypeScript-Referenz-Chat-App. diVine fügt NIP-46 QR-Authentifizierung und Erwähnungs-Unterstützung hinzu. Neue NIP-Vorschläge befassen sich mit Community-Management, sequenzbasierter Synchronisierung und verschlüsselter Dateispeicherung. Wir werfen auch einen Blick zurück auf fünf Jahre Nostr-Januare und verfolgen die Entwicklung des Protokolls von einer Handvoll früher Anwender im Jahr 2021 über den explosiven App Store-Start von Damus im Jahr 2023 bis zum ausgereiften Client-Ökosystem von 2025.

Neuigkeiten

Ridestr bringt dezentralisiertes Ridesharing zu Nostr

Ridestr entwickelt eine Peer-to-Peer-Mitfahranwendung, die vollständig auf Nostr aufgebaut ist und direkte Fahrer-Fahrgast-Transaktionen mit Bitcoin- und Cashu-Zahlungen ermöglicht. Das Protokoll verwendet benutzerdefinierte Event-Arten (30173, 3173-3175, 30180/30181) zur Koordinierung von Fahrten und wahrt dabei die Privatsphäre durch progressive Standortfreigabe und NIP-44-Verschlüsselung.

Das System funktioniert durch einen sorgfältig choreografierten Ablauf: Fahrer übertragen ihre Verfügbarkeit mit geohash-codierten Standorten (~5km Präzision) über kind 30173 Events, Fahrgäste fordern Fahrten mit Preisschätzungen über kind 3173 an, und Zahlungen werden mittels HTLC-Treuhand-Tokens vor Fahrtbeginn gesichert. Die Standortprivatsphäre wird durch progressive Freigabe gewahrt, bei der Abholdetails erst bei Ankunft des Fahrers und Zielorte erst nach PIN-Verifizierung geteilt werden. Die gesamte Kommunikation zwischen den Parteien verwendet NIP-44-Verschlüsselung für Privatsphäre.

Ridestr implementiert Zahlungssicherheit durch HTLC-Treuhand mit P2PK-Signaturen. Wenn ein Fahrgast das Angebot eines Fahrers annimmt, sperrt er Cashu-Tokens mit einem Zahlungs-Hash, den nur der Fahrer nach Abschluss der Fahrt einlösen kann. Das Protokoll arbeitet derzeit mit Single-Mint-Architektur, die erfordert, dass Fahrgäste und Fahrer denselben Cashu-Mint verwenden. Die Kotlin-basierte Android-Implementierung des Projekts übernimmt die Proof-Verifizierung und Wiederherstellung veralteter Proofs durch NUT-07 Zustandsprüfungen.

Ridestr nimmt Herausforderungen an, die die meisten Nostr-Anwendungen vermeiden: Echtzeit-Standortkoordination, Zahlungs-Treuhand mit Streitbeilegung und Reputationssysteme für Interaktionen in der physischen Welt. Das Projekt befindet sich in der Beta-Phase und demonstriert, dass Nostrs Event-Modell Peer-to-Peer-Dienstleistungsmarktplätze unterstützen kann, nicht nur Content-Sharing.

Pomade startet Alpha-Wiederherstellungssystem für Multisig-Unterzeichner

Pomade, entwickelt von hodlbod, baut auf dem bestehenden FROSTR-Ökosystem auf, um einen wiederherstellungsorientierten Schwellenwert-Signierdienst bereitzustellen. Unter Verwendung von FROST (Flexible Round-Optimized Schnorr Threshold) Signaturen über die @frostr/bifrost-Bibliothek fügt Pomade E-Mail-basierte Wiederherstellungsabläufe zur Schwellenwert-Kryptographie hinzu. Das System teilt den geheimen Schlüssel eines Benutzers mit Shamir Secret Sharing auf und verteilt Anteile auf mehrere unabhängige Unterzeichner mit einem konfigurierbaren Schwellenwert (2-von-3, 3-von-5, usw.).

Das Protokoll arbeitet vollständig über Nostr unter Verwendung einer einzigen Event-Art (28350) mit NIP-44-verschlüsselten Payloads. Beim Signieren fordert der Client Teil-Signaturen von mindestens threshold Unterzeichnern an und aggregiert diese dann zu einer gültigen Schnorr-Signatur. Für die Verschlüsselung arbeiten die Unterzeichner zusammen, um gemeinsame Geheimnisse über ECDH abzuleiten, ohne dass eine einzelne Partei den vollständigen Schlüssel erfährt.

Die Wiederherstellung funktioniert über zwei Authentifizierungsmethoden: passwortbasiert (unter Verwendung von argon2id mit dem pubkey des Unterzeichners als Salt) oder E-Mail-OTP. Um MITM-Angriffe während der OTP-Wiederherstellung zu verhindern, generiert jeder Unterzeichner seinen eigenen Verifizierungscode mit einem vom Client bereitgestellten Präfix, was Benutzer dazu zwingt, sich unabhängig bei jedem Unterzeichner zu authentifizieren. Das Protokoll erfordert Proof-of-Work für Registrierungs-Events (20+ Bits gemäß NIP-13) um Spam zu verhindern.

Das Vertrauensmodell ist explizit: Wenn threshold Unterzeichner zusammenarbeiten, können sie den Schlüssel stehlen. E-Mail-Anbietern wird vollständig vertraut, da sie OTPs abfangen können. Benutzer können ihren vollständigen geheimen Schlüssel nicht unabhängig wiederherstellen; dies erfordert die Zusammenarbeit von threshold Unterzeichnern. Das Protokoll ist für das Onboarding neuer Benutzer konzipiert, die mit Schlüsselverwaltung nicht vertraut sind, mit der ausdrücklichen Empfehlung, dass Benutzer zur Selbstverwahrung wechseln sollten, sobald sie sich sicher fühlen. Pomade warnt vor potenziellem „Schlüsselverlust, Diebstahl, Denial of Service oder Metadaten-Lecks" angesichts seines ungeprüften Alpha-Status.

Releases

Damus liefert Negentropy für zuverlässige DM-Synchronisierung

Damus v1.13 liefert die negentropy-Implementierung, die wir letzte Woche als offenen PR vorgestellt haben. PR #3536 fügt grundlegende negentropy-Unterstützung zur Netzwerkschicht hinzu und ermöglicht Set-Reconciliation mit Relays, die das Protokoll unterstützen. Ein begleitender PR #3547 fügt Pull-to-Refresh DM-Synchronisierung hinzu, die negentropy verwendet, um fehlende Nachrichten wiederherzustellen, wenn Standard-REQ-Subscriptions fehlschlagen.

Die Implementierung folgt einem konservativen Ansatz: Das normale DM-Laden bleibt unverändert, wobei negentropy als Wiederherstellungsmechanismus verfügbar ist, wenn Benutzer manuell aktualisieren. Automatisierte Tests demonstrieren die Korrektur, indem sie eine DM mit einem alten Zeitstempel generieren, die Standard-Abfragen verfehlen würden, und dann die negentropy-Synchronisierung verwenden, um sie erfolgreich abzurufen. Während negentropy-Unterstützung kompatible Relays erfordert, handhabt die Implementierung gemischte Relay-Umgebungen elegant, indem sie das Protokoll dort verwendet, wo es verfügbar ist.

Amber v4.1.1 - Relay-Vertrauensbewertungen

Amber v4.1.1 liefert die Anzeige von Relay-Vertrauensbewertungen (PR #289) und implementiert die in der letztewöchigen Berichterstattung über Trusted Relay Assertions NIP diskutierten Relay-Bewertungskonzepte. Vertrauensbewertungen erscheinen jetzt auf der Relays-Seite und für NostrConnect-Verbindungsanfragen und helfen Benutzern, die Zuverlässigkeit von Relays einzuschätzen, bevor sie Verbindungen autorisieren. Das Release enthält auch eine neu gestaltete Login/Events/Berechtigungen-Benutzeroberfläche und Unterstützung für die switch_relays-Methode. Leistungsverbesserungen cachen Keystore-Operationen und beheben Berichte über 20+ Sekunden Ladezeiten auf älteren Geräten.

nak v0.18.2 - MCP-Integration

fiatjafs nak (Nostr Army Knife) v0.18.2 fügt Model Context Protocol-Unterstützung über nak mcp hinzu und ermöglicht es KI-Agenten, auf Nostr nach Personen zu suchen, Notizen zu veröffentlichen, Benutzer zu erwähnen und Inhalte mit dem Outbox-Modell zu lesen. Das Release führt auch einen Einzeilen-Installer (curl -sSL https://raw.githubusercontent.com/fiatjaf/nak/master/install.sh | sh) ein, der vorgefertigte Binärdateien herunterlädt und die Go-Toolchain-Anforderung für Endbenutzer eliminiert. Der Bunker-Modus unterstützt jetzt Unix-Sockets und switch_relays.

Zeus v0.12.2 Beta - NWC-Korrekturen

Zeus v0.12.2-beta1 liefert mehrere NWC-Korrekturen, die Probleme aus der letztewöchigen Zeus-Berichterstattung beheben.

Projekt-Updates

Amethyst Desktop - Phase 2A ausgeliefert

Amethyst rollte Phase 2A seiner Desktop-App aus und fügte Suche, Lesezeichen, Zaps, Thread-Ansichten und Langform-Inhalte (Reads) zur Desktop-Erfahrung hinzu. Ein begleitender PR #1683 fügt transparentes Event-Broadcasting-Feedback hinzu, sodass Benutzer jetzt den Echtzeit-Status pro Relay sehen, während ihre Events über das Netzwerk verbreitet werden, was die Diagnose von Verbindungsproblemen erleichtert.

Notedeck-Fortschritt: Kalender-App und UX-Politur

Die Desktop-Anwendung Notedeck des Damus-Teams merged das Auto-Hide-Toolbar-Verhalten (PR #1268), das auf die Scroll-Geschwindigkeit reagiert, um mehr Bildschirmfläche in mobilen Ansichten zu bieten. Ein Entwurfs-PR #1271 fügt eine vollständige NIP-52 Kalender-App mit Monats-/Wochen-/Tages-/Agenda-Ansichten, RSVP-Unterstützung und NIP-22-Kommentaren zu Kalenderereignissen hinzu, derzeit mit Feature-Flag für Tests.

Jumble fügt Community-Modus hinzu

Jumble, der relay-fokussierte Web-Client, fügte Community-Modus und Unterstützung für Relay-Set-Voreinstellungen über Umgebungsvariablen hinzu, was die Bereitstellung thematischer Instanzen wie nostr.moe erleichtert.

Shopstr Bestellungs-Dashboard

Shopstr ersetzte sein chat-basiertes Bestellungsmanagement durch ein dediziertes Bestellungs-Dashboard. Die neue Oberfläche bietet Händlern eine zentrale Ansicht zur Verfolgung des Bestellstatus, zum Markieren von Nachrichten als gelesen und zur Verwaltung der Erfüllung, ohne durch Chat-Threads scrollen zu müssen. Das Update deprecates IndexedDB-Caching zugunsten von serverseitigen Bestellstatus-APIs und überarbeitet die Art und Weise, wie Bestellungs-DMs für bessere Filterung getaggt werden.

Formstr fügt Raster-Fragen hinzu

Formstr, die Nostr-native Formular-App, fügte Raster-Fragen hinzu und schrieb sein SDK um mit Embed-Unterstützung. Ein [Fix für nicht-NIP-07-Unterzeichner](https://github.com/abh3po/nostr-forms/pull/418) behob Probleme für Benutzer mit Bunker- oder lokalen Unterzeichnern, die versuchten, Formulare mit ihrer Identität abzuschicken.

nostr-tools aktualisiert Krypto-Abhängigkeiten

nostr-tools, die Kern-JavaScript-Bibliothek, aktualisierte auf @noble/curves v2.0.1, behob Breaking-API-Änderungen in 27 Dateien und übernahm die neuesten auditierten noble-Bibliotheken. fiatjaf fügte auch switch_relays-Unterstützung zu NIP-46 hinzu, was es Bunker-Clients ermöglicht, Relay-Verbindungen dynamisch zu ändern.

Zeus arbeitet an NIP-87 Mint-Bewertungen

Zeus hat einen [offenen PR für NIP-87 Mint-Bewertungen](https://github.com/ZeusLN/zeus/pull/3576), der es Benutzern ermöglicht, Cashu-Mints zu entdecken und zu bewerten, gefiltert nach Nostr-Follows. Bewertungen enthalten Sternebewertungen und können anonym oder mit dem nsec eines Benutzers abgegeben werden.

Camelus liefert vollständige DM-Unterstützung

Camelus, ein Flutter-basierter Android-Client, der mit Dart NDK für batterieeffiziente mobile Leistung entwickelt wurde, fügte diese Woche umfassende Direktnachrichten mit 20+ Commits hinzu. Das Update umfasst Chat-Kategorien, Nachrichtendaten, optimistische Sende-UI, Notiz-an-sich-selbst-Funktionalität und ordnungsgemäße DM-Relay-Handhabung.

Marmot-Protokoll-Updates

Die deterministische Commit-Auflösung MIP-03, die wir letzte Woche als offenen PR vorgestellt haben, wurde jetzt gemerged. MDK PR #152 stellt sicher, dass alle MLS-basierten Gruppenchats auf denselben Zustand konvergieren, wenn mehrere gültige Commits für dieselbe Epoche ankommen.

Ein begleitender Spec PR #28 fügt Anforderungen für den init_key-Lebenszyklus hinzu, die Lücken aus Implementierungsaudits adressieren: Privates Schlüsselmaterial aus Welcome-Nachrichten muss nach der Verarbeitung sicher gelöscht werden (Nullierung, Speicherbereinigung), und neue Mitglieder müssen innerhalb von 24 Stunden Selbst-Updates für Forward Secrecy durchführen.

Das TypeScript SDK (marmot-ts) entwickelt eine Referenz-Chat-Anwendung. PR #37 fügt Gruppenerstellung/-auflistung, Key-Package-Management mit Publish/Broadcast/Delete-Flows und QR-Code-Einladungen hinzu. Ein offener PR #38 von hzrd149 implementiert Nachrichtenverlaufs-Persistenz mit Paginierung. Das whitenoise-rs Backend merged diese Woche 15 PRs, darunter Mehrsprachenunterstützung (PR #455) und MIP-04 v2 Medienreferenzen (PR #450).

diVine fügt Nostr-Integrationsfunktionen hinzu

diVine, die Kurzform-Video-App, setzt die schnelle Nostr-Integration fort.

Offene PRs umfassen NIP-46 QR-Code-Authentifizierung (PR #1019) und NIP-17 verschlüsselte Direktnachrichten (PR #834). Die Aktivität dieser Woche konzentrierte sich auf Erwähnungs-Unterstützung, die nostr:-URIs und @Erwähnungen in klickbare Profillinks umwandelt, Classic Viners Avatar-Fallbacks mit Nostr-Profilen und Video-Bearbeitungstools einschließlich Zeichnen, Filter und Sticker.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

Zusammengeführt:

Trusted Relay Assertions - Der Vorschlag zur Standardisierung von Relay-Vertrauensbewertungen, den wir letzte Woche vorgestellt haben, wurde zusammengeführt. Die Spezifikation definiert kind 30385 Events für Relay-Vertrauensaussagen mit Bewertung über Zuverlässigkeit, Qualität und Erreichbarkeit. Die Diskussion vor dem Zusammenführen drehte sich darum, ob Vertrauensbewertungen „global" (einmal für alle Benutzer berechnet) oder „personalisiert" (relativ zum sozialen Graphen jedes Beobachters) sein sollten. PageRank-ähnliche Algorithmen wie nostr.band’s Trust Rank und GrapeRank widerstehen Sybil-Angriffen, indem sie jeden durch gefälschte Konten weitergegebenen Rang durch die Größe der Bot-Farm teilen.

Offene PRs und Diskussionen:

Communikeys - Ein umfassender Vorschlag für Community-Management, der bestehende npubs als Community-Identifikatoren verwendet, anstatt relay-basierter Ansätze. Jeder npub kann eine Community werden, indem er ein kind 10222 Event veröffentlicht; Veröffentlichungen zielen auf Communities über kind 30222 Events. Die Zugriffskontrolle verwendet NIP-58-Badges und ermöglicht delegiertes Mitgliedschaftsmanagement mit Cold Storage für Community-Schlüssel.
NIP-CF: Changes Feed - Ein Entwurf, der sequenzbasierte Event-Synchronisierung als Alternative zu zeitstempelbasierten since-Filtern vorschlägt. Das Problem: Standard-Nostr-Synchronisierung mit since-Zeitstempeln kann Events verpassen, wenn mehrere Events denselben sekundenpräzisen Zeitstempel teilen, Client- und Relay-Uhren auseinanderdriften oder Checkpointing ungenau ist. NIP-CF löst dies, indem Relays eingehenden Events monoton steigende Sequenznummern zuweisen, was eine strikte Gesamtordnung bietet. Clients fordern Änderungen seit einer bestimmten Sequenznummer an und erhalten Events in garantierter Reihenfolge mit präzisem Checkpointing, das niemals Events verpasst. Der Vorschlag unterstützt auch Live-/Continuous-Modus, bei dem Subscriptions nach der initialen Synchronisierung für Echtzeit-Updates offen bleiben.
NIP-XX: Encrypted File Sync - Ein Protokoll, das kinds 30800 (verschlüsselte Dateien), 30801 (Tresor-Indizes) und 30802 (geteilte Dokumente) für die Synchronisierung verschlüsselter Inhalte über Geräte hinweg mit Nostr-Relays definiert. Das Protokoll ermöglicht local-first Notiz-Apps, Ende-zu-Ende-verschlüsselte Synchronisierung ohne zentralisierte Server bereitzustellen. Dateiinhalte, Pfade, Namen und Ordnerstruktur werden alle mit NIP-44 Selbstverschlüsselung verschlüsselt, sodass Relays Blobs speichern, die sie nicht lesen können. Binäre Anhänge wie Bilder verwenden Blossom-Server mit clientseitiger Verschlüsselung. Kind 30802 ermöglicht die Dokumentenfreigabe zwischen Benutzern durch Verschlüsselung an den öffentlichen Schlüssel des Empfängers.

Fünf Jahre Nostr-Januare

Der Newsletter des letzten Monats verfolgte Nostrs Dezember-Meilensteine von fiatjafs erstem Client-Release bis zu Jack Dorseys katalytischer Spende. Dieser Rückblick zeichnet nach, was jeden Januar von 2021 bis 2025 passierte, mit Fokus auf verifizierte technische Entwicklungen.

Januar 2021: Frühe Entwicklung

Nostrs dritter Monat sah die fortgesetzte Entwicklung an Branle, fiatjafs Vue.js-Client, der im Dezember 2020 gestartet war. Eine kleine Gruppe früher Anwender, wahrscheinlich weniger als 15 Personen, koordinierte sich über die Telegram-Gruppe @nostr_protocol (erstellt am 16. November 2020) und testete das Protokoll auf ein oder zwei experimentellen Relays. Der Kommandozeilen-Client noscl ermöglichte terminalbasierte Interaktion.

Das technische Fundament war bereits festgelegt: Benutzer identifiziert durch secp256k1 öffentliche Schlüssel, Beiträge kryptographisch signiert mit Schnorr-Signaturen und Relays als dumme Speicher, die nicht miteinander kommunizieren. Dies war bewusst Bitcoin-native Kryptographie, eine Designentscheidung, die Jahre später die Adoptionsmuster prägen sollte.

Januar 2022: Entwickler-Entdeckung

Der Januar 2022 begann, während Nostr noch vom ersten Hacker-News-Auftritt (31. Dezember 2021) summte, der 110 Punkte und 138 Kommentare generierte. Zum Zeitpunkt dieses Posts betrieben nur etwa sieben Relays das gesamte Netzwerk, wobei Kommentatoren anmerkten: „Spam ist noch kein Problem, weil Nostr super neu ist und niemand es benutzt." Robert C. Martin („Uncle Bob") hatte Nostr als potentiell „die Endspiel-Lösung für soziale Kommunikation" unterstützt. Die Diskussion setzte sich im Januar fort, wobei Entwickler über Relay-Architektur versus echtes P2P, Zensurresistenz versus Moderation und ob Einfachheit skalieren kann, debattierten.

Der HN-Post löste eine Welle neuer Implementierungen aus. Uncle Bob selbst startete more-speech, einen Clojure-Desktop-Client, am 18. Januar. fiatjafs go-nostr-Bibliothek (erstellt Januar 2021) und noscl-Kommandozeilen-Client stellten Go-Tooling bereit, während nostr-tools JavaScript-Unterstützung bot. Bis Dezember 2022 hatten etwa 800 Profile Bios. Branle blieb der primäre Web-Client und erhielt Updates einschließlich Private-Key-Import und Multi-Relay-Unterstützung. Technische Herausforderungen waren offensichtlich: 64-Zeichen-Hex-Schlüssel erwiesen sich als unintuitiv, Nachrichtenverzögerungen frustrierten Benutzer, und die Community fragte sich, ob die Architektur Twitter-skaliertem Traffic standhalten könnte.

Januar 2023: Der Durchbruch

Der Januar 2023 transformierte Nostr vom Experiment zur Bewegung. Damus, der iOS-Client von William Casarin (jb55), kämpfte mit Apples App Store-Genehmigungsprozess. Am 1. Januar abgelehnt, am 26. Januar erneut abgelehnt, wurde er schließlich am 31. Januar genehmigt. Diese Genehmigung löste eine Kaskade aus: Damus erreichte sofort Platz 10 in den US Social Networking Charts. Jack Dorsey nannte es „einen Meilenstein für offene Protokolle."

Acht Tage zuvor, am 23. Januar, kündigte Edward Snowden seine Präsenz auf Nostr an: „Eines der coolen Dinge an Nostr… neben Zensurresistenz ist, dass man nicht auf 280 Zeichen beschränkt ist." Seine Unterstützung als NSA-Whistleblower hatte Gewicht in datenschutzbewussten Kreisen, und Benutzer begannen sofort, ihm Sats über Lightning zu zappen.

Web-Clients rannten um die Wette, um den Zustrom aufzunehmen. Snort, erstellt von kieran im Dezember 2022, entstand als funktionsreicher React-Client; am 13. Januar integrierte Snort NIP-05-Registrierung über die Nostr Plebs API, was neuen Benutzern ermöglichte, menschenlesbare Identitäten während des Onboardings zu beanspruchen. Iris, hauptberuflich entwickelt von Martti Malmi (einem frühen Bitcoin-Mitwirkenden, der die zweite Bitcoin-Transaktion überhaupt von Satoshi erhielt), bot sowohl Web- als auch Mobile-Interfaces mit kostenlosen NIP-05-Identitäten bei iris.to. Astral, gebaut von monlovesmango mit Quasar (Vue.js) als Branle-Fork, konzentrierte sich auf Relay-Management mit seiner Relay-Gruppierungsfunktion, die es Benutzern ermöglichte, Relays in Sets zum Posten und Filtern zu organisieren. TestFlight-Betas für iOS-Clients füllten sich innerhalb von Stunden, und Amethyst dominierte Android.

Die Infrastruktur kämpfte, um Schritt zu halten. Alle Relays wurden von Enthusiasten betrieben, die aus eigener Tasche zahlten. Bezahlte Relays mit Lightning-Mikrozahlungen schufen natürliche Spam-Filterung, führten aber Zugangsreibung ein. Damus wurde nur zwei Tage nach der Genehmigung aus Chinas App Store entfernt, Berichten zufolge auf Anfrage von Chinas oberster Internet-Aufsichtsbehörde.

Januar 2024: Protokoll-Härtung

Der Januar 2024 konzentrierte sich auf Protokollstandardisierung und Community-Aufbau. Nostr PHX startete das Jahr mit einem Meetup am 5. Januar in Phoenix und brachte lokale Cypherpunks zusammen. Dies war das erste von vielen Community-Events in diesem Jahr, darunter BTC Prague (Juni), Nostriga in Riga (August) und Nostrasia.

Die bedeutendste Protokollentwicklung war das Mergen von NIP-59 (Gift Wrap) am 29. Januar, das Metadatenschutz für verschlüsselte Kommunikation bietet. Gift Wrap baut auf NIP-44s Verschlüsselungsstandard (der im Dezember 2023 von Cure53 auditiert worden war) auf, um die Absenderidentität vor Relays zu verbergen. Das Protokoll wickelt verschlüsselte Nachrichten in ein äußeres Event ein, das von einem zufälligen, einmalig verwendeten Schlüsselpaar signiert ist. Relays sehen nur den Wegwerf-Pubkey, während die echte Absenderidentität im verschlüsselten Payload verborgen ist, den nur der Empfänger entschlüsseln kann. Dies verhindert, dass Relay-Betreiber und Netzwerkbeobachter erfahren, wer mit wem kommuniziert. Zeitstempel können auch randomisiert werden, um Timing-Analysen zu vereiteln.

Das Ökosystem expandierte über Social Media hinaus. Plebeian Market wurde vollständig Nostr-nativ mit NIP-15-Konformität und ermöglichte standübergreifende Warenkörbe und einen Standbrowser zum Entdecken von Händlern. Shopstr entstand als erlaubnisfreier Marktplatz für Bitcoin-Handel. Zap.stream, gebaut von kieran, brachte Live-Streaming zu Nostr mit Lightning-Zahlungen zu 21 Sats/Minute. Entwicklerwerkzeuge reiften mit NDK für TypeScript-Abstraktionen und rust-nostr für Rust-Bindings. Zeus v0.8.1 lieferte Nostr-Kontaktimport und persistentes LND und legte den Grundstein für Nostr Wallet Connect Integration in späteren Releases.

Dennoch blieb die Infrastruktur-Nachhaltigkeit herausfordernd. Akademische Forschung aus dieser Zeit fand, dass 95% der Relays Schwierigkeiten hatten, die Betriebskosten zu decken, wobei 20% erhebliche Ausfallzeiten erlebten. Die Eintrittsgebühr für bezahlte Relays betrug im Durchschnitt weniger als 1.000 Sats (~$0,45), unzureichend für einen nachhaltigen Betrieb.

Eine Anmerkung zu Betrug: Das „Nostr Assets Protocol" und der zugehörige „$NOSTR"-Token, die ungefähr zu dieser Zeit gestartet wurden, wurden öffentlich von fiatjaf angeprangert als „100% betrügerisch" und „ein Affinitätsbetrug" ohne Verbindung zum eigentlichen Nostr-Protokoll.

Januar 2025: Client-Reifung

Der Januar 2025 sah die fortgesetzte Client-Entwicklung im gesamten Ökosystem. Nostur 1.17.0 lieferte am 13. Januar geräteübergreifende Synchronisierung für Lesestatus, FROST Multi-Sig-Login-Unterstützung und optimierte lokale Datenbankleistung. Amethyst setzte seinen Übergang zum Outbox-Modell fort und kompilierte automatisch Relay-Sets basierend auf Follow-Listen, anstatt manuelle Konfiguration zu erfordern.

Große Clients begannen, sich von NIP-04 für Direktnachrichten zu entfernen und migrierten in Richtung NIP-17 und dem vorgeschlagenen NIP-104 für verbesserte Verschlüsselung und Metadatenschutz. Das Gossip-Modell (Outbox/Inbox-Kommunikation) gewann an Akzeptanz, während das Ökosystem auf effizientere Relay-Nutzungsmuster konvergierte. Branchenbeobachter sagten voraus, dass dies das Jahr sein würde, in dem Nostr vom Nischenprotokoll zur Mainstream-Anerkennung übergeht, mit einer möglichen hochkarätigen Plattformmigration, die die tägliche Aktivität verdoppeln könnte.

Januar 2026: Sicherheits- und Signierinfrastruktur

Der Januar 2026 brachte bedeutende Fortschritte in der Sicherheits- und Signierinfrastruktur. Primal Android 2.6.18 lieferte NIP-46 Remote-Signing und NIP-55 lokale Signer-Unterstützung und gesellte sich zu Amber und Aegis als vollwertiger Signing-Hub für andere Android-Apps. Bitchat absolvierte ein Cure53-Sicherheitsaudit, dieselbe Firma, die Signal und NIP-44 auditierte, mit 17+ PRs, die kritische Befunde einschließlich DH-Geheimnis-Löschung und Thread-Sicherheitsprobleme beheben. Sowohl Bitchat als auch Damus migrierten von C Tor zu Rust Arti für verbesserte Zuverlässigkeit und Speichersicherheit.

Die Protokollarbeit setzte sich fort mit dem Mergen von NIP-71 (adressierbare Video-Events) und einer Post-Quanten-Kryptographie-NIP, die Diskussionen über die Zukunftssicherheit von Nostr gegen Quantenangriffe eröffnet. Der Trusted Relay Assertions-Entwurf schlug die Standardisierung von Relay-Vertrauensbewertungen durch signierte Attestierungen vor. Das Marmot-Protokoll härtete seine MLS-basierte verschlüsselte Nachrichtenübermittlung mit 18 gemergten PRs, die Audit-Befunde adressieren.

Realwelt-Anwendungen expandierten mit Ridestr, das dezentralisiertes Ridesharing mit Cashu-Treuhand und NIP-44-Verschlüsselung entwickelt, und Pomade, das E-Mail-basierte Wiederherstellungsabläufe zu FROST-Schwellenwert-Signierung hinzufügt. Damus lieferte negentropy für zuverlässige DM-Synchronisierung, während Amethysts Desktop-App Phase 2A mit Suche, Lesezeichen und Zaps erreichte.

Ausblick

Sechs Jahre von Januaren offenbaren Nostrs Evolution von früher Entwicklung (2021) zu öffentlicher Entdeckung (2022) zu explosivem Wachstum (2023) zu Protokoll-Härtung (2024) zu Client-Reifung (2025) zu Sicherheitsinfrastruktur (2026). Das Muster ist jedem vertraut, der das Wachstum offener Protokolle beobachtet hat: Jahre ruhiger Entwicklung, eine plötzliche Explosion, wenn die Bedingungen stimmen, dann die längere Arbeit, alles zuverlässig zu machen. Was mit sieben Relays und einem Hacker-News-Thread begann, ist jetzt auditierte Infrastruktur mit echten Anwendungen. Die Frage für 2027: Wenn jemand eine Fahrt ruft, eine verschlüsselte Nachricht sendet oder einen verlorenen Schlüssel mit Nostr wiederherstellt, werden sie dann überhaupt wissen, dass sie es benutzen?

Das war’s für diese Woche. Baust du etwas? Hast du Neuigkeiten zu teilen? Möchtest du, dass wir über dein Projekt berichten? Kontaktiere uns per NIP-17 DM oder finde uns auf Nostr.

Nostr Compass #6

Wed, 21 Jan 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Ratgeber zu Nostr.

Diese Woche: Bitchat ersetzt C Tor durch die Rust Arti-Implementierung für bessere Zuverlässigkeit und Leistung. nostrdb-rs erhält Streaming-Fold-Abfragen, die Null-Allokations-Datenbankoperationen ermöglichen. Listr wird mit NDK 3 Beta-Migration und KI-gestützter Wartung nach einem Jahr Stillstand grundlegend überarbeitet. Zeus integriert 17 zusammengeführte PRs mit Fokus auf NIP-47 (Nostr Wallet Connect für Remote Lightning Control) Verbesserungen und Cashu-Updates, während Primal Android Wallet-Backup-Flows und NIP-92 (Media-Dimensionen für korrekte Seitenverhältnisse) Unterstützung hinzufügt. Ein neuer Entwurf-NIP schlägt Trusted Relay Assertions für standardisierte Relay-Vertrauensbewertung vor.

Nachrichten

Bitchat wechselt zu Rust Arti für Tor-Unterstützung

Bitchat ist von C Tor zu Arti, der Rust-Implementierung des Tor-Protokolls, migriert. PR #958 entfernt die C Tor-Abhängigkeit und integriert Arti, was Memory-Safety-Garantien und verbesserte Zuverlässigkeit mit sich bringt. Die Änderung behebt das Problem, dass ruhende Wake-Versuche Vordergrund-Service-Neustarts verursachten – ein langjähriges Problem der C-Implementierung.

Was das für Nutzer bedeutet: Stabilere verschlüsselte Messaging mit weniger Abbrüchen, besonders auf mobilen Geräten. Die Rust-Implementierung reduziert Absturzrisiken und Batterieverbrauch durch ständige Wiederverbindungsversuche.

Arti ist eine komplette Neuentwicklung von Tor in Rust durch das Tor Project, um bessere Sicherheit durch Memory Safety und einfachere Integration in Anwendungen zu bieten. Für Bitchat reduzieren die Memory-Safety-Eigenschaften die Angriffsfläche beim Umgang mit verschlüsselten Nachrichten und Relay-Verbindungen. Die Migration folgt der kürzlichen Cure53-Sicherheitsaudit des Teams (behandelt in Newsletter #5) und setzt ihre Sicherheitsverbesserungen fort.

Der PR führt auch umfassende Testabdeckung für ChatViewModel und BLEService ein, entfernt ungenutzten Code und stabilisiert die Test-Suite. Bluetooth Low Energy Mesh-Zuverlässigkeitsverbesserungen begleiten die Tor-Änderungen und beheben Probleme mit großen Datenübertragungen. Zusammen verbessern diese Änderungen Bitchats Widerstandsfähigkeit für Offline-Mesh-Netzwerk-Szenarien, in denen Tor Internetverbindung zusammen mit lokaler BLE-Kommunikation bereitstellt.

Listr mit KI-gestützter Wartung erneuert

JeffG kündigte eine große Überarbeitung von Listr, der Nostr-Listenverwaltungsanwendung unter listr.lol verfügbar, nach mehr als einem Jahr Stillstand des Projekts an. Mit KI-Unterstützung führte er ein umfassendes Upgrade durch, einschließlich Migration zu NDK 3 Beta, Updates auf die neuesten Versionen von Svelte und Vite und alle Abhängigkeiten aktualisiert. Die Überarbeitung bietet erstklassige Unterstützung für Folge-Pakete, implementiert Pagination für Listen mit über 50 Elementen und behebt zahlreiche Fehler, die sich während der Stillstandszeit angesammelt hatten.

Was das für Nutzer bedeutet: Listr ist wieder online mit verbesserter Leistung und neuen Funktionen zur Verwaltung von Folgelisten, Inhaltssammlungen und Topic-Kurationen. Die Pagination-Verbesserung macht große Listen tatsächlich nutzbar.

JeffG bemerkte, dass diese Wartungsarbeit ohne KI-Unterstützung wahrscheinlich nie hätte stattfinden können und das Projekt vor dem Verlassensein bewahrt. Listr ermöglicht Inhalts-Kurationen auf Nostr und erlaubt Nutzern, Listen von Profilen, Topics und Ressourcen zu erstellen, zu verwalten und zu teilen. Das Upgrade hält die Anwendung kompatibel mit aktuellen Nostr-Standards und Client-Erwartungen, da Listenverwaltung zentraler für Content-Discovery im Protokoll wird.

NIP-Updates

Aktuelle Änderungen im NIPs Repository:

Zusammengeführt:

NIP-29 (Relay-basierte Gruppen) - Relay-Schlüssel-Klarstellung (#2190 - zusammengeführt) stellt klar, dass der Relay-Schlüssel die Relay-URL selbst ist, nicht ein pubkey. Die Spec erklärt nun explizit “Der Relay-Schlüssel ist die WebSocket-URL des Relays (z.B. wss://groups.example.com)”, um Verwechslungen zu vermeiden. Dies beeinflusst, wie Clients identifizieren, welcher Relay eine bestimmte Gruppe hostet und stellt sicher, dass Gruppen ordnungsgemäß ihren Hosting-Relays zugeordnet werden.

Offene PRs und Diskussionen:

Trusted Relay Assertions - Ein Entwurf-NIP schlägt die Standardisierung der Relay-Vertrauensbewertung durch kind 30385 Events mit Vertrauenswerten (0-100) vor, berechnet aus NIP-66 (Relay-Entdeckung und Überwachung) Metriken, Betreiber-Reputation und Nutzerberichten. Die Spezifikation unterteilt Vertrauen in Zuverlässigkeit (Verfügbarkeit, Latenz), Qualität (TLS, Dokumentation, Betreiber-Verifizierung) und Zugänglichkeit (Gerichtsbarkeit, Barrieren, Überwachungsrisiko) Komponenten. Die Betreiber-Verifizierung umfasst kryptografische Signaturen über NIP-11 (Relay-Informationsdokumente), DNS TXT-Einträge und .well-known Dateien. Nutzer deklarieren vertraute Assertion-Provider über kind 10385 Events, was Clients ermöglicht, mehrere Provider für unterschiedliche Perspektiven abzufragen. Der Vorschlag ergänzt NIP-66 Entdeckung mit Bewertung und hilft NIP-46 (Remote-Signierung/Nostr Connect) bei der Beurteilung der Relay-Vertrauenswürdigkeit in Verbindungs-URIs.
Post-Quanten-Kryptografie - PR #2185 (offen) entwickelt sich weiter, seit Newsletter #5 den Vorschlag für quantenresistente Algorithmen einführte. Die Diskussion dieser Woche konzentrierte sich auf Implementierungsdetails für Krypto-Agilität: wie Clients duale Signaturen während der Migration handhaben, Rückwärtskompatibilität für ältere Clients und Leistungsauswirkungen größerer quantenresistenter Signaturen. Beitragende debattierten, ob nur ML-DSA-44 vorgeschrieben werden soll oder mehrere Algorithmen (ML-DSA-44, Falcon-512, Dilithium) für Flexibilität unterstützt werden sollen. Der Konsens neigt zu einem schrittweisen Ansatz: optionale Quantensignaturen zunächst, die erst nach breiter Client-Unterstützung und dem Auftreten echter Quantenbedrohungen obligatorisch werden.

NIP Deep Dive: NIP-11 und NIP-66

Diese Woche untersuchen wir zwei NIPs, die zusammenarbeiten, um Relay-Entdeckung und -Bewertung zu ermöglichen: NIP-11 definiert, wie Relays sich selbst beschreiben, und NIP-66 standardisiert, wie wir Relay-Verhalten messen. Zusammen bilden sie die Grundlage für Relay-Vertrauensbewertungssysteme.

NIP-11: Relay-Informationsdokument

NIP-11 definiert ein JSON-Dokument, das Relays über HTTP bereitstellen, um ihre Fähigkeiten, Richtlinien und Betreiberinformationen zu beschreiben. Wenn ein Client sich mit wss://relay.example.com verbindet, kann er https://relay.example.com abrufen (ersetze wss:// durch https://), um das Informationsdokument des Relays zu erhalten.

Das Dokument verwendet Standard-HTTP-Content-Negotiation mit dem Accept: application/nostr+json Header. Dies ermöglicht es Relays, ihre normale Website an Browser zu liefern und gleichzeitig maschinenlesbare Metadaten an Nostr-Clients bereitzustellen. Die Antwort enthält den Namen und die Version der Relay-Software, Kontaktinformationen des Betreibers (pubkey, E-Mail, alternativer Kontakt), unterstützte NIPs und operative Parameter wie Zahlungsanforderungen oder Inhaltsbeschränkungen.

Wichtig ist, dass grundlegende NIP-11-Dokumente unsigniertes JSON sind, das über HTTPS bereitgestellt wird und sich ausschließlich auf TLS-Zertifikate für die Authentizität verlässt. Das bedeutet, dass jeder, der den Webserver des Relays kontrolliert, das Dokument modifizieren kann, wodurch Betreiberbehauptungen nicht verifizierbar sind. Der Trusted Relay Assertions-Vorschlag schließt diese Lücke, indem er signierte Attestierungen durch das self pubkey-Feld eines Relays einführt und kryptografische Beweise für die Betreiberidentität ermöglicht, ähnlich wie Relays signierte Events für Authentifizierungsmechanismen verwenden.

{
 "name": "relay.example.com",
 "description": "Ein allgemeines öffentliches Relay",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "contact": "admin@example.com",
 "supported_nips": [1, 2, 4, 9, 11, 12, 16, 20, 22],
 "software": "git+https://github.com/relay/relay.git",
 "version": "1.2.3",
 "limitation": {
 "max_message_length": 16384,
 "max_subscriptions": 20,
 "max_filters": 100,
 "max_limit": 5000,
 "max_subid_length": 100,
 "min_prefix": 4,
 "max_event_tags": 2000,
 "max_content_length": 8196,
 "min_pow_difficulty": 0,
 "auth_required": false,
 "payment_required": false
 },
 "payments_url": "https://relay.example.com/payments",
 "fees": {
 "admission": [{"amount": 5000, "unit": "msats"}],
 "subscription": [{"amount": 1000, "unit": "msats", "period": 2592000}],
 "publication": []
 }
}

Das limitation-Objekt teilt Clients mit, welche Einschränkungen das Relay durchsetzt. max_message_length begrenzt die WebSocket-Frame-Größe, max_subscriptions begrenzt gleichzeitige REQ-Abonnements pro Verbindung, max_filters begrenzt Filter pro REQ, und max_limit beschränkt, wie viele Events ein einzelner Filter anfordern kann. Diese Parameter helfen Clients, ihr Verhalten an die Relay-Fähigkeiten anzupassen und Verbindungsabbrüche durch Überschreitung von Limits zu vermeiden.

Zahlungsinformationen erscheinen in fees und payments_url. Relays können für Zutritt (einmaliger Zugriff), Abonnement (wiederkehrender Zugriff) oder Publikation (pro Event-Gebühren) Gebühren erheben. Die payments_url verweist auf Details zu Zahlungsmethoden, typischerweise Lightning-Rechnungen oder Ecash-Mints. Kostenpflichtige Relays verwenden diese Felder, um Preise zu kommunizieren, bevor Clients eine Authentifizierung versuchen.

Das supported_nips-Array ermöglicht es Clients, Relay-Fähigkeiten zu entdecken. Wenn ein Relay NIP-50 auflistet, wissen Clients, dass sie Volltextsuche-Anfragen senden können. Wenn NIP-42 erscheint, sollten Clients Authentifizierungs-Herausforderungen erwarten. Diese deklarative Fähigkeits-Werbung ermöglicht progressive Verbesserung: Clients können erweiterte Funktionen nutzen, wo sie verfügbar sind, während sie auf Relays mit begrenzter Unterstützung elegant degradieren.

Betreiberinformationen schaffen Verantwortlichkeit. Das pubkey-Feld identifiziert den Relay-Betreiber auf Nostr und ermöglicht direkte Kommunikation über NIP-17 DMs oder öffentliche Erwähnungen. Die contact-E-Mail bietet eine Off-Protocol-Fallback-Option. Zusammen helfen diese Felder Nutzern, Betreiber für Missbrauchsmeldungen, Zugriffsanfragen oder technische Probleme zu erreichen.

NIP-11-Dokumente sind selbstberichtet: Relays beschreiben, was sie behaupten zu unterstützen, nicht unbedingt, was sie tatsächlich tun. Hier wird NIP-66 wichtig.

NIP-66: Relay-Entdeckung und Lebendüberwachung

NIP-66 standardisiert die Veröffentlichung von Relay-Überwachungsdaten auf Nostr. Überwachungsdienste testen kontinuierlich Relays auf Verfügbarkeit, Latenz, Protokollkonformität und unterstützte NIPs. Sie veröffentlichen Ergebnisse als kind 30166 Events und bieten Echtzeit-Relay-Status unabhängig von Relay-Selbstberichten.

Monitore prüfen die Relay-Verfügbarkeit, indem sie sich verbinden und Test-Abonnements senden. Latenzmessungen verfolgen Verbindungszeit, Abonnement-Antwortzeit und Event-Verbreitungsverzögerung. Protokollkonformitätstests verifizieren, dass das Relay-Verhalten den Spezifikationen entspricht, und erfassen Implementierungsfehler oder absichtliche Abweichungen. Die NIP-Unterstützungsverifizierung geht über NIP-11-Behauptungen hinaus, indem tatsächlich getestet wird, ob beworbene Funktionen korrekt funktionieren.

{
 "id": "a34b5c7d89e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
 "pubkey": "4e2d0bc6f8e7c3a5b9f1d2e3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4",
 "created_at": 1736784000,
 "kind": 30166,
 "tags": [
 ["d", "wss://relay.example.com"],
 ["rtt", "open", "143", "1736784000"],
 ["rtt", "read", "89", "1736784000"],
 ["rtt", "write", "92", "1736784000"],
 ["nips", "1", "2", "4", "9", "11", "12"],
 ["geo", "US", "United States", "New York"],
 ["other", "network", "clearnet"],
 ["other", "payment_required", "false"],
 ["other", "auth_required", "false"]
 ],
 "content": "{\"last_check\": 1736784000, \"checks\": 8760}",
 "sig": "8b9c4d5e6a7f8b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b"
}

Das d-Tag enthält die Relay-URL, was dies zu einem parametrisierten ersetzbaren Event macht. Jeder Monitor veröffentlicht ein Event pro Relay, das aktualisiert wird, wenn sich Messungen ändern. Mehrere Monitore können dasselbe Relay verfolgen und bieten Redundanz und Kreuzvalidierung. Clients fragen mehrere Monitor-Pubkeys ab, um verschiedene Perspektiven zur Relay-Gesundheit zu erhalten.

Round-Trip-Time (rtt) Tags messen die Latenz für verschiedene Operationen. rtt open verfolgt die WebSocket-Verbindungserstellung, rtt read misst die Abonnement-Antwortzeit und rtt write testet die Event-Veröffentlichungsgeschwindigkeit. Alle Werte sind in Millisekunden. Clients verwenden diese Metriken, um Relays mit niedriger Latenz für zeitkritische Operationen zu bevorzugen oder langsame Relays zu deprioritisieren.

Das nips-Tag listet tatsächlich verifizierte NIP-Unterstützung auf, nicht nur behauptete Unterstützung. Monitore testen jeden NIP, indem sie seine Funktionalität ausüben. Wenn ein Relay NIP-50 Suche in seinem NIP-11 Dokument behauptet, aber Suchabfragen fehlschlagen, werden Monitore NIP-50 aus der verifizierten Liste weglassen. Dies liefert Grundwahrheit über Relay-Fähigkeiten.

Geografische Informationen helfen Clients, nahegelegene Relays für bessere Latenz und Zensurresistenz auszuwählen. Das geo-Tag enthält Ländercode, Ländername und Region. Das network-Tag unterscheidet Clearnet-Relays von Tor Hidden Services oder I2P-Endpunkten. Zusammen ermöglichen diese Tags geografische Vielfalt: Clients können sich mit Relays in mehreren Gerichtsbarkeiten verbinden, um regionaler Zensur zu widerstehen.

Monitordaten treiben Relay-Selektoren in Clients, Explorer-Websites und den Trusted Relay Assertions-Vorschlag an. Durch die Kombination von selbstberichteten NIP-11 Dokumenten mit gemessenen NIP-66 Daten und berechneten Vertrauensbehauptungen bewegt sich das Ökosystem in Richtung informierter Relay-Auswahl, anstatt sich auf hartcodierte Standards oder Mundpropaganda-Empfehlungen zu verlassen.

Releases

0xchat v1.5.3 - Erweiterte Messaging-Funktionen

0xchat v1.5.3 bringt bedeutende Verbesserungen für den Telegram-ähnlichen Nostr-Messaging-Client. Die Version behebt NIP-55 (Android-Signer-Anwendung) Compliance-Probleme, die eine ordnungsgemäße Event-Signierung über externe Signer wie Amber verhinderten. Vollständige Compliance bedeutet, dass 0xchat jetzt korrekt Signieroperationen delegiert und die Sicherheit verbessert, indem private Schlüssel isoliert bleiben.

Das Update integriert sowohl FileDropServer als auch BlossomServer als Standard-Medienspeicheroptionen und gibt Nutzern Redundanz für Datei-Uploads. Blossom bietet inhaltsadressierte Speicherung, bei der Dateien durch ihre SHA-256-Hashes referenziert werden, was Integrität sicherstellt und Deduplizierung im Netzwerk ermöglicht. Automatisches Entwurf-Speichern für Moments verhindert Datenverlust beim Verfassen von Langform-Inhalten und behebt Nutzerbeschwerden über verlorene Posts während App-Wechseln oder Verbindungsunterbrechungen.

Die Cashu-Wallet-Integration erhält Politur mit automatischer Proof-Filterung, die ausgegebene Token aus der Wallet-Ansicht entfernt. Dies löst die verwirrende UX, bei der Nutzer ungültige Proofs neben gültigem Ecash sahen, was Bilanzberechnungen unzuverlässig machte. Die Filterung erfolgt clientseitig und bewahrt die Privatsphäre, während sie die Zahlungserfahrung für Peer-to-Peer-Transaktionen innerhalb von Chats verbessert.

Amber v4.1.0 Pre-releases - UI-Überholung

Amber v4.1.0-pre1 bis v4.1.0-pre3 führen eine neu gestaltete Oberfläche für den beliebten Android-Event-Signer ein. Der Login-Bildschirm zeigt jetzt deutlich an, welche Anwendung Signaturberechtigungen anfordert, und behebt Nutzerverwirrung über Autorisierungs-Flows. Der neue Events-Bildschirm bietet detaillierte Inspektion der Daten, die Anwendungen signieren möchten, sodass Nutzer informierte Sicherheitsentscheidungen treffen können, bevor sie Operationen genehmigen.

Das Berechtigungsmanagement erhält erhebliche Aufmerksamkeit mit einer überarbeiteten Oberfläche, die genau zeigt, welche Fähigkeiten jeder verbundenen Anwendung gewährt wurden. Nutzer können spezifische Berechtigungen widerrufen, ohne die Verbindung vollständig zu trennen, was eine feinkörnige Kontrolle über die Signierdelegation ermöglicht. Die überarbeiteten Relay-Zähler mit der aktualisierten Quartz-Bibliothek bieten Echtzeit-Statistiken über Event-Durchsatz und Relay-Leistung. NIP-46 (Nostr Connect) Bunker-Verbindungen zeigen jetzt detaillierte Fehlermeldungen an, wenn Verbindungen fehlschlagen, und ersetzen kryptische Timeout-Fehler durch verwertbare Diagnosen.

Bemerkenswerte Code- und Dokumentationsänderungen

Dies sind zusammengeführte Pull Requests und frühphasige Entwicklungen, die es wert sind, verfolgt zu werden. Einige sind experimentelle Funktionen, die sich vor der Veröffentlichung noch entwickeln könnten.

Zeus (Lightning Wallet mit Nostr Wallet Connect)

Zeus führte diese Woche 17 Pull Requests zusammen und stärkt seine Position als führende NIP-47 Nostr Wallet Connect-Implementierung. Die bedeutendsten Fixes beheben Datenkonsistenz- und Protokollkonformitätsprobleme, die Interoperabilitätsprobleme mit Nostr-Clients verursachten.

Transaktionsverlauf-Fix - PR #3542 behebt einen kritischen Fehler, bei dem NWC-Transaktionslisten falsche oder doppelte Einträge anzeigten. Das Problem trat auf, wenn Zeus Transaktionsdaten zwischenspeicherte, ohne Event-Updates ordnungsgemäß zu handhaben, was dazu führte, dass Nutzer Phantom-Transaktionen oder fehlende Zahlungen sahen. Der Fix implementiert ordnungsgemäße Event-Deduplizierung und Cache-Invalidierung, um sicherzustellen, dass der Transaktionsverlauf den Lightning-Node-Status genau widerspiegelt.

Protokollkonformität - PR #3548 behebt unvollständige getInfo-Antworten, die die Kompatibilität mit Clients brachen, die vollständige NIP-47-Konformität erwarteten. Einige Nostr-Clients stürzten ab, wenn sie partielle Antworten erhielten, denen Felder wie block_height oder network fehlten. Der PR stellt sicher, dass alle erforderlichen Felder mit sinnvollen Standardwerten zurückgegeben werden, auch wenn die zugrundeliegende Lightning-Implementierung sie nicht bereitstellt, was Zeus’ Kompatibilität im gesamten Ökosystem verbessert.

Verbindungsresilienz - PR #3543 implementiert Timeout-Benachrichtigungen für ins Stocken geratene Nostr-Verbindungen. Zuvor warteten Nutzer unbegrenzt, wenn Relay-Verbindungen stillschweigend abbrachen. Jetzt zeigt Zeus klare Timeout-Nachrichten nach 30 Sekunden Inaktivität an, sodass Nutzer erneut versuchen oder Relays wechseln können. PR #3541 fügt Backend-Validierung hinzu, um NWC-Aktivierung auf inkompatiblen Lightning-Implementierungen zu verhindern und Konfigurationsfehler zu erfassen, bevor sie Laufzeitabstürze verursachen.

Cashu Race Condition - PR #3531 behebt einen Concurrency-Fehler in der Cashu-Token-Verwaltung, bei dem gleichzeitige Mint-Operationen die Token-Datenbank beschädigen konnten. Die Race Condition trat auf, wenn mehrere Threads Token-Zählungen ohne ordnungsgemäße Sperrung aktualisierten, was gelegentlich zu falschen Salden führte. Der Fix fügt Mutex-Schutz um kritische Abschnitte hinzu und stellt atomare Updates des Token-Status sicher.

Primal Android (Client)

Primal Android lieferte 12 zusammengeführte PRs mit bedeutenden Verbesserungen bei Wallet-Sicherheit und Medienbehandlung. Die Wallet-Backup-Implementierung adressiert eine der meist angeforderten Funktionen, während NIP-92-Unterstützung die visuelle Erfahrung in der gesamten Anwendung verbessert.

Wallet-Backup-System - Eine vier-PR-Serie (#844, #845, #846, #848) implementiert umfassende Seed-Phrase-Backup-Funktionalität. Nutzer können jetzt ihr 12-Wort-Mnemonic über einen sicheren Flow exportieren, der Screenshots verhindert, den Backup-Status im Wallet-Dashboard anzeigt und bestehende Nutzer durch die Migration führt. Die Implementierung folgt BIP-39-Standards und beinhaltet Validierung, um zu verhindern, dass Nutzer Gelder durch falsche Phrasenaufzeichnung verlieren.

Mediendimensionen (NIP-92) - PR #718 implementiert NIP-92 Unterstützung für korrekte Bild- und Video-Seitenverhältnisse. Ohne Dimensionsmetadaten müssen Clients Bilder herunterladen, um ihre Größe zu bestimmen, was zu Layout-Sprüngen führt, wenn Inhalte geladen werden. NIP-92 fügt dim-Tags (wie ["dim", "1920x1080"]) zu Datei-Metadaten-Events hinzu, sodass Primal korrekten Platz vor dem Herunterladen von Medien reservieren kann. Dies eliminiert störende Reflows in Bildgalerien und verbessert die wahrgenommene Leistung.

Remote-Signer-Zuverlässigkeit - PR #841 behebt NIP-46 Verbindungsprobleme, bei denen fehlende wss://-Präfixe stille Fehler verursachten. Der PR validiert Relay-URIs während des Bunker-Verbindungsaufbaus und fügt das Protokoll-Präfix automatisch hinzu, wenn Nutzer bloße Domains einfügen. PR #843 behebt einen Threading-Fehler, bei dem schlechte Netzwerkbedingungen dazu führten, dass Antworten als Root-Notes gepostet wurden und den Gesprächsfluss unterbrachen. Der Fix stellt sicher, dass Parent-Event-IDs durch Netzwerkunterbrechungen bestehen bleiben.

Marmot Protocol: White Noise (Verschlüsselte Gruppenchat-Bibliothek)

White Noise, die Rust-Bibliothek, die Marmot Protocols verschlüsselte Gruppenchats antreibt, führte sechs PRs zusammen, die Nutzererfahrung und Sicherheit verbessern. Die Änderungen bringen Marmot näher an Feature-Parität mit Mainstream-Messaging-Anwendungen, während sie ihre Privacy-First-Architektur beibehalten.

Lesebestätigungen - PR #433 und #436 implementieren Nachrichten-Leseverfolgung für Gruppenkonversationen. Das System speichert Lesepositionen pro Nutzer pro Gruppe innerhalb eines einzelnen Geräts und ermöglicht Ungelesen-Zähler-Badges. Die Implementierung verwendet monotone Zeitstempel, um die Position der zuletzt gelesenen Nachricht für jede Konversation zu verfolgen. Diese grundlegende Funktion ermöglicht UI-Indikatoren, die ungelesene Nachrichtenzahlen pro Konversation anzeigen.

Konversations-Pinning - PR #442 fügt persistentes Konversations-Pinning durch ein pin_order-Feld in der accounts_groups-Junction-Tabelle hinzu, die Konten mit Gruppen verknüpft. Gepinnte Konversationen behalten ihre Position oben in Chat-Listen bei, unabhängig von Nachrichtenaktivität, was den Nutzererwartungen von Signal und WhatsApp entspricht. Die Implementierung verwendet Integer-Sortierung, um unbegrenzte Pins mit deterministischer Sortierung zu ermöglichen.

Deterministische Commit-Auflösung (MIP-03) - PR #152 (offen) implementiert Marmot Improvement Proposal 03 und löst das kritische Problem von Commit-Race-Conditions in verteilten Gruppenchats. Wenn mehrere Mitglieder gleichzeitig Gruppenstatusänderungen (Hinzufügen/Entfernen von Mitgliedern, Ändern von Berechtigungen) einreichen, könnten Clients bei der Commit-Reihenfolge divergieren und die Gruppe in inkompatible Zustände fragmentieren. MIP-03 führt Epochen-Snapshots und eine deterministische Gewinner-Auswahl ein: Der Commit mit dem frühesten created_at-Zeitstempel gewinnt, mit lexikografischer Event-ID als Tie-Breaker. Dies ermöglicht es allen Clients, durch Rollback und Replay auf denselben Zustand zu konvergieren und die Gruppenkohärenz auch während Netzwerkpartitionen aufrechtzuerhalten.

Sicherheitshärtung - PR #443 verhindert unnötiges Kopieren kryptografischer Geheimnisse durch die Verwendung von Referenzen in resolve_group_image_path. Dies reduziert das Zeitfenster für Speicherangriffe, bei denen Geheimnisse aus freigegebenen Heap-Allokationen wiederhergestellt werden könnten. PR #438 aktiviert SQLCipher-Datenbankverschlüsselung durch Keyring-Parameter und schützt die Nachrichtenhistorie im Ruhezustand. Die Keyring-Integration ermöglicht sichere Schlüsselspeicherung in Plattform-Keychains anstatt in Konfigurationsdateien.

nostrdb-rs (Datenbankbibliothek) - Offener PR

Streaming-Abfragen-Implementierung - PR #58 (offen) schlägt Streaming-Fold-Abfragen vor, um Null-Allokations-Datenbankoperationen zu ermöglichen. Die Implementierung fügt fold, try_fold, count, any, all und find_map Methoden hinzu, die Datenbankergebnisse einzeln verarbeiten würden, ohne ganze Ergebnismengen in Vektoren zu materialisieren. Dieser Ansatz würde den Speicherverbrauch reduzieren und frühzeitige Beendigung für gängige Abfragemuster ermöglichen.

Die technische Implementierung exponiert Low-Level-Abfrageergebnis-Callbacks (ndb_query_visit) als zustandsbehaftete Rust-Visitors, die ControlFlow-Varianten auf C-Visitor-Aktionen abbilden. Nach der Zusammenführung wird Anwendungscode wie Iterator-Logik lesen, während er nahe an der Datenbankschicht läuft. Zum Beispiel würde das Zählen passender Notizen durch Ergebnisse streamen, anstatt sie zu sammeln, und find_map würde das erste nützliche Ergebnis zurückgeben, ohne verbleibende Zeilen zu verarbeiten.

nostrdb betreibt Damus und Notedeck, beide iOS/macOS bzw. Desktop-Clients. Die Streaming-Abfragen würden effiziente Muster wie Paginierung, bedingte Filterung und Existenzprüfungen ermöglichen. Der PR ändert 3 Dateien mit +756 Hinzufügungen und -32 Löschungen, eine substantielle Umgestaltung der Abfrageschicht. Nutzer von nostrdb-rs-basierten Anwendungen würden reduzierten Speicherverbrauch beim Durchsuchen großer Timelines oder beim Durchsuchen umfangreicher Event-Datenbanken sehen.

nak (CLI-Tool)

nak, fiatjafs Kommandozeilen-Nostr-Tool, führte sechs PRs zusammen, die sich auf Build-System-Verbesserungen und neue Funktionalität konzentrieren. PR #91 implementiert eine Blossom-Mirror-Funktion, die es nak ermöglicht, als Mirror für Blossom-Medienserver zu dienen. Blossom ist ein inhaltsadressiertes Medienspeicherprotokoll, das neben Nostr-Events funktioniert.

Die verbleibenden PRs behandeln Build-System-Kompatibilität über Windows-, macOS- und Linux-Plattformen und ermöglichen FUSE-Dateisystem-Unterstützung für das Mounten von Nostr-Events als lokale Verzeichnisse.

Damus (iOS-Client) - Offene PRs

Damus hat 11 offene PRs, die bedeutende architektonische Verbesserungen erforschen. Obwohl diese noch nicht zusammengeführt wurden, signalisieren sie wichtige Richtungen für die iOS-Nostr-Client-Entwicklung, insbesondere in Bezug auf Privatsphäre, Synchronisationseffizienz und mobile Datenoptimierung.

Tor-Integration - PR #3535 bettet den Arti Tor-Client direkt in Damus ein und ermöglicht anonyme Relay-Verbindungen ohne externe Abhängigkeiten. Im Gegensatz zu Orbot- oder Tor-Browser-Ansätzen bietet das Einbetten von Arti nahtlose Integration mit iOS-Sandboxing und Hintergrundausführungslimits. Die Rust-Implementierung bringt Memory Safety zur Netzwerkanonymisierung und reduziert die Angriffsfläche im Vergleich zu C Tor. Nutzer könnten den Tor-Modus pro-Relay oder global umschalten, wobei der Client das Circuit-Management transparent handhabt.

Negentropy-Sync-Protokoll - PR #3536 implementiert Negentropy, ein Set-Reconciliation-Protokoll, das die Synchronisationseffizienz radikal verbessert. Anstatt alle Events seit der letzten Verbindung herunterzuladen, tauscht Negentropy kompakte Fingerabdrücke (Merkle-Bäume) aus, um genau zu identifizieren, welche Events zwischen Client und Relay unterschiedlich sind. Für Nutzer, die Hunderten von Pubkeys folgen, reduziert dies die Sync-Bandbreite von Megabytes auf Kilobytes. Die Implementierung integriert sich mit RelayPool und SubscriptionManager und ermöglicht automatische effiziente Synchronisation über alle verbundenen Relays.

Low-Data-Modus - PR #3549 fügt Funktionen zur Mobilfunk-Dateneinsparung hinzu, die auf Nutzerfeedback über Bandbreitenverbrauch reagieren. Der Modus deaktiviert automatisches Bildladen, Video-Prefetching und reduziert Abonnement-Limits. Nutzer mit getakteten Verbindungen können Textinhalte durchsuchen, ohne Angst vor Überschreitung von Datenobergrenzen zu haben. Die Implementierung respektiert iOS-Low-Data-Modus-Einstellungen und bietet granulare Kontrollen für verschiedene Medientypen.

Datenbankoptimierungen - PR #3548 überarbeitet nostrdb-Snapshot-Speicherung für schnellere Abfragen und reduzierten Speicherplatzbedarf. Die Optimierung ändert, wie Datenbank-Snapshots auf Disk persistiert werden, und verbessert sowohl die Leseleistung als auch die Schreibverstärkung. Dies behebt Beschwerden über Batterieentleerung von Nutzern mit großen Event-Datenbanken.

Das war’s für diese Woche. Baust du etwas? Hast du Neuigkeiten zu teilen? Möchtest du, dass wir über dein Projekt berichten? Kontaktiere uns über NIP-17 DM oder finde uns auf Nostr.

Nostr Compass #5

Tue, 13 Jan 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Leitfaden für Nostr.

Diese Woche: Bitchat durchläuft ein professionelles Sicherheitsaudit von Cure53, derselben Firma, die Signal und NIP-44 geprüft hat, wobei bereits über 17 PRs mit Fixes für kritische Befunde gemergt wurden. NIP-71 wurde gemergt und bringt adressierbare Video-Events ins Protokoll. Ein Post-Quantum-Kryptographie-NIP eröffnet die Diskussion über die Absicherung von Nostr gegen zukünftige Quantenangriffe. Amethyst v1.05.0 liefert Lesezeichenlisten, Sprachnachrichten und eine frühe Desktop-Version, während Nostur v1.25.3 NIP-17-DMs mit Reaktionen und Antworten verbessert. Bei den Libraries erweitert rust-nostr die NIP-62-Unterstützung auf SQLite- und LMDB-Backends, und NDK behebt einen Bug im Subscription-Tracking.

Neuigkeiten

Bitchat schließt Cure53-Sicherheitsaudit ab

Bitchat, der iOS-verschlüsselte Messenger, der Nostr mit Cashu kombiniert, hat ein professionelles Sicherheitsaudit von Cure53 durchlaufen, einer der angesehensten Sicherheitsfirmen der Branche. Cure53 hat zuvor Signal, Mullvad VPN und insbesondere die NIP-44-Verschlüsselungsspezifikation geprüft, die das Fundament moderner privater Nostr-Nachrichten bildet.

Das Audit fand mehr als 12 Sicherheitsprobleme (BCH-01-002 bis BCH-01-013). Das Bitchat-Team reagierte mit über 17 Pull Requests. Zu den wichtigsten Fixes gehören:

Noise Protocol DH Secret Clearing - PR #928 behebt sechs Stellen, an denen Diffie-Hellman-Shared-Secrets nach dem Key Agreement nicht gelöscht wurden, und stellt damit die Forward-Secrecy-Garantien wieder her. Wenn Secrets länger als nötig im Speicher verbleiben, könnte ein Memory-Dump oder Cold-Boot-Angriff vergangene Kommunikation kompromittieren.

Signaturverifizierung - Mehrere PRs härten die kryptographischen Verifizierungspfade und stellen sicher, dass Nachrichtenauthentizitätsprüfungen nicht durch fehlerhafte Eingaben umgangen werden können.

Thread-Sicherheit - PR #929 fügt Barrier-Synchronisation zu den Lesebestätigungs-Queues in NostrTransport hinzu und verhindert Race Conditions, die bei hohem Nachrichtenaufkommen zu Datenbeschädigung oder Abstürzen führen könnten.

Speichersicherheit - PR #920 optimiert den Nachrichtendeduplikator für bessere Leistung bei hohem Nachrichtendurchsatz und vermeidet gleichzeitig Speichererschöpfung.

Eingabevalidierung - PR #919 härtet das Parsing von Hex-Strings, um Abstürze durch fehlerhafte Eingaben zu verhindern, ein häufiger Angriffsvektor für Denial-of-Service.

Bitchat verarbeitet Cashu-Ecash, weshalb eine professionelle Sicherheitsüberprüfung unerlässlich ist. Das Audit folgt auf das Marmot-Protokoll-Audit vom letzten Jahr und das NIP-44-Audit, das die Verschlüsselungsschicht verifizierte.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

Gemergt:

NIP-71 - Adressierbare Video-Events (#1669) führt kinds 34235 (horizontales Video) und 34236 (vertikales Video) als adressierbare Events ein. Ein erforderlicher d-Tag liefert eindeutige Identifikatoren, sodass Video-Metadaten aktualisiert werden können, ohne das gesamte Event neu zu veröffentlichen. Ein optionaler origin-Tag verfolgt Importquellen. Bereits in Amethyst und nostrvine implementiert.

Offene PRs:

Post-Quantum-Kryptographie - PR #2185 schlägt vor, quantenresistente kryptographische Algorithmen zu Nostr hinzuzufügen. Die Spezifikation führt ML-DSA-44 und Falcon-512 für digitale Signaturen ein und zielt auf „hochwertige Events" wie Anwendungen und Autoritäten ab, nicht auf einzelne Benutzer. Während die symmetrische Verschlüsselung von NIP-44 (ChaCha20) quantenresistent ist, verwendet der Schlüsselaustausch secp256k1 ECDH, das anfällig für Shors Algorithmus ist. Der Vorschlag enthält ML-KEM für Key Agreement, um diese Lücke zu schließen. Dies ist ein Vorschlag im Frühstadium, der die Diskussion über Krypto-Agilität für Nostrs langfristige Sicherheit eröffnet.
BOLT12 für NIP-47 - Nach 137 Kommentaren und ausführlicher Diskussion entschied die Community, dass BOLT12-Offers eine eigene Spezifikation verdienen, anstatt NIP-47 zu erweitern. BOLT12-Offers bieten erhebliche Verbesserungen gegenüber BOLT11-Invoices, darunter Wiederverwendbarkeit, bessere Privatsphäre durch Blinded Paths und optionale Zahlungsinformationen. Das neue NIP wird Methoden wie make_offer, pay_offer und list_offers für Nostr Wallet Connect-Implementierungen definieren.
Audio-Track-NIP - PR #1043 schlägt kinds 32100 für Musiktracks und 32101 für Podcast-Episoden vor und gibt Audioinhalten die gleiche erstklassige Behandlung, die NIP-71 für Video bietet. Derzeit verwenden Audioplattformen wie Wavlake, Zapstr und Stemstr jeweils proprietäre Event-Formate, was das Ökosystem fragmentiert. Ein gemeinsamer Standard würde Interoperabilität ermöglichen, sodass Benutzer Audio von jedem kompatiblen Client entdecken und abspielen können.
NIP-A3 Universal Payment Targets - PR #2119 schlägt kind 10133 Events vor, die RFC-8905 payto:-URIs verwenden, um Zahlungsoptionen über mehrere Netzwerke hinweg bereitzustellen. Anstatt separate Event-Kinds für Bitcoin, Lightning, Cashu oder traditionelle Zahlungswege zu erstellen, ermöglicht diese Abstraktion Clients, standardisierte Tags zu parsen und native Zahlungs-Handler aufzurufen. Der Ansatz ist zukunftssicher, da neue Zahlungsmethoden nur ein payto:-URI-Schema benötigen.

NIP-Vertiefung: NIP-51 und NIP-65

Diese Woche behandeln wir zwei NIPs, die Benutzereinstellungen speichern: NIP-51 zum Organisieren von Inhalten und NIP-65 zum Organisieren von Relay-Verbindungen. Beide verwenden ersetzbare Events, was bedeutet, dass jede neue Veröffentlichung die vorherige Version überschreibt.

NIP-51: Listen

NIP-51 definiert mehrere Listentypen zum Organisieren von Referenzen auf Events, Benutzer, Hashtags und andere Inhalte. Amethyst v1.05.0 fügt Lesezeichen-Unterstützung hinzu, was dies zu einem guten Zeitpunkt macht, um zu verstehen, wie Listen funktionieren.

Die Spezifikation definiert mehrere List-Kinds, die jeweils einem anderen Zweck dienen. Kind 10000 ist deine Stummschaltungsliste zum Ausblenden von Benutzern, Threads oder Wörtern. Kind 10001 pinnt Events, um sie auf deinem Profil hervorzuheben. Kind 30003 speichert Lesezeichen, was Amethyst jetzt unterstützt. Andere Kinds verwalten Follow-Sets (30000), kuratierte Artikelsammlungen (30004), Hashtag-Interessen (30015) und benutzerdefinierte Emoji-Sets (30030).

Listen referenzieren Inhalte über Tags. Eine Lesezeichenliste verwendet e-Tags für spezifische Events und a-Tags für adressierbaren Inhalt wie Artikel:

{
 "id": "ae3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 30003,
 "tags": [
 ["d", "saved-articles"],
 ["e", "abc123def456...", "wss://relay.example"],
 ["a", "30023:author-pubkey:article-id", "wss://relay.example"]
 ],
 "content": "<encrypted-private-bookmarks>",
 "sig": "908a15e46fb4d8675bab026fc230a0e3542bfade63da02d542fb78b2a8513fcd0092619a2c8c1221e581946e0191f2af505dfdf8657a414dbca329186f009262"
}

Der d-Tag liefert einen eindeutigen Identifikator, sodass du mehrere Lesezeichen-Sets wie „saved-articles", „read-later" oder „favorites" unter demselben Kind pflegen kannst.

Listen unterstützen sowohl öffentliche als auch private Einträge. Öffentliche Einträge erscheinen im Tags-Array und sind für jeden sichtbar, der das Event abruft. Private Einträge kommen in das content-Feld und werden mit NIP-44 an dich selbst verschlüsselt. Diese duale Struktur ermöglicht es dir, öffentliche Lesezeichen zu führen und gleichzeitig private Notizen anzuhängen, oder eine Stummschaltungsliste zu pflegen, ohne preiszugeben, wen du stummgeschaltet hast. Um an dich selbst zu verschlüsseln, verwende NIP-44 mit deinem eigenen pubkey als Empfänger.

Die 10000er-Serie-Kinds sind ersetzbar, was bedeutet, dass Relays nur ein Event pro pubkey behalten. Die 30000er-Serie sind parametrisiert ersetzbar und erlauben ein Event pro pubkey- und d-Tag-Kombination. In beiden Fällen bedeutet das Aktualisieren einer Liste das Veröffentlichen eines vollständigen Ersatzes; du kannst keine inkrementellen Änderungen senden. Clients sollten unbekannte Tags beim Ändern von Listen beibehalten, um das Überschreiben von Daten zu vermeiden, die von anderen Anwendungen hinzugefügt wurden.

NIP-65: Relay-Listen-Metadaten

NIP-65 definiert kind 10002 Events, die bekannt geben, welche Relays ein Benutzer zum Lesen und Schreiben bevorzugt. Dies hilft anderen Benutzern und Clients, deine Inhalte zu finden.

{
 "id": "bd2217a96b5835b59f9a6a42d8d8a36f8c9b7d4e5f0a1b2c3d4e5f6a7b8c9d0e1",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 10002,
 "tags": [
 ["r", "wss://relay.damus.io", "read"],
 ["r", "wss://nos.lol"],
 ["r", "wss://relay.nostr.band", "write"]
 ],
 "content": "",
 "sig": "f1c2d3e4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2"
}

Jeder r-Tag enthält eine Relay-URL und einen optionalen Marker. Ein write-Marker bezeichnet deine Outbox: Relays, auf denen du deine Inhalte veröffentlichst. Ein read-Marker bezeichnet deine Inbox: Relays, auf denen du nach Erwähnungen, Antworten und Tags schaust. Das Weglassen des Markers zeigt beides an.

Wenn Alice Bobs Beiträge finden will, ruft ihr Client Bobs kind 10002 ab, extrahiert seine Write-Relays (seine Outbox) und abonniert dort. Wenn Alice auf Bob antwortet, veröffentlicht ihr Client auf seinen Read-Relays (seiner Inbox), damit er die Erwähnung sieht. Dieses relay-bewusste Routing ist das „Outbox-Modell", und es verteilt Benutzer auf viele Relays, anstatt alle auf wenigen zentralen Servern zu konzentrieren.

NIP-65 behandelt das Routing öffentlicher Inhalte, aber private Nachrichten verwenden eine separate Liste. NIP-17 definiert kind 10050 für DM-Inbox-Relays und verwendet relay-Tags anstelle von r-Tags. Beim Senden einer privaten Nachricht suchen Clients nach dem kind 10050 Event des Empfängers und veröffentlichen dort die verschlüsselte Gift-Wrapped-Nachricht. Diese Trennung hält das DM-Routing vom Routing öffentlicher Inhalte getrennt und ermöglicht es Benutzern, verschiedene Relays für private und öffentliche Kommunikation anzugeben.

Das Outbox-Modell verbessert die Zensurresistenz, da kein einzelnes Relay die Inhalte aller speichern oder bereitstellen muss. Clients halten Verbindungen zu Relays aufrecht, die in den NIP-65-Events ihrer gefolgten Benutzer aufgelistet sind, und verbinden sich dynamisch mit neuen Relays, wenn sie neue Konten entdecken. NIP-65 ergänzt die Relay-Hints, die in anderen NIPs zu finden sind. Wenn du jemanden mit ["p", "pubkey", "wss://hint.relay"] taggst, teilt der Hint Clients mit, wo sie nach dieser spezifischen Referenz suchen sollen. NIP-65 liefert die autoritative, vom Benutzer kontrollierte Liste, während Hints Abkürzungen bieten, die in einzelne Events eingebettet sind.

Für beste Ergebnisse halte deine Relay-Liste aktuell, da veraltete Einträge dich schwerer auffindbar machen. Die Spezifikation empfiehlt zwei bis vier Relays pro Kategorie. Das Auflisten zu vieler Relays belastet jeden Client, der deine Inhalte abrufen möchte, verlangsamt deren Erfahrung und erhöht die Netzwerklast. Clients cachen NIP-65-Events und aktualisieren sie regelmäßig, um auf dem neuesten Stand zu bleiben, wenn Benutzer ihre Einstellungen ändern.

Releases

Amethyst v1.05.0 - Der beliebte Android-Client liefert ein großes Update mit mehreren Hauptfunktionen. NIP-51 kind 30003 Lesezeichenlisten ermöglichen es Benutzern, Beiträge zur späteren Referenz zu speichern und über kompatible Clients hinweg zu synchronisieren. Sprachnachrichten funktionieren jetzt in DMs und normalen Beiträgen mit Wellenformvisualisierung, Medienserver-Auswahl und Upload-Fortschrittsanzeigen. Web of Trust-Scores sind jetzt in der Oberfläche sichtbar und helfen Benutzern zu verstehen, wie der Algorithmus Konten relativ zu ihrem sozialen Graphen bewertet. Die Quartz-Datenbankmigration verbessert die Abfrageleistung als Teil der von OpenSats finanzierten Kotlin-Multiplatform-Arbeit. Ein frühes Desktop-Release bringt Amethyst über Compose Multiplatform auf Windows, macOS und Linux und teilt dieselbe Codebasis wie die Android-App. Neue Benutzer-Onboarding-Flows erleichtern die Erfahrung für erstmalige Nostr-Benutzer.

Nostur v1.25.3 - Der iOS- und macOS-Client konzentriert sich auf private Nachrichten mit NIP-17-Verbesserungen. DM-Konversationen unterstützen jetzt Reaktionen und Antworten und bringen die Interaktivität öffentlicher Beiträge in verschlüsselte Nachrichten. Die Konversationsansicht wurde mit besserem Threading überarbeitet, sodass Mehrfachnachrichtenaustausche leichter zu verfolgen sind, und Zeitstempel zeigen „Zeit her" in der DM-Liste für schnelles Scannen. Desktop-Benutzer erhalten Multi-Spalten-Layouts zum gleichzeitigen Anzeigen mehrerer Feeds oder Konversationen. NIP-46 Remote-Signer-Unterstützung ermöglicht es Benutzern, ihre privaten Schlüssel in dedizierten Signer-Apps wie Amber oder nsec.app aufzubewahren. Zusätzliche Fixes stellen die DM-Funktionalität auf iOS 15 und iOS 16 wieder her, beheben Benachrichtigungsverzögerungen und fügen die Möglichkeit hinzu, zu konfigurieren, welche Relays veröffentlichte DMs erhalten.

Bemerkenswerte Code- und Dokumentationsänderungen

Dies sind offene Pull Requests und Arbeiten im Frühstadium, perfekt um Feedback zu erhalten, bevor sie gemergt werden. Wenn dich etwas interessiert, erwäge einen Review oder Kommentar!

Citrine (Android Relay)

PR #89 behebt eine SQL-Injection-Schwachstelle in der persönlichen Android-Relay-App. Das Problem ermöglichte es fehlerhaften Event-Daten, beliebige Datenbankabfragen auszuführen, ein ernstes Problem für jede App, die nicht vertrauenswürdige Eingaben speichert und verarbeitet. Der Fix bereinigt alle Datenbankoperationen ordnungsgemäß mit parametrisierten Abfragen. Es wurde noch kein Release getaggt, sodass Benutzer auf die nächste Version warten oder aus dem Quellcode bauen müssen. PR #90 optimiert die ContentProvider-Abfrageleistung mit Filterung und Paginierung auf Datenbankebene und reduziert die Latenz, wenn externe Apps wie Amethyst über Androids Inter-Process-Communication-Layer auf Citrines Event-Datenbank zugreifen.

rust-nostr (Library)

Die NIP-62 (Vanish Requests) Unterstützung wird über die Datenbank-Backends von rust-nostr hinweg erweitert. PR #1180, vor zwei Wochen gemergt, fügte NIP-62-Unterstützung zu SQLite hinzu und behandelt ALL_RELAYS Vanish Requests, da die Datenbankschicht keine spezifischen Relay-URLs kennt. PR #1210 erweitert dies auf das LMDB-Backend und stellt sicher, dass Vanish Requests auf der Festplatte persistiert werden und Relay-Neustarts überleben. Eine IndexedDB-Implementierung für Browser-Umgebungen ist ebenfalls in Arbeit. Zusammen geben diese Änderungen Entwicklern konsistente NIP-62-Unterstützung über SQLite, LMDB und bald Browser-Storage hinweg.

NDK (Nostr Development Kit)

PR #375 behebt einen Bug im seenEvents-Tracking-System. Das Problem führte dazu, dass bestimmte Subscription-Muster Events fälschlicherweise als bereits gesehen markierten, was zu verpassten Inhalten führte, wenn Benutzer neue Subscriptions öffneten oder sich wieder mit Relays verbanden. Der Fix stellt sicher, dass Events über Subscription-Lebenszyklen hinweg korrekt verfolgt werden, was besonders wichtig für Anwendungen ist, die basierend auf Benutzernavigation dynamisch subscriben und unsubscriben. NDK wurde auf beta.70 aktualisiert mit diesem Fix.

Damus (iOS)

PR #3515 behebt einen Startabsturz, der iOS 17-Benutzer betraf. Das Problem stammte von einem arithmetischen Überlauf in NdbUseLock, einer Fallback-Klasse, die verwendet wird, weil Swift Mutexes auf iOS 17 nicht verfügbar sind. Der Fix ersetzt den vorherigen Synchronisationsansatz durch NSLock, das auf iOS 17 verfügbar ist und die verbleibenden Race Conditions ordnungsgemäß behandelt. iOS 18+-Benutzer waren nicht betroffen, da sie Zugang zur nativen Swift Mutex-Implementierung haben.

Separat landete eine Reihe von Longform-Artikel-Verbesserungen über PR #3509. Lesefortschrittsbalken verfolgen deine Position durch Artikel, geschätzte Lesezeiten erscheinen auf Vorschauen, und Sepia-Modus mit einstellbaren Zeilenhöheneinstellungen bieten komfortableres Lesen. Der Fokusmodus blendet die Navigations-Chrome beim Scrollen automatisch aus und stellt sie bei Tippen wieder her, was visuelle Ablenkungen für ablenkungsfreies Lesen reduziert. Mehrere Fixes beheben die Bildanzeige in Markdown-Inhalten und stellen sicher, dass Artikel oben statt mittendrin geöffnet werden.

Zap.stream (Live-Streaming)

YouTube- und Kick-Chat-Integration verbindet Nachrichten von externen Streaming-Plattformen mit Nostr. Streamer, die zu YouTube, Kick und Zap.stream multicasten, können jetzt alle Chat-Nachrichten in einer einheitlichen Ansicht sehen, wobei Nachrichten von jeder Plattform neben nativen Nostr-Kommentaren erscheinen. Dies beseitigt einen großen Reibungspunkt für Creator, die Nostr zum Streamen nutzen möchten, aber Audiences auf etablierten Plattformen nicht aufgeben können. Die Integration zeigt an, von welcher Plattform jede Nachricht stammt, und übernimmt den Authentifizierungsflow zum Verbinden externer Konten.

Chachi (NIP-29 Groups)

Der NIP-29 Gruppen-Chat-Client lieferte diese Woche sechs gemergte PRs. Ein Sicherheitsupdate adressiert CVE-2026-22029, eine XSS-Schwachstelle in react-router, die Open-Redirect-Angriffe ermöglichen könnte; der Fix aktualisiert auf react-router-dom 6.30.0. PR #92 fügt paginiertes Nachrichten-Laden für Gruppenchats hinzu, sodass lange Konversationen inkrementell statt auf einmal geladen werden. PR #91 behebt mehrere NIP-29-Bugs, darunter eine Race Condition, die beim ersten Laden zu leeren Gruppennamen führte, und undefinierte Teilnehmerlisten, die Mitgliederansichten zum Absturz brachten. Die Übersetzungsabdeckung umfasst jetzt alle 31 unterstützten Sprachen mit je 1060 Schlüsseln.

0xchat (Messaging)

Der Messaging-Client im Telegram-Stil verbesserte die NIP-55-Compliance, indem Signer-Paketnamen bei Verwendung externer Signatur-Apps ordnungsgemäß gespeichert werden, was Probleme behebt, bei denen die App nach Neustarts den Überblick verlor, welcher Signer verwendet werden sollte. Die NIP-17-Antwortbehandlung enthält jetzt korrekt den e-Tag für Threading und stellt sicher, dass Antworten über Clients hinweg im richtigen Konversationskontext erscheinen. Leistungsoptimierungen beheben Scroll-Lag in Nachrichtenlisten, ein häufiger Schmerzpunkt beim Laden langer Chat-Verläufe. Entwürfe werden automatisch gespeichert, um Nachrichtenverlust zu verhindern, wenn du mitten in der Komposition wegnavigierst, und Dateispeicheroptionen enthalten jetzt Standard-FileDropServer- und BlossomServer-Endpoints.

Primal (iOS)

NIP-46 Remote-Signer-Unterstützung landet auf iOS über PR #184 und vervollständigt den plattformübergreifenden Rollout, der vor einigen Wochen mit Android begann. Benutzer können jetzt ihre privaten Schlüssel in dedizierten Bunker-Diensten wie nsec.app oder selbst gehosteten nsecBunker-Instanzen aufbewahren und sich über Nostr-Relays verbinden, um Events zu signieren, ohne Schlüssel der Client-App auszusetzen. Diese Trennung verbessert die Sicherheitslage für Benutzer, die Primals Funktionen nutzen möchten, während sie strengere Schlüsselverwaltungspraktiken beibehalten. Die Implementierung enthält QR-Code-Scanning für Bunker-Verbindungs-URIs und übernimmt den NIP-46-Request/Response-Flow über verschlüsselte Relay-Nachrichten.

Das war’s für diese Woche. Baust du etwas? Hast du Neuigkeiten zu teilen? Möchtest du, dass wir über dein Projekt berichten? Melde dich per NIP-17 DM oder finde uns auf Nostr.

Nostr Compass #4

Wed, 07 Jan 2026 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch das Nostr-Protokoll-Ökosystem.

Diese Woche: Primal Android liefert NIP-46 Remote Signing und NIP-55 lokale Signer-Unterstützung aus und wird damit zu einem vollwertigen Signing-Hub für andere Android-Apps. Das Marmot Protocol-Team hat Ergebnisse eines Sicherheitsaudits mit 18 zusammengeführten PRs zur Härtung von MLS-basierter verschlüsselter Kommunikation bearbeitet. Citrine erreicht v1.0 und Applesauce veröffentlicht v5.0 für seine gesamte Bibliothekssuite. TENEX baut KI-Agenten-Überwachung auf Nostr aus, und Jumble fügt intelligentes Relay-Pooling hinzu. Eine NIP-55-Spezifikationskorrektur klärt die nip44_encrypt-Rückgabefelder, und ein NIP-50-PR schlägt Query-Expression-Erweiterungen für erweiterte Suche vor. In unserem Deep Dive erklären wir NIP-04 und NIP-44: warum die Legacy-Verschlüsselung Sicherheitsmängel hat und wie der moderne Ersatz diese behebt.

Neuigkeiten

Primal Android wird zum vollständigen Signing-Hub - Version 2.6.18 fügt sowohl NIP-46 Remote Signing als auch NIP-55 lokales Signing hinzu und macht Primal damit zu einem vollständigen Signer für andere Nostr-Apps. Remote Signing über NIP-46 ermöglicht Nutzern die Verbindung zu Bunker-Diensten über Nostr-Relays, wobei die Schlüssel komplett vom Gerät ferngehalten werden. Lokales Signing über NIP-55 macht Primal als Android Content Provider verfügbar, sodass Apps wie Amethyst oder Citrine Signaturen anfordern können, ohne jemals den privaten Schlüssel zu berühren. Mehrere Folge-PRs beheben Kompatibilitätsprobleme mit der NIP-55-Spezifikationsanforderung für Hex-Pubkeys und verbessern das Parsen fehlerhafter nostrconnect://-URIs. Das Release beinhaltet außerdem Media-Pre-Caching für flüssigeres Scrollen, verbesserte Thread-Ladezeiten und Avatar-Pre-Caching.

Marmot Protocol härtet Sicherheit nach Audit - Das Marmot Development Kit (mdk), das NIP-104 MLS-basierte Ende-zu-Ende-verschlüsselte Kommunikation implementiert, erhielt diese Woche umfangreiche Sicherheitskorrekturen. Achtzehn zusammengeführte Pull Requests behoben Audit-Ergebnisse, darunter: Hash-Verifizierung für verschlüsselte Gruppenbilder zur Verhinderung von Blob-Substitutionsangriffen auf Speicherebene, Paginierung für ausstehende Willkommensnachrichten zur Verhinderung von Speichererschöpfung, MLS Group ID-Lecks in Fehlermeldungen, und Base64-Encoding-Durchsetzung für Key Packages. Die Marmot-Spezifikation selbst wurde aktualisiert mit MIP-04 v2-Versionierung und Sicherheitsverbesserungen. Aktive PRs bearbeiten weiterhin Nonce-Wiederverwendung, Secret-Zeroization und Cache-Pollution-Vektoren.

Nostrability verfolgt Relay-Hint-Unterstützung - Ein neuer Relay-Hints-Kompatibilitätstracker dokumentiert, wie Clients Relay-Hints im gesamten Ökosystem konstruieren und konsumieren. Der Tracker zeigt, dass die meisten Clients mittlerweile Hints gemäß NIP-10 und NIP-19 konstruieren, der Konsum jedoch stark variiert: einige Clients fügen Hints in ausgehende Events ein, nutzen aber eingehende Hints nicht zum Abrufen. Sechs Clients erhielten den “Full”-Tier-Status für vollständige Implementierung. Der Tracker ist nützlich für Entwickler, die Interoperabilität prüfen, und für Nutzer, die sich fragen, warum manche Clients Inhalte finden, die andere nicht finden können.

Nostria 2.0 liefert plattformübergreifende Feature-Überarbeitung - Der Nostria-Client veröffentlichte Version 2.0 am 30. Dezember mit signifikanten Erweiterungen für iOS (TestFlight), Android (Play Store), Web und Windows. Das Release fügt native Musikunterstützung mit Playlist-Erstellung, Track-Upload, Zap-basierten Künstlerzahlungen und einem WinAmp-ähnlichen Player mit funktionalem Equalizer hinzu. Live-Streaming erhält Game-API-Integration, die während Gameplay-Streams reichhaltige Metadaten anzeigt. Eine neue Zusammenfassungsfunktion generiert stündliche, tägliche oder wöchentliche Aktivitätsdigests als komprimierte Timeline-Ansichten. Der Discover-Bereich bietet kuratierte Listen zum Finden von Inhalten und Profilen. Medienveröffentlichung wird mit automatischer Kurzform-Post-Generierung für Cross-Client-Auffindbarkeit vereinfacht. Remote-Signer-Verbindungen funktionieren jetzt per QR-Code-Scan ohne manuelle Konfiguration. Die Profilerkennung adressiert ein häufiges Nostr-Problem: Wenn Nutzer zwischen Relays wechseln, ohne ihre Metadaten mitzunehmen, findet Nostria ihr Profil und veröffentlicht es erneut auf ihren aktuellen Relays. Premium-Abonnenten erhalten YouTube-Kanal-Integration, private Memos, Analyse-Dashboards und automatische Following-Listen-Backups mit Merge/Restore-Optionen.

NIP-Updates

Aktuelle Änderungen im NIPs-Repository:

Zusammengeführt:

NIP-55 - Das Rückgabefeld für die nip44_encrypt-Methode wurde korrigiert (#2184). Android-Signer müssen den verschlüsselten Payload jetzt im signature-Feld zurückgeben (passend zu nip44_decrypt) statt in einem separaten Feld. Dies bringt die Spezifikation mit bestehenden Implementierungen in Amber und Primal in Einklang.

Offene PRs:

NIP-50 - Query Expression Extensions (#2182) schlägt vor, NIP-50-Suche mit strukturierten Query-Ausdrücken zu erweitern. Der PR fügt Operatoren wie kind:1, author:npub1... und boolesche Kombinationen (AND, OR, NOT) hinzu, die präzisere Suchabfragen jenseits einfacher Textsuche ermöglichen. Dies würde Clients erlauben, erweiterte Suchoberflächen zu erstellen und dabei Rückwärtskompatibilität mit einfachen Suchstrings zu wahren.

NIP Deep Dive: NIP-04 und NIP-44

Diese Woche behandeln wir Nostrs Verschlüsselungsstandards: das Legacy-NIP-04, dem du noch begegnen wirst, und seinen modernen Ersatz NIP-44, der kritische Sicherheitsmängel behebt.

NIP-04: Verschlüsselte Direktnachrichten (Legacy)

NIP-04 war Nostrs erster Versuch für verschlüsselte Kommunikation unter Verwendung von kind 4 Events. Obwohl einfach zu implementieren, hat es bekannte Sicherheitsschwächen und wurde zugunsten von NIP-44 als veraltet erklärt.

Wie es funktioniert: NIP-04 verwendet ECDH (Elliptic Curve Diffie-Hellman), um ein gemeinsames Geheimnis zwischen Sender und Empfänger abzuleiten, und verschlüsselt dann mit AES-256-CBC.

{
 "id": "<event-id>",
 "pubkey": "<sender-pubkey>",
 "created_at": 1736200000,
 "kind": 4,
 "tags": [["p", "<recipient-pubkey>"]],
 "content": "base64-ciphertext?iv=base64-iv",
 "sig": "<signature>"
}

Der Verschlüsselungsablauf:

Gemeinsamen Punkt berechnen: shared = ECDH(sender_privkey, recipient_pubkey)
Schlüssel ableiten: key = SHA256(shared_x_coordinate)
Zufälligen 16-Byte IV generieren
Verschlüsseln: ciphertext = AES-256-CBC(key, iv, plaintext)
Inhalt formatieren: base64(ciphertext)?iv=base64(iv)

Sicherheitsprobleme:

Keine Authentifizierung: AES-CBC bietet Vertraulichkeit, aber keine Integrität. Ein Angreifer, der ein Relay kontrolliert, könnte Ciphertext-Bits modifizieren und vorhersagbare Änderungen am Klartext verursachen (Bit-Flipping-Angriffe).
IV im Klartext: Der Initialisierungsvektor wird zusammen mit dem Ciphertext übertragen, und CBC-Modus mit vorhersagbaren IVs ermöglicht Chosen-Plaintext-Angriffe.
Keine Padding-Validierung: Implementierungen unterscheiden sich darin, wie sie PKCS#7-Padding handhaben, was Padding-Oracle-Angriffe ermöglichen kann.
Metadaten-Exposition: Der Sender-Pubkey, Empfänger-Pubkey und Zeitstempel sind alle für Relays sichtbar.
Schlüsselwiederverwendung: Das gleiche gemeinsame Geheimnis wird für alle Nachrichten zwischen zwei Parteien verwendet, für immer.

Warum es noch existiert: Viele ältere Clients und Relays unterstützen nur NIP-04. Du wirst ihm begegnen, wenn du mit Legacy-Systemen interagierst. Signer wie Amber und Apps wie Primal implementieren weiterhin nip04_encrypt/nip04_decrypt für Rückwärtskompatibilität.

NIP-44: Versionierte Verschlüsselung

NIP-44 ist der moderne Verschlüsselungsstandard, der entwickelt wurde, um NIP-04s bekannte Mängel zu beheben. Ein Cure53-Sicherheitsaudit von NIP-44-Implementierungen identifizierte 10 Probleme (einschließlich Timing-Angriffe und Forward-Secrecy-Bedenken), die vor Finalisierung der Spezifikation behoben wurden. Es verwendet ChaCha20-Poly1305 mit korrekter Schlüsselableitung und authentifizierter Verschlüsselung.

Wesentliche Verbesserungen gegenüber NIP-04:

Aspekt	NIP-04	NIP-44
Cipher	AES-256-CBC	XChaCha20-Poly1305
Authentifizierung	Keine	Poly1305 MAC
Schlüsselableitung	SHA256(shared_x)	HKDF mit Salt
Nonce	16-Byte IV, Muster-Wiederverwendung	24-Byte zufällige Nonce
Padding	PKCS#7 (Länge sichtbar)	Auf Zweierpotenz gepaddet
Versionierung	Keine	Versions-Byte-Prefix

Verschlüsselungsablauf:

Conversation Key: Einen stabilen Schlüssel für jedes Sender-Empfänger-Paar ableiten:

shared_x = ECDH(sender_privkey, recipient_pubkey).x
conversation_key = HKDF-SHA256(
 ikm = shared_x,
 salt = "nip44-v2",
 info = ""
)

Message Keys: Für jede Nachricht eine zufällige 32-Byte-Nonce generieren und Verschlüsselungs-/Authentifizierungsschlüssel ableiten:

keys = HKDF-SHA256(
 ikm = conversation_key,
 salt = nonce,
 info = "nip44-v2"
)
chacha_key = keys[0:32]
chacha_nonce = keys[32:44]
hmac_key = keys[44:76]

Klartext padden: Auf die nächste Zweierpotenz auffüllen (Minimum 32 Bytes), um die Nachrichtenlänge zu verbergen:
```
padded = [length_u16_be] + [plaintext] + [zeros to next power of 2]
```

Verschlüsseln und authentifizieren:

ciphertext = XChaCha20(chacha_key, chacha_nonce, padded)
mac = HMAC-SHA256(hmac_key, nonce + ciphertext)

Payload formatieren:

payload = [version=0x02] + [nonce] + [ciphertext] + [mac]
content = base64(payload)

Versions-Byte: Das erste Byte (0x02) zeigt die Verschlüsselungsversion an. Dies ermöglicht zukünftige Upgrades ohne Beschädigung bestehender Nachrichten. Version 0x01 war ein früherer Entwurf, der nie breit eingesetzt wurde.

Entschlüsselung:

Base64 dekodieren, Versions-Byte auf 0x02 prüfen
Nonce (Bytes 1-32), Ciphertext und MAC (letzte 32 Bytes) extrahieren
Conversation Key mit dem privaten Schlüssel des Empfängers und dem öffentlichen Schlüssel des Senders ableiten
Message Keys aus Conversation Key und Nonce ableiten
MAC vor der Entschlüsselung verifizieren (bei Ungültigkeiten ablehnen)
Ciphertext entschlüsseln, Längen-Prefix extrahieren, ungepaddet Klartext zurückgeben

Sicherheitseigenschaften:

Authentifizierte Verschlüsselung: Poly1305 MAC stellt sicher, dass jede Manipulation vor der Entschlüsselung erkannt wird
Forward Secrecy (partiell): Jede Nachricht verwendet eine einzigartige Nonce, sodass die Kompromittierung einer Nachricht keine anderen preisgibt. Allerdings offenbart die Kompromittierung eines privaten Schlüssels weiterhin alle vergangenen Nachrichten (kein Ratcheting).
Längenverbergung: Zweierpotenz-Padding verschleiert die exakte Nachrichtenlänge
Timing-Angriff-Resistenz: Konstantzeit-Vergleich für MAC-Verifizierung

Verwendung in der Praxis: NIP-44 ist die Verschlüsselungsschicht für:

NIP-17 private Direktnachrichten (innerhalb von Gift Wrap)
NIP-46 Remote-Signer-Kommunikation
NIP-59 Seal-Verschlüsselung
Marmot Protocol Gruppennachrichten, wobei NIP-44 MLS-verschlüsselte Inhalte mit einem vom MLS-Exporter-Secret abgeleiteten Schlüssel umhüllt
Jede Anwendung, die sichere Punkt-zu-Punkt-Verschlüsselung benötigt

Migrationsempfehlung: Neue Anwendungen sollten ausschließlich NIP-44 verwenden. Für Rückwärtskompatibilität prüfe, ob der Client eines Kontakts NIP-44 unterstützt (über NIP-89 App-Metadaten oder Relay-Unterstützung), bevor auf NIP-04 zurückgefallen wird. Beim Empfangen von Nachrichten versuche zuerst NIP-44-Entschlüsselung, dann falle auf NIP-04 für Legacy-Inhalte zurück.

Releases

Primal Android v2.6.18 - Das vollständige Release fügt NIP-46 Remote Signing und NIP-55 lokales Signing hinzu und macht Primal damit zu einem Signing-Hub für andere Android-Apps. Leistungsverbesserungen umfassen Media-Pre-Caching, Avatar-Pre-Caching und schnelleres Thread-Laden. Bugfixes beheben Selbst-Erwähnungen in Bios, Media-Galerie-Abstürze und Stream-Titel-Fallbacks. Unter iOS verwendet Primal Hintergrund-Audiowiedergabe, um die App für den Empfang von NIP-46-Signaturanfragen aktiv zu halten; Nutzer können den Sound in den Einstellungen ändern oder komplett stummschalten.

Mostro v0.15.6 - Das neueste Release der NIP-69 P2P-Bitcoin-Trading-Plattform vervollständigt die Entwicklungsfonds-Implementierung mit Phase 4 Audit-Events. Dev-Fee-Zahlungen werden jetzt über kind 38383 Nostr-Events verfolgt, die nach jeder erfolgreichen Zahlung veröffentlicht werden, was Drittpartei-Verifizierung und Analysen ermöglicht. Betragsberechnungen wurden für Käufer/Verkäufer-Nachrichten korrigiert, und die Premium-Logik wurde mit der lnp2pbot-Referenzimplementierung abgeglichen.

Aegis v0.3.5 - Der plattformübergreifende Signer fügt Dark Mode hinzu, verbesserte App-Icon-Anzeige und sauberere UI-Layouts. Bugfixes beheben iOS iCloud Private Relay-Konflikte und Event-Parsing-Probleme. Das Release verbessert auch, wie Event-JSON an die Rust-Signing-Funktion übergeben wird.

Citrine v1.0.0 - Die Android-Relay-App erreicht 1.0. Citrine ermöglicht den Betrieb eines persönlichen Nostr-Relays direkt auf deinem Android-Gerät, nützlich für lokales Caching, Backup oder als NIP-55-Begleiter. Dieses Release fügt einen Crash-Report-Handler hinzu, verbessert die Effizienz von Datenbankabfragen und aktualisiert Übersetzungen via Crowdin.

Applesauce v5.0.0 - hzrd149s TypeScript-Bibliothekssuite liefert eine Major-Version mit Breaking Changes, die auf Korrektheit und Einfachheit fokussiert sind. Das Core-Paket verifiziert jetzt Event-Signaturen standardmäßig und benennt Koordinaten-Methoden um, um klarere “Address”-Terminologie zu verwenden (parseCoordinate -> parseReplaceableAddress). Das Relay-Paket senkt Standard-Retries von 10 auf 3 und ignoriert standardmäßig nicht erreichbare Relays, plus fügt createUnifiedEventLoader für einfacheres Event-Fetching hinzu. Das Wallet-Paket erhält NIP-87 Cashu Mint Discovery. Direkte nostr-tools-Abhängigkeiten wurden paketübergreifend entfernt, was Bundle-Größe und Versionskonflikte reduziert.

Bemerkenswerte Code- und Dokumentationsänderungen

Dies sind offene Pull Requests und Arbeiten im Frühstadium, perfekt um Feedback zu erhalten, bevor sie zusammengeführt werden. Wenn dir etwas ins Auge fällt, erwäge einen Review oder Kommentar!

Damus (iOS)

Eine Serie von PRs verbessert das Langform-Artikel-Erlebnis. Lese-UX-Verbesserungen fügen einen Fortschrittsbalken, geschätzte Lesezeit, Sepia-Modus, einstellbare Zeilenhöhe und Fokus-Modus hinzu, der die Navigation beim Scrollen versteckt. Bild-Korrekturen stellen sicher, dass Bilder in Markdown-Inhalten mit korrekten Seitenverhältnissen angezeigt werden, indem einzelne Bilder als Block-Level-Elemente vorverarbeitet werden. Langform-Vorschaukarten ersetzen Inline-@naddr1...-Text durch reichhaltige Vorschaukarten, die Artikeltitel und Metadaten zeigen. Eine neue Relay-Integrationstestsuite fügt 137 netzwerkbezogene Tests hinzu, einschließlich NIP-01-Protokollverifizierung und Verhalten unter verschlechterten Netzwerkbedingungen (3G-Simulation).

Bitchat (Verschlüsselte Kommunikation)

Sicherheitshärtung im iOS Nostr+Cashu-Messenger. Noise Protocol DH Secret Clearing behebt sechs Stellen, an denen gemeinsame Geheimnisse nach Diffie-Hellman Key Agreement nicht gelöscht wurden, und stellt Forward-Secrecy-Garantien wieder her. Thread-Sicherheit für Lesebestätigungs-Queues fügt Barrier-Synchronisation hinzu, um Race Conditions in NostrTransport zu verhindern. Nachrichten-Deduplikator-Optimierung verbessert die Leistung bei hohem Nachrichtenvolumen, und Hex-String-Parsing-Härtung verhindert Abstürze durch fehlerhafte Eingaben.

Frostr (Threshold Signing)

Das FROST-basierte Threshold-Signing-Protokoll fügt QR-Code-Anzeige hinzu für Gruppen-Anmeldedaten und Share-Anmeldedaten während des Onboardings und in der Signer-Oberfläche. Dies ermöglicht eine einfachere Einrichtung beim Verteilen von Schlüsselanteilen über mehrere Geräte, da Nutzer Anmeldedaten scannen können, anstatt lange Zeichenketten manuell zu kopieren.

Marmot mdk (Bibliothek)

Über die oben erwähnten Sicherheitskorrekturen hinaus adressieren aktive PRs verbleibende Audit-Ergebnisse: Secret-Typ für Zeroization führt einen Wrapper-Typ ein, der sensible Daten beim Drop automatisch löscht, Nachrichten-Abfrage-Paginierung verhindert Speichererschöpfung beim Laden des Chat-Verlaufs, und verschlüsselter Speicher fügt Ruheverschlüsselung für die SQLite-Datenbank hinzu, die Gruppenstatus und Nachrichten speichert.

Amethyst (Android)

Eine arbeitsreiche Woche mit Stabilitätskorrekturen im Android-Client. Nachsichtiges JSON-Parsing verhindert Abstürze durch fehlerhafte Events, indem Kotlin Serialization nachgiebiger gemacht wird. Event-Validierung prüft jetzt die Kind-Feldgröße vor der Verarbeitung, um Exceptions durch übergroße Werte zu vermeiden. Die Trust-Score-UI bekam ein kleineres Icon, um visuelle Störungen zu reduzieren, und verbessertes Fehler-Logging hilft bei der Diagnose von Relay-Verbindungsproblemen. Übersetzungsaktualisierungen kamen via Crowdin, und mehrere SonarQube-Warnungen wurden behoben.

TENEX (KI-Agenten)

Das Nostr-native KI-Agenten-Framework sah 81 Commits diese Woche, die autonome Fähigkeiten ausbauen. Ein neues Agenten-Überwachungssystem implementiert Verhaltensheuristiken zur Überwachung von Agentenaktionen und zum Eingreifen bei Bedarf. Delegationstransparenz fügt Benutzerinterventions-Logging zu Delegationstranskripten hinzu, damit Nutzer überprüfen können, was Agenten in ihrem Namen getan haben. Die LLM-Provider-Registry wurde modularisiert für einfachere Integration verschiedener KI-Backends. Projektübergreifende Konversationsunterstützung ermöglicht es Agenten, Kontext über mehrere Nostr-basierte Projekte hinweg zu bewahren.

Jumble (Web-Client)

Der Relay-fokussierte Web-Client fügt mehrere User-Experience-Verbesserungen hinzu. Intelligenter Relay-Pool verwaltet Verbindungen intelligent basierend auf Nutzungsmustern. Live-Feed-Toggle lässt Nutzer zwischen Echtzeit-Streaming und manueller Aktualisierung wechseln. Automatische Anzeige neuer Notizen oben bringt frische Inhalte an die Oberfläche, ohne Seitenneuladen zu erfordern. Persistenter Cache für Following-Feed und Benachrichtigungen verbessert Ladezeiten bei Rückkehrbesuchen. Nutzer können jetzt Standard-Relays ändern über die Einstellungen.

Das wars für diese Woche. Baust du etwas? Hast du Neuigkeiten zu teilen? Möchtest du, dass wir über dein Projekt berichten? Kontaktiere uns per NIP-17 DM oder finde uns auf Nostr.

Nostr Compass #3

Wed, 31 Dec 2025 00:00:00 +0000

Willkommen zurück bei Nostr Compass, Ihrem wöchentlichen Leitfaden zum Nostr-Protokoll-Ökosystem.

Diese Woche: Zum Abschluss des Jahres 2025 blicken wir auf fünf Jahre Dezember-Meilensteine in der Evolution von Nostr zurück. Von fiatjafs erster Client-Veröffentlichung im Dezember 2020, über Jack Dorseys wegweisende 14-BTC-Spende im Dezember 2022, bis zur NIP-55-Signer-Verbreitung und NDKs 162-facher Cache-Beschleunigung in diesem Monat - der Dezember hat konsequent Wendepunkte für das Protokoll markiert. Diese Sonderausgabe zeichnet die technische Geschichte durch jeden Dezember nach und dokumentiert das Wachstum des Protokolls von zwei experimentellen Relays zu über 2.500 Knoten in 50 Ländern. Außerdem: Amethysts Desktop-Modul nimmt durch Quartz Gestalt an, Notedeck erhält Messaging, Citrine hostet Web-Apps und NIP-54 behebt die Internationalisierung für nicht-lateinische Schriften.

Dezember-Rückblick: Fünf Jahre Nostr-Dezember

Nostr wird dieses Jahr fünf. fiatjaf startete das Protokoll am 7. November 2020, und jeder Dezember seither markierte eine eigenständige Phase seiner Entwicklung: vom Proof-of-Concept zur globalen Bewegung zum Produktions-Ökosystem. Dies ist ein technischer Rückblick von Dezember 2020 bis Dezember 2025, die prägenden Jahre, die Nostrs Grundlage etablierten und seinen Durchbruch katalysierten.

Dezember 2020: Genesis

Der erste vollständige Monat von Nostrs Existenz sah fiatjaf Branle veröffentlichen, den ersten Client des Protokolls, gebaut mit Quasar (Vue.js) und absurd-sql für lokale Speicherung. fiatjaf hatte bereits die Kernarchitektur etabliert: Benutzer identifiziert durch secp256k1-Public-Keys, alle Posts kryptografisch signiert, Relays dienen als einfache Speicher, die nicht miteinander kommunizieren. Ein oder zwei experimentelle Relays bedienten eine Handvoll frühe Anwender, die sich in der Telegram-Gruppe @nostr_protocol koordinierten, die am 16. November gestartet war. Die ursprüngliche Dokumentation beschrieb “das einfachste offene Protokoll, das in der Lage ist, ein zensurresistentes globales soziales Netzwerk zu schaffen” - eine Prämisse, deren Beweis noch zwei weitere Jahre dauern sollte.

Dezember 2021: Frühe Entwicklung

Am 31. Dezember 2021 erreichte Nostr die Hacker-News-Titelseite mit 110 Punkten und 138 Kommentaren, eingereicht von Cameri. Dies markierte die erste bedeutende Exposition des Protokolls gegenüber der breiteren Entwickler-Community. Das Netzwerk lief auf etwa sieben Relays mit weniger als 1.000 Benutzern. Branle erhielt Updates einschließlich Private-Key-Import (31. Dezember) und Multi-Relay-Unterstützung. Ein Kommandozeilen-Client, noscl, bot Terminal-basierte Interaktion. Die Protokollspezifikationen existierten in fiatjafs Dokumentation, obwohl das formelle NIPs-Repository erst im Mai 2022 erstellt werden würde. Das Protokoll war, wie fiatjaf es beschrieb, “ein Work in Progress”.

Dezember 2022: Der Wendepunkt

Dezember 2022 transformierte Nostr von einem Nischenexperiment in eine Mainstream-Bewegung. Der Katalysator kam am 15. Dezember, als Jack Dorsey 14,17171699 BTC (~245.000-250.000 $) an fiatjaf spendete, nachdem er das Protokoll entdeckt und erklärt hatte, es sei “100 Prozent das, was wir von Bluesky wollten, aber es wurde nicht von einer Firma entwickelt”. Am 16. Dezember kündigte fiatjaf an, die Mittel mit Damus-Entwickler William Casarin (jb55) zu teilen, und Dorsey verifizierte sein Nostr-Konto (npub: npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m). Die Finanzierung legitimierte das Projekt über Nacht.

In derselben Woche beschleunigte Twitters Chaos die Adoption. Am 14.-15. Dezember gab es Suspendierungen prominenter Journalisten von der New York Times, CNN und Washington Post. Am 18. Dezember kündigte Twitter Verbote für Konten an, die Nostr, Mastodon und andere Plattformen bewarben. Die Richtlinie wurde am folgenden Tag nach Gegenwehr zurückgenommen. Der Exodus trieb Benutzer dazu, Alternativen zu erkunden.

Die Protokollentwicklung beschleunigte sich. Am 16. Dezember wurde NIP-19 gemerged (#57), das bech32-kodierte Identifikatoren (npub, nsec, note, nprofile, nevent) einführte, die Schlüssel menschenlesbar und unterscheidbar machten. Das NIPs-Repository verzeichnete in diesem Monat 36+ Commits, einschließlich Updates für NIP-40 und NIP-07. Clients vermehrten sich: Damus füllte seine TestFlight-Beta innerhalb von Stunden, Astral forkte Branle für die Profilerstellung, Snort startete als “schneller, zensurresistenter” Web-Client, und Vitor Pamplona begann die Amethyst-Entwicklung. Alby v1.22.1 “Kemble’s Cascade of Stars” wurde am 22. Dezember mit NIP-19-Unterstützung ausgeliefert. Bis zum 7. Dezember hatte Nostr etwa 800 Benutzer mit Profilen; als Damus am 31. Januar 2023 den App Store erreichte, öffneten sich die Schleusen und trieben das Wachstum bis Juni 2023 auf über 315.000 Benutzer.

Dezember 2023: Ökosystem-Reifung

Dezember 2023 markierte einen kritischen Wendepunkt für die Sicherheit des Nostr-Protokolls. Am 20. Dezember wurde NIP-44 Revision 3 gemerged nach einem unabhängigen Cure53-Sicherheitsaudit (NOS-01), das 10 Probleme in den TypeScript-, Go- und Rust-Implementierungen identifizierte, einschließlich Timing-Attacken und Forward-Secrecy-Bedenken. Die aktualisierte Spezifikation ersetzte die fehlerhafte NIP-04-Verschlüsselung durch ChaCha20 und HMAC-SHA256 und etablierte die kryptografische Grundlage, die jetzt NIP-17 private DMs und NIP-59 Gift Wrapping untermauert. In derselben Woche kündigte OpenSats ihre vierte Grant-Welle am 21. Dezember an und finanzierte sieben Projekte einschließlich Lume, noStrudel, ZapThreads und ein unabhängiges NIP-44-Audit. Dies folgte der ersten Welle im Juli 2023, die Damus, Coracle, Iris und andere finanziert hatte, und brachte die Gesamtzuweisung des Nostr-Fonds auf etwa 3,4 Millionen Dollar über 39 Grants.

Der Monat offenbarte auch Nachhaltigkeitsspannungen im Ökosystem. Am 28. Dezember postete William Casarin (jb55) auf Stacker News, dass 2024 “wahrscheinlich das letzte Jahr von Damus” sein werde, und führte an, dass “Nostr-Clients kein Geld verdienen”, nachdem Apples Einschränkungen bei In-App-Zaps das Umsatzpotenzial stark limitiert hatten. Das Damus-Team hatte zuvor VC-Finanzierung abgelehnt. Unterdessen wurde Nostr Wallet Connect v0.4.1 am 26. Dezember ausgeliefert und erweiterte NIP-47 mit pay_keysend, make_invoice, lookup_invoice, list_transactions, get_balance und get_info-Methoden, was den Grundstein für die Wallet-Integrationen legte, die zum Standard über alle Clients werden sollten.

Dezember 2024: Protokoll-Fortschritt

Dezember 2024 begann mit dem Notedeck Alpha-Launch am 30. November, dem Rust-basierten Desktop-Client des Damus-Teams mit einer mehrspaligen Oberfläche und Unterstützung mehrerer Konten. Gebaut für Linux, macOS und Windows (Android für 2025 geplant), wurde Notedeck zunächst an Damus-Purple-Abonnenten ausgeliefert und stellte eine strategische Expansion über iOS hinaus dar. Zwei Wochen später kündigte OpenSats ihre neunte Grant-Welle am 16. Dezember an und finanzierte AlgoRelay (das erste algorithmische Relay für personalisierte Feeds), Pokey (Android-App mit Bluetooth-Mesh für eingeschränktes Internet), Nostr Safebox (NIP-60 Cashu-Token-Speicherung) und LumiLumi (leichtgewichtiger barrierefreier Web-Client), was die Gesamtzuweisung des Nostr-Fonds auf etwa 9 Millionen Dollar brachte - ein Anstieg von 67% im Jahresvergleich.

Der Monat sah signifikante Client-Reifung im gesamten Ökosystem. Gossip 0.13.0 landete am 23. Dezember mit File-Metadata-Unterstützung (NIP-92/NIP-94), Blossom-Integration und NIP-50 Relay-Suche. Coracle 0.5.0 wurde am 12. Dezember mit überarbeitetem Onboarding und nostr-editor-Integration ausgeliefert. Die Protokollentwicklung blieb aktiv mit 30 Pull Requests zwischen dem 9. und 22. Dezember (10 gemerged), einschließlich NIP-46-Umschreibungen zur ausschließlichen Verwendung von NIP-44-Verschlüsselung und fortgesetzter Arbeit an NIP-104 für Double-Ratchet-Verschlüsselung auf Signal-Niveau. Netzwerkstatistiken zeigten über 224.000 tägliche Trusted-Pubkey-Events, 4-faches Jahreswachstum bei neuen Profilen mit Kontaktlisten und einen 50%igen Anstieg bei öffentlichen Schreib-Events.

Dezember 2025: Ökosystem-Expansion

Dezember 2025 brachte fortgesetzte Protokollreifung und Ökosystem-Expansion. Am 21. Dezember kündigte OpenSats ihre vierzehnte Nostr-Grant-Welle an und finanzierte drei Projekte: YakiHonne (ein Multi-Plattform-Client mit Creator-Portal für Long-Form-Content und Cashu/Nutzaps-Zahlungsintegration), Quartz (Vitor Pamplonas Kotlin-Multiplatform-Bibliothek, die Amethyst antreibt und eine iOS-Version ermöglichen wird) und Nostr Feedz (bidirektionale RSS-zu-Nostr-Integration von PlebOne). Grant-Verlängerungen gingen an Dart NDK und Mattns nostr-relay.

Die Protokollevolution setzte sich fort mit NIP-BE (Bluetooth Low Energy Messaging, #1979), das im November gemerged wurde und Offline-Gerätesynchronisation ermöglicht. NIP-A4 (Public Messages, kind 24, #1988) landete später im Monat und definierte Benachrichtigungsbildschirm-Nachrichten, die q-Tags verwenden, um Threading-Komplikationen zu vermeiden. NIP-29 erhielt größere Klärung (#2106) und führte das hidden-Tag für wirklich private, nicht auffindbare Gruppen ein. Die NIP-55-Spezifikation sah ebenfalls Verfeinerung (#2166) und adressierte einen häufigen Implementierungsfehler, bei dem Entwickler get_public_key aus Hintergrundprozessen aufriefen.

Auf der Client-Seite wurde Primal Android zu einem vollständigen NIP-55-Signer durch acht gemergte PRs, die LocalSignerContentProvider implementierten, und schloss sich Amber und Aegis als Android-Signing-Optionen an. Die NDK-Bibliothek erreichte 162-mal schnellere Cache-Abfragen (von ~3.690ms auf ~22ms) durch Eliminierung doppelter Schreibvorgänge und unnötige LRU-Cache-Lookups (PR #371, PR #372). Shopstr führte Zapsnags für Flash-Sales via zaps ein. White Noise lieferte datenschutzfreundliche Push-Benachrichtigungen mit MIP-05. Siehe Newsletter #1 und Newsletter #2 für vollständige Berichterstattung.

Vor fünf Jahren veröffentlichte fiatjaf Branle für eine Handvoll Benutzer über zwei experimentelle Relays. Heute unterstützt das Protokoll 140+ Clients, 2.500+ Relays in 50 Ländern und ein wachsendes Web of Trust, das Hunderttausende von Keypairs verbindet. Dezembersmuster grosser Veröffentlichungen setzte sich diesen Monat fort mit Bluetooth-Messaging, Android-Signer-Verbreitung und Infrastruktur-Grants, die nachhaltige Investitionen in plattformübergreifende Tools signalisieren.

Neuigkeiten

Amethyst Desktop nimmt Gestalt an - Der Quartz-Grant aus OpenSats’ vierzehnter Welle produziert bereits Ergebnisse. PR #1625 erstellt ein vollständiges :desktopApp-Modul für Amethyst mit Compose Multiplatform, mit funktionierenden Login- und Global-Feed-Bildschirmen auf Desktop JVM. Die Architektur konvertiert das :commons-Modul zu Kotlin Multiplatform mit einer sauberen Source-Set-Struktur (commonMain, jvmAndroid, androidMain, jvmMain), die gemeinsame UI-Komponenten zwischen Android und Desktop ermöglicht, während plattformspezifische Entscheidungen jedem Target überlassen werden. Dies legt den Grundstein für die eventuelle iOS-Version über denselben Kotlin-Multiplatform-Ansatz.

Amethyst Sprachantworten - Eine Weihnachtslieferung von davotoula: PR #1622 fügt dedizierte Sprachantwort-Bildschirme mit Wellenform-Visualisierung, Neuaufnahme-Unterstützung, Medienserver-Auswahl und Upload-Fortschrittsanzeigen hinzu. Benutzer können jetzt sowohl auf Root-Sprachnachrichten als auch auf Sprachantworten mit Audio antworten.

Notedeck fügt Messaging hinzu - Notedeck, der Damus-Desktop-Client, erhielt eine Nachrichtenfunktion in PR #1223, die über Timeline-Browsing hinaus in direkte Kommunikation expandiert.

Citrine hostet Web-Apps - Citrine kann jetzt Web-Anwendungen hosten und verwandelt Ihr Telefon in einen Local-First-Nostr-Webserver. Ein separater PR #85 fügt automatische Neuverbindung und Event-Broadcasting hinzu, wenn die Netzwerkkonnektivität zurückkehrt, mit umfassender Testabdeckung über Android-API-Levels.

Nostrability Developer Toolkit Registry - Der Developer Kits & Tooling-Tracker pflegt ein kuratiertes Register von SDKs, Bibliotheken und Entwicklertools über Sprachen hinweg (TypeScript, Rust, Python, Go, Dart, Swift und mehr). Wenn Sie neu in der Nostr-Entwicklung sind, ist dies ein nützlicher Ausgangspunkt, um das richtige Toolkit für Ihren Stack zu finden.

NIP-Updates

Aktuelle Änderungen am NIPs-Repository:

NIP-54 - Kritische Internationalisierungskorrektur für Wiki-d-Tag-Normalisierung (#2177). Frühere Regeln konvertierten alle Nicht-ASCII-Zeichen zu -, was die Unterstützung für Japanisch, Chinesisch, Arabisch, Kyrillisch und andere Schriften brach. Die aktualisierte Spezifikation bewahrt UTF-8-Buchstaben, wendet Kleinschreibung nur auf Zeichen mit Grossbuchstaben-Varianten an und enthält umfassende Beispiele: "ウィキペディア" bleibt "ウィキペディア", "Москва" wird zu "москва", und gemischte Schriften wie "日本語 Article" normalisieren zu "日本語-article".

Veröffentlichungen

Zapstore 1.0-rc1 - Der Nostr-basierte permissionless App Store liefert den ersten Release Candidate seiner neuen Architektur mit einer vollständigen UI-Überarbeitung, umgeschriebenem Paketmanager mit verbesserter Fehlerbehandlung, App Stacks für kuratierte Entdeckung, neugestalteten Profilbildschirmen, Hintergrund-Update-Prüfung und unendlichem Scrollen in Release-Listen.

KeyChat v1.38.1 - Die MLS-basierte verschlüsselte Messaging-App fügt UnifiedPush-Unterstützung für Android- und Linux-Push-Benachrichtigungen hinzu, plus biometrische Authentifizierung für Datenschutzoperationen. Verfügbar für Android, Windows, macOS und Linux.

Alby Go v2.0.0 - Der mobile Lightning-Wallet-Begleiter liefert ein visuelles Redesign mit neuem Logo, aktualisierter Farbpalette, neugestaltetem Adressbuch und verbesserter Betragseingabe-Tastatur. BTC Map ist jetzt vom Startbildschirm aus zugänglich, und Transaktionsbeschreibungen erscheinen in Benachrichtigungen.

nak v0.17.4 - fiatjafs Kommandozeilen-Nostr-Tool veröffentlicht, nach v0.17.3s LMDB-Linux-Restriktionskorrektur von letzter Woche.

Bemerkenswerte Code- und Dokumentationsänderungen

Offene Pull Requests und Arbeiten im Frühstadium, die es wert sind, beobachtet zu werden.

Damus (iOS)

NIP-19 relay hints implementiert den Verbrauch von Relay-Hints für Event-Abruf. Wenn Benutzer nevent-, nprofile- oder naddr-Links öffnen, extrahiert Damus jetzt Relay-Hints aus den bech32-TLV-Daten und verbindet sich mit ephemeren Relays, um Inhalte abzurufen, die nicht im Relay-Pool des Benutzers sind. Die Implementierung enthält referenzgezählte Bereinigung, um Race Conditions während gleichzeitiger Lookups zu verhindern. Bild-URL-Erkennung konvertiert automatisch eingefügte Bild-URLs in Vorschau-Thumbnails im Composer, mit Karussell-Positionsabzeichen für mehrere Bilder. npub-Einfüge-Konvertierung transformiert eingefügte npub/nprofile-Strings in Erwähnungs-Links mit asynchroner Profilauflösung.

Amethyst (Android)

Payment targets fügt eine Event-Schnittstelle für NIP-57-Zap-Splits hinzu, die es Posts ermöglicht, mehrere Empfänger anzugeben, die eingehende zaps teilen (nützlich für Kollaborationen, Umsatzbeteiligung oder Trinkgeld an sowohl Content-Ersteller als auch die Tools, die sie verwenden). Quartz-Feature-Paritätsdokumentation fügt eine detaillierte Tabelle hinzu, die verfolgt, welche Features über Android-, Desktop-JVM- und iOS-Targets implementiert sind, und vermerkt, dass iOS Core-Kryptografie (Secp256k1Instance), JSON-Serialisierung und Datenstrukturen fehlen.

Notedeck (Desktop)

Timeline-Filter-Neubau behebt einen Bug, bei dem entfolgte Konten weiterhin in Feeds erschienen. Timeline-Filter wurden einmal aus der Kontaktliste erstellt und nie aktualisiert; die Korrektur fügt contact_list_timestamp-Tracking und eine invalidate()-Methode hinzu, um Neubauten auszulösen, wenn sich der Folge-Status ändert.

Citrine (Android Relay)

ContentProvider API exponiert die Event-Datenbank des lokalen Relays an andere Android-Apps über ContentResolver. Im Gegensatz zur WebSocket-Schnittstelle (die erfordert, dass Apps eine persistente Verbindung aufrechterhalten und das Nostr-Relay-Protokoll sprechen) bietet ContentProvider direkten synchronen Datenbankzugriff über Androids nativen IPC-Mechanismus. Externe Apps können Events nach ID, pubkey, kind oder Datumsbereich abfragen, neue Events mit Validierung einfügen und Events löschen, ohne Socket-Verbindungen zu verwalten.

rust-nostr (Library)

NIP-40 Relay-Level-Unterstützung fügt Ablaufbehandlung auf Relay-Builder-Ebene hinzu. Abgelaufene Events werden jetzt vor der Speicherung abgelehnt und vor dem Senden an Clients herausgefiltert, wodurch die Notwendigkeit entfällt, dass jede Datenbankimplementierung Ablaufprüfungen unabhängig behandelt.

nak (CLI)

Blossom mirror implementiert Blob-Mirroring-Funktionalität für das Kommandozeilen-Tool.

Mostro (P2P Trading)

Dev fee audit events fügt transparente Audit-Trails für Entwicklungsfonds-Zahlungen durch kind-8383-Nostr-Events hinzu. Die Implementierung veröffentlicht nicht-blockierende Audit-Events nach erfolgreichen Gebührenzahlungen, einschließlich Bestelldetails und Zahlungs-Hashes, während Käufer/Verkäufer-Pubkeys aus Datenschutzgründen ausgeschlossen werden.

MDK (Marmot Development Kit)

Drei Sicherheitsaudit-Korrekturen landeten: Autorenverifizierung erzwingt, dass Rumor-Pubkeys mit MLS-Absender-Credentials übereinstimmen, um Impersonationsangriffe zu verhindern. KeyPackage-Identitätsbindung verifiziert, dass Credential-Identität mit Event-Signierern übereinstimmt. Admin-Update-Validierung verhindert leere Admin-Sets und Nicht-Mitglieder-Admin-Zuweisungen.

Shopstr (Marketplace)

HODL invoice escrow implementiert ein vertrauensminimiertes Zahlungssystem für physische Güter. Die Architektur verwendet Albys makeHoldInvoice, um Käufergelder in ihrer eigenen Wallet zu sperren, wobei die Abwicklung erst nach der Bestandsverifizierung durch den Händler ausgelöst wird. Das Handshake-Protokoll läuft über NIP-17 verschlüsselte DMs: Käufer sendet Bestellanfrage, Händler antwortet mit HODL Invoice, Käufer zahlt (Gelder gesperrt), Händler bestätigt Bestand und Versand, dann gibt die Abwicklung die Gelder frei. Multi-Händler-Warenkorb-Unterstützung teilt Zahlungen auf Verkäufer auf.

Jumble (Web Client)

Pro-Relay-Entdeckungsmodus fügt einen Schalter hinzu, um Posts von gefolgten Benutzern auf bestimmten Relays zu verbergen, was sprachbasierte Entdeckungs-Feeds ermöglicht (z.B. nostr.band/lang/*). Die Funktion filtert Posts heraus, bei denen der Autoren-Pubkey in der Folgeliste des Benutzers erscheint, und persistiert den Schalter-Status pro Relay-URL in localStorage.

White Noise (Encrypted Messaging)

Medien-Upload-Wiederholung fügt Wiederholungsoptionen für fehlgeschlagene Uploads hinzu. Profilbearbeitungswarnungen warnen Benutzer vor Profiländerungen. Im Backend behebt whitenoise-rs eine Race Condition bei der AccountGroup-Erstellung.

npub.cash (Lightning Address Service)

v3-Umschreibung migriert zu Bun für das Monorepo und den Server, fügt SQLite-Unterstützung hinzu, entfernt v1-Kompatibilität, implementiert LUD-21 und fügt Echtzeit-Mint-Quote-Updates hinzu.

nostr-java (Library)

v1.1.1 liefert WebSocket-Handling-Refaktoren und verbesserte Test-Robustheit über zwei PRs.

NIPs Repository

NIP-54-Djot-Migration schlägt eine separate Änderung der Wiki-Spezifikation vor: Wechsel des Inhaltsformats von Asciidoc zu Djot, einer leichtgewichtigen Auszeichnungssprache mit sauberer Syntax. Der PR führt referenzbasierte Links für Wikilinks ein, was Querverweise zwischen Wiki-Artikeln in Quellform lesbarer macht. NIP-XX Quorum führt Schwellenwert-Multisignatur-Governance für Nostr-Gruppen mit FROST (Flexible Round-Optimized Schnorr Threshold signatures) ein. Ein Quorum ist ein nsec, das unter Mitgliedern durch ein T-von-N-Schema geteilt wird, bei dem Mitglieder sich selbst vertreten oder an einen Repräsentantenrat delegieren können. Wenn der Rat wechselt, wird der alte nsec obsolet und ein neuer wird verteilt - der letzte Akt jedes Rats ist die Signierung des Governance-Übergangs-Events. Die Spezifikation definiert Mitgliedschaft (öffentlich oder privat), Wahlen und Abstimmungen (Volksabstimmungen, Misstrauensvoten), optionale “Gesetze” in natürlicher Sprache und, entscheidend, Quorum-Ontologien, bei denen Quoren Mitglieder anderer Quoren sein können, was hierarchische Strukturen wie Lokalitäten ermöglicht, die regionalen Körperschaften beitreten. Anwendungsfälle umfassen Quellcode-Entwicklung, Unternehmensvorstande, HOAs und moderierte Gemeinschaften.

Das war’s für diese Woche und dieses Jahr. Bauen Sie etwas? Haben Sie Neuigkeiten zu teilen? Möchten Sie, dass wir über Ihr Projekt berichten? Kontaktieren Sie uns via NIP-17 DM oder finden Sie uns auf Nostr.

Nostr Compass #2

Wed, 24 Dec 2025 00:00:00 +0000

Willkommen zurück bei Nostr Compass, deinem wöchentlichen Guide zum Nostr-Protokoll-Ökosystem.

Diese Woche: Drei NIP-55 Signer-Implementierungen erhalten Updates: Amber fügt Performance-Caching hinzu, Aegis erhält nostrsigner: URI-Unterstützung, und Primal Android gesellt sich als vollständiger lokaler Signer hinzu. Shopstr führt “Zapsnags” für Flash-Sales via Zaps ein. Mostro fügt einen Entwicklungsfonds hinzu. Vier NIP-Updates landen, darunter Public Messages (Kind 24) und Gruppen-Datenschutzverbesserungen. NDK-Cache-Abfragen werden 162x schneller, Applesauce fügt Reaktionen und NIP-60 Wallet-Unterstützung hinzu, und Tenex führt RAL-Architektur für KI-Agent-Delegation ein. In unserem Deep Dive erklären wir NIP-02 (Follow-Listen) und NIP-10 (Antwort-Threading), grundlegende Spezifikationen für den Aufbau sozialer Timelines und Konversationen.

News

Primal Android wird ein NIP-55 Signer - Aufbauend auf der Nostr Connect Unterstützung der letzten Woche hat Primal vollständige lokale Signing-Fähigkeiten durch acht zusammengeführte Pull Requests implementiert. Die Implementierung umfasst einen vollständigen LocalSignerContentProvider, der Signing-Operationen für andere Android-Apps über die Content Provider-Schnittstelle von Android freilegt, gemäß der NIP-55-Spezifikation. Die Architektur trennt Verantwortlichkeiten sauber: SignerActivity behandelt benutzerorientierte Genehmigungsabläufe, LocalSignerService verwaltet Hintergrundoperationen, und ein neues Berechtigungssystem lässt Benutzer kontrollieren, welche Apps Signaturen anfordern können. Dies macht Primal zu einer praktikablen Alternative zu Amber für Android-Benutzer, die ihre Schlüssel in einer App behalten möchten, während sie andere für verschiedene Nostr-Erlebnisse nutzen.

Shopstr Zapsnags: Flash Sales via Lightning - Der Nostr-native Marktplatz führte “Zapsnags” ein, eine Flash-Sale-Funktion, mit der Käufer Artikel direkt aus ihrem sozialen Feed mit einem einzigen Zap kaufen können. Die Implementierung filtert Kind 1 Notizen, die mit #shopstr-zapsnag getaggt sind, und rendert sie als Produktkarten mit einem “Zap to Buy”-Button anstelle des Standard-Warenkorb-Flows.

Mostro führt Entwicklungsfonds ein - Die NIP-69 P2P Bitcoin Trading Plattform implementierte konfigurierbare Entwicklungsgebühren zur Unterstützung nachhaltiger Wartung. Betreiber können dev_fee_percentage zwischen 10-100% der Mostro-Handelsgebühr festlegen (Standard 30%), die bei jedem erfolgreichen Trade automatisch an einen Entwicklungsfonds weitergeleitet wird.

NIP Updates

Aktuelle Änderungen am NIPs Repository:

Neue NIPs:

NIP-A4 (Public Messages, Kind 24) - Ein neuer Kind für Benachrichtigungsbildschirm-Nachrichten, konzipiert für breite Client-Unterstützung (#1988).

Bedeutende Änderungen:

NIP-29 - Wichtige Klärung der Gruppen-Semantik (#2106). Das closed Tag bedeutet jetzt “schreibunfähig” (nur-Lesen für Nicht-Mitglieder), entkoppelt von Beitrittsmechanik. Ein neues hidden Tag verhindert, dass Relays Metadaten oder Mitglieder-Events an Nicht-Mitglieder senden.
NIP-51 - Kind 30006 für kuratierte Bildersets hinzugefügt (#2170).
NIP-55 - Verbindungsinitiierung für Android-Signer geklärt (#2166).

NIP Deep Dive: NIP-02 und NIP-10

Diese Woche behandeln wir zwei NIPs, die für soziale Funktionalität essentiell sind: wie Clients wissen, wem du folgst, und wie Konversationen strukturiert werden.

NIP-02: Follow-Liste

NIP-02 definiert Kind 3 Events, die deine Follow-Liste speichern. Dieser einfache Mechanismus betreibt den sozialen Graphen, der Timelines möglich macht.

Struktur: Ein Kind 3 Event enthält p Tags, die gefolgten Pubkeys auflisten:

{
 "id": "d7a8f...",
 "pubkey": "a3b9c...",
 "created_at": 1734912000,
 "kind": 3,
 "tags": [
 ["p", "91cf9..af5f", "wss://alicerelay.example.com", "alice"],
 ["p", "14aeb..8dad", "wss://bobrelay.example.com", "bob"],
 ["p", "612ae..982b", "", ""]
 ],
 "content": "",
 "sig": "e4f8a..."
}

Jedes p Tag hat vier Positionen: der Tag-Name, die gefolgte Pubkey (Hex), ein optionaler Relay-URL-Hinweis und ein optionaler “Petname” (ein lokaler Spitzname).

Ersetzbares Verhalten: Kind 3 fällt in den ersetzbaren Bereich (0, 3, 10000-19999), sodass Relays nur die neueste Version pro Pubkey behalten. Wenn du jemandem Neuen folgst, veröffentlicht dein Client ein vollständiges neues Kind 3, das alle deine Follows plus den neuen enthält.

Timelines bauen: Um einen Home-Feed zu erstellen, ruft der Client das Kind 3 des Benutzers ab, extrahiert alle Pubkeys der p Tags und abonniert dann Kind 1 Events dieser Autoren.

NIP-10: Textnotiz-Threading

NIP-10 spezifiziert, wie Kind 1 Notizen sich gegenseitig referenzieren, um Antwort-Threads zu bilden.

Das Problem: Wenn jemand auf eine Notiz antwortet, müssen Clients wissen: Worauf ist dies eine Antwort? Was ist die Wurzel der Konversation? Wer sollte benachrichtigt werden?

Markierte Tags (bevorzugt): Moderne Clients verwenden explizite Marker in e Tags:

{
 "kind": 1,
 "tags": [
 ["e", "abc123...", "wss://relay.example.com", "root"],
 ["e", "def456...", "wss://relay.example.com", "reply"],
 ["p", "91cf9..."],
 ["p", "14aeb..."]
 ],
 "content": "Toller Punkt! Ich stimme zu."
}

Der root Marker zeigt auf die ursprüngliche Notiz, die den Thread gestartet hat. Der reply Marker zeigt auf die spezifische Notiz, die beantwortet wird.

Threading-Regeln:

Direkte Antwort auf Root: Ein e Tag mit root Marker
Antwort auf eine Antwort: Zwei e Tags, eines root und eines reply
Der root bleibt durch den Thread konstant; reply ändert sich je nachdem, worauf du antwortest

Releases

Zeus v0.12.0 - Aufbauend auf der NWC parallelen Zahlungsunterstützung der letzten Woche liefert das Major Release der Lightning-Wallet einen vollständigen NIP-47 Nostr Wallet Connect Service mit benutzerdefinierter Relay-Unterstützung und Budget-Tracking.

Amber v4.0.6 - Der Android NIP-55 Signer fügt Performance-Caching zu Signing-Operationen hinzu.

nak v0.17.3 - Das neueste Release beschränkt LMDB-Builds auf Linux.

Aegis v0.3.4 - Der plattformübergreifende Nostr-Signer fügt Unterstützung für das nostrsigner: URI-Schema hinzu.

Bemerkenswerte Code- und Dokumentationsänderungen

Damus (iOS)

Mute-Listen-Persistenz behebt ein Problem, bei dem Mute-Listen bei Kaltstart gelöscht wurden. Profil-Stream-Timing eliminiert eine ~1-Sekunden-Verzögerung bevor gecachte Profile erschienen.

NDK (Bibliothek)

Zwei Pull Requests lieferten dramatische Cache-Performance-Verbesserungen. PR #371 behob einen Bug, bei dem Events aus dem SQLite-Cache sofort zurückgeschrieben wurden. PR #372 entfernte unnötige seenEvent Aufrufe. Ergebnis: Cache-Abfragen fielen von ~3.690ms auf ~22ms (162x schneller).

rust-nostr (Bibliothek)

Multi-Filter REQ Unterstützung wurde nach Entfernung in einem früheren Refactor wiederhergestellt. Relay-Herkunft wurde zu stream_events* Methoden hinzugefügt. Ein Sicherheitsfix entfernte die url-fork Abhängigkeit.

Tenex (KI-Agenten)

Das Multi-Agent-Koordinationssystem führte RAL (Request-Action-Lifecycle) Architektur in fünf zusammengeführten PRs ein. RAL ermöglicht Agenten, beim Delegieren von Aufgaben zu pausieren und fortzufahren, wenn Ergebnisse eintreffen.

Das war’s für diese Woche. Baust du etwas? Hast du Neuigkeiten zu teilen? Möchtest du, dass wir dein Projekt behandeln? Kontaktiere uns via NIP-17 DM oder finde uns auf Nostr.

Nostr Compass #1

Mon, 15 Dec 2025 00:00:00 +0000

Willkommen bei Nostr Compass, einem wöchentlichen Newsletter, der dem Nostr-Protokoll-Ökosystem gewidmet ist. Unsere Mission ist es, Entwickler, Relay-Betreiber und Builder über wichtige Entwicklungen im gesamten Netzwerk auf dem Laufenden zu halten. Wir dokumentieren die Protokollevolution mit technischer Genauigkeit, Neutralität und Tiefe und decken alles ab, von NIP-Vorschlägen über Client-Releases bis hin zu Best Practices für die Implementierung.

Nostr Compass ist inspiriert von Bitcoin Optech, dessen jahrelange engagierte Arbeit zur Förderung des technischen Bitcoin-Wissens den Standard für protokollfokussierte Newsletter gesetzt hat. Wir sind dankbar für ihr Beispiel und hoffen, dieselbe Strenge in das Nostr-Ökosystem zu bringen.

Diese Erstausgabe etabliert unser wöchentliches Format. Jeden Mittwoch bringen wir dir NIP-Updates, Release-Notes, Entwicklungs-Highlights und technische Anleitungen. Ob du einen Client baust, einen Relay betreibst oder zum Protokoll beiträgst – Nostr Compass möchte deine zuverlässige Quelle für das Geschehen im Ökosystem sein.

Was ist Nostr?

Da dies unsere erste Ausgabe ist, beginnen wir mit einer Einführung in die Funktionsweise von Nostr. Regelmäßige Leser können vorspringen.

Nostr (Notes and Other Stuff Transmitted by Relays) ist ein dezentrales Protokoll für soziale Netzwerke und Messaging. Anders als traditionelle Plattformen hat Nostr keinen zentralen Server, kein Unternehmen kontrolliert es und es gibt keinen Single Point of Failure. Benutzer besitzen ihre Identität durch kryptografische Schlüsselpaare, und Inhalte fließen durch unabhängige Relay-Server, die jeder betreiben kann.

Wie es funktioniert: Benutzer generieren ein Schlüsselpaar (einen privaten Schlüssel namens nsec und einen öffentlichen Schlüssel namens npub). Der private Schlüssel signiert Nachrichten, die “Events” genannt werden, und der öffentliche Schlüssel dient als deine Identität. Events werden an Relays gesendet, die sie speichern und an andere Benutzer weiterleiten. Da du deine Schlüssel kontrollierst, kannst du zwischen Clients oder Relays wechseln, ohne deine Identität oder Follower zu verlieren.

Warum es wichtig ist: Nostr bietet Zensurresistenz durch Relay-Vielfalt (wenn ein Relay dich sperrt, können andere immer noch deine Inhalte bereitstellen), Portabilität (deine Identität funktioniert in jeder Nostr-App) und Interoperabilität (alle Nostr-Clients sprechen dasselbe Protokoll). Es gibt keinen Algorithmus, der entscheidet, was du siehst, keine Werbung und keine Datensammlung.

Das Ökosystem heute: Nostr unterstützt Microblogging (wie Twitter/X), Langform-Inhalte (wie Medium), Direktnachrichten, Marktplätze, Livestreaming und mehr. Clients umfassen Damus (iOS), Amethyst (Android), Primal, Coracle und Dutzende weitere. Die Lightning-Network-Integration ermöglicht sofortige Zahlungen durch “Zaps”. Das Protokoll entwickelt sich weiter durch NIPs (Nostr Implementation Possibilities), community-getriebene Spezifikationen, die die Funktionalität erweitern.

News

NIP-BE Merged: Bluetooth Low Energy Support - Eine bedeutende neue Fähigkeit ist im Protokoll gelandet. NIP-BE spezifiziert, wie Nostr-Anwendungen über Bluetooth Low Energy kommunizieren und synchronisieren können. Dies ermöglicht offline-fähigen Apps, Daten zwischen nahen Geräten ohne Internetverbindung zu synchronisieren. Die Spezifikation passt WebSocket-Relay-Muster an die BLE-Einschränkungen an, verwendet DEFLATE-Kompression und fragmentierte Nachrichten, um mit den kleinen MTU-Größen von BLE (20-256 Bytes) umzugehen. Geräte verhandeln Rollen basierend auf UUID-Vergleich, wobei die höhere UUID zum GATT-Server wird.

MIP-05: Datenschutzerhaltende Push-Benachrichtigungen - Das Marmot Protocol veröffentlichte MIP-05 (Spec), eine Spezifikation für Push-Benachrichtigungen, die die Privatsphäre wahren. Traditionelle Push-Systeme erfordern, dass Server Geräte-Token und Benutzeridentitäten kennen; MIP-05 löst dies, indem Geräte-Token mit ECDH+HKDF und ChaCha20-Poly1305 verschlüsselt werden und ephemere Schlüssel verwendet werden, um Korrelation zu verhindern. Ein Drei-Event-Gossip-Protokoll (Kinds 447-449) synchronisiert verschlüsselte Token zwischen Gruppenmitgliedern, und Benachrichtigungen verwenden NIP-59 Gift Wrapping mit Köder-Token, um Gruppengrößen zu verbergen.

Blossom BUD-10: Neues URI-Schema - Das Blossom-Medienprotokoll bekommt ein benutzerdefiniertes URI-Schema via BUD-10 (Spec). Das neue blossom:<sha256>.ext-Format bettet Datei-Hash, Erweiterung, Größe, mehrere Server-Hinweise und Autor-Pubkeys für BUD-03 Server-Entdeckung ein. Dies macht Blob-Links widerstandsfähiger als statische HTTP-URLs, indem automatisches Fallback zwischen Servern ermöglicht wird.

Shopstr Marketplace Updates - Der Nostr-native Marktplatz implementierte Nostr Wallet Connect (NIP-47) für Zahlungen, fügte Listing-Ablauf hinzu mit NIP-40 und führte Rabattcodes für Verkäufer ein.

NIP Updates

Aktuelle Änderungen am NIPs Repository:

Neue NIPs:

NIP-BE - Bluetooth Low Energy Messaging und Gerätesynchronisation (#1979)
NIP-63 - Paywall/Premium Content Standard für die Handhabung von geschütztem Content im Protokoll (#2156)

Bedeutende Änderungen:

NIP-24 - Optionales languages-Array zu Kind 0 Benutzer-Metadaten hinzugefügt, das Benutzern erlaubt, mehrere bevorzugte Sprachen mit IETF BCP 47 Tags anzugeben (#2159)
NIP-69 - Order-Ablauf-Support für P2P-Trading mit expires_at und expiration Tags hinzugefügt (#2118)
NIP-59 - Gift Wrap Events können jetzt via NIP-09/NIP-62 Anfragen gelöscht werden (#2131)
NIP-51 - Hashtag- und URL-Tags aus generischen Lesezeichen entfernt; Hashtags verwenden jetzt Kind 30015 (#2133)
NIP-18 - Generische Reposts für ersetzbare Events mit a Tag Support verbessert (#2132)
NIP-17 - Formulierung verfeinert und Kind 7 Reaktions-Support zu DMs hinzugefügt (#2098)
NIP-11 - self Feld für Relay-Public-Key-Identifikation hinzugefügt (#1764)

NIP Deep Dive: NIP-01 und NIP-19

Für diese Erstausgabe behandeln wir zwei fundamentale NIPs, die jeder Nostr-Entwickler verstehen sollte. Siehe unsere Themenseiten für NIP-01 und NIP-19.

NIP-01: Basis-Protokoll

NIP-01 definiert das Kernprotokoll. Alles in Nostr baut auf dieser Spezifikation auf.

Events sind der einzige Objekttyp. Jedes Event enthält:

id: SHA256-Hash des serialisierten Events (der eindeutige Bezeichner des Events)
pubkey: Der öffentliche Schlüssel des Erstellers (32-Byte Hex, secp256k1)
created_at: Unix-Zeitstempel
kind: Integer, der den Event-Typ kategorisiert
tags: Array von Arrays für Metadaten
content: Die Nutzlast (Interpretation hängt vom Kind ab)
sig: Schnorr-Signatur, die beweist, dass die Pubkey dieses Event erstellt hat

Kinds bestimmen, wie Relays Events speichern:

Reguläre Events (1, 2, 4-44, 1000-9999): Normal gespeichert, alle Versionen behalten
Ersetzbare Events (0, 3, 10000-19999): Nur das neueste pro Pubkey wird behalten
Ephemere Events (20000-29999): Nicht gespeichert, nur an Abonnenten weitergeleitet
Adressierbare Events (30000-39999): Neuestes pro Pubkey + Kind + d Tag Kombination

Kind 0 sind Benutzer-Metadaten (Profil), Kind 1 ist eine Textnotiz (der Basis-Post), Kind 3 ist die Follow-Liste.

Kind 1: Textnotizen sind das Herz des sozialen Nostr. Ein Kind 1 Event ist ein Kurzform-Post, ähnlich einem Tweet. Das content-Feld enthält den Nachrichtentext (Plaintext, obwohl Clients oft Markdown rendern). Tags ermöglichen Antworten, Erwähnungen und Referenzen.

Adressierbare Events (30000-39999) funktionieren wie ersetzbare Events, verwenden aber ein d Tag als zusätzlichen Bezeichner. Das Relay behält nur die neueste Version jeder Pubkey + Kind + d-Tag Kombination. Dies ermöglicht editierbare Artikel, Produktlistings oder jeden Fall, in dem du mehrere ersetzbare Items pro Benutzer benötigst.

Tags sind Arrays, bei denen das erste Element der Tag-Name ist. Standard-Einzelbuchstaben-Tags (e, p, a, d, t) werden von Relays für effiziente Abfragen indexiert.

Client-Relay-Kommunikation verwendet WebSocket-Verbindungen mit JSON-Arrays als Nachrichten. Das erste Element identifiziert den Nachrichtentyp.

Von Client zu Relay:

["EVENT", <event>] - Veröffentlicht ein Event am Relay
["REQ", <sub-id>, <filter>, ...] - Abonniert Events, die dem/den Filter(n) entsprechen
["CLOSE", <sub-id>] - Beendet ein Abonnement

Von Relay zu Client:

["EVENT", <sub-id>, <event>] - Liefert ein Event, das deinem Abonnement entspricht
["EOSE", <sub-id>] - “Ende gespeicherter Events” - das Relay hat alle historischen Treffer gesendet
["OK", <event-id>, <true|false>, <message>] - Bestätigt, ob ein Event akzeptiert oder abgelehnt wurde
["NOTICE", <message>] - Menschenlesbare Nachricht vom Relay

NIP-19: Bech32-kodierte Bezeichner

NIP-19 definiert die menschenfreundlichen Formate, die du überall in Nostr siehst: npub, nsec, note und mehr. Diese werden nicht im Protokoll selbst verwendet (das Hex verwendet), aber sie sind essentiell für Teilen und Anzeige.

Warum bech32? Rohe Hex-Schlüssel sind fehleranfällig beim Kopieren und visuell schwer zu unterscheiden. Bech32-Kodierung fügt ein menschenlesbares Präfix und Prüfsumme hinzu.

Basis-Formate kodieren rohe 32-Byte-Werte:

npub - Öffentlicher Schlüssel (deine Identität, sicher zu teilen)
nsec - Privater Schlüssel (geheim halten, zum Signieren verwendet)
note - Event-ID (referenziert ein bestimmtes Event)

Teilbare Bezeichner enthalten Metadaten mit TLV-Kodierung (Type-Length-Value):

nprofile - Profil mit Relay-Hinweisen
nevent - Event mit Relay-Hinweisen, Autor-Pubkey und Kind
naddr - Adressierbare Event-Referenz (Pubkey + Kind + d-Tag + Relays)

Wichtig: Verwende niemals bech32-Formate im Protokoll selbst. Events, Relay-Nachrichten und NIP-05-Antworten müssen Hex verwenden. Bech32 ist rein für menschliche Schnittstellen.

Releases

Amber v4.0.4 - Die Android-Signer-App behebt einen NullPointerException, verbessert die Performance auf dem Aktivitätsbildschirm und fügt Übersetzungen für einige Event-Kinds hinzu. Release

Coracle 0.6.28 - Bugfix-Release für den Web-Client. Release

Flotilla v1.6.2 - Der Discord-ähnliche Communities-Client behebt Modal-Scrolling und Stil-Probleme. Release

nak v0.17.2 - Das Kommandozeilen-Nostr-Tool fügte einen neuen nip Befehl für schnelle NIP-Referenzsuche hinzu. Release

White Noise v0.2.1 - Major Release für die MLS-basierte verschlüsselte Messaging-App mit Bild-Sharing via Blossom, Hintergrund-Sync, Push-Benachrichtigungen und Lokalisierung in 8 Sprachen. Release

Amethyst v1.04.2 - Feature-Release mit Follow-Listen/Packs, neuen Timeline-Filtern, Bildergalerie und H.265-Videokompression. Release

Mostro v0.15.5 - P2P-Trading-Plattform-Update mit NIP-69 Order-Ablauf-Support. Release

Entwickler Best Practices

Validiere Auth Events Defensiv - go-nostr behob einen Panic in NIP-42 Validierung wenn das Relay-Tag fehlte. Prüfe immer erforderliche Tags vor dem Zugriff.

Rate Limiting nach Authentifizierungsstatus - khatru fügte NIP-42-basiertes Rate Limiting hinzu, das Relays erlaubt, unterschiedliche Limits für authentifizierte vs. anonyme Verbindungen anzuwenden.

Verwende Cursor-Paginierung für Listen - Blossom ersetzte datumsbasierte Paginierung durch cursorbasierte Paginierung. Datumsbasierte Paginierung bricht, wenn Items Zeitstempel teilen.

Schema-Validierung für Event-Typen - Das nostrability/schemata Projekt bietet JSON-Schemas zur Validierung NIP-konformer Events.

Das war’s für diese Woche. Baust du etwas? Hast du Neuigkeiten zu teilen? Möchtest du, dass wir dein Projekt behandeln? Kontaktiere uns via NIP-17 DM oder finde uns auf Nostr.