El protocolo Nostr, explicado en inglés simple

Un protocolo es un conjunto de reglas sobre cómo los programas se comunican entre sí. Una plataforma es una empresa que ejecuta esos programas en tu nombre. Twitter es una plataforma. El correo electrónico es un protocolo. Nostr es un protocolo.

La distinción importa porque los protocolos y las plataformas tienen diferentes modos de fallo, diferentes estructuras de costos y diferentes futuros. Esta guía explica qué hace que Nostr sea un protocolo específicamente, qué significa en la práctica, y por qué el diseño se mantiene pequeño a propósito.

TL;DR. Nostr es un protocolo de mensajería pub/sub con firmas criptográficas. Define un pequeño formato de evento y una forma sencilla para que los clientes envíen y reciban esos eventos a través de relays. Ninguna empresa lo posee. Cualquiera puede escribir un cliente, ejecutar un relay o proponer extensiones. La especificación central cabe en algunas páginas.

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

Qué es realmente un protocolo

El correo electrónico es una buena comparación. Cuando envías un correo desde Gmail a Outlook, Gmail no necesita permiso de Outlook. Ambos servicios hablan SMTP (el protocolo de correo electrónico), y SMTP define todo lo necesario para que un servidor de correo entregue un mensaje a otro. Los servidores son de diferentes empresas. El protocolo es un acuerdo neutro.

Nostr funciona de la misma manera. Un evento de Nostr (un post, un "me gusta", un seguidor) es un objeto JSON con una forma específica definida en el protocolo. Un relay es cualquier servidor que se compromete a aceptar, almacenar y reenviar eventos que se ajusten a esa forma. Dos clientes cualesquiera que hablen Nostr pueden interactuar a través de cualquier relay que hable Nostr, independientemente de quién haya hecho cualquiera de los tres.

El protocolo es un acuerdo neutro. Las implementaciones son libres de ser cualquier cosa.

La especificación de Nostr, en las frases más breves

Tres reglas lo cubren casi todo.

1. Un evento es un objeto JSON con id, pubkey, created_at, kind, tags, content, sig. El id es un hash de los otros campos; el sig es una firma Schnorr sobre el id usando la contraparte privada de la pubkey.
2. Un relay acepta eventos válidos sobre WebSocket y sirve suscripciones que filtran eventos por autor, kind, etiqueta o tiempo.
3. Un cliente firma eventos y los publica en relays; lee eventos suscribiéndose a relays con filtros.

Ese es el protocolo central. Cada característica avanzada (artículos de forma larga, zaps, DMs, comunidades, listas) es una extensión que se ajusta a este marco sin cambiarlo.

Por qué el protocolo se mantiene pequeño

La mayoría de los protocolos crecen por acumulación. Cada caso de uso se añade a la especificación; cada década la especificación es más grande que la década anterior. HTTP ahora tiene cientos de páginas. El correo electrónico creció de un puñado de RFCs a una maraña. Nostr ha evitado esto por diseño.

El mecanismo son los NIPs (Nostr Implementation Possibilities). Las nuevas características no se añaden a la especificación central; se proponen como NIPs opcionales. Los clientes implementan los NIPs que les importan. Otros clientes los ignoran. Un NIP popular se convierte en parte del protocolo práctico porque suficientes implementaciones lo hablan; un NIP impopular se desvanece sin ceremonia.

Esto significa que el núcleo es para siempre pequeño (los invariantes importantes: eventos firmados, relays abiertos, identidad portátil) y los bordes son para siempre flexibles (las nuevas características evolucionan sin romper los clientes existentes). Un cliente Nostr de 2022 todavía funciona en 2026 porque el núcleo no cambió; simplemente hace menos cosas que los clientes más nuevos.

Protocolo vs plataforma, concretamente

Cinco diferencias prácticas que puedes sentir como usuario.

Identidad. En una plataforma, tu cuenta es propiedad de la empresa. En un protocolo, tu cuenta es una identidad criptográfica que tú posees. Nadie puede quitártela.

Datos. En una plataforma, tus posts viven en su base de datos. En un protocolo, tus posts viven en múltiples relays independientes. Si uno desaparece, los otros todavía los tienen.

Velocidad de características. En una plataforma, las características se lanzan cuando la empresa lo decide. En un protocolo, las características se lanzan cuando cualquier implementador las escribe. Esto es más lento en algunos aspectos (sin hoja de ruta central) y más rápido en otros (muchos experimentos en paralelo).

Monetización. En una plataforma, la empresa captura toda la monetización. En un protocolo, la monetización es lo que los usuarios e implementadores acuerdan. Nostr tiene zaps (propinas de igual a igual sobre Lightning) porque se ajustaba a la cultura; una comunidad de protocolo diferente podría llegar a normas diferentes.

Modo de fallo. Una plataforma puede desaparecer por completo. Un protocolo no; mientras un implementador se mantenga activo, el protocolo vive. Nostr está diseñado de manera que incluso si fiatjaf (el autor original) desapareciera mañana, la red seguiría funcionando sin cambios.

Qué el protocolo explícitamente no hace

Cinco cosas dejadas fuera de la especificación a propósito.

Moderación. El protocolo no decide qué contenido es aceptable. Cada relay tiene sus propias reglas; cada cliente tiene sus propios filtros; cada usuario tiene su propia lista de silenciados. La moderación ocurre en los bordes, no en el núcleo.

Búsqueda. No hay búsqueda definida por protocolo. Algunos relays indexan texto; otros no. Los clientes que quieren búsqueda confían en relays capaces de búsqueda o ejecutan su propio indexado. La ausencia es deliberada; mantiene el protocolo neutral en lo que se encuentra.

Ranking. Sin feed "Para ti". Sin ponderación de engagement. Los clientes muestran eventos por marca de tiempo por defecto; cualquier otro orden es una decisión a nivel de cliente, no a nivel de protocolo.

Descubrimiento. Sin motor de recomendaciones. Encontrar nuevas cuentas para seguir es una característica de cliente, no una característica de protocolo. Algunos clientes invierten mucho en esto (Primal); otros lo dejan a los usuarios (Damus).

Recuperación. Sin restablecimiento de cuenta. Pierde la clave privada, pierde la cuenta. El protocolo podría incluir rotación de claves pero no lo hace, porque los compromisos son reales y la comunidad no ha acordado un mecanismo específico aún. Esta es un área en curso (borradores NIP-26, NIP-41).

Cada omisión es una opción. Los protocolos se mantienen pequeños rehusándose a resolver cada problema a nivel de protocolo.

Quién decide qué se convierte Nostr

Nadie y todos.

No hay Fundación Nostr. Ningún grupo de trabajo corporativo. Ningún comité directivo. La autoridad más concentrada en cualquier lugar del ecosistema es el repositorio GitHub de fiatjaf donde se proponen NIPs, y incluso eso es solo un punto de coordinación, no un portero.

Los NIPs propuestos son leídos por desarrolladores de clientes. Los populares se implementan. Un NIP que tres clientes principales implementan es efectivamente parte del protocolo; un NIP que un desarrollador escribió pero nadie más le importa es solo un documento en GitHub.

Este proceso es desordenado. Hay problemas de coordinación, propuestas duplicadas y ocasionales políticas. También es resiliente de una manera específica: ninguna parte puede arruinarlo tomando una mala decisión, porque las malas decisiones simplemente no se adoptan. El protocolo evoluciona en direcciones aproximadas por el peso de las opciones de los desarrolladores, no por decreto.

Cuándo el modelo de protocolo gana

Los protocolos vencen a las plataformas en condiciones específicas:

• Cuando la propiedad importa más que el pulido. Los protocolos son usualmente menos pulidos que las plataformas. Ganan cuando te importa lo que el pulido no puede darte (identidad permanente, resistencia a la censura, interoperabilidad abierta).
• Cuando el efecto de red es la característica. El valor de un protocolo crece con la adopción por implementadores, no solo por usuarios. Más clientes y relays fortalecen la red de maneras que una plataforma no puede copiar.
• Cuando el horizonte a largo plazo importa. Las plataformas se compran, venden, cierran o cambian de dirección. Los protocolos sobreviven a cualquier implementador único. El correo electrónico es más antiguo que la mayoría de las empresas; Nostr apuesta por la misma dinámica.

Si tu caso de uso no coincide con ninguno de estos, una plataforma es usualmente más rápida y fácil. Esto es honesto. Nostr no es universalmente mejor que Twitter para cada posible uso. Es mejor de maneras específicas en las que un protocolo vence a una plataforma.

Leer la especificación actual

Si esta guía te hizo querer leer el protocolo directamente, el repositorio de NIPs tiene la lista completa. NIP-01 es el núcleo; los NIPs numerados después de él son extensiones. No necesitas entender nada de esto para usar Nostr, pero leer NIP-01 toma unos diez minutos y aclara mucho.