wikis as djot: this time is different.

54.md

@@ -28,16 +28,18 @@ Articles are identified by lowercase, normalized ascii `d` tags.
 
 ## Content
 
-The `content` should be Asciidoc with two extra functionalities: **wikilinks** and **nostr:...** links.
+The `content` should be [Djot](https://djot.net/) with two special functionalities:
 
-Unlike normal Asciidoc links `http://example.com[]` that link to external webpages, wikilinks `[[]]` link to other articles in the wiki. In this case, the wiki is the entirety of Nostr. Clicking on a wikilink should cause the client to ask relays for events with `d` tags equal to the target of that wikilink.
+1. Links can have target URIs in NIP-21 format, like `[bob](nostr:npub1bob4npub4here4qwxek)`.
+2. When a reference can't be found for a "Reference"-style link should link to the wiki article with that name instead, like a "wikilink". For example:
 
-Wikilinks can take these two forms:
+> a tree is a [vegetable][] that grows big.
+>
+> trees are often [green][green color], but they can also be [red][red color] as [bob][] says.
+>
+> [bob]: nostr:npub1bob4npub4here4qwxek
 
-  1. `[[Target Page]]` -- in this case it will link to the page `target-page` (according to `d` tag normalization rules above) and be displayed as `Target Page`;
-  2. `[[target page|see this]]` -- in this case it will link to the page `target-page`, but will be displayed as `see this`.
-
-`nostr:...` links, as per [NIP-21](21.md), should link to profiles or arbitrary Nostr events. Although it is not recommended to link to specific versions of articles -- instead the _wikilink_ syntax should be preferred, since it should be left to the reader and their client to decide what version of any given article they want to read.
+In the article above, "vegetable" will link to the wiki article **"vegetable"** (with a `d` tag set to `"vegetable"`), "green" will link to the article **green color** (with `d` set to `"green-color"`), same for "red". But "bob" will link to the specified npub as in the reference.
 
 ## Optional extra tags
 
@@ -87,11 +89,11 @@ This is a stronger signal of trust than a `+` reaction.
 
 This marker is useful when a user edits someone else's entry; if the original author includes the editor's changes and the editor doesn't want to keep/maintain an independent version, the `link` tag could effectively be a considered a "deletion" of the editor's version and putting that pubkey's WoT weight behind the original author's version.
 
-## Why Asciidoc?
+## Why Djot?
 
-Wikitext is [garbage](nostr:nevent1qqsqt0gcggry60n72uglhuhypdlmr2dm6swjj69jex5v530gcpazlzsprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5ueneex) and Markdown is not powerful enough (besides being too freeform and unspecified and prone to generate incompatibilities in the future).
+Wikitext is unimplementable. Markdown and Asciidoc do not have strict specs. In Markdown every implementation has its own set of special functionalities that would cause conflict and protocol bloat, also it lacks standardized features that are good to have on encyclopaedias: subscript, superscript, description lists, math, comments and custom labeled blocks. Asciidoc, on the other hand, has all features under the sun, but its spec is so huge no one has ever implemented it, not even in JavaScript (the canonical JavaScript library that most people use is transpiled from the original in Ruby).
 
-Asciidoc has a strict spec, multiple implementations in many languages, and support for features that are very much necessary in a wiki article, like _sidebars_, _tables_ (with rich markup inside cells), many levels of _headings_, _footnotes_, _superscript_ and _subscript_ markup and _description lists_. It is also arguably easier to read in its plaintext format than Markdown (and certainly much better than Wikitext).
+Djot is a much faster parser, made by John MacFarlane (the guy behind Pandoc) with years of experience and lessons learned behind him. The spec is well-defined and simple, and has all the features listed above, while also being basically the same as the most basic Markdown.
 
 ## Appendix 1: Merge requests
 Users can request other users to get their entries merged into someone else's entry by creating a `kind:818` event.