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

Diese Woche: Amber härtet Relay-Authentifizierung ab und verschlüsselt gespeicherte Geheimnisse, Cambium signiert für Websites unter Relay-Auth-Last, Citrine hostet Gruppen und statische Sites auf einem Smartphone-Relay, Vector reiht Moderation unter Spam in die Warteschlange und synchronisiert Stummschaltungen geräteübergreifend, Sonar ergänzt verschachtelte Mesh-Antworten, Nostria veröffentlicht Podcasts, und Nail überbrückt E-Mail als Gift-Wrap-Events. Releases umfassen MDK-Gruppenzustand, Badge-Prägung, QR-Signer-Pairing, Browser-Signing auf Android und gemeinsame Wallet-Connect-Bibliotheken. Die Protokollarbeit erreicht Kommentar-Patches, verschlüsselte Dateimetadaten, Thread-Formatierung, Marmot-Neustart-Garantien und Concord-Mitgliedschaftslisten. Deep Dives: Badges und Kommentare.

Top-Storys

Amber 6.5.0 schließt einen Relay-Auth-Confused-Deputy und verschlüsselt gespeicherte Geheimnisse

Amber ist ein Android-NIP-55- (Android-Signer-Intents) und NIP-46-Signer (relay-vermitteltes Remote-Signing). Version 6.5.0 schließt vier offengelegte Lücken: einen Confused Deputy bei der Relay-Authentifizierung, der jedem Aufrufer ein Kind-22242-NIP-42-Event (Client-zu-Relay-Authentifizierung) für Relays liefern ließ, die der Nutzer nie freigegeben hatte; eine NIP-46-Replay-Lücke; Klartext-Verbindungsgeheimnisse und lokale Schlüssel, die nun ruhend envelope-verschlüsselt sind; und ein Acht-Punkte-Härtungspaket mit Aufrufer-Autorisierung vor Entschlüsselung, fail-closed-Berechtigungs-Parsing, Warnungen bei reinem ws://, sicheren QR-Bildschirmen, Log-Redaktion, lazy Key-Zeroing beim Abmelden und optionalem Keystore-Einsatz bei entsperrtem Gerät.

Version 6.5.1 verschlüsselt gespeicherte NIP-46-Geheimnisse neu, wenn sich der Keystore-Schlüssel nach dem Umschalten der Entsperr-Pflicht dreht, und behebt einen Absturz im Berechtigungseditor. Version 6.5.2 entschlüsselt keine Spalten mehr, die die Anwendungsliste nie rendert, cached den Keystore-Handle, wärmt den Account-Cache beim Start vor und debounced Relay-Status-Benachrichtigungen.

Letzte Woche brachte 6.4.0 explizite gruppierte Signierentscheidungen; 6.5.x ändert, was Amber überhaupt noch autorisieren wird.

Cambium 0.4.0 signiert für Websites und entlastet Relay-Auth-Bursts

Cambium ist ein Android-NIP-55-Proxy zu einem Heartwood-Hardware-Signer über NIP-46. Sechs Releases erschienen an zwei Tagen.

Version 0.4.0 erweitert das Signieren auf Websites. Eine Seite kann über einen validierten nostrsigner:-Callback eine Signatur anfordern, ohne die nativen Anwendungen gewährten Berechtigungen zu erben — ein Browser-Tab kann so nicht die Freigabe einer anderen App ausleihen. Dasselbe Release korrigiert die minimale Event-Form der Spezifikation: Ein Event mit nur kind und content signiert nun korrekt; Cambium ergänzt die gepaarte NIP-46-Identität, den aktuellen Zeitstempel und ein leeres Tag-Array, bevor es das Event an rust-nostr übergibt. Native rust-nostr-Instrumentierung wurde in derselben Änderung zum Pflicht-CI-Gate.

Version 0.3.6 repariert Pairing gegen spezifikationstreue Signer. Cambiums älterer rust-nostr-Build akzeptierte als Ergebnis eines NIP-46-connect-Aufrufs nur die Literalzeichenkette ack. Ein Signer, der durch Zurückgeben des Geheimnisses aus der Bunker-URI antwortet — wie die aktuelle Spezifikation verlangt und Heartwoods Firmware tut — scheiterte mit einem Unexpected-Response-Fehler. Der Sprung von rust-nostr 0.44.2 auf 0.44.8 akzeptiert beide Formen, verifiziert gegen Live-Hardware und gegen nak bunker, das weiterhin ack antwortet.

Die Releases 0.4.1 bis 0.4.3 betreffen Zulassungskontrolle unter Last. Version 0.4.1 reserviert Reaktionen, Posts, Löschungen und Verschlüsselung einen Warteschlangenplatz vor Relay-Authentifizierung und Hintergrund-Entschlüsselung, begrenzt wartende Aufrufe, verwirft sie nach Caller-Timeout und liefert bei Überlast ein terminales Unavailable-Ergebnis statt einen Vordergrund-Signierbildschirm zu öffnen. Version 0.4.2 verwirft abgelaufene oder lange untätige NIP-46-Sitzungen vor dem nächsten Request und lässt parallele Kopien desselben Kind-22242-Authentifizierungs-Events eine Hardware-Signatur teilen. Version 0.4.3 lässt höchstens eine unterschiedliche Authentifizierungs-Challenge pro Identität in den Hardware-Worker, wiederholt Authentifizierung intern nie und öffnet nach Timeout eine sechzigsekündige Cooldown-Phase pro Identität, während exakte Cache-Duplikate weiter beantwortet werden. Die Messwerte in den Release Notes stammen von einem GrapheneOS-Telefon mit Amethyst: Ein Cold-Start-Burst lieferte dreiunddreißig sofortige Overload-Antworten und dreizehn abgeschlossene Requests ohne Signer-Timeouts; ein frischer Login während eines Auth-Bursts kehrte 1,254 Sekunden nach Freigabe zurück.

Citrine 3.1.0 macht aus einem Smartphone-Relay einen Gruppen- und Site-Host

Citrine ist ein Android-Relay auf dem Gerät. Version 3.1.0 fügt drei Fähigkeiten hinzu, die ändern, was das Relay hosten kann.

Unterstützung für NIP-29 (relay-verwaltete Gruppen), die relay-basierte Gruppenspezifikation, bei der das Relay selbst Mitgliedschaft und Moderationszustand hält, bedeutet, dass ein Telefon eine Gruppe hosten kann, statt einer beizutreten. Unterstützung für NIP-86 (Relay-Verwaltungs-API), die Relay-Management-API, die administrative Aktionen über authentifiziertes JSON-RPC exponiert, kommt mit einem Einstellungsbildschirm — Allowlists und Bans lassen sich nun über die API wie aus der App steuern. Unterstützung für NIP-5A statische Websites lässt das Relay nsites an Web-Clients ausliefern; eine modernisierte Browse-Liste trägt Icons, Suche, Sortierung nach letztem Update, Installationsfortschritt, Beschreibungen und ein konfigurierbares Relay-Set zum Abruf, standardmäßig nsite.run, nos.lol und nostr.land.

Die Moderationsoberfläche wuchs im selben Release mit. Lokales Sperren eines Public Keys bietet nun an, gespeicherte Events dieses Autors zu löschen; eine konfigurierbare REJECTED_KINDS-Liste blockiert unerwünschte Kind-Nummern; Access Control kann bestehende Listen importieren. Ein Rebroadcast-Tool schiebt gespeicherte Events zurück auf ausgewählte Relays — ein telefonisch gehaltenes Archiv kann so das Netzwerk neu besamen. Das Release entfernt außerdem die WebSocket-Erweiterung permessage-deflate, strafft den Query-Hot-Path, behebt Tor-Start-/Stop-Fehler beim Umschalten der Tor-Exposition und verschiebt Logs in eine lokale Datenbank, wobei logcat auf Debug-Builds beschränkt bleibt.

Vector 0.4.2 lässt Community-Moderation eine Spam-Welle überstehen

Vector ist ein Desktop- und Android-Concord-Messenger. Version 0.4.2 fokussiert Moderation unter Last.

Schnelle Bans überschrieben sich früher gegenseitig. Sie werden nun in die Warteschlange gestellt, gestapelt und als eine Operation abgeschlossen — eine Welle von Accounts zu sperren kostet eine Key-Rotation statt eine pro Account. Eine Einladung in eine inzwischen aufgelöste Community erklärt nun den Grund und entfernt die Einladung auf jedem Gerät des Nutzers; das Auflösen einer eigenen Community räumt sie überall aus der Community-Liste — ein Fix, der in Version 0.4.3 landete. Community-Nachrichten während eines Hintergrund-Catch-ups lösen keine Benachrichtigungen mehr aus, als wären sie gerade eingetroffen; der Tipp-Indikator verfällt ab dem Sendezeitpunkt, sodass ein verzögertes Signal nicht im Kanal hängen bleibt.

Die von Concord definierte shardierte Community-Liste durchlief einen Review-Pass mit Armada, dem anderen Concord-Client. Umbenennungen blähen die Liste nicht mehr auf, Gleichstände lösen sich auf beiden Clients identisch auf, und unveränderte Daten werden nicht mehr an Relays republiziert. Stummschaltung verließ den DM-Pfad: Nutzer können jemanden direkt aus einer Community stummschalten, ohne vorherige Nachrichtenhistorie; die Stummschaltung gilt für Benachrichtigungen und Badges über Kanäle und DMs hinweg, lässt die Nachrichten selbst sichtbar. Angepinnte Nachrichten wurden zu einer geteilten Kanaloberfläche mit klickbaren Links; Bearbeitungen an einer Pin folgen ihr überall. Blocklisten, Stummschaltungen und Spitznamen synchronisieren sich geräteübergreifend, ebenso angepinnte Chats. Version 0.4.3 meldet außerdem nicht mehr, dass der Nutzer tippt, wenn ein anderer Nostr-Client unter derselben Identität angemeldet ist, und entblockiert Tor-Bootstrap unter Windows, das auf x64 und ARM64 bei fünfzehn Prozent eingefroren war.

Sonar bringt verschachtelte Antworten in einen Mesh-Messenger mit NIP-C7

Sonar ist ein Bluetooth-Mesh- und Nostr-Messenger. Version 0.1-alpha.13.1 fügt Signal-artige Antworten in NIP-C7-Kind-9-Chat hinzu, plus Erwähnungen, begrenzte Bluetooth-Reassembly, Backup-Obergrenzen, Mesh-Pfad-Signaturprüfung und FCM-Push-Fallback. Versionen 0.1-alpha.13.2 und 0.1-alpha.13.3 beheben Chat-Open-Abstürze und iOS-Tastatur-Overlap.

Nostria veröffentlicht Podcasts und fragt Relays nach Zählungen

Nostria ist ein Web-Client. Version 4.1.70 und 4.1.71 fügen Podcast-Veröffentlichung für Premium-Abonnenten hinzu, Episoden als signierte Nostr-Events. Version 4.1.69 nutzt NIP-45 COUNT (Relay-Zähl-Anfragen) für Reaktions-, Antwort- und Zap-Summen in Feeds und schließt die Lokalisierung ab. Letzte Woche erweiterte 4.1.67 verschlüsselte Community-Administration.

Releases

MDK 0.9.14: fail-closed Gruppenhistorie durch schnellere Gruppenerstellung

MDK ist das Rust-Entwicklungskit für Marmot, ein verschlüsseltes Gruppen-Messaging-Protokoll über Nostr. Version 0.9.12 macht mehrere Gruppenzustands-Pfade fail-closed statt ratend. Ein fehlender Fork-Anker ist nun ein harter Fehler (PR #1329); ein Leave-Vorschlag wird atomar persistiert, damit ein Absturz keinen halb angewendeten Austritt hinterlässt (PR #1360); Incident-Replay rät bei manifestlosen newline-delimited JSON-Streams kein Format mehr (PR #1140). Konvergenztests weiteten sich parallel aus: retained-history Cross-Route-Recovery (PR #1350), Cross-Adapter-Konvergenz-Assurance (PR #1372) und generalisierte isolierte Konvergenz-Kampagnen (PR #1357). Relay-Ablehnungsdiagnostik bleibt erhalten statt in einen generischen Fehler zu kollabieren (PR #1361).

Version 0.9.13 landete am 18. August mit Storage-Format v2 (PR #1421), Migrations-Schienen und Delta-Writes statt Live-Account-Snapshots (PR #1435), plus schnellerem Invite-Catch-up (PR #1444) und macOS-Bindings (PR #1402). Version 0.9.14 folgte am 19. August mit Gruppenerstellungs-Polish: vorab hochgeladene Gründungsbilder (PR #1498), KeyPackage-Batching (PR #1494), atomare Anfangsnachrichten-Retention (PR #1497) und Profil-Publikation mit account-eigenen Relays (PR #1495). MarmotKit 0.9.14 und wn-agent 0.9.14 shippen mit dem Core-Crate.

Divine Mobile 1.0.20: Badge prägen, ohne die App zu verlassen

Divine Mobile ist ein Kurzvideo-Client, der Video über Nostr veröffentlicht und abruft. Version 1.0.20 lässt Nutzer ein NIP-58-Badge (signierte Auszeichnungs-Events) prägen und jemandem übergeben, ohne die App zu verlassen. Ein Tipp auf ein Badge im Profil erklärt, was zum Verdienen nötig war — der Teil der Spezifikation, der oft unimplementiert bleibt, weil Definitions- und Award-Event getrennt gespeichert werden.

Der Rest des Releases ist Client-Arbeit: helles Theme, Crop/Rotate/Flip im Stop-Motion-Editor, Entwürfe einen Tipp vom Recorder entfernt, Caption-Timing zum Video, ein Feed, der bereits Gesehenes depriorisiert, Screenreader-Unterstützung in Editor, Recorder und Profil-Tabs, Reduced-Motion-Handling und Kontoeinstellungen für Divine-E-Mail/Passwort sowie Verknüpfen/Trennen von Accounts. Gelöschte Videos verlassen lokalen Zustand; Lesezeichen bleiben erhalten. Letzte Woche härtete 1.0.19 Account-Isolation und DM-Validierung ab; Badge-Ausgabe ist eine neue Publishing-Oberfläche darüber.

ClipRelay 0.2.0: Signer per Kamera koppeln

ClipRelay synchronisiert eine Zwischenablage geräteübergreifend über Nostr. Android-Version 0.2.0 fügt nostrconnect://-QR-Login hinzu — Anmeldung mit einer Signer-App auf einem anderen Telefon — und Kamera-Scanning von Bunker-URLs, sodass kein geheimnis-tragender String mehr durch einen Messenger eingefügt werden muss. Bunker-Verbindungen laufen nach sechzig Sekunden ab statt zu hängen; der Retry-Button nach fehlgeschlagenem Amber-Login funktioniert. Desktop-Version 0.2.0 übernimmt Timeout und Login-Tab-Fixes.

Version 0.1.4 ergänzte sensitive-Zwischenablage-Sync mit kurzer Relay-Ablaufzeit, feste Signer-Session-Relays und einen Liveness-Probe mit echtem Roundtrip statt lokal synthetisiertem EOSE. Letzte Woche stellte 0.1.3 Verbindungen nach Leerlauf wieder her.

Bark 1.3.9: Browser-Signer, der auf Android läuft

Bark ist eine Browser-Erweiterung mit der NIP-07-window.nostr-Schnittstelle (Webseiten-Signer), die Webseiten zum Signieren oder Verschlüsseln aufrufen. Version 1.3.9 deklariert Android-Unterstützung für den Firefox-Build, sodass die Add-ons-Liste auf dem Telefon installiert. Firefox auf Android implementiert keine Windows-API; jede Freigabe, die ein Popup öffnete, wäre pauschal abgelehnt worden. Die Freigabeoberfläche fällt nun auf einen Vordergrund-Tab zurück: Schließen lehnt ab, Review bringt ihn nach vorn, der Hintergrund schließt nach Abschluss. Die Release Notes dokumentieren Verifikation auf einem Pixel 10 Pro XL mit GrapheneOS und Firefox 153.0.4 und stellen klar, dass Chromium auf Android das Extension-Subsystem herauskompiliert — kein Chromium-abgeleiteter Android-Browser kann Bark ausführen.

Version 1.3.8 behebt einen NIP-46-Interop-Defekt in die andere Richtung. Bark prüfte ein kompaktes Heartwood-Signier-Dialekt, indem es das Event als JSON-Objekt sendete — strikt typisierte Signer einschließlich nak und rust-nostr-Bunker können das nicht parsen und verwerfen es still, Signieren hing. Die Probe geht nun nur an Signer, die sich als Heartwood identifizierten; alle anderen erhalten ab der ersten Signatur einen standardmäßigen sign_event-Aufruf.

Bray 3.0.0 und Toll Booth 6.0.0 wechseln auf eine gemeinsame Wallet-Connect-Bibliothek

Bray und Toll Booth zahlen beide über NIP-47 Nostr Wallet Connect, die Spezifikation für Zahlungsanfragen an Wallets über verschlüsselte Nostr-Events. Bray 3.0.0 und Toll Booth 6.0.0 deklarieren jeweils einen Breaking Change zur Übernahme von nwc-kit; Toll Booth entfernt im selben Schritt seinen Payer-Credential-Flow. Beide veröffentlichen reproduzierbare Builds, deren Output auf zwei unabhängigen Runnern byte-identisch war; der Tarball-Hash steht in den Release Notes zur Verifikation des Registry-Artefakts.

Drei Toll-Booth-Patches folgten: 6.0.1 pinnt den ausgehandelten Deploy-Host-Key, 6.1.1 pinnt cashu-ts auf die Zielversion seines Patches, 6.1.2 stellt einen Image-Build wieder her.

NoorNote ist ein Nostr-Client für Desktop, Web und Android. Version 1.3.4 fügt verschlüsselte Armada- und Concord-Communities als Addon hinzu: Beitritt per Einladungslink, joined Communities in den Einstellungen und Aktivitätsbenachrichtigungen. Dasselbe Release ergänzt eine Steuerung zum Ausblenden externer Quote-Posts — Highlights, die einen Webartikel-Absatz zitieren — global oder pro Autor, Reposts davon ebenfalls versteckt, eigene Highlights sichtbar gelassen. Profilauflösung wurde repariert; Profile rendern nicht mehr als abgeschnittener Public Key oder anonymer Platzhalter.

Version 1.3.5 fügt einen Expander für lange Notes hinzu und korrigiert das Layout des Armada-Einladungslink-Eingabefelds. Letzte Woche verlagerte 1.3.2 Artikel-Discovery in den Social Graph; Community-Mitgliedschaft ist eine separate Oberfläche.

Mostro verlagert Dispute-Chat weg vom Gift Wrap

Mostro ist ein Peer-to-Peer-Trading-Daemon, dessen Orders und Nachrichten als Nostr-Events laufen, mit mostro-core als gemeinsamer Bibliothek und Mostro Mobile als Client. Mobile 1.3.2 migriert Dispute-Chat von NIP-59 Gift Wrap (Metadaten-verbergende Hüllen) zu einem Kind-14-Chat-Envelope und sichert das Backlog mit dauerhaften pro-Konversation-Cursorn ab. mostro-core 0.14.5 serialisiert die Rumor-Kennung im Gift Wrap (PR #164); 0.14.4 behebt einen Ratings-Durchschnittsbug (PR #163); Mobile 1.3.1 wechselt zu Blossom-Servern, die verschlüsselte Chat-Anhänge behalten. Daemon 0.18.2 oder 0.18.4 verwenden.

NYM 3.73.522: verschlüsselte Gruppenchats und verschlüsselter lokaler Speicher

NYM ist ein Nostr-Client mit eigener Assistant-Integration. Version 3.73.522 verschlüsselt den lokalen SQLite-Speicher, nachdem 3.73.521 verschlüsselten Gruppenchat verfeinerte und 3.73.520 einen Content-Security-Policy-Bruch und doppelte Neue-Nachrichten-Darstellung behebt.

Morganite 0.0.4: Blob vor dem Cachen verifizieren

Morganite ist ein Android-Blossom-Server, das Medienprotokoll, bei dem eine Datei über den SHA-256-Hash ihres Inhalts adressiert und von jedem Host ausgeliefert wird, der sie hält. Version 0.0.4 prüft den Blob-Hash beim Download in einem Durchgang vor dem Cachen — die Prüfung, die Content Addressing auf der Empfangsseite bedeutungsvoll macht. Das Release trackt Cache-Größe inkrementell statt das Verzeichnis bei jedem Save neu zu scannen, verschiebt blockierende Netzwerkaufrufe auf IO-Threads, reused Tika-Instanzen für MIME-Erkennung und persistiert Logs in einer lokalen Datenbank.

Neu entdeckt

Nail bringt E-Mail als Gift-Wrap-Events auf Nostr

Nail ist eine MIT-lizenzierte Mail-Bridge und Web-Client vom Formstr-Team, der Gruppe hinter Formstr und nostr-calendar. Launch am 18. August mit PR #7, einer 22-Datei-Änderung mit k-Tags auf Mail-Events, Key-Recovery in den Einstellungen und einer Willkommensnachricht. Das Deployment läuft unter mailstr.app, das den eigenen _smtp-NIP-05-Eintrag (DNS-Namen zu Public Key) der Bridge bedient.

Die Mail selbst ist ein Nostr-Event. Die Constants des Clients definieren ein Kind-1301-Mail-Rumor in einem Kind-1059-NIP-59-Gift-Wrap — Nachrichten erreichen Empfänger über dieselbe metadaten-verbergende Hülle wie private DMs. Zustell-Relays kommen aus einer Kind-10050-NIP-17-Inbox-Liste (Private DMs) mit Kind-10002-NIP-65-Relay-Liste dahinter; Ordner sind Kind-1985-NIP-32-Labels (Label-Events) unter dem mail-Namespace; Client-Einstellungen leben in einem Kind-30078-NIP-78-Application-Data-Event. Anhänge über 60.000 Bytes gehen auf Blossom statt ins Event, weil NIP-44 (Verschlüsselung) verschlüsselten Klartext auf 65.535 Bytes begrenzt. Eine Adresse ist ein npub an einer Domain; eine lokale Domain ohne NIP-05-Eintrag gilt als nicht existierendes Postfach.

Die Bridge-Hälfte ist ein Node-LMTP-Server neben einer mailcow-Installation ohne Patch: Postfix leitet passende Domains an die Bridge, die Bridge injiziert Antworten zurück über SMTP. Das zwingt zu einer ehrlichen Antwort auf die härteste Frage einer E-Mail-Bridge: Was beweist ein From-Header? Nails Receive-Pfad stuft jede Nachricht in einen von vier Provenienz-Zuständen ein: die konfigurierte Bridge versiegelte sie und lehnt unverifizierte Absender upstream ab; der Nutzer versiegelte selbst; der NIP-05-Eintrag der Adresse löst auf den versiegelnden Key auf; oder nichts bestätigt den Header. Im letzten Fall fällt die Oberfläche auf den versiegelnden Public Key zurück — die einzige Identität, die das Event tatsächlich beweisen kann. Bridge-API-Aufrufe authentifizieren sich mit NIP-98-signierten HTTP-Events (HTTP-Authentifizierung über signierte Events).

Glow speichert Wallet-Labels unter passkey-abgeleiteter Identität auf Relays

Glow ist eine Breez-Self-Custody-Lightning-Wallet. Passkey-Login leitet eine Nostr-Identität ab; Wallet-Labels werden unter dieser Identität von Relays geladen und gespeichert, byte-identische Duplikate kollabieren über partielle Relay-Abdeckung hinweg.

In Entwicklung

Amethyst baut den Relay-Auth-Entscheidungsfluss neu

Amethyst ist ein Android-Nostr-Client. Ein Block gemergter Arbeit formt um, wie NIP-42-Client-zu-Relay-Authentifizierung gehandhabt wird. Berechtigungsoberfläche und Entscheidungsfluss wurden neu gestaltet (PR #3899); Authentifizierung wartet auf Challenge-Auflösung statt zu timeouten (PR #3905); neue Accounts authentifizieren standardmäßig immer mit Relays (PR #3931); eine „immer anmelden“-Wahl gilt auch für Relays, die der Account selbst nicht nutzt (PR #3937). Authentifizierung erkennt außerdem NIP-29-Gruppen und Concord-Communities als beigetretene Venues (PR #3906) — damit wirkt eine relay-gehostete Gruppe nicht bei jedem Öffnen wie ein fremdes Relay.

Zwei weitere Änderungen berühren Protokolloberflächen. Proof-of-Work-Mining unter NIP-13 (PoW-Nonce) aktualisiert created_at während des Minings und erhält GPU-Pfad-Analyse (PR #3911); Vollbild-Napplet-Hosts handhaben Input-Method-Insets (PR #3932). Ein geführtes Erststart-Key-Backup mit Einstieg in den Settings merged ebenfalls (PR #3909), neben Stummschaltung öffentlicher Chats (PR #3939).

nostrord implementiert einen ungemergten Verschlüsselungsschlüssel-Vorschlag

nostrord ist ein Nostr-Chat-Client um relay-scoped Gruppen. Er merged eine Implementierung von NIP-4e, einem ungemergten Vorschlag zur Entkopplung der Nachrichtenverschlüsselung vom Identitätsschlüssel, den Compass zuletzt in der Ausgabe vom 15. Juli beschrieb. Der Account kündigt einen eigenen Kind-10044-Verschlüsselungsschlüssel an, hält die private Hälfte lokal und entschlüsselt eingehende DMs im Prozess — Bunker oder Browser-Erweiterung fallen aus dem Lese-Pfad (PR #261). Geräte-Pairing über Kind 4454 und 4455 verschiebt den Schlüssel auf ein zweites Gerät; ein Self-Archive republiziert Historie an den neuen Key. Senden adressierte zuerst den angekündigten Key (PR #247); ein Follow-up behebt Pairing, das erfolgreich verhandelte, ohne den Schlüssel zu übergeben (PR #271). Der Pull Request stellt fest, dass das Wire-Format der deployed Jumble-Implementierung folgt, wo es vom offenen Vorschlag abweicht — die Arbeitsdefinition der Spezifikation liegt in shipped Code statt im Dokument.

Gruppenidentität wurde im selben Batch gestrafft. Eine Gruppenkennung ist nun nur innerhalb ihres Relays eindeutig (PR #269); dieselbe Kennung auf zwei Relays gilt als zwei Gruppen (PR #272); Thread-Posts rendern als Forum-Posts (PR #274). Verbindungs-Churn mit wiederholten Kind-22242-Signieraufforderungen wurde gestoppt (PR #268) — dieselbe Signer-Last-Klasse, an der Cambium diese Woche drei Releases arbeitete.

nostream ergänzt Relay-Monitor und prägt Invite-Codes

nostream ist eine TypeScript-Relay-Implementierung. Es merged einen Cluster-Worker und Probe-Scheduler, die NIP-66-Relay-Monitoring-Events (Discovery-Spezifikation für Relay-Liveness) veröffentlichen (PR #724), mit Settings-Schema und Defaults (PR #689) und Integrationstests (PR #733). Ein CLI-Tool prägt nun NIP-43-Invite-Codes (Relay-Zugangs-Metadaten) (PR #732); das Relay annonciert endlich NIP-13-Proof-of-Work in seiner Supported-Liste (PR #680), obwohl es PoW schon implementiert hatte. Data-Vending-Machine-Jobs erhielten Migrations- und Repository-Persistenz (PR #727); das Relay fängt NIP-90-DVM-Job-Requests ab und zeichnet sie über das Job-Repository auf (PR #729).

rust-nostr behebt Gift-Wrap-Kennung und lehnt geschützte Reposts ab

rust-nostr ist die Rust-Bibliothek und das SDK hinter einem großen Teil der Rust- und Mobile-Client-Arbeit dieser Ausgabe. Es stellt sicher, dass die Rumor-Kennung vor Versiegelung des Gift Wraps berechnet wird (PR #1444) — dieselbe Defektklasse, die Mostro diese Woche in der eigenen Bibliothek schloss. Das lokale Relay lehnt einen Repost eines NIP-70-geschützten Events ab (PR #1445) — der Schutz, für den die Spezifikation existiert; NIP-47-Response-Parsing toleriert fehlende und null Beträge (PR #1450) statt bei Wallets ohne Angabe zu scheitern. Relay-URL-Parsing wurde gehärtet (PR #1451).

NDK ergänzt Post-Quantum-DMs und entfernt GPL-Abhängigkeit

NDK ist ein Dart-Entwicklungskit für Nostr. Es merged hybride Post-Quantum-Verschlüsselung für DMs mit ML-KEM-1024, dem als FIPS 203 standardisierten Lattice-KEM (PR #713), neben der klassischen Key-Agreement-Schicht statt an deren Stelle. Eine separate Änderung ersetzte eine GPL-3.0-only-Dilithium-Implementierung durch fips204, den ML-DSA-Signaturstandard (PR #712) — Lizenzbeschränkung für einbettende Apps entfällt. Verbindungen nutzen je eine Identität (PR #710).

Nostter ergänzt Lesezeichenlisten, Profil-Badges und Blossom-Uploads

Nostter ist ein Web-Client. Es merged Unterstützung für standard- und Legacy-Formen von NIP-51-Lesezeichenlisten (PR #2311), aktualisierte NIP-58-Profil-Badge-Behandlung (PR #2281), einen Blossom-Media-Uploader (PR #2298) und zeigt einen NIP-05-Bezeichner (DNS-Verifizierungsname) in der Mention-Autocomplete (PR #2303).

Zap Cooking bindet Admin-Routen an signierte Requests und verschlüsselt gespeicherte Wallet-Verbindungen

Zap Cooking ist eine Rezeptseite auf Nostr-Langform-Events. Ein Sicherheitsbatch verschlüsselt gespeicherte Nostr-Wallet-Connect-Verbindungsstrings ruhend in einer NIP-44-Hülle (PR #622), ersetzt einen spoofbaren Public-Key-Vergleich auf Admin-Routen durch NIP-98-HTTP-Authentifizierung (PR #626) und löscht Kontodaten beim Logout bei begrenzten pending NIP-46-Records (PR #627).

Protokoll- und Spezifikationsarbeit

NIPs

Kein Pull Request merged in nostr-protocol/nips in diesem Fenster. Sechs Vorschläge öffneten nach Schließen der vorherigen Ausgabe, drei davon am 18. August, nachdem der Entwurf erstmals zirkulierte.

NIPs PR #2438 schlägt NIP-9A vor, kommentarbasiertes Patchen. Ein Patch ist ein Kind-1111-Kommentar, der das gepatchte Event als Parent referenziert und dessen content mit dem Literal-Label PATCH beginnt, gefolgt von Patch-Zeilen. Eine Zeile mit führender Zahl editiert den content des Ziels als <index> -<deleted> +<inserted> <eingefügte Zeichen>, gezählt in Unicode-Zeichen statt Bytes; eine Zeile mit führendem t ersetzt ein menschenlesbares Tag wie title, description, subject oder picture. Das Design ist bewusst rückwärtskompatibel: ein Client ohne Formatverständnis zeigt den Patch als gewöhnlichen gelabelten Kommentar; ein verstehender Client wendet an und blendet den Kommentar aus. Der Vorschlag nennt Kind 1, 11, 1111, 24 und 1621 als patchbar und bittet Schreiber und Leser, zu große, zu zahlreiche oder lange nach dem Original veröffentlichte Patches abzulehnen — expliziter Versuch, die Funktion nicht zum allgemeinen Bearbeitungskanal für unveränderliche Events zu machen.

NIPs PR #2437 schlägt Dateiverschlüsselung für NIP-94 vor, die Dateimetadaten-Spezifikation für ein hochgeladenes File in einem Kind-1063-Event. Drei optionale Tags kommen hinzu: encryption-algorithm mit aes-gcm als einzigem gelisteten Wert plus hex-codierter decryption-key und decryption-nonce. Tag-Semantik verschiebt sich entsprechend: m beschreibt den MIME-Typ vor Verschlüsselung, x hält den Hash der verschlüsselten Datei, ox den des Originals; thumb, image und fallback werden unter demselben Key und Nonce verschlüsselt. Zweck: ein öffentlicher Blossom-Betreiber, der die Bytes hostet, kann nicht erkennen, was sie sind; der Autor rahmt es als Übernahme der NIP-17-DM-Verschlüsselungseigenschaften in Dateimetadaten, damit dasselbe in einem imeta-Tag funktioniert.

NIPs PR #2436 ändert NIP-7D, die Forum-Thread-Spezifikation auf Kind-11-Thread-Events mit NIP-22-Kind-1111-Kommentaren als Antworten. Ein Format-Abschnitt erlaubt Thread-Posts wie Kind-1-Notes mit Inline-Bildern, Links und NIP-27-Referenzen (Textreferenzen) und optional Djot, einer leichten Markup-Sprache mit eindeutiger Grammatik. Argument: unspezifiziertes Format lädt zu späterem Markdown-by-default ein; der PR verweist auf squalk als existierende Djot-Implementierung.

NIPs PR #2439 fügt assign- und unassign-Methoden zu NIP-86 (Relay-Verwaltungsbefehle) hinzu, damit ein Relay-Administrator Admin-Rechte an einen anderen Pubkey vergeben kann, ohne den Master-Key zu teilen.

NIPs PR #2442 folgt dem Audio-Track-Vorschlag, den Compass im Januar behandelte, während der Entwurf offen blieb; der frühere Pull Request ist inzwischen geschlossen, dieser shippt in Produktion bei lightning.fm als Kind-31337-Track-Events, mit Kind-31339-Release-Objekten, Band-Profilen, Track-Contributors und optionalen NIP-57-Zap-Splits bei Verkäufen über NIP-99. Der Interop-Vertrag steht unter lightning.fm/interop; Desktop-Publisher und self-hosted Seller-Daemon sind Open Source.

Marmot

Marmot PR #416 merged am 13. August und ergänzt einen Durability- und Restart-Vertrag im Protokoll-Core. Die adoptierten Dokumente definierten bereits deterministische Konvergenz, retained candidate-parent material, publish-before-apply-Reihenfolge und fail-closed-Verhalten bei fehlender Historie — ohne eine unmissverständliche Regel für Prozessunterbrechung an den Nahtstellen. Die Änderung definiert recoverable logical facts, Restart-Äquivalenz, Publish- und Konvergenz-Unterbrechungsgrenzen, observer-atomare Übergänge, Umgang mit fehlendem oder korruptem Material und Application-Effect-Recovery; Crash- und Restart-Konformitätsszenarien folgen für jeden Punkt. Transaktionen, Journale, Snapshots, Replay-Strategie, Scheduler und Storage-Formate bleiben implementierungsdefiniert; kein Wire-Encoding-Change nötig. Der spezifische ausgeschlossene Fehler: extern akzeptierte, lokal unbestätigte Publikation oder teilweise angewandter selected branch mit implementierungsabhängigen Protokollergebnissen nach Neustart.

Concord und CORDs

Concord PR #18, letzte Woche als offener Vorschlag behandelt, merged am 15. August. Er shardet die verschlüsselte Community-Liste über Kind-33302-Events, entfernt das Fünfzig-Mitgliedschafts-Limit und entfernt ausgemusterte Einträge, damit die Liste in Relay-Größenlimits bleibt. Vectors Release Notes dieser Woche dokumentieren die Client-Hälfte inklusive Tie-Resolution und der Entscheidung, unveränderte Daten nicht mehr zu republizieren.

Concord PR #22 schlägt community-eigene Audio- und Video-Broker vor. Die CORD-02-Metadaten-Entität trüge neben Relays eine optionale av_brokers-Liste, editioniert wie der Rest; CORD-07-Rendezvous zöge aus dieser Liste oder vom Broker des Members, wenn die Community keine veröffentlicht, sortiert nach dem bestehenden room-keyed Tie-Break. Der Broker-Tag in Presence bleibt lesbar für Residual-Split-Reporting; das Argument für seine Demotion vom Routing: Routing darauf lässt untrusted Input eines Members die community-eigene Anweisung überstimmen.

Concord PR #23 macht bestehendes Implementierungsverhalten in CORD-05 normativ. Vor Persistieren eines Joins muss die Genesis-Metadaten-Edition des Owners unter den gelieferten Keys öffnen, rotierte Ebenen am Compaction-Pair verankern. Der PR stellt klar, dass das nie eine Live-Schwachstelle war: Vectors Bundle-Acceptance lehnt Bundles ab, deren gelieferte Root die Owner-Genesis nicht öffnet, und parkt keine Einladung für eine bereits gehaltene Community; Armada verwirft Bundles, die die Base einer gehaltenen Community verschieben würden. Die Lücke war fehlende Spezifikationspflicht — ein spezifikationstreuer Client hätte die verwundbare Version shippen können.

Blossom-Upgrade-Dokumente, Napplet-Anwendungsvorschläge und die Gamma-Markets-Spezifikation verzeichneten in diesem Fenster keine Änderungen.

NIP Deep Dive

Badges (NIP-58)

NIP-58, definiert in der primären Spezifikation, gibt einer Nostr-Identität einen Weg, einer anderen einen benannten Token zu verleihen, und dem Empfänger Kontrolle, ob er im Profil erscheint. Das Problem: Jede Aussage über eine Person auf Nostr wäre sonst nur eine Note — keine Struktur, die sagt, wer eine Behauptung ausstellte, wie sie heißt, wie sie aussieht oder ob das Subjekt zustimmte. Badges kodieren diese Behauptung in drei getrennten signierten Events mit drei getrennten Autorenintentionen.

Die Mechanik baut auf adressierbarer Definition, Award und Anzeigeliste. Eine Badge-Definition ist ein Kind-30009-Event des Issuers, adressierbar über sein d-Tag — der Issuer kann name, description, image und thumb später revidieren, ohne die Kennung zu ändern, auf die andere zeigen. Der Award ist ein Kind-8-Event desselben Issuers mit einem a-Tag für die 30009:<issuer-pubkey>:<d-identifier>-Koordinate und einem oder mehreren p-Tags für Empfänger. Die Anzeigeliste ist ein Kind-30008-Event des Empfängers mit festem d-Wert profile_badges, das a- und e-Tag-Paare listet: a ist die Definitionskoordinate, e das konkrete Award-Event. Die Paare sind geordnet und werden als Paare gelesen: fehlendes Award zu einem a oder fehlende Definition zu einem e wird ignoriert — ein halb referenziertes Badge rendert still nicht.

Die Design-Tradeoffs zeigen sich in dem, was die Spezifikation verweigert. Kein Revocation, kein Ablauf — ein Award ist eine permanente Issuer-Aussage über einen Moment; ein Issuer, der es bereut, kann nur die Definition ändern, auf die der Award zeigt. Kein Transfer — ein Badge zirkuliert nicht als Token. Kein Trusted-Issuer-Register — die Vertrauensfrage liegt ganz bei Client und Leser: ein Badge ist so viel wert wie der Public Key des Issuers dem Betrachter. Clients dürfen weniger Badges anzeigen als der Empfänger listete und Bildgröße wählen — damit Profile nicht zu Grafikwänden Dritter werden.

Die nächste Spezifikation ist NIP-51, die Listen-Spezifikation; der Vergleich zeigt, warum Badges drei Events brauchen statt eines. Eine Liste ist ein Autor, der Referenzen kuratiert; Listenautor ist Behauptungsautor. Ein Badge teilt Autorschaft: Issuer signiert, dass der Award geschah; Empfänger signiert, dass er die Anzeige akzeptiert. Keine Partei allein erzeugt das sichtbare Ergebnis — das trennt Badge von selbst gesetztem Label.

Ein live Kind-8-Award von nos.lol und relay.primal.net diese Woche:

{
  "id": "08504dec368939bd63849a349cab83dea0ac199a852129dbf68cf35fe5c64e96",
  "pubkey": "bef514bd58c8ceea4beb9e6b84a8d983935f7be26f49e14df68098f1ba64156e",
  "created_at": 1787051248,
  "kind": 8,
  "tags": [
    ["a", "30009:bef514bd58c8ceea4beb9e6b84a8d983935f7be26f49e14df68098f1ba64156e:blocks_orange_league"],
    ["p", "92dfa05d915196a7a09152fa3f57871debfd422e1d278ac5af266a70c3350b1f", "wss://relay.damus.io"]
  ],
  "content": "Badge awarded!",
  "sig": "5bf0218dfec5e56b47339b0b4b992cceedd2e18798fb3d47cafea51850c00827f66251e4a3e08190370e04a5e1d4d092eeb441141b7219acdd18b80290a022f8"
}

Aktuelle Implementierungen decken Ausgabe, Anzeige und Lesen ab. Divine Mobile 1.0.20 prägt und verleiht ein Badge in der App und erklärt ein verdientes Badge beim Tippen; Nostter PR #2281 aktualisiert Profil-Badge-Handling im Web-Client; Amethyst veröffentlicht Award-Events mit eigenem Client-Tag — eines erscheint in Relay-Daten neben dem Beispiel oben.

Comments (NIP-22)

NIP-22, definiert in der primären Spezifikation, liefert ein allgemeines Kommentar-Event zum Antworten auf Dinge, die keine Kurztext-Notes sind. Kurznoten-Threading hatte NIP-10 (Reply-Tag-Konventionen), dessen Tag-Konventionen um Kind 1 und Reply-Ketten wuchsen. NIP-22 existiert, weil Video, Artikel, Kalenderereignis, Wiki-Seite oder URL eine Antwortstruktur brauchen, die identifiziert, welche Art von Objekt beantwortet wird — auch wenn das Ziel adressierbar ist oder gar kein Nostr-Event.

Die Mechanik dreht sich um eine Groß-/Kleinschreibungs-Unterscheidung. Ein Kommentar ist ein Kind-1111-Event mit zwei Tag-Sätzen: Großbuchstaben-Tags beschreiben die Diskussionswurzel, Kleinbuchstaben-Tags den unmittelbaren Parent. E, A und I benennen Root-Event, Root-Adress-Koordinate oder Root-Extern-ID; K benennt die Root-Kind-Nummer; P den Root-Autor. Klein e, a, i, k und p benennen dieselben Fakten über den Parent — bei Top-Level-Kommentar ist das die Wurzel selbst, bei verschachtelter Antwort ein anderes Kind-1111. Die Trennung erlaubt einem Client die ganze Diskussion mit einem Filter auf die Großbuchstaben-Root-Tags zu holen, ohne die Reply-Kette zu gehen, und verschachteltes Rendering korrekt aus den Kleinbuchstaben-Parent-Tags. I- und i-Varianten tragen externe IDs im NIP-73-Format (externe Inhaltsreferenzen) — damit hängt ein Kommentar-Thread an einer Webseite, Podcast-Episode oder einem Buch.

Die Tradeoffs betreffen vor allem, was NIP-22 nicht absorbiert. Die Spezifikation verbietet Kommentare auf Kind-1-Notes — zwei Threading-Modelle konkurrieren nicht über dieselben Objekte; NIP-10 bleibt, wo es funktioniert. Verschachtelung ist erlaubt, die Wurzel bleibt fix — ein tiefer Thread verliert den Anker nicht, wenn Zwischenevents fehlen. Die Kind-Tags tragen die Last: ein Client, der einen Kommentar ohne Ziel fetcht, erkennt aus K und k, womit er es zu tun hat, und ob er dieses Kind rendern kann. Kein Ordering- oder Moderationsmodell — Anzeigereihenfolge, Collapsing und Ausblenden sind reine Client-Policy.

Im Vergleich zu NIP-10 liegt der Unterschied im Typing. NIP-10 setzt eine Note als Ziel und kodiert Thread-Position; NIP-22 kodiert Identität und Kind des Ziels explizit und setzt sonst nichts voraus. Deshalb greifen die Vorschläge dieser Ausgabe nach Kind 1111: ein Kommentar trägt bereits eine maschinenlesbare Aussage darüber, woran er hängt.

Ein live Kind-1111-Kommentar von nos.lol und relay.primal.net diese Woche, Antwort auf einen anderen Kommentar unter einem Video:

{
  "id": "c8d335f8bfea58ecd1a943d6000fb2045f4bddf4a36c67df53eb661671f7ab45",
  "pubkey": "3e911baba55ae247339cf805dd6ff49ad2cd6bee84ac44e088ce66450c49104f",
  "created_at": 1787062681,
  "kind": 1111,
  "tags": [
    ["E", "1c492f2bac17b79d66934a340fa43d8d30d0aea4c9fa329346c05573ef912d70", "", "482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839"],
    ["A", "34236:482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839:e64ba9ea157b1a315caff51dbca656ed73ce817d4494e3966adf24055a86f5c5", ""],
    ["K", "34236"],
    ["P", "482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839"],
    ["e", "7a14723b9ef999e74b1757a0fb74942cb6c121138d4ddafe096a57a67ed0a442", "", "8b69e548402afa997343d73e8088224a440f256350f6257b61acc4bb1fa4af4f"],
    ["k", "1111"],
    ["p", "8b69e548402afa997343d73e8088224a440f256350f6257b61acc4bb1fa4af4f"],
    ["client", "Divine", "31990:d95aa8fc0eff8e488952495b8064991d27fb96ed8652f12cdedc5a4e8b5ae540:divine-mobile", "wss://relay.divine.video"]
  ],
  "content": "niiice",
  "sig": "a5517fdea07647efa7ab1730fbea8df882690bba667e93ea5aeba4a73be6a49af1ee17c045535483650caf41dbbcb0897d5803fa39b59f395fd6f9bb193bb789"
}

Die Großbuchstaben-Tags halten Video und Autor; Klein e und k zeigen auf den Parent-Kommentar — genau die Form der Spezifikation. Implementierungen, die Kind 1111 lesen und schreiben, umfassen Divine Mobile, dessen Client-Tag im Event oben steht, Amethyst, dessen Kommentare in denselben Relay-Ergebnissen erscheinen, und nostrord, das Thread-Posts diese Woche als Forum-Posts rendert. Das vorgeschlagene Patch-Format in NIPs PR #2438 baut auf demselben Kind auf.

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