NIP-54 wechselt bei Wiki-Artikeln von Asciidoc zu Djot

Warum ein Markup-Wechsel nicht kosmetisch ist

NIP-54 verpackt content nicht in ein Container-Format mit eigenem Typ-Feld. Es sagt einfach: Dies ist Text in einer bestimmten Markup-Sprache, und es wird erwartet, dass Clients ihn entsprechend interpretieren und rendern. Das bedeutet: Jeder Client, der NIP-54-Artikel rendert, und jedes Tool oder jeder Relay, der sie erzeugt, muss sich darüber einig sein, was dieses Markup bedeutet. Ein Wechsel der Markup-Sprache ändert, was "korrektes Rendering" für den gesamten Event-Kind bedeutet, nicht nur für einen einzelnen Artikel. Das ist die Art von Änderung, die für Implementierer zählt, auch wenn sich keine Kind-Nummer und keine Tag-Struktur verschoben hat.

Wie die Syntax jetzt aussieht

Die alte Spezifikation beschrieb Inhalte in Asciidoc mit einer speziellen Wikilink-Erweiterung über doppelte eckige Klammern: [[Target Page]] verlinkte auf den Artikel unter target-page, und [[target page|see this]] erlaubte einen eigenen Anzeigetext.

Djot hat keine eigene Wikilink-Syntax mit Klammerpaaren, daher nutzt NIP-54 stattdessen Djots native Referenzlinks. Ein Link wie [cryptocurrency][] löst sich normalerweise gegen eine an anderer Stelle im Dokument definierte Referenz auf; NIP-54 legt nun fest, dass der Client ihn als Wikilink behandeln soll, wenn keine solche Referenz existiert, und ihn zum Wiki-Artikel auflöst, dessen d-Tag dem normalisierten Linktext entspricht. So wird [cryptocurrency][] zu einem Wikilink auf den mit cryptocurrency getaggten Artikel, während [Satoshi Nakamoto][] ein normaler Link bleibt, wenn im Dokument eine Referenz für "Satoshi Nakamoto" definiert ist (die zum Beispiel auf einen npub zeigt). Der PR fügt auch ausgearbeitete Beispiele für nicht-lateinische Schriften hinzu und zeigt, wie dieselbe Referenzsyntax ein Linkziel auf Japanisch oder Kyrillisch normalisiert.

nostr:-Links wie in NIP-21 definiert sind davon nicht betroffen: Sie funktionieren weiterhin für Links zu Profilen oder bestimmten Events, auch wenn die Spezifikation weiterhin Wikilinks empfiehlt, statt einen Link an eine bestimmte Artikelversion zu binden.

Was der PR sonst noch ausfüllt

Zwei Abschnitte von NIP-54 waren seit der ersten Fassung des NIP nur Platzhalter, markiert mit [INSERT EVENT EXAMPLE]. PR #2242 füllt beide mit echtem JSON:

• Das kind:818-Event für Merge Requests, mit dem man einen anderen Public Key bittet, einen geforkten Artikel zurück in die Quelle zu mergen, hat jetzt ein vollständiges Beispiel: Der Zielartikel wird mit einem a-Tag markiert, die Basisversion mit einem e-Tag, und die zu mergende Version mit einem e-Tag mit dem source-Marker.
• Das kind:30819-Event für Redirects, mit dem ein Artikeltitel auf einen anderen verweist (das Beispiel im PR ist "BTC", das auf "Bitcoin" umleitet), erhält dieselbe Behandlung: ein d-Tag mit dem Ausgangstitel und ein a-Tag, der auf den Zielartikel zeigt.

Warum Djot

Der PR fügt der Spezifikation einen neuen Abschnitt "Why Djot?" hinzu, der die frühere Begründung "Why Asciidoc?" ersetzt. Er erklärt die Wahl in konkreten Punkten: Djot wurde von John MacFarlane geschaffen, dem Autor von Pandoc und Co-Autor von CommonMark, und im Gegensatz zu Markdown, das sich in viele inkompatible Dialekte aufspaltet, oder zu Asciidoc, dessen Spezifikation an seine Ruby-Implementierung gebunden ist, hat Djot eine klare, eigenständige Spezifikation. Es gibt bereits native Implementierungen in JavaScript, Lua, Rust und Go, ganz ohne Transpilationsschritt, und es unterstützt die Funktionen, die ein enzyklopädisches Wiki-Format braucht: hochgestellt, tiefgestellt, Fußnoten, Tabellen, Definitionslisten und Mathematik. Die Syntax bleibt nah am einfachen Markdown, und der Parser ist auf lineare Laufzeit ausgelegt.

Kontext

Laut dem PR-Text setzt #2242 die Arbeit aus #2082 fort, dem Vorschlag, der den Wechsel weg von Asciidoc zuerst aufgeworfen hat, und baut auf #2177 auf, einer zuvor gemergten Änderung, die die Normalisierungsregeln für das d-Tag bei nicht-lateinischen Schriften festgelegt hat, auf denen die neuen Wikilink-Beispiele direkt beruhen.

Die Änderung betraf eine einzige Datei, 54.md, mit 63 hinzugefügten und 37 entfernten Zeilen.