Kinds y NIPs

Un sobre, muchos sellos

Hasta ahora todos los eventos se han visto iguales: un id, una pubkey, una marca de tiempo, algunas etiquetas, algo de contenido y una firma. Una nota tipo tuit, tu perfil, un “me gusta”, una entrada de blog y un recibo de Lightning viajan todos en exactamente el mismo sobre.

Entonces, ¿cómo sabe una app qué es cada cosa? Por un campo diminuto: el kind. Es solo un número entero, como un sello en el sobre. 1 significa “nota de texto corta”, 0 significa “mi perfil”, 7 significa “reacción”, 30023 significa “artículo largo”. Eso es todo. Ni tipos de mensaje nuevos ni endpoints nuevos: Nostr crece inventando números nuevos.

Piensa en el kind como la sección de una biblioteca. Todos los libros (eventos) están encuadernados igual, pero la etiqueta del lomo le dice al bibliotecario (el relay) en qué estante ponerlo, y les dice a los lectores (los clientes) cómo mostrarlo.

La tabla periódica de los kinds

Los químicos ordenan los elementos según sus propiedades. Podemos hacer lo mismo con los kinds: el color de una casilla es su categoría de almacenamiento, que depende únicamente del rango del número. Explora un poco: cada casilla abre un evento de ejemplo real. Intenta visitar los cuatro colores.

▸  { "id": "ea2e3eb8fe5e6cfbc202da21df546f68c6673e9a00c0aed61cffbac7aed9faf7" ,"pubkey": "a73883912a48c3551c1548fd454876d577126a61c76b5486c807bfec5869e183" ,"created_at": 1735686600 ,"kind": 1 , "tags": [  ] ,"content": "testing testing is this thing on" ,"sig": "82bc74fdbd5b113f257f4c8b2a6db64410ae897362bd42839fe9a34737d5ecb518a99f8517058ef8c2beadc222142e4d68f034e829edc9dd1b6bd13d2a139a7d"  } 

["REQ","kinds-demo",{"kinds":[1],"limit":10}]

import { kinds } from "nostr-tools";

kinds.ShortTextNote;            // 1
kinds.LongFormArticle;          // 30023
kinds.classifyKind(30023);      // "parameterized" (el nombre antiguo de nostr-tools para direccionable)
kinds.isReplaceableKind(10002); // true

Cuatro formas de guardarse

El número le dice a un relay qué debe conservar. NIP-01 divide la recta numérica en cuatro barrios:

• Regular (1, 2, 4–44, 1000–9999): un diario. Se conserva cada página. Las notas, reacciones, reposts y recibos de zaps se acumulan para siempre (o hasta que el relay decida otra cosa).
• Reemplazable (0, 3, 10000–19999): una pizarra. Cada persona tiene una por kind; al escribir una nueva se borra la anterior. Tu perfil (kind 0), tu lista de seguidos (kind 3) y tu lista de relays (kind 10002) funcionan así.
• Efímero (20000–29999): una llamada telefónica. Los relays se lo pasan a quien esté escuchando en ese momento y luego lo olvidan. Perfecto para desafíos de inicio de sesión y la charla de los firmantes.
• Direccionable (30000–39999): un conjunto de pizarras con etiqueta. Una por persona, por kind y por etiqueta d. Así puedes editar varios artículos largos de forma independiente.

Juega con él. Publica algunas versiones, cambia de categoría y luego prueba a reenviar una copia antigua:

["a", "30023:e550c6e92808f358382b7b8c14345344f5ef9a299529834d1c26d57b6ace44cc:relays-explained", "wss://relay.alpha.example"]

["REQ", "article", { "kinds": [30023], "authors": ["e550c6…"], "#d": ["relays-explained"] }]

¿Quieres poner a prueba tu intuición? Escribe cualquier número y mira en qué barrio vive:

NIPs: cómo crece Nostr sin un jefe

¿Quién decide que 7 significa “reacción”? Nadie y todos. Un NIP (Nostr Implementation Possibility, “posibilidad de implementación de Nostr”) es un documento corto y público que describe una convención: qué kind usar, qué etiquetas, qué significa el contenido. Viven en un único repositorio de GitHub, pero funcionan más como recetas compartidas en una comida a la canasta que como leyes:

1. Alguien tiene una idea. Una desarrolladora quiere encuestas, o calendarios, o mercados.
2. Primero lo construye. Idealmente en un cliente y un relay reales, eligiendo un número de kind que nadie más use.
3. Abre un pull request. La gente discute, simplifica y le busca los fallos en público.
4. Se fusiona cuando es real. El README pide que un NIP esté implementado en al menos dos clientes y un relay (cuando aplique), que tenga sentido, que sea opcional y retrocompatible, y que no añada una segunda forma de hacer lo mismo.

El truco clave es la palabra opcional. Un cliente que no entiende el kind 31922 (un evento de calendario) simplemente lo ignora. No se rompe nada. Por eso Nostr puede crecer hacia los lados: microblogging, contenido largo, transmisiones en vivo, colaboración en código y wallets comparten los mismos relays y las mismas claves.

Comprobación rápida