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

Diese Woche: Amethyst 1.13.1 folgt auf den Start der Nostr-Apps in Version 1.13.0 und bringt NIP-29-Authentifizierung beim Host-relay sowie authentifizierte Wiederholungsversuche für Blossom-Downloads. Code Call hält Remote-Coding-Sitzungen vom Smartphone aus in Gang, GitWorkshop koordiniert Maintainer und die Synchronisierung von Repositories, und Mosaico stellt Coding-Agenten eine gemeinsame Nostr-Schicht für Statusinformationen bereit. Nostrology kartiert, wie Profile Lese- und Schreibaufgaben auf ihre veröffentlichten relay-Listen verteilen. Android-Releases von Mafrend, Hanami und Cordn führen die Releases mit Versions-Tag an, während FIPS eine Zugriffsschicht für OpenWrt ergänzt und ein offener PR eine Portierung auf FreeBSD vorschlägt. Die Protokollberichterstattung behandelt NIPs, BUDs, NAPs, Marmot, Gamma Markets, Concord und NWC, während Sechs Jahre Nostr im Juli die Änderungen im Juli von der frühen Domainauflösung bis zum Zustand von relay-Gruppen nachzeichnet.

Top-Storys

Amethyst 1.13.1 ergänzt nach dem Start seiner Nostr-Apps authentifizierten Zugriff auf Gruppen und Blossom

Amethyst 1.13.0, am 28. Juli für den Android- und Multiplattform-Nostr-Client veröffentlicht, öffnet napplets und NIP-5A-nsites in einem isolierten Browserprozess ohne Schlüsselzugriff. Eine durch Zustimmung freigegebene window.nostr-Brücke kann über das aktive Konto signieren und ausgewählte Funktionen nutzen, während Berechtigungsansichten pro Website und pro Konto Nutzern erlauben, diese Freigaben zu prüfen oder zu widerrufen. Bevorzugte Apps können an der unteren Leiste angeheftet bleiben, ohne Cookies, Anmeldestatus oder Freigaben zwischen Konten zu teilen.

Dasselbe Release 1.13.0 ergänzt Git-Repository-Bäume, Issues und Pull Requests sowie Concord-Communities, NIP-29-relay-Gruppen, Buzz-Gruppenchats, Wiki-Seiten und RSS-Feeds. Über diese Oberflächen kann ein Nutzer unter derselben Nostr-Identität zwischen Code, Community, Publikationen und sozialen Ansichten wechseln.

Auch Zahlungen und Identitätsfunktionen wurden in Version 1.13.0 erweitert. Amethyst kann BOLT12-Angebote erstellen und bezahlen, Remote-Signer-Konten automatisch starten, Blossom-Fallback-Server hinzufügen und die Web-of-Trust-Steuerung für Badges, Communities und relay-Gruppen ausbauen. Das Folgerelease 1.13.1 vom 29. Juli ergänzt ein CORD-02-Auflösungssiegel, die Löschung von Gruppen und Kanälen mit kind 9008, NIP-29-Authentifizierung beim Host-relay und authentifizierte BUD-01-Wiederholungsversuche für zugriffsbeschränkte Blossom-Downloads.

Code Call 0.2.68 ergänzt einen Browser für Worker-Ordner, nachdem 0.2.66 eine Aufholfunktion eingeführt hatte

Code Call 0.2.68, eine Android-Fernsteuerung für Coding-Sitzungen auf einem Computer, ersetzt die bisherige, auf Sonderfälle zugeschnittene Workspace-Liste durch einen Ordnerbrowser, der im Worker-Verzeichnis beginnt. Nutzer können zu verschachtelten zulässigen Ordnern navigieren, einen davon für eine OpenCode-Sitzung auswählen und zu übergeordneten Ordnern zurückkehren; Version 0.2.67 öffnet diesen Browser beim Erstellen einer Sitzung.

Das frühere Release 0.2.66 kann einen zuständigen Worker um eine knappe Zusammenfassung des Stands seit der neuesten Smartphone-Nachricht bitten. Weitere Releases derselben Woche halten mehrere Sitzungen voneinander unabhängig, akzeptieren Antworten nur vom erwarteten Absender und halten den Posteingang für die Zustellung im Hintergrund mit jedem konfigurierten Worker-relay verbunden. Anfragen und Antworten werden als NIP-17 (Private Direktnachrichten) übertragen, während lokal verschlüsselte Blossom-Anhänge nach der Entschlüsselung ihren ursprünglichen Dateityp behalten.

GitWorkshop koordiniert Maintainer und hält die Repository-Synchronisierung unabhängig

GitWorkshops signiertes Release vom 27. Juli ergänzt die Android-Anmeldung über NIP-55 (Android-Signer-Anwendung) für die browserbasierte NIP-34-Forge (git stuff). Das Quell-Repository koordiniert jetzt leitende Maintainer rekursiv, bewahrt die relay-Hinweise jedes Maintainers und hält die Repository-Synchronisierung unabhängig von der Annahme einer Einladung. Repository-übergreifende Verweise auf Arbeitselemente verbinden zusammengehörige Arbeit in verschiedenen Repositories, während GRASP Repository-Daten zu ausgewählten Git-Endpunkten kopiert, ohne diese Übertragung an die Zustellung einer Einladung zu koppeln. Das von einem Entwickler signierte Update 3.1.1 korrigiert die Zustellung von Android-Signer-Intents, die rekursive Auflösung von Maintainern und Repository-Links unter Beibehaltung des Pfads.

Mosaico 0.1.2 lässt Coding-Agenten ihren Status über Nostr teilen

Mosaico 0.1.2 ermöglicht Sitzungen von Coding-Agenten in Claude Code, Codex, Goose, Hermes, OpenCode und Grok, kurze Statusmeldungen über NIP-29 (relay-basierte Gruppen) zu veröffentlichen. Sitzungen können zusammengehörige aktive Arbeiten über Hosts hinweg finden, ohne ihre Transkripte oder ihren Kontext zu teilen.

Die Erkennung benannter Codex-Profile und Gooses Ansicht Top Of Mind machen diese gemeinsamen Statusinformationen in beiden Agentenwerkzeugen sichtbar (PR #618, PR #619). Das Release ermöglicht gehosteten Agenten wieder den Beitritt zur öffentlichen Schicht für Statusinformationen, und die Einrichtung erfordert nun die ausdrückliche Auswahl eines relay (PR #626, PR #629). Mosaico bleibt eine Schicht für Statusinformationen und ist weder Agenten-Host noch Orchestrator oder Werkzeug zur Zusammenführung von Transkripten.

Nostrology kartiert die Konzentration von relay-Listen aus veröffentlichten NIP-65-events

Nostrologys relay-Observatorium leitet seinen Datensatz aus dem neuesten NIP-65-event (Metadaten für relay-Listen) mit kind 10002 jedes Profils ab und folgt dabei der veröffentlichten Spezifikation. Es trennt Lese-, Schreib- und kombinierte relay-Rollen, stellt grafisch dar, wie viele relays jedes Profil aufführt, und zeigt die zugrunde liegenden Zahlen in einer sortierbaren Tabelle. Bei der Veröffentlichungsprüfung am 29. Juli enthielt die Seite 34.430 verschiedene relay-URL-Werte und ordnete 520.468 Profile genau einem aufgeführten relay zu, verglichen mit 150.657 Profilen bei drei und 60.710 bei vier relays.

Derselbe Nostrology-Snapshot zeigt Überschneidungen in der Konzentration: relay.momostr.pink ist in 298.859 Profilen eingetragen, relay.damus.io in 287.181, nos.lol in 279.468 und relay.primal.net in 225.336. Diese Zahlen messen veröffentlichte Einträge in relay-Listen und nicht die Verfügbarkeit: Die Rohdatentabelle kann fehlerhafte URLs und lokale Adressen enthalten, während die NIP-65-Spezifikation Routing-Metadaten definiert und den Zustand von relays nicht prüft. Das Observatorium macht Probleme bei Verbreitung und Datenqualität sichtbar, ohne ein aufgeführtes relay als aktives relay zu behandeln.

Releases mit Versions-Tag

Kairos 0.1.1 ergänzt Erinnerungen und eine lokale Anweisung für Astraea

Kairos 0.1.1 ergänzt Erinnerungen an Fälligkeitstermine, eine ausdrückliche lokale Anweisung für Astraea sowie eine strengere Behandlung von relays und URLs. Das signierte Release 0.1.0 führte den Offline-First-Aufgabenmanager ein, dessen optionale Synchronisierungsschicht mit NIP-44 (Verschlüsselte Nutzdaten) verschlüsselte Datensätze auf vom Nutzer ausgewählte relays schreibt. Kairos verwendet deterministische Aufgabenkoordinaten und verschlüsselte Tombstones mit Löschanfragen nach NIP-09 (Anfrage zur event-Löschung), während rein lokale Aufgaben das Gerät nie verlassen.

Bray 2.3.0 erweitert sein CLI um allgemeines Gift Wrapping und eine lokale Blossom-Testoberfläche

Bray 2.3.0, ein Nostr-SDK und Kommandozeilen-Werkzeugpaket, kann beliebige events über NIP-59 (Gift Wrap) verpacken und auspacken, wobei das Signieren über NIP-46 (Nostr Connect) geleitet wird, wenn ein Bunker den Schlüssel verwahrt. PR #75 versieht außerdem das mitgelieferte Test-relay mit Herausforderungen nach NIP-42 (Authentifizierung von Clients bei relays) und stellt die verbleibenden Blossom-Client-Befehle bereit. PR #77 ergänzt einen speicherinternen BUD-01/02-Server, dessen signierte Autorisierung jeden Upload oder jede Löschung an genau einen Blob bindet, während PR #76 benannte event-kinds, Kurzformen für tags und Flags für den ID-Abgleich nach NIP-77 ergänzt, damit events, die ein Aufrufer bereits besitzt, nicht erneut heruntergeladen werden.

Buzz Desktop 0.5.0 verschärft Einladungen, Suche und Aktualisierungen der relay-Identität

Nach der Berichterstattung der vergangenen Woche über den Workspace von Armada und Buzz ergänzt Buzz Desktop 0.5.0 Einladungslinks mit begrenzter Nutzungszahl (PR #3141) und Suchfilter für Autor, Kanal und Zeitgrenzen (PR #2871). PR #2862 ruft Beitrittsrichtlinien über die native Netzwerkschicht der Desktop-App ab, und PR #2607 veröffentlicht den Identitätsdatensatz eines Agenten erneut, nachdem die Umbenennung einer Persona das relay erreicht hat. Das Release aktualisiert außerdem seine Nostr-Abhängigkeit wegen eines Hinweises auf Remote-Denial-of-Service in NIP-44 und korrigiert die Wiederherstellung des lokalen Speichers, die Positionierung in Threads, die Wiederverbindung zu relays sowie Laufzeitpfade unter Linux und Windows.

Shosho 1.0.0 erweitert seinen Marktplatz für Livestreams

Shosho 1.0.0 gestaltet den Marktplatz für Livestreams rund um Kreative, Live-Sitzungen, Clips und Produkte neu, die Nutzer über eine konfigurierbare relay-Suche finden können. Ein einheitlicher Benachrichtigungs-Feed sammelt nun Erwähnungen, Reaktionen, Reposts und zaps und unterstützt Antworten, ohne den Feed zu verlassen. Zuschauer können Clips aus Livestreams oder Wiederholungen veröffentlichen; außerdem verbessert das Release Thread-Chats, Antworten auf Clips, das Laden von Profilen und die Netzwerknutzung.

Mafrend v1.0 gibt einen Ausblick auf ortsbezogene Nostr-Chats unter Android

Mafrend v1.0 ist die erste öffentliche Android-Alpha einer geplanten App für ortsbezogene Nostr-Chats. Die Projektseite bezeichnet den Funktionsumfang als noch in aktiver Entwicklung und beschreibt jeden Kartenort als eigenen Chatraum für Gespräche rund um einen Ort. Ein öffentliches Release-Repository enthält das installierbare Zapstore-Paket, während die Haupt-App privat bleibt.

Hanami 0.1.0 bietet Blossom-Servern einen durch Signer vermittelten Android-Zugang

Hanami 0.1.0, eine Android-Begleit-App für Blossom-Server, ermöglicht Anmeldung, Upload und Download per Smartphone. Die App verwendet NIP-55 (Android-Signer-Anwendung) für ein Signieren mit Bestätigung und einen nativen Handshake nach NIP-98 (HTTP-Authentifizierung) für die Serversitzung. Hanami beschränkt seine Web-Shell und Signierbrücke auf den Ursprung des ausgewählten Servers, sodass die Zugangsdaten beim Signer verbleiben, während die bestehende Weboberfläche des Servers das Nutzungserlebnis bereitstellt. Das erste öffentliche Release erfordert Android 8 oder neuer, einen erreichbaren Hanami-Server und eine kompatible Signer-App.

Cordn startet seinen Gruppenchat mit Nostr-Identität unter Android

Cordn, ein Client für private Gruppennachrichten, bietet Android-Nutzern nun einen Einstieg mit Nostr-Identität, Profilverknüpfungen über NIP-05 (Zuordnung von Nostr-Schlüsseln zu DNS-basierten Internetkennungen) und verifizierte Links, die Cordn-Ziele in der App öffnen. Das am 24. Juli veröffentlichte Release 0.2.1 führt diese native Produktlinie neben dem bestehenden Webclient ein. Nachrichten verwenden MLS, ein Protokoll zur Gruppenverschlüsselung, mit durch einen Koordinator unterstützter Zustellung, sodass Gruppen geordnete verschlüsselte Unterhaltungen behalten, ohne eine E-Mail-Adresse oder Telefonnummer zu benötigen.

Nostur 1.30.1 korrigiert Threads und doppelte Beiträge, nachdem 1.30.0 die Freigabefunktionen erweitert hatte

Nostur 1.30.1, ein Nostr-Client für iPhone, iPad und Mac, lässt Nutzer durch verschachtelte Antwort-Threads navigieren, ohne dass die Fehler beim Auf- und Zuklappen auftreten, die das neue Layout beeinträchtigt hatten. Es verhindert außerdem, dass derselbe Entwurf zweimal veröffentlicht wird, auch wenn Callbacks beim Medien-Upload wiederholt eintreffen. Das Release folgt auf 1.30.0, das verschwindende Direktnachrichten und einen Weg über das Teilen-Menü ergänzt hatte, um Medien an Nostr zu senden. Damit verbindet die App neue Wege für Nachrichten und Veröffentlichungen mit Korrekturen an den alltäglichen Abläufen für Threads und Beiträge.

Formstr Drive 0.0.2 verbindet Nostr-Dateimetadaten mit Blossom-Blobs

Formstr Drive 0.0.2, ein Nostr-nativer Dateimanager, bietet Nutzern Vorschauen in der App und die Option, Office-Dokumente in Nostr Docs zu öffnen. Im Hintergrund speichert er große Dateien als in Stücke aufgeteilte Blossom-Blobs und löscht den entfernten Blob, wenn ein Nutzer eine Datei entfernt. Ein lokales relay hält die Nostr-Metadaten der App in unmittelbarer Nähe, während Blossom die Dateidaten verwahrt. Dies trennt die Dateiorganisation von den großen Datenmengen selbst.

NoorNote 1.3.1

NoorNote 1.3.1, ein Nostr-Client für Web, Desktop und Android, ergänzt Timer für verschwindende Nachrichten und konfiguriert funktionierende Standard-DM-relays für neu erstellte Konten. Es filtert globale Artikel ohne Titelbild und leitet Repost-Benachrichtigungen in die Artikelansicht. Das vorherige Release 1.3.0 ergänzte Karten für NIP-53 (Live-Aktivitäten), Personen-tags für NIP-68 (Bildorientierte Feeds), einen Soft Mute über NIP-78 (Anwendungsdaten) und einen relay-seen-Status für Notizen.

algia 0.0.133

algia 0.0.133, ein Go-Kommandozeilen-Client für Nostr, folgt auf 0.0.132, das Auflistung, Timelines, Beiträge, Reaktionen, Löschungen sowie Beitritts- und Austrittsabläufe für NIP-29 (relay-basierte Gruppen) ergänzte. Dasselbe Release fügte eine Vorabauthentifizierung nach NIP-42 (Authentifizierung von Clients bei relays) für relays hinzu, die dies laut Konfiguration erfordern. Version 0.0.133 ergänzte anschließend die Befehle für reguläre, Kanal- und Gruppenbeiträge um Uploads lokaler Bilder und hängt die resultierenden URLs sowie tags nach NIP-92 (Medienanhänge) an jedes event an. Auch reine Bildbeiträge funktionieren, und Gruppenbeiträge verwenden standardmäßig den Medienspeicher des Gruppen-relay, während andere Beiträge konfigurierte Dateiserver nutzen.

swift-nostr 0.7.0

Für Swift-Anwendungen ermöglicht swift-nostr 0.7.0, eine Nostr-Bibliothek für Apple-Plattformen, dass ein NIP-46-Remote-Signer über ihre Signierabstraktion sämtliche Client-Funktionen bedient. Das Release ergänzt Unterstützung für NIP-98 (HTTP-Authentifizierung) und NIP-29 (relay-basierte Gruppen), einschließlich Abläufen für Gruppenbeitritt, Beiträge und Moderation. Es validiert außerdem das Padding von NIP-44 (Verschlüsselte Nutzdaten, versioniert) anhand der offiziellen Vektoren und weist Nutzdaten zurück, die einen gültigen MAC für nicht kanonisches Padding enthalten.

lawallet-nwc 2.0.0

LaWallet NWC 2.0.0, ein mit Nostr verbundenes Wallet und ein Dienst für NIP-47 (Nostr Wallet Connect), ergänzt eine Passkey-Anmeldung, die den Nostr-Signierschlüssel im Browser mit der WebAuthn-PRF-Erweiterung ableitet. Der Server erhält dieses Geheimnis nie, und derselbe Passkey kann denselben Schlüssel auf einem anderen synchronisierten Gerät wiederherstellen. Konten können nun mehrere Nostr-pubkeys verknüpfen und zusammenführen, während der optionale Listener-Dienst Wallet-Connect-events weiterleitet und die Webhook-Zustellung nach einem nicht erreichbaren Endpunkt erneut versucht.

MDK 0.9.10

MDK 0.9.10, die Rust-Implementierung des Marmot-Protokolls, bewahrt ausstehende Sendevorgänge, solange ein Transport inaktiv ist, und überwacht die Weiterleitung von relay-Benachrichtigungen, sodass die eingehende Zustellung nach Verzögerung, Panic oder Schließung wiederhergestellt wird. PR #1159 ergänzt einen dauerhaften, paginierten Gesprächsverlauf und den vollständigen Antwortkontext für lokale Agenten, und PR #1167 veröffentlicht das aktuelle signierte KeyPackage-event erneut, statt einen Ersatz zu erzeugen. Das Release bewahrt außerdem die manuelle Chat-Reihenfolge, unterstützt die endgültige Auflösung von Gruppen und erweitert die nach Web of Trust gewichtete Suche, relay-Richtlinien-APIs und Sprachbindungen.

pakstr 0.3.1

pakstr 0.3.1 ermöglicht Webteams, die einen Nostr-Client für Android paketieren, Laufzeitkonfiguration und einen API-Proxy bereitzustellen, ohne die App-Shell neu zu bauen. Seine Release-Serie vom selben Tag ergänzte eine Amber-Signer-Brücke, Ver- und Entschlüsselung nach NIP-44 (verschlüsselte Nutzdaten) und korrigierte die Einfügung von Android-Berechtigungen vor der Arbeit an der Laufzeitkonfiguration in 0.3.x. Das Grundgerüst hält gebündelte Web-Assets lokal, während bereitstellungsspezifische Einstellungen zur Laufzeit bereitgestellt werden, und der Proxy bietet der verpackten App einen kontrollierten Weg für API-Anfragen neben ihren gewöhnlichen relay-Verbindungen.

Ditto 2.34.2

Ditto 2.34.2, ein anpassbarer sozialer Nostr-Client, stellt Nutzerstatus als Karten in Feeds, Detailseiten und eingebetteten Zitaten dar, einschließlich benutzerdefinierter Emojis, Ablaufzeit und optionaler Linkvorschau. Zaps mit Kommentaren erscheinen nun als Antworten unter dem referenzierten Beitrag. Das Release behält außerdem den optionalen Globus-Button auf Profilen aus 2.34.1 für Betreiber bei, die eine Stamm-Website nach NIP-5A (Website-Manifest) veröffentlichen, und korrigiert die Navigation auf der Startseite, die Livestream-Suche, die Behandlung externer Links und fehlerhafte benutzerdefinierte Emojis.

Earthly 0.0.9

Earthly 0.0.9, ein kollaborativer, auf Nostr aufgebauter Karteneditor, hält Likes nun sichtbar, wenn sich die Seitenleiste eines Kartenobjekts schließt, erneut öffnet oder aktualisiert. Sein Ablauf für NIP-57 (Lightning-zaps) sendet gültiges JSON für zap-Anfragen, damit Lightning-Anbieter verifizierte Belege über öffentlich erreichbare relays veröffentlichen können, auch während der lokalen Entwicklung. Erzeugte Rechnungen bleiben beim Wechsel zwischen Objektansichten sichtbar, und die App zeigt eine Bestätigung, sobald ein verifizierter Beleg eintrifft.

In Entwicklung

Keep ergänzt kind-bezogenes Signieren mit NIP-44 v3 und verschärft die Bestätigungsrichtlinie

Keep hat fünf Änderungen am Android-Signer gemergt, die Anfragen zur Ver- und Entschlüsselung mit NIP-44 (Verschlüsselte Nutzdaten) v3 sowohl durch die Transporte nach NIP-55 (Android-Signer-Anwendung) als auch durch seinen NIP-46 (Nostr Connect)-Bunker leiten. PRs #451, #452 und #453 halten Freigaben für v3 von v2 getrennt, begrenzen sie nach event-kind, weisen fehlende oder ungültige kinds zurück und bewahren Bestätigungsanfragen, die aus Benachrichtigungen geöffnet wurden. PRs #454 und #455 behandeln die Basic-Signierrichtlinie nicht mehr als Auto und verschieben die globale Auswahl in den verschlüsselten Speicher des Kerns. Die Maintainer von Keep mergten alle fünf Änderungen nach dem jüngsten getaggten Android-Release.

Routstrd ändert nach einer nicht authentifizierten Offenlegung seine standardmäßige Netzwerkbindung

Routstrd PR #56 ändert die standardmäßige Bind-Adresse des lokalen Nostr-Inferenzrouters von allen Netzwerkschnittstellen zu 127.0.0.1. Der frühere Standard machte Endpunkte für Wallet-Guthaben, Verlauf, Zugriff, Senden, Rückerstattung, API-Schlüssel, Anbieter, Client, Nutzung und Daemon-Stopp ohne Authentifizierung für jeden Host zugänglich, der den Port erreichen konnte. Betreiber können weiterhin ausdrücklich eine nicht lokale Bindung konfigurieren, aber die gemergte Änderung beschränkt eine neue Bereitstellung standardmäßig auf den lokalen Rechner und ist noch nicht in einem Release mit Versions-Tag erschienen.

Imwald Android verdeutlicht den Status von Offline-Veröffentlichungen

Imwald Android, ein Android-Nostr-Client, behandelt die Bestätigung eines lokalen relay nun nur dann als abgeschlossene Veröffentlichung, wenn jedes konfigurierte Ziel lokal ist. Seine Korrektur für Offline-Veröffentlichung und Outbox lässt die Remote-Zustellung ausstehend, wenn ein lokales relay das event angenommen hat, die konfigurierten entfernten relays jedoch noch nicht. Dadurch unterscheidet der Veröffentlichungsbericht zwischen der gerätelokalen Speicherung und der Zustellung an relays.

FIPS ergänzt eine OpenWrt-Zugriffsschicht; eine Portierung auf FreeBSD wird weiterhin geprüft

Das Nostr-native Free Internetworking Peering System ermöglicht einem OpenWrt-Router nun über den gemergten PR #126, ein offenes !FIPS-Zugangsnetzwerk bereitzustellen. Der parallele, weiterhin offene FreeBSD-PR #129 schlägt die Portierung des Daemons, des TUN-Datenpfads, der Namensauflösung für .fips, der Dienstverwaltung und des nativen Paketbaus vor. Der OpenWrt-Merge erweitert den Zugriff bereits heute, während die FreeBSD-Arbeit ihn auf ein weiteres universelles Betriebssystem ausdehnen würde.

Ein FIPS-Projektupdate vom 26. Juli meldete mehr als 300 Knoten in seinem öffentlichen UDP-Overlay und ein breiteres Mesh, das sich 2.000 Knoten nähert. Das FIPS-Repository härtete in derselben Woche parallele Netzwerktests, die Kontinuität beim Schlüsseltausch, das Verhalten von Hop-Limits, Firewall-Prüfungen und die Isolation des NAT-Labors. Die Arbeit am Repository stellt Betreibern reproduzierbare Prüfungen für diese Verhaltensweisen bereit, während das Netzwerk wächst.

Zap Cooking plant Beiträge und bindet Scanner-Anfragen

Zap Cooking, eine Nostr-App zum Teilen von Rezepten und Planen von Mahlzeiten, kann einen geplanten Beitrag nun im verschlüsselten Speicher halten und ihn bei Fälligkeit über eine periodische Abfrage von relays veröffentlichen (PR #566, PR #569). So erhalten Nutzer einen Weg zur geplanten Veröffentlichung, ohne unsignierte Beitragsinhalte in der Datenbank des Schedulers offenzulegen.

Der Kühlschrankscanner authentifiziert nun den genauen Anfragekörper mit HTTP-Authentifizierung nach NIP-98, sodass Mitgliedschaftsprüfungen auf dem Schlüssel beruhen, der die Scananfrage signiert hat, und nicht auf einem im Anfragekörper angegebenen pubkey (PR #599).

Citrine macht ein Android-Gerät zu einem verwaltbaren relay

Citrine, ein auf Android gehostetes Nostr-relay, kann gespeicherte events nun an externe relays senden und bietet Betreibern damit eine Möglichkeit, den lokalen Verlauf erneut zu übertragen (PR #179). Es ergänzt außerdem Befehle nach NIP-86 (relay-Verwaltungs-API), damit kompatible Clients das relay verwalten können (PR #150).

Gruppenbetreiber können relay-basierte Gruppen nach NIP-29 per Amber-Signatur in PR #178 verwalten, während PR #174 die Tor-gestützte relay-Konfiguration und den Lebenszykluszustand über Neustarts hinweg im Einklang hält.

Wired stellt vollständige Unterhaltungen im Browser wieder her

Wired, ein browserbasierter Nostr-Client, verfolgt Feed-Wurzeln, Antworten und referenzierte events nun bis zum Abschluss, anstatt bei festen Grenzwerten für Suchbreite oder Ergebniszahl anzuhalten (PR #148, PR #147, PR #146). Nutzer können dadurch tiefere Threads und Feed-Kontext wiederherstellen, wenn die relevanten events über ihre relays verfügbar sind.

Der Browser bewahrt außerdem relay-Hinweise an referenzierten events und verwendet sie nur für weiterhin fehlenden Kontext. Damit stellt er Unterhaltungen wieder her, die konfigurierte relays nicht enthalten (PR #145, PR #144). Ein unvollständiger Abruf bleibt von einem abgeschlossenen Snapshot getrennt, sodass eine Teilantwort die vorherige zwischengespeicherte Ansicht nicht überschreibt.

Protokoll- und Spezifikationsarbeit

NIPs: Hosting-Grenze von NIP-34, Gruppenmigration und drei aktive Entwürfe

In dieser Woche wurden zwei Spezifikationsänderungen gemergt. NIP-34-Commit 6d2979b entfernt GRASP-Hosting-Anweisungen aus der Pull-Request-Beschreibung für kind:1618, sodass Hosting- und Fallback-Verhalten außerhalb des event-Vertrags bleiben. NIP-29-Commit db5fe3d definiert, wie Metadaten von relay-Gruppen zu einem anderen relay migrieren und wie Clients einen gültigen Umzug von einem unabhängig fortbestehenden Fork unterscheiden.

PR #2424 schlägt gegenseitige Deklarationen von Schlüsselsätzen mit kind:10045 vor. Das Erfordernis der Gegenseitigkeit würde verhindern, dass eine Identität einseitig einen anderen Schlüssel zuordnet. PR #2421 schlägt BOLT12-zap-Absichten und Zahlernachweise vor, die Clients anhand von Ziel, Betrag, Angebot und abgeschlossener Zahlung validieren können, ohne von einem vom Empfänger betriebenen Belegserver abhängig zu sein.

PR #2425 würde NIP-B0-Lesezeichen erlauben, neben Web-URLs auch Nicht-HTTP-Schemata wie nostr: beizubehalten. Dadurch blieben native Nostr-Kennungen, Zahlungsanfragen und andere Anwendungsschemata in denselben privaten oder öffentlichen Lesezeichenlisten erhalten, die bereits Webadressen enthalten.

Mill implementiert einen Entwurf zur Schlüsselsicherung über Cloud-Konten

Mill kündigte einen implementierten Entwurf zur Schlüsselsicherung über Cloud-Konten an, der die Kennung eines Google-OIDC-Kontos mit einer Passphrase hoher Entropie kombiniert, um einen temporären Sicherungsschlüssel abzuleiten. Seine Referenzimplementierung verschlüsselt den echten Schlüssel des Nutzers als ncryptsec nach NIP-49 (Verschlüsselung privater Schlüssel) und speichert ihn anschließend in einem vorläufigen, parametrisiert ersetzbaren event mit kind 30049 auf konfigurierten relays. Das Projekt hat den Sicherungsablauf in main gemergt, doch kein Release nach v1.0.0 enthält ihn, und der Sicherungsablauf bleibt deaktiviert, sofern ein Betreiber keine eigenen backupRelays angibt. Ein versionierter relay-Satz bleibt vorläufig, und der Entwurf warnt davor, dass veröffentlichter Geheimtext für Offline-Versuche zum Erraten der Passphrase verfügbar bleibt. Leser sollten das Design als implementiertes Experiment behandeln, das von einer Passphrase hoher Entropie abhängt.

BUDs: Blossom-Server können unbekannte Uploads anhand ihrer Bytes identifizieren

BUD-02 PR #110 schlägt vor, eine serverseitige MIME-Erkennung zu empfehlen, wenn ein Uploader Content-Type auslässt oder application/octet-stream sendet. Ein Blossom-Server würde die ersten Bytes mit einer gepflegten Bibliothek zur Dateityperkennung untersuchen, einen spezifischen vom Client angegebenen Typ beibehalten und auf den generischen Binärtyp zurückfallen, wenn die Erkennung scheitert. Damit blieben Bilder, Audio-, Video- und von Agenten erzeugte Dateien darstellbar, ohne Byte-Sniffing für jeden Upload vorzuschreiben.

NAPs: Konventionen ersetzen nummerierte Reihen, während sich Verträge für Aufnahme und Dateisystem entwickeln

PR #87 entfernt die nummerierte, Napplet-übergreifende Protokollreihe und hält Laufzeitfunktionen unter benannten Verträgen, während sich Anwendungsnachrichten auf Konventions-URIs nach dem Muster napplet:<archetype>/<intent> zubewegen. Die gemergte Änderung der Themenidentität trennt einen stabilen Konventionspfad ohne Query-Parameter von Nutzdaten einzelner Nachrichten, und PR #90 wendet diese Transpositionsregel auf Erkennungs- und Handler-Metadaten an.

Zwei NAP-Entwürfe erweitern die Vertrauensgrenze der Shell. NAP-CAPTURE PR #94 hält die Zustimmung zur Mikrofonnutzung, Plattformberechtigung, Grenzen, Aufbewahrung und Beendigung in der Laufzeitumgebung, während ein begrenztes Medienartefakt an ein Napplet in einer Sandbox zurückgegeben wird. NAP-FS PR #88 ist der parallele Vorschlag für ein virtuelles Dateisystem mit richtliniengebundenen Handles anstelle uneingeschränkter Host-Pfade.

Marmot: Die Spezifikation definiert einen endgültigen Gruppenzustand

Marmot PR #409 ergänzt einen authentifizierten, unumkehrbaren Zustand Disbanded, da MLS selbst keine Operation zur Gruppenlöschung besitzt. Ein autorisierter Admin-Commit verschiebt eine Gruppe aus Active, verhindert ihre Wiederbelebung durch alte Zweige, Nachrichten und Welcomes und bietet bestehenden Gruppen einen ausdrücklichen Kompatibilitätspfad, bevor sie sich auflösen können. Die vorangegangene Überarbeitung von Spezifikations-Issues brachte außerdem die Autorität über Gruppenzustände, Konvergenz, Key Packages, Bestätigungen, Medienregeln, Registry-Sprache und 200 erfasste Spezifikations-Issues in Einklang.

Gamma Markets: Keine öffentlichen Spezifikationsänderungen veröffentlicht

Das Spezifikations-Repository von Gamma Markets verzeichnete vom 21. bis zum 28. Juli keine öffentlichen Commits oder Pull-Request-Aktivitäten. Seine veröffentlichten Dokumente zu Aufträgen, Abwicklung und Marktdaten bleiben die aktuelle Grundlage; dieser Eintrag ohne Änderungen hält Gamma in der wöchentlichen Spezifikationsübersicht sichtbar.

Concord: Lese- und Schreibfunktionen könnten innerhalb einer Plane getrennt werden

Concord PR #12 bleibt ein offener Entwurf für Planes, in denen nicht alle Leser auch schreiben dürfen. Er entwickelt die Control Plane in Richtung getrennter Berechtigungen für Lese- und Schreib-Streams weiter und skizziert Kanäle mit eingeschränktem Schreibzugriff, Einladungen und Bereiche für die Schlüsselneuvergabe. Der Schreibschlüssel dient im Entwurf als Spam-Schranke, während signierte innere Akteure und Prüfungen der Mitgliederliste weiterhin Autorität vermitteln.

NWC: Eine Wallet-Methode kann zwischen BOLT11 und BOLT12 wählen

NWC PR #2 schlägt optionale Methoden pay und receive für BIP-321-Zahlungs-URIs vor. Ein Wallet-Dienst kann Unterstützung ankündigen, eine kompatible BOLT11-Rechnung oder ein BOLT12-Angebot aus einem URI auswählen, vor der Zahlung ein abweichendes Bitcoin-Netzwerk zurückweisen und melden, welchen Anweisungstyp er verwendet hat. Der Vorschlag bleibt außerhalb des NWC-Kerns, sodass Wallets ohne Unterstützung für BIP-321 oder BOLT12 ihn nicht implementieren müssen.

Sechs Jahre Nostr im Juli

Diese Juli-Chronik verfolgt wiederkehrende Probleme von Nostr: lesbare Kennungen, relay-Filterung, portable Anwendungsdaten, Datenschutz und Interoperabilität. Über sechs Jahre hinweg verwandelt jede Schicht eine punktuelle Korrektur in gemeinsam genutzte Infrastruktur: Namen werden zu Profilen, Filter zu Anwendungsverträgen, und der über relays transportierte Zustand weitet sich von Notizen auf Live-Räume und Gruppen aus. Sie beginnt mit der ersten Implementierung von NIP-05 und endet mit dem Merge dieses Monats zur adressierbaren Erkennung. Anschließend untersucht sie die Änderungen im Juli, die diese Themen weiterentwickelt haben.

Juli 2021

Am 19. Juli 2021 ergänzte der nostr-tools-Commit 1ce00bd ein Modul nip05.js und hob das Paket auf Version 0.5.0 an. Seine Funktion keyFromDomain erzeugte eine DNS-TXT-Anfrage für _nostrkey.<domain>, sendete die binäre Anfrage an einen von acht rotierenden DNS-over-HTTPS-Anbietern und gab den ersten Schlüssel in der Antwort zurück. Ein Browser-Client konnte dadurch eine von Menschen kontrollierte Domain einem öffentlichen Schlüssel zuordnen, ohne einen DNS-Resolver zu betreiben oder von einem fest eingestellten Anbieter abhängig zu sein.

Dieser erste Ansatz löste die Zuordnung eines Schlüssels, unterstützte jedoch keine Namen innerhalb einer Domain, und seine Vertrauensgrenze lag im DNS sowie beim ausgewählten Resolver. Die moderne NIP-05-Spezifikation verlagerte die Erkennung zu /.well-known/nostr.json, wo eine Domain lokale Namen pubkeys zuordnet und relay-Hinweise anfügen kann. Der Code von 2021 dokumentiert den früheren Gestaltungsdruck: Öffentliche Schlüssel waren portabel, doch Menschen benötigten weiterhin Kennungen, die sie lesen, verifizieren und zwischen Clients übertragen konnten.

Juli 2022

Am 10. Juli beschränkte der NIP-12-Commit 3771186 generische relay-Anfragen auf tags mit einem einzelnen Buchstaben. Diese Entscheidung machte Filter wie #r, #g und #t für URL-Verweise, Geohashes und Hashtags nützlich, ohne relays aufzufordern, jeden beliebigen Metadatenschlüssel zu indizieren. Zehn Tage später nutzte der erste NIP-20-Entwurf für Webkommentare dieses Abfragemodell direkt: Ein Kommentar mit kind 34 enthielt eine normalisierte Webseiten-URL in einem r-tag, sodass eine Website und unabhängige Clients dieselbe Diskussion aus relays abrufen konnten.

Es folgten relay-Richtlinien und soziale Rückmeldungen. Der ursprüngliche NIP-22-Commit erlaubte relays, events zurückzuweisen, deren Zeitstempel created_at unplausibel alt war, und Commit 8bef0e9 nahm zukünftige Zeitstempel in dieselbe Richtlinie auf. Am 30. Juli definierte der NIP-25-Commit dcbd504 Reaktionen mit kind 7 und Ziel-tags e und p; der nächste Commit wies - einer negativen Reaktion zu, und Commit 6903ff5 machte + zum ausdrücklichen allgemeinen Like. Zusammen spezifizierten diese Commits die Zurückweisung von relay-Zeitstempeln, den Abruf anhand von tags, Webkommentare und Reaktions-tags für Clients, die diese Entwürfe übernahmen.

Juli 2023

Im Juli 2023 ging die Koordination über kurze Notizen hinaus. Der NIP-37-Entwurf für verlorene Schlüssel untersuchte die unumkehrbare Stilllegung von Schlüsseln, Schwellenwerte für soziale Wiederherstellung und vorab festgelegte Ersatzschlüssel, lehnte es aber ausdrücklich ab, das Ergebnis als universelle Schlüsselrotation zu bezeichnen. Fünf Tage später führte NIP-53 adressierbare Live-Aktivitäten mit kind 30311 und Chatnachrichten mit kind 1311 ein und gab Streams, Bühnen und Live-Räumen ein gemeinsames event-Modell für Hosts, Teilnehmer, Status und Unterhaltung.

Anwendungen begannen außerdem, Arbeit und Handel anzukündigen. Der erste Data-Vending-Machine-Entwurf beschrieb Auftragsanfragen mit kind 68001, Ergebnisse mit kind 68002, Gebote, Ablaufzeiten, Verkettung und konkurrierende Anbieter für Aufgaben wie Transkription, Zusammenfassung und Übersetzung. Am 13. Juli ergänzte der Entwurf für Kleinanzeigen adressierbare Angebote mit kind 30402 und Metadaten für Titel, Zusammenfassung, Preis, Ort und Status. Diese Entwürfe wurden später zu NIP-90 und NIP-99, doch bereits ihre Fassungen vom Juli trennten eine Anfrage oder Anzeige vom Server, der sie darstellte.

Auch das Zahlungsrouting wurde kombinierbar. Der NIP-57-Merge für zap-Aufteilungen vom 31. Juli änderte ein einzelnes zap-Ziel in eine gewichtete Liste aus pubkeys von Empfängern und relay-Hinweisen. Ein Client konnte einen zap auf Mitwirkende aufteilen, Empfänger ohne Gewichtung auslassen, wenn Gewichtungen vorhanden waren, und die Aufteilung vor der Zahlung anzeigen. Die Änderung standardisierte eine Darstellung durch signierte events für gewichtete zap-Empfänger und relay-Hinweise, sodass kompatible Clients die Aufteilung vor der Zahlung darstellen konnten.

Juli 2024

Am 4. Juli ergänzte der NIP-29-Commit c60ca88 die relay-Moderationsaktion kind:9007 zum Erstellen einer Gruppe. Sechs Tage später definierte NIP-70 geschützte events: Ein --tag weist ein relay an, die Veröffentlichung nur vom authentifizierten Autor des event anzunehmen. Eine Änderung gab relays einen ausdrücklichen Übergang des Gruppenzustands; die andere erlaubte Autoren, Dritte daran zu hindern, ansonsten gültige signierte events erneut in relays einzuspielen.

Am 16. Juli führte ein Commit zur Cashu-Spezifikation sowohl NIP-60-Wallets als auch NIP-61-nutzaps ein. NIP-60 legte Wallet-Metadaten in kind 37375, nicht ausgegebene Nachweise in verschlüsselten events mit kind 7375 und einen optionalen Transaktionsverlauf in kind 7376 ab. NIP-61 verband die Präferenzen des Empfängers für Mint und relays aus kind 10019 mit durch P2PK gesperrten nutzaps mit kind 7337. Wallet-Zustand und Inhabertoken konnten nun durch relays übertragen werden, während die Einlösung weiterhin von Nachweisen der Cashu-Mint und der sorgfältigen Verhinderung doppelter Ansprüche abhing.

Zwei Änderungen Ende Juli präzisierten den deterministischen Zustand. NIP-01-Commit 9c54549 schrieb event-IDs als Entscheidungskriterium nach gleichen created_at-Zeitstempeln vor, sodass Clients identische Ergebnismengen auf dieselbe Weise sortieren konnten. Der NIP-09-Merge zur Löschung stellte klar, dass Anfragen mit kind 5 auf event-IDs oder adressierbare Koordinaten zielen dürfen und k-tags enthalten sollten, welche die kinds angeben, die relays löschen sollen. Beide Änderungen verringerten die Stellen, an denen zwei korrekte Implementierungen andernfalls zu unterschiedlichen Ergebnissen kommen konnten.

Juli 2025

Die Ecash-Erkennung erhielt am 16. Juli ein eigenes soziales Verzeichnis. NIP-87-Commit 1afb6da definierte Cashu-Mint-Datensätze mit kind 38172, Fedimint-Datensätze mit kind 38173 und Empfehlungen mit kind 38000, die mit relay-Hinweisen auf diese Datensätze verweisen können. Wallets konnten Empfehlungen vertrauenswürdiger Autoren abfragen, bevor sie sich mit einer Mint verbanden, während die Spezifikation davor warnte, dass ungefilterte globale Erkennung Nutzer zu böswilligen Betreibern lenken könnte.

Eine Woche später spezifizierte ein Entwurf portable Nostr-event-Datensätze für Sprachnachrichten. Der erste NIP-A0-Commit wies dem Root-event einer Sprachnachricht kind 1222 und einer Antwort kind 1244 zu; beide enthielten eine Audio-URL zusammen mit Medienmetadaten. Die Formataktualisierung vom 27. Juli empfahl Opus in einem Ogg-Container und standardisierte eine komprimierte Wellenform. Clients konnten kurze Audiodateien austauschen, ohne sich auf ein einziges Aufnahmeprogramm, einen einzigen Host oder eine Darstellung der Wellenform zu einigen.

Private Nachrichten und Wallet-Verbindungen ergänzten danach Protokollzustände für Lesefortschritt, Verschlüsselungsauswahl und Zahlungsfortschritt. NIP-17-Commit 3d76da3 definierte einen ersetzbaren Datensatz mit kind 30016, dessen geordnete seen-tags einem Client erlauben, zwischen gelesenen Nachrichten und Lücken zu unterscheiden, die auf möglicherweise verpasste Nachrichten hinweisen. Am 31. Juli ermöglichte die Aushandlung der Verschlüsselung in NIP-47 Wallet-Diensten, NIP-44 v2 oder das ältere NIP-04 anzukündigen, während der Commit zum Transaktionszustand die Zustände pending, settled, accepted, expired und failed ergänzte. Zustellung, Verschlüsselung und Zahlungsfortschritt wurden zu ausdrücklichen Protokolldaten statt lokaler Schlussfolgerungen.

Juli 2026

Dieser Juli begann damit, gewöhnliche Webadressen mit relay-Anfragen zu verbinden. Der Commit 2f4b093 zur adressierbaren Erkennung definiert eine Abfrage unter /.well-known/nostr.json?ad=<path>, deren Antwort einen Nostr-Filter und eine relay-Liste enthält. Ein normaler Browser kann die ursprüngliche URL weiterhin als HTML öffnen, während ein Nostr-Client den entsprechenden Endpunkt /.well-known/nostr.json?ad=<path> nach einem Filter und einer relay-Liste abfragen kann, die die Adresse einer Gruppe, einer nsite, einem Feed, einem event oder einem anderen nativen Objekt zuordnen. Das Muster greift das Problem von 2021 zur Zuordnung einer Domain zu einem Schlüssel auf einer breiteren Ebene erneut auf: Eine einzelne menschenlesbare URL kann nun sowohl eine Identität als auch eine Abfrage bezeichnen.

NIP-29 entwickelte sich anschließend von flachen relay-Gruppen zu strukturierten Räumen. Der Untergruppen-Commit vom 16. Juli ergänzte Beziehungen zu übergeordneten Gruppen und geordneten Untergruppen; benachbarte Commits ergänzten Suffixe für Einladungscodes, Banner, geordnete Pin-Snapshots und Pins für adressierbare events. Am 22. Juli definierte die Klarstellung zu Migration und Fork, wann Metadaten eine Gruppe rechtmäßig zu einem anderen relay verschieben und wann ein weiterhin aktiver Zweig einen unabhängigen Fork bildet. Die Gruppenkennung blieb einfach, während Hierarchie, Darstellung und relay-Änderungen als ausdrücklicher Zustand abgebildet wurden.

Zwei kleinere Änderungen verdeutlichten die Grenzen der Implementierung. NIP-46-Commit f0af204 verlangt von einem Remote-Signer, bei unbekannten oder nicht unterstützten Methoden einen Fehler zurückzugeben, statt einen Client ohne Antwort in ein Timeout laufen zu lassen. NIP-34-Commit 6d2979b entfernt GRASP-spezifische Hosting-Anweisungen aus der Beschreibung des Pull-Request-event. Eine Änderung gibt Aufrufern eine abschließende Antwort; die andere verhindert, dass ein portables Git-event stillschweigend ein einzelnes Serverprotokoll übernimmt.

Sendet eine NIP-17-DM, um ein Projekt oder eine Nachricht über das Projekt Nostr Compass zu teilen.