Willkommen zurück bei Nostr Compass, deinem wöchentlichen Wegweiser durch Nostr.

Diese Woche: ngit und GitWorkshop bringen signierte Git-Workflows auf Nostr und Blossom, nsite-clay macht das Veröffentlichen im Browser wiederherstellbar, und die Wingman App verbindet Browsing, lokale Signierung, Authentifizierung und Dateien. Shosho und Livelier verbinden selbst gehostete Streams mit Nostr, Communitator macht Relay-Vorlagen vor der Signierung prüfbar, cal.emre.xyz veröffentlicht Terminslots, und Plektos verschlüsselt private Veranstaltungen. Getaggte Releases bringen Arbeit an Wiederherstellung und Privatsphäre in Vector, Primal Android, LibreNostr und SkateSpots. Die Entwicklungsarbeit umfasst NIP-27-Rendering, signierte Relay-Einstellungen in Conduit, NIP-A3-Zahlungsziele und Blossom-Mirrors. Gemergte Änderungen im NIPs-Repository präzisieren reine Live-Abonnements und authentifizierte Anwendungsdaten. Unser Deep Dive erklärt, wie NIP-21-Links und NIP-27-Referenzen Nostr-Profile und -Events über Anwendungen hinweg transportieren.

Top-Storys

Signierte Git-Workflows bringen CI, private Repositories und Releases auf Nostr

Der v3-Launch vom 8. September vereint ngit, GitWorkshop, ngit-grasp und ngit-ci in einem signierten Workflow. ngit überträgt Branches, Patches und Pull Requests als NIP-34-Events, während GitWorkshop die Review-Oberfläche bereitstellt. Der Launch ergänzt ngit-ci 0.1, einen selbst gehosteten Continuous-Integration-Dienst, dessen Anweisungen und Ergebnisse als signierte Nostr-Events übertragen werden, sodass Checks auf von Maintainern kontrollierter Hardware parallel zur Code-Review laufen können.

Derselbe Release bringt ngit-grasp v3 private Repositories über die GRASP-08-Erweiterung für private Repositories und macht die Autorität der Maintainer explizit. Signierte Release-Einträge können auf Assets in Blossom verweisen, wodurch sowohl Release-Metadaten als auch inhaltsadressierte Dateien außerhalb einer gehosteten Forge bleiben. Die neue Dokumentationsseite bündelt die Client-, Private-Repository-, CI- und Web-Komponenten.

nsite-clay macht das Veröffentlichen im Browser wiederherstellbar

Eine Signer-Prompt-Korrektur vom 31. August, die Wiederherstellung von Veröffentlichungen und die Bearbeitungssteuerung vom 2. September machen nsite-clay zu einem Veröffentlichungswerkzeug im Browser für eine Single-Page-Site. Ein Nutzer bearbeitet das Document Object Model direkt, serialisiert das Ergebnis, lädt es als inhaltsadressiertes Blossom-Blob hoch und veröffentlicht das NIP-5A-Manifest der Site neu. Kein lokaler Build oder Server ist erforderlich.

Der Browser-Publisher macht fehlgeschlagene Veröffentlichungen nun wiederherstellbar und reduziert wiederholte Signer-Abfragen, während der Bearbeitungsleitfaden den Ablauf dokumentiert. Das Ergebnis bleibt für bestehende Gateways eine gewöhnliche NIP-5A-Site.

Wingman App verbindet Browsing, Signierung und Dateien

Die Arbeiten im September ergänzen die Wingman App um Datei-Dialoge, Profilveröffentlichung, sicheren Signer und Sitzungswiederherstellung sowie getestete mobile Builds. Ihre Flutter-Shell injiziert einen NIP-07-Provider in Seiten, die innerhalb der App geöffnet werden, während Flight Deck und das Tower-gestützte Drive eine Arbeitsfläche und einen Datei-Arbeitsbereich neben dem Browser bereitstellen.

Wingman signiert authentifizierte HTTP-Anfragen mittels NIP-98. Die Anfrage-Implementierung erstellt das Event, das ein Server vor der Antwort verifiziert, und gibt einer installierten Identität damit einen konsistenten Genehmigungsweg für Relay-Aktionen, Web-App-Signierung und Dateien.

Shosho liefert Liveliers selbst gehostete Streams

Shosho 1.1.0 erschien am 1. September mit Unterstützung für Livelier, dessen Attributions-Update vom 31. August die Bridge und die Owncast-Quelle in überbrückten Profilen kennzeichnet. Livelier beobachtet das öffentliche Verzeichnis von Owncast, prüft, ob ein Videostream live ist, und veröffentlicht dann ein adressierbares kind:30311-Ereignis nach NIP-53. Die Entdeckung läuft über Nostr, während das Video auf dem Server des Streamers bleibt.

Der Chat durchquert die Bridge als kind:1311-Ereignisse. Das Bridge-Design öffnet eine quellseitige Verbindung nur, solange ein Nostr-Reader abonniert ist, kennzeichnet abgeleitete Identitäten und sendet flüchtige Chats an ein Relay, das sie nach drei Stunden löscht. Das Discovery-Relay akzeptiert Schreibzugriffe für Live-Ereignisse nur vom Bridge-Schlüssel; das Chat-Relay verwendet NIP-42-Authentifizierung und NIP-70-Flags für geschützte Ereignisse.

Communitator macht Relay-Vorlagen vor der Signierung überprüfbar

Die Veröffentlichungsserie vom 31. August stattet Communitator mit kanonischen Vorlagen für Relay-Listen der Art 10002, Blossom-Server der Art 10063 und Posteingänge für private Nachrichten der Art 10050 aus. Bevor ein Signer verbunden wird, zeigt die Anwendung normalisierte Endpunkte, Lese- und Schreibberechtigungen, Ereignisarten, feste Veröffentlichungs-Relays und Ziele an.

Der begrenzte Signier- und Veröffentlichungsablauf trennt das Verbinden vom Anwenden. Jedes Ereignis wird einzeln signiert, ein Durchlauf nutzt höchstens vier WebSocket-Verbindungen, und ein Ziel zählt erst nach einem positiven NIP-01-OK. Die Ergebnisse unterscheiden zwischen vollständiger, teilweiser, fehlgeschlagener und abgebrochener Zustellung. Geteilte Vorlagen bleiben unvertrauenswürdige Empfehlungen; die Zustimmungsoberfläche erläutert die Beobachtbarkeit von Relays und Netzwerk.

cal.emre.xyz veröffentlicht Terminverfügbarkeit nach NIP-52

Das öffentliche Repository wurde mit einem ersten Commit vom 2. September eröffnet, gefolgt von einer signierten Handler-Ankündigung vom 3. September für cal.emre.xyz. Ein Gastgeber veröffentlicht Verfügbarkeit als kind:31923-Ereignis nach NIP-52; ein Gast veröffentlicht eine kind:31925-RSVP.

Es liest Gastgeber-Ereignisse und akzeptierte Besetzt-RSVPs von Relays, schließt sich überschneidende Zeitspannen aus und behält Nostr-Ereignisse als Terminplanungsaufzeichnung bei, ohne sie in eine separate Datenbank zu kopieren. Gastgeber können mit NIP-07, NIP-46 oder einem lokalen Schlüssel signieren; Gäste können einen separaten Schlüssel erzeugen. Das Repository stellt außerdem die resultierenden naddr- und Kalender-Links bereit, wobei E-Mail standardmäßig deaktiviert ist.

Plektos macht private Veranstaltungen zu einem verschlüsselten Kanal

Die Implementierung privater Veranstaltungen vom 2. September macht jede Plektos-Zusammenkunft zu einem privaten Kanal innerhalb einer mit Concord verschlüsselten Community. Gästeliste, RSVP-Liste, Anmeldeboard, Thread, Beiträge, Titelbilder, Bearbeitungen und Löschungen werden gemeinsam verschlüsselt; eine Einladung enthält nur den Schlüssel des jeweiligen Ereignisses, und es wird kein Klartext-Kalenderereignis veröffentlicht.

Das Lebenszyklus-Audit vom 6. September verankert die ID der Ereignisdefinition für den direkten Abruf, wenn mehr als 500 Wraps existieren, und behält zugleich einen paginierten Fallback bei. Einladungspakete laufen 30 Tage nach dem Ende eines Ereignisses ab und können deaktiviert werden, doch wer einen Kanalschlüssel bereits erhalten hat, kann ihn behalten. Eine separate Parser-Sicherheitsreparatur sorgt dafür, dass fehlerhafte Type-Length-Value (TLV)-NIP-19-Bezeichner fehlschlagen, statt den Parser festzuhängen.

Releases

Vector 0.4.4 macht die Wiederherstellung verschlüsselter Communities sicherer

Vector 0.4.4 erschien am 31. August mit Korrekturen für Community-Wiederherstellung, Schlüsselrotation, Moderation und Antwort-Routing. Die Neugründung schließt eine angegriffene Community für den Einladungspfad, den Angreifer genutzt haben; der Ersatz der Mitgliedschaft ersetzt veralteten lokalen Zustand; und ein einzelnes unerreichbares Mitglied friert die Liste nicht mehr ein. Leere Rotationen werden abgelehnt, Beförderungen erhalten online befindliche Mitglieder, und Operationen verweigern die Ausführung, wenn erforderliche Mitglieder nicht erreichbar sind.

Die Veröffentlichung persistiert außerdem Löschungen und Sperren durch Moderatoren, verschlüsselt das Gästebuch nach einer Passwortänderung neu, bindet Benachrichtigungsantworten nach einem Neustart an ihre Konversation und verwendet ausschließlich verifizierte Mehrspieler-Pfade. Es handelt sich um Wiederherstellungskontrollen, nicht um den Widerruf bereits erlangter Schlüssel.

Primal Android 3.5.27 prüft Signer- und Wallet-Identität

Primal Android 3.5.27 erschien am 3. September, nachdem die Signer-Identitätsprüfung und die Wallet-Anfrage-Authentifizierung am 31. August gemergt wurden. Die lokale Signierung lehnt eine Anfrage ab, deren Identität nicht zum gehaltenen Konto passt, und eingehende NIP-47-Anfragen werden vor der Verarbeitung authentifiziert. Das Zap-Poll-Routing sendet Stimmen außerdem an den Autor der Umfrage, wenn die Umfrage in einer Antwort erscheint.

GRAIN 0.8.0-rc2 schließt einen Pfad, der bestätigt, aber nicht gespeichert wird

GRAIN 0.8.0-rc2 erschien am 7. September, nachdem ein Speicherfehler ein OK erlaubt hatte, bevor deren asynchroner LMDB-Datenbank-Writer die volle Speicherkapazität bemerkte. Der Relay warnt jetzt bei 80 und 95 Prozent, verweigert neue Events bei 97 Prozent, lässt aber Raum für Löschungen, und meldet Writer-Fehler nach der Annahme. Die Retention läuft vom ältesten zum neuesten Eintrag, das Teardown behandelt späte Nachrichten, und ungültige Filter verwerfen keine gültigen Geschwister mehr.

Das Release bestätigt außerdem Monitor-Ankündigungen von Kind 10166 und Relay-Reports von Kind 30166, entfernt veraltete Reports, behält konfigurierte Relays als Fallback und meldet Live-Limits und Authentifizierung in NIP-11 statt statischer Nullen.

LibreNostr 0.5.0–0.5.2 macht Tor-Routing fail-closed

LibreNostr 0.5.0 erschien am 7. September mit einem Orbot-Modus, der Relays, Zaps, Uploads, Medien, Wiedergabe und Vorschauen über einen SOCKS-Port leitet, plus einer Reparatur für einen Zap-Sheet-Absturz. Wenn Orbot oder der Proxy nicht verfügbar ist, stoppen Verbindungen, anstatt auf eine direkte Route zu leaken. Version 0.5.1 verhindert, dass langsame NIP-50-Suchen lokale Ergebnisse verzögern; 0.5.2 ersetzt das rekursive Thread-Layout und repariert die Thread-Reihenfolge.

Das Fail-Closed-Verhalten gilt für jede im Release aufgeführte Netzwerkfläche, und ein Neustart ist erforderlich, weil diese Clients langlebig sind. Die Patch-Releases bewahren diese Wahl, begrenzen zugleich aber unzusammenhängende Such-, Stack-Tiefen- und Layout-Fehler.

SkateSpots fügt einen On-Device-Relay-Pfad hinzu

Der signierte Zapstore-Release vom 8. September fügt SkateSpots einen optionalen Citrine-Relay hinzu. Spots, Crews, Nachrichten und Kartendaten können lokal geladen werden; Beiträge werden offline in die Warteschlange gestellt; und das Telefon behält eine lokale Kopie. Bestehende Stash- und Nachrichteninhalte bleiben Ende-zu-Ende-verschlüsselt. Zahlungsprüfungen verlangen Rechnungsbeträge und vom Anbieter ausgestellte Zap-Receipts, bevor Zugriff gewährt oder Beiträge gezählt werden.

Der lokale Relay ist eine Speicher- und Kontinuitätsoption, kein Ersatz für jeden Remote-Relay. Er lässt einen Skater durch eine unverbundene Phase weiterarbeiten und später signierte Aktivität abgleichen, während die Zahlungsänderungen verhindern, dass ein selbsterstellter Receipt zum Nachweis der Abrechnung wird.

Whistle 1.8.15 repariert die Recovery des Lebenszyklus verschlüsselter Gruppen

Whistle 1.8.15 erschien am 3. September, nachdem eine Android-Lebenszyklus-Reparatur verhinderte, dass route-ebene State-Holder anwendungsweite Relay-Subscriptions und Standortupdates zerstören. Die Release-Notes beschreiben außerdem aktualisierten Verbindungsstatus nach Sperre oder Doze sowie einen im beobachteten Fall zurückgewonnenen 501-Event-Backlog.

Der Bug band den Besitz eines langlebigen Dienstes an einen kurzlebigen Bildschirm. Die aktivitätsbezogene Instanz am Leben zu halten und den Socket vor einem Einmal-Lesezugriff zu prüfen, macht es weniger wahrscheinlich, dass gewöhnliche Android-Navigation und Hintergrund-Suspendierung wie eine leere Gruppe aussehen.

TWENTY ONE Companion 1.12.0 trennt verschlüsselte DMs von Legacy-Chat

TWENTY ONE Companion 1.12.0 erschien am 5. September mit gift-wrapped DMs nach NIP-17. Der verschlüsselte Posteingang ist von älterem Space-Chat getrennt, der eigen bleibt, weil diese Nachrichten nie verschlüsselt waren und nicht migriert werden können. PDFs und Videos werden unter Vorbehalt der Relay-Richtlinie unterstützt, und persönliche Verbergungen synchronisieren, ohne zu Moderator-Bans zu werden.

Die sichtbare Trennung ist Teil des Sicherheitsmodells. Die alte Historie als sicheren Posteingang zu bezeichnen, würde deren Herkunft falsch darstellen, während eine stille Migration eine Verschlüsselung suggerieren würde, die bei deren Erstellung nicht existierte.

ZapStore 1.1.2 validiert Event-Ids und Zertifikatsrotation

ZapStore 1.1.2 erschien am 4. September mit NIP-01-Event-Id-Validierung: Der Client berechnet die Id eines eingehenden Events neu und lehnt Abweichungen vor der Verwendung ab. Das Release identifiziert außerdem Pakete, die außerhalb von ZapStore installiert wurden. Auf dem Server bewahrt die Zertifikat-Hash-Retention wiederholte apk_certificate_hash-Tags, sodass die Rotation des Android-Signierschlüssels eine genehmigte Herkunft bewahren kann.

Die Event-Id-Prüfung verhindert, dass ein Relay oder Cache Tags oder Inhalt ändert, während die alte Id behalten wird. Der Installationsquellen-Indikator liefert separate Herkunft, wenn ein Android-Paket mit gleicher Anwendungs-Id aus einem anderen Kanal stammt.

Amber 6.6.1 hält Signer-Antworten zuordenbar

Amber 6.6.1 erschien am 4. September, nachdem das Berechtigungs-Parsing so repariert wurde, dass ein fehlendes optionales kind toleriert wird, und abgelehnte Signieranfragen begannen, ihren ursprünglichen Anfrage-Id zurückzugeben. Aufrufende Anwendungen können eine Ablehnung der eingereichten Operation zuordnen. Das Release aktualisiert außerdem Remote-Signer-Standardeinstellungen und fügt einen Indexer-Relay hinzu.

Gemeinsam bewahren diese Fixes die Zuordnung in beide Richtungen: Ein Berechtigungseintrag bleibt nutzbar, wenn ein optionales Feld fehlt, und eine Ablehnung bleibt an die auslösende Anfrage gebunden. Die Änderungen der Relay-Standardeinstellungen betreffen die Discovery, ersetzen aber nicht die lokale Autorisierungsentscheidung des Signers.

Unveröffentlichte Änderungen

Zap Cooking rendert NIP-27-Referenzen mit Relay-Hinweisen

Der Merge vom 4. September sorgt dafür, dass Zap Cooking nostr:npub- und nostr:nprofile-Referenzen in Artikeln, Rezepten, Editor-Vorschauen und Druckansichten rendert. Ungültige Bezeichner bleiben Text, die Auflösung erfolgt nicht-blockierend, und der Editor zeigt eine Vorschau des Markdowns, das signiert wird. Wenn Relay-Informationen vorhanden sind, wird aus einem nackten npub ein nprofile mit Outbox-Relays und einem passenden p-Tag.

In derselben Woche wurden autorenbezogene Kind-30023-Abfragen korrigiert, verifizierte NIP-50-Suchrelays mit Deduplizierung und Schutz vor veralteten Abfragen hinzugefügt und NIP-47-Wallet-Aufrufe repariert, nachdem Änderungen an Abhängigkeiten Guthaben und Verlauf beschädigt hatten.

Conduit gleicht signierte Relay- und Blossom-Einstellungen ab

Conduit hat am 2. September die Bearbeitung von Blossom-Einstellungen und am 7. September den Abgleich signierter Einstellungen gemergt. Market und Merchant behalten die neueste gültige Kind-10002-Relay-Liste und die Kind-10050-Inbox-Deklaration, bewahren eine nutzbare signierte Liste, wenn ein neueres Event fehlerhaft ist, unterscheiden eine explizit leere Liste von einer nicht verfügbaren Abfrage und ersetzen fehlgeschlagene deklarierte Relays nicht durch Code-Standardwerte.

Der Kind-10063-Editor ermöglicht es einem Nutzer, eine geordnete HTTPS-Medienserver-Liste zu laden, neu zu ordnen, zu prüfen, extern zu signieren, zu veröffentlichen und zurückzulesen, ohne diese Server zu kontaktieren oder einen nicht deklarierten Standardwert einzufügen.

NIP-A3-Zahlungsziele erreichen drei Clients

Vom 1. bis 3. September haben Amethyst, Grimoire und Pollerama NIP-A3-Zahlungsziele vom Kind 10133 implementiert. Amethyst bietet eine optionale Übergabe nur an, wenn ein kompatibles Ziel existiert, und verwandelt sie nicht in einen Zap; Grimoire nutzt eine feste Registry, bevor Wallet-URIs erstellt werden; Pollerama validiert Monero-Adressen und ruft die Relay-Liste des Autors ab, bevor Ziele abgefragt werden. Jeder Client benötigt weiterhin eine erlaubte Zahlungsmethode, eine Relay-Route und eine korrekte Anzeige.

Ditto erweitert Blossom-Fallback und Live-Einbettungen

Ditto hat am 6. September breiten Blossom-Fallback und Mirroring gemergt. Avatare, Badges, Banner, Community-Bilder, benutzerdefinierte Emojis und Anwendungssymbole versuchen nun deklarierte Server mit demselben Blob-Hash; Mirror-Uploads verwenden ein standardmäßiges BUD-11-Autorisierungstoken. Eine Änderung vom 4. September fügte kompakte kind:30311-Livestream-Einbettungen hinzu.

NIP-Aktualisierungen und Arbeit an Protokollspezifikationen

Nostr Implementation Possibilities

NIP-01 präzisiert nun den limit: 0-Filter, gemergt am 4. September. Ein Relay MUSS keine gespeicherten Events zurückliefern, MUSS EOSE senden, sobald die initialen Abfragen abgeschlossen sind, und MUSS das Abonnement für neue passende Events aktiv halten. Clients können mit einem einzigen Filterfeld ein reines Live-Abonnement öffnen und dabei den lokalen Verlauf behalten. Die Klarstellung dokumentiert kompatibles Verhalten über mehrere Relay-Implementierungen und öffentliche Relays hinweg.

NIP-78 erhielt eine Anforderung für authentifizierte App-Daten, gemergt am 3. September. Relays SOLLTEN NIP-42-Authentifizierung für die Kinds 78 und 30078 verlangen und SOLLTEN diese nur an den authentifizierten Event-Autor ausliefern. Das ist ein SOLLTE, keine Vertraulichkeitsgarantie: Clients können beliebige Relays nicht als privaten Speicher behandeln. Der Merge rät außerdem davon ab, benutzerdefinierte App-Daten-Kinds als generischen öffentlichen Austausch zu verwenden.

NIP-AC wurde am 4. September als ausdrücklich offener WebRTC-Signalisierungsvorschlag eröffnet. Er verwendet vorläufige ephemere Kinds für Ping, Verbindungsanfragen, Angebote, Antworten und ICE-Kandidaten, adressiert mit p und gruppiert über ein Sitzungs-e-Tag; Kind 30600 unterstützt die Auffindbarkeit. Relays SOLLTEN diese Signalisierungs-Events weiterverbreiten und DÜRFEN sie NICHT speichern, während Peers sich direkt verbinden. Die Nummern bleiben vorläufig, Clients SOLLTEN NIP-65-Relay-Listen verwenden, und Anwendungen, die Vertraulichkeit benötigen, SOLLTEN Angebots-, Antwort- und Kandidateninhalte mit NIP-44 verschlüsseln.

NIP Deep Dive: URI-Links und Referenzen im Event-Text

Ein Nostr-Bezeichner braucht eine transportierbare Bedeutung, bevor eine andere Anwendung ihn öffnen kann. NIP-21 setzt einen NIP-19-Bezeichner hinter das nostr:-URI-Schema und gibt Browsern, Betriebssystemen und Anwendungen damit eine einzige weiterleitbare Form. NIP-27 definiert, was dasselbe URI innerhalb eines lesbaren Event-content bedeutet. NIP-21 überschreitet eine Anwendungsgrenze; NIP-27 hält eine Profil- oder Event-Referenz in signiertem Fließtext. Keines der beiden erzeugt ein Event-Kind oder ändert Relay-Nachrichten; die beiden Spezifikationen definieren ausschließlich Verlinkungs- und Darstellungsverhalten.

URI-Dispatch und NIP-19-Semantik

Die Grammatik von NIP-21 besteht aus nostr: gefolgt von einer NIP-19-bech32-Entität. nsec ist ausgeschlossen, da es einen privaten Schlüssel kodiert. Es gibt keine Authority-, Pfad- oder Query-Komponente, daher ist ein konformer Link nostr:npub1... und nicht nostr://npub1.... Eine Plattform oder ein Client kann sich als Handler registrieren; die Spezifikation wählt weder die installierte Anwendung aus noch definiert sie einen Web-Fallback.

Das Präfix teilt einem Client mit, was zu dekodieren ist. npub enthält einen öffentlichen Schlüssel und note eine Event-ID. nprofile fügt einem Profil optionale Relay-Hinweise hinzu; nevent ergänzt eine Event-ID um Relays, Autor und Kind; und naddr enthält Autor, Kind und die d-Kennung eines adressierbaren Events, mit optionalen Relays. Diese Formen verwenden NIP-19-Type-Length-Value-Felder. Hinweise grenzen die Auffindbarkeit ein, beweisen aber weder den Besitz des Relays noch die Kontrolle des Autors. Jedes abgerufene Event erfordert weiterhin eine Neuberechnung der ID und eine Signaturprüfung.

Die Profilform in der NIP-21-Spezifikation lautet:

nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9

NIP-21 definiert außerdem HTML-Brücken: Eine Seite, die ein Nostr-Event ausliefert, kann dessen naddr in <link rel="alternate"> einbetten, und ein Profil kann ein nprofile in <link rel="me"> oder <link rel="author"> einbetten.

NIP-27-Rendering und optionale Tags

NIP-27 gilt für lesbaren Event-Inhalt wie Notizen des Kinds 1 und Artikel des Kinds 30023. Ein Composer kann @name anzeigen, veröffentlicht aber nostr:nprofile1... im signierten String. Ein Reader scannt die URI, dekodiert ihre NIP-19-Entität, ruft das Ziel ab und kann einen Namen, eine Karte, eine Vorschau oder einen lokalen Link rendern. Schlägt die Dekodierung fehl, bleibt die URI gewöhnlicher Text. Der Rohinhalt darf nicht umgeschrieben werden: Eine Änderung verändert die NIP-01-Serialisierung, die ID und die Signatur.

Inhaltsreferenzen und Tags haben verwandte, aber unterschiedliche Aufgaben. NIP-27 beschreibt optionale p- und e-Tags sowie den q-Tag aus NIP-18. Ein Client kann eine Referenz anzeigen, ohne eine Benachrichtigung oder eine Thread-Beziehung zu erzeugen; die Ermittlung von Zitaten sollte sowohl die URI als auch ein q-Tag schreiben. Die Implementierung von Zap Cooking vom 4. September folgt dieser Trennung, indem die URI beibehalten und gleichzeitig Relay-Hinweise sowie ein passendes p-Tag hinzugefügt werden. Das Hinzufügen von p oder q macht die URI nicht privat, und NIP-27 kennt keinen Modus für versteckte Erwähnungen.

Das folgende Event des Kinds 1 wurde von wss://nos.lol wiederhergestellt und vor der Aufnahme als konkrete NIP-27-Referenz verifiziert. Sein content enthält ein naddr für ein versionsunabhängiges adressierbares Event. Die Dekodierung ergibt Kind 30402, den Autor 91036d...310a, die d-Kennung des Workbooks und einen Hinweis auf wss://nos.lol/. Die Tags q, p, t, zap und client sind Entscheidungen der Anwendung, keine Anforderungen von NIP-27.

{
  "id": "cbf64aa95627f3722915e9aad29d905ddac9b09e7a8808a7594732d90deaa6bb",
  "pubkey": "ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d",
  "created_at": 1788953511,
  "kind": 1,
  "tags": [
    [
      "p",
      "91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a",
      "wss://multiplexer.huszonegy.world/"
    ],
    [
      "t",
      "archetype"
    ],
    [
      "q",
      "30402:91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a:Archetype-Workbook-Companion-Meet-your-King-Warrioir-Magician-Lover-today-oejbwe",
      "wss://nos.lol/"
    ],
    [
      "zap",
      "91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a",
      "wss://multiplexer.huszonegy.world/",
      "0.9"
    ],
    [
      "zap",
      "ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d",
      "wss://relay.nostr.band/",
      "0.1"
    ],
    [
      "client",
      "Amethyst"
    ]
  ],
  "content": "You can check, read and use this Workbook already! You can also support and get it for few sats and support us in this project.\n\nI hope it'll help you in your Archetype Journey :)\n\n#archetype\n\nnostr:naddr1qpgyzunrdpjhg7tsv5k4wmmjdd3x7mmt94pk7mtsv9hxjmmw94xk2et594uk7atj949kjmn894tkzunjd9hkju3df4skw6trd9skut2vdamx2u3dw3hkgcte94hk26nzwajszrnhwden5te0dehhxtnvdakz7q3qjypkmmqcaetrcpld4m27la946cch2hrk7qr8xjehsu5j5h3uxy9qxpqqqpmvyqnrm7n",
  "sig": "aa9592e7c773271b9e9f980c8a7e17fda2ffd5a4483a1789e5dd4c4a83018ac576c5202b21b33b08770dcabe023f93998a41f1a0be4bf00e36cdde611d07915e"
}

Vertrauen, Fehlerverhalten und Client-Implementierungen

Ein sicherer Parser findet ein vollständiges nostr:-Token, validiert bech32, dekodiert NIP-19, weist nsec zurück, ignoriert unbekannte TLV-Typen und lässt fehlerhaften oder übergroßen Text unverändert. npub und nprofile führen zu Profilabfragen; note und nevent identifizieren unveränderliche Events; naddr wählt das neueste gültige adressierbare Event für seinen Kind, Autor und d-Tag aus. Relay-Hinweise verringern den Suchaufwand, erweitern aber nicht das Vertrauen. Gemäß den NIP-01-Event-Regeln verifiziert der Client die ID eines abgerufenen nevent und prüft jede Signatur eines naddr-Kandidaten, bevor er die Ersetzungsregeln für adressierbare Events anwendet.

Inline-Vorschauen sind eine Entscheidung des Clients mit Kosten für Privatsphäre und Ressourcen. Das Abrufen jeder Referenz offenbart die Interessen des Lesers und kann einen Anfragesturm auslösen, daher können Clients einen Cache verwenden, Abrufe bis zur Sichtbarkeit aufschieben, die Parallelität begrenzen und für unbekannte Medien einen Klick verlangen. Gemäß NIP-27 muss eine Vorschau vom signierten Text des aktuellen Autors unterscheidbar bleiben. Ein Fehlschlag sollte als unaufgelöster Text oder nicht verfügbare Karte sichtbar sein, nicht stillschweigend als verifizierter Inhalt behandelt werden.

Das Vertrauen ändert sich auch je nach Identifikatortyp. Ein nevent bezeichnet unveränderliche Bytes, daher kann ein Client ein abgerufenes Event zurückweisen, dessen serialisierte ID von der angeforderten ID abweicht. Ein naddr bezeichnet eine ersetzbare Koordinate, daher muss ein Client jeden Kandidaten verifizieren und die Regeln für adressierbare Events anwenden, bevor er entscheidet, welche Version angezeigt wird. Ein Relay-Hinweis ist in beiden Fällen für die erste Abfrage nützlich, aber keine Empfehlung für das Relay oder den zurückgegebenen Inhalt. Die TLV-Definition von NIP-19 liefert die Daten, die nötig sind, um diese Prüfungen explizit zu machen.

NIP-21 definiert einen portablen Link, der von außerhalb von Nostr geöffnet werden kann, während NIP-27 denselben Link innerhalb signierten Texts dauerhaft macht. Ein Client, der nur NIP-21 implementiert, kann einen eingefügten URI öffnen, aber keine eingebetteten Referenzen darstellen. Vollständige NIP-27-Unterstützung fügt Scanning, sicheres Dekodieren, Abrufstrategien, lokale Darstellung und eine explizite Entscheidung über Benachrichtigungs- und Zitat-Tags hinzu. Der gemeinsame URI hält diese Ebenen interoperabel, ohne Clients zu zwingen, sie identisch darzustellen. Damus modelliert Inline-Referenzen als typisierte Erwähnungen. Sein Mention-Code bildet npub und nprofile auf Profilreferenzen, note und nevent auf Event-Referenzen und naddr auf Adressreferenzen ab; NostrLink leitet sie an das passende Ziel weiter. Primal Android parst das Schema und eingefügte Formen, validiert bech32 und extrahiert Relay-Hinweise, und bildet Referenzen anschließend auf Notizinhaltsmodelle ab. Zap Cooking stellt dieselben Referenzen in Artikeln, Rezepten, Editor-Vorschauen und Druckansichten dar.

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