La página es el índice de la primera columna de la demo educativa de Nostr: la que agrupa las lecciones fundamentales para empezar en el protocolo. Recorre el ciclo completo de tener una identidad y usarla con seguridad, desde la generación de claves hasta la custodia responsable del secreto.
La identidad en Nostr no la otorga una plataforma, la genera uno mismo con criptografía.
Eso trae dos consecuencias: nadie puede suplantar una identidad porque cada evento está firmado, pero nadie puede recuperarla si la clave se pierde o se filtra, porque no hay servidor al que reclamar.
La columna de inicio establece el fundamento conceptual de todo lo que viene después: en Nostr la cuenta no se crea en un servicio sino que se genera localmente, la identidad real es la clave pública y no el nombre visible, y la permanencia y seguridad de la cuenta dependen por completo de la custodia de la clave privada. Las lecciones siguientes, sobre eventos y relays, se apoyan en esta base para explicar cómo circula la información una vez que existe una identidad.
https://rookery-six.vercel.app/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/