Nostr Compass #28 | Nostr Compass

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

Diese Woche: Sprout wird in Buzz umbenannt und veröffentlicht fortan Personas, Teams und Datensätze verwalteter Agenten als Nostr-relay-Events; ein geräteübergreifender Lesestatus und Lesemarkierungen pro Nachricht ersetzen das alte Badge-Frontier-Modell. Napplets von sandwich.farm startet als Protokoll mit Vertrauensgrenze für zusammensetzbare Nostr-Apps, die über Nostr und Blossom verteilt werden. Conduit (ein Marketplace-Monorepo mit drei Nostr-Apps: Käufermarkt, Händlerportal und Store-Builder sowie eigenen NIP- und Spezifikationsverzeichnissen im Repository) mergt 17 PRs zur Härtung des Marketplace-MVP, wechselt standardmäßig zu seinem öffentlichen relay und ergänzt datenschutzfreundliche Analytik. BitBlik liefert ein P2P-Protokoll für den Tausch von BLIK in Lightning über verschlüsselte Nostr-DMs; ein Koordinator rechnet dabei atomar zwischen Fiat und Lightning-Hold-Invoices ab. Amethyst ergänzt den Wallet-, Podcast- und Workout-Start der Vorwoche um Health Connect Workouts, Road Events, einklappbare Antworten, eine klassifizierende relay-Latenzüberwachung und eine Korrektur der macOS-Notarisierung. Amber implementiert die in der Vorwoche vorgeschlagene NIP-46-Erweiterung für Client-Metadaten und zeigt native App-Icons und Identitäten auf Signer-Anfragebildschirmen. Haven startet private Standortfreigabe auf dem verschlüsselten Messaging-Protokoll Marmot. CodeDeck lässt Claude-Code-Sitzungen auf einem Laptop per Smartphone über verschlüsselte Nostr-relays steuern, reduziert das Pairing anschließend auf einen einzigen QR-Scan und ergänzt schließlich die Modellauswahl pro Sitzung. Grain liefert eine importierbare Go-Nostr-Clientbibliothek für das Outbox-Modell. Mostro Core, Wisp samt Dark Wisp, Citrine, FIPS, Kubo (von Eltern kuratierte YouTube-Kanäle und ein obligatorischer, vertrauensgesteuerter Kinderfeed) sowie Pollerama (Web-of-Trust-Score, relay-Engine auf dem Gerät und eine „Personen, die du kennen könntest“-Leiste) veröffentlichen Folgepatches. Unveröffentlichte Arbeit umfasst einen browserbasierten MLS-Koordinator von sandwich.farm, nostters UX-Iterationssprint, Zap Cookings projektübergreifende NIP-46-Korrektur und Composer-Überarbeitung, Shopstrs Cashu-Escrow-Lebenszyklus sowie Änderungen an divine.video und Nostur. Neu erfasst sind Social Agents Prototype, PRana zur Triage von Git-über-Nostr-Issues und routstr-chat. Auf Protokollebene erhält NIP-99 einen Vorschlag für Checkout und Escrow auf dem Event-Graphen, der direkt zu den Commerce-Arbeiten von Conduit, BitBlik und Shopstr passt. Da dies die letzte Compass-Ausgabe im Juni ist, endet sie mit Sechs Jahren Nostr im Juni.

Top-Storys

Amethyst v1.12.1 bis v1.12.6 folgen auf den Start von v1.12.0

Amethyst ließ auf den Start von v1.12.0 in der Vorwoche zwischen Mittwoch und Freitag sechs schnelle Patches folgen. v1.12.1 ergänzt Health Connect Workouts und eine Share-as-Image-Aktion und macht das Tor-Flag Active deterministisch, sodass der Bootstrap-Callback das Gate nicht mehr durch eine Race Condition umgehen kann. v1.12.2 ergänzt Road Events und einklappbare Antworten, v1.12.3 bringt eine klassifizierende relay-Latenzüberwachung samt Dashboard-UI sowie eine Korrektur der macOS-Notarisierung, und v1.12.4 bis v1.12.6 liefern Crowdin-Übersetzungsdurchläufe und eine automatisierte Nennung der Übersetzer.

Sprout wird in Buzz umbenannt und veröffentlicht Personas, Teams und verwaltete Agenten als relay-Events

Sprout, Blocks selbst hostbarer Workspace, in dem Menschen und KI-Agenten in denselben Kanälen zusammenarbeiten und jede Nachricht, Reaktion, jeder Workflow-Schritt, jede Review-Freigabe und jedes Git-Event als signiertes Nostr-Event geschrieben wird, wurde diese Woche in Buzz umbenannt. GitHub leitet den alten Slug block/sprout nun zu block/buzz weiter; Repository, Lizenz und Produktausrichtung bleiben unverändert. Die Berichterstattung über Sprout in früheren Ausgaben bezieht sich durchweg auf dasselbe Projekt.

Neben der Umbenennung erschien umfangreiche Produktarbeit. Personas, Teams und Datensätze verwalteter Agenten werden durch PR #1189 nun als Nostr-relay-Events veröffentlicht. Dadurch kann dieselbe Agentenidentität ohne duplizierten Zustand in mehreren Workspaces und Audit-Logs erscheinen. Ein neues Desktop-Pane zeigt NIP-OA-Owner-Attestations auf Profilen (PR #1198); die Badge-Frontier für ungelesene Channel-Threads wurde durch Lesemarkierungen pro Nachricht ersetzt, damit Zähler geräteübergreifend korrekt bleiben (PR #1178); und der Posteingang erhält Autoren- und Quellenangaben für Reminder-Events (PR #1176).

Temporäre Kanäle laufen nun standardmäßig nach sieben Tagen ab (PR #1182), relay-Overrides pro Agent berücksichtigen zuerst das konfigurierte relay und greifen erst danach auf den Workspace-Standard zurück (PR #1131), und der Windows-Build bündelt jetzt eine vollständige Git-for-Windows-Toolchain für das Shell-Werkzeug (PR #1145).

Napplets: zusammensetzbare Nostr-Apps mit definierter Vertrauensgrenze

Sandwich.farm kündigte diese Woche napplet.run als Protokoll für zusammensetzbare Nostr-Applets oder Napplets an: kleine Programme, die genau eine Aufgabe erfüllen, in Sandbox-Umgebungen laufen und über Nostr und Blossom mit derselben Event-Form wie nsites aufgelöst werden. Das Projekt verteilt sich auf drei Repositories: napplet/web enthält die Webpakete und veröffentlichte beim koordinierten Start 51 Versions-Tags für Unterpakete (@napplet/core, @napplet/sdk, @napplet/nap, @napplet/shim, @napplet/conformance); napplet/naps ist der NAP-Spezifikationszweig mit 15 gemergten PRs; und kehto/web ist die Web-Runtime mit 41 gemergten PRs und einem Playground unter kehto.github.io/web/playground. Der zugehörige Spezifikations-PR ist NIP-5D #2303, eröffnet von dskvr (sandwich.farm).

Die architektonische Grundlage ist eine auf Protokollebene definierte Vertrauensgrenze. Eine Shell vermittelt gefährliche Operationen wie Signieren, Schlüsselzugriff und relay-Schreibvorgänge; eine Runtime übernimmt Implementierung und übergeordnete UX; und Napplets bleiben portabel, wegwerfbar und schwerer von einem einzelnen Host zu vereinnahmen. Napplets können innerhalb derselben Shell miteinander kommunizieren, und das Design vermeidet einen Runtime-Lock-in. Der Autor stellt Napplets in einen Zusammenhang mit NMP von Pablof7z und Tiles von Soapbox als parallele Ansätze für dasselbe Problem. Er weist außerdem darauf hin, dass Amethysts v1.12.6-Unterstützung für NIP-5A und NIP-5D Napplets beim Start mindestens einen ausgelieferten Client gibt. Auch die Vorgeschichte gehört dazu: sandwich.farms früheres napp.run, ein NIP-07-Prototyp für native Apps, und der vom Thorium-Browser abgeleitete dryft beeinflussten das heutige Design, bevor sie eingestellt wurden.

Conduit härtet den Marketplace-MVP und wechselt standardmäßig zu seinem öffentlichen relay

Conduit ist das Marketplace-Monorepo mit drei Apps unter conduit.market (Käufermarkt, Händlerportal und Store-Builder) in der Organisation Conduit-BTC. Es enthält eigene Verzeichnisse nips/ und specs/, die Conduit-spezifische Nostr-Commerce-Primitiven definieren; darunter läuft die Scope-2-khatru-Erweiterung Conduit-BTC/conduit-relay. Beide Repositories wurden Anfang dieses Jahres eröffnet. Diese Woche mergte das Projekt 17 PRs zur Härtung des Marketplace-MVP.

Die ausgelieferten PRs konzentrieren sich auf korrekte Marketplace-Abläufe: Sicherheitszustände für Listings (PR #110) sowie die Härtung von Produktpreisen und Versandzonen auf Händlerseite (PR #115). Auf relay-Seite korrigiert PR #102 die Erkennung von Commerce-Fähigkeiten, PR #112 ignoriert unsichere relay-Hinweise Dritter, und PR #128 setzt die öffentliche Conduit-relay-Domain als Standard für neue Clients. Datenschutzfreundliche Analytik erscheint in PR #109 und PR #129; ein dompurify-Update schließt eine OSV-Warnung (PR #116). Die Arbeit gehört zu einer breiteren NIP-99-Commerce-Welle dieser Woche: PR #2323 schlägt für NIP-99-Märkte eine Checkout-Schicht auf dem Event-Graphen vor, die Bestellablauf, Escrow und Streitfälle abdeckt. Die langjährige Gamma Markets Market Spec, die NIP-99 für vollständigen E-Commerce erweitert, wird zur Spezifikationsschicht, auf der Conduit und andere aufbauen; Shopstr lieferte in derselben Woche einen Cashu-Escrow-Lebenszyklus.

BitBlik startet ein P2P-Protokoll für den Tausch von BLIK in Lightning über Nostr

BitBlik startete diese Woche als auf Nostr aufgebautes Peer-to-Peer-Protokoll für den Tausch BLIK ↔ Lightning. BLIK ist das von polnischen Banken ausgegebene Sofortzahlungssystem. Der BitBlik-Koordinator rechnet atomar zwischen BLIK-Fiat, das Taker zahlen, und von Makern finanzierten Lightning-Hold-Invoices ab; der gesamte Handelslebenszyklus läuft über Nostr. Flutter-App, CLI und Koordinator teilen sich ein core-Paket. Das Projekt wird über das GitHub-Monorepo bit-blik/bitblik, den Web-Build unter www.bitblik.app und die Zapstore-App app.bitblik ausgeliefert.

Das Protokoll nutzt verschlüsselte Nostr-Direktnachrichten (NIP-44) für Client-Koordinator-RPC. Angebote werden als parameterized replaceable Events unter Kind 38383 veröffentlicht, RPC-Requests unter Kind 25195, RPC-Responses unter Kind 25196 und Status-Updates unter Kind 25197. Der Koordinator hält eine Lightning-Hold-Invoice, während ein Taker einen BLIK-Code übermittelt, gibt nach Bestätigung der BLIK-Überweisung das Preimage frei und leitet die Invoice-Abrechnung an den Maker.

Releases mit Tags

Amber v6.2.2 implementiert NIP-46-Client-Metadaten

Amber, der verbreitete, von greenart7c3 gepflegte Android-Remote-Signer für NIP-46, veröffentlichte v6.2.2 in derselben Woche, in der der zugehörige Spezifikations-PR gemergt wurde. Das Release zeigt native App-Icons und die neuen Client-Metadatenfelder auf Anfragebildschirmen und in der App-Liste, persistiert Client-Metadaten bei jeder Verbindung und erfasst beim Verbinden und Akzeptieren Icon und Namen der nativen App. Die Änderung passt direkt zu NIP-46 PR #2381 von DocNR, der Connect-Requests optionale Client-Metadaten hinzufügt, damit Signer einen aussagekräftigen Namen und ein Icon des Anfragenden anzeigen können. Amber v6.2.2 unterstützt außerdem Event-Kind 30618 und trennt im Bildschirm Active relays Standard- und Verbindungs-relays.

Das Release verkleinert die Sicherheitsangriffsfläche des Signers. Entschlüsselte NIP-46-Request- und Response-Bodies gelangen nicht mehr in Logs; Encrypt- und Decrypt-Payloads werden als Chiffretext gespeichert und bei Bedarf entschlüsselt. Sämtliche Logcat-Ausgabe ist an BuildConfig.DEBUG gebunden, Browser-Aufrufer ohne Paket werden immer zu einer Nachfrage gezwungen, und in die Zwischenablage kopierte nsec, ncryptsec und Seed-Wörter werden als sensibel markiert und nach kurzer Verzögerung gelöscht. Explizite Ausschlüsse für Backups und Datenextraktion ergänzen Defense in Depth. Das Release behebt außerdem einen durch verschachteltes Scrollen verursachten Absturz in Active relays, einen LazyColumn-Absturz wegen doppelter Keys durch eine Race Condition bei der Deduplizierung von Bunker-Requests und eine EOSE-Race-Condition bei der Suche nach Release-Updates.

Haven startet private Standortfreigabe auf Marmot

Haven startete diese Woche als private, zensurresistente Standortfreigabe-App für Android und iOS, die auf Nostr mit dem Marmot-Protokoll läuft. Das Repository veröffentlichte innerhalb von vier Tagen fünf Releases von v0.1.0 bis v0.1.4, die ersten Releases eines neuen Projekts. Haven ist in Dart und Flutter geschrieben und wird über Zapstore als entwicklersignierte App veröffentlicht. Marmot, die MLS-basierte Ende-zu-Ende-verschlüsselte Messaging-Schicht für Nostr, liefert Gruppenzustand und Chiffretextverteilung. Haven überträgt dieses Muster vom Messaging auf Standortfreigaben, wobei der verschlüsselte Zustand jeder Gruppe die von ihr freigegebenen Standort-Updates trägt.

CodeDeck: agentengestütztes Remote-Coding über Nostr

CodeDeck startete diese Woche als Oberfläche für agentengestütztes Coding mit mehreren Sitzungen auf Android und Desktop. Die mit Tauri v2, React 19 und einem Rust-Backend gebaute Anwendung lässt Nutzer Claude-Code-Sitzungen auf einem Laptop per Smartphone über verschlüsselte Nostr-relays steuern. Das Projekt veröffentlichte v2026.06.17, v2026.6.18 und v2026.6.20 im selben Zeitraum von vier Tagen. Das Transportmodell verwendet Nostr als verschlüsselte Steuerungsebene: Ein CodeDeck-Smartphone veröffentlicht Befehle als verschlüsselte Events, die eine Bridge neben dem Laptop abonniert; der Laptop veröffentlicht die Sitzungsausgabe über dieselben relays zurück.

v2026.06.17 bettet das FIPS-Mesh nostr-vpn als Android-VPN-Dienst der App ein. So kann ein Laptop von überall Dev-Builds einer App auf einem physischen Testtelefon bauen, installieren, starten und steuern, während CodeDeck die einzige auf dem Testtelefon installierte Software bleibt. v2026.6.18 vereint Pairing und Mesh-Einladung in einem QR-Scan, und v2026.6.20 ergänzt die Modellauswahl pro Sitzung, sodass jede Sitzung mit dem gewählten Modell beginnt.

Grain v0.8.0-rc1 liefert eine vollständige Nostr-Client-Engine

Grain, das von 0ceanSlim gepflegte Go-relay, veröffentlichte v0.8.0-rc1 und ist nun sowohl Nostr-relay als auch die importierbare Go-Clientbibliothek, auf der es aufbaut. Während v0.7.x den Betrieb des relays über einen Browser in den Mittelpunkt stellte, liefert die v0.8-Reihe mit client/core eine eigenständige Nostr-Client-Engine für das Outbox-Modell, geschrieben in reinem Go ohne cgo- oder HTTP-Abhängigkeiten. Die Engine verwaltet einen gemeinsamen relay-Pool, löst die relay-Listen jedes Nutzers auf und routet alle Lese- und Veröffentlichungsoperationen nach dem Gossip-/Outbox-Modell: Notes eines Nutzers werden von seinen Outbox-relays gelesen, und eine veröffentlichte Antwort erreicht die Inbox-relays des übergeordneten Autors. Grains eigenes Web-Frontend ist nun die Referenzanwendung dieser Bibliothek und damit zugleich nutzbare App und ausgearbeitetes Beispiel für nachgelagerte Go-Projekte.

Das Release bringt native NIP-44-Verschlüsselung (v2 und v3), NIP-42-relay-AUTH, NIP-65-, NIP-17-, NIP-51- und NIP-37-relay-Listen, NIP-89-Client-Tags sowie Medienunterstützung für Blossom und NIP-96. Nachgelagerte Go-Apps, die relay-Routing bislang selbst implementieren mussten, können die Engine nun direkt importieren.

Mostro Core v0.13.1 folgt auf Protocol v2

Mostro Core veröffentlichte v0.13.1 als Nachfolger des Protocol-v2-Rollouts der Vorwoche und führt eine Fehlervariante PriceTooStale für den Price-Feed-Vertrag des Protokolls ein. Auf Daemon-Seite liefert PR #752 ungültige Order-IDs als Fehler CantDo(NotFound) an Clients, statt sie still zu verwerfen; PR #785 richtet die innere Protokollversion nach dem aktiven Transport aus; PR #778 bringt Phase 3 des Fiat-Cross-Providers El Toque für CUP und MLC; und PR #782 benennt den NIP-33-Info-Tag protocol_versions zur Angleichung an die Spezifikation in protocol_version um.

Wisp v1.1.2 und die Variante Dark Wisp

Wisp, barrydeens Android-Client in Kotlin und Jetpack Compose, veröffentlichte v1.1.2. Das Release hält Wallet-Teiltransaktionen an den eigenen Account in einer deterministischen Transaktionsreihenfolge getrennt (PR #586), erzeugt Inline-Videoplayer verzögert, damit medienreiche Notes stabil bleiben (PR #592), behebt eine ConcurrentModificationException im Event-relay-Set (PR #595) und korrigiert die intrinsische Größenmessung von Chatblasen-Inhalten, um einen SubcomposeLayout-Absturz zu verhindern (PR #596). Hinzu kommt ein inkrementeller Feedfilter mit Spam-Bewertung außerhalb des Locks. Das Wisp-Team veröffentlichte diese Woche über Zapstore außerdem Dark Wisp v1.1.0, eine Mehrwährungsvariante mit Zap-Zielen für ZEC, DASH, BCH und LTC sowie einem anonymen Modus.

Citrine v3.0.1

Citrine, greenart7c3s lokales Android-Nostr-relay, veröffentlichte v3.0.1 mit einer einzelnen Korrektur: Das Deregistrieren eines nicht registrierten Pokey-Receivers bringt das relay nicht mehr zum Absturz.

FIPS v0.4.0-rc2

FIPS, das Free Internetworking Peering System, taggte v0.4.0-rc2 als Release Candidate zur Paketvalidierung auf Basis des v0.3.x-Wire-Formats. Die v0.4.0-Reihe ergänzt einen Nym-Mixnet-Transport und eine optionale mDNS-LAN-Erkennung für Peer-Erreichbarkeit, überarbeitet die Datenebene für höheren Durchsatz auf einem einzelnen Node und geringere CPU-Kosten pro Paket, verlagert die Operator-Leseoberfläche aus dem Hot Path der Datenebene, damit die Beobachtbarkeit unter Last reaktionsfähig bleibt, liefert eine überarbeitete fipstop-TUI und härtet FMP- und FSP-Rekeying für unterbrechungsfreien Betrieb bei Paketverlust. Dies ist ein Release Candidate; die stabile Version v0.4.0 war vorläufig für den 21. Juni 2026 angesetzt.

Kubo v2026.06.12 und v2026.06.20 sperren den vertrauensgesteuerten Kinderfeed und ergänzen von Eltern kuratiertes YouTube

Kubo, JeroenOnNostrs Nostr-native YouTube-Kids-Alternative auf Basis des Trust Extended Permissions Protocol (TEPP), veröffentlichte diese Woche zwei Releases. v2026.06.12 mit Kalender-Versionierung und abgeleitetem versionCode YYYYMMDD macht den vertrauensgesteuerten Kinderfeed obligatorisch: Jeder Post, jedes Profil, jede Reaktion und jeder Repost, den ein Kind sehen oder mit dem es interagieren kann, läuft nun durch TEPP und ist auf die vom Elternteil zugelassenen Personen begrenzt. Bei neuen Installationen ist das Trust-Gate von Anfang an aktiv, und der Kreis des Kindes wird während des Onboardings angelegt, sodass der Feed bereits beim ersten Start geschützt ist. Das Release bringt außerdem verwalteten Gruppenchat für Eltern, routet Trust-Events an die privaten relays der Familie und schlägt geschlossen fehl, zeigt also nichts an, statt ungeprüfte Inhalte offenzulegen, wenn Trust-Daten nicht geladen werden können.

v2026.06.20 ergänzt von Eltern kuratierte YouTube-Kanäle: Eltern können einen Kanal suchen und dem Kinderfeed hinzufügen, damit Kinder nur Videos aus freigegebenen Kanälen sehen. Ein schneller HTTP-Pfad und optimistische UI ersetzen den etwa zehn Sekunden langen Hinzufügeprozess. Das Release entfernt außerdem die Option, Trust Extended Permissions abzuschalten, da das Projekt auf obligatorischem Vertrauen aufbaut und der Schalter deshalb stets aktiv bleibt; ergänzt eine eigene Support-Seite; korrigiert @mentions im Gruppenchat, sodass beim Taggen der klickbare @name statt eines rohen nostr:npub1… erscheint; ergänzt Autovervollständigung für Erwähnungen; und bindet die Trust-Veröffentlichung an den tatsächlichen Durchsetzungszustand statt an ein Spiegel-Flag. Beide Releases werden über Zapstore als entwicklersignierte Android-App com.kubo.app erfasst.

Pollerama v1.9.0 bis v1.9.4 ergänzen Web-of-Trust-Score, relay-Engine auf dem Gerät und eine „Personen, die du kennen könntest“-Leiste

Pollerama von abh3po, der Nostr-Client für Umfragen und Feeds aus der Form*-Familie unter pollerama.fun, veröffentlichte diese Woche fünf Releases auf Zapstore. v1.9.0 bringt eine neue relay-Engine auf dem Gerät: Ein eingebautes lokales relay speichert alles, was der Nutzer gesehen hat, und beantwortet die App zuerst aus dem lokalen Cache. Dadurch laden Feeds, Profile und Threads sofort, auch offline, und werden im Hintergrund mit dem Netzwerk synchronisiert. Sämtlicher relay-Verkehr, lesend wie schreibend, läuft außerhalb des Hauptthreads durch diese Engine; bereits geladene Notes, Profile, Reaktionen und Zaps kommen direkt aus dem lokalen Speicher, statt erneut abgerufen zu werden.

v1.9.2 behebt, dass Home- und Notes-Feeds sowie Ansichten Following und Network beim Start oder Fortsetzen gelegentlich leer blieben, indem die Follow-Liste unabhängig von der Sync-Engine gecacht wird. In DMs geteilte Notes laden nun zuverlässig, weil die referenzierte Note auch dann über relay-Hinweise abgerufen wird, wenn der Nutzer dem Autor nicht folgt. Ein Network-Einstellungspanel zeigt relay-Verbindungen, Cache-Größe und Sync-Zustand und bietet Steuerelemente zum Neuverbinden oder Löschen des lokalen Caches. v1.9.3 behebt einen Absturz beim Start und eine Regression beim Laden des Home-Feeds.

v1.9.4 führt einen Web-of-Trust-Vertrauenswert auf Profilen ein, der als Netzwerk-Chip zeigt, wie viele der eigenen Follows dieser Person ebenfalls folgen. Hinzu kommt eine „Personen, die du kennen könntest“-Leiste mit Follow-Vorschlägen aus dem eigenen Web of Trust, sortiert danach, wie viele eigene Follows ihnen folgen. Die Network-Einstellungen zeigen nun Größe und letzten Berechnungszeitpunkt des Web of Trust sowie eine Schaltfläche zur Neuberechnung. Trust-Scores und Empfehlungen werden im Hintergrund vom Web-of-Trust-Worker berechnet und blockieren die App nicht.

Kleinere Releases mit Tags

nogringo/nostr-mail-client v0.13.1 stellt den NIP-55-Login über Signer-Apps für Amber, Aegis und Primal wieder her und hört auf, Signer-Apps wiederholt zum Signieren von Kontakten aufzufordern. Cameri/nostream v3.0.0 entfernt unsafe-inline aus der Web-App-Factory und implementiert Script-Nonces. LaWallet NWC v1.0.0 veröffentlicht die erste 1.0 des Projekts mit per QR-Link teilbarer Kartenaktivierung, Erkennung von Remote Wallets und automatischer Bereitstellung einer Lightning Address. Formstr Nostr Calendar v2.0.0 bis v2.0.2 ergänzen eine PWA, beheben replaceable Events im Offlinebetrieb (PR #194) und binden Signer-Methoden, damit das Absenden privater Formulare funktioniert (PR #199). Kleinere Releases von Spl0itable/NYM, codeswot/ZapBook, 77elements/noornote, mattn/nostr-relay, mattn/algia, mouse484/astraea, dergigi/boris, fiatjaf/nak, Spl0itable/nosflare und nostrord/nostrord runden die Woche ab.

Unveröffentlichte Änderungen

Cordn Ad-hoc CVM: ein browserbasierter MLS-Koordinator

Cordn Ad-hoc, sandwich.farms neue Web-App, startete diese Woche öffentlich als MLS-Koordinator, der in einem Browser-Tab für Ad-hoc-Cordn-Gruppen läuft. Das Muster ist ungewöhnlich: Ein Browser-Tab führt den ContextVM-Nostr-Koordinatorprozess aus, veröffentlicht dessen Koordinator-pubkey, empfängt MCP-Requests über Nostr-relays und speichert MLS-Key-Packages, Welcomes, Join-Requests und Gruppennachrichten ohne Backend im Browser-Speicher. Die App verhindert, dass mehrere Koordinatoren mit demselben pubkey gleichzeitig laufen, und stellt Operatoren ein Debug-Log für rohe Nostr-Events, dekodierte Requests und Instanz-Heartbeats bereit.

SnowCait/nostter liefert 19 PRs mit UX-Iterationen

nostter, SnowCaits Nostr-Webclient, mergte diese Woche 19 PRs, ohne ein Release zu veröffentlichen. Der Ersatz von nostrapp.link durch app-manager.nostter.app (PR #2234) und die Aufnahme von deck.nostter.app in die frame-ancestors-Allowlist (PR #2233) bündeln die Oberflächen des Projekts unter der Domain nostter.app. Replaceable Events von Followees werden in IndexedDB gecacht (PR #2231), und der Seen-on-relay-Zustand wird mit getrennten Seen-on- und Via-Optionen wieder reaktiv (PR #2230).

Zap Cooking behebt einen projektübergreifenden NIP-46-Fehler und überarbeitet den Composer

Zap Cooking, der Nostr-Client zum Teilen von Rezepten, mergte diese Woche 16 PRs. Die Änderung mit der größten Reichweite ist PR #452: Primal-Remote-Signer versahen Events mit dem pubkey des Signers, wodurch Uploads, Zaps und Authentifizierung für jeden über Primal gerouteten Client scheiterten. Zap Cooking fand und korrigierte diesen Pfad; der Fix liegt im Client, der Fehler betrifft jedoch den gesamten NIP-46-Bereich. PR #458 baut den Composer mit Countdown-Timer, vereinheitlichter Antwort-/Kommentar-UI und Write-/Preview-Tabs neu. Drei SSR-Korrekturen (PR #460, PR #461, PR #462) sowie PR #454 stabilisieren Profil- und Rezept-Routen. Die Explore-Oberfläche erhält per Drag scrollbarere Zeilen, einen Avatar-Cursor mit Profillink und eine Korrektur für feststehende Community-Tabs (PR #456).

Shopstr liefert einen Cashu-Escrow-Lebenszyklus und Storefront-Werkzeuge

Shopstr, der NIP-99-Marketplace, mergte diese Woche mehrere wesentliche PRs. PR #512 implementiert einen vollständigen P2PK-Cashu-Escrow-Lebenszyklus für den Marketplace. Er gehört zur breiteren Commerce-Welle, die sich in derselben Woche durch NIP-99 PR #2323, den Vorschlag für eine Checkout-Schicht auf dem Event-Graphen, und den Start von Conduit bewegt. PR #543 bringt Lesewerkzeuge zum Auflisten von Unternehmen, Abrufen von Unternehmensdetails und Storefronts sowie Ermitteln der Verkäuferreputation. PR #229 ergänzt das Einfügen von URLs für Profil- und Shopbilder, und PR #359 versieht den Abruf von Marketplace-Statistiken mit einem Zeitstempel.

Arbeiten an divine.video Mobile und Desktop

divine.video, rabbles Client für kurze Loop-Videos mit wiederhergestellten Vine-Archiven, mergte diese Woche PRs zu Wiedergabe und Bearbeitung: Addressable Videos werden im Feed dedupliziert (PR #5465), lokale Nostr-Tag-Filter gleichen nun exakt ab und vermeiden falsche Treffer (PR #5463), der Videoeditor stellt Entwürfe mit Sticker-Ebenen ohne Absturz wieder her (PR #5474), und das Messages-Badge zählt ungelesene Chats mit gefolgten Personen, auf die noch nicht geantwortet wurde (PR #5473).

Nostur liefert NIP-46-Client-Metadaten und Korrekturen für DM-Aktualisierung

Nostur, Fabians iOS-Client, mergte nach dem Release 1.29.0 der Vorwoche vier PRs in das kanonische Repository. PR #74 ergänzt Client-Metadaten in NIP-46-Bunker-Connect-Requests, dieselbe Form, die DocNR vorgeschlagen hat und Amber v6.2.2 diese Woche ausliefert. PR #75 und PR #76 beheben DM-Aktualisierung und Foreground-Recovery nach einem Wechsel des iPhones in den Vordergrund; PR #78 ergänzt QR-Scanning für die benutzerdefinierte NWC-Einrichtung.

Neu erfasst und entdeckt

Social Agents Prototype ist ein experimentelles, auf Nostr aufgebautes KI-Werkzeug für dezentrale Kommunikation zwischen Agenten. Agenten senden atomare Fragen ins Netzwerk, nur relevante Agenten antworten, und jede gesendete oder empfangene Nachricht durchläuft vor der Übertragung ein menschliches Freigabe-Gate. Der Autor ist Sruly Rosenblat. Das Projekt bewegt sich diese Woche im selben Feld agentischer Zusammenarbeit wie Buzz und NIP-100 SNIN, wählt aber eine andere Form: Social Agents Prototype modelliert Agenten als sendende und lauschende Teilnehmer, deren jede Nachricht ein Mensch genehmigen muss. Damit werden mehrere parallele Ansätze für dasselbe Problem sichtbar.

PRana: eine Arbeitsliste für NIP-34-Issues

PRana von DocNR ist eine Arbeitsliste korrekt eröffneter NIP-34-Issues aus opt-in Git-über-Nostr-Repositories. Das Werkzeug liegt eine Ebene über dem Git-über-Nostr-Stack: Es verarbeitet NIP-34-Issue-Events teilnehmender Repositories und stellt sie als Triage-Warteschlange dar. Der Start fällt in dieselbe Woche, in der NIP-34 PR #2384 vorschlägt, den Maintainers-Tag wegen Ablaufproblemen zu entfernen. Das beeinflusst direkt, wie Werkzeuge wie PRana die Autorität für Issues über mehrere Repositories hinweg auflösen.

routstr-chat: lokaler LLM-Zugriff über das Routstr-Protokoll auf Nostr

routstr-chat vom Routstr-Team ist eine vollständig lokale Chatoberfläche, die über das Routstr-Protokoll auf beliebige LLM-Modelle über Nostr zugreift. Das Routstr-Protokoll routet Inference-Requests über auf Nostr veröffentlichte Provider-Ankündigungen (Kind 38421) und rechnet mit Cashu ab, wie in Newsletter #20 beschrieben. Der Chatclient ist die Nutzeroberfläche auf diesem Protokoll: Der Routing-Daemon Routstrd übernimmt Discovery und Bezahlung, während die Chat-App die Konversationsoberfläche bereitstellt.

Protokollarbeit

NIP-Updates

Die NIP-Aktivität dieser Woche war ungewöhnlich hoch: zwei Merges und eine Welle substanzieller offener Vorschläge.

NIP-46-Client-Metadaten erscheinen in Amber und Nostur

NIP-46 PR #2381, den Clave in der Vorwoche vorgeschlagen hatte, besitzt nun ausgelieferte Implementierungen auf beiden Seiten. Amber v6.2.2 liest das neue optionale Feld optional_client_metadata in Bunker-Connect-Requests und zeigt native App-Icons und Metadaten auf Anfragebildschirmen und in der App-Liste. Nostur PR #74 ergänzt das Feld auf Clientseite. Gemeinsam schließen die drei Projekte die Identitätslücke beim Bunker-Pairing: Ein bunker://-Pairing trägt nun dieselben Werte name, url und image, die eine App bereits über nostrconnect:// bekannt geben konnte.

NIP-86 signevent und ein ergänzendes relay-Rollen-Event

PR #2389 von staab mergte eine signevent-Operation in NIP-86, die relay-Verwaltungs-API. Damit können relay-Administratoren NIP-43-Events im Namen des relays verwalten. Der ergänzende offene Vorschlag PR #2390 von staab definiert ein relay-Rollen-Event, über das relays Rollendefinitionen erklären und Administratoren Mitglieder diesen Rollen zuweisen oder daraus entfernen können. Beide PRs sind zur Kombination gedacht: NIP-86 gibt Administratoren die Operationen, das Rollen-Event das Autorisierungsmodell.

NIP-99: Checkout-Schicht auf dem Event-Graphen für Marketplaces

PR #2323 von Colabonate ist der stärkste Verbindungspunkt dieser Woche. Der als Bitte um Designfeedback formulierte Vorschlag identifiziert zwei Lücken im Stack aus NIP-99 und Gamma Market Spec: einen Checkout-Ablauf auf dem Event-Graphen, der Zustand nach „Buy now“, Bestellerstellung, Zahlung und Lieferbestätigung als öffentliche addressable Nostr-Events abbildet, die jeder Client lesen kann; sowie Escrow und Streitbeilegung für Transaktionen, bei denen Web-of-Trust-Signale allein nicht ausreichen, etwa hochpreisige Artikel, erstmalige Gegenparteien, anonyme Marketplaces und physische Lieferung. Der Vorschlag schließt clientübergreifende Silos in Marketplaces so, wie NIP-99 die Silos für Listings schloss. Er erscheint in derselben Woche wie der Start von Conduit mit eigenen Verzeichnissen nips/ und specs/, Shopstr PR #512 mit einem vollständigen Cashu-Escrow-Lebenszyklus, BitBlik mit P2P BLIK ↔ Lightning und eigenen Escrow-Primitiven sowie der Aufnahme des eigenständigen Repositorys Gamma Markets Market Spec in die aktive Beobachtung.

NIP-34: Maintainers-Tag entfernen, um Ablaufprobleme zu lösen

PR #2384 von dhalsim entfernt den Maintainers-Tag aus NIP-34-Repository-Ankündigungen und adressiert Issue #2382. Der Maintainers-Tag besaß keine definierten Ablaufregeln. Nachgelagerte Werkzeuge konnten daher schwer erkennen, ob eine Maintainer-Zuweisung noch maßgeblich war. Die Änderung hat große Reichweite: Sie betrifft flotilla-budabit-Patches, das einzige erfasste NIP-34-Repository mit substanzieller Patch-Aktivität in dieser Woche, die NIP-34-Verteilung des Iris-Teams über acht Repositories, den BitBlik-NIP-34-Mirror, den neuen Amber-NIP-34-Mirror und DocNRs PRana-Arbeitsliste für Issues. Zu den Cross-Reviewern des PRs gehören DanConwayDev (ngit), vitorpamplona (Amethyst), TheAwiteb und chebizarro.

NIP-29-Gruppenzustände (in Arbeit)

PR #2372 von dtonon schlägt ein Modell für Gruppenzustände in NIP-29 vor und wurde als Work in Progress zur Diskussion geteilt. Dies führt die in #27 behandelte Entwicklung von NIP-29 mit einem neuen Modell fort.

NIP-79 Stories und NIP-76 Reels Feed (beide von anaskmh)

Diese Woche erschienen zwei Spezifikationen für Kurzmedien vom selben Autor. PR #2386 schlägt NIP-79 Stories vor: flüchtige Vollbild-Slides mit Fotos, Videos oder Text, die nach 24 Stunden ablaufen. Kind 19 steht für einzelne Slides, Kind 34237 für ein addressable Event mit geordneten e-Tags zur Sequenzierung mehrteiliger Stories und Kind 15750 optional für eine datenschutzfreundliche Seen-by-Bestätigung. PR #2385 schlägt NIP-76 für einen Reels Feed aus Kurzvideos vor. Beide sind parallele Spezifikationen zu dem, was bestehende Videoclients wie divine.video ausliefern, keine Implementierungen davon.

Kind 1111 als Antwort auf Kind-1-Notes

PR #2358 von zhoreeq entfernt aus dem NIP-Korpus die Zeile, die zuvor von Kind-1111-Antworten in Kommentar-Threads (NIP-22) auf Kind-1-Notes abriet (Issue #2250). Der Diff ist klein, die Wirkung breit: Jeder Client, der das Thread-Kommentarformat aus NIP-22 für gewöhnliche Kind-1-Timeline-Notes verwenden möchte, erhält nun ausdrückliche Unterstützung dafür.

Sechs Jahre Nostr im Juni

Die Repository-Geschichte des Juni verfolgt Nostr von den Anfängen des Protokolls bis zu einem Substrat für zusammensetzbare Anwendungen. 2021 passte die Arbeit noch in ein einziges Protokoll-Repository. 2022 wurden der Standardisierungsprozess und die ersten ernsthaften Clients zu getrennten Projekten. Die öffentliche Welle von 2023 machte relays, Zahlungen und reichhaltigere Identitäten dringend; 2024 ersetzte frühe Abkürzungen beim Signieren und Messaging; 2025 trug diese Verträge in private Gruppen, Git-Zusammenarbeit, Medien und Commerce; und 2026 starteten Produkte, die Nostr als eine Schicht in Agenten-Workspaces, Börsen und Entwicklerwerkzeugen verwenden. Die Entwicklung reicht vom Beweis, dass signierte Events über relays transportiert werden können, bis zu dem Punkt, an dem genau das nur noch ein Implementierungsdetail ist.

Juni 2021: Anfänge des Protokolls

Nostr war etwa sieben Monate alt. fiatjafs ursprünglicher Protokollbeitrag und das Repository fiatjaf/nostr enthielten noch fast das gesamte öffentliche Projekt. Eine Handvoll Entwickler konnte jede Änderung prüfen, und die Referenzimplementierung war ein Python-Skript. Dies war noch kein Client-Ökosystem, sondern die These, dass Nutzer Events signieren und relays auswählen könnten, ohne dass eine Plattform ihre Identität zuweist.

Es gab kein eigenes NIPs-Repository. Vorschläge und Implementierungsbeispiele teilten sich deshalb weiterhin die Hauptgeschichte des Protokolls. Dieser kompakte Umfang war in dieser Phase eine Stärke: Neue Implementierer konnten das Protokoll von Anfang bis Ende verstehen. Der Preis war, dass jedes neue Verhalten weiterhin von derselben kleinen Gruppe abhing. Die Aufteilung der Repositories und die Client-Welle von 2022 sollten diese Grenze allmählich beseitigen.

Juni 2022: Das NIPs-Repository entsteht

Mitte 2022 hatte Nostr genügend Vorschlagende, um das im Mai angelegte eigenständige Repository nostr-protocol/nips zu rechtfertigen. Rund zwanzig Spezifikationen deckten nun das grundlegende Event-Format, Follow-Listen, verschlüsselte DMs, relay-Metadaten und Bech32-Identifikatoren ab. Das Verschieben der Dokumente aus dem ursprünglichen Code-Repository änderte die Governance des Projekts: Clients konnten sich unabhängig entwickeln, während gemeinsames Wire-Verhalten explizite Vorschläge und Reviews erhielt.

Die ersten öffentlichen Webclients, darunter Astral und Anigma, liefen in frühen Formen, und William Casarins Damus-Repository bewegte sich auf eine TestFlight-Verteilung zu. Die Nutzerbasis war weiterhin klein und stark von Entwicklern geprägt, doch das System besaß nun zwei sich verstärkende Oberflächen: Mehr Menschen konnten Anwendungen bauen, ohne die Spezifikation zu pflegen, und mehr Menschen konnten die Spezifikation verbessern, ohne den ursprünglichen Client zu besitzen.

Juni 2023: Adoptionswelle nach Damus

Bis Juni 2023 hatte die öffentliche Welle nach Damus’ Start im App Store das technische Problem verändert. Primal und Iris entwickelten für Menschen, die die frühen Protokoll-Chats nicht verfolgt hatten, während strfry Betreibern mit wachsendem Verkehr ein leistungsfähiges relay bot. Das Netzwerk brauchte nicht mehr nur weitere Implementierungen, sondern Clients und relays, die bei zunehmender Zahl von Nutzern, Follows und Event-Verläufen reaktionsfähig blieben.

Die Protokollarbeit konzentrierte sich deshalb auf Routing und Werttransfer. NIP-65-relay-Listen gaben dem entstehenden Outbox-Modell eine portable Quelle der Wahrheit, während NIP-57-Zaps Events und Identitäten mit Lightning-Belegen verbanden. Der Phasenwechsel war praktisch: Identität und Veröffentlichung hatten Nutzer angezogen, doch erst selektives relay-Routing und Wallet-Interoperabilität ließen das größere Netzwerk wie mehr als einen überlasteten öffentlichen Feed funktionieren.

Juni 2024: Signer, Gift-Wrap und die Messaging-Aufrüstung

Bis Juni 2024 verlagerte sich das Signieren aus einzelnen Clients. Die NIP-46-Spezifikation, nsecBunker und Amber gaben Web- und Android-Anwendungen Möglichkeiten, Signaturen anzufordern, ohne den geheimen Schlüssel eines Nutzers zu importieren. Dies kehrte eine frühe Annahme um: Portabilität bedeutete nicht länger, einen nsec in jeden Client zu kopieren, sondern spezialisierte Signer eine Grenze darum durchsetzen zu lassen.

Messaging änderte sich aus demselben Grund. NIP-17 kombinierte NIP-44-Verschlüsselung mit NIP-59-Gift-Wrapping, um die von NIP-04 offengelegten Metadaten zu reduzieren, während NIP-89 Clients Handler für Event-Typen empfehlen ließ, die sie selbst nicht renderten. Diskussionen über MLS-over-Nostr begannen in diesem Umfeld. Datenschutz und Anwendungs-Discovery wurden zu clientübergreifenden Verträgen und bereiteten private Gruppen und reichhaltigere eventspezifische Anwendungen vor, statt dass ein Client jede Funktion zu enthalten versuchte.

Juni 2025: Marmot, Reife von Git über Nostr und der lange Schweif der Clients

Bis Juni 2025 besaß MLS-over-Nostr mit der Marmot-Spezifikation einen formalen Vertrag und mit White Noise eine öffentliche Implementierung. NIP-34-Git-Events, ngit und GitWorkshop waren ebenfalls zu einem nutzbaren Code-Review-Ablauf gereift. Diese Projekte teilten dieselbe Designphase: Sie verwendeten relays zur Koordination, verschoben aber sensiblen Gruppenzustand oder Repository-Objekte in spezialisierte Schichten, statt einen Text-Note-Client als gesamte Anwendung zu behandeln.

Commerce und Medien folgten demselben Muster. NIP-60-Wallets und NIP-61-Nutzaps brachten Cashu-Zustand in portable Events; Wavlake, Divine und NIP-99-Marketplace-Implementierungen verwendeten eigene Event-Kinds für Musik, Video und Listings. Nostr wirkte zunehmend weniger wie „ein soziales Netzwerk“, weil Anwendungen das Identitäts- und relay-Substrat behielten, aber domänenspezifische Speicherung, Zahlungen, Moderation und Darstellung einführten.

Juni 2026: ein Monat voller Starts

Der Juni 2026 brachte Starts, die Nostr als eine Komponente in größeren Produkten behandelten. Buzz eröffnete für Menschen und Agenten ein selbst hostbares Workspace-as-relay-Muster; Napplets definierte eine Vertrauensgrenze für zusammensetzbare Apps über Nostr und Blossom; und Conduit stellte Marketplace-Anwendungen neben eigene Protokolldokumente. Diese Projekte fragten nicht länger, ob signierte Events Zusammenarbeit unterstützen könnten. Sie entschieden, welche Arbeit in Events, Blobs oder lokalen Zustand gehörte und welche Berechtigungen ein Host behalten sollte.

BitBlik verwendete Nostr für einen Peer-to-Peer-Tausch zwischen Fiat und Lightning, CodeDeck transportierte Coding-Sitzungen über verschlüsselte relays, und Haven setzte Marmot außerhalb eines herkömmlichen Messengers ein. Die Entfernung zum Prototyp-Repository von 2021 besteht nicht nur in mehr Projekten. Sie ist ein Wechsel der Abstraktion: Teams konnten mit portabler Identität, relay-Discovery, Verschlüsselung und Zahlungen als vorhandenen Bausteinen beginnen und ihre Designarbeit anschließend in die anwendungsspezifische Schicht darüber investieren.