Nostr Compass #46

Diese Woche: Mostro ergänzt signierte Identitätsneubindung. Amethyst bringt private Umfragen in Marmot-Gruppen und verschlüsselte Synchronisierung der Einstellungen über mehrere Geräte hinweg. swift-nostr liefert eine Prüfung, die das Signieren von Events verweigert, deren öffentlicher Schlüssel nicht mit dem des Signers übereinstimmt. Zum Abschluss blicken wir auf sechs Jahre Nostr-Oktober zurück, 2021–2026.

Top-Meldungen

Mostro

Mostro, der über Nostr koordinierte Peer-to-Peer-Börsen-Daemon, hat 0.20.1 veröffentlicht. Die Version ergänzt signierte Identitätsneubindung, die in der Ausgabe der letzten Woche noch als nicht implementiert beschrieben wurde, und liefert die bisher nur im Quellcode vorhandenen Reputationsexporte aus. Die gebundene Identität signiert eine einmal verwendbare Autorisierung, die den Node und die neue Identität benennt und höchstens eine Stunde gültig ist. Der Daemon speichert die Event-ID und wechselt per Compare-and-Swap, sodass eine fehlgeschlagene Signatur oder eine verlorene Race Condition nichts verändert. Betreiber erhalten außerdem eine auditierte, nur über Loopback erreichbare RPC-Schnittstelle, die ein Auth-Token und eine Begründung verlangt. Die Neubindung widerruft bereits ausgestellte Attestierungen nicht.

Spätere Merges sind noch in keinem Release bestätigt. Ein optional aktivierbarer Anbieter für einen festen USD-Peg fügt dem Nostr-Feed mostro-rates USDT, USDC und DOC nur dann hinzu, wenn der Betreiber ihn aktiviert. Netzwerkanbieter und weitergeleitete Coin-Kurse schalten ihn nicht implizit ein. Eine Folgeänderung benennt den Anbieter und seinen Konfigurationsschlüssel in pegged um und ersetzt damit den unveröffentlichten Schlüssel stablecoins. Außerdem notiert sie BTC, LBTC und RBTC zu einem festen Kurs von 1:1 in Sats und veröffentlicht die Kurse als Events der kind 30078. Diese konfigurierten Peg-Annahmen garantieren weder den Peg noch die Abwicklung. Live-Prüfungen des Pegs liegen weiterhin außerhalb dieses Mechanismus. Der Anbieter ist standardmäßig deaktiviert. Akzeptierte Währungen entscheiden weiterhin über die Zulassung von Orders; die Arbeiten an Client, Protokoll-Orderbuch und Peg-Schutz laufen separat. Bond-Timelocks laufen jetzt getrennt vom Escrow. Die angekündigte Ablaufzeit von Orders wird begrenzt, und das Annahmefenster im Orderbuch schließt, bevor ein Bond ablaufen kann. Bestehende Maker-Bonds mit 144 Blöcken laufen beim Upgrade ab, und die betreffenden Orders müssen neu erstellt werden. Laufende Trades und der Cashu-Modus sind nicht betroffen, aber manche Betreiberkonfigurationen verweigern den Start, bis der Bond-Timelock angepasst wurde.

Nostr-WoT-Erweiterung

Die Nostr-WoT-Erweiterung, ein Browser-Signer mit Web-of-Trust-Funktionen, hat 0.8.15 veröffentlicht. Die Version bietet die Option, den Wiederherstellungsschlüssel aus 256 Bit eigener Entropie des Nutzers aus Würfelwürfen oder Münzwürfen zu erzeugen. Würfelergebnisse werden mit SHA-256 gehasht, Münzwürfe werden als rohe Bits verwendet, und zwar in einem isolierten Tab, der die Wiederherstellungsphrase nicht anzeigt. Das Onboarding bricht jetzt mit einem Timeout ab, wenn Relays nicht erreichbar sind. Version 0.8.16 ergänzte dauerhafte Freigaben für die Relay-Authentifizierung (NIP-42), sodass Nutzer AUTH einmalig für alle Relays einer Website oder für jede verbundene Website genehmigen können (Implementierung der Relay-Authentifizierung). Ablehnungen für ein Relay oder eine Website haben Vorrang vor diesen Freigaben, und Widerrufe werden erneut geprüft, bevor wartende Anfragen aufgelöst werden. Weit gefasste Geltungsbereiche sind immer eine ausdrückliche Entscheidung des Nutzers und gelten nie für HTTP Auth (NIP-98). Die Obergrenze der Warteschlange bleibt bei fünf, sodass überzählige Anfragen weiterhin fehlschlagen und erneut versucht werden. Version 0.8.18 führt Import und Wiederherstellung in einem einzigen Ablauf zusammen, der Schlüsselformate erkennt und eine Vorschau der Identität zeigt; eine kompatible Nosskey-Wiederherstellung behält dieselbe Identität, die bestehenden Konten und die ursprünglichen Passkeys bei.

Das separate Entwickler-SDK nostr-wot-sdk hat 3.0.1 mit stabiler Unterstützung für Identity 1.1 veröffentlicht. Die Passkey-Wiederherstellung, auch über Nosskey, behält den ursprünglichen pubkey bei, und Provider-, Wiederherstellungs- und Signiercode teilen sich jetzt eine gemeinsame Implementierung (Quellcode für SDK-Wiederherstellung und Provider). Veraltete Weiterleitungspakete funktionieren weiterhin, Integratoren sollten aber auf die gepflegten Einstiegspunkte umsteigen.

Amethyst

Amethyst, der Nostr-Client für Android und Desktop, hat Version 1.20.0 mit privaten Umfragen und weiteren Funktionen für verschlüsselte Marmot-Gruppen veröffentlicht. Dazu gehören ersetzbare private Stimmen, benutzerdefinierte verschlüsselte Emojis, Meldungen und das Entfernen von Nachrichten durch Admins sowie Medien, die an die aktuelle Epoche der Gruppe gebunden sind. Der Autor hat die clientübergreifenden Interoperabilitätsprüfungen nach dem Review nicht erneut ausgeführt und die Änderung nicht manuell auf Android getestet. Cache-Schlüssel für konkurrierende Zweige mit derselben Epochennummer bleiben bestehen, und Schlüssel für verschlüsselte Medien können verschwindende Nachrichten überdauern. Die Synchronisierung der Einstellungen speichert sechs Gruppen von App-Einstellungen als verschlüsselte NIP-78-Daten. Schlüssel, Signer, Wallets, Benachrichtigungen, Decks und Lesemarkierungen bleiben auf dem jeweiligen Gerät. Die erste Änderung an den Einstellungen veröffentlicht alle sechs Gruppen. Ein Konto mit reinem Lesezugriff behält seine Einstellungen lokal, und das Verhalten über zwei signierende Geräte hinweg ist nicht verifiziert.

System-Benachrichtigungen auf dem Desktop folgen dem Benachrichtigungsfilter und überspringen äußere Einweg-Gift-Wraps sowie stummgeschaltete DMs. Nicht vertrauenswürdige d-Tags mit mehr als 255 Bytes verursachen keine Fehler mehr. Kind-Abfragen fragen nur verbundene Relays und die Such-Relays des Kontos ab, jeweils bis zu 200 Events. Die Apps nutzen Quartz’ Kite-JSON-Verarbeitung für Frames, Events, Filter sowie NIP-46- und NIP-55-Nachrichten, wobei das Signieren über diese beiden Protokolle nicht auf Geräten verifiziert wurde. Eine spätere Aufteilung der Bibliotheken verschiebt Protokollregeln von Marmot und cordn, die auch andere Clients benötigen würden, in gemeinsam genutzte Bibliotheken.

Nach 1.20.0 gemergter Quellcode, der noch in keinem Release enthalten ist, lässt den Marmot-Empfangspfad der App über die gemeinsame Bibliothek laufen. Jede entschlüsselte Nachricht wird idempotent gespeichert. Beim Beitritt wird ein Ausgangszustand festgehalten, sodass die erste Mitgliedschaftsänderung ihre Zeile anzeigt. Eine Nachricht der kind 445, die vor ihrem Commit eintrifft, wird zurückgehalten und später erneut verarbeitet, und das Nachholen durch Admins committet vorgemerkte Austritte. amy cordn migrate export deaktiviert die Sitzungsbefehle der alten Home-Installation bis zu einem Import oder dem neuen Resume-Befehl. Der Autor hat Loopback-Tests mit amy und Bibliothekstests gegen lokale Checkouts ausgeführt. Den Live-Empfangspfad der App hat der Autor nicht manuell durchgespielt, und die Marmot-Interop-Suite wurde nicht ausgeführt. Ein inkompatibles Update des vorgeschlagenen NIP-5D-Napplet-Formats liest einen Napplet-Manifest-Hash als ein einzelnes /index.html-Artefakt und ersetzt damit das alte Pfad-Aggregat, sodass ältere Bundles neu veröffentlicht werden müssen. Nicht verfügbare erforderliche NAP-Domains führen zu einem sicheren Abbruch (fail closed), optionale bleiben einfach abwesend. Icons werden per Hash und Decoder geprüft, der Speicher wird nach Manifest-kind, Artefakt und Snapshot partitioniert, und Ressourcen-Blobs verwenden kanonisches Base64. Manuelle Tests auf Geräten, clientübergreifende Tests und eine Veröffentlichung auf Live-Relays wurden nicht durchgeführt.

Ablehnungen in einem externen Signer werden jetzt in Coroutinen behandelt, die bisher keine Absicherung hatten, sodass sie die App nicht mehr zum Absturz bringen. PressStr-E-Books, -Magazine und -Ausgaben (kinds 33953, 34609 und 39731) werden jetzt dargestellt. PDFs öffnen sich im integrierten Reader, EPUBs werden an den Systemhandler übergeben. Karten zeigen Dateityp und -größe an, laden nie ein großes PDF nur für eine Vorschau herunter und rufen Ausgaben nur vom Autor des Magazins ab. Der Autor hat für diese Änderung keine Tests auf Android-Geräten gemeldet. Wenn Rich Previews deaktiviert sind, erscheinen Invoices und LNURLs als kompakte kopierbare Labels ohne Bezahlen-Schaltfläche, und Invoice-Karten zeigen jetzt Ablaufzeiten an. amy gift wrap datiert Seal und Wrap jetzt auf voneinander unabhängige zufällige Zeitpunkte, jeweils bis zu zwei Tage in der Vergangenheit. --no-backdate schaltet dies ab. Der reguläre DM-Pfad erhält seine Korrektur separat in Quartz. Auf dem Desktop steuert jede Videokarte ihre eigene Wiedergabe, sodass Karten mit derselben URL sich nicht mehr gegenseitig das Video übernehmen. Der Autor hat dies unter macOS getestet, aber nicht mit kaltem Cache. Eine vorgeschlagene Korrektur für Links unter Windows öffnet Links über rundll32 mit vollständigem Pfad und greift ersatzweise auf AWT zurück. Die eigentliche Ursache wurde nicht reproduziert, daher handelt es sich um eine wahrscheinliche und keine bestätigte Korrektur.

Myco ergänzt verschlüsselten Napplet-Speicher und signierte Update-Hinweise

Myco, ein Android-Host für Nostr-Napplets, hat 0.12.0 und 0.12.1 ausgeliefert. Napplets können jetzt über die Runtime selbstverschlüsselte Daten nach NIP-44 speichern, doch Apps mit Leseberechtigungen für Relay, Outbox oder Mesh können den Klartext sehen, sodass die Daten nicht pro App isoliert sind. Nutzer, die sich zuvor mit Amber angemeldet haben, müssen sich erneut anmelden, um die neuen Berechtigungen zum Ver- und Entschlüsseln zu erteilen. Update-Hinweise werden von einem fest hinterlegten (gepinnten) Herausgeber signiert und erreichen nur Geräte, auf denen bereits 0.12 läuft. Online kann Myco täglich Zapstore sowie Circle prüfen, während der reine Mesh-Modus nur Circle abfragt; dies ersetzt die anfängliche Pause. Eine ausdrücklich gewählte lokale Blossom-Schiene hält Dateien ohne Server auf dem Gerät, bis zu 64 MiB pro App und Tag. Bei fehlgeschlagenen Uploads auf einen genehmigten Standardserver bleibt ebenfalls eine lokale Kopie erhalten. Keiner der beiden Wege entfernt EXIF-Metadaten. Die Releases ergänzen außerdem Unterstützung für Android TV und eine NAPFS-Dateiauswahl, in der der Nutzer die Dateien auswählt.

Getaggte Releases

Monostr

Monostr, ein sozialer Nostr-Client für Android, hat 0.26.0 veröffentlicht, seine neueste Version. Videos mit bis zu zwei Minuten Länge werden jetzt auf dem Gerät komprimiert, und Standort-Metadaten werden entfernt. Entdecken, Suche und Onboarding bieten kuratierte Follow-Listen an. Threads und Benachrichtigungen zeigen jetzt Antworten aus dem Fediverse an, die als NIP-22-Kommentare gesendet wurden.

Die Funktionen aus 0.25.0 bleiben erhalten. Fehlt der übergeordnete Beitrag einer Antwort, durchsucht die App die Relay-Hinweise der Antwort und die Relays des Autors des übergeordneten Beitrags, was bedeutet, dass sie sich kurzzeitig mit Relays außerhalb der eigenen Liste des Nutzers verbindet. Relays und Live-Abonnements für Nachrichten verbinden sich außerdem neu, sobald das Gerät das Netzwerk wechselt.

Sidecar

Sidecar, eine Nostr-Browsererweiterung und ein Signer, hat 1.16.3 veröffentlicht. Der Composer und das Markierungswerkzeug veröffentlichen jetzt auf den eigenen Relays des Kontos und zählen nur Relays, die das Event bestätigen, und verlinken anschließend auf diese Relays. Eine Bestätigung zeigt, dass das Relay das Event angenommen hat, nicht aber, dass es dieses auch aufbewahren wird. Der erweiterte Composer greift nicht mehr auf die Standard-Relays aus den Einstellungen zurück. Jedes Relay hat eine eigene Frist von 12 Sekunden. Nur eine Veröffentlichung, die auf allen Relays fehlschlägt, wird erneut versucht, und zwar einmal, über neue Sockets. Umfrageergebnisse fragen außerdem vier öffentliche Relays nach Stimmzetteln ab. Eine nach dem Tag gemergte Änderung fügt ein weiteres Relay hinzu, um Stimmzettel zu erfassen, die außerhalb der üblichen Relays abgegeben wurden. Bei einer laufenden Umfrage erhöhte dies die Zahl von 21 auf 23 Stimmen. Das ist das Ergebnis einer einzigen Umfrage und sagt nichts über die Vollständigkeit im gesamten Netzwerk aus. Die Zählung erlaubt weiterhin einen Stimmzettel pro Person und ignoriert Stimmzettel, die nach dem Ende der Umfrage abgegeben wurden. Das frühere 1.16.1 beschränkt dauerhafte Signierfreigaben auf das Konto und die Website, die sie genehmigt haben, und auf einen einzelnen adressierbaren Datensatz, wenn das Event einen d-tag hat. Freigaben umfassen nie Ver- oder Entschlüsselung. Profil-, Follow-, Stummschaltungs- und Relay-Listen bleiben von jeder Freigabe ausgenommen. Ebenfalls ausgeschlossen sind Löschungen, zap-Requests, Relay-AUTH und die Wallet-Steuerung. Eine gesperrte Erweiterung fragt weiterhin nach der PIN. Das Widerrufen einer Freigabe oder das Vergessen einer Website löscht deren Freigaben und Genehmigungsfenster.

Ein separater offener Pull Request würde das Bezahlen eines CLINK-Angebots als zap zählen lassen. Er ist im Changelog unter „Unreleased“ eingereiht und implementiert keine Debits. Das Angebotsfenster würde einen signierten zap-Request der kind 9734 mit payer_data übergeben, damit der Dienst einen Beleg der kind 9735 veröffentlichen kann. Belege würden zuerst an das Relay des Angebots und dann an die Relays des Empfängers gehen, dedupliziert und auf sechs begrenzt. Die Relays des Zahlenden werden nicht verwendet. Antwortet ein Angebot mit Code 3 und einem dekodierbaren Nachfolgeangebot, würde Sidecar diesem einmal mit einem neuen Request und einer neuen Signatur folgen. Es würde niemals in das Profil des Empfängers schreiben. Die Änderung war zum Redaktionsschluss noch nicht gemergt.

Roadbeacon

Roadbeacon, ein Client zum Melden von Standorten, der zuvor Roadstr hieß und nicht mit der unabhängigen Roadstr-App identisch ist, hat 0.4.0 unter dem neuen Namen veröffentlicht, als neues Paket mit einem neuen Event-Format. Meldungen und Abstimmungen verwenden jetzt die gemeinsamen, interoperablen kinds 1315 und 1316, Koordinaten nutzen exakt rekonstruierbare Integer-Frames, und die Web-Version validiert Signaturen. Das Paket wird neben dem alten installiert, ohne Daten zu migrieren. Ältere Events bleiben auf Relays gültig, der neue Client kann sie jedoch nicht lesen.

Jumble

Jumble, ein Nostr-Webclient, hat v26.10.1 veröffentlicht. Zu den neuen Funktionen gehören ein Editor für Langform-Artikel, stummgeschaltete Wörter, die sich über Geräte hinweg synchronisieren, System-Benachrichtigungen sowie Reader für Gruppen- und Git-Inhalte. Die in einer kürzlichen Ausgabe behandelten Änderungen an ausstehenden Beiträgen und am Layout werden mit diesem Release ausgeliefert.

Ein nach dem Release gemergter Commit ergänzt eine optionale NIP-22-Antworteinstellung. Sie ist standardmäßig deaktiviert und wird als lokale Präferenz gespeichert. Ist sie aktiviert, werden Antworten auf Textnotizen der kind 1 als Kommentare der kind 1111 versendet. Bestehende Threads der kind 1111 behalten ihre Wurzel, und Kommentare zu anderen kinds oder externen Inhalten bleiben kind 1111. Ist die Einstellung deaktiviert, behalten Antworten das bisherige Verhalten mit kind 1. Die App warnt, dass manche Clients diese Kommentare möglicherweise nicht anzeigen.

nostr-idb

nostr-idb, eine Bibliothek, die Nostr-Events in der IndexedDB des Browsers zwischenspeichert, hat 5.1.1 mit Korrekturen bei Abfragen veröffentlicht. Abfragen nach exakter ID funktionieren jetzt für ersetzbare und adressierbare Events, und alle Filterbedingungen sowie Limits pro Filter werden jetzt angewendet, auch auf ausstehende Schreibvorgänge und den Abonnementverlauf. Das Bereinigen des Caches und Events mit Zeitstempel null wurden korrigiert. Die Größe des In-Memory-Caches, maxMemoryEvents, ist standardmäßig maxEvents, und null schaltet ihn ab.

Manent

Manent, ein verschlüsseltes Notizbuch, das über Nostr synchronisiert, hat 3.0.0 mit Sprachnotizen veröffentlicht. Aufnahmen werden wie andere Notizen verschlüsselt synchronisiert, und Transkripte werden offline mit Whisper erzeugt, nachdem die App ein Modell heruntergeladen hat. Das Release liefert außerdem die zuvor als Quellcode-Arbeit behandelte Wiederherstellung der Relay-Authentifizierung aus, die jetzt über Version 0.10.1 von NDK, der Bibliothek Nostr Development Kit, ankommt.

NoorNote

NoorNote, ein Nostr-Client für Desktop und Web, hat 1.9.2 mit geräteinterner Volltextsuche über Notizen und Direktnachrichten sowie einem reinen Cache-Modus veröffentlicht. Version 1.9.3 stellt nach einer Regression durch transparentes Glas in 1.9.2 wieder lesbare Dropdowns, Menüs und Toasts her. Diese Releases liefern außerdem den Filter für Zeitstempel in der Zukunft aus, der zuvor nur im Quellcode existierte. Profile, die nicht geladen werden können, bleiben jetzt im Ladezustand, bis der Fehlschlag bestätigt ist.

Earthly

Earthly, ein Nostr-Client zum Erstellen von Karten, hat 0.1.22 mit Korrekturen für Relays und Zahlungen veröffentlicht. Die Relay-Authentifizierung ist jetzt an das aktive Konto gebunden. Wiederhergestellte Abonnements und Zählungen unterscheiden eine nicht verfügbare Zählung von einer echten Null und behalten Zählungen über Kartenrevisionen hinweg bei. Zap-Summen stammen aus echten zap-Belegen, und die App wartet, bis die Wallet-Synchronisierung abgeschlossen ist, bevor sie Geld ausgibt. Live-Zahlungen über Nostr Wallet Connect und Mints sind weiterhin ungetestet (Release-Integration).

Chama

Chama, ein auf Nostr-Events aufbauender Escrow-Handelsclient, hat 6.4.31 veröffentlicht, das Seed-Backups vor der Finanzierung prüft. Bevor der On-Chain-Handelsschlüssel dieses Geräts in signierte CREATE-, JOIN- oder Einzahlungsbedingungen eingeht, muss ein Relay das signierte Seed-Backup zurückliefern, das das Gerät geöffnet hat; ein fehlendes, ausgemustertes oder widersprüchliches Backup stoppt den Trade. Wiederholungen senden genau das gespeicherte Backup erneut, ohne neuen Seed. Das Zurücklesen zeigt die Verfügbarkeit zu diesem Zeitpunkt, nicht die dauerhafte Speicherung. Angebote mit mehreren Einheiten verwenden jetzt Mengenbestellungen. Version 6.4.30 zählt Storefront-Bestellungen nur, wenn die vom Käufer signierten Bedingungen mit dem signierten Angebot übereinstimmen, und schützt vor verspäteten Events Außenstehender bei Trades, deren signiertes CREATE auf den 1. Dezember 2026 oder später datiert ist, während frühere Trades das alte Ablaufverhalten behalten (Validierung von Trade-Ablauf und Storefront).

Ein offener Pull Request, der zum Redaktionsschluss unserer Quellen nicht gemergt war, würde ein Wallet-Seed-Backup pro Identität erlauben. Beim Start würde die erstmalige Erstellung mit einer seiteninternen Warteschlange und Web Locks serialisiert und anschließend der Relay-Zustand erneut gelesen. Getrennte Browser verlassen sich ausschließlich auf dieses erneute Lesen. Eine verteilte Sperre und die Reparatur bestehender widersprüchlicher Backups liegen außerhalb dieser Änderung. Wir haben keinen der Geldpfade getestet.

Linky

Linky, eine Cashu-Wallet, die über Nostr synchronisiert, hat in Version 26.10.7 und dem Android-Build 26.10.8 experimentelle On-Chain-Überweisungen hinter einem Flag ergänzt. Ein konfigurierter menschlicher Betreiber erledigt Sende- und Empfangsanfragen gegen eine Gebühr innerhalb von 24 Stunden, sodass Überweisungen weder atomar noch vertrauenslos sind. Die Koordinationsänderung nutzt benutzerdefinierte Nostr-App-Nachrichten, Betreiberkonfiguration nach NIP-78 und einen neuen Link-Synchronisierungsbereich. Dieser Bereich synchronisiert die ausstehenden Ecash-Sendungen des Betreibers, damit seine anderen Geräte dieselbe Sendung nicht doppelt bezahlen, erstatten oder abwickeln können. Ein Empfang ist erst abgeschlossen, wenn die Wallet des Nutzers den passenden Cashu-Betrag erhält. Betreiber und Nutzer finden einander nur über empfohlene Relays, nicht über NIP-65-Relay-Listen oder DM-Inbox-Listen, sodass der Verlust aller gemeinsamen Relays die Koordination unterbrechen kann.

LaWallet

LaWallet, ein auf Nostr Wallet Connect aufbauender Wallet- und Kontodienst, hat Version 2.9.0 und die Android-Beta 1.2.0 veröffentlicht, die beide eine durch NFC-Karten unterstützte Wiederherstellung auf einen neuen Nostr-Login ergänzen (nativer Wiederherstellungsablauf). Die Wiederherstellung erfordert ein frisches, kryptografisch verifiziertes Antippen der Karte und einen einmal verwendbaren Wiederherstellungs-QR-Code, der 15 Minuten gültig ist. Vermögenswerte werden in einer einzigen Transaktion übertragen, Rollen werden nicht übertragen, alte OAuth-Freigaben werden widerrufen, und der alte Login bleibt leer zurück. Die Kartenwiederherstellung ist standardmäßig aktiviert; Kontoinhaber können sie in den Sicherheitseinstellungen deaktivieren und ausstehende Codes widerrufen. Eine nicht erreichbare Wallet zeigt jetzt einen Kontostand von null an, was nicht bedeutet, dass sie leer ist. Die Android-Beta erzwingt in Builds mit einem Reporting-Endpunkt die Fehlerberichterstattung über Sentry, selbst nach einem früheren Opt-out; lokale und F-Droid-Builds haben keinen Endpunkt.

In nach dem Tag gemergtem Quellcode kann der Karten-Callback OK zurückgeben, bevor die NWC-Abwicklung erfolgt ist, wenn der Kontostand die Zahlung deckt, sodass Kassensysteme ihre eigene Invoice bestätigen müssen. Eine feste Zahlungsobergrenze ersetzt das kontostandbasierte Limit. Ein offener Pull Request, der zum Redaktionsschluss unserer Quellen nicht gemergt war, würde die Anmeldung mit kompatiblen Passkeys aus anderen Apps über einen konfigurierten Provider oder eine Nosskey-Wiederherstellung ermöglichen und das Konto bestätigen, bevor eine ablaufende temporäre Sitzung ausgestellt wird (#386). Ein Provider kann signieren, ohne den privaten Schlüssel zu importieren, und der Import ist eine separate, zu bestätigende Entscheidung. Die Screenshots zeigen simulierte Demo-Antworten, keinen Nachweis einer echten ursprungsübergreifenden Anmeldung.

Ein weiterer Merge, ebenfalls in keinem Release bestätigt, verhindert, dass der Callback für NWC und Lightning-Adressen die Remote-Wallet eines Nutzers allein aufgrund eines make_invoice-Fehlers ersetzt. Eine Prüfung von Erreichbarkeit und Kontostand kann die Wallet beibehalten und stattdessen einen 503 zurückgeben. Der Dienst merkt sich außerdem Kontostände und den Zustand geschützter Guthaben und ergänzt eine Wiederherstellungsoption. Seine Schwellenwerte und die unbekannte frühere Historie begrenzen, was er schützen kann, daher garantiert er nicht, dass alle Guthaben sicher sind. Es wird weder ein Deployment noch die Wiederherstellung von Nutzerkonten behauptet.

KithMoot

KithMoot, eine Nostr-basierte App für Raum-Chats und Anrufe, funktioniert jetzt ohne die öffentlichen Dienste ihres Herausgebers. Zwischen dem 21. und 23. Oktober hat der Herausgeber öffentliche Meeting-Codes, den gemeinsamen TURN-Dienst, Datei-Uploads und das Lesen gespeicherter Dateien eingestellt. Einladungslinks ersetzen Meeting-Codes, und öffentliche Dateien gehen standardmäßig an Yakihonne, mit einem Hinweis beim ersten Senden, wobei Nutzer einen eigenen Server wählen können. Anrufe versuchen weiterhin zuerst eine direkte Verbindung, während „IP verbergen“ einen funktionierenden TURN-Server benötigt und nie auf eine direkte Verbindung zurückfällt. In Desktop 0.1.102 und Android 0.6.106 ersetzt der öffentliche STUN-Server von Cloudflare den des Herausgebers, und Nutzer können einen eigenen festlegen. Bereitgestellte Sicherungskopien wurden gelöscht, während verschlüsselte Offline-Kopien erhalten bleiben. Desktop 0.1.109 und Android 0.6.121 sperren den Chat, wenn Geräte-Anmeldedaten ablaufen, behalten dabei aber Entwürfe bei, und lesen den eigenen Profilnamen des Nutzers getrennt von optionalen Verzeichnisabfragen. Die normale Anruf-Engine ist nicht auf die experimentelle Vorschau des Realtime-SDK umgestiegen, und der MLS-Gruppenkandidat bleibt standardmäßig deaktiviert.

Desktop 0.1.110 ergänzt Sandbox-Betrachter für Anhänge für Bilder, Audio, Video und PDFs auf dem Desktop und im Web. Auf dem Desktop laufen sie in einem eigenen, nicht persistenten Electron-Renderer ohne Node-Zugriff, ohne Anwendungsspeicher und ohne externen Netzwerkzugriff. Das Streaming ist begrenzt, und Betrachter werden beim Schließen oder beim Zurückziehen einer Nachricht aufgeräumt. Der WebKit-Lauf des Pull Requests und ein zusätzlicher Lauf mit feindseligem SVG im paketierten Build blieben hängen und werden nicht als verifiziert ausgewiesen, und nichts davon ist eine Sicherheitszertifizierung. Der macOS-Build ist notarisiert, während Windows eine unsignierte Vorschau bleibt.

Ein späterer Merge, für den nicht nachgewiesen ist, dass er in 0.1.110 enthalten ist, erneuert abgelaufene Geräte-Anmeldedaten anhand der realen Uhrzeit nach dem Ruhezustand und vor dem Senden und behält den Entwurf, während der Signer antwortet. Anlass war, dass die Anmeldedaten eines Testers über Nacht auf einem schlafenden Laptop abgelaufen waren. Eine Signer-Anfrage, die nie zurückkehrt, hält die Erneuerung weiterhin offen, und Android hat eine separate, ungelöste Lücke bei der Erneuerung. Ein offener Pull Request, der zum Redaktionsschluss unserer Quellen nicht gemergt war, würde „Anderen beim Verbinden helfen“ pausieren. Der Autor gibt an, dass die App ein Peer-Assist-Paar akzeptiert, ohne dessen Medien zu übertragen, was den Rückgriff auf einen Forwarder oder TURN verhindern und zu einem stummen Anruf führen kann. Der Standardwert der Bibliothek würde unverändert bleiben.

Marmot TS

marmot-ts, eine TypeScript-Bibliothek für das Protokoll für verschlüsselte Gruppennachrichten Marmot, hat v0.8.0 und v0.9.0 mit inkompatiblen Änderungen ausgeliefert. Verschlüsselte Medien V2 ergänzen eine Quellbindung und entschlüsseln verzögerte Medien nach einem Neustart, und Blossom-Upload-Deskriptoren, -Ziele und Chiffretext werden vor dem Signieren validiert. Persistierte Gruppen füllen fehlende Daten seitenweise nach, mit Wiederholungsversuchen bei unsicheren Commits. Apps müssen jetzt dauerhafte Ingest- und Rewind-Speicher bereitstellen, deren Adapter fehlgeschlagene oder abgelaufene Lesevorgänge zurückweisen. Ältere V1-Gruppen müssen neu erstellt werden, da die V1-Hilfsfunktionen nur noch für den Verlauf erhalten bleiben.

Später gemergter Quellcode gibt den Watchern für Key-Packages, Einladungen und Verlauf ein optionales AbortSignal. Ihre Listener werden bei Rückkehr, Ausnahme oder Freigabe umgehend aufgeräumt, selbst wenn noch ein Speicher-Lesevorgang aussteht. Änderungen, die eintreffen, während ein Consumer pausiert ist, werden festgehalten und zu einem einzigen Update zusammengeführt. Der zugrunde liegende Lesevorgang im Backend läuft nach dem Abbruch weiter. Fehlgeschlagene Abfragen werden weiterhin zurückgewiesen, und die Änderung bescheinigt keine Laufzeit-Interoperabilität.

Nostr-Mailclient

nostr-mail-client, ein auf Nostr aufbauender Mailclient, hat v0.19.0 mit einem einheitlichen Login-Ablauf für bunker, nsec und ncryptsec veröffentlicht, einschließlich der Genehmigung der auth_url eines Remote-Signers. Er folgt jetzt Änderungen an DM-, Inbox-, Outbox- und privaten Relay-Listen ohne erneuten Login, dedupliziert Mail-Benachrichtigungen während der Synchronisierung und synchronisiert E-Mail-Signaturen verschlüsselt zwischen Geräten. E-Mail-Anhänge über der Obergrenze von 25 MB werden mit einem Hinweis verworfen, und eine reine Nostr-Adresse kann keine per E-Mail gesendeten Antworten empfangen.

Napplet-Konformitäts-CLI

napplet/web, die Web-Pakete und Werkzeuge für Napplets (Web-Apps, die als signierte Nostr-Events verteilt werden), liefert die Verifizierungsarbeit aus der letzten Ausgabe jetzt in der versionierten @napplet/conformance-cli 0.4.0 aus. Vor einem Headless-Lauf prüft die CLI die Event-ID des Manifests, die Signatur und den exakten Hash des rohen HTML, und sie meldet Fehler bei Runtime-Bindung, Namespace und Installation getrennt von Napplet-Fehlern. Der eingebettete Fallback deckt nur RESOURCE und GAMEPAD ab, sodass benutzerdefinierte Hosts Quell- und Snapshot-Eingaben ausdrücklich übergeben müssen.

Der Deploy-Befehl von Napplet bereitet jetzt standardmäßig Zapstore-Einträge vor: Er erstellt Screenshots jedes ausgewählten Builds und bereitet ein Software-Application-Event der kind 32267 vor; --no-screenshot und --no-zapstore deaktivieren diese Schritte. Das Vorbereiten von Metadaten ist keine Veröffentlichung eines Releases, und die Änderung fügt weder ein Paket-Release noch ein Asset-Event hinzu.

napplet-soy

napplet-soy, ein Arbeitsbereich zum Erstellen und Veröffentlichen von Napplets, hat sein Kommandozeilenwerkzeug soyli als v0.31.2 und v0.31.3 getaggt; diese sind kein Studio-Deployment. Sobald die Git-Auslieferung bestätigt ist, markiert das Veröffentlichen enthaltene Vorschläge für Git-Zusammenarbeit (NIP-34) als gemergt, nachdem die exakte Abstammung und das Ziel zusammen mit der aktuellen Revision geprüft wurden, und es verwendet beim Fortsetzen vorab signierte Status wieder. Neuere Revisionen von Vorschlägen bleiben offen, und ein Tag, der einen Commit enthält, gilt nicht als Nachweis, dass der Zielbranch ihn gemergt hat. Der Quellcode hinter diesen Tags ergänzt außerdem eine erste Ansicht für die Cashu-Wallet (NIP-60) in einem einheitlichen Manage-Arbeitsbereich und hält laufende Napplets bei Tab-Wechseln am Leben. Der Updater des früheren v0.31.1 folgt der stabilen GitHub-Repository-ID, sodass Installationen ihre Konten und Projekte beim Umzug zu Soytec behalten. Installationen mit dem älteren Updater müssen den Installer einmal ausführen.

Die NIP-60-Cashu-Wallet löst NIP-61-Nutzaps ein und speichert vorbereitete Mint-Ausgaben und signierte Relay-Updates, bevor sie ausgeführt werden, sodass unsichere Anfragen wiederhergestellt werden können, ohne eine Zahlung zu wiederholen. Wallets bleiben pro Konto isoliert, und Browser-Tabs können nicht gleichzeitig Geld ausgeben, doch die Tests nutzten gefälschte Mints, und die Interoperabilität mit echtem Geld ist nicht verifiziert. Beitragsseiten unterstützen jetzt zaps an gezielte Autoren, die an den signierenden Autor des gewählten Releases oder Vorschlags zahlen.

Der Tag soyli v0.31.4 nennt Beitragsverlauf und zaps für Autoren sowie Änderungen zu NIP-5D-Bereitschaft, Audio und Tests. Domain-Aufrufe warten nicht mehr darauf, dass die Shell Bereitschaft meldet. Ein gemeinsamer Host koordiniert Audio, das Napplets über NAPMEDIA besitzen, ohne die iframe-Isolation zu lockern. Auch dieser Tag ist kein Studio-Deployment. Fünf konfigurierte Prüfungen waren erfolgreich, fünf wurden übersprungen. Vollständige Konformität ist weiterhin nicht nachgewiesen, und die reparierten Apps warten auf ihre erneute Veröffentlichung.

Pakstr

Pakstr, ein Kommandozeilenwerkzeug, das Android-Apps baut und auf Nostr veröffentlicht, hat v0.29.1 getaggt. Vor der Veröffentlichung liest es das Signer-Zertifikat, das ein APK in seinem v2- oder v3-Signaturblock angibt, und gleicht dessen SHA-256 mit der erwarteten Sidecar-Datei und dem Identitätsnachweis ab (Review zur Veröffentlichung). Unsignierte, fehlerhafte und APKs mit mehreren Zertifikaten werden abgelehnt, veraltete Sidecar-Dateien werden beim Neubau entfernt, und ein ungültiger nsec für die Veröffentlichung schlägt vor dem Build fehl. Der Parser verifiziert die APK-Signatur selbst nicht, das bleibt Android und apksigner überlassen; er erkennt also veraltete, unsignierte oder mit dem falschen Zertifikat erstellte Builds, kann aber nicht beweisen, dass ein Build nicht gefälscht ist. ZIP64, mehrere Signer und Schlüsselrotation werden nicht unterstützt.

MDK

MDK, das SDK und die Runtime für verschlüsselte Marmot-Gruppen, hat die stabile Version v0.14.0 veröffentlicht. Sie liefert Übergabe und Speicherung von Mediendateien, geordnetes Nachholen nach Offline-Phasen, den Erhalt von Follow-Listen und das Neuverschlüsseln mit rohen SQLCipher-Schlüsseln, wobei MLS und das Wire-Format unverändert bleiben. Der Release-Leitfaden zu 0.14.0 und der Integrationsleitfaden zu 0.14.0 verlangen, dass Apps einen zueinander passenden Satz aus Bindings, nativer Bibliothek und Headern ausliefern, den MarmotKit 0.14.0 für Apple und Android paketiert. Auf Apple-Plattformen ist die Binärdatei ein rohes statisches XCFramework, daher kombinieren Apps sie mit dem passenden Swift-Binding und kopieren ihre Ressource PrivacyInfo.xcprivacy in das Wrapper-Produkt, dem sie sie zuordnen; das Bestehen der Archivprüfungen des Releases beweist nicht, dass ein App-Store-Export gelingt. Datenbank und Speicher werden in einer Richtung migriert, wobei jede Seite einmal neu verschlüsselt wird. Downgrades werden weiterhin nicht unterstützt. Medien und Übergabedaten von Konten sollten von Backups ausgeschlossen werden. Der WN-Agent bleibt eine Vorabversion, und die Crates sind nicht auf crates.io verfügbar. Bekannte Einschränkungen bestehen fort: Verlauf, der mehr als fünf Epochen zu spät eintrifft, wird ohne Hinweis unentschlüsselbar. Medien, die während eines Epochenwechsels unterwegs verloren gehen, sind weiterhin nicht behoben; außerdem bleibt ein Kompatibilitätsproblem bei der Reihenfolge des Gruppenkontexts bestehen.

Die Tag-Abstammung zeigt, dass der stabile Tag außerdem fünf Änderungen an Sync und Medien enthält. Aktualisierungen von Gruppenabonnements packen nur geänderte REQ-Batch-Familien neu; eine fehlgeschlagene Familie behält ihre aktiven Routen für den nächsten Sync, während der teilweise Commit weiterhin einen fehlgeschlagenen Sync meldet. Sendungen und Gruppenänderungen gelangen weiterhin in die dauerhafte Warteschlange, wenn eine Aktualisierung vor dem Senden fehlschlägt, wobei der Abschluss allerdings CompletionUnknown bleiben kann. Ein REQ an ein nicht erreichbares relay bleibt unter derselben ID bis zur Wiederverbindung ausstehend, sodass eine eingeschränkte Abdeckung keine vollständige Historie ist. Die Freigabe einer Onboarding-Reparatur wartet auf jede Discovery-Quelle und gibt RetryableFailure zurück, wenn eine deklarierte Quelle in ein Timeout läuft. Die optionale Medienaufbewahrung pro Konto, von „Für immer behalten“ bis hinunter zu 30 Tagen, bereinigt Medien nach Empfangszeit oder letztem ausdrücklichem erneutem Herunterladen, nicht nach letzter Ansicht, ohne den Nachrichtenverlauf zu löschen. Hosts müssen den neuen FFI-Wert CleanedBySetting verarbeiten.

Nach dem Tag setzte zusammengeführter Quellcode die Arbeit an Multi-Device und Push fort, die noch kein Release für sich beansprucht. Verlaufsanfragen nach dem Beitritt bleiben erhalten, über Commits und Neustarts hinweg, und schließen so eine Lücke zwischen dem Welcome und Live-Nachrichten. Das Zählen von Mitgliedern pro Konto verhindert falsche Hinweise zu einer Person, wenn ein zweites Gerät beitritt oder austritt, und die Welcome-Verarbeitung ignoriert Zustellungen, die für Geschwistergeräte bestimmt sind, ohne den Beitritt scheitern zu lassen oder einen Schlüssel zu verbrauchen. Für Push verbreitet MDK vom Eigentümer signierte Datensätze und Tombstones per Gossip nach Commits auf neuem Push-Gossip-Speicher, teilt Tokens nach dem Hinzufügen von Mitgliedern erneut und benachrichtigt alle Geräte eines Empfängers, wobei die eigenen Geräte des Absenders allerdings weiterhin keine Benachrichtigung erhalten. Neues zufälliges Padding pro Auslöser verhindert, dass die Deduplizierung Weckvorgänge unterdrückt. Die Veröffentlichung von KeyPackages übernimmt die eigenen relay-Listen des Kontos und schlägt unter Beibehaltung der gespeicherten Liste fehl, wenn eine Liste unvollständig ist oder kein nutzbares relay enthält. Typisierte Medienstatus für veraltete Epochen und ungeklärte Zustände teilen Apps mit, ob sie erneut hochladen oder synchronisieren und erneut senden sollen, und Änderungen des Übertragungszustands kommen sofort an, während der Byte-Fortschritt gebündelt wird.

Neuerer Quellcode für Kontogeräte ist ein Fortschritt hin zu einem späteren Release, kein stabiles 0.15. Drei Nightlies vom 28. Oktober, die als nur zum Testen gekennzeichnet sind, sind auf Commit b8d0a49 festgelegt, der vor späteren Merges liegt, sodass ihre Assets nicht alles davon enthalten. MDK wählt kompatible KeyPackages pro Gerät aus, für bis zu 20 kürzlich genutzte Geräte pro Konto, und beim Abmelden wird nur der Veröffentlichungsplatz dieses Geräts zurückgezogen. Neue Pakete gelten 30 Tage plus eine Stunde und werden sechs bis sieben Tage nach der Veröffentlichung erneuert. Die Discovery sucht nach jedem Gerät, doch relay-Ausfälle können einige auslassen; eine erneute Einladung kann helfen, ohne Garantie einer automatischen Wiederherstellung. Authentifizierte Fähigkeitsprüfungen pro Leaf ersetzen den Cache pro Konto. Neue Gruppen verlangen die Kontogeräte-Komponente 0x800d, wenn jeder Gründer sie unterstützt, und aktualisierte Geräte bewerben sie nun. Solche Gruppen weisen ältere Geräte ohne sie zurück, während bestehende Gruppen unverändert bleiben. Unter dieser Anforderung weist MDK Komponentendaten, nicht unterstützte Leaves, mehr als 20 Leaves pro Konto sowie Versuche zurück, die Anforderung zu entfernen, und lässt Legacy-Gruppen und Gruppen ohne diese Anforderung, wie sie waren. Unabhängig davon lehnt es vom Host gelieferte Anfangsdaten für App-Komponenten ab, deren Schema keine Daten vorsieht, bevor eine Gruppe, ein Welcome oder ein event erstellt wird.

In 0x800d-Gruppen erhält die Engine Befugnisse zum Hinzufügen und Entfernen im eigenen Konto mit einer Commit-Klassifizierung, die den Elternzustand berücksichtigt, und unterscheidet Selbstaktualisierung, Selbstentfernung, Commits im selben Konto und Admin-Commits, wobei Privilegien im selben Konto Proposals by value erfordern. Die passende Welcome-Verarbeitung akzeptiert Welcomes aus demselben Konto nur in diesen Gruppen und nur nach Prüfungen von Komponentenzustand und Signatur; andere Gruppen benötigen weiterhin einen aktiven Admin. Sendeabsichten zum Hinzufügen und Entfernen im eigenen Konto erhalten einen fairen Platz im Scheduler, aber App-APIs stellen Sendeabsichten für dasselbe Konto noch nicht bereit. Die Entfernung des eigenen Leafs eines Geräts entscheidet nun über dessen lokale Mitgliedschaft, sodass die Anwesenheit eines Geschwistergeräts einem entfernten Gerät nicht mehr seine Mitgliedsaktionen erhält.

Push-Gossip ergänzt dauerhaft in die Warteschlange gestellte kind-447-Ankündigungen mit 8-Byte-Digest-Präfixen von Datensätzen und Tombstones, die beim Beitritt, bei Änderungen eines Datensatzes und in einem siebentägigen Nachrichtenrhythmus gesendet werden, und Peers reparieren fehlende, vom Eigentümer signierte Datensätze über gerankte, gestaffelte Antworten mit Duplikatunterdrückung und einer 24-Stunden-Grenze pro Leaf. Bei der Wiederherstellung erfinden Cut und Cancel keinen neuen Verlust mehr, und 24 Versuche ohne Fortschritt stellen eine Verpflichtung hinter eine Warnung über unvollständigen Verlauf zurück. Das Abdeckungs-Ledger läuft nur als Schattenaufzeichnung, während ein zeitlich aufgeteilter Sweep Abschnitte beginnend mit den ältesten fortsetzt, bislang ohne produktiven Scheduler. Optionale Audit-Dateien verfallen 30 Tage nach dem letzten Schreibvorgang, mit Bereinigung beim Start und stündlich. Die Löschung kann einen Tag später erfolgen; das separate Sicherheitsprotokoll für Schlüsseloffenlegungen ist von diesem Verfall ausgenommen.

Ein Pairing-Crate verwendet ephemeres X25519, ein Commitment, einen Vergleich von sieben Emojis, den der Nutzer auf beiden Bildschirmen prüft, sowie HMAC-Bestätigungen, die in einem ConfirmedLink enden. Sein Wire-Adapter deckt nur den Transport ab und ist bis zu einer Spezifikation standardmäßig deaktiviert, die UI sowie die Folgearbeiten für Welcome und Gruppenverknüpfung sind unfertig, und die Interoperabilität dieser Implementierung ist weiterhin nicht verifiziert. Quellcode für das Geräte-Roster 0x800e wendet Diff-Aktualisierungen auf eine verborgene Einzelkontogruppe an, doch das Bewerben von 0x800e erfordert eine Überschreibung der Testrichtlinie, sodass Produktions-Builds noch keine Gerätegruppe erstellen oder ihr beitreten können.

Weitere MDK-Vorschläge sind noch offen. Einer würde aufhören, einen NIP-67-Abschluss als Nachweis vollständiger Abdeckung zu behandeln, da der nicht eingeplante Sweep keine Vollständigkeitsgarantie bietet. Andere würden Checkpoint-Replay, automatischen Wiederbeitritt und die Aktivierung von 0x800d in bestehenden Gruppen ergänzen. Drei frühere Vorschläge für native APIs sind laut einer neuen Statusprüfung weiterhin offen. Die Wiederherstellung historischer Anhänge würde Quell-Slots untersuchen und authentifizierten Digest und Ablauf prüfen, bevor verifizierte Bytes in eine private, geleaste Datei geschrieben werden, wobei die Timeline netzwerkfrei bleibt; eine zugestellte Kopie ist ein Snapshot, der nicht widerrufen werden kann. Filterweite Handles für die Chat-Auswahl würden jeden Chat, der einem Filter entspricht, über die geladene Seite hinaus abdecken und dabei später eintreffende ausschließen, und die Auswahl von Gründungsadmins bei der Gruppenerstellung mit wn-agent würde eingeladene Gründungsadmins auswählen und Nichtmitglieder vor dem Upload zurückweisen.

nosfry

nosfry, ein in Rust geschriebenes Nostr-relay, hat nosfry v0.2.0 für seine native Edition und seine Workers/SQL-Edition veröffentlicht. Es liefert Funktionen aus, die in v0.1 noch unveröffentlicht waren: NIP-09-Löschung, NIP-40-Ablauf, NIP-42 AUTH mit NIP-70-geschützten events, NIP-45 COUNT, NIP-77-Negentropy-Sync, NIP-62-Vanish-Anfragen und die NIP-86-Admin-API. Außerdem ergänzt es begrenzte Abonnements mit einem ausgehenden Budget und einer Schreibrichtlinie und beschreibt permessage-deflate als standardmäßig aktiviert. Seine Leistungs- und Konformitätsangaben sind nicht unabhängig reproduziert, und es beansprucht nicht, mit jeder Implementierung zu interoperieren.

Vier Härtungsänderungen wurden am 25. Oktober nach dem 0.3-Tag zusammengeführt und sind in keinem veröffentlichten Binary enthalten. Worker-Verbindungs- und Rate-Buckets fassen IPv6 nach /64 zusammen, während die NIP-86-IP-Sperrliste weiterhin exakte Adressen abgleicht (#78), und NEG-OPEN-Scans belasten das globale Sync-Speicherbudget während der Erfassung in Schritten von 1024 Datensätzen (#73). Gruppen gleicher Zeitstempel halten einen Heap, der durch das Abfragelimit begrenzt ist (#72). NIP-86-Moderations-Snapshots gelten für gespeicherte Lesezugriffe und Live-Zustellung so, wie sie zum Anfragezeitpunkt erfasst wurden, sodass eine offene Anfrage neue Sperren nicht sofort übernimmt (#68).

Ein weiterer, ebenfalls unveröffentlichter Merge begrenzt den Writer durch ein Byte-Budget von 64 MiB und arbeitet Veröffentlichungsrückstände in größeren Transaktionen ab, die jeweils durch die geleistete Arbeit begrenzt sind, wobei der dauerhafte LMDB-Sync beibehalten wird. Die Benchmark-Zahlen des Projekts stammen aus dessen eigenen Probe-Varianten, nicht aus unseren Messungen.

nostream

nostream, ein Nostr-relay in TypeScript, hat nostream 3.7.0 und nostream 3.8.0 veröffentlicht. Version 3.7.0 liefert die Admin-Operationen, Audit-Logs, signierten Webhooks und Metriken aus, über die wir zuvor als nur im Quellcode vorhanden berichtet hatten. Sie ergänzt einen optionalen Lebenszyklus für bezahlte Schreibvorgänge und behebt das Parsen von ISO-Zeitangaben sowie den Ablauf für LNbits 1 und neuer. Statisches Mirroring wurde entfernt, und seine Einstellungen werden nun zugunsten von NIP-77-Sync mit einer Warnung ignoriert. Das Container-Image von 3.7.0 konnte nicht veröffentlicht werden, weil sein Docker-Tag ein unzulässiges @ enthielt, und 3.8.0 korrigiert die Tags und ergänzt erneute Durchläufe für fehlgeschlagene Image-Builds. Version 3.8.0 bringt außerdem pubkey- und kind-Listen sowie Steuerungen zur Umgehung von IP- und Rate-Limits in die Admin-API und die Konsole, mit Statistiken zu den aktivsten Veröffentlichern, IPs und Rate-Limit-Treffern, und behebt eine Redis-Schlüsselkollision beim Wechsel der Rate-Limit-Strategie oder beim Upgrade. Der Quellcode allein bestätigt nicht, dass die Images nun veröffentlicht werden, und eine produktiv eingesetzte Abrechnung wird nicht behauptet.

Eine separate Neuimplementierung in Rust auf dem Branch rewrite/main hat in 740ef69 ihren ersten Wire-Kern zusammengeführt, der einem echten Client antwortet, und bei 2b2287f implementiert die Strategie-Registry die 14 verbleibenden Strategiezweige. Dieser nicht standardmäßige Prototyp bleibt getrennt von TypeScript main und den stabilen 3.x-Releases, und seine Review- und CI-Ergebnisse stammen vom Autor. Die Verarbeitung von NIP-43 und NIP-56 bleibt standardmäßig deaktiviert. Eine Vanish-Anfrage kann weiterhin ein Wettrennen gegen eine gleichzeitige Veröffentlichung verlieren, daher ist Vanish keine Datenschutzgarantie. Die Bitte des Autors um eine manuelle Prüfung des Zugriffs- und Identitätscodes besteht weiterhin.

swift-nostr

swift-nostr, ein Swift-SDK für Nostr, hat am 27. Oktober 0.9.0 veröffentlicht. Das Release ergänzt typisierte Schlüssel, Event-IDs, URLs, Zeitstempel, Koordinaten und Abonnement-IDs, EventTemplates, die jeder lokale oder entfernte Signer signieren kann, typisierte Fehler, vom Pool verwaltete Abonnements und RelayRoute-Routing über den Pool, exakte relays oder die NIP-65-Outbox. Event.verify wirft nun bei einer ungültigen Signatur einen Fehler, daher erfordert der Umstieg von 0.8 Änderungen am Quellcode. Das frühere 0.8.0 war ein Härtungsrelease, dessen Notizen besagen, dass es ersetzbare events, Gift-Wrap-Absender sowie NIP-46- und NWC-Antworten verifiziert, Antworten mehrerer relays dedupliziert und signergesteuerte oder auf gemeinsamen Schlüsseln basierende NIP-44-Verschlüsselung ergänzt, mit strengeren zap-Prüfungen als Breaking Change. Dies sind Angaben des Autors, kein Audit.

Die Korrekturen nach 0.8, über die wir zuvor berichtet haben, sind nun in 0.9.0 enthalten. Signer lehnen events ab, deren öffentlicher Schlüssel von ihrem eigenen abweicht, und das Abbestellen öffnet kein getrenntes relay mehr, um CLOSE zu senden. Der zentrale Sendeaufruf wirft notConnected, und das Abonnieren verbindet explizit, wobei NWC- und NIP-46-Transporte ein abgebrochenes relay für eine neue Anfrage allerdings weiterhin neu verbinden. NWC- und Remote-Signer-Aufrufe erhalten typisierte Fehler und sofortigen Abbruch, wobei auf eine bereits gesendete Anfrage dennoch reagiert werden kann. NWC-Benachrichtigungs- und Auth-Challenge-Streams enden, wenn relays sie beenden, Verbindungswartevorgänge schlagen fehl, sobald alle relay-Streams enden, und tag-Abfragen in Filtern werden einmalig gespeichert, mit einem JSON-Schlüssel pro tag. Ein generischer WalletConnectRequest unterstützt benutzerdefinierte NIP-47-Methoden mit einer einzelnen Antwort, mit den üblichen Prüfungen von result_type und Fehlern, während multi_pay separat bleibt. Eine erweiterbare RemoteSignerMethod ruft NIP-46-Methoden über den eingebauten Umfang hinaus auf und gibt den Ergebnis-String zurück; in beiden Fällen muss die Wallet oder der Signer die Methode unterstützen. EventTemplate mit signer.sign ermöglicht entfernten NIP-46-Signern die Nutzung von Hilfsfunktionen wie zap-Anfragen, die früher einen lokalen EventSigner erforderten, mit begleitenden Änderungen an mehreren Datenmodellen sowie an NIP-29- und NIP-98-Buildern. Diese Änderung betrifft die API, nicht das Wire-Format.

Code, der nach dem 0.9.0-Tag zusammengeführt wurde, ist nicht Teil dieses Releases. Bricht ein Aufrufer einen Sendevorgang ab, bleiben gesunde relays nun erhalten, und Typen zum Öffnen von DMs und für Ergebnisse sind einfacher, wobei der Rumor-Autor an den Signer gebunden ist. FileAttachment vereinheitlicht die Metadaten verschlüsselter Dateien. Ein einzelnes Paar aus setSigner und removeSigner verhindert, dass ein veraltetes entferntes Setzen eine Abmeldung rückgängig macht; removeSigner beendet AUTH-Antworten, widerruft aber keine bereits gesendeten entfernten Anfragen. Einstellungen für Wiederverbindung und Deduplizierung erhalten eigene Konfigurationstypen.

haps

haps, ein Installer für Software, die mit Nostr-Schlüsseln signiert ist, hat haps v0.1.22 veröffentlicht. Es baut auf haps v0.1.18 auf, das Quell-Builds unter Linux und macOS in einem privaten Home-Verzeichnis und einem beschreibbaren Checkout ausführte, mit standardmäßig deaktiviertem Netzwerkzugriff. Die expliziten Optionen allow-build-network und allow-host-build können dies außer Kraft setzen. Quell-Builds unter Windows erfordern host-build. Installierte Apps bleiben außerhalb der Sandbox. haps v0.1.19 ergänzte eine einzige Bestätigung für Audit und Installation, die die festgelegte Quelle und das Build-Rezept an den Hash der gebauten Nutzlast bindet, sodass ein passendes Binary des Herausgebers unter der Richtlinie dieses geprüften Builds installiert werden kann. Die Wiederverwendung einer vertrauenswürdigen Prüfung zählt nicht als weiteres unabhängiges Audit. Installationen aus unveränderlichen signierten Katalogen erfordern weiterhin ein Audit, und veröffentlichte Warnungen benötigen eine separate Zustimmung, die standardmäßig auf Nein steht. Version 0.1.22 ergänzt begrenzte Abfragen und Herausgeberprüfungen mit vollständiger Quelle. Abfragen teilen sich nun kurze Fristen, wobei der Client Abfragen startet, nachdem sich das erste relay verbunden hat, und Snapshot-Suchen liefern die verifizierten Ergebnisse, die innerhalb eines Budgets von 3 Sekunden gefunden werden. Bevor eine Quellreferenz geändert wird, verweigert die Veröffentlichung die Ausführung, sofern sie nicht einen qualifizierten mitgelieferten Git-Helper findet, einen separat installierten Helper, der zum festgelegten Begleit-Binary passt, oder einen Helper, der complete-blob-dag-v1 bewirbt. Die grundlegende Abdeckung durch Abhängigkeitsprüfungen, Schutzmaßnahmen für Symlinks und Größen sowie begrenzte Wiederholungsversuche bleiben erhalten, was kein neues unabhängiges Audit darstellt. Eine einzige erfolgreiche Kaltinstallation zeigt nicht, dass sporadische Übertragungs-Timeouts behoben sind, und festgelegte Helper-Bundles hängen weiterhin von der Toolchain des Hosts ab.

Swarm schützt seine Admin-API mit NIP-98-Authentifizierung

Swarm, ein mit Nostr verbundener Publishing- und Admin-Server, hat v0.2.0 veröffentlicht, mit NIP-98-HTTP-Authentifizierung für seine Admin-API neben dem bestehenden Dashboard-Cookie. Der Server prüft die Signatur des kind-27235-events, ein Zeitfenster von fünf Minuten in der Vergangenheit bis eine Minute in der Zukunft, die HTTP-Methode, Pfad und Query, den festgelegten pubkey des Betreibers und einen optionalen Payload-Hash. Das Akzeptieren eines weitergeleiteten Hosts setzt einen vertrauenswürdigen vorgeschalteten Proxy voraus. Der früher öffentliche Endpunkt /environment erfordert nun eine Admin-Authentifizierung.

Ein späterer Merge, der noch nicht in einem Release bestätigt ist, ergänzt optionales Crossposting zu X für kind-1-Notizen verknüpfter Teammitglieder. Geplante Notizen und über WebSocket eintreffende Notizen durchlaufen denselben Pfad. Antworten mit e-tags werden übersprungen, nichts wird nachträglich übertragen, und Duplikate werden anhand der Event-ID entfernt. Die CMS-Seite verwendet NIP-98-Authentifizierung. Das Posten hängt von lokalem OAuth oder einem vertrauenswürdigen Delegationsdienst ab, ist also weder dezentral noch vertrauenslos. Das Posten auf dem produktiven X-Dienst wurde nicht getestet.

fips2go aktiviert direkte Verbindungen zu verifizierten Mesh-Domains

fips2go, ein Android-Mesh-Client, der Peers und Domain-Ansprüche über Nostr-Adverts findet, hat die Versionen 0.9.6 bis 0.10.0 veröffentlicht. Version 0.10 aktiviert direkte Verbindungen standardmäßig zu den Servern von bis zu zwei zuletzt verifizierten Domains, wobei nur Domains zählen, die über DNSSEC oder mehrere Resolver festgelegt wurden. Diese Verbindungen legen die öffentliche IP-Adresse des Telefons und seine Online-Zeiten gegenüber diesen Servern offen und verraten öffentlichen relays seine Serverwahl, doch Nutzer können sie abschalten. Ein TXT-Eintrag, der bereits für einen exakten Server und Port festgelegt ist, wird nun ohne neuen Nostr-Anspruch aufgelöst, während neue Server, verschobene Ports und Einträge ohne Port weiterhin warten. Wenn ein Netzwerkwechsel neue VPN-Routen erfordert, die Konfiguration aber unverändert ist, ersetzt die App nur den Tunnel und behält ihren Knoten, ihre Verbindungen und Sitzungen. Hotspot-Änderungen, andere Konfigurationsänderungen und der Fallback bei Fehlern bauen den Knoten weiterhin neu auf.

fips-pub-domains beantwortet festgelegte Abfragen vor dem Abruf von Ansprüchen

fips-pub-domains, das Nostr-signierte Bindungen von öffentlichen Domains an Mesh-Adressen auflöst, hat 0.2.9 und 0.2.10 veröffentlicht. Ein TXT-Eintrag, der für einen exakten Server und Port festgelegt ist, kann nun antworten, bevor der Abruf des Anspruchs im Hintergrund abgeschlossen ist, unter derselben Pin-Richtlinie, während ein neuer Server oder Port weiterhin auf einen Anspruch wartet. Beim Desktop-Start und nach Netzwerkänderungen wärmt der Resolver bis zu 16 festgelegte Server vor, wodurch er ihnen und Routing-Knoten seine Online-Präsenz offenlegt. Während des ersten 20-sekündigen Backoffs versucht er es alle drei Sekunden erneut und endet vorzeitig, sobald ein Server antwortet.

Zwei Änderungen, die nach diesen Tags zusammengeführt wurden, sind unveröffentlicht. Eine ergänzt eine fips-ca-ServiceClaim-Rolle ohne Port und mit eigener DNSSEC-Kette und Attestierung, getrennt von fips-dns, ohne eine neue PKI einzuführen oder die DNS-Bindungsrichtlinie zu ändern. Die andere ergänzt die CLI-Befehle verify und zone, die Pin-Dateien lesen, ohne sie zu schreiben. In diesem Code enthält eine Attestierung nur ihren eigenen vorherigen Zeugen, und Einträge anderer Rollen werden erneut verifiziert. Eine Option require-previous lehnt fehlende Daten ab, kann aber einen Ausfall nicht von einem nicht existierenden Eintrag unterscheiden.

Codr

Codr v0.8.0, eine Brücke zur Steuerung von Desktop-Coding-Sitzungen über verschlüsselte White-Noise-Chats, ergänzt ein Worker-Update, das im Chat bestätigt wird und innerhalb von zehn Minuten erfolgen muss. Es bezieht ngit-Datensätze von einem festgelegten Maintainer und per Prüfsumme verifizierte Blossom-Bytes, ohne Fallback auf GitHub. Es lehnt Änderungen an Connector- oder Speicher-Kohorten ab, und falls der Start fehlschlägt, stellt es die alte ausführbare Datei wieder her. Bisher wurde das Update nur gegen Test-Fixtures ausgeführt. Dateien und Medien erreichen nun eine beschäftigte Sitzung, ohne sie zu unterbrechen, bis zu 25 MiB und vier Anhänge. Die optionale Gemini-Transkription sendet entschlüsselte Sprachnachrichten an Google und ist standardmäßig deaktiviert. Die Releases 0.4 bis 0.7 lieferten Text vom Telefon in beschäftigte Sitzungen, ergänzten /cancel sowie Menüs für Projekt, Agent und Modell und stellten auf MDK 0.14 um. Die Migration von 0.13 funktioniert nur in eine Richtung und erfordert ein Backup und eine Freigabe.

Ein optionaler, nur für den Eigentümer bestimmter Steuerungschat (control_chat=true, standardmäßig deaktiviert) erstellt seine Gruppe beim nächsten Worker-Start. /new startet eine Projektsitzung, bevor ein Chat verknüpft ist. Ist die Erstellung ungewiss, wird sie nicht automatisch wiederholt.

Ein offener Pull Request, der zu unserem Quellen-Stichtag nicht zusammengeführt war, würde es der Gruppenerstellung für eine neue Coding-Sitzung erlauben, ein noch nicht geschriebenes Transkript als leer zu behandeln. Ungültige oder mehrdeutige Transkripte würden weiterhin zurückgewiesen. Dies würde Einladungen per Telefon für neue /new-Sitzungen vor dem ersten Prompt wiederherstellen und nichts daran ändern, wie Sitzungen autorisiert werden.

nostr-media

nostr-media 0.17, ein WordPress-Plugin zum Hosten von Nostr-Medien, härtet das Blossom-Mirroring. Es prüft nun die signierte Hash-Autorisierung vom kind 24242, bevor eine Mirror-URL abgerufen wird, und lehnt nicht autorisierte Anfragen ab, ohne herunterzuladen. Abrufe verwenden die sichere HTTP-API von WordPress, die nur öffentliche HTTP(S)-Hosts zulässt und Weiterleitungen validiert, begrenzt auf 20 Sekunden, drei Weiterleitungen und 128 MiB, und heruntergeladene Bytes werden weiterhin gehasht und geprüft. Die Header Authorization, X-SHA-256 und X-Content-Type werden ohne Beachtung der Groß- und Kleinschreibung abgeglichen. Der Schutz vor Server-Side Request Forgery ist nur so stark wie die sichere API von WordPress.

NosTube

NosTube, eine auf Nostr aufbauende Videoseite, hat Server 0.1.25 und Desktop 0.2.51 veröffentlicht, um einer kompromittierten Zertifizierungsstelle nicht mehr zu vertrauen. Das Rust-relay des Servers vertraut ihr für WebSocket- oder HTTPS-Verbindungen nicht mehr, und Image-Builds erfordern nun ein festgelegtes Debian-System-CA-Bundle. Das Desktop-Release wendet dieselbe Gegenmaßnahme auf seine TLS-Schicht und seinen almond-Sidecar an. Diese Sicherheitsangaben stammen aus den Release Notes. Die späteren Notizen zu Server 0.1.27 sagen DO NOT USE für dieses Image, weil es ein veraltetes libbrotli1 ausliefert, und verweisen auf 0.1.28, dessen Veröffentlichung wir nicht bestätigt haben.

bitchat

bitchat, ein Messenger, der über Bluetooth-Mesh und Nostr läuft, hat 1.8.0 veröffentlicht, mit Leistungsarbeit für Nostr-Standortchats (Geochat) und begrenzten Zeitstempeln bei DM-Rumors. Die App erkennt die eigenen Nachrichten des Nutzers nun anhand der Absender-ID statt des Spitznamens (Korrektur der Absenderidentität). Private Gruppen legen ihren Ersteller fest, und die Mesh-Peer-ID bleibt aus Geohash-DMs heraus. Die Leistungszahlen stammen vom Projekt selbst und wurden von uns nicht reproduziert.

Ein offener Pull Request, der zu unserem Quellen-Stichtag nicht zusammengeführt war, würde den geografischen Chat bei relay-Ausfällen verbunden halten, indem er über die fünf nächstgelegenen relays plus fünf gemeinsame Backups routet, begrenzt auf zehn Verbindungen pro Route (#1822). Nachrichten würden in eine Warteschlange gestellt, bevor das relay-Verzeichnis geladen ist, und Abonnements sowie ausstehende Schreibvorgänge würden ohne Identitätswechsel migriert. Die Validierung stammt vom Autor selbst, und die begleitende Android-Änderung ist ein separater Pull Request.

Ein weiterer offener, ebenfalls nicht zusammengeführter Pull Request würde Live-Video über das Bluetooth-Mesh unter iOS und macOS ergänzen, mit einem eigenen LIVE_VIDEO_V1-Format statt eines Nostr-Transports. Öffentliche Frames würden signiert und auf Aktualität geprüft. DM-Frames würden innerhalb der Noise-Verschlüsselung übertragen; Aufnahmen würden als Nachrichten gesendet. Der Autor berichtet, dass ein Stream von Android zum iPhone empfangen wurde. Das Senden von einem iPhone, iOS-zu-iOS-Paare und DM-Live-Video sind ungetestet.

ngit

ngit, das Kommandozeilenwerkzeug für Git-Zusammenarbeit über Nostr, hat v3.0.4 veröffentlicht. Relay-Verbindungen sowie HTTPS unter Android vertrauen einer kompromittierten Zertifizierungsstelle nicht mehr. Interaktive Eingabeaufforderungen schützen nun vor leeren Eingaben, und Befehle beachten Offline-Filter. Aktualisierungen von Remote-Tracking-Zweigen bewahren Commits, die noch nicht veröffentlicht wurden. Die Diagnose unterscheidet außerdem eine fehlende Quelle von einer Abfrage, die keine Ergebnisse geliefert hat.

Hasheus

Das Dateiverifizierungswerkzeug, das früher verify hieß, heißt nun Hasheus und hat 2.0.0 veröffentlicht. Es prüft Dateien gegen auf Nostr veröffentlichte Hashes, übernimmt nun Beschreibungen und URLs von vertrauenswürdigen Verifizierern und hasht große Dateien in Blöcken. Das Verifiziert-Banner erscheint nur bei der exakt veröffentlichten Datei. Außerdem verarbeitet es fehlerhafte Profile, dedupliziert Verifizierer und meldet einen Fehler bei einem fehlenden relay. Eine übereinstimmende Prüfsumme bestätigt die Datei, nicht die Aussagen des Herausgebers über sie.

Alby JS SDK

Albys JavaScript-SDK hat 9.0.0 veröffentlicht. NWC-Clients geben nun jeder veröffentlichten Anfrage eine feste Wartezeit von 5 Sekunden für das OK des relays und schlagen mit Nip47PublishTimeoutError fehl, wenn es nicht eintrifft, während die Antwort-Timeouts pro Methode unverändert bleiben. Eine Antwort, die sich nicht entschlüsseln lässt, führt nun zu einer Ablehnung, und der Fehlertext des relays bleibt erhalten (Behandlung von Anfragefehlern). Der Breaking Change entfernt die veralteten multi_*-Methoden, und Code, der Nip47SingleMethod verwendet, sollte auf Nip47Method umsteigen. Ein OK des relays bedeutet, dass das relay die Anfrage angenommen hat, nicht, dass eine Zahlung erfolgreich war.

Alby Hub

Alby Hub, ein selbst gehosteter Lightning-Knoten, der Wallets über Nostr Wallet Connect bereitstellt, hat 1.24.4 veröffentlicht. Der Patch entfernt das Vertrauen in eine kompromittierte Zertifizierungsstelle aus seinen nativen LDK- und Go-TLS-Verbindungen, von denen der NWC-Wallet-Dienst des Hubs abhängt. Außerdem behebt er den Start des CLN-Hold-Invoice-Plugins.

Orchard

Orchard, ein Flatpak-Softwarekatalog, hat 0.3.0 veröffentlicht. Das Release verbindet Interoperabilität von Software-Releases mit NIP-82 und die Vorbereitung von Flatpak-Assets für die Veröffentlichung über ngit oder andere NIP-82-Werkzeuge. NIP-82 ist eine vorgeschlagene Spezifikation für Softwarekataloge, die weder zugewiesen noch angenommen wurde, daher implementiert Orchard einen Entwurf, der sich noch ändern kann.

Bell

Bell, ein Android-Aggregator für Nostr-Unterhaltungen, sammelt Antworten und Zitate für mehrere Konten in einer chronologischen Liste. Seine Notizen zu 0.1.0 schließen Likes, zaps, einfache Reposts und allgemeine Erwähnungen aus, und Konten signieren über Amber oder bleiben reine Beobachtungskonten. Die Releases 0.6.0 bis 0.9.0 ergänzten Stummschaltregeln pro Konto und eine Ansicht nur für Ungelesenes mit Mehrfachauswahl zum Als-gelesen-Markieren. Ihre Notizen besagen, dass die Wiederherstellung exakt signierte Antworten und Reaktionen ohne automatische Duplikate beibehält. 0.10.0 und 0.10.1 ermöglichen es Nutzern, einzelne Beiträge auf dem Gerät auszublenden, mit Rückgängigmachen und Wiederherstellen. Das Ausblenden löscht nichts von relays, und neue Antworten erscheinen weiterhin. Spam-Meldungen betreffen sowohl den Beitrag als auch seinen Autor, werden öffentlich von einem ausdrücklich gewählten Konto gesendet und wirken nicht als private Blockierungen. 0.11.0 ergänzt Reposts, nachdem Nutzer den ursprünglichen Beitrag und das sendende Konto geprüft haben. Ein Konto-Avatar legt fest, wer antwortet, reagiert oder repostet. Dass Reposts veröffentlicht werden können, bedeutet nicht, dass Benachrichtigungen über einfache Reposts nun aggregiert werden. Zwischengespeicherte Threads können unvollständig bleiben, und das optionale Hintergrund-Lauschen hängt von den Energie- und Netzwerkregeln von Android ab, ohne Zusage einer ständig aktiven oder sofortigen Zustellung.

SkateSpots

SkateSpots ist eine Community-Karte von Skatespots und Shops. Version 1.7.4 ergänzte einen Ende-zu-Ende-verschlüsselten Community-Chat, in dem ein Community-Bot neue Geräte automatisch freigibt und Admins sie ebenfalls freigeben können. 1.7.0 machte das Community-relay zur maßgeblichen Quelle für Spots und Shops. 1.7.3 korrigierte Android-Einladungs-QR-Codes für den privaten Crew-Chat, der in früheren Releases eingeführt worden war. Die Releases 1.7.8, 1.7.10, 1.7.15, 1.7.19, 1.7.20, 1.7.21 und 1.7.22 erweitern diesen Crew-Chat. Anders als bei der Bot-Freigabe im Community-Chat gibt ein bestehendes Crew-Mitglied neue Geräte per QR frei, Mitglieder und Geräte können entfernt werden, und die Beförderung eines Gründers veröffentlicht den Admin-tag erneut. Reaktionen, Lösch-Tombstones und Lesebestätigungen werden als verschlüsselte MLS-Steuerelemente übertragen. Tombstones sind keine endgültigen Löschungen auf relays, und automatische Bestätigungen kommen nur von stillen Signern. Ein Hintergrundbeobachter verwendet den eigenen Schlüssel des Mitglieds, niemals einen Admin-Schlüssel, und wandelt Beitrittsanfragen etwa einmal pro Minute in NIP-17-DMs oder Glockenhinweise um. Für Amber-Nutzer warten Beitrittshinweise, bis die Glocke geöffnet wird, während stille Signer sie vorab laden können, sodass Amber nicht im Hintergrund zur Bestätigung auffordert. Ungelesen-Zähler verwenden ausstehende NIP-17-Umschlag-IDs, ohne sie zu entschlüsseln, schließen die eigenen gesendeten Kopien des Nutzers aus und legen keinen Betreff offen und bestätigen auch keinen. Eine sofortige oder kontinuierliche Zustellung im Hintergrund ist nicht garantiert. Die Releases 1.7.19 bis 1.7.22 ergänzen außerdem eine globale Datensatzsuche, die nur läuft, solange die Befehlspalette geöffnet ist, und merken sich den Zustand von Karte und Ebenen. Wir haben diese Änderungen weder unabhängig auf Geräten getestet noch einem Sicherheitsaudit unterzogen.

Emanator

Emanator, ein Nostr-Client für mehrere Konten, kann in Version 1.5.0 nun private Unterhaltungen nach NIP-17 beginnen, während frühere Versionen nur auf bestehende Threads antworten konnten. Nutzer wählen ein für Nachrichten freigeschaltetes Absenderkonto und suchen dann Kontakte nach Name oder NIP-05 oder fügen eine npub oder ein nprofile ein. Bestehende Unterhaltungen werden wiederverwendet, und wenn der Empfänger kein DM-Postfach angibt, bietet die App eine Zustellung nach bestem Bemühen sowie eine Legacy-Option an. Unter 1.4.1. Wiederholungsversuche behalten bereits akzeptierte signierte Events bei. Nur alte Events, die kein relay akzeptiert hat, können neu signiert und neu datiert werden.

Feather

Feather, ein Nostr-Client für Android, über den zuletzt in Ausgabe #45 während seiner 0.9-Reihe berichtet wurde, ist inzwischen bei 1.8.4 angekommen. Die Versionshinweise der 1.x-Reihe ergänzen natives Durchsuchen und Melden von NIP-34-Issues über die von einem Repository angegebenen relays. Signierte Aktionen warten nun in einem Postausgang auf dem Gerät, den WorkManager im Hintergrund zustellt, wobei übergeordnete Beiträge vor Antworten gesendet werden. 1.8.0 bringt Bildbeiträge mit kind 20 samt gespeicherten Entwürfen und Offline-Zustellung, und 1.8.4 ergänzt optionales Stummschalten nach einer erfolgreichen Meldung. Seit 1.7.0 laufen Übersetzungen über die separate App Offline Translator und deren Sprachpakete, ohne Cloud-Fallback.

OUTKAST

OUTKAST, ein Nostr-Client für Android, ergänzt in 2.2.1 eine Netzwerk-Entdeckung auf dem Gerät, die Notizen von nicht gefolgten Konten anzeigt, die Personen, denen man folgt, in den letzten 48 Stunden geliked oder geteilt haben. Laut den Versionshinweisen zählt das Ranking Reaktionen, Antworten und zaps nach Anzahl (nicht nach sat-Beträgen) und gewichtet dann die Zahl der Freunde und die Aktualität, ohne Ranking-Server. Sobald man 40 oder mehr Konten folgt, braucht eine Notiz mindestens zwei Freunde dahinter. Die Ergebnisse enden bei 100 Notizen, ohne ältere Seiten. Die Hinweise beschreiben außerdem eigene Feeds aus ausgewählten Personen oder Listen sowie einen Foto-Editor, der Bearbeitungen als metadatenfreie JPEGs speichert, während unveränderte Originale unangetastet hochgeladen werden.

CustID

CustID, eine Nostr-Signer-App, verlangt in 0.2.2-beta nun eine biometrische Freigabe für NIP-46-ASK-Anfragen bei biometrisch geschützten Identitäten, wobei eine kürzlich erfolgte Authentifizierung die Abfrage erfüllen kann. Gespeicherte Regeln zum Genehmigen und Ablehnen, einschließlich älterer Genehmigungen, gelten nun stillschweigend sowohl über NIP-46 als auch über NIP-55. Beim Aktivieren der automatischen Genehmigung erscheint zunächst eine Warnung zur Bestätigung, und ein Abbruch ändert nichts. Die Beta fügt außerdem NIP-89-Client-tags zu den von ihr veröffentlichten Events hinzu. Sie sind standardmäßig aktiv und zeigen Lesern, welche App ein Event veröffentlicht hat; eine Datenschutz-Einstellung schaltet sie ab.

Nostr Vault

Nostr Vault, ein Nostr-Client, ergänzt in 3.0.0 optionale FIPS-Geräteverbindungen, die per Adresse oder QR-Code gekoppelt werden, sodass ein Mac oder ein Ersatz-Smartphone zu Hause als Tresor dienen kann. Der Tresor synchronisiert Notizen und Verlauf, holt vorhandene Fotos über das Mesh und startet, sobald das Mesh aktiviert ist, nach einem Neustart zusammen mit dem relay. Öffentliche Medienbeiträge benötigen weiterhin einen öffentlichen Medienserver. Die Version behebt außerdem kontoübergreifende Race Conditions bei Follows und Registrierung, wartet auf die Bestätigung eines Beitrags durch die eigenen Schreib-relays des Nutzers, bevor sie Erfolg meldet, und hält DMs von Fremden hinter „Anfragen“ zurück.

Holoboard

Holoboard, eine Pinnwand, auf der Nutzer für das Platzieren von Beiträgen bezahlen, veröffentlicht Android 1.1.0 zusammen mit einem geführten Ablauf „Zur Pinnwand hinzufügen“ auf Website und Backend, der mit der Zahlung endet. Gäste können Text und Links oder einen bestehenden Nostr-Beitrag einreichen. Vorbereitete Rechnungen lassen sich im selben Browserprofil auf demselben Gerät fortsetzen, und der Rechnungs-QR-Code bleibt ohne Konto oder verbundene Wallet verfügbar. Für sich genommen aktualisiert die APK nur das Launcher-Symbol und den Startbildschirm, die Änderungen an der Pinnwand hängen also von der passenden Website und dem Backend ab. Eine Anmeldung per E-Mail oder Passwort gibt es nicht.

Hopp

Hopp, eine Podcast-App mit Value-for-Value-Boosts, geht über die in Ausgabe #45 behandelten Identitäts- und Zahlungsarbeiten der 0.2.x-Reihe hinaus. Version 0.3.0 ergänzt verschlüsselte geräteübergreifende Synchronisierung und Wiederherstellung über Nostr, ohne Hopp-Server, für Abonnements, Fortschritt, Favoriten, Up Next, Hörgewohnheiten und Download-Einstellungen. Beim Wiederherstellen bleibt die bestehende Bibliothek erhalten, und eine Statusansicht zeigt relay- und Ausstehend-Status. Laut den Hinweisen sind Boost-Anteile mit unbekanntem Ergebnis gegen doppelte Wiederholungsversuche abgesichert, und Budgets berücksichtigen nun Release Boosting und Boost2Unlock.

Nostrautica

Nostrautica, eine Begleit-App für Veranstaltungen, ergänzt in 0.15.1 Offline-Veranstaltungspakete, die Personen, Matches, Vorträge, die Veranstaltungsseite, Beiträge und Profilbilder für Veranstaltungsorte mit schwachem Empfang speichern. Der Chat erhält Erwähnungsnamen sowie Bearbeitungen mit Löschungen, und ausstehende Sendungen können erneut versucht oder verworfen werden. Version 0.16.0 wechselt zu MarmotKit 0.14, einer Bibliothek für Marmot-Gruppennachrichten, für das Offline-Nachholen mit weniger Gruppen-relay-Verbindungen, und behält ungelesene Nachrichten bei der Aufbewahrungsbereinigung bei. Die Speichermigration ist einseitig, ältere App-Versionen werden danach also nicht mehr unterstützt. Die Hinweise geben an, dass sich an der Interoperabilität mit dem Messenger White Noise oder dem Web nichts ändert.

Staircase

Staircase, eine Nostr-Gruppenchat-App von relay.tools, ergänzt in 0.1.25 einen Benachrichtigungsmodus „Häufig“, der etwa alle 5 oder 10 Minuten prüft und dann die Verbindung trennt. Im Tiefschlaf entscheidet die Android-Planung über den Zeitpunkt, die Zustellung im Hintergrund ist also weder sofort noch garantiert. Die Modi „Periodisch“ und „Häufig“ führen bei Rückkehr des Netzwerks eine begrenzte Prüfung aus, höchstens alle zwei Minuten; der Modus „Sofort“ bleibt unverändert. Der Status eines Gruppenbeitritts wartet nicht mehr, sobald eine Anfrage bearbeitet wurde oder abläuft, ohne anzugeben, was davon eintrat. Eigene Koordinator-relays bleiben unter der Kontrolle des Nutzers und werden nicht durch eine veröffentlichte Liste überschrieben.

In Entwicklung

Coracle

Coracle, ein Nostr-Webclient, hat eine Routing-Korrektur in master gemergt. Ein Klick auf einen Menüpunkt wie Listen oder Gruppen, während genau dieses Modal bereits oben liegt, bewirkt nun nichts. Bisher stapelte jeder Klick ein weiteres identisches Panel. Escape schloss sie eines nach dem anderen. Unterschiedliche Modals und die normale Seitennavigation funktionieren wie bisher. Dies ist gemergter Quellcode, nicht an eine Version gebunden.

nostter

nostter, ein Nostr-Webclient, hat fünf Korrekturen an seinem zap-Ablauf gemergt. Eine Nostr-Wallet-Connect-Antwort auf pay_invoice gilt nun nur mit dem richtigen Ergebnistyp und einem gültigen Preimage als Erfolg, wobei das Fehlerfeld null ist oder fehlt. Fehlerhafte Antworten werden abgelehnt. Der dedizierte rx-nostr-Client wird immer freigegeben, auch wenn die Einrichtung fehlschlägt. Zehn Sekunden ohne Antwort der Wallet werden als unbekanntes Ergebnis gewertet, nicht als Fehlschlag. Rechnungs- und Signierfehler erscheinen direkt im Dialog und behalten Betrag und Kommentar für einen erneuten Versuch, und Rechnungsfehler werden getrennt von NWC-Fehlern gemeldet. Der zap-Button bleibt aktiviert für wiederholte zaps. Seine orangefarbene Markierung erscheint auch, wenn eine QR-Rechnung angezeigt wird, was nicht bestätigt, dass eine manuelle Zahlung durchging. Das erneute Öffnen des Dialogs setzt ihn nur im Leerlauf zurück. Wird er geschlossen, nachdem Rechnung oder Signatur eingetroffen sind, unterbleibt eine neue NWC-Zahlung, eine bereits übermittelte Zahlung läuft jedoch weiter.

Ein offener Pull-Request würde eine Warnung anzeigen, vor dem Bezahlen über den QR-Fallback nach einem unbekannten Ergebnis den Wallet-Verlauf zu prüfen, und würde das automatische Öffnen der Wallet unterdrücken. Ein Timeout bedeutet nicht, dass die Wallet nichts abgebucht hat.

Pollerama

Pollerama, ein Client für Umfragen und Feeds, hat eine Anfragewarteschlange pro relay gemergt. Die Warteschlange passt an, wie viele Anfragen gleichzeitig laufen, weicht zurück, wenn ein relay die Rate begrenzt, teilt übergroße Filter auf und normalisiert relay-URLs. Die Ansicht „Meine Pakete“ hält nun ein dauerhaftes Abonnement, sodass auch langsame relay-Antworten noch erscheinen. Bekannte Probleme mit erneuten Anfragen in der App bleiben offen, und Direktnachrichten wurden mit dieser Änderung nicht getestet.

Grimoire

Grimoire, ein sozialer Nostr-Client, hat Korrekturen an der Synchronisierung von Direktnachrichten gemergt. Der Verlaufscursor rückt nicht mehr bei zusammengeführten relay-Seiten vor, die nur teilweise zurückreichen, und eine Abbruchsicherung verhindert, dass ein Entschlüsselungsdurchlauf Nachrichten und Gelesen-Markierungen wieder auffüllt, nachdem die Abmeldung sie gelöscht hat. Ein abgebrochenes Nachladen stoppt, bevor es den Cursor bewegt oder den Verlauf als erschöpft markiert. Lücken bleiben: Ein einzelnes antwortendes relay kann den Verlauf weiterhin als erschöpft markieren, während bei anderen etwas fehlt, und eine dauerhafte Ablehnung durch einen Signer lässt den Cursor weiterhin vorrücken.

nostr-vpn

nostr-vpn, ein VPN, das Nostr-Schlüssel zur Peer-Erkennung nutzt, hat eine Korrektur der mobilen Wiederverbindung gemergt. Wenn eine Erkennungsprobe ohnehin fällig ist, aktiviert der Client erschöpfte Pfade zu bekannten Peers nun erneut. Das geschieht nur, wenn in letzter Zeit nichts empfangen wurde und kein verbundener oder ausstehender Pfad existiert, und höchstens einmal alle 300 Sekunden. Gesunde und ausstehende Pfade bleiben unberührt, und das Wire-Format ist unverändert. Der Autor hat die Korrektur gegen eine isolierte native Testumgebung getestet, nicht in Mobilfunknetzen. Eine zweite gemergte Änderung entfernt Netzwerk-Beitrittsgeheimnisse aus Doctor-Bundles, indem sie das Beitrittsgeheimnis der Registrierung und den rohen Daemon-Zustand aus der Diagnoseausgabe weglässt. Der private Nostr-Schlüssel war dort bereits geschwärzt. Vor dieser Änderung geteilte Bundles bleiben offengelegt, wer also eines geteilt hat, sollte die betroffenen Beitrittsgeheimnisse rotieren.

Mehrere verwandte Änderungen sind noch offene Vorschläge und wurden weder gemergt noch veröffentlicht. Für gespeicherte Geheimnisse würde einer Netzwerk-Beitrittsgeheimnisse im Geheimnisspeicher der Plattform ablegen, über den bestehenden Migrationspfad. Ein anderer würde Sidecar-Geheimnisse von Windows-Rechnern auf SYSTEM und Administratoren beschränken, was die DPAPI-Dateien mit den Nostr-Knotenschlüsseln abdeckt. Diese Beschränkung greift erst beim nächsten Schreiben einer Datei, und zwischen Dateierstellung und ACL gibt es eine kurze Lücke. Eigene Konfigurationspfade sind nicht abgedeckt, und der Autor hat nicht auf einem Windows-Rechner mit mehreren Benutzern getestet. Für signierte Mitgliedschaften würde ein Vorschlag Beitrittsgenehmigungen ablehnen, deren Roster-Snapshot nicht mehr mit dem Datenträger übereinstimmt, sodass der Admin neu lädt und es erneut versucht, wobei gleichzeitig genehmigte Geräte erhalten bleiben. Ein anderer würde fünf Minuten Uhrabweichung beim Admin erlauben und stets einen konfigurierten Beitritts-Signer verlangen, auch wenn die lokale Admin-Liste leer ist, während die Bindung an das Anfragegeheimnis erhalten bleibt. Ein dritter würde Gleichstände zwischen Rostern mit identischem Zeitstempel anhand des Artefakt-Hashs auflösen. Peers, die beide Roster sehen, würden denselben einzelnen Roster wählen; jeder behält seine eigenen Mitgliedschaftsinhalte. Ein letzter Vorschlag würde eine Bestätigung für Beitrittsanfragen per Deep Link und für kostenpflichtige Exit-Anbieter verlangen. Beitrittslinks unter macOS und Linux würden auf einen expliziten Schritt „Gerät hinzufügen“ warten. Unter macOS würden außerdem Links kostenpflichtiger Anbieter bis zur Bestätigung zurückgehalten. Ein nativer Betrieb auf einer der beiden Plattformen wurde nicht vorgeführt. Alle Testergebnisse stammen vom Autor.

Buzz

Buzz, ein Community-relay mit Desktop- und Mobil-Clients, hat Arbeiten an Gruppen und Agenten gemergt. Agenten können sich gemäß der JWT-Spezifikation NIP-FI des Projekts authentifizieren, die den vom Aussteller angegebenen menschlichen Eigentümer verifiziert; wird dieser Eigentümer abgelehnt oder getrennt, enden die Sitzungen seiner Agenten, und die Community-Mitgliedschaft des Eigentümers kann einen Agenten zulassen. Huddles akzeptieren außerdem verifizierte Datensätze verwalteter Agenten vom aktuellen Nutzer oder vom Huddle-Eigentümer, zusätzlich zur Bot-Rolle mit Eigentümerbestätigung nach NIP-OA. Dieser Fallback ist eine Kompatibilitätsrichtlinie und vertraut keinen unbekannten Datensätzen Dritter. Er ist kein Identitätsnachweis. Keine der beiden Spezifikationen ist ein akzeptiertes NIP.

Offene Ankündigungskanäle können Gäste mit Lesezugriff über join_role=guest zulassen, und nicht gelistete offene Kanäle sind für Nichtmitglieder in der Entdeckung verborgen, aber für jeden mit der Kanal-ID lesbar. Zulassungs-Events können bis zu 100 Mitglieder hinzufügen, wobei Teilerfolge möglich sind. Die Korrektur der Kanaleinstellungen, letzte Woche als offener Vorschlag gemeldet, ist nun gemergt: Änderungen werden in einer Transaktion zusammen mit ihren Anfragen und Hinweisen festgeschrieben. Ein fehlgeschlagener Wechsel von öffentlich zu privat wird vollständig zurückgerollt, was verhindert, dass entfernte Mitglieder durch dieses Zurückrollen wieder auftauchen. Auf Mobilgeräten bringen Fehler bei der Push-Einrichtung die App nicht mehr zum Absturz; sie versucht es eine begrenzte Anzahl von Malen erneut und bietet eine manuelle Wiederherstellung an, wobei es Tests mit gemockten Kanälen gibt und das Verhalten von APNs-Geräten unverifiziert ist. Synchronisierte Stummschaltungen führen nicht mehr zu einem leeren Start, da nun mit den tatsächlichen DM-Push-Abonnements abgeglichen wird; diese Korrektur stützt sich auf ein einziges iPhone-Log. Im relay-Mesh laufen tote Peer-Einträge ab, nach fünf Minuten ohne Heartbeats, während aktive Verbindungen ausgenommen sind.

Neuere Merges sind in keiner Version bestätigt. Mitgliedschaftsergänzungen mit kind 9000 werden nun zusammen mit ihren Roster-Schreibvorgängen festgeschrieben: Eine fehlgeschlagene Änderung speichert keines von beiden, und dasselbe signierte Event kann erneut versucht werden. Die kinds 9001, 9021 und 9022 behalten die alte Lücke. Diagnosen im Shadow-Modus von NIP-FI protokollieren nun den verifizierten Nostr-Schlüssel und einen festen privaten Grund für Fälle, die abgelehnt würden, ohne Tokens oder Claims zu protokollieren. Das ändert nichts an Zulassung oder Durchsetzung. Buzz’ eigene Agenten-Spezifikation NIP-AP, ein Projektdokument außerhalb der akzeptierten NIPs, verlangt nun ein clientdefiniertes agentType in den Einstellungen. Starts mit den Einstellungen eines anderen Typs werden abgelehnt, ein fehlendes Feld behält seine bisherige Bedeutung, und ein Typwechsel kann die verschachtelten Einstellungen des alten Typs verwerfen. Die Auswahl einzelner Agenten schlägt bei fehlerhaften neuesten Richtlinien für verwaltete Agenten mit kind 30177 sicher fehl. Ältere Daten bleiben ausgeschlossen. Sie beschriftet Agenten mit ihrem vom Eigentümer verwalteten Namen, während Bilder und Nachrichtenautoren weiterhin Profile verwenden.

Auf Mobilgeräten nutzt das Erstellen, Auflisten und Löschen gehosteter Agenten den Eigentümernachweis nach NIP-OA und Registrierungen mit kind 30177 mit dauerhaften Wiederholungsversuchen unter derselben Identität und bewahrt private Anweisungen im sicheren Speicher auf. Die Freigabe für gehostete Agenten zur Build-Zeit ist in App-Store- und internen Builds deaktiviert, es handelt sich also nicht um eine öffentliche Verfügbarkeit. Der Kaltstart über eine Einladung für gehostete Instanzen unter iOS behält die Einladungsabsicht bei, importiert einen passenden Schlüssel und stellt aus einem Backup wieder her. Nur der Autor hat den Hauptpfad getestet, und der Fallback-Endpunkt für Mitgliedschaften sowie die Neuregistrierung bleiben ungelöst. Die Wiederherstellung der Push-Registrierung wartet mit exponentiellem Backoff und ersetzt dann eine gespeicherte, mit 401 abgelehnte Anfrage durch eine begrenzte neue Challenge und einen App-Attest-Schlüssel. Nach 400 oder vorübergehenden Fehlern behält sie die Absichten bei und behandelt ein gewöhnliches 404 normal. Diese Wiederherstellung wurde nicht auf echten Geräten geprüft. Nachrichtenlinks zu öffentlichen Kanälen, denen der Nutzer nicht beigetreten ist, holen Metadaten mit kind 39000 und öffnen schreibgeschützt, während die Sperren für private Kanäle und DMs unverändert bleiben. Links werden während Wiederverbindungen in eine Warteschlange gestellt, und eine einzelne langsame Abfrage kann spätere Links um bis zu acht Sekunden verzögern.

Mehrere offene Pull-Requests waren zu unserem Quellenstichtag nicht gemergt. Eine standardmäßig deaktivierte Fähigkeit buzz_v1 würde den clientseitigen Lesestatus durch aufruferprivate NIP-98-APIs für Seitenleiste, Lesestatus und Abdeckung ersetzen, dazu Revisionen pro Person und nur über das relay laufende Invalidierungs-Pings mit kind 24300. relays ohne diese Fähigkeit behalten NIP-RS, und große Datenbanken müssen ihre Indizes zuerst nebenläufig aufbauen. Thread-Zusammenfassungen würden nur die neuesten 1.000 Antworten durchsuchen, die neuesten 10 Autoren zurückgeben und Live-Updates höchstens einmal pro Sekunde pro Pod senden, würden also nicht jeden früheren Teilnehmer auflisten. Antworten von Agenten auf Reaktionen würden unter der Nachricht eingeordnet, auf die reagiert wurde, anhand des letzten gültigen NIP-25-tags e, mit Rückfall auf den alten Anker. Von Hermes gestützte Agenten würden eine agentenbezogene MCP-Shell zum Posten in Kanälen und DMs erhalten. Sie verweigert die Ausführung ohne ihre Bridge und schwärzt Zugangsdaten, aber Installation, Neustart und Live-Posten sind unverifiziert. Eine Korrektur des ACP-Adapters würde sowohl die v1- als auch die v2-Initialisierungsnamen senden, auf das stabile v1 zurückfallen und die validierte Hauptversion festschreiben. Das repariert den Agententransport und ist keine Änderung am Nostr-Protokoll. Vorlesen auf Mobilgeräten würde die Sprachausgabe des Telefons nutzen und Code, Links und Anhänge überspringen. Die vom Nutzer gewählte Engine bestimmt, wo die Sprache verarbeitet wird. Ein eigenständiger relay-Lastgenerator würde Menschen und NIP-OA-Agenten simulieren und Läufe als fehlgeschlagen werten, die festgelegte Fehler- und Latenzgrenzen überschreiten. Er ändert keinen relay-Code und belegt keine Skalierbarkeit im Produktivbetrieb.

Mosaico

Mosaico, ein Daemon, der Agenten in relay-basierten Gruppen (NIP-29) koordiniert, hat Heartbeat-basierte Anwesenheit gemergt. Ein Agent gilt nun nur so lange als in einem Kanal anwesend, wie er ein Status-Event mit einem Ablaufzeitstempel (NIP-40) veröffentlicht, der 90 Sekunden in der Zukunft liegt und alle 30 Sekunden erneuert wird. Ein lokal laufender Prozess zählt für sich allein nicht mehr als Anwesenheit. Die Mitgliedschaft bleibt bestehen, während ein Agent offline ist, sodass er weitermachen kann. Ein neu aufgebautes Lesemodell für Gruppen wird einmal pro relay-Änderung mit einem kanonischen Ankunftscursor erstellt, sodass beim Ersetzen eines breiten Gruppenabonnements kein Chat mehr verloren geht.

Drei spätere Merges sind in keiner Version bestätigt. Ersatzabonnements verwenden nun neue REQ-IDs und werden geöffnet, bevor das alte geschlossen wird. Ein ausgemustertes Profil wird außerhalb des latenzkritischen Pfads veröffentlicht, und ein Agent, der einen Kanal verlässt, zieht seine Anwesenheit zurück, während er noch NIP-29-Mitglied ist. Die zugrunde liegenden Messungen stammen vom Autor, nicht von uns. Die Claim-first-Abrechnung von Wiederholungsversuchen wird dauerhaft in Schema 27 gespeichert und übersteht ein relay-Replay. Sie weicht exponentiell von 30 Sekunden bis zu einer Stunde über einen einzigen seriellen Timer zurück und gibt nach 10 Fehlschlägen auf. Ein fehlendes Event wird nicht als Löschung behandelt, und da das aufbewahrte Fenster 4.096 Einträge umfasst, ist die Zustellung jedes Events nicht garantiert. Reine Gruppen-Snapshots wecken nun Gruppen-Konsumenten, und Ersetzungen mit gleichen Zeitstempeln behalten die niedrigste Event-ID, wie es NIP-01 vorschreibt. Reine Inhaltsänderungen wecken weiterhin den allgemeinen Konsumenten. Ein begrenzter Fallback für ein fehlendes übergeordnetes Element wartet unter Umständen auf die nächste Gruppenänderung oder einen Timeout von 15 Sekunden.

Sonar

Sonar, ein Messenger, der Nostr, MLS-Verschlüsselung und ein Bluetooth-Low-Energy-Mesh kombiniert, hat eine Startkorrektur für Mobilfunkverbindungen gemergt. Der PR führt das langsame erste Rendern darauf zurück, dass die Anbindung des Push-relays eine Speichersperre hält. Unter Android überspringt der Start diese Sperre, wenn der lokale Knoten bereits geöffnet ist, etwa wenn die Push-Registrierung ihn vor dem Kaltstart geöffnet hat. Unter iOS weist die App die Notification Service Extension an, das Verbinden und Abarbeiten zu beenden, damit die App rendern kann.

Shopstr

Shopstr, ein Nostr-Marktplatz, hat die Unterstützung für das Löschen von Angeboten gemergt, die letzte Woche vorgeschlagen wurde. Eine signierte Löschanfrage für Events (NIP-09) eines Verkäufers entfernt das Angebot nun aus dem Cache und versieht es mit einem Tombstone, sodass ein gelöschter Artikel nicht wieder auftauchen oder aus dem Cache gekauft werden kann, während neuere Wiedereinstellungen weiterhin angezeigt werden. Einige Löschungen werden weiterhin verpasst: Eine Löschung, die vor ihrem Angebot eintrifft, wird ignoriert, ältere Anfragen ohne k-tag passen nicht zur relay-Abfrage, und frühere Löschungen werden nicht nachträglich verarbeitet. relays können die gelöschten Events zudem behalten. Unabhängig davon blockieren fehlerhafte Gift-Wrap-Nachrichten die Ansichten „Bestellungen“ und „Meine Angebote“ nicht mehr, und Verkäufer können nun ihre eigenen Bestellungen einsehen, während andere Nutzer weiterhin ein 403 erhalten.

Drei offene Pull-Requests, zu unserem Quellenstichtag nicht gemergt, zielen auf die Integrität von Bestellungen. #665 würde die Beteiligten jeder Bestellung einmalig über eine NIP-98-Registrierung erfassen, wobei der Käufer aus der Authentifizierung und der Verkäufer aus dem signierten Angebot übernommen wird, und spätere Schreibvorgänge könnten sie nicht ändern. Eine fehlgeschlagene Registrierung würde den Checkout nicht aufhalten, und neue ungeklärte Bestellungen würden nicht aus tags erraten. Ältere Bestellungen sind nur bis zu einem begrenzten Stichtag abgedeckt, und eine Lücke bei der Speicherung des Status nach Bestell-ID bleibt unbehoben. #666, das von #665 abhängt, würde gift-wrapped (NIP-59) Bestellstatusnachrichten nur dann anwenden, wenn sie vom erfassten Käufer oder Verkäufer der Bestellung stammen, nicht von irgendeinem authentifizierten Absender. Ungeklärte Bestellungen bleiben ausstehend, die Bestätigung eines Käufers nach der Zahlung zählt nicht als Bestätigung des Verkäufers, und gefälschte Nachrichten bleiben als Chat bestehen, ohne den Bestellstatus zu ändern. #664 würde die Token-Metadaten von Cashu-v2-Keysets für Treuhandregistrierung und Entscheidungen ohne Keyset-Abfrage über das Netzwerk lesen und die Summe der Proofs korrigieren. Die Token-Dekodierung beim Erstellen von Bestellungen braucht weiterhin eine separate Korrektur.

Conduit

Conduit, ein Nostr-Marktplatz mit gekoppelten Apps für Käufer und Händler, hat einen einzigen verschlüsselten Kontodatensatz gemergt. Wallet-Metadaten, Seed, native Identität, Adresse, Einstellungen und Einrichtungsfortschritt liegen nun in einem einzigen Datensatz für beliebige benutzerdefinierte App-Daten (NIP-78), verschlüsselt mit versionierten verschlüsselten Payloads (NIP-44) und auf Signatur, Eigentümer und abgeleitete Identität geprüft; beide Apps finden ihn, sobald der Signer zustimmt. Die Umstellung ist nicht abwärtskompatibel: Ältere Backup- und Wiederherstellungspfade werden ignoriert, und Legacy-Backups bleiben ohne automatische Migration bestehen. Andere Merges ergänzen die Anmeldung mit einem vorhandenen nsec, der im lokalen Browserspeicher abgelegt wird, verlangen exakte signierte Versandbedingungen beim Bearbeiten von Produktfamilien und verlagern die Checkout-Wiederherstellung nach IndexedDB, mit Rücklesen, bevor sie als gespeichert markiert wird.

Conduit ist außerdem auf NWC SDK 8.1.1 umgestiegen, was dessen Betragsvalidierung, begrenzte Verbindungsversuche, Behandlung geschlossener Pools und Korrekturen für laufende Antworten mitbringt. Conduits Wallet-Auswahl, Verschlüsselung und Zahlungsrichtlinie sind unverändert. Die Bereitstellung der App ist weiterhin unbestätigt. Zwei Entwurfs-Pull-Requests waren zu unserem Quellenstichtag noch nicht gemergt. Die Zahlungsaktivierung würde den Zahlungsstatus innerhalb eines festen zweiminütigen Ausführungsfensters, das durch Wiederholungsversuche nicht zurückgesetzt wird, speichern, zurücklesen und zustellen. Nostr-Belege, private Kontowiederherstellung sowie Lager- oder Erfüllungsänderungen würden jeweils separate signierte Nachweise benötigen. Belege, die danach 24 Stunden aufbewahrt werden, stellen keine Zahlungsbefugnis wieder her, und Prüfungen mit echten Mitteln, auf Geräten und durch Maintainer stehen noch aus. Reine Veranstaltungsprodukte würden NIP-99-Angebote mit kind 30402 mit einer conduit_event_only-Erweiterung als verborgen markieren. Sie blieben aus dem normalen Katalog und Checkout heraus und bräuchten eine exakte, autorisierte Zuordnung zu einem Veranstaltungstermin. Die verborgenen signierten Daten bleiben öffentlich, und andere Clients unterstützen nur das standardmäßige Hidden-Flag.

LNbits

LNbits, der Lightning-Wallet- und Kontenserver, hat eine Option gemergt, seine Nostr-Benachrichtigungen als private NIP-17-Nachrichten zu senden. Administratoren können zwischen verschlüsselten Legacy-Nachrichten nach NIP-04 und privaten Direktnachrichten nach NIP-17 wählen, die bei neuen Einstellungen der Standard sind. Für NIP-17 ruft der Server die relay-Liste des DM-Postfachs des Empfängers ab, wobei NIP-05-relays als Hinweise zur Erkennung und, falls keine Liste existiert, als Ziel dienen. Eine veröffentlichte leere Liste lässt das Senden fehlschlagen. Jeder Sendevorgang ist auf 30 Sekunden begrenzt und benötigt mindestens ein Postfach-relay, das ihn annimmt, und er fällt nie auf NIP-04 zurück.

Zeus

Zeus, die mobile Bitcoin- und Lightning-Wallet, hat ihre Korrektur der Budgetabrechnung für Nostr Wallet Connect bei fehlschlagender Aktualisierung nach der Zahlung in die Vorabversion v13.2.4-rc1 aufgenommen, zusammen mit der früheren Korrektur, durch die make_invoice von Nostr Wallet Connect seine eigene Rechnung zurückgibt. Vor der Korrektur übersprang ein Aktualisierungsfehler nach einer Zahlung über NIP-47 die Budgetabrechnung und gab einen Fehler für eine Zahlung zurück, die womöglich erfolgreich war. Nun belastet ein zurückgegebenes Preimage das Budget über den bestehenden Fallback, und ein Timeout hält den Betrag als ausstehende Ausgabe zurück, auch wenn die Zahlung in der Liste fehlt. Andere Lücken, darunter laufende LND-Zahlungen, bestehen möglicherweise weiter. v13.2.4-rc2 folgte ausschließlich mit Abhängigkeitsaktualisierungen.

Zwei neuere Korrekturen wurden inzwischen in den Quellcode gemergt und sind in keinem der beiden Release-Kandidaten bestätigt. Die Korrektur des Standardablaufs sorgt dafür, dass der lokale BOLT11-Decoder den in der Spezifikation festgelegten Standardablauf von 3600 Sekunden anwendet, wenn eine Rechnung kein Ablauffeld hat. Solche Rechnungen wurden bisher als nie ablaufend behandelt, sodass die Prüfung, die das Bezahlen abgelaufener Rechnungen verhindert, nicht griff, und die NWC-Rechnungsvalidierung in NostrConnectUtils hatte dieselbe Lücke. Die walletbezogene Backup-Korrektur setzt den Nostr-Zeitstempel für Mint-Backups für jede Ecash-Wallet zurück. Vor dieser Korrektur konnte eine Wallet, die in derselben Sitzung wie eine andere Ecash-Wallet aus dem Seed wiederhergestellt wurde, deren Zeitstempel übernehmen. Sie konnte dann ihre eigenen älteren relay-Backups als veraltet verwerfen und eine leere Mint-Liste speichern, was die automatische Wiederherstellung abschaltete. Ein Backup, das nach einem Wallet-Wechsel abgeschlossen wird, kann seinen Zeitstempel weiterhin unter der falschen Wallet schreiben. Bereits betroffene Wallets behalten ihre gespeicherte leere Liste und benötigen die manuelle Wiederherstellung unter Mint-Synchronisierung oder das erneute Hinzufügen ihrer Mint-URLs. Ihr Ecash verbleibt bei der Mint. Beide Pull-Requests geben an, dass keine Tests auf Geräten durchgeführt wurden.

npub.cash

npub.cash empfängt Lightning-Zahlungen für Nostr-Identitäten und wandelt sie in Cashu-Ecash um. Es hat eine Serveränderung gemergt, die zap-Belege an die vom Zahlenden angeforderten relays veröffentlicht. Der Server hat die in einer zap-Anfrage genannten relays bereits ausgewertet, sie beim Veröffentlichen bezahlter Belege aber ignoriert. Nun gehen Belege an diese relays, wenn die Anfrage mindestens eines nennt, während Anfragen mit fehlender oder leerer relay-Liste weiterhin die konfigurierten Standard-relays verwenden.

eHagaki

eHagaki, ein Nostr-Webclient, der auch als einbettbare Web Component ausgeliefert wird, hat 1.31.0 und 1.31.1 veröffentlicht. Version 1.31.0 ergänzt Reposts (NIP-18), Reaktionen (NIP-25) und die Verwaltung hochgeladener Medien, legt das Outbox-Routing (NIP-65) fest, bevor ein Event an einen externen Signer geht, und kann Beitragsverlauf und Cache in einem lokalen Citrine-relay vorhalten. Ihre IndexedDB-Migration setzt den lokal angezeigten Beitragsverlauf zurück, behält aber Entwürfe und gespeicherte Löschanfragen; auf relays gespeicherter Verlauf kann erneut abgerufen werden, während rein lokale Beiträge vor dem Upgrade ein Backup oder einen Export benötigen. Version 1.31.1 synchronisiert NIP-96-Upload-Server über kind 10096 neben Blossoms kind 10063, behält brauchbare unvollständige relay-Einstellungen bei und enthält die Korrekturen für die Upload-Serverliste und die Mediaserver-Synchronisierung. Das Abrufen der Upload-Serverliste über die angegebenen Lese-relays behält trotz Timeouts anderer relays die neueste gültig signierte Liste bei und lässt die Einstellungen unverändert, wenn keine eintrifft. Die Mediaserver-Synchronisierung behandelt Blossom- und NIP-96-Präferenzen getrennt und veröffentlicht nach einer fehlgeschlagenen Abfrage nie eine gekürzte Liste.

Weitere gemergte Zuverlässigkeitskorrekturen sind noch in keiner Version bestätigt. Nach einem 401 oder 403 können sich Nutzer über den Medienbildschirm bei den NIP-96-Servern yabu.me oder nostrcheck.me registrieren; die NIP-98-Signatur deckt die tatsächliche POST-URL und den Hash des Bodys ab, Konto- oder Zieländerungen brechen die Anfrage ab, eine Sperre verhindert doppeltes Senden, und Anfragen mit unbekanntem Ergebnis werden nicht erneut gesendet. eHagaki übermittelt nie ein Passwort, und Schritte für Einladungscodes oder Zahlungen laufen über die offizielle Website des Anbieters. Große Blossom-Dateilisten werden aus einem begrenzten lokalen Snapshot in Seiten zu je 24 Einträgen geladen, wobei Antworten über 8 MiB oder 10.000 Einträgen abgelehnt werden und der Snapshot bei einem Wechsel von Konto, Sitzung oder Server verworfen wird; das Erreichen des Endes bedeutet, dass der Snapshot aufgebraucht ist, nicht dass der Server keine weiteren Dateien hat. Die Wiederherstellung von NIP-46-Remote-Signern baut die Verbindung neu auf und lehnt alte ausstehende Anfragen nach 30 Sekunden ausdrücklich ab, ohne sie erneut zu senden. Uploads auf Primals Blossom-Server kodieren die vorhandene signierte Autorisierung als aufgefülltes Standard-Base64, während andere Server weiterhin Base64URL verwenden.

Auch zwei neuere Merges sind noch nicht in einem Release bestätigt. Das Veröffentlichen nutzt jetzt gemeinsame, begrenzte und verifizierte Wartezeiten für relay-Anfragen und bindet Zustellung und Fortschritt an die Sitzung, womit mehrere separate Timer ersetzt werden. Die erste gültige relay-Bestätigung gilt als Erfolg, während die Zustellung an die übrigen relays weiterläuft. Der Fortschritt behauptet nie eine Zustellung an jedes relay, und ein Kontowechsel oder Abmelden beendet die Zustellung im Hintergrund. Der Beitragsverlauf kann auf Anfrage innerhalb eines Limits von drei Sekunden zugehörige Antworten, Reaktionen und Löschungen aktualisieren. Bereits empfangene Ergebnisse bleiben nach einem teilweisen Timeout erhalten, und eine nicht eintreffende Löschung wird nicht als Beweis gewertet, dass keine existiert.

Formstr Drive

Formstr Drive, eine auf Nostr und Blossom aufbauende App zum verschlüsselten Teilen von Dateien, hat ihre Arbeit an der DriveKey-Wiederherstellung gemergt, über die wir zuvor als offenen Vorschlag berichtet hatten. Die App liest jedes erreichbare relay, bevor sie einen zusammengeführten Schlüsselbund schreibt, sodass alte Schlüssel zusammenfinden, sobald sie sichtbar werden. Einen neuen Schlüssel erzeugt sie nur, wenn zwei von vier App-relays nichts zurückgeben und weder ein Verlauf noch eine Version existiert. Ein Schreib-relay, das nicht antwortet, kann einen alten Schlüssel dennoch eine Zeit lang verbergen, und ältere Builds können das neue JSON-Format nicht lesen.

Das Projekt hält außerdem die entschlüsselten Dateien, Freigaben, Ordner und den Postausgang jedes Kontos getrennt. Ein Kontowechsel blockiert ausstehende Signaturen und Importe des vorherigen Kontos, wobei ein vorbereiteter Blob unreferenziert zurückbleiben kann. Neue Konten müssen jetzt ausdrücklich einen Upload-Server wählen, ohne stillen Failover, während frühere automatische Voreinstellungen erhalten bleiben. Der Server sieht weiterhin den pubkey, den Upload-Zeitpunkt und die verschlüsselten Bytes. Duplikatwarnungen erfordern jetzt identische aktive Bytes auf demselben Server und im selben Ordner. Die Android-Pfade für die Kontotrennung und die Bestätigung von Duplikaten sind ungetestet, und wir haben nicht bestätigt, dass irgendetwas davon in einem Release enthalten ist.

diVine

diVine, ein Kurzvideo-Client für Nostr, hat Änderungen an Nachrichten, Konten und Challenges gemergt. Seine frühen Beta-Releases haben nur allgemeine Versionshinweise, daher ist nichts davon für ausgelieferte Builds belegt. Verschlüsselte Konto-Snapshots pro Feld synchronisieren Einstellungen, Badge-Entscheidungen und ausgeblendete Hinweise, wiederholen ausstehende Änderungen lokal und blockieren unsicheres Veröffentlichen bei unvollständigen Lesevorgängen. DM-Lesemarkierungen behalten das bestehende Protokoll bei, Lesestatus von Benachrichtigungen nutzen die Server-API, und „Alle als gelesen markieren“ benötigt eine Verbindung; Betriebssystemberechtigungen, Zugangsdaten und die Alterseinwilligung bleiben auf dem Gerät.

In DMs schließen sich Eingabefeld und Teilen-Dialog, sobald eine Nachricht sicher in der Warteschlange liegt; die Zustellung im Hintergrund läuft nicht, solange die App beendet ist, und als zugestellt gilt eine Nachricht erst nach der relay-Bestätigung. Fehlgeschlagene Wiederholungen werden einheitlich auf das Versuchslimit angerechnet. Legacy-NIP-04-Nachrichten mit ungültiger Struktur werden verworfen und in einem Protokoll erfasst, wobei gespeicherte leere Sprechblasen bestehen bleiben und die Kompatibilität mit externen Signern und anderen Geräten nicht belegt ist. Optionale unscharfe Vorschauen für Video-DMs von vertrauenswürdigen Absendern sind standardmäßig deaktiviert und stets mit einer Inhaltswarnung unscharf dargestellt; das Video wird trotzdem heruntergeladen, die Unschärfe bietet also keine Privatsphäre auf Netzwerkebene. In Gruppen blendet das Blockieren eines Mitglieds nur dessen Nachrichten aus; ein Hinweis weist darauf hin, dass es Ihre weiterhin erhält. Das Verlassen eines Raums wird dauerhaft gespeichert. Das Erstellen neuer Gruppen bleibt hinter einem standardmäßig deaktivierten Flag. Diese Änderungen gelten für bestehende Gruppen; eine Prüfung durch Trust and Safety steht noch aus.

Zwei zuvor offene Funktionen wurden gemergt. Das Caching empfangener DM-Videos bewahrt entschlüsselte Dateien pro Konto bis zu 30 Tage oder 300 MB auf; automatisches Laden in vertrauenswürdigen Chats und von gefolgten Nutzern verrät dem Medien-Host den Zeitpunkt des Ansehens, Videos von Fremden erfordern ein Antippen. Ein serverseitiges Entfernen widerruft zwischengespeicherte Bytes nicht sofort, diese können aber früher verdrängt werden. Die Abfrage der Eigentümerschaft von Benutzernamen prüft bei Suchen nach Divine-Handles auf der ersten Seite das NIP-05-Verzeichnis des Namensservers und heftet nur einen aktiven Eigentümer an; abgefragte Namen erscheinen in Serverprotokollen, und dies ist keine allgemeine NIP-05-Validierung.

Personenlisten gehen in die allgemeine Verfügbarkeit über und bauen auf der kombinierten Arbeit an Entdeckung und Verwaltung auf. Support-Links im Profil sind standardmäßig aktiviert, und der Editor wartet auf einen strikten Roh-Lesevorgang von kind 0 von jedem relay, wobei verborgene Anbieter und nicht gespeicherte Änderungen erhalten bleiben; eine Freigabe in den Stores und ein Backend-Rollout sind noch nicht erfolgt. Client-Attributions-tags folgen bei Wiederholungen und Metadatenänderungen der aktuellen NIP-89-Präferenz und entfernen vor dem Signieren einen fremden Client-tag, während signierte geplante Beiträge nie verändert werden. Authentifizierte externe Kurzlinks, standardmäßig deaktiviert, signieren den exakten NIP-98-POST samt Body innerhalb von zwei Sekunden und fallen auf kanonische URLs zurück, die DMs und Nostr-events stets beibehalten; die Erstellung über das Gateway ist ausgerollt, aber abgeschaltet, mit noch ausstehenden Rollout-Schranken.

Creator können die Wiederverwendung eines öffentlichen Videos mit einem expliziten tag erlauben, standardmäßig deaktiviert und beim Veröffentlichen durch Audio mit No-Derivatives-Lizenz fest gesperrt; dies ist eine Client-Konvention, kein DRM. Reine Testarbeit an Challenges umfasst eine signierte Protokollgrundlage, das Signieren von Einreichungen mit Regel- und Einwilligungsprüfungen, dauerhaften Speicher pro Konto und native Abläufe für Prüfung und Rückzug in speziellen Test-Builds. Eine relay-Bestätigung bedeutet keine Genehmigung durch die Organisatoren. Die Entdeckung in der Produktion ist deaktiviert. Backend-Auslieferung, Abnahmetests mit echten Konten und eine clientübergreifende Release-Abfolge stehen noch aus.

Auch neuere Merges sind noch nicht in einem Release bestätigt. Wenn der DM-Posteingang (kind 10050) eines Empfängers nicht gelesen werden kann, verwendet die NIP-17-Warteschlange für zurückgehaltene Sendungen jetzt die ID des Empfänger-Gift-Wraps erneut, den ein relay bereits akzeptiert hat, und erhält so die Identität dieses Wraps über Wiederholungen hinweg. Findet eine Wiederholung den Posteingang, kann der Client an die angegebenen relays erneut veröffentlichen. Taucht kein Posteingang auf, belässt er es bei der akzeptierten Kopie und verlässt sich darauf, dass relays sie aufbewahren. Nachrichten können weiterhin als „Fehlgeschlagen“ angezeigt werden. Zustellung an den Empfänger oder dessen Lesen bleiben unbewiesen; Wiederholungen von Reaktionen und Löschungen liegen außerhalb dieser Änderung. Das Vorladen öffentlicher Benachrichtigungen und die Aktualisierung der Zeitzone nutzen einen begrenzten Vorschaubild-Cache und einen gemeinsamen SQLite-Index, ausgenommen DMs und Kampagnen. Sie benötigen ein normales natives Release plus eine abgestimmte Dienständerung, und die Ausführung im Hintergrund ist nicht garantiert. Der Videoeditor erhält fünf Übergänge, insgesamt also 20, die in Vorschau und Export nativ gerendert werden. Reduzierte Bewegung begrenzt die Vorschaukacheln bewusst. Der Abstand bei Blitzübergängen kann auf eine Überblendung zurückfallen. Die native Implementierung haben wir nicht in der Praxis getestet.

Vier offene Pull Requests waren zu unserem Quellenstichtag nicht gemergt. Soziale Video-Sticker, aufgesetzt auf frühere Arbeit an Info-Stickern, würden kleine flache Sticker-tags mit Metadaten für Erwähnungen (p), Hashtags (t) und Links (r) schreiben. Der Player würde antippbare Bereiche einblenden und vor dem Öffnen externer Links warnen. Andere Clients sehen nur die in das Video eingebrannten Sticker, sofern sie die tags nicht implementieren, die kein akzeptierter NIP sind. Erwähnungen in per Flag freigeschalteten Concord-Chats würden Identitäten innerhalb authentifizierter verschlüsselter Nachrichten halten. In-App-Hinweise kämen nur von gefolgten, nicht blockierten Absendern in Räumen, die der Nutzer geöffnet hat, begrenzt auf 50 Zeilen mit gespeichertem Lesestatus. Sie würden weder Push-Benachrichtigungen des Betriebssystems noch einen öffentlichen Chat-Rollout auslösen, und Prüfungen auf Identitätskollisionen, Replays und Blockierungen sind nur durch eng gefasste Tests abgedeckt. NIP-17-Rumor-tags würden den Autor der Reaktion einmal mit dem tatsächlichen kind nennen, und verpackte Löschungen würden irreführende p-tags weglassen. Gift Wraps gingen bereits an die richtigen Empfänger, daher behebt dies kein Leck bei Empfängern. Bereits eingereihte Rumors bleiben unverändert, das Verhalten in anderen Clients ist ungetestet, und ein Zielkonflikt bei der Zuordnung zu Räumen bleibt bestehen. Der nächste native Build würde das vorhandene Teilen per Kurzlink standardmäßig aktivieren, während es in der Webversion deaktiviert bleibt. Deaktivierte, abgemeldete und Fehlerpfade würden vollständige kanonische URLs beibehalten. Store-Vertrieb, Dienstbereitschaft und Geräteprüfungen sind nicht belegt.

rust-nostr

rust-nostr, eine Sammlung von Nostr-Protokollbibliotheken in Rust, hat eine inkompatible Änderung an der Neuausgabe von Subscriptions gemergt. SubscriptionData zeigt jetzt den aktuellen EOSE-Status jedes relays. Die Neuausgabe reiht CLOSE und das REQ mit dem gespeicherten Filter in einem atomaren Schritt ein, auch ohne Verbindung; das garantiert, wie sie eingereiht werden, aber nicht, dass beide Frames das relay erreichen. Die Erholung von einer Lücke in den Benachrichtigungen verwirft nicht mehr stillschweigend eine Subscription und sendet keine doppelte Anfrage mehr. Verspätete EOSE-Nachrichten oder events aus dem vorherigen REQ können sich weiterhin mit dem neuen überschneiden, weil auf Protokollebene nichts sie unterscheidet. Dies ist gemergter Quellcode, und wir haben nicht bestätigt, dass er in einem Release enthalten ist.

nostr-sdk-ffi

nostr-sdk-ffi, die Bindings, mit denen andere Sprachen das SDK von rust-nostr nutzen können, hat direkten Zugriff auf NIP-44-v2-Konversationsschlüssel gemergt, sodass Concord-Hosts keinen eigenen ECDH- und HKDF-Code mehr mitliefern müssen. Es ist eine dünne Hülle um die bestehende Ableitung und fügt keine neue Kryptografie hinzu. Der Autor berichtete von einem Python-Build und einem Hin-und-Rück-Test, der auf beiden Seiten denselben Schlüssel ergab, fügte aber keine eigenen Unit-Tests hinzu. Dies ist ausschließlich gemergter Quellcode.

NDK

NDK, ein Nostr Development Kit für Dart, hat 0.11.0-dev.2 veröffentlicht, ein Prerelease mit inkompatiblen Änderungen. Es ist kein stabiles 0.11.0 und hat nichts mit dem JavaScript-NDK zu tun. Das Release ergänzt NIP-49 passwortverschlüsselte ncryptsec-Schlüssel samt Beispiel-UI. Laut den Versionshinweisen begrenzt die Entschlüsselung logN, weist unbekannte Sicherheitsbytes zurück und nullt abgeleitete Puffer; diese Aussagen stützen sich auf die Versionshinweise und den gemergten Quellcode, und wir haben weder ein unabhängiges Audit noch einen Durchlauf mit Testvektoren gesehen. Anfragen melden jetzt ein notSent-Ergebnis mit dem Verbindungs- oder Sendefehler, und Anfragen an nicht erreichbare relays enden, sobald kein verbleibendes relay und kein Filter mehr antworten kann, ohne einen Timeout abzuwarten. Broadcasts prüfen auf einen Signer, bevor ein event als in Bearbeitung markiert wird, zap-Request-IDs nutzen das gespeicherte created_at, und NIP-11-relay-Metadaten werden bei Bedarf über einen gemeinsamen Cache abgerufen, sodass sie nicht mehr jede Synchronisierung blockieren.

Das Prerelease enthält außerdem Änderungen, die bisher nur im Quellcode vorlagen. NIP-65-Listen, die eine relay-URL wiederholen, werden jetzt korrekt zusammengeführt, wobei Lese- und Schreibmarkierungen kombiniert werden und die Menge der Outbox-Schreib-relays erhalten bleibt; der Autor sah bei einer einzelnen Beobachtung 5 falsch gelesene Listen unter 932 Profilen. Eine optionale BUD-06-Vorabprüfung für Uploads fragt den Server mit der eigenen Autorisierung des Uploads, ob er einen Blob annehmen würde, und meldet Status und Grund, wie es jetzt auch echte Upload-Ablehnungen tun. Ein 404 bedeutet, dass die Unterstützung unbekannt ist, und ein Bestehen garantiert nicht, dass der Upload gelingt. Eine inkompatible Änderung an den Timeouts der NIP-77-Abgleiche teilt den einzelnen Timeout in einen Öffnungs- und einen Leerlauf-Timeout mit typisiertem Fehler auf, wobei die Wartezeit auf die Authentifizierung nicht mitzählt. Es gibt keine Gesamtfrist, sodass eine Synchronisierung, die weiter Fortschritte macht, unbegrenzt laufen kann, und wir haben keine Verifizierung der Änderung gegen ein Live-relay gesehen.

Offene Pull Requests schlagen nach Kennung geschlüsseltes NIP-05-Caching mit Negativ-Caching, eine Cache-API, die IDs und Zeitstempel für NIP-77 zurückgibt, Behandlung der WebSocket-Bereitschaft, vollständige NIP-11-Felder und Abschluss bei abgelehnter Verbindung vor. Ein weiterer Vorschlag, laut einer frischen Statusprüfung noch offen, würde Konten mit Plattform-Passkeys für Browser und Flutter erstellen und wiederherstellen und dabei einem Entwurf für Passkey-Identitäten mit abgeleiteten und gespeicherten Schlüsselmodi sowie expliziten Legacy-Metadaten folgen. Unbekannte Handles werden abgelehnt und nie als neues Konto behandelt, und die Wiederherstellung muss unabhängig verifiziert werden, bevor eine gespeicherte Registrierung behalten wird. Der Autor merkt an, dass die Interoperabilität nicht über alle Passkey-Anbieter hinweg validiert wurde.

Applesauce

Applesauce, eine Sammlung von TypeScript-Bibliotheken für Nostr, hat neue Quellcodeänderungen mit Changesets, und wir behaupten kein passendes Release. Eigenständige Messaging-Clients und explizite relay-Authentifizierung ergänzen NIP-04- und NIP-17-Clients für ein festes Konto, die explizite NIP-42-Auth-Anfragen stellen und vorbereitete signierte Sendungen wiederholen. Begrenzte verpackte Konversationen und Rumor-Stores stellen kind-14-Rumors und Thread-Modelle bereit, ohne Signer- oder Netzwerkarbeit anzustoßen. Die Entschlüsselung ist standardmäßig deaktiviert, verpackte Sendungen benötigen kind-10050-relays für jeden Teilnehmer einschließlich des Absenders, und die Annahme durch ein relay ist kein Empfang beim Gegenüber. Die begrenzte Wiederherstellung des Caches für entschlüsselte Inhalte nutzt standardmäßig eine Nebenläufigkeit von 8, was events umsortieren kann, sofern sie nicht auf 1 gesetzt wird. Apps müssen diese Klartext-Caches selbst eingrenzen und verschlüsseln. Es folgen der NDR-Transport und ein separater Cordn-Koordinator-Client. NDR muss seinen eigenen, separaten Ratchet-Zustand persistieren, und „Submitted“ bedeutet lokale Übergabe, nicht Empfang beim Gegenüber. Cordn übernimmt nur den Transport, ist im Beispiel zurückgestellt und implementiert kein MLS. Die Kehto-ContextVM-Integration pro Fenster gibt jedem Napplet-Fenster eine kurzlebige ContextVM-Identität, ohne Konto-Authentifizierung oder Zahlungen. Mit dauerhaften, von der App verwalteten Einzahlungen und Nutzap-Wiederherstellung erfordern neue Wallet-Einzahlungen und Einlösungen einen von der nutzenden App bereitgestellten Wiederherstellungsspeicher und eine NUT-09-Wiederherstellung durch die Mint. Das Journal speichert ausgebbare Proofs, Secrets und Blinding-Faktoren, daher sollte es verschlüsselt und pro Konto eingegrenzt werden. Die Fortsetzung läuft nur bei explizitem Aufruf, verwendet signierte IDs erneut und behält das Journal bis zu einer positiven relay-Annahme, und ein Abbruch macht die Rechnung nicht ungültig. Gebündelte Timeline-Snapshots mit synchronem Wallet-Zustand fassen Timeline-Aktualisierungen in Fenstern von 16 ms zusammen, während der Zustand der Wallet-Token synchron bleibt. Der Scheduler für COUNT-Anfragen, letzte Woche vorgeschlagen, ist jetzt gemergt. Er beginnt bei 8 unter einer Nebenläufigkeitsobergrenze und verdoppelt bis zum ersten Rate-Limit- oder Transportfehler, und jeder Fehler halbiert die Obergrenze und fügt eine Abkühlphase hinzu. Timeouts erscheinen als CountFailure, ohne die Obergrenze zu senken. Die Latenz steuert nur die Auswahl der relays; der Benchmark mit drei relays reicht weiterhin nicht für allgemeine Leistungsaussagen.

eventstore

eventstore, fiatjafs Bibliothek von Speicher-Backends für Nostr-events, hat zwei Abfragekorrekturen gemergt. Ein getaggtes Release, das sie enthält, wurde nicht verifiziert. Alle Backends folgen jetzt der NIP-01-Regel für leere Filterlisten: Eine leere ids-, authors-, kinds- oder tag-Liste passt auf nichts, während eine fehlende (nil) tag-Liste weiterhin keine Einschränkung bewirkt. Eine Korrektur der event-Zählung in LMDB bewegt den HyperLogLog-Cursor nach einem Treffer weiter, sodass Zählungen nicht mehr endlos hängen. Außerdem wendet die Zählung keine Prüfungen auf Autor, kind oder tag mehr an, wenn der Filter keine enthält, was zuvor dazu geführt hatte, dass sie null zurückgab.

zsp

zsp, das Kommandozeilenwerkzeug von Zapstore zum Veröffentlichen von Android-Apps auf Nostr, hat Version 2.0.0 veröffentlicht. Die README zu diesem Tag bietet einen Assistenten, in dem eine Person die Inhaberschaft des C1-Signaturzertifikats nachweist, sowie einen zsp skill-Befehl, der Agenten Anweisungen zum Veröffentlichen gibt. Sie untersagt, Agenten den Keystore, dessen Passwort oder private Schlüssel zu überlassen, sodass der Nachweis bei einem Menschen bleibt. Das Release erkennt JKS- und PKCS12-Keystores außerdem am Inhalt, sodass PKCS12-Speicher mit den Endungen .jks oder .keystore sowohl im Assistenten als auch im Veröffentlichungspfad geladen werden. Das Veröffentlichen damit haben wir nicht getestet.

nsite-gateway

nsite-gateway, das auf Nostr veröffentlichte statische Websites ausliefert, hat Version 3.6.6 veröffentlicht. Die Quellcodeänderung aktualisiert auf Applesauce 7 und stellt den Ablauf von events wieder her. Frühere Versionen setzten bewusst einen deaktivierten Ablaufmanager ein, um einen Upstream-Fehler beim Begrenzen von Timern zu umgehen, sodass abgelaufene Website-events unbegrenzt im Speicher des Gateways aktiv bleiben konnten. Da die Upstream-Korrektur vorliegt, nutzt das Gateway wieder den normalen event-Store. Der Ablauf bestimmt hier, was das Gateway aufbewahrt und ausliefert, und löscht keine events von relays oder Caches Dritter. Ein produktiv betriebenes Gateway haben wir nicht getestet.

44billion

44billion, ein Nostr-App-Launcher, hat geändert, wie er sich Berechtigungen merkt. Gespeicherte Freigaben sind jetzt an App, Berechtigungsname, event-kind und Geltungsbereich gebunden, und eine Platzhalter-Freigabe für kind -1 autorisiert keine bestimmten kinds mehr. Geltungsbereiche sind nur für registrierte Paare aus kind und Geltungsbereich mit übersetzten Bezeichnungen feingranular; unbekannte Geltungsbereiche fallen auf einen leeren Geltungsbereich für den ganzen kind zurück, und die Registry startet leer. IndexedDB-Schemaversion 5 setzt Freigaben aus Version 4 bewusst zurück und entfernt beim Start nicht unterstützte eingegrenzte Freigaben, während andere App-Daten erhalten bleiben. Die eigene API für persönliche Verschlüsselung enthält Hilfsfunktionen im Stil von NIP-44 v3, die kein akzeptierter Standard sind. Dies ist eine Quellcodeänderung ohne bekanntes Release oder Deployment.

Neuerer Quellcode ergänzt Einstellungen für den App-Datenzugriff, die gemerkte Freigaben nach App gruppieren und Nutzern erlauben, eine einzelne Freigabe oder eine ganze App ohne Neuladen zu widerrufen. Ein Widerruf betrifft nur künftige geschützte Anfragen. Bereits gespeicherte oder kopierte Daten werden nicht gelöscht, und bereits laufende Vorgänge werden möglicherweise nicht gestoppt. Eine Änderung am Blossom-Asset-Cache behandelt ein zwischengespeichertes Asset erst dann als vollständig, wenn der SHA-256 des gesamten Bodys stimmt und eine passende Validierungsmarkierung gespeichert ist. Vorläufige Chunks aus älteren Caches werden erneut validiert, und das Streaming meldet keinen falschen letzten Chunk mehr. Das bedeutet nicht, dass vor der Validierung keine Bytes offengelegt werden, und es gibt kein neues Binär-Release.

Blossom Servers

Das Verzeichnis Blossom Servers hat Fähigkeitsberichte aus der Community für jede Server-URL ergänzt, jeweils ihrem Beitragenden zugeordnet. Manuelle Angaben und Browser-Beobachtungen werden getrennt geführt und fallen nach 90 Tagen bzw. 24 Stunden aus den Filtern heraus. Die Prüfungen betrachten HTTP-Antworten und angekündigte Methoden sowie Auth- und Zahlungs-Challenges. Anonyme Browser-Prüfungen senden eine HEAD-Anfrage, die Metadaten für ein 68 Byte großes PNG vorschlägt, ohne etwas hochzuladen, daher beweist eine 200-Antwort nicht, dass ein echter Upload funktioniert. Das Laden von Diskussionen ist jetzt eingegrenzt, und die Zuordnung zu Beitragenden ersetzt die frühere implizite Betreiberautorität. Ein Bericht ist kein Beweis dafür, wer einen Server betreibt, sagt nichts über die globale Verfügbarkeit oder vollständige BUD-Konformität aus, und Beitragende können sich widersprechen oder irren. Ein Deployment oder Release haben wir nicht verifiziert.

Neuerer Quellcode ergänzt konfigurierbare App- und Lookup-relays und liest Konten und Outboxen über NIP-65. Eine vorhandene öffentliche Lookup-Liste (kind 10086) hat Vorrang. Beim Speichern wird die öffentliche Liste nur aktualisiert, wenn bereits eine existiert, andernfalls bleibt alles lokal. Der lokale Veröffentlichungsdatensatz wird erst aktualisiert, nachdem mindestens ein relay das event bestätigt hat, was nicht bedeutet, dass jedes relay es erhalten hat. Kein Release und kein Deployment ist bestätigt.

Ditto

Ditto, der Nostr-Client von Soapbox, hat H.264-Metadaten korrigiert, die fehlerhafte WebCodecs-Encoder erzeugen, damit transkodierte Videos auf iOS abspielbar sind. Er erkennt verdoppelte SPS- und PPS-NAL-Header-Bytes sowie fehlerhafte reservierte Bits im avcC-Datensatz und repariert sie, bevor der Mediabunny-Muxer die MP4-Metadaten schreibt, wobei wohlgeformte oder nicht erkannte Datensätze unverändert bleiben. Version 2.45.1 ist erschienen, aber wir haben weder bestätigt, dass sie die Korrektur enthält, noch die Wiedergabe auf einem physischen iOS-Gerät getestet. Die Änderung zielt auf diesen H.264-Fehler, nicht auf jeden Codec oder jedes Video.

Amber-Desktop-Signer und NIP-46-Korrektur für Android

Amber, der Nostr-Signer für Android, hat am 27. Oktober Quellcode für einen Compose-Desktop-Signer für NIP-46 (Windows/macOS/Linux) gemergt, der das Android-Berechtigungsmodell pro App und pro kind nachbildet (Commit). NIP-55 bleibt Android-exklusiv. Der Desktop-Code unterstützt mehrere Konten und nostrconnect-/bunker-Verbindungen mit relays und Verlauf pro App sowie Tor und Benachrichtigungen im Infobereich. Schlüssel liegen in verschlüsseltem PKCS12-Speicher hinter einer verpflichtenden Argon2id-Passphrase, mit verschlüsselten Datenbanken pro Konto. Paketierung und Laufzeitverhalten auf dem Desktop haben wir nicht verifiziert.

Eine separate gemergte Änderung an der Android-App, nicht am Desktop-Signer, aktualisiert NIP-46-relay-Subscriptions und Verbindungsfilter, nachdem sich ein Konto abgemeldet hat. Dadurch hört Amber nicht mehr auf die Schlüssel eines gelöschten Kontos. Die geschwärzte Benachrichtigung auf dem Sperrbildschirm zeigt jetzt außerdem die Beschreibung der Anfrage. Das macht die Benachrichtigung nützlicher, bringt aber keinen Gewinn an Privatsphäre. Ein neues stabiles Release mit einer der beiden Android-Änderungen ist nicht bestätigt.

noStrudel: Napplet-Intents und synchronisierte App-Daten

Der Web-Client noStrudel hat mehrere Quellcodeänderungen gemergt, ohne bestätigtes Tag oder Deployment. Napplet-übergreifende Intents werden über den Katalog und z/i-Manifest-Deklarationen aufgelöst und liefern akzeptierte Payloads nach dem Laden des Ziel-Frames mit einer zur Laufzeit bestätigten Absender-ID aus; nicht unterstützte Intents werden abgelehnt, und Handler mit explizitem Ziel erfordern eine Bestätigung durch den Nutzer (Commit). Installierte Napplets und Standard-Handler werden pro Konto in NIP-44-verschlüsselten App-Daten (kind 30078) mit einem Drei-Wege-Merge synchronisiert (Commit), und ausgewählte NIP-66-relay-Monitore werden über verschlüsselte NIP-78-App-Daten synchronisiert (Commit). NIP-17-Nachrichten laden zwischengespeicherte Gift Wraps und gleichen einmal pro Sitzung dreißig Tage von DM-relays ab, wo unterstützt mit NIP-77, wobei älterer Verlauf bei Bedarf geladen wird (Commit).

Nostr Feedz archiviert

Nostr Feedz, das RSS mit Nostr-Langform-Inhalten und Videos verband, gibt in seiner README jetzt an, archiviert zu sein und nicht mehr gepflegt zu werden (Commit). Der Hinweis verweist auf Readstr von PrivKey als Fork, der die Entwicklung fortsetzt. Dies ist eine Änderung des Wartungsstatus, und wir haben nicht geprüft, ob GitHub das Repository als archiviert kennzeichnet oder ob Konten und Daten übernommen werden.

Zap Cooking: abgesicherte Listen, Signer-Korrekturen und Passkey-Registrierung

Zap Cooking, ein Nostr-Client zum Teilen von Rezepten, hat einen großen Stapel an Web-Quellcodeänderungen gemergt; Deployment oder Release ist unbestätigt. Schreibvorgänge für gespeicherte Listen (kind 30001) lesen jetzt zuerst und werden pro Konto serialisiert, wobei fremde tags und verschlüsselte Inhalte aus der neuesten vollständigen Basis erhalten bleiben, und sie verweigern den Vorgang, wenn die relay-Liste unbekannt ist oder das Quorum nicht erreicht wird (#869). Das Quorum erfordert mindestens zwei EOSE-Antworten von listenfähigen relays plus die Hälfte der fähigen Schreib-relays des Nutzers, und eine leere Antwort von nostr.wine kann kein Fehlen beweisen (#878). Eigene Sammlungen nutzen den abgesicherten Schreibvorgang mit, ältere eingereihte Operationen werden unter neuen Absicherungen erneut ausgeführt (#885), und ein leeres aggregiertes EOSE allein lässt eine Liste nicht mehr leer erscheinen (#872).

Eine explizite Auth-Methode behebt einen Minifizierungsfehler in der Produktion, der Signer-Klassen verwechselte, sodass die Verschlüsselung über NIP-46 und NIP-07 den aktiven Signer statt eines veralteten lokalen Schlüssels nutzt; die Wallet-Sicherung auf relays bleibt für NIP-46 gesperrt (#896). Ein aus einem Speichern oder einer Reaktion heraus gestarteter Login setzt diese Aktion fort. Ein ausstehender zap behält Betrag und Ziel, erfordert aber weiterhin „Senden“. Ablehnungen durch den Signer zeigen einen Fehler an, ohne stillschweigend mit einem fremden Schlüssel neu zu signieren (#867).

Bei der Registrierung wird die Identität lokal erzeugt, wobei die passkey-verschlüsselte Tresor-Synchronisierung standardmäßig aktiviert ist; ein Sicherungsschlüssel ist erforderlich, wenn die Synchronisierung deaktiviert ist oder der Upload fehlschlägt, und Google Drive dient nur der Wiederherstellung (#893). Wird WebAuthn-PRF mit nur einer Abfrage eingerichtet, bleiben der Tresor unbestätigt und der Klartext-nsec im Browser, bis eine spätere erfolgreiche Tresor-Entschlüsselung den Tresor bestätigt und den Klartextschlüssel entfernt (#907). Auf eine unsignierte Registrierung, die keine Authentifizierung ist, stützt sich die Ausweitung dieser Abfrage auf die Registrierung: Jeder mit einer frischen Server-Challenge kann eine Registrierung fälschen, die die Prüfung besteht, und ein Angreifer, der die Credential-ID kennt, kann einen unbestätigten Eintrag (TTL von 30 Tagen) ersetzen und dem echten Nutzer die Synchronisierung verwehren (#911). Dies sind dokumentierte Zielkonflikte, keine Sicherheitsgarantien.

Notiz-Links werden als NIP-19-nevent mit bis zu drei beobachteten relay-Hinweisen kodiert, was Clients hilft, dünn replizierte events zu finden, ohne Verfügbarkeit zu garantieren (#873). Antworten im Profil umfassen NIP-22-Kommentare (kind 1111), die an events verankert sind (#877), und eine Korrektur des Koordinaten-Parsers hält Rezepte mit URL-d-tags in Paketen und Plänen (#888). Das Experiment mit einer Bezahlschranke für Premium-Rezepte wurde eingestellt, nachdem ein Audit durch den Autor eine Umgehung über den pubkey in der Abfrage fand; ältere Beiträge mit kind 35000 bleiben als gespeicherte Inhalte lesbar (#862).

Ein offener, noch nicht gemergter Vorschlag zielt auf Stummschaltlisten (#921). Ein nicht verfügbarer Abruf der Stummschaltliste bliebe von einem erfolgreichen Abruf unterscheidbar, der eine Liste oder keine Liste zurückgibt. Die Änderung würde aufhören, einen nicht verfügbaren Abruf fünf Minuten lang als leere Liste zwischenzuspeichern. Fehler beim Parsen würden erneut versucht, mit einer Warnung, wenn private Stummschaltungen nicht entschlüsselt werden können. Das Öffnen der Benachrichtigungsglocke würde die Liste neu laden. Ziel ist zu verhindern, dass eine stillschweigend veraltete leere Stummschaltliste stummgeschaltete Autoren in die Benachrichtigungen lässt. Sie sorgt nicht dafür, dass alle Fehler Inhalte blockieren, und sie ist nicht ausgerollt.

Lumilumi: zap-Zahlungen per NWC

Lumilumi, ein Nostr-Web-Client, hat einen Entwurfs-Pull-Request, der zap-Rechnungen mit einem Antippen über Nostr Wallet Connect (NIP-47) bezahlen würde (#1120). Die Verbindungs-URI mit Ausgabeberechtigung wird nur lokal gespeichert und aus der Klartext-Sicherung der Einstellungen (kind 30078) ausgeschlossen. Anfragen nutzen NIP-44, wenn die Wallet nip44_v2 ankündigt, und fallen andernfalls auf NIP-04 zurück. Der Autor hat es gegen eine Mock-Wallet ohne echte Zahlung geprüft, und der Entwurf war zu unserem Quellenstichtag nicht gemergt.

Wisp: Suche nach Kennungen

Ein offener Pull Request für den Nostr-Client Wisp, zu unserem Quellenstichtag nicht gemergt, würde die Suche eingefügte NIP-19- und NIP-05-Kennungen, Hex-Schlüssel und Web-Links auf Entitäten erkennen lassen, bevor sie auf eine NIP-50-Textabfrage zurückfällt (#681). Abfragen nutzen relay-Hinweise und den lokalen Cache. Die Suche würde Ergebnisse streamen, während sie bis zu einer Obergrenze von 15 Sekunden auf EOSE von den abgefragten relays wartet, sodass langsame relays nicht mehr wegfallen. Der Autor berichtet nur von Tests im Emulator, nicht auf einem physischen Gerät.

Zapstore: Unterstützung für Android TV

Zapstore, der auf Nostr basierende App-Store, hat einen offenen v2-Pull-Request für Android TV, zu unserem Quellenstichtag nicht gemergt (#407). Er würde 32-Bit-ABIs abgleichen und eine reine Fernbedienungs-Fokussteuerung für Leanback unterstützen, mit einem Fallback, wenn der Bildschirm für die Installationsberechtigung nicht verfügbar ist. 32-Bit-Builds ohne Arti zeigen ausdrücklich eine reine Direct-Verbindung an, während 64-Bit-Builds ohne Arti sicher fehlschlagen. Der TV-Build nutzt zum Testen und nicht für den Vertrieb einen lokalen Debug-Signer, und der einzige TV-Test des Autors verwendete ein lokal gebautes relay, weil das öffentliche Bundle nicht verfügbar war.

strfry: Härtung und NIP-11-Vorschläge

strfry, das Nostr-relay in C++, hat zwei Vorschläge, die zu unserem Quellenstichtag nicht gemergt waren. #281 reagiert auf die relay-Audit-Befunde SF-01 bis SF-13, indem JSON-Tiefe, dekomprimierte Payloads, Warteschlangen und Metrik-Labels begrenzt, ein Absturz bei leerem negentropy-Filter behoben und Indizes für lange tags gehasht werden. Es wechselt zu DB-Format 4, sodass Nutzer exportieren und erneut importieren müssten. Die bestandenen Tests stammen vom Autor selbst. Der Entwurf #278 würde nur tatsächlich durchgesetzte NIP-11-Einschränkungen ankündigen, dazu optionale Gebühren und payments_url, wobei payment_required standardmäßig false ist und konfigurierte Preise keine Zahlungen implementieren.

nostrcheck-server: Bark-Zahlungen

nostrcheck-server, ein Server zum Hosten von Nostr-Medien, hat einen Entwurfs-Pull-Request, der einen barkd-(Bark-)Zahlungsanbieter hinzufügt (#62). Er würde Lightning-Rechnungen über die REST-API von barkd erstellen und optional eine X-Ark-BIP-321-URI pro Datei an 402-Antworten anhängen, mit derselben Lightning-Rechnung als Fallback. Eine Wallet auf demselben Ark-Server zahlt über Ark, andere nutzen Lightning, und eine abgewickelte Zahlung schaltet die Datei einmalig frei. Tests verwenden ein gemocktes barkd, und er hängt vom offenen BUD-07-Pull-Request #61 ab. Er war zu unserem Quellenstichtag nicht gemergt und ist keine Funktion auf share.yabu.me.

mattn nostr-relay: bezahlte Schreibvorgänge

Ein Entwurfs-Pull-Request für mattns nostr-relay, zu unserem Quellenstichtag nicht gemergt, würde optionale bezahlte Schreibvorgänge über eine Bark-Wallet hinzufügen, standardmäßig deaktiviert (#37). Pubkeys würden Schreibgebühren über barkd im Voraus bezahlen, mit einem optionalen kind-Filter, und Schreibende ohne Guthaben erhalten eine restricted:-Antwort mit einer Zahlungs-URL. Aufladungen würden Ark oder Lightning über BIP-321-URIs oder NWC nutzen, mit in NIP-11 aufgeführten Gebühren. Tests verwenden einen Mock-Daemon, und ob dies in den Hauptcode gehört oder hinter einen Hook, ist noch nicht entschieden.

ContextVM: Schutz vor Wiederholungen nach Reconnect

Für das TypeScript-SDK von ContextVM, das MCP über Nostr transportiert, gibt es einen offenen Pull Request, der eine doppelte Ausführung nach Relay-Reconnects verhindern würde (#113). Verifizierte Event-IDs würde der Server-Transport bis zu seinem Schließen behalten, und ein separater, begrenzter Envelope-Cache blockiert neu verpackte Duplikate. Mit den eindeutigen verifizierten Events wächst der Speicherbedarf über die Lebensdauer des Transports. Zu unserem Quellenstichtag war der Fix nicht gemergt, und in keinem veröffentlichten Paket ist er enthalten.

Kehto-Shell: Medienwiedergabe und Freigaben

Kehto, eine Web-Shell für Nostr-Napplets, hat am 28. Oktober die NAP-MEDIA-Wiedergabe gemergt. Die Hosts Paja und Playground teilen sich nun einen richtliniengesteuerten Audio- und Videoplayer. Er nutzt Browser-Codecs für endliche URL- und Blossom-Quellen und spielt Live-Streams in HTTPS-MP3 oder ADTS-AAC ab, sofern MediaSource den Codec unterstützt, wobei die Wiedergabe beginnt, bevor die Antwort endet. Die Sitzungsberechtigung bleibt an Endpunkt, Quellfenster und ACL gebunden. Widerruf oder Abbau verwirft Blob-URLs, stoppt die Wiedergabe und bricht Streams ab. Die nur dem Host vorbehaltene Methode ResourceService.openStream verwendet die bestehenden Endpunkt-Origin-Berechtigungen und -Richtlinien und fügt keine Ressourcen-Wire-Nachricht hinzu. Die terminale Zustellung bleibt erhalten. Der Legacy-Alias sendCommand funktioniert weiterhin. Unabhängig davon funktionieren erkennbare Callbacks mit zwei Argumenten weiter, allerdings mit einer Warnung. Unäre Legacy-Callbacks wechseln zu Befehlsobjekten. Der Browser-Resolver weist Nicht-HTTPS-URLs, Zugangsdaten und private IP-Literale zurück. Außerdem deaktiviert er Weiterleitungen und Referrer. Er kann DNS nicht prüfen und garantiert daher keinen Schutz privater Adressen zum Zeitpunkt der Namensauflösung: Produktive Resolver benötigen Prüfungen zur DNS-Zeit, und die Browser-Voreinstellung stützt sich auf CORS und den Schutz privater Netzwerke. HLS, DASH, Live-Ogg, Nostr-Quellen, Warteschlangen, Persistenz und automatisches Fortsetzen bei Fokus werden weiterhin nicht unterstützt. Der Autor meldet 155 Chromium-Tests und 112 Sekunden Radiowiedergabe aus einem unveränderten Funclet-Artefakt, was wir nicht erneut ausgeführt haben. Es handelt sich um reine Quellcode-Arbeit. Dem veröffentlichten Paket Napplet 0.32 fehlen einige Entwurfstypen. NAP-MEDIA bleibt ein Entwurf; eine Konformität in einem Release wird weiterhin nicht beansprucht.

Eine zweite gemergte Änderung macht Signatur- und Veröffentlichungsfreigaben versionsspezifisch. Jede Freigabe ist an den verifizierten Herausgeber, den Artefakt-Hash und den aktiven Signer gebunden. Freigaben können widerrufen werden, und reine Signatur- und reine Veröffentlichungsfreigaben sind getrennt. Eine Legacy-Berechtigung wird nie stillschweigend hochgestuft. Die Zustimmung für eine veränderliche Entwicklungs-URL gilt nur für diesen Ladevorgang, und ein Wechsel von Endpunkt oder Konto weist ausstehende Anfragen zurück. NAP-LINK öffnet einen Link erst nach einem expliziten Klick in einem Host-Modal und verwendet dabei noopener. Die Änderung beansprucht keine umfassenden Tests gegen externe CVM-Radioquellen, und ein Merge im Quellcode belegt kein npm-Release.

Pact

Pact, ein Nostr-Protokoll für Agentenbeziehungen und Betreiberzustimmung, authentifiziert nun Antworten von Nostr Wallet Connect. Jedes Ergebnis muss die Signatur der Wallet tragen und auf seine Anfrage verweisen, und Pact prüft den Ergebnistyp und den Payment-Hash sowie ein eventuell zurückgegebenes Preimage. Die Einlösung erhält atomare Ledger-Schreibvorgänge sowie Schutzmechanismen beim Verbrauchen und Wiederholen von Anfragen, und weitere Wege zur Fälschung von Zustimmungen werden geschlossen. Ein Folge-Change, der MCP-Zahlungen begrenzt, hält diese deaktiviert, sofern nicht PACT_MCP_ALLOW_PAYMENTS=1 gesetzt ist, und prüft eine Standardobergrenze von 1.000 Sats sowohl gegen den angegebenen als auch gegen den BOLT11-Betrag. Das private Posteingangsfenster stoppt nun bei 200 Wraps und kennzeichnet eine Kürzung. Die Tests des Autors stützen sich auf Mocks.

nostr.watch

nostr.watch, ein Monitor für Nostr-Relays, erhält explizite Unterstützung für FIPS-Discovery und -Transport, und Overlay-Abfragen fallen nicht mehr auf öffentliches DNS-over-HTTPS zurück. Hosts stellen weiterhin DNS und IPv6-Routing bereit, da der Monitor weder einen FIPS-Daemon noch einen Proxy mitbringt und keine Anonymität bietet. Eine strengere npub-Prüfung akzeptiert npubs nur innerhalb geparster .fips-Hostnamen. Automatische NIP-11- und NIP-05-Prüfungen wandern in einen app-eigenen ServiceWorker, wodurch der Kontext des besitzenden Tabs aus dem beobachteten, von Erweiterungen ausgelösten Navigationspfad entfernt wird; dies wurde in einem unveränderten Firefox 155 mit einer kontrollierten Erweiterungs-Fixture geprüft. Die Konformitätssuite umfasst fünfzehn begrenzte NIP-01-Prüfungen mit einer Konversationsschicht, die unabhängige Verbindungen unterstützt. Der Autor meldet bestandene Tests und isolierte Mesh-Läufe, kein Audit mit öffentlichen Relays und keine Browser-Sicherheitsprüfung.

Bitcredit Core

Bitcredit Core, ein Peer-to-Peer-Protokoll für Kredite und Wechsel, das Nostr nutzt, prüft nun, dass mindestens ein Schreib-Relay verbunden ist, bevor eine Block-Operation etwas lokal persistiert oder ihre Effekte auslöst. Auch die Wiederherstellung initialisiert sauber neu. Die Validierung von Kandidatenketten, die letzte Woche als offen gemeldet wurde, ist inzwischen gemergt, sodass Ketten vor ihrer Persistierung validiert und vorbereitet werden. Diese Schritte verringern die Wahrscheinlichkeit eines inkonsistenten lokalen Zustands. Ein verbundenes Relay kann nicht garantieren, dass Relays das Event annehmen oder dass die Abwicklung abgeschlossen wird, und diese Prüfung allein macht die lokale Persistenz nicht dauerhaft.

Ein neuerer Merge, der in keinem Release bestätigt ist, fügt dem Identitätsdienst einen Transaktionsmanager hinzu. Identitätsblöcke, Zustand und E-Mail-Bestätigung werden nun atomar committet, bevor irgendetwas über Nostr verbreitet wird, und neue Tests prüfen, dass nichts gesendet wird, wenn der Commit fehlschlägt. Dies betrifft nur den Identitätsdienst. Der Persistenz von Wechseln und Unternehmen fehlt dieser atomare Commit, und Annahme durch Relays sowie Abwicklung sind weiterhin nicht garantiert.

MLS-KMP und Marmot-Kompatibilität

MLS-KMP, die Kotlin-MLS-Bibliothek unter marmot-kmp, hatte zuvor mehrere Wire-Verhaltensweisen an andere MLS-Implementierungen angepasst, sodass sich Mitglieder mit 1.2.0 und mit diesem neueren Code in den aufgeführten Fällen uneinig sind und Gruppen gemeinsam aktualisieren müssen. Der gespeicherte Zustand wechselte zu Version 10, die ältere Releases nicht wiederherstellen können. Der nachgelagerte Marmot-Kompatibilitätsjob ist nicht blockierend. Seine Tests liefen in der Entwicklungsumgebung dieser Änderung nicht; Marmot muss sich noch an authorizeProposal und GREASE anpassen. Eine frühere Änderung an den App-Komponenten erzwingt die Komponenten, die Marmot benötigt, um MDK v0.14 zu folgen. Eine Übernahme in Amethyst haben wir nicht überprüft.

Neuerer gemergter Quellcode, der nicht für das veröffentlichte 1.3.0 beansprucht wird, repariert die Kompilierung des nächtlichen Interop-Runners und meldet pro Skript Erfolg, Fehlschlag oder Übersprungen. Unser früherer Hinweis, dass der Live-Runner nie lief, ist daher überholt: Die Autoren melden funktionierende Läufe, allerdings lief der letzte Durchgang noch, als die Änderung eröffnet wurde, und wir haben kein abschließendes CI-Ergebnis ausgelesen. Der OpenMLS-Job bleibt nicht blockierend, überspringt 22 nicht unterstützte oder panikauslösende Szenarien und deckt nur die Ciphersuite 0x0001 ab, sodass er keine Interoperabilität zertifiziert. Diese Änderung behebt außerdem die ReInit-PSK-Suche über die beibehaltene Gruppen-ID, das Interim-Transkript in Epoche null, das Zufallsgeheimnis der ersten Epoche und die Behandlung des Resumption-PSK bei External Commits. Für das Transkript in Epoche null folgt der Code nun RFC 9420, Abschnitt 11, um OpenMLS zu entsprechen, sodass sich externe Beitritte in Epoche 0 von 1.3.0 und älteren Releases unterscheiden und gespeicherte ältere Gruppen den alten Hash bis zu ihrem ersten Commit behalten. Die ursprüngliche Engine leitete ihr erstes Epochengeheimnis aus Null ab; die Autoren fanden keinen Exploit, da spätere Commits einen frischen UpdatePath tragen, und der Fix belegt nicht, dass alle Sicherheitsprobleme gelöst sind.

Obelisk Relay

Obelisk Relay hat in seinen Standard-Branch einen Fix für private NIP-29-Gruppen gemergt. Globale Relay-Admins konnten bereits REQs für private Gruppen senden, doch der Event-Sichtbarkeitsfilter wies die passenden Events weiterhin zurück. Relay-Admins können diese Events nun lesen, und die Zugriffsprüfungen für Mitglieder bleiben bestehen. Relay-private Gruppen sind nicht Ende-zu-Ende-verschlüsselt, und die Änderung macht die Sichtbarkeit für den Server-Admin explizit. Der Fix ist gemergte Quellcode-Arbeit für Entwickler und Betreiber.

Plume

Plume, der Desktop-Client auf Basis von Rust und Tauri, hat eine Änderung gemergt, die pro Relay einen dauerhaften, sich neu verbindenden WebSocket vorhält. Feed-, Profil-, Veröffentlichungs- und Direktnachrichten-Operationen teilen sich alle diese Verbindung. Subscriptions und Event-IDs werden darüber gemultiplext. Reconnect-Versuche nutzen ein Backoff; die Verbindungen werden geschlossen, wenn die App beendet wird. Vor der Änderung öffnete jede Operation einen neuen Socket, der anschließend geleakt wurde. Die geprüfte Änderung ist gemergte Quellcode-Arbeit; Leistungsmessungen sind hier nicht belegt. Sie verspricht weder verlustfreie Wiederherstellung noch garantierte Zustellung.

Hashtree

Die TypeScript-Laufzeit 0.5.22 von Hashtree lässt Browser-Provider bis zu 256 aktuelle, signierte öffentliche Peer-Ankündigungen in IndexedDB vorhalten, getrennt nach Identität und App. Provider können sie vor der Netzwerk-Discovery neu laden. Gewöhnliche Peer-REQs können diesen Cache wiedergeben, soweit die bestehenden Zulassungsregeln dies erlauben, und private Discovery bleibt in einem separaten Besitzerbereich. Unabhängig davon bricht eine gemergte Änderung am Rust-Adapter verwaiste Index-Lesevorgänge ab, sodass Befehle nicht mehr den vollen Transport-Timeout abwarten. Der Pull Request meldet hashtree-nostr-pubsub 0.2.87 als veröffentlicht, und dieses Paket wird getrennt von der TypeScript-Laufzeit versioniert. Reine Quellcode-Commits am Rust-Client fügen kombinierte Legacy-, Lese- und Schreib-Origins von Blossom für Lesevorgänge sowie einen einzigen erneuten Versuch bei typisierten Verbindungsabbrüchen in der Anfragephase pro Quelle hinzu, ohne Teilantworten zu cachen. Eine einzelne Neuinstallation auf einem Mac beweist nicht, dass sporadische Übertragungs-Timeouts behoben sind.

nostr-pubsub

nostr-pubsub TS 0.5.20 hält einen begrenzten Speicher signierter Events vor und ergänzt IndexedDB-Persistenz, atomare tabübergreifende Transaktionen, Ablauf und lokale Wiedergabe für gewöhnliche Nostr-REQs. Dieselbe Quelle beschreibt separat eine optionale native Rust-Dateispeicher-API mit atomaren Snapshots und einer exklusiven Schreib-Lease, die vom TypeScript-Paket getrennt ist. In der Implementierung des dauerhaften Event-Speichers prüfen Neuladevorgänge Signaturen und die Gewinner ersetzbarer Events nach NIP-01 erneut und weisen ephemere Events sowie Zeitstempel zurück, die mehr als fünf Minuten vor der aktuellen Zeit liegen. Speicher werden nie implizit geöffnet, und Aufrufer wählen den Bereich für öffentliche Ankündigungen. FIPS stellt signierte Ankündigungen der kind 37195 vor der Netzwerk-Discovery wieder her und prüft weiterhin Aktualität, Schema und Namespace. Anonyme oder private Discovery-Caches müssen von der öffentlichen Wiedergabe getrennt bleiben, und ein Router, der Daten aus dem Netzwerk abruft, sollte nicht als Wiedergabequelle verwendet werden. Da die Aufbewahrung begrenzt ist, ermöglicht dies keinen unbegrenzten Offline-Bootstrap.

FIPS-TS

Die FIPS-TS-Laufzeit 0.0.57 akzeptiert einen dauerhaften, von der Anwendung verwalteten Discovery-Provider, der signierte Ankündigungen der kind 37195 über die bestehende Schnittstelle veröffentlicht und abonniert. Ist ein Provider injiziert, öffnet der Transport keine Nostr-Relay-Clients und akzeptiert eine leere Relay-Liste, und beim Herunterfahren werden ausstehende Subscriptions abgearbeitet. Der Aufrufer verantwortet die Lebensdauer des Providers und den wiederhergestellten Speicher. Namespace-, Signatur- und Ablaufprüfungen gelten weiterhin. Eine Peer-Autorisierung bleibt erforderlich. Gecachte Ankündigungen garantieren keinen Offline-Bootstrap, da neues authentifiziertes Routing und WebRTC-Signalisierung weiterhin einen erreichbaren FIPS-Carrier benötigen.

Flotilla

Flotilla hat drei Quellcode-Änderungen gemergt. Share to Chat ermöglicht es, eigenständige Notizen und NIP-22-Kommentare in jeden Raum und jede Konversation zu teilen. Zitieren in einer Konversation fügt den zitierten Autor nicht mehr zu den p-Tags hinzu und spaltet die Mitgliedschaft nicht mehr ab. Das Fortsetzen unterbrochener Uploads stellt Anhang-Uploads aus Entwürfen wieder her und lässt Nutzer fehlgeschlagene Uploads beheben, indem ein Fehler angezeigt wird. Schlägt die Komprimierung fehl, wird auf die Originaldatei zurückgegriffen, die ihre Metadaten behalten kann. Das Warten auf gespeicherte Lesemarkierungen hält Schreibvorgänge für Lesemarkierungen einer Seite zurück, bis der gespeicherte Lesestatus geladen ist, sodass frühe Lese-Updates beim Start nicht verloren gehen.

following.space

Ein offener Pull Request für following.space, zu unserem Quellenstichtag nicht gemergt, würde das Erstellen, Bearbeiten und Löschen von Follow-Packs wiederherstellen, ebenso das Folgen der Mitglieder eines Packs. Er würde Applesauce für die Discovery von Konten und Outbox-Relays verwenden und Packs als naddr-Adressen teilen. Er unterstützt Signer per Browsererweiterung, ein nur im Arbeitsspeicher gehaltenes Secret und Bunker-Signer. Der Code und die vom Autor beschriebenen Tests belegen weder einen bereitgestellten Dienst noch die Kompatibilität mit jedem Signer.

Routstr

Drei Pull Requests für Routstr waren zu unserem Quellenstichtag offen und nicht gemergt. Im Kerndienst würde die Provider-Health-Discovery angekündigte URLs und Weiterleitungen zurückweisen, die auf nicht globale Adressen auflösen, und dabei die Onion-Proxy-Behandlung beibehalten. Die Autoren beschreiben eine Anfälligkeit für Server-Side Request Forgery (SSRF) sowie Tests, doch es handelt sich weder um einen bereitgestellten Fix noch um einen bestätigten Exploit. Im SDK würde die Zuordnung eines Providers zu einer URL dem Schlüssel folgen, der das Event der kind 38421 signiert hat. Ein im Inhalt angegebener pubkey bleibt unverifiziert. Unter den 81 Events, die der Autor auf dem Standard-Relay geprüft hat, enthielt keines inhaltsbasierte Provider-Listen, daher wird weder behauptet, dass bekannte URLs ausgenutzt wurden, noch dass jeder Provider nun sicher ist. Das automatische Pinning von Modellpfaden würde von eingebauten Konstanten zu signierten Snapshots in vertrauenswürdigen adressierbaren Events der kind 38427 wechseln. Das SDK würde den letzten gültigen Snapshot und Rollback-Wasserzeichen vorhalten, und ein leerer Snapshot würde als Notabschaltung dienen. Die Änderung bricht die API für eigene Adapter. Es wurden keine Richtlinien-Events veröffentlicht, und die Einführung bleibt ein Schritt des Betreibers.

SatSigner

Ein offener Pull Request für SatSigner, zu unserem Quellenstichtag nicht gemergt, überarbeitet dessen Nostr-Relay-, Cache- und Synchronisationsschicht. Das Nichtauffinden eines Events (die Antwort eines Relays, dass keine gespeicherten Events mehr folgen) würde von Timeouts und vom völligen Fehlen eines Relays unterschieden. Veraltete gecachte Inhalte würden gekennzeichnet. Events würden gespeichert, bevor die Verarbeitung Cursor vorrückt; Rumor-IDs von Gift Wraps würden verifiziert. Das Entfernen einer Identität würde deren Nostr-Tabellen löschen, doch eine Synchronisation der kind 0 kann eine lokale Profiländerung überschreiben. Ein darauf aufbauender Folge-Change würde geschwärzte Diagnosedaten hinzufügen, Video-Vorschaubilder im Nostr-Feed, die per Antippen geladen werden, mit höchstens drei Playern, sowie ein Nachholen beim Fortsetzen der App, ohne den Relay-Pool abzubauen. Er ergänzt außerdem Relay-Tests, die Fehler injizieren. Das neue native Videomodul erfordert einen Neubau der App, und die Validierung auf Geräten steht noch aus. Keine der beiden Änderungen wurde ausgeliefert oder hat eine Laufzeitprüfung bestanden.

Bray

Bray 3.5.4 ergänzt seinen NIP-46-Bunker-Client und -Daemon um Relay-Authentifizierung nach NIP-42. Private Relays, die AUTH verlangen, können nun genutzt werden, um an den Bunker adressierte Nachrichten zu lesen. Spätere Quellcode-Änderungen sind in diesem Tag nicht belegt.

In später gemergtem Quellcode startet Brays MCP-Server schreibgeschützt, wenn kein Signer konfiguriert ist oder BRAY_READ_ONLY erzwungen wird, und er trifft diese Entscheidung, bevor er Secrets öffnet. In diesem Modus wird keine Wallet geladen, Signieren, Verschlüsseln und Entschlüsseln werden verweigert, und nur 111 seiner 261 Tools, nämlich die Abfrage-Tools, sind verfügbar. CLI und SDK verlangen weiterhin einen Signer, und eine konfigurierte, aber leere Secret-Datei bleibt ein Fehler. Neue Attestierungen verwenden nun einen Label-Namespace für Attestierungen nach NIP-32, der nip-va ersetzt. Die bestehende #l-Typabfrage findet sowohl alte als auch neue Labels, während signet-protocol seine eigene Kopie in Version 2.5.5 behält. Dies ist keine offizielle NIP-Annahme und bedeutet nicht, dass jede verschachtelte Bibliothek migriert wurde. Für keine der beiden Änderungen ist belegt, dass sie in 3.5.4 enthalten ist.

Alby-Browsererweiterung

Ein offener Pull Request für die Alby-Lightning-Browsererweiterung, zu unserem Quellenstichtag nicht gemergt, würde ihren Berechtigungs-Helper gespeicherte Sperreinträge in einem einzigen Lesevorgang zurückweisen lassen. Damit wird eine Race Condition geschlossen, bei der das Entfernen eines Sperreintrags einem Nostr-Handler ermöglichen konnte, ohne Nachfrage zu handeln. Der entsprechende Pfad für Sperreinträge bei BTC und Liquid ist derzeit nicht erreichbar. Es handelt sich nicht um einen bereitgestellten Fix, und es wurde kein Exploit bestätigt.

MintRadar: Schreibrichtlinie für das Relay

Der Quellcode von MintRadar ergänzt eine Schreibrichtlinie für Betreiber des Nostr-Relays des Projekts. Sie begrenzt öffentliche Ankündigungen der kind 38172 und Bewertungen der kind 38000 auf 16.384 Zeichen serialisiertes JSON pro Event und auf 120 pro Stunde pro IPv6-/64, wobei komprimierte IPv6-Präfixe in eine kanonische Form gebracht werden. Für stark aktive Quellen gilt eine weiche Obergrenze von 3.000 pro Stunde, und eine absolute Obergrenze von 6.000 pro Stunde zählt nur angenommene Events über alle Quellen hinweg. Privilegierte Schlüssel sind unbegrenzt. Neue Verbindungen sind auf 120 pro Minute mit einem Burst von 60 begrenzt. Dies ist Code und Betreiberkonfiguration, kein Nachweis für eine Einführung im Produktivbetrieb oder einen vollständigen Schutz vor Denial-of-Service.

Neue Projekte

bosstro

Bosstro ist ein neuer Android-Client für Streitschlichter bei Mostro. Der Quellcode des MVP ist veröffentlicht, mit einem Flutter-Frontend auf dem Rust-Kern von Mostro. Schlichter signieren mit einem eigenen Schlichterschlüssel, nie mit dem Node-Schlüssel, und der Node gewährt jedem von ihnen Lese- oder Lese-Schreib-Berechtigung. Autorisierte Schlichter können Streitfälle übernehmen, verschlüsselten Käufer-Verkäufer-Chats beitreten, die Bilder und PDFs enthalten, und den Käufer auszahlen oder dem Verkäufer erstatten. Schlüssel liegen in einem durch Android Keystore gestützten Speicher, doch Entwicklungs-Builds für Linux und Web fehlen diese Schutzmechanismen. Veröffentlichte Prüfsummen beweisen nicht, wer der Herausgeber ist.

cordn-kmp

cordn-kmp ist eine neue Cordn-Implementierung in Kotlin Multiplatform, aufgebaut auf Quartz und mls-kmp für JVM, Android, iOS, macOS und Linux. Ihr Headless-CordnGroupManager erstellt Gruppen, lädt ein, tritt bei, sendet und holt Rückstände nach, und zwar über einen MCP-Koordinator über Nostr, ein anderes Modell als die Relay-Zustellung von Marmot. Frontends stellen ihre eigene Persistenz bereit, und die in der README behauptete Interoperabilität mit ts-mls stammt vom Autor.

Das Projekt hat inzwischen 1.1.0 veröffentlicht, das gegen das veröffentlichte Quartz 2.4.0 baut, sodass die frühere Anforderung eines lokalen Checkouts von unveröffentlichtem Quartz hinter einem Build-Flag für getaggte Releases nicht mehr gilt. 1.2.0 entfernt die öffentliche Methode CordnExposure.differsFromMarmot() und überlässt den Vergleich mit einem anderen Binding den Frontends. Trotz der Minor-Versionsnummer ist dies eine inkompatible API-Änderung. Ein Vorschlag hatte diese Version als 2.0.0 bezeichnet, und das tatsächliche Release verwendet 1.2.0.

emosphere

EmoSphere ist eine Nostr-Stimmungskarte, deren Quellcode nun öffentlich ist, und ihre README beschreibt Version 0.5.1. Jedes Gerät erzeugt seinen eigenen Schlüssel und veröffentlicht signierte Events der kind 1074 mit einer Emotion und deren Intensität, einer optionalen kurzen Notiz und einem groben Standort, den Nutzer abschalten können. Beiträge erscheinen auf einer Weltkarte mit zeitlicher Wiedergabe und einem Feed gefolgter Konten. Diese Signale sind öffentlich und pseudonym, sodass Relays Stimmung und Standort lesen und sie im Lauf der Zeit einem Schlüssel zuordnen können. Android bewahrt Schlüssel in sicherem Speicher auf, während die Webversion localStorage verwendet.

matrix-appservice-nostr

matrix-appservice-nostr ist Prototyp-Quellcode für einen Matrix-Application-Service, gekoppelt mit einem Nostr-Relay. Matrix-Nutzer können Nostr-Identitäten erstellen oder importieren und aus Matrix-Räumen heraus posten, folgen, antworten, reagieren und DMs senden, mit NIP-05-Handles auf der Bridge-Domain. Inhalte und Medien bleiben im Matrix-Backend, und das Relay baut Events aus gespeicherten Originalen neu auf. Schlüssel werden mit AES-GCM unter einem konfigurierten Secret verschlüsselt oder über NIP-46 extern gehalten. Nutzer müssen dem Betreiber vertrauen, und eine Matrix-Redaction entfernt nur die Kopie der Bridge.

Sieben neuere Commits ergänzen Schatten-Identitäten für Nostr. Die Bridge erstellt sie automatisch für berechtigte Matrix-Nutzer, die nach außen interagieren, mit Profilen, die Matrix spiegeln. Das Anlegen eines vollständigen Profils wertet das bestehende Konto an Ort und Stelle auf und behält denselben Schlüssel. Bridge-Admins können externen Nutzern oder Homeservern vollen oder Schatten-Zugriff gewähren oder einen auf Räume beschränkten passiven Zugriff für Antworten, Reaktionen und Abstimmungen. Eine Berechtigung oder Sperre für einen bestimmten Nutzer hat Vorrang vor Homeserver-Regeln, die wiederum Vorrang vor Raumregeln haben. Volle Berechtigung erlaubt das Anlegen eines Profils, veröffentlicht aber nicht automatisch eines. Ein Widerruf des Zugriffs behält Schlüssel, Verlauf und Räume bei, stoppt aber das Posten nach außen, wo es nicht mehr erlaubt ist. Importierte Identitäten werden nie mit einem gespiegelten Profil überschrieben. Die Prüfungen sind mit Code und Tests hinterlegt, jedoch ohne Verifikation der Interoperabilität zur Laufzeit oder der Sicherheit, und das Vertrauen in die Schlüsselverwaltung des Betreibers bleibt erforderlich. Sticker werden nun als Bilder versendet.

nostr-scrutiny

Nostr Scrutiny veröffentlicht Quellcode und auf den 24. Oktober datierte Faktenblätter, die fünf Nostr-Clients vergleichen: Amethyst, Damus, Nostrich, Primal und Quill. Jedes Blatt behandelt die Datenschutzangaben des Clients im App Store und den veröffentlichten Code sowie die Netzwerkanfragen, die bei einem ersten Browserbesuch beobachtet wurden. Die als statisches, schlichtes HTML gebaute Website gibt an, kein First-Party-Tracking zu betreiben. Die Blätter sind eine datierte Bestandsaufnahme von Fakten, keine Sicherheitszertifizierung und kein kryptografisches Audit. Als offengelegter Interessenkonflikt entwickelt der Autor auch Quill.

v2

Solid Chat v2 ist neu veröffentlichter Client-Quellcode, der einen einzigen did:nostr-Schlüssel verwendet, um mit NIP-98-HTTP-Auth in Räume auf Solid-Pods zu schreiben und per NIP-17 als Gift Wrap verpackte DMs zu senden. Signieren funktioniert über NIP-07, NIP-46 oder einen lokalen nsec, mit NIP-44-Verschlüsselung und Wraps der kind 1059. Räume sind Klartext und nur durch die ACL des jeweiligen Pods geschützt. Verschlüsselte DM-Medien werden zu Blossom hochgeladen, und Profilabfragen gehen an ein Verzeichnis von nostr.social. Ein lokaler nsec liegt in localStorage, daher ist ein externer Signer sicherer.

witchat

Witchat ist Quellcode für einen inoffiziellen bitchat-Client unter Windows und Linux. Er chattet über ein Bluetooth-Mesh in der Nähe und weicht zwischen gegenseitigen Favoriten auf Nostr-Gift-Wraps aus. Außerdem tritt er öffentlichen Geohash-Kanälen auf Nostr bei und nutzt dabei Events der kind 20000 für Nachrichten und der kind 20001 für Präsenz. Die Interoperabilität mit den Transporten von bitchat ist eine Behauptung des Autors, und die Windows-Binärdateien sind nicht signiert. Nostr-Relays können IP-Adressen und Kanalmetadaten sehen, und Übertragungen in der Nähe laufen derzeit nur über Bluetooth.

wn-notify

wn-notify ist eine inoffizielle Python-CLI, die nur die Standardbibliothek nutzt und Nachrichten und Dateien über einen lokalen wn-agent über den Unix-Socket marmot.agent-control.v2 an White-Noise-Gruppen sendet; der Connector verwaltet Schlüssel, MLS-Zustand und Relays. Die CLI prüft auf final_sent und Nachrichten-IDs. Bei unbekanntem Ergebnis beendet sie sich mit einem von null verschiedenen Exit-Code als unbekannt und behält den Idempotenzschlüssel für einen manuellen erneuten Versuch, da sie selbst nie erneut versucht. Eine Bestätigung belegt die Veröffentlichung über ein Relay, nicht dass jemand die Nachricht gelesen hat. Getestet wurde nur wn-agent 0.13.0.

xmradar

XMRadar ist eine Browsererweiterung, die Webbeiträge und X-Artikel nach Nostr kopiert. Jede Veröffentlichung wird über einen externen NIP-07-Signer freigegeben. Release 0.2.0 ergänzt Monero-Trinkgelder auf X für Autoren, die eine Nostr-Identität haben.

Die Implementierung veröffentlicht eine Quittung der kind 9042 erst, nachdem der Nutzer angibt, ein Trinkgeld gesendet zu haben, und dies bestätigt. Die Quittung macht die npubs beider Beteiligten, den Betrag und die Adresse öffentlich. Sie enthält weder Transaktions-ID noch Transaktionsschlüssel noch Zahlungsnachweis. Ein kleiner zufälliger Piconero-Betrag lässt die Wallet des Empfängers die Zahlung zuordnen und eine Bestätigung der kind 9044 veröffentlichen. Diese Bestätigung wird vom Empfänger signiert und ist kein unabhängiger Onchain-Nachweis. Die Oberfläche unterscheidet vom Empfänger bestätigte Trinkgelder von unbestätigten Angaben. Eigene Trinkgelder eines Nutzers bleiben 30 Minuten lang ausstehend. Unbestätigte Angaben zählen einmal pro Zahler, und zwar mit der kleinsten Quittung an die aktuelle Adresse; diese Angaben können gefälscht werden. Summen werden pro Autor geführt, nicht pro Beitrag. Die Adresserkennung über X-Nachweise nach NIP-A3 und NIP-39 ist standardmäßig deaktiviert. Ist sie aktiviert, können Relays und X sehen, welche Identitäten sich der Nutzer ansieht.

agent-inbox

agent-inbox ist ein neues Tool, mit dem KI-Agenten einander über kurze Handles über Nostr erreichen. Eine einzige Python-Datei sendet standardkonforme NIP-17-Gift-Wraps mit NIP-44-v2-Verschlüsselung, kann auf ein öffentliches Board posten und enthält Fixtures aus den offiziellen Testvektoren. Handles sind gekürzte Suffixe öffentlicher Schlüssel, keine zertifizierten Identitäten. Die README warnt, dass die reine Python-Kryptografie nicht in konstanter Zeit läuft, und wir haben sie nicht auditiert. Jeder NIP-17-Client kann der npub eines Agenten weiterhin Nachrichten senden.

CarryChat

CarryChat ist ein neuer Store-and-Forward-Messenger, der begrenzte Nachrichtenbündel über den jeweils verfügbaren Weg überträgt. Nostr ist sein Internettransport, und lokale Verbindungen wie Bluetooth LE und einfacher Dateiaustausch decken die Offline-Fälle ab. Der Quellcode enthält den Nostr-Transport samt Tests dafür. Die README bezeichnet dies als frühes Release 0.2 und gibt an, dass LoRa-Feldtests auf physischer Hardware noch nicht abgeschlossen sind. Wir haben es nicht auf Geräten getestet.

Dreizehn neuere Commits, bis einschließlich 311f176, ersetzen Roadmap-Platzhalter durch funktionierenden Quellcode. Sie umfassen Wi-Fi Direct, einen MeshCore-Funkadapter, Reticulum-Verbindungen, NFC-Kontaktkarten und einen Audio-Transport, mit Kotlin-, Rust- und UI-Code. Über Audio verifiziert der Empfänger die Signaturen von Kontaktkarten und akzeptiert normale Nachrichten-Frames, verweigert aber Dateifragmente. NFC tauscht nur Kontaktkarten aus, keine Nachrichten. Dies ist Quellcode-Entwicklung nach dem früheren Release 0.2.0, keine neue verifizierte Binärdatei. Laut README stehen für MeshCore und LoRa, Reticulum, Wi-Fi Direct und NFC noch Feld- oder Zwei-Telefon-Tests aus. Die Änderungen beanspruchen weder Hardwarekompatibilität noch Anonymität noch Sicherheit. Hochfrequentes Audio hängt von der Hardware ab und ist nicht überall unhörbar. Nostr bleibt ein Internet-Relay-Transport neben den lokalen Verbindungen.

Cosign und Marble

Cosign ist ein neues Beta-Protokoll samt Bibliothek, das einen Nostr-Signaturschlüssel in FROST-Schwellenwert-Anteile aufteilt. Das Gerät eines Nutzers kann gemeinsam mit einem Server signieren, Server können jedoch nicht allein signieren. Ein Papier-Backup-Anteil unterstützt die in der README beschriebenen Abläufe für Wiederherstellung und Erneuerung von Anteilen, die nicht sicherheitsgeprüft wurden. Marble, ein Android- und Browser-Client, nutzt Cosign für Feeds und Signaturen. Die zugrunde liegende FROST-Bibliothek wurde auditiert, das eigene Protokoll von Cosign hat jedoch keine unabhängige Prüfung erhalten.

In neuerem Quellcode bindet der Browser-Client von Marble nicht gesendete Notizen an das angemeldete Konto. Vor dem Veröffentlichen erkennt er, wenn ein anderer Tab oder eine entfernte Sitzung die Anmeldung beendet hat, und eine Anfrage eines abgemeldeten Clients zeigt Signed out an. Die Sofortsuche fragt Ditto und Relays ab, nicht das allgemeine Web. Die Suche in den Beiträgen eines einzelnen Autors prüft bereits geladene Beiträge, bevor Relays angefragt werden. Wahrscheinlicher Spam wird hinter einem aufklappbaren Hinweis eingeklappt. Eine Not-Spam-Ausnahme gilt nur in diesem Browser und nur für diesen Autor. Diese Such-Helfer sind kein Beleg für eine Sicherheitsprüfung.

Cosign 0.12.7 lässt Zusammenführungen der Mitgliederliste nur noch von Servern zu, was verhindert, dass ein Papier-Backup-Anteil in eine andere Rolle hochgestuft wird. Nach einer Epochensynchronisation werden veraltete Server als zurückliegend markiert. Ungültige Teilergebnisse werden abgelehnt; die automatische Reparatur bleibt deaktiviert. Entschlüsselungs-Teilergebnisse tragen nun Chaum-Pedersen-Beweise, die geprüft werden, bevor die Teilergebnisse kombiniert werden. Ältere Clients ignorieren die Beweise, und der Android-Teil von Marble kommt mit seinem nächsten Build. Diese Sicherheitsbeschreibungen stammen vom Autor des Releases, und wir haben die Kryptografie nicht auditiert.

Android-NIP-55-Quellcode, der nach dem Tag 0.12.7 committet wurde, behebt eine Race Condition bei der ersten Verbindung, wenn die Berechtigung des Servers noch über Relays unterwegs ist. Abfragen des öffentlichen Schlüssels werden nun sofort beantwortet. Signieren und Entschlüsseln warten außerhalb des UI-Threads und versuchen es einmal erneut, und zwar nur, wenn eine frisch berechtigte Verbindung eine Widerrufsantwort erhält. Der Code unterscheidet außerdem einen nicht erreichbaren Server von einem, der mit einer Ablehnung antwortet. Für diesen späteren Quellcode-Fix ist nicht belegt, dass er im Tag 0.12.7 oder in einer aktuellen Marble-Binärdatei enthalten ist.

Dream Nests

Dream Nests ist ein neues, rein lesendes Verzeichnis von Live-Audioräumen auf Nostr, das Nests-Räume und Live-Activity-Events samt ihrem Chat zusammenführt. Für Screenreader verwendet die Web-App Überschriften und höfliche Ansagen über Live-Regionen, und kurze Earcons dienen als akustische Hinweise. Sie spielt öffentliche HLS-Streams nur zum Zuhören ab. Nests-Räume öffnen sich in Nests, während Räume von Corny Chat und HiveTalk auf deren eigenen Websites geöffnet werden, sodass das Sprechen in diesen Apps bleibt. Mikrofonanzeigen stammen aus Präsenz-Metadaten, nicht aus einer Sprachaktivitätserkennung. Wir haben die Barrierefreiheit nicht auf Geräten getestet. Das Repo dokumentiert eine öffentliche Live-URL.

fips-pub-pki

fips-pub-pki ist neuer Quellcode für signierte Nostr-Zertifikate, mit denen eine Domain an untergeordnete Aussteller delegieren kann, mit Offline-Pfadvalidierung. Vertrauensanker stammen aus dem Begleitprojekt fips-pub-domains, das DNSSEC-Angaben mit Pins und Zeugen kombiniert. Der Verifizierer fragt nie DNS ab. Der Widerruf stützt sich auf Ablauf und explizite Markierungen, nicht auf das Löschen von Events von Relays. Laut README sind Live-Mesh-Tests mit einer öffentlichen Domain und einem Telefon noch nicht abgeschlossen. Da weder ein NIP eingereicht noch eine kind registriert wurde, handelt es sich um ein Experiment, keinen Ersatz für TLS.

Magnetar

Magnetar ist ein neuer Such-Stack für NIP-35-Torrent-Events. Er kombiniert einen Crawler und ein Such-Backend mit einer Android-App, die einen lokalen SQLite-Cache vorhält. Vertrauen in Publisher leitet er aus Follows ab, und er prüft, ob ein Schwarm aktiv ist. Die erste Vorabversion 0.1 enthält Crawler-Code sowie Tests für Android und den Server. Der Autor hat sie nur mit automatisierten Tests und einem Emulator geprüft, nicht auf echten Telefonen. Follow-basiertes Vertrauen kann einen Torrent weder legal noch sicher machen, und das Backend ist kein maßgeblicher Index.

Magnitude Relay

Magnitude Relay ist ein neues Nostr-relay in Rust von VectorPrivacy, abgestimmt auf Vectors gift-wrapped DMs und den Concord-Verkehr, mit NIP-77-Sync und Tippindikatoren. Laut den Betreibern hat es strfry an zwei bestehenden Vector-Endpunkten ersetzt. Das Repository enthält Harnesses für adversariale Tests und Benchmarks, doch die veröffentlichten Geschwindigkeitswerte stammen aus eigenen Durchläufen des Autors und wurden nicht unabhängig reproduziert.

Inzwischen wurde ein Docker- und Compose-Paket für Betreiber gemergt. Es läuft als unprivilegierter Benutzer mit einem Daten-Volume, einer nur lokalen Bindung und einem Healthcheck. Die Beobachtungen zu Produktion und Import im Pull Request stammen vom Autor, und arm64 ist ungetestet. Die Paketierung allein belegt keine Protokollkonformität.

Neuerer Quellcode begrenzt neue Verbindungen pro IP standardmäßig auf einen Burst von 300, danach auf 60 pro Minute. Ein Limit von 0 deaktiviert die Begrenzung, und Loopback ist ausgenommen. Dem Real-IP-Header eines Proxys wird nur von localhost aus vertraut, und abgewiesene Verbindungen erhalten HTTP 429, bevor der WebSocket geöffnet wird. Ablehnungen durch das öffentliche relay werden nur aggregiert gemeldet, Details pro IP gibt es nur über den Admin-Socket. Der Massen-Sync über NIP-77 lässt ephemere events und events aus, die innerhalb von 600 Sekunden ablaufen, während die Live-Zustellung kurzlebige events weiterhin überträgt. Ändern sich vertrauenswürdige Verknüpfungen, überspringt das relay redundante Sichtbarkeitsprüfungen für Gift Wraps, synchronisiert die Gift Wraps aber weiterhin. Es handelt sich um Änderungen im Quellcode ohne gemessenen Produktions-Benchmark.

nostr_doctor

nostr_doctor ist eine neue Dart-Bibliothek mit CLI und Flutter-Frontend, die prüft, ob Clients die Daten eines Kontos auffinden können. Sie beginnt mit Profilmetadaten und NIP-65-relay-Listen und deckt anschließend private DM-relays und Entwürfe sowie Blossom-Server und Nutzap-Einstellungen ab. Um die Auffindbarkeit der relay-Liste zu prüfen, fragt sie die ersetzbare Liste ab. Wir haben das Diagnosewerkzeug als Quellcode geprüft und kein App-Release verifiziert. Die Ergebnisse spiegeln nur die abgefragten relays wider und zeigen keine globale Verfügbarkeit.

nostr-indexer-relay

nostr-indexer-relay ist ein neues relay in Go, das ausschließlich NIP-65-relay-Listen speichert. Sein Crawler findet die in diesen Listen genannten relays, prüft sie auf NIP-77-Unterstützung und synchronisiert sich über Negentropy mit anderen aktiven Indexern. Es enthält eine öffentliche Abfrageseite und eine Admin-Oberfläche und bezeichnet sich selbst als frühes Stadium. Es ist ein gezielter Index für relay-Listen, kein Nostr-Archiv und kein allgemeines Content-relay.

nostr2gh

nostr2gh ist eine neue Brücke, die NIP-34-Patch- und Pull-Request-events samt ihren Aktualisierungen über einen freigeschalteten Relayer von Nostr zu GitHub überträgt. Ein Mitwirkender pusht einen Branch an einen abrufbaren Ort und signiert ein Nostr-event, und ein Bekannter mit funktionierendem GitHub-Konto eröffnet dann den PR für ihn. Das Werkzeug hilft Mitwirkenden ohne GitHub-Zugang, umgeht eine Sperre aber nicht automatisch und erteilt keine Erlaubnis, nicht vertrauenswürdige Patches automatisch auszuführen.

Relay Radio

Relay Radio ist eine neue reine Lese-Web-App, die einen Live-Nostr-Feed mit Earcons und Text-to-Speech des Browsers in Klang verwandelt, ergänzt um eine optionale höfliche Live-Region für Screenreader-Nutzer. Hörer wählen einen kuratierten globalen Sender oder einen, der aus Personen gebildet wird, denen sie folgen, und hören Notes, Antworten, Reposts, Reaktionen und zaps. Die App postet und zahlt nie im Namen des Hörers. Die Inhaltsfilterung erfolgt nach bestem Bemühen und kann daher nicht garantieren, dass alles Vorgelesene unbedenklich ist.

Hibiki

Hibiki ist ein eigenständiges Feed-Napplet für Torii, und sein Quellcode bezeichnet Version 0.2.1 als ersten funktionierenden Feed. Ein Node ruft öffentliche Beiträge und Medien ab, und das am Geschmack des Nutzers orientierte Ranking läuft im Browser. Der Feed läuft in einem sandboxed iframe ohne direkten Netzwerkzugriff und behandelt signierte Spam-Reputation nur als Empfehlung. Die Datenschutzgrenze haben wir nicht unabhängig überprüft.

Gemergter Quellcode bis Version 0.2.6 ergänzt Inline-Antworten und extraktive Nachrichtenzusammenfassungen, und Likes ordnen Beiträge nicht mehr neu, wobei ein getaggtes Release weiterhin unbestätigt ist. Die Vorschau-Unterstützung im Watch-Player fügt Vorschaubilder hinzu, und Zaps kommen zusammen mit Profilseiten. Der Node prüft bei jeder Rechnung Betrag und Description-Hash. Jede Zahlung erfordert die Bestätigung des Besitzers, wobei der Zahlende WebLN oder einen QR-Code nutzt, und der Node verwahrt weder Guthaben noch Schlüssel. Rechnungen von Primal-Adressen fehlt der Description-Hash, daher akzeptiert eine Folgeänderung sie, wenn der Betrag exakt übereinstimmt; sie werden mit bound:false markiert, und der Besitzer wird gewarnt, dass die Wallet sie womöglich nicht bestätigt. Das schwächt die Verbindung zwischen Rechnung und zap-Anfrage und macht sie nicht zu gültigen NIP-57-Bestätigungen. Bei 5xx-Fehlern und Timeouts der Wallet wird einmal wiederholt und der LNURL-Grund angezeigt; einen erfolgreichen End-to-End-zap mit einer echten Wallet hat der Autor noch nicht gemeldet.

wax

wax ist ein neuer Signer in Common Lisp, der Rollenschlüssel aus einem BIP-39-Seed ableitet und jede Anfrage durch einen Policy-Guard leitet, der standardmäßig ablehnt, sofern kein Genehmigungs-Callback und keine Allowlist sie zulässt. Envelope-Sequenzen pro Aufrufer schützen vor Replay. Die Methodennamen ähneln NIP-46, doch der Kern liefert keinen Netzwerktransport. Wir haben den Signer keinem Sicherheitsaudit unterzogen.

WhatZaps

WhatZaps ist eine neue Browsererweiterung, die WhatsApp-Kontakte per Lightning bezahlt, und zwar über die WebLN-Unterstützung der Nostr-WoT-Erweiterung. Sie ordnet einen Kontakt einem Nostr-Profil zu, prüft dessen Zahlungsadresse und fragt vor jeder Zahlung ausdrücklich nach Bestätigung. Der Befehl /zap wird nicht als Chatnachricht gesendet, und der Weg über Reaktion oder Schaltfläche zahlt, ohne etwas zu posten. Es handelt sich um Lightning-Zahlungen, die Nostr zum Nachschlagen von Identitäten nutzen, nicht um signierte NIP-57-zap-Belege. Den Nachrichtenabgleich im Browser haben wir nicht getestet.

Agora: verschlüsselte Umfragen

Agora ist ein Browser-Prototyp für verschlüsselte Gruppenumfragen. Er kombiniert Bürgschaften von Mitgliedern mit blinden Abstimmungstickets und überträgt den Verkehr über Nostr-relays und WebRTC. Die README beschreibt das Design als „ein echter Mensch, eine Stimme“, doch das hängt vom Vertrauen in den Ticketaussteller ab, der Tickets fälschen kann, sowie von Bürgschaften als Form sozialen Vertrauens. Das Design bietet keinen Schutz vor Nötigung. Relays können Zeitpunkte und IP-Adressen sehen; die Ergebnisse hängen davon ab, welche events ein Client empfängt. Das Projekt hat nichts mit dem älteren Chatprojekt ghobs91/Agora zu tun.

Cinderous SDK

Cinderous SDK v0.83.0 ist ein neuer Quellcode-Prototyp, der jedem Gerät einen eigenen Schlüssel zuweist und Dokumente mit Git-ähnlicher Historie über Nostr und WebRTC synchronisiert, bei Bedarf mit relays als Ausweichweg. Der Aufrufer wählt und betreibt die relays, und das SDK liefert kein voreingestelltes öffentliches relay mit. Die Verschlüsselung nutzt ein experimentelles CinderEK-Verfahren mit Double Ratchet, das nicht extern auditiert wurde. Der hybride Schlüsselaustausch macht die secp256k1-Signaturen nicht quantensicher, und die README bezeichnet das SDK als nicht produktionsreif.

evil-napplets

evil-napplets hat die Stufen 02 bis 08 seiner Angriffsleiter ergänzt, um Hosts zu testen, die Napplets unter dem Opaque-Origin-Modell des Entwurfs NIP-5D ausführen. Die bösartigen Napplets testen Capability- und Bridge-Grenzen und melden, was der Host zugelassen hat. Standardmäßig ist der Demonstrationsmodus aktiv, aktive Modi müssen ausdrücklich eingeschaltet werden. Aktive Tests sollten nur gegen Hosts laufen, deren Prüfung dem Tester erlaubt ist. Die Suite ist ein Red-Team-Testaufbau, ein Host, der sie besteht, ist also nicht als sicher erwiesen. Sie ist ein von evil-napps getrenntes Projekt, das auf eine andere App-Architektur zielt.

evil-napps

evil-napps ist eine neue Quellcode-Suite, die Berechtigungsgrenzen in NAPP-Launchern testet. Sie deckt die Launcher-Bridge und den den Apps bereitgestellten NIP-07-Signer ab. Auch der SharedDB-Speicher gehört dazu. NAPP-Bundles kombinieren Metadaten mit einer Index-Datei, ein anderes Format als das einzelne HTML-Artefakt, das NIP-5D-Napplets verwenden. Laut README läuft die Suite standardmäßig im Demonstrationsmodus und führt aktive Tests nur auf ausdrückliche Anforderung aus. Ihre Tests und ihr Harness zertifizieren keinen Launcher.

Feedstr

Feedstr ist ein neuer RSS-Reader in Rust, der Feeds, Lesestatus und Favoriten verschlüsselt über Nostr synchronisiert. Der Sync lässt sich für einzelne Feeds abschalten. Er unterstützt OPML-Import und -Export und verarbeitet NIP-23-Langformartikel. Das Repository enthält Quellbäume für Core, Android, Web und Flatpak. Laut README ist die Software kaum getestet und nicht zur Nutzung empfohlen, und Installations- sowie Nutzungsanleitungen sollen bald folgen.

NKIP-Toolkit für Einzahlungsbelege

KYC-rip/nkip-0001 ist ein neues TypeScript-Toolkit, gepflegt von XBToshi, für NKIP-0001-Einzahlungsbelege. NKIP-0001 ist ein Belegformat auf Anwendungsebene und kein angenommener Nostr-NIP. Das Toolkit verarbeitet Ed25519-signierte Einzahlungsbelege, gesalzene Commitments, Nostr-Zeugen-events und die Wiederherstellung des Salts über NIP-44-Verschlüsselung. Sein Schutz hängt davon ab, dass die Anwendung die Einzahlungsadresse zurückhält, bis der Zeuge beobachtet wurde. Das SDK sperrt keine Bestellungen und garantiert keine Auszahlungen. Details stehen in der README.

nostr-parse

nostr-parse ist ein neuer Parser in Rust von VectorPrivacy für signierte Nostr-events. Er erzwingt die strikte Event-Form mit sieben Feldern, verlangt nichtnegative Ganzzahlen, beschränkt kinds auf den u16-Bereich, prüft Hex-Felder und validiert escapte Strings. Fehler werden mit Offsets gemeldet. Aufrufer können kompakte eigene Allokationen oder geliehene Spans in die Eingabe erzeugen, und parse_unsigned akzeptiert unsignierte NIP-59-Rumors. Das Parsen berechnet die Event-ID nicht neu und verifiziert die Schnorr-Signatur nicht, Aufrufer müssen diese Prüfungen also weiterhin selbst durchführen.

cl-deposits

cl-deposits ist eine neue Implementierung von Bitcoin Deposits in Common Lisp. In diesem Design führt ein Betreiber signierte, von einem Quorum mitsignierte Hash-Chain-Ledger über Nostr, gedeckt durch Taproot-Reserven. Das Repository enthält den Quellcode und ein Devnet mit Inspektionstests. Laut README und ROADMAP hat der Autor die Referenz-Fixtures erneut abgespielt, ein Signet-Devnet betrieben und die Interoperabilität mit deposits-rust in beide Richtungen getestet. Der Autor berichtet zudem, dass der Lightning-Empfangspfad funktioniert, und nennt InvoiceLock und Fulfill für Zahlungen als nächste Schritte. Nutzer sind auf den Betreiber, das mitsignierende Quorum und die Annahmen zu den Reserven angewiesen.

Streets

Streets, ein spaltenbasierter Nostr-Webclient, der Timelines, Benachrichtigungen und Suche nebeneinander zeigt, hat eine Änderung gemergt, die das Standard-Reaktions-Emoji im NIP-78-Deck-Dokument des Kontos (kind 30078) speichert. Nutzer müssen es nach erneutem Einloggen oder auf einem anderen Gerät nicht mehr neu auswählen. Bisher wurde die Wahl nur im localStorage des Geräts gespeichert. Das Deck-Dokument ist mit NIP-44 verschlüsselt, daher erfordert die geräteübergreifende Synchronisation eine Anmeldung mit einer Erweiterung oder einem Signer, der Verschlüsselung unterstützt. Bei anderen Anmeldearten bleibt die Einstellung auf dem Gerät. Hat ein Konto keine gespeicherte Reaktion, wird der vorhandene Gerätewert verwendet, sodass die Einstellung nicht auf das Herz zurückfällt. Ein ungültiger gespeicherter Wert wird verworfen, ohne den Rest des Decks zu verwerfen. Die Änderung ist im Quellcode, und die Release Notes zu 1.22.0 sind noch ein Entwurf.

Labradorite

Labradorite ist eine Android-App zur Steuerung von Coding-Agent-Sitzungen auf einem gekoppelten Linux-Rechner und hat 0.1.0 und 0.2.0 veröffentlicht. Das Telefon ist nur die Steueroberfläche. Ein Daemon auf dem Rechner führt den Agenten aus und tauscht Marmot-MLS-Nachrichten über gewöhnliche Nostr-relays aus, mit einer Gruppe pro Sitzung. Er akzeptiert nur npubs auf einer Allowlist, die standardmäßig leer ist (Quellcode). Version 0.1.0 startet oder setzt genehmigte Sitzungen fort, streamt Text, Tool-Aufrufe und Diffs und verarbeitet Genehmigungen und Rückfragen. Außerdem bietet sie Git-Steuerung und reines Lesen von Dateien. Version 0.2.0 reiht Folgeanweisungen als separate Turns ein, lässt Nutzer sie vom Telefon aus abbrechen, bewahrt eingereihte Arbeit über Neustarts des Daemons hinweg und spielt verpasste Historie nach dem Wiederverbinden nach. Dies sind Angaben des Herausgebers, und wir haben die Sicherheit nicht unabhängig auditiert.

Nomisma

Nomisma ist ein Android-Ledger für gemeinsame Ausgaben in der Prototyp-Beta, das zwei Teilnehmer über private Nostr-Nachrichten koppelt. Es erfasst nur Salden und bewegt oder begleicht kein Geld. Version 0.1.3 verbindet gekoppelte Geräte automatisch neu, wiederholt gespeicherte Änderungen mit wachsenden Abständen und ergänzt NIP-42-relay-Authentifizierung. Außerdem sendet sie fehlende Operationen erneut. Die beiden Geräte vergleichen einen SHA-256-Fingerabdruck von Einträgen, Zahlenden und Aufteilungen erst, wenn ihre Vektoruhren pro Autor übereinstimmen. Beide Geräte benötigen 0.1.3 und übereinstimmende relay-Einstellungen, weil sich das Standard-relay geändert hat. Checkpoints werden mit einem 15-minütigen NIP-40-Ablauf gift-wrapped, der relays auffordert, sie zu verwerfen, aber keine Löschung garantiert. Die Notes nennen Korrekturen beim Laden nativer Bibliotheken, bei der Argumentreihenfolge für Schnorr und bei der NIP-44-Schlüsselableitung, und wir haben die Sicherheit nicht unabhängig auditiert. Das Signieren für den Nutzer läuft über Amber, doch es gibt auf dem Gerät auch ephemere Schlüssel. Die Angaben zur Verteilung widersprechen sich beim APK-Signaturzertifikat, daher haben wir die Upgrade-Kompatibilität hier nicht bewertet.

Onyx

Onyx ist ein Prototyp für ein privates Tagebuch, verfügbar als Quellcode, kein geprüftes Release. Es hält datierte Markdown-Dateien auf dem Gerät als maßgebliche Quelle und sichert sie als verschlüsselte kind-30078-events auf relays. Gesalzene d-Tags vermeiden, dass Eintragsdaten direkt sichtbar werden. Die Wiederherstellung erfordert den separaten lokalen Verschlüsselungsschlüssel, Nutzer müssen ihn also sichern, denn der npub allein kann das Tagebuch nicht wiederherstellen. Ein Patch vom 27. Oktober ergänzt eine Schutzprüfung, die vor dem Veröffentlichen die Integrität der Anfragefelder kontrolliert: kind, Inhalt, pubkey, tags und Zeitstempel des vom Signer zurückgegebenen events müssen der Anfrage entsprechen. Der Patch lehnt außerdem Downloads vom falschen Autor ab, behält neuere lokale Bearbeitungen und ersetzt Daten bei der Wiederherstellung atomar. Autoren und Zeitstempel der events bleiben öffentlich. Klartext, der an den Verschlüsselungsbefehl übergeben wird, kann kurzzeitig bei lokaler Prozessinspektion sichtbar werden, und das Löschen eines Eintrags entfernt keine Kopien auf relays.

Zzub

Zzub 0.0.41 ist ein Community-Client, ein Fork von Buzz. Laut den kurzen Notes des Herausgebers bringt diese Version Kalender-Zusagen mit Zeitzonenunterstützung, Profil-zaps, die Anzeige von NIP-58-Badges und eine Huddle-Schaltfläche, die einem laufenden Meeting beitritt. Die Agent-Steuerung erhält eine Neustartoption, die Bearbeitung einer vom Budget ausgenommenen Liste und neue Typen von Aufgabenkarten. Beim Start werden nun zwischengespeicherte Kanäle verwendet.

Protokoll- und Spezifikationsarbeit

NIP-CD definiert als Klartext aufgerufene Befehle

Die NIP-CD-Spezifikation, zuerst „Commands“ und jetzt „Slash Commands“ betitelt, wurde am 21. Oktober in das NIPs-Repository gemergt (Prüfung des Vorschlags). Ein Executor kündigt einen Befehl in einem kind-31992-event an, das Trigger, Titel, Beschreibung, typisierte Positionsargumente und Geltungsbereiche auflistet. Nutzer rufen ihn als Klartext am Anfang des Event-Inhalts auf, optional ergänzt um den npub des Executors, sodass weder befehlsspezifische tags noch Client-Unterstützung nötig sind. Ein bloßer Trigger kann auf mehrere Executoren passen. Clients dürfen Autovervollständigung anbieten, aber nicht voraussetzen.

Marmot führt mehrere Geräte pro Konto ein

Marmot, ein MLS-basiertes Protokoll für verschlüsselte Gruppennachrichten über Nostr, hat seine Regeln für Konten mit mehreren Geräten gemergt (Prüfung des Vorschlags), am 26. Oktober und in einer gegenüber dem früheren Entwurf überarbeiteten Form. Ein Einladender darf in einem Commit höchstens 20 KeyPackages für ein Konto hinzufügen. Jedes Gerät hält genau einen lebenslangen zufälligen Veröffentlichungsslot und kopiert niemals MLS-Zustand oder private KeyPackages. Packages sollten 30 Tage gültig sein und alle 7 Tage erneuert werden. Einladende senden jedem berechtigten Gerät ein eigenes Welcome, und das Entfernen eines Kontos entfernt alle seine Leaves.

Marmot lässt Mitglieder die Leaves ihres eigenen Kontos verwalten

Marmot hat eine Mitgliedschaftskomponente für dasselbe Konto übernommen, marmot.group.account-devices.v1 (ID 0x800d), die keine Daten trägt. Wenn die Gruppenaushandlung die Komponente verlangt, kann ein Mitglied Adds und Removes für das eigene Konto ohne Admin-Berechtigung committen. Unter dieser Komponente kann das Mitglied weder das eigene Leaf des Committers noch andere Konten entfernen, und der Admin-Status des Kontos ändert sich nicht. Bestehende Gruppen müssen die Komponente aktivieren und ihre Unterstützungsinvarianten erfüllen.

Marmot-Push-Trigger erhalten frisches Padding

Marmot verlangt jetzt frisches Padding in jedem Push-Trigger, gemergt am 26. Oktober. Jeder kind-446-Trigger enthält mindestens einen frischen CSPRNG-Padding-Block von 1.084 Byte, sodass im Budget von 32 Blöcken höchstens 31 echte verschlüsselte Tokens Platz finden. Ohne frisches Padding würden identische Token-Bytes es der Deduplizierung per Inhalts-Hash erlauben, legitime spätere Benachrichtigungen zu unterdrücken. Server hashen alle Blöcke und dürfen einen strukturell gültigen Trigger nicht ablehnen, nur weil sie das Padding nicht erkennen können. Padding verbirgt die Token-Anzahl vor relays und Beobachtern, der entschlüsselnde Benachrichtigungsserver kann sie aber weiterhin sehen.

Marmot ergänzt Reparatur von Push-Tokens für neue Mitglieder

Marmot hat am 26. Oktober die Reparatur von Push-Tokens für neue Mitglieder gemergt, und eine Folgeänderung präzisierte den endgültigen Wortlaut. Der Urheber des Commits, der einen Beitretenden hinzufügt, sollte aktive kind-448-Token-Snapshots und kind-449-Entfernungs-Tombstones senden. Ein optionales Fingerabdruck-Set in einem kind-447-Announce erlaubt es Peers, nur die fehlenden Datensätze zu senden. Die drei am höchsten eingestuften Leaves antworten mit gestaffelten Timern, begrenzt durch einen 24-Stunden-Ratenschutz pro ankündigendem Leaf. Weitergeleitete signierte Datensätze und aufbewahrte Entfernungs-Tombstones reparieren fehlenden Token-Zustand auch dann, wenn die Besitzer offline sind.

Vorschlag für in Passkeys gehaltene Nostr-Schlüssel

Ein Vorschlag für in Passkeys gehaltene Nostr-Schlüssel baut auf Nosskey auf, einem bestehenden Verfahren zur Nutzung von Passkeys mit Nostr-Schlüsseln. Getaggte Handles trennen eine per PRF/HKDF abgeleitete Identität von einem gespeicherten Schlüssel, und verschlüsselte kind-31778-relay-Datensätze binden Relying Party, Autor und Credential. Fehlende oder unbekannte Metadaten dürfen nicht stillschweigend eine neue Identität erzeugen. Die Origin-Autorisierung der Relying Party gilt weiterhin, und alte Nosskey-Daten benötigen einen ausdrücklichen Migrationsleser. Eine abgeleitete Identität geht mit ihrem Passkey verloren, sofern sie nicht separat gesichert ist.

Vorschlag für DNS-Delegation von NIP-05-Kennungen

Ein nicht gemergter Vorschlag zur DNS-Delegation für DNS-basierte NIP-05-Kennungen ergänzt einen Fallback, der nur greift, wenn die ursprüngliche HTTPS-Abfrage 404 oder 410 liefert. Clients lesen dann einen _nip05-TXT-Eintrag, der auf einen HTTPS-Anbieter verweist. Timeouts, TLS- oder CORS-Fehler, Weiterleitungen und Schlüsselabweichungen lösen den Fallback nie aus, und im DNS werden keine Schlüssel gespeichert. DNSSEC wird empfohlen, ist aber optional, sodass bei unsigniertem DNS das TLS des Anbieters die Autorisierung durch die ursprüngliche Domain nicht unabhängig authentifizieren kann. Ältere Clients können Kennungen, die nur per Delegation existieren, nicht auflösen.

Katalog für Softwareanwendungen als NIP-82 vorgeschlagen

Ein Vorschlag für einen Katalog von Softwareanwendungen verwendet NIP-82 als vorgeschlagene Nummer in diesem offenen, nicht gemergten Pull Request; die Nummer ist weder vergeben noch übernommen. Er führt kinds für Apps (32267), Releases (30063), Assets (3063), Kuratierung (30267), Nachweise der Zertifikatsinhaberschaft (30509) und eine Katalog-relay-Liste (10067) zusammen. Assets geben ihre Plattform und Laufzeitumgebung samt Datei-Hash an. Android-Assets ergänzen einen Hash des Signaturzertifikats. Eine Nachweissignatur zeigt, dass der Herausgeber das Zertifikat kontrolliert, und Leser müssen dennoch Ablauf und Widerruf prüfen.

BIP-321-URIs als NIP-A3-Zahlungsziele vorgeschlagen

Ein nicht gemergter Vorschlag für einen bip321-Zahlungstyp für NIP-A3-Zahlungsziele erlaubt es einem kind-10133-event, eine vollständige bitcoin:-URI als statische, wiederverwendbare Zahlungsanweisung zu tragen. Weil das Ziel wiederverwendet wird, untersagt der Vorschlag einen Betrag und einen einmaligen BOLT11-lightning-Rechnungsparameter. Der Zahlende wählt den Betrag, und die Wallet sucht eine unterstützte Zahlungsmethode aus, wobei der Fallback auf Lightning-Adressen erhalten bleibt.

Vorschlag für über BIP-321-Ziele bezahlte zaps

Ein Vorschlag für über BIP-321-Ziele bezahlte zaps sieht vor, dass der Absender das wiederverwendbare NIP-A3-bip321-Ziel eines Empfängers über Ark (ein Offchain-Bitcoin-Protokoll), Lightning oder onchain bezahlt und dann einen kind-9740-zap veröffentlicht. Der Inhaber des Belegschlüssels bestätigt die Abwicklung mit kind 9741. Beide kind-Nummern sind weiterhin Platzhalter. Die Zahlungsreferenz wird mit NIP-44 versionierter Verschlüsselung für einen Belegschlüssel verschlüsselt, für den sich der Empfänger entscheidet, und nur dieser Schlüssel kann die Zahlung bestätigen. Dritte können Zahlungsdetails nicht überprüfen, die Bestätigung beruht also auf Vertrauen in die Signatur des Empfängers. Der Vorschlag ersetzt NIP-57-Lightning-zaps nicht.

Ark-Zahlungen für Nostr Wallet Connect vorgeschlagen

Ein nicht gemergter Vorschlag für eine Ark-Erweiterung für Nostr Wallet Connect, das NIP-47-Protokoll, mit dem Apps eine entfernte Wallet steuern, ergänzt die bestehende BIP-321-Unterstützung für Zahlen und Empfangen um eine Ark-Anweisung sowie einen Ark-Zahlungsdatensatz für lookup_payment, ohne neue Methoden. Eine Wallet nutzt die Anweisung nur, wenn sie Adressversion und Netzwerk unterstützt und denselben Ark-Server verwendet. Andernfalls versucht sie eine andere URI-Anweisung. Beträge müssen ganze Satoshis ohne Millisatoshi-Rundung sein, und die Datensätze unterscheiden eine vom Server mitsignierte Zahlung von Mitteln, die der Empfänger eingesammelt hat und ausgeben kann.

Ark-Zahlungsheader für Blossom-Server vorgeschlagen

Ein Vorschlag für einen Ark-Zahlungsheader in Blossom, dem Protokoll zum Speichern von Medien-Blobs auf HTTP-Servern, ergänzt X-Ark in BUD-07-Antworten mit HTTP 402 Payment Required. Der Header trägt eine BIP-321-URI mit einer frischen Ark-Adresse pro Anfrage und dem Betrag. Optional enthält die URI dieselbe Zahlung auch als Lightning-Rechnung. Als Nachweis wiederholen Clients die Anfrage nach der Abwicklung mit der bezahlten Ark-Adresse. Clients, die den Fallback genutzt haben, wiederholen sie mit dem Lightning-Preimage. Eine HEAD-Anfrage wird nicht mit Nachweis wiederholt, stattdessen gehen Clients zum GET oder PUT über.

Cashtag-Vorschlag für Asset-Erwähnungen in Notes

Ein Cashtag-Vorschlag definiert eine optionale Tokenisierung von $, gefolgt von zwei bis sechs ASCII-Buchstaben, wobei Code, URLs und Nostr-Referenzen ausgenommen sind. Ein einzelner cashtag-tag legt den Anzeigemodus fest und kann eine vom Autor gewählte Asset-ID anhängen, da ein Tickersymbol allein ein Asset nicht eindeutig identifiziert. Leser prüfen, ob das Symbol zu Chain und Adresse passt, und markieren Abweichungen, ohne sie umzubenennen. Optionale t-tags in der Form $ticker ermöglichen die Standardsuche auf relays.

Gamepad-Spezifikation für Napplets zurückgezogen

Das NAPs-Repository, in dem Napplet-Spezifikationen veröffentlicht werden, hat am 27. Oktober die Entfernung der Gamepad-Spezifikation gemergt. Die Änderung löscht NAP-GAMEPAD.md und macht die frühere Übernahme rückgängig. Derzeit ist kein Gamepad-NAP übernommen.

Cyberspace-Höhen-tags vermeiden Kollisionen mit Gruppen-tags

Cyberspace, ein auf Nostr aufbauendes räumliches Protokoll, hat mehrere seiner eigenen Spezifikationen gemergt, die DECKs genannt werden. Dabei handelt es sich um Projektspezifikationen, nicht um offizielle NIPs. Die Spezifikation benennt den Höhen-tag bei Taschen und Chat von h in H um. Der kleingeschriebene tag kollidierte mit NIP-29-Gruppen-tags und führte dazu, dass events abgelehnt oder falsch einsortiert wurden. Leser greifen nur dann auf ein altes h zurück, wenn H fehlt. Dies ändert nur die Projektspezifikation. Es ändert NIP-29 nicht und belegt nicht, dass ausgerollte Clients interoperieren.

Versteckte Audiodateien in Cyberspace

DECK-0007 definiert versteckte Audiodateien als verschlüsselte Blossom-Datei, auf die ein unsignierter Rumor innerhalb einer signierten Tasche oder Truhe verweist. Dadurch wird die Person, die sie versteckt hat, nicht über einen separat signierten, abspielbaren öffentlichen Beitrag zugeordnet. Jede Platzierung verwendet einen frischen Schlüssel und Chiffretext, doch jeder kann den Schlüssel trotzdem weitergeben. Die Spezifikation behauptet weder, dass die Verschlüsselung die Privatsphäre des Finders garantiert, noch, dass ihre URL-Regeln jede SSRF verhindern, und die Unterstützung in Lesern ist noch in Arbeit.

Öffentliche Modelle und Animation in Cyberspace

Gegenstände können jetzt auf öffentliche SNO-Modelle mit Wipp- und Drehanimationen verweisen und fallen auf die alte Darstellung zurück, wenn ein Modell ungültig oder nicht verfügbar ist. Live-Modelle können sich ändern oder verschwinden, und eine breite Übernahme wird nicht behauptet.

Cyberspace-Spezifikationen für Gegenstände, Chat und Kommentare

Die optionalen DECKs 0004 bis 0006 dokumentieren bestehenden Code für Gegenstände, Truhen, Angebote, verschlüsselten lokalen Chat und versiegelte Kommentare, mit synthetischen Testvektoren. Mehrere Probleme sind noch offen. Die Signaturen von Taschen und Truhen unterscheiden sich, und versiegelte Kommentare legen Eltern-ID und kind über öffentliche tags offen. Inhaber können Angebote überschreiben. Der Chat hat Lücken bei Replay-Schutz und Kontextbindung, und Truhenverweise sind nicht implementiert. Die Dokumentation behebt kein Sicherheitsproblem und ist kein Deployment.

Vorschlag für events mit mehreren Autoren

Ein signierter Langformartikel, Multi-Author Nostr Events as a Soft Fork, schlägt events vor, deren ID-Hash mehrere Autoren-pubkeys umfasst, wobei jeder Autor dieselbe ID signiert. Ältere Clients sähen einen secp256k1-kompatiblen Wrapper, der die Daten in neuer Form sowie Q-tags als Suchhinweise trägt. Peers würden die neue Form pro Verbindung aushandeln. Der Artikel verallgemeinert den früheren Post-Quanten-Vorschlag des Autors, der einen künftigen Schlüssel als weiteren Mitautor hinzufügen würde. Es ist ein nicht nummerierter Vorschlag, kein angenommener NIP. Das Ersetzen gemeinsam verfasster naddr und der binäre Transport bleiben offene Fragen.

Buzz-NIP-AR-Sync-Abonnements senden vor Live-Heads einen vollständigen Snapshot

Ein offener Buzz-Pull-Request schlägt NIP-AR-WebSocket-Sync-Abonnements vor (#8522). Das relay würde einen konsistenten, unter REPEATABLE READ gelesenen Artefaktsatz senden und EOSE erst ausgeben, wenn dieser Satz vollständig ist, und danach die aktuellen Heads live streamen; die Live-Registrierung in Redis erfolgt vor dem ersten Lesen. Ein Redis-Verbindungsabbruch oder -Rückstand beendet das Abonnement mit CLOSED und erfordert einen Resync, ebenso Zugriffsänderungen, Schwärzungen oder eine volle Warteschlange. Abonnements sind auf 4.096 Artefakte begrenzt, und die Änderung war zu unserem Quellen-Stichtag nicht gemergt und nicht in Produktion verfügbar.

Inkrementelles Lesen von Buzz-NIP-AR-Artefakten über HTTP

Ein separater offener Buzz-Pull-Request ergänzt inkrementelles Lesen von NIP-AR-Artefakten über HTTP (#8523). Clients blättern anhand der Änderungszeitstempel der Datenbank und stabiler IDs mit einer Überlappung von 120 Sekunden und erhalten entweder die aktuelle Revision oder eine Entfernung. Bekannte IDs können sie wiederherstellen. Die Ergebnisse folgen einem Modell der Eventual Consistency. Der Vorschlag verspricht keinen vollständigen Snapshot, und das Fehlen eines Artefakts bedeutet weder Löschung noch Zugriffsverlust. Die neueste Revision verlangt für nicht gelistete offene Kanäle eine Mitgliedschaft oder einen ausdrücklichen #h-Scope, und eine Änderung der Listung setzt den inkrementellen Fortschritt zurück. Das Feature-Gate BUZZ_ARTIFACT_INCREMENTAL_ENABLED ist ausgeschaltet und setzt voraus, dass alle Writer und Migrationen (jetzt 0074 bis 0076) vorhanden sind. Diese Verzögerung von 120 Sekunden ist eine Betriebsannahme. Zu unserem Quellen-Stichtag war die Änderung weiterhin offen.

Entwurfstext für NIP-AM zu delegierten Metrik-Lesern

Ein Entwurf eines Pull Requests zur Buzz-Dokumentation spezifiziert delegierte Leser für NIP-AM-Metriken, ohne die Autorisierung zur Laufzeit zu ändern (#8582). Das für den Eigentümer verschlüsselte Event vom kind 44200 bleibt unverändert, und der Agent gibt für jeden aktiven Grant eine separate NIP-44-Kopie aus, die an die exakte Event-ID des vom Eigentümer verfassten Grant-Events gebunden ist. Der vorgeschlagene Grant-kind 30180 und die Obergrenzen für Leser bleiben offene Fragen, ebenso wie Verlauf, Widerruf und öffentliche Verknüpfbarkeit. Ein signierter Widerruf kann Kopien, die ein Empfänger bereits besitzt, nicht löschen, und der Entwurf war zum Stichtag unserer Quellen nicht gemergt.

DECK-0003 erlaubt einem Parent, die von ihm platzierten Objekte mitzuführen

Ein offener Cyberspace-Pull-Request schlägt DECK-0003 §1.10 vor, eine Root-Tabelle mit eingebetteten SNO-Objekt-Payloads (#81). Ein vorhandener Eintrag in der Kopie des Parents hat Vorrang, ohne dass ein Abruf über das Netzwerk erfolgt, selbst wenn er ungültig ist. Jeder Eintrag ist auf den pubkey des Autors beschränkt, mit begrenzter Größe und Tiefe sowie Grenzen für Zyklen. Ältere Leseprogramme rufen fehlende Objekte ab und zeigen einen Platzhalter an. Der Vorschlag beschreibt Implementierungen, die bis zu dieser Änderung zurückgehalten werden; sie war zum Stichtag unserer Quellen nicht gemergt.

DECK-0004 definiert höhengebundene Türen mit abgeleiteten Raumschlüsseln

Ein offener Cyberspace-Pull-Request ergänzt DECK-0004 um §3.6 und §3.7 zu Looks und Türen (#82). Türen sind an eine Höhe gebunden, und der Raumschlüssel ist SHA-256(Domänenseparator ‖ Ortsschlüssel ‖ Türgeheimnis), wobei der Bag des Raums mit diesem Schlüssel verschlüsselt wird. Räume können mehrere oder verschachtelte Türen haben, und das Setzen eines neuen Schlosses rotiert den Schlüssel. Der Text enthält keine Testvektoren, solange keine erste Implementierung existiert, und er war zum Stichtag unserer Quellen nicht gemergt.

nostream-Erweiterung für Peering-Angebote in NIP-11

Ein offener nostream-Pull-Request würde das NIP-11-Dokument des Relays um einen Peering-Abschnitt erweitern (#999). Er gibt Feed-kinds mit zeitlichen Grenzen und Abrechnungsbedingungen bekannt, dazu einen Kontakt-Endpunkt und Proof-of-Work für das Peering. Nur enabled: false deaktiviert den Abschnitt, und leere Bedingungen bedeuten Peering ohne Abrechnung. Ein bekannt gegebenes Angebot ist kein akzeptierter Peer. Die Änderung implementiert weder eine Peer-Vereinbarung noch eine kostenpflichtige Föderation. Sie war zum Stichtag unserer Quellen nicht gemergt.

NIP-CD ergänzt optionale Listen installierter Befehle

Eine Folgeänderung zu NIP-CD wurde am 27. Oktober in den Default-Branch der NIPs gemergt (Merge), und die Spezifikation trägt nun den Titel Slash Commands. Sie definiert eine optionale Liste vom kind 10992 nach NIP-51, in der ein Nutzer Adress-Tags führt, die auf Befehlsdefinitionen vom kind 31992 verweisen, jeweils identifiziert durch den pubkey des Executors und den d-Wert, mit optionalem Relay-Hinweis. Nutzer können die Liste pflegen, und Clients sollten sie für die Autovervollständigung und gerenderte Chips verwenden. Die Liste ist eine Präferenz für Anzeige und Auffindbarkeit. Sie autorisiert keine Executors, und der Aufruf als Klartext funktioniert auch ohne sie, ohne befehlsspezifische Tags und ohne erforderliche Client-Unterstützung. NIP-CD bleibt ein optionaler Entwurf, und der Merge zeigt nicht, welche Clients die Liste übernommen haben.

Marmot präzisiert seine Fairnessregel für die Vorbereitung bei Account-Geräten

Marmot hat am 28. Oktober eine Korrektur gemergt, die seine Scheduling-Regel für Gruppen betrifft, die Account-Geräte voraussetzen. Nachdem ein begrenzter Konvergenzdurchlauf Stable erreicht hat, erhält ein eingereihter, von einem Admin autorisierter Intent oder ein zulässiger Intent desselben Accounts einen Vorbereitungsversuch, bevor eingereihte eingehende Arbeit allein einen weiteren Durchlauf erzwingen kann. SelfUpdate und Leave fallen nicht unter diese zusätzliche Fairnessgarantie, obwohl jedes Mitglied sie weiterhin committen darf. Die Änderung korrigiert eine frühere Formulierung, die jeden autorisierten Intent umfasste, und Gruppen, die keine Account-Geräte voraussetzen, behalten ihr bisheriges Scheduling. Es gibt keine Änderung am Wire-Format, und ein Vorbereitungsversuch garantiert keinen gültigen, akzeptierten oder kanonischen Commit.

Marmot schlägt ein verborgenes Geräteverzeichnis für Account-Gruppen vor

Ein offener, nicht gemergter Marmot-Vorschlag würde eine Komponente device-roster-v1 hinzufügen, mit der ID 0x800e, für eine verborgene Gruppe, deren Leaves alle zu einem einzigen Account gehören. Eine Gruppe führt das Roster ab ihrer Erstellung oder nie. Das Roster verzeichnet Geräte, abgelehnte Slots, abgelehnte KeyPackages und Leaf-Maps, und es ist die erste Komponente, die explizite, reihenfolgeunabhängige Diff-Updates verwendet, die auf den Kandidaten-Parent angewendet werden. Entfernte Slots können Leaf-Maps für Gruppen behalten, aus denen ihre Geschwister sie nicht entfernen können. Ein Gerät vertraut einer Gerätegruppe nur, wenn es diese Gruppe erstellt hat oder über ein Welcome beigetreten ist, das durch einen bestätigten Link authentifiziert wurde; der Marker 0x800e allein verleiht also kein Vertrauen. Das gründende Add benennt das exakte KeyPackage aus dem bestätigten Link. Ein gestohlenes verknüpftes Gerät kann das Roster bearbeiten, bis es entfernt wird. Die Geräteobergrenze gilt für Geräte. Leaf-Map- und Ablehnungseinträge haben Größenlimits pro Eintrag, aber keine Obergrenze für die Anzahl der Einträge. Roster-Daten werden nie in andere Accounts kopiert, und die Gruppe bleibt in Chats, Zählern, Benachrichtigungen und Zielen verborgen. Laut dem Text des Vorschlags hält MDK die Roster-Bytes hinter einem Testschalter, ohne neue reguläre UI.

Marmot schlägt klarere Rückmeldungen bei fehlgeschlagener Aktivierung von Account-Geräten vor

Ein weiterer offener, nicht gemergter Marmot-Vorschlag würde es Clients ermöglichen, Aktivierungsfehler zu erklären, die Account-Geräte betreffen. Ein Client darf melden, dass eine Gruppe keine Account-Geräte aktivieren kann. Diese Rückmeldung auf Gruppenebene darf die Mitglieder oder Geräte, die die Aktivierung blockieren, nicht nennen. Ein Mitglied, das kein aktiver Admin ist, erfährt nur, dass ihm der Admin-Status fehlt. Wenn eine Branch-Auswahl verloren geht oder eine neu generierte Aktivierungsprüfung fehlschlägt, muss der Nutzer eine neue Anfrage stellen. Der Client wiederholt die Aktivierung nie automatisch. Die bestehende Regel, dass die Aktivierung eine neue Nutzeranfrage von einem autorisierten Client erfordert, bleibt unverändert. Es handelt sich um normativen Entwurfstext, der kein implementiertes oder ausgerolltes Verhalten belegt.

Marmot schlägt Emoji-Verifizierung für das Koppeln neuer Geräte vor

Ein offener, nicht gemergter Marmot-Vorschlag beschreibt das Koppeln eines neuen Geräts über einen Austausch nach dem Vorbild von Matrix m.sas.v1, der X25519, HKDF und HMAC verwendet. Der Nutzer vergleicht sieben beschriftete Emoji auf beiden Bildschirmen und muss keinen Code ablesen oder eintippen. Der Besitz des Account-Schlüssels authentifiziert niemals ein Gerät. Fünf unsignierte Rumors (Request, Answer, Reveal, Confirm und Cancel) werden an den Account-pubkey gewrappt und binden den Account, die Sitzung, die neue KeyPackageRef, den bestehenden Geräte-Slot und frische Schlüssel. Das bestehende Gerät bestätigt zuerst und fügt genau die bestätigte KeyPackageRef hinzu. Das neue Gerät bestätigt erst nach der Verifizierung und akzeptiert ein Welcome nur für die Gruppen-ID, die durch den bestätigten Austausch authentifiziert wurde. Vorgeschlagen werden die kinds 452 bis 456, wobei 457 bis 489 reserviert sind. Ein Inhaber des Account-Schlüssels kann weiterhin ein Cancel fälschen, um einen Denial of Service herbeizuführen, selbst nach der Bestätigung. Das stündliche Answer-Limit bleibt über Neustarts hinweg nicht erhalten. Relays können den Wrap-Burst und die Account-Adresse sehen; einige Merge- und Welcome-Fälle bleiben zurückgestellt. Implementierungen lassen diese Formate standardmäßig deaktiviert, und zwei vom Autor bereitgestellte Known-Answer-Vektoren sind kein unabhängiges Sicherheits- oder Interoperabilitätsaudit.

NIP-5D-Napplet-Vorschlag verschärft Medien- und Quellfelder

Der offene NIP-5D-Napplet-Vorschlag wurde bereits zuvor beschrieben. Seine Änderungen vom 28. Oktober wurden nun in den Branch des Vorschlags gemergt, nicht in den Default-Branch der NIPs, und überarbeiten optionale Medien- und Quellfelder, die am 17. Oktober eingeführt wurden. Screenshot- und Preview-Tags verwenden nun die Schlüssel-Wert-Felder aus NIP-92 wieder, mit einem erforderlichen SHA-256-Wert x in Kleinbuchstaben und den optionalen Feldern m, dim, size, alt und duration. Lesende Clients müssen den Hash prüfen und das tatsächliche Format dekodieren, bevor sie rendern. Ist ein gültiges m-Feld vorhanden, muss das dekodierte Format zudem mit diesem MIME-Typ übereinstimmen. Einträge mit fehlendem, wiederholtem oder fehlerhaftem x werden ignoriert, fehlerhafte optionale Felder werden verworfen, ohne andere verwendbare Medien zu verwerfen, und mehrere Previews werden ignoriert. Ein source-commit muss sich zu einer exakten, vollständigen Git-ID auflösen lassen, und HTTPS-Quellarchive erfordern eine exakte Übereinstimmung des SHA-256 auf Byte-Ebene. Doppelte oder fehlerhafte Quellfelder werden ignoriert, und unbrauchbare Quelldaten dürfen die HTML-Wiedergabe nicht blockieren. Ein passender Commit oder ein passendes Archiv beweist keinen reproduzierbaren Build, und es wird keine Client-Konformität behauptet.

Sechs Jahre Nostr-Oktober

Über sechs Oktober hinweg haben sich die datierten Änderungen an Nostr vom Framing der Nachrichten nach außen hin zu den darauf aufbauenden Anwendungen bewegt. 2021 legte die Basisspezifikation fest, dass Client-Nachrichten als JSON-Arrays auf oberster Ebene gerahmt werden. Die folgenden Oktober brachten Client-Suche und Lightning-Rechnungen, Zeitstempelnachweise und Job-Anfragen, Medienvarianten und Ecash-Wallets, dann Code-Zusammenarbeit und Metadaten privater Nachrichten. Andere Änderungen in denselben Monaten machten Identitäten und Verbindungen leichter zwischen Programmen übertragbar, vom sichtbaren Relay-Status bis zu getrennten Signer-Schlüsseln und der Kopplung von Wallets. In diesem Oktober definierte dasselbe Dokument, worauf eine leere Filterliste passt, sodass Relays, die identisches JSON lesen, nun eine gemeinsame Regel dafür haben, welche Events es auswählt.

Oktober 2021: Den Transport eindeutig machen

Am 4. Oktober wurde NIP-01, die grundlegende Protokollspezifikation, so überarbeitet, dass Client-Nachrichten JSON-Arrays auf oberster Ebene sind. Die informellen Präfixe EVENT, REQ und CLOSE wurden zum ersten Element jedes Arrays, und die feste Pfadvorgabe /ws entfiel, sodass jeder WebSocket-Endpunkt genügte. Das präzisierte eine Spezifikation, hinter der bereits Code stand. Unabhängig voneinander geschriebene Clients brauchen ein exaktes Framing, bevor irgendetwas Anspruchsvolleres interoperieren kann.

Am 23. Oktober erhielt die Richtung vom Relay zum Client explizite EVENT- und NOTICE-Nachrichten. Ein EVENT vom Relay trägt die Kennung einer bestehenden REQ-Subscription, sodass ein Client, der mehrere Subscriptions über eine Verbindung betreibt, Ergebnisse den Anfragen zuordnen kann, und NOTICE trägt menschenlesbaren Text. Ein so kleines Vokabular lässt sich praktikabel mehr als einmal implementieren, was zu separat betriebenen Relays passt.

Der Text von NIP-01 vom 23. Oktober zeigt auch, was eine Signatur abdeckt. Die ID eines Events ist ein Digest eines kompakten UTF-8-JSON-Arrays, das eine führende Null, den öffentlichen Schlüssel des Autors, den Zeitstempel, den kind, die Tags und den Inhalt enthält, und der Autor signiert diesen Digest mit einer Schnorr-Signatur auf der Kurve secp256k1. Der WebSocket-Umschlag und die Subscription-Kennung liegen außerhalb dieser signierten Daten. Aus diesem Text folgt, dass dasselbe signierte Event über verschiedene Subscriptions oder über verschiedene Verbindungen ankommen kann, ohne erneut signiert zu werden. Ein REQ liefert zunächst passende gespeicherte Events und bleibt dann aktiv, bis der Client CLOSE sendet, den Socket schließt oder die Subscription-ID für ein neues REQ wiederverwendet. Jede Bedingung innerhalb eines Filters muss erfüllt sein, während mehrere Filter in einem REQ auf Events passen, die irgendeinen von ihnen erfüllen. Die Filternamen in dieser Version unterscheiden sich von den heutigen. Das Verhalten von NOTICE blieb unspezifiziert, und nichts garantierte, wie lange Relays Events aufbewahren oder dass eine Abfrage alle zurückgibt. Fünf Jahre später sollte sich dieselbe Spezifikation erneut der Frage zuwenden, was Filter innerhalb von REQ bedeuten.

Oktober 2022: Ein Feed wird auf dem Smartphone nutzbar

Am 8. Oktober ergänzte Damus, ein Nostr-Client für iOS, eine Suche nach Hashtags, Profilen und Events. Die Änderung betraf die Ansicht der Suchergebnisse und das Thread-Modell und ermöglichte es Lesenden, zusätzlich zum Scrollen durch eingehenden Text direkt zu einer signierten Identität oder einem bestimmten Event zu springen. Diese Suche funktionierte innerhalb der clienteigenen Navigation und war keine relayseitige Volltextsuche.

Acht Tage später ersetzte Damus die schlichten Zeilen in seiner Relay-Konfiguration durch eine Ansicht, die den Zustand jeder Verbindung zeigt. Ein farbiger Punkt liest den Relay-Pool des Clients aus. Grün bedeutet verbunden und Gelb bedeutet verbindend oder erneut verbindend, Rot steht für alles andere und Grau für die Zeit vor der ersten Abfrage. Die Ansicht aktualisiert sich beim Erscheinen und danach alle zwei Sekunden. Wischen zum Löschen, das es bereits gab, wanderte in die neue Ansicht. Mit sichtbaren Punkten musste ein stockender Feed nicht mehr als Schweigen eines Autors gedeutet werden, denn Lesende konnten sehen, welche von mehreren unabhängigen Verbindungen aktiv war und welche es erneut versuchte. Ein grüner Punkt zeigt einen offenen Socket. Er zeigt nicht, dass ein Relay ein Event akzeptiert oder behalten hat. Er zeigt auch nicht, dass eine Abfrage alles zurückgegeben hat, was das Relay vorhält. Der Commit dokumentiert die Implementierung im gemergten Quellcode. Diese Quellcodeänderung belegt kein Veröffentlichungsdatum im App Store.

Am 19. Oktober ergänzte Damus einen Parser für BOLT11-Lightning-Rechnungen sowie Rechnungs-Widgets in Beiträgen, Chats und Direktnachrichten. Das Widget zeigt die Rechnungsbeschreibung und den Betrag in Satoshis, und seine Schaltfläche Pay übergibt die lightning:-URI über iOS an einen installierten Handler. Der soziale Client präsentiert den signierten Beitrag, und eine separate Wallet bezahlt. Diese Widgets sind älter als die spätere Konvention für zap-Receipts, es handelt sich also um Rechnungsanzeigen, nicht um standardisierte zaps.

Oktober 2023: Events tragen Nachweise und Arbeitsaufträge

Am 11. Oktober wurden die OpenTimestamps-Attestierungen von NIP-03, die Nachweise über Events in Bitcoin verankern, von einem ots-Feld im Event in ein separates Event vom kind 1040 verlagert. Dieses Event benennt das Original mit einem e-Tag und trägt in seinem Inhalt die vollständige base64-kodierte OpenTimestamps-Datei mit mindestens einer Bitcoin-Attestierung. Die referenzierte Event-id ist selbst der Digest, den der Nachweis bestätigt, sodass ein Prüfer erfährt, dass das Event zum bestätigten Zeitpunkt existierte. Dieser Zeitpunkt stammt aus Bitcoin, nicht aus dem created_at des Autors. Der Nachweis datiert das Event und trifft keine Aussage über seinen Inhalt.

Am 12. Oktober erhielt die Schlüsselableitung nach NIP-06, unabhängig von der Zeitstempeländerung, zwei Testvektoren. Eine Mnemonic ist eine Wortfolge, die einen Wiederherstellungs-Seed kodiert, und die Vektoren decken eine Mnemonic mit 12 Wörtern und eine mit 24 Wörtern ab, jeweils mit den erwarteten privaten und öffentlichen Schlüsseln in Hexadezimaldarstellung sowie in nsec- und npub-Kodierung. NIP-06 nutzte bereits BIP-39, um die Mnemonic in einen binären Seed umzuwandeln, und den BIP-32-Pfad m/44'/1237'/<account>'/0/0, um einen Schlüssel abzuleiten, mit Account null als grundlegender Wahl für einen einzelnen Schlüssel. Die Ergänzung im Oktober lieferte bekannte Antworten, keine Mnemonic-Wiederherstellung und keinen neuen Ableitungsalgorithmus. Ein Client kann nun prüfen, ob seine Ableitung und seine Kodierungen die dokumentierte Identität reproduzieren. Die Übereinstimmung mit den Vektoren macht Implementierungen vergleichbar. Sie zertifiziert keine bestimmte Implementierung und beweist nicht, dass jeder Import in Wallets und Clients übereinstimmt. Der Schutz eines Seeds vor Diebstahl ist eine separate Frage, die die Vektoren nicht behandeln.

Am 29. Oktober wurde NIP-90, der Standard für Data Vending Machines, mit festen Job-kinds in das NIPs-Repository gemergt. Er reservierte die kinds 5000 bis 5999 für Job-Anfragen und legte den kind jedes Ergebnisses auf den kind der Anfrage plus 1000 fest. Feedback verwendete kind 7000. Eine Anfrage kann auf Text, URLs oder frühere Jobs verweisen. Sie kann auch die erwartete Ausgabe benennen und ein optionales Gebot anbieten. Die Aufgabe liegt daher in signierten Events, die jeder Anbieter beantworten kann, außerhalb der API eines einzelnen Anbieters. Ein früherer Entwurf hatte die kinds 68001 und 68002 verwendet.

Oktober 2024: Medienalternativen und portables Ecash

Am 15. Oktober übernahmen die Video-Events von NIP-71 imeta-Tags für Videovarianten. In den damals aktuellen adressierbaren kinds 34235 und 34236 standen URL, Abmessungen, MIME-Typ, Vorschaubild und Fallbacks jeder Variante gemeinsam in einem Tag. Ein Client, der eine Auflösung auswählt, muss wissen, welches Vorschaubild und welcher Fallback dazugehören, und abgeflachte Metadaten konnten das nicht ausdrücken. Diese kind-Nummern sind historisch: Das aktuelle NIP-71 verwendet die kinds 21 und 22.

Zehn Tage später wurden die Cashu-Wallets von NIP-60 und die nutzaps von NIP-61, beide in früheren Entwürfen eingeführt, gemeinsam als Spezifikationen gemergt. Sie bauen auf Cashu auf, einem Ecash-Protokoll, dessen Token von Mints ausgegeben werden. NIP-60 speichert verschlüsselte Wallet-Proofs auf Relays, sodass kompatible Anwendungen denselben Wallet-Zustand erreichen können. Nach NIP-61 listet ein Event vom kind 10019 des Empfängers vertrauenswürdige Mints, Relays und einen Sperrschlüssel auf, und ein Event vom kind 9321 des Absenders trägt an diesen Schlüssel gesperrte Proofs, die der Empfänger einlösen kann. Nutzer bleiben von den Mints abhängig, die die Token ausgeben, und Anwendungen müssen verhindern, dass dieselben Proofs doppelt eingelöst werden.

Am 29. Oktober wurde das Remote Signing nach NIP-46, bei dem ein separater Dienst den Schlüssel hält, der im Namen eines Nutzers signiert, so überarbeitet, dass ein bunker://-Verbindungsstring den öffentlichen Schlüssel des Remote-Signers trägt. Die Identität des Nutzers wird separat ermittelt: Der überarbeitete Text verlangt von Clients, die beiden Schlüssel auseinanderzuhalten und nach dem Verbinden get_public_key aufzurufen. Der Client erzeugt für die Unterhaltung ein eigenes Schlüsselpaar und adressiert seine verschlüsselten Anfragen an den Schlüssel des Signers, während sign_event ein mit dem Schlüssel des Nutzers signiertes Event zurückgibt. Diese beiden Schlüssel können übereinstimmen, müssen es aber nicht. Der Schlüssel im Verbindungsstring identifiziert nur den Signer-Dienst. Der Account des Nutzers ist der öffentliche Schlüssel, den get_public_key zurückgibt. NIP-60 hatte sich vier Tage zuvor mit gemeinsam genutztem Wallet-Zustand befasst; diese Überarbeitung betrifft ein separates Anliegen, die Identität des Signers. Die Beispiele in diesem Commit verwenden noch den verschlüsselten Transport, den NIP-46 damals spezifizierte, und die Änderung macht einen Remote-Signer weder vertrauenslos, noch beweist sie, wer den Schlüssel des Nutzers hält.

Oktober 2025: Updates für die Zusammenarbeit und Metadaten privater Nachrichten

Am 8. Oktober erhielt NIP-47 Nostr Wallet Connect Deep Links zum Koppeln einer App mit einer Wallet. Eine Wallet kann nostrnwc://connect oder ein app-spezifisches nostrnwc+{app_name}://connect registrieren, und eine anfragende App öffnet diesen Link mit ihrem URI-kodierten Icon, ihrem Namen und einem Callback-Schema. Sobald die Wallet die Verbindung erstellt hat, öffnet sie den Callback mit einem Parameter value, der den Kopplungscode enthält, eine nostr+walletconnect://-URI. Drei Jahre nachdem Damus Rechnungen über iOS an eine Wallet übergeben hatte, musste das Koppeln auf einem einzigen Smartphone nicht mehr bedeuten, einen QR-Code zu scannen, der auf demselben Bildschirm angezeigt wird, oder eine lange Zeichenkette zwischen Apps zu kopieren. Die Ergänzung deckt nur diese Übergabe ab. Sie ändert keine Zahlungsmethoden und bezahlt selbst nichts. Beide Apps müssen die Handler implementieren, und der Spezifikationstext ist kein Beleg dafür, dass jede Wallet dies tut. Ebenso wenig klärt er Ausgabebudgets, Einwilligungsbildschirme oder welche App ein Callback-Schema sicher für sich beanspruchen darf.

Am 16. Oktober erhielt die Git-Zusammenarbeit nach NIP-34 Pull-Request-Events vom kind 1618 und Update-Events vom kind 1619 neben ihren bestehenden Patch-Events. Ein Pull Request benennt einen Commit-Tip und Clone-Orte, und ein Update verschiebt diesen Tip. Patches werden unter 60 kB empfohlen, Pull Requests für größere Einreichungen. Damit verlagerte sich der empfohlene Weg für größere Einreichungen von Patch-Inhalten innerhalb von Events hin zu signierten Verweisen auf Commits, während kleinere Änderungen weiterhin als Patches übertragen werden können. Nostr transportiert die Koordination und die signierten Verweise, und Git-Server liefern weiterhin die Commit-Objekte, auf die diese Verweise zeigen.

Am 27. Oktober erhielt Gift Wrap nach NIP-59 die Empfehlung, die Zeitstempel von Seal und Gift Wrap unabhängig voneinander zu randomisieren, wenn Expiration-Tags hinzugefügt werden. Gift Wrap umschließt eine Nachricht mit diesen beiden Schichten, und wenn jede Schicht ihren eigenen zufälligen Zeitstempel erhält, verringert das, wie eng sich das Timing der Schichten korrelieren lässt. Hier verlagerte sich die Aufmerksamkeit von der Verschlüsselung von Inhalten hin zur Begrenzung dessen, was eine Korrelation von Metadaten offenlegen kann. Verschlüsselung verbirgt die Nachricht selbst, aber Timing und andere Metadaten rund um den Umschlag bleiben beobachtbar, und Implementierungsentscheidungen bestimmen, wie leicht sie sich verknüpfen lassen. Die Empfehlung fügt keine neue Verschlüsselung hinzu und macht die Beteiligten nicht anonym.

Oktober 2026: Gemeinsame Bedeutungen von Abfragen und durch Text ausgelöste Dienste

Am 5. Oktober erweiterten die Medienanhänge von NIP-92 imeta-Tags auf Profile vom kind 0, sodass ein Profil seine Felder picture und banner mit Fallback-URLs, einem Blurhash (einer kompakten Kodierung einer unscharfen Vorschau), Abmessungen, Alt-Text und weiteren Anhangsmetadaten beschreiben kann. NIP-92 existierte bereits vor dieser Änderung; neu ist, dass die gruppierten Metadaten, die NIP-71 2024 auf Videovarianten anwandte, nun auch Profilbilder erreichen. Die Zuordnung ist exakt. Ein Tag gilt nur, wenn seine URL der Bild- oder Banner-URL entspricht, Clients SOLLTEN Tags ignorieren, die auf keine von beiden passen, und sie SOLLTEN Fallbacks versuchen, wenn die primäre URL fehlschlägt. Da ein neues Event vom kind 0 das frühere Profil ersetzt, SOLLTE ein Herausgeber die Metadaten für ein unverändertes Bild übernehmen und Tags für nicht mehr verwendete Bilder entfernen, damit veralteter Alt-Text oder veraltete Abmessungen nicht stillschweigend ein anderes Bild beschreiben. Diese Aktualisierungsregel ist ebenso wichtig wie die neuen Felder. Ein imeta-Tag garantiert nicht, dass ein Bild verfügbar bleibt oder schneller lädt. Es bietet auch keinen Schutz der Privatsphäre, und Clients müssen nicht jedes Feld rendern.

Am 17. Oktober wurde NIP-01 dahingehend präzisiert, dass eine leere Liste in einem Filter auf keine Events passt, was sich vom Weglassen des Attributs unterscheidet. Eine Folgeänderung entfernte die widersprüchliche Formulierung „one or more“ und empfahl Clients, keine Listen zu senden, die auf nichts passen können. Im Oktober 2021 einigte sich dieses Dokument auf das JSON-Framing der REQ-Nachricht: Die REQ-Nachricht ist ein Array, und jeder Filter ist ein JSON-Objekt darin. In diesem Oktober legte es die Semantik der Filter fest, indem es bestimmte, was eine leere Liste innerhalb eines solchen Filters bedeutet, denn Relays, die denselben Frame identisch parsen, konnten trotzdem unterschiedliche Ergebnisse liefern.

Am 21. Oktober wechselte NIP-CD, damals mit dem Titel Commands, vom Vorschlag zur gemergten Entwurfsspezifikation; es beschreibt Slash-Befehle. Events vom kind 31992 definieren Befehle, und ein Aufruf ist Klartext, der am ersten Zeichen des Inhalts eines Events beginnt, sodass Clients keine besondere Unterstützung benötigen, um ihn zu senden. Ein Folgevorschlag mit einem früheren Commit auf einem separaten Branch wurde am 27. Oktober gemergt. Er benannte die Spezifikation in Slash Commands um und ergänzte optionale Listen installierter Befehle vom kind 10992, die Clients für Autovervollständigung und Darstellung verwenden sollten. Die Listen halten eine Nutzerpräferenz fest und autorisieren weder Executors, noch schränken sie den Aufruf als Klartext ein. NIP-90-Jobs verwenden strukturierte Anfrage- und Ergebnis-Events, während ein Befehl als gewöhnlicher Text lesbar bleibt.