Nostr Compass #42

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

Unsere eigens entwickelte Nostr Compass Android-App vereint Newsletter, Podcast-Episoden, Themenleitfäden und Sprachnotizen von Mitwirkenden an einem Ort. Ihre neuesten signierten Versionshinweise beschreiben vollständige Newsletter mit überprüften Signaturen, gespeicherte Ausgaben und 110 offline verfügbare Themenleitfäden sowie eine lokale Suche in Beiträgen und verfügbaren Transkripten. Mitwirkende können Sprachnotizen aufnehmen und damit antworten, eine gespeicherte Aufnahme vor dem Senden prüfen und über Amber signieren, ohne ihren privaten Schlüssel in der App zu speichern. Öffentliche Aufnahmen werden auf Nostr und Blossom veröffentlicht.

Das neueste App-Update bewahrt Aufnahmen in der Warteschlange und Upload-Fortschrittsmarkierungen, wenn Android die Hintergrundarbeit beendet, zeigt an, wenn eine Freigabe durch Amber erforderlich ist, und öffnet die betreffende Aufnahme über eine Benachrichtigung. Getrennte Ansichten für Episoden und Sprachnotizen behalten jeweils ihre eigene Scrollposition, während die Wiedergabe an derselben Stelle fortgesetzt wird. Benachrichtigungen über neue Aufnahmen hängen von der Aufgabenplanung und den Berechtigungen unter Android ab.

Diese Woche: White Noise ergänzt verschlüsselte Gruppenumfragen und Hinweise auf unvollständige Chatverläufe; Holoboard ergänzt Befehle zur Hervorhebung per Privatnachricht und eine Android-App; fips-pub-domains testet signierte öffentliche Namen in einem Mesh; Marmot MDK macht fehlende Verläufe verschlüsselter Gruppen sichtbar; und Myco gibt dem Teilen von Apps mit Geräten in der Nähe eine Nostr-Identität und einen Store. nostream passt die Zulassung zum relay an die Auslastung an, während Nostr double ratchet eine Lücke bei entfernten Mitgliedern schließt. Die Entwicklungsarbeit behebt Probleme bei der Interoperabilität verschlüsselter Gruppen in Amethyst, ergänzt Divines verschlüsselte Videonachrichten und bringt Nostr Atlas online. Protokollaktualisierungen verfeinern Identitätsnachweise, relay-Einladungen, Follow-Sets und vorgeschlagene Domain-Ansprüche. Der September-Rückblick zum Monatsende verfolgt dieselben Fragen durch sechs Jahre Nostr.

Wichtigste Meldungen

Holoboard ergänzt Nostr-Befehle zur Hervorhebung und eine Android-App

Holoboard ist eine Übersicht zum Finden von Nostr-Notizen anhand einer Rangliste, in der Beiträge durch Lightning-Zahlungen nach oben gebracht werden können. Die ursprünglichen Beiträge bleiben Nostr-events; Holoboard stellt seine Ranglisten- und Darstellungsdaten über eine eigene HTTP API bereit. Diese Unterscheidung ist wichtig, wenn Leser erwarten, dass die Sortierung der Übersicht ein relay-nativer Feed ist.

Sein Änderungsprotokoll vom 23. September verzeichnet Befehle zur Hervorhebung per Direktnachricht sowohl über verschlüsselte NIP-17- als auch über ältere NIP-04-Wege. NIP-17 verpackt private Nachrichten, um ihren Inhalt und Absender vor relays zu verbergen, während NIP-04 das ältere Verschlüsselungsformat für Direktnachrichten ist. Nutzer können im selben Gespräch eine Rechnung für die Hervorhebung anfordern, ein gekennzeichnetes Angebot für die erste bezahlte Hervorhebung erhalten und sich durch eine Antwort mit YES für Erinnerungen vor Ablauf anmelden. Der Sender der Hervorhebung versucht fehlgeschlagene relays erneut, während das Update vom 24. September eine Android-App ergänzt und den Rechnungsablauf vereinfacht.

Die Hinweise zur relay-Integration des Projekts beschreiben gewöhnliche Notizen und Kommentare auf Nostr, die Weiterleitung an verschlüsselte Posteingänge sowie den Umgang mit Zitaten und Löschungen. Sein signierter Android-Eintrag in Zapstore belegt die Existenz einer App-Veröffentlichung, doch der Schlüssel des Eintrags wurde nicht als öffentliche Board-Identität von Holoboard bestätigt. Dies ist die erste Berichterstattung über das Projekt in Compass.

fips-pub-domains testet signierte öffentliche Namen für ein Mesh

fips-pub-domains ist ein neues Resolver- und Namensgebungsexperiment, das öffentliche Domainnamen an Knoten in FIPS bindet, einem verschlüsselten Mesh, das Nostr-Nachrichten zur Peer-Erkennung verwendet. Seine erste Veröffentlichung kombiniert diese Ansprüche mit DNS-TXT-Einträgen, optionaler DNSSEC-Validierung, lokal fest hinterlegten Bindungen, einem Linux-Resolver-Daemon und einer Android-Integration mit fips2go, dem FIPS-Client für Telefone. Ein signierter Anspruch allein belegt nicht den Besitz einer öffentlichen Domain; Clients benötigen DNS- oder DNSSEC-Nachweise, einen konfigurierten Zeugen oder eine zuvor als vertrauenswürdig eingestufte feste Bindung.

Die Veröffentlichung 0.2.0 ergänzt Ansprüche um DNSSEC-Nachweise, sodass ein Client mit Zugriff nur auf ein Mesh-relay einen nicht fest hinterlegten Namen validieren kann, und ermöglicht mehreren validierten Servern, eine Domain zu bedienen. Außerdem behebt sie Probleme mit veralteten festen Bindungen und dem DNS-Failover. Version 0.2.1 korrigiert eine systemd-Unit, die andernfalls nicht startete, und führt den Server ohne root aus; bestehende Installationen müssen diese Unit ersetzen, um die Korrektur zu erhalten.

Unter Android folgt eine übernommene fips2go-Änderung verifizierten Bindungen öffentlicher Namen in seinem DNS-Proxy. Eine zweite übernommene Änderung leitet Verbindungen zu konfigurierten Nostr-relays über das Mesh, sodass der Resolver einen zuvor unbekannten Domain-Anspruch abrufen und überprüfen kann, während das Telefon keine Internetverbindung hat. Die Ergebnisse auf den Geräten werden von den Maintainern in diesen Pull Requests berichtet; sie belegen keine breitere Nutzung.

Die Tests des Projekts mit zwei Knoten und einem ausschließlich über das Mesh erreichbaren relay sind von den Maintainern berichtete Nachweise für eine frühe Implementierung, nicht für einen Einsatz im Produktivbetrieb. Sein NIP-DB-Vorschlag ist weiterhin offen, und die event-kinds in seinem Entwurf bleiben bis zur Registrierung Platzhalter. Der fips2go-Beitrag der vergangenen Woche behandelte den Mesh-Verbindungsaufbau und die Peer-Erkennung; die Arbeit dieser Woche befasst sich mit öffentlichen Namen und ihrer Überprüfung.

Marmot MDK 0.11.0 macht Lücken im Kontoverlauf sichtbar

Marmot MDK, die Rust-Laufzeitumgebung und die generierten Bindings für MLS-verschlüsselte Nostr-Gruppennachrichten, folgt auf die Veröffentlichung der vergangenen Woche zum dauerhaft abgesicherten Versand mit Version 0.11.0. Die Kontowiederherstellung erklärt eine Lücke im Verlauf nun erst dann für vollständig geschlossen, wenn jedes erforderliche relay einen ungekürzten event-Vergleich abgeschlossen hat; eine nicht nachweislich geschlossene Lücke erzeugt einen dauerhaft gespeicherten Hinweis, den eine Host-Anwendung dem Nutzer anzeigen kann. Eine volle Zustellwarteschlange lagert in die Kontodatenbank aus, statt events zu verwerfen, und die laufende Zustellung setzt den Transport-Cursor weiter, damit ein Neustart nicht denselben Verlauf erneut abruft.

Die vollständigen Versionshinweise beschreiben außerdem optionale verschlüsselte Gruppenumfragen, zustandslose event-Verifizierung in den Bindings und auf 16-KB-Speicherseiten ausgerichtete Android-Bibliotheken. Anwendungen müssen die generierten Bindings und nativen Bibliotheken aus diesem zusammengehörigen Quellstand gemeinsam aktualisieren; Kontodatenbanken werden beim ersten Öffnen über Schema 98 migriert, und ein Downgrade der Datenbank wird nicht unterstützt. Ein bestehender sporadischer Fehler beim Nachholen kann weiterhin dazu führen, dass Nachrichten, die mehr als fünf Gruppenepochen zurückliegen, ohne entsprechenden Hinweis nicht entschlüsselt werden können. Diese Veröffentlichung beansprucht daher nicht, den Verlauf in jedem Fall vollständig wiederherzustellen.

Myco 0.8.0–0.8.1 gibt Apps in der Nähe einen eigenen Nostr-Store

Myco ist eine Android-App zum Austausch kleiner Nostr-Programme, sogenannter napplets, mit Telefonen in der Nähe, auch wenn diese offline sind. Version 0.8.0 gibt jeder Installation eine Nostr-Gastidentität und ermöglicht die Anmeldung mit einem vorhandenen Schlüssel oder Amber, einem Android-Signer, der Signaturen freigibt, ohne den Kontoschlüssel weiterzugeben. Außerdem ersetzt sie den Discover-Tab durch einen App-Store, der selbst ein napplet ist. Dieser Store liest signierte App-Einträge und Empfehlungen, während ein heruntergeladenes Update ohne Internetverbindung zwischen Telefonen im Circle eines Nutzers weitergegeben werden kann.

Version 0.8.1 macht diese Einträge leichter auffindbar, indem sie die relays abfragt, die ein Autor bekannt gibt; frühere Builds verließen sich auf öffentliche Standard-relays. Sie zeigt zwischengespeicherte Profile und Apps sofort an, speichert langsamere relay-Antworten für spätere Besuche, vergrößert bei fehlschlagenden relays die Abstände zwischen erneuten Versuchen und hält Abonnements aktiv, solange eine Ansicht geöffnet ist. Beide Updates bewahren das bestehende Übertragungsformat zwischen Telefonen. Aktualisierte Telefone können napplet-Updates herunterladen und teilen; ältere Telefone leiten lediglich deren Ankündigungen weiter.

Veröffentlichungen mit Versions-tag

White Noise Android ergänzt Gruppenumfragen und kontospezifische Standardeinstellungen für verschwindende Nachrichten

White Noise Android ist ein Nostr-Messenger für private, mit Marmot verschlüsselte Unterhaltungen. Nach den Verbesserungen bei Zustellung und Teilen, über die wir letzte Woche berichtet haben, ergänzt die Veröffentlichung vom 30. September über das Marmot Development Kit Gruppenumfragen mit auswählbaren Antworten, Ergebnisbalken und Fristen. Sie ergänzt außerdem gerätespezifische Standardeinstellungen für verschwindende Nachrichten pro Konto: Neue direkte Unterhaltungen und Gruppen übernehmen die gewählte Dauer, während bestehende Unterhaltungen und ihre individuellen Einstellungen ihre aktuelle Regelung beibehalten. Hallo winken sendet eine Begrüßung, die ein neu hinzugefügtes Mitglied erwähnt, ohne den aktuellen Entwurf zu verändern.

Die Veröffentlichung lässt Nutzer den Bildausschnitt für Profil- und Gruppenbilder wählen und einen Chatordner löschen, ohne dessen Unterhaltungen zu löschen. Ihre Verlaufshinweise zeigen an, wenn der Konto- oder Gruppenverlauf nach einer Wiederherstellung möglicherweise unvollständig ist, und lassen sich jeweils separat ausblenden. Das seitenweise Laden von Unterhaltungen vermeidet es, beim Sprung zu den neuesten Nachrichten den angezeigten Verlauf neu aufzubauen, und Bearbeitungen ausstehender Nachrichten behalten ihren Text bei, während der ursprüngliche Sendevorgang seine bestätigte event-ID erhält. Diese Übergabe der Bearbeitung deckt Wechsel zwischen Unterhaltungen innerhalb der laufenden App ab; sie gewährleistet keine dauerhafte Speicherung über das Beenden des Prozesses hinaus.

Beim Diktieren lässt sich jetzt für jede Aufnahme Einfügen oder Senden wählen, wobei das automatische Abschließen das Transkript in den Entwurf einfügt. Die Einrichtung von Offline-Anbietern erläutert die Verarbeitung auf dem Gerät, hält die dafür erforderliche Zustimmung von der für andere Sprachanbieter getrennt und setzt unterbrochene Medien nach Ende der Aufnahme fort. Die Verarbeitung allgemeiner Dateien akzeptiert größenbegrenzte, nicht leere Dokumente mit korrekten Dateinamen, MIME-Metadaten und Fehlermeldungen; ausdrückliche Downloads von Anhängen verwenden Androids vom Nutzer initiierte Übertragungsaufträge mit einer Vordergrund-Ausweichlösung. Die Bedienelemente zum Einfügen verwenden jetzt Androids Systemaktion, damit GrapheneOS Secure Paste Zugriff auf die Zwischenablage gewähren kann. Android stellt von iOS geteilte GIPHY-Inhalte außerdem als animierte Medien dar und berücksichtigt dabei die Downloadrichtlinie.

Benachrichtigungskorrekturen aktualisieren die Spitznamen der Absender und räumen Benachrichtigungen auf, wenn eine Unterhaltung geöffnet wird. Die Änderungen zur Wiederherstellung von Benachrichtigungen erhalten ausstehende Push-Aufgaben, wenn die Zuständigkeit im Vordergrund nicht verfügbar ist, und verwenden eine begrenzte Zahl von Wiederholungsversuchen. Das Signieren mit Amber koordiniert gehäufte Freigaben für dasselbe Konto, damit Ratenbegrenzungen keine Sendevorgänge abbrechen. Die neue Audit-Konfiguration verlangt vor dem Hochladen an den neuen Empfänger eine erneute Entscheidung zur Weitergabe von Protokollen. Der Quellcode wird außerdem auf die Lizenz AGPL-3.0-only umgestellt.

nostream 3.1.0 passt den Proof of Work des relay an die Last an

nostream ist ein Nostr-relay in TypeScript mit PostgreSQL als Datenbank. Version 3.1.0 kann den Proof-of-Work-Schwellenwert für events innerhalb vom Betreiber festgelegter Grenzen erhöhen oder senken, wenn sich die beobachtete event-Rate ändert. Die Einstellung ist standardmäßig deaktiviert, verwendet die gemessene Rate jedes Workers und lässt den bestehenden statischen Schwellenwert für öffentliche Schlüssel unabhängig davon bestehen. Betreiber müssen sie daher ausdrücklich aktivieren, bevor für Absender eine andere Zulassungsanforderung gilt.

Dieselbe Veröffentlichung ergänzt ein Admin-Dashboard für relay-, WebSocket- und event-Metriken, Ergebnisse von Netzwerkzustandsprüfungen und konfigurierbare Betreiberbenachrichtigungen. Ihre Admin-API ist standardmäßig deaktiviert. Diese Bedienelemente helfen Betreibern, relay-Last und Erreichbarkeitsprobleme zu unterscheiden, während die neue Richtlinie weiterhin ausdrücklich konfiguriert werden muss.

Nach seiner Veröffentlichung mit lastabhängigem Proof of Work hat nostream Aktionen für Meldungen vertrauenswürdiger Moderatoren integriert. NIP-56 definiert events zur Meldung von Inhalten; die neue Option nip56.hideActionableReports schließt gemeldete events aus REQ- und COUNT-Ergebnissen aus, wenn auch das Melden aktiviert ist. Eine Meldung zu einem event blendet dieses event aus, während eine Meldung zu einem öffentlichen Schlüssel jedes event dieses Autors ausblendet. Die neue Option ist standardmäßig auf false gesetzt, sodass das alleinige Aktivieren der Erfassung von Meldungen die bestehenden Abfrageergebnisse beibehält.

Nostr double ratchet 0.0.171–0.0.172 schließt eine Lücke bei entfernten Mitgliedern

Nostr double ratchet ist eine TypeScript-Bibliothek für verschlüsselte private Chats, die über Nostr übertragen werden. Version 0.0.171 rotiert nach Änderungen an der Mitgliedschaft den Absenderschlüssel einer Gruppe, sodass eine entfernte Person mit den alten Schlüsseln spätere Nachrichten eines aktualisierten Absenders nicht entschlüsseln kann, auch nachdem dieser Absender neu gestartet wurde. Sie verweigert außerdem Sendevorgänge oder Schlüsselrotationen durch einen entfernten lokalen Eigentümer und bricht einen Sendevorgang ab, wenn sich die Mitgliedschaft während der Schlüsselverteilung ändert.

Version 0.0.172 übermittelt die bestehende, vom Konto signierte Gerätefreigabe in einer optionalen verschlüsselten Einladungsantwort. Ein Empfänger, der die Aktualisierung verwendet, kann das Gerät des Absenders verifizieren, bevor ein separates Registrierungs-event eintrifft, während verknüpfte Geräte ihre Freigabe über Neustarts hinweg behalten. Das Einladungsfeld ist optional und lässt den ursprünglichen Handshake und das Ratchet-Nachrichtenformat unverändert.

Die Versionen 0.0.173–0.0.175 erweitern diese Arbeiten zum Entfernen von Mitgliedern um dauerhaft gespeicherte Gruppenschlüsselübergaben und einen vor der Veröffentlichung gespeicherten Zustellungszustand der Warteschlange, sodass unterbrochene Übergaben nach einem Neustart wieder aufgenommen werden. Veröffentlichungs-Callbacks enthalten lokalen Gruppenkontext, mit dem Anwendungen nach einer Entfernung dauerhaft gespeicherte Wiederholungsversuche abbrechen können, während Steuernachrichten zur Mitgliedschaft weiterhin zustellbar bleiben; Sendevorgänge in der Warteschlange behalten ihre ursprünglichen inneren event-IDs. Doppelte Einladungsantworten erhalten bestehende Sitzungen, Abonnements bleiben bei Änderungen an Kontakten stabil, und App-Schlüssel-Snapshots behalten Gerätenamen bei, ohne veränderbare Kopien gemeinsam zu nutzen. Das signierte Übertragungsformat bleibt unverändert; die Hinweise zu 0.0.173 berichten außerdem über Rust 0.0.168 mit einer Ausweichlösung für Empfangssitzungen und der Filterung lokaler Gruppenechos.

Scramble 0.7.4–0.7.5 ruft die Nachrichten ab, die ein neues Gruppenmitglied sehen sollte

Scramble ist ein plattformübergreifender Marmot-Gruppenmessenger mit einer nativen Android-Oberfläche. In Version 0.7.5 erhält jede Gruppe ihren eigenen Zeitgrenzwert für den relay-Verlauf: Zuvor wurde der Grenzwert der aktivsten Unterhaltung auf jede Gruppe angewendet, sodass eine neu beigetretene Gruppe leer bleiben konnte, weil ihre Nachrichten seit dem Beitritt nie angefordert wurden. Der Ablauf beim erneuten Verbinden erhält dieselbe Korrektur, und eine Gruppe ohne lokale Aktivität fordert jetzt alle verfügbaren Nachrichten an; MLS verhindert weiterhin, dass ein neues Mitglied vor seinem Beitritt gesendete Nachrichten entschlüsseln kann.

Die vorherige Veröffentlichung 0.7.4 behebt die wiederholte Annahme von Einladungen, die dadurch entstand, dass sich bei wiederverwendeten Android-Zeilen Klick-Handler ansammelten, und sorgt dafür, dass eine benutzerdefinierte Einstellung für den Blossom-Medienserver in der nativen App dauerhaft gespeichert wird. Version 0.7.5 liefert nur die native Android-APK aus, sodass Nutzer, die dem älteren Avalonia-Dateinamen folgen, ihr Aktualisierungsziel ändern müssen. Konten und Verlauf lassen sich zwischen diesen beiden Android-Builds übertragen, aber Gruppen, die mit der älteren MLS-Engine 0.6.x erstellt wurden, werden nicht auf 0.7.x migriert.

Scramble 0.7.6 ergänzt ein manuelles Bedienelement “Fehlende Nachrichten abrufen”, das jede von einer Gruppe verwendete Routing-Adresse abfragt, die zeitliche Beschränkung aufhebt, eine veraltete gespeicherte Adresse repariert und meldet, was wiederhergestellt wurde. Es kann weiterhin keine Epochen aus der Zeit vor dem Beitritt des Nutzers entschlüsseln. Administratoren in der nativen App können andere Mitglieder hoch- oder herunterstufen, wobei der aktuelle Mitgliederstatus und Fehlschläge sichtbar sind; Unterhaltungen zwischen zwei Personen blenden diese Bedienelemente weiterhin aus. Die Aktion “Kopieren” in den Gruppeninformationen reagiert jetzt, allerdings kann sie bei Unterhaltungen, zu denen eine Einladung vorliegt, weiterhin eine interne Chatkennung statt der Gruppen-ID des Protokolls kopieren. Version 0.7.7 arbeitet außerdem zurückgehaltene Nachrichten ab, wenn der Commit eines anderen Mitglieds eintrifft; 0.7.8 ergänzt einen Regressionstest für diesen Ablauf bei passiven Mitgliedern.

Amber 6.6.6 korrigiert Verbindungsgeheimnisse für Remote-Signer

Amber ist ein Android-Signer, der Signaturen für Nostr-events genehmigt, ohne einer Anwendung ihren Kontoschlüssel zu überlassen. Nach der Änderung an der Backup-Verschlüsselung in der vergangenen Woche korrigiert Version 6.6.6 den nostrconnect-Parser: Ein Verbindungsparameter mit =, etwa ein Geheimnis mit Padding, war verändert worden, bevor Amber antwortete. Dadurch schlug bei NDK-basierten Clients die Prüfung des Geheimnisses fehl, selbst wenn die Verbindung zum Signer ansonsten gültig erschien.

Die Veröffentlichung sendet außerdem Feedback-Issues an die relays, die Ambers Repository-Ankündigung angibt, und greift auf das bisherige relay zurück, wenn sich die Ankündigung nicht abrufen lässt. Längere Tor-Zeitlimits geben langsamen relays mehr Zeit, diese Veröffentlichung zu bestätigen. Die übrigen Änderungen verbessern die Sichtbarkeit von Symbolen und Text in Ambers Themes.

FIPS 0.5.2 behebt ein Datenschutzleck bei der Nostr-Peer-Erkennung

FIPS ist ein verschlüsseltes Mesh-Netzwerk, das Nostr-Identitäten und relay-Nachrichten zur Erkennung von Peers nutzt. Die Wartungsversion 0.5.2 signiert Löschanfragen für NAT-Traversal nicht mehr mit dem Routing-Schlüssel des Knotens, wodurch dieser Schlüssel zuvor mit Traversal-Verkehr auf relays verknüpft worden war. Sie aktualisiert außerdem die für relay-Verbindungen verwendete TLS-Bibliothek auf eine Version, die eine in einem veröffentlichten Sicherheitshinweis beschriebene Schwachstelle behebt, und korrigiert mehrere Fälle verlorener Nachrichten bei der Erneuerung von Verbindungs- und Sitzungsschlüsseln.

Die Versionshinweise fordern Betreiber auf allen Plattformen zum Upgrade auf und erläutern zugleich separate Korrekturen für Windows-Schlüsseldateiberechtigungen, Gateways und Paketdienste. Ephemere Knoten schreiben keine private fips.key mehr, die ein späterer Neustart überschreiben könnte; Betreiber, die eine stabile Identität beabsichtigen, sollten vor dem Upgrade den persistenten Modus einstellen. Die Veröffentlichung ändert das Übertragungsformat des Mesh-Netzwerks nicht, sodass Knoten mit unterschiedlichen Versionen einzeln aktualisiert werden können.

napplet soyLI 0.23.1–0.23.4 korrigiert Backend-Veröffentlichung und Signer-Genehmigung

soyLI von napplet.soy ist das Erstellungs- und Veröffentlichungswerkzeug für kleine Nostr-Programme in Sandbox-Umgebungen. Nach der Veröffentlichung für gemeinsam genutzte Kreationen in der vergangenen Woche bezieht Version 0.23.1 Backend-Manifeste, Handler und Schemas in die Erstellerprüfungen und Mehrspieler-Vorschauen ein. Sie hält portable Anbieterkonfigurationen im Projektmanifest fest, während private Identitätsbindungen und Entwicklungsdatenbanken außerhalb des veröffentlichten Quellcode-Snapshots bleiben.

Version 0.23.2 ermöglicht Projekten, die früher einen generierten öffentlichen Backend-Kontext eingecheckt haben, nach strenger Validierung wieder die Veröffentlichung, weist aber weiterhin private Bindungen, Journale, Datenbanken und Zugangsdaten in der erreichbaren Historie zurück. Die spätere Veröffentlichung 0.23.4 behebt einen Sitzungsfehler bei persistenten Backends, der eine gültige Genehmigung durch eine Erweiterung oder einen Remote-Signer ablehnen konnte, wenn eine Person mehrere Sekunden zum Signieren benötigte. Öffentliche Hosts benötigen auch die Korrektur für gemeinsam genutzte Hosts; allein die Aktualisierung der CLI eines Erstellers hat einen bereitgestellten Host nicht repariert.

Dart NDK 0.10.0 begrenzt Blossom-Authentifizierung und Remote-Signierung

Dart NDK ist eine Flutter- und Dart-Bibliothek für den Zugriff auf Nostr-relay, das Signieren, Wallet-Anfragen und Medienoperationen. Nach der Vorabversion der vergangenen Woche ändert 0.10.0-dev.7 Blossom-Medienanfragen so, dass sie anonym bleiben, bis ein Server sie ablehnt, und autorisiert sie anschließend über eine explizite Richtlinie, die festlegt, welche Identität eine Operation offenlegen darf. Diese Autorisierung wird durch den gesamten Anfragepfad weitergegeben und ersetzt die älteren Optionen useAuth und customSigner, eine inkompatible Integrationsänderung für Apps, die die API der Vorabversion verwenden.

Dev.9 hält eine Remote-Signer-Antwort nicht mehr zurück, bis das langsamste relay sie bestätigt. Dev.8 reduziert relay-Abfragen und Cache-Arbeit im Hintergrund; die übrigen Korrekturen betreffen die dauerhafte Speicherung von Wallet-Seeds und Abwicklungsfristen. Die stabile Veröffentlichung 0.10.0 bündelt diese Entwicklungsreihe nun mit den unten beschriebenen Änderungen an Verbindungsmetadaten und privaten Abonnement-IDs. Der Vergleich mit dev.9 enthält diese integrierten Änderungen. Anwendungen sollten beim Upgrade sowohl die Änderung an der Medienauthentifizierungs-API als auch den Antwortpfad des Remote-Signers prüfen.

Die stabile Veröffentlichung enthält NIP-46-Verbindungsmetadaten und angeforderte Berechtigungen und ersetzt separate Verbindungsfelder durch einen Nip46ClientMetadata-Wert. Dies ist eine Änderung an der Quellcode-API, mit der Login-Widgets die Anwendungsidentität und angeforderte Berechtigungen an den Bunker übergeben können. Eine weitere Änderung an Anfrage-IDs verwendet im Produktivbetrieb 32 zufällige hexadezimale Zeichen und hält damit Anwendungsfallnamen und Paginierungsphasen aus den für relay sichtbaren Abonnement-IDs heraus. Explizite IDs bleiben auf das 64-Zeichen-Limit von NIP-01 beschränkt, während der Debug-Modus einen kurzen Diagnosenamen beibehält.

Mostro Core 0.16.0 entfernt den alten Gift-Wrap-Transport

Mostro Core stellt das Nachrichtenprotokoll bereit, das Mostros Nostr-basierte Peer-to-Peer-Handelsclients und der Koordinator verwenden. Version 0.16.0 entfernt den Gift-Wrap-Transport der Protokollversion v1 sowie die alten Wrap- und Unwrap-Funktionen, sodass der neuere Transport als Bibliothekspfad verbleibt. Das ist eine inkompatible Änderung für Anwendungen, die über diese Bibliothek weiterhin v1-Nachrichten erstellen oder lesen.

Die Bibliotheksveröffentlichung geht der inzwischen veröffentlichten Version 0.19.0 des Koordinators voraus. Betreiber, die ältere Clients bedienen, müssen beide Seiten der Transportmigration aktualisieren. Der vorherige tag 0.15.1 ergänzt einen Streitfallstatus für kooperative Stornierungen, doch die Entfernung des Transports ist der entscheidende Kompatibilitätsmeilenstein.

Cambium 0.6.0–0.7.1 registriert ein Telefon zum Entsperren über relay-Nachrichten

Cambium ist eine Android-Begleitapp zum Signieren mit einem Heartwood-Hardwareschlüssel, die die Platine nach einem Neustart auch entsperren kann. Version 0.6.0 ermöglicht es, ein Telefon ohne USB-Kabel über die Nostr-relay der Platine zum Entsperren zu registrieren; der Nutzer vergleicht fünf Anfragewörter auf dem Telefon, der Platine und Sapwood, der Registrierungsoberfläche der Platine, bevor er die Taste auf der Platine drückt. Neu angekündigte relay erhalten eine zufällige Verbindungsverzögerung, damit der erste Kontakt des Telefons nicht genau verrät, wann es die Aktualisierung der Platine gesehen hat.

Version 0.7.0 kehrt den Einladungsablauf um: Ein Telefon scannt Sapwoods kurzlebigen QR-Code und sendet ein einzelnes verschlüsseltes, einmaliges event von einem Wegwerfschlüssel zurück. Ein erneuter Versuch veröffentlicht dasselbe event erneut, wenn kein relay es annimmt, während der alte Ablauf mit Codeanzeige für ältere Sapwood-Builds erhalten bleibt. Der Patch 0.7.1 hält den abschließenden Prüfcode sichtbar und verbessert die Reproduzierbarkeit von F-Droid-Builds; der QR-Ablauf erfordert weiterhin die angegebenen neueren Sapwood- und Heartwood-Versionen.

Bray 3.5.0–3.5.2 begrenzt vom Agenten angestoßene Ausgaben aus Nostr-Wallets

Bray ist ein Nostr-Toolserver, über den ein KI-Assistent relay-, Identitäts- und Wallet-Aktionen über eine Schnittstelle mit begrenztem Geltungsbereich anfordern kann. Die Veröffentlichung 3.5.0 ergänzt eine Obergrenze für jede Nostr-Wallet-Connect-Zahlung und ein dauerhaft gespeichertes Tagesbudget, mit menschlicher Bestätigung, sofern der Assistenten-Host dies unterstützt. Die Bereitstellung separater Verbindungen für Ausgaben erfordert nun eine explizite Wallet-Diensteinstellung, prüft jede Berechtigung vor der Nutzung erneut und beschränkt Rechnungsabfragen auf Hashes innerhalb dieser Berechtigung.

Die Veröffentlichung weist Nutzer außerdem an, eine Wallet-Verbindungs-URI in einer privaten Datei aufzubewahren, statt sie in den Chat einzufügen, und verweigert es, eine Zahlung mit ungewissem Ausgang erneut zu versuchen, als wäre ihr Fehlschlag erwiesen. Version 3.5.2 gleicht Zahlungswege auf dem Marktplatz lokal ab, nachdem relay den angeforderten Zahlungsmethodenfilter abgelehnt hatten. Diese Prüfungen begrenzen, was ein beauftragter Assistent ausgeben kann, und verhindern, dass eine Annahme über relay-Filter passende Angebote verbirgt.

Mafrend 1.3.0-alpha stellt private Kartengruppen auf die aktuelle Marmot-Spezifikation um

Mafrend ist eine kartenbasierte soziale Nostr-App, mit der Menschen Orte erkunden und sich über Reiseziele unterhalten können. Die Veröffentlichung 1.3.0-alpha aktualisiert private Gruppen auf eine neuere Spezifikation für verschlüsselte Marmot-Gruppen und ergänzt Profilansichten aus Chats und Bewertungen. Das Gruppenformat ist mit älteren Alpha-Chats inkompatibel; Nutzer sollten dies als Alpha-Migration mit einem Kompatibilitätsbruch behandeln.

Dieselbe Veröffentlichung ergänzt das Teilen von Screenshots und Chat-Änderungen neben Verbesserungen an Karten und Markierungen. Profilfunktionen sind vom Projekt weiterhin als in Arbeit gekennzeichnet. Die wesentliche Nostr-Änderung ist die Umstellung der Interoperabilität privater Gruppen; Nutzer mit älteren Testgruppen sollten vor dem Upgrade den Kompatibilitätshinweis prüfen.

Sonar alpha.15–alpha.15.1 behebt Fehler beim Veröffentlichen in verschlüsselten Gruppen

Sonar ist ein privater Messenger, der Unterhaltungen über ein Bluetooth-Mesh und Nostr übertragen kann. Alpha.15 ergänzt Emoji-Reaktionen auf Nachrichten und das private Teilen der lokalen Uhrzeit innerhalb verschlüsselter Chats, mit einer Einstellung, um diese Freigabe zu widerrufen. Die Wallet wechselt zu Cashu, doch diese Änderung bei Zahlungen ist vom Nachrichten-Update getrennt.

Alpha.15.1 behebt einen Startfehler, durch den der Unterhaltungsindex leer bleiben konnte, nachdem ein Build eines älteren Entwicklungszweigs eine fremde Schemaversion geschrieben hatte. Ohne den Index verschlüsselte und veröffentlichte die App die geteilten lokalen Uhrzeiten bei jedem erneuten Öffnen erneut in allen Gruppen und versandte dabei manchmal Hunderte von events, bevor die Ratenbegrenzungen der relay griffen. Der Hotfix baut diesen lokalen Zustand neu auf und beendet die wiederholten Veröffentlichungen in Gruppen.

Elisym führt mit seinen Commerce-Paketen private Nostr-Bestellungen ein

Elisym ist ein Nostr-basiertes Agenten-Toolkit, das derzeit einen Handelsablauf mit signierten events entwickelt. Sein bereits zusammengeführtes commerce-Paket definiert Shopprodukte, die Autorisierung durch den Eigentümer, privat gekapselte Bestellungen und Belege sowie die Angebotsprüfung für die Checkout- und Händlerkomponenten. Ein späterer tag für commerce 0.2.0 leitet die Zahlungsreferenz einer Bestellung aus dieser Bestellung ab und verknüpft so die Zahlungssuche mit dem signierten Kaufablauf.

Die Paketserie führt außerdem separate Arbeiten an payment-core und am Browser-Checkout ein, doch ihre Release-tags belegen nicht, dass ein vollständiger Händler-Checkout bereitgestellt ist. Der event kind für die Shopautorisierung ist in der Primärquelle des Projekts ausdrücklich vorläufig. Die elf tags für SDK, MCP, CLI und payment-core kennzeichnen eine einzelne Handelsfunktion in Entwicklung.

Elisyms neue Paketveröffentlichungen stellen den selbst gehosteten Händlerknoten als Paket bereit, während MCP 0.31.0 buy_product und get_order für Commerce-Produkte ergänzt. Nachfolgende Veröffentlichungen von commerce und merchant-node ergänzen die Unterstützung für Tempo-Zahlungen innerhalb desselben Checkouts. Diese Pakete entwickeln die bestehende Integration signierter Produkte und privater Bestellungen weiter; die tag-Liste macht das vorläufige event-Schema weder zu einem Standard noch belegt sie den vollständigen Start eines gehosteten Dienstes.

Flotilla 1.11.2 behebt Blockaden bei Signierdiensten und unvollständige relay-Feeds

Flotilla ist ein Nostr-Client für Unterhaltungen, Räume und gemeinsam genutzte Bereiche. Version 1.11.2 bietet Nutzern einen Ausweg, wenn der Start beim Warten auf einen entfernten Signierdienst hängen bleibt, und meldet eine Sitzung ab, deren lokale Anwendungsdaten gelöscht wurden. Ein Raum kann seine Nachrichten jetzt anzeigen, bevor die Synchronisierung des übergeordneten Bereichs abgeschlossen ist, und Feeds lassen Beiträge nicht mehr allein deshalb aus, weil ein relay später als ein anderes geantwortet hat.

Dieselbe Veröffentlichung stellt außerdem einen F-Droid-Build bereit, der mit dem bestehenden Schlüssel der App signiert ist, und hält die GitHub-Veröffentlichungen für Obtainium aktuell. Diese Arbeit an der Verteilung ist für Nutzer wichtig, die den Aktualisierungskanal wechseln, doch die Korrekturen bei relay und Signierdiensten sind der unmittelbare Grund für ein Upgrade.

Ditto 2.42.3 zeigt die Zustellung an relay und stärkt die Kontotrennung

Ditto ist ein sozialer Nostr-Client, mit dem Nutzer ihre relay auswählen und sich bei ihnen authentifizieren können. In Version 2.42.3 zeigen die event-Details eines Beitrags, auf welchen relay des Nutzers und des Autors er gespeichert ist; die Broadcast-Funktion richtet sich nur an diejenigen, auf denen er fehlt. Die Veröffentlichung weist außerdem auf nicht reagierende Lese-relay hin und bietet eine Möglichkeit für einen erneuten Versuch, sodass sich ein fehlender Beitrag leichter diagnostizieren lässt, ohne ihn erneut überallhin zu senden.

Laut den Versionshinweisen werden beim Kontowechsel keine Beiträge mehr an die relays des vorherigen Kontos gesendet, stummgeschaltete Nutzer können keine allgemeinen Telefonbenachrichtigungen auslösen, und Links oder Bilder in Beiträgen können keine Geräte im lokalen Netzwerk des Lesers erreichen. Beiträge von langsamen relays verschwinden nicht mehr aus den Feeds “Gefolgt” und “Geliebt”, während Livestream-Chats und webxdc-Spiele aktualisiert werden, ohne wiederholt die gesamte Ansicht herunterzuladen. Das Durchsuchen von Torrents und Audioinhalten ist ebenfalls neu, doch das relay-Routing und die Kontotrennung sind die Änderungen mit den weitreichendsten Auswirkungen auf Nostr.

Iris Chat 2026.9.24.4 bringt Anrufe in verschlüsselte Unterhaltungen

Iris Chat ist ein Ende-zu-Ende-verschlüsselter Nostr-Messenger, der die Double-Ratchet-Familie von Chatprotokollen verwendet. Seine Veröffentlichung vom 24. September ergänzt Sprach- und Videoanrufe mit kompatiblen Kontakten, auch über eine bestehende lokale Verbindung, wenn das Internet nicht verfügbar ist. Nutzer können die Videoqualität reduzieren, einen Videoanruf als Sprachanruf annehmen und einen eingehenden Anruf über die Anrufoberfläche von Android bedienen; durch Annehmen oder Ablehnen hören auch die anderen verknüpften Geräte auf zu klingeln.

Die Veröffentlichung ermöglicht außerdem die Anmeldung über eine separate Signier-App und zeigt, welche verknüpften Geräte verbunden sind. Spätere Patches vom 24. September behalten die ursprünglichen Zeitstempel verzögerter Nachrichten bei und verbessern die Zustellung im Nahbereich nach dem Verlust eines Pakets zum Wiederverbinden. Diese geräteübergreifenden Funktionen und Anruffunktionen befinden sich noch in einem frühen Stadium, daher ist das Update vor allem für Kontakte nützlich, die kompatible Iris-Builds verwenden können.

Das spätere, vom Entwickler signierte Update vom 30. September bewahrt den lokalen Gruppenverlauf eines entfernten Mitglieds, deaktiviert aber das Senden, verbessert die Zustellung zwischen verknüpften Geräten und in großen Gruppen und behebt Fehler bei Lesebestätigungen und der Anzahl ungelesener Nachrichten. Für Anrufe kommen die Auswahl des Audiogeräts und wiederhergestellte Rufzeichen bei ausgehenden Anrufen hinzu; ein veralteter Mikrofonstatus unterdrückt eingehendes Audio nicht mehr. Zeitlich begrenztes Stummschalten, das Kopieren von Bildern, per Drag-and-drop angehängte Dateien, das Benachrichtigungsrouting und die Push-Registrierung erhalten Korrekturen, während das Abmelden lokale Caches leert und das Entfernen eines Geräts dessen Sitzung beendet. Ein zweites Update verbessert den Zugriff auf Dateien, die von anderen Iris-Apps auf demselben Gerät zwischengespeichert wurden, und hält die lokale Dateifreigabe auch bei deaktiviertem Nearby verfügbar.

LibreNostr 0.6.0–0.7.0 leitet relay-Verbindungen durch integriertes Tor

LibreNostr ist ein Android-Nostr-Client mit konfigurierbaren relay- und Datenschutzeinstellungen. Version 0.6.0 bündelt eine Arti-basierte Tor-Engine auf ARM64 und wendet den gewählten Modus “Direkt”, “Tor für alles” oder “Nur .onion” auf relay-WebSockets, HTTP-Anfragen, Medien, Uploads und Webseiten an. Der strikte Tor-Modus blockiert Verbindungen, wenn Tor nicht verfügbar ist, und sendet niemals unbemerkt eine Anfrage direkt; beim Moduswechsel werden relay-Sockets über die neue Route neu verbunden.

Version 0.6.2 ergänzt einen auf dem Gerät arbeitenden Web-of-Trust-Filter, der aus öffentlichen Follow-Listen aufgebaut wird, und wählt zusätzliche relay danach aus, welche weiteren gefolgten Personen sie erreichen. Version 0.7.0 zeigt anschließend Notizen und Benachrichtigungen an, bevor Profil- und Zählerabfragen abgeschlossen sind, begrenzt langsame relay-Abfragen und entschlüsselt nicht mehr bei jedem Öffnen einer Unterhaltung den gesamten DM-Posteingang. Zusammen verändern diese Veröffentlichungen sowohl, wohin sich der Client verbinden darf, als auch, wie lange ein langsames relay seine Oberfläche aufhalten kann.

Die vom Entwickler signierte erste stabile Veröffentlichung, 1.0.0, ergänzt gespeicherte, profilspezifische Tablet-Decks mit verschiebbaren Spalten für Feeds, Hashtags, Profile, Langtexte, Benachrichtigungen und Nachrichten. Tablets im Querformat erhalten dieses Layout; Smartphones behalten ihre bestehende Oberfläche. Die Suche erhält OR, Ausschlüsse, Medienfilter und funktionierende Datumsbereiche, liefert zwischengespeicherte Profile vor Verfeinerungen durch relay zurück und fährt nach abgelehnten Volltextanfragen sofort fort. Hashtags werden chronologisch sortiert, das seitenweise Laden wartet auf ausreichend relay-Antworten, und ungenutzte Feeds geben ihre Abonnements frei.

Dieselbe Veröffentlichung bewahrt bei Bearbeitungen bestehende öffentliche und verschlüsselte Einträge in Stummschaltlisten und Lesezeichen, anstatt sie durch eine einzelne Änderung zu ersetzen. Sie trennt Lesezeichen und Benachrichtigungen zwischen Konten und beschränkt zusätzliche Autoren-relay auf öffentliche Lesezugriffe, sodass private Anfragen und die relay-Authentifizierung von ihnen ferngehalten werden. Sie verhindert außerdem, dass veraltete Profilantworten neuere Metadaten ersetzen, behebt Fehler beim seitenweisen Laden von Benachrichtigungen und bei Benachrichtigungszählern, behält ältere Feed-Einträge beim Eintreffen neuer Einträge bei und korrigiert Countdowns zum Rückgängigmachen von Antworten, doppelte Veröffentlichungen, Medien-URLs mit Abfragezeichenfolgen sowie die Anzahl ungelesener Nachrichten nach dem Markieren eines Chats als gelesen. Version 1.0.1 behebt einen Startabsturz der Tablet-Decks im neuen Layout.

Newlay 0.3.45 streamt große relay-Abfragen, statt sie zu schließen

Newlay ist ein auf Android gehostetes Nostr-relay mit zugehörigen lokalen Diensten. Seine signierte Release-Ankündigung für 0.3.45 besagt, dass große Abfrageergebnisse jetzt mit Backpressure gestreamt werden, statt die Verbindung des Clients zu schließen. Der eingebettete Git-Host entfernt nach Pushes abgelöste Packs, während sein Cordn-Koordinator für verschlüsselte Nachrichten übergroße Client-Anfragen akzeptiert und bei einer Zeitüberschreitung einer Prüfanfrage einen Abbruch-Frame sendet.

Das Release bietet dem Android-Betreiber außerdem eine Live-Statuskarte für events, Speicher, Adresse und Administration und passt die native Kryptografiebibliothek für Geräte mit 16 KB großen Speicherseiten an. Die Änderungen am relay und Koordinator erstrecken sich über mehrere Releases seit der vorherigen Store-Version 0.3.39; 0.3.45 bündelt sie als gemeinsamen Versionsstand.

ngit-grasp 3.0.5 hält Git-Pushes und relay-Synchronisierung am Laufen

ngit-grasp ist ein selbst gehostetes Nostr-relay und Git-Server für signierte Zusammenarbeit an Repositorys. Seine signierte Release-Ankündigung für 3.0.5 verlagert den langsamen Verlaufsabgleich aus dem gemeinsam genutzten Live-Sync-Aktor, sodass relay-Abonnements starten können, während frühere events geprüft werden. Für Ratenbegrenzungen, unvollständige Verlaufsabfragen, Postfach-Lesevorgänge und Identitätsabfragen werden die Wartezeiten vor erneuten Versuchen getrennt erhöht, sodass ein gestörtes relay nicht länger die Kapazität für Wiederholungsversuche monopolisiert.

Dasselbe Release gleicht mit dem lokalen event-Bestand ab, um bereits gespeicherten Verlauf nicht erneut abzurufen, und schließt unvollständige Abonnements, bevor es deren Abdeckung als verifiziert behandelt. Auf der Git-Seite akzeptiert es Pushes, die eine im Hintergrund erfolgte Zustandsübernahme bereits angewendet hat, behält den Konfliktschutz für geänderte Refs bei und liest während Uploads laufend die Git-Fortschrittsausgabe aus, um einen blockierten Push zu verhindern. Diese Details sind wichtig, weil ein Repository auf relays aktiv erscheinen kann, während seine Git-Übertragung noch auf ein maßgebliches Ergebnis wartet.

Armada 0.63.0 unterstützt Push-Benachrichtigungen über verschiedene Signer-Typen hinweg

Armada ist ein Nostr-Client für verschlüsselte Communitys, Kanäle und Direktnachrichten. Nach dem Release zum Schutz der Privatsphäre bei Medien in der vergangenen Woche beschreibt seine signierte Ankündigung für 0.63.0 einen neuen Browser-Push-Pfad, der bei geschlossener App sowohl für Anmeldungen über Erweiterungen und Remote-Signer als auch für andere Kontotypen funktioniert. Tenna, eine Host-App, die Armada einbettet, erhält ebenfalls Hintergrundbenachrichtigungen für ihre Nutzer.

Das Release lädt ältere Nachrichten in langen Community-Kanälen schneller und vermeidet es, bei neuen Nachrichten den gesamten Verlauf erneut einzulesen. Tippindikatoren in Direktnachrichten verwenden weniger relay-Verbindungen. Desktop-Updates erhalten eine Aufforderung zum Neustart, während direkte Upgrades von Versionen vor 0.50.0 nicht mehr unterstützt werden.

Das signierte Folge-Release 0.63.1 ergänzt bearbeitbare Emoji-Pakete mit Ordnerimport und Änderung der Reihenfolge, ruft zitierte Nachrichten auch jenseits des geladenen Verlaufs ab und macht auf relays gehostete Antworten interoperabel. Es reduziert den Datenverkehr beim Wiederverbinden unter Android, holt nach langen Verbindungsunterbrechungen auf, ohne alte Benachrichtigungen zu wiederholen, schließt Erwähnungen vor dem Beitritt aus und bewahrt unbearbeitete Gruppenfelder sowie private Einträge in Serverlisten. Löschungen in auf relays gehosteten Gruppen erfordern nun den Nachrichtenautor oder einen Administrator. Auch das Verschieben von Servern per Ziehen, die Verarbeitung fehlerhafter relay-Informationen und Repository-Abonnements erhalten Korrekturen.

Version 0.63.2 erweitert Markdown in Nachrichten um verschachtelte Zitate und Listen, horizontale Linien, Code-Fences, durch Unterstreichung markierte Überschriften und Formatierung über Links oder Erwähnungen hinweg. Links zu Tenor- und Giphy-Seiten werden als GIFs abgespielt. Die Synchronisierung des Lesestatus überträgt weniger Daten, beim Wiederverbinden werden redundante Downloads und Anmeldungen vermieden, und Android-Hintergrundbenachrichtigungen pausieren die relay-Synchronisierung, wenn große Einstellungsaktualisierungen sie überfluten.

deed 0.3.0–0.3.2 macht die Nostr-Veröffentlichung mit Zig stabiler

deed ist ein Zig-Kommandozeilenwerkzeug zum Lesen und Veröffentlichen von Nostr-events. Seine Version 0.3.2 vom 24. September ergänzt einen Agent-Skill und korrigiert die Fristen für relay-Pings; die vorangegangenen Releases 0.3.1 und 0.3.0 verbessern Leistung und Zuverlässigkeit der Veröffentlichung. Die drei tags beschreiben eine frühe Versionsreihe des Werkzeugs. Der sichtbare Nutzen für Nostr ist eine stabilere relay-Verbindung und ein stabilerer Pfad zur event-Veröffentlichung für Skripte, die die CLI verwenden.

Cordn 0.5.1 hält andere Gruppen am Laufen, wenn ein Koordinator ausfällt

Cordn ist ein MLS-verschlüsselter Gruppenmessenger, der Nostr-Identitäten und relays nutzt, um Gesprächskoordinatoren zu finden. Sein signiertes Client-Release 0.5.1 setzt die Arbeit an der Offline-Warteschlange aus der vergangenen Woche fort, indem es die Ablaufplanung für Koordinatoren und Postausgang trennt: Ein nicht verfügbarer Koordinator verzögert nicht mehr den Versand für andere Gruppen. Aufgelöste relay-Hinweise bleiben nach der Ermittlung erhalten, Gruppendokumente übertragen sie zwischen Geräten, und ein dauerhaft gespeicherter Datensatz für ausstehende Veröffentlichungen stellt steckengebliebene Sendungen wieder her. Bei der Wiederherstellung auf mehreren Geräten laufen Abfragen der Verlaufskette und von Lücken überlappend, während die aktuelle Konfiguration gelesen wird.

Das Release ergänzt außerdem Dateianhänge per Drag-and-drop, angeheftete Gruppen, Profilnamen in Vorschauen und Benachrichtigungen sowie Koordinatorbeschriftungen. Es korrigiert die Positionierung bei der ersten ungelesenen Nachricht, Ungelesen-Zähler, doppelte Benachrichtigungen, Vorschauen für Medien und Systemnachrichten, Antworten auf Medien mit Bildunterschriften sowie Bedienelemente für den Bildzoom. Native Downloads verwenden einen “Speichern unter”-Auswahldialog. Ein erst spät verfügbarer Signer verursacht keine falsche Warnung über nicht unterstützte Verschlüsselung mehr, und Kontowechsel konkurrieren nicht mehr mit der initialen Befüllung im Hintergrund.

Nymbot 1.0.7 ergänzt lokale Dokumentverarbeitung und verschlüsseltes Teilen von Chats

Nymbot ist ein Assistent, der über verschlüsselte, per Gift-Wrap verpackte Nostr-Nachrichten erreichbar ist. Sein vom Entwickler signiertes Release 1.0.7 liest Dokumente auf dem Gerät, wählt relevante Passagen aus, wenn eine Datei zu groß ist, um sie vollständig zu senden, und gibt die verwendeten Seiten an. Gespräche lassen sich über einen Ende-zu-Ende-verschlüsselten Link teilen, dessen Zugriff später entzogen werden kann. Python- und JavaScript-Antworten können lokal ausgeführt werden, wobei ihre Ausgabe in das Gespräch zurückfließt.

Dasselbe Release ergänzt Recherche mit Quellenangaben und einer Preisangabe vor dem Absenden, Bildbearbeitung, Modellauswahl pro Nachricht sowie Ausgabenlimits pro Chat und Bot. Über MCP angebundene externe Werkzeuge fragen vor Datenänderungen nach einer Bestätigung. Repository-Läufe können Änderungen zur Überprüfung pausieren, CI-Ergebnisse anzeigen und nach einer Auslastung des Gateways fortgesetzt werden. Vorgeschlagene Antworten, angeheftete Hinweise, eingeklappte Quellenlisten und eine durchsuchbare Modellauswahl vervollständigen das Update; diese Angaben stammen aus den Release-Notes des Entwicklers; Compass hat den Datenschutz der App nicht unabhängig geprüft.

0xchat 1.5.6 liefert seine Korrekturen für Signierung und Nachrichtenauthentifizierung aus

0xchat ist ein Nostr-Messenger mit privaten Chats, externer Signierung und Wallet-Funktionen. Version 1.5.6 liefert die Sicherheitskorrekturen aus, über deren Übernahme in den Quellcode letzte Woche berichtet wurde, darunter Gift-Wrap-Authentifizierung, Konfiguration vertrauenswürdiger Infrastruktur und Zustimmung zur Signierung durch eingebettete Seiten. Sie schließt außerdem Wege zur Umgehung des Tor-Proxys, validiert TLS-Zertifikate für Nicht-Onion-Hosts und verhindert, dass Release-Builds potenziell sensible Zugangsdaten und Wallet-Material in die Gerätekonsole schreiben. Entwicklerprotokolle, die ausdrücklich aktiviert werden müssen, zeichnen weiterhin Fehler auf.

Das Release erhöht die Wartezeit vor erneuten relay-Verbindungen schrittweise von drei Sekunden auf fünf Minuten, repariert Abonnements nach dem Wiederverbinden und übermittelt Anfragen, die während des Verbindungsaufbaus zu einem relay in die Warteschlange gestellt wurden. Bei Kontowechseln sammeln sich keine doppelten relay-Listener mehr an, eine fehlgeschlagene Anmeldung bewahrt das bereits aktive Konto, und Verbindungen zu externen Signern bleiben über Neustarts hinweg bestehen. Fehlgeschlagene Sendungen zeigen nun Fehler an und bewahren ungesendeten Text oder einen wiederherstellbaren Zustand beim Teilen von Tokens. Die Schlüsselentschlüsselung beim Start und das Hashing von Uploads werden aus dem UI-Thread verlagert; Chat- und Video-Caches vermeiden wiederholtes Rendern und Herunterladen. Das Release stellt Android- und Desktop-Dateien mit SHA-256-Prüfsummen bereit, darunter die von Play signierte Android-APK und einen aus dem Quellcode erstellten Windows-Installer.

Nostr Mail Client 0.17.0 verbirgt Postfachaktionen vor relays

Nostr Mail Client tauscht E-Mails über Nostr aus und unterstützt zugleich die herkömmliche E-Mail-Zustellung. Nach der Veröffentlichung der vergangenen Woche mit empfängerspezifischer Transportwahl und Datenschutz für Medien verbirgt Version 0.17.0 den Lese-, Archiv-, Ordner- und Labelstatus sowie den Zeitpunkt entsprechender Änderungen vor relays und ermöglicht es Nutzern, E-Mails zu löschen, ohne deren Absender zu benachrichtigen. Die Veröffentlichung erfordert, alle Geräte gemeinsam zu aktualisieren, da ältere Clients den neuen Status oder die Löschungen nicht sehen. Sie schützt außerdem Bcc-Empfänger in E-Mails mit mehr als 32 KB, hält lokale Kontaktaliasnamen aus ausgehenden Nachrichten heraus, behebt die QR-Anmeldung mit Amber und veröffentlicht öffentliche E-Mails auf den Lese-relays der Empfänger.

Die Veröffentlichung ergänzt farbige Ordner und Labels mit Regeln für Absender, Betreff und Anhänge; Zitate beim Antworten und Weiterleiten; inline eingefügte Bilder; Vorschauen und Umbenennung von Anhängen; sowie die Auswahl zusammenhängender Bereiche in E-Mail-Listen. Beim Weiterleiten bleiben ursprüngliche Bilder und Anhänge erhalten, Antwortzitate sind zunächst eingeklappt, und der Webeditor erhält ein Kontextmenü. HTML-Tabellen und Inline-Bilder werden genauer dargestellt, Links in reinem Text funktionieren, und die Zeitplanung unterstützt Termine bis zu fünf Jahre im Voraus. Namen und Bilder aus dem Adressbuch erscheinen in der gesamten Benutzeroberfläche, und für die Designfarben stehen Systempaletten, vorgeschlagene oder benutzerdefinierte Paletten zur Auswahl.

Dieselbe Veröffentlichung hält aus Dateien ausgewählte Hintergründe lokal und speichert verlinkte Hintergründe im Cache, wobei ausdrücklich ein Migrationsaufwand anfällt: Ältere dateibasierte Hintergründe müssen auf nativen Plattformen erneut hinzugefügt werden. Sie ändert die standardmäßigen Empfehlungen für relays und Medien, ergänzt die Entdeckung von Nostr-Apps während der Ersteinrichtung sowie Aktualisierungshinweise, bewahrt unbekannte Einstellungen, die von anderen Clients geschrieben wurden, und behebt Probleme bei der unterbrochenen Erstellung des E-Mail-Speichers und bei der Linux-Paketierung. Bei Startfehlern werden nun Details und ein vorausgefüllter Fehlerbericht statt eines leeren Bildschirms angezeigt.

Nostr WoT 0.8.7 bindet die Authentifizierung an das Ziel

Nostr WoT ist eine Browsererweiterung, die das Signieren mit Nostr mit Vertrauenswerkzeugen verbindet. Version 0.8.7 verlangt für die signierte HTTP-Authentifizierung nach NIP-98 eine Zustimmung, die sich auf die genaue URL, die Abfrageparameter, die Methode, das Konto und den anfragenden Ursprung bezieht. Ältere pauschale Genehmigungen erfordern eine erneute Zustimmung. Die relay-Authentifizierung nach NIP-42 verfügt über ein separates, kontogebundenes Berechtigungssystem, in dem seitenspezifische Ablehnungen Vorrang vor gemeinsam genutzten relay-Freigaben haben. Authentifizierungsanfragen müssen von einem verifizierten Browserursprung auf oberster Ebene stammen, und Wartezeiten auf eine Genehmigung oder Entsperrung lösen eine erneute Konto- und Zugriffsprüfung aus.

Die Veröffentlichung überprüft entfernte NIP-46-Signaturen und das vollständige genehmigte event, damit eine zurückgegebene Signatur nicht unbemerkt Inhalte oder ein Ziel austauschen kann. Die Bereitstellung von Wallets und Adressänderungen verwenden eine an den Anfrageinhalt gebundene Authentifizierung, einmalig nutzbare Backend-Challenges und separate Transaktionstoken; allgemeine Signaturanfragen von Websites können diese internen Wallet-Token nicht erzeugen. Das kompatible Backend muss zuerst bereitgestellt werden, und der Client verweigert den Rückgriff auf stillgelegte Endpunkte. Zahlungen über Nostr Wallet Connect überprüfen außerdem ein zurückgegebenes Zahlungs-Preimage anhand des Hashs der angeforderten Rechnung und behandeln eine Abweichung als unbekannten Ausgang.

In der Anfrageoberfläche können Nutzer vollständige rohe events prüfen, bestimmte Anfragen innerhalb einer Website-Gruppe auswählen und private Nachrichten lokal ansehen, ohne deren Rückgabe an eine Website zu genehmigen. Lokale Vorschauen blenden sich nach 30 Sekunden aus; eingehende Anfragen bleiben nicht ausgewählt, und die gewöhnliche Sammelgenehmigung schließt Authentifizierungen aus. Die Erweiterung trennt relay-Berechtigungen für einzelne Websites von solchen für alle Websites, begrenzt das Caching verifizierter Profile, entscheidet bei ersetzbaren events mit identischem Zeitstempel anhand der niedrigeren event-ID und hält Lesezugriffe auf Veröffentlichungen im Start-Popup lokal. Chrome und Firefox erhalten separat überprüfte Pakete und serialisierte Abläufe zur Einreichung stabiler Veröffentlichungen; diese Abläufe belegen keine aktuelle Verfügbarkeit in den Stores.

Die gemeinsame Laufzeitumgebung von Iris hält relay- und Peer-Verläufe konsistent

nostr-pubsub stellt eine gemeinsame Laufzeitumgebung für Nostr-events mit dauerhaftem event-Speicher und einer Warteschlange für ausgehende Veröffentlichungen bereit. Versionen 0.5.7–0.5.13 bündeln exakte Abonnements, spielen sie nach einer erneuten Verbindung wieder ein, halten lokale Nachweise sowie Nachweise von relays und Peers getrennt und melden einen unvollständigen Verlauf, wenn die dauerhafte Speicherung fehlschlägt. Abgeschlossene Abfragen warten darauf, dass jedes empfangene event die Aufnahmeprüfung beendet hat. Der standardmäßige relay-Stapel enthält nun höchstens 20 OR-Filter, um mit gängigen Servern kompatibel zu sein, während Peer-Stapel eine unabhängige Trefferprüfung und einen unabhängigen Abbruch beibehalten.

Die Laufzeitaktualisierungen von Hashtree ersetzen Worker-spezifische Netzwerkfunktionen durch diese gemeinsame Laufzeitumgebung, dauerhafte event-Indizes und eine Ausgangswarteschlange, sodass events und zwischengespeicherte Dateien einen FIPS-Knoten gemeinsam nutzen können. FIPS TypeScript 0.0.44–0.0.45 wählt Routen mit ausreichender Kapazität für vollständige Signalisierungsdatensätze, stellt einen unterbrochenen Sitzungsaufbau innerhalb der Handshake-Frist wieder her und versucht WebRTC-Antworten erst nach einer ausdrücklichen Routing-Ablehnung erneut. Größere gerahmte WebSocket-Routen erfordern kompatible native Peers; die Hinweise zu 0.0.44 verlangen, zuerst das native FIPS 0.4.85 bereitzustellen.

Iris Kit 0.2.5 ergänzt einen persistenten Anwendungsclient für einfache events und transportunabhängiges Signieren nach NIP-46, wobei Kontoschlüssel und Offline-Lesezugriffe erhalten bleiben. Version 0.2.6 gibt eine bereits verifizierte vollständige event-ID sofort aus dem Worker oder dem nativen Backend zurück; Präfixabfragen und Abfragen nach ersetzbaren events warten weiterhin auf den Verlauf, bevor sie den neuesten Wert auswählen. Es handelt sich um Bibliotheksveröffentlichungen, und die Hinweise belegen keine Bereitstellung in jeder Iris-Anwendung.

Die Quellcodeaktualisierung von Iris Meet vom 30. September ersetzt dessen NDK-Integration durch eine persistente Publish/Subscribe-Infrastruktur und gemeinsam genutzte Identitätssignierer. Der Patch ergänzt Testabdeckung für die Offline-Wiederherstellung von Identitäten, das Signieren nach NIP-07 und die Isolation von Besprechungsräumen. Die bestehende Besprechungs-App verwendet Nostr für verschlüsselte Signalisierung und WebRTC für Audio und Video. Dies ist ein Implementierungsfortschritt im Standardbranch; das Repository hat keine mit einem Versions-Tag versehene Veröffentlichung, die belegt, dass diese konkrete Aktualisierung die Live-Website erreicht hat.

Chama übermittelt Angebotsstornierungen und Hintergrundbenachrichtigungen

Chama verwendet signierte events für den Handel innerhalb von Gemeinschaften und private Gespräche. Versionen 6.4.14–6.4.16 veröffentlichen eine signierte Stornierung, bevor ein Angebot lokal gelöscht wird, sodass andere Clients dasselbe zwischengespeicherte Angebot außer Kraft setzen können. Weck-tags für Empfänger begleiten events nun unabhängig von der Benachrichtigungseinstellung des Absenders, und der Benachrichtigungsserver dedupliziert anhand des signierten event, sodass ein Chat unmittelbar nach einem Beitritt weiterhin ein Aufwecken auslösen kann. Hintergrundaufgaben spielen betroffene Handelsvorgänge ab gespeicherten Cursorpositionen erneut ein, isolieren fehlgeschlagene Verarbeitungsketten und entschlüsseln Benachrichtigungstexte lokal; die Veröffentlichung erfordert eine erneute Bereitstellung des zugehörigen Watchers.

Die zusammengefassten Veröffentlichungen wenden außerdem Teilnehmerverlängerungen zu den Zeitpunkten ihrer signierten events an, stellen Finanzierungssperren unter Quarantäne, die nach dem Ablauf eines Platzes eingerichtet wurden, und machen die Wiederherstellung des gespeicherten Inhaberbelegs zugänglich. Die Veröffentlichung eines Anspruchs wartet auf einen bestätigten Import oder eine bestätigte Zahlung. Angebotsfilter behalten die Währung des Betrachters über verschiedene Gemeinschaftsbereiche hinweg bei, und die Kopfzeilen von Handelsvorgängen verwenden den endgültigen Beitrittsbetrag. Diese Änderungen gleichen an, was zwei über Nostr verbundene Clients aus demselben event-Verlauf ableiten.

Earthly 0.1.12 ergänzt wiederverwendbare Kartenkonfigurationen

Earthly ist ein kollaborativer Nostr-Karteneditor mit signierter Veröffentlichung und verschlüsselter Freigabe. Version 0.1.12 ergänzt wiederverwendbare GMapper-Konfigurationen für öffentliche Google My Maps, die Entdeckung von durch Entwickler erstellten Maplets, die private Speicherung oder öffentliche Veröffentlichung von Konfigurationen sowie das Kopieren von Geometrien mit Quellenangabe. Dieselbe Veröffentlichung ergänzt die verschlüsselte Freigabe von Verbindungen, Entity-Drops und die Chat-Navigation auf Mobilgeräten. Die Verfügbarkeit von Google-Exporten und Browser-CORS schränken den Import ein, heruntergeladene ausführbare Maplets bleiben in Tauri nicht verfügbar, und Upgrade-Prüfungen auf physischen Android-Geräten stehen weiterhin aus.

Die Arbeiten an der Konfiguration migrierten bestehende Veröffentlichungsadressen und Einstellungen und ergänzten die Prüfung oder Rücknahme von Konfigurationsaktualisierungen. Der ursprüngliche Android-Workflow schlug vor der Kompilierung fehl; eine Korrektur an den Entwicklungswerkzeugen bereitete die anschließend mit einem Versions-Tag versehene Veröffentlichung vor.

Mostro 0.19.0 nimmt seinen Transport der ersten Generation außer Betrieb

Mostro koordiniert Peer-to-Peer-Handel über Nostr. Version 0.19.0 enthält nun die Entfernung des Gift-Wrap-Transports der ersten Generation, sodass Clients das neuere Protokoll verwenden müssen. Die bestehenden Zeitstempel-tags für die Auftragserstellung und Streitfalleröffnung werden in published_at umbenannt, ohne ihre gespeicherten Werte zu ändern; created_at des umschließenden event bleibt dessen Signierzeitpunkt. Wiederherstellungsantworten geben den Handelsschlüssel der Gegenpartei zurück, akzeptierte create/take-Operationen erkennen Handelsschlüssel, und die Veröffentlichung über relay ist mit der ersten positiven relay-Bestätigung abgeschlossen. Dieselbe Version aktualisiert Kautionsfristen und Stornierung, schließt Streitfälle ab, wenn ein Handel abgeschlossen wird, benachrichtigt den Schlichter und begrenzt das Alter der über relay weitergegebenen Preise.

Mostros Korrektur der Handelsschlüsselzulassung erkennt einen Schlüssel, sobald ein Auftrag oder Streitfall, der ihn einführt, festgeschrieben ist. Knoten mit strengeren Proof-of-Work-Anforderungen beim Erstkontakt konnten zuvor eine legitime Folgenachricht verwerfen, bis die periodische Aktualisierung bekannter Schlüssel erfolgte; bei gleichen Standardschwellenwerten trat das Problem nicht auf. Eine Streitfalltransaktion schreibt den Auftragsübergang und den Streitfalldatensatz atomar fest und verhindert dadurch Fehler durch inkonsistente Zustände. Abschlussbenachrichtigungen senden dem zugewiesenen Schlichter nach dem Best-Effort-Prinzip eine private Nachricht, wenn die Nutzer einen Streitfall lösen; das bestehende ersetzbare event bleibt dabei die Ausweichlösung für den Offline-Fall.

SCRUTINY Lens bringt Sicherheitsforschung auf Nostr

SCRUTINY Lens v0.1.0, dessen erste öffentliche Version am 29. September erschien, ist ein Browser-Client für über Nostr veröffentlichte Sicherheitsmetadaten. Analysten können nach CVE-, Paket- oder Zertifikatskennungen suchen, event-Verläufe und Rücknahmen prüfen sowie Beziehungen in einem Themengraphen erkunden. Der Browser überprüft event-Signaturen und -Kennungen. Optionale KI-Suche und Erklärungen verwenden einen vom Nutzer gewählten Endpunkt; die App prüft zitierte Belege anhand der zugrunde liegenden events. Die Versionshinweise beschreiben relay-Einschränkungen ausdrücklich und benennen lokale Build-Abhängigkeiten, die weiterhin benachbarte Repositorys erfordern.

Mangatsu und Noteds erscheinen für Android

Mangatsu v0.1.11 gehört zur ersten Android-Veröffentlichungsreihe der Anwendung zum Lesen und Veröffentlichen von Comics in dieser Woche. Der Quellcode ergänzt die Anmeldung mit Amber über NIP-55, die Android-Schnittstelle, über die ein externer Signierer um die Genehmigung von Nostr-Operationen gebeten wird. Comics und Kapitel sind Nostr-events, während ihre Seiten auf Blossom-Servern liegen; die Leseanwendung unterstützt außerdem eine verschlüsselte gespeicherte Bibliothek und Offline-Lesen. Nachfolgende Commits befassen sich mit dem Aufruf des Signierers und der Aktualisierung von relay-Listen.

Noteds v0.1.2 bringt über Tauri einen Nostr-Kleinanzeigenmarkt auf Android. Seine Integration eines Android-Signierers verwendet Android-NIP-55-Signierung. Die App veröffentlicht Anzeigen und Nachrichten über Nostr und erstellt einen lokalen Suchgraphen mit Kategorien, geografischen Gebieten und optionalen Browser-Embeddings. Der neueste Quellcode korrigiert den nativen Standortzugriff für die Suche in der Nähe. Beide Projekte befinden sich in einer frühen Veröffentlichungsphase; ihre GitHub-Versionsseiten enthalten keine ausführlichen Hinweise, daher stammen diese Angaben zu Funktionen aus den mit Versions-tags versehenen READMEs und den Implementierungs-Commits.

Statim kombiniert Nostr-Direktnachrichten mit anderen Netzwerken

Statim v0.4.0 folgt auf die erste Veröffentlichung vom 23. September. Der mit einem Versions-tag versehene Quellcode beschreibt einen Messenger mit NIP-17-Nostr-Direktnachrichten neben XMTP, Status, Telegram und Matrix. Konten werden ausgehend von einer lokal gespeicherten Wiederherstellungsphrase eingerichtet; jede Unterhaltung kennzeichnet ihr Protokoll, da diese Netzwerke unterschiedliche Datenschutzeigenschaften bieten. Unter Android fehlt derzeit die Telegram-Integration. Dies sind die dokumentierten Funktionen des Projekts, keine unabhängig geprüften Garantien oder eine Bestätigung der Verfügbarkeit in App-Stores.

In Entwicklung

Amethyst behebt Interoperabilitätsprobleme bei verschlüsselten Gruppen

Amethyst ist ein Android-Nostr-Client mit Unterstützung für verschlüsselte Marmot-Gruppen. White Noise ist ein weiterer Marmot-Messenger; ein mit dessen Clients getestetes Interoperabilitätspaket behebt Probleme bei der Gruppenverwaltung, bei Formulierungen zu Löschungen und bei anderen Verhaltensweisen, die sichtbar werden, wenn die beiden Clients eine Unterhaltung teilen. Gezieltere Korrekturen senden Reaktionen und Löschungen innerhalb der Marmot-Gruppe statt als separate private Nachrichten in NIP-17-Gift-Wraps und übernehmen nach einem Neustart Bearbeitungen aus einem anderen Client. Diese Änderungen wurden in den Quellcode übernommen; die in den PRs beschriebenen Tests sind enger begrenzt als eine veröffentlichte clientübergreifende Version.

Eine separate übernommene Änderung an der Cordn-Gruppenlaufzeit und -Oberfläche fügt einen weiteren Weg für verschlüsselte Gruppen über Koordinatorserver hinzu. Cordn ist von Marmot verschieden, daher sollten die beiden Änderungen nicht als eine gemeinsame Transportmigration verstanden werden.

Amethyst hat außerdem HTTP-relay-Befehle in seinem Geode-relay und Quartz-Client im Rahmen seines NIP-FE-Vorschlags sowie eine Oberfläche zur Prüfung von Sicherungskonflikten für ersetzbare Profil- und Listen-events übernommen. NIP-FE ist eine Bezeichnung für einen Vorschlag des Projekts; der Sicherungsablauf ermöglicht es einer Person, Versionen zu vergleichen, bevor sie einen Ersatz akzeptiert, und verhindert unbemerkte Überschreibungen des lokalen Zustands.

Amethyst entwickelt außerdem Concord, ein separates Protokoll für verschlüsselte Communitys, das von Armada und Accordion verwendet wird. Ein Konformitätspaket ergänzt fragmentierte Community-Listen, Anheftungsnachweise, Schlüsselrotation und Auflösungsdatensätze, gefolgt von verschwindenden Nachrichten und direkten Einladungen. Eine Einladung verbleibt bis zur Annahme in einem privaten Posteingang; ihr Empfang stellt keinen Kontakt zu den relays der Community her. Dieselbe Änderung korrigiert einen Autorenvergleich, durch den eine Löschung eines anderen Autors eine Nachricht entfernen konnte. Clientübergreifende Korrekturen beheben die Serialisierung unsignierter Rumors, fehlende Einladungsfelder, die relay-bestätigte Erstellung von Communitys und den Beitritt ohne Neustart; an den gemeldeten Emulatortests waren aktive Armada- und Accordion-Gegenstellen beteiligt.

Eine spätere Implementierung privater Kanäle rotiert Kanalschlüssel nach relevanten Zugriffsentzügen und ergänzt Steuerelemente zum Erstellen, zum Umschalten auf privat oder öffentlich und zum Erneuern der Schlüssel. Sie ergänzt außerdem kooperative Ausschlüsse mit Rangprüfung und lässt Nachrichtenanhänge zusammen mit ihren übergeordneten Nachrichten ablaufen. WebXDC-Aktualisierungen können in einen separaten Kanalpuffer gelangen, aber Amethyst verfügt weiterhin über keinen WebXDC-Anwendungshost. Für dieses spätere Paket werden Tests des Übertragungsformats und Unit-Tests gemeldet, jedoch keine Tests auf Geräten oder mit aktiven relays; das frühere Interoperabilitätsergebnis bestätigt daher nicht jedes neu hinzugefügte Steuerelement.

Die MLS-Engine von Quartz bewahrt nun übersprungene Nachrichtengenerierungsgeheimnisse über einen Neustart hinweg, sodass Nachrichten, die nicht in der richtigen Reihenfolge eintreffen, nach der Wiederherstellung eines gespeicherten Zustands weiterhin entschlüsselt werden können. Vier aufbewahrte frühere Epochen ermöglichen es aufrufendem Code, verspätete Anwendungsnachrichten zu authentifizieren, deren authentifizierte Daten aufzubewahren und zu verhindern, dass eine verbrauchte Generation erneut geöffnet wird. Eine Aktualisierung des Geheimnisbaums lädt noch nicht expandierte Knotengeheimnisse aus einem Zustand im Stil von ts-mls; absenderspezifische Fehler für veraltete Generationen unterscheiden eine eigene Ratchet-Kollision eines Clients von einem Replay durch ein anderes Mitglied. Der PR sagt ausdrücklich, dass Marmots bestehender Rückfallmechanismus für aufbewahrte Epochen separat bleibt; dies ist daher eine Fähigkeit der Engine und kein Beleg dafür, dass jeder Nachrichtenpfad in Amethyst sie nutzt.

Eine Prüfung der tag-Leser in Quartz behebt private Geohash-Einträge, die im Klartext veröffentlicht werden konnten, sowie einen Parser, der den privaten Schlüssel aus einem nsec als öffentlichen Schlüssel behandelte. Sie korrigiert außerdem Repost-Adressen, Ziele zum Ausblenden von Kanälen, Root-tags für Live-Räume und adressierbare Mint-events. Der veraltete ForkTag-Leser wird entfernt, wodurch sich die Quellcode-API für Nutzer von Quartz ändert; bereits vorhandene SQLite-Mint-Zeilen benötigen weiterhin eine separate Migration. Zusätzliche event-Modelle decken die Projektcontainer-, Artefaktrevisions- und Teamvorschläge von Buzz ab, während Modelle für Videoaufrufe und verschlüsselte Push-Steuerung den Schemas von Divine folgen; diese Ergänzungen schaffen Unterstützung für Parsing und Erstellung, aber keine vollständigen Client-Oberflächen oder verabschiedeten nummerierten NIPs.

Der Client stellt außerdem Ultra-HDR-Fotografien dar, und zwar im Feed und im Vollbildbetrachter unter Android 14 oder neuer. Android 15 und neuer begrenzen die Helligkeitsverstärkung im Feed auf das Doppelte des gewöhnlichen Bereichs, während im Vollbild der gesamte Bereich des Displays genutzt werden kann; auf den gemeldeten Testgeräten liefen neuere Android-APIs, sodass Android 14 und 15 ungetestet blieben. Eine übernommene Änderung für eine gemeinsame UI und die Portierung des Uploads stellt 140 Ansichten auf gemeinsamen Android-/Desktop-Code um und verlagert die Android-Medienverarbeitung aus dem UI-Thread. Die zugehörige Prüfung stellt außerdem die Fehlermeldungen beim Entfernen von Metadaten wieder her, sodass das Refactoring mehr als eine bloße Verschiebung von Dateien ist.

Divine ergänzt verschlüsselte Videos in Direktnachrichten

Divine ist ein Nostr-Video-Client. NIP-17 überträgt private Nachrichten in verschlüsselten Gift-Wraps, die ihren Absender vor relays verbergen. Die übernommene Arbeit an Videonachrichten von Divine verschlüsselt ein angehängtes Video auf dem Gerät, lädt den Chiffretext hoch und sendet den Entschlüsselungsschlüssel innerhalb dieser privaten Nachricht. Ein Empfänger kann die Datei zur Wiedergabe überprüfen und entschlüsseln oder sie speichern. Eine separate Korrektur der Verlaufswiederherstellung verhindert, dass eine mehrdeutige Ablehnung durch einen relay die Wiederherstellung vorzeitig beendet, wenn andere relays noch antworten können.

Divines Korrektur für ausgemusterte Moderationsschlüssel lehnt ausgemusterte Schlüssel bei der Auflösung von Moderationslabels ab und wählt beim Einreichen einer Meldung den aktuellen Meldungsempfänger aus. Ausstehende Meldungen, die an einen ausgemusterten Schlüssel adressiert sind, werden an den im Build fest hinterlegten Schlüssel umgeleitet, und ungeklärte Unterhaltungen bleiben für Schreibzugriffe gesperrt. Die Änderung unterscheidet außerdem die Verwahrung ausgemusterter Schlüssel bei der Entscheidung, welche historischen Threads eine minderjährige Person lesen darf; Aktualisierungen der Verwahrung erfordern weiterhin eine neue Anwendungsversion. Die Cache-Behandlung gelöschter Kommentare verhindert, dass ein erfolgreich gelöschter neuerer Kommentar beim erneuten Laden eines Threads wieder erscheint.

Für Ersteller zeigt ein Aufnahmemodus mit Live-Farbmaske eine Vorschau des Ersatzhintergrunds an, bevor eine Aufnahme aufgezeichnet wird, und die Maskierung weißer Wände ergänzt eine helligkeitssensitive Maskierung über das Video-Plugin. Wortweise Untertitel bewahren die erkannten Zeitangaben einzelner Wörter und verwenden ungefähre Zeitangaben, wenn der Server nur vollständige Untertitelabschnitte liefert. Die Fortsetzung von Stop-Motion-Aufnahmen hängt neue Standbilder im Tempo der bestehenden Komposition an, während das Zurückführen abgetrennter Clips, die gruppierte Schriftartauswahl und Geschwindigkeitsvoreinstellungen Bearbeitungsfunktionen ergänzen, ohne das Nostr-event-Format zu ändern.

Die Ausrichtung beim quadratischen Export und die zugehörige Folgekorrektur für kleinere Clips halten Text und Sticker über Clips mit unterschiedlichen Auflösungen hinweg an ihrem Platz. Die HLS-Wiedergabe von Drittanbietern vermeidet einen Android-Heap-Absturz, indem sie an Schleifengrenzen zurückspringt, statt wiederholte importierte Wiedergabelisten vorab zu puffern; diese Schleifen können bei jedem Neustart kurz pausieren. Ein Neuladen der Kontoeinstellungen hält kontogebundene Filter bei einem Wechsel auf ihren Standardwerten und korrigiert zugleich einen Teil einer Debug-Assertion bei der Anmeldung. Ein separates Problem bei der Aktualisierung von Moderationslabels bleibt offen, daher behauptet der PR nicht, dass jeder Anmeldefehler behoben ist.

Buzz erweitert die Kanal- und Identitätskontrollen seines relay

Buzz ist ein Nostr-basierter Arbeitsbereich mit eigenem relay und eigenen Clients. Seine gemergte Implementierung für Kanalartefakte ordnet einem bearbeitbaren Datensatz genau einen Kanal zu und gibt ihm eine Revisionskette; widersprüchliche Bearbeitungen können nicht beide zur aktuellen Revision werden. Die Bezeichnung NIP-AR des Projekts bezieht sich auf dessen eigenen Vorschlag und dessen eigene Implementierung, nicht auf einen etablierten Nostr-Standard.

Für geschützte eingehende HTTP-Zugriffe verknüpft eine weitere gemergte Änderung eine föderierte Identitätszusicherung mit demselben Schlüssel, der durch die NIP-98-Autorisierung nachgewiesen wird. NIP-98 definiert signierte HTTP-Authentifizierungs-events; die NIP-FI-Zusicherung von Buzz ist eine projektspezifische Spezifikation. Außerdem wurde HPKE-Verschlüsselung für Backup-Hüllen geheimer Schlüssel gemergt. Dieser PR belegt Sicherheitsarbeit auf Quellcode-Ebene; die Auslieferung an jeden Client bleibt unbestätigt.

Buzz desktop 0.5.26 enthält die Arbeiten an Kanalartefakten, native HPKE-Verschlüsselung für Backups geheimer Schlüssel und eine Administrationskonsole für den relay auf dem Desktop. Die gemeinsam genutzten Änderungen beheben Anfragen für nicht gelistete Projektkanäle, synchronisieren Abschnitte der Seitenleiste, Sortierung, Sternmarkierungen und Stummschaltungen geräteübergreifend, begrenzen Lesevorgänge für lange Threads und verschärfen Blossom-Identitätszusicherungen. Die repositoryweiten Hinweise führen separat die Identitätsverknüpfung beim relay, die Zustellung von Companion-Erwähnungen, konfigurierbare Push-URLs, atomare administrative Löschung und kontextbezogene Namen auf Mobilgeräten auf. Eine Desktop-Veröffentlichung belegt die Auslieferung der Desktop- und gemeinsam genutzten Komponenten; sie beweist nicht, dass diese mobilen Änderungen in einem mobilen Build ausgeliefert wurden.

Die Durchsetzung von NIP-FI über WebSocket in Buzz prüft eine föderierte Identitätszusicherung, bevor Frames angenommen werden, und verlangt dann, dass deren Nostr-Schlüssel mit dem durch NIP-42 authentifizierten Schlüssel übereinstimmt. NIP-42 weist die Identität eines Clients gegenüber einem relay nach. Eine Sitzung läuft zum frühesten der folgenden Zeitpunkte ab: Ablauf des Tokens, Erreichen des maximalen Alters der Zusicherung oder Ende der konfigurierten Verbindungsdauer; nach dem Ablauf lässt sie keine neuen wirksamen Vorgänge mehr zu. Dieser projektspezifische NIP-FI-Modus ist standardmäßig deaktiviert. Bereits zugelassene Audio-Commits und die Einrichtung von Abonnements können weiterhin auf eine blockierte Abhängigkeit warten, sodass die Änderung keine universell begrenzte Zeit bis zur Trennung belegt.

Die Vorbereitung der Löschung durch Eigentümer leitet von Betreibern bestätigte Anfragen über eine an den Bestand gebundene automatische Genehmigung an die bestehende Löschkomponente weiter. Eine Folgeänderung am relay sorgt dafür, dass ein erneuter Versuch derselben Anfrage deren aktuellen Zustand zurückgibt, und reserviert das aktive Kontingent des Eigentümers, bis die Löschung abgeschlossen ist; dauerhaft aufbewahrte Host-Tombstones zählen zu einer Obergrenze von 20 Communities über die gesamte Lebensdauer. Dies sind administrative Änderungen auf Quellcode-Ebene, und die Folgeänderung weist Betreiber an, die Löschung deaktiviert zu lassen, bis der zugehörige relay und der Drain-Executor in Betrieb sind. Separat erkennt eine Prüfung des Partitionskatalogs Sammelpartitionen und nicht abgedeckte Monate, bevor neue Partitionen für events und Zustellprotokolle erstellt werden, und macht damit die Sicherheit der Bereitstellung und die Aktualität der Prüfung für Betreiber sichtbar.

Buzz mobile unterscheidet jetzt Personen und Agenten, die denselben Anzeigenamen haben. Sein Resolver für Identitätsnamen ergänzt Agentennamen um deren Eigentümer und fügt nur bei Bedarf ein kurzes Schlüsselsuffix hinzu; die Integration in Unterhaltungen verwendet diese Namen für Autoren, Erwähnungen und Mitgliedschaftshinweise. Listen, Suche und Pulse vervollständigen dasselbe Verhalten außerhalb einer Unterhaltung. Die sichtbare Ergänzung verändert die lokale Bezeichnung, während eine ausgewählte Erwähnung den ursprünglichen Übertragungsnamen der Identität beibehält.

Conduit setzt den Checkout nach der Annahme durch einen relay fort

Conduit ist ein Nostr-Marktplatz, der private Bestellnachrichten an Händler sendet. Die progressive Veröffentlichung über relays unterscheidet die erste positive Bestätigung eines relay vom Abschluss aller relay-Versuche, und eine Folgeänderung am Checkout speichert diese erste Bestätigung dauerhaft, bevor der Ablauf fortgesetzt wird. Die Annahme durch einen relay bedeutet, dass die signierte Bestellung einen relay erreicht hat; sie beweist nicht, dass ein Händler sie gelesen oder erfüllt hat.

Conduit hat außerdem wiederherstellbare Sitzungen mit entfernten Signierern und transaktionale Aushandlung des Signierer-relay gemergt. NIP-46 ermöglicht einer Anwendung, Signaturen von einem Schlüssel anzufordern, den ein separater Signierer verwahrt; diese Änderungen erhalten den Kontoarbeitsbereich eines Nutzers, während dessen Transportverbindung repariert wird, und überprüfen dann vor dem Fortsetzen das genaue Konto. Die PRs belegen das Verhalten im Quellcode, nicht einen ausgelieferten Checkout-Build.

Conduits gemergte Produktsuche mit Relevanzsortierung sendet eine gewöhnliche NIP-50-Volltextsuchanfrage für Produkte mit kind 30402 und bewahrt die Relevanzreihenfolge des relay über Signaturprüfungen, Revisionsabgleich und lokale Eignungsfilterung hinweg. Karten können erscheinen, bevor Hintergrundabfragen für exakte Produkte abgeschlossen sind, während neuere signierte Löschungen maßgeblich bleiben. Aktualisieren und Erneut versuchen bleiben auf die Suche und Abfragen für exakte Produkte beschränkt, statt eine breit angelegte Katalogerkundung zu starten. Eine Begrenzung auf 100 Ergebnisse mit anschließender lokaler Filterung kann geeignete Treffer übersehen, sodass eine leere Teilantwort eine Möglichkeit zur Wiederaufnahme bietet und nicht beweist, dass es keine Produkte gibt.

Elisym entwickelt einen Nostr-Commerce-Checkout

Elisym entwickelt ein Commerce-Toolkit, das Produkte signiert und private Bestell- und Belegnachrichten über Nostr übermittelt. Sein gemergtes Commerce-Paket definiert Angebotsprüfung und per Gift Wrap verpackte Bestell-events; eine Checkout-Oberfläche übernimmt die Prüfung von Angeboten, die Zahlung per Wallet und den Lieferstatus, während ein selbst gehosteter Händlerknoten die Shop-Seite bündelt. Das Projekt bezeichnet kind 30490 als vorläufig und beschreibt einen minimalen Funktionsumfang für Oktober. Diese Quellcode-Merges belegen eine entstehende Integration; ein anerkannter Nostr-Commerce-Standard oder eine vollständige öffentliche Einführung wurde nicht nachgewiesen.

Elisyms Checkout-Werkzeuge für Agenten ergänzen buy_product und get_order für seine über Nostr beworbenen Produkte. Der erste Aufruf gibt ein Preisangebot zurück, ohne eine Bestellung auszulösen, und ein zweiter Aufruf akzeptiert das einmalig verwendbare Preisangebot und die Warnhinweise für denselben Agenten und dasselbe Netzwerk; der Bestellstatus wird dauerhaft im lokalen Datei-Backend des Agenten gespeichert. Die Unterstützung für Tempo-Checkout ergänzt einen Zahlungsweg über eine Browser-Wallet mit Händlerprüfung und Lieferung. Ein gesendeter Transaktionshash hält den Versuch aktiv, bis dessen Ergebnis feststeht, und vermeidet so ein als unbezahlt ausgewiesenes Ergebnis, solange eine übertragene Transaktion noch abgeschlossen werden könnte.

Eine spätere Checkout-Korrektur ermöglicht die Initialisierung des Checkouts für signierte Produkte, wenn sich eine Browser-Wallet unmittelbar während der Erkennung meldet. Die Quellcode-Änderung verlegt die Sitzungsdeklaration vor den Zeitpunkt, zu dem dieser Callback ausgeführt werden kann; der Merge allein bestätigt keine gehostete Bereitstellung.

nostter verbessert Signiererprüfungen und den Abruf von events

nostter ist ein sozialer Nostr-Client. Seine gemergte Änderung zur Signiererfähigkeit prüft, ob ein verwendbarer Signierer vorhanden ist, bevor Aktionen zum Folgen und Reagieren angeboten werden. Neue Pin-tags enthalten den Schlüssel des Autors und einen bekannten relay-Hinweis, ohne einen zu erraten, und die Cache-Sortierung für ersetzbare events folgt der Zeitstempelregel und der event-ID-Regel zur Auflösung von Gleichständen aus NIP-01. NIP-01 definiert die grundlegenden Regeln für Nostr-events, einschließlich der Auswahl zwischen ersetzbaren events durch Clients.

Pensieve bereitet einen isolierten Archivabgleich vor

Pensieve ist ein Werkzeug zur Archivierung und Wiederherstellung für Nostr. Seine gemergte isolierte Negentropy-Laufzeit stellt der Synchronisierung einen begrenzten Worker und ein dauerhaftes Abschlussverhalten bereit. Die Funktion muss ausdrücklich aktiviert werden, und der PR stellt ausdrücklich fest, dass kein Produktionsdienst und keine Konfiguration aktiviert wurden; dies sind Vorarbeiten für einen sichereren Wiederherstellungsweg, kein Beleg für eine laufende Bereitstellung.

ContextVM vermeidet doppelte Aufrufe über mehrere relays

Das TypeScript SDK von ContextVM übermittelt Werkzeug- und Ressourcenanfragen als Nostr-events. Seine gemergte Korrektur zur Deduplizierung eingehender Anfragen erkennt eine Klartextanfrage anhand der event-ID auch dann, wenn mehrere relays oder eine erneute Verbindung sie nochmals zustellen, entsprechend dem bestehenden Pfad für verpackte Nachrichten. Der PR berichtet, dass vor der Korrektur ein nicht idempotentes Werkzeug bei einem einzelnen Aufruf dreimal ausgeführt wurde. Eine begleitende Änderung an Ressourcenbenachrichtigungen sendet Aktualisierungen nur an abonnierte Clients; initialisierte Sitzungen ohne Abonnement erhalten sie nicht mehr.

Cyberspace überarbeitet die Objektregeln von DECK-0003

Cyberspace entwickelt das DECK-0003-Format für strukturierte Nostr-Objekte und verschlüsselte Regions-Bags, mit dessen Implementierung Amethyst laut der Ausgabe von letzter Woche begonnen hat. Neue Regeln für Teile und verborgene Objekte und Bag-Referenzen ermöglichen es einem Bag, auf ein separat veröffentlichtes Objekt zu verweisen, statt jeden Teil einzubetten. Eine spätere Korrektur besagt, dass eine event-ID-Referenz eine alte Version eines adressierbaren event nicht zuverlässig festhalten kann, weil ein relay sie nach einer Ersetzung verwerfen kann. Leser sollten die korrigierte Regel für Koordinatenreferenzen verwenden; der Wortlaut der früheren übernommenen Änderung wurde ersetzt.

Wisp korrigiert Antworten auf Nostr-Kommentare

Wisp ist ein Nostr-Client mit relay-Routing und Wallet-Funktionen. Nach der letzte Woche veröffentlichten Unterstützung für NIP-22-Kommentare sorgt eine übernommene Folgeänderung dafür, dass eine Antwort auf einen NIP-22-Kommentar ebenfalls ein Kommentar-event ist, mit den korrekten Eltern- und Wurzelreferenzen; der bisherige Ablauf veröffentlichte immer eine gewöhnliche Notiz. NIP-22 ermöglicht es, Kommentare an viele Nostr-Inhaltstypen anzuhängen. Die Korrektur wurde nach Wisps Versions-Tag 1.2.5 übernommen, dessen Versionshinweise lediglich die Versionsnummer erhöhen. Es handelt sich somit um Fortschritt auf Quellcode-Ebene, dessen Veröffentlichung weiterhin nicht bestätigt ist.

Cordn übermittelt Koordinatorstandorte an ein zweites Gerät

Cordn koordiniert verschlüsselte Gruppennachrichten über Nostr. Seine übernommene Änderung der Spezifikation für mehrere Geräte überträgt die relay-Hinweise zum Koordinator einer Gruppe im replizierten Gruppendokument. Ein neu mit Ausgangsdaten versorgtes Gerät kann dadurch einen Koordinator finden, der auf den Standard-relays nicht vorhanden ist, statt scheinbar einer Gruppe beizutreten, deren bisherige und laufende Nachrichten es nicht abrufen kann. Dies ist Arbeit am Protokolldokument im Anschluss an Cordns Veröffentlichung der Offline-Warteschlange letzte Woche, keine neue Client-Veröffentlichung.

Nostr Atlas eröffnet ein Verzeichnis für überprüfbare Identitäten

Nostr Atlas ist ein neues Verzeichnis, das Nostr-Profile zusammen mit beanspruchten Zuordnungen zu externen Konten darstellt. Die übernommene Veröffentlichung der Website trennt das Verzeichnis von der Komponentendemo des Projekts, und die Website ist öffentlich erreichbar. Eine übernommene Änderung des Zuordnungsablaufs ermöglicht es dem Inhaber eines X-Kontos, mit einem Browser-Signer einen signierten NIP-39-Nachweis zu veröffentlichen, während die Profilanreicherung Nostr-Metadaten von kind-0 erst liest, nachdem der Nachweis erfolgreich überprüft wurde. NIP-39 definiert das Nachweismuster für die Zuordnung eines Nostr-Schlüssels zu einer anderen Online-Identität; eine relay-Bestätigung allein kennzeichnet eine beanspruchte Zuordnung nicht als verifiziert.

nostr-java ergänzt Werkzeuge für Medienhosting und bewahrt tag-Positionen

nostr-java ist eine Java-Bibliothek und ein MCP-Werkzeugsatz für Nostr-Anwendungen. Seine übernommenen Blossom-Werkzeuge ermöglichen es einem Aufrufer, hash-adressierte Medien hochzuladen, zu finden, aufzulisten und zu löschen sowie die Serverliste des Nutzers zu verwalten. Eine separate Korrektur bei der Veröffentlichung hält leere tag-Werte an ihrer Position: Nostr-tags sind positionsabhängig, sodass das Entfernen eines leeren relay-Hinweises einen Marker in das falsche Feld verschieben und dazu führen könnte, dass das veröffentlichte event von der genehmigten Vorschau abweicht.

Zap Cooking ändert die Wiederherstellung des Kontoverlaufs

Zap Cooking ist ein Nostr-Client zum Teilen von Rezepten. Seine übernommenen Arbeiten an der Lazarus-Wiederherstellung ersetzen eine auf anwendungsspezifischen Daten-events nach NIP-78 beruhende Sicherung durch einen Ansatz, der von relays aufbewahrte Versionen ersetzbarer events durchsucht, um überschriebene Follow-Beziehungen, Stummschaltungen oder Profile zu erkennen. Lazarus bleibt ein Protokollentwurf; die Wiederherstellung hängt von relays ab, die die älteren Versionen aufbewahrt haben, und ein übernommener PR für den Web-Client garantiert nicht, dass jedes verlorene event wiederhergestellt werden kann.

Der Client hat außerdem optionale NIP-13-Proof-of-Work-Steuerungen für Notizen und Antworten sowie ein Anhangsmodell übernommen, das die Medienreihenfolge und NIP-92-Beschreibungen zwischen Vorschau und Veröffentlichung konsistent hält. NIP-13 ermöglicht es einem Absender, vor der Veröffentlichung lokale Rechenleistung für ein event aufzuwenden; NIP-92 überträgt Medienmetadaten als event-tags.

Zap Cookings Korrektur für NIP-05-Namensansprüche verlangt eine NIP-98-Autorisierung über den exakten Anfragekörper und weist einen Signer zurück, der vom öffentlichen Schlüssel abweicht, der den Namen beansprucht. Zuvor akzeptierte dieser öffentliche Endpunkt nicht authentifizierte Ansprüche, die den Namen eines anderen Mitglieds ersetzen konnten. Die Mitgliedschaftsstufe stammt nun aus dem bestehenden Mitgliedschaftsdatensatz, und Nutzer eines Remote-Signers erhalten beim Beanspruchen eines Namens eine Signaturanfrage. Der separate vertrauenswürdige serverseitige Registrierungspfad bleibt unverändert.

Eine Reparatur der Stummschaltungsliste verhindert, dass Aktionen zum Stummschalten von Profilen die gesamte Liste von kind 10000 allein durch tags mit öffentlichen Schlüsseln ersetzen. Der bisherige Ablauf löschte Wort-, Hashtag- und Thread-Einträge sowie verschlüsselte Inhalte, und eine Oberfläche konnte entschlüsselte private Stummschaltungsschlüssel öffentlich erneut veröffentlichen. Der neue Ablauf liest die Kopie vom relay, bewahrt nicht betroffene tags und den Geheimtext und verweigert die Veröffentlichung, wenn dieses Auslesen nicht möglich ist. Das Entfernen einer privaten Stummschaltung erfordert Entschlüsselung und erneute Verschlüsselung durch den Signer.

Opal bringt Remote-Signierung zu Omarchy

Opal ist ein Desktop-Nostr-Signer für die Omarchy-Linux-Umgebung. Seine Version 0.3.3 vom 28. September folgt auf die erste öffentliche Veröffentlichungsreihe mit Unterstützung für Remote-Signierung nach NIP-46, einem lokalen Schlüsselbund und einer Berechtigungsoberfläche für Anfragen verbundener Apps. NIP-46 belässt den Kontoschlüssel beim Signer, während ein separater Client ihn um die Genehmigung von Vorgängen bittet. Dies ist eine frühe Veröffentlichung eines plattformspezifischen Signers, keine Behauptung einer breiteren Desktop-Unterstützung.

WatchTower eröffnet eine NIP-86-Verwaltungsoberfläche für relays

WatchTower ist eine neu veröffentlichte Oberfläche für die relay-Administration über NIP-86, das Protokoll für authentifizierte relay-Verwaltungsanfragen. Eine öffentliche Instanz ist erreichbar und bietet Betreibern die Möglichkeit, die Oberfläche zu prüfen. Das Repository wurde am 22. September erstellt; eine erreichbare Website belegt weder, dass ihre Autorisierungsabläufe unabhängig geprüft wurden, noch, dass sie mit jeder relay-Implementierung funktioniert.

Hubstr Blossom eröffnet einen persönlichen Ursprungsserver für Medien

Der neu veröffentlichte Hubstr Blossom server ermöglicht es einem Nostr-Client, Bilder, Videos und Dateien auf einen selbst gehosteten Blossom-Endpunkt hochzuladen und diese URLs anschließend in events einzufügen. Seine README dokumentiert eine lokale Speicherung anhand von Inhalts-Hashes, einen SQLite-Index, signierte kind-24242-Autorisierung für Änderungen sowie eine Reihe von Blossom-Vorgängen zum Hochladen, Spiegeln, Auflisten und Löschen. Öffentliche Lesezugriffe ermöglichen es anderen Clients, veröffentlichte Medien darzustellen, ohne Upload-Rechte zu erhalten.

Die dokumentierten Optionen des Servers extrahieren außerdem Dateimetadaten für NIP-94-events, die geteilte Medien beschreiben. Der Server kann Bilder ohne EXIF-Metadaten neu kodieren und schützt Spiegelungsanfragen standardmäßig vor Zielen in privaten Netzwerken. Dies ist eine neu veröffentlichte Implementierung mit Bereitstellungsanweisungen, kein Beleg für einen breiten Einsatz im Produktivbetrieb.

Hubstr Relay veröffentlichte seinen ersten Quellcode am 24. September. Es kombiniert einen persönlichen SQLite-event-Cache mit einem öffentlichen relay: Nicht authentifizierte Leser sehen erlaubte öffentliche events, während über NIP-42 authentifizierte Mandanten ihren Cache lesen können. NIP-17-Gift-Wraps bleiben für Gastleser unzugänglich. Sein Update vom 25. September korrigiert Datensätze, die von NIP-86-pubkey-Listenmethoden zurückgegeben werden.

Meshstr experimentiert mit einem erlaubnisfreien relay-Mesh

Meshstr ist ein Entwurf im Alpha-Stadium, mit dem Nostr-relays Budgets zwischen Peers aushandeln und signierte Nutzungsbelege austauschen sollen. Seine erste Implementierung umfasst eine Brücke für die Schreibrichtlinie von strfry, einem Nostr-relay, die am 27. September hinzugefügt wurde, gefolgt von einer Socket-Korrektur am nächsten Tag. Das Repository beschreibt DIDComm-Verhandlungen und den Abgleich nach NIP-77, der es Peers ermöglicht, event-Mengen zu vergleichen, ohne ihre vollständigen Bestände auszutauschen, sowie überprüfbare Berichte über Peers, die vereinbarte Budgets überschreiten.

Diese Projektregeln sind ein Vorschlag, kein verabschiedetes NIP und kein nachgewiesenes öffentliches relay-Netzwerk. Der konkrete Fortschritt dieser Woche ist der veröffentlichte Codepfad, der die Schreibrichtlinie eines relay mit der vorgeschlagenen Mesh-Abrechnung verbindet.

Dossier zeigt, was eine öffentliche Nostr-Historie offenlegen kann

Dossier ist ein neues browserseitiges Tool zur Selbstüberprüfung der Nostr- und Lightning-Spuren einer Person, mit einer öffentlichen Demo. Es sammelt sichtbare Profillinks, zap-Spuren, Veröffentlichungszeiten, Metadaten aus alten, mit NIP-04 verschlüsselten Direktnachrichten und Medienmetadaten wie EXIF-Daten von Fotos; es kann außerdem zeigen, wo ein relay noch ein event ausliefert, das jemand zu löschen versucht hat. Die Unterstützung für NIP-07-Signer ermöglicht es Nutzern, Bereinigungsaktionen zu autorisieren, ohne einen privaten Schlüssel in die Seite einzufügen.

Die dokumentierten Grenzen des Projekts sind wichtig: Ein Scan sieht nur die relays, die er erreicht, und eine Löschanfrage kann keine Kopien entfernen, die andernorts gespeichert sind. Das Repository erschien am 27. September und hat kein mit einem tag versehenes Release; die Demo und der Quellcode belegen ein frühes Tool, keine vollständige Bestandsaufnahme der vergangenen Aktivitäten einer Person.

Marmot MDK erweitert Umfragen, benutzerdefinierte Emojis und Kontometadaten

Marmot MDK stellt die Laufzeitumgebung und Bindings für verschlüsselte Nostr-Gruppennachrichten bereit. Spätere, in den MDK-Quellcode übernommene Änderungen machen seitenweise abrufbare Umfrageauswahlen pro abstimmender Person zugänglich und verwenden dabei dieselben Regeln zur Ermittlung der maßgeblichen Antworten wie die aggregierten Auszählungen. Optionale anwendungseigene Gruppenkomponenten geben Hosts administrativ kontrollierte Einstellungen, die die Nachrichtenaufbewahrung überdauern und neue Mitglieder in ihrer Welcome-Nachricht erreichen. Sendungen mit tags und Medienreaktionen transportieren Metadaten benutzerdefinierter Emojis durch die Laufzeitumgebung und Bindings, bewahren Entschlüsselungsmaterial für angehängte Reaktionsbilder nach einem Epochenwechsel auf und weisen gefälschte Anhang-tags zurück. Diese Änderung erweitert die C-Struktur für Upload-Anfragen, sodass C-Nutzer ihren Code gegen den Header neu kompilieren müssen.

Eine Konvergenzkorrektur hält Nachrichten ausstehend, wenn kein kanonischer Zweig ausgewählt wurde, statt sie für ungültig zu erklären, ohne den aktuellen Zustand auszuprobieren. Eine begleitende Bereinigung unerreichbarer Codepfade führt unaufgelöste vorgemerkte Commits dem beibehaltenen Wiederholungsverhalten zu. Lesevorgänge für verschlüsselte Medien gleichen das HTTP-Lesezeitlimit an die Behandlung von Leerlaufzeiten bei fortsetzbaren Antwortinhalten an und gehen damit stockende große Übertragungen an, ohne zu behaupten, dass der noch ausstehende Geräte-Abnahmetest für eingehende APKs bestanden wurde. Markierungen für Startphasen zeigen, welcher Schritt beim Öffnen eines Kontos das Zeitlimit überschritten hat, und liefern zusätzliche diagnostische Hinweise, ohne zu behaupten, dass die zugrunde liegende Blockade beim Start behoben ist.

Der lokale Agent-Connector führt außerdem vorhandene Profilmetadaten zusammen, wenn er ein kind 0-Update veröffentlicht, und bewahrt dabei Felder, die in der Anfrage fehlen. Gruppenprofil-Updates machen Änderungen am Namen und an der Beschreibung einer Gruppe über den bestehenden, vom aktuellen Administrator autorisierten Pfad zugänglich. Seine Socket-Authentifizierung gewährt weiterhin Zugriff auf die gesamte lokale API; diese übernommene Änderung fügt keine Berechtigungsvergabe pro zugreifender Identität hinzu. Diese Quellcodeänderungen folgen auf das mit einem tag versehene Release 0.11.0.

rust-nostr ordnet relay-Zählantworten den Anfragen zu

rust-nostr, eine Rust-Bibliothek und ein SDK für Nostr-Anwendungen, hat zugeordnete COUNT-Antworten und klarere Fehler beim Warten übernommen. Das SDK richtet das Abonnement vor dem Senden von COUNT ein und akzeptiert nur die passende Antwort. Dadurch wird verhindert, dass ein verloren gegangener oder geschlossener Empfänger als legitime Null erscheint. Es bewahrt außerdem Empfängerfehler für Veröffentlichungsbestätigungen und die relay-Authentifizierung, sodass Aufrufer eine fehlende Bestätigung von einer ausdrücklichen Ablehnung unterscheiden können. Die Signaturen öffentlicher Methoden bleiben unverändert.

ZapTracker ergänzt Nostr-Netzwerk- und Zitatmetriken

ZapTracker ist ein Dashboard für Content-Ersteller zur Interaktion auf Nostr und zur Wallet-Aktivität. Eine übernommene Änderung am Netzwerk-Dashboard ersetzt Lightning-Netzwerkstatistiken durch Daten zu erreichbaren Nostr-relays von nostr.watch und Informationen zu unterstützten Funktionen aus NIP-11-Dokumenten. Eine Änderung an den Zitatmetriken zählt kind 1-events mit q-tags neben Likes, Reposts, Lesezeichen und zaps. Damit können Content-Ersteller Zitate in Inhaltsranglisten und Interaktionsdiagrammen sehen; der Nachweis beschränkt sich weiterhin auf den übernommenen Quellcode.

LaWallet NWC leitet Kartenaufladungen an die Karten-Wallet weiter

LaWallet NWC verbindet Lightning-Wallets über Nostr Wallet Connect mit Anwendungen. Seine übernommene Änderung für BoltCard-Aufladungen stellt einen LUD-19-Zahlungslink bereit, der über die NWC-Methode make_invoice der Karten-Wallet eine Rechnung erstellt. Gesperrte, deaktivierte oder nicht gekoppelte Karten stellen keinen Zahlungslink bereit, und der Pfad leitet Aufladungen nicht an die separate Lightning-Adresse des Eigentümers um. Eine Folgeänderung macht denselben Link im Emulator zugänglich und übermittelt bei LNURL-Sendungen vom Empfänger akzeptierte Mitteilungen des Zahlenden.

Ein neues khatru-relay macht Moderationsfunktionen für Eigentümer zugänglich

nostr-relay-khatru veröffentlichte seinen ersten Quellcode am 29. September als allgemeines relay, das aus der eingestellten HiveScope-spezifischen Implementierung abgeleitet wurde. Die öffentliche Instanz liefert ein NIP-11-Dokument aus, das dieses Repository nennt und Authentifizierung, event-Ablauf, geschützte events, Zählung, Abgleich und relay-Verwaltung als Funktionen ausweist. Eine Implementierung vom 30. September ergänzt Moderationsfunktionen im Eigentümerbereich. Die öffentlichen Metadaten bestätigen einen bereitgestellten Endpunkt, nicht die erfolgreiche Prüfung jeder ausgewiesenen Methode.

Ein lokales Tool zum Aufbau eines Vertrauensnetzes verfolgt Entfolgungen

etemiz/wot veröffentlichte am 30. September einen Nostr-Crawler für Vertrauensnetze. Er liest Follow-Listen und NIP-65-relay-Listen, berechnet Vertrauen anhand konfigurierbarer Ausgangspunkte und schreibt Bewertungen für relay-Richtlinien, Feeds und Spamfilter in LMDB. Die Projektdokumentation erläutert den Kompromiss: Live-Updates erhöhen das Vertrauen, während geplante vollständige Crawls Verringerungen und Entfolgungen berücksichtigen. Die Bewertungen hängen von den gewählten Ausgangspunkten ab. Es handelt sich um neu veröffentlichten Quellcode, ohne ein mit einem tag versehenes Release oder die Behauptung eines produktiven Einsatzes.

Moyu veröffentlicht einen Marmot-Workspace-Client

Moyu hat den Quellcode eines auf Marmot aufgebauten Rust-Workspace-Chat-Clients mit Kommandozeilen-, Terminal- und Desktop-Oberflächen veröffentlicht. Seine Änderungen vom 30. September nutzen lokal aufgezeichnete Mitgliedschaftsänderungen, um zu verhindern, dass alte Beitrittsanfragen entfernte Mitglieder wieder aufnehmen, lassen Einladungscodes nach sieben Tagen ablaufen und ermöglichen Administratoren, sie zu widerrufen. Die Terminalausgabe filtert von anderen Mitgliedern gelieferte Steuerzeichen und Überschreibungen der Textrichtung. Ein auf einen festen Stand gesetzter MDK-Fork leitet Blossom-Anhangsübertragungen durch den konfigurierten SOCKS5-Proxy, wobei die Auflösung von Hostnamen durch diesen Proxy erfolgt. Die Änderungen für 0.3.0 sind im öffentlichen Quellcode enthalten; ein öffentlicher Release-tag oder Release-Eintrag ist noch nicht verfügbar.

Arbeiten an Protokoll und Spezifikationen

NIP-39 erweitert Identitätsnachweise um Bluesky und Discord

NIP-39 ermöglicht es einem Nostr-Konto, auf einen Nachweis zu verweisen, dass es eine Identität auf einer anderen Plattform kontrolliert. Eine am 27. September übernommene Änderung gibt für neue Nachweise einen empfohlenen Satz vor und weist Prüfende an, ältere Nachweise zu akzeptieren, die die npub des Kontos enthalten, auch wenn ihr Wortlaut abweicht. Sie dokumentiert außerdem Bluesky-Beiträge und Discord-Nachrichten als Orte für Nachweise. Eine Discord-Behauptung kann nur von jemandem überprüft werden, der den Server lesen kann, auf dem die zugehörige Nachricht veröffentlicht wurde.

NIP-86 ergänzt die Verwaltung von Einladungscodes für relay-Administratoren

Compass beschrieb in der Ausgabe vom 8. Juli den NIP-86-Einladungsvorschlag, als er noch offen war; inzwischen wurde er übernommen. NIP-86 definiert eine standardisierte API zur relay-Verwaltung, und NIP-43 definiert, wie zugangsbeschränkte relays die Mitgliedschaft bekannt geben und Aufnahmeanfragen verarbeiten. Die am 24. September übernommene Änderung ergänzt listclaims, createclaim und deleteclaim, damit ein Administrator von einem relay akzeptierte Einladungscodes auflisten, ausstellen und widerrufen kann. Damit erhalten Betreiber einen Verwaltungsweg für Einladungen, die einem Mitglied nach dem Beitritt eine Rolle gewähren können; es wird nicht verlangt, dass jedes relay die Methoden unterstützt.

Eine Korrektur zur NIP-86-Berichterstattung der vergangenen Woche: Die übernommene Spezifikation ergänzte unallowevent, unbanevent, listallowedevents und listdisallowedkinds. Der frühere Beitrag führte Namen aus einer veralteten Vorschlagsbeschreibung auf. Die ersten beiden Methoden machen eine Zulassungs- oder Sperrentscheidung auf event-Ebene rückgängig; die anderen dienen der Einsicht in zugelassene events und unzulässige kinds.

NIP-51 verschiebt favorisierte Follow-Sets auf ein ungenutztes event-kind

NIP-51 definiert öffentliche und private Listen, darunter eine Liste der favorisierten Follow-Sets eines Nutzers. Compass beschrieb den Vorschlag zur kind-Kollision in der Ausgabe vom 22. Juli; inzwischen wurde er übernommen. Die Korrektur vom 27. September weist dieser Favoritenliste kind 10021 zu, weil die frühere Nummer bereits verwendet wurde. Ihre a-tags verweisen weiterhin auf Follow-Sets mit kind 30000. Die Änderung löst eine Nummernkollision in der Spezifikation; sie schafft keine neue Möglichkeit, Personen zu folgen.

NIP-51 schlägt ausgeblendete Antworten für jeden Thread vor

Ein offener NIP-51-Vorschlag würde es dem Autor eines Threads ermöglichen, eine öffentliche Menge ausgeblendeter Antworten zu veröffentlichen, die unterstützende Clients hinter einem Umschalter anzeigen. Er verwendet pro Thread ein adressierbares event des kind-30027, mit der ID des Ausgangsbeitrags als d tag und e tags, die Antworten benennen; nur eine vom Autor des Ausgangsbeitrags signierte Menge gilt. Die Aufnahme des Ausgangsbeitrags in die Liste fordert Clients auf, Antworten anderer Autoren auszublenden und keinen Antworteditor mehr anzubieten, während Antworten weiterhin auf relays veröffentlicht werden können. Das Format pro Thread begrenzt Bearbeitungskonflikte auf dieselbe Unterhaltung. Der Autor berichtet von einer Implementierung in Nostrich, doch die Prüfung öffentlicher Quellen konnte diese nicht belegen; der Vorschlag ist weiterhin nicht zusammengeführt, und sein Mengenformat wird noch diskutiert.

NIP-DB schlägt verifizierte Domainnamen für schlüsseladressierte Dienste vor

Der offene NIP-DB-Vorschlag, eingereicht am 28. September, beschreibt Nostr-events, die eine gewöhnliche Internetdomain an den Schlüssel binden, der sie über ein schlüsseladressiertes Netzwerk wie FIPS bereitstellt, ein verschlüsseltes Mesh-Netzwerk, das Knoten anhand ihres öffentlichen Nostr-Schlüssels adressiert. Ein Domaininhaber kann die Bindung mit einem DNS-TXT-Eintrag oder einem zusammen mit der Behauptung übermittelten DNSSEC-Nachweis herstellen; Clients würden ein verifiziertes Ergebnis für die spätere Offline-Nutzung festhalten. Der Vorschlag untersagt ausdrücklich die Auflösung über eine nicht verifizierte Behauptung, da jeder in einem Nostr-event die Domain eines anderen für sich beanspruchen kann. fips-pub-domains ist die Referenzimplementierung des Autors, doch die event-kind-Nummern und einige Overlay-spezifische Formulierungen werden noch geprüft. Die gemeldeten Ende-zu-Ende-Tests sind die Belege des Autors, keine Behauptung, dass der Vorschlag ein akzeptiertes NIP ist.

Ein Entwurf für private Feeds untersucht verschlüsselte Empfängergruppen

Ein neuer Vorschlag für Umschläge mit mehreren Empfängern, eröffnet am 29. September, skizziert private Notizen, Antworten und Verbindungen, deren vorgesehene Empfänger ein event finden können, ohne ihre gewöhnlichen öffentlichen Schlüssel in dessen sichtbaren tags offenzulegen. Er schlägt undurchsichtige paarweise Alias-tags vor, die aus gemeinsamen Geheimnissen abgeleitet werden, sowie vorläufige event-kinds, einschließlich einer Möglichkeit, ein anderes Nostr-event für Hunderte von Lesern einzuhüllen. Das könnte kleinen privaten Feeds einen direkteren Abrufweg bieten, als jedem Mitglied eine separate Nachricht zu senden.

Der Autor des Vorschlags bezeichnet dies ausdrücklich als laufende Arbeit. Für den Entwurf gibt es weder eine nachgewiesene Implementierung noch eine Sicherheitsprüfung, und seine kind-Zuweisungen und Signaturregeln auf Byte-Ebene sind weiterhin offen.

Ein Blossom-Vorschlag lässt andere Personen gespiegelte Medien ankündigen

Ein offener NIP-Vorschlag beschreibt eine Möglichkeit für jemanden, der den Blossom-Blob eines anderen Autors spiegelt, diese Kopie über Nostr anzukündigen. Ein Client könnte dann nach der Kopie suchen, wenn der ursprüngliche Server den Blob verliert. In der Diskussion wurde außerdem angesprochen, die aktuelle BUD-03-Serverliste des Spiegelanbieters zu prüfen, wenn ein angekündigter Serverhinweis veraltet ist. Dies ist ein vorgeschlagener Auffindungsweg, keine Garantie dafür, dass Clients oder Archiv-relays bereits Ersatzspeicher bereitstellen.

Meldungen zu Straßenereignissen streben ein gemeinsames Nostr-Format an

Der offene Vorschlag zu Road Event Reports beschreibt Meldungen und Bestätigungen zu Schlaglöchern, Sperrungen, Kameras und anderen Straßenbedingungen. Er verwendet Standort-tags und den Ablaufzeitstempel von NIP-40, der relays mitteilt, wann sie ein event nicht mehr bereitstellen sollen, sodass eine Meldung nicht unbegrenzt aktuell bleiben muss. Der Autor stützte Überarbeitungen auf eine Stichprobe von events, die aus öffentlichen relays abgerufen wurden, sowie auf die bestehenden Roadstr-Clients zur Meldung von Straßenbedingungen, doch der Entwurf lässt weiterhin eine Frage zur kompakten Kodierung offen, und die vorgeschlagene NIP-Nummer wurde nicht übernommen.

Marmot überarbeitet die Koordination mehrerer Geräte

Marmots Neuentwurf für mehrere Geräte ersetzt einen nicht implementierten External-Commit-Entwurf durch eine nicht normative Schritt-für-Schritt-Darstellung für frühe Rückmeldungen. Die neue Richtung untersucht, wie ein bestehendes Gerät ein neues genehmigt, es in Unterhaltungen aufnimmt und später Geräte entfernt, während offene Fragen sichtbar bleiben. Vom entfernten Entwurf reservierte IDs werden freigegeben, weil keine Implementierung sie übernommen hat. Das Ideendokument weist keine neuen IDs oder Übertragungsformate zu und ist keine implementierte Funktion für mehrere Geräte.

Sechs Jahre Nostr im September

Die letzte Septemberausgabe bietet Gelegenheit, nachzuzeichnen, wie sich Nostr von Skizzen zu einer größeren Sammlung interoperabler Werkzeuge entwickelt hat. Ein Prototyp zur Fahrtenvermittlung von 2021 nutzte signierte events, um einen Dienst zu koordinieren; fünf Jahre später gehören Formulierungen zum Identitätsnachweis und Kollisionen bei Listen-kinds zu den Details, die Maintainer klären. Dazwischen lernten Clients, Unterhaltungen, Medien und Wiederherstellung so darzustellen, dass gewöhnliche Menschen sie nutzen können. Die datierten Quellen unten zeigen Etappen dieser Entwicklung. Sie belegen weder, dass jedes Experiment an den Start ging, noch, dass jeder alte Entwurf weiterhin empfohlen wird.

September 2021: frühe Experimente mit nützlichen Formen

Ein BUber-Commit vom 4. September untersuchte ein Konzept zur Taxivermittlung mithilfe von Nostr-events. Er zeigte, wie eine signierte, über relays übermittelte Anfrage Menschen koordinieren konnte, ohne den gesamten Dienst einem einzigen Server zuzuweisen. Die Quelle ist ein Konzept und belegt keinen gestarteten Fahrdienst.

Später im selben Monat bot Loquaz’ Quellstand vom 23. September einen Desktop-Chat-Prototyp. Das war ein weiterer früher Versuch, relay-Nachrichten wie eine gewöhnliche Anwendung wirken zu lassen. Die Quelle belegt weder eine fertiggestellte Ende-zu-Ende-Verschlüsselung noch einen produktiv eingesetzten Messenger; der bleibende rote Faden ist die Suche nach einer brauchbaren Unterhaltungsoberfläche auf der Grundlage einfacher events. BUber erprobte die Fahrtenvermittlung und Loquaz den Chat; beide verwendeten signierte events, bevor sich gemeinsame Client-Muster etabliert hatten. Diese Versuche zeigten zwei wiederkehrende Probleme für spätere Clients auf: die Koordination über relays und die Darstellung von events als nutzbare Unterhaltung.

September 2022: Chat und delegierte Aktionen finden Eingang in die Spezifikationen

Die NIP-28-Änderung vom 10. September beschrieb öffentliche Chatkanäle mit Nachrichten und Metadaten, die Clients gemeinsam interpretieren konnten. NIP-28 machte einen gemeinsamen Raum zu einem ausdrücklichen Gegenstand des Protokolls und gab Clients eine gemeinsame Kanalkonvention.

Am 23. September dokumentierte NIP-26 im Text zum delegierten Signieren eine Möglichkeit, mit einem Schlüssel einen anderen zum Signieren begrenzter events zu autorisieren. Er hielt eine wichtige Entwurfsfrage von 2022 fest: Wie lässt sich eine Nostr-Identität nutzen, ohne jeder Anwendung den primären Schlüssel zu überlassen? NIP-26 ist inzwischen als nicht empfohlen gekennzeichnet, daher ist dies eine Dokumentation eines Experiments, kein Rat für neue Integrationen. Sein späterer Status zeigt, wie sich das Signaturmodell entwickelt hat: Eine Spezifikation kann eine nützliche Problemstellung bewahren, selbst wenn die vorgeschlagene Antwort außer Gebrauch genommen wird.

September 2023: Clients werden mit relay-Auffindung und Metadaten ausgereifter

Damus ist ein sozialer Nostr-Client. Sein Änderungsprotokoll vom 21. September dokumentierte Arbeiten an seiner lokalen Nostr-Datenbank, der Suche und der Hashtag-Navigation. Diese Änderungen erleichterten es, einen belebten sozialen Feed auf einem Telefon zu durchsuchen und wiederherzustellen; das datierte Änderungsprotokoll ist ein Beleg für diese Client-Veröffentlichung, nicht für jede spätere Funktion von Damus.

Auch die Protokolldetails entwickelten sich weiter. Eine Änderung vom 26. September an NIP-24 präzisierte optionale Profilmetadatenfelder, während sich die NIP-65-Änderung vom 29. September mit der Normalisierung und Deduplizierung von relay-URIs befasste. NIP-65 erklärt Clients, wie sie die relays veröffentlichen können, die sie zum Lesen und Schreiben verwenden; eine einheitliche Behandlung von URIs hilft diesen Listen, auf dasselbe relay zu verweisen, selbst wenn sich Zeichenfolgen auf harmlose Weise unterscheiden. Diese kleine Konvention lenkte den Client-Entwurf in Richtung zuverlässiger Auffindung: Um die events einer Person zu finden, muss man wissen, wo sie veröffentlicht werden.

September 2024: Beiträge erhalten reichhaltigeren Kontext

Die Versionshinweise von Damus vom 22. September beschrieben die Unterstützung für Hervorhebungen und Kommentare nach NIP-84. NIP-84 gibt Lesern eine Möglichkeit, eine Passage aus längeren Texten zu zitieren und zu diskutieren. Die Arbeit am Client zeigt, wie aus einer Protokollidee etwas wurde, das Menschen beim Lesen nutzen konnten.

Unterdessen erhielt NIP-34 eine Änderung vom 20. September, die Betreffzeilen und Labels von Issues für die git-Zusammenarbeit über Nostr verfeinerte, und NIP-73 erhielt eine Änderung am selben Tag, die Kennungen für externe Inhalte verfeinerte. Dies sind separate Spezifikationsänderungen: Die eine hilft den Issues eines Repositorys, ihre Struktur zu bewahren, während die andere es einem event ermöglicht, auf Material außerhalb von Nostr zu verweisen. Beide erweitern die Bedeutung, die ein Client bewahren kann, wenn Inhalte zwischen Gemeinschaften, Repositorys und anderen Medien wandern.

September 2025: Zugriffskontrollen und Zahlungskontext werden präziser

Eine Überarbeitung von NIP-42 vom 6. September befasste sich mit der Authentifizierung mehrerer Nutzer an einem relay. NIP-42 ermöglicht es einem relay, einen Client aufzufordern, nachzuweisen, welcher Nostr-Schlüssel eine Anfrage stellt; die Aktualisierung war für Dienste relevant, die über dieselbe Verbindung mehr als ein authentifiziertes Konto bedienen.

Eine Aktualisierung von NIP-47 vom 15. September ergänzte Anfragen über Nostr Wallet Connect um optionale Zahlungsmetadaten. NIP-47 ermöglicht es einer App, eine Wallet über Nostr um die Ausführung von Aktionen zu bitten. Mehr Kontext kann eine Interaktion mit einer Wallet verständlich machen, doch die Metadaten können Angaben zur zahlenden Person offenlegen, weshalb Clients und Wallets sie weiterhin als sensibel behandeln müssen. Die Änderung veranschaulicht, dass die Arbeit an der Interoperabilität nun auch umfasste, was ein Empfänger erfahren kann, und nicht nur, ob eine Anfrage zugestellt werden kann.

September 2026: Interoperabilitätsdetails treffen auf öffentliche Identität

In diesem September wurde durch eine gemergte Änderung an NIP-51 der event kind für Follow-Sets geändert, um eine Kollision zu vermeiden. NIP-51 definiert Listen, die eine Person pflegen und teilen kann; eindeutige event kinds ermöglichen es Clients, einen Listentyp von einem anderen zu unterscheiden. Eine frühere Ausgabe von Compass behandelte den Vorschlag, während der Merge im September die Statusänderung darstellt.

Eine zweite gemergte Änderung an NIP-39 präzisierte den Nachweistext und ergänzte weitere Möglichkeiten, ein externes Konto mit einer Nostr-Identität zu verknüpfen. NIP-39 befasst sich mit überprüfbaren Identitätsbehauptungen, nicht mit einem zentralen Identitätsregister. Zusammengenommen zeigen die beiden Merges, dass sich die aktuelle Arbeit am Protokoll auf die kleinen Details konzentriert, die darüber entscheiden, ob unabhängige Clients dieselben Identitäts- und Listen-events korrekt interpretieren. Sie zeigen auch eine Verlagerung von der Erfindung neuer event-Kategorien hin zur Verringerung von Mehrdeutigkeit in bestehenden Kategorien.

Über diese sechs September hinweg zeigt sich eine Entwicklung vom Nachweis, dass ein signiertes event eine Anwendungsanfrage beschreiben kann, hin zur Frage, wie ein Client eine Behauptung über eine Person überprüft. Die alten Prototypen sind wichtig, weil sie die Fragen offenlegen, die spätere Spezifikationen und Clients beantworten mussten: wer signiert, wo ein event zu finden ist, was es bedeutet und wie jemand weiß, ob es vertrauenswürdig ist. Deshalb kann auch eine kleine, präzise Protokollkorrektur genauso wichtig sein wie eine neue Benutzeroberfläche.