nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 16:35:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Improve the text

Browse Source
This commit is contained in:
arthurfranca 2023-03-23 10:11:18 -03:00
parent 9764a3b510
commit 2b926f54cd
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
27.md
View File

@ -6,13 +6,13 @@ Text Note References
`draft` `optional` `author:fiatjaf` `author:scsibug` `author:arthurfranca`
This document standardizes the treatment given by clients of inline references of other events and pubkeys inside the content of `text notes` (currently kinds 1 and 30023).
This document standardizes the treatment given by clients of inline references of other events and profiles inside the content of `text notes` (currently kinds 1 and 30023).
Clients that want to allow inline mentions of profiles 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 by a client, for example, when an user pastes a NIP-19 nostr profile string inside the event content input field (or optionally by any other means the client may wish to support, such as selecting an user from a context menu or autocompleter), the client MUST replace it with the notation `nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg` as per NIP-21 before effectively creating the event. The client MAY add the corresponding pubkey to the `.tags` with the tag `p` if it wishes to notify mentioned user.
Once a mention is identified, for example, the pubkey `27866e9d854c78ae625b867eefdfa9580434bc3e675be08d2acb526610d96fbe`, the client MUST replace its textual reference (inside `.content`) with the notation `nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg` as per NIP-21. If client doesn't support NIP-21, it can instead use a regular http link to a nostr client such as `https://a-nostr-client.com/nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg`. The client MAY add that pubkey to the `.tags` with the tag `p` if it wishes to notify mentioned user.
The same process applies for referencing event IDs, except that the client SHOULD NOT add the event id to the `.tags` with the tag `e` so to not negatively impact thread loading.
The same process applies for referencing event IDs (using `nostr:nevent1...`), except that the client SHOULD NOT add the event id to the `.tags` with the tag `e` so to not negatively impact thread loading.
Because `e` tags on `text notes` are usually considered ancestor events used to build a conversarion thread (as per NIP-10), it is advised to use inline references when mentioning events and NOT adding corresponding `e` tag to the `.tags` event key.
A client that receives a `text_note` event with such `nostr:...` mentions in its `.content` CAN do any desired context augmentation (for example, linking to the pubkey or showing a preview of the mentioned event contents) it wants in the process.
Note that the usage of `nostr:npub1...` for profile mentions or `nostr:note1...` for event mentions is discouraged due to their lack of embedded relay recommendation.
A reader client that receives a `text_note` event with such `nostr:...` mentions in its `.content` CAN do any desired context augmentation (for example, linking to the profile or showing a preview of the mentioned event contents) it wants in the process. If turning such mentions into links, they could become internal links, NIP-21 links or direct links to web clients that will handle these references.