← All NIPs

NIP-31

Dealing with Unknown Events

UnrecommendedEvents

Unrecommended, though alt tags are still common. Give custom-kind events an alt tag with a one-line human description, so clients that don't know the kind can still show something sensible.

At a glance

Status
Still documented, but new software should not build on it.
Last changed
May 31, 2026

Not recommended: unnecessarily bloated

Try it

Edit the form or the JSON: both stay in sync, the badge says whether the result is valid, and tapping any field explains it.

Examples
Valid 6 notes

Not signed yet · Demo keys only. These personas' secret keys are public on purpose.

Form
Jan 1, 2025, 12:00 AM UTC

Content

The event's own content, defined by its kind's NIP.

Tags

  1. alt Required

    A short human-readable summary for clients that don't understand this kind.

  2. d Not described by this NIP
  3. title Not described by this NIP
  4. start Not described by this NIP
  5. end Not described by this NIP
  6. location Not described by this NIP
Add tag

How this NIP works

Step 1 of 4

Unrecommended, but you will see it

The NIP is marked unrecommended as unnecessarily bloated, and has no direct replacement. Many apps still add alt tags, so it helps to recognise them. NIP-89 app handlers are the richer way to deal with unknown kinds.

In the course

No course chapter covers this NIP yet. The editor above is the quickest way in.

See also

Specification

Specification text is quoted in English from the nostr-protocol/nips repository. Our explanations and the interface are translated. Source on GitHub at commit 0046368

Read the spec190 words, quoted from the repository at commit 0046368.

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 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.

kind:1-centric clients can make interacting with these event kinds more functional by supporting NIP-89.