¿Por qué Nostr?

La mañana en que Alice desapareció

Alice hornea los mejores rollos de canela del barrio. En cinco años reunió una audiencia de 20.000 personas en una gran red social. Ahí es donde sus clientes ven el menú del día, donde ella avisa cuando se agota todo y donde sus clientes de siempre la saludan.

Un martes abre la app y ve un recuadro gris: “Tu cuenta ha sido suspendida.” No hay ningún humano a quien llamar. No hay forma de exportar la lista de sus seguidores. Un filtro automático decidió algo, y cinco años de relaciones se quedaron en silencio con un solo clic.

Nadie tuvo que hackear a Alice. Nadie tuvo que discutir con ella. La empresa simplemente era dueña de la sala en la que ella hablaba, y le apagó el micrófono.

Cuatro formas de armar una red social

Tomemos a los mismos cinco amigos (Alice, Bob, Carol, Dave y Erin) y conectémoslos de cuatro formas distintas. Tu trabajo es ser el mono del caos: tumba servidores y luego pulsa Banear a Alice para ver a quién se le sigue escuchando.

• Centralizada: una empresa, un servidor, todo el mundo vive ahí.
• Federada: muchos servidores independientes que se reenvían publicaciones entre sí. Es el modelo de federación de Mastodon y del correo electrónico.
• Nostr: relays sencillos que guardan y reenvían notas, y personas que publican en varios relays a la vez.
• Bluesky: un diseño más nuevo en el que tus datos viven en un servidor de datos personal (PDS), y grandes agregadores cosen las publicaciones de todos en líneas de tiempo.

Prueba este orden: tumba BigCo en la red Centralizada, tea.social en la Federada, alpha en Nostr y el AppView en Bluesky. Después vuelve a cada una y pulsa Banear a Alice. ¿Notas el patrón?

¿Qué acaba de pasar?

La red Centralizada es un solo tronco: córtalo y cae el árbol entero. Si banean a Alice, simplemente desaparece, porque la empresa es la red.

La red Federada es mucho mejor. Perder una instancia solo afecta a quienes viven en ella. Pero mira la fila de Alice en el marcador: “Cuenta perdida junto con tea.social.” En un mundo federado tu nombre se ve como @alice@tea.social, y esa segunda mitad es el casero. Si la instancia cierra, o el administrador te banea, tu cuenta y tu lista de seguidores se van con ella. Puedes mudarte, pero solo mientras el antiguo casero siga abriendo la puerta.

Nostr ni se inmuta. La identidad de Alice no es una cuenta en el servidor de nadie: es un par de claves que vive en su propio dispositivo. Cada nota que escribe está firmada con su clave secreta, así que cualquier relay puede guardarla y cualquier lector puede comprobar que de verdad la escribió ella. Envía cada nota a dos relays. Si uno muere, o la banea, el otro todavía la tiene.

Bluesky queda en un punto intermedio. Las cuentas pueden moverse entre servidores de datos, lo cual es genial. Pero en la práctica la mayoría lee a través de un gran relay y un gran AppView, así que tumbar cualquiera de los dos todavía deja a oscuras casi todo hoy en día.

Por qué los relays son tontos a propósito

Este es el truco que hace funcionar a Nostr: los relays no hablan entre sí y no son dueños de nadie. Un relay es un pequeño servidor que acepta notas firmadas (llamadas eventos) a través de un WebSocket y se las entrega a quien las pida.

Piensa en los relays como apartados de correos más que como una plaza pública. Alice alquila un apartado en dos oficinas de correos y deja una copia de cada carta en ambos. Los carteros de sus amigos (sus clientes) saben qué oficinas usa y van a recoger sus cartas allí. Si una oficina se incendia o se niega a atenderla, las cartas siguen esperando en la otra, y mañana Alice puede abrir un tercer apartado sin pedirle permiso a nadie.

Esa es toda la receta:

1. Tú eres tus claves. Sin registro, sin nombre de usuario que te puedan confiscar. Tu clave pública (npub) es tu nombre.
2. Cada nota va firmada. Los relays no pueden falsificar ni editar en secreto lo que dijiste.
3. Publica en todas partes. Eliges varios relays y puedes cambiarlos cuando quieras.
4. Los lectores te siguen a ti. Los clientes usan tu lista de relays publicada para encontrar tus notas: ese es el modelo outbox.

["EVENT", {
  "id": "<sha256 de 32 bytes del evento serializado, en hex>",
  "pubkey": "<clave pública de Alice de 32 bytes, en hex>",
  "created_at": 1735689600,
  "kind": 1,
  "tags": [],
  "content": "¡Los rollos de canela vuelven a las 8!",
  "sig": "<firma Schnorr de 64 bytes del id, en hex>"
}]

import { finalizeEvent, generateSecretKey } from "nostr-tools/pure";
import { SimplePool } from "nostr-tools/pool";

const sk = generateSecretKey(); // tu identidad: 32 bytes aleatorios que nunca salen del dispositivo
const note = finalizeEvent(
  { kind: 1, created_at: Math.floor(Date.now() / 1000), tags: [], content: "¡hola, relays!" },
  sk, // calcula el pubkey, el id y la firma
);

const pool = new SimplePool();
const relays = ["wss://relay.alpha.example", "wss://relay.beta.example"];
// Una promesa por relay: basta con que *algún* relay acepte la nota.
await Promise.any(pool.publish(relays, note));

{
  "kind": 10002,
  "tags": [
    ["r", "wss://relay.alpha.example"],
    ["r", "wss://relay.beta.example", "write"],
    ["r", "wss://relay.gamma.example", "read"]
  ],
  "content": "",
  "...": "pubkey, created_at, id y sig como siempre"
}

¿Esto es simplemente “cero moderación”?

No, y es un matiz importante. Cada relay es libre de poner sus propias reglas: bloquear spam, cobrar por el acceso (un relay de pago) o aceptar solo a los miembros de una comunidad. Cada cliente puede filtrar lo que ves, por ejemplo usando tu red de confianza.

Lo que Nostr elimina es el único cuello de botella. La moderación pasa a ser una decisión de muchos relays y muchas apps, en lugar del veredicto de una sola empresa que además tiene tu identidad. Esa propiedad tiene nombre: resistencia a la censura.

¿De dónde salió Nostr?

Nostr significa “Notes and Other Stuff Transmitted by Relays” (notas y otras cosas transmitidas por relays). Lo propuso en 2020 un desarrollador conocido como fiatjaf, como un protocolo deliberadamente diminuto: un formato de eventos en JSON, un puñado de mensajes por WebSocket y firmas de clave pública. Todo lo demás se añade mediante propuestas opcionales y numeradas llamadas NIPs (Nostr Implementation Possibilities), que se mantienen de forma abierta en github.com/nostr-protocol/nips.

El resto de este curso es un recorrido por esa receta. Lo siguiente: el par de claves que eres tú.

Comprobación rápida