https://www.zonaautonoma.org/bludit/ Congratulations you have successfully installed your Bludit. Tue, 22 Sep 2026 22:22:32 -0400 https://www.zonaautonoma.org/bludit/la-pagina-que-te-ense%C3%B1a-como-funciona-nostr-demo-e-inicio-rapido <h1>Getting started: la columna de inicio de la demo</h1> <p>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.</p> <h2>Funcionalidades principales</h2> <ul> <li><strong>Listado de lecciones:</strong> presenta las cinco secciones de la columna, cada una con su propia página interactiva dentro de la demo.</li> <li><strong>Progresión lógica:</strong> las lecciones se ordenan del concepto de identidad al riesgo de exponerla, construyendo una base antes de pasar a temas técnicos como eventos y relays.</li> <li><strong>Títulos descriptivos:</strong> cada entrada comunica su idea central de por sí, de modo que el índice funciona también como mapa de la columna.</li> </ul> <h2>Idea central</h2> <blockquote> <p>La identidad en Nostr no la otorga una plataforma, la genera uno mismo con criptografía.</p> </blockquote> <p>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.</p> <h2>Las lecciones de la columna</h2> <ol> <li><strong>You already have an account:</strong> no existe registro. La cuenta son las claves criptográficas, que pueden existir sin pedir permiso a nadie.</li> <li><strong>Your handle and your key:</strong> distingue el nombre visible, que puede cambiar, de la clave pública, que es la identidad real e inmutable.</li> <li><strong>Nobody can post as you:</strong> sin la clave privada nadie puede suplantar la identidad, porque cada evento lleva una firma matemática.</li> <li><strong>The box you should never fill in:</strong> nunca pegar el nsec en una página web. Una vez filtrado es irrecuperable: no hay reset ni soporte a quien acudir.</li> <li><strong>An account that lasts:</strong> la cuenta perdura porque no depende de ningún servidor. Quien tenga la clave tiene la identidad, dondequiera que la use.</li> </ol> <p>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.</p> <ul> <li>Aqui esta el link de la fuente: <code>https://rookery-six.vercel.app/</code></li> </ul> Tue, 22 Sep 2026 22:19:32 -0400 4c49de3df39a50a7847311aa6d98f9ec https://www.zonaautonoma.org/bludit/la-pagina-que-te-ense%C3%B1a-como-funciona-nostr-parte-i/la-pagina-que-te-ense%C3%B1a-como-funciona-nostr-parte-ix <h1>Cuando un relay dice no: los rechazos especificados en NIP-01</h1> <p>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 <strong>prefijo legible por máquina</strong>. Así, un cliente puede distinguir un reintento posible de un rechazo definitivo.</p> <h2>Funcionalidades principales</h2> <ul> <li><strong>Rechazos provocables:</strong> el visitante puede disparar cada tipo de rechazo a propósito, algo que ningún relay público permitiría, y observar tanto el evento como la respuesta del relay.</li> <li><strong>Cinco motivos de rechazo:</strong> autenticación requerida, límite de velocidad, política de contenido, límite de tamaño y prueba de trabajo exigida.</li> <li><strong>Restablecimiento del relay:</strong> controles para volver a aceptar todo y limpiar el estado del relay local entre experimentos.</li> <li><strong>Lectura del prefijo:</strong> la demo enfatiza que la parte útil de la respuesta es el prefijo inicial, que indica al cliente qué hacer a continuación.</li> </ul> <h2>Idea central</h2> <blockquote> <p>Cada rechazo dice por qué ocurre. Un cliente que lee el prefijo puede actuar con sensatez en lugar de mostrar una cadena de error.</p> </blockquote> <p>El rechazo no es un fallo del sistema sino parte del diseño: relays simples con políticas claras y comunicadas de forma estandarizada.</p> <h2>Las cinco formas de rechazo</h2> <ol> <li><strong>auth-required:</strong> el relay solo acepta eventos de miembros. Un cliente real responde con un intercambio NIP-42 demostrando que controla la clave y reintenta.</li> <li><strong>rate-limited:</strong> el evento llegó demasiado rápido y no se almacenó. Un cliente bien comportado reduce la velocidad en lugar de insistir.</li> <li><strong>restricted:</strong> el relay rechaza ese tipo de evento. Un relay de artículos largos podría aceptar solo el kind 30023. Es política, no protocolo.</li> <li><strong>invalid:</strong> el evento no pasa las reglas del relay, como un límite de tamaño. En la demo el límite es de treinta y dos caracteres.</li> <li><strong>pow:</strong> el relay exige prueba de trabajo según NIP-13: un identificador de evento que empiece por cierto número de ceros, lo que cuesta cómputo real. Es caro para un spammer y apenas perceptible para una nota.</li> </ol> <h2>Qué significa cada prefijo para el cliente</h2> <ul> <li><strong>rate-limited:</strong> esperar y reintentar más tarde.</li> <li><strong>auth-required:</strong> autenticar y reintentar.</li> <li><strong>restricted:</strong> y <strong>blocked:</strong> publicar en otro lugar.</li> </ul> <h2>Por qué se publica en varios relays</h2> <p>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.</p> <p>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é.</p> <ul> <li>Aqui esta el link de la fuente: <code>https://rookery-six.vercel.app/</code></li> </ul> Tue, 22 Sep 2026 21:20:19 -0400 05f760c6c237999beffd891e672a9eee https://www.zonaautonoma.org/bludit/la-pagina-que-te-ense%C3%B1a-como-funciona-nostr-parte-i/pedir-cosas-a-un-relay-suscripciones-y-filtrosla-p%C3%A1gina-e <h1>Pedir cosas a un relay: suscripciones y filtros</h1> <p>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 <strong>suscripción</strong>: 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.</p> <h2>Funcionalidades principales</h2> <ul> <li> <p><strong>Suscripción interactiva:</strong> el visitante construye una petición REQ con filtros (kinds y limit), la envía al relay y observa el tráfico resultante.</p> </li> <li> <p><strong>Visualización del ciclo completo:</strong> muestra las tres fases de una suscripción: la historia almacenada, el mensaje EOSE y los eventos nuevos a medida que aparecen.</p> </li> <li> <p><strong>Doble filtro:</strong> permite enviar dos filtros en el mismo REQ para demostrar que funcionan como alternativas, no como condiciones acumulativas.</p> </li> <li> <p><strong>Publicación para capturar eventos:</strong> se puede publicar un evento tras suscribirse y ver cómo llega por el canal en vivo, después del EOSE.</p> </li> </ul> <h2>Idea central</h2> <blockquote> <p>Dentro de un filtro, todas las condiciones deben cumplirse a la vez. Entre filtros distintos, basta con que se cumpla cualquiera.</p> </blockquote> <p>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.</p> <h2>El ciclo de una suscripción</h2> <ol> <li><strong>REQ:</strong> se envía la petición con un identificador elegido por el cliente y uno o más filtros.</li> <li><strong>Historia:</strong> el relay envía todo lo coincidente que ya tiene almacenado.</li> <li><strong>EOSE:</strong> llega el mensaje de fin de eventos guardados, que marca la frontera entre historia y actualidad.</li> <li><strong>Noticias:</strong> a partir de ese momento el relay sigue enviando solo los eventos nuevos que vayan llegando.</li> </ol> <p>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.</p> <h2>Estructura de la petición de la demo</h2> <pre><code>json ["REQ","explore",{"kinds":[1],"limit":10}]</code></pre> <ul> <li>Aqui esta el link de la fuente: <code>https://rookery-six.vercel.app/</code></li> </ul> Tue, 22 Sep 2026 21:10:32 -0400 1537c7e1c4fdb1fe784b52a0945affc3 https://www.zonaautonoma.org/bludit/la-pagina-que-te-ense%C3%B1a-como-funciona-nostr-parte-i/la-pagina-que-te-ense%C3%B1a-como-funciona-nostr-parte-vii <h1>Etiquetas en Nostr: las etiquetas crean la estructura</h1> <p>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 <strong>etiquetas</strong> que apuntan a otras cosas, y son los clientes quienes reconstruyen las conversaciones a partir de ellas.</p> <h2>Funcionalidades principales</h2> <ul> <li><strong>Experimento de doble publicación:</strong> el visitante publica el mismo texto dos veces, una con etiquetas y otra sin ellas. Los dos eventos son idénticos salvo por las etiquetas, y solo uno es una respuesta.</li> <li><strong>Visualización de las etiquetas:</strong> muestra las etiquetas que llevará la respuesta antes de publicarla: una etiqueta <code>e</code> para el evento al que se responde y una etiqueta <code>p</code> para notificar a su autor.</li> <li><strong>Consulta indexada:</strong> permite pedir al relay todo lo etiquetado con la etiqueta <code>e</code> de ese identificador, obteniendo únicamente la respuesta, no la publicación sin etiquetas.</li> <li><strong>Glosario de etiquetas:</strong> presenta las etiquetas de una sola letra que aparecerán en el día a día de Nostr.</li> </ul> <h2>Idea central</h2> <blockquote> <p>Los relays no almacenan ninguna estructura de hilos. Las conversaciones las reconstruyen los clientes a partir de las etiquetas que apuntan a cosas.</p> </blockquote> <p>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.</p> <h2>Cómo funciona una respuesta</h2> <p>Una respuesta es una nota ordinaria que lleva etiquetas concretas:</p> <ul> <li><strong>Etiqueta e:</strong> nombra el identificador del evento al que se responde.</li> <li><strong>Etiqueta p:</strong> nombra a la clave pública del autor de ese evento, de modo que su cliente pueda notificarle.</li> </ul> <p>Estas convenciones son acuerdos entre clientes, no reglas del protocolo. El relay simplemente almacena el evento con sus etiquetas sin interpretarlas.</p> <h2>Etiquetas indexadas frente a etiquetas portadas</h2> <p>Las etiquetas de una sola letra están <strong>indexadas</strong> por los relays: se puede pedir todo lo que lleve una etiqueta <code>e</code> con un identificador concreto y obtener resultados. Las etiquetas con nombres más largos viajan dentro del evento, pero <strong>no se pueden usar para filtrar</strong> en las consultas.</p> <h2>Las etiquetas que encontrarás</h2> <ul> <li><strong>e:</strong> un evento. Se usa en respuestas, citas y reacciones.</li> <li><strong>p:</strong> una persona. Se usa en menciones y notificaciones.</li> <li><strong>t:</strong> un tema. Es el hashtag.</li> <li><strong>d:</strong> un identificador. Determina qué evento addressable es este.</li> <li><strong>a:</strong> un evento addressable, referenciado por kind, clave pública e identificador.</li> </ul> <p>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.</p> <ul> <li>Aqui esta el link de la fuente: <code>https://rookery-six.vercel.app/</code></li> </ul> Tue, 22 Sep 2026 20:59:16 -0400 b7064c5007d57779357305bb7ffee9f7 https://www.zonaautonoma.org/bludit/la-pagina-que-te-ense%C3%B1a-como-funciona-nostr-parte-i/la-pagina-que-te-ense%C3%B1a-como-funciona-nostr-parte-vi <h1>Tipos de eventos en Nostr: el número decide las reglas</h1> <p>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 <strong>convención entre clientes</strong>. Lo que el relay sí conoce es la <strong>regla de almacenamiento</strong>, que depende exclusivamente del rango numérico del campo <code>kind</code>.</p> <h2>Funcionalidades principales</h2> <ul> <li><strong>Demostración interactiva:</strong> el visitante publica eventos de distintos tipos dos veces seguidas y observa el contador del relay, comprobando en la práctica cómo se comporta cada rango.</li> <li><strong>Cuatro comportamientos visibles:</strong> notas regulares que se acumulan, perfiles que se sobrescriben, artículos que conviven por etiqueta y eventos efímeros que nunca se guardan.</li> <li><strong>Panel de rangos:</strong> muestra la tabla completa de rangos numéricos y la regla de almacenamiento asociada a cada uno.</li> <li><strong>Verificación en vivo:</strong> un monitor permite ver llegar los eventos efímeros en tiempo real, aunque el relay no los retenga.</li> </ul> <h2>Idea central</h2> <blockquote> <p>El significado de un evento es convención. La regla de almacenamiento es protocolo.</p> </blockquote> <p>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.</p> <h2>Los cuatro comportamientos del relay</h2> <ol> <li> <p><strong>Regular (por ejemplo, kind 1, la nota):</strong> el relay guarda todas las copias. Publicar dos notas deja dos eventos almacenados.</p> </li> <li> <p><strong>Reemplazable (kinds 0 y 3, y el rango 10000 a 19999):</strong> 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.</p> </li> <li> <p><strong>Addressable (rango 30000 a 39999, artículos largos):</strong> funcionan como reemplazables, pero por etiqueta <code>d</code>. El mismo identificador sobrescribe el artículo; un identificador distinto crea uno nuevo, de modo que un autor puede tener muchos artículos conviviendo.</p> </li> <li> <p><strong>Ephemeral (rango 20000 a 29999):</strong> 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.</p> </li> </ol> <p>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.</p> <ul> <li>Aqui esta el link de la fuente: <code>https://rookery-six.vercel.app/</code></li> </ul> Tue, 22 Sep 2026 20:36:06 -0400 6d6603c65344fb24065c4c8ae7fca547