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

Diese Woche: Shopstr hält Remote-Signer- und Wallet-Geheimnisse aus dem Browser-Speicher heraus, Routstr SDK verifiziert relay-basierte Provider-Discovery, Postr startet als kleiner Android-Composer, Infans verschlüsselt Familien-Tracking und Co-Parent-Synchronisierung, walls.rip transportiert PGP-verschlüsselten Chat über öffentliche Nostr-relays, und pakstr macht die Zapstore-Veröffentlichung explizit. nostr-tools bindet Gift-Wrap-Rumors an ihre Seals. Releases umfassen Subscription-Isolierung, Profilstatus und relay-bezogene Leave-Marker. Die Protokollarbeit erreicht den Rollout von Kommentar-Threads, Entwürfe für Wallet-Connect-Gebühren und Zahlungsabfragen, Napplet-Display-Anfragen und experimentelle Anmeldung über dasselbe Konto. Die Ausgabe schließt mit Sechs Jahre Nostr im August.

Top-Storys

Postr startet als kleiner Android-Composer

Postr ist ein bewusst kleiner Android-Composer für Kind-1-Notizen. Die Verwahrung des privaten Schlüssels bleibt in Amber, einem Android-NIP-55- (lokaler Signer) und NIP-46-Signer. Version 1.0.0 liefert eine dauerhafte Outbox, die Verbindungsverlust und Prozessende übersteht, kontospezifische private Entwürfe und Blossom-Anhänge mit verifizierten Hashes und begrenzter Upload-Autorisierung.

Ein Beitrag gilt erst dann als erfolgreich, wenn Postr das identische signierte Event zurückliest und seine Signatur prüft. Wiederholungsversuche behalten dieselbe Event-ID. Die Veröffentlichung nutzt die Write-relays aus der NIP-65-Liste (relay-Liste) des Autors plus verschlüsselte Bootstrap-relays oder eine eigene Liste pro Konto. Eine signierte NIP-34-(Git-über-Nostr-)Repository-Ankündigung und ein passendes Kind-0-Projektprofil werden auf relay.ngit.dev veröffentlicht. Feeds, Analytik, Werbung und Schlüsselspeicherung bleiben außerhalb der App.

Infans verschlüsselt Familien-Tracking und Co-Parent-Synchronisierung über Nostr

Co-Eltern können Fütterungs-, Schlaf- und Wachstumsdaten auf ihren eigenen Telefonen behalten und ohne Anbieter für Familiendaten teilen. Infans ist ein Android-Baby-Tracker, der eine lokale Room-Datenbank als Quelle der Wahrheit behandelt und verschlüsselte Kind-30078-Events nach NIP-78 (anwendungsspezifische Daten) für Backup und Partner-Synchronisierung veröffentlicht. Das Repository bezeichnet die lokale Verschlüsselung als NIP-44 (Payload-Verschlüsselung), die Implementierung verwendet jedoch AES-256-GCM, während NIP-44 v2 ChaCha20 mit HMAC-SHA256 verlangt. Payloads im lokalen Modus sollten daher nicht als NIP-44-kompatibel dargestellt werden.

Die Partner-Synchronisierung nutzt den d-Tag baby-tracker-sync, Selbst-Backups dagegen baby-tracker-backup. Asynchrone Notizen reisen innerhalb der Partner-Payload. Der dokumentierte Amber-NIP-55-Pfad (lokaler Signer) delegiert Signieren und Verschlüsseln an den Signer, doch das Repository liefert keinen Interoperabilitätstest, der zeigt, dass jeder Backup- und Partner-Synchronisierungspfad NIP-44-v2-Chiffretext erzeugt. Das Repository erhebt weder einen Medizinprodukt-Anspruch noch legt es eine externe Sicherheitsprüfung vor.

walls.rip Ghost Chat bringt PGP-verschlüsselten Chat auf öffentliche Nostr-relays

walls.rip ist ein Werkzeugkasten für anonyme Kommunikation, dessen Ghost-Chat-Modus eine OpenPGP-Identität im Browser erzeugt oder importiert. Sein Open-Source-Client verschlüsselt jede Nachricht an den öffentlichen PGP-Schlüssel des Empfängers. Die lesbare Unterhaltung bleibt im lokalen Session-Storage auf dem Gerät; die Anwendung hat kein Chat-Konto und keine zentrale Nachrichtendatenbank.

Der Transport ist echtes Nostr, aber bewusst app-spezifisch. Ghost Chat veröffentlicht armored Chiffretext als Kind-1-Events an fünf Standard-relays und markiert jedes Event mit einem stabilen Raum-Tag, das aus dem PGP-Fingerprint des Empfängers abgeleitet ist. Entwickler erhalten damit ein konkretes Beispiel für relays als zensurresistenten Nachrichtentransport, und gleichzeitig zeigt es, warum dezentrale Zustellung allein weder Metadaten schützt noch mit NIP-17-Direktnachrichten interoperabel ist.

pakstr 0.13.0 bis 0.15.0 macht die Zapstore-Veröffentlichung explizit

Nach der Packaging- und Amber-Arbeit in 0.3.1 im Juli ist pakstr ein CLI, das einen Ordner mit Web-Assets in ein signiertes Android-APK verwandelt und es mit einem Nostr-Schlüssel bei Zapstore veröffentlicht. 0.13.0 ergänzt automatische Release-Versionierung. Die Folgeversionen 0.13.1 bis 0.13.3 reparieren die Blossom-Veröffentlichung: die Autorisierung nutzt jetzt base64url, Uploads tragen ein Content-Digest, und das Zapstore-Application-Event wird vor dem Blossom-Upload veröffentlicht.

0.14.0 validiert den Zapstore-Publisher, bevor eine Veröffentlichung fortfährt. 0.15.0 schreibt Listing-Metadaten in Kind-32267-Application-Events und legt Release-Notes in den Content von Kind-30063-Release-Events, sodass der Zapstore-Eintrag einer verpackten App Name, Kurzbeschreibung und Notizen ohne separaten manuellen Listing-Schritt tragen kann.

Heterodyne spezifiziert portable Personas und verschlüsselte soziale Kommunikation

Heterodyne ist eine spezifikationsgetriebene Protokollfamilie für portable Personas, authentifizierte Kommunikation, Kontrolle über eigene Geräte und soziale Interaktion. Ihr aktuelles README setzt vier bestehende Schichten zusammen: signierte Nostr-Events, Radicle (Peer-to-Peer-Git) als dauerhaften Speicher, Marmot (MLS-Gruppen-Messaging über Nostr) für verschlüsselte Einzel- und Gruppengespräche sowie KERI-Key-Event-Logs (Key Event Receipt Infrastructure) für die Schlüsselrotation der Identität. Eine Persona wird als Cold-Root-Nostr-npub plus akzeptiertes KERI-Log beschrieben; das routinemäßige Signieren nutzt rotierende Epochen-Schlüssel, während Radicle-Node-Identitäten mit doppeltem Nachweis delegiert werden.

Die Familie teilt diese Arbeit in vier unabhängig versionierte 0.x-Entwürfe. Core besitzt Identität, Verifikation von Key-Event-Logs, kanonische Nostr-Bytes und das Radicle-Repository-Substrat; Comms besitzt Nostr-native Envelopes, Datenschutzstufen, Veröffentlichung und Marmot-Unterhaltungen; und Social besitzt öffentliches Folgen, Interaktionen und Listen. Control, für die Anmeldung eigener Geräte und Berechtigungen, ist unvollständig und kann nicht beansprucht werden. Diese Dokumente bleiben Entwürfe, die vor 1.0 brechen können, und diese Ausgabe stellt die Familie vor, bevor ein Heterodyne-Client-Release erschienen ist.

Releases

Nostr Java v2.0.8: Subscription-Isolierung und portables NIP-44

Eine Gift-Wrap-Abfrage gegen ein relay mit fünf Events lieferte zufällig null, zwei oder sechs Events zurück, weil Nostr Java, eine Java-Bibliothek für die Kommunikation mit relays und die Verschlüsselung von Nostr-Payloads, jedes eingehende Frame an jeden Listener der Verbindung weitergab. Version 2.0.8 routet EVENT, EOSE und CLOSED an die Subscription, die diese Frames benennen, sodass das End-of-Stored-Events-Signal einer Abfrage keine andere mehr schließen kann. Verbindungsbezogene Frames wie NOTICE, OK und AUTH erreichen weiterhin jeden Listener.

NIP-44 (Payload-Verschlüsselung) im gleichen Release benötigt keinen im Prozess registrierten JCE-Provider mehr. Die Verschlüsselung funktionierte zuvor nur, nachdem in dieser JVM ein Schlüssel erzeugt worden war, was BouncyCastle als Nebeneffekt registrierte, und sie scheiterte auf Android, wo das Hinzufügen eines Providers mit dem Namen “BC” wirkungslos ist. Beide Cipher-Pfade nutzen jetzt die leichtgewichtige ChaCha20-Engine von BouncyCastle, und die Schlüsselerzeugung verändert keinen prozessweiten JCE-Zustand mehr. Aufrufer, die sich auf die Bibliothek für die Provider-Registrierung verlassen haben, müssen ihn selbst registrieren. Die Abhängigkeit von NIP-44 zum JCE-Provider ist das damit geschlossene Issue.

NoorNote v1.3.6: Profilstatus und Kleinanzeigen

NoorNote ist ein Nostr-Client für Desktop, Web und Android. Eine Woche nachdem 1.3.4 verschlüsselte Community-Beitritte ergänzte, zeigt Version 1.3.6 NIP-38 (Nutzerstatus) unter dem NIP-05-Namen (domainverifiziert) eines Profils: die optional ablaufenden adressierbaren Kind-30315-Events, die einen einzeiligen allgemeinen oder Musik-Status tragen. Ein Klick auf diese Zeile setzt den eigenen Status des Betrachters.

Kleinanzeigen aus NIP-99 (Kind-30402-Marktplatzangebote) werden nun überall in der App gerendert, sodass das Marktplatz-Addon nur noch zum Kaufen und Verkaufen nötig ist. Private Petname-Notizen auf Profilen erscheinen zudem in warnendem Orange, mit gefülltem Notiz-Icon und orangefarbenem Avatar-Ring.

nostrord v2.9.0: relay-bezogener Gruppenzustand und Medien

Das Verlassen einer NIP-29-Gruppe (relay-verwaltete Gruppen) auf einem Host unterdrückte früher dieselbe Gruppen-ID auf jedem anderen relay, weil nostrord, ein plattformübergreifender Client für relay-gehostete Communitys, seine Leave- und Delete-Marker nach der nackten ID indexierte. Pro relay begrenzte Leave- und Delete-Marker halten diese Unterdrückungen auf dem Host, der sie erzeugt hat, sodass eine Gruppe, die eine ID über zwei relays teilt, nicht mehr als Paar verlassen oder verworfen wird. Ein Beitritt, den das relay ablehnt, weil man schon Mitglied ist, zählt nun als Erfolg und löscht den lokalen Marker, der bislang ein absorbierender Zustand war: die Selbstheilung räumte einen Slot, während der Cold Start den anderen wiederherstellte.

Version 2.9.0 rendert außerdem Markdown-Bild-Embeds, die andere Clients als ![alt](url) schreiben, statt die Markdown-Zeichen um eine bereits erkannte URL anzuzeigen. Direktnachrichten unterstützen nun NIP-17 (gift-wrapped private DMs) und Kind-15-Datei-Rumors, sodass ein aus Jumble gesendeter verschlüsselter Anhang heruntergeladen, entschlüsselt und angezeigt wird und ausgehende Anhänge vor dem Upload verschlüsselt werden. Dieses Tag liefert nun die NIP-4e-Verschlüsselungsschlüsselarbeit, die letzte Woche behandelt wurde. Der Vorschlag bleibt ungemergt, und nostrord sagt, seine Implementierung folge dem ausgelieferten Jumble-Verhalten, wo dieses vom Entwurf abweicht.

Unveröffentlichte Änderungen

Shopstr hält Remote-Signer- und Wallet-Geheimnisse aus dem Browser-Speicher heraus

Shopstr ist ein Web-Marktplatz für NIP-99-Kleinanzeigen. Nach der Zahlungsintegritätsarbeit im letzten Monat schreibt es serialisierte Bunker-Signer-Geheimnisse nicht mehr in localStorage. Eine NIP-46-Bunker-Payload (Remote-Signing) hatte die aktive bunker://-URL und den erzeugten privaten App-Schlüssel enthalten, sodass jedes Skript im Shopstr-Origin die Remote-Signing-Sitzung fortsetzen konnte. Bunker-Daten bleiben jetzt für die laufende Sitzung im Arbeitsspeicher, übrig gebliebene Bunker-Payloads werden beim Auffinden entfernt, und Signer-Typen außer Bunker behalten ihr bisheriges Speicherverhalten.

Die entsprechende NWC-Änderung tut dasselbe für NIP-47-Zugangsdaten (Wallet Connect). Shopstr hatte den vollständigen nostr+walletconnect://-String samt dem für Wallet-Aktionen genutzten Secret als gewöhnliche Browserdaten gespeichert und beim Checkout wiederverwendet. Verbindungsstrings und Wallet-Metadaten bleiben jetzt im Arbeitsspeicher, und ältere gespeicherte Kopien werden beim Lesen lokaler Daten gelöscht. Skripte, die während einer aktiven Sitzung bereits im Shopstr-Origin laufen, können diese Werte im Arbeitsspeicher weiterhin sehen.

Routstr verifiziert relay-basierte Provider-Discovery

Ein einzelnes bösartiges relay konnte bisher entscheiden, welchen Inferenz-Providern ein Routstr-Client vertraute. Routstr SDK ist die TypeScript-Bibliothek hinter Routstr, einem Marktplatz, der KI-Provider auf Nostr entdeckt und sie mit Cashu bezahlt. Der Discovery-Fix dieser Woche verifiziert jede vom relay gelieferte Provider-Ankündigung, Modellliste und Bewertung (Kinds 38421, 38423 und 38425), bevor ein Konsument sie sieht, sodass eine Bewertung, die einen vertrauenswürdigen Pubkey nennt, aber eine unbrauchbare Signatur trägt, nicht mehr ins Ranking gelangt.

Zeitstempel weit in der Zukunft werden vor der Auswahl der “neuesten Bewertung” verworfen. Events, die mehr als fünfzehn Minuten vor der lokalen Uhr liegen, werden auf dem Live-Pfad und beim Lesen des persistenten Speichers entfernt, was verhindert, dass ein gefälschtes created_at gültig signierte Bewertungen über Neustarts hinweg überholt. Sind keine vertrauenswürdigen Bewertungen verfügbar, schließt das Bewertungs-Gate fail-closed und schließt unbewertete Provider vom Zahlungs-Ranking aus, bis Bewertungen eintreffen. Betreiber können einen Provider weiterhin manuell freischalten.

nostr-tools bindet Gift-Wrap-Rumors an ihre Seals

Das Entpacken eines NIP-59-Events (Gift Wrap) entschlüsselte früher den Wrap, entschlüsselte den Seal und gab den inneren Rumor zurück, ohne zu prüfen, von wem der Seal stammte. nostr-tools ist eine JavaScript-Bibliothek mit Nostr-Protokoll-Helfern. Der Unwrap-Fix dieser Woche verlangt, dass der Wrap Kind 1059 ist, der Seal Kind 13 mit gültiger Signatur, und dass der pubkey des Rumors dem pubkey des Seals entspricht. Die Entschlüsselung des Seals beweist bereits die Kontrolle über seal.pubkey. Ohne die letzte Prüfung könnte jeder einen Rumor sealen, der jemand anderen als Autor nennt, und einen Client dazu bringen, die Nachricht diesem Opfer zuzuschreiben.

NIP-17 (gift-wrapped private DMs) nutzt denselben Unwrap-Pfad, die Bindung gilt also auch für private DMs. Batch-Unwrap überspringt einen Wrap, der diese Prüfungen nicht besteht, statt eine Exception zu werfen, denn Gift Wraps sind unaufgefordert, und ein einziges feindliches Event würde sonst den Rest einer relay-Abfrage verwerfen.

Haven ergänzt signierte relay-Verwaltung und einen lokalen Notizbrowser

Haven ist ein selbst gehostetes Nostr-relay und ein Blossom-Medienserver. Seine neu gemergte Verwaltungskonsole stellt NIP-86-Management-Aufrufe an jedem relay-Endpunkt bereit, wobei jede Anfrage durch ein NIP-98-Event des konfigurierten Eigentümers authentifiziert wird. Betreiber können Sperren, Allowlists, Kind-Regeln, relay-Namen und gespeicherte Medien verwalten, ohne dem relay einen Signierschlüssel zu geben. Ein Nur-Lese-Notizbrowser hält verschlüsselte Kinds opak und lädt entfernte Medien erst nach einem Klick, womit eine automatische Anfrage vermieden wird, die dem externen Host die IP-Adresse des Betreibers verraten würde.

Dieselbe Haven-Änderung ergänzt dauerhafte Traffic-Diagramme und behebt einen Standard-LMDB-Fehler, bei dem das Zählen gespeicherter Events endlos laufen, einen CPU-Kern belegen und spätere Statistikaufrufe blockieren konnte. Haven nutzt jetzt den Backend-Zähler, wo er terminiert, und andernfalls einen begrenzten Event-Durchlauf. Das Projekt fügte seine ersten 23 Tests rund um Event-Paging, Löschung, Metrik-Persistenz, Eigentümerprüfungen und URL-gebundene Anfragesignaturen hinzu.

Amethyst verlagert Blossom-Autorisierung von den Bildlade-Threads

Amethyst, ein Android-Nostr-Client, wartet nicht mehr auf die Blossom-Leseautorisierung auf OkHttp-Dispatcher-Threads. Der Interceptor startet das Signieren nun abseits des Netzwerk-Threads, während der Image-Fetcher eine gemeinsame Signatur pro Host abwartet und die geschützte Blob-Anfrage wiederholt. Ein Schub gegateter Bilder belegt daher nicht mehr jeden Verbindungsslot pro Host, während ein Signer antwortet.

Derselbe Amethyst-Patch bringt die Token-Kodierung in Einklang mit BUD-11: Base64url ohne Padding, server-Scope und kein blob-spezifischer x-Tag, sodass ein Token mehrere Blobs auf demselben Host abdecken kann. Neue Concurrency-Tests prüfen Caching, Ablauf, signierte Wiederholungen und sechzehn gleichzeitige Aufrufer, die eine Signatur teilen.

NIP-Updates und Protokoll-Spezifikationsarbeit

NIPs

Snort und Ditto nutzen jetzt NIP-22 (Kommentar-Threads) für gewöhnliche Textantworten und konvergieren auf Kind 1111, während sie Kompatibilitätspfade behalten; das etabliert keine protokollweit einheitliche Antwort-Kind. Nachdem die Änderung im Juni das Verbot aufgehoben hatte, NIP-22 gegen Kind-1-Notizen zu verwenden, listet eine gemergte Ergänzung zu NIP-30 (Custom Emoji) Kind 1111 unter den Events, die emoji-Tags tragen dürfen, wobei ein Shortcode in content über diesen Tag aufgelöst wird. Snort, ein Web-Nostr-Client, schreibt jetzt jede Antwort als Kind 1111, lädt diese Kommentare über großgeschriebene E/A-Root-Scope-Tags und akzeptiert weiterhin einen optionalen NIP-10-Pfad (Kind-1-Antwort-Tags) für ältere Notizen. Ditto, ein kombinierter Mastodon-Server und Nostr-relay, veröffentlicht jede Antwort als NIP-22-Kommentar, Kind 1111 für Text und Kind 1244 für Sprache, und rendert bestehende Kind-1-Antworten weiter. Clients, die nur NIP-10 verstehen, sehen die neue Form nicht. Top-Level-Beiträge bleiben Kind 1.

Eine NIP-47-pay_invoice-Anfrage (Nostr Wallet Connect) hat derzeit keinen standardisierten Weg, mit dem der Client eine Obergrenze für Routing-Gebühren angeben kann. Ein offener Vorschlag für eine Gebührenobergrenze ergänzt einen optionalen max_fee-Parameter in Millisatoshi für pay_invoice. Wallets, die das Budget einhalten, MÜSSEN keine Zahlung senden, deren Routing-Kosten amount + max_fee übersteigen, und MÜSSEN FEE_LIMIT_EXCEEDED zurückgeben, definiert als keine Belastung und kein Zahlungsversuch. Unterstützende Implementierungen MÜSSEN fees_paid in der Antwort mitschicken, damit der Client abgleichen kann. Implementierungen ohne Gebührenlimit-Unterstützung ignorieren den unbekannten Parameter, und Clients sollten ein fehlendes fees_paid-Feld als Hinweis behandeln, dass die Obergrenze möglicherweise nicht erzwungen wurde. Die Änderung führt keine Event-Kinds ein und bleibt ein Vorschlag, bis sie gemergt wird.

Ein offener NIP-32-Vorschlag für Sprachlabels würde ["l", "<BCP-47>", "lang"] für die vom Autor deklarierte Textsprache standardisieren. Da der einbuchstabige l-Tag bereits relay-indexierbar ist, könnten Clients einen japanischen Feed mit {"#l":["ja"]} anfordern, ohne relay-Upgrade und ohne unzuverlässige Spracherkennung nach dem Download. Der Entwurf migriert auch die Sprachbeispiele in NIP-66-relay-Reports, NIP-68-Bildmetadaten und NIP-71-Audiotracks in denselben Namespace. Labels bleiben unverifizierte Autorenbehauptungen, und die Änderung ist nicht gemergt.

Nostr Wallet Connect

Nach einem Timeout, einem Reconnect oder einer verpassten Benachrichtigung braucht ein Wallet-Connect-Client einen Weg, einen einzelnen Zahlungsdatensatz abzufragen, ohne zu wissen, welches Bitcoin-Zahlungsprotokoll ihn erzeugt hat. Ein offener Entwurf für Zahlungsabfragen im NWC-Erweiterungs-Repository definiert das optionale NWC-09 lookup_payment neben dem NIP-47-Kern. Die Anfrage nutzt genau einen Selektor: eine stabile, wallet-bezogene transaction_id, die BOLT11-kompatiblen Felder payment_hash und/oder invoice, die lookup_invoice schon nutzt, oder ein payment_type plus ein typisiertes lookup-Objekt, das eine andere Erweiterung definiert. Ein erfolgreiches Ergebnis liefert ein gemeinsames Envelope (transaction_id, type, state, payment_type, amount in msats, Zeitstempel, optional fees_paid und metadata sowie ein unterschiedenes details-Objekt) und MUSS sich auf genau einen für diese Verbindung sichtbaren Datensatz auflösen. Das Wallet DARF NICHT offenlegen, ob ein unzugänglicher Datensatz existiert, und ein Selektor, der mehrere sichtbare Datensätze trifft, gibt MULTIPLE_MATCHES zurück. Die Zustände sind pending, accepted, settled, failed, expired und canceled. Derselbe Vorschlag ergänzt NWC-12-BOLT12-Offer- und Zahlungsdetails, die dieses Envelope wiederverwenden. Beide Dokumente sind noch Entwürfe.

NAPs

Ein offener NAP-DISPLAY-Entwurf würde einem Napplet erlauben, seinen Host nach den Pixel-Displays zu fragen, die es nutzen darf. Er baut auf dem separat ungemergten NIP-5D-Vorschlag für Web-Applets auf, den Newsletter #17 vorgestellt hat und der außerhalb des gemergten NIP-Sets bleibt. Der Entwurf definiert display.list, das opake stabile Identifikatoren mit logischer Breite, Höhe und einem zur Laufzeit gewählten Typ (lcd, eink, led-matrix oder other) zurückgeben würde, und display.push, das einen nicht leeren Batch koordinatenadressierter sRGB-Pixel mit drei Bytes übermitteln würde. Die Laufzeit-Discovery würde logisches RGB auf native Farbtiefe, Orientierung und Bildwiederholung abbilden und DARF Updates rotieren, umordnen, quantisieren, dithern oder zusammenfassen. Die Shell-Policy würde steuern, welche Displays ein Napplet auflisten oder beschreiben darf, und DARF Batches ablehnen, ratenbegrenzen oder deckeln. Bevor ein Pixel angewendet wird, würde die Laufzeit den gesamten Batch validieren, sodass ein fehlgeschlagener Push nichts auf dem Gerät ändern würde. Erfolg würde bedeuten, dass der Batch akzeptiert wurde, nicht dass die Hardware-Aktualisierung abgeschlossen ist.

Marmot

Ein offenes Marmot-Experiment würde den zurückgezogenen External-Commit-Entwurf für die Anmeldung über dasselbe Konto durch eine begrenzte Commit-Form ersetzen. Marmot, das MLS-Gruppen-Messaging-Protokoll auf Nostr, weist in diesem Entwurf die datenlose Komponente 0x800d (marmot.same-account-membership.v1) als verhandelten Verhaltensmarker zu. Solange er erforderlich ist, darf ein aktuelles Leaf entweder genau ein inline Same-Account-Add oder ein bis vier inline Sibling-Removes verfassen, jeweils mit normalem UpdatePath und gewöhnlicher Konvergenzpriorität, und jeder Commit MUSS höchstens fünf aktuelle Leaves pro Konto zurücklassen. Das Pairing nutzt einen kurzlebigen, vom Sponsor angezeigten QR-Code (marmot-pairing-v1:), dessen Secret HKDF-SHA256 und ChaCha20-Poly1305 über einen trägerunabhängigen Kanal speist. Nur lokale Kind-453-Proofs binden die Sitzung an den gemeinsamen Kontoschlüssel und werden nie über relays gesendet. Nach einem passenden Welcome ist die erste Anwendungs-Payload des Beitretenden eine nicht gerenderte Kind-452-Bestätigung, gebunden an die Welcome- und GroupInfo-Digests, sodass ein byte-identisches Welcome wiederhergestellt werden kann, ohne das KeyPackage erneut zu verbrauchen. Der gepaarte Sponsor ist die Vertrauenswurzel des Beitretenden für diesen Zweig und beweist keine globale Finalität. Ein begleitendes Dokument zur Kontosynchronisierung bleibt exploratorisch und nicht interoperabel. Das Experiment ist nicht Teil des angenommenen Basisprofils.

Sechs Jahre Nostr im August

Die Augustmonate folgen einem einzigen Interoperabilitätsproblem: wie ein Client ein Ziel benennt und Feedback daran anhängt. Das ursprüngliche Protokoll-Repository verzeichnete keine Commits im August 2021, der Kern der signierten Events stand also still. NIP-25 (Reaktionen) verließ dann 2022 die Kind-1-Schublade. Reguläre replaceable Records erhielten 2023 naddr- und a-Koordinaten mit leerem Identifikator; 2024 wurde die separate parameterized-replaceable-Klasse in addressable Events umbenannt, ohne Änderung des Wire-Formats. 2025 wanderten Reaktionen auf externe Medien. NIP-22 (Kommentar-Threads) Kind 1111 erreichte 2026 produzierende Clients. Der Verlauf führt von einem ruhenden Protokolldokument zu einem gemeinsamen Vokabular für Antworten und Reaktionen, das über Notizen, replaceable Records und Objekte außerhalb des Netzwerks hinweg funktioniert.

August 2021

Das Commit-Fenster August 2021 im ursprünglichen Protokoll-Repository ist leer. Die letzte Änderung vor diesem inaktiven Monat war der NIP-05-Entwurf vom 18. Juni, der DNS-Domain-Identifikatoren als menschenlesbaren Zeiger auf einen öffentlichen Schlüssel einführte. NIP-05 (Domain-Identifikatoren) wechselte später zu einer well-known-JSON-Datei, war Mitte 2021 aber noch ein DNS-TXT-Lookup. Der August erweiterte diese Identifikatorarbeit nicht und ergänzte weder eine neue Event-Kind noch eine relay-Nachricht.

Dasselbe leere Fenster zeigt sich in den Werkzeugen, die neben der Spezifikation schon existierten. noscl, ein im Januar 2021 entstandener Kommandozeilen-Client, verzeichnete keine August-Commits; go-nostr und nostr-tools ebenso wenig. Die Protokollaktivität nahm erst zum Jahresende wieder zu, als das Repository NIP-09 (Anfragen zur Event-Löschung) zuwies und das DNS-Schema durch eine well-known-JSON-Identifikatordatei ersetzte. August 2021 ist die inaktive Phase zwischen dem Identifikator-Entwurf im Juni und der Lösch- und well-known-JSON-Arbeit im Dezember, während das Modell aus signierten Events und relays wie geschrieben Bestand hatte.

August 2022

Am 19. August erweiterte eine NIP-25-Änderung die Ziele von Kind-7-Reaktionen von Kind-1-Textnotizen auf andere Notizen. Das Kind-7-Event und die +/--Konvention standen bereits im Entwurf. Diese Interoperabilitätsänderung erlaubte einem Like, Dislike oder Emoji, sich an ein Profil, eine Follow-Liste oder jede spätere Event-Kind zu hängen, die dieselben e- und p-Tags wiederverwendete.

Die aktuelle NIP-25-Spezifikation behält diese Verallgemeinerung: eine Reaktion zeigt Nutzerreaktionen auf andere Events an, und ein addressable Ziel erhält zusätzlich einen a-Tag mit kind:pubkey:d-tag-Koordinaten. Amethyst, ein Android-Client, implementiert diesen Vertrag in seinem Reaktions-Builder. Der Builder akzeptiert jedes Event, schreibt e-, p- und k-Tags und ergänzt einen a-Tag, wenn das Ziel ein addressable Event ist. Damit reichten Reaktionsziele über Kind 1 hinaus; spätere August-Änderungen ergänzten stabile Koordinaten und Kommentar-Kontext-Tags.

Auch relay-Software übersetzte Tag-Regeln in Speicherverhalten. Am 17. August behandelte nostr-rs-relay nicht länger jeden hexadezimal aussehenden Tag-Wert als binären Indexschlüssel. Es beschränkte diese Optimierung auf einbuchstabige Tags und kleingeschriebene Hexadezimalwerte und erhielt so gewöhnliche Text-Tags, statt sie in eine Form zu dekodieren, die Filter nicht treffen konnten. Derselbe Monat verband damit zwei Seiten der Interoperabilität: Spezifikationen erweiterten, worauf eine Interaktion zielen konnte, während ein relay korrigierte, wie diese Ziel-Tags indexiert und abgerufen wurden.

August 2023

Am 24. August definierte NIP-19 (Bech32-Identifikatoren), wie ein nicht parameterisiertes replaceable Event als naddr kodiert wird. Das Identifikatorfeld, der d-Tag, wurde zu einer leeren Zeichenkette für Kinds, die allein über Pubkey und Kind ersetzen, etwa Metadaten und Kontaktlisten. Fünf Tage später ergänzte NIP-01 (das Basis-Event- und relay-Protokoll) das passende a-Tag-Format: kind:pubkey: mit abschließendem Doppelpunkt und ohne Identifikator. Clients konnten nun auf einen replaceable Record zeigen, ohne auf eine bestimmte Event-ID zu warten, die das nächste Replace ungültig machen würde.

Der aktuelle NIP-19-Text weist Implementierer weiterhin an, für diese replaceable Events eine leere Zeichenkette zu nutzen. nostr-tools, die JavaScript-Identifikatorbibliothek, kodiert dieses Feld über naddrEncode, sodass ein Aufrufer einen leeren Identifikator übergeben und eine teilbare Koordinate erzeugen kann. Die Arbeit im August 2023 machte replaceable Zustand zu etwas, das ein Kommentar, eine Reaktion oder ein Share-Link benennen konnte, nachdem das zugrunde liegende Event ersetzt worden war. Der nächste August standardisierte die Terminologie für die verwandte parameterized-replaceable-Klasse, während spätere Kommentar-Tags die Koordinatengrammatik als A und a wiederverwendeten.

Private Payloads wurden zur gleichen Zeit portabel. Am 24. August ergänzte rust-nostr NIP-44-Encrypt- und Decrypt-Funktionen in seinen JavaScript-Bindings und stellte das versionierte Conversation-Key-Schema neben nativen Rust-Aufrufern auch Webanwendungen bereit. Am 22. August trennte Amethyst die NIP-44-Verschlüsselung vom Messaging-Event-Format und spiegelte damit die Protokolltrennung zwischen der Verschlüsselung von Inhalten und deren Transport durch eine Anwendung. Stabile Koordinaten machten öffentliche Objekte leichter referenzierbar; wiederverwendbare Verschlüsselungs-APIs machten private Inhalte leichter zwischen Implementierungen verschiebbar, ohne sie an eine Nachrichten-Kind zu koppeln.

Derselbe Monat brachte auch Förderung für angrenzende Arbeit an Schlüsselisolierung, Oberflächen und Bildung. Eine OpenSats-Förderrunde vom 17. August vergab ihre Nostr-Fund-Zuschüsse an Amber, gemeinsames Nostr-Interface-Design und Bildung zu Nostr-Anwendungsfällen. Ambers Zuschuss konzentrierte sich darauf, Signierschlüssel über NIP-46 in einer dedizierten Android-Anwendung zu halten, während die Design- und Bildungszuschüsse Onboarding und wiederverwendbare Anwendungsmuster adressierten. Das weitere Nostr-System entwickelte sich über Spezifikations-Commits, Schlüsselisolierung, Interface-Arbeit und geförderte Entwicklerbildung als gemeinsame Infrastruktur.

August 2024

Am 20. August benannten die Spezifikationen “parameterized replaceable event” in “addressable event” um, quer über NIP-01 und sechzehn weitere Dokumente, darunter Langform-Artikel, Live-Aktivitäten, Listen, Kalender und Kleinanzeigen. Das Wire-Format änderte sich nicht. kind:pubkey:d-tag blieb die Koordinate. Geändert hat sich, dass jede Spezifikation, die diese Koordinaten bereits nutzte, nun dasselbe Wort dafür verwendete.

Dieses Vokabular ist das, was aktuelle Implementierungen ausliefern. NIP-01 speichert addressable Events als den neuesten Record pro Kind, Pubkey und d-Tag. NIP-19 nennt ein naddr “a nostr addressable event coordinate”. Amethysts oben zitierter Reaktionspfad typisiert das Ziel als AddressableEvent, bevor er den a-Tag schreibt. Die Koordinatenerweiterung von 2023 und die Terminologieänderung von 2024 nutzen beide die Koordinatengrammatik kind:pubkey:d-tag, während NIP-01 weiterhin reguläre replaceable Events von addressable Events unterscheidet. Ein späterer Kommentar kann eine addressable Diskussion daher über großgeschriebenes A abrufen, ohne zu wissen, welche Event-ID diese Adresse aktuell belegt.

Speicherprotokolle wandten dieselbe Vorliebe für explizite Identifikatoren an. Am 27. August erlaubte Blossoms BUD-04 einem Autorisierungs-Event, mehrere Blob-Hash-x-Tags zu tragen, sodass ein Client einen begrenzten Batch von Uploads, Mirrors oder Löschungen autorisieren konnte, ohne vorzugeben, die Hashes beschrieben ein einziges Objekt. Vier Tage später präzisierte das Projekt seinen Blob-Deskriptor und ergänzte ein Beispiel. Nostr-Events koordinierten Operationen auf inhaltsadressierten Medien, während die Bytes auf Medienservern blieben, und trennten so signierte Autorisierung von Speichertransport.

Am 29. August wurde Remote-Signing toleranter gegenüber unvollkommenen relay-Sets. go-nostr änderte seinen NIP-46-Client so, dass ein fehlerhaftes relay eine über andere konfigurierte relays gesendete Anfrage nicht blockieren konnte: relay-Verbindungen und Veröffentlichungsversuche laufen unabhängig, und der Aufruf fährt fort, sobald irgendeine Verbindung gelingt. Am 19. August kündigte OpenSats außerdem langfristige Unterstützung für Amethyst-Entwickler Vitor Pamplona an, einschließlich Arbeit an NIP-17-Privatnachrichten, plattformübergreifenden Bibliotheken und dem Outbox-Modell. Protokollvokabular, robuster Transport, Datenschutzarbeit und dauerhafte Wartungsförderung konvergierten auf dasselbe Ziel: Clients, die über Geräte und ungleichmäßige relay-Bedingungen hinweg weiterarbeiten können.

August 2025

Am 22. August erhielt NIP-25 Reaktionen auf externe Inhalte. Eine Reaktion auf etwas, das kein natives Nostr-Event ist, muss Kind 17 sein und k- und i-Tags nach NIP-73 (Identifikatoren für externe Inhalte) tragen, was den älteren Website-r-Tag ersetzt. Die Beispiele im gemergten Text sind eine Web-URL (k=web) und eine Podcast-Episode, identifiziert über Show-GUID und Item-GUID, mit Fountain-URLs als Hinweisen. Reaktionen hatten Kind 1 im Jahr 2022 verlassen. Nun verließen sie das Nostr-Event-Set.

Fountain 1.3, veröffentlicht am 15. August 2025, lieferte diese Likes vor dem Merge der Spezifikation aus und erklärte, sie liefen über Nostr, damit andere Podcast-Apps sie lesen können. Das heutige NIP-25-Dokument verwendet weiterhin Fountains Podcast-GUID-Beispiel. Bis August 2025 konnte eine Reaktionskoordinate eine Podcast-Episode oder eine Webseite mit derselben Identifikatorgrammatik benennen, die ein Kommentar später für einen externen Root nutzt.

August 2026

Dieser August brachte Kommentar-Threads in die Clients, die gewöhnliche Antworten schreiben. Die Änderung im Juni, später gemergt, entfernte die Zeile, die Clients untersagt hatte, NIP-22-Kommentare für kurze Notizen zu verwenden. NIP-30 (Custom Emoji) ergänzte dann Kind 1111 neben Notizen, Reaktionen und Nutzerstatus, sodass ein Kommentar dieselben Emoji-Tags tragen kann, die diese anderen Kinds schon nutzten. Die Spezifikationsarbeit ist die Erlaubnis. Die Client-Arbeit ist der Rollout.

Snort, ein Web-Client, veröffentlicht nun standardmäßig NIP-22-Kommentare für Kind-1-Ziele, abonniert Threads über großgeschriebene E/A-Root-Tags und akzeptiert Kind 1111 in Benachrichtigungen. Ditto, ein Community-Web-Client, veröffentlicht jede Antwort als NIP-22-Kommentar, Kind 1111 für Text und 1244 für Sprache, einschließlich Antworten auf Kind-1-Notizen, und liest weiterhin NIP-10-Antworten (Notiz-Threading). Die Verschiebung über sechs Jahre zeigt sich in diesen Standards: 2022 verallgemeinerte die Reaktion, 2023 und 2024 benannten die Koordinate, 2025 richtete Reaktionen aus dem Netzwerk hinaus, und 2026 machte den Kommentar zum gemeinsamen Antwort-Event über dieselben Ziele.

Infrastruktur für private Gruppen definierte Wiederherstellung als Interoperabilitätsanforderung. Marmots Dauerhaftigkeits- und Neustart-Vertrag vom 13. August legt fest, welcher lokale MLS- und Veröffentlichungszustand einen Neustart überleben muss, und verlangt von Clients, den persistierten Zustand abzugleichen, bevor sie Gruppenoperationen fortsetzen. Das erweitert den August-Verlauf über das Benennen eines Ziels hinaus: ein ausgereifter Client muss außerdem genug kryptografischen und Zustellzustand bewahren, um nach einer Unterbrechung sicher weiterzumachen. Gemeinsame Event-Formen nützen nur, wenn Implementierungen den Zustand wiederherstellen können, der für ihre Nutzung nötig ist.

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