NIP-31
No recomendadoEventos
No recomendado, aunque los tags alt siguen siendo comunes. Da a los eventos de kinds personalizados un tag alt con una descripción legible de una línea, para que los clientes que no conocen el kind puedan mostrar algo sensato.
No recomendado: unnecessarily bloated
Edita el formulario o el JSON: ambos se mantienen sincronizados, la insignia indica si el resultado es válido y, al tocar cualquier campo, se explica qué hace.
Aún sin firmar · Solo claves de demo. Las claves secretas de estos personajes son públicas a propósito.
Selecciona cualquier campo del formulario o del JSON para ver qué hace.
Paso 1 de 4
El NIP está marcado como no recomendado por innecesariamente pesado, y no tiene un reemplazo directo. Muchas apps siguen añadiendo tags alt, así que conviene reconocerlos. Los manejadores de apps de NIP-89 son la forma más completa de tratar los kinds desconocidos.
Ningún capítulo del curso cubre este NIP todavía. El editor de arriba es la forma más rápida de empezar.
NIP-89 permite a los clientes encontrar una app que maneje un kind desconocido.
Los eventos de calendario (NIP-52) son un kind personalizado típico que se beneficia de alt.
El texto de las especificaciones se cita en inglés del repositorio nostr-protocol/nips. Nuestras explicaciones y la interfaz están traducidas. Código fuente en GitHub en el 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.