NIPs de Nostr explicadas: los documentos de especificación del protocolo

La evolución de Nostr ocurre a través de NIPs, documentos de especificación cortos que cualquiera puede proponer. Si quieres entender cómo nuevas características como zaps o DMs cifrados se integran en el protocolo, los NIPs son la respuesta.

Esta guía cubre qué son los NIPs, cómo funcionan como mecanismo de gobernanza, y cuáles leer si quieres profundizar técnicamente.

Los NIPs son documentos markdown cortos en GitHub que proponen cómo implementar características de Nostr. Los desarrolladores de clientes eligen cuáles soportar. Un NIP se convierte en "real" cuando suficientes implementadores la adoptan. El conjunto central de NIPs ampliamente utilizados es alrededor de 30; la lista completa está más cerca de 100.

Cuando estés listo, pide tu dirección @nostr.blog →

Qué es realmente un NIP

Un NIP es un archivo markdown en el repositorio github.com/nostr-protocol/nips. Cada archivo describe una característica, formato o convención específica: cómo firmar eventos, cómo se ve un evento de metadatos de perfil, cómo enviar un mensaje directo, qué formato utilizan las solicitudes de zap Lightning.

El tamaño varía. Los NIPs más cortos tienen menos de una página; los más largos tienen varios miles de palabras. La mayoría rondan entre 500 y 2000 palabras. Están escritos para ser implementables solo a partir de la especificación, así que incluyen formatos de mensajes, campos requeridos y ejemplos de eventos.

La convención de nombres es NIP-XX donde XX es un número. Los números se asignan cuando se fusiona el NIP; no reflejan prioridad o importancia. NIP-05 trata sobre identificadores verificados; NIP-04 es el estándar anterior de DM; NIP-01 es el protocolo central. Los números rastrean el orden de propuesta, no la importancia de la característica.

Por qué "Implementation Possibilities"

El nombre es una elección deliberada. Compara con otras tradiciones de especificación.

• RFCs (Requests for Comments) en protocolos de internet a menudo terminan siendo obligatorios para la interoperabilidad.
• EIPs (Ethereum Improvement Proposals) a menudo se hacen obligatorios a través de una actualización de red.
• NIPs son permanentemente opcionales. Un cliente que implementa 40 NIPs y un cliente que implementa 10 son ambos clientes Nostr válidos; simplemente hacen diferentes subconjuntos de cosas.

Esto significa que los NIPs nunca "rompen" implementaciones existentes. Un nuevo NIP para alguna característica no fuerza a clientes más antiguos a cambiar. El protocolo crece en los bordes mientras el núcleo se mantiene estable.

El ciclo de vida del NIP

Cómo un nuevo NIP llega a existir:

1. Alguien nota una brecha o necesidad. "No tenemos una forma estándar de hacer X." Podría ser un desarrollador de cliente, un operador de relay, o un usuario frustrado por un problema específico.
2. Escriben un borrador. El formato sigue los NIPs existentes: título, propósito, especificación, ejemplos.
3. Envían un pull request al repositorio de NIPs.
4. La comunidad revisa. Desarrolladores, operadores de relay y usuarios interesados comentan. El borrador se revisa según la retroalimentación.
5. Se fusiona o se abandona. Los NIPs fusionados reciben un número y se convierten en parte del repositorio. Los borradores abandonados quedan en el historial de pull requests.
6. La implementación sigue (o no). Algunos NIPs se implementan dentro de semanas. Algunos esperan años. Algunos nunca se implementan ampliamente.

El proceso es ligero. Sin votaciones de comité, sin aprobación formal. Si el pull request obtiene retroalimentación ampliamente positiva y aborda una necesidad obvia, se fusiona.

NIPs que importan si eres un usuario

La mayoría de los NIPs son invisibles para los usuarios. Un puñado afecta tu experiencia diaria:

• NIP-01: Protocolo central. Cómo se estructuran y firman los eventos. Nunca lo ves, pero todo lo demás depende de ello.
• NIP-05: Identificadores verificados. Te da nombres legibles como tu@dominio.com. Nuestra guía de NIP-05 lo cubre.
• NIP-07: Firma de extensión de navegador. Permite que clientes web firmen sin ver tu clave privada.
• NIP-19: Codificación Bech32. Por qué tu clave pública se ve como npub1... en lugar de hex crudo.
• NIP-23: Artículos de forma larga. Habilita publicaciones tipo blog en Nostr.
• NIP-44: DMs cifrados. El estándar moderno de mensajería directa (mejor que el anterior NIP-04).
• NIP-57: Zaps. Propinas Lightning con recibos públicos.
• NIP-98: Autenticación HTTP. Permite que identidades Nostr se autentiquen en sitios web regulares.

Como usuario te beneficias de todos estos sin interactuar con ellos. Los clientes manejan los detalles del protocolo.

NIPs que importan si eres un desarrollador

Si estás escribiendo o manteniendo un cliente Nostr, los NIPs que vale la pena leer crecen a docenas:

• NIP-01 a NIP-10 (mecánicas centrales).
• NIP-11 (documentos de información de relay).
• NIP-13 (prueba de trabajo, para resistencia al spam).
• NIP-17 (DMs envueltos como regalo para ocultamiento de metadatos).
• NIP-22 (expiración de eventos).
• NIP-27 (referencias de notas de texto).
• NIP-30 (emoji personalizado).
• NIP-31 (tipos de eventos).
• NIP-33 (eventos reemplazables parametrizados).
• NIP-42 (autenticación de conexiones a relays).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (capacidad de búsqueda).
• NIP-65 (metadatos de lista de relay).
• NIP-78 (datos de aplicación personalizada arbitraria).

Estos son los que la mayoría de clientes principales implementan. Un cliente que soporta este conjunto más los NIPs orientados al usuario anteriores cubre el 95% del uso típico.

Leer un NIP

Si quieres leer uno directamente, el repositorio está en github.com/nostr-protocol/nips. La estructura de la mayoría de los NIPs:

• Título y descripción. Qué propone el NIP.
• Motivación. Por qué se necesita la característica.
• Especificación. Formato exacto de mensaje, campos requeridos, reglas de validación.
• Eventos de ejemplo. JSON concreto mostrando cómo se ve un evento conforme.
• Comportamiento de cliente/relay. Cómo las implementaciones deben manejar los eventos.

Los NIPs están escritos para ser legibles por desarrolladores que los implementan. La sección de especificación es la importante; es donde vive el protocolo actual.

NIPs con adopción parcial

Algunos NIPs existen pero se implementan de manera inconsistente en los clientes. Esto crea casos extremos donde tu experiencia varía según el cliente.

NIP-44 (DMs cifrados). Adoptado por Damus, Primal, Amethyst y la mayoría de clientes principales en 2024-2025. Algunos clientes más antiguos solo soportan NIP-04. Si envías un DM a alguien cuyo cliente solo soporta NIP-04, tus mensajes NIP-44 fallan silenciosamente. La respuesta práctica: usa un cliente moderno y espera que tu corresponsal también.

NIP-17 (DMs envueltos como regalo). DMs que ocultan metadatos. La adopción en 2026 crece pero no es universal. La característica es excelente donde ambas partes de los clientes la soportan; de lo contrario, silenciosamente vuelve a DMs menos privados.

NIP-46 (firmantes remotos). Permite que un firmante de hardware o aplicación bunker firme eventos en nombre de un cliente. Soportado en Amethyst, parcialmente en otros lugares.

NIP-65 (lista de relays del usuario). Permite que los usuarios publiquen sus relays preferidos para que los clientes enruten automáticamente a los lugares correctos. La adopción está mejorando; los clientes más antiguos la ignoran.

NIP-50 (búsqueda). Permite que los clientes consulten relays para coincidencias de texto. Algunos relays la soportan; muchos no. La calidad de búsqueda es inconsistente como resultado.

Verificar qué NIPs soporta un cliente dado es un diagnóstico útil cuando algo no funciona como se esperaba. La mayoría de los clientes publican su matriz de soporte de NIP en su documentación.

Cómo el proceso de NIP mantiene el protocolo coherente

Sin autoridad central, así que la coherencia proviene de la dinámica social. Algunas observaciones:

Los NIPs malos no se propagan. Una propuesta que duplica un NIP existente o resuelve el problema equivocado obtiene adopción mínima y muere silenciosamente. La comunidad no es formal pero es muy opinada.

Los buenos NIPs se implementan independientemente. Múltiples desarrolladores de clientes leen propuestas y deciden independientemente. Las buenas ideas acumulan adoptadores; las malas ideas no.

A veces emergen NIPs compitiendo. Dos propuestas diferentes para la misma característica pueden coexistir por un tiempo. Por lo general una gana en la práctica porque más clientes la implementan; a veces se fusionan.

Evolución compatible con bifurcación. Porque los NIPs son opcionales, un cliente puede implementar NIP-X-v1 y luego actualizar a NIP-X-v2 sin romper a nadie que solo soporta v1. El protocolo no se divide.

Esto es desordenado pero funcional. El protocolo ha evolucionado significativamente en cinco años sin un cuerpo de gobernanza central porque el mecanismo social de "los implementadores leen, los implementadores deciden, los implementadores programan" tiene suficiente alineación para producir coherencia.

Proponer tu propio NIP

Si tienes una idea para una nueva característica de Nostr:

1. Verifica primero el repositorio de NIPs. Alguien puede haber propuesto ya.
2. Si no, abre un issue de GitHub describiendo el problema que estás resolviendo.
3. Según la retroalimentación, redacta un NIP completo siguiendo el formato existente.
4. Envía un pull request.
5. Participa en la discusión. Sé dispuesto a revisar.
6. Si se fusiona, excelente. Si no, el problema puede tener una solución mejor; considera por qué.

No toda buena idea se convierte en un NIP. No todo NIP se convierte en una característica. El ecosistema tiene más propuestas que cualquier desarrollador único podría rastrear, y el filtro es "¿suficiente comunidad la implementa?" Ese filtro es el núcleo de cómo Nostr se mantiene coherente sin ser descendente.