Merge 35f6a880f1 into 7dec812f99

nip22: fix example type for external URL (#2011 )
NIP-24: Fix heading levels (#2009 )
2025-08-12 22:26:32 +00:00 · 2025-08-11 17:26:05 -04:00 · 2025-08-11 19:37:53 +09:00 · 2025-08-11 19:35:36 +09:00 · 2024-11-11 22:03:06 -03:00
4 changed files with 34 additions and 13 deletions
--- a/21.md
+++ b/21.md
@ -21,7 +21,7 @@ The identifiers that come after are expected to be the same as those defined in

 ### Linking HTML pages to Nostr entities

-`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023' events served under itself as a relay or through some other relay). For example:
+`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023` events served under itself as a relay or through some other relay). For example:

 ```
 <head>
--- a/22.md
+++ b/22.md
@ -143,13 +143,13 @@ A comment on a website's url looks like this:
  "tags": [
    // referencing the root url
    ["I", "https://abc.com/articles/1"],
-    // the root "kind": for an url, the kind is its domain
-    ["K", "https://abc.com"],
+    // the root "kind": for an url
+    ["K", "web"],

    // the parent reference (same as root for top-level comments)
    ["i", "https://abc.com/articles/1"],
-    // the parent "kind": for an url, the kind is its domain
-    ["k", "https://abc.com"]
+    // the parent "kind": for an url
+    ["k", "web"]
  ]
  // other fields
 }
--- a/24.md
+++ b/24.md
@ -8,8 +8,7 @@ Extra metadata fields and tags

 This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become _de facto_ standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs.

-kind 0
-======
+### kind 0

 These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:

@ -19,24 +18,22 @@ These are extra fields not specified in NIP-01 that may be present in the string
  - `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
  - `birthday`: an object representing the author's birth date. The format is { "year": number, "month": number, "day": number }. Each field MAY be omitted.

-### Deprecated fields
+#### Deprecated fields

 These are fields that should be ignored or removed when found in the wild:

  - `displayName`: use `display_name` instead.
  - `username`: use `name` instead.

-kind 3
-======
+### kind 3

 These are extra fields not specified in NIP-02 that may be present in the stringified JSON of follow events:

-### Deprecated fields
+#### Deprecated fields

  - `{<relay-url>: {"read": <true|false>, "write": <true|false>}, ...}`: an object of relays used by a user to read/write. [NIP-65](65.md) should be used instead.

-tags
-====
+### tags

 These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings:

--- a/46.md
+++ b/46.md
@ -200,6 +200,30 @@ _client_ should display (in a popup or new tab) the URL from the `error` field a

 ![signing-example-with-auth-challenge](https://i.nostr.build/W3aj.png)

+## Pure public key login
+
+A _client_ SHOULD support logins with just an `npub`, an `nprofile` or a NIP-05 address instead of requiring a full `bunker://...` URI. In order to do that, it can follow these steps:
+
+  1. Read _user-pubkey_ from the provided NIP-05, `nprofile` or `npub` code;
+  2. Acquire the list of outbox relays for _user_ (either by fetching the user's `kind:10002` relay list from relay hints or hardcoded relays or by other means);
+  3. Query these relay for a `kind:10046` event from _user_;
+  4. Read NIP-46 bunker connection metadata from that event -- then proceed as if the user had typed that bunker URI.
+
+For this to work _user_ must have somehow published such `kind:10046` event beforehand (which might be a job for the bunker provider or app directly or not).
+
+### `kind:10046` event format:
+
+```jsonc
+{
+    "pubkey": "<user-pubkey>",
+    "kind": 10046,
+    "tags": [
+        ["relays", "<remote-signer-relay-url>", "<any-number-of-other-relay-urls...>"],
+        ["pubkey", "<remote-signer-pubkey>"]
+    ]
+}
+```
+
 ## Appendix

 ### Announcing _remote-signer_ metadata
Author	SHA1	Message	Date
fiatjaf_	c0a723d69d	Merge `35f6a880f1` into `7dec812f99`	2025-08-12 22:26:32 +00:00
Awiteb	7dec812f99	nip22: fix example type for external URL (#2011 )	2025-08-11 17:26:05 -04:00
Yoji Shidara	739f3c5263	NIP-24: Fix heading levels (#2009 )	2025-08-11 19:37:53 +09:00
Yoji Shidara	8830525250	NIP-21: Fix markup issue by closing backtick (#2008 )	2025-08-11 19:35:36 +09:00
fiatjaf	35f6a880f1	nip46: simple public key login using kind:10046	2024-11-11 22:03:06 -03:00