La página es la segunda sección de la columna sobre relays en la demo educativa de Nostr. Se explica que publicar puede fallar, y que NIP-01 define con precisión cómo: el relay responde con OK falso y un mensaje que empieza con un prefijo legible por máquina. Así, un cliente puede distinguir un reintento posible de un rechazo definitivo.
Cada rechazo dice por qué ocurre. Un cliente que lee el prefijo puede actuar con sensatez en lugar de mostrar una cadena de error.
El rechazo no es un fallo del sistema sino parte del diseño: relays simples con políticas claras y comunicadas de forma estandarizada.
Cualquiera de los relays puede rechazar un evento por razones no relacionadas con el evento mismo: política de contenido, límites de tamaño o requisitos de membresía. El que lo acepte es tan bueno como cualquier otro, y la redundancia garantiza que el evento circule aunque algunos relays digan que no.
La lección muestra que el rechazo en Nostr está especificado, no improvisado. Al definir prefijos de error legibles por máquina, el protocolo permite que los clientes distingan un retraso temporal de un rechazo definitivo y actúen en consecuencia. Los relays rechazan cosas de unas pocas formas concretas, y cada una de ellas dice por qué.
https://rookery-six.vercel.app/La página es la primera sección de la columna sobre relays en la demo educativa de Nostr. Se explica cómo funciona una suscripción: una petición con nombre que devuelve la historia coincidente, marca el final de esa historia y después se convierte en un canal de eventos nuevos en vivo.
Suscripción interactiva: el visitante construye una petición REQ con filtros (kinds y limit), la envía al relay y observa el tráfico resultante.
Visualización del ciclo completo: muestra las tres fases de una suscripción: la historia almacenada, el mensaje EOSE y los eventos nuevos a medida que aparecen.
Doble filtro: permite enviar dos filtros en el mismo REQ para demostrar que funcionan como alternativas, no como condiciones acumulativas.
Publicación para capturar eventos: se puede publicar un evento tras suscribirse y ver cómo llega por el canal en vivo, después del EOSE.
Dentro de un filtro, todas las condiciones deben cumplirse a la vez. Entre filtros distintos, basta con que se cumpla cualquiera.
Esta lógica es la base de todas las consultas en Nostr, y los clientes la usan para saber exactamente qué están pidiendo y qué están recibiendo.
Los clientes usan la frontera del EOSE para decidir cuándo dejar de mostrar el indicador de carga: antes de él se está recibiendo historia, después de él se está recibiendo noticias.
json
["REQ","explore",{"kinds":[1],"limit":10}]https://rookery-six.vercel.app/La página es la tercera sección sobre eventos en la demo educativa de Nostr. Se explica que en el protocolo no existe un campo de respuesta ni una estructura de hilos. Las respuestas, menciones y temas son simplemente etiquetas que apuntan a otras cosas, y son los clientes quienes reconstruyen las conversaciones a partir de ellas.
e para el evento al que se responde y una etiqueta p para notificar a su autor.e de ese identificador, obteniendo únicamente la respuesta, no la publicación sin etiquetas.Los relays no almacenan ninguna estructura de hilos. Las conversaciones las reconstruyen los clientes a partir de las etiquetas que apuntan a cosas.
Un evento no es una respuesta por su contenido, sino por las etiquetas que lleva. Esa diferencia es todo el sistema de hilos de Nostr.
Una respuesta es una nota ordinaria que lleva etiquetas concretas:
Estas convenciones son acuerdos entre clientes, no reglas del protocolo. El relay simplemente almacena el evento con sus etiquetas sin interpretarlas.
Las etiquetas de una sola letra están indexadas por los relays: se puede pedir todo lo que lleve una etiqueta e con un identificador concreto y obtener resultados. Las etiquetas con nombres más largos viajan dentro del evento, pero no se pueden usar para filtrar en las consultas.
La lección demuestra que la estructura social de Nostr, hilos, menciones y temas, no vive en los servidores sino en las etiquetas de los propios eventos. Al dejar que los clientes interpreten esas referencias y que los relays solo las indexen, el protocolo mantiene su simplicidad radical: las conversaciones son un conjunto de notas independientes que apuntan unas a otras.
https://rookery-six.vercel.app/La página es la segunda sección sobre eventos en la demo educativa de Nostr. Se explica que un relay no entiende el significado humano de los eventos: no sabe qué es un perfil o una nota. Ese significado es convención entre clientes. Lo que el relay sí conoce es la regla de almacenamiento, que depende exclusivamente del rango numérico del campo kind.
El significado de un evento es convención. La regla de almacenamiento es protocolo.
Un relay puede ser simple e intercambiable porque no necesita saber qué es un perfil: solo necesita saber que el kind 0 es reemplazable y conservar el más reciente por autor.
Regular (por ejemplo, kind 1, la nota): el relay guarda todas las copias. Publicar dos notas deja dos eventos almacenados.
Reemplazable (kinds 0 y 3, y el rango 10000 a 19999): el relay conserva solo el más reciente de cada autor. Tu perfil es un único evento que se sobrescribe al editarlo, no un historial. Lo mismo ocurre con tu lista de seguidos.
Addressable (rango 30000 a 39999, artículos largos): funcionan como reemplazables, pero por etiqueta d. El mismo identificador sobrescribe el artículo; un identificador distinto crea uno nuevo, de modo que un autor puede tener muchos artículos conviviendo.
Ephemeral (rango 20000 a 29999): el relay los entrega a quien esté escuchando en ese momento y no guarda ninguno. Son útiles para señales en tiempo real como chat o presencia, pero imposibles de recuperar después.
La lección muestra cómo Nostr consigue relays extremadamente simples sin sacrificar riqueza de funcionalidades. Al repartir los números de tipo en rangos con reglas de almacenamiento bien definidas, el protocolo se queda con la parte mecánica, mantener una copia, solo la última o ninguna, y deja el significado de cada evento a los clientes. El rango del kind decide si el relay guarda todas las copias, una sola o ninguna.
https://rookery-six.vercel.app/La página es la primera sección práctica sobre la estructura de datos de Nostr. Se explica que no existen tipos de datos diferentes para posts, perfiles o mensajes.
Todo es un único objeto JSON con siete campos, y la diferencia entre una nota y un perfil radica únicamente en el valor del campo kind y en lo que se coloca en tags y content.
id y sig) aparecen señalados como derivados: no se eligen, se calculan a partir de los demás.id calculado.Nostr tiene una sola estructura de datos. El contexto de cada evento lo da el número del campo
kind, no una tabla o esquema separado.
Esta uniformidad permite que cualquier cliente o relay procese cualquier evento sin conocimientos previos: basta con leer el número de tipo y validar que el id coincida con el hash del contenido.
id, hecha con la clave secreta.El id es el SHA-256 de exactamente este array, sin espacios y en orden fijo: el cero inicial, la clave pública, el timestamp, el kind, los tags y el content. Cualquier modificación mínima en uno de esos valores produce un identificador completamente distinto.
La lección establece la base arquitectónica de Nostr: una simplicidad radical donde todo es el mismo objeto. Al derivar el identificador y la firma directamente del contenido, el protocolo elimina la necesidad de autoridades centrales que certifiquen la autenticidad de los eventos. La verificación es matemática y está al alcance de cualquiera.
https://rookery-six.vercel.app/La página es la septima sección de la demo educativa sobre Nostr. Aquí se explica dónde reside físicamente la clave privada cuando usas diferentes tipos de aplicaciones, y cómo el protocolo NIP-46 permite que una app firme eventos sin nunca ver tu clave.
sign_event:1), lo que le permite firmar solo notas de texto y rechazar otras operaciones como cambios de perfil.Una aplicación puede obtener una firma válida de un firmante remoto sin nunca acceder a la clave privada del usuario.
Esto invierte el modelo de seguridad tradicional: en lugar de confiar en que la app no robe la clave, el sistema garantiza criptográficamente que la app no puede acceder a ella, limitando el daño potencial incluso si el cliente es malicioso.
La clave vive en el JavaScript del navegador. Cualquier script de terceros (analítica, publicidad, dependencias comprometidas) puede leerla. Es el modelo más inseguro.
La clave reside en el almacenamiento aislado de la extensión. La página web pide firmas a la extensión, que actúa como intermediaria. Es más seguro que la web, pero la clave sigue en el mismo dispositivo y navegador.
La clave está en otro dispositivo o aplicación (como Amber en Android o un bunker remoto). La app web se comunica mediante eventos cifrados a través de relays. La clave nunca toca el navegador.
El protocolo utiliza tres pares de claves distintos:
Solo la tercera es tu identidad permanente. Las otras dos son canales de comunicación temporales.
El firmante se inicia con permisos específicos como sign_event:1. Esto significa:
La aplicación no puede portarse mal porque el firmante no le concede la capacidad técnica, eliminando la necesidad de confiar en la buena voluntad del desarrollador.
La lección demuestra que la custodia de claves no es binaria (tenerla o no tenerla), sino un espectro de riesgo. Al separar la identidad (tu clave) de la capacidad de firma (mediante firmantes remotos con permisos limitados), Nostr permite usar aplicaciones web con la seguridad de que, incluso si son maliciosas, el daño está limitado y la clave permanece a salvo fuera de su alcance.
https://rookery-six.vercel.app/