unrecommended: deprecated in favor of NIP-27
This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of
Clients that want to allow tagged mentions they MUST show an autocomplete component or something analogous to that whenever the user starts typing a special key (for example, “@”) or presses some button to include a mention etc – or these clients can come up with other ways to unambiguously differentiate between mentions and normal text.
Once a mention is identified, for example, the pubkey
27866e9d854c78ae625b867eefdfa9580434bc3e675be08d2acb526610d96fbe, the client MUST add that pubkey to the
.tags with the tag
p, then replace its textual reference (inside
.content) with the notation
#[index] in which “index” is equal to the 0-based index of the related tag in the tags array.
The same process applies for mentioning event IDs.
A client that receives a
text_note event with such
#[index] mentions in its
.content CAN do a search-and-replace using the actual contents from the
.tags array with the actual pubkey or event ID that is mentioned, doing any desired context augmentation (for example, linking to the pubkey or showing a preview of the mentioned event contents) it wants in the process.
#[index] has an
index that is outside the range of the tags array or points to a tag that is not an
p tag or a tag otherwise declared to support this notation, the client MUST NOT perform such replacement or augmentation, but instead display it as normal text.
Source: nostr-protocol/nips/08.md version: b315d1a 2023-04-19T22:32:08+09:00