Nostr Compass #30

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

Diese Woche: die [Marmot-Spezifikation ist in 42 Dateien als MDK übernommen gekennzeichnet, während MDK Versionen v0.9.0 bis v0.9.3 mit verschlüsselten Gruppen-Avataren, Unterstützung für externe Signierer und MarmotKit iOS- und Android-Bindings veröffentlicht. Mostro liefert Transport v2 auf NIP-44-Direktnachrichten mit Anti-Spam-Sperren und einem Koexistenzfenster sowohl in mostrod v0.18.0 als auch in Mobile v1.3.0. Bitchat 1.6.0 fügt NIP-13 Proof-of-Work zu geohash-Kanalnachrichten hinzu, ein opt-in Mesh-zu-Nostr-Gateway, das es einem online verbundenen Telefon ermöglicht, eine ganze Menge zu verlinken, Prekey-Bündel, transitive Verifizierung und von den Erstellern verwaltete verschlüsselte private Gruppen. Amber steuert Profilabonnements pro Konto, ruft NIP-65 relay Listen vor Profildaten ab und fügt eine Live-Tor Statusbenachrichtigung mit einer Neustartaktion hinzu. rust-nostr fügt NIP-40 expiration zu gift wrap und NIP-17 DM Buildern hinzu, verankert am zufällig generierten Zeitstempel des Wrappers. Amethyst fasst 43 PRs zur Negentropie-Synchronisationshärtung, NIP-50 Volltext-Suchinfrastruktur und event kinds für Nischenvertikale zusammen. Nostrord liefert v2.0.0 und v2.1.0 mit einem gefalteten relay-Pool, Zombie-WebSocket-Erkennung und einem vollständigen disk-first Cache-Naht. Ngit v2.6.2, Jumble v26.7.1, Applesauce Unterzeichner 6.2.2, Bray v1.33.0, Deepmarks 1.0.0, Bitcredit Kern v0.5.13, Coop Mobile v0.2.4, Granary v11.0, Nostr-relay v0.0.244, Manent v1.4.0, Routstrd v0.3.7, Nymchat 1.0.1, und 21Meetup 1.1.0 werden ebenfalls geliefert, und SafeBox markiert Phase 3 weitgehend abgeschlossen zusammen mit einem FreeBSD-Jail-Deployment-Runbook und einem OpenETR-Spin-off für elektronische übertragbare Dokumente. Das NIPs-Repository vereint eine NIP-51 und NIP-37 Namensangleichung und eröffnet fünf Vorschläge: NIP-AD Nostr Webadressen, NIP-86 Einladungscode-Anspruchsverwaltung, ein HSL-Rollenfarbformat, NIP-80 hardware-bestätigte Medienherkunft, und ein Seitenzahlen-Fix in NIP-01. Tiefgehende Analysen behandeln NIP-13 (proof-of-work) und NIP-40 (expiration Zeitstempel).

Leitgeschichten

Marmot markiert die angenommene Spezifikation und MDK schneidet v0.9.x

Das Marmot Protokoll-Repository hat am 3. Juli PR #170 zusammengeführt und dabei 42 Dateien von Status: draft for internal review (und experimental draft) zu Status: adopted geändert. Der README-Titel wurde von der Darstellung des Repos als ein laufendes Projekt zu „Marmot Protocol“ als übernommenem Text geändert, die MIP-era-Dokumente wurden als veraltete Version des Protokolls neu dargestellt, und der Abschnitt „Review Status“ („Dies ist noch kein übernommener Spezifikationstext“) wurde zu „Review Guidance“ für die Bearbeitung der aktuellen Spezifikation. Das v2-Label verschwindet überall: Die Formulierung von MIP-contrast („neu in v2“, „die v2-Spezifikation behält“) wird durch „diese Spezifikation“ und „unter dieser Spezifikation“ ersetzt. Zwei Dokumente behalten ihren Entwurfsstatus absichtlich: implementation-model.md bleibt nicht normativ, und das eigene Dokument der Multi-Geräte-Funktion bleibt ein Entwurf.

Dasselbe Repository landete PR #171, das die Invarianten von Admin-Richtlinie, Mitgliedschaft und Rollenänderung angleicht. Die komponentenübergreifende Prüfung, dass ein Entfernen keinen Admin isolieren kann, wird jetzt als Eigenschaft jedes resultierenden Epochenzustands angegeben und wird gegen die Admin-Menge der vorherigen Epoche bewertet, wenn ein Commit kein Update der Admin-Richtlinie enthält. Die Kandidaten-Branch-Regel von Convergence wurde verschärft, sodass “validiert” die vollständige Gültigkeit des Commits einschließlich der Überprüfungen der resultierenden Epoche über verschiedene Komponenten hinweg bedeutet, was verhindert, dass ein invariantverletzender Commit einen Kandidaten-Edge auf einem beliebigen Branch erzeugt. Statusbenachrichtigungen, die von einem abgelösten Commit abgeleitet wurden, MÜSSEN zurückgezogen werden, wenn die Branch-Auswahl ihn ersetzt, was den Fehler „Verlierender Umbenennungsvorgang wird als erfolgreiche Systemmeldung dargestellt“ auf Spezifikationsebene schließt. Ein neuer Abschnitt „Entfernung realisieren“ in member-departure.md definiert den primären Realisierungseingang (das akzeptierte kanonische Commit, das dein letztes Blatt entfernt) und die Fallback-Option für Clients, die das entfernte Commit nie angewendet haben: Authentifizierte Nachräumungsnachweise tauchen nun als SelfEvicted-Ergebnis mit Behalte-inaktiv-Semantik für die entfernte Gruppenkopie auf. PR #236 verschärfte dann die Draht-Grenzvalidierung, legte die Lebensdauerakzeptanz von KeyPackage auf 84 Tage zuzüglich einer einstündigen Abweichung fest, fügte eine Nostr-Tag-Kardinalitätstabelle für die Gruppe h, Geschenkverpackung p, Begrüßung e und relays sowie KeyPackage-Tags hinzu und stellte fest, dass nicht verifizierte Nostr event-IDs und Metadaten nicht als vertrauenswürdige Routing-, Wiederholungs- oder Telemetriebeweise gelten.

Flussabwärts wurde der MDK-Arbeitsbereich am 6. Juli mit einer vollständigen Versionsanhebung des Arbeitsbereichs auf v0.9.0 geschnitten, gefolgt von v0.9.1, v0.9.2 und v0.9.3 in den folgenden zwei Tagen. v0.9.0 rotiert veraltete Schlüsselringeinträge, wenn eine neue SQLite-Datenbank erstellt wird, und implementiert die validate-before-mutate-Disziplin über die Speicherebene. v0.9.1 leitet jede ausgehende Verbindung über einen einzigen Host-Sicherheits-Dial-Knotenpunkt über PR #732], wodurch die Klasse von Fehlern geschlossen wird, bei denen verschiedene Aufrufstellen das Netzwerk mit unterschiedlicher Validierung erreicht haben. v0.9.3 macht verschlüsselte Gruppen-Avatare über download_group_image und image_hash_hex durch PR #771] für die Uniffi-Bindungen zugänglich, fügt Unterstützung für externe Signierer hinzu und kennzeichnet wn-opencode über PR #781] als produktionsbereit. Neben den MDK-Schnitten liefert MarmotKit bei jeder Version iOS- und Android-Bindings aus (ein MarmotKit.xcframework plus Swift-Bindings für iOS und Kotlin-Bindings plus JNI-Bibliotheken für Android, beide aus einem festgelegten MDK-Commit-Hash generiert), und ein neuer wn-agent Release-Kanal stellt Shell-Installer bereit, die die WN Agent-Version auf ein unveränderliches Release-Tag festlegen, sodass nachgelagerte Apps den aktuellen Agent mit einem einzigen Abruf beziehen können curl Befehl.

Mostro v0.18.0 und Mobile v1.3.0 versenden Transport v2 auf NIP-44

Mostro ist das Peer-to-Peer-Bitcoin-Handelsprotokoll, das Orderbücher, Treuhand und Streitbeilegung über Nostr events betreibt, koordiniert von einem Daemon (mostrod), mit dem Clients über verschlüsselte DMs kommunizieren. Bis diese Woche war das Drahtprotokoll zwischen Clients und mostrod Transport v1. Mostro v0.18.0 landet Transport v2, verdrahtet das Protokoll auf NIP-44 Direktnachrichten mit Anti-Spam-Toren und Dual-Empfangs-Unterstützung auf Serverseite. PR #776 ist die Phasen-1-Kabeländerung, PR #780 fügt die Phasen-2-Anti-Spam-Tore für Protokoll v2 hinzu, und PR #785 lässt die innere Protokollversion dem aktiven Transport folgen, sodass ein v2-Client und ein v1-Client während des Migrationsfensters koexistieren können. Ein verwandter PR #782 behebt eine NIP-33-Info-Tag, indem protocol_versions auf die Singularform protocol_version umbenannt wird. Neben der Transportarbeit bringt das Release einen Phase-4-einheitlichen Live-Quote-Pfad mit Cache- und Veraltensüberwachung (PR #783) sowie einen El-Toque-Fiat-Cross-Anbieter, der die kubanischen CUP- und MLC-Paare abdeckt (PR #778). PR #779 fügt eine Benachrichtigung für bestrafte Parteien bei Streitfall-Strafen hinzu, sodass ein Benutzer, der seine Kaution verloren hat, direkt vom Daemon erfährt; das vorherige Verhalten trat nur als fehlender Wallet-Saldo auf.

Mostro Mobile v1.3.0 ist die Client-Seite der Migration. PR #613 migriert die App auf Riverpod 3.x, Phase A (PR #620) fügt Dual-Empfang-Unterstützung für NIP-44 Direktnachrichten im Haupt-Isolat und im Hintergrund-Isolat hinzu, sodass ein v2 mostrod und ein v1 Client während der Migration miteinander kommunizieren können, Phase B in PR #624 fügt Dual-Senden hinzu, PR #632 wendet Dual-Senden nach dem Riverpod 3.x Cut erneut an, und Phase C in PR #637 finalisiert die Migration. Die Veröffentlichung fügt auch die Abdeckung afrikanischer Zahlungsmethoden hinzu: PR #625 fügt Zahlungsmethoden für Malawi Kwacha hinzu und PR #627 fügt Methoden für KES (Kenia-Schilling), MZN (Mosambikanischer Metical), TZS (Tansania-Schilling), UGX (Uganda-Schilling), ZAR (Südafrikanischer Rand) und ZMW (Sambia-Kwacha) hinzu, während NGN (Nigerianischer Naira) erweitert wird. Ein Wiederherstellungsfluss wartet nun auf die Knotenverbindung, bevor Wiederherstellungsanforderungen ausgegeben werden, und ursachenbewusste Handhabung unterscheidet zwischen einem streitgesteuerten Bond-Slash und einem zeitüberschreitungsbedingten.

Bitchat 1.6.0 fügt NIP-13 proof-of-work und ein optionales Mesh-zu-Nostr-Gateway hinzu

Bitchat 1.6.0 ist die Bluetooth-Mesh-Chat-App, die Nostr für ihre geohash-Kanäle und DM-Übergabe verwendet. Das Release macht zwei Nostr-förmige Dinge, die es wert sind, gelesen zu werden. PR #1382 fügt NIP-13 (proof-of-work) zu ausgehenden geohash-Kanalnachrichten hinzu (kind 20000 ephemere events): Jeder sendet vor der Veröffentlichung ein ["nonce", "<value>", "<target>"]-Tag, das auf 8 führende Nullbits abzielt, was durchschnittlich 256 Hash-Versuche erfordert und auf einem M-Serie-Mac in unter einer Millisekunde abgeschlossen wird. Eingehende events mit validiertem PoW lockern das Aufnahmelimit pro Absender, sodass ein Spammer für jede Nachricht Rechenleistung bezahlt, während ein regulärer Absender die Kosten nicht spürt. Der Umfang ist bewusst eng gefasst: Nur kind 20000 Kanalnachrichten gehören mir PoW, und Anwesenheits-Heartbeats (kind 20001), kind-1 Standortnotizen und DMs bleiben unberührt.

PR #1384 fügt den Gateways-Modus hinzu, eine Opt-in-Mesh-zu-Nostr-Uplink für geohash-Kanäle. Wenn ein reiner Mesh-Benutzer (kein Internet, kein erreichbares relay) eine Nachricht in einem geohash-Kanal sendet und ein anderer Peer im Mesh die .gateway-Funktionalität bewirbt, wird das signierte kind 20000 event in einem neuen MessageType.nostrCarrier = 0x28 TLV-Umschlag verpackt und an ein Gateway direkt gesendet. Der Gateway-Peer veröffentlicht das event im Auftrag des Absenders an Nostr und sendet eingehenden Kanalverkehr mit dem Standard-TTL zurück ins Mesh. Uplinks nutzen den Kurierumschlagpfad (gerichtet, weitergeleitet über mehrere Hops); Downlinks nutzen Broadcast. Die Signatur erfolgt, bevor das event den Absender verlässt, sodass der Gateway entscheiden kann, ob veröffentlicht wird, aber die Zuschreibung nicht fälschen kann. Die angegebene Motivation sind Katastrophen- und Protestszenarien, in denen ein verbundenes Telefon in einer Menschenmenge ausreicht, um dem gesamten geohash-Kanal einen funktionierenden Nostr-Uplink zu geben.

Die gleiche Veröffentlichung liefert eine zweite Charge von Nostr-naher Arbeit. PR #1381 fügt Prekey-Bündel für vorwärtsgeheimes asynchrones Erstkontakt auf dem Kurier-Mail-Pfad hinzu, sodass ein Absender eine Nachricht an einen Offline-Peer verfassen und sie dem Mesh übergeben kann, ohne zuvor ein Live-Noise-Handshake durchgeführt zu haben. PR #1380 fügt transitive Verifikation hinzu: Ein Peer, der das Noise-Handshake mit jemandem abgeschlossen hat, den Sie bereits verifiziert haben, ist jetzt über die Noise-Sitzung empfohlen, sodass das Vertrauensnetzwerk einen Schritt auf einmal verbreitet wird, anstatt für jeden neuen Kontakt eine neue persönliche Verifizierung zu erfordern. PR #1383 fügt von Erstellern verwaltete verschlüsselte private Gruppen über das Mesh hinzu, PR #1376 erkennt, rendert und löst Cashu Ecash-Token mit einem /pay-Befehl ein, und PR #1379 fügt ein persistentes signiertes geohash-Blackboard hinzu, das auf Mesh-Synchronisierung basiert. PR #1372 erweitert Store-and-Forward mit offenen Kuriere, Spray-and-Wait-Routing, einem persistenten Postausgang und einem sechs Stunden langen öffentlichen Verlauf. Bitchat 1.5.4 wurde früher in der Woche mit der End-to-End-Favoritenbehebung in PR #1367, die Duplikate in der Peer-Liste bereinigt, Nostr-Synchronisation und /fav-Schlüsselkorruption liefert, ausgeliefert.

Getaggte Releases

Amber v6.2.3 legt Profile-Abonnements fest und fügt eine Tor-Statusbenachrichtigung hinzu

Amber v6.2.3 ist ein Leistungs- und Korrekturdurchgang beim Android NIP-46 Signer, und die in der Woche darum zusammengeführten PRs deuten auf ein zusammenhängendes Thema hin. Das Release selbst fügt eine konfigurierbare Einstellung für das Abrufen von Profilen mit den Optionen nie und immer hinzu (PR #492]), zeigt ein Profilbild im Account-Wechsel-Bottom-Sheet an und begrenzt Profilabonnements auf das aktuelle Konto, sodass ein Signierer, der mehrere Konten besitzt, keine Abonnements für Konten verteilt, mit denen der Benutzer derzeit nicht signiert. Das Parsen von Bunker-Berechtigungen erhält eine explizite Fehlerbehandlung bei Parsing-Fehlern. Mehrere StrictMode-Verstöße wurden behoben: ein DiskReadViolation durch Coils onSuccess Logging, ein Keystore-Verstoß beim Laden des Kontos im Hauptthread, Lesevorgänge des Kontonamens und Bildes im Hauptthread im Kontowechselblatt, und das eifrige KeyPair()-Konstrukt auf den Anmelde- und Registrierungsbildschirmen wurde jetzt vom Hauptthread verschoben. In den Tagen nach der Freigabe von v6.2.3 hat PR #493 den Bootpfad so umgeordnet, dass die Benutzer-NIP-65 relay-Liste vor den Profildaten abgerufen wird (damit die Profilabfrage die von dem Benutzer veröffentlichten relays abruft), und PR #494 hat die integrierte Tor-Benachrichtigung in eine Live-Statusanzeige mit einer Neustartaktion umgewandelt, sodass ein Benutzer, dessen Tor-Daemon während einer Signiersitzung abstürzt, das Scheitern sieht und Springe es, ohne den Unterzeichner zu verlassen. PR #495 hat Android Lint im strikten Warnungen-als-Fehler-Modus im gesamten Codebestand aktiviert.

Jumble v26.7.1 macht Blossom zum Standard-Upload-Dienst in einem auf DM fokussierten Schnitt

Jumble v26.7.1 ist ein Nostr Web-Client, der auf Direktnachrichten und Medien ausgerichtet ist. Die Veröffentlichung gestaltet die Einstellungen für Medien-Uploads neu und macht Blossom zum Standard-Upload-Dienst, der den vorherigen NIP-96-Standard ersetzt. DM-Verarbeitung erhält ein mobiles Nachrichtenmenü, verbesserte Desktop-Nachrichtenaktionen, eine „Zum neuesten scrollen“-Taste, Langzeitdruckreaktionen auf DM-Medien und einen Wiederholungsweg für fehlgeschlagene ausgehende DMs aus der Nachrichtenliste. Die Bearbeitung benutzerdefinierter Emojis erhält eine Detailansicht, die Größenanpassung der Nachrichtenblasen wird für Rechnungen und eingebettete Inhalte verbessert, mehrere DM-Scroll- und Nachrichtenanordnungsprobleme werden behoben, und Probleme nach der Bearbeitung im Zusammenhang mit Emoji-Einfügung, Textkopie und Dateizug ziehen werden bereinigt. Die Bildorientierung wird korrigiert, wenn beim Hochladen Metadaten entfernt werden, und Linux ARM64-Downloads werden zur Release-Matrix hinzugefügt.

Applesauce-Unterzeichner 6.2.2 entfernt eine nbunksec-Abhängigkeit

applesauce-signers@6.2.2 lässt die @sandwichfarm/encoded-entities-Abhängigkeit des Unterpakets zugunsten eines eingebauten nbunksec-Helfers über Commit d654349 fallen. Die NIP-46-Bunker-Session-Verschlüsselung von Applesauce, die letzte Woche hinzugefügt wurde, benötigt die externe Verschlüsselungsbibliothek nicht mehr, wodurch eine Angriffsfläche in der Lieferkette für nachgelagerte Clients, die das Signers-Paket verwenden, reduziert wird.

Ngit v2.6.2 stoppt doppelten PR-Status events beim Push auf den Standard-Branch

Ngit v2.6.2 ist eine Fehlerbehebungs-Version für das git-over-Nostr CLI. git push zum Standard-Branch stoppt die Veröffentlichung doppelter PR-Merge/angewandter Status events für PRs, die bereits als angewandt markiert sind, da die Merge-Erkennung jetzt den Pre-Push-Zustand des Nostr-Repos (die Quelle der Wahrheit dafür, ob ein PR bereits auf der NIP-34-Seite des Workflows gelöst wurde) liest. Die vorherige Heuristik basierte auf Git-Interna und duplizierte den Status event. Aktive Repositories, die ngit für Git-over-Nostr Push-Flows verwenden, hören auf, den doppelten kind-1621 Status events in ihr Publikum zu senden.

Bray v1.33.0 CLI übernimmt ein Bunkerprofil, Persona, und Tor ausgehend

Bray v1.33.0 ist eine Nostr SDK-plus-CLI Veröffentlichung. bunker --profile <name> erhält einen automatisch stabilen Verbindungsschlüssel und relay-Fallback, sodass ein gespeichertes Profil einen relay-Ausfall überstehen kann; bunker --persona <name> signiert als abgeleitete nsec-Baum-Identität, wodurch ein Unterzeichner als mehrere pubkeys aus einem einzigen abgeleiteten Baum agieren kann; und alle HTTP-Abfragen können durch einen Tor SOCKS-Proxy geleitet werden, wenn konfiguriert. Die Veröffentlichung fügt Wallet-Unterbefehle für NIP-47 NWC, NIP-29 Gruppen-Admin-Schreiboperationen (erstellen, aktualisieren, Benutzer hinzufügen, Benutzer entfernen, Rollen festlegen), NIP-86 Admin-Verben und NIP-65 Outbox-Helfer hinzu. Veröffentlichungs-Verben übernehmen --jsonl-, --csv- und --tsv-Ausgabe-Flags, ein req-Verb für generische NIP-01-Filterabfragen, ein event-Verb für beliebige event-Konstruktionen, einen publish-raw-Befehl, der vorgefertigte events signiert und überträgt, einen bunker sign einmaligen NIP-46-Signaturbefehl und ein pro Befehl --relay-Flag bei jedem Veröffentlichungsbefehl. Die Sicherheitsarbeit umfasst drei Chargen von Prüfungsaufschüben: geheime Nullstellungs-Disziplin, HTTP-Transport-Bearer-auth und Rate-Limit-Härtung sowie SSRF-Validierung auf relay-URLs. Das npm-Tarball wird mit 533.844 Bytes geliefert und ein byte-identischer reproduzierbarer Build wurde über zwei unabhängige CI-Runner überprüft.

Deepmarks 1.0.0 härtet die Nostr-Lesezeichenoberfläche

Deepmarks 1.0.0 ist ein Sicherheits-Härtungs-1.0-Meilenstein für einen öffentlichen Nostr-Lesezeichenservice. Jedes Lesezeichen ist immer noch ein signiertes Nostr event, das jeder Client lesen kann. Die API- und Archivarbeiter sitzen in einer privilegierten Netzwerkposition (sie können das interne Redis, den relay-Pfad des Bunkers und die Cloud-Metadaten erreichen), sodass der SSRF-Wächter lasttragend ist, und das Release behebt eine kritische IPv6-literal-Umgehung in isPrivateIp: In Klammern gesetzte IPv6-Literale wurden als öffentlich klassifiziert, sodass [::1], [fd00::1] und IPv4-zugeordnete [::ffff:10.0.0.4] alle interne Ziele über Dual-Stack-Verbindungen erreichten. Der Schutz entfernt nun die Klammern und reduziert IPv4-zugeordnete und IPv4-kompatible IPv6 auf das eingebettete v4, bevor die Private-Range-Prüfung auf beiden Systemen erfolgt. Ingestierte kind:0-Profile von externen relays werden nun am Ziel signaturgeprüft, sodass ein feindlicher relay kein nip05 oder lud16 für ein beliebiges Opfer-pubkey fälschen kann, und Lesezeichen-URLs werden an jedem Rendering-Ziel schematisch überprüft, sodass ein kind:39701-Lesezeichen, das direkt mit einem javascript:- oder data:-d-Tag an das relay veröffentlicht wird, kein <a href> erreicht. Zap-Belege überstehen nun einen vorübergehenden Bunker-Ausfall: Der Abwicklungsbearbeiter fordert das ausstehende Zap atomar an, schließt es erst nach erfolgreicher Unterzeichnung ab und gibt die Anforderung bei einem Fehlschlag frei, sodass ein erneut zugestelltes invoice_updated erneut versucht werden kann. Die /publish-Fan-out-Entwässerung verwendet BLMOVE in einer pro-Arbeiter-Verarbeitungsliste mit herzschlaggesteuerter Wiederherstellung, sodass ein abgestürzter Arbeiter ein unterschriebenes event beibehält, für das der Client bereits 202 erhalten hatte.

Bitcredit Core v0.5.13 entschlüsselt Block-Metadaten auf dem Nostr-Draht

Bitcredit Core v0.5.13 entfernt eine Verschlüsselungsschicht von dem Nostr öffentlichen events, der vom Kreditabrechnungsprotokoll verwendet wird. Block-Metadaten (Block-ID, Hash, Signatur) sind nun unverschlüsselt auf der Nostr-Leitung; nur die Blockdaten selbst bleiben mit dem entsprechenden Abrechnungsschlüssel verschlüsselt. Neue Apps verarbeiten alte Ketten, alte Apps verarbeiten keine neuen Ketten. Die Veröffentlichung fügt auch eine Rechnung-Service-Funktion hinzu, um die Rechnungskette abzurufen, und wechselt das Veröffentlichen zu einem optimistischen Schwellenwertmodell: Sobald ein konfigurierter relay-Schwellenwert (Standardwert eins) eine Veröffentlichung akzeptiert, erhalten die verbleibenden relays das event asynchron, sodass das Veröffentlichen nicht mehr durch die langsamste relay blockiert wird.

Coop Mobile v0.2.3 und v0.2.4

Coop Mobile wurde am 4. Juli v0.2.3] und am 7. Juli v0.2.4] ausgeliefert, wodurch die stetige Veröffentlichungsfrequenz des Android-NIP-17] Direct-Messaging-Clients fortgesetzt wird. v0.2.3 fügt Inline-Bild- und Linkanzeige in Chatnachrichten, Bildanhänge, Sprache-zu-Text-Eingabe und einen Bestätigungsdialog für das Entfernen von Kontakten hinzu. v0.2.4 behebt einen Indikator, der für immer hängen geblieben ist, verbessert das Nostr Connect-Handshaking und fügt den ncryptsec1-Import (das NIP-49 verschlüsselte-private-Schlüssel-Format) zusammen mit einem neu gestalteten Import-Identitätsbildschirm hinzu.

Granary v11.0 fügt NIP-71 Video event Unterstützung hinzu

Granary v11.0 ist die Multi-Protokoll-Konvertierungsbibliothek, die Bridgy Feds plattformübergreifende Verbindung antreibt. Das Nostr-Modul erhält drei sichtbare Änderungen.] NIP-71 Video events (kinds 21, 22, 34235 und 34236) wird jetzt in ActivityStreams 1 Notizen mit Videoanhängen konvertiert, und der Konverter extrahiert das imeta Bild (Miniaturansicht), die Videodauer, das obere published_at Tag und das alt Tag als Fallback displayName beim ersten Video- oder Audioanhang. Auf der API Seite wird sign in hash_and_sign umbenannt und verify löst nun ValueError bei einem Fehler aus; Der Nostr-Konstruktor löst ValueError bei einer ungültigen relay-URL aus, und Nostr.query überspringt die NIP-42 AUTH-Herausforderung, wenn der Aufrufer kein privkey gesetzt hat, problemlos. Eine anschließende Konvertierungs-Korrektur verhindert Abstürze, wenn ein Nostr article-Objekt ohne id eintrifft. Jede Brücke oder jeder Leser, der NIP-71-Video-events über Granary verarbeitet, kann sie jetzt im Format anzeigen, das der Ziel-Leser erwartet.

Nostr-relay v0.0.244 fügt ein Firestore-Backend hinzu

mattn/nostr-relay v0.0.244 fügt ein Firestore-Backend über PR #12 hinzu und erweitert die Speicher-Ebene von Go relay mit einer Google Cloud Firestore-Option neben den bestehenden Backends. Die Änderung ist klein, eröffnet aber Firestore als verwaltete serverlose Datenbankoption für einen relay-Betreiber.

Manent v1.4.0 behebt NIP-42 AUTH und fügt Medien-Zwischenablage-Flows hinzu

Manent v1.4.0 ist die verschlüsselte Notizen- und Dateispeicher-App, die auf Nostr mit NIP-44-Verschlüsselung, NIP-46- und NIP-55-Signaturunterstützung, NIP-65-Outbox-Routing und Blossom-Speicher aufbaut. Das Update behebt NIP-42 relay-Authentifizierung (zuvor defekt), korrigiert Blossom-Uploads zu http://-Hosts (zuvor fehlerhaft behandelt) und schreibt den Komprimierungsablauf neu. Auf der Medienseite können Benutzer nun ein Bild in die Zwischenablage kopieren, ein Bild aus der Zwischenablage einfügen, Dateien per Drag & Drop verschieben, Bilder zuschneiden und drehen, Videos und GIFs abspielen und ein Video mit einem langen Druck auf das Kamerasymbol aufnehmen. Unter Linux ist die primäre Zwischenablage über einen mittleren Mausklick zugänglich. Das Laden von Notizen und das Scrollen erhalten mehrere Optimierungen.

Routstrd v0.3.7 macht, dass der Nostr event die persistente Quelle der Wahrheit speichert

Routstrd v0.3.7 ist der lokale Daemon für das Routstr dezentralisierte KI-Inferenznetzwerk, das LLM-Anfragen über Nostr kind 38421 Anbieterentdeckung und kind 38425 LGTM Bewertungen weiterleitet. Das Release fügt einen routstrd update Unterbefehl hinzu, der neue Binärdateien sowohl für routstrd als auch für cocod herunterlädt und laufende Daemons ordnungsgemäß neu startet; Der Daemon ruft jetzt refreshNostrEvents() beim Start und alle 21 Minuten auf, damit die Anbieterentdeckung und Bewertungen ohne manuelles Eingreifen aktuell bleiben. Das gebündelte @routstr/sdk wird von 0.3.12 auf 0.3.15 aktualisiert, entfernt die ProviderRegistry-Ebene zugunsten der direkten Nutzung von DiscoveryAdapter, bereinigt Modelle von verschwundenen Nostr-Anbietern, sodass sie nicht länger in Rankings durchscheinen, und behandelt den Nostr event Store als persistente Quelle der Wahrheit (die fehlerhafte 210-minütige TTL auf zwischengespeichertem events ist verschwunden). Die Xcashu-Rückerstattungsabwicklung wird verschärft: Rückerstattungstoken werden im Fehlerpfad vor den Originalen ausprobiert, 404s werden 3× mit zwei Minuten Abstand erneut versucht, und 425 Too Early wird behandelt, ohne eine Ausnahme zu werfen.

Nymchat 1.0.1 wird als Progressive Web App auf NIP-17 gestartet

Nymchat 1.0.1 (auch bekannt als NYM, Nostr Ynstant Messenger) ist eine Progressive Web App und ein nativer iOS/Android-Messenger für flüchtige Chats über Nostr, verbunden mit Bitchat. Kanäle verwenden kind 20000 flüchtige events für geohash-Kanäle und kind 23333 für benannte Kanäle; Private Nachrichten und Gruppenchats werden NIP-17, geschenkverpackt events (kind 1059) mit rotierenden flüchtigen Empfängerschlüsseln und automatischer Wiederherstellung nach der Kompromittierung. Benutzer können ein pro Sitzung ein ephemeres Tastatur ohne Registrierung erstellen oder sich mit einer persistenten Identität über NIP-07-Browsererweiterungen, einen NIP-46-Remote-Unterzeichner] oder einen nsec anmelden. Optionale geräteinterne Identitätsverschlüsselung verwendet Passwort, PIN, Passkey oder biometrische Entsperrung über WebAuthn PRF (Passkey und biometrisch) oder PBKDF2 (Passwort und PIN), wobei der Klartextschlüssel niemals auf die Festplatte geschrieben wird, solange die Verschlüsselung aktiv ist. Sprach- und Videoanrufe verwenden NIP-17 gift wraps für Signalisierung und WebRTC für den Medienpfad. Nachrichtenreaktionen verwenden NIP-25, benutzerdefinierte Emojis verwenden NIP-30, und die Webanwendung wird als statische Dateien bereitgestellt, plus Cloudflare Pages-Funktionen, die als Datenschutz-Proxy für relays und Medien fungieren.

21Meetup 1.1.0 bringt Nostr-signierte Anwesenheitsausweise auf den Markt

21Meetup 1.1.0 ist eine Flutter-App für die deutsche Einundzwanzig-Bitcoin-Community, die die Teilnahme an Meetups über NFC-Tags und rotierende QR-Codes aufzeichnet. Jedes Teilnahme-Abzeichen ist ein Nostr event (kind 21000), das vom Meetup-Organisator unter Verwendung von BIP-340 Schnorr signiert wird, sodass ein Teilnehmer eine Reihe von signierten events sammelt, die bestimmte Meetups zu bestimmten Blockhöhen attestieren. Der rollende QR-Code rotiert alle 10 Sekunden, sodass ein Abzeichen nicht aus der Ferne erstellt werden kann, und das NFC-Tag ist nur in physischer Nähe lesbar. Ein Vertrauenswert wird lokal aus den gesammelten Abzeichen berechnet; der Wert kann als QR-Code zur Überprüfung bei Peer-to-Peer-Handel präsentiert werden. Die App richtet sich auf den Ruf der Bitcoin-Community, nicht auf allgemeine Nostr soziale Zwecke, aber die Abzeichen events selbst sind gewöhnliche Nostr events, die jeder Leser überprüfen kann.

Nostrord v2.0.0 und v2.1.0 falten den relay-Pool und heilen den Zombie WebSockets

Nostrord v2.0.0 ist ein wichtiger Ableger des KMP/WASM Nostr-Clients, der NIP-29, NIP-42, NIP-44, NIP-46, NIP-57, NIP-65 und NIP-98 unterstützt. v2.0.1 wurde einen Tag später über PR #166 mit einem release-blockierenden Desktop-Fix veröffentlicht: Das verpackte 2.0.0 (deb, rpm, msi, dmg) ist beim Start mit NoClassDefFoundError: java/sql/DriverManager abgestürzt, weil das jpackage jlink-Image das java.sql-Modul vermisste, von dem der SQLDelight sqlite-Treiber abhängt; Das Update fügt java.sql zum Laufzeit-Image hinzu, und derselbe PR leitet den optimistischen Versand über die Netzwerkschicht, sodass die Nachricht relay erreicht (der vorherige Codepfad speicherte stillschweigend zwischen und wurde nie zugestellt), außerdem Tastatur- und Scroll-Verhalten im mobilen Web.

v2.1.0 folgte am 7. Juli mit der “relay Pool-Zusammenlegung” (PR #176), die die zuvor separate, auf NIP-29 ausgerichtete relay-Buchse in den gemeinsamen Pool integriert. Ein Reconnect-Planer deckt jetzt alle relays ab, NIP-42 AUTH-Signaturen sind mit Wiederholungen begrenzt, veröffentlicht bei Fehler geschlossen und wiederholt bei auth erforderlich, Request-Sturm-Rennen in requestPrivateGroupData und fetchGroupPreviews sind geschlossen, kind-10009 Benutzergruppenlisten werden pro relay in Stapeln abgefragt, und das mux_chat Live-Abonnement deckt jetzt jede beigetretene Gruppe ab (nicht nur die geöffnete) und heilt sich selbst, wenn ein relay stillschweigend abbricht Abonnement. UI-seitige Änderungen ersetzen die layoutverschiebende „Senden…“-Zeile durch ein Inline-Uhr-dann-Haken-Symbol und verwandeln festgefahrenes Scroll-Back in eine explizite Wiederholungszeile. PR #179 wurde am selben Tag eingebracht, um das Zombie WebSockets auf Android zu erkennen: Mobile Netzwerke und der Doze-Modus töten TCP ohne ein Close-Frame, sodass Schreibvorgänge in den toten Socket-Buffer lokal erfolgen, ohne eine Ausnahme auszulösen, und isConnected() bleibt wahr, obwohl niemals etwas empfangen wird. NostrGroupClient stempelt jetzt lastInboundAtMs auf jeden Frame, erhält markDead() (was die Frame-Schleife abbricht, sodass der normale Wiederverbindungs- und erneute Abonnierpfad ausgeführt wird) und probeLiveness() (ein REQ, das jedes relay innerhalb von 5 Sekunden beantworten muss), ausgelöst bei OK-Timeout ohne eingehende Frames oder bei veralteten Mux plus keine Socket-Frames. Ein zweiter Bugfix im selben PR verhindert, dass optimistische Nachrichten beim Einfügen in den persistierenden Cache geschrieben werden; Sie schreiben jetzt nur noch nach Lieferbestätigung. v2.1.1 wurde einen Tag später über PR #178 versendet, wobei iOS-Plattformdaten, native Testunterstützung und App-Symbole zusammen mit der v2.1.0 Zombie-WebSocket-Arbeit hinzugefügt wurden.

Nicht veröffentlichte Änderungen

rust-nostr fügt NIP-40 expiration zu gift wrap und privaten DM-Erstellern hinzu

rust-nostr zusammengeführter PR #1384 fügt eine expiration-Option zu GiftWrapBuilder und PrivateDirectMessageBuilder hinzu. Die Bibliothek nimmt einen Duration vom Aufrufer: das NIP-40 expiration-Tag ist an den randomisierten created_at des gift wrap (created_at + Dauer) gebunden, wodurch es vom tatsächlichen Sendezeitpunkt entkoppelt wird. Wenn ein Anrufer einen absoluten Zeitstempel übergibt, würde dies die Sendezeit für einen relay-Beobachter preisgeben (ziehen Sie die Dauer ab, und Sie erhalten die ursprüngliche Sendezeit zurück), daher erstellt die Bibliothek das Tag intern aus dem zufällig gewählten Wrap-Zeitstempel. Das expiration-Tag wird auf dem gift wrap event angebracht, nicht auf dem kind:13-Siegel (das laut NIP-59] leere Tags haben muss). NIP-17 gibt denselben Wert an den gift wrap-Builder von PrivateDirectMessageBuilder weiter. Die Änderung schließt Issue #1381 und wird über dasselbe Builder-Muster wie rust-nostr für extra_tags übernommen. rust-nostr hat auch PR #1387 zusammengeführt und nostr-relay-builder in nostr-sdk konsolidiert, eine Maßnahme zur Vereinfachung des Arbeitsbereichs.

Amethyst verbringt die Woche damit, die Negentropie-Synchronisation zu verstärken und NIP-50-Suche hinzuzufügen

Amethyst’s Hauptzweig hat 43 PRs über drei zusammenhängende Themen zusammengeführt. Der größte Strang ist die Negentropie-Synchronisation an der geode-zu-strfry-Grenze: Ein verweigerter Fenster-Fehlermodus, der früher den Client in eine Fenster-Split-Schleife gezwungen hat, fährt jetzt sauber zurück (PR #3480), die zugrunde liegende negentropyKmp-Abhängigkeit geht auf v1.1.1 (PR #3475), ein 1-Million-event-Geode-zu-strfry-Benchmark landet mit einem strfry-Paritäts-Spiegel (PR #3478), und Produktions-Benchmarks treten neben erweiterten Synchronisationsoptimierungen in die CI-Matrix ein (PR #3458, PR #3466). Lock-freie nebenläufige Sammlungen ersetzen das vorherige Mutex-pro-relay-Muster und eine UDP-Socket-Threading-Fix wird mitgeliefert (PR #3459).

Der zweite Thread ist NIP-50 Volltext-Suchinfrastruktur. Eine SearchableEvent-Schnittstelle wird bereitgestellt, sodass events Index-Metadaten direkt übertragen kann (PR #3452), und NIP-50-Sucherweiterungen werden jetzt vor der Abfrage von SQLite FTS entfernt, sodass die lokale Suchmaschine nicht mehr an der Syntax von serverseitigen Erweiterungen scheitert (PR #3464). Standard-Suche relays wird zentralisiert (PR #3446).

Der dritte Strang sind Protokollintegrationen für Nischenbranchen. Die Unterstützung für Birdstar Vogel-Erkennung events (kind 2473) erreicht einen Android-Client (PR #3473), und PS1 Memory-Card-Speicherstände können als signierte events auf kind 38192 veröffentlicht werden (PR #3482). Die Woche abrundend: Eine Compose-Signatur-Einstellung fügt automatisch benutzerdefinierten Text zu Beiträgen hinzu (PR #3450), die Desktop-Benachrichtigungsansicht wurde mit nativen OS-Toasts und einem gemeinsamen Filter neu gestaltet (PR #3457), die Nachrichten-Spalte erhält eine Datenschutzeinstellung (PR #3432), NostrServer.ingest fügt einen lokalen Schreibpfad mit Überspringen der Überprüfung pro Einreichung hinzu (PR #3469), und equals/hashCode-Verträge werden im OpenTimestamps-Überprüfungspfad repariert (PR #3477).

Buzz härtet weiterhin das relay aus und definiert kind 44200 für Agenten-Drehmetriken

Buzz (das Projekt, früher Sprout genannt) hat im Zeitraum vom 1. bis 7. Juli 123 PRs zusammengeführt. Zwei Threads tragen das meiste Gewicht. Der erste ist ein neuer event kind für Agenten-Telemetrie: PR #1441 definiert NIP-AM dauerhafte verschlüsselte Agenten-Turn-Metriken als kind 44200, welche die Telemetrie als signiertes event in den eigenen relay-Archiven des Benutzers platziert und die Metriken auf benutzereigener Infrastruktur speichert. Ein lokales Archiv für den kind folgt (PR #1555), der Remove-kind-Pfad wird atomar gemacht (PR #1562), und der Modellname wird durch den Emit-Pfad weitergegeben, damit nachgelagerte Leser unterscheiden können, welches Modell welche Runde produziert hat (PR #1564).

Der zweite Thread ist die Leistung von relay. Die Post-Commit-Auswertung wird verschoben und ein Überprüfungsklon vermieden (PR #1453), Ingest- und Fan-out-Datenbank-Rundreisen werden gebündelt mit gemessenen p99-Anerkennungsverlusten von 7 bis 16 Prozent und p999-Spitzenverlusten von 29 bis 53 Prozent im Vergleich zum vorherigen Stand (PR #1454), die Ausführung von Multi-Filter-Abfragen erfolgt mit begrenzter Parallelität (PR #1457), und ausgehende WebSocket-Datenrahmen werden beim Senden gebündelt (PR #1464). Neben der Leistungsarbeit ein pro-Community-Workspace-Symbolsatz, den Administratoren konfigurieren, und der relay über NIP-11 bereitgestellt wird, erweitert relay zxq012qxz’s Informationsdokument mit einer pro-Community-Anpassungsoberfläche (PR #1463), Agentenbesitzer können die Nachrichten ihres Agenten über relay kind:5 events löschen, plus passende Desktop- und Mobile-UX (PR #1519), OpenTelemetry-Tracing ergänzt Prometheus-Metriken auf der relay (PR #1398), und das Git-Repository-Name-Register wird auf Postgres verschoben (PR #1432).

Divine Video richtet die Signaturüberprüfung relay und eine NostrConnect-Extraktion ein

Die Mobile-App von Divine Video mobile app hat 97 PRs im Fenster zusammengeführt, und der Nostr-bezogene Thread betrifft die Härtung der Vertrauensgrenze sowie die Bereinigung der Authentifizierung. PR #5774 überprüft eingehende relay event Signaturen und schließt eine Klasse von Vertrauensproblemen im relay; PR #5828 verschlüsselt das FCM-Push-Token im kind-3080 Deregistrierungs-event, sodass das Gerätetoken des Benutzers nicht mehr im Klartext auf dem relay erscheint, wenn sie sich abmelden; und PR #5831 teilt das kind:5 Löschungs-REQ in Abschnitte auf, sodass ein Benutzer mit einer großen Löschhistorie den relay-Rahmen nicht mehr überläuft. Auf der Authentifizierungsseite extrahiert PR #5826 einen NostrConnectCoordinator für den nostrconnect://-Fluss und bereinigt den NIP-46 client-initiierten Bunker-Codepfad im Vorfeld einer größeren auth-Überarbeitung, die unter issue #4741 verfolgt wird. PR #5709 ordnet kind-16-Reposts zu, wenn notification_type fehlt, sodass eine Repost-Benachrichtigung korrekt angezeigt wird, selbst wenn der sendende Client den Hinweis weglässt.

Zap Cooking behebt den NIP-46 Bunker-Login und fügt die NIP-50 Rezeptsuche hinzu

Zap Cooking’s frontend hat 18 PRs im Fenster unter einem Thema zusammengeführt: das Wiederherstellen von Nostr auth-Oberflächen nach einem Fehler. PR #503 behebt den Bunker-Login mit einem expliziten Verbindungs-Handshake, der Handhabung von authUrl und der Fehleranzeige, sodass ein Benutzer, der einen externen Signierer anschließt, eine echte Fehlermeldung bei einem Fehler sieht, während der vorherige Schnitt den Login-Bildschirm blockierte. PR #495 fügt NIP-98 auth zu den Upload-Pfaden für Bilder und Texte des extract-recipe-Endpunkts hinzu, sodass Uploads pubkey zugeordnet werden können. Ein separater Feature-Thread führt NIP-50 die Volltextrezeptsuche über den nostrarchives-Such-Backend (PR #483) ein, wodurch ein Benutzer Rezepte im gesamten relay-Korpus abfragen kann, ohne einen Client-seitigen Index. Polierte Inhaltsdarstellung wird gleichzeitig veröffentlicht:] Inhalt und Medien von zitierten Notizen werden nun direkt in der übergeordneten Notiz angezeigt und ersetzen das bisherige versteckte Link-Backup (PR #491), Link-Vorschauen und Hashtag-Größenanpassungen werden eingeführt (PR #492), Suchanfragen mit mehreren Wörtern funktionieren (PR #482), und serverseitige Vorschaukarten für Notizen, Reads und Profil-Links werden generiert (PR #494).

swift-nostr-Client v0.6.0 schreitet in Richtung eines ersten stabilen Schnitts voran

[yysskk/swift-nostr hat v0.6.0 zusammen mit 30 zusammengeführten PRs veröffentlicht. Die Swift Nostr Bibliothek rückt näher an eine erste stabile API Oberfläche für Swift Nostr Clients, die das Verknüpfen der MDK oder MarmotKit Toolchains vermeiden.

Nostr Applet-Protokoll (NAPS) verstärkt NAP-OUTBOX-Routing und Fanout

NAPS hatte eine bedeutende Aufräumwoche, hauptsächlich in NAP-OUTBOX. Die Schlagzeile lautet: engere Grenzen: weniger vom Anrufer gesteuerte Weiterleitungen, weniger durchgesickerte relay-Details und eine gemeinsame event-Ergebnisstruktur, die relay-Hinweise und Ressourcen-Sidecars enthalten kann, verbunden mit NAP-RESOURCE. Auch die Veröffentlichung ist klarer: expliziter Outbox, Inbox und relay-Fanout-Regeln. Nettoeffekt: weniger Mehrdeutigkeit, bessere Interoperabilität.

Napplet-Toolchain verbessert die Protokollabstimmung und liefert ihr CLI aus

In dieser Woche haben sich Napplets Pakete von „nützlichem SDK“ hin zu einer engeren Protokoll-Toolchain bewegt. Die große Neuigkeit ist die Angleichung an die aktuellen NAP-Spezifikationen: NAP-COUNT Abfrageunterstützung , OUTBOXs laufzeitgesteuerter Lebenszyklus , und RelayEventResult Sidecars sind alle eingeführt worden, wodurch shell-vermittelte Lesevorgänge und Abonnements präziser werden. Auch mehrere Bereiche wurden geschärft: CVM-Registrierungsunterstützung, DM-Fehlerumschläge, MEDIA-Sitzungskontext, LISTEN-Zählfelder, COMMON-Profilresultate und der htree: RESOURCE-Schema. Bei den Werkzeugen ist das neue @napplet/cli ein wichtiger Meilenstein, das Konfigurationsentdeckung, Bereitstellungsplanung, Signierung, Blossom-Uploads und Manifestgenerierung hinzufügt. Schließlich machten der host-injective Shim Prelude und die JSR-Bereitschaftsarbeiten den Stack einfacher zu injizieren, zu veröffentlichen und zu überprüfen.

primal-android erweitert die Remote-Signer-Oberfläche

Primal Android hat 18 PRs im Fenster zusammengeführt. Auf der Nostr Seite implementiert PR #1075 switch_relays und logout Methoden für die Rolle des Remote-Signers der App und erweitert die NIP-46 Signer-Oberfläche von Primal. PR #1083 fügt ein splash-gegated lokales App-Migrations-Framework hinzu, und PR #1080 implementiert Note-Feed-Prefetching im Splash-View-Model. Der Rest ist UI-Politur über die obere und untere Leiste des Homes, Explore-Hinweise und den Profilbildschirm.

Wisp fügt einen Multi-Account-Umschalter und Blossom-Parser-Tests hinzu

Wisp hat 9 PRs zusammengeführt. PR #604 fügt einen Multi-Account-Umschalter mit einem expliziten Abbruchpfad im Konto-hinzufügen-Flow hinzu. PR #613 fügt Unit-Tests für Blossom.parseServerList hinzu und verschärft den Blossom Server-Listen-Parser. PR #574 schreibt das Zap-Sheet für iOS-Layout mit einer Instant-Zap-Einstellungsoberfläche um, PR #605 wandelt die Transaktionshistorie in ein Swipe-Bottom-Sheet um, PR #611 parsest Hashtags mit Nicht-ASCII-Unicode-Buchstaben, PR #609 behält die Profilnotizen mit Feed-Paginierung und rendert Inline-Galerie-Medien, und PR #603 bewahrt leere Zeilen vor Inline-Profil- und Hashtag-Segmenten.

TAO und Wired erhöhen das PoW-Signal auf 21 Bit und erzeugen frische PoW-Wurzeln

smolgrrr/TAO und smolgrrr/Wired (derselbe Commit-Satz wurde in beiden Repositories bereitgestellt) haben 13 PRs zusammengeführt. PR #84 erhöht das Standard-Post-Signal proof-of-work-Ziel auf 21 führende Nullbits, und PR #80 zeigt Feed-Wurzeln aus frischer PoW-Aktivität an, sodass ein Client die Zeitleiste nach aktueller NIP-13-Arbeit ranken kann; das vorherige Ranking basierte auf dem reinen event-Alter. PR #75 stellt einen benutzerdefinierten Emoji-Auswähler wieder her und PR #65 fügt Vorschauen des ersten Videoframes hinzu. Dies ist der zweite Nostr-Client in dieser Woche, der auf NIP-13 als erstklassigen Filter für von Nutzern erstellte Inhalte setzt und Bitchats kanalbezogenes PoW ergänzt.

keep-android verbessert NIP-46 UX und bringt einen TOCTOU-Fix

privkeyio/keep-android hat v1.1.5 zusammen mit 13 zusammengeführten PRs veröffentlicht, dann v1.1.6 am 8. Juli, wobei das zugrunde liegende Keep-Core auf v0.5.0 festgelegt wurde. Keep ist ein mobiler Identitätsspeicher (behandelt in Issue #29 als CustID). v1.1.5 war UX-Feinschliff am NIP-46 Challenge-Flow. v1.1.6 schließt ein Check-then-Set (TOCTOU) Rennen in set_active_share vom zugrunde liegenden Keep-Mobile-Crate, zeigt die URL und Methode an, die im NIP-98 HTTP-auth Genehmigungs-Popup autorisiert werden, damit ein Benutzer sehen kann, was er unterschreibt, und wechselt die RNG-Integritätsprüfung so, dass sie bei Fehler geschlossen wird (einen Fehler zurückgibt) anstatt einen Panic auszulösen. Ein instrumentierter Test deckt den NIP-55 Genehmigungsfluss-Killschalter ab. Die v0.5.0 CLI-Funktionen, die mit der zugrunde liegenden Version geliefert wurden (Threshold-OPRF-Freischaltung, Software-DKG, HD FROST-Wallets), sind in der Android-App noch nicht verfügbar; v1.1.6 liefert nur die Sicherheitskorrekturen.

Heartwood liefert die relay-zu-Seriell-Signaturbrücke

forgesworn/heartwood v0.7.0 landet die relay-zu-serielle Signing-Bridge, die letzte Woche im Betrieb war, und verkabelt das HSM-Modus-Datenflugzeug für Bray’s Serial-Signer-Pfad. PR #11 ist die Bridge selbst, PR #13 fügt Serialframe-Abdeckung hinzu und behebt den Payload-Offset read_frame Gerät, und PR #14 extrahiert den seriellen Frame-Codec in eine gemeinsame heartwood-frame-Kiste.

SafeBox veröffentlicht einen Fortschrittsbericht zur Phase 3 und ein FreeBSD-Jail-Handbuch

SafeBox ist ein privater tragbarer Datentresor auf Nostr, der NIP-47 Nostr Wallet Connect, nAuth, nembed und relay-vermittelte Datentransfers über QR und NFC in einem vom Betreiber einsetzbaren Dienst kombiniert. Ein Fortschrittsbericht vom Juli 2026, veröffentlicht am 6. Juli, markiert Phase 3 als im Wesentlichen abgeschlossen: Seit dem April-Bericht wurden 49 Commits hinzugefügt, wodurch das Repository auf 1.136 Commits angewachsen ist, und die vier Phase-3-Engineering-Verpflichtungen (Phase-2-Experimente festigen, interoperable Instanzen unterstützen, auf Skalierung vorbereiten, disziplinierte kommerzielle Produktarbeit einführen) sind weitgehend abgeschlossen. Der Bericht beschreibt den nächsten Schritt als begrenztes Pilotprojekt und gibt bekannt, dass ein Telekommunikationsanbieter unter NDA ein Pilotprojekt für Gesundheitsakten auf SafeBox untersucht.

Die Betonarbeit Nostr-facing wurde früher in Phase 3 abgeschlossen und im Bericht zusammengefasst: mutierende NWC-Aktionen werden nun in die Warteschlange gestellt, um Beweis-Rennen zu vermeiden, fehlgeschlagene Lightning-Schmelzen schützen Beweise, bevor sie zurückkehren, und langlebige NWC-Listener aktualisieren sich jetzt proaktiv, sodass eine Sitzung ihre Leerlaufgrenze überschreiten kann; Das vorherige Verhalten war ein stilles Anhalten, und LNURL-Rückrufe verwenden kanonische Ursprünge mit explizitem JSON und CORS-Antworten. Der Austausch von QR- und NFC-Datensätzen erhielt eine einheitliche Flowspezifikation, die Empfänger-präsentierte, Sender-präsentierte und geräteübergreifende Präsentationsmodi abdeckt, mit klarerer KEM (Key Encapsulation Mechanism)-Behandlung und Wiederholschutz durch die Open Quantum Safe-Bibliothek. Der In-Window-Commit ist 6866dae, der ein FreeBSD-Jail-Deployment und liboqs-Build-Runbook zusammen mit einer FreeBSD-Appliance-Spezifikation hinzufügt und ZFS-Snapshots, Jail-Isolierung, rc.d-Service-Management, Reverse-Proxy-Konfiguration auf Host-Ebene und Rücksetzverfahren für eine SafeBox-Bereitstellung auf FreeBSD/ARM-Hardware dokumentiert.

Der Bericht kündigt außerdem OpenETR als eigenständiges Spin-off an, das die SafeBox-Kryptographie-Kontroll-plus-portable-Aufzeichnungen-Architektur auf elektronische übertragbare Urkunden anwendet: Konnossemente, Lagerquittungen, Wechsel und Zertifikate. Das OpenETR-Repository verzeichnete am 7. Juli 7 Commits, darunter ea612a9, der die Attestierung vom Kern-Datensatz trennte, ca153a3 zur Handhabung von Mandat-versus-Effekt, und ba84b61, der einen Vergleich zu verifizierbaren Zertifikatsformaten hinzufügte.

Protokollarbeit und NIP-Aktualisierungen

Zusammengeführt: NIP-51 und NIP-37 richten den kind 10013 Namen aus

PR #2404 ist ein reiner Konsistenzfix für den Fließtext. In NIP-37, wird kind 10013 als Relay List for Private Content benannt; in NIP-51 unter Draft relays wurde dasselbe kind mit unterschiedlichen Formulierungen beschrieben. NIP-51 verwendet jetzt den Namen NIP-37 für dasselbe event kind. Keine Änderungen im Leitungsverhalten und keine neuen Tag-Semantiken; Der Wert liegt darin, dass NIP-51 die übergeordnete Spezifikation für das listenförmige events ist und NIP-37 die Folge für private Inhalte darstellt, und die nicht übereinstimmende Benennung zwischen den beiden macht es leicht zu übersehen, dass sie dasselbe kind beschreiben.

Öffnen: NIP-AD Nostr Webadressen über .well-known-Suche

PR #2406 wird als Nachfolger eines geschlossenen PR #2393 eröffnet, mit einem vollständigen Spezifikationsentwurf unter AD.md. NIP-AD definiert Web-URLs, die eine optionale Nostr-Komponente enthalten. Ein Client, der eine URL wie https://golf.com/players sieht, fordert https://golf.com/.well-known/nostr.json?ad=/players an, was ein JSON-Objekt zurückgibt, das Pfade auf {filter, relays}-Paare abbildet. Der zurückgegebene Filter ist ein Standard-NIP-01-Filter (kinds, Autoren, #d, limit usw.), und die relays-Array-Namen geben an, welche relays der Client abfragen sollte. Mit "limit": 1 löst die URL auf eine einzelne event auf; ohne sie auf eine Liste. In einem normalen Webbrowser rendert die URL HTML wie jede andere URL, sodass dieselbe Domain Webnutzer und Nostr-Clients von einem kanonischen Pfad aus bedienen kann. Die angegebenen Anwendungsfälle umfassen NIP-29 Gruppenamen, die zu einem kind 39000 event auf einem bestimmten relay aufgelöst werden (was die Notwendigkeit des Sammelns von Gruppen-IDs überflüssig macht), NIP-5A nsite-Abfragen, gehostete Feeds, die einen {"ids": [...]}-Filter veröffentlichen, native Darstellung eingefügter njump.me/nevent1... und clientspezifischer event-URLs, und Nostr-gestützte Blogs, die sowohl nativ innerhalb von Nostr als auch für Besucher von außen existieren. Das .well-known/nostr.json-Wiederverwendungsplus-Pfad-als-Objektschlüssel-Layout wird gewählt, damit der Resolver eine statische Datei sein kann.

Offen: NIP-86 Anspruchsverwaltung für Einladungscodes

PR #2408 schlägt vor, drei Methoden zu NIP-86] hinzuzufügen: listclaims (Params [], gibt ein Array von NIP-43-Einladungscodes), createclaim (Params [claim], gibt true zurück) und deleteclaim (Params [claim], gibt true zurück). Heutzutage ermöglicht NIP-86 einem relay-Administrator, Benutzer und Rollenzuweisungen zu verwalten, hat aber keine Einladungscode-Oberfläche. Der Anwendungsfall des PR-Autors ist Community-relay Onboarding: Ein Administrator erstellt einen Einladungscode, der mit einer Rolle verbunden ist, sammelt die Zahlung, bevor die Identität des Benutzers erstellt wird, übergibt den Einladungscode an den Benutzer, und ein Bot hört auf die daraus resultierende kind 28935 claim event auf dem relay und weist die Rolle automatisch zu. Die drei Methoden lassen diesen Ablauf vollständig durch das relay-Management-RPC laufen.

Öffnen: Rollenfarbe als (h, s, l) Tupel

PR #2402 ändert das Format der Rollenfarbe in NIP-43 von einem einzelnen hue-Wert (0 bis 360) zu einem Tupel aus hue (0 bis 360), saturation (0 bis 1) und lightness (0 bis 1). Leere Zeichenfolgen sind für jede Komponente zulässig, sodass Clients ihre eigenen Standardwerte für eine stimmige Palette bereitstellen können, und der Spezifikationstext empfiehlt, nur hue bereitzustellen, es sei denn, eine spezifische Farbe wie Silber ist gewünscht. Die Änderung zieht sich durch NIP-86 im selben PR: createrole und editrole nehmen jetzt [id, label, description, [h, s, l], order]; die vorherige Signatur trug in derselben Position einen einfarbigen Parameter. Die Motivation ist, dass der Farbton allein die Clients zwingt, Sättigung und Helligkeit für den Operator zu wählen, sodass verschiedene Clients dieselbe Rolle mit sichtbar unterschiedlicher Intensität darstellen.

Offen: NIP-80 hardwarebestätigte Medienherkunft

PR #2409 öffnet NIP-80, ein event-Format für Medienherkunft, das an die Aufnahmetechnik gebunden ist. Eine Kamera signiert jedes Foto zum Aufnahmezeitpunkt und veröffentlicht den Nachweis auf relays, der durch den Inhalt selbst verschlüsselt ist, sodass die Überprüfung Metadatenlöschung, erneutes Hochladen und Plattformentfernungen überdauert. Der Vorschlag definiert sechs neue event kinds: kind 1080 für Erfassungsbescheinigungen, kind 1081 für Ableitungsbescheinigungen, die Größenänderungs-, Zuschneide-, Neukomprimierungs- oder Schwärzungsoperationen abdecken (mit einem Enthüllungsmodus oder einer Zero-Knowledge-Option), kind 1082 für Widerrufe (regulärer events, dauerhaft, autorenspezifisch, monoton), kind 11080 für Geräteankündigungen, kind 31080 für Gerätebefürwortungen und kind 31081 für ein Geräteset für anonyme Bescheinigungen (markiert experimentell und möglicherweise in ein Begleit-NIP aufgeteilt). Wiederverwendete Primitive umfassen NIP-94 x-Tag-Semantik, NIP-92 imeta, NIP-65 für Widerrufserkennung, Blossom für Medienspeicherung und optional NIP-03 Zeitstempelverankerung. Das Signierungsmodell kombiniert einen BIP-340-Geräteschlüssel mit einem Hardware-ECDSA-Schlüssel, da gängige Secure Elements derzeit noch keine BIP-340-Signaturen erzeugen (Microchip ATECC608 unterstützt P-256, NXP SE050 unterstützt secp256k1, aber nur ECDSA, TPM 2.0-Module und Infineon OPTIGA Trust M decken P-256/RSA ab, Apple Secure Enclave und Android StrongBox verwenden P-256). Der angegebene Umfang versucht ausdrücklich nicht zu beweisen, dass die Szene echt ist: Eine Bestätigung beweist, dass dieses genaue Bild ungefähr zu dieser Zeit von diesem Gerät stammt und nur auf deklarierte, nachweisbare Weise verändert wurde, und die Spezifikation verbietet es den Clients, Ergebnisse in ein bloßes „authentisches“ Abzeichen zu komprimieren. Ein funktionierender Prototyp OpenVeilCam, eine Rust-Kameralaufzeit für Raspberry Pi unter Verwendung des ATECC608-Sicherheitsmoduls, wird aktualisiert, um die vorgeschlagenen event kinds zusammen mit einem eigenständigen Verifizierer zu veröffentlichen.

Offen: NIP-01 Paginierungshärtung

PR #2407 fügt NIP-01 einen Unterabschnitt “Seitennummerierung & Limits” hinzu. Die konkreten Regeln: Ein relay, der ein maximales limit vorgibt, MUSS dieses größer als die größte Anzahl von events festlegen, die eine einzige created_at in seiner Datenbank teilen, sodass keine einzelne zweite Einheit eine Seite füllen und die Seitennummerierung blockieren kann. Clients, die rückwärts blättern, MÜSSEN Anfragen mit until = oldest (einschließlich) wiederholen und MÜSSEN nach id deduplizieren (da die älteste Sekunde in jeder Runde erneut abgerufen wird), und das Blättern ist abgeschlossen, wenn eine Runde nach der Deduplizierung keine neuen events liefert. Wenn eine volle Seite den ältesten und den neuesten events teilt und dabei einen created_at gemeinsam benutzt, MUSS der Client diese zweite Sekunde mit einem größeren limit erneut versuchen, und wenn der relay das größere limit einschränkt und trotzdem eine Seite liefert, die auf eine Sekunde beschränkt ist, MUSS der Client entweder mit until = oldest - 1 fortfahren (und dabei nicht abgerufene events als verworfen behandeln) oder abbrechen. Normales Paging DARF limit NICHT setzen; Das relay-Maximum ist maßgeblich, und ein kleinerer Wert führt erneut zum Stillstand. Das Anheben von limit, um eine feststeckende Sekunde abzuleiten, ist die einzige Ausnahme. Diese Korrektur ist wichtig, weil ein naiver since/until-Cursor entweder events mit doppelten Zeitstempeln überspringt oder diese erneut verarbeitet, und der aktuelle NIP-01-Text sagt keiner Seite, wie man der Falle entkommt.

NIP Tiefenanalyse: NIP-13 (Nachweis der Arbeit)

NIP-13 definiert einen proof-of-work-Mechanismus für Nostr events. Er existiert, weil E-Mail-ähnlicher Spam in einem öffentlichen relay-Netzwerk trivial zu erzeugen ist: Jeder kann ein Schlüsselpaar generieren und ein Thema überfluten, und es gibt keine wirtschaftlichen Kosten pro event. NIP-13 ermöglicht es einem event-Autor, pro event Kosten in Form von Rechenleistung aufzuerlegen, die ein Spammer insgesamt zahlen müsste, während ein regulärer Absender nur einmal pro Nachricht zahlt.] Relays und Kunden können dann events verlangen oder bevorzugen, die eine Schwierigkeitsstufe erfüllen.

Der Mechanismus

Ein event-Autor wählt ein Schwierigkeitsziel aus, das in Bits ausgedrückt wird, und schürft die ID des event (den sha256-Hash des serialisierten event), bis sie mindestens so viele führende Null-Bits hat. Da die ID des event den created_at-Zeitstempel, die Tags und den Inhalt enthält, erfordert das Schürfen, etwas im event-Inhalt zu ändern, um den Hash-Raum zu durchsuchen. NIP-13 definiert ein nonce-Tag genau zu diesem Zweck:

["nonce", "<nonce_value>", "<target_bits>"]

Der nonce_value ist jede Zeichenfolge, die der Miner auswählt; der target_bits ist die Schwierigkeit, zu der sich der Miner verpflichtet hat. Ein Prüfer zählt die führenden Nullbits der event-ID und vergleicht sie mit target_bits. Der target_bits im Tag ist eine Behauptung, und ein Prüfer misst die tatsächliche Anzahl der führenden Nullen der ID, um sie zu bestätigen.

Die Anzahl der führenden Nullenbits in einer zufälligen SHA256-Ausgabe folgt einer geometrischen Verteilung: jedes zusätzliche Bit verdoppelt die erwartete Arbeit. 8 Bits erfordern im Durchschnitt 256 Hash-Versuche, 20 Bits ungefähr eine Million, und 28 Bits ungefähr 268 Millionen. Das 8-Bit-Ziel von Bitchat für geohash-Kanalnachrichten kostet auf moderner Hardware weniger als eine Millisekunde CPU-Zeit und wird unterhalb jeder wahrnehmbaren Latenz abgeschlossen. Das 21-Bit-Standard von TAO und Wired beträgt ungefähr zwei Millionen Hash-Versuche pro Beitrag, was auf einem Laptop schnell ist, aber im großen Maßstab für eine Botfarm teuer wird. NIP-13 schreibt keine Schwierigkeit vor; jeder relay und Client wählt seine eigene.

Beispiel event

Eine minimale NIP-13-abgebaute kind-1 Notiz sieht so aus:

{
  "id": "000000000e9d97a1ab09fc381030b346cdd7a1a8a6f27c9c88f68c8b9d0f6c8a",
  "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
  "created_at": 1720368000,
  "kind": 1,
  "tags": [
    ["nonce", "72847", "28"]
  ],
  "content": "hello, this cost me 28 bits of PoW",
  "sig": "b1a5c9c74cff59f8a48e5c3b3d8e1c8e7e2c1d4a8e2b9f7d1c3e8b4f6a2c8d1e9f4b3c7a1d8e5b2f9c6a3d7e1b8f4c9a2d6e3b7f1c8a4d9e2b5f8c1a7d4e6b9f3c2"
}

Der id beginnt mit sieben hexadezimalen Nullen (28 führende Nullbits, entsprechend dem target_bits im nonce-Tag). Der Miner variierte den nonce_value 72847, bis die ID das Ziel erfüllte. Ein Prüfer hasht die serialisierte event und bestätigt, dass die ID mindestens 28 führende Nullbits hat, und überprüft dann die Signatur. NIP-13 fügt keine neuen Felder hinzu; es fügt das nonce-Tag hinzu und beschränkt die Nullbitanzahl der ID.

Wo es verwendet wird

Die Version 1.5.4 von Bitchat verwendet 8-Bit PoW auf kind 20000 geohash-Kanalnachrichten: ausgehende Nachrichten senden den Tag vor der Veröffentlichung und eingehende events mit validiertem PoW lockern das Intake-Limit pro Absender. TAO und Wired verwenden 21-Bit PoW als standardmäßigen Post-Signal-Schwellenwert und zeigen Feed-Wurzeln aus frischer PoW-Aktivität an, wobei PoW als Timeline-Rangsignal behandelt wird. cagliostr erzwingt NIP-13 auf der relay-Ebene und lehnt events unterhalb eines Schwellenwerts ab. NoStrudel bietet eine clientseitige PoW-Mining-Einstellung für Autoren, die gegenüber filternden Clients signalisieren wollen. Damus und Amethyst berechnen führende Nullbits beim Anzeigen von events, sodass ein Benutzer das PoW-Commitment auf Notizen sehen kann. Coracle stellt PoW sowohl zum Mining als auch zum Filtern bereit.] NDK und nostr-Tools stellen PoW-Bergbauhilfen den Bibliotheksnutzern zur Verfügung.

Die Gestalt-Eigenschaft, die die Bereitstellung von NIP-13 bestimmt, ist, dass PoW nicht fälschbar ist: Eine Behauptung von target_bits zählt nur dann als Beweis, wenn die ID so viele führende Nullen hat, und eine Fälschung erfordert das erneute Erledigen der Arbeit. Diese Eigenschaft ermöglicht es Bitchat, eingehendes PoW selbst dann als Rate-Limit-Locker zu verwenden, wenn ein Spammer eine hohe Schwierigkeit behauptet; die Überprüfung ist eine Zählung von Hashes, keine Vertrauensentscheidung. Die komplementäre Eigenschaft ist, dass PoW den Miner nicht auf eine bestimmte pubkey oder Inhalte festlegt; ein Spammer kann immer noch wählen, auf 8 Bits zu minen und Rechenleistung zu verbrauchen, aber die Rechenleistung ist ein echter Kostenfaktor. NIP-13 verschiebt das Spam-Problem von „unmöglich“ zu „quantifizierbar“ und ermöglicht es den Nutzern, ihren eigenen Preis festzulegen.

NIP Tiefenanalyse: NIP-40 (Expiration Zeitstempel)

NIP-40 definiert ein expiration-Tag, das einem relay und einem Client Anweisungen gibt, dass ein event nach einem bestimmten Unix-Zeitstempel als abgelaufen betrachtet werden sollte. Es existiert, weil Nostr events sonst dauerhaft sind: Sobald ein signiertes event auf einem relay landet, ist der einzige Weg, es zu entfernen, ein NIP-09-Delete-event, und selbst dann kann ein relay das Original behalten. NIP-40 ermöglicht es einem Autor, zum Zeitpunkt der Veröffentlichung zu erklären, dass ein event kurzlebig ist, und fordert relays auf, es nicht mehr bereitzustellen und die Clients, es nach dem Zeitstempel nicht mehr anzuzeigen.

Der Mechanismus

Ein Autor fügt einem event-Tag ein expiration hinzu:

["expiration", "<unix_timestamp>"]

Der Zeitstempel ist Unix-Sekunden. Ein relay KANN events ablehnen, dessen expiration beim Einlesen bereits in der Vergangenheit liegt, KANN aufhören, events zu bedienen, dessen expiration verstrichen ist, und SOLLTE die vom Autor angegebene expiration respektieren. Ein Client SOLLTE abgelaufene events vor dem Benutzer verbergen. NIP-40 erfordert nicht, dass relay die event löscht, und es hebt nicht die NIP-70-geschützten event-Semantiken auf; Es ist ein Hinweis plus ein weicher Vertrag.

Das Tag befindet sich auf dem event selbst (oder im Fall von umhüllten Nachrichten auf der äußeren Hülle). NIP-40 definiert keine Löschsemantik; der event bleibt ein signierter event, den jeder, der ihn hat, weiterhin lesen kann. Was NIP-40 bietet, ist eine koordinierte Erwartung, dass der relay und der Client nach Ablauf der Frist aufhören werden, den event anzuzeigen. Dies macht NIP-40 nützlich für flüchtige Beiträge, zeitgesteuerte Ankündigungen, Live-event-Notizen, die nach dem event nicht mehr bereitgestellt werden sollten, und NIP-17-Direktnachrichten, die nicht über einen angegebenen Zeitpunkt hinaus bestehen sollten.

Interaktion mit gift wrap

Der rust-nostr PR, der diese Woche gelandet ist (PR #1384), ist eine Fallstudie dafür, wie NIP-40 mit NIP-59 gift wrap interagiert. NIP-59 definiert eine zweischichtige Hülle: ein kind:13 „Siegel“ event, das mit dem echten Schlüssel des Absenders signiert ist, und ein kind:1059 „gift wrap“ event, das mit einem flüchtigen Schlüssel signiert ist. Beide Schichten haben zufällig generierte created_at-Werte, bis zu 48 Stunden vor der tatsächlichen Sendezeit, sodass ein relay-Beobachter den echten Sendezeitstempel nicht wiederherstellen kann. NIP-59 schreibt vor, dass das Siegel leere Tags haben muss.

Dieses Mandat ist der Grund, warum das expiration-Tag auf das gift wrap gesetzt werden muss und nicht auf das Siegel, und warum das Verankern des Tags an der tatsächlichen Sendezeit die Zeitprivatsphäre von gift wrap untergraben würde: Wenn ein Anrufer einen absoluten expiration-Zeitstempel übergibt, zieht ein Beobachter den beabsichtigten TTL des Anrufers ab und ermittelt die tatsächliche Sendezeit. rust-nostr’s Designentscheidung ist, die API als eine Duration für den Aufrufer offenzulegen und dann expiration = wrap.created_at + duration innerhalb der Bibliothek zu berechnen. Die created_at des Wrappers ist bereits innerhalb der Bibliothek randomisiert, sodass der expiration-Zeitstempel die gleiche Randomisierung übernimmt und die tatsächliche Sendezeit nicht preisgibt.

Beispiel event

Ein minimales NIP-40-Beispiel auf einer kind-1-Notiz:

{
  "id": "1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b",
  "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
  "created_at": 1720368000,
  "kind": 1,
  "tags": [
    ["expiration", "1720454400"]
  ],
  "content": "this note expires in 24 hours",
  "sig": "d2e5b8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1"
}

created_at ist der Unix-Zeitstempel der Veröffentlichung; Das expiration-Etikett besagt, dass die event 86.400 Sekunden (24 Stunden) später nicht mehr zugestellt werden soll. Ein relay, der NIP-40 nach 1720454400 aufhört, diese event an REQs zurückzugeben, und ein Client, der NIP-40 respektiert, verbirgt sie nach dieser Zeit vor dem Nutzer.

Wo es verwendet wird

Die Ersteller von rust-nostr (GiftWrapBuilder, PrivateDirectMessageBuilder) stellen jetzt expiration als erstklassigen Duration-Parameter bereit. NDK stellt einen expiration-Helfer für kind-1 und DM-Ersteller bereit. nostr-Tools haben ein getExpiration- und isExpired-Paar zum Lesen und Durchsetzen des Tags. strfry, nostr-rs-relay, khatru und andere relay-Implementierungen respektieren NIP-40 bei der REQ-Verarbeitung (Ablehnung oder Auslassung abgelaufener events abhängig von der Richtlinie des Betreibers). Damus, Amethyst, noStrudel, Coracle und Primal filtern alle abgelaufene events aus ihrer Timeline-Darstellung. Live-Activity-Clients wie zap.stream verwenden NIP-40 auf dem zugehörigen kind-1311-Chat events, sodass ein Live-Chat nach dem Ende des Streams nicht mehr fortbesteht.

Die Design-Eigenschaft, die NIP-40 in den meisten Implementierungen sauber landen lässt, ist, dass sie pro event optional ist und keine koordinierte Bereitstellung erfordert. Ein Autor kann das Tag heute hinzufügen; ein relay, das es berücksichtigt, erhält einen saubereren Arbeitsbereich; ein relay, das es ignoriert, schneidet nicht schlechter ab als zuvor; und ein Client, der abgelaufene events ausblendet, gibt dem Autor, was er verlangt hat. Die Änderung rust-nostr in dieser Woche verstärkt, dass die Platzierung des Tags genauso wichtig ist wie seine Anwesenheit: in einem datenschutzfreundlichen Umschlag wie NIP-59 gift wrap sitzt der Tag auf der Schicht, deren Zeitstempel bereits zufällig gemacht wurde, und die API-Oberfläche verhindert, dass ein Aufrufer versehentlich einen echten Zeitstempel wieder in die Hülle weitergibt.

Das war’s für diese Woche. Baust du etwas oder hast du Nachrichten zu teilen? Kontaktiere uns über NIP-17 DM oder finde uns auf Nostr.