rename coordinates: nitem->naddr, "i"->"a"

This commit is contained in:
fiatjaf 2023-02-13 08:47:23 -03:00
parent a85067ec68
commit b4493aa56a
4 changed files with 12 additions and 11 deletions

10
19.md
View File

@ -35,7 +35,7 @@ These are the possible bech32 prefixes with `TLV`:
- `nprofile`: a nostr profile
- `nevent`: a nostr event
- `nrelay`: a nostr relay
- `nitem`: a nostr parameterized replaceable event coordinate (NIP-33)
- `naddr`: a nostr parameterized replaceable event coordinate (NIP-33)
These possible standardized `TLV` types are indicated here:
@ -44,14 +44,14 @@ These possible standardized `TLV` types are indicated here:
- for `nprofile` it will be the 32 bytes of the profile public key
- for `nevent` it will be the 32 bytes of the event id
- for `nrelay`, this is the relay URL
- for `nitem`, it is the identifier (the `"d"` tag) of the event being referenced
- for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced
- `1`: `relay`
- for `nprofile`, `nevent` and `nitem`, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii
- for `nprofile`, `nevent` and `naddr`, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii
- this may be included multiple times
- `2`: `author`
- for `nitem`, the 32 bytes of the pubkey of the event
- for `naddr`, the 32 bytes of the pubkey of the event
- `3`: `kind`
- for `nitem`, the 32-bit unsigned integer of the kind, big-endian
- for `naddr`, the 32-bit unsigned integer of the kind, big-endian
## Examples

8
23.md
View File

@ -31,13 +31,13 @@ These articles are meant to be editable, so they should make use of the replacea
### Linking
The article may be linked to using the NIP-19 `nitem` code along with the `"i"` tag (see NIP-33 and NIP-19).
The article may be linked to using the NIP-19 `naddr` code along with the `"a"` tag (see NIP-33 and NIP-19).
### References
Clients that support publishing NIP-23 events should implement support for parsing pasted NIP-19 `nitem` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](nitem1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`).
Clients that support publishing NIP-23 events should implement support for parsing pasted NIP-19 `naddr` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](naddr1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`).
Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:nitem1...` links or direct links to web clients that will handle these references.
Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:naddr1...` links or direct links to web clients that will handle these references.
The idea here is that having these tags is that reader clients can display a list of backreferences at the bottom when one article mentions another.
@ -56,7 +56,7 @@ The same principles can be applied to `nevent1...`, `note1...`, `nprofile1...` o
["published_at", "1296962229"],
["t", "placeholder"],
["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "wss://relay.example.com"],
["i", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"]
["a", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"]
],
"pubkey": "...",
"id": "..."

4
33.md
View File

@ -38,11 +38,11 @@ Normally (as per NIP-01, NIP-12) the `"p"` tag is used for referencing public ke
equivalents for event tags (i.e. an `nprofile` is generally translated into a tag
`["p", "<event hex id>", "<relay url>"]`).
To support linking to parameterized replaceable events, the `nitem` code is introduced on
To support linking to parameterized replaceable events, the `naddr` code is introduced on
NIP-19. It includes the public key of the event author and the `d` tag (and relays) such that
the referenced combination of public key and `d` tag can be found.
The equivalent in `tags` to the `nitem` code is the tag `"i"`, comprised of `["i", "<kind>:<pubkey>:<d-identifier>", "<relay url>"]`.
The equivalent in `tags` to the `naddr` code is the tag `"a"`, comprised of `["a", "<kind>:<pubkey>:<d-identifier>", "<relay url>"]`.
Client Behavior
---------------

View File

@ -92,6 +92,7 @@ When experimenting with kinds, keep in mind the classification introduced by [NI
| ---------- | ----------------------- | ----------------- | ------------------------ |
| e | event id (hex) | relay URL, marker | [1](01.md), [10](10.md) |
| p | pubkey (hex) | relay URL | [1](01.md) |
| a | coordinates to an event | relay URL | [33](33.md), [23](23.md) |
| r | a reference (URL, etc) | | [12](12.md) |
| t | hashtag | | [12](12.md) |
| g | geohash | | [12](12.md) |