wikis as djot: this time is different.

47.md

@@ -667,3 +667,21 @@ Here are some properties that are recognized by some NWC clients:
   "sig": "31f57b369459b5306a5353aa9e03be7fbde169bc881c3233625605dd12f53548179def16b9fe1137e6465d7e4d5bb27ce81fd6e75908c46b06269f4233c845d8"
 }
 ```
+
+### Deep-links
+
+Wallet applications can register deeplinks in mobile systems to make it possible to create a linking UX that doesn't require the user scanning a QR code or pasting some code.
+
+`nostrnwc://connect` and `nostrnwc+{app_name}://connect` can be registered by wallet apps and queried by apps that want to receive an NWC pairing code.
+
+All URI parameters, MUST be URI-encoded.
+
+URI parameters:
+ * `appicon` -- URL to an icon of the client that wants to create a connection.
+ * `appname` -- Name of the client that wants to create a connection.
+ * `callback` -- URI schema the wallet should open with the connection string
+
+Once a connection has been created by the wallet, it should be returned to the client by opening the callback with the following parameters
+ * `value` -- NWC pairing code (e.g. `nostr+walletconnect://...`)
+
+

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`;
+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.
-  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.
 
 ## 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.

71.md

@@ -20,20 +20,6 @@ Nothing except cavaliership and common sense prevents a _short_ video from being
 
 The format uses a _regular event_ kind `21` for _normal_ videos and `22` for _short_ videos.
 
-## Addressable Video Events
-
-For content that may need updates after publication (such as correcting metadata, descriptions, or handling URL migrations), addressable versions are available:
-
-- Kind `34235` for _addressable normal videos_
-- Kind `34236` for _addressable short videos_
-
-These addressable events follow the same format as their regular counterparts but include a `d` tag as a unique identifier and can be updated while maintaining the same addressable reference. This is particularly useful for:
-
-- Metadata corrections (descriptions, titles, tags) without republishing
-- Preservation of imported content IDs from legacy platforms
-- URL migration when hosting changes
-- Platform migration tracking
-
 The `.content` of these events is a summary or description on the video content.
 
 The primary source of video information is the `imeta` tags which is defined in [NIP-92](92.md)
@@ -85,9 +71,6 @@ The `image` tag contains a preview image (at the same resolution). Multiple `ima
 
 Additionally `service nip96` may be included to allow clients to search the authors NIP-96 server list to find the file using the hash.
 
-### Required tags for addressable events:
-* `d` - Unique identifier for this video (user-chosen string, required for kinds 34235, 34236)
-
 ### Other tags:
 * `title` (required) title of the video
 * `published_at`, for the timestamp in unix seconds (stringified) of the first time the video was published
@@ -100,9 +83,6 @@ Additionally `service nip96` may be included to allow clients to search the auth
 * `p` (optional, repeated) 32-bytes hex pubkey of a participant in the video, optional recommended relay URL
 * `r` (optional, repeated) references / links to web pages
 
-### Optional tags for imported content:
-* `origin` - Track original platform and ID: `["origin", "<platform>", "<external-id>", "<original-url>", "<optional-metadata>"]`
-
 ```jsonc
 {
   "id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
@@ -147,56 +127,3 @@ Additionally `service nip96` may be included to allow clients to search the auth
   ]
 }
 ```
-
-## Addressable Event Example
-
-```jsonc
-{
-  "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
-  "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
-  "created_at": <Unix timestamp in seconds>,
-  "kind": 34235 | 34236,
-  "content": "<summary / description of video>",
-  "tags": [
-    ["d", "<unique-identifier>"],
-    ["title", "<title of video>"],
-    ["published_at", "<unix timestamp>"],
-    ["alt", "<description for accessibility>"],
-
-    // video data
-    ["imeta",
-      "url https://example.com/media.mp4",
-      "m video/mp4",
-      "dim 480x480",
-      "blurhash eVF$^OI:${M{%LRjWBoLoLaeR*",
-      "image https://example.com/thumb.jpg",
-      "x 3093509d1e0bc604ff60cb9286f4cd7c781553bc8991937befaacfdc28ec5cdc"
-    ],
-
-    ["duration", <duration in seconds>],
-    ["content-warning", "<reason>"],
-
-    // origin tracking for imported content
-    ["origin", "<platform>", "<external-id>", "<original-url>", "<optional-metadata>"],
-
-    // participants
-    ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],
-
-    // hashtags
-    ["t", "<tag>"],
-    ["t", "<tag>"],
-
-    // reference links
-    ["r", "<url>"]
-  ]
-}
-```
-
-## Referencing Addressable Events
-
-To reference an addressable video:
-
-```
-["a", "34235:<pubkey>:<d-tag-value>", "<relay-url>"]  // for normal videos
-["a", "34236:<pubkey>:<d-tag-value>", "<relay-url>"]  // for short videos
-```

README.md

@@ -263,8 +263,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `31989`       | Handler recommendation          | [89](89.md)                            |
 | `31990`       | Handler information             | [89](89.md)                            |
 | `32267`       | Software Application            |                                        |
-| `34235`       | Addressable Video Event         | [71](71.md)                            |
-| `34236`       | Addressable Short Video Event   | [71](71.md)                            |
 | `34550`       | Community Definition            | [72](72.md)                            |
 | `38172`       | Cashu Mint Announcement         | [87](87.md)                            |
 | `38173`       | Fedimint Announcement           | [87](87.md)                            |