Diese Woche war geprägt von Signer-Arbeit, P2P-Handelsprotokollen und Releases führender Clients. Amethyst v1.12.0 liefert über 170 PRs und ergänzt NIP-60-Cashu-Wallets, NIP-61-Nutzaps, NIP-82-Software-App-Feeds, NIP-F4-Podcast-Unterstützung, CLINK-Verifikation für On-Chain-Zaps, die KMP-Phasen 1 und 2 der iOS-Migration und einen Tor-Selbstheilungstreiber. Clave v1.0.0 (Build 102) wurde beim App Store eingereicht und bringt per Push geweckte Hintergrundsignatur und Verifikation eingehender Signaturen auf iOS. Mostro Core v0.13.0 liefert Protokoll v2 und ersetzt die relay-basierte Auftragskommunikation durch NIP-44-gift-wrapped Direktnachrichten, und Mostro v0.17.5 machte die betreiberseitige Anti-Missbrauchs-Kaution optional und konfigurierbar. Signet v1.11.0 behebt eine Umgehung der Signaturprüfung bei NIP-17-Adminbefehlen (gift-wrapped private DMs), die es jedem mit öffentlichen Informationen erlaubte, Kill-Switch-Befehle zu fälschen. Chama veröffentlichte sieben Escrow-Releases in sechs Tagen und verwandelte den Handelsraum von einer Wand aus Bedienelementen in ein Gespräch pro Sitzplatz. Auf der Signer-Seite implementieren Amber v6.2.1, Clave (Builds 100, 101 und 102) und Nostur 1.29.0 alle die neue NIP-46-Logout-Methode, die diese Woche gemergt wurde (PR #2373). Zeus v13.1.0-rc1 und Amethyst liefern beide CLINK-noffer-Unterstützung, die vorgeschlagene gemeinsame Lightning-Schnittstelle für Nostr-Schlüssel. NIP-29-Relay-Gruppen erhielten fünf offene Vorschläge zu Banner-Tags, Einladungscodes, Nachrichten-Anpinnen, Gruppenmeldungen über NIP-17-DMs und rollenbasierter Zugriffskontrolle.

Top-Storys

Amethyst ist der dominierende Android-Nostr-Client von Vitor Pamplona. v1.12.0 bündelt die 93 PRs, die als unveröffentlichte Arbeit in Newsletter #25 (NIP-32-Hashtag-Labeling, NIP-F4-Podcast-Bildschirm, Musiktitel, ephemere Signer, On-Chain-Zaps mit NIP-05-Filter) und Newsletter #26 (fortgesetztes NIP-F4, Grundlage für den Tor-Watchdog) behandelt wurden, plus einen umfangreichen neuen Block aus dieser Woche. Die neue Arbeit dreht sich um eine Cashu-/Nutzap-Oberfläche, einen CLINK-Treiber für On-Chain-Zaps, einen Tor-Selbstheilungs-Cluster und die KMP-iOS-Migration.

Unterstützung für NIP-60-Cashu-Wallets und das Rendern von NIP-61-Nutzaps landen in PR #3075, mit einer Guthabenansicht pro Mint (PR #3115) und einer einheitlichen Zahlungskarten-UI (PR #3191), die Lightning-Adressen, On-Chain-Zaps, Cashu-Mints und NWC auf einem einzigen Profil-Zahlungsbildschirm zusammenführt (PR #3185). Ein CLINK-Treiber zur Verifikation von On-Chain-Zaps kommt mit PR #3039, PR #3177 und PR #3182. CLINK ist das Common Lightning Interface for Nostr Keys, dieselbe noffer-Schnittstelle, die Zeus v13.1.0-rc1 diese Woche ausliefert, und Amethyst ergänzt einen Verifikations-Zustandsautomaten, einen Reverify-Treiber und einen Mindestbetrag für On-Chain-Zaps (PR #3030). PR #3201 führt private Notizen ein, indem Kind-1-Antworten an p-getaggte Nutzer gemäß NIP-17 gift-wrapped werden, sodass der Composer je nach Adressierung eine öffentliche Notiz oder eine versiegelte Gruppenantwort erzeugt.

Ein Tor-Zuverlässigkeits-Cluster kommt als vollständiger Selbstheilungs-Stack: PR #3053 hebt Arti auf v2.3.0 mit Watchdog und Integrationstests, PR #3223 hält über Tor geroutete Relay-Verbindungen zurück, bis Tor bereit ist, PR #3224 begrenzt den Arti-Bootstrap mit einem 60-Sekunden-Timeout, damit ein feindliches Netzwerk die Schleife nicht blockieren kann, und PR #3231 heilt sich selbst, wenn Tor aktiv ist, aber jeder Circuit tot ist. Das Ergebnis ist ein Tor-Stack, der sich ohne manuellen Eingriff von Netzwerkwechseln und Sleep-Resume-Zyklen erholt. Phase 1 und Phase 2 der KMP-iOS-Migration kommen mit PR #3047 und PR #3050 und geben iOS-CI für die Module quartz und commons frei, was die Grundlage für einen iOS-Amethyst-Build legt.

Mostro Core v0.13.0 schaltet mit Protokoll v2 den Relay-Mittelsmann aus

Mostro ist eine über Lightning abgewickelte P2P-Bitcoin-Börse, die Nostr als Orderbuch und Kommunikationsschicht für Trades nutzt. v0.13.0 von mostro-core, der Rust-Bibliothek, die das Wire-Protokoll definiert, ersetzt das relay-geroutete Nachrichtenmodell durch das, was das Changelog Protokoll v2 nennt: einen NIP-44-Direkttransport auf Basis von Kind-14-Events. Handelsspezifische Aktionen reisen nun als Kind-14-Nachrichten, gemäß NIP-44 verpackt und an den Trade-Schlüssel gebunden, den der Teilnehmer bei der Auftragserstellung erzeugt hat, ohne die Handelskonversation über öffentliche adressierbare Events zu leiten.

Im früheren Modell lag die gesamte Oberfläche der Handelskonversation für jedes relay offen, das die Events führte. Der direkte Kind-14-Transport hält Auftragsaufbau, Streitfall und Abwicklungsmetadaten zwischen den beiden Parteien und dem Mostro-Daemon, während die relays nur verschlüsselte Umschläge sehen. Neben der Transportänderung bindet v0.13.0 auch den v2-Identitätsnachweis an den Trade-Schlüssel (Commit-Log) und schließt damit eine Klasse von Replay-Risiken gegen das neue Protokoll. Auf der Daemon-Seite machte Mostro v0.17.5 die Anti-Missbrauchs-Kaution optional und für Betreiber konfigurierbar: Vor dem Start bestimmter Trades muss jede Seite unter Umständen eine kleine Kaution sperren, die bei normalem Abschluss zurückgegeben und bei Verzögerung, Nichterscheinen oder Störung verfallen wird. Die Kaution wird auf Ebene des Node-Betreibers aktiviert, nicht netzwerkweit auferlegt, sodass Mostro nicht-kustodial bleibt und jeder Betreiber den Kompromiss zwischen Marktplatzfriktion und Missbrauchsresistenz selbst wählt. Auf der Client-Seite lieferte Mostro Mobile v1.2.8 17 Funktionen zur Unterstützung des neuen Pfades, darunter Bootstrap-Relay-Discovery anstelle fest gepinnter Standard-relays (PR #610), die Maker-Anti-Missbrauchs-Kaution bei der Auftragserstellung als Phase 5 des Kautions-Rollouts (PR #608) und in der Benachrichtigungshistorie mit Kontext gespeicherte Auftragsstornierungen (PR #602). v1.2.9 folgte zwei Tage später und zeigt die Kautionsrichtlinie aus dem Node-Info-Event, sodass ein Nutzer die Kautionsregeln der Mostro-Instanz sehen kann, bevor er einen Auftrag eröffnet (PR #617).

Signet v1.11.0 behebt eine Umgehung der Signaturprüfung bei NIP-17-Adminbefehlen

Signet ist ein Remote-Bunker-Signer mit einer Kill-Switch-Oberfläche, über die ein Administrator den Signer per Nostr in Panik versetzen, wiederbeleben oder prüfen kann, ohne den Host anzufassen. v1.11.0 behebt einen Sicherheitsfehler in dieser Oberfläche, bei dem der NIP-17-Gift-Wrap-Pfad für Adminbefehle nur den behaupteten Autor des unsignierten inneren Rumors prüfte und den signierten Seal nie verifizierte. Da NIP-44-Conversation-Keys symmetrisch sind, konnte ein Angreifer mit ausschließlich öffentlichen Informationen (Signer-Pubkey, Admin-npub, ein Admin-relay) von außen ein Gift Wrap fälschen und jeden Kill-Switch-Befehl ausführen, darunter panic, resumeall oder alive. Der Fix ruft verifyEvent auf dem Seal auf und bindet den Rumor-Autor an die Seal-Signatur, sodass unsignierte Fälschungen jetzt am Eingang abgewiesen werden. Signet-Betreiber sollten zügig aktualisieren; Spezifikation und gepatchter Codepfad zusammen liefern einem Angreifer ein klares Reproduktionsrezept.

Chama v3.2.0 bis v3.5.0 zeichnen den Handelsraum neu und härten den Geldpfad

Chama ist ein Nostr-nativer P2P-Escrow-Client, der Fedimint-Ecash mit 2-von-3-Shamir-Secret-Sharing für serverlose Handelsabwicklung verbindet. Newsletter #26 behandelte die Serie v2.0.0 bis v3.1.0, die die Grenze zur eigenständigen App überschritt und Storefronts pro Verkäufer ergänzte. Die sechs Folge-Releases dieser Woche setzen bei v3.2.0 an und enden am 15. Juni bei v3.5.0. Sie zeichnen die Handelsraum-UI rund um eine einzige Frage pro Sitzplatz neu (was soll ich jetzt tun) und härten den Geldpfad gegen Teilausfälle. v3.2.0 gab Käufer, Verkäufer und Schlichter jeweils eigene farbcodierte Handlungsaufforderungen, sodass jeder Sitzplatz in jedem Handelszustand seinen nächsten Schritt sieht. v3.3.0 verschärfte zwei Konsensregeln in der Handelsmaschine und erforderte koordinierte Client-Übernahme, um wirksam zu werden. v3.3.1 lokalisierte Preise und Zahlungsmethoden auf die Community-Währung des Händlers. v3.4.0 ergänzte fünf Härtungskorrekturen am Geldpfad, damit ein Aussetzer, eine Race Condition oder ein geschlossener Tab den Nutzer nicht stillschweigend Sats kostet. v3.5.0 ergänzte zwei clientseitige Schutzmechanismen rund um die Schlichterrolle, den einen Sitzplatz, der einen Handel sonst unauffällig kippen könnte.

Clave 1.0 geht mit per Push geweckter Hintergrundsignatur in den App Store

Clave ist ein iOS-NIP-46-Remote-Signer, der den privaten Nostr-Schlüssel des Nutzers im iPhone-Keychain hält. Apps fordern Signaturen über einen Ende-zu-Ende-verschlüsselten Kanal an und erhalten den Schlüssel selbst nie. v1.0.0 Build 102 wurde diese Woche beim App Store eingereicht und markiert nach acht Monaten TestFlight-Betas den 1.0-Meilenstein. Das Release liefert per Push geweckte Hintergrundsignatur: Clave kann eine Anfrage entschlüsseln, Berechtigungen prüfen, signieren und antworten, während die App geschlossen ist, sodass die iOS-Vordergrundanforderung, die die Signer-Reaktionsfähigkeit vorher begrenzte, entfällt. Die Verifikation eingehender Signaturen wird mit BIP-340-Schnorr über dem kanonischen NIP-01-Event-Serialisierungsformat (die Basisspezifikation, die definiert, wie jedes signierte Nostr-Event gehasht wird) plus einem Replay-Frischeschutz erzwungen, sodass eine bösartige App kein neu signiertes Event durch den Antwortkanal schmuggeln kann.

Das Release bringt außerdem die aktualisierte NIP-44-Verschlüsselungsschicht mit einem kind-bezogenen Berechtigungsmodell und drei Sensitivitätsstufen, behebt den Grenzfall bei Signaturen mit geringem Vertrauen, in dem eine “jedes Mal fragen”-Anfrage einen Fehler zurückgab, bevor der Nutzer zustimmen konnte, und ergänzt Multi-Account-Pairing, sodass ein App-Pairing über mehrere Identitäten fließen kann. Bunker-Pairings zeigen nun die echte App-Identität über die NIP-46-Connect-Metadaten-Erweiterung, die Clave in PR #2381 vorgeschlagen hat. Der saubere Trennungsablauf nutzt die neue NIP-46-Methode logout, die in PR #2373 gemergt wurde, sodass eine gepaarte App ihre Sitzung ohne manuelles Entkoppeln sauber beenden kann. Vertrauensstufen pro App (Full, Medium, Low) mit Überschreibungen pro Event-Kind, ein Aktivitätsprotokoll für jede Signatur und ein eigener Push-Proxy runden die Oberfläche ab; der Proxy-Stack ist MIT-lizenziert, und die Interop-Matrix pro Client wird in docs/nip46-compatibility.md geführt.

Releases

Amber v6.2.1 ergänzt NIP-46-Logout und senkt den Akkuverbrauch des Signers

Amber ist der dominierende Android-Nostr-Signer. v6.2.1 reduziert den Akkuverbrauch durch relay-Reconnects und WebSocket-Pings, entfernt tote relays aus dem Subscription-Pool und weckt das Gerät nicht mehr beim Aktualisieren der relay-Benachrichtigung. Das Release ergänzt außerdem Unterstützung für die NIP-46-Logout-Methode, sodass Clients Remote-Signer-Sitzungen sauber beenden können (dieselbe Methode, die diese Woche als PR #2373 in die Spezifikation gemergt wurde), und ergänzt das Parsen von Event-Kind 39701 (öffentliches Web-Bookmark), sodass Nutzer Bookmark-Events direkt aus Amber signieren können. Die Einstellungen wurden mit gruppierten Material-3-Karten und eigenen Icons neu gebaut, ein Navigationsabsturz auf dem Bildschirm für Anwendungsberechtigungen wurde behoben, und ein Datenbankverbindungsleck pro Konto wurde durch atomares Anlegen der Datenbanken geschlossen.

Nostur 1.29.0 liefert anonyme Antworten und Remote-Signer-Logout

Nostur ist ein iOS-Nostr-Client von Fabian. 1.29.0-desktop ergänzt Unterstützung für Antworten auf Zap-Belege und für anonyme Antworten. Auf der Signer-Seite verbessert das Release den Verbindungsablauf zum Remote-Bunker, sendet beim Abmelden eines Kontos ein NIP-46-Logout an den Remote-Signer und behebt einen hängenden Spinner, wenn eine Remote-Signer-Verbindung scheitert. Das Release behebt außerdem DM-Ladeprobleme durch Konflikte zwischen DM-relays und App-relays, behebt doppelte Beiträge beim Navigieren zu einer Antwort und zurück und zeigt ein Medien-Thumbnail in Benachrichtigungszeilen.

Citrine v3.0.0 liefert Negentropy, NIP-42-AUTH und Filterung von Onion-relays

Citrine ist ein lokaler Android-relay-Aggregator. v3.0.0 ist ein großer Versionssprung, der NIP-77-Negentropy-Unterstützung für Set-Reconciliation-Syncs, externe Signer und NIP-42-AUTH-Unterstützung im relay-Aggregator sowie das Beachten von NIP-51-Mute-Listen bei Aggregator-Abrufen ergänzt. Der Aggregator begrenzt Abrufe auf drei relays pro Autor mit konfigurierbaren Quell- und Indexer-relays, verwendet zwischengespeicherte Follow-, Mute- und Metadaten über Neustart und Netzwerkwechsel hinweg erneut, pausiert in begrenzten oder eingeschränkten Netzwerken und filtert Onion-relay-URLs, wenn der Outbound-Proxy deaktiviert ist. Reposts, die geschützte Events einbetten, werden abgewiesen, und Mute-Listen sind standardmäßig vor altersbasierter Löschung geschützt.

FIPS v0.4.0-rc1 ergänzt einen Nym-Mixnet-Transport und mDNS-LAN-Discovery

FIPS ist die Implementierung des FIPS-Mesh-Sync-Protokolls. v0.4.0-rc1 ist wire-kompatibel mit v0.3.0, sodass gemischte Meshes interoperieren und kein Flag-Day-Upgrade nötig ist. Das Release ergänzt zwei neue Wege, wie Nodes sich finden und erreichen: einen ausgehenden Nym-Mixnet-Transport mit einer Single-Container-Demo und einem Mixnet-Relay-Beispiel sowie optionale mDNS-/DNS-SD-Discovery im lokalen Netz. Eine neue, nur zählende show_metrics-Abfrage ermöglicht einen Prometheus-Scraper ohne Kosten im Hot Path, und FMP- sowie FSP-Rekey wurden so gehärtet, dass sie bei Paketverlust in beiden Richtungen unterbrechungsfrei bleiben.

Calendar by Formstr v1.6.1 und v1.6.2 ergänzen Benachrichtigungen pro Termin

Calendar by Formstr ist ein NIP-52-Kalender-Client. v1.6.1 ergänzt Benachrichtigungseinstellungen pro Termin (PR #109), sodass ein Nutzer Erinnerungen für jeden einzelnen Kalendertermin aktivieren oder abbestellen kann. v1.6.2 behebt die Anmeldung mit Amber (PR #185), sodass der neue NIP-46-Handshake aus Amber 6.2.x durchgängig funktioniert.

Bitchat v1.5.2 und v1.5.3 härten den Nostr-und-BLE-Transport

Bitchat ist ein Mesh-Chat-Client über Bluetooth und Nostr. v1.5.2 begrenzt iOS-Peer-Benachrichtigungen, um Flooding zu verhindern (PR #972), und härtet Nostr-Validierung und BLE-Announce-Prüfungen (PR #1012), sodass der relay-seitige Nostr-Eingangspfad fehlerhafte Nachrichten nun abweist, bevor sie den lokalen Mesh-Handler erreichen. v1.5.3 ist ein Hotfix für einen Startabsturz durch ein rekursives dispatch_once zwischen NostrRelayManager und NetworkActivationService (PR #1343).

Keep v1.0.5 verlagert die Signer-Policy-Oberfläche in den auditierten Rust-Kern

Keep ist ein Android-Signer, der den keep-Rust-Kern umschließt. v1.0.5 pinnt auf keep v0.4.8 und liefert einen Fix für eine Race Condition bei der Bunker-Initialisierung (PR #296), sodass der Handshake das erste Event unter Last nicht mehr verwirft, füllt den Bildschirm für autorisierte Clients aus dem Bunker-Callback onConnect (PR #291) und konsolidiert den Kill Switch auf eine einzige Quelle der Wahrheit in keep-mobile (PR #284). Der vorgelagerte Rust-Kern brachte am 13. Juni v0.4.9, das die Signer-Policy-Oberfläche für NIP-55 und NIP-46 (Berechtigungsentscheidung, Dauerbegrenzung für sensible Kinds, Ablauf, manipulationssichere Audit-Kette mit HMAC, Trust-on-First-Use für Aufrufer, persistenter Signatur-Ratenbegrenzer) in den auditierten Rust-Kern verlagert, der die Logik vorher in Kotlin duplizierte, plus eine Implementierung des NIP-44-v3-Ciphers; dieser Kern kommt mit dem nächsten keep-mobile-Sprung.

ants ist dergigis Nostr-Such- und Leseprogramm. v0.4.5 ergänzt Artikelkarten-Aktionen für Langform-Beiträge, darunter Artikel-Portal-Links, artikelspezifisches naddr-Teilen, nevent-Kopieren und Zugriff auf das Roh-JSON. Das Artikel-Portal-Set wurde erneuert, indem Habla wiederhergestellt, ausgefallene Ziele ersetzt und das imwald-Portal entfernt wurden. Das Release stellt außerdem das Rendern von Artikel-Fußnoten mit erhaltener Anker-Navigation im Artikel wieder her und wartet beim Wiederherstellen der Anmeldung auf eine relay-Verbindung, bevor das Profil abgerufen wird, sodass der Header-Avatar korrekt auflöst.

Morganite v0.0.3 liefert einen lokalen Blossom-Cache für Android mit Tor auf Abruf

Morganite ist ein neuer lokaler Blossom-Cache für Android von greenart7c3 (dem Autor von Amber und Citrine). Der Cache fungiert als lokaler BUD-08-Mirror, der die am wenigsten genutzten Blobs entfernt, sobald er 1 GB übersteigt. v0.0.3 startet Tor auf Abruf und stoppt es im Leerlauf, um Akku zu sparen, trennt das Nostr-relay nach der Autorensuche, um Hintergrundverbrauch zu stoppen, behebt Akkuverbrauch durch einen ungefilterten logcat-Stream und geleakte HTTP-Clients und gibt ersetzte OkHttp-Clients außerhalb des Main-Threads frei. Das Release ruft außerdem die Inbox-relays des Nutzers ab, bevor es die Blossom-Serverliste abfragt (sodass Blob-Discovery dem Outbox-Modell folgt), und lädt den Blob bei HEAD-Anfragen herunter, wenn er nicht lokal zwischengespeichert ist, was das Aufwärmen des Caches an die tatsächliche Client-Nachfrage bindet.

Coracle 0.6.34 und 0.6.35 beheben NIP-46-Login, veraltete Feeds und Antwort-Umschaltung

Coracle ist ein Nostr-Web-Client von hodlbod. 0.6.34 behebt den NIP-46-Login, einen veralteten Feed-Zustand, in dem sich die Home-Timeline nach einem Ansichtswechsel nicht aktualisierte, und eine Antwort-Umschaltung, die im aktivierten Zustand alles herausfilterte. Das Release baut außerdem Feed- und Listenansichten neu, behebt ein Problem mit dem Safe-Area-Inset von Toasts und verbessert das Laden von Bildern. 0.6.35 ist ein kleiner Nachtrag, der behebt, dass Reposts bei deaktivierten Antworten verborgen wurden, sodass der Repost-Filter den Antwortfilter nicht mehr überdehnt.

Zeus ist eine selbstverwahrende Bitcoin- und Lightning-Wallet mit einer Nostr-Oberfläche für Wallet-Connect- und noffer-Zahlungen. v13.1.0-rc1 ergänzt warteschlangenfreie NIP-47-Nostr-Wallet-Connect-Zahlungen auf iOS (in Zusammenarbeit mit Primal), sodass eine bezahlte NWC-Rechnung nicht mehr in einer Hintergrund-Warteschlange wartet, liefert CLINK-noffer-Zahlungsunterstützung, wobei Zeus Pay für jedes Konto einen CLINK-noffer erzeugt, sodass ein Sender jeden Zeus-Nutzer allein über den Nostr-Schlüssel bezahlen kann, und ergänzt eine Opt-out-Möglichkeit für Nostr-Zaps in Zeus Pay, sodass ein Empfänger den Kind-9735-Belegpfad deaktivieren kann, ohne NWC zu deaktivieren.

Alby Extension v3.14.3 migriert die vom NIP-07-Signer genutzten noble/scure-Krypto-Stacks

Alby Extension ist die Browsererweiterung, die neben ihrer Lightning-Oberfläche NIP-07-Signatur und Nostr Wallet Connect bereitstellt. v3.14.3 migriert die Stacks @noble/curves, @noble/hashes, @noble/ciphers, @noble/secp256k1, @scure/bip32 und @scure/base auf die Majors v2 und v3. Das sind die kryptografischen Bibliotheken, auf die sich der NIP-07-Signerpfad für Event-Signatur und NIP-44-Verschlüsselung stützt, sodass ein Major-Versionssprung das Wire-Format berührt, das die Erweiterung für jede signierte Event-Anfrage eines Nostr-Web-Clients erzeugt.

Mostro Mobile v1.2.8 und v1.2.9 unterstützen Protokoll v2 und zeigen die Kautionsrichtlinie

Mostro Mobile ist der mobile Client für Mostro. v1.2.8 bringt die clientseitige Unterstützung für mostro-core v0.13.0 Protokoll v2 (in der Top-Story oben behandelt) und ergänzt insgesamt 17 Funktionen, darunter die Maker-Anti-Missbrauchs-Kaution aus PR #608, Bootstrap-Relay-Discovery aus PR #610, in der Benachrichtigungshistorie gespeicherte Auftragsstornierungen aus PR #602 und Fiat-Betragsgrenzen im Auftragserstellungs-Bildschirm aus PR #605. v1.2.9 zeigt die Anti-Missbrauchs-Kautionsrichtlinie aus dem Node-Info-Event (PR #617), sodass ein Nutzer die Kautionsregeln der Mostro-Instanz sehen kann, bevor er einen Auftrag eröffnet.

ZapBook Builds 4 bis 27 liefern Multi-Account, Marmot-Schlüsselveröffentlichung und Circle-Neueinladungen

ZapBook ist eine Nostr-native App für soziales Lesen von codeswot für iOS und Android, organisiert um Lesekreise von 1 bis 100 Personen, die Meilensteine teilen und sich gegenseitig Sats als Ermutigung zappen. Zwischen Build 4 am 11. Juni und Build 27 am 15. Juni lieferte das Projekt 17 getaggte Builds und 7 gemergte PRs. Multi-Account-Unterstützung mit fließendem Kontowechsel landete in PR #25, sodass ein Nutzer mehrere Nostr-Identitäten in der App halten und Sitzungen zwischen ihnen migrieren kann. Die initiale Veröffentlichung eines Marmot-Key-Packages (Kind 443) wird nun automatisch beim Abschluss des Onboardings ausgelöst (PR #20), was die Voraussetzung für Gruppennachrichten nur auf Einladung in den Lesekreisen ist. Die Behandlung entfernter Circle-Mitglieder verarbeitet frische Neueinladungen nun korrekt (PR #24) und schließt eine Klasse von Fehlern, bei denen wieder hinzugefügte Mitglieder nach dem Entfernen keine neuen Einladungen erhielten. Die Release-Linie verlagert außerdem ONNX-Embedding-Inferenz in ein Hintergrund-Isolate (PR #19) für semantische Suche im Reader und integriert den NWC-Dienst mit einem APP_ID_SUFFIX für umgebungsspezifische Konfigurationen, sodass ein einziger Hub mehrere ZapBook-Builds bedienen kann.

Alby Hub v1.23.0 behebt NIP-47-Publish für gelöschte Apps und stellt Bitrefill auf NWC um

Alby Hub ist ein selbst gehosteter Lightning-und-Nostr-Hub. Die Nicht-Nostr-Oberfläche von v1.23.0 ist groß (Just-in-Time-Kanäle, eine Cards-Seite für Debitkarten-Aufladungen, ein experimentelles Ark-Zahlungs-Backend und eine Stories-Startseite) und liegt außerhalb des Compass-Rahmens. Auf der NIP-47-Seite beendet das Release die Wiederholungsversuche für NIP-47-Info-Publish bei gelöschten Apps, sodass eine entfernte Verbindung ihr Kind-13194-Info-Event nicht länger weiter veröffentlicht (PR #2391), und entfernt den Bitrefill-Custom-App-Eintrag zugunsten einer standardmäßigen NWC-Verbindung (PR #2420). Die Readonly-Option für App-Store-Apps (PR #2415) verengt die Berechtigungsbereiche für NWC-Apps, die über den Store im Hub veröffentlicht werden.

Ebenfalls veröffentlicht

Kleinere Releases dieser Woche mit Nostr-relevantem Inhalt, aber begrenzter Substanz je Release: Nostria v3.1.48 bis v3.1.50 mit dem fortgesetzten Web-Bookmarks-Rollout sowie Benachrichtigungszuverlässigkeit und Datenbankoptimierung für Event-Threads in v3.1.50; Deepmarks v0.7.0 bis v0.7.5 mit Iterationen am NIP-B0-Social-Bookmark-Client (das Projekt brachte diese Woche auch seinen Website-Link in PR #96 unter); Keep v1.1.1 bis v1.1.4 mit vier Korrekturen für reproduzierbare F-Droid-Builds oben auf dem oben behandelten v1.0.5-Signer-Release; NoorNote v0.11.1, v0.12.0, v0.13.0 und v0.13.1 am Desktop-Notiz-Client; Boris v0.12.2 am Boris-Reader; Nostr Mail Client v0.13.0; Feeder 2.21.1; nak v0.19.13 als leerer Wartungssprung am Nostr-CLI; Hashtree v0.2.68 bis v0.2.71 mit Erneuerung der Gateway-Caches für veränderliche Roots beim hash-tree-adressierten Release-Publisher; NYM v3.72.501 und v3.72.502 mit Sprüngen der auf Nostrify basierenden relay-Implementierung; swift-nostr-client 0.3.0, 0.4.0 und 0.5.0 mit drei Minor-Releases auf Basis von 85 gemergten PRs am iOS-Nostr-Client; lawallet-nwc v0.11.0 mit 18 gemergten PRs an der LaWallet-Nostr-Wallet-Connect-Brücke; sowie Astraea v5.35.59 bis v5.35.62 mit Iterationen am Astraea-Nostr-Client; und die NIP-05-verifizierten Nostr-DM-Bots BTC Recharge und giftcardshop, die dem Projektverzeichnis unter der neuen Kategorie Shops hinzugefügt wurden.

Unveröffentlichte Änderungen

diVine mergt 119 PRs auf den nächsten Kurzvideo-Drop hin

diVine ist ein Nostr-nativer Client für kurze Schleifenvideos, der das Vine-Archiv auf einem Nostr-Backbone wiederherstellt. Das Projekt mergte diese Woche 119 PRs, ohne ein getaggtes Release zu schneiden. Die substanzielle Arbeit an der Nostr-Oberfläche umfasst einen REST-first-Pfad zur Videoveröffentlichung, sodass ein fehlendes relay-OK nicht mehr als Fehler erscheint (PR #5221 und PR #5220), erneutes Filtern der Blocklist in kuratierten und gelikten Rastern, wenn sich die breite Blocklist ändert (PR #5208), Wiederherstellung der DM-Konversationsliste nach einer Regression bei der Neuinstallation (PR #5202), Wiederherstellung der Nostr-Badge-Anzeige auf Profilen (PR #5218) und verlinkte nostr:-Referenzen in Kommentarzitaten (PR #5225). Der Video-Editor-Stack ergänzte Mehrfachauswahl zum Zusammenführen oder Löschen von Clips, eine Pinch-to-Zoom-Leinwand mit einem den Zoom nachführenden Letterbox-Scrim sowie Zuschnitt-, Dreh- und Spiegel-Transformationen für Clips.

Pollerama mergt 15 PRs im Zeitfenster mit einer Signer-Überarbeitung und einer Funktionswelle

Pollerama (Repository formstr-hq/nostr-polls) ist der Nostr-native Umfragen- und Feed-Client der Form*-Familie, Geschwister von Calendar by Form*, das diese Woche v1.6.2 lieferte. Das neueste getaggte Release auf nostr-polls ist v1.6.4 vom März, sodass die Arbeit im Zeitfenster für den nächsten Tag vorgemerkt und noch nicht ausgeliefert ist, doch der Merge-Strom ist dicht: Zwischen dem 9. und 16. Juni landeten fünfzehn Pull Requests, mit Beiträgen von abh3po, geralt-debugs und SIDDHANTCOOKIE. Auf der Signer-Seite ersetzte das Projekt die bestehende Signaturoberfläche in PR #198 und verbesserte den Ersatz in PR #201, und PR #200 verhindert, dass Kind-0-Metadaten-Updates beim Login ausgelöst werden, sodass eine frische Anmeldung kein Profil-Event mehr veröffentlicht, das der Nutzer nicht angefordert hat. Die Funktionswelle umfasst einen Profileditor mit Veröffentlichen aus der Profilansicht (PR #205), einen verbesserten Repost-Ablauf (PR #209) und einen einfacheren Weg zur Themenentdeckung (PR #202). Das nächste getaggte Release nimmt all das auf.

Bibliotheks- und Werkzeugarbeit

NDK PR #375 und die gemergte Arbeit an den Repositories rust-nostr und nostr-tools waren diese Woche ruhig, mit je einem oder zwei gemergten PRs und ohne getaggte Releases. Die Aktivität bei ContextVM SDK (1 gemergter PR), mesh-llm (37 gemergte PRs, 8 offene PRs), Zap Cooking (26 gemergte PRs) und Routstrd (2 gemergte PRs) lief im Zeitfenster ohne Release-Tag weiter.

NIP-Updates und Protokoll-Spezifikationsarbeit

Die Protokollarbeit dieser Woche bündelt sich an zwei Stellen: Signer-Härtung und NIP-29-Gruppenverwaltung.

Diese Woche gemergt:

  • NIP-46 (Nostr Connect). PR #2373 ergänzt eine logout-Methode, mit der ein Client eine Remote-Signer-Sitzung sauber beenden kann. Amber, Clave und Nostur lieferten in derselben Woche Unterstützung.
  • NIP-CC (Community Chat). PR #2365 aktualisiert NIP-CC, sodass es für die clientseitige Mechanik auf die moderne Spezifikation NIP-GC (Group Chat) verweist, und richtet die Community-Raum-Spezifikation am kanonischen Gruppenchat-Primitiv aus.

Offener NIP-29-Cluster (relay-basierte Gruppenverwaltung):

  • Banner-Tags. PR #2383 ergänzt einen banner-Tag im Gruppen-Metadaten-Event Kind 39000.
  • Einladungscode-Suffix. PR #2380 führt ein Einladungscode-Suffix am Gruppenidentifikator ein, sodass eine Einmal-Einladung in der Gruppen-ID selbst kodiert werden kann.
  • Nachrichten-Anpinnen. PR #2379 ergänzt eine Moderationsaktion zum Aktualisieren der Pin-Liste und ein Kind-39005-Event, um das angepinnte Set zu verbreiten.
  • Gruppenmeldungen über NIP-17-DMs. PR #2377 definiert einen Meldeablauf, bei dem Mitglieder Gruppenmissbrauch über NIP-17-gift-wrapped DMs an den administrativen Kontakt des relays melden, sodass Moderationsverkehr aus dem öffentlichen Gruppen-Event-Stream bleibt.
  • Rollenbasierte Zugriffskontrolle. PR #2376 ergänzt eine RBAC-Rollenoberfläche über der bestehenden Trennung von Admin und Mitglied.

Offene NIP-46-Nachträge:

  • Client-Metadaten in der Connect-Anfrage. PR #2381 erlaubt dem verbindenden Client, optionale Felder name, url und icon in seiner Connect-Anfrage zu senden, sodass der Signer die Identität der Anwendung auf dem Pairing-Bildschirm anzeigen kann. Clave Build 101 implementiert den Vorschlag.
  • Stille Timeouts vermeiden. PR #2375 verschärft die Spezifikation, sodass ein Signer, der Nutzereingaben braucht, die Anfrage offen hält, bis der Nutzer entscheidet, und behebt damit den Fehlerfall, den Clave Build 100 auf der Implementierungsseite gepatcht hatte.

Weitere offene Arbeit:

  • NIP-100 Sovereign Agent Identity Network (SNIN). PR #2378 schlägt ein Agent-zu-Agent-Protokoll für Identität und Fähigkeitsentdeckung autonomer Agenten vor. Der Vorschlag ist breit angelegt und wird im Review wahrscheinlich in kleinere Teile aufgeteilt.

Blossom-Spezifikation. BUD-00 PR #108 wurde am 15. Juni gemergt und weitet die BUD-Definition aus, sodass sie auch clientseitige Konventionen und Datenformate abdeckt, die auf Blossom-Blobs aufbauen und von Servern nicht implementiert werden. Die Änderung zieht BUDs wie BUD-10 (das blossom:-URI-Schema) und BUD-08 (Konventionen für lokale Caches, die Morganite diese Woche implementiert) in die kanonische Nummerierung, wo sie vorher als Erweiterungen außerhalb des Bandes behandelt wurden.

NIP Deep Dive: NIP-77 (Negentropy)

NIP-77 definiert ein Set-Reconciliation-Protokoll für Nostr-relays. Zwei Parteien (ein Client und ein relay oder zwei relays in einer Brücke) halten jeweils eine Menge von Events, die einem Filter entsprechen, und wollen zur Vereinigung konvergieren, ohne alles erneut zu senden. Der naive Ansatz wäre, alle Event-IDs über die Leitung zu schicken und zu vergleichen; bei einem stark frequentierten Filter skalieren diese Kosten mit der Größe der größeren Menge, unabhängig davon, wie stark sich die Mengen unterscheiden. NIP-77 senkt diese Kosten auf ein Maß proportional zur symmetrischen Differenz.

Die Spezifikation setzt auf zwei relay-Nachrichten auf, NEG-OPEN und NEG-MSG. Ein Client eröffnet eine Reconciliation-Sitzung mit ["NEG-OPEN", <subscription_id>, <filter>, <initial_message>], wobei <initial_message> eine hex-kodierte Negentropy-Nutzlast ist, die die Sicht des Clients auf die Menge beschreibt. Antworten kommen als NEG-MSG-Frames, und beide Seiten tauschen Nachrichten aus, bis sie einen Fixpunkt erreichen. Jedes NEG-MSG verengt entweder die Unstimmigkeit (indem ein Bereich in Unterbereiche mit eigenen Fingerprints geteilt wird) oder beendet ein Blatt (indem die IDs in einem kleinen Bereich aufgelistet werden, sodass der Empfänger die Differenz direkt berechnen kann). Wenn eine Seite feststellt, dass die andere Events hat, die ihr fehlen, sendet sie ein normales REQ für diese IDs; wenn sie Events hat, die der anderen fehlen, überlässt die Spezifikation den Upload-Pfad einer normalen EVENT-Veröffentlichung auf der anderen Seite.

Die darunterliegende Datenstruktur ist eine Variante eines sequenzierten Merkle-Baums. Jedes Event der lokalen Menge wird über (created_at, id) verschlüsselt und in Bereiche einsortiert; jeder Bereich trägt einen kleinen Fingerprint, berechnet aus den enthaltenen IDs. Stimmt ein Fingerprint zwischen Client und relay überein, ist dieser Bereich konvergiert und wird übersprungen. Weicht er ab, teilt die antwortende Seite den Bereich in Hälften (oder Unterbereiche) und sendet Fingerprints für jeden, wobei sie in die Unstimmigkeit hinein rekursiert. Blattbereiche (unterhalb einer kleinen Event-Schwelle) werden wortwörtlich gesendet. Die entscheidende Eigenschaft: Konvergierte Bereiche zu bestätigen kostet fast nichts, egal wie viele Events darin liegen.

Die Rahmung in created_at-Reihenfolge ist aus zwei Gründen wichtig. Erstens nutzt Nostrs bestehende Paginierung until und since gegen denselben Zeitstempel, sodass ein Reconciler über Sitzungen hinweg fortsetzen kann, ohne das ganze Archiv neu zu synchronisieren: Er cacht die obere Grenze und startet den nächsten Sync dort. Zweitens sind Bereichsteilungen bei sortiertem Schlüssel deterministisch, sodass Client und relay sich immer über die nächste Grenze einig sind, ohne separate Verhandlungsnachricht. Die Kosten eines Syncs liegen etwa bei O(d log n), wobei d die Größe der symmetrischen Differenz und n die größere Menge ist, weit unter den O(n)-Kosten eines naiven ID-Dumps und weit unter den O(n) Roundtrips beim Absetzen von N REQs.

Drei Implementierungs-Kompromisse verdienen Aufmerksamkeit. Die Fingerprint-Größe (die Spezifikation nutzt 32 Byte pro Bereich) ist ein Kompromiss zwischen Kollisionswahrscheinlichkeit und Bandbreite: Kleinere Fingerprints sparen Bytes, erhöhen aber die Chance einer falschen Übereinstimmung, die Events verliert. Die Blatt-Schwelle (wann das Teilen endet und IDs wortwörtlich gesendet werden) ist ein Kompromiss zwischen Roundtrips und Bandbreite pro Nachricht: Kleinere Schwellen bedeuten mehr Runden, größere Schwellen größere Blattnachrichten. Und das Protokoll setzt voraus, dass beide Parteien denselben Fingerprint über denselben Bereich berechnen können; das erfordert eine stabile Serialisierung der (created_at, id)-Paare, auf die sich beide Implementierungen einigen, weshalb die Spezifikation bei der Byte-Reihenfolge in der Fingerprint-Konstruktion pedantisch ist.

Ein relay, das NIP-77 in seinem NIP-11-Feld supported_nips bewirbt, lässt Clients anstelle eines (oder neben einem) regulären REQ-Syncs abgleichen. Der Client wählt das Protokoll nach Bedarf: Eine frische Subscription, die Tail-Traffic will, nutzt REQ, weil kein Vorzustand zum Abgleich existiert; ein länger laufender Mirror, der nach einer Ausfallzeit aufholen will, nutzt NEG-OPEN, weil die symmetrische Differenz relativ zum Archiv klein ist. Die beiden Pfade ergänzen sich in unterschiedlichen Einsatzkontexten.

Beispielhafter NEG-OPEN-Austausch:

→ ["NEG-OPEN", "sync-1", {"kinds":[1],"authors":["abc..."]}, "<hex initial Negentropy message>"]
← ["NEG-MSG", "sync-1", "<hex relay response>"]
→ ["NEG-MSG", "sync-1", "<hex client refinement>"]
← ["NEG-MSG", "sync-1", "<hex leaf with IDs the relay has and client lacks>"]
→ ["REQ", "fetch-1", {"ids":[...]}]
← [...EVENT messages...]
← ["EOSE", "fetch-1"]
→ ["CLOSE", "sync-1"]

Citrine v3.0.0 liefert diese Woche NIP-77-Unterstützung im relay-Aggregator, das erste Mal, dass die lokale Android-relay-Oberfläche gegen externe relays abgleichen kann, anstatt REQ-Massenabrufe zu nutzen.

NIP Deep Dive: NIP-61 (Nutzaps)

NIP-61 definiert Peer-to-Peer-Cashu-Ecash-Zahlungen, die als Nostr-Events geliefert werden. Ein Sender veröffentlicht ein Cashu-Token, das an den aus Nostr abgeleiteten öffentlichen Schlüssel des Empfängers gebunden ist, und der Empfänger löst es beim Mint ein, wann es passt. Anders als NIP-57-Zaps, die erfordern, dass der Empfänger im Moment der Zahlung über Lightning erreichbar ist, ist ein Nutzap ein in sich geschlossenes Ecash-Token, das der Empfänger nach eigenem Zeitplan einlösen kann.

Die Spezifikation kombiniert drei Event-Kinds mit Cashus P2PK-Sperrprimitiv. Kind 10019 ist die Mint-Empfehlung des Empfängers: ein replaceable Event, das ein oder mehrere Mints auflistet, von denen der Empfänger Nutzaps annimmt, plus den Cashu-Public-Key, mit dem Proofs an ihn gesperrt werden. Dieser Schlüssel unterscheidet sich vom Nostr-Identitätsschlüssel des Empfängers; er ist ein wallet-bezogener Schlüssel, der für den Nutzap-Empfang abgeleitet wird, sodass der Identitätsschlüssel niemals Ecash-Geheimnisse berühren muss. Sender lesen Kind 10019 vor dem Senden, damit das konstruierte Token eines ist, das der Empfänger bei einem Mint einlösen kann, dem er bereits vertraut.

Kind 9321 ist das Zahlungs-Event. Es trägt einen oder mehrere Cashu-proof-Tags (jeder mit einem P2PK-gesperrten Proof, gebunden an den Nutzap-Pubkey des Empfängers aus Kind 10019), einen u-Tag mit der Mint-URL, optionale e- und a-Tags zur Identifikation einer gezappten Notiz und einen p-Tag für den Empfänger. Der Empfänger erhält das Kind 9321 über seine normale Nostr-Subscription, prüft, dass die Proofs an seinen Nutzap-Pubkey bei einem in seinem eigenen Kind 10019 gelisteten Mint gesperrt sind, entsperrt die Proofs mit dem zugehörigen privaten Schlüssel und hält sie entweder in seiner NIP-60-Wallet oder schmilzt sie zu Lightning. Kind 7375 verzeichnet die eingelösten Proofs in der Wallet-Event-Kette des Empfängers, sodass eine Wallet, die von relays neu synchronisiert, Nutzap-Proofs nicht doppelt gegen dieselbe Quelle zählt.

Das Vertrauensmodell ist der ausdrückliche Preis des Entwurfs. Cashu-Mints halten den zugrunde liegenden Wert; ein bösartiger oder beschlagnahmter Mint kann die Einlösung verweigern. NIP-61 erbt dieses Verwahrungsrisiko von NIP-60 und versucht nicht, es zu beseitigen. Was der Entwurf einbringt, sind offline-fähige Mikrozahlungen mit sofortiger Endgültigkeit: Das Token ist die Zahlung, der Empfänger muss keinen Lightning-Node betreiben oder eingehende HTLCs in Echtzeit annehmen, und ein Sender mit Proofs beim selben Mint kann ohne einen einzigen Netzwerk-Hop zu einem Verwahrer zahlen. Die Kind-10019-Ankündigung ist das Tor auf sozialer Ebene: Sender, die einen Mint außerhalb des vertrauenswürdigen Sets des Empfängers wählen, riskieren ein nicht einlösbares Token, was die Einlöseoberfläche des Empfängers vorhersehbar hält.

Verglichen mit NIP-57 ist auch der Verifikationspfad einfacher. Ein NIP-57-Zap-Beleg ist ein Kind 9735, veröffentlicht vom LNURL-Dienst des Empfängers, was vom Prüfer verlangt, den LNURL-Endpunkt abzurufen und zu bestätigen, dass der Signaturschlüssel des Belegs dem entspricht, was der Endpunkt angegeben hat. Ein Nutzap trägt den kryptografischen Zahlungsnachweis inline (die P2PK-gesperrten Proofs selbst), sodass jeder Prüfer mit den öffentlichen Schlüsseln des Mints die Gültigkeit der Proofs ohne Roundtrip zu einem Dritten bestätigen kann. Der Kompromiss: Nutzap-Verifikation erfordert Verständnis der Keysets des Mints, während NIP-57-Verifikation nur Standard-LNURL-Infrastruktur braucht.

Die beiden Zap-Formate existieren als Ergänzungen nebeneinander. NIP-57-Zaps bleiben die richtige Wahl für Empfänger mit vorhandenem Lightning-Routing und Sender, die in Sats denominieren und Lightning-Abwicklungssemantik wollen. NIP-61-Zaps werden die richtige Wahl für Offline-Empfänger, mikrozahlungslastige Abläufe, in denen Lightning-Gebühren den übertragenen Wert übersteigen, und Clients, die auf Nutzer ohne Lightning-Infrastruktur zielen.

Beispielhaftes Nutzap-Event:

{
  "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
  "created_at": 1750162800,
  "kind": 9321,
  "tags": [
    ["proof", "{\"amount\":21,\"secret\":\"...\",\"C\":\"...\",\"id\":\"...\"}"],
    ["u", "https://mint.example.com"],
    ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3"],
    ["p", "c5d8a4e3b2a1f0e9d8c7b6a5949382716050403020100ffeeddccbbaa99887766"]
  ],
  "content": "Great post!",
  "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Amethyst v1.12.0 liefert diese Woche erstklassiges Rendern von NIP-61-Nutzaps neben seiner NIP-60-Wallet-Oberfläche (PR #3075) und macht Amethyst zum ersten dominierenden Android-Client, der empfangene Nutzaps in der Timeline rendert und Guthabenansichten pro Mint in der Wallet bietet.