La respuesta corta
Nostr es un protocolo pequeño para publicar mensajes firmados. No es una empresa, no es una aplicación y no es una red a la que uno se afilie. Su repositorio expande el nombre como Notes and Other Stuff Transmitted by Relays, notas y otras cosas transmitidas por relays, y esa es casi toda la descripción: se firma una nota, se la entrega a unos servidores llamados relays, y cualquiera que la quiera la busca ahí y verifica la firma.
El problema que aborda
En una plataforma normal el nombre de usuario es una fila que la empresa puede reasignar, las publicaciones viven en sus servidores, y los seguidores son una lista que no se puede llevar a ningún otro lado. Las tres cosas pertenecen a la misma parte, así que perder la cuenta las pierde a las tres a la vez, sea por una decisión de política interna, un bloqueo automático o una quiebra. La cuenta no existe en ningún otro lugar, así que toda apelación pasa por ellos.
Nostr separa las tres: la identidad es una clave propia, las publicaciones son objetos firmados que cualquier servidor puede almacenar, y la lista de seguidos es a su vez una nota firmada que viaja con la clave.
La identidad es un par de claves
La cuenta es una clave pública. El inicio de sesión es la clave privada correspondiente. Ese es todo el sistema de identidad: no hay tabla de usuarios, no hay registro, no hay contraseña.
Ambas se muestran en los formatos bech32 de
NIP-19, npub1… y nsec1…,
que existen solo para exhibirse: las claves npub "NO DEBEN usarse en eventos NIP-01", que
usan hexadecimal crudo. La construcción de fondo es la misma que aparece en
claves públicas y privadas.
No hay recuperación de contraseña, y una clave privada filtrada no se puede revocar. En un servicio normal el servidor decide quién es uno, así que se le puede pedir que cambie de opinión. En Nostr nada decide eso: la clave es la identidad, de modo que quien la tenga es uno, de forma permanente, ante cada relay y cada cliente. El único remedio es abandonar la identidad y empezar con una clave nueva, dejando atrás seguidores e historial.
Es el mismo costo que se acepta al tener bitcoin en custodia propia, y la razón por la que la clave debe vivir en un signer y no pegarse dentro de una aplicación.
Todo es un evento firmado
NIP-01 define una única
estructura de datos, el evento: JSON con siete campos, id, pubkey, created_at,
kind, tags, content y sig. El id es un hash SHA-256 de una serialización fija de
los demás, y sig es una firma Schnorr sobre ese hash en secp256k1 según BIP-340, el
esquema que Bitcoin adoptó con Taproot. kind es un entero que dice qué es el evento: 0 es
metadatos de perfil, 1 una nota de texto plano, 5 un pedido de borrado, 10002 una lista de
relays.
Los relays y los clientes son estrictos con la firma y tontos con el contenido: un relay verifica el id y la firma, y después guarda una cadena de texto que nunca interpreta. Por eso aparecen aplicaciones de tipos nuevos sin que ningún operador de relay cambie nada.
Los relays
Un relay acepta eventos por WebSocket, guarda algunos, y devuelve los que coinciden con los filtros de un cliente. Ese es todo el trabajo, mucho menos de lo que hace un nodo de Bitcoin, y los relays no acuerdan nada entre sí.
No le deben nada a nadie. NIP-01 les da un vocabulario para rechazar un evento: blocked,
rate-limited, restricted, invalid. Algunos cobran por escribir. Publicar en varios
hace que uno que rechace o que cierre cueste esa copia y nada más: la identidad nunca
estuvo adentro. NIP-65 hace que los clientes publiquen esa lista de relays, y sugiere
mantenerla en 2 a 4 para leer y otros tantos para escribir.
Los relays son además el punto débil. El alcance depende de la superposición: quien no lea ninguno de los relays donde uno escribe nunca lo ve, y no hay índice global que lo arregle. Un relay también ve la dirección IP, qué claves se consultan y en qué momento hay conexión. Ser difícil de silenciar no es lo mismo que ser difícil de observar.
Los clientes son intercambiables
Un cliente es la aplicación: se conecta a los relays, verifica firmas y muestra eventos.
Como la identidad y los datos quedan afuera, cambiar de cliente no es una migración. Se apunta un cliente nuevo a la clave, lee los mismos relays, y ahí están las notas y los seguidos. Eso es el propósito del diseño y no una de sus prestaciones: la aplicación pasa a ser una preferencia, no un encierro.
Zaps, y nombres legibles
Dos cosas conectan Nostr con Bitcoin, y ninguna es una blockchain. Nostr no tiene cadena ni token.
Los zaps son pagos Lightning adjuntos a un evento, especificados en NIP-57. El cliente envía un pedido de zap firmado de kind 9734 al callback LNURL-pay del destinatario en lugar de a los relays, su billetera devuelve una factura, y una vez pagada su nodo publica un recibo de zap de kind 9735 que los clientes contabilizan. La especificación aclara su propio límite: "El recibo de zap no es una prueba de pago, lo único que prueba es que algún usuario de nostr pidió una factura."
NIP-05 convierte una clave en una dirección con forma de [email protected], que se
resuelve buscando un archivo JSON en ese dominio.
La especificación es explícita
en que identifica, no verifica. Un dominio responde por una clave, que no es lo mismo que
establecer quién la tiene.
Lo que Nostr no hace
No es anónimo, es seudónimo. La clave no es el nombre legal, pero los relays ven la dirección IP y los hábitos de lectura.
Las notas públicas no están cifradas. Una nota de kind 1 es texto plano que cualquiera puede leer. Los mensajes directos cifrados existen aparte, bajo NIP-17, que oculta a los participantes frente a los relays, y solo algunos clientes lo implementan.
El borrado es un pedido. NIP-09 define un evento de kind 5 que pide a los relays descartar algo. Muchos lo respetan, pero la especificación dice sin rodeos que "es imposible borrar eventos de todos los relays y clientes".
La moderación es local. Cada relay decide qué guarda y cada cliente qué muestra. Nadie puede eliminarlo a uno de todas partes, y nadie puede eliminar a otro de todas partes tampoco.
Adónde seguir
El paso siguiente es una clave propia y una aplicación que nunca la vea, que es lo que cubre cómo iniciar sesión en una aplicación de Nostr.