Nostr Compass #23
Primal 3.5 liefert eine überarbeitete Android-Shell aus, Amethyst fügt Onchain-Bitcoin-Zaps hinzu, White Noise erhält Markdown-Rendering und Deep Links, Keycast besteht ein Security-Audit, und AgentNoise ermöglicht die Steuerung lokaler KI-Coding-Agenten über Marmot-verschlüsselten Chat. Hostr startet eine P2P-Vermietungsplattform auf Nostr mit vier NIP-Entwürfen für Listings, Reservierungen und EVM-basierten Escrow. Angor migriert verschlüsseltes Messaging von NIP-04 zu NIP-44, Dart NDK fügt NIP-77 und einen Web-Signer hinzu, Alby js-sdk v8 liefert nativen NWC-Multi-Relay-Reconnect, und KeyChat schließt eine Forward-Secrecy-Lücke im Signal One-Time-Prekey-Löschen. Auf Protokollseite erreicht Mostros Anti-Abuse-Bond Phase 2, Wisp liefert private Antworten und gift-wrapped Reaktionen, und eine Welle von Namecoin-NIP-05-Implementierungen berührt in einer einzigen Woche ein halbes Dutzend Clients.
Top-Stories
Primal 3.5 für Android
Primal, der Social-Client, gestützt auf seine eigene Caching-Relay-Infrastruktur, lieferte diese Woche 3.5.9 mit einer überarbeiteten Anwendungs-Shell aus. Das Redesign ersetzt die vorherige Navigationsstruktur mit einem aktualisierten Layout und einem neuen Explore-Screen, der der Haupt-Discovery-Oberfläche ein eigenes dediziertes Zuhause gibt. Das Release fügt Audio-Wiedergabe für Link-Vorschauen hinzu, sodass in Notes eingebettete Audiodateien inline abgespielt werden, ohne den Feed zu verlassen. NIP-05-Verifizierungs-Badges erscheinen jetzt inline auf Profilen und machen die Identitätsbestätigung auf einen Blick sichtbar. Die Notification-Filterung wurde überarbeitet und lässt Benutzer eingrenzen, welche Event-Typen ihre Notification-Liste erreichen. Der Editor erhielt besseres Event-Link-Handling, und die zugrunde liegende Datenbankschicht erhielt Stabilitäts-Fixes.
White Noise: Markdown, Deep Links und Audio-Metadaten
White Noise, die Marmot-verschlüsselte Gruppen-Messaging-App, gebaut auf Nostr und MLS (RFC 9420), hatte eine der bisher geschäftigsten Wochen sowohl in Frontend- als auch Backend-Repositories.
Im Frontend fügt PR #665 vollständiges Markdown-Rendering für Chat-Nachrichten hinzu, sodass fett, kursiv, Code-Blöcke und Links jetzt nativ in der Nachrichtenansicht gerendert werden. PR #675 aktiviert den Leave-Group-Flow, der zuvor für Nicht-Letzt-Admins blockiert war, und PR #661 fügt native Deep-Link-Unterstützung für whitenoise:// und whitenoise-staging:// URIs für Benutzer, Chats und Einstellungen hinzu, ohne HTTP-Redirect-Infrastruktur zu benötigen.
Im Backend in whitenoise-rs sorgt PR #835 dafür, dass die Key-Package-Rotation korrekt funktioniert, indem der d_tag-Slot für kind:30443 Veröffentlichungen wiederverwendet wird, was NIP-33 Replaceable-Event-Semantik ermöglicht, sodass aufeinanderfolgende Key-Package-Rotationen das vorherige Event auf Relays ersetzen und nur das aktuelle Key-Package behalten. PR #833 erweitert FileMetadata um optionale duration_ms- und waveform-Felder für Audio-Anhänge, koordiniert mit MDKs PR #300, der dieselben Felder zu MIP-04-Medien-Tags hinzufügt. Ein neuer whitenoise-markdown-Crate (PR #836) ersetzt den vorherigen nostr-sdk-Token-Parser durch eine dedizierte Markdown-Rendering-Bibliothek.
Die Marmot-Protokollspezifikation selbst erhielt einen Security-Fix in PR #68, der ein Sicherheitsproblem schließt, indem HKDF-SHA256 für Bildschlüsselableitungen in MIP-01 explizit spezifiziert wird, wodurch Ambiguität entfernt wird, die zu Implementierungs-Divergenz führen könnte. In MDK bereinigt PR #307 Welcome-Fehlerbegründungen und begrenzt die gespeicherte Länge, was einen separaten Sicherheitsbefund schließt.
Amethyst v1.10.0: Onchain-Bitcoin-Zaps
Amethyst lieferte diese Woche vier Releases aus, wobei v1.10.0 die Schlagzeile war. Das Release fügt Unterstützung für NIP-BC Onchain-Bitcoin-Zaps hinzu und ermöglicht Benutzern, Zaps direkt onchain über Bitcoin-Transaktionen zu senden, zu empfangen und anzuzeigen. Frühere Releases in der Reihe behoben die Blossom-Blob-Erkennung, um nicht-konforme Dateinamen abzulehnen (v1.09.2), patchten ProGuard-Regeln für Desktop-Builds und mergten PR #2977, um Onchain-Bitcoin-Zapper als dedizierte ₿-Zeile in der erweiterten Reaktionen-Galerie anzuzeigen. Ein in Arbeit befindlicher On-Chain-Transaktions-Historien-Screen mit Paginierung landete in PR #2974.
AgentNoise: Coding-Agenten über White Noise steuern
AgentNoise von nvk ist ein Rust-nativer Desktop-Helper, mit dem man ein White-Noise-Telefon als Steuerungsoberfläche für lokale Codex- und Claude-Coding-Agent-Sessions verwenden kann. Das Tool lauscht auf einen oder mehrere White-Noise-Chats, authentifiziert Absender über einen First-Pairing-PIN-Flow und startet lokale Coding-Agenten über den konfigurierten Launcher. Das Senden von /claude <prompt> vom Telefon öffnet eine neue White-Noise-Arbeitssession, benannt nach dem Maschinen-Hostname und einer kurzen Prompt-Zusammenfassung, und streamt dann Fortschrittsupdates und die endgültige Ausgabe zurück in diesen Chat. Es ist bewusst Rust-first gehalten und hält Node aus dem vertrauenswürdigen Bridge-Pfad heraus. Das Projekt erreichte diese Woche v0.1.24 und fügte kürzere Telefon-lesbare Antworten, Job-Referenzen per kurzem eindeutigem Präfix und einen optionalen lokalen Session-Watcher hinzu. AgentNoise treibt die wn- und wnd-CLIs aus marmot-protocol/whitenoise-rs als Subprozesse an, sodass es seinen Nostr-Transport mit dem White-Noise-Client selbst teilt.
Keycast-Security-Audit abgeschlossen
Keycast, der teamorientierte NIP-46-Remote-Signing-Server, der Nostr-Private-Keys verschlüsselt at rest in SQLite speichert, hat im Mai 2026 ein Security-Audit abgeschlossen. Der Härtungsdurchgang adressierte Auth-, Berechtigungs-, Datenintegritäts- und Abhängigkeitsprobleme, und die Ergebnisse sind in AUDIT.md dokumentiert. Änderungen umfassen: NIP-98 HTTP-Auth erfordert jetzt genau einen u Tag und einen method Tag, lehnt veraltete Zeitstempel ab und validiert payload-Hashes; die ALLOWED_PUBKEYS-Allowlist wird exakt geparst und serverseitig durchgesetzt; leere Policies verweigern jetzt standardmäßig Sign/Encrypt/Decrypt-Anfragen; Foreign-Key-Enforcement ist auf SQLite-Verbindungen aktiviert; und verschachtelte App-Routen wie /teams/:id sind serverseitig geschützt. Eine SQL-Migration normalisiert alte Allowed-Kinds-Berechtigungs-JSON beim Start. Das Projekt befindet sich noch in einem frühen Stadium, und das Audit nennt Restpunkte, die vor dem Vertrauen mit echten Teamschlüsseln zu erledigen sind.
Scramble: Marmot-Client für Desktop und Android
Scramble (früher OpenChat) ist ein .NET/Avalonia-Desktop- und Android-Client für das Marmot-Protokoll, das MIPs 00-04 implementiert: KeyPackage-Veröffentlichung (kind:30443), Gruppen-Metadaten mit der NostrGroupData-MLS-Erweiterung, NIP-59 gift-wrapped Welcome-Events (kind:444), ChaCha20-Poly1305 verschlüsselte Nachrichten (kind:445) und Blossom verschlüsselte Medien-Anhänge. Es ist vollständig interoperabel mit White Noise und jedem anderen Marmot-kompatiblen Client.
Das Projekt lieferte diese Woche 13 Releases aus, mit Multi-Device-Unterstützung als Hauptfeature. Jedes Gerät generiert einen eindeutigen KeyPackage-Slot (ein d-Tag auf kind:30443). Beim Start holt Scramble die eigenen KeyPackages des Benutzers von Relays, erkennt Peer-Device-Slot-IDs und fügt sie automatisch bestehenden MLS-Gruppen über den Staged-Commit-Flow hinzu. Auto-Add ist auf Gruppen beschränkt, in denen der aktuelle Benutzer Admin ist; Nicht-Admin-Gruppen werden übersprungen, mit dem Hinweis, den Gruppen-Admin zu fragen. Ein Forward-Secrecy-Disclosure-Banner informiert neu verknüpfte Geräte, dass alte Nachrichten nicht verfügbar sind. Ein Slot-ID-Reconciliation-Durchgang (TryReconcileSlotId) verarbeitet Geräte, die von Pre-Multi-Device-Versionen migriert wurden, indem Relay-KeyPackage-Bytes gegen lokales Schlüsselmaterial abgeglichen werden, um das korrekte d-Tag zu übernehmen. External-Signer-Reconnect für Amber- und NIP-46-Benutzer wurde ebenfalls behoben: der IsConnected-Guard, der den eingebauten Auto-Reconnect von ExternalSignerService blockierte, wurde an allen neun Aufrufstellen in NostrService entfernt.
Hostr: P2P-Vermietungsplattform auf Nostr
Hostr (Quelle) ist eine Peer-to-Peer-Vermietungsplattform, die vollständig auf Nostr aufgebaut ist. Sie deckt den gesamten Airbnb-artigen Flow ab (Suche und Auflistung von Immobilien, Verhandlung von Reservierungen und Zahlungsabwicklung) mithilfe von vier NIP-Entwürfen, die das Projekt parallel zur Anwendung entwickelt.
Das Accommodation-NIP erweitert NIP-99 Classified Listings (kind:30402 aktiv, kind:30403 Entwurf) um unterkunftsspezifische Tags für Typ (room, house, apartment, villa, hotel, hostel, resort), Check-in/Check-out-Zeiten, Mindestaufenthalt und H3-Geospatial-Cell-Indexes für standortbasierte Suche in konfigurierbarer Präzision. Das Reservation-NIP definiert ein vollständiges Verhandlungs- und Lebenszyklus-Protokoll: kind:32122 replaceable Reservierungs-Events tragen eine d Trade-ID, einen Listing-Anker a Tag und Teilnehmer-p-Tags mit Rollen (buyer, seller, escrow); kind:1327 strukturierte Message-Rumors liefern private negotiate-stage Gegenangebote per NIP-59-Gift-Wraps, sodass die Verhandlung von öffentlichen Relays fernbleibt; kind:1326 Append-Only-Transitions-Events erstellen einen öffentlichen Audit-Trail, sobald eine Reservierung committed. Käuferprivatsphäre wird durch temporäre Nostr-Keys pro Trade bewahrt, die über verschlüsselte participant_proof-Tags an die reale Identität des Käufers gebunden sind. Das Escrow-NIP definiert kind:30303 Escrow-Service-Ankündigungen und kind:17388 User-Trust-Deklarationen; die Referenzimplementierung nutzt EVM-Smart-Contracts auf Rootstock, wobei contractBytecodeHash es Clients erlaubt zu verifizieren, dass der deployte Contract mit einer bekannten geprüften Implementierung übereinstimmt. Das Marketplace-Listing-NIP definiert generische Tags, die von allen NIP-99-Marketplace-Profilen geteilt werden, einschließlich instantBook, negotiable, quantity, securityDeposit, cancellationPolicy und maxDisputePeriod. Diese Woche bereitete das Projekt seine App-Store-Einreichung vor und mergte MCP-Client-Identity-Unterstützung für agent-basierte Automatisierung.
Zwei neue Einträge erschienen diese Woche auf der Shakespeare-MiniApps-Plattform: InkPress, ein KI-Magazin-Generator, der strukturierte magazinartige Inhalte als Nostr-Events veröffentlicht, und PressStr, eine Schreib- und Publishing-Plattform für den Soapbox-Stack.
Diese Woche ausgeliefert
ngit v2.4.4
ngit lieferte v2.4.4 aus und fügte ngit sync --trust-server (-t) für Fälle hinzu, in denen ein Git-Server dem Nostr-Zustand voraus ist. Wenn diese Situation erkannt wird, meldet sync die betroffenen Refs und verlangt das Flag, um ein aktualisiertes State-Event zu signieren und zu veröffentlichen; eine nostr.trust-server-domains Git-Config-Einstellung bietet eine mit Semikolon getrennte Allowlist für Server, denen automatisch ohne das Flag vertraut werden soll.
Amber v6.1.0-pre3 fügt PSBT-Signierung hinzu
Amber veröffentlichte v6.1.0-pre3 mit verbessertem Layout für neue App-Verbindungen, Crash-Fixes und einer Select/Deselect-All-Option auf dem Berechtigungs-Screen. PR #438 fügt PSBT-Signing-Unterstützung sowohl über den Intent-basierten als auch über den NIP-46 Relay-basierten Pfad hinzu und erlaubt Amber, Partially Signed Bitcoin Transactions zu signieren, ohne die nsec der anfragenden App preiszugeben.
Wisp v1.1.0 liefert private Antworten und verwirft Amber-Unterstützung
Wisp veröffentlichte v1.1.0 mit privaten Antworten per NIP-17-Gift-Wrap (PR #540), gift-wrapped Reaktionen und DIP-03-Zaps auf private Antworten (PR #543), Auto-Übersetzung für Notes (PR #523) und einer Register-artigen Fiat-Eingabe im Zap-Dialog. PR #541 migriert private Zaps von einem hausgemachten DM-Relay-Klartext-Schema zu DIP-03 mit korrektem DM-Relay-Routing. Derselbe Release-Zyklus entfernte die NIP-55-Remote-Signer-Unterstützung (PR #531), verwarf Amber und andere externe Signer-Integrationen und entfernte das gebündelte lokale Relay (PR #533). Wisp ist ein Nostr-Social-Client für Android.
Calendar by Formstr v1.5.4 behebt Gift-Wrap für neue Teilnehmer
Calendar by Formstr lieferte v1.5.4 aus (das neueste in einer v1.5.2 → v1.5.4 Sequenz). PR #160 behebt einen Bug, bei dem das Bearbeiten eines privaten Kalender-Events mit neuen Teilnehmern das aktualisierte Event mit den neuen pubkeys in p Tags veröffentlichte, aber nie Gift-Wrap-Einladungen an diese Teilnehmer erstellte oder auslieferte, was den Einladungs-Flow für Last-Minute-Ergänzungen brach. PR #156 fügt Fehlerbehandlung rund um die Private-Event-Entschlüsselung hinzu, sodass Clients nicht mehr bei unentschlüsselbaren Events werfen, und PR #138 korrigiert wiederkehrende Event-Zeiten, die über Zeitzonen drifteten.
Applesauce v6.1.0 fügt NIP-34-Git-Casts und NIP-51-Lookup-Relays hinzu
Applesauce veröffentlichte v6.1.0 über seine Pakete hinweg mit signifikanter NIP-34-Unterstützung (Git-über-Nostr): applesauce-common fügt neue GitRepository-, GitGraspList- und FavoriteGitRepos-Casts plus passende Factories hinzu und exponiert User.favoriteGitRepos$, User.gitAuthors$ und User.graspServers$ als reaktive Eigenschaften, sodass Anwendungen die gefolgten Git-Repos, Repo-Maintainer und konfigurierten GRASP-Server eines Benutzers direkt aus demselben User-Objekt auflisten können. Dasselbe Release fügt Unterstützung für NIP-51 kind 10086 Lookup-Relay-Listen hinzu, eine jüngste Ergänzung zur Relay-List-Familie, die verwendet wird, um herauszufinden, wo bestimmte Daten zu finden sind. applesauce-core gewinnt replaceableAddress auf EventCast für NIP-01 Replaceable-Address-Lookup, plus pointer, kind und einen getReplaceableAddressForEvent-Helper und fügt eine timeline$()-Methode zum Basis-User-Cast hinzu. PR #73 behebt Pool-Manual-Methoden, die offline Relays stillschweigend fallen ließen.
Sprout v0.0.16 liefert Sprig-Binary und Huddle-Protokoll v2
Sprout von Block, ein selbstgehosteter Nostr-Relay-basierter Team-Workspace, in dem Menschen und KI-Agenten dieselben Räume und Event-Logs teilen, lieferte v0.0.16 der Desktop-App zusammen mit Rolling Builds des neuen Sprig-All-in-One-Binaries (PR #605) aus, das den ACP-Harness, den Agenten und das Developer-MCP in ein einzelnes Busybox-artiges Binary bündelt, für einfaches Deployment. Das --no-memory-Flag, hinzugefügt in PR #611, erlaubt Betreibern, die NIP-AE-Core-Memory-Injection für den ACP-Harness zu deaktivieren. Auf der Echtzeit-Seite erweitert PR #609 das Huddle-Voice-Protokoll auf einen v2 Frame-Header, der bis zu 10 gleichzeitige Peers unterstützt.
Nostrord v1.0.3 fügt OS-Keychain und Multi-Account hinzu
Nostrord veröffentlichte v1.0.3 mit lokaler Schlüsselspeicherung, gehärtet über OS-Keychain und Passphrase-Fallback, Multi-Account-Unterstützung und einem tappbaren Bunker-QR-Code, der die Signer-App auf Android öffnet.
Angor migriert zu NIP-44 und liefert Security-Hardening aus
Angor, die Bitcoin-Crowdfunding-App auf Basis von Nostr und Taproot, lieferte diese Woche drei instabile Releases aus (v0.2.24, v0.2.25 und v0.2.26) mit einer Reihe von Security-Hardening- und Nostr-Integrations-Änderungen. PR #860 migriert das verschlüsselte Nostr-Messaging von NIP-04 zu NIP-44 und ersetzt das deprecatete XOR-basierte Schema durch ChaCha20-Poly1305-Verschlüsselung. PR #861 erlaubt Blossom-Medien-Uploads ohne ausgewählte Wallet, indem ein ephemerer Nostr-Auth-Key verwendet wird, wodurch Uploads für Benutzer entsperrt werden, die noch keine Wallet verbunden haben. Die Security-Serie adressierte mehrere gehärtete Kategorien: PR #854 fügt Typsicherheit für AngorKey und Mnemonic-Memory-Schutz hinzu, PR #856 erzwingt Protokoll-Level-Validierung für Timelocks, Fee-Rates, Dust-Schwellenwerte und Penalty-Regeln, und PR #851 wendet Non-Breaking-Hardening über acht Kategorien mittleren und niedrigen Schweregrads an. PR #859 behebt GrapheneOS-Kompatibilität, indem AOT-Kompilierung aktiviert und Runtime-Code-Generierung entfernt wird, und PR #855 verhindert Wallet-Verlust bei Android-Swipe-Kill, indem der Wallet-Zustand persistiert wird, bevor das OS den Prozess beendet.
Alby js-sdk v8.0 liefert NWC-Multi-Relay-Reconnect
Alby js-sdk veröffentlichte die v8.0-Linie (v8.0.1 bis v8.0.3) mit NWC-Multi-Relay-Subscription-Unterstützung. PR #516 aktualisiert die nostr-tools-Abhängigkeit und aktiviert nativen Auto-Reconnect über mehrere Relays, ersetzt den vorherigen Polling-Ansatz durch relay-native Reconnection-Logik. PR #542 ersetzt alle console.debug-Aufrufe durch eine injizierbare Logger-Schnittstelle, sodass Anwendungsentwickler SDK-Diagnosen durch ihre eigene Logging-Infrastruktur routen können. Das Release verwirft den WebSocket-Polyfill und erfordert Node.js 22 oder höher für serverseitige Konsumenten. v8.0.2 fügte einen Fix für einen Utils-Crypto-Import-Bug hinzu, der bestimmte Bundler brach.
KeyChat v1.41.1 behebt Forward Secrecy
KeyChat, eine Messaging-App, die das Signal-Protokoll mit Nostr-Relay-Transport kombiniert, veröffentlichte v1.41.1+6513. Der Schlagzeilen-Fix erzwingt Forward Secrecy, indem Signal-One-Time-Prekeys unmittelbar nach einer erfolgreichen Entschlüsselung gelöscht werden, was eine Lücke schließt, in der ein zurückbehaltener Prekey verwendet werden könnte, um vergangene Nachrichten zu entschlüsseln, falls das Gerät später kompromittiert wird. Das Release fügt außerdem URL-Vorschau für Nachrichten hinzu, die aus einem einzelnen Link bestehen, zentralisiert Medien-Auto-Download unter einem neuen FileDownloadManager mit einem 20-MB-Auto-Schwellenwert und refaktoriert das NIP-11-Relay-Info-Fetching, um beim Kaltstart einen Force-Refresh zu erzwingen, sodass Paid-Relay-Fee-Konfigurationen immer korrekt geladen werden.
In Entwicklung
Citrine mergte PR #151 und implementierte NIP-70-Enforcement: das Android-Relay blockiert jetzt Reposts, die geschützte Event-Inhalte einbetten, wie die Spezifikation es verlangt. PR #149 fügt Anzeige- und Kopieraktionen für mehrere Verbindungsadressen, Localhost, lokales WLAN und Tor, vom Relay-Einstellungs-Screen aus hinzu. PR #141 fügt NIP-42 AUTH-Challenge-Handling über externe Signer-Integration mit Amber hinzu.
Mostro erreichte Phase 2 seines Anti-Abuse-Bond-Rollouts. PR #737 landet Solver-directed Dispute-Slash-Logik: Admin-Handler konsumieren jetzt die BondResolution-Payload von mostro-core, wodurch ein Admin bei der Auflösung eines Disputes den Bond einer der Parteien slashen kann. Phase 1.5, gemerged in PR #736, führte eine dedizierte PayBondInvoice-Aktion und einen WaitingTakerBond-Status ein und trennte die Anti-Abuse-Bond-Zahlung des Takers vom Trade-Payout des Käufers. Der Mobile-Client fügte die vollständige Phase-1.5-UX in PR #592 hinzu. Mostro ist ein Peer-to-Peer-Bitcoin-Exchange-Protokoll auf Basis von Nostr.
Damus mergte PR #3773 und stellte den Relay-Signal-Indikator wieder her, und PR #3775 behebt Relays, die sich nach einem anfänglichen Verbindungsfehler nicht wieder verbanden.
rust-nostr mergte PR #1358 und fügte Event-Finalization-Traits und NIP-spezifische Event-Builder hinzu, was es einfacher macht, korrekt typisierte Events für bestimmte Protokollfunktionen zu konstruieren. PR #1363 portiert einen Fix zurück, der sicherstellt, dass der NIP-46-Signer Notifications abonniert, bevor er die Connect-Antwort sendet, was eine Race-Condition schließt, bei der Client-Nachrichten, die unmittelbar nach Connect eintrafen, verpasst werden konnten.
dart-nostr mergte PR #44 und fügte einen Namecoin-.bit-Relay-Resolver und TLSA-Pin-Records hinzu, was Flutter-Anwendungen erlaubt, wss://example.bit/-Relay-URLs über Namecoin-DNS zu ihren tatsächlichen WebSocket-Adressen aufzulösen.
Dart NDK (das Dart/Flutter-Nostr-Development-Kit, jetzt bei relaystr/ndk) mergte PR #464 und implementierte NIP-77, das Offline-Event-Signing-Protokoll. Auf Signer-Seite fügen PR #602 und PR #601 einen web-spezifischen Event-Signer und eine PlatformEventVerifier-Abstraktion hinzu, sodass Flutter-Web-Apps den Plattform-Signer ohne separaten Codepfad nutzen können; PR #604 führt eine Event-Signer-Factory für Runtime-Signer-Auswahl ein. PR #608 fügt getDmRelays() zum Abrufen einer NIP-17-DM-Relay-Liste eines Benutzers (kind:10050) hinzu, und PR #600 behebt die NIP-46 Signed-Field-Preservation, sodass Remote-Signer keine Felder beim Round-Trip verlieren.
Pages by Form* (Repo), Formstrs Nostr-natives kollaboratives Dokument-App, gehostet auf pages.formstr.app, mergte diese Woche vier PRs, die die Encrypted-Attachment- und Dokument-Management-Flows straffen. PR #37 behebt fehlende Bilder in DOCX-, HTML- und PDF-Exports, indem verschlüsselte Anhänge inline eingebunden werden: es holt <encrypted-file>-Blobs von Blossom-Servern, entschlüsselt sie mit AES-GCM 256-Bit unter Verwendung des gespeicherten Schlüssels und Nonce, validiert den Bild-MIME-Typ und konvertiert sie in Base64-Data-URLs, sodass Exports Bilder erhalten, die nur auf Blossom in verschlüsselter Form existieren. PR #39 fügt einen lokalen Dokument-Suchmechanismus hinzu, PR #38 räumt den Rename-Flow auf, und PR #40 behebt Shared-Backup-Handling.
Zap Cooking mergte PR #396, die erste Phase einer Feed-Überarbeitung, die Feed-Rendering-Primitive legt, ohne noch benutzersichtbare Änderungen. Der PR führt einen NIP-92 imeta Tag-Parser ein, der die Slots url, m (MIME), dim (Dimensionen), blurhash, alt, x (File-Hash) und fallback liest, plus einen handportierten kanonischen Blurhash-Decoder (~200 LOC), der PNG-Data-URLs per Canvas mit einem SSR-sicheren Null-Fallback erzeugt. Wenn imeta-Tags fehlen, greift der Parser auf das Extrahieren roher Bild- und Video-URLs aus dem Event-Inhalt zurück und nutzt dieselben Heuristiken, die der aktuelle Feed bereits verwendet.
Nurunuru (ぬるぬる, tami1A84/null--nostr), ein Nostr-Client mit nativen Android-, iOS- und Web-Varianten, die eine Rust-FFI-Engine teilen, mergte seinen v1.5.0 Native → Web Sync in PR #176. Der Sync bringt mehrere Feature-Ergänzungen zum Web-Build, die auf Android v1.4.9 und iOS 1.0.4 bereits ausgeliefert waren: das NotificationModal zeigt jetzt Geburtstagsbenachrichtigungen, Mutual-Follow-Zap-Erkennung und benutzerdefinierte Emoji-Reaktions-Benachrichtigungen; der Reaction-Picker verwirft die Unicode-Default-Reactions-Quick-Row und zentriert die UX auf benutzerdefinierte Emoji; die Empfehlungsmaschine in lib/recommendation.js filtert Benutzer ohne Icons oder Display-Names heraus und priorisiert Following-Einträge, während Recommended im Hintergrund lädt. Spracheingabe ist das eine Feature, das in die andere Richtung geht: der Web-Build verwendet bereits ElevenLabs-Scribe-Streaming, und v1.5.0 synchronisiert die Native-Seite teilweise zum OS-Standard SpeechRecognizer (Android) und SFSpeechRecognizer + AVAudioEngine (iOS), während die vollständige Native-Scribe-Integration auf v1.6 verschoben wird.
Protokoll- und Spezifikationsarbeit
PR #2251 verschärft die NIP-70-Protected-Events-Spezifikation: es wird jetzt explizit festgelegt, dass Reposts, die den vollen Inhalt eines geschützten Events einbetten, von Relays abgelehnt werden müssen. NIP-70 definiert den - Tag, der signalisiert, dass ein Note-Autor der Republikation seiner Note nicht zustimmt. Die ursprüngliche Spezifikation deckte das Verhalten der Relay-Filterung ab, ließ den Repost-Fall aber mehrdeutig. Dieser PR schließt diese Lücke. Citrines PR #151 implementiert die Durchsetzung auf Relay-Seite in derselben Woche.
PR #1653 schlägt ein Drafts-NIP zum Speichern und Synchronisieren privater Draft-Events vor. Der Vorschlag verwendet replaceable Events mit einem draft-Status und NIP-44-Verschlüsselung an den eigenen Key des Autors, wodurch Clients Work-in-Progress-Werke auf Relays speichern können, ohne dass diese Events für irgendjemanden anderes sichtbar sind. Das Draft-Event trägt das vollständige, zur Veröffentlichung vorgesehene Event als verschlüsselten Inhalt, einschließlich seines schließlichen kinds und seiner Tags.
Snapshots (PR #2279) ist ein offener Vorschlag, ein unveränderliches Snapshot-Event zur Bewahrung einer exakten Version eines replaceable Nostr-Events zu definieren. Das Snapshot-Event trägt den vollständigen Inhalt des replaceable Events zu einem bestimmten Zeitpunkt, mit einem a Tag, der zurück zur Adresse des replaceable Events verlinkt, sodass alle historischen Versionen zusammen abgefragt werden können. Das macht es möglich für Beobachter, historischen Zustand zu inspizieren, selbst nachdem Relays alte Versionen nicht mehr aufbewahren.
Namecoin-NIP-05-Welle: Diese Woche gab es einen koordinierten Vorstoß, .bit NIP-05-Auflösung zu Nostr-Clients hinzuzufügen. Der NIP-Diskussions-Feed erfasste Open-Source-PRs gegen Aegis (#14, der Sign-Time-Verifikation beim Signer hinzufügt), nostter (#2128) und dart-nostr (#44), neben einem Upstream-NIP-Entwurf (PR #2349). Der Aegis-PR ist bemerkenswert dafür, die Verifikation auf die Producer-Seite zu setzen: der Signer prüft die Namecoin-Chain, bevor er ein kind:0-Event signiert, das eine .bit-Identität beansprucht, und warnt den Benutzer bei Nichtübereinstimmung, wodurch das Problem erkannt wird, bevor das Event ein Relay erreicht.
NIP Deep Dive: NIP-07 (window.nostr für Web-Browser)
NIP-07 definiert die window.nostr-Schnittstelle, die Browser-Erweiterungen für Webanwendungen bereitstellen. Es ist die am weitesten verbreitete Signer-Schnittstelle im Web, implementiert von Erweiterungen wie Alby, nos2x, Flamingo und horse.
Die Schnittstelle hat zwei erforderliche und mehrere optionale Methoden. window.nostr.getPublicKey() gibt den Public Key des Benutzers als Hex-String zurück, ohne dass der Private Key jemals an die aufrufende Seite freigegeben wird. window.nostr.signEvent(event) nimmt ein partielles Event mit created_at, kind, tags und content entgegen und gibt das vollständige signierte Event zurück, mit hinzugefügtem id, pubkey und sig. Der wichtige Punkt ist, dass der Private Key niemals den isolierten Kontext der Erweiterung verlässt; die Webanwendung reicht ein unsigniertes Event ein und erhält ein signiertes zurück.
Die optionalen Methoden decken Verschlüsselung ab: window.nostr.nip04.encrypt und window.nostr.nip04.decrypt für das ältere NIP-04-Schema (jetzt deprecated) und window.nostr.nip44.encrypt und window.nostr.nip44.decrypt für das aktuelle NIP-44-Schema. Erweiterungen, die NIP-44 unterstützen, können daher sowohl Direct-Message-Verschlüsselung als auch jede andere Anwendung, die pubkey-gebundene Verschlüsselung benötigt, verarbeiten, ohne dass die aufrufende Seite den nsec sieht.
Die Spezifikation enthält auch eine Empfehlung an Erweiterungs-Autoren: Skripte mit "run_at": "document_end" im Erweiterungs-Manifest zu laden, sodass window.nostr synchron verfügbar ist, wenn die Seite lädt, wodurch Race-Conditions vermieden werden, bei denen ein Client window.nostr prüft, bevor die Erweiterung es injiziert hat.
Ein wichtiges Beispiel für NIP-07 in Aktion ist das oben behandelte Keycast-Projekt. Das Keycast-Web-Frontend nutzt NIP-07, um NIP-98-HTTP-Auth-Events zu signieren: die SvelteKit-App handhabt den nsec des Benutzers nie direkt. Sie ruft window.nostr.signEvent auf, um den Auth-Header zu erzeugen, und sendet diesen Header dann an die Keycast-API. Diese Architektur bedeutet, dass das Schlüsselmaterial während des gesamten Team-Key-Management-Flows in der Browser-Erweiterung bleibt.
{
"id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
"pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
"created_at": 1747785600,
"kind": 1,
"tags": [],
"content": "Hello from a NIP-07 signed event",
"sig": "0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2cdd"
}
NIP Deep Dive: NIP-39 (externe Identitäten in Profilen)
NIP-39 definiert, wie ein Nostr-Benutzer die Kontrolle über externe Plattform-Identitäten in seinem Profil deklarieren kann. Jede Deklaration verwendet einen i Tag innerhalb eines kind:10011-Events und behauptet den Besitz eines bestimmten Kontos auf einer anderen Plattform zusammen mit einem Beweis, der unabhängig verifiziert werden kann.
Jedes Tag folgt dem Format ["i", "platform:identity", "proof"], wobei platform:identity den Plattformnamen und den Benutzernamen mit einem Doppelpunkt-Separator kombiniert (github:semisol, twitter:semisol_public). proof zeigt auf ein verifizierbares Artefakt auf der Plattform selbst.
Für GitHub ist der Beweis eine Gist-ID. Der Benutzer erstellt aus seinem GitHub-Konto einen öffentlichen Gist, der den Text Verifying that I control the following Nostr public key: npub1... enthält. Ein Client, der die Behauptung verifiziert, holt https://gist.github.com/<identity>/<proof> und prüft, dass der Gist vom beanspruchten GitHub-Benutzernamen verfasst wurde und den erwarteten pubkey enthält. Für Twitter ist der Beweis eine Tweet-ID, für Mastodon eine Post-ID und für Telegram eine Nachrichten-Referenz in einer öffentlichen Gruppe.
Der Identitätsanbieter-Name darf nur a-z, 0-9 und die Zeichen ._-/ enthalten und darf : nicht enthalten. Identitätsnamen sollten auf Kleinbuchstaben normalisiert werden, wobei der primäre Alias verwendet wird, wenn mehrere existieren.
Die diese Woche stattfindende Namecoin-.bit-NIP-05-Diskussion zeigt die Rolle von NIP-39 im breiteren Identity-Stack: es bietet einen standardisierten, relay-agnostischen Weg, einen Nostr-Key mit einer etablierten Identität andernorts zu kreuzverweisen, ohne eine zentrale Verifikationsstelle zu benötigen. Ein Client kann den Beweis unabhängig verifizieren, indem er ein öffentliches Artefakt auf der benannten Plattform holt, und der Beweis ist an den spezifischen Nostr-pubkey im Gist- oder Tweet-Text gebunden, nicht an eine generische Plattform-Credential.
{
"id": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3",
"pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
"created_at": 1747785600,
"kind": 10011,
"tags": [
["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
["i", "twitter:semisol_public", "1619358434134196225"],
["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"]
],
"content": "",
"sig": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3eff"
}
Das war’s für diese Woche. Wenn du an etwas baust oder Neuigkeiten zu teilen hast, DM uns auf Nostr oder finde uns unter nostrcompass.org.