author

Co-authored-by: Râu Cao <842+raucao@users.noreply.github.com>
blergh
2025-12-09 00:28:51 +00:00 · 2025-04-30 10:10:42 -03:00 · 2025-04-29 16:31:33 -03:00 · 2025-04-29 15:58:37 -03:00
5 changed files with 30 additions and 26 deletions
--- a/21.md
+++ b/21.md
@@ -12,9 +12,27 @@ The scheme is `nostr:`.

 The identifiers that come after are expected to be the same as those defined in [NIP-19](19.md) (except `nsec`).

-## Examples
+#### Examples

 - `nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9`
 - `nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpp4mhxue69uhhytnc9e3k7mgpz4mhxue69uhkg6nzv9ejuumpv34kytnrdaksjlyr9p`
 - `nostr:note1fntxtkcy9pjwucqwa9mddn7v03wwwsu9j330jj350nvhpky2tuaspk6nqc`
 - `nostr:nevent1qqstna2yrezu5wghjvswqqculvvwxsrcvu7uc0f78gan4xqhvz49d9spr3mhxue69uhkummnw3ez6un9d3shjtn4de6x2argwghx6egpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5nxnepm`
+
+### 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:
+
+```
+<head>
+  <link rel="alternate" href="nostr:naddr1qqyrzwrxvc6ngvfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cph95ag" />
+</head>
+```
+
+Likewise, `<link>` tags with `rel="me"` or `rel="author"` can be used to assign authorship of webpages to Nostr profiles. For example:
+
+```
+<head>
+  <link rel="me" href="nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyd8wumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6qpq80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwswpnfsn" />
+</head>
+```
--- a/44.md
+++ b/44.md
@@ -84,12 +84,10 @@ NIP-44 version 2 has the following design characteristics:
   - Slice 76-byte HKDF output into: `chacha_key` (bytes 0..32), `chacha_nonce` (bytes 32..44), `hmac_key` (bytes 44..76)
 4. Add padding
   - Content must be encoded from UTF-8 into byte array
-   - Validate plaintext length. Minimum is 1 byte, maximum is 4294967296 bytes
+   - Validate plaintext length. Minimum is 1 byte, maximum is 65535 bytes
   - Padding format is: `[plaintext_length: u16][plaintext][zero_bytes]`
   - Padding algorithm is related to powers-of-two, with min padded msg size of 32 bytes
-   - Plaintext length is encoded in big-endian:
-     - if smaller than 65536, as a u16 in the first 2 bytes of the padded blob;
-     - if greater than 65536, the first 6 bytes of the padded blob, the first 2 being zero and the other 4 being the actual encoded length as u32
+   - Plaintext length is encoded in big-endian as first 2 bytes of the padded blob
 5. Encrypt padded content
   - Use ChaCha20, with key and nonce from step 3
 6. Calculate MAC (message authentication code)
@@ -126,9 +124,7 @@ validation rules, refer to BIP-340.
 6. Decrypt ciphertext
   - Use ChaCha20 with key and nonce from step 3
 7. Remove padding
-   - Read the first 2 bytes,
-     - if they're zero, read the next 4 bytes as the u32 big-endian plaintext length;
-     - otherwise interpret those 2 bytes as the u16 plaintext length
+   - Read the first two BE bytes of plaintext that correspond to plaintext length
   - Verify that the length of sliced plaintext matches the value of the two BE bytes
   - Verify that calculated padding from step 3 of the [encryption](#Encryption) process matches the actual padding

@@ -152,6 +148,8 @@ validation rules, refer to BIP-340.
  - `x[i:j]`, where `x` is a byte array and `i, j <= 0` returns a `(j - i)`-byte array with a copy of the
    `i`-th byte (inclusive) to the `j`-th byte (exclusive) of `x`.
 - Constants `c`:
+  - `min_plaintext_size` is 1. 1 byte msg is padded to 32 bytes.
+  - `max_plaintext_size` is 65535 (64kB - 1). It is padded to 65536 bytes.
 - Functions
  - `base64_encode(string)` and `base64_decode(bytes)` are Base64 ([RFC 4648](https://datatracker.ietf.org/doc/html/rfc4648), with padding)
  - `concat` refers to byte array concatenation
@@ -184,27 +182,16 @@ def calc_padded_len(unpadded_len):
 def pad(plaintext):
  unpadded = utf8_encode(plaintext)
  unpadded_len = len(plaintext)
-  if (unpadded_len < 1 or
-      unpadded_len > 4294967295): raise Exception('invalid plaintext length')
-  if unpadded_len > 65536:
-      prefix = concat(
-        [0, 0],
-        write_u32_be(unpadded_len),
-      )
-  else:
-      prefix = write_u16_be(unpadded_len)
+  if (unpadded_len < c.min_plaintext_size or
+      unpadded_len > c.max_plaintext_size): raise Exception('invalid plaintext length')
+  prefix = write_u16_be(unpadded_len)
  suffix = zeros(calc_padded_len(unpadded_len) - unpadded_len)
  return concat(prefix, unpadded, suffix)

 # Converts padded bytearray to unpadded plaintext
 def unpad(padded):
  unpadded_len = read_uint16_be(padded[0:2])
-  if unpadded_len == 0:
-      unpadded_len = read_uint32_be(padded[2:6])
-      unpadded = padded[6:6+unpadded_len]
-  else:
-      unpadded = padded[2:2+unpadded_len]
-
+  unpadded = padded[2:2+unpadded_len]
  if (unpadded_len == 0 or
      len(unpadded) != unpadded_len or
      len(padded) != 2 + calc_padded_len(unpadded_len)): raise Exception('invalid padding')
--- a/60.md
+++ b/60.md
@@ -68,7 +68,7 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs

 * `.content` is a [NIP-44](44.md) encrypted payload:
   * `mint`: The mint the proofs belong to.
-   * `proofs`: unencoded proofs
+   * `proofs`: unecoded proofs
   * `del`: token-ids that were destroyed by the creation of this token. This assists with state transitions.

 When one or more proofs of a token are spent, the token event should be [NIP-09](09.md)-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event (the change output should include a `del` field).
--- a/65.md
+++ b/65.md
@@ -32,7 +32,6 @@ When publishing an event, clients SHOULD:

 - Send the event to the **write** relays of the author
 - Send the event to all **read** relays of each tagged user
- Send the author's `kind:10002` event to all relays the event was published to

 ### Size

--- a/84.md
+++ b/84.md
@@ -23,7 +23,7 @@ or obvious non-useful information from the query string.
 ### Attribution
 Clients MAY include one or more `p` tags, tagging the original authors of the material being highlighted; this is particularly
 useful when highlighting non-nostr content for which the client might be able to get a nostr pubkey somehow
-(e.g. prompting the user or reading a `<meta name="nostr:nprofile1..." />` tag on the document). A role MAY be included as the
+(e.g. prompting the user or reading a `<link rel="me" href="nostr:nprofile1..." />` tag on the document). A role MAY be included as the
 last value of the tag.

 ```jsonc
Author	SHA1	Message	Date
fiatjaf_	a68553cce0	author Co-authored-by: Râu Cao <842+raucao@users.noreply.github.com>	2025-04-30 10:10:42 -03:00
fiatjaf_	fc358c8eee	blergh Co-authored-by: hodlbod <jstaab@protonmail.com>	2025-04-29 16:31:33 -03:00
fiatjaf	31ace26aa2	<link>	2025-04-29 15:58:37 -03:00