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

Esta semana: Amethyst 1.13.1, tras el lanzamiento de las aplicaciones Nostr en la versión 1.13.0, incorpora autenticación del relay anfitrión NIP-29 y reintentos autenticados de descargas de Blossom. Code Call permite mantener en marcha sesiones remotas de programación desde un teléfono, GitWorkshop coordina a los responsables de mantenimiento y la sincronización de repositorios, y Mosaico ofrece a los agentes de programación una capa compartida de visibilidad sobre la actividad en Nostr. Nostrology cartografía cómo los perfiles distribuyen las funciones de lectura y escritura entre sus listas de relays publicadas. Los lanzamientos para Android de Mafrend, Hanami y Cordn encabezan los lanzamientos etiquetados, mientras FIPS añade una capa de acceso para OpenWrt y un PR abierto propone una adaptación para FreeBSD. Las novedades sobre protocolos abarcan NIPs, BUDs, NAPs, Marmot, Gamma Markets, Concord y NWC, mientras Seis julios en la historia de Nostr recorre los cambios de julio desde las primeras búsquedas de dominios hasta el estado de los grupos de relay.

Historias principales

Amethyst 1.13.1 añade acceso autenticado a grupos y a Blossom tras el lanzamiento de sus aplicaciones Nostr

Amethyst 1.13.0, publicado el 28 de julio para el cliente Nostr de Android y multiplataforma, abre napplets y nsites NIP-5A dentro de un proceso de navegador aislado y sin claves. Un puente window.nostr sujeto a consentimiento puede firmar y usar capacidades seleccionadas mediante la cuenta activa, mientras las pantallas de permisos por sitio y por cuenta permiten a los usuarios revisar o revocar esas concesiones. Las aplicaciones favoritas pueden permanecer fijadas en la barra inferior sin compartir cookies, estado de inicio de sesión ni concesiones entre cuentas.

El mismo lanzamiento 1.13.0 añade árboles de repositorios Git, incidencias y pull requests junto con comunidades Concord, grupos de relay NIP-29, chat grupal de Buzz, páginas wiki y feeds RSS. Estas superficies permiten al usuario moverse entre vistas de código, comunidad, publicación y actividad social con la misma identidad Nostr.

Los pagos y la identidad también se ampliaron en la versión 1.13.0. Amethyst puede crear y pagar ofertas BOLT12, iniciar automáticamente cuentas con firmante remoto, añadir servidores Blossom de respaldo y ampliar los controles de Web of Trust para insignias, comunidades y grupos de relay. La actualización 1.13.1 del 29 de julio añade un sello de disolución CORD-02, eliminación de grupos y canales con kind 9008, autenticación del relay anfitrión NIP-29 y reintentos BUD-01 autenticados para descargas de Blossom con acceso restringido.

Code Call 0.2.68 añade un explorador de carpetas de workers después de que 0.2.66 introdujera la puesta al día

Code Call 0.2.68, un control remoto para Android de sesiones de programación ejecutadas en un ordenador, sustituye su lista específica de espacios de trabajo por un explorador de carpetas con raíz en el directorio del worker. El usuario puede entrar en carpetas permitidas anidadas, seleccionar una para una sesión de OpenCode y volver a las carpetas superiores; la versión 0.2.67 abre ese explorador cuando se inicia una sesión.

El lanzamiento 0.2.66 anterior puede pedir a un worker enrutado una puesta al día concisa a partir del último mensaje del teléfono. Otros lanzamientos de la misma semana mantienen independientes varias sesiones, aceptan respuestas únicamente del remitente esperado y mantienen la bandeja de entrada conectada a cada relay de worker configurado para la entrega en segundo plano. Las solicitudes y respuestas viajan dentro de NIP-17 (Mensajes directos privados), mientras los archivos adjuntos de Blossom cifrados localmente conservan su tipo de archivo original después de descifrarlos.

GitWorkshop coordina a los responsables de mantenimiento y mantiene independiente la sincronización de repositorios

El lanzamiento firmado de GitWorkshop del 27 de julio añade inicio de sesión en Android mediante NIP-55 (Aplicación de firma para Android) a la forja web NIP-34 (elementos de git). Su repositorio de código fuente ahora coordina de forma recursiva a los responsables principales de mantenimiento, conserva las sugerencias de relay de cada responsable y mantiene la sincronización del repositorio independiente de la aceptación de invitaciones. Las referencias a elementos de trabajo entre repositorios conectan trabajos relacionados, mientras GRASP copia datos del repositorio en endpoints Git seleccionados sin vincular esa transferencia a la entrega de invitaciones. La actualización 3.1.1, firmada por el desarrollador, repara la entrega de intents de Android al firmante, la resolución recursiva de responsables de mantenimiento y los enlaces de repositorio que preservan las rutas.

Mosaico 0.1.2 permite que los agentes de programación compartan su estado mediante Nostr

Mosaico 0.1.2 permite que las sesiones de agentes de programación en Claude Code, Codex, Goose, Hermes, OpenCode y Grok publiquen actualizaciones breves de estado mediante NIP-29 (Grupos basados en relays). Las sesiones pueden encontrar trabajo activo relacionado entre hosts sin compartir sus transcripciones ni su contexto.

El descubrimiento de perfiles de Codex por nombre y la vista Top Of Mind de Goose muestran ese estado compartido dentro de ambos entornos (PR #618, PR #619). El lanzamiento restaura la capacidad de los agentes alojados para incorporarse a la capa pública de visibilidad sobre la actividad, y la configuración ahora exige elegir explícitamente un relay (PR #626, PR #629). Mosaico sigue siendo una capa de visibilidad sobre la actividad, no un host de agentes, un orquestador ni un sistema para combinar transcripciones.

Nostrology cartografía la concentración de listas de relays a partir de events NIP-65 publicados

El observatorio de relays de Nostrology deriva su conjunto de datos del event kind 10002 más reciente de cada perfil conforme a NIP-65 (Metadatos de listas de relays), siguiendo la especificación publicada. Separa las funciones de lectura, escritura y combinadas de los relays, muestra en gráficos cuántos relays enumera cada perfil y expone los recuentos subyacentes en una tabla ordenable. En la revisión de publicación del 29 de julio, la página contenía 34.430 valores distintos de URL de relay y agrupaba 520.468 perfiles con exactamente un relay enumerado, frente a 150.657 con tres y 60.710 con cuatro.

La misma captura de Nostrology muestra una concentración superpuesta en torno a relay.momostr.pink con 298.859 perfiles, relay.damus.io con 287.181, nos.lol con 279.468 y relay.primal.net con 225.336. Estos recuentos miden entradas publicadas en listas de relays, no disponibilidad: la tabla sin procesar puede incluir URL malformadas y direcciones locales, mientras la especificación NIP-65 define metadatos de enrutamiento y no comprueba el estado de los relays. El observatorio hace visibles los problemas de adopción y calidad de datos sin asumir que cada relay incluido esté activo.

Lanzamientos etiquetados

Kairos 0.1.1 añade recordatorios y una instrucción local para Astraea

Kairos 0.1.1 añade recordatorios de fechas límite, una instrucción local explícita para Astraea y un manejo más estricto de relays y URL. El lanzamiento firmado 0.1.0 introdujo el gestor de tareas con prioridad al funcionamiento sin conexión, cuya capa opcional de sincronización escribe registros cifrados mediante NIP-44 (Cargas útiles cifradas) en relays seleccionados por el usuario. Kairos usa coordenadas deterministas de tareas y lápidas cifradas con solicitudes de eliminación NIP-09 (Solicitud de eliminación de events), mientras las tareas exclusivamente locales nunca salen del dispositivo.

Bray 2.3.0 permite aplicar Gift Wrap a cualquier event desde su CLI y añade un entorno local de pruebas para Blossom

Bray 2.3.0, un SDK de Nostr y conjunto de herramientas de línea de comandos, puede envolver y desenvolver cualquier event mediante NIP-59 (Gift Wrap), con la firma enrutada mediante NIP-46 (Nostr Connect) cuando un bunker conserva la clave. El PR #75 también dota al relay de pruebas incluido de desafíos NIP-42 (Autenticación de clientes ante relays) y expone los comandos restantes del cliente Blossom. El PR #77 añade un servidor BUD-01/02 en memoria cuya autorización firmada vincula cada carga o eliminación a un único blob, mientras el PR #76 añade event kinds con nombre, tags abreviados y opciones de reconciliación de ID de NIP-77 que evitan descargar events que el solicitante ya posee.

Buzz Desktop 0.5.0 refuerza las invitaciones, la búsqueda y las actualizaciones de identidad en relays

Después de la cobertura de la semana pasada sobre los espacios de trabajo de Armada y Buzz, Buzz Desktop 0.5.0 añade enlaces de invitación con un límite de usos (PR #3141) y filtros de búsqueda por autor, canal e intervalos temporales (PR #2871). El PR #2862 obtiene políticas de incorporación mediante la capa de red nativa de la aplicación de escritorio, y el PR #2607 vuelve a publicar el registro de identidad de un agente después de que el cambio de nombre de un perfil llegue al relay. El lanzamiento también actualiza su dependencia de Nostr a raíz de un aviso sobre denegación de servicio remota en NIP-44 y repara la recuperación del almacenamiento local, la posición en hilos, la reconexión de relays y las rutas de ejecución de Linux y Windows.

Shosho 1.0.0 amplía su mercado de transmisiones en directo

Shosho 1.0.0 rediseña el mercado de transmisiones en directo en torno a creadores, sesiones en directo, clips y productos que los usuarios pueden encontrar mediante búsquedas configurables en relays. Un feed unificado de notificaciones reúne ahora menciones, reacciones, republicaciones y zaps, y permite responder sin salir del feed. Los espectadores pueden publicar clips de transmisiones en directo o repeticiones, mientras el lanzamiento también mejora el chat con hilos, las respuestas a clips, la carga de perfiles y el uso de red.

Mafrend v1.0 presenta una versión preliminar del chat Nostr basado en lugares para Android

Mafrend v1.0 es la primera alfa pública para Android de una aplicación prevista de chat Nostr basado en lugares. Su página del proyecto indica que el conjunto de funciones sigue en desarrollo activo y describe cada ubicación del mapa como una sala de chat específica para conversaciones sobre un lugar. Un repositorio público de lanzamientos contiene el paquete instalable de Zapstore, mientras la aplicación principal sigue siendo privada.

Hanami 0.1.0 ofrece a los servidores Blossom una vía para Android mediada por un firmante

Hanami 0.1.0, una aplicación complementaria para Android destinada a servidores Blossom, permite iniciar sesión, cargar y descargar desde un teléfono. La aplicación usa NIP-55 (Aplicación de firma para Android) para someter cada firma a aprobación y un intercambio nativo de NIP-98 (Autenticación HTTP) para establecer la sesión con el servidor. Hanami restringe su shell web y su puente de firma al origen del servidor elegido, lo que mantiene las credenciales en el firmante mientras la interfaz web existente del servidor proporciona la experiencia de la aplicación. El primer lanzamiento público requiere Android 8 o posterior, un servidor Hanami accesible y una aplicación de firma compatible.

Cordn lanza en Android su chat grupal con identidad Nostr

Cordn, un cliente privado de mensajería grupal, ofrece ahora a los usuarios de Android incorporación con identidad Nostr, enlaces de perfil mediante NIP-05 (Asignación de claves Nostr a identificadores de Internet basados en DNS) y enlaces verificados que abren destinos de Cordn en la aplicación. El lanzamiento 0.2.1 publicado el 24 de julio introduce esa versión nativa junto con el cliente web existente. Los mensajes usan MLS, un protocolo de cifrado grupal, con entrega asistida por un coordinador, por lo que los grupos conservan conversaciones cifradas y ordenadas sin requerir una dirección de correo electrónico ni un número de teléfono.

Nostur 1.30.1 corrige los hilos y las publicaciones duplicadas después de que 1.30.0 ampliara las opciones para compartir

Nostur 1.30.1, un cliente Nostr para iPhone, iPad y Mac, permite recorrer hilos de respuestas anidadas sin los fallos de expansión y contracción que alteraban el nuevo diseño. También impide que el mismo borrador se publique dos veces, incluso cuando se repiten las devoluciones de llamada de carga de medios. El lanzamiento sigue a 1.30.0, que añadió mensajes directos que desaparecen y una vía desde la hoja de compartir para enviar medios a Nostr, de modo que la aplicación combina ahora nuevas rutas de mensajería y publicación con correcciones para sus flujos cotidianos de hilos y publicaciones.

Formstr Drive 0.0.2 combina metadatos de archivos Nostr con blobs de Blossom

Formstr Drive 0.0.2, un gestor de archivos nativo de Nostr, ofrece a los usuarios vistas previas en la aplicación y la opción de abrir documentos de oficina en Nostr Docs. En segundo plano, almacena los archivos grandes como blobs fragmentados de Blossom y elimina el blob remoto cuando el usuario borra un archivo. Un relay local mantiene cerca los metadatos Nostr de la aplicación mientras Blossom conserva los datos del archivo, separando la organización de los archivos del almacenamiento de sus datos de gran tamaño.

NoorNote 1.3.1

NoorNote 1.3.1, un cliente Nostr para web, escritorio y Android, añade temporizadores para mensajes que desaparecen y configura relays predeterminados funcionales para DM en cuentas recién creadas. Filtra los artículos globales sin imágenes de portada y dirige las notificaciones de republicaciones al lector de artículos. El lanzamiento 1.3.0 anterior añadió tarjetas de NIP-53 (actividades en directo), tags de personas de NIP-68 (Feeds centrados en imágenes), silenciamiento parcial mediante NIP-78 (datos de aplicaciones) y la indicación de qué relays han visto las notas.

algia 0.0.133

algia 0.0.133, un cliente de línea de comandos para Nostr escrito en Go, sigue a 0.0.132, que añadió listado, cronologías, publicación, reacciones, eliminaciones y flujos para entrar y salir de NIP-29 (Grupos basados en relays). El mismo lanzamiento añadió preautenticación NIP-42 (Autenticación de clientes ante relays) para los relays configurados para exigirla. La versión 0.0.133 añadió después la carga de imágenes locales a los comandos de publicación normal, en canales y en grupos, adjuntando las URL resultantes y los tags de NIP-92 (Archivos adjuntos multimedia) a cada event. También funcionan las publicaciones que solo contienen imágenes, y las publicaciones grupales se dirigen de forma predeterminada al almacén multimedia del relay del grupo, mientras las demás usan los servidores de archivos configurados.

swift-nostr 0.7.0

Para aplicaciones Swift, swift-nostr 0.7.0, una biblioteca Nostr para plataformas Apple, permite que un firmante remoto NIP-46 gestione todas las funciones del cliente mediante su abstracción de firma. El lanzamiento añade compatibilidad con NIP-98 (Autenticación HTTP) y NIP-29 (Grupos basados en relays), incluidos los flujos para incorporarse a grupos, publicar y moderar. También valida el relleno de NIP-44 (Cargas útiles cifradas con versiones) frente a los vectores oficiales y rechaza las cargas útiles que contienen un MAC válido sobre un relleno no canónico.

lawallet-nwc 2.0.0

LaWallet NWC 2.0.0, una cartera conectada a Nostr y un servicio NIP-47 (Nostr Wallet Connect), añade inicio de sesión con passkey que deriva la clave de firma Nostr en el navegador mediante la extensión PRF de WebAuthn. El servidor nunca recibe ese secreto, y la misma passkey puede recuperar la misma clave en otro dispositivo sincronizado. Las cuentas ahora pueden vincular y combinar varios pubkeys de Nostr, mientras el servicio opcional de escucha retransmite events de conexión con la cartera y vuelve a intentar la entrega de webhooks cuando un endpoint resulta inaccesible.

MDK 0.9.10

MDK 0.9.10, la implementación en Rust del protocolo Marmot, conserva los envíos pendientes mientras un transporte está inactivo y supervisa el reenvío de notificaciones de relays para que la entrega entrante se recupere tras un retraso, un panic o un cierre. El PR #1159 añade un historial de conversaciones duradero y paginado, además del contexto completo de las respuestas para agentes locales, y el PR #1167 vuelve a publicar el event KeyPackage firmado actual en vez de generar un sustituto. El lanzamiento también conserva la ordenación manual de chats, admite la disolución definitiva de grupos y amplía la búsqueda clasificada por Web of Trust, las API de políticas de relays y los bindings para lenguajes.

pakstr 0.3.1

pakstr 0.3.1 permite que los equipos web que empaquetan un cliente Nostr para Android proporcionen configuración en tiempo de ejecución y un proxy de API sin reconstruir el shell de la aplicación. Su serie de lanzamientos del mismo día añadió un puente para el firmante Amber, cifrado y descifrado mediante NIP-44 (cargas útiles cifradas), y corrigió la inyección de permisos de Android antes del trabajo de configuración en tiempo de ejecución de la serie 0.3.x. La plantilla mantiene locales los recursos web incluidos mientras la configuración específica del despliegue llega en tiempo de ejecución, y el proxy ofrece a la aplicación empaquetada una ruta controlada para solicitudes de API junto a sus conexiones habituales con relays.

Ditto 2.34.2

Ditto 2.34.2, un cliente social Nostr personalizable, muestra los estados de los usuarios como tarjetas en feeds, páginas de detalle y citas incrustadas, incluidos emoji personalizados, caducidad y vistas previas opcionales de enlaces. Los zaps con comentarios ahora aparecen como respuestas debajo de la publicación referenciada. El lanzamiento también conserva el botón opcional del globo terráqueo en el perfil de 2.34.1 para propietarios que publican un sitio raíz NIP-5A (manifiesto de sitio web), y corrige la navegación de la página de inicio, la búsqueda de transmisiones en directo, el manejo de enlaces externos y los emoji personalizados rotos.

Earthly 0.0.9

Earthly 0.0.9, un editor colaborativo de mapas construido sobre Nostr, ahora mantiene visibles los «me gusta» cuando se cierra, vuelve a abrir o actualiza el panel de una entidad del mapa. Su flujo de NIP-57 (zaps Lightning) envía JSON válido de solicitudes de zap para que los proveedores Lightning puedan publicar recibos verificados en relays accesibles públicamente, también durante el desarrollo local. Las facturas generadas permanecen visibles al cambiar entre las vistas de una entidad, y la aplicación muestra una confirmación después de que llega un recibo verificado.

En desarrollo

Keep añade firma NIP-44 v3 limitada por kind y refuerza la política de aprobación

Keep integró cinco cambios en el firmante de Android que transmiten solicitudes de cifrado y descifrado NIP-44 (Cargas útiles cifradas) v3 mediante los dos transportes NIP-55 (Aplicación de firma para Android) y su bunker NIP-46 (Nostr Connect). Los PR #451, #452 y #453 mantienen las concesiones v3 separadas de v2, restringen su alcance según el kind del event, rechazan kinds ausentes o no válidos y conservan las solicitudes de aprobación abiertas desde notificaciones. Los PR #454 y #455 dejan de tratar la política de firma Basic como Auto y trasladan la selección global al almacén cifrado gestionado por el núcleo. Los responsables de Keep integraron los cinco cambios después del lanzamiento etiquetado más reciente para Android.

Routstrd cambia su enlace de red predeterminado después de una exposición sin autenticación

El PR #56 de Routstrd cambia la dirección de enlace predeterminada del router local de inferencia Nostr, de todas las interfaces de red a 127.0.0.1. La configuración anterior exponía sin autenticación los endpoints de saldo de cartera, historial, acceso, envío, reembolso, claves de API, proveedor, cliente, uso y detención del daemon a cualquier host que pudiera alcanzar el puerto. Los operadores aún pueden configurar explícitamente un enlace no local, pero el cambio integrado hace que un despliegue nuevo sea exclusivamente local de forma predeterminada y todavía no ha aparecido en un lanzamiento etiquetado.

Imwald Android aclara el estado de publicación sin conexión

Imwald Android, un cliente Nostr para Android, ahora da por completada una publicación tras la confirmación de un relay local solo cuando todos los destinos configurados son locales. Su corrección de publicación sin conexión y outbox mantiene pendiente la entrega remota cuando un relay local ha aceptado el event pero los relays remotos configurados no lo han hecho, de modo que el informe de publicación distingue el almacenamiento local en el dispositivo de la entrega a relays.

FIPS añade una capa de acceso para OpenWrt; una adaptación para FreeBSD sigue en revisión

El Free Internetworking Peering System nativo de Nostr permite ahora que un router OpenWrt exponga una red de acceso !FIPS abierta mediante el PR #126 integrado. El PR #129 para FreeBSD, paralelo y aún abierto, propone adaptar el daemon, la ruta de datos TUN, la resolución de nombres .fips, la gestión de servicios y la compilación de paquetes nativos. La integración de OpenWrt amplía el acceso hoy, mientras el trabajo para FreeBSD lo extendería a otro sistema operativo de propósito general.

Una actualización del proyecto FIPS del 26 de julio informó de más de 300 nodos en su red superpuesta UDP pública y de una malla más amplia que se acercaba a los 2.000 nodos. El repositorio de FIPS dedicó la misma semana a reforzar las pruebas de red simultáneas, la continuidad tras el cambio de claves, el comportamiento del límite de saltos, las comprobaciones del cortafuegos y el aislamiento del laboratorio NAT. El trabajo en el repositorio ofrece a los operadores comprobaciones reproducibles de estos comportamientos a medida que crece la red.

Zap Cooking programa publicaciones y vincula las solicitudes del escáner

Zap Cooking, una aplicación Nostr para compartir recetas y planificar comidas, puede ahora conservar una publicación programada en almacenamiento cifrado y publicarla cuando corresponda mediante un barrido periódico de relays (PR #566, PR #569). Esto ofrece a los usuarios una vía de publicación programada sin dejar expuesto contenido de publicaciones sin firmar en la base de datos del programador.

Su escáner de nevera ahora autentica el cuerpo exacto de la solicitud con autenticación HTTP NIP-98, por lo que las comprobaciones de membresía se basan en la clave que firmó la solicitud de escaneo en vez de un pubkey proporcionado en su cuerpo (PR #599).

Citrine convierte un dispositivo Android en un relay gestionable

Citrine, un relay Nostr alojado en Android, puede ahora enviar los events que ha almacenado a relays externos, lo que ofrece al operador una forma de volver a difundir el historial local (PR #179). También añade comandos NIP-86 (API de gestión de relays) para que los clientes compatibles puedan administrar el relay (PR #150).

Los operadores de grupos pueden administrar grupos basados en relays NIP-29 mediante la firma de Amber en el PR #178, mientras el PR #174 mantiene alineados durante los reinicios la configuración de relays mediante Tor y el estado del ciclo de vida.

Wired recupera conversaciones completas en el navegador

Wired, un cliente Nostr basado en navegador, ahora sigue las raíces de feeds, las respuestas y los events referenciados hasta completarlos en vez de detenerse ante límites fijos de amplitud o resultados (PR #148, PR #147, PR #146). Por tanto, los usuarios pueden recuperar hilos más profundos y el contexto de los feeds cuando los events pertinentes están disponibles en sus relays.

El navegador también conserva las sugerencias de relay en los events referenciados y solo las usa para el contexto que aún falta, lo que restaura conversaciones que los relays configurados no contienen (PR #145, PR #144). La recuperación incompleta se mantiene separada de una captura completa, por lo que una respuesta parcial no sobrescribe la vista anterior almacenada en caché.

Trabajo sobre protocolos y especificaciones

NIPs: límite de alojamiento de NIP-34, migración de grupos y tres borradores activos

Esta semana se integraron dos cambios en especificaciones. El commit 6d2979b de NIP-34 elimina las instrucciones de alojamiento GRASP de la descripción del pull request kind:1618, dejando el alojamiento y el comportamiento alternativo fuera del contrato del event. El commit db5fe3d de NIP-29 define cómo migran los metadatos de un grupo de relay a otro relay y cómo distinguen los clientes un traslado válido de una bifurcación que continúa de forma independiente.

El PR #2424 propone declaraciones mutuas de conjuntos de claves con kind:10045. El requisito recíproco impediría que una identidad vinculara unilateralmente otra clave. El PR #2421 propone intents de zap BOLT12 y pruebas del pagador que los clientes puedan validar frente al destino, el importe, la oferta y el pago liquidado sin depender de un servidor de recibos operado por el destinatario.

El PR #2425 permitiría que los marcadores NIP-B0 conservaran esquemas distintos de HTTP, como nostr:, junto con URL web. Esto mantendría intactos los identificadores nativos de Nostr, las solicitudes de pago y otros esquemas de aplicaciones dentro de las mismas listas privadas o públicas de marcadores que ya contienen direcciones web.

Mill implementa un borrador para copias de seguridad de claves mediante cuentas en la nube

Mill anunció un borrador implementado de copia de seguridad de claves mediante cuentas en la nube que combina un identificador de cuenta OIDC de Google con una frase de contraseña de alta entropía para derivar una clave de respaldo desechable. Su implementación de referencia cifra la clave real del usuario como un ncryptsec NIP-49 (Cifrado de claves privadas) y después la almacena en un event provisional kind 30049, reemplazable y parametrizado, en los relays configurados. El proyecto integró el flujo de copia de seguridad en main, pero ningún lanzamiento posterior a v1.0.0 lo incluye, y el flujo de copia de seguridad permanece desactivado salvo que un operador proporcione backupRelays específicos. Un conjunto versionado de relays sigue siendo provisional, y el borrador advierte que el texto cifrado publicado sigue disponible para intentar adivinar la frase de contraseña sin conexión. Los lectores deben considerar el diseño como un experimento implementado que depende de una frase de contraseña de alta entropía.

BUDs: los servidores Blossom pueden identificar cargas desconocidas por sus bytes

El PR #110 de BUD-02 propone recomendar la detección del tipo MIME en el servidor cuando quien carga un archivo omite Content-Type o envía application/octet-stream. Un servidor Blossom inspeccionaría los primeros bytes con una biblioteca actualizada de tipos de archivo, conservaría un tipo específico proporcionado por el cliente y recurriría al tipo binario genérico cuando fallara la detección. Esto permitiría presentar correctamente imágenes, audio, vídeo y archivos producidos por agentes sin hacer obligatoria la inspección de bytes para cada carga.

NAPs: las convenciones sustituyen las vías numeradas mientras se desarrollan contratos de captura y sistema de archivos

El PR #87 elimina la vía numerada de protocolos entre napplets y mantiene las capacidades de tiempo de ejecución bajo contratos con nombre, mientras los mensajes de las aplicaciones convergen en URI de convención napplet:<archetype>/<intent>. El cambio de identidad de temas integrado separa una ruta de convención estable y sin consultas de los datos de carga útil de cada mensaje, y el PR #90 aplica esa regla de transposición a los metadatos de descubrimiento y manejadores.

Dos borradores NAP amplían el límite del shell de confianza. El PR #94 de NAP-CAPTURE mantiene en el entorno de ejecución el consentimiento para el micrófono, los permisos de la plataforma, los límites, la retención y la limpieza al finalizar, mientras devuelve un artefacto multimedia acotado a un napplet aislado. El PR #88 de NAP-FS es la propuesta paralela de sistema de archivos virtual, con descriptores sujetos a políticas en vez de rutas de host sin restricciones.

Marmot: la especificación define un estado terminal de grupo

El PR #409 de Marmot añade un estado Disbanded autenticado e irreversible porque MLS no dispone de una operación para eliminar grupos. Un commit autorizado de administrador saca a un grupo de Active, impide que ramas antiguas, mensajes y Welcomes lo reactiven, y ofrece a los grupos existentes una vía explícita de compatibilidad antes de poder disolverse. La revisión anterior de incidencias de la especificación también concilió la autoridad sobre el estado del grupo, la convergencia, los paquetes de claves, las confirmaciones, las reglas de medios, el lenguaje del registro y 200 incidencias de especificación registradas.

Gamma Markets: no se incorporaron cambios públicos en la especificación

El repositorio de la especificación de Gamma Markets no registró commits públicos ni actividad de pull requests entre el 21 y el 28 de julio. Sus documentos publicados sobre órdenes, liquidación y datos de mercado siguen siendo la referencia actual; esta entrada sin cambios mantiene a Gamma visible en la revisión semanal de especificaciones.

Concord: las capacidades de lectura y escritura pueden separarse dentro de un mismo plano

El PR #12 de Concord sigue siendo un borrador abierto para planos en los que no todos los lectores deberían poder escribir. Orienta el Control Plane hacia capacidades separadas para flujos de lectura y escritura, y esboza canales de escritura restringida, invitaciones y ámbitos de cambio de claves. La clave de escritura funciona como barrera contra spam en el borrador, mientras los actores internos firmados y las comprobaciones de la lista de miembros siguen otorgando la autoridad.

NWC: un método de cartera puede elegir entre BOLT11 y BOLT12

El PR #2 de NWC propone métodos opcionales pay y receive para URI de pago BIP-321. Un servicio de cartera puede anunciar compatibilidad, elegir una factura BOLT11 o una oferta BOLT12 compatible de una URI, rechazar una red Bitcoin que no coincida antes del pago e informar del tipo de instrucción que utilizó. La propuesta permanece fuera del núcleo de NWC para que las carteras sin compatibilidad con BIP-321 o BOLT12 no tengan que implementarla.

Seis julios en la historia de Nostr

Este recorrido histórico por los julios de Nostr aborda problemas recurrentes: identificadores legibles, filtrado de relays, datos portátiles de aplicaciones, privacidad e interoperabilidad. A lo largo de seis años, cada capa transforma una solución puntual en infraestructura compartida: los nombres se convierten en perfiles, los filtros en contratos de aplicación y el estado transportado por relays se expande de las notas a las salas y los grupos en directo. Comienza con la primera implementación de NIP-05 y termina con la integración del descubrimiento direccionable de este mes, y después examina los cambios de julio que desarrollaron esos temas.

Julio de 2021

El 19 de julio de 2021, el commit 1ce00bd de nostr-tools añadió un módulo nip05.js y elevó el paquete a la versión 0.5.0. Su función keyFromDomain construía una solicitud DNS TXT para _nostrkey.<domain>, enviaba la consulta binaria a uno de ocho proveedores DNS-over-HTTPS seleccionados por rotación y devolvía la primera clave de la respuesta. Así, un cliente de navegador podía obtener una clave pública a partir de un dominio controlado por una persona sin operar un resolutor DNS ni depender de un único proveedor predefinido en el código.

Ese primer enfoque resolvía la búsqueda, pero no los nombres dentro de un dominio, y su perímetro de confianza abarcaba DNS y el resolutor seleccionado. La especificación NIP-05 moderna trasladó el descubrimiento a /.well-known/nostr.json, donde un dominio asigna nombres locales a pubkeys y puede adjuntar sugerencias de relay. El código de 2021 registra la presión de diseño anterior: las claves públicas eran portátiles, pero las personas aún necesitaban identificadores que pudieran leer, verificar y trasladar entre clientes.

Julio de 2022

El 10 de julio, el commit 3771186 de NIP-12 limitó las consultas genéricas de relays a tags de una sola letra. Esa decisión hizo útiles filtros como #r, #g y #t para referencias URL, geohashes y hashtags sin pedir a los relays que indexaran todas las claves arbitrarias de metadatos. Diez días después, el primer borrador de comentarios web NIP-20 usó directamente ese modelo de consulta: un comentario kind 34 llevaba una URL de página web normalizada en un tag r, lo que permitía a un sitio y a clientes independientes recuperar la misma conversación de los relays.

A continuación llegaron la política de relays y la respuesta social. El commit original de NIP-22 permitía a los relays rechazar events cuya marca temporal created_at fuera inverosímilmente antigua, y el commit 8bef0e9 añadió las marcas temporales futuras a la misma política. El 30 de julio, el commit dcbd504 de NIP-25 definió reacciones kind 7 con tags de destino e y p; el commit siguiente asignó - a una reacción negativa, y el commit 6903ff5 convirtió + en el «me gusta» genérico explícito. En conjunto, estos commits especificaron el rechazo de marcas temporales por los relays, la recuperación basada en tags, los comentarios web y los tags de reacción para los clientes que adoptaran los borradores.

Julio de 2023

Julio de 2023 llevó la coordinación más allá de las notas breves. El borrador de NIP-37 sobre claves perdidas exploró la retirada irreversible de claves, umbrales de recuperación social y claves de sustitución precomprometidas, a la vez que se negaba explícitamente a denominar el resultado rotación universal de claves. Cinco días después, NIP-53 introdujo actividades en directo direccionables kind 30311 y mensajes de chat kind 1311, lo que proporcionó a transmisiones, escenarios y salas en directo un modelo de event compartido para anfitriones, participantes, estado y conversación.

Las aplicaciones también comenzaron a anunciar trabajo y comercio. El primer borrador de Data Vending Machine describió solicitudes de trabajo kind 68001, resultados kind 68002, ofertas, vencimientos, encadenamiento y proveedores que compiten por tareas como transcripción, resumen y traducción. El 13 de julio, el borrador de anuncios clasificados añadió ofertas direccionables kind 30402 con metadatos de título, resumen, precio, ubicación y estado. Esos borradores se convirtieron más tarde en NIP-90 y NIP-99, pero sus formas de julio ya separaban una solicitud o un anuncio del servidor que los mostraba.

El enrutamiento de pagos también se volvió componible. La integración de divisiones de zap de NIP-57 del 31 de julio convirtió un único destino de zap en una lista ponderada de pubkeys de destinatarios y sugerencias de relay. Un cliente podía dividir un zap entre colaboradores, omitir destinatarios sin ponderar cuando había algunas ponderaciones y mostrar la división antes del pago. El cambio estandarizó una representación mediante events firmados para los destinatarios ponderados de zaps y las sugerencias de relay, lo que permitía a clientes compatibles presentar la división antes del pago.

Julio de 2024

El 4 de julio, el commit c60ca88 de NIP-29 añadió la acción de moderación de relay kind:9007 para crear un grupo. Seis días después, NIP-70 definió los events protegidos: un tag - indica a un relay que acepte la publicación únicamente del autor autenticado del event. Un cambio dio a los relays una transición explícita de estado de grupo; el otro permitió a los autores impedir que terceros reprodujeran en relays events firmados que, por lo demás, eran válidos.

El 16 de julio, un commit de la especificación Cashu introdujo tanto las carteras NIP-60 como los nutzaps NIP-61. NIP-60 colocó los metadatos de la cartera en kind 37375, las pruebas no gastadas en events kind 7375 cifrados y el historial opcional de transacciones en kind 7376. NIP-61 combinó las preferencias de mint y relay del destinatario, publicadas en kind 10019, con nutzaps kind 7337 bloqueados mediante P2PK. El estado de la cartera y los tokens al portador podían circular entonces por relays, mientras el canje seguía dependiendo de las pruebas del mint Cashu y de una prevención cuidadosa de las reclamaciones dobles.

Dos modificaciones de finales de julio reforzaron el estado determinista. El commit 9c54549 de NIP-01 exigió usar los ID de event como criterio de desempate después de marcas temporales created_at iguales, para que los clientes pudieran ordenar del mismo modo conjuntos de resultados idénticos. La integración de eliminación NIP-09 aclaró que las solicitudes kind 5 pueden dirigirse a ID de event o a coordenadas direccionables y deberían incluir tags k que identifiquen los kinds que los relays deberían eliminar. Ambos cambios redujeron los puntos en los que dos implementaciones correctas podrían discrepar.

Julio de 2025

El descubrimiento de ecash obtuvo su propio directorio social el 16 de julio. El commit 1afb6da de NIP-87 definió registros kind 38172 de mints Cashu, registros kind 38173 de Fedimint y recomendaciones kind 38000 que pueden apuntar a esos registros con sugerencias de relay. Las carteras podían consultar las recomendaciones de autores de confianza antes de conectarse a un mint, mientras la especificación advertía que el descubrimiento global sin filtrar podía dirigir a los usuarios hacia operadores maliciosos.

Una semana después, un borrador especificó registros portátiles de events Nostr para mensajes de voz. El primer commit de NIP-A0 asignó kind 1222 a la raíz de un mensaje de voz y kind 1244 a una respuesta, con una URL de audio y metadatos multimedia. La actualización de formato del 27 de julio recomendó Opus en un contenedor Ogg y estandarizó una forma de onda comprimida. Los clientes podían intercambiar audio breve sin acordar un único grabador, host o representación de forma de onda.

La mensajería privada y las conexiones de cartera añadieron después estado de protocolo para el seguimiento de lectura, la selección de cifrado y el progreso de los pagos. El commit 3d76da3 de NIP-17 definió un registro reemplazable kind 30016 cuyos tags seen ordenados permiten a un cliente distinguir los mensajes leídos de los intervalos que podría haberse perdido. El 31 de julio, la negociación de cifrado NIP-47 permitió a los servicios de cartera anunciar NIP-44 v2 o el antiguo NIP-04, mientras el commit de estado de transacciones añadió los estados pending, settled, accepted, expired y failed. La entrega, el cifrado y el progreso del pago se convirtieron en datos explícitos del protocolo en vez de inferencias locales.

Julio de 2026

Este julio comenzó conectando direcciones web corrientes con consultas de relays. El commit 2f4b093 de descubrimiento direccionable define una búsqueda /.well-known/nostr.json?ad=<path> cuya respuesta contiene un filtro Nostr y una lista de relays. Un navegador normal aún puede abrir la URL original como HTML, mientras un cliente Nostr puede consultar el endpoint /.well-known/nostr.json?ad=<path> correspondiente para obtener un filtro y una lista de relays que resuelvan la dirección como un grupo, nsite, feed, event u otro objeto nativo. El patrón retoma el problema de 2021 de pasar del dominio a la clave en una capa más amplia: una URL legible por humanos puede ahora nombrar tanto una identidad como una consulta.

NIP-29 pasó entonces de grupos de relay planos a espacios estructurados. El commit sobre subgrupos del 16 de julio añadió relaciones de padre e hijos ordenados; otros commits relacionados añadieron sufijos de códigos de invitación, banners, instantáneas ordenadas de elementos fijados y events direccionables fijados. El 22 de julio, la aclaración sobre migración y bifurcación definió cuándo los metadatos trasladan legítimamente un grupo a otro relay y cuándo una rama todavía activa constituye una bifurcación independiente. El identificador del grupo se mantuvo sencillo, mientras la jerarquía, la presentación y los cambios de relay se convirtieron en estado explícito.

Dos modificaciones menores aclararon los límites de implementación. El commit f0af204 de NIP-46 exige que un firmante remoto devuelva un error ante métodos desconocidos o no compatibles en vez de dejar que el cliente agote en silencio el tiempo de espera. El commit 6d2979b de NIP-34 elimina de la descripción del event de pull request las instrucciones de alojamiento específicas de GRASP. Uno proporciona a los solicitantes una respuesta definitiva; el otro evita que un event portátil de git herede en silencio un protocolo de servidor.

Envíe un DM NIP-17 para compartir un proyecto o una noticia mediante el proyecto Nostr Compass.