move relay tags into encrypted section and remove from nip51

47.md

@@ -667,21 +667,3 @@ 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,18 +28,16 @@ Articles are identified by lowercase, normalized ascii `d` tags.
 
 ## Content
 
-The `content` should be [Djot](https://djot.net/) with two special functionalities:
+The `content` should be Asciidoc with two extra functionalities: **wikilinks** and **nostr:...** links.
 
-1. Links can have target URIs in NIP-21 format, like `[bob](nostr:npub1bob4npub4here4qwxek)`.
+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.
-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:
 
-> a tree is a [vegetable][] that grows big.
+Wikilinks can take these two forms:
->
-> trees are often [green][green color], but they can also be [red][red color] as [bob][] says.
->
-> [bob]: nostr:npub1bob4npub4here4qwxek
 
-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.
+  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.
 
 ## Optional extra tags
 
@@ -89,11 +87,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 Djot?
+## Why Asciidoc?
 
-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).
+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).
 
-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.
+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).
 
 ## 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.

60.md

@@ -28,7 +28,9 @@ This NIP doesn't deal with users' *receiving* money from someone else, it's just
     "content": nip44_encrypt([
         [ "privkey", "hexkey" ],
         [ "mint", "https://mint1" ],
-        [ "mint", "https://mint2" ]
+        [ "mint", "https://mint2" ],
+        [ "relay", "wss://relay1.example.com" ],
+        [ "relay", "wss://relay2.example.com" ]
     ]),
     "tags": []
 }
@@ -36,9 +38,10 @@ This NIP doesn't deal with users' *receiving* money from someone else, it's just
 
 The wallet event is an replaceable event `kind:17375`.
 
-Tags:
+Encrypted Tags:
 * `mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
 * `privkey` - Private key used to unlock P2PK ecash. MUST be stored encrypted in the `.content` field. **This is a different private key exclusively used for the wallet, not associated in any way to the user's Nostr private key** -- This is only used for receiving [NIP-61](61.md) nutzaps.
+* `relay` - Relay(s) where the wallet's events (`kind:7374`, `kind:7375`, `kind:7376`) are published to and queried from. Clients MUST use these relays for all wallet operations. If no `relay` tags are present, clients SHOULD fall back to the user's [NIP-65](65.md) relay list.
 
 ### Token Event
 Token events are used to record unspent proofs.
@@ -104,10 +107,14 @@ All tags can be [NIP-44](44.md) encrypted. Clients SHOULD leave `e` tags with a
 Multiple `e` tags can be added, and should be encrypted, except for tags with the `redeemed` marker.
 
 ## Flow
-A client that wants to check for user's wallets information starts by fetching `kind:10019` events from the user's relays, if no event is found, it should fall back to using the user's [NIP-65](65.md) relays.
+A client that wants to check for user's wallet information:
+
+1. Fetches the user's `kind:17375` wallet event from the user's [NIP-65](65.md) relays (or any known relays)
+2. Reads the `relay` tags from the wallet event to determine which relays to use for wallet operations
+3. If no `relay` tags are present, falls back to using the user's [NIP-65](65.md) relay list
 
 ### Fetch wallet and token list
-From those relays, the client should fetch wallet and token events.
+Using the relays from the wallet event's `relay` tags (or NIP-65 relays if not specified), the client should fetch wallet and token events:
 
 `"kinds": [17375, 7375], "authors": ["<my-pubkey>"]`