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

update NIP to use alt tag

Browse Source
This commit is contained in:
pablof7z 2023-06-08 22:27:00 +02:00
parent b8aec7dad5
commit 964bc5b5ce
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
31.md
View File

@ -6,8 +6,10 @@ Dealing with unknown event kinds
`draft` `optional` `author:pablof7z` `author:fiatjaf` `draft` `optional` `author:pablof7z` `author:fiatjaf`
When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like `kind:1`), clients should use the `tags` field to store all their custom data related to their protocol, and use the `content` field to write a short human-readable plaintext summary of what that event is about. When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like `kind:1`), clients should use an `alt` tag to write a short human-readable plaintext summary of what that event is about.
The intent is that social clients, used to display only `kind:1` notes, can still show something in case a custom event pops up in their timelines. The intent is that social clients, used to display only `kind:1` notes, can still show something in case a custom event pops up in their timelines. The content of the `alt` tag should provide enough context for a user that doesn't know anything about this event kind to understand what it is.
These clients that only know `kind:1` are not expected to ask relays for events of different kinds, but users could still reference these weird events on their notes, and without proper context these could be nonsensical notes. Having the fallback text makes that situation much better -- even if only for making the user aware that they should try to view that custom event elsewhere. These clients that only know `kind:1` are not expected to ask relays for events of different kinds, but users could still reference these weird events on their notes, and without proper context these could be nonsensical notes. Having the fallback text makes that situation much better -- even if only for making the user aware that they should try to view that custom event elsewhere.
`kind:1`-centric clients can make interacting with these event kinds more functional by supporting [NIP-89](https://github.com/nostr-protocol/nips/blob/master/89.md).