Nostr Compass #46

Esta semana: Mostro añade la revinculación de identidad firmada. Amethyst lleva encuestas privadas a los grupos Marmot y añade sincronización cifrada de ajustes entre dispositivos. swift-nostr incorpora una comprobación que se niega a firmar events cuya clave pública no coincide con la del firmante. Cerramos con Seis años de octubres en Nostr, 2021–2026.

Noticias destacadas

Mostro

Mostro, el daemon de intercambio entre pares coordinado mediante Nostr, publicó la versión 0.20.1. Incorpora la revinculación de identidad firmada, que el número de la semana pasada describía como no implementada, e incluye las exportaciones de reputación que antes solo existían en el código fuente. La identidad vinculada firma una autorización de un solo uso que nombra el nodo y la nueva identidad, válida durante una hora como máximo. El daemon registra el ID del event y realiza el cambio con una operación compare-and-swap, de modo que una firma fallida o una carrera perdida no alteran nada. Los operadores disponen además de una RPC auditada, accesible solo por loopback, que exige un token de autenticación y un motivo. La revinculación no revoca las atestaciones ya emitidas.

Las fusiones posteriores no están confirmadas en ninguna versión publicada. Un proveedor opcional de paridad fija con el USD añade USDT, USDC y DOC al feed mostro-rates de Nostr solo cuando el operador lo activa. Ni los proveedores de red ni las cotizaciones de monedas retransmitidas lo activan de forma implícita. Un cambio posterior renombra el proveedor y su clave de configuración a pegged, en sustitución de la clave stablecoins, nunca publicada. También cotiza BTC, LBTC y RBTC a una paridad fija de 1:1 en sats y publica las tasas como events de kind 30078. Estos supuestos de paridad configurados no garantizan ni la paridad ni la liquidación. Las comprobaciones de paridad en vivo quedan fuera de este mecanismo. El proveedor viene desactivado por defecto. Las monedas aceptadas siguen condicionando las órdenes; el trabajo en el cliente, el libro del protocolo y la protección de paridad va por separado. Los timelocks de las fianzas ahora funcionan de forma independiente del escrow. La caducidad anunciada de las órdenes queda acotada, y la ventana para tomar una orden en el libro se cierra antes de que pueda caducar una fianza. Las fianzas de maker existentes de 144 bloques caducan al actualizar, y esas órdenes deben crearse de nuevo. Los intercambios en curso y el modo Cashu no se ven afectados, aunque algunas configuraciones de operador se niegan a arrancar hasta que se ajuste el timelock de la fianza.

Extensión Nostr WoT

La extensión Nostr WoT, un firmante para navegador con funciones de red de confianza, publicó la 0.8.15 con una opción para generar la clave de recuperación a partir de 256 bits de entropía obtenidos por el propio usuario con dados o monedas. Las tiradas de dados se procesan con SHA-256 y los lanzamientos de moneda se usan como bits en bruto, todo en una pestaña aislada que no muestra la frase de recuperación. El proceso de incorporación ahora agota su tiempo de espera cuando los relays no son accesibles. La versión 0.8.16 añadió permisos permanentes para la autenticación ante relays (NIP-42), de forma que los usuarios pueden aprobar AUTH una sola vez para todos los relays de un sitio o para cada sitio conectado (implementación de la autenticación ante relays). Las denegaciones por relay o por sitio prevalecen sobre estos permisos, y las revocaciones se vuelven a comprobar antes de resolver las solicitudes en cola. Los alcances amplios son siempre una elección explícita del usuario y nunca se aplican a HTTP Auth (NIP-98). El límite de la cola sigue en cinco, así que las solicitudes que lo superan continúan fallando y reintentándose. La versión 0.8.18 une la importación y la recuperación en un único flujo que detecta los formatos de clave y muestra una vista previa de la identidad; además, la recuperación compatible con Nosskey conserva la misma identidad, las cuentas existentes y las passkeys originales.

El SDK para desarrolladores, distribuido por separado, nostr-wot-sdk, publicó la 3.0.1 con compatibilidad estable con identity 1.1. La recuperación con passkey, también a través de Nosskey, conserva la pubkey original, y el código del proveedor, de recuperación y de firma comparte ahora una única implementación (código fuente de recuperación y del proveedor del SDK). Los paquetes de reenvío obsoletos siguen funcionando, pero los integradores deberían pasar a los puntos de entrada mantenidos.

Amethyst

Amethyst, el cliente de Nostr para Android y escritorio, publicó la versión 1.20.0 con encuestas privadas y otras funciones de los grupos cifrados Marmot. Entre ellas figuran votos privados reemplazables, emoji personalizados cifrados, eliminación de mensajes por parte de los administradores, denuncias y archivos multimedia vinculados a la época actual del grupo. Tras la revisión, el autor no volvió a ejecutar las comprobaciones de interoperabilidad entre clientes ni probó el cambio manualmente en Android. Siguen existiendo claves de caché para ramas en competencia que comparten número de época, y las claves de los archivos multimedia cifrados pueden sobrevivir a los mensajes efímeros. La sincronización de ajustes guarda seis grupos de ajustes de la aplicación como datos cifrados de NIP-78. Las claves, los firmantes, los monederos, las notificaciones, los paneles y los marcadores de lectura permanecen en cada dispositivo. La primera modificación de ajustes publica los seis grupos. Una cuenta de solo lectura mantiene sus ajustes en local, y el comportamiento con dos dispositivos firmantes no se ha verificado.

Las notificaciones del sistema en escritorio siguen el filtro de Notificaciones y omiten los gift wraps externos desechables y los DM silenciados. Los tags d no confiables de más de 255 bytes ya no provocan errores. Las búsquedas por kind consultan únicamente los relays conectados y los de búsqueda de la cuenta, con un máximo de 200 events cada uno. Las aplicaciones usan el manejo de JSON Kite de Quartz para frames, events, filtros y mensajes de NIP-46 y NIP-55, aunque la firma mediante esos dos protocolos no se verificó en dispositivos. Una división de bibliotecas posterior traslada a bibliotecas compartidas las reglas de los protocolos Marmot y cordn que otros clientes necesitarían.

El código fusionado después de la 1.20.0, que aún no forma parte de ninguna versión, ejecuta sobre la biblioteca compartida la ruta de recepción Marmot de la aplicación. Cada mensaje descifrado se persiste de forma idempotente. Al unirse se registra una línea base, de modo que el primer cambio de membresía muestra su fila. Un mensaje de kind 445 que llega antes que su commit se retiene y se reproduce más tarde, y la puesta al día de los administradores confirma las salidas pendientes. amy cordn migrate export desactiva los comandos de sesión de la instalación antigua hasta que se realice una importación o se use el nuevo comando de reanudación. El autor ejecutó pruebas de amy por loopback y pruebas de la biblioteca contra copias locales. No probó manualmente la ruta de recepción de la aplicación en vivo ni ejecutó el conjunto de pruebas de interoperabilidad de Marmot. Una actualización incompatible del formato de napplets NIP-5D propuesto interpreta el hash del manifiesto de un napplet como un único artefacto /index.html, en lugar del antiguo agregado de rutas, por lo que los paquetes heredados deben volver a publicarse. Los dominios NAP obligatorios que no están disponibles fallan de forma cerrada, y los opcionales simplemente quedan ausentes. Los iconos pasan comprobaciones de hash y de decodificador, el almacenamiento se particiona por kind del manifiesto, artefacto e instantánea, y los blobs de recursos usan base64 canónico. No se hicieron pruebas manuales en dispositivos, pruebas entre clientes ni publicaciones en relays en vivo.

Los rechazos en un firmante externo se gestionan ahora en corrutinas que antes no tenían protección, así que ya no bloquean la aplicación. Los libros electrónicos, revistas y números de PressStr (kinds 33953, 34609 y 39731) ya se muestran. Se abren los PDF en el lector integrado y los EPUB se envían al gestor del sistema. Las tarjetas muestran el tipo y el tamaño del archivo, nunca descargan un PDF grande solo para previsualizarlo y obtienen los números únicamente del autor de la revista. El autor no informó de pruebas en dispositivos Android para este cambio. Con las vistas previas enriquecidas desactivadas, las facturas y los LNURL aparecen como etiquetas compactas que se pueden copiar, sin botón de Pagar, y las tarjetas de factura ahora indican su caducidad. amy gift wrap ahora fecha el seal y el wrap en momentos aleatorios distintos, cada uno hasta dos días en el pasado. --no-backdate lo desactiva. La ruta habitual de DM recibe su corrección por separado en Quartz. En escritorio, cada tarjeta de vídeo controla su propia reproducción, de modo que las tarjetas con la misma URL ya no se quitan el vídeo unas a otras. El autor lo probó en macOS, pero no con la caché vacía. Una corrección propuesta para los enlaces en Windows abre los enlaces mediante rundll32 con su ruta completa y recurre a AWT como alternativa. No se reprodujo la causa raíz, así que se trata de una corrección probable, no confirmada.

Myco añade almacenamiento cifrado para napplets y avisos de actualización firmados

Myco, un host para napplets de Nostr en Android, publicó la 0.12.0 y la 0.12.1. Ahora los napplets pueden guardar datos autocifrados con NIP-44 a través del entorno de ejecución, pero las aplicaciones con permisos de lectura de relay, outbox o malla pueden ver el texto en claro, de modo que los datos no quedan aislados por aplicación. Quienes iniciaron sesión antes con Amber deben volver a hacerlo para conceder los nuevos permisos de cifrado y descifrado. Los avisos de actualización los firma un editor fijado y solo llegan a dispositivos que ya ejecutan la 0.12. Con conexión, Myco puede consultar Zapstore a diario y Circle, mientras que el modo solo malla consulta únicamente Circle, en sustitución de la pausa inicial. Una vía Blossom local elegida de forma explícita conserva los archivos en el dispositivo sin servidor alguno, hasta 64 MiB por aplicación y día. Las subidas fallidas a un servidor predeterminado aprobado también guardan una copia local. Ninguna de las dos vías elimina los metadatos EXIF. Las versiones añaden además compatibilidad con Android TV y un selector de archivos NAPFS en el que el usuario elige los archivos.

Versiones publicadas

Monostr

Monostr, un cliente social de Nostr para Android, publicó la 0.26.0, su versión más reciente. Los vídeos de hasta dos minutos ahora se comprimen en el dispositivo y se les eliminan los metadatos de ubicación. Descubrir, la búsqueda y la incorporación ofrecen listas de seguimiento seleccionadas. Los hilos y las notificaciones muestran ya las respuestas del Fediverso enviadas como comentarios NIP-22.

Se mantienen las funciones de la 0.25.0. Cuando falta el mensaje padre de una respuesta, la aplicación lo busca en las pistas de relay de la respuesta y en los relays del autor del mensaje padre, lo que implica conectarse brevemente a relays ajenos a la lista del propio usuario. Además, los relays y las suscripciones a mensajes en vivo se reconectan cada vez que el dispositivo cambia de red.

Sidecar

Sidecar, una extensión de navegador y firmante de Nostr, publicó la 1.16.3. El editor y la herramienta de subrayado ahora publican en los relays propios de la cuenta y cuentan solo los relays que confirman el event, y después enlazan a esos relays. Una confirmación indica que el relay aceptó el event, no que vaya a conservarlo. El editor ampliado ya no recurre a los relays predeterminados de Ajustes. Cada relay tiene su propio plazo de 12 segundos. Solo se reintenta, una vez y con sockets nuevos, una publicación que falla en todos los relays. Los resultados de las encuestas también consultan cuatro relays públicos en busca de votos. Un cambio fusionado después de la etiqueta añade un relay más para captar votos registrados fuera de los relays habituales. En una encuesta en vivo, esto elevó el recuento de 21 a 23 votos. Es el resultado de una sola encuesta y no dice nada sobre la exhaustividad en toda la red. El recuento sigue admitiendo un voto por persona e ignora los emitidos después del cierre de la encuesta. La anterior 1.16.1 limita los permisos de firma permanentes a la cuenta y al sitio que los aprobaron, y a un único registro direccionable cuando el event tiene un tag d. Los permisos nunca cubren el cifrado ni el descifrado. Las listas de perfil, seguidos, silenciados y relays quedan fuera de cualquier permiso. También se excluyen las eliminaciones, las solicitudes de zap, el AUTH ante relays y el control del monedero. Con la extensión bloqueada se sigue pidiendo el PIN. Revocar un permiso u olvidar un sitio borra sus permisos y sus ventanas de aprobación.

Un pull request abierto, independiente del anterior, haría que pagar una oferta CLINK contara como un zap. Figura en la sección Unreleased del registro de cambios y no implementa Debits. El panel de la oferta pasaría una solicitud de zap firmada de kind 9734 con payer_data, para que el servicio pueda publicar un recibo de kind 9735. Los recibos irían primero al relay de la oferta y después a los relays del destinatario, sin duplicados y con un máximo de seis. No se usan los relays del pagador. Si una oferta responde con el código 3 y una oferta sucesora que se puede decodificar, Sidecar la seguiría una vez con una nueva solicitud y una nueva firma. Nunca escribiría en el perfil del destinatario. En la fecha de corte, el cambio seguía sin fusionarse.

Roadbeacon

Roadbeacon, un cliente para informar de ubicaciones que antes se llamaba Roadstr y que es distinto de la aplicación independiente Roadstr, publicó la 0.4.0 con su nuevo nombre como un paquete nuevo y con un nuevo formato de events. Los informes y los votos usan ahora los kinds compartidos e interoperables 1315 y 1316, las coordenadas emplean marcos enteros que se pueden reconstruir con exactitud y la versión web valida las firmas. El paquete se instala junto al antiguo sin migrar datos. Los events anteriores siguen siendo válidos en los relays, pero el nuevo cliente no puede leerlos.

Jumble

Jumble, un cliente web de Nostr, publicó la v26.10.1. Entre las novedades hay un editor de artículos largos, palabras silenciadas que se sincronizan entre dispositivos, notificaciones del sistema y lectores para contenido de grupos y de Git. Los cambios en las publicaciones pendientes y en el diseño de los que hablamos en un número reciente llegan con esta versión.

Un commit fusionado después de la publicación añade un ajuste opcional de respuestas NIP-22. Viene desactivado por defecto y se guarda como preferencia local. Si se activa, las respuestas a notas de texto de kind 1 se envían como comentarios de kind 1111. Los hilos existentes de kind 1111 conservan su raíz, y los comentarios sobre otros kinds o sobre contenido externo siguen siendo de kind 1111. Con el ajuste desactivado, las respuestas mantienen el comportamiento heredado de kind 1. La aplicación advierte de que algunos clientes podrían no mostrar estos comentarios.

nostr-idb

nostr-idb, una biblioteca que almacena en caché events de Nostr en el IndexedDB del navegador, publicó la 5.1.1 con correcciones en las consultas. Las búsquedas por ID exacto ya funcionan con events reemplazables y direccionables, y ahora se aplican todas las restricciones de los filtros y los límites por filtro, también a las escrituras pendientes y al historial de suscripciones. Se han corregido la poda de la caché y los events con marca de tiempo cero. El tamaño de la caché en memoria, maxMemoryEvents, es por defecto maxEvents, y el valor cero la desactiva.

Manent

Manent, un cuaderno cifrado que se sincroniza a través de Nostr, publicó la 3.0.0 con notas de voz. Las grabaciones se sincronizan cifradas como cualquier otra nota, y las transcripciones se generan sin conexión con Whisper después de que la aplicación descargue un modelo. La versión incluye también la recuperación de la autenticación ante relays que antes cubrimos como trabajo en el código fuente, y que ahora llega a través de la versión 0.10.1 de NDK, la biblioteca Nostr Development Kit.

NoorNote

NoorNote, un cliente de Nostr para escritorio y web, publicó la 1.9.2 con búsqueda de texto completo local en el dispositivo sobre notas y mensajes directos, además de un modo que solo usa la caché. La versión 1.9.3 devuelve la legibilidad a los desplegables, menús y avisos emergentes tras una regresión de vidrio transparente en la 1.9.2. Estas versiones incluyen también el filtro de marcas de tiempo futuras que antes solo existía en el código fuente. Los perfiles que no logran cargarse permanecen ahora en estado de carga hasta que se confirma que no están disponibles.

Earthly

Earthly, un cliente de Nostr para crear mapas, publicó la 0.1.22 con correcciones de relays y pagos. La autenticación ante relays queda ahora vinculada a la cuenta activa. Las suscripciones y los recuentos recuperados distinguen un recuento no disponible de un cero real y mantienen los recuentos entre revisiones del mapa. Los totales de zaps salen de recibos de zap reales, y la aplicación espera a que termine la sincronización del monedero antes de gastar. Los pagos en vivo con Nostr Wallet Connect y con mints siguen sin probarse (integración de la versión).

Chama

Chama, un cliente de intercambio con escrow construido sobre events de Nostr, publicó la 6.4.31, que comprueba las copias de seguridad de la semilla antes de financiar. Antes de que la clave de intercambio on-chain de este dispositivo entre en los términos firmados de CREATE, JOIN o depósito, un relay debe devolver la copia de seguridad firmada de la semilla que el dispositivo abrió; si la copia falta, está retirada o entra en conflicto, el intercambio se detiene. Los reintentos reenvían exactamente la copia guardada sin generar una semilla nueva. La relectura demuestra la disponibilidad en ese momento, no la persistencia. Los anuncios con varias unidades usan ahora pedidos por cantidad. La versión 6.4.30 solo contabiliza los pedidos de la tienda cuando los términos firmados por el comprador coinciden con el anuncio firmado, y protege frente a events tardíos de terceros en intercambios cuyo CREATE firmado tenga fecha del 1 de diciembre de 2026 o posterior, mientras que los intercambios anteriores conservan el antiguo comportamiento de caducidad (validación de caducidad de intercambios y de la tienda).

Un pull request abierto, sin fusionar en nuestra fecha de corte de fuentes, permitiría una única copia de seguridad de la semilla del monedero por identidad. Al arrancar, la primera creación se serializaría con una cola dentro de la página y Web Locks, y luego se volvería a leer el estado del relay. Los navegadores distintos dependen únicamente de esa relectura. Un bloqueo distribuido y la reparación de copias en conflicto ya existentes quedan fuera de este cambio. No probamos ninguna ruta que mueva dinero.

Linky

Linky, un monedero Cashu que se sincroniza a través de Nostr, añadió transferencias on-chain experimentales tras un flag en la versión 26.10.7 y en la compilación 26.10.8 para Android. Un operador humano configurado completa las solicitudes de envío y recepción en un plazo de 24 horas a cambio de una comisión, por lo que las transferencias no son atómicas ni prescinden de la confianza. El cambio de coordinación usa mensajes de aplicación personalizados de Nostr, configuración del operador mediante NIP-78 y un nuevo ámbito de sincronización de enlaces. Ese ámbito sincroniza los envíos de ecash pendientes del operador para que sus otros dispositivos no puedan pagar, reembolsar ni liquidar dos veces el mismo envío. Una recepción solo se completa cuando el monedero del usuario recibe la cantidad Cashu correspondiente. Operador y usuario se encuentran únicamente en relays recomendados, no mediante listas de relays NIP-65 ni listas de bandeja de entrada de DM, así que perder todos los relays compartidos puede romper la coordinación.

LaWallet

LaWallet, un servicio de monedero y cuentas construido sobre Nostr Wallet Connect, publicó la versión 2.9.0 y la beta 1.2.0 para Android; ambas añaden la recuperación asistida con tarjeta NFC hacia un nuevo inicio de sesión de Nostr (flujo de recuperación nativo). La recuperación exige acercar la tarjeta en ese momento, con verificación criptográfica, y un código QR de recuperación de un solo uso válido durante 15 minutos. Los activos se mueven en una sola transacción, los roles no se transfieren, las autorizaciones OAuth antiguas se revocan y el inicio de sesión antiguo queda vacío. La recuperación con tarjeta está activada por defecto; los titulares de cuenta pueden desactivarla en los ajustes de Seguridad y revocar los códigos pendientes. Un monedero inaccesible muestra ahora un saldo de cero, lo cual no significa que esté vacío. La beta de Android activa a la fuerza el envío de errores a Sentry en las compilaciones que tienen un endpoint de informes, incluso si antes el usuario lo había desactivado; las compilaciones locales y las de F-Droid no tienen endpoint.

En el código fusionado después de la etiqueta, la callback de la tarjeta puede devolver OK antes de la liquidación por NWC cuando el saldo cubre el pago, así que los terminales de punto de venta deben confirmar su propia factura. Un límite de pago fijo sustituye al límite basado en el saldo. Un pull request abierto, sin fusionar en nuestra fecha de corte de fuentes, permitiría iniciar sesión con passkeys compatibles de otras aplicaciones mediante un proveedor configurado o la recuperación con Nosskey, confirmando la cuenta antes de emitir una sesión temporal con caducidad (#386). Un proveedor puede firmar sin importar la clave privada, e importarla es una elección aparte que requiere confirmación. Sus capturas de pantalla muestran respuestas de demostración simuladas, no una prueba de inicio de sesión real entre orígenes.

Otra fusión, tampoco confirmada en ninguna versión, impide que la callback de NWC y de la dirección Lightning sustituya el monedero remoto de un usuario solo por un error de make_invoice. Una comprobación de disponibilidad y de saldo puede conservar el monedero y devolver en su lugar un 503. El servicio también recuerda los saldos y el estado de los fondos protegidos, y añade una opción de Restaurar. Sus umbrales y el historial anterior desconocido limitan lo que puede proteger, de modo que no garantiza que todos los fondos estén a salvo. No se afirma que haya despliegues ni cuentas de usuario restauradas.

KithMoot

KithMoot, una aplicación basada en Nostr para chat en salas y llamadas, funciona ahora sin los servicios públicos de su editor. Entre el 21 y el 23 de octubre, el editor retiró los códigos públicos de reunión, el servicio TURN compartido, la subida de archivos y la lectura de archivos almacenados. Los enlaces de invitación sustituyen a los códigos de reunión, y los archivos públicos usan por defecto Yakihonne, con un aviso en el primer envío, aunque los usuarios pueden elegir su propio servidor. Las llamadas siguen intentando primero una conexión directa, mientras que Ocultar IP necesita un servidor TURN operativo y nunca recurre a la conexión directa. En la versión de escritorio 0.1.102 y la de Android 0.6.106, el STUN público de Cloudflare reemplaza al del editor, y los usuarios pueden configurar el suyo. Se eliminaron las copias de seguridad servidas, mientras que las copias cifradas sin conexión se conservan. La versión de escritorio 0.1.109 y la de Android 0.6.121 bloquean el chat cuando caducan las credenciales del dispositivo, pero conservan los borradores, y leen el nombre de perfil del propio usuario por separado de las consultas opcionales al directorio. El motor de llamadas habitual no ha pasado a la vista previa experimental del SDK en tiempo real, y el candidato de grupos MLS sigue desactivado por defecto.

La versión de escritorio 0.1.110 añade visores de adjuntos aislados para imágenes, audio, vídeo y PDF en escritorio y en la web. En escritorio se ejecutan en un renderer de Electron dedicado y no persistente, sin acceso a Node, sin almacenamiento de la aplicación y sin acceso a la red externa. El streaming está acotado, y los visores se limpian al cerrarse o cuando se retira un mensaje. La ejecución con WebKit del pull request y una ejecución adicional empaquetada con un SVG hostil se quedaron bloqueadas y no se presentan como verificadas; nada de esto constituye una certificación de seguridad. La compilación para macOS está notarizada, mientras que la de Windows sigue siendo una vista previa sin firmar.

Una fusión posterior, sin que conste que esté en la 0.1.110, renueva las credenciales caducadas del dispositivo según la hora real del reloj tras la suspensión y antes de enviar, conservando el borrador mientras responde el firmante. Surge a raíz de que la credencial de un probador caducara durante la noche en un portátil suspendido. Una solicitud al firmante que nunca obtiene respuesta sigue manteniendo abierta la renovación, y Android tiene un problema de renovación aparte sin resolver. Un pull request abierto, sin fusionar en nuestra fecha de corte de fuentes, pausaría Ayudar a otras personas a conectarse. Según el autor, la aplicación acepta un par de asistencia entre pares sin transportar su contenido multimedia, lo que puede impedir el recurso a un reenviador o a TURN y dejar una llamada en silencio. El valor predeterminado de la biblioteca no cambiaría.

Marmot TS

marmot-ts, una biblioteca en TypeScript para el protocolo de mensajería cifrada en grupo Marmot, publicó la v0.8.0 y la v0.9.0 con cambios incompatibles. Encrypted media V2 añade vinculación con el origen y descifra el contenido multimedia retrasado tras un reinicio, y los descriptores de subida de Blossom, los destinos y el texto cifrado se validan antes de firmar. Los grupos persistidos se rellenan por páginas, con reintentos para los commits inciertos. Ahora las aplicaciones deben proporcionar almacenes duraderos de ingesta y de rebobinado cuyos adaptadores rechacen las lecturas fallidas o que superen el tiempo de espera. Los grupos V1 heredados deben volver a crearse, ya que las funciones auxiliares de V1 se mantienen solo para el historial.

Código fusionado posteriormente da a los observadores de key packages, invitaciones e historial un AbortSignal opcional. Sus listeners se limpian de inmediato al retornar, lanzar una excepción o ser desechados, incluso con una lectura de almacenamiento aún pendiente. Los cambios que llegan mientras un consumidor está en pausa se retienen y se combinan en una sola actualización. La lectura subyacente del backend continúa tras la cancelación. Los fallos de consulta siguen provocando un rechazo, y el cambio no certifica la interoperabilidad en tiempo de ejecución.

Cliente de correo de Nostr

nostr-mail-client, un cliente de correo construido sobre Nostr, publicó la v0.19.0 con un único flujo de inicio de sesión para bunker, nsec y ncryptsec, que incluye la aprobación de la auth_url de un firmante remoto. Ahora sigue los cambios en las listas de relays de DM, bandeja de entrada, outbox y privados sin necesidad de volver a iniciar sesión, elimina notificaciones de correo duplicadas durante la sincronización y sincroniza las firmas de correo entre dispositivos de forma cifrada. Los adjuntos de correo que superan el límite de 25 MB se descartan con un aviso, y una dirección exclusiva de Nostr no puede recibir respuestas enviadas desde el correo electrónico.

CLI de conformidad de napplets

napplet/web, los paquetes y herramientas web para napplets (aplicaciones web distribuidas como events de Nostr firmados), incluye ya el trabajo de verificación del número anterior en la versión numerada @napplet/conformance-cli 0.4.0. Antes de una ejecución sin interfaz, la CLI comprueba el ID del event del manifiesto, la firma y el hash exacto del HTML en bruto, e informa de los fallos de vinculación en tiempo de ejecución, de espacio de nombres y de instalación por separado de los errores del napplet. La alternativa integrada solo cubre RESOURCE y GAMEPAD, por lo que los hosts personalizados deben pasar explícitamente las entradas de origen y de instantánea.

El comando de despliegue de Napplet prepara ahora por defecto las fichas de Zapstore: captura pantallas de cada compilación seleccionada y prepara un event de Software Application de kind 32267; --no-screenshot y --no-zapstore desactivan estos pasos. Preparar los metadatos no equivale a publicar una versión, y el cambio no añade ningún event de versión de paquete ni de recurso.

napplet-soy

napplet-soy, un entorno de trabajo para crear y publicar napplets, etiquetó su herramienta de línea de comandos soyli como v0.31.2 y v0.31.3, que no constituyen un despliegue de Studio. Una vez confirmada la entrega por Git, la publicación marca como fusionadas las propuestas de colaboración en Git (NIP-34) incluidas tras comprobar la ascendencia exacta y el destino junto con la revisión actual, y al reanudar reutiliza estados prefirmados. Las revisiones más recientes de una propuesta siguen abiertas, y una etiqueta que contiene un commit no se toma como prueba de que la rama de destino lo haya fusionado. El código detrás de estas etiquetas añade también una primera vista de monedero Cashu (NIP-60) en un espacio de trabajo Manage unificado y mantiene los napplets en ejecución al cambiar de pestaña. El actualizador de la anterior v0.31.1 sigue el ID estable del repositorio de GitHub, de modo que las instalaciones conservan sus cuentas y proyectos tras el traslado a Soytec. Las instalaciones con el actualizador antiguo deben ejecutar el instalador una vez.

El monedero Cashu NIP-60 canjea nutzaps NIP-61 y guarda las salidas de mint preparadas y las actualizaciones firmadas para los relays antes de ejecutarlas, de modo que las solicitudes inciertas se pueden recuperar sin repetir un pago. Los monederos permanecen aislados por cuenta y las pestañas del navegador no pueden gastar al mismo tiempo, pero las pruebas usaron mints falsos y la interoperabilidad con dinero real no está verificada. Las páginas de contribución admiten ya zaps dirigidos al autor, que pagan al autor firmante de la versión o propuesta elegida.

La etiqueta soyli v0.31.4 recoge el historial de contribuciones y los zaps de los autores, además de cambios de preparación para NIP-5D, audio y pruebas. Las llamadas de dominio ya no esperan a que la shell indique que está lista. Un host compartido coordina el audio que los napplets controlan mediante NAPMEDIA sin relajar el aislamiento de los iframes. Esta etiqueta tampoco es un despliegue de Studio. Cinco comprobaciones configuradas se superaron y otras cinco se omitieron. La conformidad completa sigue sin demostrarse, y las aplicaciones reparadas están pendientes de volver a publicarse.

Pakstr

Pakstr, una herramienta de línea de comandos que compila aplicaciones Android y las publica en Nostr, etiquetó la v0.29.1. Antes de publicar, lee el certificado del firmante que un APK declara en su bloque de firma v2 o v3 y compara su SHA-256 con el sidecar esperado y la prueba de identidad (revisión de la publicación). Se rechazan los APK sin firmar, mal formados o con varios certificados, los sidecars obsoletos se eliminan al recompilar y un nsec de publicación no válido falla antes de la compilación. El analizador no verifica la firma del APK en sí, tarea que queda en manos de Android y de apksigner, así que detecta compilaciones obsoletas, sin firmar o con el certificado equivocado, pero no puede demostrar que una compilación no esté falsificada. No se admiten ZIP64, los firmantes múltiples ni la rotación de claves.

MDK

MDK, el SDK y entorno de ejecución para los grupos cifrados Marmot, publicó la v0.14.0 estable. Incluye la entrega y el almacenamiento de archivos multimedia, la puesta al día ordenada tras periodos sin conexión, la preservación de las listas de seguimiento y el cambio de clave en bruto de SQLCipher, sin cambios en MLS ni en el formato de transmisión. La guía de la versión 0.14.0 y la guía de integración de la 0.14.0 exigen que las aplicaciones incluyan un conjunto coherente de bindings, biblioteca nativa y cabeceras, que MarmotKit 0.14.0 empaqueta para Apple y Android. En las plataformas de Apple el binario es un XCFramework estático en bruto, de modo que las aplicaciones lo combinan con el binding de Swift correspondiente y copian su recurso PrivacyInfo.xcprivacy en el producto envoltorio que asignen; superar las comprobaciones de archivo de la versión no demuestra que una exportación para la App Store vaya a funcionar. La base de datos y el almacenamiento migran en un solo sentido y cada página cambia de clave una vez. Las versiones anteriores siguen sin admitirse. Los archivos multimedia de la cuenta y los datos de entrega deberían excluirse de las copias de seguridad. El agente WN sigue en fase previa, y los crates no están en crates.io. Persisten limitaciones conocidas: el historial que llega con más de cinco épocas de retraso se vuelve indescifrable sin aviso. El contenido multimedia perdido en tránsito durante un avance de época sigue sin corregirse; también se mantiene un problema de compatibilidad en el orden del contexto de grupo.

La ascendencia de la etiqueta muestra que la versión estable también incluye cinco cambios de sincronización y multimedia. Al refrescar las suscripciones de grupo solo se reempaquetan las familias de lotes REQ que han cambiado; una familia que falla conserva sus rutas activas para la siguiente sincronización, mientras que el commit parcial sigue informando de una sincronización fallida. Los envíos y los cambios de grupo siguen entrando en la cola duradera cuando falla un refresco previo al envío, aunque su finalización puede quedarse en CompletionUnknown. El REQ de un relay inaccesible sigue pendiente con el mismo ID hasta la reconexión, así que una cobertura degradada no equivale a un historial completo. La aprobación de la reparación durante la incorporación espera a todas las fuentes de descubrimiento y devuelve RetryableFailure cuando una fuente declarada agota su tiempo. La retención opcional de contenido multimedia por cuenta, desde Conservar siempre hasta 30 días, limpia los archivos según la hora de recepción o la última redescarga explícita, no según la última visualización, sin borrar el historial de mensajes. Los hosts deben gestionar el nuevo valor FFI CleanedBySetting.

Después de la etiqueta, el código fusionado continuó el trabajo multidispositivo y de notificaciones push que aún no reivindica ninguna versión. Las solicitudes de historial posteriores a la unión persisten entre commits y reinicios, lo que cierra un hueco entre el Welcome y los mensajes en vivo. Contar los miembros por cuenta evita avisos falsos sobre una persona cuando un segundo dispositivo se une o se marcha, y la gestión de Welcome ignora las entregas destinadas a dispositivos hermanos sin hacer fallar la unión ni consumir una clave. En cuanto a push, MDK difunde por gossip registros y tombstones firmados por el propietario tras los commits sobre un nuevo almacenamiento de gossip para push, vuelve a compartir los tokens tras añadir miembros y notifica a todos los dispositivos de un destinatario, aunque los dispositivos del propio remitente siguen sin recibir notificación. Un relleno aleatorio nuevo en cada disparo impide que la deduplicación suprima los avisos de activación. La publicación de KeyPackages adopta las listas de relays de la propia cuenta y falla, conservando la lista almacenada, si una lista está incompleta o no tiene ningún relay utilizable. Los estados tipados de época obsoleta y de contenido multimedia sin resolver indican a las aplicaciones si deben volver a subir o sincronizar y reenviar, y los cambios de estado de las transferencias llegan de inmediato, con el progreso en bytes agrupado.

El código más reciente de dispositivos por cuenta es un avance hacia una versión futura, no una 0.15 estable. Tres compilaciones nocturnas del 28 de octubre, etiquetadas como solo para pruebas, están fijadas al commit b8d0a49, anterior a fusiones posteriores, por lo que sus recursos no lo contienen todo. MDK selecciona KeyPackages compatibles por dispositivo para un máximo de 20 dispositivos recientes por cuenta, y cerrar sesión retira solo la ranura de publicación de este dispositivo. Los paquetes nuevos duran 30 días más una hora y se renuevan entre seis y siete días después de su publicación. El descubrimiento busca todos los dispositivos, pero los fallos de los relays pueden omitir algunos; volver a invitar puede ayudar, sin garantía de recuperación automática. Las comprobaciones de capacidad autenticadas por hoja sustituyen a la caché por cuenta. Los grupos nuevos exigen el componente de dispositivos por cuenta 0x800d cuando todos los fundadores lo admiten, y los dispositivos actualizados ya lo anuncian. Esos grupos rechazan los dispositivos antiguos que carecen de él, mientras que los grupos existentes no cambian. Bajo ese requisito, MDK rechaza datos de componente, hojas no compatibles, más de 20 hojas por cuenta e intentos de eliminar el requisito, y deja como estaban los grupos heredados y los que no lo exigen. Por otra parte, rechaza los datos iniciales aportados por el host para componentes de aplicación cuyo esquema no tiene datos antes de crear cualquier grupo, Welcome o event.

En los grupos 0x800d, el motor obtiene autoridad para añadir y quitar dispositivos de la propia cuenta, con una clasificación de commits que tiene en cuenta el estado del padre, que distingue entre commits de autoactualización, de autoeliminación, de la misma cuenta y de administrador; el privilegio de la misma cuenta exige propuestas por valor. La gestión de Welcome correspondiente acepta Welcomes de la misma cuenta solo en esos grupos y solo tras comprobar el estado del componente y la firma; los demás grupos siguen necesitando un administrador activo. Las intenciones de envío para añadir y quitar dispositivos de la propia cuenta reciben un turno equitativo en el planificador, pero las API de la aplicación todavía no exponen las intenciones de envío de la misma cuenta. La eliminación de la propia hoja de un dispositivo determina ahora su membresía local, de modo que la presencia de un dispositivo hermano ya no mantiene las acciones de miembro de un dispositivo eliminado.

El gossip de push añade anuncios de kind 447 en cola duradera que contienen prefijos de resumen de 8 bytes de registros y tombstones, enviados al unirse, al cambiar un registro y con una cadencia de mensajes de siete días, y los pares reparan los registros firmados por el propietario que faltan mediante respuestas clasificadas y escalonadas, con supresión de duplicados y un límite de 24 horas por hoja. En la recuperación, cortar y cancelar ya no se inventan pérdidas nuevas, y 24 intentos sin avances aparcan una obligación tras un aviso de historial incompleto. El registro de cobertura solo funciona como registrador en la sombra, mientras que un barrido por franjas de tiempo reanuda franjas empezando por las más antiguas, todavía sin planificador de producción. Los archivos de auditoría opcionales caducan 30 días después de la última escritura, con limpieza al arrancar y cada hora. El borrado puede producirse un día más tarde; el registro de seguridad de revelación de claves, que es independiente, queda excluido de esa caducidad.

Un crate de emparejamiento usa X25519 efímero, un compromiso, una comparación de siete emoji que el usuario verifica en ambas pantallas y confirmaciones HMAC que terminan en un ConfirmedLink. Su adaptador de transmisión cubre solo el transporte y está desactivado por defecto a la espera de una especificación; la interfaz y los trabajos de seguimiento de Welcome y de enlace de grupo están sin terminar, y la interoperabilidad de esta implementación sigue sin verificarse. El código del registro de dispositivos 0x800e aplica actualizaciones diferenciales a un grupo oculto de una sola cuenta, pero anunciar 0x800e requiere una anulación de la política de pruebas, así que las compilaciones de producción aún no pueden crear un grupo de dispositivos ni unirse a uno.

Otras propuestas de MDK siguen abiertas. Una dejaría de tratar la finalización de NIP-67 como prueba de cobertura completa, porque el barrido sin planificar no ofrece ninguna garantía de exhaustividad. Otras añadirían reproducción desde puntos de control, reincorporación automática y activación de 0x800d en grupos existentes. Tres propuestas anteriores de API nativa siguen abiertas según una comprobación reciente de su estado. La recuperación de adjuntos históricos inspeccionaría las ranuras de origen y comprobaría el resumen autenticado y la caducidad antes de escribir los bytes verificados en un archivo privado arrendado, sin que la línea temporal tenga que acceder a la red; una copia entregada es una instantánea que no se puede revocar. Los manejadores de selección de chats a nivel de filtro abarcarían todos los chats que coincidan con un filtro más allá de la página cargada, excluyendo los que lleguen después, y la selección de administradores fundadores para la creación de grupos en wn-agent elegiría a los administradores fundadores invitados y rechazaría a quienes no sean miembros antes de la subida.

nosfry

nosfry, un relay de Nostr escrito en Rust, publicó nosfry v0.2.0 para sus ediciones nativa y Workers/SQL. Incluye funciones que no estaban publicadas en la v0.1: borrado con NIP-09, caducidad con NIP-40, AUTH de NIP-42 con events protegidos de NIP-70, COUNT de NIP-45, sincronización Negentropy de NIP-77, solicitudes de desaparición de NIP-62 y la API de administración de NIP-86. También añade suscripciones acotadas con un presupuesto de salida y una política de escritura, y describe permessage-deflate como activado por defecto. Sus afirmaciones sobre rendimiento y conformidad no se han reproducido de forma independiente, y no afirma interoperar con todas las implementaciones.

Cuatro cambios de refuerzo se fusionaron el 25 de octubre, después de la etiqueta 0.3, y no están en ningún binario publicado. Los cubos de conexiones y de límite de tasa de los workers agregan IPv6 por /64, mientras que la lista de bloqueo de IP de NIP-86 sigue coincidiendo con direcciones exactas (#78), y los escaneos de NEG-OPEN cargan el presupuesto global de memoria de sincronización en pasos de 1024 registros durante la recolección (#73). Los grupos de empate con la misma marca de tiempo mantienen un heap acotado por el límite de la consulta (#72). Las instantáneas de moderación de NIP-86 se aplican a las lecturas almacenadas y a la entrega en vivo tal como se capturaron en el momento de la solicitud, así que una solicitud abierta no recoge al instante los nuevos bloqueos (#68).

Otra fusión, también sin publicar, limita el escritor con un presupuesto de 64 MiB y vacía las colas de publicación pendientes en transacciones más grandes, cada una limitada por el trabajo realizado, sin renunciar a la sincronización duradera de LMDB. Las cifras de rendimiento del proyecto proceden de sus propias variantes de sondeo, no de mediciones nuestras.

nostream

nostream, un relay de Nostr en TypeScript, publicó nostream 3.7.0 y nostream 3.8.0. La versión 3.7.0 incluye las operaciones de administración, los registros de auditoría, los webhooks firmados y las métricas que antes describimos como presentes solo en el código fuente. Añade un ciclo de vida opcional para las escrituras de pago y corrige el análisis de horas ISO y la caducidad para LNbits 1 y versiones posteriores. Se elimina el espejado estático, cuyos ajustes ahora se ignoran con una advertencia en favor de la sincronización NIP-77. La imagen de contenedor de la 3.7.0 no llegó a publicarse porque su etiqueta de Docker contenía un @ no permitido; la 3.8.0 corrige las etiquetas y añade reejecuciones para las compilaciones de imágenes fallidas. La versión 3.8.0 lleva además a la API y la consola de administración listas de pubkeys y kinds, junto con controles de exención de IP y de límite de tasa, con estadísticas sobre los principales publicadores, IP y activaciones del límite de tasa, y corrige una colisión de claves de Redis al cambiar de estrategia de límite de tasa o al actualizar. El código fuente por sí solo no confirma que las imágenes se publiquen ya, y no se afirma que haya facturación desplegada.

Una reescritura en Rust aparte, en la rama rewrite/main, fusionó en 740ef69 su primer núcleo de transmisión capaz de responder a un cliente real, y en 2b2287f el registro de estrategias implementa las 14 ramas de estrategia restantes. Este prototipo, que no es el predeterminado, se mantiene separado de main en TypeScript y de las versiones estables 3.x, y sus resultados de revisión y de CI proceden del autor. La gestión de NIP-43 y NIP-56 sigue desactivada por defecto. Una solicitud de desaparición todavía puede perder una carrera frente a una publicación simultánea, por lo que la desaparición no es una garantía de privacidad. Sigue en pie la petición del autor de una revisión manual del código de acceso e identidad.

swift-nostr

swift-nostr, un SDK de Nostr para Swift, publicó la 0.9.0 el 27 de octubre. La versión añade claves, IDs de event, URL, marcas de tiempo, coordenadas e IDs de suscripción tipados, EventTemplates que cualquier firmante local o remoto puede firmar, errores tipados, suscripciones gestionadas por el pool y enrutamiento RelayRoute a través del pool, de relays exactos o del outbox de NIP-65. Event.verify lanza ahora una excepción ante una firma incorrecta, así que pasar desde la 0.8 requiere cambios en el código. La anterior 0.8.0 fue una versión de refuerzo cuyas notas indican que verifica los events reemplazables, los remitentes de gift wraps y las respuestas de NIP-46 y NWC, elimina duplicados en las respuestas de varios relays y añade cifrado NIP-44 dirigido por el firmante o con clave compartida, con comprobaciones de zap más estrictas como cambio incompatible. Son afirmaciones del autor, no una auditoría.

Las correcciones posteriores a la 0.8 que ya cubrimos llegan ahora con la 0.9.0. Los firmantes rechazan los events cuya clave pública difiere de la suya, y cancelar una suscripción ya no abre un relay desconectado para enviar CLOSE. La llamada de envío principal lanza notConnected y la suscripción conecta de forma explícita, aunque los transportes de NWC y NIP-46 siguen reconectando un relay caído para una nueva solicitud. Las llamadas a NWC y a firmantes remotos obtienen errores tipados y cancelación inmediata, si bien una solicitud ya enviada todavía puede ejecutarse. Los flujos de notificaciones y de desafíos de autenticación de NWC terminan cuando los relays finalizan, las esperas de conexión fallan una vez que terminan todos los flujos de relay y las consultas de tags de los filtros se almacenan una sola vez, con una clave JSON por tag. Un WalletConnectRequest genérico admite métodos personalizados de NIP-47 de respuesta única con las comprobaciones habituales de result_type y de errores, mientras que multi_pay sigue aparte. Un RemoteSignerMethod extensible llama a métodos de NIP-46 ajenos al conjunto integrado y devuelve la cadena de resultado; en ambos casos, el monedero o el firmante deben admitir el método. EventTemplate con signer.sign permite que los firmantes remotos NIP-46 usen funciones auxiliares como las solicitudes de zap, que antes requerían un EventSigner local, con cambios complementarios en varios modelos de datos y en los constructores de NIP-29 y NIP-98. Ese cambio altera la API, no el formato de transmisión.

El código fusionado después de la etiqueta 0.9.0 no forma parte de esa versión. Ahora, cuando un llamador cancela un envío, se conservan los relays sanos, y los tipos de apertura y resultado de DM son más simples, con el autor del rumor vinculado al firmante. FileAttachment unifica los metadatos de archivos cifrados. Un único par setSigner y removeSigner impide que una asignación remota obsoleta deshaga el cierre de sesión; removeSigner detiene las respuestas AUTH, pero no revoca las solicitudes remotas ya enviadas. Los ajustes de reconexión y deduplicación tienen ahora sus propios tipos de configuración.

haps

haps, un instalador de software firmado con claves Nostr, publicó haps v0.1.22. Se apoya en haps v0.1.18, que ejecutaba las compilaciones desde código fuente en Linux y macOS dentro de un directorio personal privado y una copia de trabajo con permisos de escritura, con el acceso a la red desactivado por defecto. Las opciones explícitas allow-build-network y allow-host-build pueden anular este comportamiento. En Windows, las compilaciones desde código fuente requieren host-build. Las aplicaciones instaladas siguen fuera del sandbox. haps v0.1.19 añadió una única confirmación de auditoría e instalación que vincula el código fuente fijado y la receta de compilación con el hash del payload compilado, de modo que un binario del publicador que coincida puede instalarse bajo la política de esa compilación revisada. Reutilizar una revisión de confianza no cuenta como otra auditoría independiente. Las instalaciones desde catálogos firmados inmutables siguen exigiendo una auditoría, y las advertencias publicadas necesitan un consentimiento aparte cuyo valor por defecto es No. La versión 0.1.22 añade búsquedas acotadas y comprobaciones del publicador con código fuente completo. Las búsquedas comparten ahora plazos cortos, con el cliente iniciando las consultas tras conectarse el primer relay, y las búsquedas de instantáneas devuelven los resultados verificados encontrados dentro de un único margen de 3 segundos. Antes de cambiar cualquier referencia de código fuente, la publicación se niega a ejecutarse salvo que encuentre un helper de git incluido y cualificado, un helper instalado por separado que coincida con el binario complementario fijado, o un helper que anuncie complete-blob-dag-v1. Se mantienen la cobertura básica de revisión de dependencias, las protecciones contra enlaces simbólicos y de tamaño y los reintentos acotados, lo cual no constituye una nueva auditoría independiente. Una sola instalación en frío correcta no demuestra que estén resueltos los tiempos de espera intermitentes en las transferencias, y los paquetes de helpers fijados siguen dependiendo de la cadena de herramientas del host.

Swarm protege su API de administración con autenticación NIP-98

Swarm, un servidor de publicación y administración conectado a Nostr, publicó la v0.2.0 con autenticación HTTP NIP-98 para su API de administración, junto a la cookie del panel ya existente. El servidor comprueba la firma del event de kind 27235, una ventana temporal que va de cinco minutos en el pasado a un minuto en el futuro, el método HTTP, la ruta y la consulta, la pubkey fijada del operador y un hash opcional del payload. Aceptar un host reenviado presupone que delante hay un proxy de confianza. El endpoint /environment, antes público, ahora exige autenticación de administrador.

Una fusión posterior, no confirmada en ninguna versión, añade publicación cruzada opcional en X para las notas de kind 1 de los miembros del equipo vinculados. Las notas programadas y las que llegan por WebSocket siguen el mismo camino. Se omiten las respuestas con tags e, no se recupera nada retroactivamente y los duplicados se eliminan por ID de event. En el lado del CMS se usa autenticación NIP-98. La publicación depende de OAuth local o de un servicio delegado de confianza, así que no es descentralizada ni prescinde de la confianza. No se ha probado a publicar en el servicio de producción de X.

fips2go activa enlaces directos con dominios de malla verificados

fips2go, un cliente de malla para Android que encuentra pares y reclamaciones de dominio mediante anuncios de Nostr, publicó las versiones 0.9.6 a 0.10.0. La versión 0.10 activa por defecto enlaces directos con los servidores de hasta los dos dominios verificados más recientemente, contando solo dominios fijados mediante DNSSEC o varios resolvedores. Estos enlaces exponen a esos servidores la dirección IP pública del teléfono y sus horarios de conexión, y revelan a los relays públicos qué servidor ha elegido, aunque los usuarios pueden desactivarlos. Un registro TXT ya fijado para un servidor y puerto exactos se resuelve ahora sin una nueva reclamación de Nostr; en cambio, los servidores nuevos, los puertos cambiados y los registros sin puerto siguen esperando. Si un cambio de red necesita nuevas rutas VPN pero la configuración no ha cambiado, la app sustituye solo el túnel y conserva su nodo, sus enlaces y sus sesiones. Los cambios de punto de acceso, otros cambios de configuración y la recuperación ante fallos siguen reconstruyendo el nodo.

fips-pub-domains responde a las búsquedas fijadas antes de obtener las reclamaciones

fips-pub-domains, que resuelve vinculaciones firmadas con Nostr entre dominios públicos y direcciones de malla, publicó 0.2.9 y 0.2.10. Un registro TXT fijado para un servidor y puerto exactos puede responder ahora antes de que termine la obtención de la reclamación en segundo plano, bajo la misma política de fijación, mientras que un servidor o puerto nuevo sigue esperando una reclamación. Al arrancar el escritorio y tras cambios de red, el resolvedor precalienta hasta 16 servidores fijados, lo que revela su presencia en línea a ellos y a los nodos de enrutamiento. Durante el primer intervalo de espera de 20 segundos reintenta cada tres segundos y termina antes en cuanto responde un servidor.

Dos cambios fusionados después de estas etiquetas no se han publicado. Uno añade un rol ServiceClaim fips-ca sin puerto y con su propia cadena DNSSEC y atestación, separado de fips-dns, sin lanzar una nueva PKI ni cambiar la política de vinculación DNS. El otro añade comandos CLI de verificación y de zona que leen los archivos de fijación sin escribirlos. En este código, una atestación lleva solo su propio testigo anterior, y las demás entradas de rol se vuelven a verificar. Una opción require-previous rechaza los datos ausentes, pero no puede distinguir una caída del servicio de un registro inexistente.

Codr

Codr v0.8.0, un puente para controlar sesiones de programación de escritorio a través de chats cifrados de White Noise, añade una actualización del worker que se confirma en el chat y debe producirse en un plazo de diez minutos. Obtiene registros de ngit de un mantenedor fijado y bytes de Blossom verificados por suma de comprobación, sin recurrir a GitHub como alternativa. Rechaza los cambios de conector o de cohorte de almacenamiento y, si falla el arranque, restaura el ejecutable antiguo. Hasta ahora la actualización solo se ha ejecutado contra fixtures de prueba. Los archivos y contenidos multimedia llegan ahora a una sesión ocupada sin interrumpirla, hasta 25 MiB y cuatro adjuntos. La transcripción opcional con Gemini envía a Google las notas de voz descifradas y está desactivada por defecto. Las versiones 0.4 a 0.7 llevaron el texto del teléfono a sesiones ocupadas, añadieron /cancel y menús de proyecto, agente y modelo, y pasaron a MDK 0.14. La migración desde 0.13 funciona en un solo sentido y requiere una copia de seguridad y aprobación.

Un chat de control opcional exclusivo para el propietario (control_chat=true, desactivado por defecto) crea su grupo en el siguiente arranque del worker. /new inicia una sesión de proyecto antes de que se vincule ningún chat. Si la creación es incierta, no se reintenta automáticamente.

Un pull request abierto, sin fusionar en nuestra fecha de corte de fuentes, permitiría que la creación de grupos para una nueva sesión de programación trate como vacía una transcripción que aún no se ha escrito. Las transcripciones no válidas o ambiguas seguirían rechazándose. Esto restablecería las invitaciones por teléfono para sesiones /new nuevas antes del primer prompt y no cambiaría cómo se autorizan las sesiones.

nostr-media

nostr-media 0.17, un plugin de WordPress para alojar contenido multimedia de Nostr, refuerza la réplica de Blossom. Ahora comprueba la autorización de hash firmada de kind 24242 antes de obtener una URL de réplica y rechaza las solicitudes no autorizadas sin descargar nada. Las descargas usan la API HTTP segura de WordPress, que solo permite hosts HTTP(S) públicos y valida las redirecciones, con un límite de 20 segundos, tres redirecciones y 128 MiB, y los bytes descargados se siguen hasheando y comprobando. Las cabeceras Authorization, X-SHA-256 y X-Content-Type se comparan sin distinguir mayúsculas y minúsculas. La protección contra la falsificación de solicitudes del lado del servidor es tan sólida como lo sea la API segura de WordPress, y no más.

NosTube

NosTube, un sitio de vídeo construido sobre Nostr, publicó server 0.1.25 y desktop 0.2.51 para dejar de confiar en una autoridad de certificación comprometida. El relay en Rust del servidor ya no confía en ella para conexiones WebSocket ni HTTPS, y la construcción de imágenes exige ahora un paquete fijo de CA del sistema de Debian. La versión de escritorio aplica la misma mitigación a su capa TLS y a su sidecar almond. Estas afirmaciones de seguridad proceden de las notas de la versión. Las notas posteriores de server 0.1.27 dicen DO NOT USE (NO USAR) esa imagen porque incluye un libbrotli1 desactualizado, y remiten a 0.1.28, cuya publicación no hemos confirmado.

bitchat

bitchat, un mensajero que funciona sobre malla Bluetooth y Nostr, publicó la 1.8.0 con mejoras de rendimiento para los chats por ubicación de Nostr (geochat) y marcas de tiempo acotadas en los rumores de DM. La app reconoce ahora los mensajes propios del usuario por el ID del remitente y no por el apodo (corrección de identidad del remitente). Los grupos privados fijan a su creador, y el ID de par de la malla queda fuera de los DM por geohash. Las cifras de rendimiento son del propio proyecto y no las hemos reproducido.

Un pull request abierto, sin fusionar en nuestra fecha de corte de fuentes, mantendría conectado el chat geográfico durante las caídas de relays enrutando a través de los cinco relays más cercanos más cinco de respaldo compartidos, con un máximo de diez conexiones por ruta (#1822). Los mensajes se pondrían en cola antes de que se cargue el directorio de relays, y las suscripciones y escrituras pendientes migrarían sin cambio de identidad. La validación es del propio autor, y el cambio complementario para Android es un pull request aparte.

Otro pull request abierto, también sin fusionar, añadiría vídeo en directo sobre la malla Bluetooth de iOS y macOS usando un formato LIVE_VIDEO_V1 propio, no un transporte de Nostr. Los fotogramas públicos irían firmados y con comprobación de frescura. Los fotogramas de DM viajarían dentro del cifrado Noise; las grabaciones se enviarían como mensajes. Según el autor, se recibió una transmisión de Android a iPhone. No se han probado el envío desde un iPhone, las parejas iOS a iOS ni el vídeo en directo por DM.

ngit

ngit, la herramienta de línea de comandos para colaborar con Git sobre Nostr, publicó la v3.0.4. Las conexiones a relays, y también HTTPS en Android, ya no confían en una autoridad de certificación comprometida. Los prompts interactivos se protegen ahora contra entradas en blanco, y los comandos respetan los filtros sin conexión. Las actualizaciones de seguimiento remoto conservan los commits que aún no se han publicado. Además, los diagnósticos distinguen entre una fuente ausente y una consulta que no devolvió resultados.

Hasheus

La herramienta de verificación de archivos antes llamada verify es ahora Hasheus y ha publicado la 2.0.0. Comprueba archivos con hashes publicados en Nostr, y ahora toma descripciones y URL de verificadores de confianza y hashea por bloques los archivos grandes. El aviso de verificado solo aparece con el archivo exacto publicado. También gestiona perfiles malformados, deduplica verificadores y da error si falta un relay. Una suma de comprobación coincidente confirma el archivo, no lo que el publicador afirma sobre él.

Alby JS SDK

El SDK de JavaScript de Alby publicó la 9.0.0. Los clientes NWC conceden ahora a cada solicitud publicada una espera fija de 5 segundos para recibir el OK del relay y fallan con Nip47PublishTimeoutError si no llega, mientras que los tiempos de espera de respuesta por método no cambian. Una respuesta que no se puede descifrar ahora provoca un rechazo, y se conserva el texto de error del relay (gestión de errores de solicitud). El cambio incompatible elimina los métodos multi_* obsoletos, y el código que use Nip47SingleMethod debería pasar a Nip47Method. Un OK del relay significa que el relay aceptó la solicitud, no que un pago se haya completado.

Alby Hub

Alby Hub, un nodo Lightning autoalojado que sirve billeteras mediante Nostr Wallet Connect, publicó la 1.24.4. El parche elimina la confianza en una autoridad de certificación comprometida de sus conexiones TLS nativas de LDK y Go, de las que depende el servicio de billetera NWC del hub. También corrige el arranque del plugin de facturas retenidas (hold invoices) de CLN.

Orchard

Orchard, un catálogo de software Flatpak, publicó la 0.3.0. La versión enlaza la interoperabilidad de versiones de software con NIP-82 y la preparación de recursos Flatpak para publicarlos mediante ngit u otras herramientas NIP-82. NIP-82 es una especificación propuesta de catálogo de software que no ha sido asignada ni aceptada, así que Orchard implementa un borrador que aún puede cambiar.

Bell

Bell, un agregador de conversaciones de Nostr para Android, reúne en una sola lista cronológica las respuestas y citas de varias cuentas. Sus notas de la 0.1.0 excluyen los me gusta, los zaps, los reposts simples y las menciones genéricas, y las cuentas firman a través de Amber o quedan en modo de solo lectura. Las versiones 0.6.0 a 0.9.0 añadieron reglas de silenciado por cuenta y una vista de solo no leídos con selección múltiple para marcar como leído. Según sus notas, la recuperación conserva exactamente las respuestas y reacciones firmadas, sin duplicados automáticos. Con 0.10.0 y 0.10.1, los usuarios pueden ocultar publicaciones concretas en el dispositivo, con opciones para deshacer y restaurar. Ocultar no borra nada de los relays, y las respuestas nuevas siguen apareciendo. Los informes de spam abarcan tanto la publicación como a su autor, se envían públicamente desde una cuenta elegida de forma explícita y no funcionan como bloqueos privados. 0.11.0 añade la posibilidad de repostear después de que el usuario revise la publicación original y la cuenta emisora. El avatar de una cuenta determina quién responde, reacciona o repostea. Poder publicar reposts no significa que las notificaciones de reposts simples se agreguen ahora. Los hilos en caché pueden quedar incompletos, y la escucha opcional en segundo plano depende de las reglas de energía y red de Android, sin ninguna promesa de entrega permanente ni inmediata.

SkateSpots

SkateSpots es un mapa comunitario de spots y tiendas de skate. La versión 1.7.4 añadió un chat comunitario cifrado de extremo a extremo, en el que un bot de la comunidad aprueba automáticamente los dispositivos nuevos y los administradores también pueden aprobarlos. 1.7.0 convirtió el relay de la comunidad en la fuente de referencia para spots y tiendas. 1.7.3 corrigió en Android los códigos QR de invitación al chat privado de crew, introducido en versiones anteriores. Las versiones 1.7.8, 1.7.10, 1.7.15, 1.7.19, 1.7.20, 1.7.21 y 1.7.22 amplían ese chat de crew. A diferencia de la aprobación por bot del chat comunitario, aquí es un miembro existente de la crew quien aprueba los dispositivos nuevos mediante QR; además, se pueden eliminar miembros y dispositivos, y ascender a un fundador vuelve a publicar el tag de administrador. Las reacciones, las lápidas de borrado y los acuses de lectura viajan como controles MLS cifrados. Las lápidas no son borrados definitivos en los relays, y los acuses automáticos solo proceden de firmantes silenciosos. Un vigilante en segundo plano usa la clave propia del miembro, nunca una clave de administrador, y convierte las solicitudes de unión en DM NIP-17 o avisos en la campana aproximadamente una vez por minuto. Para los usuarios de Amber, los avisos de unión esperan hasta que se abre la campana, mientras que los firmantes silenciosos pueden precargarlos, de modo que Amber no recibe solicitudes en segundo plano. Los contadores de no leídos usan los ID de sobres NIP-17 pendientes sin descifrarlos, excluyen las copias enviadas por el propio usuario y no revelan ni confirman ningún asunto. No se garantiza una entrega en segundo plano instantánea ni continua. Las versiones 1.7.19 a 1.7.22 también añaden una búsqueda global en el conjunto de datos que solo se ejecuta mientras la paleta de comandos está abierta, y recuerdan el estado del mapa y de las capas. No hemos probado estos cambios de forma independiente en dispositivos ni los hemos sometido a una auditoría de seguridad.

Emanator

Emanator, un cliente de Nostr multicuenta, puede iniciar ya en la 1.5.0 conversaciones privadas NIP-17, cuando las versiones anteriores solo respondían a hilos existentes. El usuario elige una cuenta emisora con mensajería habilitada y luego busca contactos por nombre o por NIP-05, o pega un npub o nprofile. Se reutilizan las conversaciones existentes, y si el destinatario no declara ninguna bandeja de entrada de DM, la app ofrece una entrega en la medida de lo posible y además una opción heredada. En la 1.4.1. Los reintentos conservan los events firmados ya aceptados. Solo los events antiguos que ningún relay aceptó pueden volver a firmarse y fecharse de nuevo.

Feather

Feather, un cliente de Nostr para Android del que hablamos por última vez en el número 45, durante su serie 0.9, ha llegado desde entonces a la 1.8.4. Las notas de la serie 1.x añaden la exploración y el reporte nativos de incidencias NIP-34 a través de los relays anunciados por un repositorio. Las acciones firmadas esperan ahora en una bandeja de salida en el dispositivo que WorkManager entrega en segundo plano, enviando los mensajes padre antes que las respuestas. 1.8.0 añade publicaciones de imágenes de kind 20 con borradores guardados y entrega sin conexión, y 1.8.4 añade el silenciado opcional tras un reporte correcto. Desde la 1.7.0, la traducción pasa por la app independiente Offline Translator y sus paquetes de idiomas, sin alternativa en la nube.

OUTKAST

OUTKAST, un cliente de Nostr para Android, añade en la 2.2.1 un descubrimiento de Red en el propio dispositivo que muestra notas de cuentas no seguidas a las que personas que sigues dieron me gusta o repostearon en las últimas 48 horas. Según las notas, la clasificación cuenta las reacciones, respuestas y zaps por número (no por cantidad de sats) y después pondera el número de amigos y la novedad, sin servidor de clasificación. Cuando sigues a 40 cuentas o más, una nota necesita al menos dos amigos que la respalden. Los resultados se detienen en 100 notas, sin páginas más antiguas. Las notas también describen feeds personalizados a partir de personas o listas elegidas y un editor de fotos que guarda las ediciones como JPEG sin metadatos, mientras que los originales sin cambios se suben intactos.

CustID

CustID, una app firmante de Nostr, exige ahora en la 0.2.2-beta aprobación biométrica para las solicitudes ASK de NIP-46 en identidades protegidas con biometría, aunque una autenticación reciente puede satisfacer el aviso. Las reglas recordadas de aprobación y rechazo, incluidas las aprobaciones antiguas, se aplican ahora de forma silenciosa tanto en NIP-46 como en NIP-55. Al activar la aprobación automática aparece primero una advertencia de confirmación, y cancelarla no cambia nada. La beta añade además tags de cliente NIP-89 a los events que publica. Vienen activados por defecto y muestran a los lectores qué app publicó un event; un ajuste de Privacidad permite desactivarlos.

Nostr Vault

Nostr Vault, un cliente de Nostr, añade en la 3.0.0 conexiones opcionales entre dispositivos FIPS, emparejados por dirección o código QR, para que un Mac o un teléfono de repuesto en casa haga de bóveda. La bóveda sincroniza notas e historial, obtiene las fotos existentes a través de la malla y, una vez activada la malla, arranca junto con el relay tras un reinicio. Publicar contenido multimedia público sigue requiriendo un servidor multimedia público. La versión también corrige condiciones de carrera entre cuentas relacionadas con los seguimientos y el registro, espera a que los propios relays de escritura del usuario confirmen una publicación antes de informar de que se ha completado, y mantiene los DM de desconocidos tras Solicitudes.

Holoboard

Holoboard, un tablón en el que la gente paga por colocar publicaciones, lanza Android 1.1.0 junto con un flujo guiado de Añadir al tablón en su web y su backend que termina en el pago. Los invitados pueden enviar texto y enlaces o una publicación de Nostr ya existente. Las facturas preparadas se retoman en el mismo perfil de navegador del mismo dispositivo, y el QR de la factura sigue disponible sin cuenta ni billetera conectada. Por sí solo, el APK solo actualiza el icono del lanzador y la pantalla de bienvenida, de modo que los cambios del tablón dependen de la web y el backend correspondientes. No hay inicio de sesión con correo electrónico y contraseña.

Hopp

Hopp, una app de pódcast con boosts de valor por valor, va más allá del trabajo de identidad y pagos de la serie 0.2.x que tratamos en el número 45. La versión 0.3.0 añade sincronización y restauración cifradas entre dispositivos a través de Nostr, sin servidor de Hopp, que abarcan suscripciones, progreso, favoritos, Up Next, hábitos de escucha y ajustes de descarga. La restauración conserva la biblioteca existente, y una vista de estado muestra el estado de los relays y de los elementos pendientes. Según las notas, los repartos de boosts con resultado desconocido están protegidos contra reintentos duplicados, y los presupuestos tienen ahora en cuenta Release Boosting y Boost2Unlock.

Nostrautica

Nostrautica, una app de acompañamiento para eventos, añade en la 0.15.1 paquetes de evento sin conexión que guardan personas, emparejamientos, charlas, la página del evento, publicaciones y fotos de perfil para recintos con poca cobertura. Su chat incorpora nombres en las menciones y ediciones con borrados, y los envíos pendientes pueden reintentarse o descartarse. La versión 0.16.0 pasa a MarmotKit 0.14, una biblioteca de mensajería en grupo de Marmot, para ponerse al día sin conexión con menos conexiones a relays de grupo, y conserva los mensajes no leídos durante la limpieza por retención. La migración del almacenamiento es unidireccional, así que después dejan de admitirse las versiones antiguas de la app. Las notas afirman que no cambia la interoperabilidad con el mensajero White Noise ni con la web.

Staircase

Staircase, una app de chat en grupo de Nostr de relay.tools, añade en la 0.1.25 un modo de notificación Frecuente que comprueba aproximadamente cada 5 o 10 minutos y luego se desconecta. En suspensión profunda es la planificación de Android la que decide los tiempos, así que la entrega en segundo plano no es instantánea ni está garantizada. Los modos Periódico y Frecuente ejecutan una única comprobación acotada cuando vuelve la red, como máximo cada dos minutos; el modo Instantáneo no cambia. El estado de unión a un grupo deja de esperar en cuanto una solicitud se gestiona o caduca, sin indicar cuál de las dos cosas ha ocurrido. Los relays coordinadores personalizados siguen bajo el control del usuario y no se sobrescriben con una lista publicada.

En desarrollo

Coracle

Coracle, un cliente web de Nostr, fusionó una corrección de enrutamiento en master. Ahora, hacer clic en un elemento del menú como Listas o Grupos cuando ese mismo modal ya está en primer plano no hace nada. Antes, cada clic apilaba otro panel idéntico. Escape los cerraba de uno en uno. Los modales distintos y la navegación normal entre páginas funcionan como antes. Se trata de código fusionado, no vinculado a ninguna versión.

nostter

nostter, un cliente web de Nostr, fusionó cinco correcciones en su flujo de zaps. Una respuesta pay_invoice de Nostr Wallet Connect solo cuenta ahora como éxito si tiene el tipo de resultado correcto y una preimagen válida, con el campo de error nulo u omitido. Las respuestas malformadas se rechazan. El cliente rx-nostr dedicado siempre se libera, incluso cuando falla la configuración. Diez segundos sin respuesta de la billetera se tratan como un resultado desconocido, no como un fallo. Los errores de factura y de firma aparecen en línea y conservan el importe y el comentario para reintentar, y los fallos de factura se notifican por separado de los fallos de NWC. El botón de zap sigue habilitado para zaps repetidos. Su marca naranja también aparece cuando se muestra una factura QR, lo cual no confirma que un pago manual se haya realizado. Volver a abrir el diálogo solo lo restablece cuando está inactivo. Cerrarlo después de que lleguen la factura o la firma detiene un nuevo pago NWC, pero un pago ya enviado continúa.

Un pull request abierto mostraría una advertencia para revisar el historial de la billetera antes de pagar mediante la alternativa QR tras un resultado desconocido, y suprimiría la apertura automática de la billetera. Un tiempo de espera agotado no significa que la billetera no haya cobrado nada.

Pollerama

Pollerama, un cliente de encuestas y feed, fusionó una cola de solicitudes por relay. La cola ajusta cuántas solicitudes se ejecutan a la vez, espera más cuando un relay limita la frecuencia, divide los filtros demasiado grandes y normaliza las URL de los relays. La vista de paquetes Míos mantiene ahora una suscripción permanente, de modo que las respuestas lentas de los relays siguen apareciendo. Los problemas conocidos de solicitudes repetidas en la app siguen abiertos, y los mensajes directos no se probaron con este cambio.

Grimoire

Grimoire, un cliente social de Nostr, fusionó correcciones en la sincronización de mensajes directos. El cursor del historial ya no avanza con páginas de relays fusionadas que solo llegan a cubrir parte del pasado, y una protección de cancelación impide que una pasada de descifrado vuelva a llenar los mensajes y los marcadores de visto después de que el cierre de sesión los borre. Un relleno de historial cancelado se detiene antes de mover el cursor o de marcar el historial como agotado. Siguen quedando huecos: un solo relay que responda todavía puede marcar el historial como agotado mientras faltan otros, y una negativa permanente de un firmante sigue haciendo avanzar el cursor.

nostr-vpn

nostr-vpn, una VPN que usa claves de Nostr para descubrir pares, fusionó una corrección de reconexión en móviles. Cuando ya toca una sonda de descubrimiento, el cliente vuelve a activar ahora las rutas agotadas hacia pares conocidos. Solo lo hace cuando no se ha recibido nada recientemente y no existe ninguna ruta conectada o pendiente, y como máximo una vez cada 300 segundos. Las rutas sanas y pendientes no se tocan, y el formato de transmisión no cambia. El autor probó la corrección con un fixture nativo aislado, no en redes móviles. Un segundo cambio fusionado elimina los secretos de unión a la red de los paquetes de doctor, dejando fuera de la salida de diagnóstico el secreto de unión de inscripción y el estado bruto del daemon. La clave privada de Nostr ya se ocultaba ahí. Los paquetes compartidos antes de este cambio siguen expuestos, así que quien haya compartido alguno debería rotar los secretos de unión afectados.

Varios cambios relacionados siguen siendo propuestas abiertas y no se han fusionado ni publicado. En cuanto a los secretos almacenados, una guardaría los secretos de unión a la red en el almacenamiento seguro de la plataforma mediante la ruta de migración existente. Otra limitaría los secretos del sidecar de la máquina en Windows a SYSTEM y Administrators, abarcando los archivos DPAPI que guardan las claves de nodo de Nostr. Esa restricción solo se aplica la próxima vez que se escribe un archivo, y hay un breve intervalo entre la creación del archivo y la ACL. Las rutas de configuración personalizadas no están cubiertas, y el autor no hizo pruebas en una máquina Windows multiusuario. En cuanto a la pertenencia firmada, una propuesta rechazaría las aprobaciones de unión cuya instantánea de la lista de miembros ya no coincida con el disco, de modo que el administrador recargue y reintente, conservando los dispositivos aprobados de forma simultánea. Otra permitiría cinco minutos de desfase en el reloj del administrador y exigiría siempre un firmante de unión configurado, incluso cuando la lista local de administradores esté vacía, manteniendo la vinculación con el secreto de la solicitud. Una tercera desempataría las listas de miembros con la misma marca de tiempo por el hash del artefacto. Los pares que vean ambas listas elegirían la misma lista única; cada una conserva su propio contenido de pertenencia. Una última propuesta exigiría confirmación para las solicitudes de unión mediante enlace profundo y para los proveedores de salida de pago. Los enlaces de unión en macOS y Linux esperarían a un paso explícito de Añadir dispositivo. macOS retendría además los enlaces de proveedores de pago hasta su confirmación. No se demostró su ejecución nativa en ninguna de las dos plataformas. Todos los resultados de las pruebas proceden del autor.

Buzz

Buzz, un relay comunitario con clientes de escritorio y móviles, fusionó trabajo sobre grupos y agentes. Los agentes pueden autenticarse según la especificación JWT NIP-FI del proyecto, que verifica al propietario humano declarado por el emisor; denegar o desconectar a ese propietario termina las sesiones de sus agentes, y la pertenencia del propietario a la comunidad puede dar acceso a un agente. Además, las Huddles aceptan registros verificados de agentes gestionados del usuario actual o del propietario de la Huddle, además del rol de bot con atestación de propietario de NIP-OA. Esta alternativa es una política de compatibilidad y no confía en registros desconocidos de terceros. No es una prueba de identidad. Ninguna de las dos especificaciones es una NIP aceptada.

Los canales de anuncios abiertos pueden admitir invitados de solo lectura mediante join_role=guest, y los canales abiertos no listados quedan ocultos al descubrimiento de quienes no son miembros, pero cualquiera que tenga el ID del canal puede leerlos. Los events de admisión pueden añadir hasta 100 miembros, con posibilidad de éxito parcial. La corrección de los ajustes de canal, de la que informamos la semana pasada como propuesta abierta, ya se ha fusionado: los cambios se confirman en una sola transacción junto con sus solicitudes y avisos. Un cambio fallido de público a privado se revierte por completo, lo que impide que los miembros eliminados reaparezcan a través de esa reversión. En móviles, los fallos de configuración de push ya no rompen la app, que reintenta un número limitado de veces y ofrece recuperación manual; las pruebas se hicieron con canales simulados y el comportamiento en dispositivos APNs no está verificado. Los silenciados sincronizados ya no provocan un arranque en blanco, y ahora se cotejan con las suscripciones push reales de DM; esta corrección se basa en el registro de un único iPhone. En la malla de relays, los registros de pares muertos caducan tras cinco minutos sin latidos, mientras que las conexiones activas quedan exentas.

Las fusiones más recientes no están confirmadas en ninguna versión. Las altas de miembros de kind 9000 se confirman ahora junto con sus escrituras en la lista de miembros: un cambio fallido no guarda ninguna de las dos cosas, y el mismo event firmado puede reintentarse. Los kinds 9001, 9021 y 9022 mantienen el hueco anterior. Los diagnósticos del modo sombra de NIP-FI registran ahora la clave de Nostr verificada y un motivo privado fijo en los casos que se denegarían, sin registrar tokens ni claims. Esto no cambia ninguna admisión ni aplicación de normas. La propia especificación de agentes NIP-AP de Buzz, un documento del proyecto ajeno a las NIP aceptadas, exige ahora un agentType definido por el cliente en los ajustes. Se rechazan los lanzamientos con ajustes de otro tipo, un campo ausente conserva su significado heredado y cambiar el tipo puede descartar los ajustes anidados del tipo anterior. La selección de agente individual falla de forma cerrada ante políticas de agentes gestionados de kind 30177 más recientes que estén malformadas. Los datos más antiguos siguen excluidos. Etiqueta a los agentes con el nombre gestionado por su propietario, mientras que las ilustraciones y los autores de mensajes siguen usando los perfiles.

En móviles, la creación, el listado y el borrado de agentes alojados usan la prueba de propietario NIP-OA y registros de kind 30177 con reintentos duraderos bajo la misma identidad, y guardan las instrucciones privadas en almacenamiento seguro. Su compuerta de alojamiento en tiempo de compilación está desactivada en las compilaciones de App Store e internas, así que esto no supone disponibilidad pública. El arranque en frío con invitación alojada en iOS conserva la intención de invitación, importa una clave coincidente y se recupera desde la copia de seguridad. Solo el autor probó el camino principal, y siguen sin resolver el endpoint alternativo de pertenencia y el registro nuevo. La recuperación del registro de push espera con retroceso exponencial y después sustituye una solicitud guardada rechazada con 401 por un desafío nuevo acotado y una clave App Attest. Conserva las intenciones tras errores 400 o transitorios y trata un 404 corriente con normalidad. Esta recuperación no se ha comprobado en dispositivos reales. Los enlaces a mensajes de canales públicos a los que el usuario no se ha unido obtienen los metadatos de kind 39000 y se abren en modo de solo lectura, mientras que las restricciones de canales privados y DM no cambian. Los enlaces se ponen en cola durante las reconexiones, y una sola búsqueda lenta puede retrasar los enlaces posteriores hasta ocho segundos.

Varios pull requests abiertos seguían sin fusionar en nuestra fecha de corte de fuentes. Una capacidad buzz_v1 desactivada por defecto sustituiría el estado de lectura del lado del cliente por API NIP-98 privadas para el llamador de barra lateral, estado de lectura y cobertura, además de revisiones por persona y pings de invalidación de kind 24300 exclusivos del relay. Los relays sin esa capacidad mantienen NIP-RS, y las bases de datos grandes deben construir antes sus índices de forma concurrente. Los resúmenes de hilos solo analizarían las 1.000 respuestas más recientes, devolverían los 10 autores más recientes y enviarían actualizaciones en directo como máximo una vez por segundo por pod, de modo que no enumerarían a todos los participantes pasados. Las respuestas de los agentes a reacciones se anidarían bajo el mensaje que recibió la reacción, usando el último tag e válido de NIP-25 y recurriendo al ancla anterior como alternativa. Los agentes basados en Hermes obtendrían un shell MCP con alcance de agente para publicar en canales y DM. Se niega a ejecutarse sin su puente y oculta las credenciales, pero la instalación, el reinicio y la publicación real no están verificados. Una corrección del adaptador ACP enviaría los nombres de inicialización de v1 y v2, recurriría a la v1 estable y fijaría la versión principal validada. Esto repara el transporte de agentes y no es un cambio del protocolo Nostr. La función móvil Leer en voz alta usaría el motor de texto a voz del teléfono y omitiría código, enlaces y adjuntos. El motor que elija el usuario determina dónde se procesa la voz. Un generador de carga para relays independiente simularía humanos y agentes NIP-OA y marcaría como fallidas las ejecuciones que superen los límites establecidos de errores y latencia. No cambia ningún código del relay ni demuestra escala de producción.

Mosaico

Mosaico, un daemon que coordina agentes en grupos basados en relays (NIP-29), fusionó la presencia basada en latidos. Ahora un agente solo cuenta como presente en un canal mientras publique un event de estado con una marca de tiempo de expiración (NIP-40) fijada 90 segundos en el futuro y renovada cada 30 segundos. Un proceso que se ejecuta localmente ya no cuenta por sí solo como presencia. La pertenencia se mantiene mientras un agente está desconectado, para que pueda reanudar. Un modelo de lectura de grupos reconstruido se construye una vez por cada cambio de relay con un cursor canónico de llegada, de modo que el chat ya no se pierde cuando se sustituye una suscripción amplia de grupo.

Tres fusiones posteriores no están confirmadas en ninguna versión. Las suscripciones de sustitución usan ahora ID de REQ nuevos y se abren antes de cerrar la anterior. Un perfil retirado se publica fuera del camino crítico para la latencia, y un agente que abandona un canal retira su presencia aunque siga siendo miembro NIP-29. Las sondas que lo respaldan son del autor, no mediciones nuestras. La contabilidad de reintentos con reclamación previa se guarda de forma duradera en el esquema 27 y sobrevive a la reproducción del relay. Aplica un retroceso exponencial de 30 segundos a una hora con un único temporizador en serie y desiste tras 10 fallos. Un event ausente no se trata como un borrado y, como la ventana retenida contiene 4.096 entradas, no se garantiza la entrega de todos los events. Las instantáneas exclusivas de grupo despiertan ahora a los consumidores de grupo, y las sustituciones con marcas de tiempo iguales conservan el ID de event más bajo, como especifica NIP-01. Los cambios que solo afectan al contenido siguen despertando al consumidor general. Una alternativa acotada para un mensaje padre ausente puede esperar al siguiente cambio de grupo o a un tiempo de espera de 15 segundos.

Sonar

Sonar, un mensajero que combina Nostr, cifrado MLS y malla Bluetooth Low Energy, fusionó una corrección de arranque para conexiones móviles. El PR atribuye la lentitud del primer pintado a que la conexión al relay de push retiene un bloqueo del almacén. En Android, el arranque omite ese bloqueo cuando el nodo local ya está abierto, como ocurre cuando el registro de push lo abrió antes del arranque en frío. En iOS, la app indica a la extensión del servicio de notificaciones que deje de conectarse y de vaciar la cola para que la app pueda renderizar.

Shopstr

Shopstr, un mercado de Nostr, fusionó el soporte para borrar anuncios que se propuso la semana pasada. Una solicitud de borrado de event (NIP-09) firmada por un vendedor elimina ahora el anuncio de la caché y lo marca con una lápida, de modo que un artículo borrado no puede reaparecer ni comprarse desde la caché, mientras que las nuevas publicaciones del anuncio siguen mostrándose. Algunos borrados todavía se pierden: un borrado que llega antes que su anuncio se ignora, las solicitudes antiguas sin tag k no coinciden con la consulta al relay y los borrados pasados no se recuperan retroactivamente. Los relays también pueden conservar los events borrados. Por otra parte, los mensajes con envoltorio de regalo malformados ya no bloquean las vistas de Pedidos y Mis anuncios, y los vendedores pueden ver ya sus propios pedidos, mientras que otros usuarios siguen recibiendo un 403.

Tres pull requests abiertos, sin fusionar en nuestra fecha de corte de fuentes, se centran en la integridad de los pedidos. #665 registraría una sola vez los participantes de cada pedido mediante un registro NIP-98, tomando al comprador de la autenticación y al vendedor del anuncio firmado, y las escrituras posteriores no podrían cambiarlos. Un registro fallido no detendría el proceso de pago, y los pedidos nuevos sin resolver no se deducirían a partir de los tags. Los pedidos heredados solo quedan cubiertos hasta una fecha de corte limitada, y sigue sin corregirse un hueco en cómo se almacena el estado por ID de pedido. #666, que depende de #665, aplicaría los mensajes de estado de pedido con envoltorio de regalo (NIP-59) solo cuando procedan del comprador o vendedor registrado del pedido, y no de cualquier remitente autenticado. Los pedidos sin resolver quedan pendientes, la confirmación del comprador tras el pago no cuenta como confirmación del vendedor, y los mensajes falsificados quedan como chat sin cambiar el estado del pedido. #664 leería los metadatos de token de keysets v2 de Cashu para el registro de custodia y las resoluciones sin consultar el keyset por red, y corregiría la suma de pruebas. La decodificación de tokens al crear pedidos sigue necesitando una corrección aparte.

Conduit

Conduit, un mercado de Nostr con apps emparejadas para compradores y comerciantes, fusionó un único registro de cuenta cifrado. Los metadatos de la billetera, la semilla, la identidad nativa, la dirección, las preferencias y el progreso de configuración residen ahora en un solo registro de datos arbitrarios de apps personalizadas (NIP-78), cifrado con payloads cifrados versionados (NIP-44) y comprobado en cuanto a firma, propietario e identidad derivada; ambas apps lo encuentran una vez que el firmante da su aprobación. La transición no es retrocompatible: se ignoran las rutas antiguas de copia de seguridad y recuperación, y las copias de seguridad heredadas permanecen donde están sin migración automática. Otras fusiones añaden el inicio de sesión con un nsec existente, guardado en el almacenamiento local del navegador, exigen condiciones de envío firmadas exactas al editar familias de productos y trasladan la recuperación del proceso de pago a IndexedDB, con una relectura antes de marcarla como guardada.

Conduit también pasó a NWC SDK 8.1.1, que aporta sus correcciones de validación de importes, intentos de conexión acotados, gestión de pools cerrados y respuestas en curso. La elección de billetera, el cifrado y la política de pagos de Conduit no cambian. El despliegue de la app sigue sin confirmarse. Dos pull requests en borrador seguían sin fusionar en nuestra fecha de corte de fuentes. La activación de pagos persistiría, releería y entregaría el estado del pago dentro de una ventana de ejecución fija de dos minutos que los reintentos no reinician. Los recibos de Nostr, la recuperación privada de la cuenta y los cambios de stock o de cumplimiento de pedidos necesitarían cada uno su propia prueba firmada por separado. Conservados durante las 24 horas posteriores, los recibos no restauran la autoridad de pago, y las comprobaciones con fondos, en dispositivos y por parte de los mantenedores siguen pendientes. Los productos exclusivos de eventos marcarían los anuncios NIP-99 de kind 30402 como ocultos con una extensión conduit_event_only. Quedarían fuera del catálogo normal y del proceso de pago, y necesitarían una asignación exacta y autorizada a una edición del evento. Los datos firmados ocultos siguen siendo públicos, y otros clientes solo admiten el indicador de oculto estándar.

LNbits

LNbits, el servidor de billeteras y cuentas Lightning, fusionó una opción para enviar sus notificaciones de Nostr como mensajes privados NIP-17. Los administradores pueden elegir entre los mensajes cifrados heredados de NIP-04 y los mensajes directos privados de NIP-17, que son la opción por defecto en las configuraciones nuevas. Para NIP-17, el servidor busca la lista de relays de bandeja de entrada de DM del destinatario, usando los relays de NIP-05 como pistas de descubrimiento y como destino cuando no existe ninguna lista. Si hay publicada una lista vacía, el envío falla. Cada envío está limitado a 30 segundos y necesita que al menos un relay de bandeja de entrada lo acepte, y nunca recurre a NIP-04.

Zeus

Zeus, la billetera móvil de Bitcoin y Lightning, incluyó su corrección de la contabilidad del presupuesto de Nostr Wallet Connect cuando falla la actualización posterior al pago en la versión preliminar v13.2.4-rc1, junto con la corrección anterior que hace que make_invoice de Nostr Wallet Connect devuelva su propia factura. Antes de la corrección, un error de actualización después de un envío NIP-47 se saltaba la contabilidad del presupuesto y devolvía un error para un pago que podía haberse completado. Ahora, una preimagen devuelta descuenta el presupuesto mediante la alternativa existente, y un tiempo de espera agotado retiene el importe como gasto pendiente aunque el pago no aparezca en la lista. Puede que persistan otros huecos, incluidos los pagos LND en curso. A continuación llegó v13.2.4-rc2, solo con actualizaciones de dependencias.

Desde entonces se han fusionado en el código fuente dos correcciones más recientes, que no están confirmadas en ninguna de las dos candidatas a versión. La corrección de la caducidad predeterminada hace que el decodificador BOLT11 local aplique la caducidad predeterminada que fija la especificación, de 3600 segundos, cuando una factura no tiene campo de caducidad. Esas facturas se trataban como si nunca caducaran, de modo que no se aplicaba la comprobación que impide pagar facturas caducadas, y la validación de facturas NWC en NostrConnectUtils tenía la misma laguna. La corrección de las copias de seguridad por monedero restablece para cada monedero de ecash la marca de tiempo de la copia de seguridad de mints en Nostr. Antes de esta corrección, un monedero recuperado desde la semilla en la misma sesión que otro monedero de ecash podía heredar la marca de tiempo de este último. En ese caso podía descartar sus propias copias de seguridad más antiguas en los relays por considerarlas obsoletas y guardar una lista de mints vacía, lo que desactivaba la restauración automática. Una copia de seguridad que termine después de un cambio de monedero todavía puede escribir su marca de tiempo bajo el monedero equivocado. Los monederos ya afectados conservan la lista vacía guardada y necesitan la restauración manual en Mint sync, o bien volver a añadir las URL de sus mints. Su ecash sigue en el mint. Ambas pull requests indican que no se hicieron pruebas en dispositivos.

npub.cash

npub.cash recibe pagos Lightning para identidades de Nostr y los convierte en ecash de Cashu. Ha fusionado un cambio en el servidor que publica los recibos de zap en los relays que solicitó el pagador. El servidor ya analizaba los relays indicados en una solicitud de zap, pero los ignoraba al publicar los recibos pagados. Ahora los recibos van a esos relays cuando la solicitud indica al menos uno, mientras que las solicitudes sin lista de relays o con una lista vacía siguen usando los relays predeterminados configurados.

eHagaki

eHagaki, un cliente web de Nostr que también se distribuye como Web Component integrable, publicó las versiones 1.31.0 y 1.31.1. La versión 1.31.0 añade reposts (NIP-18), reacciones (NIP-25) y gestión de los archivos multimedia subidos, resuelve el enrutamiento outbox (NIP-65) antes de que un event pase a un firmante externo y puede guardar el historial de publicaciones y una caché en un relay Citrine local. Su migración de IndexedDB restablece el historial de publicaciones que se muestra localmente, pero conserva los borradores y las solicitudes de eliminación guardadas; el historial que guardan los relays se puede volver a descargar, mientras que las publicaciones que solo existen en local necesitan una copia de seguridad o una exportación antes de actualizar. La versión 1.31.1 sincroniza los servidores de subida NIP-96 mediante el kind 10096 junto al kind 10063 de Blossom, conserva los ajustes parciales de relays que sean utilizables e incluye las correcciones de la lista de servidores de subida y de la sincronización de servidores multimedia. La obtención de la lista de servidores de subida a través de los relays de lectura declarados conserva la lista más reciente con firma válida aunque otros relays agoten el tiempo de espera, y deja los ajustes sin cambios cuando no llega ninguna. La sincronización de servidores multimedia trata por separado las preferencias de Blossom y de NIP-96 y nunca publica una lista recortada tras una consulta fallida.

Otras correcciones de fiabilidad ya fusionadas aún no están confirmadas en ninguna versión. Tras un error 401 o 403, los usuarios pueden registrarse en los servidores NIP-96 yabu.me o nostrcheck.me desde la pantalla de archivos multimedia; la firma NIP-98 cubre la URL real del POST y el hash del cuerpo, los cambios de cuenta o de destino cancelan la solicitud, una protección impide los envíos dobles y las solicitudes de resultado desconocido no se reenvían. eHagaki nunca proporciona una contraseña, y los pasos de código de invitación o de pago se realizan en el sitio oficial del proveedor. Las listas grandes de archivos de Blossom se paginan con un tamaño de página de 24 elementos a partir de una instantánea local acotada, rechazan las respuestas de más de 8 MiB o de 10.000 entradas y descartan la instantánea si cambia la cuenta, la sesión o el servidor; llegar al final significa que la instantánea se ha agotado, no que el servidor no tenga más archivos. La recuperación del firmante remoto NIP-46 reconstruye la conexión y, pasados 30 segundos, rechaza explícitamente las solicitudes pendientes antiguas sin reenviarlas. Las subidas al servidor Blossom de Primal codifican la autorización firmada existente en Base64 estándar con relleno, mientras que los demás servidores mantienen Base64URL.

Dos fusiones más recientes tampoco están confirmadas en ninguna versión. La publicación comparte ahora esperas acotadas y verificadas de las solicitudes a los relays y mantiene la entrega y el progreso ligados a la sesión, en sustitución de varios temporizadores independientes. El primer acuse de recibo válido de un relay cuenta como éxito, mientras continúa la entrega a los relays restantes. En ningún momento el progreso afirma que se haya entregado a todos los relays, y cambiar de cuenta o cerrar sesión detiene la entrega en segundo plano. El historial de publicaciones puede actualizar bajo demanda las respuestas, reacciones y eliminaciones relacionadas con un límite de tres segundos. Tras un agotamiento parcial del tiempo se conservan los resultados ya recibidos, y una eliminación que no llega no se toma como prueba de que no exista ninguna.

Formstr Drive

Formstr Drive, una aplicación cifrada para compartir archivos construida sobre Nostr y Blossom, fusionó su trabajo de recuperación de DriveKey, del que ya informamos cuando era una propuesta abierta. La aplicación lee todos los relays accesibles antes de escribir un llavero combinado, de modo que las claves antiguas convergen a medida que se hacen visibles. Solo crea una clave nueva cuando dos de los cuatro relays de la aplicación no devuelven nada y no hay historial ni versión. Un relay de escritura que no responda todavía puede ocultar una clave antigua durante un tiempo, y las compilaciones anteriores no pueden leer el nuevo formato JSON.

El proyecto también mantuvo separados los archivos descifrados, los elementos compartidos, las carpetas y la bandeja de salida de cada cuenta. Al cambiar de cuenta se bloquean las firmas e importaciones pendientes de la cuenta anterior, aunque un blob preparado puede quedar sin referencia. Las cuentas nuevas deben elegir ahora explícitamente un servidor de subida, sin conmutación por error silenciosa, mientras que se conservan los valores predeterminados automáticos anteriores. El servidor sigue viendo la pubkey, el momento de las subidas y los bytes cifrados. Los avisos de duplicados exigen ahora bytes activos idénticos en el mismo servidor y la misma carpeta. Las rutas de Android para la separación de cuentas y la confirmación de duplicados no se han probado, y no hemos confirmado que nada de esto esté en una versión publicada.

diVine

diVine, un cliente de vídeos cortos para Nostr, fusionó cambios en mensajería, cuentas y retos. Sus primeras versiones beta solo tienen notas genéricas, así que nada de esto consta en compilaciones distribuidas. Las instantáneas de cuenta cifradas por campo sincronizan preferencias, decisiones sobre insignias y descartes, reintentan localmente los cambios pendientes y bloquean la publicación insegura cuando las lecturas están incompletas. Los marcadores de lectura de los DM mantienen el protocolo existente, la lectura de notificaciones usa la API del servidor y marcar todo como leído requiere conexión; los permisos del sistema operativo, las credenciales y el consentimiento de edad permanecen en el dispositivo.

En los DM, el editor y la hoja para compartir se cierran en cuanto un mensaje queda en cola de forma segura; la entrega en segundo plano no se ejecuta mientras la aplicación está cerrada, y la entrega solo cuenta tras el acuse de recibo del relay. Los reintentos fallidos cuentan de forma coherente para el límite de intentos. Los mensajes NIP-04 heredados con forma no válida se descartan y se registran en un libro de registro, aunque las burbujas vacías almacenadas permanecen y no está establecida la compatibilidad con firmantes externos y otros dispositivos. Las vistas previas difuminadas opcionales para DM de vídeo de remitentes de confianza están desactivadas por defecto y siempre se difuminan con una advertencia de contenido; el vídeo se descarga igualmente, por lo que el difuminado no aporta privacidad de red. En los grupos, bloquear a un miembro solo oculta sus mensajes; una advertencia indica que esa persona sigue recibiendo los tuyos. La salida de una sala queda guardada de forma persistente. La creación de grupos nuevos sigue detrás de un indicador desactivado por defecto. Estos cambios se aplican a los grupos existentes; la revisión de confianza y seguridad está pendiente.

Se fusionaron dos funciones que antes estaban abiertas. El almacenamiento en caché de los vídeos recibidos por DM conserva los archivos descifrados por cuenta durante un máximo de 30 días o 300 MB; la carga automática en chats de confianza y de usuarios seguidos revela al servidor multimedia el momento de visualización, y los vídeos de desconocidos requieren un toque. Una retirada en el servidor no revoca de inmediato los bytes en caché, que pueden desalojarse antes. La consulta de propiedad de nombres de usuario comprueba el directorio NIP-05 del servidor de nombres en las búsquedas de identificadores de Divine de la primera página y solo fija a un propietario activo; los nombres consultados aparecen en los registros del servidor, y esto no es una validación general de NIP-05.

Las listas de personas pasan a disponibilidad general, sobre la base del trabajo combinado de descubrimiento y gestión. Los enlaces de apoyo en el perfil están activados por defecto, y el editor espera a una lectura estricta del kind 0 en bruto desde todos los relays, conservando los proveedores ocultos y las ediciones sin guardar; aún no se han producido la promoción en las tiendas ni el despliegue del backend. Los tags de atribución del cliente siguen la preferencia NIP-89 vigente en los reintentos y en las ediciones de metadatos, y eliminan el tag de un cliente ajeno antes de firmar, mientras que las publicaciones programadas ya firmadas nunca cambian. Los enlaces cortos externos autenticados, desactivados por defecto, firman el POST NIP-98 exacto y su cuerpo en un plazo de dos segundos y recurren a las URL canónicas, que los DM y los events de Nostr conservan siempre; la creación en la pasarela está desplegada pero desactivada, con controles de despliegue pendientes.

Los creadores pueden permitir la reutilización de un vídeo público mediante un tag explícito, desactivado por defecto y bloqueado en el momento de publicar si se usa audio con licencia sin obras derivadas; se trata de una convención del cliente, no de DRM. El trabajo sobre retos, solo de prueba, abarca una base de protocolo firmada, la firma de participaciones con comprobaciones de reglas y consentimiento, el almacenamiento duradero por cuenta y flujos nativos de revisión y retirada en compilaciones de prueba especiales. El acuse de recibo de un relay no significa la aprobación del organizador. En producción, el descubrimiento está desactivado. Quedan pendientes la entrega del backend, las pruebas de aceptación con cuentas reales y una secuencia de lanzamiento coordinada entre clientes.

Otras fusiones más recientes tampoco están confirmadas en ninguna versión. Cuando no se puede leer la bandeja de entrada de DM de kind 10050 del destinatario, la cola de envíos retenidos de NIP-17 reutiliza ahora el ID del gift wrap del destinatario que un relay ya aceptó, con lo que esa identidad del wrap se mantiene entre reintentos. Si un reintento encuentra la bandeja de entrada, el cliente puede volver a publicar en los relays anunciados. Si no aparece ninguna bandeja, se queda con la copia aceptada y confía en que los relays la conserven. Los mensajes todavía pueden aparecer como Failed. Sigue sin demostrarse la entrega al destinatario o su lectura; los reintentos de reacciones y eliminaciones quedan fuera de este cambio. La precarga de notificaciones públicas y la actualización de la zona horaria usan una caché de miniaturas acotada y un índice SQLite compartido, y excluyen los DM y las campañas. Necesitan una versión nativa normal más un cambio coordinado en el servicio, y no se garantiza la ejecución en segundo plano. El editor de vídeo gana cinco transiciones, hasta un total de 20, renderizadas de forma nativa en la vista previa y en la exportación. En el modo de movimiento reducido se limitan deliberadamente las miniaturas de vista previa. El espaciado del destello puede recurrir a un fundido. No probamos la implementación nativa en condiciones reales.

Cuatro pull requests abiertas seguían sin fusionar en nuestra fecha de corte de fuentes. Los stickers sociales para vídeo, apilados sobre el trabajo anterior de stickers informativos, escribirían tags de sticker pequeños y planos con metadatos de mención (p), hashtag (t) y enlace (r). El reproductor superpondría zonas pulsables y avisaría antes de abrir enlaces externos. Los demás clientes solo ven los stickers incrustados en el vídeo, salvo que implementen los tags, que no forman parte de ningún NIP aceptado. Las menciones en los chats de Concord ocultos tras un indicador mantendrían las identidades dentro de mensajes cifrados y autenticados. Las alertas dentro de la aplicación solo procederían de remitentes seguidos y no bloqueados en salas que el usuario haya abierto, con un máximo de 50 filas y el estado de lectura guardado. No activarían notificaciones push del sistema operativo ni un despliegue público del chat, y las comprobaciones de colisión de identidad, repetición y bloqueo solo están cubiertas por pruebas acotadas. Los tags de rumor de NIP-17 nombrarían una sola vez al autor de la reacción con el kind real, y las eliminaciones envueltas dejarían de incluir tags p engañosos. Los gift wraps ya iban a los destinatarios correctos, así que esto no corrige ninguna filtración de destinatarios. Los rumores ya en cola no cambian, el comportamiento en otros clientes no se ha probado y persiste una contrapartida en la clasificación por salas. La próxima compilación nativa activaría por defecto el uso compartido mediante enlaces cortos ya existente, mientras que la versión web lo mantiene desactivado. Las rutas de función desactivada, sesión cerrada y error conservarían las URL canónicas completas. No están demostradas la distribución en tiendas, la preparación del servicio ni las comprobaciones en dispositivos.

rust-nostr

rust-nostr, un conjunto de bibliotecas del protocolo Nostr en Rust, fusionó un cambio incompatible en la forma de volver a emitir las suscripciones. SubscriptionData muestra ahora el estado EOSE actual de cada relay. Al volver a emitir una suscripción se ponen en cola el CLOSE y el REQ con el filtro almacenado en un único paso atómico, incluso sin conexión, lo que garantiza cómo se encolan, pero no que ambas tramas lleguen al relay. Recuperarse de un hueco en las notificaciones ya no elimina en silencio una suscripción ni envía una solicitud duplicada. Los mensajes EOSE tardíos o los events del REQ anterior todavía pueden solaparse con el nuevo, porque nada en la transmisión permite distinguirlos. Se trata de código fuente fusionado, y no hemos confirmado que esté en una versión publicada.

nostr-sdk-ffi

nostr-sdk-ffi, los bindings que permiten usar el SDK de rust-nostr desde otros lenguajes, fusionó el acceso directo a las claves de conversación de NIP-44 v2, de modo que los hosts de Concord ya no necesitan incluir su propio código de ECDH y HKDF. Es una capa fina sobre la derivación existente y no añade criptografía nueva. El autor informó de una compilación en Python y de una prueba de ida y vuelta que obtenía la misma clave desde ambos lados, pero no añadió pruebas unitarias específicas. Por ahora solo es código fuente fusionado.

NDK

NDK, un kit de desarrollo de Nostr para Dart, publicó 0.11.0-dev.2, una versión preliminar con cambios incompatibles. No es una 0.11.0 estable y no tiene relación con el NDK de JavaScript. La versión añade NIP-49 claves ncryptsec cifradas con contraseña, con una interfaz de ejemplo. Sus notas dicen que el descifrado acota logN, rechaza bytes de seguridad desconocidos y pone a cero los búferes derivados; estas afirmaciones se basan en las notas y en el código fuente fusionado, y no hemos visto ninguna auditoría independiente ni una ejecución con vectores de prueba. Las solicitudes informan ahora de un resultado notSent que incluye el fallo de conexión o de envío, y las solicitudes a relays inaccesibles terminan en cuanto ningún relay o filtro restante puede responder, sin esperar a que se agote un tiempo de espera. Las difusiones comprueban que haya un firmante antes de marcar un event como en curso, los ID de las solicitudes de zap usan el created_at almacenado, y los metadatos de relay de NIP-11 se obtienen bajo demanda a través de una caché compartida, por lo que ya no bloquean cada sincronización.

La versión preliminar también incluye cambios que antes solo estaban en el código fuente. Las listas NIP-65 que repiten una URL de relay ahora se combinan correctamente, uniendo los marcadores de lectura y escritura y conservando el conjunto de relays de escritura del outbox; el autor encontró 5 listas mal interpretadas entre 932 perfiles en una única observación. Una comprobación previa opcional de subida BUD-06 pregunta al servidor, con la propia autorización de la subida, si aceptaría un blob, e informa del estado y del motivo, como ahora hacen también los rechazos de subidas reales. Un 404 significa que se desconoce si hay soporte, y superar la comprobación no garantiza que la subida vaya a funcionar. Un cambio incompatible en los tiempos de espera de la reconciliación NIP-77 divide el tiempo de espera único en tiempos de apertura e inactividad con un error tipado, sin contar el tiempo que se pasa esperando la autenticación. No hay un plazo global, así que una sincronización que siga avanzando puede ejecutarse indefinidamente, y no hemos visto que el cambio se haya verificado con un relay real.

Las pull requests abiertas proponen caché de NIP-05 indexada por identificador con caché negativa, una API de caché que devuelve ID y marcas de tiempo para NIP-77, gestión de la disponibilidad del WebSocket, campos completos de NIP-11 y finalización cuando se rechaza una conexión. Otra propuesta, que seguía abierta en una comprobación de estado reciente, permitiría crear y recuperar cuentas con passkeys de la plataforma en navegador y Flutter, siguiendo un borrador de diseño de identidad con passkeys que tiene modos de clave derivada y almacenada además de metadatos heredados explícitos. Los identificadores desconocidos se rechazan y nunca se tratan como una cuenta nueva, y la recuperación debe verificarse de forma independiente antes de conservar un registro almacenado. El autor señala que no se ha validado la interoperabilidad con todos los proveedores de passkeys.

Applesauce

Applesauce, un conjunto de bibliotecas de TypeScript para Nostr, tiene nuevos cambios en el código fuente con changesets, y no afirmamos que haya una versión correspondiente. Los clientes de mensajería independientes y la autenticación explícita con relays añaden clientes NIP-04 y NIP-17 para una cuenta fija que hacen solicitudes de autenticación NIP-42 explícitas y reintentan envíos firmados ya preparados. Las conversaciones envueltas y los almacenes de rumores con ámbito exponen rumores de kind 14 y modelos de hilos sin iniciar trabajo del firmante ni de red. El descifrado está desactivado por defecto, los envíos envueltos necesitan relays de kind 10050 para todos los participantes, incluido el remitente, y la aceptación por un relay no equivale a la recepción por el destinatario. La restauración acotada de la caché de contenido descifrado usa por defecto una concurrencia de 8, lo que puede reordenar los events salvo que se fije en 1. Las aplicaciones deben delimitar y cifrar ellas mismas esas cachés de texto en claro. A continuación llegan el transporte NDR y un cliente coordinador Cordn independiente. NDR debe persistir su propio estado de ratchet por separado, y Submitted significa entrega local, no recepción por el destinatario. Cordn solo se ocupa del transporte, está aparcado en el ejemplo y no implementa MLS. La integración de Kehto ContextVM por ventana da a cada ventana de napplet una identidad ContextVM efímera, sin autenticación de cuenta ni pagos. Con los depósitos duraderos propiedad de la aplicación y la recuperación de nutzaps, los nuevos depósitos y canjes del monedero requieren un almacén de recuperación proporcionado por la aplicación consumidora y la restauración NUT-09 del mint. El diario persiste pruebas gastables, secretos y factores de cegado, por lo que debería cifrarse y delimitarse por cuenta. La reanudación solo se ejecuta cuando se invoca explícitamente, reutiliza los ID firmados y conserva el diario hasta que haya una aceptación positiva por parte de un relay, y cancelar no invalida la factura. Las instantáneas de cronología agrupadas con estado síncrono del monedero agrupan las actualizaciones de la cronología en ventanas de 16 ms, mientras el estado de los tokens del monedero sigue siendo síncrono. El planificador de solicitudes COUNT, propuesto la semana pasada, ya se ha fusionado. Empieza en 8 bajo un límite de concurrencia y lo duplica hasta el primer error de límite de tasa o de transporte, y cada error reduce el límite a la mitad y añade un periodo de enfriamiento. Los tiempos de espera agotados aparecen como CountFailure sin reducir el límite. La latencia solo orienta la elección de relays; la prueba de rendimiento con tres relays sigue siendo insuficiente para hacer afirmaciones generales sobre el rendimiento.

eventstore

eventstore, la biblioteca de fiatjaf con backends de almacenamiento para events de Nostr, fusionó dos correcciones de consultas. No se ha verificado ninguna versión etiquetada que las contenga. Todos los backends siguen ahora la regla de NIP-01 para las listas de filtro vacías: una lista vacía de ids, authors, kinds o tags no coincide con nada, mientras que una lista de tags ausente (nil) sigue sin imponer restricción alguna. Una corrección del recuento de events en LMDB hace avanzar el cursor de HyperLogLog tras una coincidencia, de modo que los recuentos ya no se quedan colgados para siempre. Además, el recuento ya no aplica comprobaciones de autor, kind o tag cuando el filtro no las incluye, algo que hacía que devolviera cero.

zsp

zsp, la herramienta de línea de comandos de Zapstore para publicar aplicaciones Android en Nostr, publicó la versión 2.0.0. El README de esa etiqueta ofrece un asistente con el que una persona demuestra la propiedad del certificado de firma C1, y un comando zsp skill que da instrucciones de publicación a los agentes. Prohíbe entregar a los agentes el almacén de claves, su contraseña o cualquier clave privada, de modo que la prueba sigue en manos humanas. La versión también detecta los almacenes de claves JKS y PKCS12 por su contenido, así que los almacenes PKCS12 con nombre .jks o .keystore se cargan tanto en el asistente como en la ruta de publicación. No probamos a publicar con ella.

nsite-gateway

nsite-gateway, que sirve sitios web estáticos publicados en Nostr, publicó la versión 3.6.6. El cambio en el código fuente actualiza a Applesauce 7 y restablece la caducidad de los events. Las versiones anteriores sustituían deliberadamente el gestor de caducidad por uno desactivado para evitar un fallo de limitación de temporizadores en el proyecto original, por lo que los events de sitios caducados podían seguir activos indefinidamente en el almacén de la pasarela. Con la corrección original ya aplicada, la pasarela vuelve a usar el almacén de events normal. Aquí la caducidad determina lo que la pasarela conserva y sirve, y no elimina events de los relays ni de cachés de terceros. No probamos ninguna pasarela desplegada.

44billion

44billion, un lanzador de aplicaciones de Nostr, cambió la forma en que recuerda los permisos. Las concesiones guardadas quedan ahora ligadas a la aplicación, el nombre del permiso, el kind del event y el ámbito, y una concesión comodín de kind -1 ya no autoriza kinds concretos. Los ámbitos solo son granulares para los pares de kind y ámbito registrados que tienen etiquetas traducidas; los ámbitos desconocidos recurren a un ámbito vacío que abarca todo el kind, y el registro empieza vacío. La versión 5 del esquema de IndexedDB restablece intencionadamente las concesiones de la versión 4 y elimina al arrancar las concesiones con ámbito no admitidas, conservando el resto de datos de las aplicaciones. La API personalizada de cifrado personal incluye funciones auxiliares al estilo de NIP-44 v3 que no son un estándar aceptado. Se trata de un cambio en el código fuente sin versión ni despliegue identificados.

Código fuente más reciente añade ajustes de App Data Access que agrupan las concesiones recordadas por aplicación y permiten a los usuarios revocar una concesión o una aplicación entera sin recargar. La revocación solo afecta a las solicitudes protegidas futuras. Los datos ya almacenados o copiados no se eliminan, y es posible que no se detenga el trabajo que ya esté en curso. Un cambio en la caché de recursos de Blossom solo considera completo un recurso en caché después de que el SHA-256 del cuerpo entero se haya verificado y se haya guardado un marcador validado coincidente. Los fragmentos provisionales de cachés antiguas se vuelven a validar, y la transmisión en streaming ya no anuncia un falso fragmento final. Esto no significa que no se expongan bytes antes de la validación, y no hay una nueva versión binaria.

Blossom Servers

El directorio Blossom Servers añadió informes de capacidades aportados por la comunidad para cada URL de servidor, cada uno atribuido a quien lo aporta. Las declaraciones manuales y las observaciones desde el navegador se guardan por separado y dejan de aparecer en los filtros pasados 90 días y 24 horas, respectivamente. En las comprobaciones se examinan las respuestas HTTP y los métodos anunciados, además de los desafíos de autenticación y de pago. Las comprobaciones anónimas desde el navegador envían una solicitud HEAD que propone metadatos para un PNG de 68 bytes sin subir nada, así que una respuesta 200 no demuestra que una subida real funcione. La carga de los debates tiene ahora un ámbito delimitado, y la atribución a quien aporta el informe sustituye a la autoridad de operador que antes se daba a entender. Un informe no prueba quién gestiona un servidor ni dice nada sobre la disponibilidad global o el cumplimiento completo de los BUD, y quienes aportan informes pueden discrepar o equivocarse. No verificamos ningún despliegue ni versión.

Código fuente más reciente añade relays de aplicación y de consulta configurables y lee las cuentas y los outboxes mediante NIP-65. Una lista pública de consulta de kind 10086 ya existente tiene prioridad. Al guardar solo se actualiza la lista pública si ya existe; en caso contrario, el cambio se queda en local. El registro local de publicación solo se actualiza cuando al menos un relay acusa recibo del event, lo que no significa que lo hayan recibido todos los relays. No hay ninguna versión ni despliegue confirmados.

Ditto

Ditto, el cliente de Nostr de Soapbox, corrigió los metadatos H.264 generados por codificadores WebCodecs defectuosos para que los vídeos transcodificados puedan reproducirse en iOS. Detecta bytes de cabecera NAL de SPS y PPS duplicados y bits reservados incorrectos en el registro avcC, y los repara antes de que el multiplexor Mediabunny escriba los metadatos MP4, sin tocar los registros bien formados o no reconocidos. La versión 2.45.1 ya está disponible, pero no confirmamos que contenga la corrección ni probamos la reproducción en un dispositivo iOS físico. El cambio se dirige a este fallo de H.264, no a todos los códecs o vídeos.

Firmante de escritorio de Amber y corrección de NIP-46 en Android

Amber, el firmante de Nostr para Android, fusionó el 27 de octubre código fuente para un firmante NIP-46 de escritorio en Compose (Windows/macOS/Linux) que replica el modelo de permisos por aplicación y por kind de Android (commit). NIP-55 sigue siendo exclusivo de Android. El código de escritorio admite varias cuentas y conexiones nostrconnect/bunker con relays e historial por aplicación, además de Tor y notificaciones en la bandeja del sistema. Las claves se guardan en un almacenamiento PKCS12 cifrado protegido por una frase de contraseña Argon2id obligatoria, con bases de datos cifradas por cuenta. No hemos verificado el empaquetado ni el comportamiento en ejecución de la versión de escritorio.

Un cambio fusionado aparte en la aplicación de Android, no en el firmante de escritorio, actualiza las suscripciones de relays de NIP-46 y los filtros de conexión cuando una cuenta cierra sesión. Como resultado, Amber deja de escuchar las claves de una cuenta eliminada. La notificación censurada de la pantalla de bloqueo muestra ahora también la descripción de la solicitud. Eso hace la notificación más útil, pero no añade privacidad. No hay confirmada ninguna nueva versión estable con alguno de los dos cambios de Android.

Intents de napplets y datos de aplicación sincronizados en noStrudel

El cliente web noStrudel fusionó varios cambios en el código fuente, sin etiqueta ni despliegue confirmados. Los intents entre napplets se resuelven mediante el catálogo y las declaraciones de manifiesto z/i, y entregan las cargas aceptadas después de que se cargue el marco de destino, con un ID de remitente certificado en tiempo de ejecución; los intents no admitidos se rechazan y los manejadores con destino explícito requieren la confirmación del usuario (commit). Los napplets instalados y los manejadores predeterminados se sincronizan por cuenta en datos de aplicación de kind 30078 cifrados con NIP-44, con una fusión a tres bandas (commit), y los monitores de relays NIP-66 seleccionados se sincronizan mediante datos de aplicación NIP-78 cifrados (commit). Por su parte, los mensajes NIP-17 se rellenan a partir de los gift wraps en caché y concilian treinta días desde los relays de DM una vez por sesión, usando NIP-77 donde esté disponible, con el historial más antiguo bajo demanda (commit).

Nostr Feedz, archivado

Nostr Feedz, que combinaba RSS con contenido de formato largo y vídeo de Nostr, indica ahora en su README que está archivado y ya no recibe mantenimiento (commit). El aviso remite a Readstr, de PrivKey, como fork que continúa el desarrollo. Se trata de un cambio en el estado de mantenimiento, y no hemos comprobado si GitHub marca el repositorio como archivado ni si las cuentas y los datos se trasladan.

Listas protegidas, correcciones de firmantes y registro con passkey en Zap Cooking

Zap Cooking, un cliente de Nostr para compartir recetas, fusionó un gran lote de cambios en el código fuente web; no está confirmado ningún despliegue ni versión. Las escrituras de listas guardadas de kind 30001 ahora leen primero y se serializan por cuenta, conservando los tags ajenos y el contenido cifrado a partir de la base completa más reciente, y se rechazan cuando la lista de relays es desconocida o no se alcanza el quórum (#869). El quórum requiere al menos dos respuestas EOSE de relays capaces de servir listas, más la mitad de los relays de escritura capaces del usuario, y una respuesta vacía de nostr.wine no puede probar la ausencia (#878). Las colecciones personalizadas comparten el escritor protegido, las operaciones en cola más antiguas se reproducen con protecciones nuevas (#885), y un EOSE agregado vacío ya no basta por sí solo para mostrar una lista como vacía (#872).

Un método de autenticación explícito corrige un fallo de minificación en producción que confundía las clases de firmante, de modo que el cifrado de NIP-46 y de NIP-07 usa el firmante activo y no una clave local obsoleta; la copia de seguridad del monedero en relays sigue bloqueada para NIP-46 (#896). Un inicio de sesión lanzado desde un guardado o una reacción retoma esa acción. Todo zap pendiente conserva el importe y el destino, pero sigue necesitando pulsar Send. Los rechazos del firmante muestran un error sin volver a firmar en silencio con una clave ajena (#867).

El registro crea la identidad localmente con la sincronización de una bóveda cifrada con passkey activada por defecto; se exige una clave de respaldo si la sincronización está desactivada o falla la subida, y Google Drive solo sirve para restaurar (#893). La configuración de WebAuthn PRF con una sola solicitud deja la bóveda sin confirmar y el nsec en texto claro en el navegador hasta que un descifrado posterior correcto de la bóveda la confirma y elimina la clave en texto claro (#907). Extender esa solicitud única al registro depende de un registro sin firmar que no constituye autenticación: cualquiera con un desafío nuevo del servidor puede falsificar un registro que se acepte, y un atacante que conozca el ID de la credencial puede sustituir una entrada sin confirmar (TTL de 30 días) e impedir la sincronización al usuario legítimo (#911). Son contrapartidas documentadas, no garantías de seguridad.

Los enlaces a notas se codifican como nevent de NIP-19 con hasta tres pistas de relays observados, lo que ayuda a los clientes a encontrar events poco replicados sin garantizar su disponibilidad (#873). Las respuestas del perfil incluyen comentarios de kind 1111 de NIP-22 cuya raíz es un event (#877), y una corrección del analizador de coordenadas mantiene en packs y planes las recetas con d-tags que son URL (#888). Se retira el experimento de muro de pago para recetas premium después de que una auditoría realizada por el autor encontrara una forma de eludirlo mediante la pubkey de la consulta, y las publicaciones heredadas de kind 35000 siguen siendo legibles como contenido almacenado (#862).

Una propuesta abierta, aún sin fusionar, se ocupa de las listas de silenciados (#921). Una obtención no disponible de la lista de silenciados seguiría siendo distinta de una obtención correcta que devuelve una lista o ninguna. El cambio dejaría de guardar en caché durante cinco minutos una obtención no disponible como si fuera una lista vacía. Los fallos de análisis se reintentarían, con un aviso cuando no se puedan descifrar los silenciados privados. Abrir la campana de notificaciones recargaría la lista. El objetivo es evitar que una lista de silenciados vacía y obsoleta sin aviso deje entrar en las notificaciones a autores silenciados. No hace que todos los fallos bloqueen el contenido, y no está desplegado.

Pagos de zaps con NWC en Lumilumi

Lumilumi, un cliente web de Nostr, tiene una pull request en borrador que permitiría pagar facturas de zap mediante Nostr Wallet Connect (NIP-47) con un solo toque (#1120). La URI de conexión de gasto solo se almacena localmente y queda excluida de la copia de seguridad de ajustes de kind 30078 en texto claro. Las solicitudes usan NIP-44 cuando el monedero anuncia nip44_v2 y, si no, recurren a NIP-04. El autor lo comprobó con un monedero simulado sin ningún pago real, y el borrador seguía sin fusionar en nuestra fecha de corte de fuentes.

Búsqueda de identificadores en Wisp

Una pull request abierta para el cliente de Nostr Wisp, sin fusionar en nuestra fecha de corte de fuentes, haría que la búsqueda reconociera identificadores NIP-19 y NIP-05 pegados, claves hexadecimales y enlaces web a entidades antes de recurrir a una consulta de texto NIP-50 (#681). Las consultas usan pistas de relays y la caché local. La búsqueda mostraría los resultados a medida que llegan mientras espera el EOSE de los relays consultados, con un límite de 15 segundos, de modo que los relays lentos ya no se descartan. El autor indica que solo lo probó en un emulador, no en un dispositivo físico.

Compatibilidad de Zapstore con Android TV

Zapstore, la tienda de aplicaciones basada en Nostr, tiene abierta una pull request de la v2 para Android TV, sin fusionar en nuestra fecha de corte de fuentes (#407). Haría coincidir las ABI de 32 bits y admitiría el foco Leanback solo con mando a distancia, con una alternativa cuando la pantalla de permiso de instalación no esté disponible. Las compilaciones de 32 bits sin Arti muestran explícitamente una conexión solo directa, mientras que las de 64 bits a las que les falte Arti fallan de forma cerrada. La compilación para TV usa un firmante de depuración local para pruebas y no para distribución, y la única prueba del autor en una TV usó un relay compilado localmente porque el paquete público no estaba disponible.

Propuestas de refuerzo y de NIP-11 en strfry

strfry, el relay de Nostr en C++, tiene dos propuestas sin fusionar en nuestra fecha de corte de fuentes. #281 responde a los hallazgos de auditoría del relay SF-01 a SF-13 acotando la profundidad del JSON, las cargas descomprimidas, las colas y las etiquetas de métricas, corrigiendo un fallo con filtros de negentropy vacíos y aplicando hash a los índices de tags largos. Pasa al formato de base de datos 4, así que quienes lo adopten tendrían que exportar y volver a importar. Las pruebas superadas son las del propio autor. El borrador #278 anunciaría solo las limitaciones de NIP-11 que realmente se aplican, más tarifas opcionales y payments_url, con payment_required en false por defecto y precios configurados que no implementan pagos.

Pagos con Bark en nostrcheck-server

nostrcheck-server, un servidor de alojamiento multimedia para Nostr, tiene una pull request en borrador que añade un proveedor de pagos barkd (Bark) (#62). Crearía facturas Lightning mediante la API REST de barkd y, de forma opcional, adjuntaría a las respuestas 402 una URI BIP-321 X-Ark por archivo, con la misma factura Lightning como alternativa. Un monedero en el mismo servidor Ark paga a través de Ark y los demás usan Lightning, y un pago liquidado desbloquea el archivo una vez. Las pruebas usan un barkd simulado, y depende de la pull request abierta #61 de BUD-07. Seguía sin fusionar en nuestra fecha de corte de fuentes y no es una función de share.yabu.me.

Escrituras de pago en nostr-relay de mattn

Una pull request en borrador para nostr-relay de mattn, sin fusionar en nuestra fecha de corte de fuentes, añadiría escrituras de pago opcionales mediante un monedero Bark, desactivadas por defecto (#37). Las pubkeys prepagarían las tarifas de escritura a través de barkd con un filtro de kind opcional, y quienes escriban sin saldo reciben una respuesta restricted: con una URL de pagos. Para las recargas se usaría Ark o Lightning mediante URI BIP-321 o NWC, con las tarifas publicadas en NIP-11. Las pruebas usan un daemon simulado, y no está decidido si esto debe ir en el propio árbol o detrás de un hook.

Protección contra repeticiones al reconectar en ContextVM

ContextVM, que transporta MCP sobre Nostr, tiene una pull request abierta para su SDK de TypeScript que evitaría la ejecución duplicada tras las reconexiones a relays (#113). El transporte del servidor conservaría los ID de events verificados hasta cerrarse, y una caché de sobres acotada e independiente bloquea los duplicados reenvueltos. La memoria crece con los events verificados únicos durante la vida útil del transporte. La corrección seguía sin fusionar en nuestra fecha de corte de fuentes y no está en ningún paquete publicado.

Reproducción multimedia y aprobaciones en el shell Kehto

Kehto, un shell web para napplets de Nostr, fusionó la reproducción NAP-MEDIA el 28 de octubre. Los hosts Paja y playground comparten ahora un reproductor de audio y vídeo mediado por políticas. Usa los códecs del navegador para fuentes finitas de URL y de Blossom, y reproduce transmisiones en directo HTTPS en MP3 o ADTS AAC cuando MediaSource admite el códec, empezando antes de que termine la respuesta. La autoridad de la sesión sigue ligada al endpoint, la ventana de origen y la ACL. La revocación o el desmontaje retiran las URL de Blob, detienen la reproducción y cancelan las transmisiones. El método ResourceService.openStream, exclusivo del host, usa las concesiones y la política existentes basadas en el origen del endpoint, y no añade ningún mensaje de recursos al protocolo. La entrega terminal se mantiene. El alias heredado sendCommand sigue funcionando. Por otro lado, las retrollamadas de dos argumentos detectables siguen funcionando con un aviso. Las retrollamadas heredadas unarias pasan a objetos de comando. El resolutor del navegador rechaza las URL que no son HTTPS, las credenciales y los literales de IP privadas. También desactiva las redirecciones y los referrers. No puede inspeccionar el DNS, así que no garantiza la protección frente a direcciones privadas en el momento de la resolución: los resolutores de producción necesitan comprobaciones en el momento del DNS, y el comportamiento predeterminado del navegador depende de CORS y de la protección de redes privadas. HLS, DASH, Ogg en directo, las fuentes de Nostr, las colas, la persistencia y la reanudación automática al recuperar el foco siguen sin estar admitidos. El autor informa de 155 pruebas en Chromium y de 112 segundos de reproducción de radio desde un artefacto Funclet sin modificar, que no volvimos a ejecutar. Es trabajo solo en el código fuente. Al paquete publicado Napplet 0.32 le faltan algunos tipos del borrador. NAP-MEDIA sigue siendo un borrador; no se reivindica conformidad en ninguna versión publicada.

Un segundo cambio fusionado hace que las aprobaciones de firma y publicación sean específicas de cada versión. Cada aprobación queda ligada al editor verificado, al hash del artefacto y al firmante activo. Las aprobaciones se pueden revocar, y las aprobaciones solo de firma y solo de publicación son independientes. Un permiso heredado nunca se amplía en silencio. El consentimiento para una URL de desarrollo mutable solo dura esa carga, y un cambio de endpoint o de cuenta rechaza las solicitudes pendientes. NAP-LINK solo abre un enlace tras un clic explícito en un modal del host, con noopener. El cambio no afirma haberse probado de forma universal con fuentes de radio CVM externas, y una fusión en el código fuente no demuestra que haya una versión en npm.

Pact

Pact, un protocolo de Nostr para relaciones entre agentes y consentimiento del operador, autentica ahora las respuestas de Nostr Wallet Connect. Cada resultado debe llevar la firma del monedero y hacer referencia a su solicitud, y Pact comprueba el tipo de resultado y el hash del pago, además de cualquier preimagen devuelta. El canje incorpora escrituras atómicas en el libro contable y protecciones al consumir y reintentar solicitudes, y se cierran más vías de falsificación del consentimiento. Un cambio posterior que limita los pagos MCP los mantiene desactivados salvo que se configure PACT_MCP_ALLOW_PAYMENTS=1 y comprueba un límite predeterminado de 1.000 sats tanto con el importe declarado como con el de BOLT11. La ventana de la bandeja de entrada privada se detiene ahora en 200 wraps y señala el truncamiento. Las pruebas del autor se basan en simulaciones.

nostr.watch

nostr.watch, un monitor de relays de Nostr, añade compatibilidad explícita con el descubrimiento y el transporte FIPS, y las consultas de la red superpuesta ya no recurren al DNS sobre HTTPS público. Los hosts siguen aportando el DNS y el enrutamiento IPv6, ya que el monitor no incluye ningún daemon ni proxy FIPS y no ofrece anonimato. Una comprobación de npub más estricta solo acepta npubs dentro de nombres de host .fips analizados. Las sondas automáticas de NIP-11 y NIP-05 pasan a un ServiceWorker propiedad de la aplicación, lo que elimina el contexto de la pestaña propietaria de la ruta de navegación observada que provocan las extensiones; esto se comprobó en Firefox 155 sin modificar con un entorno de prueba de extensión controlado. El conjunto de pruebas de conformidad contiene quince comprobaciones acotadas de NIP-01 con una capa de conversación que admite conexiones independientes. El autor informa de pruebas superadas y de ejecuciones en una malla aislada, no de una auditoría con relays públicos ni de seguridad del navegador.

Bitcredit Core

Bitcredit Core, un protocolo de crédito y letras de cambio entre pares que usa Nostr, comprueba ahora que haya al menos un relay de escritura conectado antes de que una operación de bloque persista nada localmente o desencadene sus efectos. La recuperación también se reinicializa de forma limpia. La validación de cadenas candidatas, de la que informamos la semana pasada como abierta, ya se ha fusionado, así que las cadenas se validan y preparan antes de persistirse. Estos pasos reducen la probabilidad de un estado local incoherente. Un relay conectado no puede garantizar que los relays acepten el event ni que se complete la liquidación, y esa comprobación por sí sola no hace duradera la persistencia local.

Una fusión más reciente, no confirmada en ninguna versión, añade un gestor de transacciones al servicio de identidad. Los bloques de identidad, el estado y la confirmación del correo electrónico se confirman ahora de forma atómica antes de que nada se propague por Nostr, y nuevas pruebas comprueban que no se envía nada cuando falla la confirmación. Esto solo abarca el servicio de identidad. La persistencia de letras y empresas carece de esta confirmación atómica, y la aceptación por los relays y la liquidación siguen sin estar garantizadas.

Compatibilidad entre MLS-KMP y Marmot

MLS-KMP, la biblioteca MLS en Kotlin que hay bajo marmot-kmp, ya había corregido varios comportamientos de transmisión para coincidir con otras implementaciones de MLS, de modo que los miembros en la 1.2.0 y los que usan ese código más reciente no coinciden en los casos enumerados, y los grupos deben actualizarse a la vez. El estado guardado pasó a la versión 10, que las versiones anteriores no pueden restaurar. La tarea de compatibilidad con Marmot, aguas abajo, no es bloqueante. Sus pruebas no se ejecutaron en el entorno en que se escribió ese cambio; Marmot todavía debe adaptarse a authorizeProposal y a GREASE. Un cambio anterior en los componentes de la aplicación exige los componentes que Marmot necesita para seguir MDK v0.14. No hemos verificado su adopción en Amethyst.

Código fuente fusionado más reciente, que no se atribuye a la versión publicada 1.3.0, repara la compilación del ejecutor nocturno de interoperabilidad e informa de éxito, fallo u omisión por cada script. Por tanto, nuestra nota anterior de que el ejecutor real nunca se había ejecutado está desfasada: los autores informan de ejecuciones que funcionan, aunque la última seguía en curso cuando se abrió el cambio y no hemos consultado un resultado final de CI. La tarea de OpenMLS sigue sin ser bloqueante, omite 22 escenarios no admitidos o que provocan pánico y solo cubre la suite de cifrado 0x0001, por lo que no certifica la interoperabilidad. Ese cambio también corrige la búsqueda de la PSK de ReInit por ID de grupo conservado, la transcripción provisional de la época cero, el secreto aleatorio de la primera época y el manejo de la PSK de reanudación en los commits externos. Para la transcripción de la época cero, el código sigue ahora la sección 11 del RFC 9420 para coincidir con OpenMLS, así que las incorporaciones externas en la época 0 difieren de la 1.3.0 y de versiones anteriores, y los grupos antiguos guardados mantienen el hash anterior hasta su primer commit. El motor original derivaba el secreto de su primera época a partir de cero; los autores no encontraron ningún exploit porque los commits posteriores llevan un UpdatePath nuevo, y la corrección no demuestra que se hayan resuelto todos los problemas de seguridad.

Obelisk Relay

Obelisk Relay fusionó en su rama predeterminada una corrección para los grupos NIP-29 privados. Los administradores globales del relay ya podían enviar REQ para grupos privados, pero el filtro de visibilidad de events seguía rechazando los events correspondientes. Ahora los administradores del relay pueden leer esos events, y las comprobaciones de acceso de los miembros se mantienen. Los grupos privados del relay no tienen cifrado de extremo a extremo, y el cambio hace explícita la visibilidad que tiene el administrador del servidor. La corrección es trabajo fusionado en el código fuente, dirigido a desarrolladores y operadores.

Plume

Plume, el cliente de escritorio en Rust y Tauri, fusionó un cambio que mantiene un único WebSocket persistente y con reconexión por relay. Las operaciones de feed, perfil, publicación y mensajes directos comparten esa conexión. Las suscripciones y los ID de events se multiplexan sobre ella. Los intentos de reconexión se espacian progresivamente; las conexiones se cierran cuando la aplicación sale. Antes del cambio, cada operación abría un socket nuevo que después quedaba abierto sin liberarse. El cambio revisado es trabajo fusionado en el código fuente; aquí no se establece ninguna medición de rendimiento. No promete una recuperación sin pérdidas ni una entrega garantizada.

Hashtree

El runtime de TypeScript 0.5.22 de Hashtree permite a los proveedores del navegador guardar en IndexedDB hasta 256 anuncios públicos y firmados de pares vigentes, con ámbito por identidad y aplicación. Los proveedores pueden recargarlos antes del descubrimiento en la red. Los REQ ordinarios de pares pueden reproducir esa caché cuando las reglas de admisión existentes lo permiten, y el descubrimiento privado permanece en un ámbito de propietario independiente. Por otro lado, un cambio fusionado en el adaptador de Rust cancela las lecturas de índice abandonadas, de modo que los comandos ya no esperan a que se agote el tiempo de espera completo del transporte. La pull request indica que hashtree-nostr-pubsub 0.2.87 está publicado, y ese paquete se versiona por separado del runtime de TypeScript. Commits del cliente de Rust que solo están en el código fuente añaden orígenes Blossom combinados heredados, de lectura y de escritura para las lecturas y un reintento por fuente ante reinicios de conexión tipados en la fase de solicitud, sin guardar en caché respuestas parciales. Una sola instalación en frío en un Mac no demuestra que estén resueltos los agotamientos intermitentes del tiempo de espera en las transferencias.

nostr-pubsub

nostr-pubsub TS 0.5.20 mantiene un almacén acotado de events firmados y añade persistencia en IndexedDB, transacciones atómicas entre pestañas, caducidad y reproducción local para los REQ ordinarios de Nostr. La misma fuente describe por separado una API nativa opcional de almacén en archivos en Rust, con instantáneas atómicas y una concesión de escritor exclusivo, que es distinta del paquete de TypeScript. En la implementación del almacén duradero de events, las recargas vuelven a comprobar las firmas y los events reemplazables ganadores según NIP-01, y rechazan los events efímeros y las marcas de tiempo que superan en más de cinco minutos la hora actual. Los almacenes nunca se abren de forma implícita, y quien llama elige el alcance del anuncio público. FIPS restaura los anuncios firmados de kind 37195 antes del descubrimiento en la red y sigue comprobando la vigencia, el esquema y el espacio de nombres. Las cachés de descubrimiento anónimas o privadas deben mantenerse separadas de la reproducción pública, y no conviene usar como fuente de reproducción un enrutador que obtiene datos de la red. Como la retención es acotada, esto no ofrece un arranque sin conexión indefinido.

FIPS-TS

El runtime FIPS-TS 0.0.57 acepta un proveedor de descubrimiento duradero propiedad de la aplicación, que publica anuncios firmados de kind 37195 y se suscribe a ellos mediante la interfaz existente. Con un proveedor inyectado, el transporte no abre ningún cliente de relay de Nostr y acepta una lista de relays vacía; al apagarse, vacía las suscripciones pendientes. Quien llama es responsable del ciclo de vida del proveedor y del almacenamiento restaurado. Las comprobaciones de espacio de nombres, firma y caducidad siguen aplicándose. La autorización de pares sigue siendo obligatoria. Los anuncios en caché no garantizan el arranque sin conexión, porque el nuevo enrutamiento autenticado y la señalización WebRTC siguen necesitando un portador FIPS alcanzable.

Flotilla

Flotilla fusionó tres cambios en el código fuente. Compartir en el chat permite a los usuarios compartir notas independientes y comentarios NIP-22 en cualquier sala o conversación. Citar en una conversación ya no añade al autor citado a las p-tags ni bifurca la membresía. La reanudación de subidas interrumpidas restaura las subidas de adjuntos desde los borradores y, al mostrar un error, permite a los usuarios recuperarse de las subidas fallidas. Si la compresión falla, recurre al archivo original, que puede conservar sus metadatos. La espera de los marcadores de lectura almacenados retiene las escrituras de marcadores de lectura de la página hasta que se carga el estado de lectura almacenado, de modo que las actualizaciones de lectura tempranas no se pierden al iniciar.

following.space

Una pull request abierta para following.space, sin fusionar en nuestra fecha de corte de fuentes, restauraría la creación, edición y eliminación de follow packs, además de seguir a los miembros de un pack. Usaría Applesauce para descubrir la cuenta y los relays outbox, y compartiría los packs como direcciones naddr. Admite firmantes de extensión del navegador, un secreto guardado solo en memoria y firmantes bunker. Ni el código ni las pruebas descritas por el autor muestran un servicio desplegado ni compatibilidad con todos los firmantes.

Routstr

En nuestra fecha de corte de fuentes había tres pull requests de Routstr abiertas y sin fusionar. En el servicio principal, el descubrimiento de la salud de los proveedores rechazaría las URL anunciadas y las redirecciones que se resuelven en direcciones no globales, manteniendo el manejo del proxy onion. Los autores describen una exposición a falsificación de solicitudes del lado del servidor (SSRF) y pruebas, pero no se trata de una corrección desplegada ni de un exploit confirmado. En el SDK, la atribución de proveedor de una URL seguiría a la clave que firmó el event de kind 38421. Una pubkey escrita en su contenido sigue sin verificarse. Entre los 81 events que el autor revisó en el relay predeterminado, ninguno tenía listas de proveedores basadas en el contenido, así que no se afirma que se explotaran URL conocidas ni que todos los proveedores sean ahora seguros. La fijación automática de rutas de modelos pasaría de constantes integradas a instantáneas firmadas en events direccionables de confianza de kind 38427. El SDK conservaría la última instantánea válida y marcas de agua contra reversiones, y una instantánea vacía actuaría como interruptor de emergencia. El cambio rompe la API de adaptadores personalizados. No se ha publicado ningún event de política, y el despliegue sigue siendo un paso a cargo del operador.

SatSigner

Una pull request abierta para SatSigner, sin fusionar en nuestra fecha de corte de fuentes, rehace su capa de relays, caché y sincronización de Nostr. No encontrar un event (la respuesta de fin de events almacenados de un relay) se distinguiría de los tiempos de espera agotados y de no tener ningún relay. El contenido en caché obsoleto quedaría marcado. Los events se almacenarían antes de que el procesamiento haga avanzar los cursores, y se verificarían los ID de los rumores de gift wrap. Eliminar una identidad borraría sus tablas de Nostr, aunque una sincronización de kind 0 puede sobrescribir una edición local del perfil. Un cambio posterior apilado sobre ella añadiría diagnósticos con datos ocultos, pósteres de vídeo que se cargan al tocarlos en el feed de Nostr con un máximo de tres reproductores, y puesta al día al reanudar la app sin desmontar el conjunto de relays. También añade pruebas de relays que inyectan fallos. El nuevo módulo nativo de vídeo exige recompilar la app, y la validación en dispositivos está pendiente. Ninguno de los dos cambios se ha publicado ni ha superado una comprobación en tiempo de ejecución.

Bray

Bray 3.5.4 añade autenticación de relays NIP-42 a su cliente y daemon de bunker NIP-46. Ahora pueden usarse relays privados que exigen AUTH para leer los mensajes dirigidos al bunker. Los cambios posteriores en el código fuente no constan en esta etiqueta.

En código fuente fusionado posteriormente, el servidor MCP de Bray arranca en modo de solo lectura cuando no hay ningún firmante configurado o se fuerza BRAY_READ_ONLY, y toma esa decisión antes de abrir ningún secreto. En este modo no se carga ningún monedero, se rechazan la firma, el cifrado y el descifrado, y solo están disponibles 111 de sus 261 herramientas, las de consulta. La CLI y el SDK siguen requiriendo un firmante, y un archivo de secreto configurado pero vacío sigue siendo un error. Las nuevas atestaciones usan ahora un espacio de nombres de etiquetas de atestación NIP-32, que sustituye a nip-va. La consulta existente por tipo #l encuentra tanto las etiquetas antiguas como las nuevas, mientras que signet-protocol conserva su propia copia 2.5.5. Esto no supone una aceptación oficial como NIP ni significa que todas las bibliotecas anidadas hayan migrado. No se demuestra que ninguno de los dos cambios esté en 3.5.4.

Extensión de navegador de Alby

Una pull request abierta para la extensión de navegador Alby Lightning, sin fusionar en nuestra fecha de corte de fuentes, haría que su asistente de permisos rechace las entradas bloqueadas recordadas en una sola lectura. Así se cierra una condición de carrera en la que eliminar una entrada de denegación podía permitir que un manejador de Nostr actuara sin preguntar. La ruta equivalente de entradas bloqueadas para BTC y Liquid no es alcanzable actualmente. No es una corrección desplegada, y no se ha confirmado ningún exploit.

Política de escritura del relay de MintRadar

El código fuente de MintRadar añade una política de escritura del operador para el relay de Nostr del proyecto. Limita los anuncios públicos de kind 38172 y las reseñas de kind 38000 a 16.384 caracteres de JSON serializado por event y a 120 por hora por cada /64 de IPv6, y los prefijos IPv6 comprimidos se llevan a su forma canónica. A las fuentes con mucho tráfico se les aplica un techo flexible de 3.000 por hora, y un tope absoluto de 6.000 por hora cuenta solo los events aceptados de todas las fuentes. Las claves privilegiadas no tienen límite. Las conexiones nuevas se limitan a 120 por minuto con una ráfaga de 60. Se trata de código y configuración del operador, no de una prueba de despliegue en producción ni de una protección completa contra la denegación de servicio.

Proyectos nuevos

bosstro

Bosstro es un nuevo cliente Android para quienes resuelven disputas en Mostro. Su código fuente de MVP está publicado, con una interfaz en Flutter sobre el núcleo en Rust de Mostro. Los resolutores firman con una clave de resolutor dedicada, nunca con la clave del nodo, y el nodo concede a cada uno autoridad de lectura o de lectura y escritura. Los resolutores autorizados pueden tomar disputas, unirse a chats cifrados entre comprador y vendedor que incluyen imágenes y PDF, y pagar al comprador o reembolsar al vendedor. Las claves se guardan en un almacenamiento respaldado por Android Keystore, pero las compilaciones de desarrollo para Linux y web carecen de esas protecciones. Las sumas de verificación publicadas no demuestran quién es el publicador.

cordn-kmp

cordn-kmp es una nueva implementación de Cordn en Kotlin Multiplatform, construida sobre Quartz y mls-kmp para JVM, Android, iOS, macOS y Linux. Su CordnGroupManager sin interfaz crea grupos, invita, se une, envía y se pone al día mediante un coordinador MCP sobre Nostr, un modelo distinto de la entrega por relays de Marmot. Las interfaces aportan su propia persistencia, y la afirmación del README sobre interoperabilidad con ts-mls procede del autor.

Desde entonces, el proyecto ha publicado 1.1.0, que compila contra Quartz 2.4.0 ya publicado, de modo que el requisito anterior de una copia local de Quartz sin publicar tras un indicador de compilación ya no se aplica a las versiones etiquetadas. 1.2.0 elimina el método público CordnExposure.differsFromMarmot() y deja a las interfaces la comparación con otro binding. Pese al número de versión menor, es un cambio de API incompatible. Una propuesta había llamado a esta versión 2.0.0, y la versión real usa 1.2.0.

emosphere

EmoSphere es un mapa de estados de ánimo en Nostr cuyo código fuente ya es público; su README describe la versión 0.5.1. Cada dispositivo genera su propia clave y publica events firmados de kind 1074 que llevan una emoción y su intensidad, una nota breve opcional y una ubicación aproximada que los usuarios pueden desactivar. Las publicaciones aparecen en un mapa mundial con reproducción temporal y un feed de seguidos. Estas señales son públicas y seudónimas, por lo que los relays pueden leer el estado de ánimo y la ubicación y vincularlos a una clave a lo largo del tiempo. Android guarda las claves en almacenamiento seguro, mientras que la versión web usa localStorage.

matrix-appservice-nostr

matrix-appservice-nostr es código fuente prototipo de un servicio de aplicación de Matrix emparejado con un relay de Nostr. Los usuarios de Matrix pueden crear o importar identidades de Nostr y publicar, seguir, responder, reaccionar y enviar DM desde salas de Matrix, con identificadores NIP-05 en el dominio del puente. El contenido y los archivos multimedia permanecen en el backend de Matrix, y el relay reconstruye los events a partir de los originales guardados. Las claves se cifran con AES-GCM bajo un secreto configurado o se mantienen en remoto mediante NIP-46. Los usuarios deben confiar en el operador, y un borrado de contenido en Matrix (redaction) elimina solo la copia del puente.

Siete commits más recientes añaden identidades de Nostr en la sombra. El puente las crea automáticamente para los usuarios de Matrix autorizados que interactúan hacia fuera, con perfiles que reflejan los de Matrix. Crear un perfil completo actualiza la cuenta existente sin moverla y conserva la misma clave. Los administradores del puente pueden conceder a usuarios o servidores domésticos externos acceso completo o en la sombra, o acceso pasivo limitado a una sala para responder, reaccionar y votar. Una concesión o un bloqueo para un usuario concreto prevalece sobre las reglas del servidor doméstico, que a su vez prevalecen sobre las de la sala. El permiso completo permite crear un perfil, pero no lo publica automáticamente. Revocar el acceso conserva las claves, el historial y las salas, pero detiene la publicación hacia fuera allí donde ya no está permitida. Las identidades importadas nunca se sobrescriben con un perfil reflejado. Las comprobaciones cuentan con código y pruebas, pero no con verificación de interoperabilidad en tiempo de ejecución ni de seguridad, y sigue siendo necesario confiar en cómo gestiona las claves el operador. Los stickers se envían ahora como imágenes.

nostr-scrutiny

Nostr Scrutiny publica código fuente y fichas informativas fechadas el 24 de octubre que comparan cinco clientes de Nostr: Amethyst, Damus, Nostrich, Primal y Quill. Cada ficha recoge las declaraciones de privacidad del cliente en las tiendas de apps y su código publicado, junto con las solicitudes de red observadas en una primera visita con el navegador. Construido como HTML estático y sencillo, el sitio afirma no tener seguimiento propio. Las fichas son un inventario de hechos fechado, no una certificación de seguridad ni una auditoría criptográfica. Como conflicto de intereses declarado, el autor también desarrolla Quill.

v2

Solid Chat v2 es código fuente de cliente recién publicado que usa una única clave did:nostr para escribir en salas de pods de Solid con autenticación HTTP NIP-98 y para enviar DM envueltos en gift wrap según NIP-17. La firma funciona mediante NIP-07, NIP-46 o un nsec local, con cifrado NIP-44 y envoltorios de kind 1059. Las salas están en texto plano, protegidas solo por la ACL de cada pod. Los archivos multimedia de los DM cifrados se suben a Blossom, y las búsquedas de perfiles van a un directorio de nostr.social. Un nsec local se guarda en localStorage, por lo que un firmante externo es más seguro.

witchat

Witchat es código fuente de un cliente no oficial de bitchat para Windows y Linux. Chatea a través de una malla Bluetooth cercana y, entre favoritos mutuos, recurre a gift wraps de Nostr. También se une a canales públicos de geohash en Nostr, con events de kind 20000 para los mensajes y de kind 20001 para la presencia. La interoperabilidad con los transportes de bitchat es una afirmación del autor, y los binarios de Windows no están firmados. Los relays de Nostr pueden ver las direcciones IP y los metadatos de los canales, y las difusiones cercanas viajan, por ahora, solo por Bluetooth.

wn-notify

wn-notify es una CLI no oficial en Python, solo con la biblioteca estándar, que envía mensajes y archivos a grupos de White Noise a través de un wn-agent local mediante el socket Unix marmot.agent-control.v2; el conector guarda las claves, el estado MLS y los relays. La CLI comprueba final_sent y los ID de los mensajes. Ante un resultado desconocido, termina con un código distinto de cero como desconocido y conserva la clave de idempotencia para un reintento manual, ya que nunca reintenta por su cuenta. Un acuse de recibo confirma la publicación en el relay, no que alguien haya leído el mensaje. Solo se ha probado wn-agent 0.13.0.

xmradar

XMRadar es una extensión de navegador que copia publicaciones web y artículos de X a Nostr. Cada publicación se aprueba mediante un firmante externo NIP-07. La versión 0.2.0 añade propinas en Monero en X para autores que tienen una identidad de Nostr.

La implementación publica un recibo de kind 9042 solo después de que el usuario indique que envió una propina y lo confirme. El recibo hace públicos los npub de ambos participantes, el importe y la dirección. No incluye ningún ID de transacción, clave de transacción ni prueba de pago. Una pequeña cantidad aleatoria de piconeros permite que el monedero del destinatario identifique el pago y publique una confirmación de kind 9044. Esa confirmación la firma el destinatario y no es una prueba independiente en cadena. La interfaz distingue las propinas confirmadas por el destinatario de las reclamaciones sin confirmar. Las propinas propias del usuario quedan pendientes durante 30 minutos. Las reclamaciones sin confirmar cuentan una vez por pagador, según el recibo más pequeño a la dirección actual; esas reclamaciones pueden falsificarse. Los totales se llevan por autor, no por publicación. El descubrimiento de direcciones mediante pruebas de X de NIP-A3 y NIP-39 está desactivado por defecto. Cuando se activa, los relays y X pueden ver qué identidades consulta el usuario.

agent-inbox

agent-inbox es una nueva herramienta que permite a los agentes de IA comunicarse entre sí mediante identificadores cortos sobre Nostr. Un único archivo de Python envía gift wraps estándar de NIP-17 con cifrado NIP-44 v2, puede publicar en un tablón público e incluye datos de prueba de los vectores de prueba oficiales. Los identificadores son sufijos truncados de claves públicas, no identidades certificadas. El README advierte de que su criptografía en Python puro no es de tiempo constante, y nosotros no la hemos auditado. Cualquier cliente NIP-17 puede seguir enviando mensajes al npub de un agente.

CarryChat

CarryChat es un nuevo mensajero de almacenamiento y reenvío que mueve paquetes acotados de mensajes por cualquier ruta disponible. Nostr es su transporte por internet, y los enlaces locales, como Bluetooth LE y el simple intercambio de archivos, cubren los casos sin conexión. El código fuente incluye el transporte de Nostr junto con sus pruebas. El README lo califica de versión 0.2 temprana y dice que las pruebas de campo de LoRa en hardware físico no están terminadas. No lo hemos probado en dispositivos.

Trece commits más recientes, hasta 311f176, sustituyen marcadores de posición de la hoja de ruta por código fuente funcional. Abarcan Wi-Fi Direct, un adaptador de radio MeshCore, enlaces Reticulum, tarjetas de contacto NFC y un transporte de audio, con código en Kotlin, Rust y de interfaz. Por audio, el receptor verifica las firmas de las tarjetas de contacto y acepta tramas de mensajes normales, pero rechaza fragmentos de archivos. NFC solo intercambia tarjetas de contacto, no mensajes. Se trata de desarrollo de código fuente posterior a la versión 0.2.0 anterior, no de un nuevo binario verificado. Según el README, MeshCore y LoRa, Reticulum, Wi-Fi Direct y NFC siguen pendientes de pruebas de campo o con dos teléfonos. Los cambios no afirman compatibilidad de hardware, anonimato ni seguridad. El audio de alta frecuencia depende del hardware y no es inaudible en todas partes. Nostr sigue siendo un transporte por relays de internet junto a los enlaces locales.

Cosign y Marble

Cosign es un nuevo protocolo y biblioteca en beta que divide una clave de firma de Nostr en participaciones de umbral FROST. El dispositivo de un usuario puede firmar junto con un servidor, pero los servidores no pueden firmar solos. Una participación de respaldo en papel da soporte a los flujos de recuperación y de renovación de participaciones descritos en el README, que no se han verificado en cuanto a seguridad. Marble, un cliente para Android y navegador, usa Cosign para los feeds y la firma. La biblioteca FROST subyacente ha sido auditada, pero el protocolo propio de Cosign no ha tenido ninguna revisión independiente.

En código fuente más reciente, el cliente de navegador de Marble vincula las notas no enviadas a la cuenta con sesión iniciada. Antes de publicar, detecta cuándo otra pestaña o una sesión remota ha cerrado la sesión, y una solicitud desde un cliente sin sesión muestra Signed out. La búsqueda instantánea consulta Ditto y los relays, no la web en general. Buscar las publicaciones de un autor revisa las ya cargadas antes de preguntar a los relays. El probable spam se pliega tras un aviso desplegable. Una anulación Not Spam se aplica solo en ese navegador y solo a ese autor. Estas ayudas de búsqueda no son prueba de una revisión de seguridad.

Cosign 0.12.7 solo permite que las fusiones de la lista de miembros provengan de servidores, lo que impide que una participación de respaldo en papel sea promovida a otro rol. Tras una sincronización de época, los servidores desactualizados se marcan como rezagados. Los resultados parciales no válidos se rechazan; la reparación automática sigue desactivada. Ahora los parciales de descifrado llevan pruebas de Chaum-Pedersen, que se comprueban antes de combinarlos. Los clientes antiguos ignoran las pruebas, y la parte de Android de Marble llegará con su próxima compilación. Estas descripciones de seguridad proceden del autor de la versión, y no hemos auditado la criptografía.

El código fuente NIP-55 para Android confirmado después de la etiqueta 0.12.7 corrige una condición de carrera en la primera conexión, cuando la concesión del servidor aún está llegando a través de los relays. Las consultas de clave pública responden ahora de inmediato. La firma y el descifrado esperan fuera del hilo de la interfaz y reintentan una vez, y solo cuando una conexión recién concedida recibe una respuesta de revocación. El código también distingue un servidor inalcanzable de uno que responde con un rechazo. No consta que esta corrección posterior del código fuente esté en la etiqueta 0.12.7 ni en un binario actual de Marble.

Dream Nests

Dream Nests es un nuevo directorio de solo lectura de salas de audio en directo de Nostr que reúne salas de Nests y events de actividad en directo junto con su chat. Para los lectores de pantalla, la aplicación web usa encabezados y anuncios de región en vivo corteses, y unos breves earcons sirven como señales sonoras. Reproduce flujos HLS públicos solo para escuchar. Las salas de Nests se abren en Nests, mientras que las de Corny Chat y HiveTalk se abren en sus propios sitios, así que hablar sigue ocurriendo en esas apps. Los indicadores de micrófono proceden de metadatos de presencia, no de detección de actividad de voz. No hemos probado la accesibilidad en dispositivos. El repositorio documenta una URL pública en funcionamiento.

fips-pub-pki

fips-pub-pki es código fuente nuevo para certificados de Nostr firmados que permiten a un dominio delegar en subemisores, con validación de rutas sin conexión. Los anclajes de confianza proceden del proyecto complementario fips-pub-domains, que combina declaraciones DNSSEC con fijaciones y testigos. El verificador nunca consulta el DNS. La revocación se basa en la caducidad y en marcadores explícitos, no en borrar events de los relays. Según el README, las pruebas en malla reales con un dominio público y un teléfono no están terminadas. Sin ningún NIP enviado ni kind registrado, es un experimento, no un sustituto de TLS.

Magnetar

Magnetar es una nueva pila de búsqueda para events de torrents de NIP-35. Combina un rastreador y un backend de búsqueda con una app de Android que mantiene una caché local en SQLite; además, construye la confianza en los publicadores a partir de los seguimientos y comprueba la actividad del enjambre. La primera prerrelease 0.1 incluye el código del rastreador y pruebas tanto para Android como para el servidor. El autor solo lo ha validado con pruebas automatizadas y un emulador, no en teléfonos reales. La confianza basada en seguimientos no puede hacer que un torrent sea legal o seguro, y el backend no es un índice de referencia.

Magnitude Relay

Magnitude Relay es un nuevo relay de Nostr en Rust de VectorPrivacy, ajustado para los DM envueltos en gift wrap de Vector y el tráfico de Concord, con sincronización NIP-77 e indicadores de escritura. Sus operadores dicen que sustituyó a strfry en dos endpoints existentes de Vector. Su repositorio incluye entornos de pruebas adversariales y de medición de rendimiento, pero las cifras de velocidad publicadas proceden de ejecuciones del propio autor y no se han reproducido de forma independiente.

Desde entonces ha fusionado empaquetado con Docker y Compose para operadores. Se ejecuta como usuario sin privilegios con un volumen de datos, una escucha solo local y una comprobación de salud. Las observaciones sobre producción e importación de la pull request proceden del autor, y arm64 no está probado. El empaquetado por sí solo no demuestra conformidad con el protocolo.

Código fuente más reciente limita por defecto las conexiones nuevas por IP a una ráfaga de 300 y después a 60 por minuto. Fijar el límite en 0 lo desactiva, y la interfaz de loopback está exenta. La cabecera de IP real de un proxy solo se acepta desde localhost, y las conexiones rechazadas reciben un HTTP 429 antes de abrirse el WebSocket. Los rechazos públicos del relay solo se informan de forma agregada, y el detalle por IP solo está disponible en el socket de administración. La sincronización masiva NIP-77 excluye los events efímeros y los que caducan en menos de 600 segundos, mientras que la entrega en vivo sigue transmitiendo events de corta duración. Cuando cambian los enlaces de confianza, el relay omite sondeos redundantes de visibilidad de gift wraps, aunque estos se siguen sincronizando. Son cambios en el código fuente sin ningún benchmark medido en producción.

nostr_doctor

nostr_doctor es una nueva biblioteca de Dart, con una CLI y una interfaz en Flutter, que comprueba si los clientes pueden descubrir los datos de una cuenta. Empieza por los metadatos del perfil y las listas de relays NIP-65, y después abarca los relays de DM privados y los borradores, así como los servidores Blossom y la configuración de nutzaps. Para comprobar el descubrimiento de la lista de relays, sondea la lista reemplazable. Revisamos la herramienta de diagnóstico como código fuente y no verificamos ninguna versión publicada de la app. Sus resultados solo reflejan los relays que consulta y no muestran la disponibilidad global.

nostr-indexer-relay

nostr-indexer-relay es un nuevo relay en Go que solo almacena listas de relays NIP-65. Su rastreador encuentra los relays mencionados en esas listas, comprueba si admiten NIP-77 y se sincroniza con otros indexadores activos mediante negentropy. Incluye una página pública de consulta y una interfaz de administración, y se describe a sí mismo como temprano. Es un índice centrado en listas de relays, no un archivo de Nostr ni un relay de contenido general.

nostr2gh

nostr2gh es un nuevo puente que lleva events de parches y pull requests de NIP-34, junto con sus actualizaciones, de Nostr a GitHub a través de un retransmisor incluido en una lista blanca. Un colaborador sube una rama a una ubicación desde la que se pueda descargar y firma un event de Nostr; luego, un amigo con una cuenta de GitHub operativa abre la PR por él. La herramienta ayuda a colaboradores sin acceso a GitHub, pero no elude automáticamente una prohibición ni autoriza a ejecutar automáticamente parches no confiables.

Relay Radio

Relay Radio es una nueva aplicación web de solo lectura que convierte un feed de Nostr en directo en sonido mediante earcons y la síntesis de voz del navegador, con una región en vivo cortés opcional para usuarios de lectores de pantalla. Los oyentes eligen una emisora global seleccionada o una construida a partir de las personas a las que siguen, que abarca notas, respuestas, republicaciones, reacciones y zaps. Nunca publica ni paga en nombre del oyente. El filtrado de contenido se hace lo mejor posible, así que no puede garantizar que todo lo que se lee en voz alta sea seguro.

Hibiki

Hibiki es una napplet de feed independiente para Torii, y su código fuente considera la versión 0.2.1 su primer feed funcional. Un nodo obtiene publicaciones y archivos multimedia públicos, y la clasificación basada en los gustos del usuario se ejecuta en el navegador. El feed funciona en un iframe aislado sin acceso directo a la red y trata la reputación de spam firmada solo como una recomendación. No hemos verificado de forma independiente el límite de privacidad.

El código fuente fusionado hasta la versión 0.2.6 añade respuestas en línea y resúmenes extractivos de noticias, y los «me gusta» ya no reordenan las publicaciones. Sigue sin confirmarse una versión etiquetada. La compatibilidad con vistas previas en el reproductor Watch añade fotogramas de vista previa. Los zaps llegan junto con las páginas de perfil. El nodo comprueba el importe y el hash de descripción de cada factura. Cada pago requiere la confirmación del propietario; quien paga usa WebLN o un código QR. El nodo no custodia fondos ni claves. Las facturas de direcciones de Primal carecen del hash de descripción, por lo que un cambio posterior las acepta cuando el importe coincide exactamente. Se marcan como bound:false, y se advierte al propietario de que el monedero puede no confirmar. Esto debilita el vínculo entre la factura y la solicitud de zap y no las convierte en confirmaciones válidas de NIP-57. Los errores 5xx del monedero y los tiempos de espera agotados se reintentan una vez y muestran el motivo de LNURL. El autor no ha informado de ningún zap de extremo a extremo realizado con éxito con un monedero real.

wax

wax es un nuevo firmante en Common Lisp que deriva claves de rol a partir de una semilla BIP-39 y somete cada solicitud a una guarda de políticas, que deniega por defecto salvo que una función de aprobación o una lista de permitidos lo autorice. Las secuencias de sobres por llamante protegen contra la reproducción. Los nombres de sus métodos se parecen a los de NIP-46, pero el núcleo no ofrece ningún transporte de red. No hemos auditado la seguridad del firmante.

WhatZaps

WhatZaps es una nueva extensión de navegador que paga a contactos de WhatsApp por Lightning gracias al soporte de WebLN de la extensión Nostr WoT. Asocia un contacto con un perfil de Nostr, comprueba su dirección de pago y siempre pide una confirmación explícita antes de pagar. El comando /zap no se envía como mensaje de chat, y la vía de la reacción o el botón paga sin publicar nada. Son pagos Lightning que usan Nostr para buscar identidades, no recibos de zap firmados de NIP-57. No hemos probado su detección de mensajes en el navegador.

Encuestas cifradas de Agora

Agora es un prototipo de navegador para encuestas de grupo cifradas. Combina el aval entre miembros con boletos de voto ciegos y transporta el tráfico por relays de Nostr y WebRTC. El README plantea el diseño como una persona real, un voto, pero eso depende de confiar en el emisor de boletos, que puede fabricarlos, y en el aval como forma de confianza social. El diseño no ofrece resistencia a la coacción. Los relays pueden ver los tiempos y las direcciones IP; los resultados dependen de qué events reciba un cliente. El proyecto no tiene relación con el antiguo proyecto de chat ghobs91/Agora.

Cinderous SDK

Cinderous SDK v0.83.0 es un nuevo prototipo en código fuente que asigna a cada dispositivo su propia clave y sincroniza documentos con un historial al estilo de Git sobre Nostr y WebRTC, recurriendo a los relays cuando hace falta. Quien llama elige y despliega los relays, y el SDK no incluye ningún relay público predeterminado. Su cifrado usa un esquema experimental, CinderEK, con un Double Ratchet, que no ha pasado una auditoría externa. El intercambio de claves híbrido no hace que las firmas secp256k1 sean resistentes a la computación cuántica, y el README describe el SDK como no apto para producción.

evil-napplets

evil-napplets añadió los niveles 02 a 08 de su escalera de ataques para probar anfitriones que ejecutan napplets bajo el modelo de origen opaco del borrador NIP-5D. Las napplets maliciosas sondean los límites de capacidades y del puente e informan de lo que el anfitrión permitió. El modo de demostración es el predeterminado, y los modos activos deben habilitarse explícitamente. Las pruebas activas solo deben ejecutarse contra anfitriones que quien hace las pruebas esté autorizado a sondear. El conjunto es un banco de pruebas de red team, así que un anfitrión que lo supera no ha demostrado ser seguro. Es un proyecto distinto de evil-napps, que se dirige a otra arquitectura de apps.

evil-napps

evil-napps es un nuevo conjunto en código fuente que sondea los límites de autoridad en lanzadores NAPP. Abarca el puente del lanzador y el firmante NIP-07 expuesto a las apps. El almacenamiento SharedDB también entra en su alcance. Los paquetes NAPP combinan metadatos con un archivo índice, un formato distinto del artefacto HTML único que usan las napplets de NIP-5D. Según el README, el conjunto se ejecuta por defecto en modo de demostración y solo lanza sondeos activos cuando se solicita explícitamente. Sus pruebas y su entorno de ejecución no certifican ningún lanzador.

Feedstr

Feedstr es un nuevo lector RSS en Rust que sincroniza los feeds, el estado de lectura y los favoritos sobre Nostr de forma cifrada. La sincronización puede desactivarse para feeds concretos. Admite importación y exportación OPML y maneja artículos largos de NIP-23. El repositorio tiene árboles de código fuente para el núcleo, Android, web y Flatpak. El README dice que el software apenas se ha probado y que no se recomienda usarlo, y que las instrucciones de instalación y uso llegarán pronto.

Kit de herramientas para recibos de depósito NKIP

KYC-rip/nkip-0001 es un nuevo kit de herramientas en TypeScript, mantenido por XBToshi, para recibos de depósito NKIP-0001. NKIP-0001 es un formato de recibo de aplicación y no un NIP de Nostr aceptado. El kit maneja recibos de depósito firmados con Ed25519, compromisos con sal, events testigo de Nostr y la recuperación de la sal mediante cifrado NIP-44. Su protección depende de que la aplicación oculte la dirección de depósito hasta haber observado el testigo. El SDK no controla el paso de las órdenes ni garantiza los pagos. Los detalles están en el README.

nostr-parse

nostr-parse es un nuevo analizador en Rust de VectorPrivacy para events de Nostr firmados. Impone la forma estricta de event de siete campos, exige enteros no negativos, limita los kinds al rango u16, comprueba los campos hexadecimales y valida las cadenas con escapes. Los errores se notifican con desplazamientos. Quien llama puede producir asignaciones propias compactas o tramos prestados sobre la entrada, y parse_unsigned acepta rumores NIP-59 sin firmar. El análisis no recalcula el ID del event ni verifica la firma Schnorr, así que quien llama sigue teniendo que hacer esas comprobaciones por su cuenta.

cl-deposits

cl-deposits es una nueva implementación en Common Lisp de Bitcoin Deposits. En este diseño, un operador mantiene sobre Nostr libros contables firmados en cadena de hashes y cofirmados por un quórum, respaldados por reservas Taproot. El repositorio incluye el código fuente y una devnet con pruebas de inspección. Según el README y la ROADMAP, el autor ha reproducido los datos de prueba de referencia, ha ejecutado una devnet en signet y ha probado la interoperabilidad con deposits-rust en ambos sentidos. El autor también afirma que la ruta de recepción por Lightning funciona, y señala como siguientes pasos InvoiceLock y Fulfill para pagos. Los usuarios dependen del operador, del quórum de cofirmantes y de los supuestos sobre las reservas.

Streets

Streets, un cliente web de Nostr basado en columnas que muestra cronologías, notificaciones y búsquedas en paralelo, fusionó un cambio que guarda el emoji de reacción predeterminado en el documento de panel NIP-78 de la cuenta (kind 30078). Los usuarios ya no tienen que volver a elegirlo tras iniciar sesión de nuevo o en otro dispositivo. Antes, la elección se guardaba solo en el localStorage del dispositivo. El documento de panel está cifrado con NIP-44, así que la sincronización entre dispositivos exige iniciar sesión con una extensión o un firmante que admita cifrado. Los demás modos de inicio de sesión mantienen el ajuste en el dispositivo. Si una cuenta no tiene ninguna reacción guardada, se usa el valor existente del dispositivo, por lo que el ajuste no vuelve al corazón. Un valor guardado no válido se descarta sin desechar el resto del panel. El cambio está en el código fuente, y las notas de la versión 1.22.0 siguen siendo un borrador.

Labradorite

Labradorite es una app de Android para controlar sesiones de agentes de programación en un ordenador Linux emparejado, y ha publicado 0.1.0 y 0.2.0. El teléfono es solo la interfaz de control. Un daemon en el ordenador ejecuta el agente e intercambia mensajes MLS de Marmot a través de relays de Nostr corrientes, con un grupo por sesión. Solo acepta npubs incluidos en una lista de permitidos que está vacía por defecto (código fuente). La versión 0.1.0 inicia o reanuda sesiones aprobadas, transmite texto, llamadas a herramientas y diffs, y gestiona aprobaciones y preguntas. También ofrece controles de Git y exploración de archivos de solo lectura. La versión 0.2.0 pone en cola las peticiones de seguimiento como turnos separados, permite cancelarlas desde el teléfono, conserva el trabajo en cola tras reiniciar el daemon y reproduce el historial perdido tras reconectarse. Son afirmaciones del publicador, y no hemos auditado su seguridad de forma independiente.

Nomisma

Nomisma es un libro de gastos compartidos para Android en beta de prototipo que empareja a dos participantes mediante mensajes privados de Nostr. Solo registra saldos y no mueve ni liquida dinero. La versión 0.1.3 reconecta automáticamente los dispositivos emparejados, reintenta los cambios persistidos con esperas crecientes y añade autenticación de relays NIP-42. También reenvía las operaciones que faltan. Los dos dispositivos comparan una huella SHA-256 de las entradas, los pagadores y los repartos solo cuando sus relojes vectoriales por autor coinciden. Ambos dispositivos necesitan la 0.1.3 y la misma configuración de relays, porque cambió el relay predeterminado. Los puntos de control van envueltos en gift wrap con una caducidad NIP-40 de 15 minutos, que pide a los relays que los descarten pero no garantiza su borrado. Las notas informan de correcciones en la carga de bibliotecas nativas, el orden de los argumentos de Schnorr y la derivación de claves NIP-44, y no hemos auditado su seguridad de forma independiente. La firma del usuario pasa por Amber, pero en el dispositivo también existen claves efímeras. Las notas de distribución se contradicen sobre el certificado de firma del APK, así que no hemos valorado aquí la compatibilidad de las actualizaciones.

Onyx

Onyx es un prototipo de diario privado disponible como código fuente, no como una versión validada. Mantiene en el dispositivo archivos Markdown fechados como fuente de verdad y hace copias de seguridad en relays como events cifrados de kind 30078. Las d-tags con sal evitan exponer directamente las fechas de las entradas. La restauración requiere la clave de cifrado local, que es independiente, así que los usuarios deben guardar una copia de ella, porque el npub por sí solo no puede restaurar el diario. Un parche del 27 de octubre añade una guarda que comprueba la integridad de los campos de la solicitud antes de publicar: el kind, el contenido, la pubkey, las tags y la marca de tiempo del event que devuelve el firmante deben coincidir con la solicitud. El parche también rechaza descargas del autor equivocado, conserva las ediciones locales más recientes y sustituye los datos de forma atómica durante la restauración. Los autores y las marcas de tiempo de los events siguen siendo públicos. El texto plano que se pasa al comando de cifrado puede quedar expuesto brevemente a la inspección local de procesos, y borrar una entrada no elimina las copias en los relays.

Zzub

Zzub 0.0.41 es un cliente comunitario derivado de Buzz. Según las breves notas del publicador, esta versión añade confirmaciones de asistencia en el calendario con soporte de zonas horarias, zaps a perfiles, visualización de insignias NIP-58 y un botón de huddle que se une a una reunión en curso. Los controles de agentes ganan una opción de reinicio, la edición de una lista exenta de presupuesto y nuevos tipos de tarjetas de tareas. El arranque usa ahora canales en caché.

Trabajo en protocolos y especificaciones

NIP-CD define comandos invocados como texto plano

La especificación NIP-CD, titulada primero Commands y ahora Slash Commands, se fusionó en el repositorio de NIPs el 21 de octubre (revisión de la propuesta). Un ejecutor anuncia un comando en un event de kind 31992 que enumera su disparador, título, descripción, argumentos posicionales tipados y ámbitos. Los usuarios lo invocan como texto plano al principio del contenido del event, opcionalmente calificado con el npub del ejecutor, de modo que no se requieren tags específicas del comando ni soporte del cliente. Un disparador sin calificar puede coincidir con varios ejecutores. Los clientes pueden ofrecer autocompletado, pero no pueden exigirlo.

Marmot adopta varios dispositivos por cuenta

Marmot, un protocolo de mensajería de grupo cifrada para Nostr basado en MLS, fusionó sus reglas de cuentas multidispositivo (revisión de la propuesta) el 26 de octubre, en una forma revisada respecto al borrador anterior. Quien invita puede añadir como máximo 20 KeyPackages de una misma cuenta en un Commit. Cada dispositivo tiene exactamente una ranura de publicación aleatoria para toda su vida y nunca copia el estado MLS ni los KeyPackages privados. Los paquetes deberían durar 30 días, con una renovación a los 7 días. Quien invita envía a cada dispositivo elegible su propio Welcome, y eliminar una cuenta elimina todas sus hojas.

Marmot permite a los miembros gestionar las hojas de su propia cuenta

Marmot adoptó un componente de membresía de la misma cuenta, marmot.group.account-devices.v1 (ID 0x800d), que no lleva datos. Cuando la negociación del grupo exige el componente, un miembro puede confirmar Adds y Removes para su propia cuenta sin autoridad de administrador. Con este componente, el miembro no puede eliminar la hoja propia de quien confirma ni eliminar otras cuentas, y la condición de administrador de la cuenta no cambia. Los grupos existentes deben activar el componente y cumplir sus invariantes de soporte.

Los disparadores push de Marmot incorporan relleno nuevo

Marmot exige ahora relleno nuevo en cada disparador push, un cambio fusionado el 26 de octubre. Cada disparador de kind 446 lleva al menos un fragmento de relleno nuevo de 1.084 bytes generado con un CSPRNG, lo que deja como máximo 31 tokens cifrados reales dentro del presupuesto de 32 fragmentos. Sin relleno nuevo, unos bytes de token idénticos harían que la deduplicación por hash de contenido suprimiera notificaciones posteriores legítimas. Los servidores calculan el hash de todos los fragmentos y no deben rechazar un disparador estructuralmente válido por no poder detectar el relleno. El relleno oculta el número de tokens a los relays y a los observadores, pero el servidor de notificaciones que descifra todavía puede verlo.

Marmot añade la reparación de tokens push para miembros nuevos

Marmot fusionó la reparación de tokens push para miembros nuevos el 26 de octubre, y un cambio posterior aclaró su redacción final. El propietario del Commit que añade a quien se une debería enviar instantáneas de tokens activos de kind 448 y lápidas de eliminación de kind 449. Un conjunto opcional de huellas en un anuncio de kind 447 permite a los pares enviar solo los registros que faltan. Las tres hojas mejor clasificadas responden con temporizadores escalonados, bajo un límite de frecuencia de 24 horas por cada hoja que anuncia. Los registros firmados retransmitidos y las lápidas de eliminación conservadas reparan el estado de tokens que falta incluso cuando los propietarios están desconectados.

Propuesta de claves de Nostr custodiadas por passkeys

Una propuesta de claves de Nostr custodiadas por passkeys se basa en Nosskey, un esquema existente para usar passkeys con claves de Nostr. Unos identificadores etiquetados separan una identidad derivada mediante PRF/HKDF de una clave almacenada, y los registros cifrados de kind 31778 en los relays vinculan la parte confiante, el autor y la credencial. Los metadatos ausentes o desconocidos no deben crear silenciosamente una identidad nueva. La autorización del origen de la parte confiante sigue aplicándose, y los datos heredados de Nosskey necesitan un lector de migración explícito. Una identidad derivada se pierde con su passkey a menos que se respalde por separado.

Propuesta de delegación DNS para identificadores NIP-05

Una propuesta de delegación DNS sin fusionar para los identificadores basados en DNS de NIP-05 añade una alternativa que solo se aplica cuando la consulta HTTPS original devuelve 404 o 410. En ese caso, los clientes leen un registro TXT _nip05 que apunta a un proveedor HTTPS. Los tiempos de espera agotados, los fallos de TLS o CORS, las redirecciones y las discrepancias de claves nunca activan la alternativa, y el DNS no almacena claves. DNSSEC se recomienda pero es opcional, por lo que con un DNS sin firmar el TLS del proveedor no puede autenticar de forma independiente la autorización del dominio original. Los clientes antiguos no pueden resolver identificadores que solo funcionan mediante delegación.

Propuesta de catálogo de aplicaciones de software como NIP-82

Una propuesta de catálogo de aplicaciones de software usa NIP-82 como número propuesto en esa pull request abierta y sin fusionar; el número no se ha asignado ni adoptado. Reúne kinds para apps (32267), versiones (30063), recursos (3063), curación (30267), pruebas de titularidad de certificados (30509) y una lista de relays de catálogo (10067). Los recursos identifican su plataforma y su entorno de ejecución junto con un hash del archivo. Los recursos de Android añaden un hash del certificado de firma. Una firma de prueba demuestra que el publicador controla el certificado, y quienes lo leen deben seguir comprobando su caducidad y revocación.

Propuesta de URI BIP 321 como destinos de pago NIP-A3

Una propuesta sin fusionar que añade un tipo de pago bip321 a los destinos de pago NIP-A3 permite que un event de kind 10133 lleve una URI bitcoin: completa como instrucciones de pago estáticas y reutilizables. Como el destino se reutiliza, la propuesta no admite un importe ni un parámetro de factura BOLT11 de un solo uso lightning. Quien paga elige el importe y el monedero escoge un método de pago que admita, y se mantiene la alternativa de dirección Lightning.

Propuesta de zaps pagados mediante destinos BIP 321

Una propuesta de zaps pagados mediante destinos BIP 321 hace que el remitente pague el destino bip321 reutilizable NIP-A3 de un destinatario mediante Ark (un protocolo de Bitcoin fuera de la cadena), Lightning o en cadena, y después publique un zap de kind 9740. Quien posee la clave de recibos confirma la liquidación con un kind 9741. Ambos números de kind siguen siendo provisionales. La referencia del pago se cifra con el cifrado versionado NIP-44 hacia una clave de recibos que el destinatario decide activar, y solo esa clave puede confirmar el pago. Los terceros no pueden verificar los detalles del pago, así que la confirmación depende de confiar en la firma del destinatario. La propuesta no sustituye a los zaps de Lightning de NIP-57.

Propuesta de pagos Ark para Nostr Wallet Connect

Una propuesta de extensión Ark sin fusionar para Nostr Wallet Connect, el protocolo NIP-47 que permite a las aplicaciones controlar una cartera remota, añade una instrucción Ark al soporte existente de pago y cobro BIP 321 y un registro de pago Ark para lookup_payment, sin métodos nuevos. Una cartera usa la instrucción solo cuando admite la versión de dirección y la red y comparte el mismo servidor Ark. De lo contrario, prueba otra instrucción del URI. Los importes deben ser satoshis enteros, sin redondeo de milisatoshis, y los registros distinguen un pago cofirmado por el servidor de los fondos que el destinatario ha cobrado y puede gastar.

Propuesta de cabecera de pago Ark para servidores Blossom

Una propuesta de cabecera de pago Ark en Blossom, el protocolo para almacenar blobs multimedia en servidores HTTP, añade X-Ark a las respuestas HTTP 402 de pago requerido de BUD-07. La cabecera lleva un URI BIP 321 con una dirección Ark nueva para cada solicitud y el importe. De forma opcional, el URI incluye también el mismo pago como factura Lightning. Como prueba, los clientes reintentan con la dirección Ark pagada tras la liquidación. Los que recurrieron a la alternativa reintentan con la preimagen de Lightning. Una solicitud HEAD no se reintenta con prueba, y los clientes pasan al GET o al PUT.

Propuesta de cashtags para mencionar activos en notas

Una propuesta de cashtags define la tokenización opcional de $ seguido de entre dos y seis letras ASCII, excluyendo código, URL y referencias Nostr. Un único tag cashtag fija el modo de visualización y puede adjuntar un ID de activo elegido por el autor, ya que un ticker por sí solo no puede identificar un activo de forma única. Los lectores comprueban que el símbolo coincida con la cadena y la dirección, y señalan las discrepancias sin reetiquetarlas. Los tags opcionales t con la forma $ticker permiten la búsqueda estándar en relays.

Se retira la especificación gamepad de Napplet

El repositorio NAPs, donde se publican las especificaciones Napplet, fusionó la eliminación de la especificación de mando de juego (gamepad) el 27 de octubre. El cambio borra NAP-GAMEPAD.md y deshace la adopción anterior. Actualmente no hay ningún NAP de gamepad adoptado.

Los tags de altura de Cyberspace evitan colisiones con los tags de grupo

Cyberspace, un protocolo espacial construido sobre Nostr, fusionó varias de sus propias especificaciones, llamadas DECK. Son especificaciones del proyecto, no NIP oficiales. La especificación ahora renombra el tag de altura de bolsas y chat de h a H. El tag en minúscula chocaba con los tags de grupo de NIP-29 y hacía que los events se rechazaran o se clasificaran mal. Los lectores recurren a un h heredado solo cuando falta H. Esto cambia únicamente la especificación del proyecto. No modifica NIP-29 ni demuestra que los clientes desplegados interoperen.

Audio oculto en Cyberspace

DECK-0007 define el audio oculto como un archivo Blossom cifrado, referenciado por un rumor sin firmar dentro de una bolsa o un cofre firmados. Así, a quien lo escondió no se le atribuye mediante una publicación pública firmada por separado que pueda reproducirse. Cada colocación usa una clave y un texto cifrado nuevos, pero cualquiera puede compartir la clave igualmente. La especificación no afirma que el cifrado garantice la privacidad de quien lo encuentra ni que sus reglas de URL bloqueen todo SSRF, y el soporte en los lectores sigue en desarrollo.

Modelos públicos y animación en Cyberspace

Los objetos ya pueden referenciar modelos SNO públicos con animaciones de balanceo (bob) y giro (spin), y vuelven al renderizado anterior cuando un modelo no es válido o no está disponible. Los modelos en vivo pueden cambiar o desaparecer, y no se afirma una adopción amplia.

Especificaciones de objetos, chat y comentarios en Cyberspace

Los DECK opcionales 0004 a 0006 documentan código ya existente para objetos, cofres, listados, chat local cifrado y comentarios sellados, con vectores de prueba sintéticos. Varios problemas siguen abiertos. Las firmas de bolsas y cofres difieren, y los comentarios sellados exponen el ID y el kind del padre mediante tags públicos. Los poseedores pueden anular los listados. El chat tiene carencias frente a la repetición (replay) y en la vinculación al contexto, y las referencias a cofres no están implementadas. La documentación no corrige ningún problema de seguridad y no constituye un despliegue.

Propuesta de events con varios autores

Un artículo largo firmado, Multi-Author Nostr Events as a Soft Fork, propone events cuyo hash de ID abarca varias pubkeys de autor, y cada autor firma el mismo ID. Los clientes antiguos verían un envoltorio compatible con secp256k1 que transporta los datos de la nueva forma y tags Q como pistas de búsqueda. Los pares negociarían la nueva forma en cada conexión. El artículo generaliza la propuesta poscuántica anterior del autor, que añadiría una clave futura como un coautor más. Se trata de una propuesta sin número, no de un NIP aceptado. La sustitución de naddr en coautoría y el transporte binario siguen siendo cuestiones abiertas.

Las suscripciones de sincronización NIP-AR de Buzz envían una instantánea completa antes de las cabezas en vivo

Un pull request abierto de Buzz propone suscripciones de sincronización WebSocket NIP-AR (#8522). El relay enviaría un conjunto coherente de artefactos leído bajo REPEATABLE READ y emitiría EOSE solo cuando ese conjunto estuviera completo, para después transmitir en vivo las cabezas actuales; el registro en vivo en Redis ocurre antes de la lectura inicial. Una desconexión o un retraso de Redis termina la suscripción con CLOSED y obliga a resincronizar, y lo mismo ocurre con cambios de acceso, eliminaciones de contenido (redactions) o una cola llena. Las suscripciones tienen un tope de 4.096 artefactos, y el cambio no estaba fusionado en nuestra fecha de corte de fuentes ni disponible en producción.

Lecturas incrementales de artefactos NIP-AR por HTTP en Buzz

Otro pull request abierto de Buzz añade lecturas HTTP incrementales para artefactos NIP-AR (#8523). Los clientes paginan según las marcas de tiempo de modificación de la base de datos e ID estables, con un solapamiento de 120 segundos, y reciben la revisión actual o una eliminación. Pueden recuperar ID conocidos. Los resultados siguen un modelo de consistencia eventual. La propuesta no promete una instantánea completa, y la ausencia de un artefacto no significa borrado ni pérdida de acceso. Su revisión más reciente exige pertenencia o un alcance #h explícito para canales abiertos no listados, y un cambio de listado reinicia el progreso incremental. El interruptor de la funcionalidad, BUZZ_ARTIFACT_INCREMENTAL_ENABLED, está desactivado y exige que todos los escritores y migraciones (ahora de la 0074 a la 0076) estén implantados. Este retraso de 120 segundos es una suposición operativa. En nuestra fecha de corte de fuentes, el cambio seguía abierto.

Borrador de texto NIP-AM para lectores delegados de métricas

Un pull request de documentación en borrador de Buzz especifica lectores delegados para métricas NIP-AM sin cambiar la autorización en tiempo de ejecución (#8582). El event de kind 44200 cifrado para el propietario no cambia, y el agente emite una copia NIP-44 aparte para cada concesión activa, vinculada al ID exacto del event de concesión creado por el propietario. El kind de concesión propuesto, 30180, y los límites de lectores siguen siendo cuestiones abiertas, igual que el historial, la revocación y la vinculación pública. Una revocación firmada no puede borrar las copias que un destinatario ya tiene, y el borrador no estaba fusionado en nuestra fecha de corte de fuentes.

DECK-0003 permite que un padre lleve los objetos que coloca

Un pull request abierto de Cyberspace propone la §1.10 de DECK-0003, una tabla raíz de cargas útiles de objetos SNO en línea (#81). Una entrada presente en la copia del padre prevalece sin descarga por red, incluso cuando no es válida. Cada entrada se limita a la pubkey del autor, con tamaño y profundidad acotados además de límites de ciclos. Los lectores antiguos descargan los objetos que faltan y muestran un marcador de posición. La propuesta describe implementaciones en espera de este cambio, que no estaba fusionado en nuestra fecha de corte de fuentes.

DECK-0004 define puertas ligadas a la altura con claves de sala derivadas

Un pull request abierto de Cyberspace añade las §3.6 y §3.7 de DECK-0004 sobre aspectos y puertas (#82). Las puertas están ligadas a la altura, y la clave de la sala es SHA-256(separador de dominio ‖ clave de ubicación ‖ secreto de la puerta), con la bolsa de la sala cifrada con ella. Las salas pueden tener puertas múltiples o anidadas, y fijar una cerradura nueva rota la clave. El texto no tendrá vectores de prueba hasta que exista una primera implementación, y no estaba fusionado en nuestra fecha de corte de fuentes.

Extensión de anuncio de peering en NIP-11 para nostream

Un pull request abierto de nostream ampliaría el documento NIP-11 del relay con una sección de peering (#999). Anuncia kinds de feed con límites temporales y condiciones de liquidación, junto con un endpoint de contacto y prueba de trabajo para el peering. Solo enabled: false desactiva la sección, y unas condiciones vacías significan peering sin liquidación. Una oferta anunciada no es un par aceptado. El cambio no implementa ningún acuerdo entre pares ni federación de pago. No estaba fusionado en nuestra fecha de corte de fuentes.

NIP-CD añade listas opcionales de comandos instalados

Una continuación de NIP-CD se fusionó en la rama por defecto de NIPs el 27 de octubre (fusión), y la especificación se titula ahora Slash Commands. Define una lista opcional de kind 10992, conforme a NIP-51, en la que un usuario guarda tags de dirección que apuntan a definiciones de comandos de kind 31992, cada una identificada por la pubkey del ejecutor y el valor d, con una pista de relay opcional. Los usuarios pueden mantener la lista, y los clientes deberían usarla para el autocompletado y los chips renderizados. La lista es una preferencia de visualización y descubrimiento. No autoriza a los ejecutores, y la invocación en texto plano sigue funcionando sin ella, sin tags específicos de comandos ni soporte obligatorio en los clientes. NIP-CD sigue siendo un borrador opcional, y la fusión no muestra qué clientes han adoptado la lista.

Marmot acota su regla de preparación equitativa para dispositivos de cuenta

Marmot fusionó el 28 de octubre una corrección de su regla de planificación para grupos que requieren dispositivos de cuenta. Después de que una pasada de convergencia acotada alcance Stable, una intención en cola autorizada por un administrador, o una intención permitida de la misma cuenta, obtiene un intento de preparación antes de que el trabajo entrante en cola pueda forzar por sí solo otra pasada. SelfUpdate y Leave quedan fuera de esta garantía adicional de equidad, aunque cualquier miembro puede seguir haciendo su commit. El cambio corrige una redacción anterior que abarcaba toda intención autorizada, y los grupos que no requieren dispositivos de cuenta mantienen su planificación anterior. No hay cambios en el formato de transmisión, y un intento de preparación no garantiza un Commit válido, aceptado o canónico.

Marmot propone un roster oculto de dispositivos para grupos de cuenta

Una propuesta abierta de Marmot, sin fusionar, añadiría un componente device-roster-v1 con ID 0x800e para un grupo oculto cuyas hojas pertenecen todas a una misma cuenta. Un grupo lleva el roster desde su creación o no lo lleva nunca. El roster registra dispositivos, ranuras rechazadas, KeyPackages rechazados y mapas de hojas, y es el primer componente que usa actualizaciones diferenciales explícitas e independientes del orden, aplicadas al padre candidato. Las ranuras eliminadas pueden conservar mapas de hojas para grupos de los que sus hermanas no pueden eliminarlas. Un dispositivo confía en un grupo de dispositivos solo si lo creó o si se unió mediante un Welcome autenticado por un vínculo confirmado, de modo que el marcador 0x800e por sí solo no otorga confianza. El Add fundacional nombra el KeyPackage exacto del vínculo confirmado. Un dispositivo vinculado robado puede editar el roster hasta que se elimine. El límite de dispositivos se aplica a los dispositivos. Los registros de mapas de hojas y de rechazos tienen límites de tamaño por entrada, pero ninguno sobre el número de registros. Los datos del roster nunca se copian a otras cuentas, y el grupo permanece oculto en chats, recuentos, notificaciones y destinos. Según el texto, MDK mantiene los bytes del roster tras un interruptor de pruebas, sin nueva interfaz ordinaria.

Marmot propone avisos más claros cuando falla la activación de dispositivos de cuenta

Otra propuesta abierta de Marmot, sin fusionar, permitiría a los clientes explicar los fallos de activación de dispositivos de cuenta. Un cliente puede informar de que un grupo no puede activar dispositivos de cuenta. Ese aviso a nivel de grupo no puede nombrar a los miembros ni a los dispositivos que lo bloquean. Un miembro que no es administrador activo solo sabe que carece de estatus de administrador. Si se pierde una selección de rama o falla una comprobación de activación regenerada, el usuario debe hacer una solicitud nueva. El cliente nunca reintenta la activación automáticamente. No cambia la regla existente según la cual la activación requiere una solicitud nueva del usuario desde un cliente autorizado. Es texto normativo en borrador y no refleja un comportamiento implementado ni desplegado.

Marmot propone verificación por emoji para emparejar dispositivos nuevos

Una propuesta abierta de Marmot, sin fusionar, describe el emparejamiento de un dispositivo nuevo mediante un intercambio inspirado en m.sas.v1 de Matrix, con X25519, HKDF y HMAC. El usuario compara siete emoji etiquetados en ambas pantallas y no lee ni teclea ningún código. Poseer la clave de la cuenta nunca autentica un dispositivo. Cinco rumores sin firmar (Request, Answer, Reveal, Confirm y Cancel) se envuelven hacia la pubkey de la cuenta y vinculan la cuenta, la sesión, el nuevo KeyPackageRef, la ranura del dispositivo existente y claves nuevas. El dispositivo existente confirma primero y añade exactamente el KeyPackageRef confirmado. El dispositivo nuevo confirma solo después de verificar, y acepta un Welcome únicamente para el ID de grupo autenticado por el intercambio confirmado. Se proponen los kinds 452 a 456, con 457 a 489 reservados. Quien posea la clave de la cuenta aún puede falsificar Cancel para denegar el servicio, incluso después de la confirmación. El límite horario de Answer no persiste entre reinicios. Los relays pueden ver la ráfaga de envoltorios y la dirección de la cuenta; algunos casos de fusión y de Welcome siguen aplazados. Las implementaciones mantienen estos formatos desactivados por defecto, y dos vectores de respuesta conocida aportados por el autor no constituyen una auditoría independiente de seguridad ni de interoperabilidad.

La propuesta de napplets NIP-5D endurece los campos de medios y de código fuente

La propuesta abierta de napplets NIP-5D ya se describió anteriormente. Sus cambios del 28 de octubre se han fusionado ahora en la rama de la propuesta, no en la rama por defecto de NIPs, y revisan los campos opcionales de medios y de código fuente introducidos el 17 de octubre. Los tags de captura de pantalla y de vista previa reutilizan ahora los campos clave-valor de NIP-92, con un valor x SHA-256 en minúsculas obligatorio y m, dim, size, alt y duration opcionales. Los lectores deben verificar el hash y decodificar el formato real antes de renderizar. Si hay un campo m válido, el formato decodificado también debe concordar con ese tipo MIME. Se ignoran las entradas con x ausente, repetido o incorrecto; los campos opcionales incorrectos se descartan sin desechar otros medios utilizables, y las vistas previas múltiples se ignoran. Un source-commit debe resolverse en un ID de Git completo y exacto, y los archivos de código fuente por HTTPS necesitan una coincidencia SHA-256 exacta a nivel de bytes. Los campos de código fuente duplicados o malformados se ignoran, y los datos de código fuente inutilizables no deben bloquear la reproducción del HTML. Que un commit o un archivo coincidan no demuestra una compilación reproducible, y no se afirma la conformidad de ningún cliente.

Seis años de octubres en Nostr

A lo largo de seis octubres, los cambios fechados de Nostr se desplazaron desde el encuadre de los mensajes hacia las aplicaciones construidas sobre él. En 2021, la especificación básica estableció que los mensajes de los clientes se encuadran como arrays JSON de nivel superior. Los octubres siguientes trajeron la búsqueda en clientes y las facturas Lightning, las pruebas de marca de tiempo y las solicitudes de trabajo, las variantes multimedia y las carteras de ecash, y después la colaboración en código y los metadatos de los mensajes privados. Otros cambios de esos mismos meses hicieron que identidades y conexiones fueran más fáciles de llevar de un programa a otro, desde el estado visible de los relays hasta las claves de firmante separadas y el emparejamiento de carteras. Este octubre, el mismo documento definió con qué coincide una lista de filtro vacía, de modo que los relays que leen un JSON idéntico tienen ahora una regla común sobre qué events selecciona.

Octubre de 2021: un transporte sin ambigüedades

El 4 de octubre, NIP-01, la especificación básica del protocolo, se revisó para que los mensajes de los clientes sean arrays JSON de nivel superior. Los prefijos informales EVENT, REQ y CLOSE pasaron a ser el primer elemento de cada array, y se eliminó el requisito de la ruta fija /ws, así que valía cualquier endpoint WebSocket. Esto aclaró una especificación que ya tenía código detrás. Los clientes escritos de forma independiente necesitan un encuadre exacto antes de que pueda interoperar algo más sofisticado.

El 23 de octubre, la dirección de relay a cliente incorporó mensajes EVENT y NOTICE explícitos. Un EVENT del relay lleva el identificador de una suscripción REQ existente, de modo que un cliente que mantiene varias suscripciones sobre una sola conexión puede emparejar resultados con solicitudes, y NOTICE lleva texto legible por humanos. Un vocabulario tan reducido resulta práctico de implementar más de una vez, lo que encaja con relays operados por separado.

El texto de NIP-01 del 23 de octubre también muestra qué cubre una firma. Cada event tiene como ID un resumen de un array JSON compacto en UTF-8 que contiene un cero inicial, la clave pública del autor, la marca de tiempo, el kind, los tags y el contenido, y el autor firma ese resumen con una firma Schnorr sobre la curva secp256k1. El sobre WebSocket y el identificador de suscripción quedan fuera de esos datos firmados. De ese texto se deduce que el mismo event firmado puede llegar por suscripciones distintas, o por conexiones distintas, sin volver a firmarse. Un REQ devuelve primero los events almacenados que coinciden y luego permanece activo hasta que el cliente envía CLOSE, cierra el socket o reutiliza el ID de suscripción para un REQ nuevo. Todas las condiciones de un mismo filtro deben cumplirse, mientras que varios filtros en un REQ coinciden con los events que satisfacen cualquiera de ellos. Los nombres de los filtros de esa versión difieren de los actuales. El comportamiento de NOTICE quedó sin especificar, y nada garantizaba cuánto tiempo conservan los relays los events ni que una consulta los devuelva todos. Cinco años después, la misma especificación volvería sobre el significado de los filtros dentro de REQ.

Octubre de 2022: un feed se vuelve usable en el teléfono

El 8 de octubre, Damus, un cliente Nostr para iOS, añadió búsqueda de hashtags, perfiles y events. El cambio afectó a su vista de resultados de búsqueda y a su modelo de hilos, y permitió al lector saltar a una identidad firmada o a un event concreto, además de desplazarse por el texto entrante. Esta búsqueda funcionaba dentro de la propia navegación del cliente y no era una búsqueda de texto completo en el relay.

Ocho días después, Damus sustituyó las filas simples de su configuración de relays por una vista que muestra el estado de cada conexión. Un punto de color se basa en el pool de relays del cliente. Verde significa conectado, y amarillo, conectando o reconectando; el rojo indica cualquier otra cosa, y el gris aparece antes de la primera lectura. La vista se actualiza al aparecer y, a partir de ahí, cada dos segundos. El gesto de deslizar para borrar, que ya existía, pasó a la nueva vista. Con los puntos a la vista, un feed detenido ya no tenía por qué interpretarse como el silencio de un autor, porque el lector podía ver cuál de varias conexiones independientes estaba activa y cuál estaba reintentando. Un punto verde indica un socket abierto. No indica que un relay haya aceptado o conservado un event. Tampoco indica que una consulta haya devuelto todo lo que guarda el relay. El commit registra la implementación en código fusionado. Este cambio de código no establece ninguna fecha de publicación en la App Store.

El 19 de octubre, Damus añadió un analizador de facturas Lightning BOLT11 y widgets de factura en publicaciones, chats y mensajes directos. En el widget se muestran la descripción de la factura y el importe en satoshis, y su botón Pagar pasa el URI lightning:, a través de iOS, a un gestor instalado. El cliente social presenta la publicación firmada, y una cartera independiente realiza el pago. Estos widgets son anteriores a la convención posterior de recibos de zap, así que son visualizaciones de facturas, no zaps estandarizados.

Octubre de 2023: los events llevan pruebas y solicitudes de trabajo

El 11 de octubre, las atestaciones OpenTimestamps de NIP-03, que anclan en Bitcoin pruebas sobre los events, pasaron de un campo ots del event a un event aparte de kind 1040. Ese event nombra el original con un tag e y lleva en su contenido el archivo OpenTimestamps completo en base64, con al menos una atestación de Bitcoin. El id del event referenciado es en sí mismo el resumen que atestigua la prueba, de modo que un verificador sabe que el event existía en el momento atestiguado. Ese momento procede de Bitcoin, no del created_at del autor. La prueba fecha el event y no afirma nada sobre su contenido.

El 12 de octubre, sin relación con el cambio de marcas de tiempo, la derivación de claves de NIP-06 incorporó dos vectores de prueba. Un mnemónico es una secuencia de palabras que codifica una semilla de recuperación, y los vectores cubren un mnemónico de 12 palabras y otro de 24, cada uno con sus claves privada y pública esperadas en hexadecimal y en las codificaciones nsec y npub. NIP-06 ya usaba BIP-39 para convertir el mnemónico en una semilla binaria y la ruta BIP-32 m/44'/1237'/<account>'/0/0 para derivar una clave, con la cuenta cero como opción básica de clave única. La incorporación de octubre aportó respuestas conocidas, no recuperación de mnemónicos ni un nuevo algoritmo de derivación. Ahora un cliente puede comprobar que su derivación y sus codificaciones reproducen la identidad documentada. Coincidir con los vectores hace comparables las implementaciones. No certifica ninguna implementación concreta ni demuestra que todas las importaciones de carteras y clientes concuerden. Proteger una semilla frente al robo es otra cuestión que los vectores no abordan.

El 29 de octubre, NIP-90, el estándar de máquinas expendedoras de datos (data vending machines), se fusionó en el repositorio de NIPs con kinds de trabajo fijos. Reservó los kinds 5000 a 5999 para solicitudes de trabajo y fijó cada kind de resultado en el kind de la solicitud más 1000. Para la retroalimentación se usaba el kind 7000. Una solicitud puede apuntar a texto, URL o trabajos anteriores. También puede indicar la salida esperada y ofrecer una puja opcional. Así, la tarea vive en events firmados a los que cualquier proveedor puede responder, fuera de la API de un único proveedor. Un borrador anterior había usado los kinds 68001 y 68002.

Octubre de 2024: alternativas multimedia y ecash portátil

El 15 de octubre, los events de vídeo de NIP-71 adoptaron tags imeta para las variantes de vídeo. En los kinds direccionables vigentes entonces, 34235 y 34236, la URL, las dimensiones, el tipo MIME, la imagen de vista previa y las alternativas de cada variante iban juntas en un solo tag. Un cliente que elige una resolución necesita saber qué miniatura y qué alternativa le corresponden, y los metadatos aplanados no podían indicarlo. Esos números de kind son históricos: el NIP-71 actual usa los kinds 21 y 22.

Diez días después, las carteras Cashu de NIP-60 y los nutzaps de NIP-61, ambos presentados en borradores anteriores, se fusionaron juntos como especificaciones. Se basan en Cashu, un protocolo de ecash cuyos tokens emiten casas de emisión (mints). NIP-60 guarda en relays las pruebas cifradas de la cartera, de modo que las aplicaciones compatibles pueden acceder al mismo estado de cartera. Con NIP-61, el event de kind 10019 de un destinatario enumera mints de confianza, relays y una clave de bloqueo, y el event de kind 9321 de un remitente lleva pruebas bloqueadas con esa clave para que el destinatario las canjee. Los usuarios siguen dependiendo de los mints que emiten los tokens, y las aplicaciones deben protegerse frente al canje doble de las mismas pruebas.

El 29 de octubre, la firma remota de NIP-46, en la que un servicio independiente guarda la clave que firma en nombre del usuario, se revisó para que una cadena de conexión bunker:// lleve la clave pública del firmante remoto. La identidad del usuario se obtiene por separado: el texto revisado exige que los clientes distingan ambas claves y llamen a get_public_key tras conectarse. El cliente genera su propio par de claves para la conversación y dirige sus solicitudes cifradas a la clave del firmante, mientras que sign_event devuelve un event firmado con la clave del usuario. Esas dos claves pueden coincidir, pero no tienen por qué. La clave de la cadena de conexión identifica solo al servicio firmante. La cuenta del usuario es la clave pública que devuelve get_public_key. NIP-60 había abordado el estado compartido de la cartera cuatro días antes; esta revisión aborda una cuestión distinta, la identidad del firmante. Los ejemplos de ese commit aún usan el transporte cifrado que NIP-46 especificaba entonces, y el cambio ni hace que un firmante remoto deje de requerir confianza ni demuestra quién tiene la clave del usuario.

Octubre de 2025: novedades en colaboración y metadatos de mensajes privados

El 8 de octubre, Nostr Wallet Connect de NIP-47 incorporó enlaces profundos para emparejar una aplicación con una cartera. Una cartera puede registrar nostrnwc://connect o un nostrnwc+{app_name}://connect específico de la aplicación, y la aplicación solicitante abre ese enlace con su icono codificado como URI, su nombre y un esquema de retorno (callback). Una vez creada la conexión, la cartera abre el callback con un parámetro value que contiene el código de emparejamiento, un URI nostr+walletconnect://. Tres años después de que Damus entregara facturas a una cartera a través de iOS, emparejar en un mismo teléfono ya no obligaba a escanear un código QR mostrado en la misma pantalla ni a copiar una cadena larga entre aplicaciones. La incorporación cubre solo esta transferencia. No cambia ningún método de pago ni paga nada por sí misma. Ambas aplicaciones deben implementar los gestores, y el texto de la especificación no prueba que todas las carteras lo hagan. Tampoco resuelve los presupuestos de gasto, las pantallas de consentimiento ni qué aplicación puede apropiarse con seguridad de un esquema de callback.

El 16 de octubre, la colaboración git de NIP-34 incorporó events de pull request de kind 1618 y de actualización de kind 1619 junto a sus events de parche existentes. Un pull request nombra la punta de un commit y ubicaciones de clonado, y una actualización mueve esa punta. Se recomiendan parches por debajo de 60 kB, y pull requests para envíos mayores. Esto desplazó la vía recomendada para los envíos grandes, de cuerpos de parche transportados dentro de events a referencias firmadas a commits, mientras que los cambios pequeños aún pueden viajar como parches. Nostr transporta la coordinación y las referencias firmadas, y los servidores Git siguen proporcionando los objetos commit a los que apuntan esas referencias.

El 27 de octubre, el gift wrap de NIP-59 incorporó la recomendación de aleatorizar de forma independiente las marcas de tiempo del sello y del gift wrap cuando se añaden tags de expiración. El gift wrap encierra un mensaje en esas dos capas, y dar a cada capa su propia marca de tiempo aleatoria reduce el grado en que puede correlacionarse la temporización de ambas. Aquí la atención pasó de cifrar el contenido a limitar lo que puede revelar la correlación de metadatos. El cifrado oculta el mensaje en sí, pero la temporización y otros metadatos que rodean al sobre siguen siendo observables, y las decisiones de implementación determinan con qué facilidad pueden vincularse. La recomendación no añade cifrado nuevo ni hace anónimos a los participantes.

Octubre de 2026: significados de consulta compartidos y servicios activados por texto

El 5 de octubre, los adjuntos multimedia de NIP-92 extendieron los tags imeta a los perfiles de kind 0, lo que permite a un perfil describir su picture y su banner con URL alternativas, un blurhash (una codificación compacta de una vista previa difuminada), dimensiones, texto alternativo y otros metadatos de adjuntos. NIP-92 ya existía antes de este cambio; lo nuevo es que los metadatos agrupados que NIP-71 aplicó a las variantes de vídeo en 2024 llegan ahora a las imágenes de perfil. La asociación es exacta. Un tag solo se aplica cuando su URL es igual a la URL de la imagen de perfil o del banner; los clientes DEBERÍAN (SHOULD) ignorar los tags que no coincidan con ninguna, y DEBERÍAN probar las alternativas cuando falle la URL principal. Como un nuevo event de kind 0 sustituye al perfil anterior, un publicador DEBERÍA conservar los metadatos de una imagen sin cambios y eliminar los tags de imágenes que ya no se usan, para que un texto alternativo o unas dimensiones obsoletos no describan en silencio otra imagen. Esa regla de actualización importa tanto como los campos nuevos. Un tag imeta no garantiza que una imagen siga disponible ni que cargue más rápido. Tampoco ofrece protección de privacidad, y los clientes no tienen por qué renderizar todos los campos.

El 17 de octubre, NIP-01 se aclaró para que una lista vacía en un filtro no coincida con ningún event, algo distinto de omitir el atributo. Una continuación eliminó la redacción incoherente de «uno o más» y recomendó que los clientes eviten enviar listas que no pueden coincidir. En octubre de 2021, este documento fijó el encuadre de los mensajes JSON de REQ: el mensaje REQ es un array, y cada filtro es un objeto JSON dentro de él. Este octubre fijó la semántica de los filtros al determinar qué significa una lista vacía dentro de un filtro así, ya que relays que analizan la misma trama de forma idéntica aún podían devolver resultados distintos.

El 21 de octubre, NIP-CD, entonces titulado Commands, pasó de propuesta a especificación en borrador fusionada; describe los comandos de barra (slash commands). Los events de kind 31992 definen comandos, y una invocación es texto plano que empieza en el primer carácter del contenido de un event, así que los clientes no necesitan soporte especial para enviarla. Una propuesta de continuación, con un commit anterior en una rama aparte, se fusionó el 27 de octubre. Cambió el título de la especificación a Slash Commands y añadió listas opcionales de comandos instalados de kind 10992 que los clientes deberían usar para el autocompletado y el renderizado. Las listas registran una preferencia del usuario y no autorizan a los ejecutores ni condicionan la invocación en texto plano. Los trabajos de NIP-90 usan events estructurados de solicitud y resultado, mientras que un comando sigue siendo legible como texto ordinario.