Cómo funciona realmente Nostr: el protocolo, sin jerga técnica

La mayoría de explicaciones sobre Nostr se detienen en "es un protocolo social descentralizado" y dejan sin decir la parte interesante. La parte interesante es que todo el protocolo cabe en un documento corto. Sin trucos inteligentes, sin complejidad oculta. Solo algunos primitivos que funcionan juntos.

Esta guía recorre esos primitivos en el orden en que surgen cuando realmente usas Nostr: cómo se construye un evento, cómo se firma, cómo llega a los relays, cómo se suscriben los clientes, y cómo se ve el flujo cuando das like a un post, recibes una respuesta o reciben un zap. Sin comparaciones con blockchain, sin narrativas grandilocuentes. Solo los mecanismos.

TL;DR. Nostr es pub/sub sobre WebSockets con firmas criptográficas. Los clientes publican objetos JSON firmados (eventos) a relays (servidores pequeños), y otros clientes se suscriben a relays con filtros que coinciden con los eventos que quieren. Las firmas previenen falsificaciones; múltiples relays previenen puntos únicos de fallo. Ese es todo el protocolo; todo lo demás son convenciones de formato para diferentes tipos de contenido.

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

El componente básico: un evento

Todo en Nostr es un evento. Un post es un evento. Una reacción es un evento. Una actualización de perfil es un evento. Un mensaje directo es un evento. Un recibo de zap es un evento.

Un evento es un objeto JSON con exactamente esta forma:

{
  "id": "abc123...",
  "pubkey": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88",
  "created_at": 1776329035,
  "kind": 1,
  "tags": [
    ["t", "nostr"],
    ["p", "3bf0c63f..."]
  ],
  "content": "hello nostr",
  "sig": "def456..."
}

Seis campos hacen trabajo significativo. id es un hash del contenido del evento en sí; lo identifica de forma única. pubkey es el autor (una clave pública de 64 caracteres hexadecimales). created_at es una marca de tiempo Unix. kind es un entero que describe lo que representa el evento (más sobre esto abajo). tags es una lista de anotaciones estructuradas como hashtags (t), menciones (p para pubkey, e para evento), y docenas de otros. content es la carga útil de forma libre, generalmente texto.

sig es la firma de Schnorr, hecha con la clave privada del autor, sobre el hash en id. Este es el campo que previene falsificaciones: cualquiera puede calcular el hash, pero solo el titular de la clave privada puede producir una firma válida sobre él.

¿Qué es un "kind"

El campo kind le dice a los clientes cómo interpretar el evento. El número es todo el tipo semántico.

Un puñado de kinds en uso activo:

Nuevos kinds se proponen y se estandarizan a través de NIPs (Nostr Implementation Possibilities). Cualquiera puede proponer uno. Los que se adopten ampliamente se convierten en partes de facto del protocolo; los que no simplemente permanecen como nicho sin romper nada.

Cómo se publica un evento

Cuando presionas "publicar" en un cliente Nostr, se ejecuta esta secuencia:

1. El cliente ensambla el JSON. Rellena pubkey, created_at, kind, tags, content.
2. El cliente calcula el id. Ejecuta SHA-256 sobre una serialización canónica de esos campos. Este es el hash que cubre la firma.
3. El cliente firma el id con la clave privada. Firma de Schnorr sobre secp256k1, la misma curva que usa Bitcoin. La firma de 64 bytes se convierte en el campo sig.
4. El cliente abre conexiones WebSocket a cada relay configurado. O reutiliza las existentes abiertas si están activas.
5. El cliente envía el evento como un mensaje. El formato en línea es un array JSON: ["EVENT", {...event...}].
6. Cada relay valida la firma. Rechaza el evento si la firma no verifica contra la pubkey reclamada. Acepta y almacena en caso contrario.
7. Cada relay envía el evento a los suscriptores. Cualquier cliente con una suscripción abierta cuyo filtro coincida con este evento recibe el evento entregado en tiempo real.

El viaje redondo completo toma de 50 a 300 milisegundos dependiendo de las ubicaciones de los relays. Si algún relay es lento o está sin conexión, los otros relays aún publican el evento. Solo necesitas que un relay lo acepte para que el evento exista en la red.

Cómo un cliente obtiene posts

Leer es el espejo de publicar.

Tu cliente abre conexiones WebSocket a una lista de relays. Para cada uno, envía un mensaje de suscripción:

["REQ", "sub_id_1", { "authors": ["pubkey1", "pubkey2", ...], "kinds": [1, 6], "limit": 50 }]

Esto pide al relay hasta 50 eventos de los autores en la lista, de kind 1 (nota corta) o kind 6 (repost). El relay:

1. Consulta su base de datos local para eventos coincidentes, los envía (más antiguos a más nuevos por defecto, hasta el límite) de vuelta al cliente como mensajes EVENT.
2. Envía un mensaje EOSE (fin de eventos almacenados) para que el cliente sepa que el volcado histórico está completo.
3. Mantiene la suscripción abierta. Cualquier nuevo evento que coincida con el filtro (publicado por alguien más después) se envía al cliente en tiempo real.

Así es cómo tu feed se vuelve en vivo. No estás consultando; el relay está transmitiendo.

Tu cliente hace esto en paralelo en cada relay configurado. La unión de respuestas es tu línea de tiempo. Los eventos duplicados en relays se deduplicen por id.

Cómo las firmas realmente previenen falsificaciones

Esta es la parte que la mayoría de explicaciones dejan pasar por alto.

Cuando un cliente recibe un evento, recalcula el hash sobre la serialización canónica (de la misma manera que el publicador) y ejecuta verificación de Schnorr: dada la pubkey, el id y el sig, ¿criptográficamente verifica la firma?

Si es sí, el evento es auténtico. El autor de este evento era el titular de esa pubkey en el momento de firmar. Cada cliente ejecuta esta verificación en cada evento. Un relay que envía un evento falsificado con una firma incorrecta simplemente lo deja caer silenciosamente cada cliente que lo ve.

Esto importa porque significa que los relays no son de confianza. Un relay malicioso no puede poner palabras en tu boca. Puede rehusar servir tus posts, puede inyectar posts legítimos de alguien más en tu feed, pero no puede producir un post válido firmado por ti sin tu clave privada, y no puede modificar uno de tus posts existentes sin romper la firma.

El costo de esta propiedad es exactamente una verificación de Schnorr por evento, que es lo suficientemente rápida para que incluso clientes móviles la manejen a decenas de miles de eventos por segundo.

Lo que los relays realmente hacen

Un relay es un tubo tonto y rápido con tres trabajos:

1. Aceptar eventos y validar firmas. Rechaza cualquier cosa que no verifique o falle controles de política (filtros de spam, límites de tamaño, pubkeys bloqueadas).
2. Almacenar eventos. Generalmente en una base de datos SQLite o PostgreSQL indexada por id, pubkey, kind y valores de tags.
3. Servir suscripciones. Hacer coincidir filtros REQ entrantes contra la base de datos (para histórico) y contra eventos en vivo (para tiempo real).

Eso es todo. Un relay no clasifica, no recomienda, no cura, no monetiza, no muestra anuncios, no aplica un algoritmo, ni hace nada que una plataforma haría. Solo reenvía bytes firmados.

La ausencia de esos otros trabajos es por qué los relays pueden ser pequeños. Un único VPS de $5 por mes puede ejecutar un relay sirviendo a cientos de usuarios activos. La misma función a escala de Twitter cuesta miles de millones porque Twitter hace todas las otras cosas.

Las políticas de relay difieren. Algunas son sin permisos y sirven cualquier evento firmado. Algunas requieren pago (el modelo de "relay pagado"), otras se restringen a una comunidad específica (empleados de una empresa, miembros de un servidor Discord), y otras más son agresivas sobre filtrado de spam. Tú eliges qué relays usar; tu elección afecta qué posts ves y cuáles llegan a tus seguidores.

Un ejemplo completo: alguien da like a tu post

Juntando todo, aquí es lo que sucede de punta a punta cuando Alice da like a un post que escribió Bob.

1. Bob publica. El cliente de Bob construye un evento kind:1 con contenido "hello world," lo firma, lo envía a cinco relays configurados de bob. Cada relay lo acepta y almacena.
2. Alice se suscribe. El cliente de Alice tiene una suscripción abierta en dos de esos relays con un filtro que incluye la pubkey de Bob en authors. Los relays envían el evento de Bob por la suscripción. El cliente de Alice muestra el post en su línea de tiempo.
3. Alice toca like. El cliente de Alice construye un evento kind:7 con contenido "+" (la convención Nostr de "like"), etiqueta el post al que reacciona (["e", "bob_post_id"]) y al autor (["p", "bob_pubkey"]). Lo firma y publica en cinco relays configurados de Alice.
4. La reacción se propaga. Cualquier relay que tenga una suscripción activa que coincida con el filtro { "#e": ["bob_post_id"], "kinds": [7] } (que es lo que el cliente de Bob usa para observar reacciones a sus propios posts) envía la reacción a Bob. El cliente de Bob agrega los likes y muestra el número bajo el post.

Observa lo que no sucedió. Ningún servicio centralizado de "botón de like" fue consultado. Ningún backend decidió si el like cuenta. El like es simplemente un evento firmado, anunciado en los mismos canales que el post en sí.

Lo que Nostr explícitamente no hace

Cinco cosas omitidas del protocolo central a propósito, porque pertenecen en el cliente o en el relay, no en el formato de cable compartido.

• Verificación de identidad. Nostr solo prueba "esta pubkey firmó este post." Si la pubkey pertenece a un ser humano específico es una pregunta separada respondida por NIP-05 y contexto fuera de cadena.
• Moderación de contenido. El protocolo no decide qué es visible. Los clientes filtran, los relays filtran, los usuarios filtran. Cada capa independientemente.
• Búsqueda. No hay punto final de búsqueda global. Algunos relays soportan búsqueda de texto sobre su pool de eventos local; no hay garantía de protocolo de que cualquier relay pueda encontrar cualquier post.
• Clasificación algorítmica. Sin feed "para ti" en el protocolo. La clasificación ocurre en el cliente si es que ocurre.
• Recuperación de cuenta. Sin restablecimiento de email, sin restablecimiento de teléfono, sin sistema central de disputas. Pierde la clave privada, pierde la identidad. Este es un equilibrio, no un error.

Esas ausencias son lo que hace el protocolo pequeño. También son lo que hace construir una experiencia de usuario pulida encima más difícil que construir una en una plataforma centralizada, que es el costo honesto.

Por qué el diseño funciona en absoluto

El diseño se basa en una propiedad simple: las firmas son baratas de verificar, la falsificación es imposible sin la clave privada, y los relays son libres de reemplazar.

Esos tres hechos se componen. La verificación barata significa que cada cliente puede verificar cada evento. La falsificación imposible significa que los relays no necesitan ser de confianza. El reemplazo libre significa que ningún relay tiene poder sobre nadie.

Juntos, obtienes una red social donde la capa de plataforma es intercambiable y la capa de identidad es propiedad del usuario. Que es lo que "descentralizado" realmente significa en la práctica, en lugar de cómo el marketing usualmente usa la palabra.

Si quieres ver el flujo completo desde el lado del usuario (un par de claves, una identidad NIP-05, una lista de relays, una billetera, listo para publicar), el registro de nostr.blog colapsa esos pasos en una página. Los mecanismos descritos aquí son lo que realmente se ejecuta debajo de ese flujo.