mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-09 00:28:51 +00:00
Compare commits
4 Commits
link
...
bigger-nip
| Author | SHA1 | Date | |
|---|---|---|---|
|
b8782df594 | ||
|
|
4de6a69931 | ||
|
5b7d338200 | ||
|
2ade2e6229 |
20
21.md
20
21.md
@@ -12,27 +12,9 @@ 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>
|
||||
```
|
||||
|
||||
31
44.md
31
44.md
@@ -84,10 +84,12 @@ 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 65535 bytes
|
||||
- Validate plaintext length. Minimum is 1 byte, maximum is 4294967296 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 as first 2 bytes of the padded blob
|
||||
- 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
|
||||
5. Encrypt padded content
|
||||
- Use ChaCha20, with key and nonce from step 3
|
||||
6. Calculate MAC (message authentication code)
|
||||
@@ -124,7 +126,9 @@ validation rules, refer to BIP-340.
|
||||
6. Decrypt ciphertext
|
||||
- Use ChaCha20 with key and nonce from step 3
|
||||
7. Remove padding
|
||||
- Read the first two BE bytes of plaintext that correspond to plaintext length
|
||||
- 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
|
||||
- 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
|
||||
|
||||
@@ -148,8 +152,6 @@ 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
|
||||
@@ -182,16 +184,27 @@ def calc_padded_len(unpadded_len):
|
||||
def pad(plaintext):
|
||||
unpadded = utf8_encode(plaintext)
|
||||
unpadded_len = len(plaintext)
|
||||
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)
|
||||
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)
|
||||
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])
|
||||
unpadded = padded[2:2+unpadded_len]
|
||||
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]
|
||||
|
||||
if (unpadded_len == 0 or
|
||||
len(unpadded) != unpadded_len or
|
||||
len(padded) != 2 + calc_padded_len(unpadded_len)): raise Exception('invalid padding')
|
||||
|
||||
2
60.md
2
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`: unecoded proofs
|
||||
* `proofs`: unencoded 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).
|
||||
|
||||
1
65.md
1
65.md
@@ -32,6 +32,7 @@ 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
|
||||
|
||||
|
||||
2
84.md
2
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 `<link rel="me" href="nostr:nprofile1..." />` tag on the document). A role MAY be included as the
|
||||
(e.g. prompting the user or reading a `<meta name="nostr:nprofile1..." />` tag on the document). A role MAY be included as the
|
||||
last value of the tag.
|
||||
|
||||
```jsonc
|
||||
|
||||
Reference in New Issue
Block a user