Nostr Compass #37

Bienvenidos de nuevo a Nostr Compass, vuestra guía semanal de Nostr.

Esta semana: Shopstr mantiene los secretos del firmante remoto y de la cartera fuera del almacenamiento del navegador, Routstr SDK verifica el descubrimiento de proveedores procedente de relays, Postr se lanza como un compositor pequeño para Android, Infans cifra el seguimiento familiar y la sincronización entre progenitores, walls.rip transporta chat cifrado con PGP por relays públicos de Nostr, y pakstr hace explícita la publicación en Zapstore. nostr-tools vincula los rumors de gift wrap con sus seals. Las versiones cubren el aislamiento de suscripciones, los estados de perfil y los marcadores de salida por relay. El trabajo de protocolo alcanza el despliegue de hilos de comentarios, borradores de límite de comisión y consulta de pagos en wallet connect, solicitudes de pantalla para napplets, y una inscripción experimental desde la misma cuenta. El número cierra con Seis agostos en la historia de Nostr.

Historias Principales

Postr se lanza como un compositor pequeño para Android

Postr es un compositor deliberadamente pequeño para notas kind 1 en Android. La custodia de la clave privada permanece en Amber, un firmante NIP-55 (firmante local) y NIP-46 para Android. La versión 1.0.0 incorpora una bandeja de salida duradera que sobrevive a la pérdida de conectividad y a la muerte del proceso, borradores privados por cuenta, y adjuntos Blossom con hashes verificados y autorización de subida acotada.

Una publicación tiene éxito después de que Postr relea el evento firmado idéntico y compruebe su firma. Los reintentos conservan el mismo id de evento. La publicación usa los relays de escritura de la lista NIP-65 (lista de relays) del autor más relays de arranque cifrados, o una lista personalizada por cuenta. Un anuncio de repositorio NIP-34 (git sobre Nostr) firmado y un perfil de proyecto kind 0 correspondiente se publican en relay.ngit.dev. Los feeds, la analítica, la publicidad y el almacenamiento de claves quedan fuera de la aplicación.

Infans cifra el seguimiento familiar y la sincronización entre progenitores sobre Nostr

Los progenitores pueden mantener los registros de alimentación, sueño y crecimiento en sus propios teléfonos y compartirlos sin un proveedor de datos familiares. Infans es un rastreador de bebés para Android que trata una base de datos Room local como fuente de verdad y publica eventos cifrados kind 30078 de NIP-78 (datos específicos de aplicación) para copia de seguridad y sincronización con la pareja. Su repositorio etiqueta el cifrado local como NIP-44 (cifrado de payload), pero la implementación usa AES-256-GCM mientras NIP-44 v2 exige ChaCha20 con HMAC-SHA256, así que los payloads en modo local no deberían presentarse como compatibles con NIP-44.

La sincronización con la pareja usa el d-tag baby-tracker-sync, mientras las copias propias usan baby-tracker-backup. Las notas asíncronas viajan dentro del payload de la pareja. La ruta documentada de Amber NIP-55 (firmante local) delega la firma y el cifrado en el firmante, pero el repositorio no aporta ninguna prueba de interoperabilidad que muestre que cada ruta de copia y de sincronización produce texto cifrado NIP-44 v2. El repositorio no presenta ninguna declaración de producto sanitario ni ninguna auditoría de seguridad externa.

El Ghost Chat de walls.rip lleva el chat cifrado con PGP a relays públicos de Nostr

walls.rip es un conjunto de herramientas de comunicación anónima cuyo modo Ghost Chat crea o importa una identidad OpenPGP en el navegador. Su cliente de código abierto cifra cada mensaje con la clave pública PGP del destinatario. La conversación legible permanece en el almacenamiento de sesión local del dispositivo; la aplicación no tiene cuenta de chat ni base de datos central de mensajes.

El transporte es Nostr real, pero es deliberadamente específico de la aplicación. Ghost Chat publica texto cifrado en formato armored como eventos kind 1 hacia cinco relays predeterminados y etiqueta cada evento con un tag de sala estable derivado de la huella PGP del destinatario. Eso ofrece a los desarrolladores un ejemplo concreto de uso de relays como transporte de mensajes resistente a la censura, y también muestra por qué la entrega descentralizada por sí sola no protege los metadatos ni es interoperable con los mensajes directos NIP-17.

pakstr 0.13.0 a 0.15.0 hace explícita la publicación en Zapstore

Tras el trabajo de empaquetado y Amber de 0.3.1 en julio, pakstr es una CLI que convierte una carpeta de recursos web en un APK de Android firmado y lo publica en Zapstore con una clave Nostr. 0.13.0 añade versionado automático de releases. Las versiones 0.13.1 a 0.13.3 reparan la publicación en Blossom: la autorización ahora usa base64url, las subidas llevan un Content-Digest, y el evento de aplicación de Zapstore se publica antes de la subida a Blossom.

0.14.0 valida al publicador de Zapstore antes de que la publicación continúe. 0.15.0 escribe los metadatos de la ficha en eventos de aplicación kind 32267 y coloca las notas de la versión en el content de los eventos de release kind 30063, de modo que el registro de Zapstore de una app empaquetada puede llevar nombre, resumen y notas sin un paso manual de ficha aparte.

Heterodyne especifica personas portables y comunicación social cifrada

Heterodyne es una familia de protocolos orientada a especificación para personas portables, comunicación autenticada, control sobre el propio dispositivo e interacción social. Su README actual compone cuatro capas existentes: eventos Nostr firmados, Radicle (git entre pares) como almacenamiento duradero, Marmot (mensajería de grupo MLS sobre Nostr) para conversaciones cifradas directas y de grupo, y registros de eventos de clave KERI (Key Event Receipt Infrastructure) para la rotación de identidad. Una persona se describe como un npub Nostr de raíz en frío más un registro KERI aceptado; la firma rutinaria usa claves de época rotatorias, mientras las identidades de nodo Radicle se delegan con doble prueba.

La familia divide ese trabajo en cuatro borradores 0.x versionados de forma independiente. Core posee la identidad, la verificación de registros de eventos de clave, los bytes canónicos de Nostr y el sustrato de repositorio Radicle; Comms posee los sobres nativos de Nostr, los niveles de privacidad, la publicación y las conversaciones Marmot; y Social posee el seguimiento público, las interacciones y las listas. Control, para la inscripción y los permisos del propio dispositivo, está incompleto y no puede reclamarse. Estos documentos siguen siendo borradores que pueden romperse antes de 1.0, y este número presenta la familia antes de que haya llegado ningún lanzamiento de cliente Heterodyne.

Versiones

Nostr Java v2.0.8: aislamiento de suscripciones y NIP-44 portable

Una consulta de gift wrap contra un relay con cinco eventos devolvía cero, dos o seis eventos al azar, porque Nostr Java, una biblioteca Java para hablar con relays y cifrar payloads de Nostr, entregaba cada frame entrante a todos los listeners de la conexión. La versión 2.0.8 enruta EVENT, EOSE y CLOSED a la suscripción que esos frames nombran, así que la señal de fin de eventos almacenados de una consulta ya no puede cerrar otra. Los frames de ámbito de conexión como NOTICE, OK y AUTH siguen llegando a todos los listeners.

NIP-44 (cifrado de payload) en la misma versión ya no necesita un proveedor JCE registrado en el proceso. El cifrado solo funcionaba después de generar una clave en esa JVM, lo que registraba BouncyCastle como efecto secundario, y fallaba en Android, donde añadir un proveedor llamado “BC” no hace nada. Ambas rutas de cifrado usan ahora el motor ligero ChaCha20 de BouncyCastle, y la generación de claves ya no altera el estado JCE de todo el proceso. Quienes dependían de la biblioteca para registrar el proveedor deben registrarlo por su cuenta. La dependencia de NIP-44 respecto al proveedor JCE es el issue que esto cierra.

NoorNote v1.3.6: estados de perfil y anuncios clasificados

NoorNote es un cliente Nostr para escritorio, web y Android. Una semana después de que 1.3.4 añadiera incorporaciones cifradas a comunidades, la versión 1.3.6 muestra NIP-38 (estados de usuario) bajo el nombre NIP-05 (verificado por dominio) de un perfil: los eventos direccionables kind 30315, con expiración opcional, que llevan un estado general o musical de una línea. Al hacer clic en esa línea se establece el estado propio de quien mira.

Los anuncios clasificados de NIP-99 (ofertas de mercado kind 30402) se renderizan ahora en toda la aplicación, así que el complemento de mercado solo hace falta para comprar y vender. Las notas privadas de apodo en los perfiles también aparecen en naranja de advertencia, con un icono de nota rellenado y un anillo naranja en el avatar.

nostrord v2.9.0: estado de grupo y medios por relay

Salir de un grupo NIP-29 (grupos gestionados por relay) en un servidor suprimía antes el mismo id de grupo en todos los demás relays, porque nostrord, un cliente multiplataforma para comunidades alojadas en relays, indexaba sus marcadores de salida y borrado por el id desnudo. Los marcadores de salida y borrado acotados por relay mantienen esas supresiones en el servidor que las produjo, así que un grupo que comparte un id entre dos relays ya no se abandona ni se descarta en pareja. Una incorporación que el relay rechaza por ser ya miembro cuenta ahora como éxito y limpia el marcador local, que había sido un estado absorbente: la autorreparación limpiaba una ranura mientras el arranque en frío restauraba la otra.

La versión 2.9.0 también renderiza imágenes incrustadas en markdown que otros clientes escriben como ![alt](url), en lugar de mostrar la puntuación markdown alrededor de una URL ya detectada. Los mensajes directos incorporan NIP-17 (DM privados con gift wrap) y rumors de archivo kind 15, así que un adjunto cifrado enviado desde Jumble se descarga, se descifra y se muestra, y los adjuntos salientes se cifran antes de subirse. Esta etiqueta incluye ya el trabajo de clave de cifrado NIP-4e cubierto la semana pasada. La propuesta sigue sin fusionarse, y nostrord dice que su implementación sigue el comportamiento desplegado de Jumble donde ese comportamiento difiere del borrador.

Cambios no publicados

Shopstr mantiene los secretos del firmante remoto y de la cartera fuera del almacenamiento del navegador

Shopstr es un mercado web para anuncios clasificados NIP-99. Tras el trabajo de integridad de pagos del mes pasado, deja de escribir en localStorage los secretos serializados del firmante bunker. Un payload de bunker NIP-46 (firma remota) había incluido la URL bunker:// activa y la clave privada de aplicación generada, así que cualquier script en el origen de Shopstr podía reanudar la sesión de firma remota. Los datos del bunker permanecen ahora en memoria durante la sesión actual, los payloads de bunker residuales se eliminan cuando se encuentran, y los tipos de firmante que no son bunker mantienen su comportamiento de almacenamiento anterior.

El cambio de NWC correspondiente hace lo mismo con las credenciales NIP-47 (wallet connect). Shopstr había guardado la cadena nostr+walletconnect:// completa, incluido el secreto usado para las acciones de cartera, como datos ordinarios del navegador y la reutilizaba al pagar. Las cadenas de conexión y los metadatos de cartera permanecen ahora en memoria, y las copias almacenadas antiguas se borran al leer los datos locales. Los scripts que ya se ejecutan en el origen de Shopstr durante una sesión activa siguen pudiendo ver esos valores en memoria.

Routstr verifica el descubrimiento de proveedores procedente de relays

Un único relay malicioso podía decidir antes en qué proveedores de inferencia confiaba un cliente Routstr. Routstr SDK es la biblioteca TypeScript detrás de Routstr, un mercado que descubre proveedores de IA en Nostr y les paga con Cashu. La corrección de descubrimiento de esta semana verifica cada anuncio de proveedor, lista de modelos y reseña entregados por relays (kinds 38421, 38423 y 38425) antes de que cualquier consumidor los vea, así que una reseña que nombra un pubkey de confianza pero lleva una firma basura ya no entra en el ranking.

Las marcas de tiempo muy futuras se descartan antes de seleccionar la “reseña más reciente”. Los eventos con más de quince minutos de adelanto respecto al reloj local se eliminan en la ruta en vivo y al leer el almacén persistente, lo que evita que un created_at falsificado supere a reseñas firmadas válidamente entre reinicios. Si no hay reseñas de confianza disponibles, la puerta de reseñas falla en cerrado y excluye a los proveedores sin reseña del ranking de pagos hasta que lleguen reseñas. Los operadores todavía pueden habilitar un proveedor a mano.

nostr-tools vincula los rumors de gift wrap con sus seals

Desenvolver un evento NIP-59 (gift wrap) descifraba antes el wrap, descifraba el seal y devolvía el rumor interior sin comprobar de quién venía el seal. nostr-tools es una biblioteca JavaScript de utilidades del protocolo Nostr. La corrección de desenvoltura de esta semana exige que el wrap sea kind 1059, que el seal sea kind 13 con firma válida, y que el pubkey del rumor sea igual al pubkey del seal. Descifrar el seal ya prueba el control de seal.pubkey. Sin esa última comprobación, cualquiera podría sellar un rumor que nombrara a otra persona como autora y hacer que un cliente atribuyera el mensaje a esa víctima.

NIP-17 (DM privados con gift wrap) usa la misma ruta de desenvoltura, así que el vínculo se aplica a los DM privados. El desenvuelto por lotes omite ahora un wrap que falle esas comprobaciones en lugar de lanzar una excepción, porque los gift wraps no se solicitan y un solo evento hostil descartaría el resto de una consulta al relay.

Haven añade administración de relay firmada y un navegador local de notas

Haven es un relay Nostr autoalojado y un servidor de medios Blossom. Su consola de administración recién fusionada expone llamadas de gestión NIP-86 en cada endpoint del relay, con cada petición autenticada por un evento NIP-98 del propietario configurado. Los operadores pueden gestionar bloqueos, listas de permitidos, reglas de kind, nombres de relay y medios almacenados sin dar al relay una clave de firma. Un navegador de notas de solo lectura mantiene opacos los kinds cifrados y carga medios remotos solo después de un clic, evitando una petición automática que revelaría la dirección IP del operador a un servidor externo.

El mismo cambio en Haven añade gráficas de tráfico persistentes y corrige un fallo con LMDB por defecto en el que contar eventos almacenados podía entrar en bucle indefinido, fijar un núcleo de CPU y bloquear llamadas posteriores de estadísticas. Haven usa ahora el contador del backend donde este termina y un recorrido acotado de eventos en el resto de los casos. El proyecto añadió sus primeras 23 pruebas sobre paginación de eventos, borrado, persistencia de métricas, comprobaciones de propietario y firmas de peticiones ligadas a la URL.

Amethyst saca la autorización de Blossom de los hilos de carga de imágenes

Amethyst, un cliente Nostr para Android, deja de esperar la autorización de lectura de Blossom en los hilos del dispatcher de OkHttp. El interceptor inicia ahora la firma fuera del hilo de red, mientras el cargador de imágenes espera una firma compartida por servidor y reintenta la petición del blob protegido. Una ráfaga de imágenes con puerta ya no ocupa por tanto todas las ranuras de conexión por servidor mientras un firmante responde.

El mismo parche de Amethyst alinea la codificación del token con BUD-11: Base64url sin relleno, ámbito server, y sin tag x específico de blob, permitiendo que un token cubra varios blobs en el mismo servidor. Nuevas pruebas de concurrencia ejercitan el cacheado, la expiración, los reintentos firmados y dieciséis llamantes simultáneos compartiendo una firma.

Actualizaciones de NIPs y trabajo de especificación del protocolo

NIPs

Snort y Ditto usan ahora NIP-22 (hilos de comentarios) para las respuestas de texto ordinarias, convergiendo en kind 1111 mientras conservan rutas de compatibilidad; esto no establece un kind de respuesta único para todo el protocolo. Después de que la modificación de junio eliminara la prohibición de usar NIP-22 contra notas kind 1, una adición fusionada a NIP-30 (emoji personalizados) lista kind 1111 entre los eventos que pueden llevar tags emoji, con un shortcode en content resuelto por ese tag. Snort, un cliente Nostr web, escribe ahora cada respuesta como kind 1111, carga esos comentarios mediante tags de ámbito raíz E/A en mayúsculas, y todavía acepta una ruta opcional NIP-10 (tags de respuesta kind 1) para las notas antiguas. Ditto, un servidor Mastodon y relay Nostr combinados, publica cada respuesta como un comentario NIP-22, kind 1111 para texto y kind 1244 para voz, mientras sigue renderizando las respuestas kind 1 existentes. Los clientes que solo entienden NIP-10 no verán la nueva forma. Las publicaciones de nivel superior siguen siendo kind 1.

Una petición pay_invoice de NIP-47 (Nostr Wallet Connect) no tiene actualmente una manera estándar de que el cliente especifique un techo de comisión de enrutamiento. Una propuesta abierta de techo de comisión añade un parámetro opcional max_fee, en milisatoshis, a pay_invoice. Las carteras que respeten el presupuesto NO DEBEN enviar un pago cuyo coste de enrutamiento supere amount + max_fee y DEBEN devolver FEE_LIMIT_EXCEEDED, definido como ningún cargo y ningún pago intentado. Las implementaciones que lo soporten DEBEN incluir fees_paid en la respuesta para que el cliente pueda conciliar. Las implementaciones sin soporte de límite de comisión ignoran el parámetro desconocido, y los clientes deberían tratar la ausencia del campo fees_paid como señal de que el tope puede no haberse aplicado. El cambio no añade kinds de evento y sigue siendo una propuesta hasta que se fusione.

Una propuesta abierta de etiquetas de idioma en NIP-32 estandarizaría ["l", "<BCP-47>", "lang"] para el idioma del texto declarado por el autor. Como el tag l de una sola letra ya es indexable por los relays, los clientes podrían pedir un feed en japonés con {"#l":["ja"]} sin actualizar el relay ni recurrir a una detección de idioma poco fiable tras la descarga. El borrador también migra los ejemplos de idioma en los informes de relay de NIP-66, los metadatos de imagen de NIP-68 y las pistas de audio de NIP-71 al mismo espacio de nombres. Las etiquetas siguen siendo afirmaciones del autor sin verificar, y el cambio no está fusionado.

Nostr Wallet Connect

Tras un tiempo de espera agotado, una reconexión o una notificación perdida, un cliente de wallet connect necesita una manera de pedir un único registro de pago sin saber qué protocolo de pago de Bitcoin lo creó. Un borrador abierto de consulta de pagos en el repositorio de extensiones de NWC define el opcional NWC-09 lookup_payment junto al núcleo de NIP-47. La petición usa exactamente un selector: un transaction_id estable acotado a la cartera, los campos payment_hash y/o invoice compatibles con BOLT11 que ya usa lookup_invoice, o un payment_type más un objeto lookup tipado definido por otra extensión. Un resultado exitoso devuelve un sobre común (transaction_id, type, state, payment_type, amount en msats, marcas de tiempo, fees_paid y metadata opcionales, y un objeto details discriminado) y DEBE resolverse a exactamente un registro visible para esa conexión. La cartera NO DEBE revelar si existe un registro inaccesible, y un selector que coincida con varios registros visibles devuelve MULTIPLE_MATCHES. Los estados son pending, accepted, settled, failed, expired y canceled. La misma propuesta añade detalles de oferta y pago BOLT12 en NWC-12 que reutilizan ese sobre. Ambos documentos siguen siendo borradores.

NAPs

Un borrador abierto de NAP-DISPLAY permitiría a un napplet pedir a su anfitrión las pantallas de píxeles que tiene permitido usar. Se apoya en la propuesta de web applets NIP-5D, sin fusionar y tramitada por separado, que presentó el Newsletter #17 y que sigue fuera del conjunto de NIPs fusionados. El borrador define display.list, que devolvería identificadores estables opacos con ancho y alto lógicos y un tipo elegido en tiempo de ejecución (lcd, eink, led-matrix u other), y display.push, que enviaría un lote no vacío de píxeles sRGB de tres bytes direccionados por coordenadas. El descubrimiento en tiempo de ejecución mapearía el RGB lógico sobre la profundidad de color nativa, la orientación y el refresco, y PUEDE rotar, reordenar, cuantizar, aplicar dither o fusionar actualizaciones. La política del shell controlaría qué pantallas puede listar o escribir un napplet y PUEDE rechazar, limitar la tasa o topar los lotes. Antes de aplicar cualquier píxel, el runtime validaría todo el lote, así que un push fallido no cambiaría nada en el dispositivo. El éxito significaría que el lote fue aceptado, no que el refresco del hardware haya terminado.

Marmot

Un experimento abierto de Marmot sustituiría el borrador retirado de External Commit para la inscripción desde la misma cuenta por una forma de Commit acotada. Marmot, el protocolo de mensajería de grupo MLS sobre Nostr, asigna en ese borrador el componente sin datos 0x800d (marmot.same-account-membership.v1) como marcador de comportamiento negociado. Mientras sea obligatorio, una hoja actual puede redactar exactamente un Add inline de la misma cuenta o de uno a cuatro Removes inline de hermanos, cada uno con un UpdatePath normal y prioridad de convergencia ordinaria, y cada Commit DEBE dejar como máximo cinco hojas actuales por cuenta. El emparejamiento usa un QR efímero mostrado por el patrocinador (marmot-pairing-v1:) cuyo secreto alimenta HKDF-SHA256 y ChaCha20-Poly1305 sobre un canal independiente del portador. Las pruebas kind 453 solo locales ligan la sesión a la clave de cuenta compartida y nunca se envían por relays. Tras un Welcome coincidente, el primer payload de aplicación de quien se une es un acuse kind 452 no renderizado ligado a los digests de Welcome y GroupInfo, de modo que un Welcome idéntico byte a byte puede recuperarse sin consumir de nuevo el KeyPackage. El patrocinador emparejado es la raíz de confianza de quien se une para esa rama y no prueba finalidad global. Un documento acompañante de sincronización de cuentas sigue siendo exploratorio y no interoperable. El experimento no forma parte del perfil base adoptado.

Seis agostos en la historia de Nostr

Los agostos siguen un solo problema de interoperabilidad: cómo un cliente nombra un objetivo y le adjunta comentarios. El repositorio original del protocolo no registró commits en agosto de 2021, así que el núcleo de eventos firmados quedó quieto. NIP-25 (reacciones) salió luego de la caja de solo kind 1 en 2022. Los registros reemplazables regulares ganaron coordenadas naddr y a con identificador vacío en 2023; en 2024, la clase reemplazable parametrizada aparte pasó a llamarse eventos direccionables sin cambiar el formato de cable. Las reacciones se trasladaron a medios externos en 2025. El kind 1111 de NIP-22 (hilos de comentarios) llegó a clientes en producción en 2026. La progresión va de un documento de protocolo inactivo a un vocabulario compartido de respuestas y reacciones que funciona en notas, registros reemplazables y objetos fuera de la red.

Agosto de 2021

La ventana de commits de agosto de 2021 en el repositorio original del protocolo está vacía. El último cambio antes de ese mes inactivo fue el borrador de NIP-05 del 18 de junio, que añadió identificadores de dominio DNS como puntero legible por humanos a una clave pública. NIP-05 (identificadores de dominio) pasó después a un archivo JSON well-known, pero a mediados de 2021 seguía siendo una consulta TXT de DNS. Agosto no amplió ese trabajo de identificadores ni añadió un nuevo kind de evento o mensaje de relay.

La misma ventana vacía aparece en las herramientas que ya existían junto a la especificación. noscl, un cliente de línea de comandos creado en enero de 2021, no registró commits en agosto; tampoco lo hicieron go-nostr ni nostr-tools. La actividad del protocolo se reanudó solo a final de año, cuando el repositorio asignó NIP-09 (solicitudes de borrado de eventos) y sustituyó el esquema DNS por un archivo JSON well-known de identificadores. Agosto de 2021 es la etapa inactiva entre el borrador de identificadores de junio y el trabajo de borrado y JSON well-known de diciembre, mientras el modelo de eventos firmados y relays se mantuvo tal como estaba escrito.

Agosto de 2022

El 19 de agosto, una edición de NIP-25 amplió los objetivos de las reacciones kind 7 desde las notas de texto kind 1 a otras notas. El evento kind 7 y la convención +/- ya estaban en el borrador. Ese cambio de interoperabilidad permitió que un me gusta, un no me gusta o un emoji se adjuntara a un perfil, una lista de seguidos o cualquier kind de evento posterior que reutilizara los mismos tags e y p.

La especificación actual de NIP-25 conserva esa generalización: una reacción indica reacciones de usuario a otros eventos, y un objetivo direccionable recibe además un tag a con coordenadas kind:pubkey:d-tag. Amethyst, un cliente Android, implementa ese contrato en su constructor de reacciones. Su constructor acepta cualquier evento, escribe tags e, p y k, y añade un tag a cuando el objetivo es un evento direccionable. Esto generalizó los objetivos de reacción más allá de kind 1; cambios posteriores de agosto añadieron coordenadas estables y tags de contexto de comentario.

El software de relay también estaba convirtiendo reglas de tags en comportamiento de almacenamiento. El 17 de agosto, nostr-rs-relay dejó de tratar cualquier valor de tag con aspecto hexadecimal como clave de índice binaria. Limitó esa optimización a los tags de una sola letra y a los valores hexadecimales en minúsculas, preservando los tags de texto ordinarios en lugar de decodificarlos a una forma que los filtros no podían igualar. Ese mismo mes unió así dos caras de la interoperabilidad: las especificaciones ampliaron a qué podía apuntar una interacción, mientras un relay corregía cómo se indexaban y recuperaban esos tags de objetivo.

Agosto de 2023

El 24 de agosto, NIP-19 (identificadores bech32) definió cómo codificar un evento reemplazable no parametrizado como naddr. El campo de identificador, el tag d, pasó a ser una cadena vacía para los kinds que reemplazan solo por pubkey y kind, como los metadatos y las listas de contactos. Cinco días después, NIP-01 (el protocolo base de eventos y relays) añadió el formato de a-tag correspondiente: kind:pubkey: con dos puntos finales y sin identificador. Los clientes podían ahora apuntar a un registro reemplazable sin esperar un id de evento concreto que el siguiente reemplazo invalidaría.

El texto actual de NIP-19 sigue indicando a quienes implementan que usen una cadena vacía para esos eventos reemplazables. nostr-tools, la biblioteca JavaScript de identificadores, codifica ese campo mediante naddrEncode, así que quien la llama puede pasar un identificador vacío y producir una coordenada compartible. El trabajo de agosto de 2023 convirtió el estado reemplazable en algo que un comentario, una reacción o un enlace de compartición podía nombrar después de que el evento subyacente hubiera sido sustituido. El agosto siguiente estandarizó la terminología de la clase reemplazable parametrizada relacionada, mientras tags de comentario posteriores reutilizaron la gramática de coordenadas como A y a.

Los payloads privados se estaban volviendo portables al mismo tiempo. El 24 de agosto, rust-nostr añadió funciones de cifrado y descifrado NIP-44 a sus bindings de JavaScript, exponiendo el esquema versionado de clave de conversación a las aplicaciones web junto a quienes llamaban desde Rust nativo. El 22 de agosto, Amethyst separó el cifrado NIP-44 del formato del evento de mensajería, reflejando la separación de protocolo entre cómo se cifra el contenido y cómo lo transporta una aplicación. Las coordenadas estables hicieron más fáciles de referenciar los objetos públicos; las APIs de cifrado reutilizables hicieron más fácil mover contenido privado entre implementaciones sin acoplarlo a un kind de mensaje.

El mismo mes también trajo financiación para trabajo adyacente de aislamiento de claves, interfaz y educación. Una ronda de subvenciones de OpenSats del 17 de agosto asignó sus subvenciones del Nostr Fund a Amber, al diseño compartido de interfaz de Nostr y a la educación sobre casos de uso de Nostr. La subvención de Amber se centró en mantener las claves de firma en una aplicación Android dedicada mediante NIP-46, mientras las subvenciones de diseño y educación abordaron la incorporación y los patrones de aplicación reutilizables. El sistema Nostr más amplio avanzaba mediante commits de especificación, aislamiento de claves, trabajo de interfaz y educación de desarrolladores financiada como infraestructura compartida.

Agosto de 2024

El 20 de agosto, las especificaciones renombraron “evento reemplazable parametrizado” a “evento direccionable” en NIP-01 y dieciséis documentos más, incluidos artículos de formato largo, actividades en directo, listas, calendarios y anuncios clasificados. El formato de cable no cambió. kind:pubkey:d-tag siguió siendo la coordenada. Lo que cambió es que cada especificación que ya usaba esas coordenadas empezó a usar la misma palabra para ellas.

Ese vocabulario es el que llevan las implementaciones actuales. NIP-01 almacena los eventos direccionables como el registro más reciente por kind, pubkey y tag d. NIP-19 llama a un naddr “a nostr addressable event coordinate”. La ruta de reacciones de Amethyst, citada arriba, tipa el objetivo como AddressableEvent antes de escribir el tag a. La extensión de coordenadas de 2023 y el cambio de terminología de 2024 usan ambos la gramática de coordenadas kind:pubkey:d-tag, mientras NIP-01 sigue distinguiendo los eventos reemplazables regulares de los direccionables. Un comentario posterior puede por tanto recuperar una discusión direccionable mediante A en mayúscula sin importarle qué id de evento ocupa esa dirección en ese momento.

Los protocolos de almacenamiento aplicaban la misma preferencia por identificadores explícitos. El 27 de agosto, el BUD-04 de Blossom permitió que un evento de autorización llevara varios tags x de hash de blob, de modo que un cliente pudiera autorizar un lote acotado de subidas, réplicas o borrados sin pretender que los hashes describían un solo objeto. Cuatro días después, el proyecto aclaró su descriptor de blob y añadió un ejemplo. Los eventos Nostr coordinaban operaciones sobre medios direccionados por contenido mientras los bytes permanecían en servidores de medios, separando la autorización firmada del transporte de almacenamiento.

El 29 de agosto, la firma remota se volvió más tolerante con conjuntos de relays imperfectos. go-nostr cambió su cliente NIP-46 para que un relay defectuoso no pudiera bloquear una petición enviada por otros relays configurados: las conexiones a relays y los intentos de publicación se ejecutan de forma independiente, y la llamada avanza en cuanto cualquier conexión tiene éxito. El 19 de agosto, OpenSats también anunció apoyo a largo plazo para el creador de Amethyst, Vitor Pamplona, incluido trabajo en los mensajes privados NIP-17, las bibliotecas multiplataforma y el modelo outbox. El vocabulario del protocolo, el transporte resistente, el trabajo de privacidad y la financiación sostenida de mantenimiento convergían en el mismo objetivo: clientes que pudieran seguir funcionando entre dispositivos y condiciones desiguales de relay.

Agosto de 2025

El 22 de agosto, NIP-25 ganó reacciones a contenido externo. Una reacción a algo que no es un evento Nostr nativo debe ser kind 17 y debe llevar tags k e i de NIP-73 (identificadores de contenido externo), sustituyendo el antiguo tag r de sitio web. Los ejemplos del texto fusionado son una URL web (k=web) y un episodio de pódcast identificado por GUID de programa y GUID de ítem, con URLs de Fountain como pistas. Las reacciones habían salido de kind 1 en 2022. Ahora salieron del conjunto de eventos Nostr.

Fountain 1.3, publicado el 15 de agosto de 2025, incorporó esos me gusta antes de la fusión de la especificación y dijo que funcionan con Nostr para que otras apps de pódcast puedan leerlos. El documento de NIP-25 de hoy sigue usando el ejemplo de GUID de pódcast de Fountain. Para agosto de 2025, una coordenada de reacción podía nombrar un episodio de pódcast o una página web con la misma gramática de identificadores que un comentario usa después para una raíz externa.

Agosto de 2026

Este agosto llevó los hilos de comentarios a los clientes que escriben respuestas ordinarias. La modificación de junio, fusionada después, eliminó la línea que había dicho a los clientes que no usaran comentarios NIP-22 en notas cortas. NIP-30 (emoji personalizados) añadió luego kind 1111 junto a notas, reacciones y estados de usuario, así que un comentario puede llevar los mismos tags de emoji que esos otros kinds ya usaban. El trabajo de especificación es el permiso. El trabajo de cliente es el despliegue.

Snort, un cliente web, publica ahora comentarios NIP-22 para objetivos kind 1 por defecto, se suscribe a hilos mediante tags raíz E/A en mayúsculas, y acepta kind 1111 en las notificaciones. Ditto, un cliente web comunitario, publica cada respuesta como comentario NIP-22, kind 1111 para texto y 1244 para voz, incluidas las respuestas a notas kind 1, mientras sigue leyendo respuestas NIP-10 (encadenado de notas). El giro de seis años se ve en esos valores por defecto: 2022 generalizó la reacción, 2023 y 2024 nombraron la coordenada, 2025 apuntó las reacciones fuera de la red, y 2026 convirtió el comentario en el evento de respuesta compartido para esos mismos objetivos.

La infraestructura de grupos privados definía la recuperación como requisito de interoperabilidad. El contrato de durabilidad y reinicio del 13 de agosto de Marmot especifica qué estado local de MLS y de publicación debe sobrevivir a un reinicio, y exige a los clientes reconciliar el estado persistido antes de continuar con operaciones de grupo. Eso extiende la progresión de agosto más allá de nombrar un objetivo: un cliente maduro debe además preservar suficiente estado criptográfico y de entrega para reanudar con seguridad tras una interrupción. Las formas de evento compartidas solo sirven cuando las implementaciones pueden recuperar el estado necesario para usarlas.

Enviad un DM NIP-17 para compartir un proyecto o una noticia a través del proyecto Nostr Compass.