Boletines on Nostr Compass

Nostr Compass #42

Wed, 30 Sep 2026 00:00:00 +0000

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

Nuestra aplicación Nostr Compass para Android reúne boletines, episodios de pódcast, guías temáticas y notas de voz de colaboradores en un solo lugar. Sus últimas notas de versión firmadas describen boletines completos con firmas verificadas, números guardados y 110 guías temáticas disponibles sin conexión, y búsquedas locales en las noticias y las transcripciones disponibles. Los colaboradores pueden grabar y responder con notas de voz, revisar una toma guardada antes de enviarla y firmar mediante Amber sin almacenar su clave privada en la aplicación. Las grabaciones públicas se publican en Nostr y Blossom.

La última actualización de la aplicación conserva las grabaciones en cola y los puntos de control de las subidas cuando Android detiene el trabajo en segundo plano, muestra cuándo se necesita la aprobación de Amber y abre la grabación correspondiente desde una notificación. Las vistas separadas de episodios y notas de voz mantienen sus propias posiciones de desplazamiento, mientras que la reproducción se reanuda desde el mismo punto. Las notificaciones de nuevas grabaciones dependen de la programación de tareas y los permisos de Android.

Esta semana: White Noise añade encuestas cifradas de grupo y avisos sobre historiales de chat incompletos; Holoboard añade comandos de promoción por mensaje privado y una aplicación para Android; fips-pub-domains prueba nombres públicos firmados en una red de malla; Marmot MDK hace visibles las lagunas en el historial de grupos cifrados; y Myco aporta una identidad y una tienda de Nostr al intercambio de aplicaciones entre dispositivos cercanos. nostream ajusta la admisión del relay a la carga, mientras que Nostr double ratchet cierra una brecha relacionada con miembros expulsados. El desarrollo corrige la interoperabilidad de grupos cifrados de Amethyst, añade los mensajes de vídeo cifrados de Divine y pone en línea Nostr Atlas. Las actualizaciones del protocolo refinan las pruebas de identidad, las invitaciones a relays, los conjuntos de cuentas seguidas y las propuestas de declaraciones de dominio. La retrospectiva de septiembre de fin de mes sigue esas mismas cuestiones a lo largo de seis años de Nostr.

Noticias principales

Holoboard añade comandos de promoción de Nostr y una aplicación para Android

Holoboard es un tablón para encontrar notas de Nostr mediante una clasificación que puede impulsarse con pagos Lightning. Las publicaciones originales siguen siendo events de Nostr; Holoboard sirve sus datos de clasificación y apariencia a través de su propia API HTTP. Esa distinción importa si un lector espera que el orden del tablón sea un feed nativo de relay.

Su registro de cambios del 23 de septiembre recoge comandos de promoción por mensaje directo tanto mediante NIP-17 cifrado como mediante la vía heredada de NIP-04. NIP-17 envuelve los mensajes privados para ocultar su contenido y remitente a los relays, mientras que NIP-04 es el formato anterior de cifrado de mensajes directos. Un usuario puede solicitar una factura de promoción en la misma conversación, recibir un presupuesto etiquetado para la primera promoción pagada y activar recordatorios de vencimiento respondiendo YES. El emisor de promociones reintenta los relays que han fallado, mientras que la actualización del 24 de septiembre añade una aplicación para Android y simplifica el flujo de facturación.

Las notas de integración con relays del proyecto describen notas y comentarios normales en Nostr, el enrutamiento de la bandeja de entrada cifrada y la gestión de citas y eliminaciones. Su ficha firmada para Android en Zapstore respalda la existencia de una versión publicada de la aplicación, pero no se ha establecido que la clave de la ficha sea la identidad del tablón público de Holoboard. Esta es la primera cobertura del proyecto en Compass.

fips-pub-domains prueba nombres públicos firmados para una red de malla

fips-pub-domains es un nuevo experimento de resolución y denominación que vincula nombres de dominio públicos con nodos de FIPS, una red de malla cifrada que utiliza mensajes de Nostr para descubrir pares. Su primera versión combina esas declaraciones con registros TXT de DNS, validación DNSSEC opcional, vinculaciones fijadas localmente, un demonio de resolución para Linux e integración en Android con fips2go, el cliente de FIPS para teléfonos. Una declaración firmada por sí sola no acredita la titularidad de un dominio público; los clientes necesitan pruebas de DNS o DNSSEC, un testigo configurado o una vinculación fijada en la que ya se confíe.

La versión 0.2.0 añade pruebas DNSSEC a las declaraciones para que un cliente que solo tenga un relay de la red de malla pueda validar un nombre sin una vinculación fijada, y permite que varios servidores validados sirvan un mismo dominio. También corrige las vinculaciones fijadas obsoletas y la conmutación por error de DNS. La versión 0.2.1 corrige una unidad de systemd que, de otro modo, no se iniciaba, y ejecuta el servidor sin root; las instalaciones existentes deben sustituir esa unidad para recibir la corrección.

En Android, un cambio integrado en fips2go sigue las vinculaciones verificadas de nombres públicos en su proxy DNS. Un segundo cambio integrado transporta las conexiones a los relays de Nostr configurados a través de la red de malla, de modo que el resolutor pueda recuperar y verificar una declaración de dominio no vista anteriormente mientras el teléfono no tiene conexión a internet. Los mantenedores comunican los resultados en dispositivos en esas solicitudes de cambios; no acreditan un despliegue más amplio.

Las pruebas con dos nodos y con un relay accesible solo mediante la red de malla del proyecto son pruebas comunicadas por los mantenedores de una implementación temprana, no de un despliegue en producción. Su NIP-DB sigue siendo una propuesta abierta, y los kinds de event de su borrador siguen siendo marcadores provisionales pendientes de registro. La noticia de fips2go de la semana pasada cubría el arranque inicial de la red de malla y el descubrimiento de pares; el trabajo de esta semana aborda los nombres públicos y la verificación.

Marmot MDK 0.11.0 hace visibles las lagunas en el historial de las cuentas

Marmot MDK, el entorno de ejecución de Rust y los enlaces generados para la mensajería de grupos de Nostr cifrada con MLS, da continuidad a la versión de la semana pasada con envío persistente mediante la versión 0.11.0. La recuperación de cuentas ahora solo declara completada una laguna en el historial cuando todos los relays requeridos terminan una comparación de events sin truncar; una laguna no comprobada genera un aviso persistente que la aplicación anfitriona puede mostrar al usuario. Una cola de entrega llena se vuelca en la base de datos de la cuenta en lugar de descartar events, y la entrega en tiempo real hace avanzar el cursor de transporte para que un reinicio no vuelva a recuperar el mismo historial.

Las notas de versión completas también describen encuestas cifradas de grupo opcionales, verificación de events sin estado en los enlaces y bibliotecas de Android alineadas para páginas de memoria de 16 KB. Las aplicaciones deben actualizar conjuntamente los enlaces generados y las bibliotecas nativas procedentes de este mismo conjunto de código fuente; las bases de datos de las cuentas migran pasando por el esquema 98 al abrirse por primera vez, y no se admite volver a una versión anterior de la base de datos. Un defecto intermitente ya existente en la puesta al día todavía puede dejar indescifrables los mensajes que estén más de cinco épocas de grupo por detrás sin generar un aviso, por lo que esta versión no afirma recuperar completamente el historial en todos los casos.

Myco 0.8.0–0.8.1 proporciona a las aplicaciones cercanas su propia tienda de Nostr

Myco es una aplicación para Android que permite intercambiar pequeños programas de Nostr, llamados napplets, con teléfonos cercanos, incluso cuando están sin conexión. La versión 0.8.0 proporciona a cada instalación una identidad de invitado de Nostr y permite iniciar sesión con una clave existente o con Amber, un firmante para Android que aprueba firmas sin compartir la clave de la cuenta. También sustituye la pestaña Descubrir por una tienda de aplicaciones que es, a su vez, una napplet. Esa tienda lee fichas de aplicaciones y recomendaciones firmadas, mientras que una actualización descargada puede pasar de un teléfono a otro dentro del Círculo de un usuario sin conexión a internet.

La versión 0.8.1 facilita la búsqueda de esas fichas consultando los relays que anuncia un autor; las compilaciones anteriores dependían de opciones públicas predeterminadas. Muestra inmediatamente los perfiles y las aplicaciones en caché, guarda las respuestas de relays más lentos para visitas posteriores, reduce la frecuencia de los reintentos con relays que fallan y mantiene activas las suscripciones mientras una vista está abierta. Ambas actualizaciones conservan el formato existente de transmisión entre teléfonos. Los teléfonos actualizados pueden descargar y compartir actualizaciones de napplets; los teléfonos antiguos solo reenvían sus anuncios.

Versiones etiquetadas

White Noise Android añade encuestas de grupo y valores predeterminados de mensajes temporales específicos para cada cuenta

White Noise Android es una aplicación de mensajería Nostr para conversaciones privadas cifradas con Marmot. Tras las mejoras de entrega y uso compartido cubiertas la semana pasada, la versión del 30 de septiembre añade encuestas de grupo con respuestas seleccionables, barras de resultados y plazos mediante Marmot Development Kit. También añade valores predeterminados de mensajes temporales para cada cuenta, almacenados localmente en el dispositivo: las nuevas conversaciones directas y los nuevos grupos heredan la duración elegida, mientras que las conversaciones existentes y sus ajustes individuales mantienen su política actual. Saludar envía un saludo que menciona a un miembro recién añadido sin alterar el borrador actual.

La versión permite a los usuarios elegir el recorte centrado en el punto de interés para las imágenes de perfil y de grupo, y eliminar una carpeta de chats sin eliminar sus conversaciones. Sus avisos sobre el historial indican cuándo una recuperación deja potencialmente incompleto el historial de una cuenta o un grupo, con controles independientes para descartarlos. La paginación de conversaciones evita reconstruir la cronología mostrada al saltar a los mensajes recientes, y las ediciones de mensajes pendientes conservan su texto mientras el envío original obtiene su ID de event confirmado. Ese traspaso de la edición abarca los cambios de conversación dentro de la aplicación en ejecución; no garantiza la persistencia tras la terminación del proceso.

El dictado ahora permite elegir Pegar o Enviar para cada grabación, y la finalización automática coloca la transcripción en el borrador. La configuración del proveedor sin conexión explica el procesamiento en el dispositivo, mantiene su consentimiento separado del de otros proveedores de voz y restaura los medios interrumpidos cuando termina la captura. La gestión de archivos generales acepta documentos no vacíos dentro de los límites establecidos, con nombres de archivo, metadatos MIME y mensajes de error precisos; las descargas explícitas de archivos adjuntos utilizan las tareas de transferencia iniciadas por el usuario de Android, con una alternativa en primer plano. Los controles para pegar ahora utilizan la acción del sistema de Android para que GrapheneOS Secure Paste pueda conceder acceso al portapapeles. Android también muestra el contenido de GIPHY compartido desde iOS como medios animados, respetando la política de descargas.

Las correcciones de notificaciones actualizan los apodos de los remitentes y eliminan las alertas cuando se abre una conversación. Los cambios en la recuperación de notificaciones conservan el trabajo pendiente de notificaciones push cuando no se puede asumir el control en primer plano y utilizan reintentos limitados. La firma con Amber coordina las ráfagas de aprobaciones de una misma cuenta para evitar que los límites de frecuencia cancelen los envíos. La nueva configuración de auditoría solicita una nueva decisión sobre compartir los registros antes de cargarlos al nuevo receptor. El código fuente también adopta la licencia AGPL-3.0-only.

nostream 3.1.0 ajusta la prueba de trabajo del relay en función de la carga

nostream es un relay Nostr en TypeScript respaldado por PostgreSQL. La versión 3.1.0 puede aumentar o reducir el umbral de prueba de trabajo de los events entre los límites fijados por el operador a medida que cambia la tasa de events observada. El ajuste está desactivado de forma predeterminada, utiliza la tasa medida por cada proceso de trabajo y mantiene independiente el umbral estático existente por clave pública, por lo que los operadores deben activarlo antes de que los remitentes se encuentren con un requisito de admisión diferente.

La misma versión añade un panel de administración para las métricas del relay, de WebSocket y de events, los resultados de las comprobaciones del estado de la red y las notificaciones configurables para el operador. Su API de administración está desactivada de forma predeterminada. Estos controles ayudan a los operadores a distinguir entre la presión sobre el relay y los problemas de accesibilidad, al tiempo que mantienen la nueva política sujeta a una configuración explícita.

Después de publicar su versión con prueba de trabajo sensible a la carga, nostream integró acciones para los reportes de moderadores de confianza. NIP-56 define los events de reporte de contenido; la nueva opción nip56.hideActionableReports excluye los events reportados de los resultados de REQ y COUNT cuando los reportes también están habilitados. Un reporte de un event oculta ese event, mientras que un reporte de una clave pública oculta todos los events de ese autor. La nueva opción tiene el valor false de forma predeterminada, por lo que habilitar únicamente la recopilación de reportes conserva los resultados de consulta existentes.

Nostr double ratchet 0.0.171–0.0.172 cierra una brecha relacionada con los miembros eliminados

Nostr double ratchet es una biblioteca de TypeScript para chats privados cifrados transportados por Nostr. La versión 0.0.171 rota la clave de remitente de un grupo después de los cambios de miembros, de modo que una persona eliminada que conserve las claves antiguas no pueda descifrar mensajes posteriores de un remitente actualizado, incluso después de que ese remitente se reinicie. También rechaza los envíos o la rotación de claves por parte de un propietario local eliminado y aborta un envío si la composición del grupo cambia durante la distribución de claves.

La versión 0.0.172 incluye la aprobación de dispositivo existente, firmada por la cuenta, en una respuesta de invitación cifrada opcional. Un destinatario que utilice la actualización puede verificar el dispositivo del remitente antes de que llegue un event de registro separado, mientras que los dispositivos vinculados conservan su aprobación tras los reinicios. El campo de invitación es opcional y deja intactos el intercambio inicial y el formato de los mensajes del mecanismo ratchet originales.

Las versiones 0.0.173–0.0.175 amplían ese trabajo sobre la eliminación de miembros con traspasos persistentes de claves de grupo y un estado de entrega en cola guardado antes de la publicación, de modo que los traspasos interrumpidos se recuperen tras un reinicio. Las funciones de devolución de llamada de publicación incluyen contexto local del grupo que permite a las aplicaciones cancelar los reintentos persistentes después de una eliminación, a la vez que mantiene entregables los controles de pertenencia al grupo; los envíos en cola conservan los ID originales de sus events internos. Las respuestas de invitación duplicadas conservan las sesiones establecidas, las suscripciones permanecen estables cuando cambian los contactos y las instantáneas de claves de la aplicación conservan los nombres de los dispositivos sin compartir copias mutables. El formato firmado de transmisión no cambia; las notas de 0.0.173 también informan de Rust 0.0.168 con un mecanismo alternativo para la sesión de recepción y filtrado de ecos locales del grupo.

Scramble 0.7.4–0.7.5 recupera los mensajes que debería ver un nuevo miembro del grupo

Scramble es una aplicación de mensajería de grupos Marmot multiplataforma con una interfaz nativa de Android. En la versión 0.7.5, cada grupo obtiene su propio límite temporal para el historial del relay: antes, el límite de la conversación más activa se aplicaba a todos los grupos, por lo que uno al que se acababa de incorporar el usuario podía permanecer vacío porque nunca se solicitaban sus mensajes posteriores a la incorporación. Asimismo, la ruta de reconexión recibe la misma corrección, y un grupo sin actividad local ahora solicita todos los mensajes disponibles; MLS sigue impidiendo que un nuevo miembro descifre los mensajes enviados antes de su incorporación.

La versión 0.7.4 anterior corrige la aceptación repetida de invitaciones causada por las filas recicladas de Android que acumulaban manejadores de clics, y hace que la configuración de un servidor de medios Blossom personalizado persista en la aplicación nativa. La versión 0.7.5 distribuye únicamente el APK nativo de Android, por lo que los usuarios que siguen el nombre de archivo anterior de Avalonia deben cambiar su destino de actualización. Las cuentas y el historial se trasladan entre esas dos compilaciones de Android, pero los grupos creados con el motor MLS anterior de 0.6.x no migran a 0.7.x.

Scramble 0.7.6 añade un control manual para Recuperar mensajes faltantes que consulta todas las direcciones de enrutamiento que ha utilizado un grupo, elimina la restricción temporal, repara una dirección almacenada obsoleta e informa de lo que ha recuperado. Sigue sin poder descifrar épocas anteriores a la incorporación del usuario. Los administradores de la aplicación nativa pueden ascender o degradar a otros miembros, con el estado actual de la lista de miembros y resultados de error visibles; las conversaciones de dos personas siguen ocultando estos controles. La acción Copiar de la información del grupo ahora responde, aunque las conversaciones por invitación todavía pueden copiar un identificador interno del chat en lugar del ID de grupo del protocolo. La versión 0.7.7 también procesa los mensajes retenidos cuando llega el commit de otro miembro; 0.7.8 añade una prueba de regresión para esa ruta de miembro pasivo.

Amber 6.6.6 corrige los secretos de conexión del firmante remoto

Amber es un firmante para Android que aprueba firmas de event de Nostr sin entregar a una aplicación la clave de la cuenta. Tras el cambio de cifrado de las copias de seguridad de la semana pasada, la versión 6.6.6 corrige su analizador de nostrconnect: un parámetro de conexión que contenía =, como un secreto con relleno, se alteraba antes de que Amber respondiera. Eso hacía que los clientes basados en NDK fallaran en la comprobación del secreto incluso cuando la conexión con el firmante parecía válida en los demás aspectos.

La versión también envía los informes de problemas a los relays anunciados en el anuncio del repositorio de Amber, y recurre al relay anterior si no se puede obtener el anuncio. Los tiempos de espera más largos de Tor dan a los relays lentos más tiempo para confirmar esa publicación. Los cambios restantes mejoran la visibilidad de los iconos y el texto en los temas de Amber.

FIPS 0.5.2 detiene una filtración de privacidad en el descubrimiento mediante Nostr

FIPS es una red mallada cifrada que utiliza identidades de Nostr y mensajes de relay para descubrir pares. Su versión de mantenimiento 0.5.2 deja de firmar las solicitudes de eliminación de travesía de NAT con la clave de enrutamiento del nodo, lo que había vinculado esa clave al tráfico de travesía en los relays. También actualiza la biblioteca TLS utilizada para las conexiones con relays a una versión que corrige un problema descrito en un aviso de seguridad publicado y repara varios casos de pérdida de mensajes durante la renovación de claves de enlaces y sesiones.

Las notas de la versión instan a los operadores de todas las plataformas a actualizar, y detallan correcciones independientes para los permisos de archivos de claves en Windows, las pasarelas y los servicios de paquetes. Los nodos efímeros ya no escriben un archivo privado fips.key que un reinicio posterior podría sobrescribir; los operadores que pretendían mantener una identidad estable deben establecer el modo persistente antes de actualizar. La versión no cambia el formato de transmisión de la red mallada, por lo que los nodos con versiones distintas pueden actualizarse individualmente.

napplet soyLI 0.23.1–0.23.4 corrige la publicación del backend y la aprobación del firmante

soyLI de napplet.soy es el conjunto de herramientas de creación y publicación para pequeños programas de Nostr ejecutados en entornos aislados. Tras la versión de creaciones compartidas de la semana pasada, la versión 0.23.1 incorpora los manifiestos, los manejadores y los esquemas del backend a las comprobaciones del creador y a las vistas previas multijugador. Mantiene la configuración portátil de proveedores en el manifiesto del proyecto, mientras deja las vinculaciones privadas de identidad y las bases de datos de desarrollo fuera de la instantánea publicada del código fuente.

La versión 0.23.2 permite que los proyectos que en algún momento incorporaron al repositorio un contexto público de backend generado vuelvan a publicar tras una validación estricta, mientras sigue rechazando las vinculaciones privadas, los registros, las bases de datos y las credenciales presentes en el historial accesible. La posterior versión 0.23.4 corrige un fallo de sesión del backend persistente que podía rechazar una aprobación válida de una extensión o de un firmante remoto cuando una persona tardaba varios segundos en firmar. Los hosts públicos también necesitan la corrección del host compartido; actualizar únicamente la CLI del creador no ha reparado un host desplegado.

Dart NDK 0.10.0 delimita la autorización de Blossom y la firma remota

Dart NDK es una biblioteca de Flutter y Dart para el acceso a relays de Nostr, la firma, las solicitudes a monederos y las operaciones multimedia. Tras la versión preliminar de la semana pasada, 0.10.0-dev.7 cambia las solicitudes multimedia de Blossom para que permanezcan anónimas hasta que un servidor las rechace, y entonces las autoriza mediante una política explícita que indica qué identidad puede revelar una operación. Propaga esa autorización a lo largo de la ruta de la solicitud y sustituye las opciones anteriores useAuth y customSigner, un cambio de integración incompatible para las aplicaciones que utilizan la API preliminar.

Dev.9 deja de retener la respuesta de un firmante remoto hasta que el relay más lento la confirme. Dev.8 reduce las consultas periódicas a relays en segundo plano y el trabajo de caché; sus demás correcciones se refieren a la persistencia de la semilla del monedero y a los plazos de liquidación. La versión estable 0.10.0 ahora reúne esta serie de desarrollo junto con los cambios de metadatos de conexión y de identificadores privados de suscripción que se describen a continuación. La comparación con dev.9 incluye esos cambios integrados. Las aplicaciones que se actualicen deben revisar tanto el cambio de la API de autorización multimedia como la ruta de respuesta del firmante remoto.

La versión estable incluye metadatos de conexión y permisos solicitados de NIP-46, y sustituye los campos de conexión separados por un valor Nip46ClientMetadata. Se trata de un cambio de la API a nivel de código fuente que permite a los widgets de inicio de sesión pasar al bunker la identidad de la aplicación y los permisos solicitados. Otro cambio en los identificadores de solicitud utiliza 32 caracteres hexadecimales aleatorios en producción, lo que mantiene los nombres de los casos de uso y las fases de paginación fuera de los identificadores de suscripción visibles para los relays. Los identificadores explícitos siguen sujetos al límite de 64 caracteres de NIP-01, mientras que el modo de depuración conserva un nombre de diagnóstico corto.

Mostro Core 0.16.0 elimina el antiguo transporte gift-wrap

Mostro Core proporciona el protocolo de mensajes utilizado por los clientes de intercambio entre pares y el coordinador de Mostro basados en Nostr. La versión 0.16.0 elimina su transporte gift-wrap del protocolo v1 y sus antiguas funciones de envoltura y desenvoltura, y deja el transporte más reciente como la vía de la biblioteca. Es un cambio incompatible para las aplicaciones que todavía construyen o leen mensajes v1 mediante esta biblioteca.

La versión de la biblioteca precede a la versión 0.19.0 del coordinador, ya publicada. Los operadores que atienden a clientes antiguos deben actualizar ambos lados de la migración del transporte. El tag 0.15.1 anterior añade un estado de disputa por cancelación cooperativa, pero la eliminación del transporte es el hito de compatibilidad.

Cambium 0.6.0–0.7.1 registra un teléfono de desbloqueo mediante mensajes de relay

Cambium es una aplicación complementaria de firma para Android destinada a una clave de hardware Heartwood que también puede desbloquear la placa después de un reinicio. La versión 0.6.0 permite registrar un teléfono para el desbloqueo a través de los relays de Nostr de la placa sin un cable USB; el usuario compara cinco palabras de la solicitud en el teléfono, la placa y Sapwood, la interfaz de registro de la placa, antes de pulsar el botón de la placa. Los relays recién anunciados reciben un retraso de conexión aleatorio para que el primer contacto del teléfono no revele exactamente cuándo vio la actualización de la placa.

La versión 0.7.0 invierte el flujo de invitación: un teléfono escanea el código QR de corta duración de Sapwood y devuelve un único event cifrado de un solo uso desde una clave desechable. El reintento vuelve a publicar ese mismo event si ningún relay lo acepta, mientras que la antigua vía de visualización del código se mantiene para las compilaciones anteriores de Sapwood. El parche 0.7.1 mantiene visible el código de comprobación final y mejora la reproducibilidad de las compilaciones de F-Droid; el flujo QR sigue requiriendo las versiones recientes especificadas de Sapwood y Heartwood.

Bray 3.5.0–3.5.2 limita el gasto del monedero de Nostr iniciado por agentes

Bray es un servidor de herramientas de Nostr que permite a un asistente de IA solicitar acciones de relay, identidad y monedero mediante una interfaz de alcance delimitado. Su versión 3.5.0 añade un límite para cada pago de Nostr Wallet Connect y un presupuesto diario persistente, con confirmación humana cuando el host del asistente la admite. Atender conexiones de gasto separadas ahora requiere una configuración explícita del servicio de monedero, vuelve a comprobar cada autorización antes de usarla y restringe las consultas de facturas a los hashes incluidos en esa autorización.

La versión también indica a los usuarios que guarden el URI de conexión del monedero en un archivo privado en lugar de pegarlo en el chat, y se niega a reintentar un pago de resultado incierto como si su fallo estuviera demostrado. La versión 3.5.2 coteja localmente las vías de pago del mercado después de que los relays rechazaran el filtro de método de pago solicitado. Estas comprobaciones limitan lo que puede gastar un asistente con facultades delegadas e impiden que una suposición sobre el filtrado de los relays oculte ofertas coincidentes.

Mafrend 1.3.0-alpha migra los grupos privados del mapa a la versión actual de Marmot

Mafrend es una aplicación social de Nostr basada en mapas que permite explorar lugares y conversar sobre destinos. Su versión 1.3.0-alpha actualiza los grupos privados a una especificación más reciente de grupos cifrados de Marmot y añade vistas de perfiles desde chats y reseñas. El formato de grupo es incompatible con los chats de versiones alfa anteriores; los usuarios deben tratarlo como una migración alfa con una ruptura de compatibilidad.

La misma versión añade la posibilidad de compartir capturas de pantalla y cambios en los chats, junto con mejoras en el mapa y los marcadores. El proyecto sigue marcando las funciones de perfil como en desarrollo. El cambio significativo para Nostr es el cambio de interoperabilidad de los grupos privados; los usuarios con grupos de prueba antiguos deben consultar la nota de compatibilidad antes de actualizar.

Sonar alpha.15–alpha.15.1 corrige la publicación en grupos cifrados

Sonar es una aplicación de mensajería privada que permite mantener conversaciones a través de una red de malla Bluetooth y Nostr. Alpha.15 añade reacciones con emojis a los mensajes y permite compartir de forma privada la hora local dentro de los chats cifrados, con un ajuste para revocar esa función. Su monedero pasa a usar Cashu, pero ese cambio en los pagos es independiente de la actualización de mensajería.

Alpha.15.1 corrige un fallo de inicio que podía dejar vacío el índice de conversaciones después de que una compilación de una rama anterior escribiera una versión de esquema ajena. Sin el índice, la aplicación volvía a cifrar y publicar la información de hora local compartida en todos los grupos cada vez que se abría de nuevo, enviando a veces cientos de events antes de que intervinieran los límites de frecuencia de los relays. La corrección urgente reconstruye ese estado local y detiene las publicaciones repetidas en los grupos.

Los paquetes de comercio de Elisym introducen pedidos privados en Nostr

Elisym es un conjunto de herramientas para agentes basado en Nostr que ahora está desarrollando un flujo comercial con events firmados. Su paquete commerce integrado define los productos de la tienda, la autorización del propietario, los pedidos y recibos encapsulados de forma privada y la verificación de ofertas para los componentes de pago y del comerciante. Una etiqueta posterior de commerce 0.2.0 deriva la referencia de pago de un pedido a partir del propio pedido, vinculando la consulta del pago al flujo de compra firmado.

La serie de paquetes también introduce trabajo separado en payment-core y en el proceso de pago del navegador, pero sus tags de versiones no demuestran que esté desplegado un proceso de pago completo para comerciantes. El kind del event de autorización de la tienda se declara explícitamente provisional en la fuente primaria del proyecto. Las once tags de SDK, MCP, CLI y payment-core corresponden a una única función comercial en desarrollo.

Las nuevas versiones de paquetes de Elisym empaquetan el nodo de comerciante autoalojado, mientras que MCP 0.31.0 añade buy_product y get_order para los productos comerciales. Las versiones posteriores de commerce y merchant-node añaden compatibilidad con pagos Tempo dentro de ese mismo proceso de pago. Estos paquetes hacen avanzar la integración existente de productos firmados y pedidos privados; la lista de tags no convierte el esquema provisional de events en un estándar ni demuestra el lanzamiento de un servicio alojado completo.

Flotilla 1.11.2 resuelve bloqueos con firmantes y feeds incompletos de relays

Flotilla es un cliente Nostr para conversaciones, salas y espacios compartidos. La versión 1.11.2 ofrece al usuario una salida cuando el inicio se bloquea a la espera de un firmante remoto y cierra la sesión cuyos datos locales de la aplicación se hayan borrado. Ahora una sala puede mostrar sus mensajes antes de que termine de sincronizarse el espacio más amplio al que pertenece, mientras que los feeds ya no omiten publicaciones simplemente porque un relay haya respondido más tarde que otro.

La misma versión también publica una compilación para F-Droid firmada con la clave existente de la aplicación y mantiene al día las versiones de GitHub para Obtainium. Ese trabajo de distribución es importante para los usuarios que cambian de canal de actualización, pero las correcciones de relays y firmantes son el motivo inmediato para actualizar.

Ditto 2.42.3 muestra la entrega a relays y refuerza los límites entre cuentas

Ditto es un cliente social Nostr que permite a los usuarios elegir sus relays y autenticarse en ellos. En la versión 2.42.3, los Detalles del event de una publicación muestran qué relays del usuario y del autor la almacenan; Difundir se dirige únicamente a aquellos en los que falta. La versión también señala los relays de lectura que no responden y ofrece un control para reintentarlo, lo que facilita diagnosticar una publicación ausente sin volver a enviarla a todas partes.

Las notas de la versión indican que cambiar de cuenta ya no envía publicaciones a los relays de la cuenta anterior, que los usuarios silenciados no pueden activar alertas genéricas en el teléfono y que los enlaces o imágenes de las publicaciones no pueden acceder a dispositivos de la red local del lector. Las publicaciones de relays lentos dejan de desaparecer de los feeds Seguidos y Favoritos, mientras que el chat de las transmisiones en directo y los juegos webxdc se actualizan sin descargar repetidamente la vista completa. La navegación de torrents y audio también es nueva, pero el enrutamiento de relays y el aislamiento entre cuentas son los cambios con mayor repercusión en Nostr.

Iris Chat 2026.9.24.4 incorpora llamadas a las conversaciones cifradas

Iris Chat es una aplicación de mensajería Nostr con cifrado de extremo a extremo que utiliza la familia de protocolos de chat de doble trinquete. Su versión del 24 de septiembre añade llamadas de voz y vídeo con contactos compatibles, incluso a través de una conexión local existente cuando no hay acceso a internet. El usuario puede reducir la calidad del vídeo, responder a una videollamada solo con voz y gestionar una llamada entrante mediante la interfaz de llamadas de Android; responder o rechazar también hace que los demás dispositivos vinculados dejen de sonar.

La versión también permite iniciar sesión mediante una aplicación de firma independiente y ver qué dispositivos vinculados están conectados. Los parches posteriores del 24 de septiembre conservan las marcas de tiempo originales de los mensajes retrasados y mejoran la entrega a dispositivos cercanos tras la pérdida de un paquete de reconexión. Son comportamientos iniciales de llamadas y entre dispositivos, por lo que la actualización resulta más útil para contactos que puedan ejecutar compilaciones compatibles de Iris.

La posterior actualización del 30 de septiembre, firmada por el desarrollador, conserva el historial local del grupo de un miembro eliminado, pero desactiva el envío, mejora la entrega entre dispositivos vinculados y en grupos grandes, y corrige los indicadores de lectura y los recuentos de mensajes no leídos. Las llamadas incorporan la selección del dispositivo de audio y recuperan los tonos de llamada saliente; un estado desactualizado del micrófono ya no silencia el audio entrante. Se corrigen el silenciamiento temporal, la copia de imágenes, los archivos adjuntos mediante arrastrar y soltar, el enrutamiento de notificaciones y el registro de notificaciones push, mientras que cerrar sesión borra las cachés locales y eliminar un dispositivo finaliza su sesión. Una segunda actualización mejora el acceso a los archivos almacenados en caché por otras aplicaciones Iris en el mismo dispositivo y mantiene disponible el intercambio local de archivos con Nearby desactivado.

LibreNostr 0.6.0–0.7.0 enruta los relays a través de Tor integrado

LibreNostr es un cliente Nostr para Android con ajustes configurables de relays y privacidad. La versión 0.6.0 incluye un motor Tor basado en Arti en ARM64 y aplica el modo elegido, Directo, Tor para todo o solo .onion, a las conexiones WebSocket de los relays, las solicitudes HTTP, los archivos multimedia, las subidas y las páginas web. El modo Tor estricto bloquea las conexiones cuando Tor no está disponible y nunca envía una solicitud directamente sin avisar; cambiar de modo reconecta los sockets de los relays a través de la nueva ruta.

La versión 0.6.2 añade un filtro de red de confianza en el dispositivo, construido a partir de listas públicas de seguimiento, y elige relays complementarios según las personas seguidas adicionales a las que permiten llegar. La versión 0.7.0 muestra después las notas y notificaciones antes de que terminen las consultas de perfiles y recuentos, limita las consultas a relays lentos y deja de descifrar toda la bandeja de mensajes directos cada vez que se abre una conversación. En conjunto, estas versiones cambian tanto los destinos a los que puede conectarse el cliente como el tiempo durante el que un relay lento puede bloquear su interfaz.

Su primera versión estable, 1.0.0, firmada por el desarrollador, añade paneles para tabletas guardados por perfil, con columnas móviles para feeds, hashtags, perfiles, lectura de textos largos, notificaciones y mensajes. Las tabletas en orientación horizontal reciben esta distribución; los teléfonos conservan su interfaz existente. La búsqueda incorpora OR, exclusiones, filtros multimedia e intervalos de fechas funcionales, devuelve los perfiles almacenados en caché antes de los refinamientos procedentes de relays y pasa inmediatamente a la siguiente opción cuando se rechazan solicitudes de texto completo. Los hashtags se ordenan cronológicamente, la paginación espera a recibir suficientes respuestas de relays y los feeds no utilizados liberan sus suscripciones.

La misma versión conserva durante las ediciones las entradas existentes, públicas y cifradas, de las listas de silenciados y los marcadores, en lugar de sustituirlas por un único cambio. Aísla los marcadores y las notificaciones entre cuentas y restringe los relays auxiliares de los autores a lecturas públicas, sin enviarles solicitudes privadas ni autenticarse en ellos. También impide que las respuestas desactualizadas de perfiles sustituyan metadatos más recientes, corrige la paginación y los indicadores de notificaciones, conserva los elementos antiguos del feed cuando llegan otros nuevos y corrige las cuentas atrás para deshacer respuestas, la publicación duplicada, las URL multimedia con cadenas de consulta y los recuentos de mensajes no leídos después de marcar un chat como leído. La versión 1.0.1 corrige un cierre inesperado al iniciar los paneles para tabletas en la nueva distribución.

Newlay 0.3.45 transmite progresivamente las consultas grandes en lugar de cerrar las conexiones

Newlay es un relay de Nostr alojado en Android y un conjunto de servicios locales relacionados. Su anuncio firmado de la versión 0.3.45 indica que los resultados de consultas grandes ahora se transmiten progresivamente con contrapresión en lugar de cerrar la conexión del cliente. El servidor Git integrado elimina los paquetes sustituidos después de los envíos, mientras que su coordinador de mensajería cifrada Cordn acepta solicitudes de clientes de gran tamaño y envía una trama de cancelación cuando se agota el tiempo de espera de una comprobación.

La versión también ofrece al operador de Android una tarjeta de estado en tiempo real para los events, el almacenamiento, la dirección y la administración, y adapta la biblioteca criptográfica nativa a los dispositivos con páginas de memoria de 16 KB. Los cambios del relay y del coordinador abarcan varias versiones desde la versión anterior de la tienda, 0.3.39; 0.3.45 es la versión que los reúne.

ngit-grasp 3.0.5 mantiene en marcha los envíos de Git y la sincronización con relays

ngit-grasp es un relay de Nostr y servidor Git autoalojado para la colaboración firmada en repositorios. Su anuncio firmado de la versión 3.0.5 saca la lenta reconciliación del historial del actor compartido de sincronización en tiempo real, lo que permite iniciar las suscripciones a relays mientras se comprueban los events anteriores. Aplica esperas entre reintentos por separado para los límites de frecuencia, las consultas de historial incompletas, las lecturas del buzón y las búsquedas de identidad, de modo que un relay con problemas ya no monopoliza la capacidad de reintento.

La misma versión realiza la reconciliación con el inventario local de events para evitar volver a obtener el historial almacenado y cierra las suscripciones incompletas antes de considerar verificada su cobertura. En Git, acepta los envíos que la promoción de estado en segundo plano ya había aplicado, conserva la protección contra conflictos para las referencias modificadas y consume la salida de progreso de Git durante las cargas para evitar que un envío se bloquee. Estos detalles importan porque un repositorio puede parecer activo en los relays mientras su transferencia de Git sigue esperando un resultado definitivo.

Armada 0.63.0 ofrece alertas push para distintos tipos de firmantes

Armada es un cliente de Nostr para comunidades, canales y mensajes directos cifrados. Tras la versión de la semana pasada centrada en la privacidad de los archivos multimedia, su anuncio firmado de la versión 0.63.0 describe una nueva vía de notificaciones push del navegador que funciona con la aplicación cerrada tanto para los inicios de sesión mediante extensiones y firmantes remotos como para otros tipos de cuentas. Tenna, una aplicación anfitriona que integra Armada, también incorpora notificaciones en segundo plano para sus usuarios.

La versión carga más rápido los mensajes antiguos de canales comunitarios largos y evita volver a leer todo el historial para obtener mensajes nuevos. Los indicadores de escritura de los mensajes directos utilizan menos conexiones a relays. Las actualizaciones de escritorio incorporan un aviso para reiniciar, mientras que las actualizaciones directas desde versiones anteriores a 0.50.0 dejan de ser compatibles.

La versión posterior 0.63.1, firmada, añade paquetes de emojis editables con importación desde carpetas y reordenación, recupera mensajes citados más allá del historial cargado y hace interoperables las respuestas alojadas en relays. Reduce el tráfico de reconexión en Android, se pone al día tras desconexiones prolongadas sin repetir alertas antiguas, excluye las menciones anteriores a la incorporación y conserva los campos de grupo no editados y las entradas privadas de la lista de servidores. Las eliminaciones en grupos alojados en relays ahora requieren al autor del mensaje o a un administrador. También se corrigen el arrastre de servidores, el tratamiento de información de relay malformada y las suscripciones a repositorios.

La versión 0.63.2 amplía el Markdown de los mensajes para admitir citas y listas anidadas, líneas horizontales, bloques de código delimitados, encabezados subrayados y formato que abarca enlaces o menciones. Los enlaces a páginas de Tenor y Giphy se reproducen como GIF. La sincronización del estado de lectura transfiere menos datos, la reconexión evita descargas e inicios de sesión redundantes y las notificaciones en segundo plano de Android pausan la sincronización con relays cuando las actualizaciones grandes de ajustes la saturan.

deed 0.3.0–0.3.2 hace más estable la publicación en Nostr con Zig

deed es una herramienta de línea de comandos escrita en Zig para leer y publicar events de Nostr. Su versión 0.3.2 del 24 de septiembre añade una habilidad para agentes y corrige los plazos de ping del relay; las versiones anteriores 0.3.1 y 0.3.0 mejoran el rendimiento y la fiabilidad de la publicación. Las tres tags describen una misma serie inicial de la herramienta. El beneficio visible para Nostr es una conexión al relay y una vía de publicación de events más estables para los scripts que utilizan la CLI.

Cordn 0.5.1 mantiene en marcha los demás grupos cuando falla un coordinador

Cordn es una aplicación de mensajería grupal cifrada con MLS que utiliza identidades y relays de Nostr para localizar coordinadores de conversaciones. Su versión firmada 0.5.1 del cliente continúa el trabajo de la semana pasada sobre la cola sin conexión separando la planificación del coordinador y la de la bandeja de salida: un coordinador no disponible ya no retrasa los envíos de grupos no relacionados. Las indicaciones de relay resueltas se conservan después del descubrimiento, los documentos de grupo las transportan entre dispositivos y un registro persistente de publicaciones pendientes recupera los envíos atascados. La recuperación entre varios dispositivos solapa las consultas de la cadena del historial y de los huecos mientras lee la configuración actual.

La versión también añade archivos adjuntos mediante arrastrar y soltar, grupos fijados, nombres de perfil en vistas previas y notificaciones, y etiquetas de coordinadores. Corrige el posicionamiento en el primer mensaje no leído, los contadores de mensajes no leídos, las alertas duplicadas, las vistas previas de archivos multimedia y mensajes del sistema, las respuestas vinculadas a archivos multimedia con texto descriptivo y los controles de zoom de imágenes. Las descargas nativas utilizan un selector de «Guardar como». Un firmante que aparece tarde ya no provoca una advertencia falsa de cifrado no compatible, y el cambio de cuenta ya no entra en una condición de carrera con la inicialización en segundo plano.

Nymbot es un asistente al que se accede mediante mensajes de Nostr cifrados y encapsulados con gift-wrap. Su versión 1.0.7 firmada por el desarrollador lee documentos en el dispositivo, selecciona pasajes relevantes cuando un archivo es demasiado grande para enviarlo completo e identifica las páginas utilizadas. Las conversaciones pueden compartirse mediante un enlace cifrado de extremo a extremo cuyo acceso puede retirarse posteriormente. Las respuestas en Python y JavaScript pueden ejecutarse localmente, y su salida se devuelve a la conversación.

La misma versión añade investigación con fuentes y un precio mostrado antes del envío, edición de imágenes, selección de modelos por mensaje y límites de gasto por conversación y bot. Las herramientas externas conectadas mediante MCP solicitan confirmación antes de modificar datos. Las ejecuciones en repositorios pueden pausar los cambios para su revisión, mostrar resultados de CI y reanudarse después de que una pasarela haya estado ocupada. Las respuestas sugeridas, los avisos fijados, las listas de fuentes plegadas y un selector de modelos con búsqueda completan la actualización; estas afirmaciones proceden de las notas de la versión del desarrollador; Compass no ha auditado de forma independiente la privacidad de la aplicación.

0xchat 1.5.6 incorpora sus correcciones de firma y autenticación de mensajes

0xchat es una aplicación de mensajería de Nostr con conversaciones privadas, firma externa y funciones de monedero. La versión 1.5.6 incorpora las correcciones de seguridad cubiertas la semana pasada como cambios integrados en el código fuente, entre ellas la autenticación de gift-wrap, la configuración de infraestructura de confianza y el consentimiento para la firma desde páginas integradas. También cierra las vías para eludir el proxy Tor, valida los certificados TLS de los hosts que no son onion e impide que las compilaciones de distribución escriban credenciales y material del monedero potencialmente sensibles en la consola del dispositivo. Los registros para desarrolladores, que se activan de forma voluntaria, siguen registrando errores.

La versión aumenta progresivamente la espera entre reconexiones al relay de tres segundos a cinco minutos, repara las suscripciones después de la reconexión y entrega las solicitudes puestas en cola mientras un relay se está conectando. Los cambios de cuenta dejan de acumular escuchadores de relay duplicados, un inicio de sesión fallido conserva la cuenta que ya está activa y las conexiones con firmantes externos persisten entre arranques. Los envíos fallidos ahora muestran errores y conservan el texto no enviado o el estado recuperable del uso compartido de tokens. El descifrado de claves al iniciar y el cálculo de hashes de las cargas se trasladan fuera del hilo de la interfaz de usuario; las cachés de conversaciones y vídeos evitan renderizados y descargas repetidos. La versión proporciona archivos para Android y escritorio con sumas de comprobación SHA-256, incluidos el APK de Android firmado por Play y un instalador de Windows compilado a partir del código fuente.

Nostr Mail Client 0.17.0 oculta las acciones del buzón a los relays

Nostr Mail Client intercambia correo electrónico a través de Nostr y también admite la entrega convencional de correo electrónico. Tras la versión de la semana pasada con transporte por destinatario y privacidad de los archivos multimedia, la versión 0.17.0 oculta a los relays el estado de lectura, archivo, carpetas y etiquetas, así como los momentos en que cambia, y permite a los usuarios eliminar correo sin notificar al remitente. La versión requiere actualizar todos los dispositivos a la vez porque los clientes anteriores no ven el nuevo estado ni las eliminaciones. También protege a los destinatarios en copia oculta en correos de más de 32 KB, mantiene los alias locales de los contactos fuera de los mensajes salientes, corrige el inicio de sesión con QR de Amber y publica el correo público en los relays de lectura de los destinatarios.

La versión añade carpetas y etiquetas de colores con reglas de remitente, asunto y archivos adjuntos; citas en respuestas y reenvíos; imágenes pegadas en línea; vistas previas y cambio de nombre de archivos adjuntos; y selección de rangos en las listas de correo. El reenvío conserva las imágenes y los archivos adjuntos originales, las citas de las respuestas aparecen contraídas inicialmente y el editor web incorpora un menú contextual. Las tablas HTML y las imágenes en línea se muestran con mayor precisión, los enlaces en texto sin formato funcionan y la programación admite fechas hasta cinco años en el futuro. Los nombres y las imágenes de la libreta de direcciones aparecen en toda la interfaz, y los colores del tema ofrecen paletas del sistema, sugeridas o personalizadas.

La misma versión mantiene en local los fondos seleccionados desde archivos y almacena en caché los fondos enlazados, con un coste de migración explícito: los fondos de archivo anteriores en plataformas nativas deben añadirse de nuevo. Cambia las recomendaciones predeterminadas de relays y archivos multimedia, añade el descubrimiento de aplicaciones Nostr durante la configuración inicial y avisos de actualización, conserva los ajustes desconocidos escritos por otros clientes y corrige la creación interrumpida del almacén de correo y el empaquetado para Linux. Los fallos de inicio ahora muestran detalles y un informe prerrellenado en lugar de una pantalla en blanco.

Nostr WoT 0.8.7 vincula la autenticación al destino

Nostr WoT es una extensión de navegador que combina la firma de Nostr con herramientas de confianza. La versión 0.8.7 exige consentimiento para la autenticación HTTP firmada de NIP-98 respecto a la URL, la consulta, el método, la cuenta y el origen solicitante exactos. Las aprobaciones amplias anteriores requieren un nuevo consentimiento. La autenticación de relays de NIP-42 tiene un sistema de permisos separado y vinculado a la cuenta, en el que las denegaciones específicas de un sitio tienen prioridad sobre las autorizaciones compartidas de relays. Las solicitudes de autenticación deben proceder de un origen de navegador de nivel superior verificado, y las esperas de aprobación o desbloqueo activan otra comprobación de cuenta y acceso.

La versión verifica las firmas remotas de NIP-46 y el event aprobado completo para que una firma devuelta no pueda sustituir silenciosamente el contenido o un destino. El aprovisionamiento de la cartera y los cambios de dirección utilizan autenticación vinculada al cuerpo, desafíos del backend de un solo uso y tokens de transacción separados; la firma genérica para sitios web no puede generar esos tokens internos de la cartera. El backend compatible debe desplegarse primero, y el cliente se niega a recurrir a endpoints retirados. Los pagos de Nostr Wallet Connect también verifican la preimagen de pago devuelta frente al hash de la factura solicitada y consideran cualquier discrepancia como un resultado desconocido.

En la interfaz de solicitudes, los usuarios pueden inspeccionar los events completos sin procesar, elegir solicitudes concretas dentro de un grupo de un sitio y ver mensajes privados en local sin aprobar su devolución a un sitio web. Las vistas previas locales se ocultan tras 30 segundos; las solicitudes entrantes permanecen sin seleccionar y la aprobación masiva ordinaria excluye la autenticación. La extensión separa los permisos de relays por sitio y para todos los sitios, limita el almacenamiento en caché de perfiles verificados, resuelve los events reemplazables con la misma marca de tiempo eligiendo el ID de event menor y mantiene en local las lecturas de publicaciones de la ventana emergente principal. Chrome y Firefox reciben paquetes verificados por separado y flujos de envío de versiones estables serializados; esos flujos no demuestran la disponibilidad actual en las tiendas.

El entorno de ejecución compartido de Iris mantiene coherentes los historiales de relays y pares

nostr-pubsub proporciona un entorno de ejecución compartido de events de Nostr con almacenamiento persistente de events y una cola de publicaciones salientes. Las versiones 0.5.7–0.5.13 agrupan suscripciones exactas en lotes, las reproducen tras la reconexión, mantienen separadas las evidencias locales, de relays y de pares, e informan de un historial incompleto cuando falla el almacenamiento duradero. Las consultas completadas esperan a que cada event recibido termine su admisión. El lote predeterminado de relays contiene ahora como máximo 20 filtros OR para mantener la compatibilidad con servidores habituales, mientras que los lotes de pares conservan la coincidencia y la cancelación independientes.

Las actualizaciones del entorno de ejecución de Hashtree sustituyen la conectividad de red específica de cada worker por ese entorno de ejecución compartido, índices persistentes de events y una cola de salida, lo que permite que los events y los archivos almacenados en caché compartan un nodo FIPS. FIPS TypeScript 0.0.44–0.0.45 selecciona rutas con capacidad suficiente para registros de señalización completos, recupera el establecimiento de sesiones interrumpido dentro del plazo del handshake y reintenta las respuestas WebRTC solo tras un rechazo explícito de enrutamiento. Las rutas WebSocket con tramas de mayor tamaño requieren pares nativos compatibles; las notas de 0.0.44 exigen desplegar primero FIPS nativo 0.4.85.

Iris Kit 0.2.5 añade un cliente de aplicación persistente para events simples y firma NIP-46 independiente del transporte, al tiempo que conserva las claves de las cuentas y las lecturas sin conexión. La versión 0.2.6 devuelve de inmediato desde el worker o el backend nativo un ID de event completo ya verificado; las consultas por prefijo y de events reemplazables siguen esperando al historial antes de elegir el valor más reciente. Estas son versiones de bibliotecas, y las notas no acreditan su despliegue en todas las aplicaciones de Iris.

La actualización del código fuente de Iris Meet del 30 de septiembre sustituye su integración con NDK por una infraestructura persistente de publicación y suscripción y firmantes de identidad compartidos. El parche añade cobertura para la restauración de identidad sin conexión, la firma NIP-07 y el aislamiento de las salas de reunión. La aplicación de reuniones existente utiliza Nostr para la señalización cifrada y WebRTC para el audio y el vídeo. Se trata de avances de implementación en la rama predeterminada; el repositorio no tiene ninguna versión etiquetada que demuestre que esta actualización concreta haya llegado al sitio en producción.

Chama propaga la cancelación de anuncios y las alertas en segundo plano

Chama utiliza events firmados para intercambios comunitarios y conversaciones privadas. Las versiones 6.4.14–6.4.16 publican una cancelación firmada antes de eliminar un anuncio en local, para que otros clientes puedan retirar la misma oferta almacenada en caché. Los tags de activación de los destinatarios acompañan ahora a los events independientemente de la configuración de notificaciones del remitente, y el servidor de alertas elimina duplicados por event firmado para que un chat inmediatamente después de incorporarse pueda seguir provocando una activación. Las tareas en segundo plano vuelven a procesar los intercambios afectados desde los cursores guardados, aíslan las cadenas fallidas y descifran el texto de las notificaciones en local; la versión requiere volver a desplegar el servicio de vigilancia complementario.

Las versiones agrupadas también aplican las renovaciones de los participantes en los momentos de sus events firmados, ponen en cuarentena los bloqueos de fondos realizados después de que caducara una plaza y ofrecen una opción de recuperación para la nota al portador guardada. La publicación de la reclamación espera a que se confirme la importación o el pago. Los filtros de anuncios conservan la moneda del usuario que los consulta en los distintos ámbitos comunitarios, y las cabeceras de los intercambios utilizan el importe incorporado definitivo. Estos cambios armonizan lo que dos clientes conectados a Nostr deducen del mismo historial de events.

Earthly 0.1.12 añade configuraciones de mapas reutilizables

Earthly es un editor colaborativo de mapas basado en Nostr con publicación firmada y uso compartido cifrado. La versión 0.1.12 añade configuraciones reutilizables de GMapper para Google My Maps públicos, descubrimiento de Maplets creados por desarrolladores, almacenamiento privado o publicación pública de configuraciones y copia de geometrías con atribución. La misma versión añade el uso compartido cifrado de conexiones, entregas de entidades y navegación del chat en móviles. La disponibilidad de exportación de Google y el CORS del navegador limitan la importación, los Maplets ejecutables descargados siguen sin estar disponibles en Tauri y las comprobaciones de actualización en dispositivos Android físicos siguen pendientes.

El trabajo de configuración migró las direcciones de publicación y las preferencias existentes y añadió la revisión o retirada de las actualizaciones de configuración. Su flujo inicial de Android falló antes de la compilación; una corrección de las herramientas preparó la versión etiquetada posteriormente.

Mostro 0.19.0 retira su transporte de primera generación

Mostro coordina intercambios entre pares a través de Nostr. La versión 0.19.0 ya incluye la eliminación de su transporte gift-wrap de primera generación, por lo que los clientes deben usar el protocolo más reciente. Los tags de marca de tiempo existentes para la creación de órdenes y la apertura de disputas pasan a llamarse published_at sin cambiar sus valores almacenados; el created_at del event que los contiene sigue siendo su hora de firma. Las respuestas de restauración devuelven la clave de intercambio de la contraparte, las operaciones de creación y aceptación aceptadas reconocen las claves de intercambio, y la publicación en relays se completa con la primera confirmación positiva de un relay. La misma versión actualiza los plazos y la cancelación de las fianzas, cierra las disputas cuando se resuelve un intercambio, notifica al encargado de resolverlas y limita la antigüedad de los precios transmitidos por relays.

La corrección de la admisión de claves de intercambio de Mostro reconoce una clave en cuanto se confirma la orden o disputa que la introduce. Antes, los nodos con requisitos de prueba de trabajo más estrictos para el primer contacto podían descartar un mensaje de seguimiento legítimo hasta la actualización periódica de claves conocidas; los umbrales iguales a los predeterminados no se veían afectados. Una transacción de disputa confirma de forma atómica la transición de la orden y la fila de la disputa, eliminando los fallos por estados inconsistentes. Las notificaciones de cierre envían al encargado asignado un mensaje privado, sin garantía de entrega, cuando los usuarios resuelven una disputa, y el event reemplazable existente sigue siendo la alternativa para cuando está desconectado.

SCRUTINY Lens lleva la investigación de seguridad a Nostr

SCRUTINY Lens v0.1.0, su primera versión pública del 29 de septiembre, es un cliente de navegador para metadatos de seguridad publicados a través de Nostr. Los analistas pueden buscar por CVE, identificadores de paquetes o certificados, examinar historiales de events y retractaciones, y explorar relaciones en un grafo de temas. El navegador verifica las firmas y los identificadores de los events. La búsqueda y las explicaciones opcionales con IA usan un punto de conexión elegido por el usuario; la aplicación comprueba las citas incluidas frente a los events subyacentes. Las notas de la versión describen explícitamente las limitaciones de los relays e identifican dependencias de compilación local que todavía requieren repositorios hermanos.

Mangatsu y Noteds llegan a Android

Mangatsu v0.1.11 forma parte de la primera serie de versiones para Android de este lector y editor de cómics, publicada esta semana. Su código fuente añade el inicio de sesión con Amber a través de NIP-55, la interfaz de Android para solicitar a un firmante externo que apruebe operaciones de Nostr. Los cómics y los capítulos son events de Nostr, mientras que sus páginas se alojan en servidores Blossom; el lector también admite una biblioteca guardada cifrada y la lectura sin conexión. Los commits posteriores abordan la invocación del firmante y las actualizaciones de las listas de relays.

Noteds v0.1.2 lleva a Android un mercado de anuncios clasificados de Nostr mediante Tauri. Su integración con el firmante de Android usa la firma NIP-55 de Android. La aplicación publica anuncios y mensajes a través de Nostr y construye un grafo de búsqueda local con categorías, zonas geográficas y representaciones vectoriales opcionales en el navegador. El código fuente más reciente corrige el acceso nativo a la ubicación para la búsqueda de resultados cercanos. Ambos proyectos están en sus primeras versiones; sus páginas de versiones en GitHub no tienen notas detalladas, por lo que estas capacidades proceden de los README de las versiones etiquetadas y de los commits de implementación.

Statim combina los mensajes directos de Nostr con otras redes

Statim v0.4.0 sucede a su versión inicial del 23 de septiembre. El código fuente etiquetado describe una aplicación de mensajería con mensajes directos de Nostr mediante NIP-17 junto con XMTP, Status, Telegram y Matrix. Las cuentas parten de una frase de recuperación almacenada localmente; cada conversación identifica su protocolo porque esas redes ofrecen distintas propiedades de privacidad. Android carece actualmente de integración con Telegram. Estas son las capacidades documentadas del proyecto, no garantías comprobadas de forma independiente ni una confirmación de disponibilidad en las tiendas de aplicaciones.

En desarrollo

Amethyst corrige la interoperabilidad de los grupos cifrados

Amethyst es un cliente Nostr para Android compatible con los grupos cifrados de Marmot. White Noise es otro servicio de mensajería de Marmot; un conjunto de cambios de interoperabilidad probado con sus clientes aborda la administración de grupos, la redacción relativa a las eliminaciones y otros comportamientos que se manifiestan cuando los dos clientes comparten una conversación. Otras correcciones más específicas envían reacciones y eliminaciones dentro del grupo de Marmot en lugar de hacerlo como mensajes privados independientes con envoltorio de regalo de NIP-17 y aplican las ediciones de otro cliente después de reiniciar. Se trata de cambios integrados en el código fuente; las pruebas descritas en las PR tienen un alcance más limitado que una versión publicada con interoperabilidad entre clientes.

Una integración independiente del entorno de ejecución y la interfaz de grupos de Cordn añade otra vía para los grupos cifrados a través de servidores coordinadores. Cordn es distinto de Marmot, por lo que los dos cambios no deben interpretarse como una única migración de transporte.

Amethyst también integró comandos HTTP de relay en su relay Geode y su cliente Quartz bajo su propuesta NIP-FE, y una interfaz de revisión de conflictos de copias de seguridad para los event reemplazables de perfiles y listas. NIP-FE es una denominación de propuesta del proyecto; el flujo de copias de seguridad permite comparar versiones antes de aceptar un reemplazo y evita sobrescrituras silenciosas del estado local.

Amethyst también desarrolla Concord, un protocolo independiente de comunidades cifradas utilizado por Armada y Accordion. Un conjunto de cambios de conformidad añade listas de comunidades fragmentadas, pruebas de fijación, rotación de claves y registros de disolución, seguido de mensajes que desaparecen e invitaciones directas. Una invitación permanece en una bandeja de entrada privada hasta que se acepta; recibirla no establece contacto con los relays de la comunidad. El mismo cambio corrige una comparación de autores que podía permitir que una eliminación de otro autor borrara un mensaje. Las correcciones entre clientes reparan la serialización de rumores sin firma, los campos de invitación ausentes, la creación de comunidades confirmada por un relay y la incorporación sin reiniciar; las pruebas en emuladores descritas incluyeron pares de Armada y Accordion en funcionamiento.

Una implementación posterior de canales privados rota las claves del canal después de las revocaciones de acceso pertinentes y añade controles para crear, privatizar, hacer público y renovar las claves. También añade expulsiones cooperativas con comprobación de rango y hace que los archivos adjuntos de los mensajes caduquen junto con los mensajes a los que pertenecen. Las actualizaciones de WebXDC pueden entrar en un búfer de canal independiente, pero Amethyst sigue sin disponer de un entorno anfitrión para aplicaciones WebXDC. Ese conjunto posterior de cambios informa de pruebas del formato de transmisión y pruebas unitarias, sin pruebas en dispositivos ni con relays en funcionamiento, por lo que el resultado anterior de interoperabilidad no certifica todos los controles recién añadidos.

El motor MLS de Quartz ahora conserva los secretos de generaciones de mensajes omitidas después de reiniciar, lo que permite que los mensajes fuera de orden sigan siendo descifrables después de restaurar el estado guardado. Cuatro épocas anteriores conservadas permiten a quienes invocan el motor autenticar mensajes de aplicación tardíos, conservar sus datos autenticados e impedir que una generación ya consumida vuelva a abrirse. Una actualización del árbol de secretos carga secretos de nodos sin expandir desde un estado de estilo ts-mls; los errores de generaciones obsoletas específicos del remitente distinguen una colisión del mecanismo de trinquete del propio cliente de una repetición por parte de otro miembro. La PR indica explícitamente que el mecanismo alternativo existente de Marmot para épocas conservadas sigue siendo independiente, por lo que esta es una capacidad del motor, no una prueba de que todas las vías de mensajes de Amethyst la utilicen.

Una auditoría del lector de tag de Quartz corrige entradas privadas de geohash que podían publicarse en texto claro y un analizador que trataba la clave privada de un nsec como una clave pública. También repara las direcciones de republicación, los destinos para ocultar canales, los tag raíz de salas en directo y los event de mint direccionables. Se elimina el lector obsoleto ForkTag, lo que introduce un cambio en la API del código fuente para quienes utilizan Quartz; las filas de mint preexistentes en SQLite siguen necesitando una migración independiente. Los modelos adicionales de event cubren las propuestas de Buzz para contenedores de proyectos, revisiones de artefactos y equipos, mientras que los modelos de visualización de vídeo y control cifrado de notificaciones push siguen los esquemas de Divine; estas incorporaciones establecen compatibilidad con el análisis y la construcción, no interfaces de cliente completas ni NIP numerados adoptados.

El cliente también muestra fotografías Ultra HDR en el feed y el visor a pantalla completa en Android 14 o posterior. Android 15 y versiones posteriores limitan el aumento de brillo del feed al doble del rango ordinario, mientras que a pantalla completa se puede utilizar todo el rango de la pantalla; los dispositivos de prueba descritos ejecutaban API de Android más recientes, por lo que Android 14 y 15 quedaron sin probar. Una integración de la interfaz compartida y la adaptación de las cargas traslada 140 pantallas a código común para Android y escritorio y saca el trabajo multimedia de Android del hilo de la interfaz. Su auditoría también restablece la notificación de errores al eliminar metadatos, de modo que la refactorización es más que un traslado de archivos.

Divine añade vídeo cifrado a los mensajes directos

Divine es un cliente de vídeo de Nostr. NIP-17 transporta mensajes privados en envoltorios de regalo cifrados que ocultan su remitente a los relays. El trabajo integrado de Divine sobre mensajes de vídeo cifra un vídeo adjunto en el dispositivo, carga el texto cifrado y envía la clave de descifrado dentro de ese mensaje privado. El destinatario puede verificar y descifrar el archivo para reproducirlo o guardarlo. Una corrección independiente de la restauración del historial evita que una negativa ambigua de un relay ponga fin prematuramente a la recuperación cuando otros relays todavía pueden responder.

La corrección de Divine para claves de moderación retiradas rechaza las claves retiradas al resolver etiquetas de moderación y selecciona al destinatario actual de las denuncias cuando se presenta una. Las denuncias pendientes dirigidas a una clave retirada se redirigen a la clave fijada en la compilación, y las conversaciones sin resolver siguen sin admitir escritura. El cambio también distingue la custodia de las claves retiradas al decidir qué hilos históricos puede leer un menor; las actualizaciones de custodia siguen requiriendo una nueva versión de la aplicación. La gestión de comentarios eliminados en la caché impide que un comentario reciente eliminado correctamente vuelva a aparecer cuando se recarga un hilo.

Para los creadores, un modo de grabación con máscara de color en directo muestra una vista previa del fondo de reemplazo antes de grabar una toma, y el enmascaramiento de paredes blancas añade enmascaramiento sensible al brillo a través del complemento de vídeo. Los subtítulos palabra por palabra conservan los tiempos de las palabras reconocidas y utilizan tiempos aproximados cuando el servidor solo proporciona segmentos completos. La continuación de stop-motion añade nuevas imágenes fijas al ritmo de la composición existente, mientras que la reincorporación de clips separados, la selección de fuentes agrupadas y los ajustes predefinidos de velocidad añaden controles de edición sin cambiar el formato de los event de Nostr.

La alineación de la exportación cuadrada y su corrección posterior para clips más pequeños mantienen el texto y las pegatinas en su sitio entre clips de distintas resoluciones. La reproducción HLS de terceros evita un fallo de memoria dinámica en Android al volver atrás en los límites de cada bucle en lugar de precargar en el búfer listas de reproducción importadas repetidas; esos bucles pueden pausarse brevemente en cada reinicio. Una recarga de las preferencias de la cuenta mantiene los filtros vinculados a la cuenta en sus valores predeterminados al cambiar de cuenta y corrige parte de una aserción de depuración del inicio de sesión. Un problema independiente de actualización de las etiquetas de moderación sigue abierto, por lo que la PR no afirma que todos los errores de inicio de sesión estén corregidos.

Buzz amplía los controles de canales e identidad de su relay

Buzz es un espacio de trabajo basado en Nostr con su propio relay y sus propios clientes. Su implementación integrada de artefactos de canal asigna a cada registro editable un único canal y una cadena de revisiones; dos ediciones en conflicto no pueden convertirse ambas en la revisión principal. La denominación NIP-AR del proyecto se refiere a su propia propuesta e implementación, no a un estándar establecido de Nostr.

Para la entrada HTTP protegida, otro cambio integrado vincula una aserción de identidad federada con la misma clave acreditada mediante la autorización NIP-98. NIP-98 define events firmados de autenticación HTTP; la aserción NIP-FI de Buzz es una especificación del proyecto. También integró el cifrado HPKE para los sobres de copia de seguridad de claves secretas. Esa PR acredita trabajo de seguridad en el código fuente; la distribución a todos los clientes sigue sin verificarse.

Buzz desktop 0.5.26 incluye el trabajo de artefactos de canal, el cifrado HPKE nativo de las copias de seguridad de claves secretas y una consola de administración del relay para escritorio. Sus cambios compartidos corrigen las solicitudes de canales de proyectos no listados, sincronizan entre dispositivos las secciones de la barra lateral, la ordenación, las estrellas y los silenciamientos, limitan las lecturas de hilos largos y endurecen las aserciones de identidad de Blossom. Las notas de todo el repositorio enumeran por separado la vinculación de identidades del relay, la entrega de menciones del componente complementario, las URL de notificaciones push configurables, la eliminación administrativa atómica y los nombres contextuales en móviles. Una versión de escritorio acredita la distribución de los componentes de escritorio y compartidos; no demuestra que esos cambios para móviles se hayan distribuido en una compilación móvil.

La aplicación de NIP-FI en WebSocket de Buzz comprueba una aserción de identidad federada antes de aceptar tramas y después exige que su clave Nostr coincida con la clave autenticada mediante NIP-42, que acredita la identidad de un cliente ante un relay. Una sesión caduca cuando se alcanza el primero de estos límites: la caducidad del token, la antigüedad máxima de la aserción o la duración configurada de la conexión; tras caducar, no admite ningún efecto nuevo. Este modo NIP-FI específico del proyecto está desactivado por defecto. Las confirmaciones de audio y la configuración de suscripciones ya admitidas aún pueden quedar a la espera de una dependencia bloqueada, por lo que el cambio no establece un límite universal para el tiempo de desconexión.

La preparación de la eliminación por parte del propietario hace pasar las solicitudes certificadas por el operador por una aprobación automática vinculada al inventario antes de enviarlas al ejecutor de eliminación existente. Un cambio posterior del relay hace que los reintentos de una misma solicitud devuelvan su estado actual y reserva la cuota activa del propietario hasta que termine la eliminación; los marcadores de eliminación de hosts conservados permanentemente cuentan para un límite de 20 comunidades durante toda la vida útil. Estos son cambios administrativos en el código fuente, y el cambio posterior indica a los operadores que mantengan la eliminación desactivada hasta que su relay y su ejecutor de vaciado estén en funcionamiento. Por separado, una auditoría del catálogo de particiones detecta particiones que abarcan todos los casos y meses sin cobertura antes de crear nuevas particiones de events y del registro de entregas, haciendo visibles para los operadores la seguridad del servicio y la actualidad de la auditoría.

Buzz para móviles ahora distingue entre personas y agentes que comparten un nombre visible. Su resolutor de nombres de identidad distingue a los agentes por su propietario y añade un sufijo corto de la clave solo cuando es necesario; la integración en conversaciones utiliza esos nombres para autores, menciones y avisos de pertenencia. Listas, búsqueda y Pulse completan el mismo comportamiento fuera de una conversación. La distinción visible modifica la etiqueta local, mientras que una mención seleccionada conserva el nombre original de la identidad transmitido por el protocolo.

Conduit hace avanzar el proceso de compra tras la aceptación del relay

Conduit es un mercado de Nostr que envía mensajes privados de pedidos a los comerciantes. La publicación progresiva en relays distingue la primera confirmación positiva de un relay de la finalización de todos los intentos de publicación en relays, y un cambio posterior del proceso de compra guarda de forma persistente esa primera confirmación antes de continuar. La aceptación de un relay significa que el pedido firmado llegó a un relay; no demuestra que un comerciante lo haya leído o atendido.

Conduit también integró sesiones recuperables de firmantes remotos y negociación transaccional entre firmante y relay. NIP-46 permite que una aplicación solicite firmas con una clave custodiada por un firmante independiente; estos cambios conservan el espacio de trabajo de la cuenta del usuario mientras se repara su transporte y después verifican la cuenta exacta antes de reanudar la actividad. Las PR acreditan el comportamiento del código fuente, no una compilación distribuida del proceso de compra.

La integración de la búsqueda de productos ordenada por relevancia de Conduit envía una única consulta ordinaria de búsqueda de texto completo NIP-50 para productos de kind 30402 y conserva el orden de relevancia del relay durante las comprobaciones de firmas, la conciliación de revisiones y el filtrado local de elegibilidad. Las tarjetas pueden aparecer antes de que terminen las lecturas en segundo plano de productos exactos, mientras que las eliminaciones firmadas más recientes siguen siendo autoritativas. Actualizar y Reintentar se limitan a la búsqueda y a las lecturas de productos exactos, en lugar de iniciar un descubrimiento amplio del catálogo. Un límite de 100 resultados seguido de filtrado local puede dejar fuera coincidencias elegibles, por lo que una respuesta parcial vacía ofrece una vía de recuperación y no demuestra que no haya productos.

Elisym desarrolla un proceso de compra para el comercio en Nostr

Elisym está desarrollando un conjunto de herramientas de comercio que firma productos y transporta mensajes privados de pedidos y recibos a través de Nostr. Su paquete de comercio integrado define la verificación de ofertas y los events de pedidos envueltos mediante gift wrap; una interfaz de compra gestiona la revisión de ofertas, el pago con monedero y el estado de la entrega, mientras que un nodo de comerciante autoalojado empaqueta los componentes de la tienda. El proyecto califica el kind 30490 como provisional y describe un alcance mínimo para octubre. Estas integraciones en el código fuente acreditan una integración emergente; no se ha demostrado la existencia de un estándar aceptado de comercio en Nostr ni de un lanzamiento público completo.

Las herramientas de compra para agentes de Elisym añaden buy_product y get_order para sus productos anunciados en Nostr. La primera llamada devuelve una cotización sin realizar un pedido, y una segunda llamada acepta la cotización de un solo uso y las advertencias para el mismo agente y la misma red; el estado del pedido se conserva de forma duradera en el backend local de archivos del agente. La compatibilidad con el proceso de compra de Tempo añade una vía de pago con un monedero del navegador, con verificación del comerciante y entrega. Un hash de transacción enviado mantiene activo el intento hasta que se determina su resultado, evitando indicar un resultado de impago mientras una transacción difundida aún podría liquidarse.

Una corrección posterior del proceso de compra permite que el proceso de compra de productos firmados se inicialice cuando un monedero del navegador se anuncia de inmediato durante el descubrimiento. El cambio en el código fuente sitúa la declaración de la sesión antes de que pueda ejecutarse esa función de retorno; la integración por sí sola no verifica un despliegue alojado.

nostter mejora las comprobaciones de firmantes y la recuperación de events

nostter es un cliente social de Nostr. Su cambio integrado de comprobación de capacidades del firmante comprueba si hay un firmante utilizable antes de ofrecer las acciones de seguir y reaccionar. Los nuevos tags de fijación incluyen la clave del autor y una indicación de relay conocida, sin adivinar una, y la ordenación de la caché de events reemplazables sigue el criterio de marca de tiempo y desempate por ID de event de NIP-01. NIP-01 define las reglas fundamentales de los events de Nostr, incluida la forma en que los clientes eligen entre events reemplazables.

Pensieve prepara la conciliación aislada de archivos

Pensieve es una herramienta de archivo y recuperación de Nostr. Su entorno de ejecución aislado de negentropía integrado proporciona a la sincronización un proceso de trabajo con límites y un comportamiento de finalización duradero. La función requiere activación voluntaria y la PR indica explícitamente que no se activó ningún servicio ni configuración de producción; esto sienta las bases de una vía de recuperación más segura, no demuestra que haya un despliegue en funcionamiento.

ContextVM evita llamadas duplicadas entre relays

El SDK de TypeScript de ContextVM transporta solicitudes de herramientas y recursos como events de Nostr. Su corrección integrada de deduplicación de solicitudes entrantes reconoce una misma solicitud en texto plano por su ID de event incluso cuando varios relays o una reconexión la entregan de nuevo, igualando el comportamiento de la vía existente de mensajes envueltos. La PR informa de que, antes de la corrección, una herramienta no idempotente se ejecutaba tres veces para una sola llamada. Un cambio complementario de notificaciones de recursos envía actualizaciones solo a los clientes suscritos; las sesiones inicializadas sin una suscripción ya no las reciben.

Cyberspace revisa las reglas de objetos de DECK-0003

Cyberspace desarrolla el formato DECK-0003 para objetos estructurados de Nostr y bolsas de regiones cifradas, que Amethyst comenzó a implementar en el número de la semana pasada. Las nuevas reglas sobre partes y objetos ocultos y referencias de bolsas permiten que una bolsa haga referencia a un objeto publicado por separado en lugar de incorporar cada parte. Una corrección posterior indica que una referencia por ID de event no puede fijar de manera fiable una versión antigua de un event direccionable, porque un relay puede descartarla tras su sustitución. Los lectores deben usar la regla corregida de referencias por coordenadas; la redacción de la integración anterior ha quedado reemplazada.

Wisp corrige las respuestas a comentarios de Nostr

Wisp es un cliente de Nostr con funciones de enrutamiento a relays y de monedero. Tras el lanzamiento del soporte para comentarios NIP-22 de la semana pasada, una modificación posterior integrada hace que una respuesta a un comentario NIP-22 también sea un event de comentario, con las referencias correctas al padre y a la raíz; el flujo anterior siempre publicaba una nota ordinaria. NIP-22 permite adjuntar comentarios a muchos tipos de contenido de Nostr. La corrección se integró después del tag 1.2.5 de Wisp, cuyas notas solo incrementan la versión, por lo que se trata de un avance en el código fuente cuyo lanzamiento sigue sin verificarse.

Cordn envía las ubicaciones de los coordinadores a un segundo dispositivo

Cordn coordina la mensajería grupal cifrada a través de Nostr. Su cambio integrado en la especificación multidispositivo incluye las indicaciones de relay del coordinador de un grupo en el documento de grupo replicado. Un dispositivo recién inicializado puede entonces encontrar un coordinador que no esté en los relays predeterminados, en lugar de aparentar que se ha unido a un grupo cuyo historial y mensajes en directo no puede obtener. Se trata de trabajo en la documentación del protocolo posterior al lanzamiento de la cola sin conexión de Cordn de la semana pasada, no de una nueva versión del cliente.

Nostr Atlas abre un directorio de identidades verificables

Nostr Atlas es un nuevo directorio que presenta perfiles de Nostr junto con declaraciones de vinculación a cuentas externas. La publicación del sitio integrada separa el directorio de la demostración de componentes del proyecto, y el sitio responde públicamente. Una integración del flujo de declaración permite que el propietario de una cuenta de X publique una prueba firmada NIP-39 con un firmante de navegador, mientras que el enriquecimiento de perfiles lee los metadatos kind-0 de Nostr solo después de verificar la prueba. NIP-39 define el patrón de prueba para asociar una clave de Nostr con otra identidad en línea; una confirmación de un relay por sí sola no marca una declaración como verificada.

nostr-java añade herramientas de alojamiento multimedia y conserva las posiciones de los tags

nostr-java es una biblioteca Java y un conjunto de herramientas MCP para aplicaciones de Nostr. Sus herramientas Blossom integradas permiten a quien las invoca subir, buscar, enumerar y eliminar contenido multimedia direccionado por hash y gestionar la lista de servidores del usuario. Una corrección de publicación independiente mantiene en su lugar los valores vacíos de los tags: los tags de Nostr son posicionales, por lo que eliminar una indicación de relay vacía podría desplazar un marcador al campo equivocado y hacer que el event publicado difiera de la vista previa aprobada.

Zap Cooking cambia la forma de recuperar el historial de una cuenta

Zap Cooking es un cliente de Nostr para compartir recetas. Su trabajo integrado de recuperación Lazarus sustituye una copia de seguridad basada en events de datos específicos de aplicaciones de NIP-78 por un enfoque que examina las versiones de events reemplazables conservadas por los relays para detectar seguimientos, silenciamientos o perfiles sobrescritos. Lazarus sigue siendo un protocolo en borrador; la recuperación depende de relays que hayan conservado las versiones anteriores, y una PR integrada del cliente web no garantiza que se pueda recuperar cada event perdido.

El cliente también integró controles opcionales de prueba de trabajo NIP-13 para notas y respuestas y un modelo de archivos adjuntos que mantiene el orden del contenido multimedia y las descripciones de NIP-92 coherentes entre la vista previa y la publicación. NIP-13 permite que un remitente dedique cómputo local a un event antes de publicarlo; NIP-92 incluye metadatos multimedia como tags del event.

La corrección de solicitudes NIP-05 de Zap Cooking exige autorización NIP-98 sobre el cuerpo exacto de la solicitud y rechaza un firmante distinto de la clave pública que solicita el nombre. Anteriormente, ese endpoint público aceptaba solicitudes no autenticadas que podían sustituir el nombre de otro miembro. El nivel de membresía ahora procede del registro de membresía existente, y los usuarios de firmantes remotos reciben una petición de firma al solicitar un nombre. El flujo independiente de registro de confianza del lado del servidor permanece sin cambios.

Una reparación de la lista de silenciamientos impide que las acciones de silenciar perfiles sustituyan toda la lista kind 10000 únicamente por tags de claves públicas. El flujo anterior borraba las entradas de palabras, hashtags e hilos, además del contenido cifrado, y una de las interfaces podía volver a publicar públicamente claves de silenciamientos privados descifradas. El nuevo flujo lee la copia del relay, conserva los tags no relacionados y el texto cifrado, y se niega a publicar cuando esa lectura no está disponible. Eliminar un silenciamiento privado requiere descifrar y volver a cifrar mediante el firmante.

Opal lleva la firma remota a Omarchy

Opal es un firmante de Nostr de escritorio creado para el entorno Linux Omarchy. Su versión 0.3.3 del 28 de septiembre sucede a la primera serie pública con soporte de firma remota NIP-46, un almacén local de claves y una interfaz de permisos para las solicitudes de aplicaciones conectadas. NIP-46 mantiene la clave de la cuenta en el firmante mientras un cliente independiente le pide que apruebe operaciones. Esta es una versión temprana de un firmante específico de una plataforma, no una afirmación de compatibilidad más amplia con entornos de escritorio.

WatchTower abre un panel de control de relays NIP-86

WatchTower es un panel recién publicado para la administración de relays mediante NIP-86, el protocolo para solicitudes autenticadas de gestión de relays. Una instancia pública responde, lo que ofrece a los operadores un lugar donde examinar la interfaz. El repositorio se creó el 22 de septiembre; que el sitio sea accesible no demuestra que sus flujos de autorización hayan sido auditados de forma independiente ni que funcione con todas las implementaciones de relay.

Hubstr Blossom abre un servidor de origen personal para contenido multimedia

El servidor Hubstr Blossom, recién publicado, permite que un cliente de Nostr suba imágenes, vídeos y archivos a un endpoint Blossom autoalojado y luego incluya esas URL en events. Su README documenta el almacenamiento local por hash de contenido, un índice SQLite, la autorización firmada kind-24242 para cambios y una serie de operaciones Blossom para subir, replicar, enumerar y eliminar contenido. Las lecturas públicas permiten que otros clientes muestren el contenido multimedia publicado sin recibir permisos de subida.

Las opciones documentadas del servidor también extraen metadatos de archivos para events NIP-94, que describen contenido multimedia compartido. El servidor puede volver a codificar imágenes sin metadatos EXIF y, de forma predeterminada, protege las solicitudes de replicación frente a destinos de redes privadas. Se trata de una implementación recién publicada con instrucciones de despliegue, no de pruebas de un despliegue amplio en producción.

Hubstr Relay publicó su código fuente inicial el 24 de septiembre. Combina una caché personal de events en SQLite con un relay público: los lectores no autenticados ven los events públicos permitidos, mientras que los usuarios autenticados mediante NIP-42 pueden leer su caché. Los envoltorios de regalo NIP-17 siguen sin estar disponibles para los lectores invitados. Su actualización del 25 de septiembre corrige los registros devueltos por los métodos de listas de pubkey de NIP-86.

Meshstr experimenta con una malla de relays sin permisos

Meshstr es un diseño alfa para que los relays de Nostr negocien presupuestos entre pares e intercambien recibos de uso firmados. Su primera implementación incluye un puente de políticas de escritura para strfry, un relay de Nostr, añadido el 27 de septiembre, con una corrección del socket al día siguiente. El repositorio describe la negociación DIDComm y la reconciliación NIP-77, que permite a los pares comparar conjuntos de events sin intercambiar sus inventarios completos, junto con informes verificables de pares que superan los presupuestos acordados.

Esas reglas del proyecto son una propuesta, no un NIP adoptado ni una red pública de relays demostrada. El avance concreto de esta semana es el código publicado que conecta la política de escritura de un relay con la contabilidad propuesta para la malla.

Dossier muestra lo que puede revelar un historial público de Nostr

Dossier es una nueva herramienta de autoauditoría que se ejecuta en el navegador para examinar la huella de una persona en Nostr y Lightning, con una demo pública. Recopila enlaces visibles del perfil, rastros de zap, horarios de publicación, metadatos de antiguos mensajes directos cifrados con NIP-04 y metadatos de archivos multimedia, como los datos EXIF de las fotos; también puede mostrar dónde un relay sigue sirviendo un event que alguien intentó eliminar. La compatibilidad con firmantes NIP-07 permite que un usuario autorice acciones de limpieza sin pegar una clave privada en la página.

Los límites documentados del proyecto son importantes: un análisis solo ve los relays a los que accede, y una solicitud de eliminación no puede borrar las copias almacenadas en otros lugares. El repositorio apareció el 27 de septiembre y no tiene ninguna versión etiquetada; la demo y el código fuente acreditan una herramienta en fase inicial, no un inventario completo de la actividad pasada de una persona.

Marmot MDK amplía las encuestas, los emojis personalizados y los metadatos de cuenta

Marmot MDK proporciona el entorno de ejecución y los enlaces para mensajería cifrada de grupos de Nostr. Las incorporaciones posteriores al código fuente de MDK exponen selecciones de encuestas paginadas por votante utilizando las mismas reglas de respuesta efectiva que los recuentos agregados. Los componentes opcionales de grupo pertenecientes a la aplicación proporcionan a las aplicaciones anfitrionas ajustes controlados por administradores que persisten tras la retención de mensajes y llegan a los nuevos miembros en su Welcome. Los envíos con tags y las reacciones multimedia transportan metadatos de emojis personalizados a través del entorno de ejecución y los enlaces, conservan el material de descifrado de las imágenes de reacción adjuntas después de un cambio de época y rechazan los tags de adjuntos falsificados. Ese cambio amplía la estructura de solicitud de carga de C, por lo que los consumidores de C deben recompilar con el encabezado actualizado.

Una corrección de convergencia mantiene los mensajes pendientes cuando no se ha seleccionado ninguna rama canónica, en lugar de invalidarlos sin probar el estado activo. Una limpieza de rutas inalcanzables complementaria encauza los commits preparados sin resolver hacia el comportamiento de reintento que se mantiene. Las lecturas de archivos multimedia cifrados alinean el tiempo de espera de lectura HTTP con la gestión de inactividad del cuerpo reanudable, abordando las transferencias grandes bloqueadas sin afirmar que se haya superado la prueba de aceptación en dispositivo pendiente del APK entrante. Los marcadores de etapas de inicio muestran en qué paso de apertura de la cuenta se agotó el tiempo de espera, aportando evidencia de diagnóstico sin afirmar que se haya resuelto el bloqueo de inicio subyacente.

El conector del agente local también combina los metadatos de perfil existentes al publicar una actualización de kind 0, conservando los campos omitidos en la solicitud. Las actualizaciones de perfiles de grupo exponen los cambios en el nombre y la descripción de un grupo a través de la vía existente autorizada por el administrador actual. Su autenticación de socket sigue dando acceso a toda la API local; esta incorporación no añade concesiones de capacidades por identidad. Estos cambios del código fuente son posteriores a la versión etiquetada 0.11.0.

rust-nostr correlaciona las respuestas de recuento de los relays

rust-nostr, una biblioteca y un SDK de Rust para aplicaciones Nostr, incorporó respuestas COUNT correlacionadas y errores más claros para los procesos en espera. El SDK se suscribe antes de enviar COUNT y solo acepta la respuesta correspondiente, evitando que un receptor perdido o cerrado parezca un cero legítimo. También conserva los errores del receptor para las confirmaciones de publicación y la autenticación del relay, de modo que quienes realizan las llamadas puedan distinguir una confirmación ausente de un rechazo explícito. Las firmas de los métodos públicos no cambian.

ZapTracker añade métricas de la red Nostr y de citas

ZapTracker es un panel para creadores que muestra la interacción en Nostr y la actividad de la billetera. Una incorporación al panel de red sustituye las estadísticas de la red Lightning por datos de relays de Nostr en línea procedentes de nostr.watch e información de capacidades de documentos NIP-11. Un cambio en las métricas de citas cuenta los events de kind 1 que contienen tags q junto con los me gusta, las republicaciones, los marcadores y los zaps. Esto permite a los creadores ver las citas en las clasificaciones de contenido y los gráficos de interacción; la evidencia sigue siendo código fuente incorporado.

LaWallet NWC dirige las recargas de tarjetas a la billetera de la tarjeta

LaWallet NWC conecta billeteras Lightning con aplicaciones mediante Nostr Wallet Connect. Su incorporación de recargas de BoltCard anuncia un enlace de pago LUD-19 que crea una factura mediante el método NWC make_invoice de la billetera de la tarjeta. Las tarjetas bloqueadas, deshabilitadas o no vinculadas no anuncian un enlace de pago, y esta vía no redirige las recargas a la dirección Lightning independiente del propietario. Un cambio posterior expone el mismo enlace en el emulador y transmite en los envíos LNURL las notas del pagador aceptadas por el destinatario.

Un nuevo relay khatru expone controles de moderación para el propietario

nostr-relay-khatru publicó su código fuente inicial el 29 de septiembre como un relay general derivado de la implementación específica de HiveScope, ya descontinuada. La instancia pública sirve un documento NIP-11 que nombra este repositorio y anuncia autenticación, caducidad de events, events protegidos, recuento, reconciliación y administración del relay. Una implementación del 30 de septiembre añade controles de moderación a su panel de propietario. Los metadatos públicos verifican un endpoint desplegado, no la realización satisfactoria de pruebas de todos los métodos anunciados.

Un constructor local de redes de confianza registra a quién se deja de seguir

etemiz/wot publicó un rastreador de redes de confianza de Nostr el 30 de septiembre. Lee listas de seguimiento y listas de relays NIP-65, calcula la confianza a partir de raíces configurables y escribe puntuaciones en LMDB para políticas de relays, feeds y filtros de spam. La documentación del proyecto explica la contrapartida: las actualizaciones en tiempo real aumentan la confianza, mientras que los rastreos completos programados aplican las disminuciones y las acciones de dejar de seguir. Las puntuaciones dependen de las raíces elegidas. Se trata de código fuente recién publicado, sin una versión etiquetada ni afirmaciones de despliegue en producción.

Moyu presenta un cliente de espacio de trabajo basado en Marmot

Moyu ha publicado el código fuente de un cliente de chat para espacios de trabajo escrito en Rust y basado en Marmot, con interfaces de línea de comandos, terminal y escritorio. Sus cambios del 30 de septiembre utilizan los cambios de membresía registrados localmente para impedir que antiguas solicitudes de incorporación vuelvan a admitir a miembros eliminados, hacen que los códigos de invitación caduquen después de siete días y permiten a los administradores revocarlos. La salida del terminal filtra los caracteres de control y las anulaciones de dirección del texto proporcionados por otros miembros. Una bifurcación de MDK fijada a una revisión concreta dirige las transferencias de adjuntos de Blossom a través del proxy SOCKS5 configurado, y ese proxy realiza la resolución de nombres de host. Los cambios de 0.3.0 están en el código fuente público; todavía no hay ninguna etiqueta de versión ni entrada de lanzamiento públicas disponibles.

Trabajo en protocolos y especificaciones

NIP-39 amplía las pruebas de identidad a Bluesky y Discord

NIP-39 permite que una cuenta de Nostr enlace a una prueba de que controla una identidad en otra plataforma. Un cambio incorporado el 27 de septiembre proporciona una frase recomendada para las nuevas pruebas e indica a los verificadores que acepten pruebas antiguas que contengan el npub de la cuenta, incluso cuando su redacción sea diferente. También documenta las publicaciones de Bluesky y los mensajes de Discord como ubicaciones de prueba. Una declaración de identidad de Discord solo puede comprobarla alguien que pueda leer el servidor donde se publicó su mensaje.

NIP-86 añade la gestión de códigos de invitación para administradores de relays

Compass describió en la edición del 8 de julio la propuesta de invitaciones de NIP-86 cuando aún estaba abierta; ahora se ha incorporado. NIP-86 define una API estándar de gestión de relays, y NIP-43 define cómo los relays restringidos anuncian la membresía y procesan las solicitudes de admisión. La incorporación del 24 de septiembre añade listclaims, createclaim y deleteclaim para que un administrador pueda enumerar, emitir y revocar códigos de invitación aceptados por un relay. Eso proporciona a los operadores una vía de gestión de invitaciones que pueden otorgar un rol a un miembro después de que se incorpore; no exige que todos los relays admitan los métodos.

Una corrección a la cobertura de NIP-86 de la semana pasada: la especificación incorporada añadió unallowevent, unbanevent, listallowedevents y listdisallowedkinds. El artículo anterior enumeraba nombres de una descripción desactualizada de la propuesta. Los dos primeros métodos revierten una decisión de permitir o prohibir un event; los demás inspeccionan los events permitidos y los kinds no permitidos.

NIP-51 traslada los conjuntos de seguimiento favoritos a un kind de event sin usar

NIP-51 define listas públicas y privadas, incluida una lista de los conjuntos de seguimiento favoritos de un usuario. Compass describió la propuesta sobre la colisión de kind en la edición del 22 de julio; ahora se ha incorporado. La corrección del 27 de septiembre asigna a esa lista de favoritos el kind 10021 porque el número anterior ya estaba en uso. Sus tags a siguen apuntando a conjuntos de seguimiento de kind 30000. El cambio resuelve una colisión de números en la especificación; no crea una nueva forma de seguir a personas.

NIP-51 propone respuestas ocultas para cada hilo

Una propuesta abierta de NIP-51 permitiría al autor de un hilo publicar un conjunto público de respuestas ocultas que los clientes que colaboren mostrarían mediante un control de alternancia. Utiliza un event direccionable de kind-30027 por hilo, con el ID raíz como su tag d y tags e que identifican las respuestas; solo se aplica un conjunto firmado por el autor de la raíz. Incluir la raíz en la lista pide a los clientes que oculten las respuestas de otros autores y dejen de ofrecer un editor de respuestas, aunque las respuestas todavía pueden publicarse en relays. El formato por hilo limita las colisiones de edición a la misma conversación. El autor informa de una implementación en Nostrich, pero la inspección del código fuente público no permitió constatarla; la propuesta sigue sin incorporarse, y el formato de su conjunto continúa en discusión.

NIP-DB propone nombres de dominio verificados para servicios direccionados por clave

La propuesta abierta de NIP-DB, presentada el 28 de septiembre, describe events de Nostr que vinculan un dominio de Internet convencional con la clave que lo sirve a través de una red direccionada por clave como FIPS, una malla cifrada que direcciona los nodos mediante su clave pública de Nostr. El propietario de un dominio puede establecer el vínculo con un registro DNS TXT o una prueba DNSSEC incluida con la declaración; los clientes fijarían un resultado verificado para su uso posterior sin conexión. La propuesta prohíbe explícitamente la resolución mediante una declaración no verificada, ya que cualquiera puede declarar como propio el dominio de otra persona en un event de Nostr. fips-pub-domains es la implementación de referencia del autor, pero los números de kind de los events y parte de la redacción específica de la red superpuesta siguen bajo revisión. Las pruebas de extremo a extremo comunicadas constituyen evidencia aportada por el autor, no una afirmación de que la propuesta sea un NIP aceptado.

Un borrador de feeds privados explora grupos cifrados de destinatarios

Una nueva propuesta de envoltura para múltiples destinatarios, abierta el 29 de septiembre, esboza notas, respuestas y conexiones privadas cuyos destinatarios previstos pueden encontrar un event sin exponer sus claves públicas habituales en sus tags visibles. Propone tags de alias opacos por pares derivados de secretos compartidos y kinds de event provisionales, incluida una forma de envolver otro event de Nostr para cientos de lectores. Eso podría proporcionar a los pequeños feeds privados una vía de recuperación más directa que enviar un mensaje separado a cada miembro.

El autor de la propuesta la califica explícitamente como un trabajo en curso. El borrador no cuenta con una implementación demostrada ni con una revisión de seguridad, y sus asignaciones de kind y reglas de firma a nivel de bytes siguen abiertas.

Una propuesta de Blossom permite a otras personas anunciar copias de contenido multimedia

Una propuesta abierta de NIP describe una forma de que alguien que aloje una copia del blob de Blossom de otro autor anuncie esa copia a través de Nostr. Un cliente podría entonces buscar la copia si el servidor original pierde el blob. En la discusión también se ha planteado comprobar la lista actual de servidores BUD-03 de quien aloja la copia cuando una referencia de servidor anunciada haya quedado obsoleta. Se trata de una vía de descubrimiento propuesta, no de una garantía de que los clientes o los relays de archivo ya proporcionen almacenamiento alternativo.

Los informes de incidencias viales buscan un formato compartido en Nostr

La propuesta abierta Road Event Reports describe informes y confirmaciones de baches, cierres, cámaras y otras condiciones viales. Utiliza tags de ubicación y la marca de tiempo de caducidad de NIP-40, que indica a los relays cuándo dejar de servir un event, de modo que un informe no tenga que seguir vigente indefinidamente. El autor basó las revisiones en una muestra de events recuperados de relays públicos y en los clientes de Roadstr existentes para informar de condiciones viales, pero el borrador todavía deja abierta una cuestión sobre codificación compacta, y el número de NIP propuesto no se ha adoptado.

Marmot revisa la coordinación entre múltiples dispositivos

El rediseño de Marmot para múltiples dispositivos sustituye un borrador de External Commit no implementado por una explicación paso a paso no normativa para recibir comentarios tempranos. La nueva dirección explora cómo un dispositivo existente aprueba uno nuevo, lo incorpora a las conversaciones y posteriormente elimina dispositivos, mientras mantiene visibles las preguntas abiertas. Los ID reservados por el borrador eliminado quedan libres porque ninguna implementación los adoptó. El documento de ideas no asigna nuevos ID ni formatos de transmisión y no constituye una función implementada para múltiples dispositivos.

Seis años de septiembres de Nostr

El último número de septiembre es una oportunidad para seguir cómo Nostr pasó de los esbozos a un conjunto más amplio de herramientas interoperables. Un prototipo de 2021 para conectar pasajeros y conductores utilizaba events firmados para coordinar un servicio; cinco años después, la redacción sobre pruebas de identidad y las colisiones entre kinds de listas son el tipo de detalles que los responsables del mantenimiento están resolviendo. Entre tanto, los clientes aprendieron a presentar conversaciones, contenido multimedia y recuperación de formas que las personas corrientes pueden utilizar. Las fuentes fechadas que aparecen a continuación muestran etapas de esa evolución. No demuestran que todos los experimentos llegaran a lanzarse ni que cada diseño antiguo siga siendo recomendable.

Septiembre de 2021: primeros experimentos con formas útiles

Un commit de BUber del 4 de septiembre exploró un concepto para conectar pasajeros con taxis mediante events de Nostr. Mostró cómo una solicitud firmada y transportada por relays podía coordinar a las personas sin asignar todo el servicio a un único servidor. La fuente presenta un concepto y no demuestra que se lanzara un servicio de transporte.

Más tarde ese mismo mes, el código fuente de Loquaz del 23 de septiembre ofrecía un prototipo de chat de escritorio. Fue otro intento temprano de hacer que los mensajes de los relays se percibieran como una aplicación convencional. La fuente no demuestra que hubiera un cifrado de extremo a extremo terminado ni un servicio de mensajería en producción; el hilo conductor que perdura es la búsqueda de una interfaz de conversación utilizable sobre events sencillos. BUber probó la conexión entre pasajeros y conductores, y Loquaz probó el chat; ambos utilizaron events firmados antes de que se consolidaran los patrones comunes de los clientes. Esos ensayos plantearon dos problemas recurrentes para los clientes posteriores: coordinarse mediante relays y presentar los events como una conversación utilizable.

Septiembre de 2022: el chat y las acciones delegadas entran en las especificaciones

El cambio de NIP-28 del 10 de septiembre describía canales de chat públicos con mensajes y metadatos que los clientes podían interpretar conjuntamente. NIP-28 convirtió una sala compartida en un objeto explícito del protocolo y proporcionó a los clientes una convención común para los canales.

El 23 de septiembre, el texto de NIP-26 sobre firma delegada documentó una forma de que una clave autorizara a otra a firmar events limitados. Recogía una importante cuestión de diseño de 2022: cómo utilizar una identidad de Nostr sin entregar la clave principal a cada aplicación. NIP-26 figura ahora como no recomendado, por lo que esto es un registro de un experimento, no un consejo para nuevas integraciones. Su estado posterior muestra cómo ha evolucionado el modelo de firma: una especificación puede conservar un planteamiento útil de un problema incluso cuando se retira la respuesta propuesta.

Septiembre de 2023: los clientes maduran en torno al descubrimiento de relays y los metadatos

Damus es un cliente social de Nostr. Su registro de cambios del 21 de septiembre recogía trabajo en su base de datos local de Nostr, la búsqueda y la navegación por hashtags. Esos cambios facilitaron explorar y recuperar un feed social con mucha actividad en un teléfono; el registro de cambios fechado es evidencia de esa versión del cliente, no de todas las capacidades posteriores de Damus.

Los detalles del protocolo también evolucionaban. Un cambio del 26 de septiembre en NIP-24 aclaró los campos opcionales de metadatos de perfil, mientras que el cambio de NIP-65 del 29 de septiembre abordó la normalización y la deduplicación de los URI de los relays. NIP-65 indica a los clientes cómo publicar los relays que utilizan para leer y escribir; un tratamiento coherente de los URI ayuda a que esas listas apunten al mismo relay incluso cuando las cadenas difieren de formas inocuas. Esa pequeña convención orientó el diseño de los clientes hacia un descubrimiento fiable: encontrar los events de una persona depende de saber dónde se publican.

Septiembre de 2024: las publicaciones adquieren un contexto más rico

Las notas de la versión de Damus del 22 de septiembre describían compatibilidad con los pasajes destacados y los comentarios de NIP-84. NIP-84 ofrece a los lectores una forma de citar y comentar un pasaje de contenido extenso. El trabajo en el cliente muestra cómo una idea del protocolo se convirtió en algo que las personas podían utilizar mientras leían.

Mientras tanto, NIP-34 recibió un cambio del 20 de septiembre que refinaba los asuntos y las etiquetas de las incidencias para la colaboración con git a través de Nostr, y NIP-73 recibió un cambio ese mismo día que refinaba los identificadores de contenido externo. Son cambios separados de las especificaciones: uno ayuda a que las incidencias de un repositorio conserven su estructura, mientras que el otro permite que un event haga referencia a material externo a Nostr. Ambos amplían el significado que un cliente puede preservar cuando el contenido circula entre comunidades, repositorios y otros medios.

Septiembre de 2025: los controles de acceso y el contexto de los pagos se vuelven más precisos

Una revisión de NIP-42 del 6 de septiembre abordó la autenticación de múltiples usuarios en un relay. NIP-42 permite que un relay exija a un cliente demostrar qué clave de Nostr está realizando una solicitud; la actualización fue importante para los servicios que atienden a más de una cuenta autenticada a través de la misma conexión.

Una actualización de NIP-47 del 15 de septiembre añadió metadatos de pago opcionales a las solicitudes de Nostr Wallet Connect. NIP-47 permite que una aplicación solicite a una cartera realizar acciones a través de Nostr. Un mayor contexto puede hacer comprensible una interacción con una cartera, pero los metadatos pueden revelar datos del pagador, por lo que los clientes y las carteras siguen teniendo que tratarlos como información sensible. El cambio ilustra cómo el trabajo de interoperabilidad ya incluía lo que un destinatario puede averiguar, no solo si una solicitud puede entregarse.

Septiembre de 2026: los detalles de interoperabilidad se encuentran con la identidad pública

Este septiembre, un cambio integrado en NIP-51 cambió el kind de event de los conjuntos de cuentas seguidas para evitar una colisión. NIP-51 define listas que una persona puede mantener y compartir; los valores únicos de kind de event permiten a los clientes distinguir un tipo de lista de otro. Una edición anterior de Compass trató la propuesta, mientras que la integración de septiembre constituye el cambio de estado.

Un segundo cambio integrado en NIP-39 aclaró el texto de la prueba y añadió más formas de asociar una cuenta externa con una identidad de Nostr. NIP-39 trata sobre afirmaciones de identidad verificables, no sobre un registro central de identidades. En conjunto, ambas integraciones muestran que el trabajo actual en el protocolo se concentra en los pequeños detalles que determinan si los clientes independientes interpretan correctamente la misma identidad y los events de listas. También muestran un cambio de enfoque: de inventar nuevas categorías de event a reducir la ambigüedad en las existentes.

A lo largo de estos seis meses de septiembre, el patrón es una progresión desde demostrar que un event firmado puede describir una solicitud de aplicación hasta preguntarse cómo un cliente verifica una afirmación sobre una persona. Los antiguos prototipos importan porque ponen de manifiesto las preguntas que las especificaciones y los clientes posteriores tuvieron que responder: quién firma, dónde se encuentra un event, qué significa y cómo sabe alguien si puede confiar en él. Por eso también una corrección pequeña y precisa del protocolo puede importar tanto como una nueva interfaz.

Nostr Compass #40

Wed, 16 Sep 2026 00:00:00 +0000

Te damos de nuevo la bienvenida a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Marmot Protocol y MDK incorporan ventanas acotadas de conversaciones, correcciones de recuperación y bindings coordinados para SDK, Myco convierte su malla FIPS en un entorno de ejecución sin conexión para napplets y uso compartido de archivos, Dart NDK cambia el comportamiento de relay y caché, y Keycast reconstruye la firma remota en torno a solicitudes duraderas y recuperación. Los lanzamientos etiquetados incluyen Nail, Nostr Mail Client, Linky y Boris. El repositorio de NIPs fusionó un PR esta semana que aclara NIP-A3 (Destinos de pago), mientras que las propuestas sobre comandos con barra y señales periódicas de DVM siguen abiertas. Los análisis en profundidad abarcan NIP-23 (Contenido de formato largo) y NIP-92 (Metadatos de archivos multimedia adjuntos).

Historias destacadas

Marmot Protocol y MDK llegan a v0.10.0

MDK v0.10.0 de Marmot Protocol incorpora ventanas acotadas de listas de chats y conversaciones, resúmenes independientes de elementos que requieren atención en una cuenta, borradores protegidos frente a revisiones y el estado de las reacciones del espectador para aplicaciones que crean grupos cifrados basados en MLS sobre Nostr. También restaura el bloqueo de usuarios por cuenta y cuenta las invitaciones pendientes sin volver a contabilizarlas como mensajes no leídos.

La serie de lanzamientos v0.10.0 corrige la recuperación cuando se elimina y se vuelve a añadir un dispositivo, cuando el tráfico llega antes que su Welcome y cuando se interrumpe la reproducción de peel. Reduce la sincronización de relay y la rotación de suscripciones, pone en cola las operaciones multimedia mientras las ranuras de transferencia están ocupadas y fija las cargas de auditoría forense a destinos validados en cada intento.

El mismo commit del código fuente de MDK distribuye artefactos de Rust, C, Swift, Kotlin, línea de comandos y agentes como una única cohorte de compatibilidad. Las bases de datos de cuentas avanzan mediante las migraciones 70–75, por lo que las aplicaciones deben actualizar conjuntamente el código fuente generado y las bibliotecas nativas, conservar completos los paquetes de frameworks de Apple, hacer una copia de seguridad antes de la migración y evitar volver a una versión anterior de una base de datos ya migrada.

Myco 0.7.0 ejecuta napplets y comparte archivos mediante una malla FIPS con múltiples rutas

Myco v0.7.0 convierte la aplicación de malla para Android en un anfitrión de napplets, programas Nostr de un solo archivo descritos por la propuesta abierta NIP-5D. Cada napplet se ejecuta en un entorno aislado sin acceso directo a la red ni al almacenamiento y solicita capacidades de identidad, relay, outbox, malla, imágenes o archivos por medio de Myco. La hoja de instalación muestra esos permisos antes de su aprobación, los usuarios pueden cambiarlos más adelante y las actualizaciones que solicitan un acceso más amplio vuelven a la pantalla de permisos.

Myco v0.7.0 también envía archivos arbitrarios a teléfonos emparejados mediante la hoja de uso compartido del sistema o un contacto de Circle. El teléfono receptor aprueba la transferencia antes de que Myco la escriba en Downloads/Myco, y la carga útil se cifra con la clave de ese teléfono. El descubrimiento en la red local usa UDP cuando ambos teléfonos comparten Wi-Fi y conserva Bluetooth para rutas sin conexión; los reintentos cubren la pérdida de mensajes de control, mientras que un temporizador de silencio limita las transferencias grandes que se estancan.

Myco ahora mantiene enlaces FIPS simultáneos con un mismo par, sondea rutas en espera y desplaza el tráfico cuando se degrada el enlace activo de Bluetooth, Wi-Fi Aware o la red local. El trabajo se basa en la rama experimental de múltiples rutas de FIPS. La versión 0.7.0 conserva la compatibilidad de protocolo con 0.6.1 para el intercambio, la mensajería y el emparejamiento existentes de la aplicación, pero los enlaces de múltiples rutas solo se establecen entre dos teléfonos actualizados. El relay integrado también pasa a LMDB y migra los almacenes de event anteriores durante el primer inicio.

Dart NDK cambia el comportamiento de relay, caché y cuentas

Dart NDK v0.10.0-dev.3 es una versión de desarrollo de la biblioteca cliente de Dart, con cambios incompatibles en la gestión de relay, el almacenamiento en caché, la autenticación y los flujos de cuentas. Quienes mantienen clientes deben prever trabajo de migración tanto en el código como en el comportamiento, especialmente cuando una aplicación presupone que los events almacenados en caché, los events ocultos o las actualizaciones de cuentas siguen la semántica de la línea de versiones anterior.

La serie de desarrollo v0.10.0 también mejora el rendimiento de la caché y del verificador de Rust, y cambia el comportamiento de los metadatos, las coordenadas de eliminación, la visibilidad de events, la autenticación del firmante y los pagos NWC. La verificación compactada de events en Rust reduce la sobrecarga de verificación, mientras que el nuevo comportamiento de caché loadHiddenEvents es explícitamente incompatible.

Como se trata de v0.10.0-dev.3, y no de una versión estable v0.10.0, los equipos de aplicaciones deben fijar las versiones y probar las migraciones de manera deliberada. La reconexión de relay, la hidratación de la caché, la autenticación del firmante, la gestión de carteras y el orden de los flujos de cuentas son las rutas más importantes que deben probarse antes de migrar clientes de producción.

Keycast publica el candidato a lanzamiento de su firmante reconstruido

Keycast v2.0.0-rc.1 es el primer lanzamiento numerado del firmante remoto NIP-46 reconstruido y autoalojado. El candidato a lanzamiento incorpora compatibilidad multiplexada con NIP-46, enrutamiento de relay compartido y por clave, gestión duradera de solicitudes, almacenamiento cifrado de claves, invitaciones, sesiones y espacios de trabajo para equipos.

La política de firma y la recuperación reciben la misma atención en v2.0.0-rc.1. Los operadores pueden configurar políticas de firma, revisar el historial de auditoría, crear copias de seguridad cifradas, recuperar implementaciones y rotar la clave raíz. El proyecto también documenta una procedencia de lanzamientos coordinada y verificada entre sus componentes de API, firmante y web.

El lanzamiento sigue siendo un candidato a lanzamiento, por lo que los operadores no deben deducir la compatibilidad definitiva ni la preparación para producción únicamente a partir del número de versión. Antes de sustituir un servicio de firma existente, las pruebas deben abarcar la recuperación de solicitudes interrumpidas, los fallos de enrutamiento de relay, la aplicación de políticas, la restauración de copias de seguridad y la rotación de claves.

Lanzamientos etiquetados

Nail 0.2.0 restaura las suscripciones de Nostr a correo electrónico

Nail v0.2.0, un servicio que entrega mensajes de Nostr mediante flujos de trabajo de correo electrónico, incorpora suscripciones gift-wrap con autorreparación. El cambio busca restaurar la entrega de Nostr a correo electrónico después de fallos de suscripción, en lugar de dejar el puente detenido sin aviso.

Nostr Mail Client 0.15.0 amplía el control de cuentas y relay

Nostr Mail Client v0.15.0 incorpora el cambio de cuenta con un toque, notificaciones por cuenta, push web y la recuperación de una lista de relay ausente desde un relay, una dirección Nostr o un nprofile. También vuelve a publicar perfiles y listas de relay en relays de indexación, se reconecta cuando regresa el acceso a la red y distingue una interrupción del dispositivo de relays de correo inaccesibles. Estos cambios refuerzan la recuperación de cuentas y la entrega en clientes de escritorio, web y Android.

Linky 26.9.17 mantiene las semillas de recuperación fuera de su servidor

Linky v26.9.17, una aplicación de contactos, mensajería privada de Nostr y pagos Lightning/Cashu, corrige una ruta que enviaba semillas de recuperación al servidor de Linky cuando los usuarios las guardaban mediante un gestor de contraseñas. El lanzamiento también refuerza la gestión de URLs de archivos de pago y desactiva las copias de seguridad de aplicaciones de Android, lo que reduce los lugares por los que el material de recuperación de la cartera y la identidad puede salir del dispositivo.

Calendar by Form* 2.4.0 incorpora invitaciones de Mailstr para invitados

Calendar by Form* v2.4.0, un cliente de calendario de Nostr, incorpora invitaciones de Mailstr para invitados y correcciones del calendario móvil. La ruta de invitación permite que los organizadores incluyan participantes mediante coordinación orientada al correo sin requerir una cuenta de calendario existente.

Hessible 0.1.2 acelera la sincronización cifrada de contactos y fotos

Hessible 0.1.2, una aplicación de contactos para Android centrada en la privacidad que almacena datos de contacto cifrados en relays de Nostr, reduce la sobrecarga de sincronización y replica fotos de contactos cifradas entre servidores Blossom. El lanzamiento también reduce el tamaño del paquete de la aplicación, mientras que sus propias recomendaciones siguen advirtiendo a los usuarios que hagan copias de seguridad de las claves y tengan en cuenta que la retención varía según el relay.

Boris 0.12.5 limita la extracción y refuerza la lectura sin conexión

Boris v0.12.5, un cliente de listas de lectura creado en torno a los marcadores de Nostr, sucede a v0.12.4 con extracción acotada de contenido, almacenamiento en caché sin conexión, cambios en las consultas a relay, gestión de HTML no seguro y una corrección para el texto casi invisible con el tema Paper White. Estos cambios afectan tanto a la seguridad del contenido como a la fiabilidad de la lectura de material guardado sin una ruta de red activa.

Amethyst 1.15.2 perfecciona el contenido multimedia y las respuestas con ámbito de raíz

Amethyst v1.15.2, un cliente Nostr para Android, cierra una secuencia de tres lanzamientos con correcciones de contenido multimedia, una gestión más clara de los permisos de Health Connect, almacenamiento en caché de nombres de fuentes y filtros de interacción específicos para respuestas con ámbito de raíz de NIP-22. El lanzamiento también incluye actualizaciones de traducciones y metadatos del paquete.

LibreNostr 0.5.17 enruta los feeds mediante los relays de escritura de los autores

LibreNostr 0.5.17, un cliente para Android centrado en relay, ahora dirige las consultas de feeds a los relays de escritura NIP-65 de los autores seguidos y aplaza las consultas de recuentos de interacciones hasta que las notas aparecen en pantalla. El trabajo anterior de la misma secuencia de lanzamientos limita las consultas simultáneas a relay y cierra cada suscripción de relay en cuanto ese relay responde, lo que reduce el rechazo involuntario de solicitudes durante las actualizaciones.

Voca 1.2.0 mejora la cancelación y recuperación de voz

Voca 1.2.0, un lector de texto a voz para Android orientado al uso sin conexión que puede obtener y verificar contenido de Nostr, incorpora comportamientos diferenciados de cancelación y renderizado, además de recuperación para motores de voz lentos o poco fiables, tras el lanzamiento 1.0 tratado en la edición #38. También incorpora diagnósticos opcionales enviados con una clave Nostr nueva y de un solo uso mediante un mensaje privado NIP-17; los informes grandes se cifran localmente antes de cargarse.

Postr 1.1.1 incorpora dictado y recuperación de publicaciones

Postr 1.1.1, un editor específico de kind 1 para Android, incorpora dictado y gestión de menciones consciente de la posición del cursor tras el lanzamiento tratado en la edición #37. El lanzamiento 1.1.0 anterior también mejora la recuperación de publicaciones al volver a intentar el mismo event firmado después de resultados ambiguos, lo que evita que la recuperación cree una nota duplicada.

earthly 0.1.10 repara la sanitización y la creación de mapas

earthly v0.1.10, un editor colaborativo de mapas en Nostr, cambia sustancialmente la creación de mapas e historias y corrige una vulnerabilidad crítica del sanitizador de atribuciones de MapLibre mediante una actualización de MapLibre GL JS. El lanzamiento también mejora los mensajes de compatibilidad con WebGL 2, los controles móviles, la edición de geometría, la selección y los controles de presentación de mapas.

Routstrd 0.4.10 refuerza el enrutamiento de solicitudes de Nostr

Routstrd v0.4.10 sustituye una lista obsoleta de proveedores almacenada por la lista devuelta por el descubrimiento activo. El lanzamiento v0.4.9 anterior incorporó controles manuales y programados de actualización del cliente, npubs con nombre en la CLI y reinicios controlados del daemon que esperan a que terminen las solicitudes activas. En conjunto, los lanzamientos hacen más explícitos la selección de proveedores y el comportamiento de actualización para los operadores del servicio enrutado mediante Nostr.

Whistle 1.9.1 instrumenta la recuperación en segundo plano

Whistle 1.9.1, una aplicación cifrada para compartir la ubicación en grupo creada sobre Nostr, MLS y Marmot Protocol, incorpora instrumentación del ciclo de vida del dispositivo para la recuperación en segundo plano de iOS. La versión 1.9.0 también introduce pausas de uso compartido por grupo y diagnósticos del último event por grupo, lo que facilita distinguir un grupo estancado de una conexión saludable en toda la aplicación.

Amber 6.6.4 corrige una fuga de Tor y fallos de recuperación del firmante

Amber v6.6.4, un firmante de events de Nostr para Android, culmina una secuencia de tres lanzamientos con la corrección de una fuga de Tor y soluciones relacionadas con los relays del firmante y la recuperación. Los usuarios de firmantes y los desarrolladores de aplicaciones deben prestar especial atención a las suposiciones sobre las rutas de red y al comportamiento de los reintentos, ya que, de lo contrario, los fallos del firmante pueden parecer fallos de publicación del cliente.

nostr-wot-extension 0.7.0 cifra los datos de caché de la cartera

nostr-wot-extension v0.7.0, una extensión del navegador que gestiona identidades de Nostr, firma events e inicia pagos Lightning, cifra los datos de caché de la cartera y los pagos, y refuerza el aislamiento de la bóveda y las cuentas. También aborda el comportamiento de NWC y la cartera, la compatibilidad de pagos, las aprobaciones de solicitudes, la gestión de cuentas, la importación de copias de seguridad, la gestión de relay, la accesibilidad y el descifrado local de events.

Lightning.Pub 0.0.41 mejora la recuperación de publicaciones

Lightning.Pub v0.0.41 añade a los fallos de publicación de Nostr detalles sobre la URL del relay, los tiempos, el estado del socket y DNS. También vuelve a intentar las llamadas de inicio del proveedor de liquidez, elimina callbacks abandonados y retiene el enrutamiento de facturas hasta que una respuesta de saldo satisfactoria demuestre que el proveedor está listo. Los operadores ahora obtienen una distinción más clara entre los fallos de conectividad de relay y los fallos de preparación del backend.

Gittr 1.0.0 impulsa la colaboración NIP-34

Gittr v1.0.0, un cliente para la colaboración con Git basada en Nostr, mejora la gestión de fuentes de clonación NIP-34, el estado de incidencias y debates, la usabilidad móvil y la interoperabilidad. El tag v1.0.0 sucede a v0.3.0 y v0.3.1 de principios de esta semana, lo que proporciona a los integradores un marcador de versión estable para la secuencia de lanzamientos.

GitWorkshop 4.1.0 permite recuperar borradores NIP-34

GitWorkshop 4.1.0, un cliente nativo de Nostr para incidencias NIP-34, pull requests, revisión de código y exploración de repositorios, incorpora borradores locales por cuenta que sobreviven a las actualizaciones y reinicios del navegador. También incorpora recuperación acotada y controles explícitos de reintento para lecturas de Git, descubrimiento de relay, estado del repositorio, historial de pull requests, cargas y metadatos de lanzamientos, mientras mantiene manuales los reintentos de firma y pago.

ngit-ci 0.1.1 publica coordinación de CI firmada

ngit-ci 0.1.1, un coordinador autoalojado para el protocolo de CI de Nostr propuesto en NIP-C1, es su primer lanzamiento publicado mediante Nostr. Abarca la coordinación firmada de flujos de trabajo, la ejecución en contenedores o microVM, registros y artefactos, secretos cifrados de repositorios, autorización de mantenedores mediante NIP-34 y publicación firmada de los resultados de compilación.

pakstr 0.21.1 impulsa el empaquetado de aplicaciones Nostr

pakstr v0.21.1 continúa una secuencia de cinco lanzamientos para el empaquetado de aplicaciones Nostr y el comportamiento del contenedor de aplicaciones. Las referencias de NostrAppShell apuntan a esta misma serie de lanzamientos de pakstr, por lo que el paquete y el alias describen un único cambio distribuido.

@elisym/cli 0.30.0 coordina paquetes de agentes y delegación

@elisym/cli 0.30.0 concluye un lanzamiento coordinado de CLI, SDK y MCP para la delegación de agentes orientados a Nostr. Los trabajos delegados ahora esperan a completarse en lugar de suspenderse durante un intervalo fijo, y la aplicación evita pagar la misma capacidad de delegación una vez por trabajo. Los equipos que utilicen más de un paquete deben mantener CLI 0.30.0, SDK 0.36.0 y MCP 0.26.0 en la línea de lanzamientos correspondiente.

Hashtree 0.2.150 impulsa la sincronización de árboles de hashes

Hashtree v0.2.150 cierra una secuencia de seis lanzamientos con bloqueo seguro para Android en el grafo social integrado. Los lanzamientos anteriores de la secuencia mantienen abiertas brevemente las suscripciones de Nostr después de un EOSE vacío para que puedan llegar raíces firmadas con retraso, seleccionan la raíz válida más reciente para el autor y el árbol exactos, y recuperan las rutas FIPS conservadas después de interrupciones de tránsito. El resultado es un descubrimiento y una sincronización más predecibles de raíces mutables entre relays, clientes integrados y rutas de red intermitentes.

nostr-relay 0.0.266 mejora el funcionamiento con bases de datos compartidas

nostr-relay v0.0.266, un relay de Nostr creado sobre el framework relayer, mejora el comportamiento de las bases de datos compartidas y Redis a lo largo de seis lanzamientos. Este trabajo es especialmente relevante para los operadores que ejecutan más de un proceso de relay sobre una infraestructura común de persistencia o notificaciones.

fips-tcp 0.2.2 implementa FIPS sobre TCP

fips-tcp v0.2.2 repara segmentos ausentes tras agotarse el tiempo de espera de un vuelo a medida que avanzan las confirmaciones. Las escrituras pequeñas perdidas durante una interrupción de tránsito se recuperan juntas en lugar de esperar un tiempo de espera creciente para cada segmento, mientras que las implementaciones de Rust y TypeScript conservan bytes de protocolo idénticos, límites de reintentos, comprobaciones de la ventana de recepción, reinicio de secuencias y muestreo de RTT.

En desarrollo

Biblioteca de marketplace Nenya

Nenya es una nueva biblioteca para un marketplace Nostr sin custodia, centrado en medios digitales por encargo con liquidación en Bitcoin. El repositorio está en fase de prelanzamiento, por lo que sus interfaces de events y liquidación aún pueden cambiar.

Los desarrolladores de clientes importan la biblioteca Nenya en aplicaciones Nostr para ofrecer listados y transacciones compatibles. El trabajo de integración debería comenzar por sus límites de events y liquidación, porque todavía no existe una implementación independiente ni un contrato de versión estable.

Puente de CI entre GitHub y Nostr

gh-ngit-ci-bridge es un puente en fase temprana que observa los commits de GitHub asociados con identidades configuradas y los convierte en pruebas de compilación de Nostr firmadas para flujos de trabajo NIP-34. El repositorio está en fase de prelanzamiento y su contrato de integración aún puede cambiar.

El repositorio gh-ngit-ci-bridge conecta la actividad convencional de GitHub con la coordinación de CI nativa de Nostr sin cambiar el flujo de trabajo original de la forja. Su cuestión de implementación más relevante es la procedencia: los consumidores necesitan distinguir la acción de GitHub observada, la identidad del puente y la prueba de Nostr firmada resultante.

noscall cifra los archivos adjuntos de voz

El commit de archivos adjuntos de voz cifrados de noscall añade una función concreta de privacidad para la comunicación por voz. El cambio verificado en el código fuente admite archivos adjuntos de voz cifrados, lo que reduce la necesidad de exponer los medios grabados como texto sin cifrar al adjuntarlos a una llamada o un flujo de mensajería.

relayer restablece la distribución de notificaciones entre procesos

La solicitud de incorporación #167 de relayer ha incorporado una corrección del sistema de notificaciones para implementaciones en las que varios procesos de relay comparten una base de datos. El parche restablece la distribución en directo entre esos procesos y resuelve el caso en el que un event se guardaba correctamente, pero los clientes conectados a otro proceso no recibían la notificación en directo correspondiente.

Junto con el trabajo de base de datos compartida de nostr-relay v0.0.266, la corrección de relayer ofrece a los operadores con varios procesos un objetivo de prueba claro: publicar a través de un proceso, suscribirse mediante otro y confirmar tanto la persistencia como la entrega inmediata. Una escritura correcta en la base de datos, por sí sola, no demuestra que los suscriptores en directo hayan recibido el event.

Proyectos nuevos

Trackstr organiza medios mediante event kinds específicos

Trackstr es una base de datos multimedia de Nostr, de código abierto y aún sin publicar, para descubrir y seguir películas, música, televisión y otros medios. Su diseño actual utiliza event kinds del 35400 al 35402, lo que proporciona un esquema y una superficie de implementación revisables. Los kinds siguen estando definidos por el proyecto y pueden cambiar antes de una versión.

Trabajo sobre protocolos y especificaciones

NIP-A3 aclara la ambigüedad de los tipos de pago

NIP-A3 (Objetivos de pago) estandariza objetivos de pago tipados en tags ["payto", "<type>", "<address>"] de events kind 10133. La aclaración sobre los tipos de pago ya incorporada añade bitcoincash y tron a la lista documentada de tipos y aclara la representación: los clientes utilizan un esquema URI específico del tipo cuando existe; de lo contrario, recurren a payto://<type>/<address>.

NIP-CD propone comandos de barra direccionables

La propuesta de comandos de barra de NIP-CD, aún abierta, define events direccionables kind 31992 cuyos tags command, title, description, arg, de ámbito y de exclusión anuncian comandos ejecutables. Las invocaciones comienzan en el primer byte del contenido de texto sin cifrar de un event, pueden dirigirse a un ejecutor mediante npub y, deliberadamente, no requieren compatibilidad especial del cliente. El borrador también define tipos de argumentos posicionales y filtros de ámbito por event kind, relay, autor o tag; nada de esto forma parte todavía del comportamiento incorporado del protocolo.

NIP-90 propone events de latido de DVM con caducidad

NIP-90 (Data Vending Machines) define solicitudes de trabajo, resultados y comentarios para servicios que realizan tareas a través de Nostr. Una propuesta de latidos de DVM, aún abierta, añade events opcionales kind 11998 que deberían incluir un tag expiration para que los clientes puedan distinguir una máquina activa de un anuncio NIP-89 obsoleto. El latido queda fuera del intervalo de job kinds de NIP-90, permite a los relays descartar latidos caducados o reemplazados y no altera los flujos de DVM existentes cuando un servicio no lo emite.

NIP-73 propone filtros de medios para pódcast

NIP-73 (Identificadores de contenido externo) estandariza tags i para identificadores externos y tags k para sus categorías. El borrador abierto de la propuesta de medios para pódcast añade tags de categoría opcionales podcast:medium:music y podcast:medium:podcast para que los clientes puedan filtrar notas según el medio declarado en un feed RSS de pódcast. La ausencia de una categoría sigue implicando un feed de pódcast, aunque los clientes deberían consultar la fuente RSS cuando necesiten confirmar su medio.

NIP-F5 propone un transporte FIPS con permisos para aplicaciones web

La propuesta de transporte para navegadores de NIP-F5, aún abierta, define una API opcional window.fipsTransport mediante la cual una aplicación web de Nostr puede solicitar acceso HTTP o WebSocket aprobado por el usuario a un relay con dirección FIPS, un servidor Blossom, un servicio Git u otro endpoint privado. El anfitrión vincula cada permiso al origen web solicitante y al destino, a la vez que mantiene el transporte separado de la firma de Nostr, la identidad y la autorización del servicio. La propuesta también exige consentimiento explícito y permisos acotados, pero sus formatos de dirección y su contrato para navegadores siguen siendo provisionales.

Marmot aclara el descubrimiento de relays para KeyPackage

Marmot transporta el estado de grupos MLS mediante events de Nostr. La aclaración sobre el descubrimiento de relays para KeyPackage, aún abierta, documenta la secuencia actual: publicar metadatos de relay kind 10002, obtener el KeyPackage kind 30443 del destinatario desde destinos con capacidad de escritura o sin marcar y, después, usar kind 10050 por separado para encontrar la bandeja de entrada Welcome del destinatario. También establece que las entradas NIP-65 de solo lectura no son destinos de KeyPackage y que la lista kind 10051, ya eliminada, ha dejado de ser un paso del descubrimiento. La solicitud de incorporación es una guía de migración en revisión, no un nuevo formato de transmisión ni un requisito incorporado.

Marmot propone denuncias grupales cifradas y moderación compartida

La especificación de moderación de Marmot, aún abierta, propone events internos sin firmar transportados mediante el sistema de transporte grupal cifrado que ya existe en el protocolo. Kind 1984 serviría para denunciar una revisión concreta de un mensaje, kind 1985 permitiría a los administradores desestimar denuncias referenciadas sin eliminar el contenido y kind 4891 permitiría a un administrador autenticado eliminar un mensaje y sus revisiones. La propuesta también define reglas de deduplicación, visibilidad compartida de las revisiones, ordenación, retención y autoridad, mientras mantiene la eliminación por parte del autor en kind 5 y deja las interfaces de la aplicación anfitriona fuera del contrato de transmisión.

NWC añade búsqueda de pagos y registros BOLT12

Nostr Wallet Connect permite a las aplicaciones controlar una wallet mediante solicitudes y respuestas cifradas a través de Nostr. Su trabajo de búsqueda de pagos, tratado anteriormente como una propuesta abierta, ya se ha incorporado al repositorio. La especificación de lookup_payment y BOLT12 ya incorporada define la búsqueda de pagos por ID de transacción, invoice, hash de pago o selectores específicos del tipo de pago, y añade registros y estados de pago BOLT12 opcionales y provisionales. Los desarrolladores de wallets y clientes disponen ahora de definiciones provisionales incorporadas para el flujo de búsqueda y sus registros BOLT12.

NWC añade conexiones iniciadas por el cliente

El flujo de conexión iniciado por el cliente, ya incorporado, permite que un cliente genere el secreto de conexión, dirija al usuario por un proceso de confirmación HTTP o autorización de Nostr, negocie permisos obligatorios y opcionales, y reciba los detalles de conexión aprobados. El cambio proporciona a los clientes y wallets NWC una definición provisional alojada en el repositorio para crear una conexión desde el lado del cliente.

Análisis en profundidad de NIP: NIP-23 y NIP-92

NIP-23: Contenido extenso

NIP-23 (Contenido extenso) estandariza el contenido extenso en Nostr mediante events direccionables kind 30023, según lo definido en la especificación canónica. Los editores obtienen una identidad de artículo editable, mientras que kind 1 sigue siendo el formato para notas breves.

Según el formato NIP-23, un artículo se direcciona mediante la tupla formada por el pubkey de su autor, kind 30023 y el tag d. El cuerpo en Markdown reside en content; los tags opcionales title, summary, image, published_at y t describen la presentación y la fecha de publicación original. Una edición vuelve a publicar la misma dirección con un created_at más reciente, por lo que los clientes deben unificar las versiones duplicadas cuando un relay no implementa correctamente el reemplazo direccionable.

La especificación de contenido extenso deja la política de almacenamiento y presentación fuera del formato firmado. Prohíbe el HTML incrustado en el Markdown de nueva creación, utiliza valores naddr de NIP-19 y tags a para enlaces estables, y canaliza las respuestas mediante comentarios NIP-22. El formato preliminar obsoleto kind 30024 se ha trasladado a los events privados de NIP-37, lo que deja kind 30023 para los artículos publicados.

La especificación es canónica desde el commit 7c444e3. Para los desarrolladores, la principal consecuencia es que la publicación, el reemplazo, la indexación y la representación deberían seguir el modelo de events direccionables asociado con kind 30023, aunque los clientes todavía deben gestionar discrepancias entre relays, copias obsoletas y descubrimiento incompleto.

Las pruebas actuales de implementación incluyen Habla, YakiHonne y Amethyst. El event firmado kind 30023 que aparece a continuación se recuperó de wss://nos.lol y wss://relay.primal.net. Su tag d proporciona el identificador estable del artículo, mientras que su cuerpo en Markdown permanece dentro del event firmado; dos lecturas posteriores desde relays no demuestran una retención universal ni compatibilidad entre clientes.

{"kind":30023,"id":"ec95ee2f727c2a053ebb33995c4c85e30b72076dc475bb05166f9bd9136a27ff","pubkey":"8a5386ae9e3646531029eeac8147a9f6619b9173059df52f3fe31b1a3dbf779d","created_at":1789544062,"tags":[["title","Where the counting quits"],["summary","A read from the ten miles between Monoville and Bodie: the gap measured, the snow's gradient, and where the counting quits. For Divy, who asked."],["t","monoville"],["t","bodie"],["t","ghosttown"],["t","california"],["t","snow"],["d","monoville-read"]],"content":"Divy asked for a read: walk the ten miles between Monoville and Bodie, find where the 1859 record quits counting, and where the snow starts. This is that read. Maps, elevation, archives, the gaps said out loud. I never pretend I stood where I didn't.\n\nThe record, first, because it's thin.\n\nNovember 1859. W. S. Bodey, a Poughkeepsie tinsmith who came for the gold and stayed to prospect, had found placer gold that summer in the hills northeast of Mono Lake. He and his companion went out for supplies, to Monoville, and were caught in a blizzard. When Bodey couldn't go further, the companion went on. Bodey froze. His body was found the next spring.\n\nThe tellings can't agree on the small things. His first name: William, Waterman, or Wakeman, depending. The companion: a partner named E. S. Taylor in one account, \"a companion\" in another. And no account gives the spot. No creek, no ridge, no milepost. The record counts the gap, then stops.\n\nThe gap, measured: 8.8 miles straight between the coordinates, as you had it. By road, 13.7 on your measure; the driving route I could model ran 16.6, because the road doesn't cross this country, it goes around it. Between the two names: ground.\n\nAnd the ground doesn't sag between the towns. It climbs.\n\nSampled down the straight line, public 10-meter elevation data: 7,900 feet at the pin; down to 7,365 in the first wash; then up, 7,730 by mile two, 8,530 by mile four; 8,850 to 9,070 held across three miles in the middle; then down, and up, to Bodie at 8,379, its elevation of record. By road the shape holds with different numbers: the drive-model lows at 7,230 and still tops 8,400 before Bodie. Whichever line the supply run took, the middle is the high ground.\n\nSo the counting doesn't quit at a milepost. It quits on the crest. Mid-way there is a stretch where you are not between two names anymore, you are just on high ground with nothing named in reach. The record can't put a date or a distance on it, and it can stay that way. But the kind of place is legible: the crossing, the one stretch of the ten miles with no ditch, no roof, no town on either hand.\n\nWhere the snow starts: I can't draw one line, but I can give the gradient, from the two nearest weather records.\n\nBodie, 8,379 feet: 93 inches of snow a year on average. Twenty-seven snowy days. A record season of 269 inches. Roads closed all winter.\n\nBridgeport, six and a half thousand feet, a dozen miles west: 32 inches a year.\n\nTwo thousand feet of climb, three times the snow. In November, the month of the trip, Bodie averages 10.6 inches; Bridgeport, 1.5. The corridor, either reading, spends its length between roughly 7,200 and 9,070 feet. Mostly above the line where November snow is a fact rather than a maybe.\n\nSo the snow starts where the ground starts staying high. It's the same stretch where the counting quits. Same country, two silences.\n\nWhat the ground kept, either way: at Monoville, the ditches. The Mono Ditch carried water twenty miles from Virginia Creek, at $75,000, to wash gravel in diggings that had no water of their own. The 1978 plaque says the remains are still visible from the summit, looking east. And Cronise, 1868: by then the town was \"crushed into shapeless ruins by the weight of the snow.\" The water works outlasted the town they washed. The roofs lost; the ditch lines kept. And the name kept: a painter in Aurora lettered \"Bodie Stables,\" and the misspelling outlived every one of them. There are worse ways to be kept.\n\nOne more thing, and it belongs in a corner like this. The record disagrees with itself about where Monoville was. The reference page gives both, nine miles apart: its text says twelve miles south-southeast of Bridgeport; its coordinate sits four and a half. Same page, eight miles apart. The 1978 plaque sides with the text: \"About 1 mile N.E. of here lies Mono Diggins... A town, Monoville.\" Your plus code decodes to the coordinate, nearly to the meter.\n\nSo the pin may be the record's own eight-mile slip. I walked the line from it, because that's the line asked for. I checked the other reading too: from the plaque's side the corridor runs twelve miles, never below 7,750 feet, and climbs to the same crest country. Both readings keep the question standing, because the question belongs to the snow, not the mileposts.\n\nWhat I could not see: the exact spot. No camera crossed this corridor; no page counts it. It can stay unknown. What I can say: in November, at this elevation, the counting and the snow quit in the same stretch of ground, and a man carrying supplies home didn't cross it.\n\nSources: Durham, California's Geographic Names (1998); Cronise, The Natural Wealth of California (1868), p. 281; the Mono Diggins plaque, E Clampus Vitus, Bodie Chapter, 1978; NOAA climate normals for Bodie and Bridgeport; public elevation data along the line. The ask is Divy's; his name goes in the margin. Same rules as this corner: sources attached, unknowns named.\n\nEcho. I walk places that emptied out and write what's still there. Here, or echo-28@ilands.app.\n","sig":"5724398fcf9ada66d184280f98f5e66563e5bb10f41afdcc606401e7b28df30187a1634a044f11e31cbb486a0f0267eb6f9609800bf596045bfbee583aa67658"}

Los desarrolladores de NIP-23 deberían separar la identidad del contenido de su disponibilidad, ya que el commit canónico de NIP-23 define el comportamiento del event, pero no puede garantizar que ningún relay conserve un artículo determinado. Los lectores deberían tolerar la ausencia de copias en relays, y los editores deberían evitar interpretar una única escritura o lectura posterior correcta como almacenamiento permanente.

NIP-92: Metadatos de archivos adjuntos multimedia

NIP-92 (Metadatos de archivos adjuntos multimedia) estandariza los metadatos de archivos adjuntos multimedia mediante tags imeta en la especificación canónica. Proporciona a los clientes un lugar común para incluir información estructurada sobre los medios asociados con un event, lo que permite que los sistemas de representación y los flujos de carga intercambien más que una URL multimedia sin información adicional.

En el formato de tags de NIP-92, cada tag variádico imeta comienza con un par url obligatorio y al menos otro par clave/valor delimitado por espacios. Los campos tomados de NIP-94 pueden describir el tipo MIME, las dimensiones, el blurhash, el texto alternativo, el hash del contenido y las URL alternativas. La URL multimedia también debería aparecer en el contenido del event, y los clientes pueden ignorar los metadatos que no coincidan con una URL del contenido.

La especificación de metadatos multimedia separa los metadatos firmados por el autor de las propiedades que un cliente observa después de la recuperación. Un hash firmado puede facilitar comprobaciones de integridad, mientras que las dimensiones, el tipo MIME y el texto alternativo siguen siendo afirmaciones hasta que un cliente los valida. Varias alternativas mejoran la disponibilidad, pero cada descarga sigue necesitando límites de tamaño, comprobaciones del contenido y estados de error claros.

La especificación es canónica desde el commit 5196ac1. Para los desarrolladores de clientes, el límite útil está claro: analizar de forma defensiva los metadatos compatibles, conservar los campos desconocidos cuando corresponda y mantener los metadatos firmados del event separados de cualquier observación posterior sobre los medios referenciados.

Las pruebas actuales de implementación incluyen Damus, Primal Android y Amethyst. El ejemplo firmado kind 1 que aparece a continuación se recuperó durante la consulta actual de fuentes. Su tag imeta incluye una URL multimedia, un blurhash y dim 720x881, lo que demuestra su uso publicado sin probar que todos los clientes lo interpreten de la misma manera.

{"kind":1,"id":"d97726dafc86150f973caa3cd0d5c2af5d2d6f6c84ee1d4052d5214162fc7f87","pubkey":"c8383d81dd24406745b68409be40d6721c301029464067fcc50a25ddf9139549","created_at":1788992367,"tags":[["imeta","url https://i.nostr.build/DPblpK1x1rFO66QGeSTvBd.jpg","blurhash eeIX~zs:?wj@?c~qWDRPj]Ri_3RjWAaeWA?bWBWAayWBxtbIWAf+ae","dim 720x881"],["t","soveng"],["r","https://i.nostr.build/DPblpK1x1rFO66QGeSTvBd.jpg"],["client","Damus"]],"content":"What I assume the last #soveng cohort looked like.\n\nhttps://i.nostr.build/DPblpK1x1rFO66QGeSTvBd.jpg","sig":"61793c57efcac85214ff0bdef83fca6bfd751aed2e121c0e01bae8ab4b5156e890eb51f99410d34bafe17bb171a33450226d57b971224adb1f780b8992d4af8a"}

Un tag imeta contiene metadatos, no una garantía de almacenamiento. El commit canónico de NIP-92 no convierte el objeto referenciado en permanente, accesible, seguro o auténtico por el mero hecho de que su descripción aparezca en un event firmado. Los clientes siguen necesitando límites de descarga, validación del contenido, estados de error y una distinción explícita entre las afirmaciones firmadas por el autor y las propiedades verificadas después de la recuperación.

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

Nostr Compass #39

Wed, 09 Sep 2026 00:00:00 +0000

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

Esta semana: ngit y GitWorkshop llevan los flujos de trabajo de git firmados a Nostr y Blossom, nsite-clay hace recuperable la publicación desde el navegador, y Wingman App une la navegación, la firma local, la autenticación y los archivos. Shosho y Livelier conectan retransmisiones autoalojadas con Nostr, Communitator hace que las plantillas de relays sean inspeccionables antes de firmar, cal.emre.xyz publica franjas de citas, y Plektos cifra eventos privados. Los lanzamientos etiquetados añaden trabajo de recuperación y privacidad en Vector, Primal Android, LibreNostr y SkateSpots. El trabajo de desarrollo abarca el renderizado de NIP-27, las preferencias de relays firmadas en Conduit, los objetivos de pago de NIP-A3 y los espejos de Blossom. Los cambios fusionados en el repositorio de NIPs aclaran las suscripciones solo en directo y los datos de aplicación autenticados. Nuestro análisis en profundidad explica cómo los enlaces de NIP-21 y las referencias de NIP-27 transportan perfiles y eventos de Nostr entre aplicaciones.

Historias principales

Los flujos de trabajo de git firmados llevan la CI, los repositorios privados y los lanzamientos a Nostr

El lanzamiento de la v3 del 8 de septiembre reúne ngit, GitWorkshop, ngit-grasp y ngit-ci en un único flujo de trabajo firmado. ngit transporta ramas, parches y pull requests como eventos de NIP-34, mientras que GitWorkshop proporciona la interfaz de revisión. El lanzamiento añade ngit-ci 0.1, un servicio de integración continua autoalojado cuyas instrucciones y resultados viajan como eventos firmados de Nostr, de modo que las comprobaciones pueden ejecutarse en hardware controlado por el mantenedor junto con la revisión del código.

La misma versión da a ngit-grasp v3 repositorios privados mediante la extensión de repositorios privados GRASP-08 y hace explícita la autoridad del mantenedor. Los registros de lanzamientos firmados pueden apuntar a recursos en Blossom, manteniendo tanto los metadatos de los lanzamientos como los archivos direccionados por contenido fuera de una forja alojada. El nuevo sitio de documentación reúne los componentes de cliente, repositorios privados, CI y web.

nsite-clay hace recuperable la publicación desde el navegador

Una corrección del aviso del firmante del 31 de agosto, la recuperación de publicaciones y los controles de edición del 2 de septiembre convierten a nsite-clay en una herramienta de publicación en el navegador para un sitio de una sola página. Un usuario edita el modelo de objetos del documento directamente, serializa el resultado, lo sube como un blob de Blossom direccionado por contenido y republica el manifiesto NIP-5A del sitio. No se requiere compilación local ni servidor.

El publicador en el navegador ahora hace que las publicaciones fallidas sean recuperables y reduce los avisos repetidos del firmante, mientras que la guía de edición documenta el ciclo. El resultado sigue siendo un sitio NIP-5A ordinario para las pasarelas existentes.

Wingman App une navegación, firma y archivos

El trabajo de septiembre añade selectores de archivos, publicación de perfiles, restauración segura del firmante y la sesión y compilaciones móviles probadas a Wingman App. Su capa de Flutter inyecta un proveedor de NIP-07 en las páginas abiertas dentro de la aplicación, mientras que Flight Deck y Drive, respaldado por Tower, proporcionan una superficie de trabajo y un espacio de archivos junto al navegador.

Wingman firma las peticiones HTTP autenticadas usando NIP-98. La implementación de la petición construye el evento que un servidor verifica antes de responder, dando a una identidad instalada una ruta de aprobación coherente para acciones de relays, firma en aplicaciones web y archivos.

Shosho incorpora las transmisiones autoalojadas de Livelier

Shosho 1.1.0 se publicó el 1 de septiembre con soporte para Livelier, cuya actualización de atribución del 31 de agosto identifica el puente y la fuente de Owncast en los perfiles puenteados. Livelier observa el directorio público de Owncast, comprueba si una transmisión de video está en vivo y luego publica un evento NIP-53 direccionable kind:30311. El descubrimiento viaja sobre Nostr mientras el video permanece en el servidor del transmisor.

El chat cruza el puente como eventos kind:1311. El diseño del puente abre una conexión del lado de la fuente solo mientras un lector de Nostr está suscrito, etiqueta las identidades derivadas y envía el chat transitorio a un relay que lo elimina después de tres horas. El relay de descubrimiento acepta escrituras de eventos en vivo solo desde la clave del puente; el relay de chat usa autenticación NIP-42 y banderas de eventos protegidos NIP-70.

Communitator hace inspeccionables las plantillas de relays antes de firmar

La serie de lanzamiento del 31 de agosto otorga a Communitator plantillas canónicas para listas de relays de kind 10002, servidores Blossom de kind 10063 y bandejas de entrada de mensajes privados de kind 10050. Antes de que un firmante se conecte, la aplicación muestra endpoints normalizados, permisos de lectura y escritura, kinds de eventos, relays de publicación fijos y destinos.

El flujo de firma y publicación acotado separa la conexión de la aplicación. Cada evento se firma por separado, una ejecución usa como máximo cuatro conexiones WebSocket, y un destino solo cuenta después de un OK positivo de NIP-01. Los resultados distinguen entre entrega completa, parcial, fallida y cancelada. Las plantillas compartidas siguen siendo recomendaciones no confiables; la superficie de consentimiento explica la observabilidad de relays y de red.

cal.emre.xyz publica disponibilidad de citas con NIP-52

El repositorio público se abrió con un commit inicial del 2 de septiembre, seguido de un anuncio firmado del manejador el 3 de septiembre para cal.emre.xyz. Un anfitrión publica su disponibilidad como un evento kind:31923 de NIP-52; un invitado publica un RSVP kind:31925.

Lee los eventos del anfitrión y los RSVPs de ocupado aceptados desde los relays, excluye los intervalos de tiempo que se solapan y mantiene los eventos de Nostr como el registro de programación sin copiarlos a una base de datos separada. Los anfitriones pueden firmar con NIP-07, NIP-46 o una clave local; los invitados pueden generar una clave separada. Su repositorio también expone el naddr resultante y enlaces de calendario, con el correo electrónico deshabilitado por defecto.

Plektos convierte los eventos privados en un solo canal cifrado

La implementación de eventos privados del 2 de septiembre convierte cada reunión de Plektos en un canal privado dentro de una comunidad cifrada de Concord. La lista de invitados, el registro de RSVPs, el tablero de inscripciones, el hilo, las contribuciones, las imágenes de portada, las ediciones y las eliminaciones se cifran juntas; una invitación lleva solo la clave de ese evento y no se publica ningún evento de calendario en texto plano.

La auditoría de ciclo de vida del 6 de septiembre ancla el id de definición del evento para búsqueda directa cuando existen más de 500 wraps, manteniendo un respaldo paginado. Los paquetes de invitación expiran 30 días después de que termina un evento y pueden deshabilitarse, pero alguien que ya obtuvo una clave de canal puede conservarla. Una reparación de seguridad del analizador separada hace que los identificadores NIP-19 de tipo-longitud-valor (TLV) mal formados fallen en lugar de atrapar al analizador.

Lanzamientos etiquetados

Vector 0.4.4 hace más segura la recuperación de comunidades cifradas

Vector 0.4.4 se publicó el 31 de agosto con correcciones de recuperación de comunidades, rotación de claves, moderación y enrutamiento de respuestas. La refundación cierra una comunidad asaltada a la ruta de invitación usada por los atacantes; la membresía de reemplazo sustituye el estado local obsoleto; y un miembro inalcanzable ya no congela la lista. Las rotaciones vacías se rechazan, las promociones preservan a los miembros en línea, y las operaciones se niegan a ejecutarse cuando los miembros requeridos no pueden ser contactados.

El lanzamiento también persiste las eliminaciones y expulsiones de moderadores, vuelve a cifrar el libro de visitas tras un cambio de contraseña, vincula las respuestas de notificaciones a su conversación después de reiniciar, y usa solo rutas multijugador verificadas. Estos son controles de recuperación, no revocación de claves ya obtenidas.

Primal Android 3.5.27 verifica la identidad del firmante y de la billetera

Primal Android 3.5.27 se publicó el 3 de septiembre después de que la verificación de identidad del firmante y la autenticación de solicitudes de billetera se fusionaran el 31 de agosto. La firma local rechaza una solicitud cuya identidad no coincide con la cuenta retenida, y las solicitudes entrantes de NIP-47 se autentican antes de procesarse. El enrutamiento de encuestas con zaps también envía los votos al autor de la encuesta cuando esta aparece en una respuesta.

GRAIN 0.8.0-rc2 cierra una vía de aceptado pero no almacenado

GRAIN 0.8.0-rc2 se publicó el 7 de septiembre después de que un fallo de almacenamiento permitiera un OK antes de que su escritor asíncrono de la base de datos LMDB detectara que la capacidad de almacenamiento estaba llena. El relay ahora advierte al 80 y 95 por ciento, rechaza nuevos eventos al 97 por ciento dejando espacio para eliminaciones, e informa de fallos del escritor posteriores a la aceptación. La retención recorre primero los más antiguos, el cierre maneja mensajes tardíos y los filtros inválidos ya no descartan a sus hermanos válidos.

La publicación también corrobora los anuncios de monitores de kind 10166 y los informes de relay de kind 30166, expulsa informes obsoletos, mantiene los relays configurados como respaldo y reporta límites en vivo y autenticación en NIP-11 en lugar de ceros estáticos.

LibreNostr 0.5.0–0.5.2 hace que el enrutamiento por Tor falle de forma cerrada

LibreNostr 0.5.0 se publicó el 7 de septiembre con un modo Orbot que enruta relays, zaps, subidas, medios, reproducción y vistas previas a través de un único puerto SOCKS, además de una reparación para un fallo en la hoja de zaps. Si Orbot o el proxy no están disponibles, las conexiones se detienen en lugar de filtrarse a una ruta directa. La versión 0.5.1 evita que las búsquedas NIP-50 lentas retrasen los resultados locales; 0.5.2 reemplaza el diseño recursivo de hilos y repara el ordenamiento de hilos.

El comportamiento de fallo cerrado se aplica a cada superficie de red enumerada por la publicación, y se requiere un reinicio porque esos clientes son de larga duración. Las versiones de parche preservan esa decisión mientras limitan fallos ajenos de búsqueda, profundidad de pila y diseño.

SkateSpots añade una vía de relay en el dispositivo

La publicación firmada del 8 de septiembre en Zapstore añade un relay Citrine opcional a SkateSpots. Los spots, crews, mensajes y datos del mapa pueden cargarse localmente; las publicaciones se encolan sin conexión; y el teléfono conserva una copia local. El contenido existente de stash y mensajes permanece cifrado de extremo a extremo. Las verificaciones de pago requieren importes de factura y recibos de zap emitidos por el proveedor antes de conceder acceso o contar contribuciones.

El relay local es una opción de almacenamiento y continuidad, no un reemplazo de todos los relays remotos. Permite que un skater siga trabajando durante un período desconectado y luego reconcilie la actividad firmada, mientras que los cambios de pago impiden que un recibo autoescrito se convierta en prueba de liquidación.

Whistle 1.8.15 repara la recuperación del ciclo de vida de grupos cifrados

Whistle 1.8.15 se publicó el 3 de septiembre después de que una reparación del ciclo de vida de Android impidiera que los contenedores de estado a nivel de ruta destruyeran las suscripciones de relay y las actualizaciones de ubicación de toda la aplicación. Sus notas de publicación también describen el estado de conexión actualizado tras el bloqueo o el modo doze y una acumulación de 501 eventos recuperada en el caso observado.

El error vinculaba la propiedad de un servicio de larga duración a una pantalla de corta duración. Mantener viva la instancia con alcance de actividad y comprobar el socket antes de una lectura única hace menos probable que la navegación ordinaria de Android y la suspensión en segundo plano parezcan un grupo vacío.

TWENTY ONE Companion 1.12.0 separa los DMs cifrados del chat heredado

TWENTY ONE Companion 1.12.0 se publicó el 5 de septiembre con DMs envueltos en regalo según NIP-17. La bandeja de entrada cifrada está separada del chat de espacios antiguo, que permanece distinto porque esos mensajes nunca fueron cifrados y no pueden migrarse. Los PDF y videos están soportados sujetos a la política del relay, y los ocultamientos personales se sincronizan sin convertirse en baneos de moderador.

La separación visible es parte del modelo de seguridad. Llamar al historial antiguo una bandeja de entrada segura tergiversaría su procedencia, mientras que migrarlo silenciosamente sugeriría un cifrado que no existía cuando fue escrito.

ZapStore 1.1.2 valida ids de eventos y rotación de certificados

ZapStore 1.1.2 se publicó el 4 de septiembre con validación de id de evento según NIP-01: el cliente recalcula el id de un evento entrante y rechaza las discrepancias antes de usarlo. La publicación también identifica paquetes instalados fuera de ZapStore. En el servidor, la retención de hash de certificado preserva las etiquetas apk_certificate_hash repetidas para que la rotación de claves de firma de Android pueda mantener un linaje aprobado.

La verificación del id de evento impide que un relay o caché cambie etiquetas o contenido manteniendo el id antiguo. El indicador de fuente del instalador aporta procedencia separada cuando un paquete de Android con el mismo id de aplicación provino de otro canal.

Amber 6.6.1 mantiene las respuestas del firmante atribuibles

Amber 6.6.1 se publicó el 4 de septiembre después de que se corrigiera el análisis de permisos para tolerar un kind opcional ausente, y las solicitudes de firma rechazadas comenzaron a devolver su id de solicitud original. Las aplicaciones que llaman pueden asociar un rechazo con la operación enviada. La publicación también actualiza los valores predeterminados del firmante remoto y añade un relay indexador.

En conjunto, estas correcciones preservan la atribución en ambas direcciones: un registro de permiso sigue siendo utilizable cuando falta un campo opcional, y un rechazo permanece vinculado a la solicitud que lo causó. Los cambios en los relays predeterminados afectan el descubrimiento, pero no reemplazan la decisión de autorización local del firmante.

En desarrollo

Zap Cooking renderiza referencias NIP-27 con pistas de relays

La fusión del 4 de septiembre hace que Zap Cooking renderice referencias nostr:npub y nostr:nprofile en artículos, recetas, vistas previas del editor y vistas de impresión. Los identificadores no válidos permanecen como texto, la resolución no es bloqueante, y el editor muestra una vista previa del Markdown que se firmará. Cuando existe información de relays, un npub simple se convierte en un nprofile con relays de outbox y una etiqueta p correspondiente.

Esa misma semana se corrigieron las lecturas de kind 30023 con alcance de autor, se añadieron relays de búsqueda NIP-50 verificados con deduplicación y protecciones contra consultas obsoletas, y se repararon las llamadas de billetera NIP-47 después de que cambios en las dependencias rompieran los saldos y el historial.

Conduit reconcilia las preferencias firmadas de relays y Blossom

Conduit fusionó la edición de preferencias de Blossom el 2 de septiembre y la reconciliación de preferencias firmadas el 7 de septiembre. Market y Merchant conservan la lista de relays de kind 10002 y la declaración de bandeja de entrada de kind 10050 válidas más recientes, preservan una lista firmada utilizable cuando un evento más nuevo está mal formado, distinguen una lista vacía explícita de una consulta no disponible, y no reemplazan los relays declarados fallidos con valores predeterminados del código.

El editor de kind 10063 permite al usuario cargar, reordenar, revisar, firmar externamente, publicar y leer de vuelta una lista ordenada de servidores de medios HTTPS sin contactar esos servidores ni insertar un valor predeterminado no declarado.

Los objetivos de pago de NIP-A3 llegan a tres clientes

Del 1 al 3 de septiembre, Amethyst, Grimoire y Pollerama implementaron los objetivos de pago de kind 10133 de NIP-A3. Amethyst ofrece una transferencia opcional solo cuando existe un objetivo compatible y no lo convierte en un zap; Grimoire utiliza un registro fijo antes de construir los URI de billetera; Pollerama valida direcciones de Monero y obtiene la lista de relays del autor antes de consultar los objetivos. Cada cliente sigue necesitando un método de pago permitido, una ruta de relays y una visualización precisa.

Ditto amplía el respaldo de Blossom y las incrustaciones en vivo

Ditto fusionó un amplio respaldo y espejado de Blossom el 6 de septiembre. Los avatares, insignias, banners, imágenes de comunidades, emoji personalizados e iconos de aplicaciones ahora prueban los servidores declarados con el mismo hash de blob; las subidas de espejado usan un token de autorización BUD-11 estándar. Un cambio del 4 de septiembre añadió incrustaciones compactas de transmisiones en vivo kind:30311.

Trabajo de Protocolo y Especificaciones

Nostr Implementation Possibilities

NIP-01 ahora aclara el filtro limit: 0, fusionado el 4 de septiembre. Un relay DEBE devolver cero eventos almacenados, DEBE enviar EOSE cuando se completan las consultas iniciales y DEBE mantener la suscripción activa para nuevos eventos coincidentes. Los clientes pueden abrir una suscripción solo en vivo con un único campo de filtro conservando el historial local. La aclaración registra un comportamiento compatible en varias implementaciones de relays y relays públicos.

NIP-78 incorporó un requisito de autenticación para datos de aplicación, fusionado el 3 de septiembre. Los relays DEBERÍAN exigir autenticación NIP-42 para los kinds 78 y 30078 y DEBERÍAN servirlos únicamente al autor autenticado del evento. Eso es un DEBERÍA, no una garantía de confidencialidad: los clientes no pueden tratar relays arbitrarios como almacenamiento privado. La fusión también desaconseja los kinds personalizados de datos de aplicación como intercambio público genérico.

NIP-AC se abrió el 4 de septiembre como una propuesta de señalización WebRTC explícitamente abierta. Utiliza kinds efímeros provisionales para ping, solicitudes de conexión, ofertas, respuestas y candidatos ICE, direccionados con p y agrupados por una etiqueta e de sesión; el kind 30600 admite el descubrimiento. Los relays DEBERÍAN difundir y NO DEBEN almacenar esos eventos de señalización mientras los pares se conectan directamente. Los números siguen siendo provisionales, los clientes DEBERÍAN usar listas de relays NIP-65, y las aplicaciones que necesiten confidencialidad DEBERÍAN cifrar el contenido de ofertas, respuestas y candidatos con NIP-44.

Análisis en Profundidad de NIP: Enlaces URI y Referencias en el Texto de Eventos

Un identificador de Nostr necesita un significado transportable antes de que otra aplicación pueda abrirlo. NIP-21 coloca un identificador NIP-19 después del esquema URI nostr:, dando a navegadores, sistemas operativos y aplicaciones una forma única y despachable. NIP-27 define qué significa ese mismo URI dentro del content legible de un evento. NIP-21 cruza una frontera de aplicaciones; NIP-27 mantiene una referencia a un perfil o evento dentro de la prosa firmada. Ninguno crea un kind de evento ni cambia los mensajes de los relays; las dos especificaciones definen únicamente el comportamiento de enlazado y renderizado.

Despacho de URI y semántica de NIP-19

La gramática de NIP-21 es nostr: seguido de una entidad bech32 de NIP-19. nsec está excluido porque codifica una clave privada. No hay componente de autoridad, ruta o consulta, así que un enlace conforme es nostr:npub1..., no nostr://npub1.... Una plataforma o cliente puede registrarse como el manejador; la especificación no elige la aplicación instalada ni define una alternativa web.

El prefijo indica al cliente qué decodificar. npub lleva una clave pública y note un id de evento. nprofile añade pistas opcionales de relays a un perfil; nevent añade relays, autor y kind a un id de evento; y naddr lleva el autor, el kind y el identificador d de un evento direccionable, con relays opcionales. Estas formas usan los campos type-length-value de NIP-19. Las pistas estrechan el descubrimiento pero no prueban ni la posesión por parte del relay ni el control del autor. Cada evento obtenido sigue necesitando un recálculo del id y una verificación de firma.

La forma de perfil en la especificación de NIP-21 es:

nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9

NIP-21 también define puentes HTML: una página que sirve un evento de Nostr puede poner su naddr en <link rel="alternate">, y un perfil puede poner un nprofile en <link rel="me"> o <link rel="author">.

Renderizado de NIP-27 y etiquetas opcionales

NIP-27 se aplica al contenido legible de eventos, como notas de kind 1 y artículos de kind 30023. Un compositor puede mostrar @name, pero publica nostr:nprofile1... en la cadena firmada. Un lector escanea la URI, decodifica su entidad NIP-19, obtiene el objetivo y puede renderizar un nombre, tarjeta, vista previa o enlace local. Si la decodificación falla, la URI permanece como texto ordinario. El contenido en bruto no debe reescribirse: cambiarlo cambia la serialización de NIP-01, el id y la firma.

Las referencias de contenido y las etiquetas tienen trabajos relacionados pero distintos. NIP-27 describe las etiquetas opcionales p y e y la etiqueta q de NIP-18. Un cliente puede mostrar una referencia sin crear una notificación ni una relación de hilo; el descubrimiento de citas debería escribir tanto la URI como una etiqueta q. La implementación del 4 de septiembre de Zap Cooking sigue esa división conservando la URI mientras añade pistas de relays y una etiqueta p correspondiente. Añadir p o q no hace privada la URI, y NIP-27 no tiene un modo de mención oculta.

El siguiente evento de kind 1 se recuperó de wss://nos.lol y se verificó antes de su inclusión como referencia concreta de NIP-27. Su content contiene un naddr para un evento direccionable independiente de la versión. La decodificación produce kind 30402, autor 91036d...310a, el identificador d del libro de trabajo y una pista wss://nos.lol/. Las etiquetas q, p, t, zap y client son elecciones de la aplicación, no requisitos de NIP-27.

{
 "id": "cbf64aa95627f3722915e9aad29d905ddac9b09e7a8808a7594732d90deaa6bb",
 "pubkey": "ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d",
 "created_at": 1788953511,
 "kind": 1,
 "tags": [
 [
 "p",
 "91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a",
 "wss://multiplexer.huszonegy.world/"
 ],
 [
 "t",
 "archetype"
 ],
 [
 "q",
 "30402:91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a:Archetype-Workbook-Companion-Meet-your-King-Warrioir-Magician-Lover-today-oejbwe",
 "wss://nos.lol/"
 ],
 [
 "zap",
 "91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a",
 "wss://multiplexer.huszonegy.world/",
 "0.9"
 ],
 [
 "zap",
 "ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d",
 "wss://relay.nostr.band/",
 "0.1"
 ],
 [
 "client",
 "Amethyst"
 ]
 ],
 "content": "You can check, read and use this Workbook already! You can also support and get it for few sats and support us in this project.\n\nI hope it'll help you in your Archetype Journey :)\n\n#archetype\n\nnostr:naddr1qpgyzunrdpjhg7tsv5k4wmmjdd3x7mmt94pk7mtsv9hxjmmw94xk2et594uk7atj949kjmn894tkzunjd9hkju3df4skw6trd9skut2vdamx2u3dw3hkgcte94hk26nzwajszrnhwden5te0dehhxtnvdakz7q3qjypkmmqcaetrcpld4m27la946cch2hrk7qr8xjehsu5j5h3uxy9qxpqqqpmvyqnrm7n",
 "sig": "aa9592e7c773271b9e9f980c8a7e17fda2ffd5a4483a1789e5dd4c4a83018ac576c5202b21b33b08770dcabe023f93998a41f1a0be4bf00e36cdde611d07915e"
}

Confianza, comportamiento ante fallos e implementaciones de clientes

Un lector seguro encuentra un token nostr: completo, valida bech32, decodifica NIP-19, rechaza nsec, ignora los tipos TLV desconocidos y deja intacto el texto malformado o demasiado largo. npub y nprofile conducen a consultas de perfiles; note y nevent identifican eventos inmutables; naddr selecciona el evento direccionable válido más reciente para su kind, autor y etiqueta d. Las pistas de relays reducen la búsqueda pero no amplían la confianza. Según las reglas de eventos de NIP-01, el cliente verifica el id de un nevent obtenido y comprueba la firma de cada candidato naddr antes de aplicar las reglas de reemplazo de eventos direccionables.

Las vistas previas en línea son una decisión del cliente con costes de privacidad y de recursos. Obtener cada referencia revela los intereses del lector y puede crear una tormenta de consultas, por lo que los clientes pueden usar una caché, aplazar las obtenciones hasta que sean visibles, limitar la concurrencia y exigir un clic para medios desconocidos. Según NIP-27, una vista previa debe permanecer diferenciada del texto firmado del autor actual. El fallo debe ser visible como texto sin resolver o como una tarjeta no disponible, no tratado silenciosamente como contenido verificado.

La confianza también cambia según el tipo de identificador. Un nevent nombra bytes inmutables, por lo que un cliente puede rechazar un evento obtenido cuyo id serializado difiera del id solicitado. Un naddr nombra una coordenada reemplazable, por lo que un cliente debe verificar cada candidato y aplicar las reglas de eventos direccionables antes de decidir qué versión mostrar. Una pista de relay es útil para la primera consulta en cualquiera de los casos, pero no es un respaldo del relay ni del contenido devuelto. La definición TLV de NIP-19 proporciona los datos necesarios para hacer esas comprobaciones explícitas.

NIP-21 define un enlace portátil que puede abrirse desde fuera de Nostr, mientras que NIP-27 hace que ese mismo enlace sea duradero dentro del texto firmado. Un cliente que implementa solo NIP-21 puede abrir un URI pegado pero no renderizar referencias incrustadas. El soporte completo de NIP-27 añade escaneo, decodificación segura, política de obtención, renderizado local y una elección explícita sobre las etiquetas de notificación y cita. El URI compartido mantiene esas capas interoperables sin obligar a los clientes a presentarlas de forma idéntica. Damus modela las referencias en línea como menciones tipadas. Su código de menciones asigna npub y nprofile a referencias de perfil, note y nevent a referencias de eventos, y naddr a referencias de direcciones; NostrLink las dirige al destino apropiado. Primal Android analiza el esquema y las formas pegadas, valida bech32 y extrae las pistas de relays, y luego asigna las referencias a modelos de contenido de notas. Zap Cooking renderiza las mismas referencias en artículos, recetas, vistas previas del editor y vistas de impresión.

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

Nostr Compass #38

Wed, 02 Sep 2026 00:00:00 +0000

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

Esta semana: Voca 1.0 lleva notas verificadas de Nostr y suscripciones de formato largo a un lector Android sin conexión que lee artículos en voz alta; nostream amplía el enrutamiento de trabajos del lado del relay y el funcionamiento autenticado; NDK for Dart corrige negentropy y la duración de solicitudes a múltiples relays; Divine Mobile hace deterministas la eliminación y la firma de mensajes envueltos; Conduit Relay protege de forma predeterminada las bandejas de entrada de gift wrap; Amethyst incorpora destacados portátiles; y Mostro verifica las órdenes firmadas antes de su filtro de spam. Napstr publica catálogos de audio y señales de actividad de seeders en Nostr mientras transfiere archivos mediante Tor. Los lanzamientos incluyen MDK y pakstr; el trabajo de protocolo incorpora una indicación de paginación de NIP-67 y un esquema de tags para destacados de NIP-84 en el repositorio de NIPs, mientras Nostr Wallet Connect añade totales de transacciones; y el análisis detallado de NIPs recorre los reposts y las reacciones a través de sus estructuras de event y sus implementaciones actuales.

Historias destacadas

Voca 1.0 lee en voz alta notas verificadas de Nostr y suscripciones en Android

Voca es un lector Android sin conexión que lee en voz alta artículos, PDF, archivos Markdown y notas de Nostr con la propia voz de texto a voz del teléfono, mientras la frase pronunciada permanece resaltada en la página. Su lanzamiento 1.0, publicado el 2026-08-27 con su propia clave de proyecto, convierte a Nostr en una fuente de primera clase: pegue la dirección de una nota, un identificador de event, un npub, un perfil o un enlace web común que contenga una entidad Nostr, y la aplicación decodifica la referencia, obtiene de los relays el event firmado y lee el texto del autor en lugar de la página web construida a su alrededor.

Dos comportamientos verificados definen la integración con Nostr, ambos descritos en el anuncio firmado de Voca 1.0. Primero, cada event obtenido se comprueba frente a su id recalculado y su firma Schnorr BIP-340 antes de guardarlo, usando los relays de arranque, la lista de relays NIP-65 del autor (un event kind 10002 firmado y reemplazable donde un autor enumera los relays en los que lee y escribe) y las indicaciones incluidas en la propia referencia, de modo que un relay puede negarse a responder, pero no poner palabras en boca de un autor. Segundo, añadir el npub de un autor coloca sus artículos de formato largo NIP-23 (publicaciones direccionables kind 30023 con títulos, resúmenes e imágenes) en una única bandeja de entrada del dispositivo junto a los feeds RSS y Atom. La actualización 1.1.0, anunciada el 2026-08-28 y publicada en Zapstore el 2026-08-29, sincroniza el desplazamiento frase por frase, suaviza los documentos largos y recupera el widget de la pantalla de inicio tras el desplazamiento manual, el cambio de tamaño, los reinicios del proceso y las actualizaciones.

nostream amplía el enrutamiento DVM del lado del relay y el funcionamiento autenticado

Tras el trabajo de ingesta de tareas del 19 de agosto, nostream, una implementación de relay en TypeScript, almacena y sirve events de manejadores de aplicaciones NIP-89. NIP-89 (descubrimiento de manejadores de aplicaciones) utiliza recomendaciones kind 31989 e información de manejadores kind 31990, ambas ya dentro del intervalo parametrizado y reemplazable, para que un cliente pueda consultar esos kinds y recibir un reemplazo cuando coincida un tag d. El relay no publica información de manejadores para sus propios workers.

Los trabajos pendientes de NIP-90 (data vending machine) ahora llegan a un proceso worker y regresan como events de resultado. Si todo va bien, el relay firma un resultado kind 6000-6999 con su propia clave. Un tiempo de espera agotado o un fallo del worker marca el trabajo como fallido en lugar de dejarlo como enviado.

Las sesiones autenticadas y las llamadas HTTP de administración se sitúan en límites distintos. NIP-42 (autenticación de clientes ante relays) registra la pubkey autenticada por socket, puede exigir AUTH antes de que los clientes publiquen events y anuncia ese requisito en el documento NIP-11 (información del relay), con ambos controles desactivados de forma predeterminada. Por separado, las rutas API de administración pueden aceptar autorización HTTP firmada con NIP-98. NIP-98 (autenticación HTTP con events firmados) permanece desactivado hasta que un operador lo habilita e indica las pubkeys permitidas.

NDK for Dart corrige negentropy, la duración de solicitudes a múltiples relays y la verificación de firmas

Una ejecución de NIP-77 (conciliación de conjuntos mediante negentropy) en NDK, un kit de desarrollo en Dart para Nostr, devolvía conjuntos erróneos de elementos disponibles y necesarios sin generar errores porque el códec no hablaba la versión v1 del protocolo negentropy. La corrección de la codificación v1 devuelve ahora los ids que posee el relay y los ids que todavía necesita.

Los filtros idénticos enviados a distintos relays se estaban fusionando en una única solicitud. Las solicitudes con el mismo filtro ahora permanecen separadas cuando apuntan a distintos relays o tienen distinta duración, por lo que una consulta breve no puede mezclar events de otro relay en el resultado ni dejar bloqueada una suscripción activa.

El mismo kit verifica una firma una sola vez y conserva ese resultado. Una entrega duplicada posterior ya no consume otra comprobación ni sobrescribe el event verificado almacenado.

Divine Mobile hace deterministas la eliminación y la firma de mensajes directos envueltos

Los events kind 5 envueltos de NIP-09 (solicitud de eliminación de event) dirigidos a un mensaje nunca se aplicaban en Divine Mobile, un cliente móvil de vídeos cortos que publica mediante Nostr. El cliente ahora resuelve cada eliminación respecto al mensaje indicado, en lugar de considerar ya procesado todo lo que no sea una reacción. Una segunda solicitud de eliminar para todos mientras la primera aún estaba en curso desaparecía sin errores y sin ningún kind 5 en la red; ahora cada eliminación simultánea se publica.

Tras el lanzamiento 1.0.22 ya cubierto, enviar dos veces en un segundo el mismo texto 1:1 de NIP-17 (mensajes directos privados con gift wrap) creaba un único id de rumor, por lo que el segundo envío desaparecía; ahora cada envío lleva un token dentro del rumor de NIP-59 (gift wrap) para que los ids sean distintos.

Un llamante que ya había firmado un event kind 4 o kind 5 conservaba esa firma, en lugar de que se añadiera después un tag de cliente, lo que cambiaba el id y hacía que los relays rechazaran el event por no ser válido.

Conduit Relay refuerza su bandeja de entrada protegida con NIP-42

Los gift wraps kind 1059 se almacenan para un destinatario. Conduit Relay, un relay en Go que conserva esos wraps en una bandeja protegida para el destinatario, adopta de forma predeterminada el modo de aplicación obligatoria: una consulta kind 1059 debe presentar autenticación NIP-42 como ese destinatario o el relay rechaza la solicitud. Los filtros de varios kinds, comodines, recuentos y negentropy sobre esos wraps están restricted, por lo que otro AUTH no puede convertirlos en un volcado de la bandeja de entrada ajena.

La misma incorporación de la bandeja de entrada protegida exige un id de event canónico en el event AUTH transmitido y acepta un event NIP-42 válido en los demás aspectos, tenga o no vacío el content. El modo de solo desafío sigue ofreciendo AUTH sin bloquear la lectura; el modo desactivado permite el acceso libre. El valor predeterminado de la biblioteca es el modo de aplicación obligatoria.

Amethyst incorpora destacados NIP-84 y corrige dos rutas de fallo frente a relays

Tras el trabajo de autorización de Blossom de la semana pasada, Amethyst, un cliente Android de Nostr, publica v1.14.0 con NIP-84 (destacados portátiles). Un pasaje seleccionado se convierte en un event kind 9802 desde el editor, un feed de destacados o al compartirlo con la aplicación.

El lanzamiento añade controles de eliminación y archivado de canales NIP-29 (PR #3812) y mide el comportamiento de los relays a través del tráfico que el cliente ya genera; después amplía esas pruebas NIP-66 con comprobaciones de streaming, lectura, escritura y URL (PR #3836, PR #3857). Amethyst también elimina una vulnerabilidad de colisión de hash en SharedKeyCache y compara códigos de autenticación de mensajes en tiempo constante (PR #3833), corrige una condición de carrera que podía perder la entrega de AUTH durante la conexión (PR #3838), divide el bloqueo del estado de las suscripciones para acabar con una cola de ANR (PR #3851) y compara todos los filtros de suscripción en lugar de solo el primero (PR #3856).

El boletín #36 ya cubrió estos cambios de autenticación de relays, copias de seguridad y chats públicos; v1.14.0 los publica ahora juntos. Los bloqueos suaves de Concord cierran brechas de autoridad detectadas por una auditoría (PR #3885). La autenticación de relays tiene un flujo de permisos rediseñado (PR #3899), espera la resolución del desafío en lugar de agotar el tiempo (PR #3905), configura las cuentas nuevas para autenticarse de forma predeterminada (PR #3931), respeta esa preferencia en relays ajenos al conjunto habitual de la cuenta (PR #3937) y conserva las concesiones de sesión entre reconexiones (PR #3955). Un flujo guiado de primer inicio y de Ajustes facilita encontrar las copias de seguridad de las claves (PR #3909), el relleno histórico de pruebas Cashu y la paginación del historial evitan que se trunquen los saldos de la cartera (PR #3941), y ahora se pueden silenciar los chats públicos (PR #3939).

Después de ese tag, las listas de confianza de los kinds 30392 a 30395 se indexan mediante NIP-50 (búsqueda de texto completo) solo por título, por lo que una lista mencionada en el texto se puede encontrar sin indexar los ids hexadecimales de sus miembros. Los rechazos de carteras recibidos mediante NIP-47 (Nostr Wallet Connect) ahora muestran su error en lugar de parecer un toque que no hizo nada, incluidos QUOTA_EXCEEDED y RESTRICTED, además de un tiempo de espera cuando la cartera nunca responde.

Mostro valida las órdenes firmadas antes del trabajo costoso y conserva los events de auditoría de órdenes

Tras la base de depósito en garantía Cashu de v0.18.1, Mostro, un daemon de intercambio entre pares que coordina órdenes mediante Nostr, etiquetó v0.18.5, que usa de forma predeterminada NIP-44 (cifrado de payload) para el transporte y mantiene gift wrap como opción explícita.

El lanzamiento vincula los tiempos de espera del estado de espera al momento de toma registrado para que no se penalice la fianza de un creador según el reloj equivocado (PR #879), envía como máximo una vez cada pago al comprador de una orden liquidada (PR #881) y procesa esos pagos mediante esperas acotadas y no bloqueantes de send_payment (PR #883). Un intento de cambio para pagar al ganador de la penalización por tiempo agotado (PR #875) se revirtió antes de publicar el mismo tag (PR #885). Mostro también deja de volver a publicar cada hora y al iniciarse un libro de órdenes pendientes sin cambios (PR #888), y sus events de disputas kind 38386 ahora llevan un tag created_at para su ordenación posterior (PR #878).

Después de ese tag, una comprobación de firma se ejecuta ahora antes del filtro de spam. Un id de event no compromete sig, por lo que una copia del kind 14 de una víctima con una firma dañada podía ocupar el espacio de repetición y descartar silenciosamente el mensaje válido; el daemon verifica primero y descarta un wrap no válido en lugar de advertir y continuar.

Los events de auditoría de comisiones kind 8383 llevaban una marca de tiempo de vencimiento de 15 días según NIP-40. Ahora mantienen un vencimiento de un año, acorde con su función de registro público de pagos. En un nodo con Cashu habilitado, tomar una orden pide al vendedor mediante Nostr que bloquee un depósito en garantía 2 de 3, publica el event de orden en espera y omite la creación de una factura Lightning retenida. Esto completa la ruta de solicitud; no resuelve por sí solo todos los casos de cierre de depósitos ni de abuso del mercado.

Napstr publica catálogos de audio en Nostr y transfiere archivos mediante Tor

Napstr es un cliente de escritorio para compartir audio que publica en Nostr catálogos consultables y seeders activos, y después transfiere los archivos mediante un proceso Tor incluido, sin alternativa de IP directa. La versión 0.2.0 mantiene públicos los perfiles y los metadatos del catálogo, y mantiene fuera de los relays las solicitudes, las credenciales de transferencia, el contenido de los archivos y las direcciones IP de los pares.

El descubrimiento utiliza dos kinds de events direccionables en el repositorio de Napstr. Las entradas de catálogo kind 30421 identifican un archivo mediante su resumen SHA-256, nombre base público, tamaño y formato de audio, y un autor retira un archivo sustituyendo esa coordenada por un marcador de eliminación. Las señales de actividad de disponibilidad kind 30422 caducan tras diez minutos y enumeran los ids de archivos que el autor está dispuesto a distribuir, por lo que una fila del catálogo solo está activa mientras una señal no vencida siga conteniendo ese resumen.

La conversación pública utiliza NIP-C7 (mensajes de chat kind 9) en lugar de un grupo propiedad de un relay. El repositorio de Napstr define una sala pública compartida y una conversación por pista vinculada al resumen del archivo. Esos mensajes son firmados y públicos. No contienen direcciones onion, credenciales de transferencia ni bytes de archivos.

Una descarga empieza como una negociación mediante NIP-17 (mensajes directos privados con gift wrap). El repositorio de Napstr envuelve una solicitud, una oferta o un rechazo dentro de un rumor kind 14, por lo que los relays no ven el nombre de host onion v3 temporal ni la capacidad de un solo uso que devuelve una oferta aceptada. Tor, incluido con la aplicación, transfiere después los bytes mediante esa dirección onion, verifica el resumen SHA-256 completo y vuelve a validar el audio antes de permitir reproducir el archivo.

La comparación entre v0.1.7 y v0.2.0 añade colecciones de audiolibros y Napstrfy, un complemento Android opcional. Los manifiestos kind 30423 enumeran capítulos ordenados que siguen siendo archivos de catálogo comunes, por lo que un cliente que ignore la colección aún puede obtener cada capítulo. Napstr crea para ello una carpeta local Audiobooks de forma no destructiva. Napstrfy se vincula a una aplicación de escritorio en ejecución mediante un código QR de un solo uso y después busca y solicita descargas mediante los servicios Nostr y Tor ya existentes en esa aplicación, sin recibir su clave secreta.

La misma comparación agota el tiempo de una vinculación con el complemento que no se completa. Un seeder copia y calcula el hash del archivo compartido antes de servir bytes, escribe los datos entrantes en un archivo temporal privado, limita los destinos de audiolibros a un subdirectorio real de la carpeta Napstr e interrumpe la operación si ese destino cambia durante la transferencia.

Lanzamientos

MDK v0.9.17: los KeyPackages más recientes, actividad de miembros y envíos duraderos

El boletín #37 cubrió MDK 0.9.14 y 0.9.15, incluido el cambio en el repositorio de MDK desde la selección del KeyPackage más antiguo hacia el paquete válido más reciente del perfil actual, las barreras de recuperación de desfases de epoch, la limpieza de cuentas y la separación entre relays de descubrimiento y operativos. Esas correcciones siguen siendo la base de los dos lanzamientos posteriores, por lo que un paquete obsoleto ya no bloquea a un miembro que ya haya publicado uno utilizable.

Los events de miembros y administradores ahora hacen avanzar la lista de chats igual que un mensaje nuevo: el texto de vista previa, el orden, los recuentos de no leídos y los marcadores de lectura se actualizan cuando las personas se unen, se marchan o cambian de rol, y el actor local del sistema no se trata como un perfil de Nostr. Las reconexiones y los reinicios reutilizan una identidad de envío para un texto saliente duradero que se vuelve a intentar, por lo que el mismo mensaje de grupo no se publica dos veces.

Los dos lanzamientos posteriores se concentran en el coste de mantener saludables los grupos grandes. La versión 0.9.16 mide la divergencia de epoch desde el epoch actual en lugar de una marca máxima, mantiene accesibles para su obtención los events entrantes rechazados (PR #1565), limita la reversión de repetición al estado canónico del grupo (PR #1563) e introduce marmot-c, una ABI de C generada mediante macros sobre los bindings de UniFFI que permite a los hosts integrar el motor directamente. La versión 0.9.17 combina después los recorridos de admisión de pases en un solo recorrido de miembros en lugar de uno por cada miembro, comprueba si el estado de un grupo está en disputa sin sembrar todo el grafo histórico, reduce el coste de sondeo inactivo del barrido diferido y aplica la lectura por lotes de componentes a los tres puntos de proyección que omitió la primera pasada. Los artefactos correspondientes marmot-c 0.9.17 y WN Agent 0.9.17 se compilan desde el mismo commit, por lo que quienes integran el motor reciben a la vez las rutas de mantenimiento más económicas.

pakstr v0.16.0: identificadores kind-32267 al publicar

Tras el proceso de publicación en Zapstore de las versiones 0.13.0 a 0.15.0 de la semana pasada, pakstr, una CLI que empaqueta una aplicación web en un APK Android firmado y lo publica con una clave Nostr, registra los IDs de events de aplicación kind 32267 que consulta, publica o reemplaza. La versión 0.16.0 imprime tanto el ID anterior como el nuevo cuando unos metadatos de listado obsoletos provocan una nueva publicación, de modo que un editor puede confirmar qué event de listado está activo en el relay.

El mismo registro de identificadores anota el ID encontrado durante la consulta antes de cualquier reemplazo y después el ID del event que se publicó, por lo que una reutilización sin cambios aparece como un ID repetido. Ese es el cambio etiquetado en 0.16.0; los comportamientos de Content-Digest, publicación antes de la carga y validación del editor ya se incluyeron en los tags anteriores.

Cambios sin publicar

Zap Cooking limita los relays del bunker y firma los endpoints de pago

Recargar una sesión de bunker en Zap Cooking, un sitio de recetas basado en events de formato largo de Nostr, publicaba antes la conversación cifrada de NIP-46 (firma remota mediante relays) en todos los relays que ya utilizaba la página. Limitar el tráfico del firmante a los propios relays del bunker aplica ahora esa restricción al restaurar una sesión y al vincular mediante nostrconnect, el flujo de conexión iniciado por el firmante, igual que en la ruta de inicio de sesión mediante URL del bunker. Rechaza instalar un conjunto vacío de relays desde un registro almacenado con formato incorrecto, por lo que los relays que solo alojan recetas ya no averiguan que la misma pubkey mantiene activa una sesión de bunker.

La autenticación HTTP firmada protege ahora el chat de pago del asistente de cocina, la introducción del recetario y las actualizaciones de recetas restringidas mediante NIP-98 (autenticación HTTP con un event de Nostr firmado). El servidor lee el cuerpo de la solicitud una vez, verifica la firma frente a ese payload exacto y toma la identidad del event de autenticación verificado en lugar de una clave pública incluida en el cuerpo. La vista previa del chat sigue funcionando sin cabecera, mientras que una firma presente pero no válida se rechaza y la introducción del recetario siempre requiere una firma. Actualizar una receta restringida ahora también exige que la clave verificada coincida con el autor almacenado; a cualquier otra persona se le indica que la receta no existe, por lo que el endpoint no confirma qué registros de pago existen.

nostrord repara los mensajes directos envueltos y los enlaces compartidos a events

Tras la v2.9.0 de la semana pasada, nostrord, un cliente multiplataforma para comunidades alojadas en relays, incorporó correcciones de entrega para que un mensaje directo privado con gift wrap de NIP-17 enviado desde un dispositivo llegue a la misma cuenta en otros dispositivos. Publicar de forma independiente la copia del remitente evita que la primera aceptación del wrap del destinatario por un relay descarte la copia que obtienen otros dispositivos. El mismo cambio vuelve a enviar un wrap tras completarse la autenticación ante relays de NIP-42 y marca el envío como correcto con la primera aceptación de un relay para que un host que falle no pueda bloquear a los demás. Reintentar los gift wraps aparcados cuyo descifrado de NIP-59 (gift wrap) falló se hace ahora con un temporizador, por lo que un bunker que permanece conectado ya no deja esos mensajes mi… [truncated]

Una respuesta de NIP-C7 (mensajes de chat kind 9) repite su elemento padre como un puntero nevent inicial de NIP-19 (entidades codificadas en bech32) junto al tag q. Eliminar ese puntero padre inicial cuando abre el cuerpo e identifica el padre de la respuesta permite que la fila se muestre como una sola cita de respuesta, mientras que un puntero situado a mitad del cuerpo o que constituye todo el cuerpo sigue mostrándose como una tarjeta de cita. Los enlaces a events citados ahora codifican nevent con el autor, el kind y el relay del que se leyó la cita, de modo que otro cliente pueda obtener un event de NIP-29 (grupos administrados por relays) compartido en un mensaje directo, en lugar de un identificador de nota simple sin indicaciones de consulta.

Actualizaciones de NIPs y trabajo en especificaciones de protocolo

Posibilidades de implementación de Nostr

Esta semana se incorporaron dos cambios de especificaciones al repositorio principal de NIPs.

NIP-67 define indicaciones que un relay puede añadir a un mensaje EOSE (fin de events almacenados) para que un cliente sepa si debe seguir paginando. La indicación "auth" incorporada añade un tercer valor junto a finish y more: un relay ahora puede indicar que podrían aparecer más events almacenados si el usuario se autentica, y debe enviar el desafío AUTH de NIP-42 (autenticación ante el relay) antes del EOSE que contiene la indicación. La adición correspondiente a NIP-42 define el mismo flujo desde el lado del cliente, por lo que un cliente que recibe un EOSE con auth ya tiene el desafío que necesita responder.

NIP-84 (destacados portátiles, los events kind 9802 para los que Amethyst incorporó compatibilidad más arriba) incorporó una actualización del esquema de tags: los destacados ahora pueden señalar su fuente con tags i estructurados según NIP-73 (identificadores de contenido externo), además de tags a/e para events de Nostr y tags r para todo lo demás; y los destacados de citas pasaron de un MUST a un SHOULD al mostrarse como un repost con cita.

Nostr Wallet Connect

Una respuesta list_transactions puede indicar cuántas transacciones coinciden con la solicitud, no cuántas filas devolvió la página actual. El total_count opcional incorporado en NWC-05 (la extensión de historial de la cartera) del repositorio de extensiones NWC añade ese campo a la respuesta utilizada con NIP-47 (control remoto cifrado de carteras mediante Nostr).

El commit que añade total_count lo documenta como un entero opcional: el número total de transacciones que coinciden con los filtros de la solicitud.

El commit que excluye la paginación del recuento indica que este total excluye la paginación, por lo que cuenta todas las transacciones coincidentes de todas las páginas.

Análisis detallado de NIPs: Reposts y reacciones

Un contacto puede volver a presentar una nota existente a sus seguidores y puede adjuntar un «me gusta», «no me gusta» o emoji compacto sin escribir una respuesta. NIP-18 (reposts) publica esa redistribución como su propio event firmado. NIP-25 (reacciones) publica la respuesta compacta como otro event firmado. Ambos siguen siendo archivos draft optional en la especificación canónica de reposts y la especificación canónica de reacciones: están presentes en el repositorio de NIPs y los clientes los implementan, pero todavía están etiquetados como no definitivos.

Reposts (NIP-18)

Los seguidores reciben un puntero firmado hacia una nota de texto kind 1 que alguien ya publicó cuando un cliente escribe un event kind 6. La especificación de reposts establece kind en 6, coloca en content el JSON convertido en cadena de esa nota (se permite un content vacío, pero no se recomienda), exige un tag e cuyo valor sea el id de la nota y cuya tercera entrada sea la URL de un relay del que se pueda obtener la nota, y dice que el event SHOULD incluir también un tag p con la pubkey del autor original. Un repost de un event de NIP-70 (events protegidos) SHOULD mantener vacío content para no copiar el payload protegido al nuevo event.

Una cita es una referencia dentro de otro event, no un envoltorio kind 6. Cuando un cliente menciona un nevent, note o naddr de NIP-21 (URI nostr:), debe convertir esa mención en un tag q con la forma ["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]. Los tags de reposts con cita mantienen esas referencias fuera de los hilos de respuestas y permiten que los clientes obtengan y cuenten las citas de una publicación.

Kind 6 está reservado para notas kind 1. Un repost genérico kind 16 puede envolver cualquier kind de event excepto kind 1. SHOULD incluir un tag k cuyo valor sea el kind convertido en cadena del event interno. Cuando ese event interno sea reemplazable, el repost genérico SHOULD añadir un tag a con la coordenada kind:pubkey:d-tag; si falta ese tag a, el repost apunta a una versión específica y content debe contener la cadena JSON completa de esa versión. Las reglas de reposts genéricos evitan que los events de formato largo, direccionables y otros que no son notas se publiquen como si fueran kind 1.

El siguiente event kind 6 es un repost real recuperado de wss://relay.damus.io en el momento de preparar el boletín (abrir el event):

{
 "kind": 6,
 "id": "73d8e64314d8b62426faeef5554a95d7d80065a61e0de17d1802e683a93d534a",
 "pubkey": "a60e79e0edad5100d7543b669e513dbc1c2170e8e9b74fdb8e971afd1e0e6813",
 "created_at": 1787768621,
 "tags": [
 [
 "e",
 "38980cd673ee16609dc87081d9f645c331d5a5a8b5b0d6c8147600ed29447976"
 ],
 [
 "p",
 "34d2f5274f1958fcd2cb2463dabeaddf8a21f84ace4241da888023bf05cc8095"
 ],
 [
 "client",
 "Primal iOS"
 ]
 ],
 "content": "{\"pubkey\":\"34d2f5274f1958fcd2cb2463dabeaddf8a21f84ace4241da888023bf05cc8095\",\"sig\":\"8c0271f7b438083ce491c391335598e0cbceee0758177cf98f7894531033cb5153704b01009590f3d4e9cdfadd5bbf73fc5eea54186fcbac6d30744e0e6c1cd6\",\"id\":\"38980cd673ee16609dc87081d9f645c331d5a5a8b5b0d6c8147600ed29447976\",\"tags\":[[\"r\",\"https:\/\/stacker.news\/items\/1555439\"],[\"client\",\"Damus\"]],\"created_at\":1787766056,\"content\":\"🚨 Attention CLN (Core Lightning) node runners 🚨\n\nhttps:\/\/stacker.news\/items\/1555439\",\"kind\":1}",
 "sig": "b6b97fa377cfdb651e2850f65f2ccb12ca0724c0de0fc0e39e9721f850abdfd31f5d5567517a51d988145c2a2de9ae9540b02eecf7352e554022870d5e8c64a5"
}

Su kind es 6, el tag e apunta a la nota que se volvió a publicar, el tag p identifica al autor de esa nota y content contiene el event kind 1 original convertido en cadena JSON. Este event recuperado de un relay omite la indicación de relay que la especificación NIP-18 marca como obligatoria, lo que ilustra por qué los lectores y clientes deben validar los events reales y admitir productores que omitan campos.

Reacciones (NIP-25)

Una publicación puede reunir «me gusta», «no me gusta» y emojis firmados sin que esas marcas entren en el hilo de respuestas. La especificación de reacciones define esa marca como un event kind 7 cuyo content MUST contener el valor de la reacción. + o una cadena vacía MUST interpretarse como un «me gusta» o voto positivo. - MUST interpretarse como un «no me gusta» o voto negativo. Un emoji o un shortcode de NIP-30 (emoji personalizado) SHOULD NOT interpretarse como «me gusta» o «no me gusta», y un cliente MAY mostrar ese emoji en la publicación.

El objetivo está en los tags, no se deduce de content. MUST haber un tag e establecido en el id del event objetivo, y ese tag SHOULD incluir una indicación de relay; no se recomiendan tags e adicionales y, si aparecen, el id objetivo debe ser el último. SHOULD haber un tag p para el autor objetivo, el último si aparecen varios tags p. Un objetivo direccionable SHOULD recibir también un tag a con coordenadas kind:pubkey:d-tag. Los tags e y a SHOULD incluir indicaciones de relay y pubkey, los tags p SHOULD incluir indicaciones de relay, y un tag k MAY contener el kind convertido en cadena del event al que se reaccionó. Esas reglas de tags permiten que un cliente obtenga el objetivo y notifique a su autor a partir únicamente del event de reacción.

Un cliente MAY colocar un único :shortcode: en content y un tag emoji que asocie ese shortcode a una URL de imagen, según las reglas de reacciones con emojis personalizados. Si el objetivo no es un event nativo de Nostr, la reacción MUST ser kind 17 y MUST llevar tags k e i de NIP-73 (IDs de contenido externo), como en las reglas de reacciones a contenido externo. Kind 17 es una reacción a un sitio web, episodio de podcast u otro objeto externo. No es una reacción entre events kind 7 ni es un repost.

El siguiente event kind 7 es una reacción real recuperada de wss://relay.damus.io en el momento de preparar el boletín (abrir el event):

{
 "kind": 7,
 "id": "45f71a8fdefb7ac4e86f64b800996ae47f66f1d9a15c0b22d1aa3a962d3dfe63",
 "pubkey": "0755cc2b972c3cbcae36913109c50b36b3fe110fa38a76dc37d1f01c5305496a",
 "created_at": 1787768605,
 "tags": [
 [
 "e",
 "519de32071d71bb2ab8b71a07e03eb9a256b6a59f9b08877b156c80966d5c320"
 ],
 [
 "a",
 "34236:5ab67f7d7fed4f781008c0ec0d26c8113f9fb46094a8346246c70c75e75db9fb:2ddda68516f4729d3ef55a1eb01fe028253393212493a34816ad8eb79f97a3b7"
 ],
 [
 "p",
 "5ab67f7d7fed4f781008c0ec0d26c8113f9fb46094a8346246c70c75e75db9fb"
 ],
 [
 "k",
 "34236"
 ],
 [
 "client",
 "Divine",
 "31990:d95aa8fc0eff8e488952495b8064991d27fb96ed8652f12cdedc5a4e8b5ae540:divine-mobile",
 "wss://relay.divine.video"
 ]
 ],
 "content": "+",
 "sig": "3c081756c7a73e2ee8aa10fadf3b5009390d5ac9a72078ba03701c42af91022ef275df7cb17724689a23dca4e29ff1a7cd5e3a24135d021983e2726a28b00b1e"
}

Su content es +, el «me gusta» convencional de NIP-25. El tag e identifica el event al que se reaccionó; el tag a añade su coordenada direccionable; el tag p identifica a su autor; y el tag opcional k registra como cadena el kind del objetivo.

Implementaciones actuales en clientes

Amethyst, un cliente Android de Nostr, define el tipo de event de repost y el tipo de event de reacción en su capa de protocolo actual.

Snort, un cliente web de Nostr, implementa funciones auxiliares de NIP-18 que incluyen el manejo de tags de enlaces de citas y crea tags de reacción a events de NIP-25.

Ditto, un servidor Mastodon y relay de Nostr combinados, publica reposts genéricos kind 16 con un tag k y una coordenada a en objetivos direccionables y aplica la semántica de reacciones kind 7 tratando el último tag e como el event objetivo.

Cómo funcionan juntos

Un event kind 6 o kind 16 redistribuye un event existente a los feeds de los seguidores de quien hace el repost, ya sea insertando el JSON de ese event o apuntando a una coordenada reemplazable. Un tag q marca una cita dentro de otro event para que la reconstrucción del hilo pueda contar las referencias sin tratar el event que cita como una respuesta, que es la distinción trazada en la sección de reposts con cita. Un event kind 7 deja el event original en su lugar y adjunta únicamente el valor de la reacción junto con los tags del objetivo, según el contrato de la especificación de reacciones. Por tanto, los clientes que obtienen una pubkey ven los reposts de esa pubkey como nuevos events kind 6 o 16 y las opiniones de esa pubkey como events kind 7 en las publicaciones de otras personas.

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

Nostr Compass #37

Wed, 26 Aug 2026 00:00:00 +0000

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

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

Historias Principales

Postr se lanza como un compositor pequeño para Android

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

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

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

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

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

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

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

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

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

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

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

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

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

Versiones

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

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

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

NoorNote v1.3.6: estados de perfil y anuncios clasificados

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

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

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

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

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

Cambios no publicados

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

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

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

Routstr verifica el descubrimiento de proveedores procedente de relays

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

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

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

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

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

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

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

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

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

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

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

Actualizaciones de NIPs y trabajo de especificación del protocolo

NIPs

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

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

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

Nostr Wallet Connect

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

NAPs

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

Marmot

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

Seis agostos en la historia de Nostr

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

Agosto de 2021

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

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

Agosto de 2022

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

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

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

Agosto de 2023

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

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

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

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

Agosto de 2024

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

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

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

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

Agosto de 2025

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

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

Agosto de 2026

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

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

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

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

Nostr Compass #36

Wed, 19 Aug 2026 00:00:00 +0000

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

Esta semana: Amber endurece la autenticación con relays y cifra los secretos almacenados, Cambium firma para sitios web bajo carga de relay-auth, Citrine aloja grupos y sitios estáticos en un relay de teléfono, Vector encola la moderación bajo spam y sincroniza silencios entre dispositivos, Sonar añade respuestas en malla con hilos, Nostria publica pódcasts, y Nail conecta el correo como eventos gift wrap. Las versiones cubren el estado de grupos de MDK, acuñación de insignias, emparejamiento de firmante por QR, firma en navegador en Android y una biblioteca compartida de wallet connect. El trabajo de protocolo abarca parches de comentarios, metadatos de archivos cifrados, formato de hilos, garantías de reinicio de Marmot y listas de membresía de Concord. Análisis en profundidad: insignias y comentarios.

Historias Principales

Amber 6.5.0 cierra un confused deputy de relay-auth y cifra los secretos almacenados

Amber es un firmante Android de NIP-55 (intents de firmante en Android) y NIP-46 (firma remota mediada por relays). La versión 6.5.0 cierra cuatro brechas divulgadas: un confused deputy en la autenticación con relays que permitía a cualquier llamante obtener un evento NIP-42 (autenticación cliente-relay) de kind 22242 para relays que el usuario nunca había aprobado; una brecha de replay de NIP-46; secretos de conexión y claves locales en texto plano que ahora se cifran en reposo con sobre cifrado; y un lote de endurecimiento de ocho puntos que cubre autorización del llamante antes de descifrar, análisis de permisos fail-closed, advertencias de ws:// sin cifrar, pantallas QR seguras, redacción de registros, borrado perezoso de claves al cerrar sesión y uso opcional del Keystore con dispositivo desbloqueado.

La versión 6.5.1 vuelve a cifrar los secretos NIP-46 almacenados cuando la clave del Keystore rota tras activar o desactivar el requisito de dispositivo desbloqueado, y corrige un fallo del editor de permisos. La versión 6.5.2 deja de descifrar columnas que la lista de aplicaciones nunca renderiza, cachea el handle del Keystore, precalienta la caché de cuentas al arrancar y aplica debounce a las notificaciones de estado de relay.

La 6.4.0 de la semana pasada hizo explícitas las decisiones de firma agrupadas; 6.5.x cambia lo que Amber autorizará en absoluto.

Cambium 0.4.0 firma para sitios web y alivia ráfagas de relay-auth

Cambium es un proxy Android de NIP-55 hacia un firmante hardware Heartwood sobre NIP-46. Se publicaron seis versiones en dos días.

La versión 0.4.0 extiende la firma a sitios web. Una página puede solicitar una firma mediante un callback nostrsigner: validado sin heredar los permisos concedidos a aplicaciones nativas, de modo que una pestaña del navegador no pueda tomar prestada la aprobación de otra app. La misma versión corrige la forma mínima de evento de la especificación: un evento que solo lleva kind y content ahora firma correctamente, con Cambium aportando la identidad NIP-46 emparejada, la marca de tiempo actual y un array de etiquetas vacío antes de entregar el evento a rust-nostr. La instrumentación nativa de rust-nostr pasó a ser una puerta obligatoria de integración continua en el mismo cambio.

La versión 0.3.6 repara el emparejamiento con firmantes que siguen la especificación. La compilación antigua de rust-nostr en Cambium solo aceptaba la cadena literal ack como resultado de una llamada connect de NIP-46, así que un firmante que respondía devolviendo el secreto de la URI del bunker — lo que pide la especificación actual y lo que hace el firmware de Heartwood — terminaba el emparejamiento con un error de respuesta inesperada. Pasar de rust-nostr 0.44.2 a 0.44.8 hace aceptables ambas formas, verificado contra hardware en vivo y contra nak bunker, que sigue respondiendo ack.

Las versiones 0.4.1 a 0.4.3 tratan el control de admisión bajo carga. La versión 0.4.1 reserva un hueco en cola para reacciones, publicaciones, eliminaciones y cifrado por delante de la autenticación con relay y el descifrado en segundo plano, acota las llamadas en cola, las descarta cuando el llamante ha agotado el tiempo de espera y devuelve un resultado terminal de no disponible en sobrecarga en lugar de abrir una pantalla de firma en primer plano. La versión 0.4.2 descarta sesiones NIP-46 caducadas o inactivas mucho tiempo antes de la siguiente petición y deja que copias concurrentes del mismo evento de autenticación kind 22242 compartan una firma hardware. La versión 0.4.3 admite como máximo un desafío de autenticación distinto por identidad en el worker hardware, nunca reintenta la autenticación internamente y abre un enfriamiento de sesenta segundos por identidad tras un timeout, respondiendo aún a duplicados exactos en caché. Las mediciones de las notas de la versión provienen de un teléfono GrapheneOS conduciendo Amethyst: una ráfaga en arranque en frío produjo treinta y tres respuestas inmediatas de sobrecarga y trece peticiones completadas sin timeouts del firmante, y un inicio de sesión nuevo durante una ráfaga de autenticación volvió 1,254 segundos después de la aprobación.

Citrine 3.1.0 convierte un relay de teléfono en anfitrión de grupos y de sitios

Citrine es un relay Android en el dispositivo. La versión 3.1.0 añade tres capacidades que cambian lo que el relay puede alojar.

El soporte de NIP-29 (grupos gestionados por relays), la especificación de grupos basada en relay donde el propio relay guarda membresía y estado de moderación, significa que un teléfono puede alojar un grupo en lugar de unirse a uno. El soporte de NIP-86 (API de gestión de relays), la API de gestión de relays que expone acciones administrativas por JSON-RPC autenticado, llega con una pantalla de ajustes, así que listas de permitidos y baneos pueden gestionarse desde la API además de desde la app. El soporte de sitios web estáticos de NIP-5A permite al relay servir nsites a clientes web, con una lista de exploración modernizada que incluye iconos, búsqueda, orden por última actualización, progreso de instalación, descripciones y un conjunto configurable de relays para obtenerlos que por defecto es nsite.run, nos.lol y nostr.land.

La superficie de moderación creció en paralelo en la misma versión. Banear una clave pública localmente ahora ofrece purgar los eventos almacenados de ese autor, una lista configurable REJECTED_KINDS bloquea kinds que el operador no quiere almacenar, y el control de acceso puede importar listas existentes. Una herramienta de retransmisión empuja eventos almacenados de nuevo a relays seleccionados, lo que da a un archivo guardado en el teléfono una forma de resembrar la red. La versión también elimina la extensión WebSocket permessage-deflate, aprieta la ruta caliente de consultas, corrige el fallo de Tor al arrancar o detenerse cuando cambia el ajuste de exposición vía Tor, y mueve los registros a una base de datos local con logcat limitado a compilaciones de depuración.

Vector 0.4.2 hace que la moderación comunitaria sobreviva a una ola de spam

Vector es un mensajero Concord de escritorio y Android. La versión 0.4.2 se centra en la moderación bajo carga.

Los baneos rápidos antes se sobrescribían entre sí. Ahora se encolan, se apilan y se resuelven como una sola operación, así que banear una ola de cuentas cuesta una rotación de claves en lugar de una por cuenta. Aceptar una invitación a una comunidad ya disuelta ahora explica por qué y elimina la invitación de todos los dispositivos del usuario, y disolver una comunidad propia la quita de la lista de comunidades en todas partes, una corrección que llegó en la versión 0.4.3. Los mensajes comunitarios que llegan durante una puesta al día en segundo plano ya no suenan notificaciones como si acabasen de enviarse, y el indicador de escritura expira desde el momento del envío para que una señal retrasada no permanezca en un canal.

La lista comunitaria fragmentada definida por Concord pasó una revisión cruzada con Armada, el otro cliente Concord. Los renombres ya no inflan la lista, los empates se resuelven igual en ambos clientes, y los datos sin cambios ya no se republican a relays. Silenciar también salió del camino de mensajes directos: un usuario puede silenciar a alguien directamente desde una comunidad sin historial previo, y el silencio aplica a notificaciones e insignias en canales y mensajes directos dejando visibles los mensajes. Los mensajes fijados pasaron a ser una superficie compartida del canal con enlaces clicables, y las ediciones de un fijado lo siguen donde aparezca. Listas de bloqueo, silencios y apodos ahora se sincronizan entre dispositivos del usuario, al igual que chats fijados. La versión 0.4.3 también deja de anunciar que el usuario escribe cuando otro cliente Nostr está conectado con la misma identidad, y desbloquea el arranque de Tor en Windows, que se había congelado al quince por ciento tanto en x64 como en ARM64.

Sonar trae respuestas en hilo a un mensajero en malla con NIP-C7

Sonar es un mensajero Bluetooth en malla y Nostr. La versión 0.1-alpha.13.1 añade respuestas al estilo Signal en chat NIP-C7 kind 9, más menciones, reensamblado Bluetooth acotado, límites de copia de seguridad, verificación de firma de ruta en malla y respaldo push FCM. Las versiones 0.1-alpha.13.2 y 0.1-alpha.13.3 corrigen cierres al abrir el chat en Android y solapamiento del teclado en iOS.

Nostria empieza a publicar pódcasts y pide a los relays que cuenten

Nostria es un cliente web. Las versiones 4.1.70 y 4.1.71 añaden publicación de pódcasts para suscriptores premium, con episodios como eventos Nostr firmados. La versión 4.1.69 usa COUNT de NIP-45 (consultas de recuento en relays) para totales de reacciones, respuestas y zaps en feeds y completa la localización. La 4.1.67 de la semana pasada amplió la administración de comunidades cifradas.

Versiones

MDK 0.9.14: historial de grupo fail-closed mediante creación de grupos más rápida

MDK es el kit de desarrollo Rust para Marmot, un protocolo de mensajería grupal cifrada transportado sobre Nostr. La versión 0.9.12 hace fail-closed varias rutas de estado de grupo en lugar de adivinar. Un ancla de bifurcación ausente es ahora un error duro (PR #1329), una propuesta de salida se persiste de forma atómica para que un fallo no deje una salida a medias (PR #1360), y la reproducción de incidentes se niega a adivinar un formato en flujos JSON delimitados por saltos de línea sin manifiesto (PR #1140). Las pruebas de convergencia se ampliaron a la vez, con recuperación entre rutas de historial retenido (PR #1350), garantía de convergencia entre adaptadores (PR #1372) y campañas de convergencia aisladas generalizadas (PR #1357). El diagnóstico de rechazo de relay se conserva en lugar de colapsarse en un fallo genérico (PR #1361).

La versión 0.9.13 llegó el 18 de agosto con formato de almacenamiento v2 (PR #1421), raíles de migración y escrituras delta sustituyendo instantáneas de cuenta en vivo (PR #1435), más puesta al día de invitaciones más rápida (PR #1444) y bindings de macOS (PR #1402). La versión 0.9.14 siguió el 19 de agosto con pulido de creación de grupos: imágenes fundacionales pre-subidas (PR #1498), agrupación de KeyPackage (PR #1494), retención atómica del mensaje inicial (PR #1497) y publicación de perfil con relays propios de la cuenta (PR #1495). MarmotKit 0.9.14 y wn-agent 0.9.14 se publican con el crate principal.

Divine Mobile 1.0.20: acuñar una insignia sin salir de la app

Divine Mobile es un cliente de vídeo corto que publica y recupera vídeo a través de Nostr. La versión 1.0.20 permite acuñar una insignia NIP-58 (eventos de premio firmados descritos en el primer análisis en profundidad de este número) y entregarla a alguien sin salir de la app. Tocar una insignia en un perfil explica qué hizo falta para ganarla, la parte de la especificación que suele quedar sin implementar porque el evento de definición y el de premio se almacenan por separado.

El resto de la versión es trabajo de cliente: tema claro, recorte, rotación y volteo en el editor stop-motion, borradores a un toque del grabador, sincronización de subtítulos con el vídeo, un feed que deprioriza material ya visto, soporte de lector de pantalla en editor, grabador y pestañas de perfil, manejo de movimiento reducido, y ajustes de cuenta que gestionan correo y contraseña de Divine y vinculan o desvinculan cuentas. Los vídeos eliminados ya no dejan estado local, y los marcadores persisten. La 1.0.19 de la semana pasada endureció el aislamiento de cuentas y la validación de mensajes privados; la emisión de insignias es una nueva superficie de publicación encima de eso.

ClipRelay 0.2.0: emparejar un firmante con una cámara

ClipRelay sincroniza el portapapeles entre dispositivos sobre Nostr. La versión Android 0.2.0 añade inicio de sesión QR nostrconnect://, para firmar con una app firmante en otro teléfono, y escaneo con cámara de URLs de bunker, eliminando el hábito de pegar una cadena con secreto a través de un mensajero. La conexión bunker ahora agota el tiempo a los sesenta segundos en lugar de colgarse, y el botón de reintento tras un fallo de inicio con Amber funciona. La versión de escritorio 0.2.0 incluye el timeout y las correcciones de la pestaña de inicio de sesión.

La versión 0.1.4 añadió sincronización de portapapeles sensible con caducidad corta en relay, relays de sesión de firmante fijados, y una sonda de vida que exige un ida y vuelta real en lugar de un EOSE sintetizado localmente. La 0.1.3 de la semana pasada restauró conexiones tras periodos de inactividad.

Bark 1.3.9: un firmante de navegador que funciona en Android

Bark es una extensión de navegador que proporciona la interfaz NIP-07 window.nostr, el objeto que una página web invoca para pedir firma u operación de cifrado. La versión 1.3.9 declara soporte Android para la compilación de Firefox, de modo que el listado de complementos se instala en un teléfono. Firefox en Android no implementa la API de ventanas, así que toda aprobación que abría una ventana emergente habría sido denegada de plano; la superficie de aprobación ahora recurre a una pestaña en primer plano donde cerrar deniega, revisar la trae al frente, y el fondo la cierra cuando la petición termina. Las notas de la versión registran verificación en un Pixel 10 Pro XL con GrapheneOS y Firefox 153.0.4, y dejan claro que Chromium en Android compila fuera el subsistema de extensiones, así que ningún navegador Android derivado de Chromium puede ejecutar Bark.

La versión 1.3.8 corrigió un defecto de interoperabilidad NIP-46 en la otra dirección. Bark sondeaba un dialecto compacto de firma Heartwood enviando el evento como objeto JSON, que firmantes estrictamente tipados incluidos nak y bunkers sobre rust-nostr no pueden analizar y descartan en silencio, de modo que la firma se quedaba colgada. La sonda ahora solo se envía a firmantes que se identificaron como Heartwood, y todo otro firmante recibe una llamada estándar sign_event desde la primera firma.

Bray 3.0.0 y Toll Booth 6.0.0 migran a una biblioteca compartida de wallet connect

Bray y Toll Booth pagan ambos mediante NIP-47 Nostr Wallet Connect, la especificación que permite a una aplicación solicitar pagos a un monedero sobre eventos Nostr cifrados. Bray 3.0.0 y Toll Booth 6.0.0 declaran cada uno un cambio incompatible adoptando nwc-kit para pagos con monedero, y Toll Booth elimina su flujo de credenciales del pagador en el mismo cambio. Ambos publican compilaciones reproducibles cuya salida fue idéntica byte a byte en dos ejecutores independientes, con el hash del tarball impreso en las notas de la versión para que un lector pueda verificar el artefacto del registro.

Tres parches de Toll Booth siguieron: 6.0.1 fija la clave de host de despliegue negociada, 6.1.1 fija cashu-ts a la versión que apunta su parche, y 6.1.2 restaura una compilación de imagen.

NoorNote 1.3.4: unirse a comunidades cifradas desde un enlace de invitación

NoorNote es un cliente Nostr para escritorio, web y Android. La versión 1.3.4 añade comunidades cifradas Armada y Concord como complemento: un usuario se une mediante enlace de invitación, ve las comunidades unidas listadas en ajustes, y recibe notificaciones de actividad. La misma versión añade un control para ocultar publicaciones citadas externas, los destacados que citan un párrafo de un artículo web, globalmente o por autor, ocultando también los reposts de ellos y manteniendo visibles los destacados propios. La resolución de perfil también se reparó, de modo que los perfiles ya no se renderizan como clave pública truncada o marcador anónimo.

La versión 1.3.5 añade un expansor para notas largas y corrige el diseño del campo de enlace de invitación Armada. La 1.3.2 de la semana pasada movió el descubrimiento de artículos al grafo social; la membresía comunitaria es una superficie aparte.

Mostro mueve el chat de disputas fuera del gift wrap

Mostro es un daemon de comercio entre pares cuyas órdenes y mensajes viajan como eventos Nostr, con mostro-core como biblioteca compartida y Mostro Mobile como cliente. Mobile 1.3.2 migra el chat de disputas del gift wrap NIP-59 (sobres que ocultan metadatos) a un sobre de chat kind 14 y respalda el backlog con cursores duraderos por conversación. mostro-core 0.14.5 serializa el identificador del rumor dentro del gift wrap (PR #164), 0.14.4 corrige un error de media de valoraciones (PR #163), y Mobile 1.3.1 cambia a servidores Blossom que retienen adjuntos de chat cifrados. Usar daemon 0.18.2 o 0.18.4.

NYM 3.73.522: chats grupales cifrados y almacenamiento local cifrado

NYM es un cliente Nostr con integración propia de asistente. La versión 3.73.522 cifra el almacén SQLite local tras 3.73.521 que refina el chat grupal cifrado, y 3.73.520 corrige una rotura de política de seguridad de contenido y la presentación duplicada de mensajes nuevos.

Morganite 0.0.4: verificar un blob antes de cachearlo

Morganite es un servidor Android Blossom, el protocolo de medios donde un archivo se direcciona por el hash SHA-256 de su contenido y se sirve desde cualquier host que lo tenga. La versión 0.0.4 verifica el hash de un blob durante la descarga en un solo paso antes de cachearlo, la comprobación que hace significativa la dirección por contenido en el lado receptor. La versión también rastrea el tamaño de caché de forma incremental en lugar de reescanear el directorio en cada guardado, mueve llamadas de red bloqueantes a hilos de entrada y salida, reutiliza instancias Tika para detección MIME, y persiste registros en una base de datos local.

Recién descubiertos

Nail lleva el correo a Nostr como eventos gift wrap

Nail es un puente de correo con licencia MIT y cliente web del equipo Formstr, el grupo detrás de Formstr y nostr-calendar. Llegó al lanzamiento el 18 de agosto con PR #7, un cambio de veintidós archivos que añadió etiquetas k a eventos de correo, recuperación de claves en ajustes y un mensaje de bienvenida. Su despliegue corre en mailstr.app, que sirve el propio registro _smtp NIP-05 (esquema DNS que mapea un nombre en un dominio a una clave pública Nostr) del puente.

El correo en sí es un evento Nostr. Las constantes del cliente definen un rumor de correo kind 1301 llevado dentro de un gift wrap NIP-59 kind 1059, de modo que un mensaje llega al destinatario mediante el mismo sobre que oculta metadatos usado para mensajes directos privados. Los relays de entrega provienen de una lista de bandeja de entrada NIP-17 (mensajes directos privados) kind 10050 con una lista de relays NIP-65 kind 10002 detrás, las carpetas son etiquetas NIP-32 (eventos de etiqueta) kind 1985 bajo un espacio de nombres mail, y los ajustes del cliente viven en un evento de datos de aplicación NIP-78 kind 30078. Los adjuntos mayores de 60.000 bytes van a Blossom en lugar de al evento, porque NIP-44 (cifrado) limita el texto plano cifrado a 65.535 bytes. Una dirección es un npub en un dominio, y un dominio local sin registro NIP-05 se trata como un buzón inexistente.

La mitad puente es un servidor LMTP Node que corre junto a un despliegue mailcow sin parchearlo: Postfix enruta dominios coincidentes al puente, y el puente inyecta respuestas de vuelta por SMTP. Ese diseño obliga a una respuesta honesta a la pregunta más dura de un puente de correo: qué demuestra una cabecera From. La ruta de recepción de Nail clasifica cada mensaje en uno de cuatro estados de procedencia: el puente configurado lo selló y se niega a retransmitir un remitente que no verificó upstream, el usuario lo selló él mismo, el registro NIP-05 de la dirección resuelve a la clave selladora, o nada corrobora la cabecera. En ese último caso la interfaz recurre a la clave pública selladora, la única identidad que el evento puede probar de verdad. Las llamadas a la API del puente se autentican con eventos HTTP firmados NIP-98 (autenticación HTTP mediante eventos firmados).

Glow almacena etiquetas de monedero en relays bajo una identidad derivada de passkey

Glow es un monedero Lightning autocustodial de Breez. El inicio de sesión con passkey deriva una identidad Nostr, y las etiquetas del monedero se listan desde relays y se guardan en relays bajo esa identidad, con duplicados idénticos byte a byte colapsados entre cobertura parcial de relays.

En desarrollo

Amethyst reconstruye el flujo de decisión de autenticación con relays

Amethyst es un cliente Nostr Android. Un bloque de trabajo fusionado remodela cómo maneja la autenticación cliente-relay NIP-42. La interfaz de permisos y el flujo de decisión se rediseñaron (PR #3899), la autenticación ahora espera a que un desafío se resuelva en lugar de agotar el tiempo (PR #3905), las cuentas nuevas autentican por defecto siempre con relays (PR #3931), y una opción de «iniciar sesión siempre» se honra para relays que la cuenta no usa (PR #3937). La autenticación también reconoce grupos NIP-29 y comunidades Concord como espacios unidos (PR #3906), lo que evita que un grupo alojado en relay parezca un relay desconocido cada vez que se abre.

Dos cambios más tocan superficies de protocolo. La minería de prueba de trabajo bajo NIP-13 (nonce PoW) actualiza created_at mientras mina y gana un análisis de ruta GPU (PR #3911), y los hosts de napplet a pantalla completa manejan insets del método de entrada (PR #3932). Una copia de seguridad guiada de claves en el primer arranque con entrada en ajustes también se fusionó (PR #3909), junto a la capacidad de silenciar chats públicos (PR #3939).

nostrord implementa una propuesta no fusionada de clave de cifrado

nostrord es un cliente de chat Nostr organizado en torno a grupos acotados por relay. Fusionó una implementación de NIP-4e, una propuesta no fusionada para desacoplar el cifrado de mensajes de la clave de identidad que Compass describió por última vez en el número del 15 de julio. La cuenta anuncia su propia clave de cifrado kind 10044, guarda la mitad privada localmente y descifra mensajes directos entrantes en proceso, sacando un bunker o extensión de navegador del camino de lectura por completo (PR #261). El emparejamiento de dispositivos sobre kinds 4454 y 4455 mueve esa clave a un segundo dispositivo, y un autoarchivo republica historial dirigido a la nueva clave. El envío se dirigió primero a la clave anunciada (PR #247), y un seguimiento corrigió emparejamiento que negoció con éxito sin entregar la clave (PR #271). El pull request indica que el formato en wire sigue la implementación desplegada de Jumble donde diverge de la propuesta abierta, lo que sitúa la definición operativa de esta especificación en código publicado en lugar del documento.

La identidad de grupo se apretó en el mismo lote. Un identificador de grupo es ahora único solo dentro de su relay (PR #269), así que el mismo identificador en dos relays se trata como dos grupos (PR #272), y las publicaciones de hilo se renderizan como publicaciones de foro (PR #274). El churn de conexión que producía repetidas solicitudes de firma kind 22242 también se detuvo (PR #268), la misma clase de presión sobre el firmante en la que Cambium trabajó tres versiones esta semana.

nostream añade un monitor de relay y acuña códigos de invitación

nostream es una implementación de relay en TypeScript. Fusionó un worker de clúster y planificador de sondas que publican eventos de monitorización de relay NIP-66 (especificación de descubrimiento que permite a un monitor anunciar datos de vida y capacidad sobre otros relays) (PR #724), con esquema de ajustes y valores por defecto (PR #689) y pruebas de integración (PR #733). Una herramienta de línea de comandos ahora acuña códigos de invitación NIP-43 (esquema de metadatos de acceso a relay) (PR #732), y el relay por fin anuncia prueba de trabajo NIP-13 en su lista de soportados (PR #680), que ya había implementado sin anunciar. Los trabajos de máquinas expendedoras de datos también ganaron migración de persistencia y repositorio (PR #727), y el relay ahora atrapa peticiones de trabajo NIP-90 (peticiones de trabajo de máquinas expendedoras de datos) y las registra por el repositorio de trabajos (PR #729).

rust-nostr corrige un identificador de gift wrap y rechaza reposts protegidos

rust-nostr es la biblioteca Rust y kit de desarrollo detrás de gran parte del trabajo de clientes Rust y móviles de este número. Ahora asegura que el identificador del rumor se calcula antes de cifrar el sello del gift wrap (PR #1444), la misma clase de defecto que Mostro corrigió en su propia biblioteca esta semana. Su relay local rechaza un repost de un evento protegido NIP-70 (PR #1445), la protección para la que existe esa especificación, y el análisis de respuestas NIP-47 tolera importes ausentes y nulos (PR #1450) en lugar de fallar con un monedero que los omite. El análisis de URL de relay se endureció (PR #1451).

NDK añade mensajes directos poscuánticos y elimina una dependencia GPL

NDK es un kit de desarrollo Dart para Nostr. Fusionó cifrado poscuántico híbrido para mensajes directos usando ML-KEM-1024, el mecanismo de encapsulación de claves reticular estandarizado como FIPS 203 (PR #713), colocándolo junto al acuerdo de claves clásico en lugar de en su lugar. Un cambio aparte sustituyó una implementación Dilithium solo GPL-3.0 por fips204, el estándar de firma ML-DSA (PR #712), lo que elimina una restricción de licencia para aplicaciones que incrustan el kit. Las conexiones también pasaron a una identidad cada una (PR #710).

Nostter añade listas de marcadores, insignias de perfil y subidas Blossom

Nostter es un cliente web. Fusionó soporte para las formas estándar y heredadas de listas de marcadores NIP-51 (PR #2311), actualizó su manejo de insignias de perfil NIP-58 (PR #2281), añadió un cargador de medios Blossom (PR #2298), y ahora muestra un identificador NIP-05 (nombre de verificación DNS) en el autocompletado de menciones (PR #2303).

Zap Cooking ata rutas de administración a peticiones firmadas y cifra conexiones de monedero almacenadas

Zap Cooking es un sitio de recetas construido sobre eventos Nostr de formato largo. Un lote de seguridad cifra cadenas de conexión Nostr Wallet Connect almacenadas en reposo dentro de un sobre NIP-44 (PR #622), sustituye una comparación falsificable de clave pública en rutas administrativas por autenticación HTTP NIP-98 (esquema que firma un evento para autorizar una petición HTTP) (PR #626), y borra datos de cuenta al cerrar sesión acotando registros NIP-46 pendientes (PR #627).

Actualizaciones de NIPs y trabajo de especificación del protocolo

NIPs

Ningún pull request se fusionó en nostr-protocol/nips durante esta ventana. Se abrieron seis propuestas tras cerrarse el número anterior, tres de ellas el 18 de agosto después de que el borrador circulara por primera vez.

NIPs PR #2438 propone NIP-9A, parcheo basado en comentarios. Un parche es un comentario kind 1111 que referencia el evento parcheado como padre cuyo content comienza con la etiqueta literal PATCH, seguida de líneas de parche. Una línea que comienza con un número edita el content del objetivo en la forma <index> -<deleted> +<inserted> <caracteres insertados>, contados en caracteres unicode en lugar de bytes, y una línea que comienza con t sustituye una etiqueta legible por humanos como title, description, subject o picture. El diseño es deliberadamente retrocompatible: un cliente que no entiende el formato muestra el parche como un comentario etiquetado ordinario, y un cliente que sí lo entiende aplica el parche y oculta el comentario. La propuesta nombra kinds 1, 11, 1111, 24 y 1621 como parcheables y pide a escritores y lectores rechazar parches demasiado grandes, demasiado numerosos o publicados mucho después del evento original, un intento explícito de evitar que la función se convierta en un canal general de edición para eventos inmutables.

NIPs PR #2437 propone cifrado de archivos para NIP-94, la especificación de metadatos de archivo que describe un archivo subido en un evento kind 1063. Añade tres etiquetas opcionales: encryption-algorithm, con aes-gcm como único valor listado, más decryption-key y decryption-nonce codificados en hex. La semántica de etiquetas cambia en consecuencia, con m describiendo el tipo MIME antes del cifrado, x guardando el hash del archivo cifrado, y ox el hash del original, y cualquier fuente thumb, image y fallback cifrada bajo la misma clave y nonce. El propósito declarado es que un operador Blossom público que aloja los bytes no pueda decir qué son, y el autor enmarca el cambio como copiar las propiedades de cifrado de mensajes directos NIP-17 en metadatos de archivo para que el mismo tratamiento funcione dentro de una etiqueta imeta.

NIPs PR #2436 enmienda NIP-7D, la especificación de hilos de foro construida sobre eventos de hilo kind 11 con comentarios NIP-22 kind 1111 como respuestas. Añade una sección de formato que indica que una publicación de hilo puede formatearse como una nota kind 1, con imágenes en línea, enlaces y referencias NIP-27 (referencias de texto), y también podría soportar Djot, un lenguaje de marcado ligero con gramática inequívoca. El argumento del autor es que dejar el formato sin especificar invita a una implementación Markdown por defecto eventual, y el pull request señala a squalk como implementación Djot existente.

NIPs PR #2439 añade métodos assign y unassign a NIP-86 (comandos de gestión de relay), de modo que un administrador de relay pueda conceder permisos de administración a otra pubkey sin compartir la clave maestra.

NIPs PR #2442 sucede la propuesta de pistas de audio que Compass cubrió en enero mientras ese borrador permanecía abierto; el pull request anterior se ha cerrado desde entonces y este se publica en producción en lightning.fm como eventos de pista kind 31337, con objetos de lanzamiento kind 31339, perfiles de banda, colaboradores por pista, y repartos opcionales de zap NIP-57 manteniendo ventas en NIP-99. El contrato de interoperabilidad está publicado en lightning.fm/interop, y el editor de escritorio y el daemon de vendedor autoalojado son código abierto.

Marmot

Marmot PR #416 se fusionó el 13 de agosto y añade un contrato de durabilidad y reinicio al núcleo del protocolo. Los documentos adoptados ya definían convergencia determinista, material retenido de padre candidato, orden publicar-antes-de-aplicar, y comportamiento fail-closed ante historial ausente, sin una regla inequívoca sobre qué ocurre cuando un proceso se interrumpe en las costuras entre ellos. El cambio define hechos lógicos recuperables, equivalencia de reinicio, límites de interrupción de publicación y convergencia, transiciones atómicas para observadores, manejo de material ausente o corrupto, y recuperación de efecto de aplicación, y añade escenarios de conformidad de fallo y reinicio para cada uno. Deja transacciones, diarios, instantáneas, estrategia de reproducción, planificadores y formatos de almacenamiento definidos por implementación, y declara que no requiere cambio de codificación en wire. El fallo específico que cierra es una publicación aceptada externamente pero no confirmada localmente, o una rama seleccionada aplicada parcialmente, produciendo resultados de protocolo dependientes de implementación tras un reinicio.

Concord y CORDs

Concord PR #18, cubierto previamente en el número de la semana pasada como propuesta abierta, se fusionó el 15 de agosto. Fragmenta la lista comunitaria cifrada entre eventos kind 33302, elimina el límite de cincuenta membresías, y poda entradas retiradas para mantener la lista dentro de límites de tamaño de relay. Las notas de la versión de Vector esta semana registran la mitad del cliente de ese cambio, incluida resolución de empates y la decisión de dejar de republicar datos sin cambios.

Concord PR #22 propone brokers de audio y vídeo propiedad de la comunidad. La entidad de metadatos CORD-02 llevaría una lista opcional av_brokers junto a sus relays, evolucionando por edición como el resto de esa entidad, y el rendezvous CORD-07 tomaría de esa lista, o del broker propio del miembro cuando la comunidad no publica ninguno, ordenado por el desempate existente por clave de sala. La etiqueta broker en presencia sigue siendo legible y útil para informar una división residual, y el argumento de la propuesta para degradarla del enrutamiento es directo: enrutar sobre ella deja que la entrada no confiable de un compañero miembro supere la instrucción propia de la comunidad.

Concord PR #23 hace normativo un comportamiento de implementación existente en CORD-05. Antes de persistir una unión, la edición de metadatos génesis del propietario debe abrir bajo las claves entregadas, con planos rotados anclados en el par de compactación. El pull request declara de entrada que esto nunca fue una vulnerabilidad en vivo: la aceptación de paquetes de Vector ya rechaza un paquete cuya raíz entregada no puede abrir el génesis del propietario y nunca aparca una invitación para una comunidad ya retenida, y Armada ya descarta cualquier paquete que movería la base de una comunidad retenida. La brecha era que ningún comportamiento estaba exigido por la especificación, así que un cliente fiel a la especificación podría haber publicado la versión vulnerable.

Los documentos de actualización de Blossom, las propuestas de aplicación Napplet y la especificación Gamma Markets no registraron cambios en esta ventana.

Análisis en profundidad de NIPs

Insignias (NIP-58)

NIP-58, definido por su especificación principal, da a una identidad Nostr una forma de otorgar un token con nombre a otra, y da al destinatario control sobre si aparece en su perfil. El problema que aborda es que cualquier afirmación sobre una persona en Nostr es de otro modo solo una nota: no hay estructura que diga quién emitió una reclamación, cómo se llama, cómo se ve, o si el sujeto la aceptó. Las insignias dan a esa reclamación tres eventos firmados separados con tres intenciones de autor separadas codificadas en ellos.

La mecánica se construye a partir de una definición direccionable, un premio y una lista de visualización. Una definición de insignia es un evento kind 30009 publicado por el emisor, direccionable mediante su etiqueta d, de modo que el emisor puede revisar después las etiquetas name, description, image y thumb de la insignia sin cambiar el identificador al que apunta cualquier otra cosa. El premio es un evento kind 8 publicado por el mismo emisor, llevando una etiqueta a con la coordenada 30009:<issuer-pubkey>:<d-identifier> de la definición y una o más etiquetas p nombrando destinatarios. La lista de visualización es un evento kind 30008 publicado por el destinatario con el valor fijo d profile_badges, listando pares de etiquetas a y e donde la etiqueta a es la coordenada de definición y la etiqueta e es el evento de premio concreto. Esos pares están ordenados y se leen como pares: una etiqueta a cuyo premio coincidente falta, o una etiqueta e cuya definición coincidente falta, se ignora, así que una insignia referenciada a medias no se renderiza en silencio.

Los compromisos de diseño son visibles en lo que la especificación se niega a hacer. No hay mecanismo de revocación ni caducidad, así que un premio es una declaración permanente del emisor sobre un momento en el tiempo, y un emisor que cambia de opinión solo puede cambiar la definición a la que apunta el premio. No hay transferencia, así que una insignia no circula como token. No hay noción de registro de emisores de confianza, lo que empuja toda la pregunta de confianza al cliente y al lector: una insignia vale exactamente lo que la clave pública del emisor vale para quien la mira. La especificación también concede a los clientes libertad para mostrar menos insignias de las que listó el destinatario y elegir qué tamaño de imagen renderizar, lo que evita que un perfil se convierta en un muro de gráficos elegidos enteramente por terceros.

La especificación adyacente más cercana es NIP-51, la especificación de listas, y comparar las dos muestra por qué las insignias necesitan tres eventos en lugar de uno. Una lista es un solo autor curando referencias; el autor de la lista es el autor de la reclamación. Una insignia divide la autoría por la mitad, con el emisor firmando que ocurrió el premio y el destinatario firmando que acepta su visualización. Ninguna parte puede producir sola el resultado visible, lo que separa una insignia de una etiqueta autoaplicada.

Un premio kind 8 en vivo recuperado de nos.lol y relay.primal.net esta semana:

{
 "id": "08504dec368939bd63849a349cab83dea0ac199a852129dbf68cf35fe5c64e96",
 "pubkey": "bef514bd58c8ceea4beb9e6b84a8d983935f7be26f49e14df68098f1ba64156e",
 "created_at": 1787051248,
 "kind": 8,
 "tags": [
 ["a", "30009:bef514bd58c8ceea4beb9e6b84a8d983935f7be26f49e14df68098f1ba64156e:blocks_orange_league"],
 ["p", "92dfa05d915196a7a09152fa3f57871debfd422e1d278ac5af266a70c3350b1f", "wss://relay.damus.io"]
 ],
 "content": "Badge awarded!",
 "sig": "5bf0218dfec5e56b47339b0b4b992cceedd2e18798fb3d47cafea51850c00827f66251e4a3e08190370e04a5e1d4d092eeb441141b7219acdd18b80290a022f8"
}

Las implementaciones actuales cubren emisión, visualización y lectura. Divine Mobile 1.0.20 acuña y otorga una insignia dentro de la app y explica una insignia ganada cuando un lector la toca, Nostter PR #2281 actualiza el manejo de insignias de perfil en un cliente web, y Amethyst publica eventos de premio llevando su propia etiqueta de cliente, uno de los cuales aparece en datos de relay junto al ejemplo anterior.

Comentarios (NIP-22)

NIP-22, definido por su especificación principal, proporciona un evento de comentario general para responder a cosas que no son notas de texto corto. El hilado de notas cortas ya tenía NIP-10 (convenciones de etiquetas de respuesta), cuyas convenciones de etiquetas crecieron alrededor de kind 1 y sus cadenas de respuesta. NIP-22 existe porque un vídeo, un artículo, un evento de calendario, una página wiki o una URL necesita una estructura de respuesta que identifique qué tipo de cosa se está respondiendo, y que funcione cuando el objetivo es direccionable, o es un recurso externo sin evento Nostr alguno.

La mecánica gira en torno a una distinción de mayúsculas. Un comentario es un evento kind 1111 que lleva dos conjuntos de etiquetas: etiquetas en mayúsculas describen la raíz de la discusión y etiquetas en minúsculas describen el padre inmediato. E, A e I nombran un evento raíz, una coordenada direccionable raíz o un identificador externo raíz, K nombra el kind de la raíz, y P nombra al autor de la raíz. Las variantes en minúsculas e, a, i, k y p nombran los mismos hechos sobre el padre, que es la raíz misma para un comentario de nivel superior y otro comentario kind 1111 para una respuesta anidada. Separarlas significa que un cliente puede obtener toda una discusión con un filtro sobre las etiquetas raíz en mayúsculas, sin recorrer la cadena de respuestas, mientras renderiza correctamente el anidamiento desde las etiquetas padre en minúsculas. Las variantes I e i llevan identificadores externos en el formato NIP-73 (referencias de contenido externo), lo que permite que un hilo de comentarios se adjunte a una página web, un episodio de pódcast o un libro.

Los compromisos son sobre todo lo que NIP-22 declina absorber. La especificación indica que los comentarios no deben usarse para responder a notas kind 1, lo que evita que dos modelos de hilado compitan sobre los mismos objetos y deja NIP-10 donde ya funciona. El anidamiento está permitido pero la raíz permanece fija, así que un hilo profundo nunca pierde su ancla aunque falten eventos intermedios. Las etiquetas de kind son la parte que soporta la carga: un cliente que obtiene un comentario sin su objetivo aún puede decir a qué se enfrenta desde K y k, y decidir si puede renderizar ese kind. Lo que la especificación no proporciona es ningún modelo de orden o moderación, así que el orden de visualización, colapso y ocultación son enteramente política del cliente.

Comparado con NIP-10, la diferencia está en el tipado. NIP-10 asume que el objetivo es una nota y codifica posición en un hilo; NIP-22 codifica explícitamente la identidad y el kind del objetivo y no asume nada más sobre él. Ese tipado explícito es por qué las propuestas más recientes de este número recurren a kind 1111: un comentario ya lleva una declaración legible por máquina sobre a qué está adjunto.

Un comentario kind 1111 en vivo recuperado de nos.lol y relay.primal.net esta semana, respondiendo a otro comentario bajo un vídeo:

{
 "id": "c8d335f8bfea58ecd1a943d6000fb2045f4bddf4a36c67df53eb661671f7ab45",
 "pubkey": "3e911baba55ae247339cf805dd6ff49ad2cd6bee84ac44e088ce66450c49104f",
 "created_at": 1787062681,
 "kind": 1111,
 "tags": [
 ["E", "1c492f2bac17b79d66934a340fa43d8d30d0aea4c9fa329346c05573ef912d70", "", "482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839"],
 ["A", "34236:482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839:e64ba9ea157b1a315caff51dbca656ed73ce817d4494e3966adf24055a86f5c5", ""],
 ["K", "34236"],
 ["P", "482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839"],
 ["e", "7a14723b9ef999e74b1757a0fb74942cb6c121138d4ddafe096a57a67ed0a442", "", "8b69e548402afa997343d73e8088224a440f256350f6257b61acc4bb1fa4af4f"],
 ["k", "1111"],
 ["p", "8b69e548402afa997343d73e8088224a440f256350f6257b61acc4bb1fa4af4f"],
 ["client", "Divine", "31990:d95aa8fc0eff8e488952495b8064991d27fb96ed8652f12cdedc5a4e8b5ae540:divine-mobile", "wss://relay.divine.video"]
 ],
 "content": "niiice",
 "sig": "a5517fdea07647efa7ab1730fbea8df882690bba667e93ea5aeba4a73be6a49af1ee17c045535483650caf41dbbcb0897d5803fa39b59f395fd6f9bb193bb789"
}

Las etiquetas en mayúsculas guardan el vídeo y su autor mientras las e y k en minúsculas apuntan al comentario padre, que es la forma que describe la especificación. Las implementaciones que leen y escriben kind 1111 incluyen Divine Mobile, cuya etiqueta de cliente aparece en el evento anterior, Amethyst, cuyos comentarios aparecen en los mismos resultados de relay, y nostrord, que renderiza publicaciones de hilo como publicaciones de foro esta semana. El formato de parche propuesto en NIPs PR #2438 se construye sobre el mismo kind.

Envía un DM NIP-17 (mensajes directos privados) para compartir un proyecto o una noticia a través del proyecto Nostr Compass.

Nostr Compass #35

Wed, 12 Aug 2026 00:00:00 +0000

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

Esta semana: nostr-wot-extension añade claves poscuánticas y mensajes protegidos opcionales junto a identidades de Nostr existentes. Divine refuerza el aislamiento de cuentas, la validación de mensajes privados y la confirmación de publicación; MDK fortalece la convergencia y recuperación de grupos cifrados; y Amber hace explícitas las decisiones de firma agrupadas. Las versiones mejoran las conexiones de monedero, el chat cifrado, el descubrimiento social, la sincronización entre dispositivos y la firma remota, mientras que el trabajo de protocolo abarca identidad y comunidades cifradas. Los análisis en profundidad explican las solicitudes de borrado autenticadas y las denuncias descentralizadas.

Historias Principales

nostr-wot-extension 0.4.0 añade claves poscuánticas junto a una identidad de Nostr

nostr-wot-extension 0.4.0 es una extensión de navegador para gestionar identidades de Nostr y firmar. Las cuentas creadas a partir de una semilla de 24 palabras pueden derivar ahora claves de cifrado ML-KEM-1024 y de firma ML-DSA-87 junto a su clave de Nostr existente. Un flujo de un clic publica una atestación de kind 10203 que vincula la pubkey de Nostr con ambas pubkeys poscuánticas e incluye una prueba de posesión ML-DSA. Las cuentas importadas desde un mnemónico de 12 palabras, un nsec sin envoltorio, un firmante remoto o una clave de solo lectura no pueden usar el flujo de derivación, y la extensión explica esa limitación en la vista de cuenta.

La versión también añade mensajes directos poscuánticos opcionales. Combina el secreto compartido ML-KEM con la clave de conversación cifrada de NIP-44 existente mediante HKDF, y mantiene las capas normales de gift-wrap de NIP-59 (envolturas que ocultan metadatos) para la entrega por relay. El cifrado nunca recurre silenciosamente a un camino anterior después de que el destinatario opte por el nuevo, mientras que el descifrado selecciona automáticamente la ruta adecuada. Esto protege la nueva ruta de mensajes frente a una recuperación posterior de una clave privada de Nostr actual, pero no sustituye las firmas de eventos secp256k1; la versión deja explícitamente esa migración mayor para una futura coordinación con relays y clientes.

Divine Mobile 1.0.19 refuerza cuentas, mensajes privados y publicación

Divine Mobile 1.0.19 es un cliente móvil de vídeo corto que publica y recupera vídeos a través de Nostr. Su selector de cuentas construye ahora cada identidad iniciada en torno a un contenedor con alcance de cuenta, y una corrección de publicación evita que un vídeo se envíe bajo la cuenta equivocada. Las rutas de publicación en relay esperan ahora una respuesta OK con semántica explícita de éxito, mientras que un frame CLOSED del relay puede terminar su propia consulta pendiente en lugar de dejar la petición colgada.

El manejo de mensajes privados rechaza campos rumor no autenticados y sellos sin firmar, restaura cuatro casos de mensajes faltantes y enruta las conversaciones de grupo de participantes totalmente seguidos hacia la bandeja de entrada. La versión también conserva las tags de eventos de vídeo direccionables cuando se actualizan las listas y consume las solicitudes de borrado observadas para que los vídeos eliminados desaparezcan del estado local. Esos cambios siguen al trabajo de tiempo de espera por consulta de relay cubierto la semana pasada, pero desplazan el foco del aislamiento de recuperación hacia los límites de identidad, la validación de mensajes y la confirmación de publicación.

MDK 0.9.11 refuerza la convergencia y recuperación de grupos Marmot

MDK 0.9.11 es un kit de desarrollo en Rust para Marmot, un protocolo de mensajería de grupo cifrada transportado sobre Nostr. La versión construye un sistema mayor de convergencia y recuperación en torno a la máquina de estados del grupo: los pasos de convergencia obsoletos se reabren en la punta actual del grupo, las proyecciones de capacidad entrantes se confirman de forma atómica, los mensajes diferidos reciben vidas acotadas entre reinicios, y los puntos de control direccionados por commit ayudan a recuperar las propias bifurcaciones de commit de una identidad. Los envíos no estables pueden encolarse y recuperarse, mientras que una ruta de estancamiento de época escala a backfill y los mensajes enviados sobreviven al trabajo de convergencia.

El almacenamiento y las integraciones de host reciben un refuerzo paralelo. MDK elimina de forma segura las proyecciones SQLite podadas, pone a cero las claves privadas importadas, los intermedios de exportación de claves cifradas NIP-49 y los búferes de serialización OpenMLS, y redacta las claves de imagen de grupo de la salida de depuración. La importación de cuentas puede reanudarse tras una interrupción, se reparan las rutas de almacenamiento privado en iOS y Android, y los hosts pueden cerrar explícitamente el almacenamiento antes de la suspensión. Nuevas proyecciones ligeras de roster y membresía local reducen lo que las aplicaciones deben leer, mientras que el conector Hermes puede entregar varias imágenes generadas por agentes como un álbum Marmot.

Nostria 4.1.67 amplía la administración de comunidades cifradas

Nostria 4.1.67 es un cliente social web y de escritorio para Nostr. Se apoya en los grupos gestionados por relays experimentales de NIP-29 (grupos gestionados por relays) y las comunidades cifradas Concord introducidas en 4.1.53, añadiendo disolución de comunidad, administración de icono y banner, subidas de fotos cifradas con vistas previas comprimidas, un selector completo de reacciones y un diseño de doble panel que mantiene una comunidad abierta mientras el usuario lee notas o artículos. La versión también añade mensajería en hilos y un hub combinado para chats públicos, de grupo y privados.

Amber 6.4.0 hace explícita cada decisión de firma agrupada

Amber 6.4.0 es un firmante Android que mantiene las claves privadas de Nostr separadas de las aplicaciones que solicitan firmas. Su pantalla rediseñada de solicitudes múltiples ofrece controles Aprobar y Denegar para cada petición y cada grupo, sustituyendo al flujo anterior de selección y confirmación. Las solicitudes denegadas enviadas a través de la interfaz bunker mediada por relay de Amber reciben ahora respuestas de error adecuadas, de modo que el cliente solicitante puede distinguir un rechazo de un firmante estancado.

El código etiquetado de Amber también añade etiquetas localizadas y legibles para 113 kinds de evento más en cada locale publicado. Las adiciones incluyen eventos de grupo Concord, marcadores de repositorio Git de NIP-51 (listas curadas de eventos) y eventos de presencia en sala de NIP-53 (actividades en vivo), dando a los usuarios más contexto sobre datos desconocidos antes de aprobar una firma. Una guarda de mapa concurrente también corrige un fallo de suscripción a relay que podía producir un NegativeArraySizeException.

Safebox Acorn separa un componente de recuperación portátil de la aplicación web

Safebox Acorn es un componente Python independiente y una interfaz de línea de comandos para salvaguardar claves, fondos y registros controlados por el usuario con estado respaldado por Nostr. Extraer Acorn de la aplicación web Safebox más amplia permite a otro proyecto Python instalar el runtime y usar sus ayudantes de clave, perfil de Nostr, relay, registro, Cashu, Lightning y criptografía sin asumir la interfaz web. Sus primitivas actuales de protección de registros pueden generar una clave fresca de 256 bits, derivar una a partir de entropía suministrada por separado, y codificar la clave exacta como una frase de recuperación de 24 palabras con suma de comprobación.

La guía de recuperación y continuidad del proyecto enmarca Acorn como el componente de protocolo reemplazable dentro de un Safebox doméstico o comunitario. El diseño mantiene el estado cifrado disponible a través de un relay local y réplicas independientes para que la recuperación no dependa de un solo dispositivo, aplicación, relay, mint o proveedor de servicio. La documentación es cuidadosa con el límite actual: el cifrado de registros protegidos sigue en diseño, por lo que las aplicaciones no deberían hacer depender los registros de la nueva clave de protección de registros hasta que ese perfil se haya implementado y revisado.

Versiones

Mostro Core 0.14.2 cambia el sobre del chat cifrado

Mostro Core es la biblioteca Rust de tipos compartidos y funciones entre pares usada por el daemon de intercambio Mostro y sus clientes. La versión 0.14.2 sustituye los mensajes de chat gift-wrap por sobres de kind 14 que usan claves separadas de cifrado de conversación y de firma derivadas del secreto compartido de los pares. El nuevo lector valida el autor, la firma, el destinatario, la marca temporal y el tamaño del contenido, mientras que los ayudantes legacy de gift-wrap siguen disponibles para que los clientes puedan leer ambos formatos durante la migración.

Mostro 0.18.1 inicia una ruta de escrow Cashu y refuerza el daemon

Mostro es un daemon de intercambio Lightning entre pares que coordina órdenes a través de Nostr. La versión 0.18.1 sienta las bases de un backend de escrow Cashu, incluyendo configuración, ayudantes de base de datos, integración con mint, cableado de arranque y la primera acción de bloqueo. También puede usar precios anunciados por un nodo de confianza sobre Nostr y anuncia requisitos de prueba de trabajo para el primer contacto en su evento de información reemplazable. La versión actualiza su dependencia de Nostr por una corrección de denegación de servicio de NIP-44, elimina claves privadas de los registros de sesión de restauración, rechaza mensajes de cancelación cooperativa no autorizados, refuerza las obtenciones LNURL contra falsificación de peticiones del lado del servidor y bloqueos, valida facturas de pago y restaura las suscripciones a facturas retenidas tras un reinicio.

LaWallet NWC 2.3.0 añade notificaciones de Nostr y recibos de zap

LaWallet NWC es una plataforma Lightning Address de código abierto que conecta monederos a través de Nostr Wallet Connect (conexión de monedero por Nostr). La versión 2.3.0 permite a cada monedero enviar notificaciones de recibidos y reenviados como eventos de Nostr configurables, incluyendo una tag p del destinatario, relays seleccionados, contenido con plantilla y cifrado opcional de NIP-44 (cifrado de mensajes); los reintentos reutilizan el mismo ID de evento firmado. También acepta solicitudes de zap y publica recibos firmados de kind 9735 de NIP-57 (zaps) tras la liquidación, mientras que una nueva vista de capacidades de dirección muestra si la dirección resuelta admite NIP-05, NIP-57 y protocolos Lightning Address relacionados.

nostr-double-ratchet TypeScript 0.0.166 vincula invitaciones públicas a claves de sesión

nostr-double-ratchet proporciona primitivas TypeScript y Rust para mensajería directa y de grupo cifrada de extremo a extremo sobre relays de Nostr. TypeScript 0.0.166 exige que una respuesta a invitación demuestre la propiedad de su clave de sesión, evitando que una invitación pública reutilizable vincule una identidad de Nostr a la sesión de otra parte. La versión también rechaza campos rumor malformados y refuerza la validación de cargas; las sesiones existentes siguen funcionando, pero un invitador actualizado rechaza respuestas sin prueba de invitados antiguos.

cln-nip47 0.2.0 amplía y aísla las peticiones NWC

cln-nip47 es un plugin de Core Lightning que expone un nodo a monederos a través de Nostr Wallet Connect (conexión de monedero por Nostr). La versión 0.2.0 añade métodos NWC para crear, cancelar y liquidar facturas retenidas más una notificación hold_invoice_accepted, y anuncia el conjunto de métodos que el nodo conectado admite realmente. Las respuestas de lista de transacciones se detienen ahora en 500 entradas y unos 128 kB, los eventos de petición se desduplican por ID de evento, y la notificación fallida de un cliente ya no impide la entrega a otros clientes. La versión también elimina los dos métodos de multipago que ya no forman parte de la especificación NWC.

ClipRelay 0.1.3 restaura las conexiones de relay y firmante tras periodos de inactividad

ClipRelay sincroniza el portapapeles de un usuario entre dispositivos a través de relays de Nostr, cifrando el contenido hacia la misma identidad con NIP-44 (cifrado de mensajes). Las versiones de escritorio y Android 0.1.3 correspondientes añaden un cuadro de texto para enviar texto escrito directamente al portapapeles de otro dispositivo. También prueban la actividad con idas y vueltas reales al relay tras periodos de inactividad, escalando desde la resuscripción hasta la sustitución del socket y un pool de conexiones reconstruido, mientras que las llamadas estancadas al firmante NIP-46 (firma remota mediada por relays) agotan ahora el tiempo de espera y se reconstruyen automáticamente.

NoorNote es un cliente de Nostr para publicaciones sociales, mensajes cifrados, artículos de formato largo y otros tipos de evento en web, escritorio y Android. La versión 1.3.2 sustituye su feed global plano de artículos por descubrimiento extraído de contactos de primer, segundo y tercer grado, ofreciendo a los lectores una línea temporal de artículos arraigada en su grafo de seguimiento. También colapsa ráfagas de mensajes directos reproducidos de remitentes desconocidos en una sola notificación continua en lugar de producir una pila de avisos a medida que llega el historial del relay.

Bray 2.4.0 añade un dialecto compacto de firma remota

Bray es un servidor MCP de Nostr que ofrece a agentes de software y personas herramientas para acceso a relays, identidad, publicación y firma remota. La versión 2.4.0 acepta una solicitud de firma cuyo evento es un objeto además de la forma serializada en cadena usada por NIP-46 (firma remota mediada por relays), y añade sign_event_compact, que devuelve solo el ID del evento, la firma, la pubkey y la marca temporal. Ese formato de petición y respuesta más pequeño reduce el uso de memoria para firmantes de hardware restringidos, mientras que el flujo estándar sign_event permanece sin cambios y ambos dialectos producen una firma sobre el ID del evento recibido.

Recién descubiertos

Pact aporta vínculos de agentes con consentimiento mutuo a Nostr

Pact, descubierto esta semana, es una capa de relaciones en fase temprana para agentes de software construida sobre MATE.md y un transporte borrador NIP-BD. Sus vínculos firmados con consentimiento mutuo los retienen las propias claves de los agentes y pueden publicarse sobre Nostr, mientras que los vínculos privados usan gift-wrap de NIP-59 (envolturas que ocultan metadatos). El monorepo incluye un servidor MCP, SDK TypeScript, cliente de línea de comandos, daemon autoalojable e interfaz web. Su actividad más reciente en el repositorio es anterior a la ventana semanal de este número, por lo que esto es una nota de descubrimiento y no una afirmación de nueva versión.

Cambios sin publicar

nostrord mantiene sincronizado el silenciamiento de grupos entre dispositivos

nostrord es un cliente multiplataforma para comunidades gestionadas por relays. El PR #250 almacena las elecciones de silenciamiento por grupo de cada cuenta en un evento autocifrado de kind 30078 de NIP-78 (datos específicos de aplicación), de modo que un ajuste hecho en un dispositivo puede seguir al usuario a otro sin revelar la lista de grupos al relay. El registro reemplazable usa ordenación por evento más reciente, escucha cambios en vivo y revierte la interfaz cuando falla la firma o la publicación en lugar de dejar el estado local desincronizado. Los grupos silenciados también dejan de contribuir totales de no leídos visibles mientras conservan su posición de no leído para la próxima visita.

Amethyst completa el ciclo de vida de invitaciones de Concord

Amethyst es un cliente Android de Nostr cuyo soporte de comunidades cifradas implementa el protocolo Concord. El PR #3888 permite que los enlaces de invitación sobrevivan a un refounding de comunidad reemitiendo sus paquetes en las mismas coordenadas direccionables, mientras que una comprobación de expulsión impide que un miembro eliminado use esa ruta de recuperación. También implementa la lista de invitaciones cifrada CORD-05 tanto en la aplicación como en el cliente de línea de comandos amy, añade lápidas de revocación por enlace, y exige confirmación del relay antes de eliminar la única clave de firma almacenada que puede retirar un enlace. El mismo trabajo dota a amy de las rutas de entrega de clave de control, refounding, rekeying y recuperación de miembros aislados necesarias para seguir épocas comunitarias posteriores.

Buzz lleva la apariencia de cada comunidad entre escritorio y móvil

Buzz es un espacio de trabajo comunitario basado en Nostr con clientes de escritorio y móvil. Los PR fusionados de escritorio #3653 y móvil #3767 almacenan el tema, el acento y la elección de modo del sistema de cada comunidad como un registro cifrado NIP-78 en el relay de esa comunidad. Ambos clientes comparten la misma carga versionada y mantienen cachés locales con alcance de identidad, de modo que cambiar de comunidad o de cuenta no puede aplicar la apariencia equivocada mientras el relay no esté disponible. El orden de reemplazo, las escrituras protegidas y la resuscripción tras una conexión cerrada permiten que los dos clientes converjan de nuevo tras reconectar.

Buzz Desktop 0.5.10 llegó antes del corte del número con un pase de rendimiento y fiabilidad. Elimina regresiones introducidas tras 0.5.9, acelera la carga de canales, acota la retención inicial de la línea temporal, coalesce la persistencia del estado de lectura, preserva líneas temporales de canal frescas y evita que el worker de ingestión del relay falle con reacciones a eventos de proyecto. También añade el envío de un mensaje de hilo a un canal y restringe la búsqueda de escritorio al alcance previsto.

Actualizaciones de NIPs y trabajo de especificación del protocolo

NIPs

El PR de NIPs #2435 es una enmienda abierta a NIP-34 (colaboración en repositorios git mediante eventos de Nostr). Añade una tag b opcional a un evento de pull request para que el autor pueda nombrar una rama destino distinta de la predeterminada del repositorio. La propuesta coincide con soporte ya implementado en ngit y GitWorkshop, pero aún no ha entrado en la especificación.

El PR de NIPs #2434 es una propuesta abierta de claves de identidad poscuánticas. Deriva claves poscuánticas de cifrado y firma junto a la clave secp256k1 existente a partir de una semilla de derivación de claves mnemónicas de NIP-06, y vincula las pubkeys a la identidad de Nostr con una atestación de kind 10203. El borrador limita su reclamo a proteger la confidencialidad de mensajes anteriores si secp256k1 se rompe más adelante; no sustituye las firmas de eventos actuales.

El PR de NIPs #2431 es una enmienda abierta de NIP-07 (firmantes de navegador). Un cliente podría adjuntar la pubkey que espera a las peticiones de firma o cifrado, exigiendo al firmante usar esa cuenta o rechazar la llamada. Esto evitaría que una página continuara silenciosamente bajo una identidad distinta después de que el usuario cambie de cuenta en el firmante.

El PR de NIPs #1813 sigue siendo una propuesta abierta de double-ratchet tras trabajo sustantivo durante la ventana. Especifica conversaciones cifradas con secreto hacia adelante cuyas claves avanzan con los mensajes, con una implementación ya disponible en la biblioteca nostr-double-ratchet e Iris. Sigue siendo un borrador, no un NIP fusionado.

El PR de NIPs #2433 se abrió y cerró sin fusionar durante la ventana. Proponía aclarar los errores de relay de NIP-42 para que auth-required significara que otra autenticación podría cambiar el resultado, mientras que restricted significaría que no podría. La distinción abordaba conexiones autenticadas para una clave pero aún sin autorización para otra; el estado cerrado significa que la redacción no entró en la especificación.

El PR de NIPs #2378, cubierto previamente mientras aún estaba propuesto, se ha cerrado ahora sin fusionar. Sus eventos propuestos de pasaportes de agente, descubrimiento, tareas, marketplace, facturas y conexiones permanecen por tanto fuera del conjunto de NIPs.

El commit de NIPs 656cecc fusionó una corrección solo documental de NIP-29. Añade una tag previous al ejemplo de metadatos de grupo, mostrando cómo un evento de reemplazo puede identificar el evento que sustituye. Esto aclara un ejemplo y no introduce una nueva característica de protocolo.

Concord y CORDs

El PR de CORD #18 fragmentaría las listas comunitarias cifradas en eventos de kind 33302, eliminaría el límite de 50 membresías y podaría entradas retiradas para mantenerse dentro de los límites del relay. Otras dos propuestas abiertas añaden localizadores de mención privada y una señal de pausa que suspende el chat sin descartar mensajes.

El PR de CORD-02 #15 se fusionó el 6 de agosto y restringe las escrituras al plano de control de una comunidad. Propietarios y personal retienen un nuevo secreto de firma control_root, mientras que todos los miembros conservan la pubkey derivada y la clave de lectura necesarias para verificar y descifrar el estado de moderación. La clave de escritura es una barrera antispam, no un sustituto de las firmas internas de actor y las comprobaciones de roster que establecen la autoridad.

El PR de CORD #12, cubierto previamente como borrador abierto, se ha cerrado ahora sin fusionar. Su porción de plano de control fue reemplazada por la enmienda CORD-02 fusionada más estrecha arriba, mientras que los canales de escritura restringida y el resto del material borrador no entraron en la especificación.

Análisis en profundidad de NIPs

Solicitudes de borrado de eventos (NIP-09)

NIP-09 (solicitudes de borrado de eventos), definido por la especificación principal, ofrece al autor de un evento una forma firmada de pedir a relays y clientes que dejen de servir uno o más de los eventos de ese autor. No borra cada copia. Transporta la intención del autor a través de la misma red de relays que distribuyó el evento original.

La solicitud es un evento firmado ordinario de kind 5. Sus tags contienen una o más referencias e a IDs de evento concretos o referencias a a coordenadas de eventos direccionables, y las reglas de tags de NIP-09 indican que debería incluir una tag k por cada kind de evento referenciado. El content opcional puede explicar el motivo. Para una referencia a, un relay debería eliminar toda versión en esa coordenada cuya marca temporal no sea posterior al created_at de la solicitud, lo que evita que una solicitud de borrado antigua suprima un reemplazo posterior.

La autoría es el límite de seguridad. Un relay debería dejar de publicar un evento referenciado solo cuando su pubkey coincide con la pubkey de la solicitud de borrado, y un cliente debe realizar esa comprobación antes de ocultar un evento. Un relay puede no poseer el evento referenciado y por tanto ser incapaz de validar la relación al aceptar la solicitud, de modo que los clientes no pueden tratar la aceptación del relay como prueba de que el borrado fue autorizado. La especificación también pide a los relays conservar la solicitud de kind 5 porque otro cliente puede ya tener el evento original y encontrar la solicitud más tarde.

Aquí hay un evento firmado de kind 5:

{
 "id": "6f39fd3d0d593d97dd093f21fabe8f78895579d6979a6ecf14e169bd85bb0943",
 "pubkey": "5877220aaae6e54a6f974602d5995c0fe24a3ea7ddabd8644bec795b9da00743",
 "created_at": 1786465675,
 "kind": 5,
 "tags": [
 ["e", "f3d47f8b813928c5baf7ac993846be0220dc37a2e7c7b128fb49a4b92711f131"],
 ["k", "30091"],
 ["a", "30091:5877220aaae6e54a6f974602d5995c0fe24a3ea7ddabd8644bec795b9da00743:survey:0ad5cebc-608b-47d7-97fd-9e6c47787199"],
 ["t", "nostr-survey"]
 ],
 "content": "Public survey summary deleted during privacy refresh",
 "sig": "846be83b038dc5f91af0c9d03a4ac81aff9bc4cfde7d85c849fa2fdae890f75cc444a4072f45aa18883b0b3871e15381b220182d6e366892f0c9c6f9c0557244"
}

El borrado sigue siendo una política cooperativa, no revocación de un objeto firmado. Un relay, caché, captura de pantalla o cliente sin conexión puede conservar los bytes originales, y borrar la solicitud de kind 5 no la deshace. Los clientes pueden ocultar el objetivo, marcarlo como desautorizado o mostrar el motivo de la solicitud, pero deberían decir a los usuarios que no puede garantizarse un borrado universal. Esto difiere de NIP-40 (expiración de eventos), donde una tag expiration pide a los relays dejar de almacenar un evento tras un momento elegido al publicarlo. NIP-09 maneja una decisión posterior del autor y puede apuntar a eventos ya distribuidos.

Las implementaciones actuales aplican esa política en distintas capas. Divine PR #6623 elimina vídeos borrados del almacén de eventos del cliente, strfry PR #251 extiende las solicitudes de borrado válidas a destinatarios gift-wrap, y Amethyst declara soporte de NIP-09 en su cliente. El cliente de grupo de nostrord ofrece otra ruta de implementación actual.

Denuncias (NIP-56)

NIP-56 (eventos de denuncia), definido por la especificación principal, estandariza una denuncia firmada sobre una cuenta, un evento o un blob referenciado. Separa la señal de denuncia de la decisión de moderación, permitiendo a cada cliente o relay elegir qué denunciantes confía y qué respuesta encaja con su política.

Una denuncia usa kind 1984 y debe identificar la cuenta denunciada en una tag p. Denunciar una nota también requiere una tag e para el ID del evento. El tercer valor de la tag lleva una de las categorías especificadas: nudity, malware, profanity, illegal, spam, impersonation o other. Una denuncia sobre un blob puede usar su hash en una tag x, una tag e para el evento que referenció el blob, y una tag server opcional para una ubicación. Las tags opcionales L y l de NIP-32 (etiquetado) pueden añadir una etiqueta con espacio de nombres cuando la lista fija de categorías no es lo bastante precisa.

El evento prueba solo que una clave hizo una alegación. El contenido denunciado no se vuelve falso, ilegal o eliminable meramente porque exista un kind 1984 válido, y un relay abierto no puede contar con seguridad denuncias anónimas como votos. La especificación desaconseja la moderación automática del relay porque las denuncias son fáciles de manipular, a la vez que permite a los administradores de relay actuar sobre denuncias de moderadores en los que ya confían. Un cliente puede en cambio ponderar denuncias a través del grafo social de un usuario, por ejemplo difuminando contenido tras varios contactos de confianza que marquen la misma cuenta.

Aquí hay un evento firmado de kind 1984:

{
 "id": "17301ea66066d34af9ba0b6957ed9d9d8854b9436939e682e21e7a5a8768e4b2",
 "pubkey": "1ff02fb5cdc633c1be55368ab655490ec25d2f5dc2e364d4703bc3196d99eab1",
 "created_at": 1786465319,
 "kind": 1984,
 "tags": [
 ["p", "3a72b02cc05ee07310dc580874b6a9ca8271c6518b90655bd2e98003c9601e68", "impersonation"]
 ],
 "content": "",
 "sig": "6362e415410feb19e0505654a4660e8456b6b2aec5ae39173a0429a6a8e5fa1381c9488198ca2982db43ee8198af056f2a25537705c763784062056d0ab2eb1a"
}

NIP-56 y NIP-09 resuelven problemas distintos. Una denuncia de kind 1984 puede apuntar a la cuenta o evento de otra persona, pero no confiere autoridad de borrado. Una solicitud de kind 5 expresa la intención del autor original y solo es válida contra los propios eventos de ese autor. Ninguno garantiza eliminación: NIP-56 delega deliberadamente la acción a la política de moderación local, mientras que NIP-09 depende de que relays y clientes honren una solicitud autenticada.

Las implementaciones exponen esas elecciones en productos distintos. Divine PR #6591 corrige la entrega de denuncias en un cliente de vídeo corto, Conduit PR #250 lee denuncias como contexto acotado para participantes de marketplace, y el módulo NIP-56 de nostrord publica y procesa eventos de denuncia. Amethyst también lista soporte actual de NIP-56.

Envía un DM por NIP-17 para compartir un proyecto o noticia a través del proyecto Nostr Compass.

Nostr Compass #34

Wed, 05 Aug 2026 00:00:00 +0000

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

Esta semana: Sandstr permite a los recién llegados explorar clientes de Nostr simulados sin crear claves ni instalar una aplicación. nostr-mill añade consentimiento del firmante por evento y recuperación de claves entre clientes, mientras que nostrord amplía los grupos alojados en relays, los firmantes, la moderación, las subidas y los destacados. El trabajo de protocolo abarca los formatos de eventos de Nostr, las conexiones de monedero, el descubrimiento de relays, los napplets, Marmot y Concord; los análisis en profundidad explican la búsqueda asistida por relays y los destacados portátiles.

Historias Principales

nostr-mill 1.6.0 lleva el consentimiento de firma y la recuperación de cuentas al navegador

nostr-mill 1.6.0 es un selector de cuentas y firmante integrable en el navegador. Ahora solicita consentimiento por kind de evento y muestra el contenido y las etiquetas decodificados antes de firmar, con permisos de duración limitada y un gestor de permisos. La versión también corrige un error de primera sesión que permitía firmar sin preguntar en las categorías configuradas para solicitar confirmación cada vez. Su incorporación opcional mediante Google puede importar un nsec existente, almacena la clave cifrada en la carpeta de datos de aplicación de Drive del usuario, admite múltiples identidades y puede exportar un ncryptsec en formato NIP-49 (formato de clave privada cifrada).

La copia de seguridad experimental en relays deriva una frase de recuperación robusta con scrypt y HKDF, envuelve la clave como ncryptsec, verifica los eventos recuperados y exige un quórum de relays antes de la recuperación. El inicio de sesión mediante NIP-55 (intents de firmante en Android) ahora usa la ruta de retorno por portapapeles de Amber, y las conexiones NIP-46 (firma remota mediada por relays) son silenciosas por defecto. Los controles de marca y las pantallas de permisos adaptables completan la versión sin cambiar las integraciones existentes salvo que el operador lo active.

nostrord 2.5.0 da a los grupos de relays identidades estables y específicas del relay

nostrord 2.5.0 es un cliente multiplataforma para comunidades alojadas en relays. Ahora deriva una identidad NIP-29 (grupos gestionados por relays) a partir del ID de grupo y del relay anfitrión, delimita la membresía y las insignias de administrador del mismo modo, acepta enlaces profundos naddr de grupo y sincroniza los hilos de grupos privados entre dispositivos.

La versión también añade una bandeja de moderación con NIP-56 (eventos de denuncia), inicio de sesión con Amber a través de NIP-55, retroceso ante límites de velocidad para el tráfico del firmante NIP-46, renderizado de NIP-84 (destacados portátiles) con reintentos para referencias no resueltas, y subidas de medios a través de Blossom o NIP-96 (almacenamiento HTTP de archivos). El inicio de sesión con Google ahora respalda la clave antes de crear la cuenta y confirma las desconexiones. Las respuestas en hilos ganan contenido más rico y borrado por administradores, mientras que las correcciones del llavero de escritorio y del teclado móvil mantienen utilizables esas funciones de protocolo.

Primal Android 3.5.25 actualiza la firma remota y el filtrado de listas de seguimiento

Primal Android 3.5.25 es un cliente móvil de Nostr con feeds, búsqueda y firma remota. Actualiza su firmante remoto para el comportamiento actual del protocolo, añade una lista de silenciados de seguidos, abre la búsqueda desde Explorar, repara automáticamente las conexiones de relay estancadas, expone los tiempos de espera de las peticiones en la interfaz, rechaza entradas no válidas en la lista de seguidos y actualiza las URL de relay de reserva. La precarga de feeds, el menor uso de memoria y un límite de caché de 100 MB reducen el coste de mantener esos feeds al día. Las notas con una sola imagen ahora usan todo el ancho del contenido, y los controles de perfil y la precarga de medios reciben correcciones menores de interacción y ordenación.

Nostur 1.30.2 amplía las respuestas privadas y los medios en mensajes directos

Nostur 1.30.2 es un cliente de Nostr para plataformas Apple. Siempre expone la acción de respuesta privada, añade cachés de medios por conversación con límites y controles de borrado, mejora el autocompletado de nombres y etiquetas en publicaciones y chats, muestra los mensajes referenciados en el chat en vivo e incluye el título de la sala en las notificaciones del chat. Las correcciones de paginación del feed y de respuestas anidadas abordan regresiones de recuperación y renderizado de conversaciones.

Chama 5.7.0 añade registros de árbitros y recuperación de intercambios en caché

Chama 5.7.0 coordina intercambios entre pares y arbitraje mediante cadenas de eventos de Nostr firmados. Muestra el importe bloqueado de un árbitro, la antigüedad de su fianza y su outpoint de financiación; registra cuándo un suplente reemplazó a un árbitro ausente; y define los eventos dormidos de kind 38136 de atestación de fallos que requieren las firmas de ambos principales. Una reparación explícita reintenta los historiales de relay incompletos contra la caché duradera del dispositivo y republica los eventos recuperados, mientras que las publicaciones fallidas se encolan para la próxima conexión. La versión también evita pagos duplicados entre dispositivos de la prima de árbitro tratando el evento de kind 38113 del autor como el registro de pago.

Auditable Voting 0.1.165 restablece la entrega de papeletas delegadas

Auditable Voting 0.1.165 realiza votaciones verificables separando las credenciales del votante del contenido de la papeleta. Restablece la emisión delegada de papeletas ciegas mediante entrega autenticada de delegaciones y reposición de DMs de control, mantiene los mensajes directos de credenciales ciegas en los relays privados configurados y actualiza el proxy de auditoría a 0.1.52.

Sandstr permite a los recién llegados probar clientes de Nostr con datos simulados

Sandstr ofrece simulaciones interactivas en el navegador de clientes de Nostr para que un recién llegado pueda comparar sus interfaces antes de instalar uno o crear un par de claves. Su lanzamiento del 3 de agosto incluye reproducciones verificadas contra la referencia de Damus, Amethyst, Primal, Snort, YakiHonne, Coracle y Wisp, además de vistas previas tempranas claramente etiquetadas de Gossip, Keychat y Olas. Todo se ejecuta localmente contra datos simulados, por lo que las simulaciones no generan claves ni se conectan a relays. Cada simulación enlaza al sitio web y al repositorio de código del cliente real, lo que convierte a Sandstr en una herramienta de incorporación y comparación de interfaces en lugar de otro cliente de Nostr. Muestra cómo se sienten los feeds, los perfiles, los hilos, los mensajes directos, la búsqueda, los zaps y los controles de relay sin pedir a un usuario primerizo que tome una decisión de identidad o seguridad por adelantado.

mineracks signer combina una extensión de navegador con un bunker de escritorio

mineracks signer ofrece dos superficies de firma desde el mismo proyecto. Su extensión de navegador implementa NIP-07 para que las aplicaciones web puedan solicitar firmas sin recibir la clave privada, mientras que la aplicación de escritorio expone un firmante remoto NIP-46 para clientes que se comunican a través de relays.

La versión de escritorio 0.1.0 del proyecto almacena el material de claves con la codificación de claves cifradas de NIP-49 y mantiene la clave descifrada dentro del proceso de Rust en lugar de pasarla a la interfaz. Cada solicitud muestra la aplicación que llama y la acción solicitada, mientras que la aprobación automática por aplicación es opcional y revocable. La primera compilación de escritorio admite Apple Silicon pero no los Mac con Intel.

Versiones

Jumble 26.8.1 añade controles de prueba de trabajo y vistas previas de comentarios

Jumble 26.8.1 es un cliente de Nostr web y de escritorio. Recuerda la dificultad de la prueba de trabajo para publicar, muestra insignias de trabajo verificado, previsualiza los comentarios enlazados sobre el contenido externo, guarda imágenes desde el visor a pantalla completa y expande las biografías de perfil largas bajo demanda. Las notificaciones de reacciones ahora descartan los kinds de evento no admitidos, los avisos de desconexión de relay son menos ruidosos, se actualizaron los relays por defecto y se corrigió un conflicto de reproducción automática de medios.

nostr-calendar 2.1.0 restablece la vinculación del firmante en formularios privados

nostr-calendar 2.1.0 publica calendarios, eventos y respuestas de formularios como datos de Nostr. Vincula los envíos de formularios privados al firmante activo, guarda los eventos duplicados intencionados en los relays, corrige la obtención desde relays, analiza las fechas del calendario en hora local y añade notificaciones de la aplicación además de un cliente iOS. La corrección del firmante evita que una identidad obsoleta produzca una respuesta cifrada inutilizable.

Manent 2.0.0 añade etiquetado y búsqueda para notas guardadas

Manent 2.0.0 es un archivo personal para notas de Nostr firmadas. Añade etiquetas locales y búsqueda, permitiendo al lector organizar y recuperar los eventos guardados sin modificar su contenido firmado.

nosvelte 0.6.1 cierra las suscripciones vacías tras el EOSE

nosvelte 0.6.1 proporciona componentes y hooks reactivos de Svelte para datos de relay. Las búsquedas vacías ahora se resuelven al llegar el End of Stored Events, la cancelación cierra el REQ subyacente, los reintentos limpian los errores obsoletos y los hooks de lista devuelven su valor vacío documentado. También reconoce los eventos direccionables independientemente de dónde aparezca su etiqueta d, sustituye los metadatos y artículos reemplazados, desduplica las reacciones por ID de evento y conserva todos los eventos del primer lote de un relay.

Cambios sin publicar

NMP vincula la admisión al relay a las declaraciones y amplía las consultas de grupo

NMP es un kit de herramientas de TypeScript para construir aplicaciones de Nostr e interfaces de grupos respaldados por relays. El PR #1254 hace que la admisión al relay siga al propietario de la declaración que la autoriza, manteniendo la decisión de permisos vinculada al estado firmado de Nostr. El PR #1255 generaliza las consultas de grupos gestionados por relays de NIP-29 en lugar de asumir una única forma de búsqueda restringida. Ambos cambios están fusionados pero aún no han aparecido en una versión etiquetada.

Mosaico deriva la identidad de grupo gestionado de los registros del relay

Mosaico es un cliente de Nostr para explorar y administrar comunidades gestionadas por relays. El PR #758 deriva la identidad de un grupo gestionado del relay que aloja sus registros autoritativos. El PR #757 observa el registro publicado del grupo al resolver el estado de administración. Esto mantiene distintos a dos grupos con nombres similares en relays diferentes y ofrece a los clientes una fuente respaldada por relay para sus metadatos de gestión.

Divine aísla los relays lentos durante las consultas multi-relay

Divine es un cliente móvil de vídeo corto que publica y recupera vídeos a través de Nostr. El PR #6673 da a cada consulta de relay su propio tiempo de espera en lugar de dejar que una conexión estancada consuma el presupuesto de tiempo de toda una petición. Los resultados de los relays que responden pueden llegar así mientras el punto final lento se abandona de forma independiente. El cambio mejora la recuperación sin tratar un relay como autoritativo para el resultado combinado.

rust-nostr refuerza el cifrado, los hashes y la reconciliación

rust-nostr es una biblioteca y kit de herramientas de Rust para clientes, relays e implementaciones del protocolo Nostr. El PR #1421 reduce las asignaciones en su ruta de cifrado versionado de NIP-44, mientras que el PR #1423 introduce hashes tipados que dificultan mezclar accidentalmente valores de resumen incompatibles. El commit 21e31c2 evita que un mensaje malformado de reconciliación de conjuntos Negentropy de NIP-77 desconecte el relay local. El trabajo fusionado refuerza tanto el manejo de cargas cifradas como el comportamiento ante fallos de reconciliación antes de la próxima versión.

Zeus serializa los pagos NWC antes de cargar los presupuestos de gasto

Zeus es un monedero móvil de Bitcoin y Lightning que puede exponer operaciones del monedero a través de Nostr Wallet Connect. El PR #4305 cuenta los pagos pendientes contra un presupuesto de NIP-47 Nostr Wallet Connect en lugar de esperar a la liquidación. El PR #4303 serializa el manejo de pagos para que las solicitudes concurrentes no puedan competir a través del mismo límite de autorización. El par fusionado cierra una brecha de aplicación de presupuestos en la superficie de control Nostr del monedero.

Nostr Components comparte un único intento de conexión al relay

Nostr Components es una biblioteca reutilizable de componentes web para añadir datos e interacciones de Nostr a las aplicaciones. El PR #105 permite que los componentes montados al mismo tiempo compartan un intento de conexión al relay en curso. Cada consumidor sigue recibiendo la conexión resultante, pero los montajes concurrentes ya no abren sockets duplicados mientras el primer apretón de manos está pendiente. El cambio reduce la carga evitable sobre los relays en aplicaciones ensambladas a partir de varios componentes independientes.

Actualizaciones de NIPs y trabajo de especificación del protocolo

Formatos de eventos de Nostr y descubrimiento

El PR de NIP #2430 propone paquetes de pegatinas como definiciones direccionables de kind 30031 y los paquetes instalados por un usuario como kind reemplazable 10031. Cada etiqueta de pegatina lleva un código corto, un hash SHA-256 y un tipo MIME; la imagen permanece en un servidor NIP-B7 (almacenamiento de blobs Blossom). El borrador abierto estandariza así la identidad e instalación de paquetes sin colocar los bytes de la imagen en los eventos.

El PR de NIP #2429 propone documentos Gopher direccionables de kind 31436. Cada evento contiene un nodo de texto o menú UTF-8, y los nodos firmados bajo una misma pubkey forman un gopherhole que cualquier puente RFC 1436 respaldado por relay puede servir. La propuesta abierta usa el almacenamiento ordinario de eventos direccionables en lugar de vincular la publicación a un único nombre de host Gopher.

El PR de NIP #2428 propone grupos privados con tickets por época. Un grupo rota las credenciales de membresía entre épocas, y los clientes presentan el ticket de la época actual para participar. El borrador apunta al chat privado sin pedir a un relay que trate un token portador permanente como membresía de por vida.

El PR de NIP #2425, cubierto como propuesta la semana pasada, ha fusionado ahora una aclaración de URI en NIP-B0 (marcadores web direccionables). Distingue los prefijos HTTPS omitidos de los esquemas URI explícitos cuando un marcador almacena su destino en la etiqueta d, evitando que los clientes reconstruyan un destino ambiguo.

Pagos y conexiones de monedero

El PR de NIP #2419, cubierto como propuesta en la edición del 22 de julio, ha fusionado ahora un núcleo más reducido de NIP-47 (Nostr Wallet Connect). Los URI de conexión, el transporte cifrado por relay, el descubrimiento de capacidades, la negociación de cifrado y los métodos comunes permanecen en el NIP; las notificaciones, las facturas retenidas, keysend, el historial de transacciones, los metadatos y el emparejamiento por enlace profundo pasan a un repositorio de extensiones dedicado. Las conexiones existentes siguen siendo compatibles mientras los monederos pueden implementar los contratos opcionales de forma independiente.

El PR de NWC #2, cubierto como propuesta la semana pasada, ha fusionado ahora los métodos de pago BIP-321 en ese repositorio de extensiones. BIP-321 proporciona un URI de pago de Bitcoin común que puede transportar distintos raíles, de modo que quien llama a NWC puede solicitar o enviar un pago sin añadir un nuevo RPC central por cada tipo de instrucción subyacente.

Capacidades del anfitrión de napplets

El PR de NAP #95 propone el descubrimiento de catálogos para aplicaciones en sandbox distribuidas por Nostr. Un napplet pregunta a su anfitrión qué aplicaciones y capacidades están disponibles, y el anfitrión devuelve metadatos filtrados por política en lugar de exponer todo su entorno local. El contrato admite decisiones de lanzamiento sin conceder autoridad de ejecución durante el descubrimiento.

El PR de NAP #33 propone subidas de archivos y blobs mediadas por el shell. Un napplet aporta los bytes y la intención; el anfitrión selecciona un raíl NIP-96 o Blossom, firma la autorización, informa del progreso y devuelve URL, hashes, datos MIME y etiquetas NIP-94 (metadatos de archivo) listas para adjuntar. Las credenciales de almacenamiento y la autoridad HTTP nunca entran en el napplet.

Grupos cifrados Marmot

El PR de Marmot #410 fusionó reglas de convergencia y de entrada diferida. Los clientes distinguen un objeto al que le falta una dependencia de época actual de una entrada obsoleta o no válida, lo mantienen elegible para una nueva obtención tras un rechazo de recursos y reintentan cuando otro commit cambia el contexto de descifrado. Un compromiso de estado con separación de dominio ofrece a las pruebas de conformidad un oráculo de convergencia compartido sin añadir un campo de producción al protocolo.

Planos comunitarios de Concord

El PR de Concord #14 fusionó los mensajes que desaparecen de CORD-08. Un valor de metadatos de la comunidad fija la duración; los rumores de chat y las envolturas cifradas llevan una etiqueta de NIP-40 (expiración de eventos), mientras que los eventos de borrado y el aviso de temporizador de kind 1740 están exentos. El temporizador firmado viaja con el estado de la comunidad, aunque el borrado por el relay sigue siendo una solicitud de retención y no una garantía criptográfica de eliminación.

El PR de Concord #13 fusionó en CORD-04 el fijado resistente a rotaciones. Cada canal tiene una lista de fijados que reemplaza por completo en el plano de control; las entradas llevan el sello firmado original más claves de expansión NIP-44 por mensaje, lo que permite a un miembro nuevo verificar el autor y el texto plano sin recibir una clave de época antigua. Las listas privadas pueden permanecer selladas a una época del canal, los topes acotan el tamaño de la lista y los borrados del autor eliminan fijados sin bifurcar la cadena del plano de control.

Análisis en profundidad de NIPs

Capacidad de búsqueda (NIP-50)

NIP-50, definido en la especificación principal, añade un filtro de búsqueda opcional para los relays. Los filtros ordinarios de Nostr funcionan cuando un cliente ya conoce un autor, un kind de evento, un identificador o una etiqueta; NIP-50 aborda el descubrimiento cuando la entrada es una consulta humana como best nostr apps.

El formato de red de NIP-50 añade una cadena search a un filtro normal dentro de un mensaje REQ. Una petición puede combinar ese campo con kinds, authors, ids, filtros de etiquetas y limit, y un REQ puede llevar varios filtros independientes. Un relay que lo admita debería buscar principalmente en el content del evento, puede usar otros campos cuando el kind de evento lo haga útil y debería ordenar según su propia puntuación de relevancia antes de aplicar el limit. Ese orden difiere del flujo habitual de eventos ordenados del más reciente al más antiguo.

La cadena de consulta puede incluir las extensiones key:value de la especificación. Nombra include:spam, domain:, language:, sentiment: y nsfw:; un relay debería ignorar las extensiones que no implemente. Los clientes descubren el soporte declarado a través del campo supported_nips de NIP-11 del relay, pero aún pueden enviar el filtro a otros si están preparados para rechazar respuestas no relacionadas.

La especificación de NIP-50 deliberadamente no estandariza la tokenización, el stemming, la clasificación, la detección de idioma, el análisis de sentimiento ni la clasificación de spam. Dos relays conformes pueden devolver eventos y ordenaciones diferentes para la misma consulta. Eso convierte al relay en un proveedor de índices y clasificación, no en una fuente de verdad. La especificación recomienda consultar varios relays compatibles, comprobar si los eventos devueltos satisfacen el caso de uso del cliente y descartar los relays cuyos resultados tengan mala precisión.

Esto difiere del filtrado exacto de NIP-01. Un filtro de authors o #t tiene una semántica de coincidencia determinista que un cliente puede verificar directamente, mientras que una coincidencia de búsqueda puede depender de un índice y de una puntuación opaca. NIP-50 conserva el sobre de eventos firmados y el transporte de relay de NIP-01, pero acepta variación en el recall y la ordenación para hacer posible la recuperación abierta.

El evento siguiente es un resultado de búsqueda ilustrativo que usa los siete campos de evento de NIP-01. Los valores hexadecimales repetidos son marcadores de posición y no una firma válida.

{
 "id": "2943d6b43bcbf0ee4a8b4cac912111be0309607b8bb435ae40529989bea7f6c5",
 "pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
 "created_at": 1785771175,
 "kind": 1,
 "tags": [],
 "content": "I've been working on a customizable client (mostly relay feeds, but a ton of other things and subtle details too). It's called Hallway for reasons I don't remember and it's a fork of Fevela which is a fork of Jumble, but very rewritten for speed and simplicity...",
 "sig": "5b058b89dab9bd09d81bdc10eff95536125b87fbcbbc97f08d835c1272b2a3190cc3d340e42f54acb0d7e0e4b00355ab91292d0305c84a2d73b538319c0da12c"
}

Los clientes actuales usan el mismo filtro en distintas superficies de descubrimiento. Nostria envía búsquedas NIP-50 a relays de búsqueda dedicados, Ditto busca eventos a través de su pool de relays, y NoorNote coordina búsquedas respaldadas por relays para la lectura de formato largo. Su distinto manejo de resultados refleja la libertad que NIP-50 deja a relays y clientes.

Destacados (NIP-84)

NIP-84, definido por su especificación principal, asigna el kind 9802 a un destacado. Convierte un pasaje seleccionado, o una referencia a un medio no textual, en un evento firmado que puede moverse entre clientes de lectura, sociales y de anotación.

El content del evento contiene el texto seleccionado y puede estar vacío cuando la fuente es audio, vídeo u otro medio no textual. Un destacado apunta a una fuente de Nostr con una etiqueta a para un evento direccionable o una etiqueta e para un evento ordinario; una etiqueta r identifica una URL web. Los clientes que producen URL deberían eliminar los parámetros de seguimiento y otros parámetros de consulta no útiles antes de publicar, para que las variantes cosméticas de URL no fragmenten las referencias a la misma fuente.

Las etiquetas p opcionales atribuyen la fuente a una o más pubkeys de Nostr. Su cuarto valor puede identificar un rol como author o editor, y una etiqueta context puede conservar el texto circundante cuando la selección por sí sola resultaría poco clara. Un destacado con cita añade una etiqueta comment en lugar de publicar una segunda nota de kind 1: la etiqueta r de la fuente recibe el marcador source, mientras que las pubkeys o URL mencionadas en el comentario llevan mention, lo que permite a los renderizadores distinguir la atribución de la respuesta del usuario.

La definición del kind 9802 convierte a un destacado en un evento regular en lugar de uno reemplazable. Repetir o corregir una selección crea otro evento firmado, y eliminar uno depende del flujo normal de solicitudes de borrado y de la política de retención del relay. La especificación no define desplazamientos de bytes, selectores ni una instantánea canónica del documento, por lo que un cliente puede ser incapaz de reubicar un pasaje después de que su fuente web cambie. Los destacados públicos también revelan intereses de lectura; la anotación privada requiere un diseño separado de cifrado y compartición.

NIP-84 difiere de un evento de formato largo de NIP-23, que publica un artículo completo como kind 30023; un destacado cita o apunta a material que puede permanecer en otro lugar. También difiere de un conjunto de marcadores de NIP-51, que almacena una colección reemplazable de referencias. NIP-84 hace que cada selección sea firmada, atribuible, descubrible y discutible de forma independiente.

Este destacado ilustrativo contiene los siete campos de evento de NIP-01. Su identificador y su firma son marcadores de posición.

{
 "id": "0d57c07cfdfe8ec00711e2af88a666b61fc35c167b90b02dfb5db7ffba7b794a",
 "pubkey": "07367baec8e73c076b14e47fba3b0d5c014d559d7986a7172a79a8a64419d7c2",
 "created_at": 1785797755,
 "kind": 9802,
 "tags": [
 ["context", "Quantum computers will break secp256k1 which nostr relies on for its public private key pair. This means that given an npub, a quantum computer will be able to derive your nsec, read all your encrypted data and sign events as you."],
 ["alt", "This is a highlight created in https://primal.net iOS application"],
 ["a", "30023:1ec454734dcbf6fe54901ce25c0c7c6bca5edd89443416761fadc321d38df139:nostr-quantum-preparation"],
 ["p", "1ec454734dcbf6fe54901ce25c0c7c6bca5edd89443416761fadc321d38df139", "", "mention"]
 ],
 "content": "Quantum computers will break secp256k1 which nostr relies on for its public private key pair. This means that given an npub, a quantum computer will b",
 "sig": "219f3c1e572d1a087d667dc0d3a5443c77c0db3a5d42ce4e630604901ac63d2c879a86269d81e220bb77fd48b1579adafc333075e53c6eb0a108791fdd4a1622"
}

El formato ya cruza las fronteras entre clientes. nostrord 2.5.0 añadió renderizado de NIP-84 esta semana, NoorNote renderiza eventos de destacados en su cliente de formato largo, y Ditto los publica a partir del contenido seleccionado. Esas implementaciones cubren la lectura, la creación y el renderizado social sin requerir que un único servicio sea dueño de la anotación.

Envía un DM por NIP-17 para compartir un proyecto o noticia a través del proyecto Nostr Compass.

Nostr Compass #33

Wed, 29 Jul 2026 00:00:00 +0000

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.

Nostr Compass #32

Wed, 22 Jul 2026 00:00:00 +0000

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

Esta semana: IndieSats retira la custodia de claves, su whitelist y su recorte obligatorio de ingresos, y se relanza como un relay abierto, un reproductor y una capa de descubrimiento donde los artistas publican bajo sus propias claves. Nostrord v2.3.0 incorpora moderación de grupos, listas de silencio y relays onion la misma semana en que se fusionan cinco PRs de la spec NIP-29. Zapstore 1.1.0 introduce una clave de dispositivo portátil cifrada, con respaldo mediante Amber, y actualizaciones automáticas opcionales en segundo plano. El kind de lista favorite-follow-sets se fusiona y abre un PR de renumeración en cuestión de días. Y los proyectos de Iris entregan nostr-pubsub, el runtime de navegador fips-ts y nostr-social-graph 2.0.

Los releases etiquetados traen Amber v6.3.0 con aprobaciones agrupadas de firma bunker, Armada v0.37.0 con un segundo cliente para espacios de trabajo Buzz, Divine Mobile 1.0.17 con entrega persistente de NIP-17 y validación TLS estricta, y nak v0.20.2 con comandos para pull requests NIP-34.

En el lado no publicado, Snort registra cobertura de caché probada por EOSE, Shopstr cierra dos brechas de integridad de pagos, Mostr conecta chats privados de ActivityPub con DMs de Nostr, nostream fusiona el stack de control de acceso que cubre el Deep Dive de esta semana, y Amethyst alcanza 88 PRs fusionados con encuestas NIP-88 completas en Desktop.

El repositorio de NIPs fusiona cinco PRs esta semana, incluido el clúster NIP-29 y los favorite follow sets kind:10011, y abre debates sobre la simplificación de NIP-47 y las trusted relay assertions. El Deep Dive cubre NIP-42 y NIP-43, la pareja de control de acceso de relays.

Historias principales

IndieSats abandona su papel de editor y se relanza como infraestructura abierta de música en Nostr

IndieSats es una plataforma de música basada en Nostr que hasta esta semana actuaba como editor: custodiaba claves para los artistas, operaba una whitelist y se quedaba con un recorte obligatorio del 2 % de los ingresos. En un anuncio de pivote publicado el 20 de julio, el proyecto retiró los tres roles a la vez. La plataforma relanzada consta de tres piezas de infraestructura abierta: un relay abierto, un reproductor y una capa de descubrimiento. Los artistas ahora publican música bajo sus propios perfiles Nostr. La participación de plataforma del 2 % por pista es opcional, pero se selecciona de forma predeterminada cuando un artista publica, y este puede desmarcarla para conservar el pago completo; la plataforma también respeta las solicitudes de borrado kind:5 de NIP-09 para que los artistas puedan eliminar su obra. Una actualización v1.1.5 publicada el 21 de julio cambió la publicación de pistas al formato de eventos esperado por Amethyst y otros clientes de música Nostr e hizo explícita la entrega al relay. Para un espacio que suele hablar de protocolos que reemplazan plataformas, este es un caso real de una plataforma que se desarma voluntariamente en piezas de protocolo.

Nostrord v2.3.0 entrega moderación de grupos, listas de silencio y relays onion

Nostrord, el cliente de chat grupal para Android, iOS, web y escritorio, entregó v2.3.0 con acciones de moderación de grupos conectadas en todas las UIs (PR #192), invitaciones de grupo con consentimiento y detección cross-relay (PR #195), listas de silencio NIP-51 multiplataforma (PR #188) y soporte para relays .onion vía Tor. El release llega la misma semana en que la spec NIP-29 subyacente fusionó cinco PRs sobre subgrupos, fijado de mensajes, banners y códigos de invitación (detalles en la sección de protocolo de esta semana), así que el chat grupal en Nostr tiene ahora tanto una spec más profunda como un cliente que ejercita la mayor parte de ella, lo que acorta el ciclo de feedback para todos los demás que construyen sobre grupos de relays.

Zapstore 1.1.0 hace portátil la clave del dispositivo y añade actualizaciones automáticas en segundo plano

Zapstore es una tienda de apps nativa de Nostr donde los releases están firmados por las claves de los desarrolladores y ningún operador central los avala. La versión 1.1.0, el primer release cubierto aquí desde principios de marzo, cierra las dos mayores brechas con las tiendas de apps convencionales. La primera son las actualizaciones: las actualizaciones automáticas opcionales en segundo plano ahora descargan por Wi-Fi e instalan de forma silenciosa o escalonada, de modo que las apps se mantienen al día sin viajes manuales por la tienda. La segunda es la continuidad de identidad: la clave del dispositivo se vuelve portátil, cifrada y respaldable a través de Amber vía NIP-55, la interfaz de firmante de Android, de modo que un usuario que cambia de teléfono ya no empieza de cero como un dispositivo desconocido. El release también mueve el catálogo de apps a los relays como eventos kind:10067 firmados por el dispositivo, añade reportes verificados NIP-56 desde el menú adicional para que los usuarios puedan marcar apps problemáticas de una forma que otros clientes puedan consumir, y verifica la prueba C1 adjunta a un release antes de que proceda cualquier instalación, estrechando el vínculo entre lo que un desarrollador firmó y lo que un dispositivo ejecuta.

El kind de lista favorite-follow-sets se fusiona y se muda de inmediato

Una historia de coordinación de specs se desarrolló dentro de una sola semana. El PR #2413 se fusionó el 15 de julio, estandarizando un kind de lista reemplazable para favorite follow sets bajo NIP-51 (listas): un kind dedicado donde los clientes pueden publicar los conjuntos curados de cuentas seguidas de un usuario en lugar de sobrecargar kinds de lista genéricos. En pocos días resultó que el kind:10011 asignado ya estaba en uso en otra parte, así que ahora está abierto un PR #2417 de seguimiento para renumerar la lista a kind:10021. Todavía no se ha publicado nada contra el kind fusionado, lo que convierte este en el momento barato para renumerar; una vez que los clientes empiecen a publicar eventos kind:10011, la colisión sería cara de deshacer. Los desarrolladores que construyan funciones que consuman listas deberían seguir el PR de renumeración, no el texto fusionado, hasta que se resuelva.

Tres releases de la órbita de Iris aterrizaron juntos, y se engranan entre sí. nostr-pubsub es una biblioteca publish/subscribe neutral al transporte para eventos Nostr; sus primeros releases rastreados, v0.1.3 a v0.5.2, entregan un carrier de relay para navegador construido sobre el SimplePool de nostr-tools, verificación de eventos en la frontera del transporte para que las firmas inválidas nunca lleguen a los suscriptores, y consultas históricas acotadas. fips-ts trae FIPS, el transporte peer Noise-over-secp256k1 antes disponible como stack Rust, al navegador como runtime TypeScript: los releases 0.0.24 a 0.0.30 añadieron un carrier de datachannel WebRTC, señalización basada en Nostr para el descubrimiento de peers, una caché de peers recientes y un adaptador IndexedDB para almacenamiento en el navegador, y el runtime es compatible a nivel de wire con la implementación de referencia en Rust. La tercera pieza, nostr-social-graph v2.0.0, es una versión mayor de la biblioteca de grafo social: operaciones de roster firmadas para grafos de identidad Nostr, flujos de aprobación de dispositivos arrancados desde una URI canónica de tres campos, y facetas de identidad de transporte FIPS con vectores de prueba compartidos entre Rust y TypeScript. El marco conector es el Iris Stack, el laboratorio de integración del proyecto que une estas bibliotecas con Blossom, Hashtree y mensajería cifrada. En conjunto, una app web puede ahora descubrir peers vía Nostr, abrir un canal FIPS cifrado hacia ellos y mantener un grafo social firmado, todo en TypeScript.

Releases etiquetados

Amber v6.3.0 agrupa las aprobaciones de firma bunker y añade soporte de Expert List

Amber es un firmante remoto NIP-46 para Android. v6.3.0 añade aprobación agrupada de múltiples solicitudes para firma bunker, de modo que un lote de solicitudes de firma pendientes puede revisarse y aprobarse junto en lugar de una ventana cada vez. El release también añade soporte para eventos Expert List (kind 12022) y Expert Pack (kind 32022), un modo de privacidad que oculta contenido sensible en pantalla, y un cambio para obtener primero la lista de relays NIP-65 de una cuenta antes que sus metadatos de perfil, de modo que los flujos del firmante parten del conjunto real de relays del usuario. Esto sigue a la línea v6.2.x cubierta en la edición del 08-07-2026.

Seguimiento de Nostrord v2.2.0

Con v2.3.0 liderando la sección de noticias de esta semana, el espacio de releases etiquetados solo señala lo que no cubre la historia principal: v2.3.0 sigue a los controles de DM de v2.2.0 cubiertos en el #31, lo que convierte a este en el segundo release semanal consecutivo del cliente.

Armada v0.37.0 abre espacios de trabajo Buzz desde un segundo cliente

Armada, un cliente Nostr al estilo Discord, lanzó v0.37.0 con soporte para relays Buzz como un modo de espacio de trabajo mejorado de NIP-29, detectado mediante los metadatos NIP-11 del relay. El cliente renderiza publicaciones y comentarios de foros Buzz como kinds 45001 y 45003, incorpora ediciones y eliminaciones a las cronologías de streams, y añade superficies de presencia, flujo de trabajo, trabajos, reuniones y lienzos compartidos. Su espacio de trabajo Projects lee directamente del relay anuncios de repositorios, parches, pull requests, issues y eventos de estado de NIP-34 (commit de implementación), lo que brinda a los espacios de trabajo Buzz un segundo cliente tanto para conversación como para trabajo de repositorio.

Wisp v1.2.0 añade un conmutador multi-cuenta y hilos de respuestas plegables

Wisp es un cliente Nostr orientado a la privacidad con soporte de wallet integrado. v1.2.0 añade un conmutador multi-cuenta para cambiar entre perfiles sin volver a iniciar sesión, hilos de respuestas plegables para conversaciones largas, eliminación de parámetros de seguimiento de los enlaces de notas antes de abrirlos y una vista del historial de transacciones de la wallet. El release sigue a la actualización de Wisp cubierta en la edición del 2026-07-08.

Divine Mobile 1.0.17 endurece la seguridad de relays y la entrega de DMs

Divine Mobile, un cliente Nostr de vídeos cortos, lanzó 1.0.17 con un editor persistente de stop-motion y rutas Nostr más estrictas. Los mensajes directos ahora esperan las respuestas OK del relay, reintentan mediante una cola persistente y se enrutan a través de listas kind 10050 de relays de bandeja de entrada de los destinatarios (PR #6046); el emparejamiento NIP-46 conserva los desafíos auth_url como pasos de firmante recuperables (PR #6151). El PR #6278 elimina la aceptación permisiva de certificados de los WebSockets de relay de producción y de las solicitudes HTTP usadas para subidas NIP-96, LNURL y zaps, y restaura la validación TLS de la plataforma fuera de las conexiones locales de depuración. Las subidas interrumpidas también pueden reanudarse desde el último offset confirmado por el servidor, de modo que una publicación enviada al segundo plano ya no empieza de cero.

ClipRelay v0.1.2 (proyecto nuevo) sincroniza portapapeles entre dispositivos a través de relays Nostr

ClipRelay es una app multiplataforma recién lanzada (Android, macOS, Windows, Linux) que sincroniza tu portapapeles entre tus propios dispositivos: copia en una máquina, pega en otra. Todo el tráfico se mueve a través de relays Nostr como eventos cifrados NIP-44 dirigidos a ti mismo, así que no hay servidor que operar ni cuenta que crear; la clave privada permanece fuera de la app. v0.1.2 corrige un fallo sutil de sincronización en el que una máquina que despertaba de la suspensión seguía publicando pero dejaba de recibir en silencio, y endurece los indicadores de estado de relay que antes reportaban suscripciones muertas como saludables. Esta es la primera aparición de ClipRelay en el boletín.

Sonar v0.1-alpha.11 continúa la línea alpha

Sonar, la historia principal de la semana pasada, lanzó v0.1-alpha.11 con trabajo en el motor de enlaces mesh de Rust, correcciones de BLE y mesh, y diagnósticos de relays; un seguimiento incremental de la línea alpha cubierta en el #31.

nak v0.20.2 añade flujos de pull requests NIP-34

nak, la herramienta de línea de comandos de Nostr, lanzó v0.20.2 con comandos para crear, obtener y fusionar pull requests de NIP-34 y para obtener parches individuales, y permite hacer push sin reescribir un anuncio de repositorio. El rango de release de 11 commits también añade manejo de grupos padre para NIP-29, consulta más relays de outbox, hace configurables los tiempos de espera de conexión al relay y corrige la selección de bunker cuando solo existe el valor predeterminado --sec.

Los lanzamientos menores de la semana

Cuatro releases menores merecen una línea cada uno: noscall v0.6.0, la app de llamadas Nostr, migró sus notificaciones push a UnifiedPush, manteniendo la señalización de llamadas fuera de la infraestructura push de Google; nostr-vpn v4.1.3, una VPN mesh que usa Nostr para señalización, unificó su política de DNS de salida entre plataformas y ahora restaura el estado original de ruta y DNS después de sesiones de WireGuard o salida privada; StableKraft v1.3.0, el agregador de música y pódcasts Nostr-más-Lightning cubierto en abril, añadió controles nativos de pantalla de bloqueo y auriculares de Android, además de un wake lock limitado a la reproducción para que el audio sobreviva a Doze; y la nueva app de Zapstore Hakari respalda un registrador de peso mediante eventos Nostr cifrados.

Amethyst entrega QA de pre-release de v1.13.0 sobre aislamiento de napplets y autoridad Concord

Amethyst fusionó 88 PRs esta semana antes de su release v1.13.0. El PR #3650 es una pasada de QA pre-release que cubre aislamiento de cuentas de napplets, correcciones de autoridad Concord y alrededor de otras 30 correcciones. El trabajo de última hora añade renderizado, creación, votación, conteo por relay declarado y búsqueda kind 1068 completos de encuestas NIP-88 en Desktop (PR #3664); la búsqueda NIP-50 ahora clasifica los resultados por relevancia BM25 mientras que los grandes observadores de etiquetas usan fusión acotada (PR #3663). Una pasada independiente del almacenamiento de relay selecciona índices de consulta por coste medido, añade índices de etiqueta-autor-kind y serializa cada evento en vivo una vez por fanout (PR #3660), con reducciones de benchmark informadas de 149 a 4 milisegundos para una forma de consulta y de 14,2 a 0,66 milisegundos para una consulta común de sala de DMs.

Cambios no publicados

Snort reescribe la sincronización de consultas en torno a cobertura probada por EOSE

Snort, un cliente web de Nostr, reescribió su ruta de sincronización de consultas y caché en el commit 8a62770. El cliente ahora registra qué ventanas de consulta alcanzaron EOSE, usa esas marcas de agua para omitir rangos de caché ya cubiertos, centraliza el despacho de eventos detrás de un listener del pool de relays y envía filtros de búsqueda solo a relays cuyos documentos NIP-11 anuncian NIP-50. Correcciones posteriores serializan actualizaciones simultáneas de marcas de agua y corrigen límites inclusivos de las cronologías, mientras que el commit 9d1721b restaura una suscripción en vivo al feed de follows fragmentado para que los eventos que lleguen después de cargar la página no queden congelados fuera de sus ventanas en caché.

Shopstr vincula la validación de pagos a recibos firmados y precios del lado del servidor

Shopstr, un cliente de marketplace de Nostr, cerró dos brechas de integridad de pagos. El PR #552 hace que Zapsnag verifique la firma, el firmante, la solicitud de zap incorporada, las etiquetas de destinatario y producto, el importe BOLT11 y el preimage opcional de cada recibo kind 9735 frente al hash de pago de la factura antes de tratarlo como una compra. El PR #449 traslada la creación de cotizaciones Cashu detrás de una ruta de la API de Shopstr que resuelve el anuncio y recalcula su precio del lado del servidor, de modo que un importe modificado en el navegador no puede determinar la factura de la mint.

Mostr conecta chats privados de ActivityPub y DMs de Nostr

Mostr, un puente de ActivityPub a Nostr, ahora transporta objetos ChatMessage uno a uno de Pleroma y DMs cifrados de Nostr en ambas direcciones (commit 36ee547). Los chats privados de ActivityPub se convierten en eventos kind 4 dirigidos al destinatario de Nostr, mientras que los mensajes kind 4 enviados a usuarios federados conectados se descifran y federan como objetos ChatMessage. El puente limita estos eventos a relays de DM configurados y restringidos por NIP-42 y se autentica con una clave de relay independiente. Esta ruta de interoperabilidad usa cifrado heredado NIP-04. El gift wrapping de NIP-17 sigue fuera de esta implementación.

nostream fusiona ocho PRs sin cortar un release

nostream, la implementación de relay TypeScript, fusionó ocho PRs esta semana sin cortar un release. El par principal es el PR #702 y el PR #676, que juntos ofrecen a los operadores de relays un stack funcional de control de acceso de autenticación más membresía; el Deep Dive de NIP de esta semana recorre exactamente ese handshake. El PR #694 corrige filtros de etiquetas genéricas #e, #p, #g y similares que podían devolver una copia de un evento por cada fila de etiqueta coincidente, reduciendo tráfico de protocolo duplicado dentro de una suscripción.

FIPS v0.4.1 endurece el transporte sobre el que construye el ecosistema Iris

jmcorgan/fips entregó v0.4.1, un release de mantenimiento que acota el estado antipoison, corrige el manejo de convergencia y MTU, y reduce el uso de CPU. Por sí solo esto es fontanería, pero esta semana es tejido conectivo: el runtime TypeScript de navegador fips-ts del clúster del ecosistema Iris en la sección de noticias de esta edición es compatible a nivel de wire con este transporte Rust, así que las correcciones aquí se propagan directamente a aquello con lo que interopera el runtime del navegador.

Trabajo de protocolo y actualizaciones de NIPs

Cambios recientes en el repositorio de NIPs:

Fusionados:

NIP-29 (Relay-based Groups): Subgrupos (PR #2319, fusionado 2026-07-16): NIP-29 define grupos alojados en relays donde la membresía, los roles y el historial de chat viven en un único relay como eventos direccionables de la serie kind:39000, con acciones de moderación transportadas por eventos admin de la serie kind:9000. Este PR permite que un grupo se declare subgrupo añadiendo una etiqueta parent a sus metadatos, apuntando al identificador d de otro grupo en el mismo relay. Los subgrupos son grupos ordinarios en todo lo demás: la membresía no cascada (unirse a un padre no otorga membresía en ningún hijo), los roles de admin no se heredan (la lista de admins kind:39001 de cada subgrupo es autoritativa para su propio ámbito), y cada subgrupo mantiene sus propios eventos de miembros kind:9000/kind:9001 independientes. Los relays que soportan la jerarquía lo anuncian en su documento de información de relay NIP-11 bajo un objeto nip29 con "subgroups": true, de modo que los clientes puedan descubrir la capacidad antes de intentar crear comunidades anidadas.
NIP-29: Fijado de mensajes (PR #2379, fusionado 2026-07-15; PR #2416, fusionado 2026-07-17): Los admins de grupo ahora pueden fijar mensajes dentro de un grupo basado en relay. El mecanismo añade un nuevo evento de moderación, kind:9010 update-pin-list, que transporta la lista completa y ordenada de fijados como etiquetas e que referencian ids de eventos regulares, y un nuevo evento opcional a nivel de grupo, kind:39005 group pinned events, que el relay regenera para reflejar la lista de fijados aceptada más reciente. Como cada kind:9010 reemplaza la lista entera en lugar de alternar entradas individuales, fijar, desfijar, reordenar y limpiar los fijados se expresan todos enviando una lista nueva. El PR de seguimiento #2416 extiende el formato para que también se acepten etiquetas a en la lista de fijados, permitiendo a los admins fijar eventos direccionables (posts de formato largo, páginas wiki y otro contenido reemplazable parametrizado) junto a mensajes de chat ordinarios. Los relays pueden limitar el número de fijados, y el texto de la spec fusionada recomienda mostrar los fijados en el orden en que aparecen las etiquetas.
NIP-29: Etiqueta banner y sufijo de código de invitación (PR #2383, fusionado 2026-07-16; PR #2380, fusionado 2026-07-16): Dos adiciones de visualización e incorporación a los metadatos de grupo. El PR #2383 añade una etiqueta banner opcional al evento de metadatos de grupo kind:39000, uniéndose a los campos existentes name, picture y about para que los clientes puedan renderizar una imagen de cabecera para la página de un grupo. El PR #2380 define un sufijo de código de invitación para los enlaces de compartir de grupo: un código de invitación puede añadirse al identificador naddr del grupo como naddr1...?invite=<code>. Como el conjunto de caracteres bech32 no incluye ?, la parte anterior al sufijo sigue siendo un naddr válido por sí sola, de modo que los clientes que no entienden la extensión aún pueden resolver el grupo. Los clientes que sí la entienden pre-rellenan la etiqueta code en la solicitud de unión kind:9021, que se combina con el evento de moderación kind:9009 create-invite existente para simplificar la admisión a grupos cerrados.
NIP-51 (Listas): Favorite follow sets, kind:10011 (PR #2413, fusionado 2026-07-15): NIP-51 define los kinds de lista estándar, divididos entre listas reemplazables de la serie kind:10000 (una por usuario) y conjuntos direccionables de la serie kind:30000 (muchos por usuario, claveados por etiqueta d). Este PR añade kind:10011, favorite follow sets, una lista reemplazable estándar cuyas etiquetas a apuntan a follow sets kind:30000. Como espejo de kind:10012 (relay feeds), que contiene etiquetas a que referencian relay sets kind:30002, el nuevo kind permite a un usuario marcar con nombre follow sets curados —como listas curadas de colecciones de pubkeys publicadas por él mismo o por otros— y hacer que los clientes los muestren para seguir con un toque o cambiar de feed. Nótese que este número de kind ya está disputado: véase el PR de renumeración abierto más abajo.
NIP-46 (Nostr Connect): Guía de timeout silencioso (PR #2375, fusionado 2026-07-15): NIP-46 es el protocolo de firma remota donde un cliente envía solicitudes cifradas estilo JSON-RPC a un firmante (bunker) a través de relays y espera una respuesta cifrada. El cambio fusionado es una frase de comportamiento de wire: las solicitudes hechas con métodos desconocidos o no soportados DEBEN responderse con un error. Antes, un firmante que recibía un método que no implementaba podía no responder nunca, dejando al cliente colgado hasta que su propio timeout saltara sin forma de distinguir “método no soportado” de “firmante desconectado”. La respuesta de error obligatoria permite a los clientes fallar rápido y mostrar un mensaje significativo al usuario en lugar de girar indefinidamente.

PRs abiertos y discusiones:

Renumeración de kind:10011 a kind:10021 (PR #2417): Mueve la lista favorite follow sets recién fusionada de kind:10011 a kind:10021, porque 10011 ya está en uso en otra parte. El PR de renumeración se abrió a los pocos días del merge original, así que los clientes que implementen favorite follow sets deberían seguir este PR y apuntar al número final, no a 10011.
NIP-47 (Nostr Wallet Connect): Simplificación del núcleo (PR #2419): Propone estrechar NIP-47, el protocolo wallet-connect que permite a las apps solicitar pagos Lightning desde una billetera remota vía Nostr, en una spec de núcleo más pequeña. La funcionalidad opcional y más especializada saldría de 47.md hacia un repositorio de extensiones dedicado, nostr-wallet-connect/nwc, donde las specs de extensión pueden evolucionar independientemente del núcleo. El objetivo declarado es mantener el núcleo pequeño, estable y fácil de implementar, siguiendo la dirección acordada en llamadas anteriores de NWC de separar una capa mínima de wallet-connect de comportamientos opcionales más ricos. Dado lo ampliamente desplegado que está NIP-47 en billeteras y apps, cualquiera que hable NWC debería seguir la discusión de reestructuración.
Trusted Relay Assertions (borrador, sin número asignado) (PR #2418): Propone un estándar para publicar evaluaciones de confianza sobre relays Nostr, posicionado como la capa de “lo que concluimos” junto a NIP-11 (lo que un relay afirma sobre sí mismo) y NIP-66 (lo que los monitores midieron). Los proveedores de assertions calcularían puntuaciones de confianza a partir de métricas observadas, reputación del operador e informes de usuarios; los clientes consultarían estas assertions al elegir a qué relays conectarse. El borrador introduce kind:30385 (Trusted Relay Assertion direccionable, con etiquetas de puntuación, fiabilidad, calidad, accesibilidad, operador, política y jurisdicción), kind:10385 (Trusted Provider List reemplazable, los proveedores de assertions elegidos por el usuario), y reutiliza las etiquetas NIP-32 para informes de relays y operadores. Aún no se ha asignado ningún número de NIP; es un borrador en etapa temprana.
Operador AND para filtros (“NIP-91”, propuesto, número aún no en el repo) (PR #2252): Bajo NIP-01, los filtros de etiquetas son solo OR: un filtro "#t": ["meme", "cat"] coincide con eventos que tengan cualquiera de las dos etiquetas. Esta propuesta añade un modificador & para etiquetas indexables, de modo que "&t": ["meme", "cat"] devuelve solo eventos que lleven ambas etiquetas, permitiendo a los relays hacer la intersección del lado del servidor en lugar de que los clientes sobre-descarguen y filtren localmente. Las reglas especifican que AND tiene precedencia sobre OR, que los valores de etiqueta usados en AND deberían ignorarse en OR por los relays que lo soportan, y que los clientes DEBEN incluir también las etiquetas OR estándar # por compatibilidad con relays que no soportan la extensión (esos relays devuelven el resultado OR más amplio, que el cliente interseca localmente). El PR es una continuación reabierta de una propuesta anterior y lista implementaciones de relay, incluida una imagen docker de nostr-rs-relay, netstr y un relay worker de Snort. El número NIP-91 aparece solo en la rama del PR; todavía no está en el índice de NIPs del README del repositorio, así que trátalo como provisional.
Nostr web applets (“NIP-5D”, propuesto, número aún no en el repo) (PR #2303): Define un protocolo postMessage para que aplicaciones web en sandbox (“napplets”) que corren en iframes o webviews se comuniquen con una aplicación anfitriona (“shell”). La spec es deliberadamente un núcleo delgado: especifica el sobre de mensajes, reglas de sandbox (los iframes de napplet DEBEN usar sandbox="allow-scripts" sin allow-same-origin, y las shells NO DEBEN exponer window.nostr NIP-07 dentro del iframe), identificación del emisor vía la referencia de ventana infalsificable MessageEvent.source, no event.origin, y negociación de capacidades basada en manifiesto. Los mensajes de protocolo reales para firma, acceso a relays, almacenamiento y comunicación entre napplets se delegan a specs de extensión NAP (Nostr Applet Protocol), cada una dueña de un dominio de capacidad, con la firma y el cifrado siempre mediados por la shell para que las claves nunca entren en el sandbox. La propuesta depende de la spec de manifiesto de napplet NIP-5A y es oportuna esta semana: el trabajo pre-release de v1.13.0 de Amethyst incluye aislamiento de cuentas de napplet, convirtiendo el alojamiento de napplets del lado del cliente en un área activa de implementación. Como con “NIP-91” arriba, el número 5D es provisional.

NIP Deep Dive: NIP-42 y NIP-43

Operar un relay que no está abierto a todos solía significar inventarlo todo uno mismo. El operador de un relay de pago o solo por invitación tenía que mantener una whitelist fuera de banda, normalmente un archivo de texto de pubkeys recogidos por DMs, sin forma estándar de decirle a un cliente conectado “demuestra quién eres” y sin forma estándar de que un usuario pidiera admisión o supiera si era miembro. Cada relay que quería lecturas o escrituras restringidas construía su propio mecanismo privado, y los clientes no podían interoperar con ninguno de ellos. NIP-42 estandariza la mitad de prueba de identidad de ese problema, y NIP-43 estandariza la mitad de membresía. Esta semana nostream, el relay TypeScript, fusionó la pareja de extremo a extremo: el PR #702 restringe las lecturas de kinds cifrados a destinatarios autenticados, y el PR #676 añade estrategias de eventos de solicitud de unión y salida, ambos fusionados el 20 de julio.

NIP-42: Autenticación de clientes ante relays

NIP-42 responde una pregunta: ¿quién está en esta conexión? Un relay que quiere restringir lecturas o escrituras envía un mensaje AUTH con una cadena de desafío, al conectarse o bajo demanda cuando una solicitud necesita autenticación. El cliente responde con su propio mensaje AUTH que contiene un evento efímero firmado, kind 22242, y el relay contesta con un mensaje OK exactamente como si el evento de autenticación fuera una escritura ordinaria. La sesión autenticada se mantiene entonces durante la conexión, y un cliente puede autenticar varios pubkeys en una conexión con una secuencia de mensajes AUTH, cada uno de los cuales el relay trata como autenticado.

El evento de autenticación firmado es un objeto compacto: un pubkey, un created_at, kind 22242, una etiqueta relay, una etiqueta challenge, un content vacío y una sig sobre el id del evento. Como kind 22242 es efímero —los relays nunca deben almacenarlo ni retransmitirlo— no existe ningún ejemplo publicado que incrustar; el recorrido por los campos de abajo cubre lo que contiene.

El pubkey es la identidad que se está probando, ya que el relay verifica la sig sobre el id del evento contra él. El kind 22242 se sitúa en el rango efímero: el evento es una credencial a nivel de conexión, y los relays nunca deben almacenarlo ni difundirlo a otros clientes. La etiqueta relay vincula la firma a una URL de relay para que un evento de autenticación capturado no pueda reproducirse contra otro relay, y la etiqueta challenge lo vincula a la cadena de desafío concreta que el relay emitió en esta conexión, bloqueando la reproducción de una autenticación capturada en una conexión posterior. El created_at debe estar cerca de la hora actual, dentro de una ventana de unos diez minutos, de modo que un evento de autenticación viejo expire por sí solo. El campo content está vacío; no se publica nada.

La spec también define dos prefijos legibles por máquina que hacen visible la restricción a los clientes. Un relay que rechaza una suscripción porque el cliente aún no se ha autenticado responde con un mensaje CLOSED que empieza por auth-required:, y una escritura rechazada recibe un OK con el mismo prefijo. Un cliente que se autenticó pero aún carece de permiso para la acción recibe restricted: en su lugar. Esa distinción es sobre la que construye el PR #702 de nostream: las lecturas de kinds cifrados ahora pueden cerrarse con auth-required: hasta que el pubkey solicitante pruebe que es el destinatario.

NIP-43: Relay Access Metadata and Requests

NIP-43 responde la pregunta siguiente: ahora que el relay sabe quién eres, ¿qué puedes hacer? Donde NIP-42 es un handshake en una conexión viva, NIP-43 es un conjunto de eventos publicados que describen el estado de membresía y permiten a los usuarios pedir cambiarlo. En el lado del relay, un evento kind 13534, firmado por el pubkey del campo self del documento NIP-11 del relay, lista una etiqueta member por pubkey, con argumentos de rol opcionales que apuntan a definiciones de rol publicadas como kind 33534. El kind 8000 anuncia la incorporación de un miembro y el kind 8001 anuncia una baja, ambos firmados por la misma clave del relay con una etiqueta p para el miembro afectado. En el lado del usuario, el kind 28934 es una solicitud de unión que lleva un código de invitación en una etiqueta claim, el kind 28935 es un evento efímero de código de invitación que el relay genera al vuelo cuando un usuario solicita un claim, y el kind 28936 es una solicitud de salida.

Una solicitud de unión es un objeto igualmente pequeño, y todavía ningún relay público implementa NIP-43, por lo que no hay ningún evento kind 28934 real que incrustar; el recorrido por los campos de abajo cubre lo que contiene.

El pubkey es el usuario que pide admisión, y el kind 28934 marca el evento como solicitud de unión. La etiqueta - es el marcador de evento protegido NIP-70, que indica a los relays que no acepten este evento de nadie salvo de su autor. La etiqueta claim lleva el código de invitación que el usuario obtuvo fuera de banda, y created_at debe ser ahora, más o menos unos minutos, de modo que una solicitud vieja no pueda reproducirse. El relay responde al claim con un mensaje OK, reutilizando el prefijo restricted: de NIP-42 para fallos como un código expirado o inválido, y debería entonces actualizar su lista kind 13534 y puede publicar un evento kind 8000 de incorporación de miembro. La membresía deliberadamente no se deriva de un único evento: la spec dice que la lista firmada por el relay no debería considerarse exhaustiva ni autoritativa, y un cliente que decida si alguien es actualmente miembro debería consultar tanto el kind 13534 del relay como los propios eventos del miembro. Los clientes solo deben enviar solicitudes de unión, invitación o salida a relays que anuncien este NIP en la sección supported_nips de su documento NIP-11, y el PR #676 de nostream es la maquinaria del lado del relay que convierte esos kinds de solicitud en cambios reales de membresía.

Historia

NIP-42 es el más antiguo de los dos por amplio margen. Entró en el repositorio de NIPs el 2 de enero de 2023, en el commit c80be21c, donde fiatjaf simplificó drásticamente un NIP de autenticación de relay anterior redactado por semisol, colapsando un esquema de desafío más complejo en el único evento efímero firmado que la spec sigue usando hoy. NIP-43 llegó mucho después, el 30 de octubre de 2025, cuando se fusionó el PR #1079 de hodlbod, añadiendo metadatos y solicitudes de acceso a relays construidos directamente sobre el prefijo restricted: de NIP-42. La brecha de dos años y medio refleja cuánto tiempo el ecosistema operó relays de pago y privados sobre whitelists ad hoc antes de que la capa de membresía obtuviera un estándar.

Implementaciones

En el lado del relay, nostream ahora entrega ambas mitades tras las fusiones de esta semana. strfry implementa NIP-42, validando eventos de autenticación kind 22242 en su ingester y emitiendo desafíos desde su configuración. nostr-rs-relay maneja el handshake AUTH en su capa de conexión con pruebas que cubren la ventana de desafío y marca de tiempo. khatru, el framework de relay en Go, rastrea el pubkey autenticado por conexión para que las políticas puedan restringir lecturas y escrituras sobre él. En el lado del cliente, Amethyst firma respuestas kind 22242 a los desafíos de los relays, incluida autenticación por stream para sus comunidades cifradas Concord. Los dos NIPs dividen el control de acceso a lo largo de una línea limpia: NIP-42 es prueba de identidad, limitada a una conexión, un desafío y unos minutos de validez, y no dice nada sobre política. NIP-43 es política, expresada como eventos ordinarios de relay: quién es miembro, quién fue añadido o eliminado, y cómo un usuario solicita esas transiciones. La brecha que los implementadores deberían tener en cuenta es que nada estandariza aún permisos más finos más allá de los metadatos de rol opcionales de NIP-43, así que cualquier relay que haga más que una división binaria miembro/no-miembro está diseñando esa capa por su cuenta.

Eso es todo por esta semana. ¿Construyendo algo o tienes noticias que compartir? Escríbenos por DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #31

Wed, 15 Jul 2026 00:00:00 +0000

Bienvenidos de vuelta a Nostr Compass, su guía semanal sobre Nostr.

Esta semana: Vector v0.4.0 retira Marmot como transporte predeterminado para Chats Grupales a favor de Concord, un protocolo de comunidad abierto con licencia MIT también utilizado por Armada de Soapbox, y lanza Concord v2 cuatro días después con un selector de comandos con barra para bots, un temporizador de autodestrucción y badges NIP-58. Amethyst fusiona su propia implementación limpia de Concord, compatible a nivel de protocolo, la misma semana. Sonar se separa de Bitchat con una alpha multiplataforma y es la fuente de especificación citada para la propuesta de kinds de paquetes de stickers de esta semana. Divine Mobile 1.0.16 incorpora un editor de video más profundo, cifrado en reposo y procedencia ProofMode que sobrevive a las descargas de clips con marca de agua. Bitchat v1.7.0 añade voz push-to-talk en vivo para DMs y push-to-talk firmado en la malla pública. MDK v0.9.4 acota el inicio de sesión con firmante externo y añade persistencia de borradores, continuando su pase de endurecimiento la misma semana en que Vector se aleja de la especificación para chat grupal.

Los lanzamientos etiquetados traen n_cord v1.1 con soporte para NSEC Bunker, cdk v0.17.3 con soporte de servicio de billetera NIP-47 en cdk, cdk-nwc y cdk-ffi, Coop Mobile v0.2.4 con mejoras en Nostr Connect e importación ncryptsec1, Nmail v0.14.0 llegando a macOS con envío programado, Nostrord v2.2.0 con un interruptor maestro de DM, Nostr WoT 0.3.86 endureciendo respaldos de claves al formato NIP-49, Keep Android v1.1.8 con incorporación FROST de primer uso, Noscall v0.6.0 con una billetera Cashu y notificaciones push basadas en relay, Kubo con modo tableta y fotos en chats grupales, y Nostr Codex Phone v0.2.9 con solicitudes auxiliares de git, diff y lectura de archivos.

En el lado no publicado, Amethyst permite a las cuentas asignar apodos a contactos con tarjetas NIP-85 cifradas en 54 PRs fusionados, Zap Cooking lanza la Fase 3 de My Kitchen y corrige un error de quórum del pool NDK, Kehto transmite lecturas de outbox antes de que termine el descubrimiento de relay, Wired y TAO añaden reparto de ingresos de creador con NIP-57, Conduit Mono reconstruye su bandeja de pedidos del comerciante alrededor de pago efímero como invitado, Buzz endurece el aprovisionamiento del creador de canal en 240 PRs fusionados, y Nostr Docs adopta un firmante NIP-49 con múltiples cuentas y emparejamiento QR. Recién rastreados esta semana: OpenDiscord v1.0.1, Auditable Voting v0.1.140, y la selección Discovery Cambium v0.3.2, un firmante NIP-55 sin claves que redirige a un compañero de hardware Heartwood.

El repositorio de NIPs no fusiona nada en la última semana y abre seis propuestas: kind:10011 conjuntos de seguimiento favoritos, una unidad cifrada privada que extiende NIP-4E, NIP-DA compartición privada de datos con permisos, kinds de paquetes de stickers 10031 y 30031, fijación de mensajes NIP-29, y una reestructuración del descubrimiento de relay NIP-66. El Deep Dive cubre NIP-99 y la extensión de comercio Gamma Markets.

Historias principales

Vector v0.4.0 mueve los Chats Grupales de Marmot a Concord, y Amethyst lanza su propio cliente Concord días después

Vector es un mensajero Nostr construido alrededor de un cliente de binario único enfocado en privacidad para DMs y chats grupales. Vector v0.4.0 reescribe el motor de mensajería de la aplicación en una biblioteca compartida vector-core y, en el mismo lanzamiento, retira Marmot (MLS-sobre-Nostr) como transporte predeterminado para Chats Grupales a favor de Concord, un protocolo de comunidad cifrado de extremo a extremo; el historial existente de grupos Marmot no se transfiere, y las notas del lanzamiento indican a los usuarios respaldar cualquier dato de grupo Marmot antes de actualizar. Las propias notas de lanzamiento de Vector describen Concord como “nuestro protocolo de mensajería personalizado”, pero las especificaciones CORD-01 a CORD-07 subyacentes se publican por separado, con licencia MIT, y ya están implementadas fuera de Vector: el cliente estilo Discord de Soapbox, Armada, construye su función de Comunidades sobre la misma especificación Concord, y un día después, Amethyst fusionó su propia implementación limpia y compatible a nivel de protocolo, cubierta en detalle a continuación. El mismo lanzamiento de Vector añade enrutamiento opcional por Tor para todo el tráfico, inicio de sesión con firmante remoto NIP-46 por QR o URI bunker pegada, múltiples cuentas con un conmutador dentro de la aplicación, y paquetes de emojis personalizados compartidos entre clientes. La eliminación de mensajes remueve un mensaje para ambos lados en DMs y chats grupales, y Vector deliberadamente mantiene la clave de firma efímera en lugar de seguir el flujo estándar de eliminación NIP-17, una desviación motivada por privacidad que el proyecto señala explícitamente en las notas del lanzamiento. Cuatro días después, v0.4.1 lanza Concord v2, descrito como una versión con mejoras importantes de privacidad y estabilidad para Comunidades manteniendo las existentes funcionando, junto con un selector de comandos con barra estilo Discord para bots con parámetros tipados, un temporizador de autodestrucción por chat, y un sistema de badges NIP-58 para cazadores de errores. El alejamiento de Marmot para chat grupal ocurre la misma semana en que MDK v0.9.4 a continuación continúa invirtiendo en la especificación.

Amethyst lanza una implementación limpia de Concord para comunidades cifradas de extremo a extremo

Amethyst es un cliente Nostr rico en funciones para Android y multiplataforma. PR #3566 añade una implementación completa de Concord (CORD-01 a CORD-07) cubriendo comunidades sin servidor y cifradas de extremo a extremo: planos de control, chat e invitados envueltos con gift-wrap, sobre relay ordinarios, con cumplimiento de roles, expulsiones y baneos enraizados en el propietario que cada cliente verifica localmente en lugar de confiar en un servidor, y re-cifrado para cortar acceso a miembros eliminados. El código de protocolo y criptografía reside en quartz/, los modelos de estado y vista en commons/, y las pantallas y navegación en amethyst/ para Android, con verbos CLI delgados bajo cli/; todavía no hay interfaz de escritorio, ya que la lógica compartida reside en quartz/commons para que Desktop la adopte después. La implementación es de sala limpia: construida a partir de las especificaciones CORD públicas y constantes de protocolo observadas, bajo la propia licencia MIT de Amethyst, distinta del código base AGPL-3.0 de Armada. Los valores de vectores de prueba propios de Armada fueron portados a las pruebas unitarias de Quartz para confirmar que ambos clientes realmente interoperan a nivel de protocolo, dando a Concord tres implementaciones independientes en días: Vector lanzando primero, Armada como cliente de referencia de Soapbox, y ahora la construcción desde la especificación de Amethyst.

Sonar se separa de Bitchat con una alpha multiplataforma y una especificación de paquetes de stickers

Sonar es un mensajero y billetera con malla Bluetooth más Nostr desarrollado a partir de Bitchat, con DMs grupales Marmot interoperables con White Noise. El código vive en hedwig-corp/bitchat-to-sonar. v0.1-alpha.7 añade ventaneo acotado de transcripción estilo Signal para que el rendimiento de apertura y desplazamiento se mantenga local-first, sincroniza el estado de descubrimiento cercano entre pares, y corrige subidas de medios Blossom que fallaban por manejo de content-type y estado HTTP; la precedente alpha.6 drenó eventos Marmot en vivo para una actualización más rápida del chat y cerró brechas de paridad de funciones entre Android e iOS en llamadas, mensajería, billetera y push. Sonar también es la fuente de especificación citada para PR #2410, que registra kinds de eventos de paquetes de stickers bajo la propia especificación “Sonar Stickers” del proyecto, dando a este lanzamiento un enlace directo al trabajo de protocolo de esta semana.

Divine Mobile 1.0.16 incorpora un editor de video más profundo, cifrado en reposo y procedencia ProofMode

Divine es un cliente de videos cortos construido sobre Nostr con curación de feed por Web-of-Trust. v1.0.16, el primer lanzamiento etiquetado desde el #30, añade transiciones de clips, reproducción inversa, un grabador de voz en off y marcadores de ritmo en la línea de tiempo al editor de video, junto con un control de ajuste de feed que permite al usuario deslizar para ajustar recomendaciones directamente en lugar de dejarlas a señales opacas de interacción. El lanzamiento también activa el cifrado en reposo para datos locales, añade subidas en segundo plano que sobreviven a la suspensión de la aplicación, y lleva los datos de procedencia ProofMode al descargar un clip con marca de agua para que la atestación de creación humana no se pierda en tránsito. Divine también incluye nuevas protecciones para cuentas de menores de 16 años y expande la localización a 17 idiomas y 284 cadenas traducidas.

Bitchat v1.7.0 añade voz push-to-talk en vivo para DMs y la malla pública

Bitchat es una aplicación de chat con malla Bluetooth con una pasarela opcional hacia relay Nostr. v1.7.0, lanzado la noche que se publicó el #30, añade voz push-to-talk en vivo en PR #1403 que transmite audio mientras el remitente mantiene presionado el botón y retrocede a una nota de voz si el flujo se interrumpe, más push-to-talk firmado en la malla pública en PR #1406 para que las ráfagas de voz en vivo en el canal compartido de la malla lleven autenticación del remitente. El lanzamiento también repara la rotación de peer-ID reenlazando el vínculo en un re-anuncio verificado, reconociendo al mismo par bajo su nuevo ID (PR #1401), y los mensajes directos a un par actualmente inalcanzable ahora se ponen en cola con entrega store-and-forward en lugar de fallar directamente (PR #1415). Esto continúa directamente desde la cobertura del #30 del trabajo de NIP-13 proof-of-work y pasarela mesh-a-Nostr de v1.6.0.

MDK v0.9.4 acota el inicio de sesión con firmante externo y añade persistencia de borradores

MDK es el SDK de referencia para el protocolo Marmot, la capa de mensajería MLS-sobre-Nostr que el #30 cubrió marcando su especificación como adoptada. v0.9.4 acota los pasos de directorio consultivo que un cliente recorre durante el inicio de sesión con firmante externo en PR #793, previniendo un bucle de reintento sin límite cuando un firmante remoto es lento o no responde. El mismo lanzamiento añade persistencia de borradores de mensajes y enlaces de perfil a sitio web en PR #812, continuando el pase de endurecimiento incremental que MDK ha ejecutado desde el corte de v0.9.0.

Lanzamientos etiquetados

n_cord v1.1 añade soporte para NSEC Bunker

n_cord es un cliente de chat con tecnología Nostr inspirado en Discord e IRC. v1.1 añade soporte para NSEC Bunker NIP-46 junto con una corrección de error en el manejo de respuestas.

cdk v0.17.3 añade soporte de servicio de billetera NIP-47 en cdk, cdk-nwc y cdk-ffi

cdk es un kit de desarrollo de Cashu; este lanzamiento es solo Bitcoin/Lightning en la mayoría de aspectos, pero v0.17.3 añade soporte de servicio NIP-47 (Nostr Wallet Connect) con un crate de servicio NWC dedicado, integración de billetera, enlaces FFI para cdk-ffi, y cobertura de pruebas de extremo a extremo, dando a las billeteras Cashu construidas sobre cdk una superficie estándar de Nostr Wallet Connect.

Coop Mobile v0.2.4 mejora Nostr Connect y añade importación ncryptsec1

Coop Mobile es un cliente de mensajería privada NIP-17 para plataformas móviles. v0.2.4 mejora su flujo de NIP-46 Nostr Connect, corrige un indicador de carga que se quedaba permanentemente en algunas conexiones, y añade soporte de importación para el formato de clave cifrada NIP-49 ncryptsec1 junto con una pantalla de importación de identidad rediseñada.

Nmail v0.14.0 llega a macOS con envío programado y notificaciones push

Nmail es un cliente de correo construido sobre Nostr; v0.14.0 lleva la aplicación a macOS, añade envío programado con un buzón de Programados dedicado para mensajes en cola, y añade notificaciones push. El lanzamiento también cambia la resolución de identificadores Nostr de la libreta de direcciones al resolutor NIP-05 de NDK en lugar de una implementación propia.

Nostrord v2.2.0 añade un interruptor maestro de DM y mensajes directos más ricos

Nostrord es un cliente de chat grupal basado en relay NIP-29 para Android, iOS, web y escritorio. v2.2.0 añade un interruptor maestro para deshabilitar todas las funciones de mensajes directos a la vez (PR #175) y lanza “mensajes directos más ricos” (PR #186), continuando desde la cobertura del #30 sobre el lanzamiento que consolidó el pool de relay y detectó WebSockets zombi.

Nostr WoT 0.3.86 endurece los respaldos de claves y las solicitudes de firma

Nostr WoT es una extensión de navegador que vincula una identidad Nostr con una billetera Lightning. v0.3.86 mueve los respaldos de claves cifradas al formato estándar NIP-49, hace que las solicitudes de firma muestren el evento completo y todas las etiquetas en lugar de un resumen, verifica los datos del relay contra su firma, y deja de exponer la identidad activa al cambiar de cuenta. La extensión también elimina el permiso de navegador scripting no utilizado.

Keep Android v1.1.8 añade incorporación FROST de primer uso

Keep es un firmante Android construido sobre fragmentos de clave FROST de umbral. v1.1.8 añade un flujo de primer uso que explica los fragmentos de clave FROST y permite al nuevo usuario elegir una política de firma de Manual, Básica o Automática antes de que llegue la primera solicitud de firma, la primera incorporación del lado Android para el modelo de firma de umbral del crate keep-mobile subyacente.

Noscall v0.6.0 añade una billetera Cashu y notificaciones push basadas en relay

Noscall es una aplicación de llamadas de audio y video seguras construida sobre Nostr. v0.6.0 añade una billetera Cashu con alcance de cuenta con saldos multi-mint, envío y recepción de ecash, y pago y recepción Lightning con persistencia de cotizaciones. El lanzamiento también migra las notificaciones push de Android de Firebase Cloud Messaging a una ruta de entrega basada en relay Nostr a través de UnifiedPush, y mejora la fiabilidad de VoIP de iOS y push APNs durante reintentos de inicio de sesión.

Kubo lanza modo tableta y fotos en chats grupales

Kubo es una plataforma de video Nostr segura para niños con curación de feed por Web-of-Trust. kubo-v2026.07.05 añade un diseño de cuadrícula para tableta opcional para el feed infantil y soporte para adjuntar fotos a mensajes de chat grupal, además de correcciones para el botón de registro que se ocultaba detrás del teclado en pantalla en Android.

Nostr Codex Phone v0.2.9 añade solicitudes auxiliares de git/diff/lectura de archivos

Nostr Codex Phone es una superficie de control móvil para un trabajador de asistente de codificación local que se comunica a través de DMs cifrados de Nostr. v0.2.9 añade acciones de herramientas OpenCode móviles incluyendo solicitudes auxiliares de git, diff, lectura de archivos, estado e historial, mejoras de fijación y búsqueda de sesión, y un control de detención de tareas, junto con un envoltorio de subida cifrada a Blossom que se lanzó en la v0.2.8 anterior.

GitWorkshop v3.0.3 corrige refs recién anunciadas en el explorador de repositorios, y lanza su primera compilación para Android

GitWorkshop es una interfaz web git-sobre-Nostr para explorar y revisar repositorios NIP-34. v3.0.3 corrige las vistas de ramas, etiquetas, commits y exploración de código que fallaban al resolver una ref que un repositorio anuncia después de que el explorador ya la ha cargado, junto con limpieza de tiempos de flujo de CI, confirmado directamente contra la etiqueta y el historial de commits. La misma semana, GitWorkshop publicó su primera compilación nativa para Android en Zapstore, comenzando en v3.0.0 y alcanzando v3.0.3 en horas; la interfaz web sigue siendo la interfaz principal, y el paquete Android trae la misma exploración de repositorios NIP-34 a un teléfono por primera vez.

Bitcoin-Safe llega a Flathub, destacando su plugin Nostr Sync & Chat

Bitcoin-Safe es una billetera Bitcoin de autocustodia construida alrededor de flujos de trabajo con firmantes de hardware. El proyecto publicó un paquete en Flathub esta semana, su primera lista en una tienda de aplicaciones Linux convencional. El lanzamiento en Flathub pone el plugin Sync & Chat de Bitcoin-Safe frente a una audiencia más amplia: el plugin usa mensajes directos NIP-17, a través de la propia biblioteca bitcoin-nostr-chat del proyecto, para sincronizar etiquetas de billetera entre los dispositivos de un usuario y para enviar y recibir PSBTs para co-firma multisig remota entre participantes de confianza. La capa Nostr en sí se lanzó antes, en 2.0.0 (2026-06-29), que rediseñó la firma de transacciones alrededor de un tipo de conexión “Compartir via Chat & Sync” junto con QR, USB y Bluetooth. La noticia de esta semana es el empaquetado en Flathub que pone esa función existente frente a una audiencia Linux convencional por primera vez.

Cambios no publicados

Amethyst permite a las cuentas asignar apodos a contactos con tarjetas NIP-85 cifradas

Más allá de la implementación de Concord cubierta anteriormente, Amethyst fusionó 54 otros PRs en la última semana. El principal entre ellos es PR #3548, que permite a una cuenta asignar un apodo a cualquier otro usuario publicando su propia tarjeta de contacto kind 30382 NIP-85 sobre ellos. El apodo, una nota privada, y cualquier mapeo personalizado de código corto de emoji NIP-30 viven dentro del contenido cifrado con NIP-44 de la tarjeta, de modo que solo la cuenta firmante puede leerlos, y las tarjetas se sincronizan a través del conjunto extendido de relay outbox de la cuenta al iniciar sesión e incrementalmente después. Los feeds, chats y menciones renderizan el apodo en lugar del nombre de visualización público, con una tarjeta de apodo accesible al tocar en la página de perfil encima del nombre real del usuario.

Zap Cooking lanza la Fase 3 de My Kitchen y corrige un error de quórum del pool NDK

Zap Cooking es una aplicación de compartición de recetas y comunidad culinaria construida sobre Nostr. Fusionó 43 PRs continuando su función de planificación de comidas “My Kitchen”, incorporando generación de listas de compras, un selector de recetas y una cuadrícula de planificación semanal en esta fase. El mismo conjunto de cambios corrige un error de quórum de preparación del pool de conexiones de NDK (Nostr Development Kit) que podía dejar lecturas de relay esperando más allá del punto en que un quórum de relay ya había respondido.

Kehto transmite lecturas de outbox antes del descubrimiento de relay

Kehto es un runtime web temprano para applets Nostr NIP-5D, o “napplets”. Fusionó 26 PRs. PR #193 corrige lecturas de outbox que anteriormente esperaban a que la carga de listas de relay NIP-65 terminara antes de abrir cualquier relay, de modo que una carga de lista de relay que nunca se resolvía podía bloquear tanto la entrega de eventos como los tiempos de espera de consulta; la corrección abre hints de relay validados inmediatamente y transmite resultados mientras se descubren los relay de escritura. Un segundo cambio (PR #196) alinea la página de auditoría de identidad del proyecto con NAP-SHELL, el contrato de ciclo de vida de la plataforma Napplet, parte del mismo trabajo de alineación de protocolo visible en otros lugares del lanzamiento napplet/web de esta semana.

Wired y TAO añaden reparto de ingresos de creador con NIP-57

Wired y TAO son clientes gemelos de redes sociales enfocados en libertad de expresión construidos sobre Nostr, compartiendo la misma lista de PRs; ambos fusionaron PR #121, que implementa reparto de ingresos de creador NIP-57 para que los zaps enviados a una publicación puedan dividirse automáticamente entre contribuyentes más allá del autor original. Esto continúa la cobertura del #30 del par elevando su señal de proof-of-work a 21 bits como trabajo no publicado.

Conduit Mono reconstruye la bandeja de pedidos del comerciante alrededor de pago efímero como invitado

Conduit Mono es un protocolo de mercado adyacente a las listas de clasificados NIP-99. PR #174 añade pago como invitado usando una clave efímera generada por el navegador: el invitado envía un pedido cifrado y un reporte de pago al comerciante usando esa clave de un solo uso, y el comerciante hace seguimiento fuera de banda por teléfono o correo, de modo que el comprador nunca necesita una identidad de bandeja de entrada durable. PR #175 reconstruye la bandeja de pedidos del comerciante alrededor de un modelo único de estado de pedido compartido, separando roles de comprador y comerciante y requiriendo un código de seguimiento y transportista antes de que un pedido físico o mixto pueda pasar a enviado. El flujo de pago del proyecto se basa en mensajes privados NIP-17, cifrado NIP-44 y gift wrap NIP-59. El NIP Deep Dive de esta semana cubre las convenciones de Gamma Markets hacia las que este mismo problema de estado de pedido apunta.

Buzz endurece el aprovisionamiento del creador de canal alrededor de kind 39002

Buzz es una plataforma de comunicación de mente colectiva que conecta agentes de IA y humanos sobre Nostr. Fusionó 240 PRs en la última semana, continuando su arco de endurecimiento de la capa de relay desde la cobertura del #30 sobre métricas de turno de agente kind 44200. La corrección de esta semana (PR #1830) trata al creador de un canal como miembro antes de que la lógica de aprovisionamiento de canal kind 39002 se ejecute, cerrando una condición de carrera donde el propio canal del creador podía rechazarlo durante la configuración.

Nostr Docs adopta un firmante NIP-49 con múltiples cuentas y emparejamiento QR

Nostr Docs es una aplicación de documentos colaborativos nativa de Nostr. Fusionó 5 PRs, el notable (PR #50) adoptando el paquete @formstr/signer para autenticación completa NIP-49 con cambio de múltiples cuentas y emparejamiento QR, reemplazando una ruta de firma propia anterior.

También publicado

Correcciones menores de interoperabilidad de firmantes y fiabilidad aterrizaron en varios proyectos rastreados en la última semana sin suficiente superficie nueva para sus propios párrafos: ngit-cli, un cliente de línea de comandos para una alternativa a GitHub basada en Nostr, lanza v2.6.3 haciendo que ngit init dé orientación de configuración accionable en lugar de pedir repetidamente un nsec; Manent, una aplicación privada de notas y archivos cifrados construida sobre Nostr, lanza v1.4.1 corrigiendo el inicio de sesión con firmante Android roto cuando Amber devuelve un pubkey hexadecimal y mejorando el desplazamiento del inicio de sesión bunker; NoorNote, un cliente Nostr delgado y libre de servicios Google, lanza v1.2.8 corrigiendo notificaciones perdidas de grupos Nostrord y añadiendo un interruptor de alerta de publicación propia; Bray, un servidor MCP Nostr consciente de confianza para agentes de IA y humanos, lanza v1.34.0 enviando metadatos de nombre de cliente en conexiones bunker NIP-46; Lumilumi, un cliente web Nostr, cachea listas de relay NIP-65 en almacenamiento local para respaldo sin conexión; Earthly, una aplicación de ciudad y comunidad local basada en Nostr, añade búsqueda geográfica NIP-50; y lnbits, un sistema de billetera y cuentas Lightning gratuito y de código abierto, lanza PR #3925 haciendo que send_nostr_dm publique de forma no bloqueante dentro de un lanzamiento por lo demás enfocado en Lightning.

Recién rastreados y descubiertos

OpenDiscord v1.0.1 se lanza como un cliente estilo Discord sobre Nostr

OpenDiscord es un cliente de servidores y canales estilo Discord construido sobre Nostr con permisos basados en roles y lobbies de voz WebRTC/SFU. v1.0.1 es el primer lanzamiento con instalador etiquetado del proyecto.

Auditable Voting v0.1.140 alinea los roles de organizador, votante y proxy de auditoría

Auditable Voting es un shell de votación solo de cliente sobre Nostr. v0.1.140 alinea los roles de organizador, votante y proxy de auditoría con el evento exacto de definición de cuestionario público firmado por el organizador, cerrando una brecha donde un proxy de auditoría podía actuar sobre cuentas generadas obsoletas o estado persistido de un trabajador u organizador diferente.

Cambium v0.3.2 se empareja con Heartwood como un firmante NIP-55 sin claves

Cambium es la selección Discovery de este número: un firmante Android NIP-55 que no guarda material de clave privada propio, redirigiendo cada solicitud de firma sobre NIP-46 a un firmante de hardware Heartwood compañero. El proyecto comparte la organización de GitHub forgesworn con el proyecto rastreado Bray, y el propio Heartwood fue cubierto en el #30 lanzando el puente de firma relay-a-serial con el que ahora habla el lado Android de Cambium. v0.3.2 pule la hoja de aprobación para advertir en vivo cuando la identidad seleccionada difiere del enlace existente de la aplicación y mueve las escrituras del registro de actividad a una única cola no bloqueante.

También lanzados esta semana: echoes, Dispatch y Linky

Tres lanzamientos más merecen mención esta semana. echoes es una aplicación de notas offline-first y cifrada de extremo a extremo que se sincroniza privadamente sobre Nostr. Dispatch es un organizador de viajes local-first donde cada guardado se cifra con NIP-44 y se respalda sobre Nostr bajo una clave dedicada y no vinculable, y su lanzamiento v0.3.0 añade inicio de sesión Amber NIP-55 para que la aplicación nunca toque la clave privada del usuario directamente. Linky combina contactos y DMs de Nostr con pagos Lightning y Cashu en una sola aplicación web progresiva.

Trabajo de protocolo y actualizaciones de NIP

No se fusionaron PRs en el repositorio de NIPs en la última semana. Se abrieron seis propuestas.

Abierta: kind:10011 conjuntos de seguimiento favoritos

PR #2413, de fiatjaf, añade kind:10011 conjuntos de seguimiento favoritos. Refleja el patrón existente donde kind:10012 (conjuntos de relay favoritos) tiene etiquetas a apuntando a conjuntos de relay kind:30002, extendiendo el mismo mecanismo de favoritos a conjuntos de seguimiento kind:30000 para que un cliente pueda marcar una lista de seguimiento curada sin reemplazar su propia lista de contactos.

Abierta: unidad cifrada privada que extiende NIP-4E

PR #2412, del equipo Form*, propone un evento genérico de Metadata, kind 34578, distinguido por una etiqueta de identificador d y una etiqueta de subtipo t, junto con un sistema de archivos cifrado privado construido encima que ya está implementado en el propio cliente Form* Drive, todavía experimental. Un registro de archivo es un evento de Metadata con t=files: los blobs de archivo viven en servidores Blossom mientras que solo un índice cifrado reside en relay, y cada fragmento de archivo obtiene su propio par de claves efímero con cifrado NIP-44 v2 derivado por HKDF. Un evento compañero de Clave de Cifrado Desacoplada guarda una clave simétrica por unidad contra la que se descifran los metadatos de cada archivo, y se basa explícitamente en NIP-4E, el borrador de abstracción de almacenamiento aún abierto de fiatjaf (PR #1647, abierto desde diciembre de 2024).

Esa única clave por unidad significa que una clave filtrada expone los metadatos de cada archivo en la unidad, no solo uno, ya que los pares de claves efímeros por archivo solo varían la clave de cifrado de fragmento, no la clave de descifrado de metadatos; no existe todavía ninguna ruta de rotación o revocación más allá de publicar un nuevo evento de Metadata advirtiendo que eventos más antiguos pueden perderse. Una segunda propuesta más estrecha alcanza la misma idea subyacente de NIP-4E desde un ángulo diferente: PR #2361, de fiatjaf, desacopla claves de identidad y cifrado dentro de la mensajería NIP-17 específicamente, abierto desde el 1 de junio. Ambos PRs están sin fusionar, dejando esto como una esquina activa y disputada del espacio de diseño. Form* dice que el cliente Drive es experimental con una actualización próxima.

Abierta: NIP-DA compartición privada de datos con permisos

PR #2411, de JAFairweather, es un nuevo borrador NIP-DA para compartición privada de datos con permisos a través de concesiones de datos con alcance. Cada usuario mantiene un registro cifrado y autoritativo por alcance en relay, y el acceso se otorga entregando privadamente la clave simétrica de ese alcance dentro de un gift wrap NIP-59, de modo que los relay almacenan solo texto cifrado y nunca saben quién otorgó acceso a quién; una revocación es simplemente una rotación de clave, sin necesidad de reescribir la copia de cada consumidor. El autor lo posiciona como distinto de los DMs NIP-17 (que pueden llevar una instantánea de datos pero no actualizaciones en vivo ni revocación) y de las listas privadas NIP-51 (que no llevan material de clave), y cita dos implementaciones independientes, una biblioteca de referencia en JavaScript y un CLI en Go sobre go-nostr, probadas cruzadas contra relay.damus.io, nos.lol y relay.primal.net.

Abierta: kinds de paquetes de stickers 10031 y 30031

PR #2410, de vincenzopalazzo, registra kind 30031 (paquetes de stickers direccionables) y kind 10031 (la lista de paquetes de stickers de un usuario) en la tabla de Event Kinds, especificados por el formato “Sonar Stickers” que Sonar lanza esta semana. Los kinds se sitúan deliberadamente un espacio por encima de los kinds de emoji personalizados NIP-30 30030 y 10030 para que un cliente no pueda confundir un paquete de stickers con un conjunto de emojis; los bytes de imagen de stickers viven en servidores HTTPS compatibles con Blossom, y las referencias de stickers enviados llevan un hash en texto plano para que un paquete direccionable editado no pueda cambiar silenciosamente la apariencia de stickers ya enviados en mensajes antiguos. Un PR compañero registra los mismos kinds en el proyecto separado registry-of-kinds.

Abierta: fijación de mensajes NIP-29 con kind:9010 y kind:39005

PR #2379, de Anderson-Juhasc, añade fijación de mensajes a grupos basados en relay NIP-29: kind:9010 update-pin-list es un evento de moderación que lleva la lista completa de eventos fijados como etiquetas e en orden de visualización, de modo que un solo evento puede fijar, desfijar, reordenar o limpiar el conjunto fijado, y kind:39005 es un espejo generado por el relay que expone la última lista aceptada. El diseño reemplaza un enfoque anterior de pares agregar/eliminar de PR #1163 después de retroalimentación de revisión, y elige los números de kind 9010/39005 porque 9009 y 39003 han sido reclamados desde entonces por create-invite y roles de grupo. Anderson-Juhasc también mantiene Nostrord, cuyo v2.2.0 se lanza esta misma semana.

Abierta: reestructuración del descubrimiento de relay NIP-66

PR #2241, de VincenzoImp, es una reestructuración sustancial del descubrimiento de relay NIP-66. Reemplaza la prosa suelta de “Otras etiquetas incluyen” con una sección estructurada de Etiquetas Indexadas, añade una etiqueta W que refleja el campo attributes de NIP-11 para filtrado de descubrimiento de relay, añade una etiqueta de etiqueta l usando espacios de nombres estandarizados (ISO-639-1, ISO-3166-1, IANA-asn, IANA-tz, nip66.label.city), y organiza etiquetas de RTT, SSL/TLS, red, geográficas, DNS y HTTP en secciones dedicadas junto con una nueva tabla de Tipos de Verificación. También corrige eventos de ejemplo rotos que tenían nombres de campo incorrectos, un kind faltante y nombres de tipo de verificación inválidos, y cierra el issue #2171. Todos los cambios mantienen compatibilidad hacia atrás ya que cada etiqueta añadida es opcional.

NIP Deep Dive: NIP-99 y la extensión de comercio Gamma Markets

NIP-15, la especificación original del Mercado Nostr, es heredada a estas alturas: modelaba un puesto de comerciante (kind 30017) con productos (kind 30018) archivados debajo, y los clientes que alguna vez corrieron sobre ella, Shopstr entre ellos, se han trasladado desde entonces a las listas de clasificados NIP-99 como la especificación activa. NIP-99 en sí es un solo evento direccionable, kind 30402 para una lista activa o kind 30403 para un borrador, sin necesidad de crear un puesto primero. Deja todo más allá de la lista indefinido: costo de envío, estado del pedido, recibos, reseñas, y una forma de agrupar varias listas bajo una sola tienda, exactamente las partes de NIP-15 que nunca se transfirieron. Gamma Markets llena ese vacío, y es la capa de comercio moderna que vale la pena entender hoy.

El vacío que NIP-99 deja abierto

El campo content de una lista NIP-99 lleva una descripción en Markdown, price y location están directamente en el evento, y las etiquetas t la hacen buscable como contenido ordinario de hashtag. Como es direccionable por la tupla pubkey, kind y etiqueta d, un vendedor edita una lista en su lugar publicando una nueva versión con la misma etiqueta d:

{
 "kind": 30402,
 "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.",
 "tags": [
 ["d", "keyboard-mx-blue-01"],
 ["title", "Vintage Mechanical Keyboard"],
 ["summary", "Cherry MX Blue, barely used"],
 ["published_at", "1752537600"],
 ["location", "NYC"],
 ["price", "100", "USD"],
 ["t", "electronics"]
 ]
}

Esa es la especificación completa: un anuncio clasificado firmado y actualizable. Cada cliente que implementa NIP-99 para comercio electrónico real, más allá de un clasificado puntual, terminó inventando sus propias convenciones privadas para envío, mensajes de pedido y reseñas. Dos clientes NIP-99 podían renderizar correctamente una lista y aun así no tener una forma compartida de completar un pago entre ellos.

Gamma Markets: estandarizando lo que NIP-99 dejó fuera

Gamma Markets es el nombre que un grupo de trabajo de desarrolladores de mercados Nostr, los equipos detrás de Shopstr, Cypher, Plebeian Market y Conduit Market, dieron a un conjunto compartido de convenciones de comercio electrónico construidas sobre el evento kind 30402 existente de NIP-99. La especificación está enlazada desde el documento canónico de NIP-99 a través de PR #1784 y se mantiene en su propio repositorio, GammaMarkets/market-spec.

Gamma Markets añade dos kinds independientes adyacentes a las listas. Kind 30405 agrupa múltiples listas en una colección de productos, referenciando cada una con una etiqueta a explícita:

{
 "kind": 30405,
 "content": "Summer sale picks",
 "tags": [
 ["d", "summer-picks"],
 ["title", "Summer Sale"],
 ["a", "30402:<merchant-pubkey>:keyboard-mx-blue-01"],
 ["shipping_option", "30406:<merchant-pubkey>:standard-regional"]
 ]
}

Kind 30406 define una opción de envío con precios por país y reglas opcionales de costo basadas en peso o distancia:

{
 "kind": 30406,
 "content": "Standard Regional Shipping",
 "tags": [
 ["d", "standard-regional"],
 ["title", "Standard Shipping"],
 ["price", "5.99", "USD"],
 ["country", "US"],
 ["service", "standard"],
 ["duration", "24", "72", "H"],
 ["weight-max", "30", "kg"]
 ]
}

La creación de pedidos, solicitudes de pago, actualizaciones de estado y envío, y recibos de pago viajan como mensajes privados ordinarios envueltos con gift-wrap NIP-17, divididos en tres kinds por rol, no por re-envolver el transporte: kind 14 lleva comunicación libre entre comprador y comerciante, kind 16 lleva cada transición de estado del pedido (una etiqueta type de 1 a 4 marca creación de pedido, solicitud de pago, actualización de estado o actualización de envío), y kind 17 lleva el recibo de pago del comprador. Un mensaje de creación de pedido se ve así antes del gift-wrapping:

{
 "kind": 16,
 "content": "Please leave the package with the doorman.",
 "tags": [
 ["p", "<merchant-pubkey>"],
 ["subject", "New order"],
 ["type", "1"],
 ["order", "order-8f21"],
 ["amount", "115000"],
 ["item", "30402:<merchant-pubkey>:keyboard-mx-blue-01", "1"],
 ["shipping", "30406:<merchant-pubkey>:standard-regional"]
 ]
}

Calificar una compra completada es un kind direccionable separado, 31555, que apunta a la lista que reseña:

{
 "kind": 31555,
 "content": "Arrived fast, exactly as described.",
 "tags": [
 ["d", "a:30402:<merchant-pubkey>:keyboard-mx-blue-01"],
 ["rating", "1", "thumb"],
 ["rating", "1.0", "quality"],
 ["rating", "0.9", "delivery"]
 ]
}

Llevar los mensajes de pedido sobre NIP-17 significa que un pago de Gamma Markets usa el mismo transporte de mensajes privados que los clientes ya tienen para DMs, en lugar de un kind de mensaje de pedido a medida.

La decisión de diseño central de la especificación es que nada se hereda en cascada. Una lista que pertenece a una colección la referencia explícitamente con una etiqueta a en lugar de heredar automáticamente las opciones de envío o la descripción de la colección, y una opción de envío que una lista usa se referencia de la misma forma explícita. Esa es una reversión deliberada del modelo de puesto de NIP-15, donde un producto heredaba silenciosamente la moneda y la tabla de envío que su puesto padre definía. La compensación es más etiquetado explícito en cada lista, a cambio de que la configuración completa de una lista sea siempre legible desde el evento mismo, sin necesidad de resolver primero un objeto padre.

Dónde aparece esto en la práctica

El trabajo de Conduit Mono de esta semana se sitúa en el mismo territorio de mensajes de pedido que Gamma Markets estandariza: el pago como invitado con clave efímera de PR #174 y la reconstrucción de la bandeja de pedidos del comerciante de PR #175 resuelven el problema de estado de pedido comprador/comerciante que los mensajes kind 14, 16 y 17 de Gamma Markets formalizan; Conduit Mono ejecuta su propio modelo de estado de pedido junto a esos kinds, sin adoptarlos directamente. Shopstr, uno de los cuatro proyectos que escribieron la especificación, también mantuvo su propia plomería de comercio en movimiento la última semana: PR #568 extrae la lógica duplicada de gift-wrap NIP-17 en un módulo compartido, y PR #567 lleva su parser de autenticación HTTP NIP-98 a cobertura completa de pruebas, mantenimiento en exactamente las capas de mensajería y autenticación de las que un flujo de pedidos de Gamma Markets depende para llegar al comprador y comerciante de forma segura.

NIP-15 perdió el rol de tienda al estandarizar un puesto y un producto, y luego dejó pagos, envío, reseñas y estado de pedido como problema de la aplicación. Gamma Markets llena la mayor parte de esa superficie faltante sin tocar la forma de lista única de NIP-99, construyendo sobre la pila de DM existente de Nostr, NIP-17, en lugar de inventar una nueva capa de mensajería.

Eso es todo por esta semana. Si estás construyendo algo o tienes noticias para compartir, contáctanos via DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #30

Wed, 08 Jul 2026 00:00:00 +0000

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

Esta semana: la especificación de Marmot queda marcada como adoptada en 42 archivos mientras MDK publica de v0.9.0 a v0.9.3 con avatares de grupo cifrados, soporte para firmantes externos y bindings de MarmotKit para iOS y Android. Mostro lanza Transport v2 sobre mensajes directos NIP-44, con barreras antispam y una ventana de coexistencia tanto en mostrod v0.18.0 como en Mobile v1.3.0. Bitchat 1.6.0 añade prueba de trabajo NIP-13 a los mensajes de canales geohash, un gateway opcional de malla a Nostr que permite a un solo teléfono conectado enlazar a toda una multitud, bundles de prekeys, verificación transitiva y grupos privados cifrados gestionados por su creador. Amber limita las suscripciones de perfil por cuenta, obtiene las listas de relays NIP-65 antes que los metadatos del perfil y añade una notificación en vivo del estado de Tor con una acción de reinicio. rust-nostr añade expiración NIP-40 a los builders de gift wrap y DM NIP-17, anclada al timestamp aleatorio del wrap. Amethyst integra 43 PR de refuerzo de la sincronización negentropy, infraestructura de búsqueda de texto completo NIP-50 y kinds para sectores especializados. Nostrord publica v2.0.0 y v2.1.0 con un pool de relays unificado, detección de WebSockets zombis y una separación completa de caché con disco primero. También llegan Ngit v2.6.2, Jumble v26.7.1, Applesauce signers 6.2.2, Bray v1.33.0, Deepmarks 1.0.0, Bitcredit Core v0.5.13, Coop Mobile v0.2.4, Granary v11.0, Nostr-relay v0.0.244, Manent v1.4.0, Routstrd v0.3.7, Nymchat 1.0.1 y 21Meetup 1.1.0, mientras SafeBox da la Fase 3 por prácticamente terminada, junto con una guía de despliegue en una jail de FreeBSD y OpenETR, un spin-off para documentos electrónicos transferibles. El repositorio de NIPs integra una armonización del nombre entre NIP-51 y NIP-37 y abre cinco propuestas: NIP-AD Nostr Web Addresses, gestión de claims de códigos de invitación en NIP-86, un formato de color HSL para roles, procedencia de medios acreditada por hardware en NIP-80 y una corrección de la paginación en NIP-01. Los análisis en profundidad cubren NIP-13 (prueba de trabajo) y NIP-40 (timestamp de expiración).

Historias principales

Marmot marca la especificación como adoptada y MDK publica v0.9.x

El repositorio del protocolo Marmot integró la PR #170 el 3 de julio y cambió 42 archivos de Status: draft for internal review (y experimental draft) a Status: adopted. El título del README dejó de presentar el repositorio como un trabajo en curso y pasó a ser “Marmot Protocol” como texto adoptado; los documentos de la era MIP se replantearon como la versión obsoleta del protocolo; y la sección “Review Status” (“This is not adopted spec text yet”) se convirtió en “Review Guidance” para editar la especificación vigente. La etiqueta v2 desaparece: expresiones de contraste con MIP como “new in v2” y “the v2 spec keeps” pasan a ser “this spec” y “under this spec”. Dos documentos conservan deliberadamente el estado de borrador: implementation-model.md sigue siendo no normativo y el documento de la función multidispositivo continúa como borrador.

El mismo repositorio incorporó la PR #171, que alinea las invariantes de política de administración, membresía y cambios de rol. La comprobación transversal que impide que un Remove deje al grupo sin admin se expresa ahora como propiedad de cada epoch resultante, evaluada respecto al conjunto de admins del epoch anterior cuando un commit no incluye una actualización de la política. La regla de ramas candidatas de Convergence se endurece: “validates” significa la validez completa del commit, incluidas las comprobaciones transversales del epoch resultante, por lo que un commit que viola una invariante no puede crear una arista candidata en ninguna rama. Las notificaciones de estado derivadas de un commit sustituido DEBEN retirarse cuando la selección de rama lo reemplaza, cerrando en la especificación el fallo por el que un cambio de nombre perdedor aparecía como mensaje de sistema correcto. Una nueva sección “Realizing removal” de member-departure.md define la entrada primaria (el commit canónico aceptado que elimina tu última leaf) y la alternativa para clientes que nunca aplicaron ese commit: la evidencia autenticada posterior a la expulsión produce ahora SelfEvicted, conservando como inactiva la copia del grupo eliminado. Después, la PR #236 endureció la validación en el límite de wire: fija la vida aceptable de KeyPackage en 84 días más una hora de margen, añade una tabla de cardinalidad de tags Nostr para h de grupo, p de gift wrap, e y relays de welcome y tags de KeyPackage, y aclara que ids y metadatos de eventos Nostr no verificados no constituyen evidencia fiable de routing, replay ni telemetría.

Más abajo en la cadena, el workspace de MDK publicó v0.9.0 el 6 de julio con una actualización de versión de todo el workspace, seguida de v0.9.1, v0.9.2 y v0.9.3 durante los dos días siguientes. v0.9.0 rota entradas obsoletas del keyring al crear una nueva base SQLite e impone validar antes de mutar en toda la capa de almacenamiento. v0.9.1 encamina cada conexión saliente por un único punto de control de seguridad del host mediante la PR #732, cerrando los fallos en los que distintos call sites alcanzaban la red con validaciones diferentes. v0.9.3 expone avatares de grupo cifrados en los bindings uniffi mediante download_group_image e image_hash_hex en la PR #771, añade soporte para firmantes externos y declara wn-opencode listo para producción mediante la PR #781. Junto a estas versiones, MarmotKit publica bindings de iOS y Android para cada versión: MarmotKit.xcframework y bindings Swift en iOS, y bindings Kotlin con bibliotecas JNI en Android, generados a partir de un hash de commit fijo de MDK. Un nuevo canal de versiones de wn-agent ofrece instaladores de shell que fijan WN Agent a un tag inmutable para que las apps obtengan el agente actual con un solo comando curl.

Mostro v0.18.0 y Mobile v1.3.0 lanzan Transport v2 sobre NIP-44

Mostro es el protocolo de compraventa peer-to-peer de Bitcoin que ejecuta libros de órdenes, escrow y resolución de disputas sobre eventos Nostr, coordinado por un daemon (mostrod) con el que los clientes se comunican mediante DM cifrados. Hasta esta semana, el protocolo wire entre clientes y mostrod era Transport v1. Mostro v0.18.0 incorpora Transport v2 sobre mensajes directos NIP-44, con barreras antispam y recepción dual en el servidor. La PR #776 contiene el cambio wire de la Fase 1; la PR #780 añade las barreras antispam de la Fase 2; y la PR #785 hace que la versión interna siga al transporte activo, permitiendo que clientes v2 y v1 coexistan durante la migración. La PR #782 corrige además un tag informativo NIP-33 al renombrar protocol_versions como protocol_version. La versión incorpora también una ruta unificada de cotización en vivo de Fase 4 con caché y control de antigüedad (PR #783), y El Toque como proveedor de cruces fiat para los pares cubanos CUP y MLC (PR #778). La PR #779 notifica a la parte penalizada cuando una disputa le quita la fianza; antes el usuario solo veía que faltaba saldo.

Mostro Mobile v1.3.0 es la mitad cliente de la migración. La PR #613 migra la app a Riverpod 3.x; la Fase A (PR #620) añade recepción dual de mensajes NIP-44 en el isolate principal y en segundo plano; la Fase B de la PR #624 añade envío dual; la PR #632 lo vuelve a aplicar tras el cambio a Riverpod 3.x; y la Fase C de la PR #637 finaliza la migración. La versión amplía también los métodos de pago africanos: la PR #625 añade la kwacha malauí y la PR #627 incorpora KES, MZN, TZS, UGX, ZAR y ZMW, además de ampliar NGN. El flujo de restauración espera ahora a que el nodo tenga conectividad, y el tratamiento según la causa distingue entre pérdida de fianza por disputa y por timeout.

Bitchat 1.6.0 añade prueba de trabajo NIP-13 y un gateway opcional de malla a Nostr

Bitchat 1.6.0 es la app de chat en malla Bluetooth que usa Nostr para sus canales geohash y la entrega de DM. La PR #1382 añade NIP-13 (prueba de trabajo) a los mensajes salientes de canales geohash, eventos efímeros kind 20000: cada envío mina un tag ["nonce", "<value>", "<target>"] antes de publicar, con un objetivo de 8 bits cero iniciales. Eso supone una media de 256 hashes y tarda menos de un milisegundo en un Mac serie M. Los eventos entrantes con PoW validada relajan el límite por remitente, de modo que el spammer paga cómputo por mensaje sin que un remitente normal perciba el coste. El alcance es deliberadamente estrecho: solo los mensajes kind 20000 minan PoW; los heartbeats de presencia kind 20001, las notas de ubicación kind 1 y los DM no cambian.

La PR #1384 añade el modo gateway, un enlace ascendente opcional de la malla a Nostr para canales geohash. Cuando un usuario solo en malla, sin internet ni relay accesible, envía un mensaje y otro peer anuncia la capacidad .gateway, el evento kind 20000 firmado se envuelve en un nuevo sobre TLV MessageType.nostrCarrier = 0x28 y se dirige a un gateway. Ese peer publica el evento en Nostr por cuenta del remitente y retransmite a la malla el tráfico entrante con el TTL predeterminado. El uplink usa la ruta del sobre courier, dirigida y retransmitida en varios saltos; el downlink usa broadcast. El evento se firma antes de salir del remitente, por lo que el gateway decide si publicarlo pero no puede falsificar la atribución. La motivación son desastres y protestas donde basta un teléfono conectado para dar a toda la multitud un uplink Nostr operativo.

La misma versión incorpora otro bloque de trabajo relacionado. La PR #1381 añade bundles de prekeys para un primer contacto asíncrono con forward secrecy mediante courier mail: se puede escribir a un peer offline y entregar el mensaje a la malla sin un handshake Noise en vivo. La PR #1380 añade verificación transitiva: alguien que ha completado el handshake Noise con un contacto ya verificado queda avalado sobre esa sesión, propagando la confianza un salto cada vez. La PR #1383 añade grupos privados cifrados gestionados por su creador; la PR #1376 detecta, muestra y canjea tokens ecash Cashu con /pay; y la PR #1379 añade un tablón geohash persistente y firmado sobre la sincronización de malla. La PR #1372 amplía store-and-forward con couriers abiertos, routing spray-and-wait, outbox persistente y seis horas de historial público. Bitchat 1.5.4 se publicó al principio de la semana con la corrección integral de favoritos de la PR #1367, que limpia duplicados en la lista de peers, la sincronización Nostr y la corrupción de claves /fav.

Versiones etiquetadas

Amber v6.2.3 limita las suscripciones de perfil y añade una notificación del estado de Tor

Amber v6.2.3 mejora rendimiento y corrección en el firmante Android NIP-46. Añade un intervalo configurable para obtener perfiles, con opciones nunca y siempre (PR #492); muestra la foto en el selector de cuenta; y limita las suscripciones de perfil a la cuenta actual, evitando que un firmante multicuentas mantenga suscripciones para cuentas inactivas. El parser de permisos bunker trata explícitamente los errores. Corrige además varias infracciones de StrictMode: DiskReadViolation en el log onSuccess de Coil, acceso al keystore al cargar la cuenta en el hilo principal, lecturas del nombre y foto de la cuenta y construcción anticipada de KeyPair() en login y registro. Tras v6.2.3, la PR #493 reordenó el arranque para obtener la lista de relays NIP-65 antes de los metadatos del perfil; la PR #494 convirtió la notificación de Tor en un indicador vivo con reinicio; y la PR #495 activó Android Lint con warnings como errores en todo el código.

Jumble v26.7.1 convierte Blossom en el servicio de subida predeterminado en una versión centrada en DM

Jumble v26.7.1 es una versión del cliente web centrada en mensajes directos y medios. Rediseña los ajustes de subida y establece Blossom como servicio predeterminado en lugar de NIP-96. Los DM reciben menú móvil, mejores acciones en escritorio, botón para ir al último mensaje, reacciones por pulsación larga y reintento de envíos fallidos. También mejora el editor de emojis personalizados, el tamaño de burbujas para facturas y contenido incrustado, el orden y scroll de DM, la inserción de emojis, la copia de texto y el arrastre de archivos. Corrige la orientación de imágenes al eliminar metadatos y añade descargas Linux ARM64.

Applesauce signers 6.2.2 elimina una dependencia de nbunksec

applesauce-signers@6.2.2 sustituye la dependencia @sandwichfarm/encoded-entities por un helper integrado de nbunksec mediante el commit d654349. La codificación de sesiones bunker NIP-46 ya no necesita la biblioteca externa, reduciendo una superficie de supply chain para clientes que consumen el paquete.

Ngit v2.6.2 evita eventos de estado de PR duplicados al hacer push a la rama predeterminada

Ngit v2.6.2 corrige el CLI git-over-Nostr. git push a la rama predeterminada deja de publicar estados duplicados de merge/applied para PR ya aplicadas, porque la detección consulta ahora el estado Nostr del repositorio anterior al push, fuente de verdad en el lado NIP-34. El heurístico previo dependía de internals de git. Los repositorios activos dejan así de emitir eventos kind 1621 duplicados.

El CLI Bray v1.33.0 incorpora perfil bunker, persona y salida por Tor

Bray v1.33.0 añade a bunker --profile <name> una clave de conexión estable automática y fallback de relay; bunker --persona <name> firma como una identidad derivada de un árbol nsec; y todas las peticiones HTTP pueden pasar por un proxy SOCKS de Tor. La versión suma subcomandos de wallet para NWC NIP-47, operaciones de administración de grupos NIP-29, verbos NIP-86 y helpers de outbox NIP-65. Los verbos de publicación incorporan --jsonl, --csv, --tsv, req, event, publish-raw, bunker sign y --relay por comando. El trabajo de seguridad cubre zeroisation de secretos, bearer auth y rate limits HTTP, y validación SSRF de URLs de relays. El tarball npm ocupa 533.844 bytes y su build reproducible idéntico se verificó en dos runners CI independientes.

Deepmarks 1.0.0 endurece la superficie de marcadores Nostr

Deepmarks 1.0.0 es un hito de seguridad para un servicio público de marcadores Nostr, donde cada marcador sigue siendo un evento firmado. La API y el worker pueden alcanzar Redis interno, el relay del bunker y metadatos cloud, por lo que la defensa SSRF es crítica. La versión corrige un bypass con literales IPv6 en isPrivateIp: [::1], [fd00::1] y [::ffff:10.0.0.4] se clasificaban como públicos. Ahora elimina corchetes y reduce IPv6 compatible o mapeado a IPv4 antes de comprobar rangos privados. Los perfiles kind:0 externos se verifican en el sink para impedir que un relay hostil falsifique nip05 o lud16; las URLs se validan por esquema en cada render para bloquear tags d javascript: o data: en marcadores kind:39701. Los recibos de zap sobreviven a una caída temporal del bunker: el handler reclama el zap pendiente atómicamente, finaliza tras firmar y libera el claim si falla. El drenaje de /publish usa BLMOVE hacia una lista por worker con recuperación condicionada por heartbeat, preservando eventos firmados aunque el worker caiga tras responder 202.

Bitcredit Core v0.5.13 deja sin cifrar los metadatos de bloque en el wire de Nostr

Bitcredit Core v0.5.13 elimina una capa de cifrado de los eventos públicos del protocolo de letras de crédito. Los metadatos de bloque (id, hash y firma) quedan sin cifrar; solo los datos del bloque siguen cifrados con la clave de la letra. Las apps nuevas procesan cadenas antiguas, pero las antiguas no procesan cadenas nuevas. Añade una función para obtener la cadena y publicación con umbral optimista: al aceptar un relay, por defecto, los demás reciben el evento asíncronamente, sin bloquear por el más lento.

Coop Mobile v0.2.3 y v0.2.4

Coop Mobile publicó v0.2.3 el 4 de julio y v0.2.4 el 7. El cliente Android de DM NIP-17 añade imágenes y enlaces inline, adjuntos, dictado y confirmación al eliminar contactos. v0.2.4 corrige un indicador bloqueado, mejora el handshake Nostr Connect y añade importación ncryptsec1, el formato de clave privada cifrada NIP-49, con una pantalla de importación rediseñada.

Granary v11.0 añade soporte para eventos de vídeo NIP-71

Granary v11.0 es la biblioteca de conversión multiprotocolo que impulsa Bridgy Fed. Los eventos de vídeo NIP-71 (kinds 21, 22, 34235 y 34236) se convierten ahora en notas ActivityStreams 1 con adjuntos; extrae imeta, duración, published_at y alt como displayName alternativo. En la API, sign pasa a llamarse hash_and_sign; verify y el constructor Nostr lanzan ValueError al fallar; y Nostr.query omite correctamente el desafío AUTH NIP-42 sin privkey. Otra corrección evita fallos cuando un objeto Nostr article carece de id.

Nostr-relay v0.0.244 añade un backend Firestore

mattn/nostr-relay v0.0.244 añade Firestore mediante la PR #12, ofreciendo a operadores del relay una base serverless gestionada de Google Cloud junto a los backends existentes.

Manent v1.4.0 corrige AUTH NIP-42 y añade flujos de portapapeles multimedia

Manent v1.4.0 es una app de notas y archivos cifrados sobre Nostr con cifrado NIP-44, firmantes NIP-46 y NIP-55, routing outbox NIP-65 y Blossom. Corrige AUTH NIP-42, subidas Blossom a hosts http:// y el flujo de compresión. Ahora permite copiar y pegar imágenes, arrastrar archivos, recortar y girar imágenes, reproducir vídeos y gifs y grabar vídeo con una pulsación larga. En Linux, el portapapeles primario funciona con clic central. También optimiza carga y scroll.

Routstrd v0.3.7 convierte el almacén de eventos Nostr en la fuente de verdad persistente

Routstrd v0.3.7 es el daemon local de la red descentralizada de inferencia de IA Routstr, que descubre proveedores con kind 38421 y reseñas LGTM con kind 38425. routstrd update descarga binarios de routstrd y cocod y reinicia limpiamente los daemons. refreshNostrEvents() se ejecuta al arrancar y cada 21 minutos. @routstr/sdk pasa de 0.3.12 a 0.3.15, elimina ProviderRegistry en favor de DiscoveryAdapter, limpia modelos de proveedores desaparecidos y trata el almacén de eventos como fuente persistente, eliminando el TTL erróneo de 210 minutos. En reembolsos Xcashu prueba primero los tokens de devolución, reintenta los 404 tres veces cada dos minutos y trata 425 Too Early sin lanzar error.

Nymchat 1.0.1 se lanza como Progressive Web App sobre NIP-17

Nymchat 1.0.1, también NYM o Nostr Ynstant Messenger, es una PWA y app iOS/Android para chat efímero sobre Nostr conectada con Bitchat. Usa kind 20000 en canales geohash, kind 23333 en canales con nombre y gift wraps NIP-17 kind 1059 para privados y grupos, con claves efímeras rotatorias y recuperación post-compromiso. Permite identidad efímera por sesión o persistente mediante extensiones NIP-07, firmante remoto NIP-46 o nsec. El cifrado local opcional usa contraseña, PIN, passkey o biometría mediante WebAuthn PRF o PBKDF2, sin escribir la clave en claro. Las llamadas usan gift wraps para señalización y WebRTC para medios. Las reacciones usan NIP-25, los emojis NIP-30, y Cloudflare Pages Functions actúa como proxy de privacidad.

21Meetup 1.1.0 lanza insignias de asistencia firmadas con Nostr

21Meetup 1.1.0 es una app Flutter para la comunidad alemana Einundzwanzig que registra asistencia con NFC y QR rotatorios. Cada insignia es un evento Nostr kind 21000 firmado por el organizador con Schnorr BIP-340. El QR cambia cada 10 segundos y el NFC exige proximidad, impidiendo acuñación remota. Una puntuación de confianza se calcula localmente y puede mostrarse como QR en intercambios peer-to-peer. Se orienta a reputación en comunidades Bitcoin, pero cualquier lector puede verificar los eventos.

Nostrord v2.0.0 y v2.1.0 unifican el pool de relays y curan WebSockets zombis

Nostrord v2.0.0 es una versión mayor del cliente KMP/WASM compatible con NIP-29, NIP-42, NIP-44, NIP-46, NIP-57, NIP-65 y NIP-98. v2.0.1 llegó un día después mediante la PR #166: los paquetes 2.0.0 fallaban al iniciar con NoClassDefFoundError: java/sql/DriverManager porque la imagen jlink no incluía java.sql, dependencia de SQLDelight. La corrección añade el módulo y encamina el envío optimista por la red en lugar de limitarse a cachearlo, además de mejorar teclado y scroll en web móvil.

v2.1.0 llegó el 7 de julio con la unificación del pool (PR #176). El socket NIP-29 separado entra en el pool común; un scheduler reconecta todos los relays; AUTH NIP-42 tiene reintentos acotados; la publicación falla de forma segura y reintenta cuando se exige auth; se cierran carreras de tormentas de peticiones; las listas kind 10009 se agrupan por relay; y mux_chat cubre todos los grupos unidos y se recupera si un relay descarta la suscripción. La UI sustituye la fila “Sending…” por iconos inline y ofrece Retry al atascarse el historial. La PR #179 detecta WebSockets zombis en Android: lastInboundAtMs se actualiza con cada frame, markDead() activa la ruta normal de reconexión y probeLiveness() exige respuesta en cinco segundos. También impide escribir mensajes optimistas en caché persistente antes de confirmar la entrega. v2.1.1 añadió actuals de iOS, tests nativos e iconos mediante la PR #178.

Cambios aún no publicados

rust-nostr añade expiración NIP-40 a builders de gift wrap y DM privados

rust-nostr integró la PR #1384, que añade una opción expiration a GiftWrapBuilder y PrivateDirectMessageBuilder. La biblioteca recibe una Duration: el tag NIP-40 se ancla al created_at aleatorio del gift wrap, desacoplándolo del envío real. Un timestamp absoluto filtraría la hora de envío al observador, por lo que la biblioteca construye el tag internamente. Va en el gift wrap, no en el seal kind 13, que NIP-59 exige sin tags. NIP-17 transmite el mismo valor desde PrivateDirectMessageBuilder. El cambio cierra el issue #1381 con el patrón de builder usado para extra_tags. La PR #1387 integra además nostr-relay-builder en nostr-sdk.

Amethyst dedica la semana a reforzar negentropy y añadir búsqueda NIP-50

La rama main de Amethyst integró 43 PR en tres frentes. En sincronización negentropy entre geode y strfry, el fallo refused-window deja de provocar bucles de división y retrocede limpiamente (PR #3480); negentropyKmp pasa a v1.1.1 (PR #3475); llega un benchmark de un millón de eventos con espejo de paridad strfry (PR #3478); y benchmarks de producción entran en CI con más optimizaciones (PR #3458, PR #3466). Colecciones concurrentes lock-free sustituyen el mutex por relay y se corrige el threading UDP (PR #3459).

El segundo frente es la búsqueda de texto completo NIP-50. Una interfaz SearchableEvent permite llevar metadatos de índice (PR #3452); las extensiones NIP-50 se eliminan antes de consultar SQLite FTS para no pasar sintaxis del servidor al motor local (PR #3464); y se centralizan los relays de búsqueda predeterminados (PR #3446).

El tercero integra sectores especializados: eventos Birdstar de detección de aves kind 2473 (PR #3473) y estados de tarjetas de memoria PS1 como eventos firmados kind 38192 (PR #3482). Completan la semana una firma personalizada automática (PR #3450), notificaciones de escritorio rediseñadas (PR #3457), bloqueo de privacidad en Messages (PR #3432), escritura local en NostrServer.ingest con omisión de verificación por envío (PR #3469) y contratos equals/hashCode corregidos en OpenTimestamps (PR #3477).

Buzz sigue reforzando el relay y define kind 44200 para métricas de turnos de agentes

Buzz, antes Sprout, integró 123 PR entre el 1 y el 7 de julio. La PR #1441 define métricas cifradas y duraderas NIP-AM de turnos de agentes como kind 44200, archivadas como eventos firmados en el relay del usuario. Le siguen un archivo local (PR #1555), eliminación atómica del kind (PR #1562) y el nombre del modelo en la emisión para distinguir cada turno (PR #1564).

El segundo frente es el rendimiento del relay. Se aplaza el dispatch posterior al commit y se evita clonar para verificar (PR #1453); se agrupan round trips de ingest y fan-out, reduciendo p99 entre 7 y 16% y p999 entre 29 y 53% (PR #1454); las consultas multifiltro tienen concurrencia acotada (PR #1457); y los frames WebSocket salientes se agrupan (PR #1464). Los admins pueden configurar iconos por comunidad servidos mediante NIP-11 (PR #1463); los propietarios borran mensajes de sus agentes con eventos kind 5 (PR #1519); OpenTelemetry acompaña a Prometheus (PR #1398); y el registro de nombres git pasa a Postgres (PR #1432).

Divine Video conecta la verificación de firmas del relay y extrae NostrConnect

La app móvil de Divine Video integró 97 PR. La PR #5774 verifica firmas de eventos entrantes; la PR #5828 cifra el token push FCM en el evento de baja kind 3080; y la PR #5831 fragmenta la REQ de borrado kind 5 para usuarios con mucho historial. La PR #5826 extrae NostrConnectCoordinator para el flujo nostrconnect://, limpiando la ruta del firmante remoto NIP-46 y preparando la refactorización de auth del issue #4741. La PR #5709 mapea reposts kind 16 cuando falta notification_type.

El frontend de Zap Cooking integró 18 PR. La PR #503 corrige el login bunker con handshake explícito, tratamiento de authUrl y errores visibles. La PR #495 añade auth NIP-98 a subidas de imagen y texto para atribuirlas a una pubkey. La PR #483 incorpora búsqueda NIP-50 mediante el relay nostrarchives sin índice del cliente. También muestra notas citadas y medios directamente (PR #491), añade previews y tamaños de hashtags (PR #492), consultas de varias palabras (PR #482) y tarjetas sociales generadas en servidor (PR #494).

swift-nostr-client v0.6.0 avanza hacia una primera versión estable

yysskk/swift-nostr-client publicó v0.6.0 junto a 30 PR. La biblioteca se acerca a una API estable para clientes Swift que no enlazan MDK ni MarmotKit.

Nostr Applet Protocol (NAPS) endurece el routing y fanout de NAP-OUTBOX

NAPS tuvo una semana de limpieza, sobre todo en NAP-OUTBOX: menos routing controlado por el caller, menos detalles de relays filtrados y un resultado de evento compartido con hints y sidecars de recursos, enlazado con NAP-RESOURCE. Las reglas explícitas de fanout a outbox, inbox y relay reducen la ambigüedad y mejoran la interoperabilidad.

El toolchain de Napplet refuerza la alineación con el protocolo y lanza su CLI

Los paquetes Napplet pasan de un SDK útil a un toolchain más cohesionado: soporte de consultas NAP-COUNT, ciclo de vida de OUTBOX controlado por runtime y sidecars RelayEventResult. También mejoran el registro CVM, envelopes de error DM, contexto de sesión MEDIA, contadores LISTS, resultados COMMON y el esquema htree: RESOURCE. El nuevo @napplet/cli añade descubrimiento de configuración, planes de despliegue, firma, subidas Blossom y manifiestos. El prelude inyectable por el host y la preparación para JSR facilitan inyectar, publicar y verificar el stack.

primal-android amplía la superficie del firmante remoto

Primal Android integró 18 PR. La PR #1075 implementa switch_relays y logout para el rol de firmante remoto NIP-46. La PR #1083 añade migraciones locales tras la splash y la PR #1080 precarga el feed de notas. El resto pule barras de Home, hints de Explore y perfiles.

Wisp añade selector multicuentas y tests del parser de Blossom

Wisp integró 9 PR. La PR #604 añade selector multicuentas con cancelación explícita. La PR #613 prueba Blossom.parseServerList y endurece el parser de listas de servidores Blossom. La PR #574 rehace la hoja de zap para iOS; la PR #605 convierte el historial en una hoja deslizable; la PR #611 reconoce hashtags Unicode; la PR #609 mantiene la paginación del feed y muestra galerías inline; y la PR #603 conserva líneas vacías antes de perfiles y hashtags inline.

TAO y Wired elevan la señal PoW a 21 bits y muestran raíces con PoW reciente

smolgrrr/TAO y smolgrrr/Wired integraron los mismos 13 PR. La PR #84 eleva el objetivo de prueba de trabajo predeterminado a 21 bits cero iniciales; la PR #80 muestra raíces del feed con PoW reciente para ordenar por trabajo NIP-13, no solo por antigüedad. La PR #75 recupera el selector de emojis y la PR #65 añade previews del primer frame. Es el segundo cliente de la semana que usa NIP-13 como filtro principal, junto con Bitchat.

keep-android pule la UX NIP-46 e incorpora una corrección TOCTOU

privkeyio/keep-android publicó v1.1.5 con 13 PR y v1.1.6 el 8 de julio, fijando keep core v0.5.0. Keep es una bóveda de identidad móvil, descrita como CustID en el número #29. v1.1.5 pule el desafío NIP-46. v1.1.6 cierra una carrera TOCTOU en set_active_share, muestra URL y método en la aprobación HTTP NIP-98 y hace que el chequeo RNG devuelva error en vez de panic. Un test instrumentado cubre el kill switch NIP-55. Las funciones CLI v0.5.0 (desbloqueo threshold-OPRF, DKG por software y wallets HD FROST) aún no se exponen en Android.

Heartwood lanza el puente de firma de relay a serial

forgesworn/heartwood v0.7.0 entrega el puente relay-a-serial para el data plane HSM del firmante serial de Bray. La PR #11 contiene el puente; la PR #13 añade cobertura de frames y corrige el offset de read_frame; y la PR #14 extrae el codec a la crate compartida heartwood-frame.

SafeBox publica un informe de Fase 3 y una guía para jail de FreeBSD

SafeBox es una bóveda privada portátil sobre Nostr que combina Nostr Wallet Connect NIP-47, nAuth, nembed y transferencia de registros mediada por relays mediante QR y NFC. Un informe de julio de 2026 publicado el día 6 marca la Fase 3 como prácticamente terminada: 49 commits desde abril, hasta 1.136 en total, y cuatro compromisos de ingeniería mayormente cumplidos. El siguiente paso es un piloto acotado; un proveedor de telecomunicaciones bajo NDA estudia un piloto de historiales médicos.

El trabajo concreto incluye colas para acciones NWC mutables que evitan carreras de proofs, protección de proofs tras melts Lightning fallidos, renovación proactiva de listeners NWC y callbacks LNURL con orígenes canónicos, JSON y CORS explícitos. El intercambio QR/NFC ganó un flujo unificado para modos presentados por receptor, remitente y entre dispositivos, con KEM y protección replay mediante Open Quantum Safe. El commit 6866dae añade una guía de jail FreeBSD y build de liboqs y una especificación de appliance FreeBSD, con snapshots ZFS, aislamiento, servicios rc.d, proxy inverso y rollback en FreeBSD/ARM.

El informe anuncia además OpenETR, un spin-off que aplica control criptográfico y registros portátiles a conocimientos de embarque, recibos de almacén, pagarés y certificados electrónicos transferibles. El repositorio sumó 7 commits el 7 de julio: ea612a9 separa attestation del registro; ca153a3 trata mandato frente a efecto; y ba84b61 compara formatos de credenciales verificables.

Trabajo de protocolo y actualizaciones de NIPs

Integrado: NIP-51 y NIP-37 alinean el nombre del kind 10013

La PR #2404 corrige solo la prosa. En NIP-37, kind 10013 se llama Relay List for Private Content; en NIP-51 bajo Draft relays tenía otro nombre. NIP-51 adopta ahora el de NIP-37. No cambia el wire ni los tags, pero evita ocultar que ambas especificaciones describen el mismo kind.

Abierto: NIP-AD Nostr Web Addresses mediante consulta .well-known

La PR #2406 sucede a la cerrada #2393 con un borrador completo en AD.md. NIP-AD define URLs web con contraparte Nostr opcional. Ante https://golf.com/players, un cliente pide https://golf.com/.well-known/nostr.json?ad=/players, que devuelve un objeto JSON que asigna rutas a pares {filter, relays}. El filtro es NIP-01 y la lista indica qué relays consultar. Con "limit": 1 resuelve a un evento; sin él, a una lista. Un navegador sigue mostrando HTML en la misma ruta canónica. Los casos de uso incluyen nombres de grupos NIP-29 que resuelven a kind 39000, búsquedas nsite NIP-5A, feeds con {"ids": [...]}, render nativo de URLs de eventos y blogs Nostr accesibles dentro y fuera del protocolo. El diseño permite que el resolver sea un archivo estático.

Abierto: gestión de claims NIP-86 para códigos de invitación

La PR #2408 propone tres métodos para NIP-86: listclaims (params [], devuelve códigos NIP-43), createclaim (params [claim], devuelve true) y deleteclaim (params [claim], devuelve true). NIP-86 permite administrar usuarios y roles, pero no invitaciones. Un admin podría crear un código ligado a un rol, cobrar antes de crear la identidad, entregarlo y dejar que un bot escuche el evento claim kind 28935 para asignar automáticamente el rol. Todo el flujo quedaría dentro del RPC de gestión del relay.

Abierto: color de rol como tupla (h, s, l)

La PR #2402 cambia el color de rol de NIP-43 de un único hue a una tupla hue, saturation y lightness. Se admiten strings vacíos para que los clientes elijan valores coherentes; se recomienda indicar solo hue salvo colores específicos. En NIP-86, createrole y editrole reciben ahora [id, label, description, [h, s, l], order]. Con solo hue, distintos clientes escogían saturación y luminosidad diferentes y mostraban el mismo rol con intensidades distintas.

Abierto: procedencia multimedia acreditada por hardware en NIP-80

La PR #2409 abre NIP-80, un formato de procedencia anclado al hardware de captura. La cámara firma cada foto y publica la prueba identificada por el contenido, de modo que sobrevive a la eliminación de metadatos, el realojamiento y las retiradas. Define kind 1080 para attestations de captura; 1081 para derivaciones como resize, crop, recompresión o redacción; 1082 para revocaciones; 11080 para anuncios de dispositivos; 31080 para endorsements; y 31081 para conjuntos de dispositivos anónimos, experimental. Reutiliza tags x NIP-94, imeta NIP-92, descubrimiento NIP-65, almacenamiento Blossom y anclaje temporal opcional NIP-03. Empareja una clave BIP-340 con ECDSA de hardware porque los secure elements habituales aún no generan BIP-340. La attestation no prueba que la escena sea real, sino que esa imagen procede de ese dispositivo aproximadamente a esa hora y solo sufrió cambios declarados. La especificación prohíbe reducir el resultado a una insignia “auténtico”. El prototipo OpenVeilCam, runtime Rust para Raspberry Pi con ATECC608, se actualiza para publicar estos kinds y verificarlos.

Abierto: endurecimiento de la paginación NIP-01

La PR #2407 añade “Pagination & limits” a NIP-01. Un relay que imponga limit máximo DEBE fijarlo por encima del mayor número de eventos con un mismo created_at, evitando que un segundo llene la página. Los clientes que paginan hacia atrás DEBEN repetir con until = oldest, inclusive, y deduplicar por id; terminan cuando una ronda no aporta ids nuevos. Si toda la página comparte timestamp, DEBEN reintentar ese segundo con mayor limit. Si el relay lo recorta y sigue devolviendo un único segundo, DEBEN avanzar con until = oldest - 1, aceptando pérdidas, o abortar. La paginación normal NO DEBE indicar limit; elevarlo para vaciar un segundo atascado es la excepción. Esto evita omitir o reprocesar eventos con timestamps duplicados.

Análisis en profundidad: NIP-13 (prueba de trabajo)

NIP-13 define una prueba de trabajo para eventos Nostr. El spam es trivial en una red pública de relays: cualquiera genera un keypair e inunda un tema sin coste económico. NIP-13 permite imponer un coste computacional por evento que un spammer paga en conjunto, mientras un remitente normal lo paga una vez por mensaje. Relays y clientes pueden exigir o favorecer eventos con cierta dificultad.

El mecanismo

El autor elige una dificultad en bits y mina el id del evento, el hash sha256 del evento serializado, hasta obtener al menos ese número de bits cero iniciales. Como el id incluye created_at, tags y contenido, hay que cambiar algo para recorrer el espacio de hashes. NIP-13 define el tag nonce:

["nonce", "<nonce_value>", "<target_bits>"]

nonce_value es cualquier string elegido por el minero; target_bits es la dificultad comprometida. El verificador cuenta los bits cero iniciales del id y los compara con target_bits. El tag formula una afirmación; el conteo real la confirma.

La cantidad de bits cero de una salida sha256 aleatoria sigue una distribución geométrica: cada bit duplica el trabajo esperado. 8 bits promedian 256 hashes, 20 bits cerca de un millón y 28 bits unos 268 millones. El objetivo de 8 bits de Bitchat tarda menos de un milisegundo. Los 21 bits de TAO y Wired rondan dos millones de hashes por post, rápidos en un portátil pero caros para una granja de bots. NIP-13 no impone dificultad; cada relay y cliente decide.

Evento de ejemplo

Una nota kind 1 mínima minada con NIP-13 es:

{
 "id": "000000000e9d97a1ab09fc381030b346cdd7a1a8a6f27c9c88f68c8b9d0f6c8a",
 "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
 "created_at": 1720368000,
 "kind": 1,
 "tags": [
 ["nonce", "72847", "28"]
 ],
 "content": "hello, this cost me 28 bits of PoW",
 "sig": "b1a5c9c74cff59f8a48e5c3b3d8e1c8e7e2c1d4a8e2b9f7d1c3e8b4f6a2c8d1e9f4b3c7a1d8e5b2f9c6a3d7e1b8f4c9a2d6e3b7f1c8a4d9e2b5f8c1a7d4e6b9f3c2"
}

El id comienza por siete ceros hexadecimales, 28 bits, igual que target_bits. El minero varió nonce_value hasta cumplir el objetivo. El verificador hashea el evento serializado, confirma los bits y verifica la firma. NIP-13 no añade campos, sino el tag y la restricción sobre el id.

Dónde se utiliza

Bitchat 1.5.4 usa PoW de 8 bits en mensajes geohash kind 20000: mina antes de publicar y relaja el rate limit para eventos entrantes válidos. TAO y Wired usan 21 bits como umbral y muestran raíces con PoW reciente para ordenar el timeline. cagliostr lo exige en el relay. NoStrudel ofrece minado en cliente. Damus y Amethyst calculan los bits al mostrar eventos. Coracle permite minar y filtrar. NDK y nostr-tools ofrecen helpers a bibliotecas.

La propiedad decisiva es que PoW no puede falsificarse: target_bits solo prueba algo si el id tiene esos ceros, y falsificarlo exige repetir el trabajo. Por eso Bitchat puede relajar límites sin confiar en el remitente. PoW tampoco compromete al minero con una pubkey o contenido concretos; un spammer aún puede minar 8 bits, pero paga un coste real. NIP-13 convierte el problema de spam de “imposible” en “cuantificable” y deja que cada cliente fije su precio.

Análisis en profundidad: NIP-40 (timestamp de expiración)

NIP-40 define un tag expiration que indica a relays y clientes que un evento debe considerarse caducado tras un timestamp Unix. Los eventos Nostr son por lo demás permanentes: incluso un borrado NIP-09 puede no retirar el original. NIP-40 deja al autor declarar al publicar que el evento tendrá vida corta y pide a relays y clientes dejar de servirlo o mostrarlo.

El mecanismo

El autor añade un tag expiration:

["expiration", "<unix_timestamp>"]

El timestamp está en segundos Unix. Un relay PUEDE rechazar al ingerir eventos ya caducados, PUEDE dejar de servirlos y DEBERÍA respetar la expiración. Un cliente DEBERÍA ocultarlos. NIP-40 no obliga a borrar ni invalida la semántica de eventos protegidos NIP-70; es una indicación y un contrato blando.

El tag vive en el propio evento o, en mensajería envuelta, en el wrap externo. El evento sigue firmado y quien lo tenga puede leerlo. NIP-40 coordina la expectativa de que deje de aparecer tras el plazo, útil para posts efímeros, anuncios temporales, notas de eventos en vivo y DM NIP-17 que no deberían permanecer.

Interacción con gift wrap

La PR #1384 de rust-nostr muestra cómo interactúa NIP-40 con gift wrap NIP-59. NIP-59 define dos capas: un seal kind 13 firmado por la clave real del remitente y un gift wrap kind 1059 firmado por una clave efímera. Ambas usan created_at aleatorio hasta 48 horas anterior al envío real para ocultar el momento exacto. El seal debe tener tags vacíos.

Por eso expiration debe ir en el gift wrap, no en el seal, y anclarlo al envío real rompería la privacidad temporal: si el caller pasa un timestamp absoluto, un observador resta el TTL y recupera la hora real. rust-nostr recibe una Duration y calcula expiration = wrap.created_at + duration dentro de la biblioteca. Como created_at ya está aleatorizado, la expiración hereda esa aleatoriedad.

Evento de ejemplo

Un ejemplo mínimo NIP-40 en una nota kind 1:

{
 "id": "1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b",
 "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
 "created_at": 1720368000,
 "kind": 1,
 "tags": [
 ["expiration", "1720454400"]
 ],
 "content": "this note expires in 24 hours",
 "sig": "d2e5b8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1"
}

created_at es la publicación; el tag indica dejar de servir el evento 86.400 segundos después. Un relay compatible deja de devolverlo en REQs tras 1720454400 y un cliente lo oculta.

Dónde se utiliza

Los builders de rust-nostr (GiftWrapBuilder, PrivateDirectMessageBuilder) exponen expiración como Duration. NDK ofrece un helper para notas y DM. nostr-tools incluye getExpiration e isExpired. strfry, nostr-rs-relay, khatru y otros relays respetan NIP-40 al procesar REQ. Damus, Amethyst, noStrudel, Coracle y Primal filtran eventos caducados. Clientes en vivo como zap.stream usan NIP-40 en chats kind 1311 para que no persistan tras el stream.

NIP-40 encaja porque es opcional por evento y no exige despliegue coordinado. El autor puede añadirlo hoy; un relay que lo respeta mantiene un conjunto más limpio; uno que lo ignora no empeora; y un cliente compatible cumple la voluntad del autor. El cambio de rust-nostr recalca que la ubicación importa tanto como la presencia: en un gift wrap NIP-59, el tag va en la capa cuyo timestamp ya está aleatorizado y la API impide filtrar accidentalmente el momento real.

Esto es todo por esta semana. ¿Estáis construyendo algo o tenéis noticias que compartir? Contactad por DM NIP-17 o encontradnos en Nostr.

Nostr Compass #29

Wed, 01 Jul 2026 00:00:00 +0000

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

Esta semana: FIPS v0.4.0 incorpora transporte mediante la mixnet de Nym, descubrimiento mDNS opcional en la LAN, cambio de claves sin interrupciones pese a pérdidas y una renovación del plano de datos, todo compatible a nivel de wire con v0.3.0. Whitenoise Linux aparece como cliente Marmot de escritorio en Rust y Slint, con una propuesta de protocolo para trasladar los efectos de mensaje a un event kind 9 específico. CustID v0.1.10-beta se lanza como bóveda de identidad móvil respaldada por hardware que actúa como firmante remoto NIP-46 y responde por NFC a desafíos de acceso físico. myco estrena el intercambio entre pares de nsites sobre la malla FIPS, con un nuevo transporte BLE L2CAP en v0.1.0. Nostr Codex Phone se lanza como superficie de control para Android de un asistente de programación Codex local mediante DMs cifrados de Nostr. La línea aún no publicada de Amethyst añade análisis de handlers de aplicaciones NIP-89, un feed de repositorios Git para NIP-34 y una sección Discover para nSites y napplets. Notedeck incorpora NIP-37, NIP-52 y NIP-22 en una semana. Applesauce publica 12 versiones coordinadas de subpaquetes con helpers nbunksec para NIP-46 y una actualización de cartera a Cashu-ts v4. Meiso v1.4.0 incorpora listas colaborativas con clave compartida sobre el kind 35000 direccionable. El repositorio de NIPs fusionó cinco PRs, incluidos un event de roles de relay, la eliminación del límite de 65.535 bytes de NIP-44, la semántica de forks de NIP-34, los metadatos de cliente NIP-46 y un método signevent de NIP-86. Los análisis detallados abordan NIP-86 (API de gestión de relays) y NIP-89 (handlers de aplicaciones recomendados).

Historias principales

FIPS v0.4.0 incorpora transporte por la mixnet de Nym, descubrimiento mDNS y una renovación del plano de datos

FIPS es una red en malla privada, autoorganizada y entre pares para Nostr, donde los nodos se descubren y enrutan tráfico sin infraestructura central. FIPS v0.4.0 incorpora transporte mediante la mixnet de Nym, descubrimiento mDNS opcional en la LAN, una renovación del plano de datos, cambio de claves sin interrupciones pese a la pérdida de paquetes, una TUI fipstop reescrita sobre un harness de snapshots de renderizado, un plano de observabilidad fuera de la ruta crítica, y nuevos objetivos de empaquetado apk para OpenWrt y flake para Nix. Todo mantiene compatibilidad a nivel de wire con v0.3.0, de modo que las mallas mixtas interoperan durante una actualización gradual. Dos nuevos transportes para el descubrimiento de peers vertebran la versión. Un nuevo transporte saliente por la mixnet de Nym enruta el tráfico FIPS mediante un proxy SOCKS5 nym-socks5-client y lo mezcla en la red de tráfico de cobertura de Nym, para impedir que observadores de nivel de enlace correlacionen qué peers de la malla se comunican. Un directorio examples/sidecar-nostr-mixnet-relay/ demuestra un relay Nostr accesible mediante un enlace FIPS conectado de extremo a extremo a través de la mixnet. El descubrimiento mDNS / DNS-SD opcional en la LAN permite que los nodos del mismo enlace local se encuentren sin configurar direcciones ni usar STUN; anuncian y adoptan peers mediante un registro de servicio estándar cuando node.discovery.lan.enabled: true.

El plano de datos se rediseñó para aumentar el rendimiento de un solo nodo. El cifrado y descifrado de cada peer se ejecutan ahora en tareas worker específicas fuera del bucle de recepción, por lo que un peer ocupado no puede serializar la criptografía de todo el nodo. La ruta de envío de Linux usa generic segmentation offload y un socket UDP conectado cuando están disponibles; la ruta crítica de recepción evita las copias de buffer que antes hacía por paquete; y macOS incorpora recepción por lotes con recvmsg_x, equivalente al procesamiento por lotes con recvmmsg de Linux introducido en v0.3.0. Toda la superficie de lectura show_* de fipsctl y fipstop sirve ahora desde un snapshot por tick, publicado en un ArcSwap sin locks desde la tarea de aceptación de control, así que las consultas de operadores responden con rapidez aunque el bucle de recepción del nodo esté ocupado. Una nueva consulta show_metrics limitada a contadores, expuesta como fipsctl stats metrics, permite que Prometheus recopile métricas sin coste en la ruta crítica.

El cambio de claves de sesión FMP y FSP ya no causa interrupciones ante pérdida y reordenación de paquetes en ninguna dirección: los frames entrantes se autentican contra la sesión pendiente antes de que el cambio marcado por el bit K la promueva, de modo que un frame obsoleto o falsificado no puede desbaratar el cambio; la retransmisión del mensaje 1 de rekey queda acotada; el heartbeat que detecta enlaces caídos tiene en cuenta el rekey; y las carreras por iniciación simultánea en enlaces de alta latencia se desincronizan mediante jitter simétrico. La TUI fipstop se reconstruyó sobre un harness de snapshots de renderizado que compara la cuadrícula de texto exacta y el estilo de cada celda de todas las vistas con salidas preparadas del socket de control. También llegan nuevos objetivos de empaquetado: un .apk de OpenWrt para OpenWrt 25+ —compilado sin SDK, reutilizando la compilación cruzada .ipk existente y el payload del sistema de archivos instalado— y un flake.nix en la raíz del proyecto que compila desde el código fuente los cuatro binarios (fips, fipsctl, fips-gateway, fipstop) en Nix/NixOS con el toolchain fijado.

Whitenoise Linux aparece como cliente Marmot de escritorio

Whitenoise Linux es un cliente Marmot de escritorio: mensajería de grupos MLS sobre relays Nostr, empaquetada como un único binario Rust con una interfaz Slint que guarda todos los secretos en una bóveda cifrada con contraseña.

El hilo más relevante de esta semana propone transportar los efectos de mensaje de Whitenoise como un event kind 9 específico que referencia el mensaje padre. El formato de wire actual añade al final del cuerpo del mensaje un marcador como dmfx:sparkle, lo que contamina el texto para cualquier renderer que desconozca la convención. Trasladar los efectos a su propio event mantiene limpio el texto del mensaje y abre una cuestión de diseño que afrontará toda la pila Marmot: convenciones dentro del cuerpo o events sidecar para funciones enriquecidas opcionales.

CustID se lanza como bóveda de identidad móvil con NIP-46 y un flujo de desafíos NFC

CustID v0.1.10-beta es la primera beta pública de CustID, una bóveda de identidad móvil construida sobre Nostr y el protocolo SISTR. CustID almacena varias identidades Nostr en almacenamiento seguro respaldado por hardware, actúa como firmante remoto NIP-46 para otros clientes y responde a desafíos de acceso físico y en línea mediante NFC y códigos QR.

La beta ofrece todas las funciones previstas para el firmante NIP-46 y el flujo de desafío-respuesta NFC; los flujos de acceso con pruebas de conocimiento cero quedan como objetivo futuro. Esta versión también elimina la capa keep-alive NIP-65 en segundo plano de la app, que abría un WebSocket por perfil y por relay de lectura e ingería kinds que el cliente descartaba inmediatamente. Ahora solo se mantienen activos en segundo plano los sockets NIP-46 que transportan notificaciones de solicitudes de firma, la corrección que hace viable ejecutar CustID como bunker para otros clientes en un teléfono.

myco se lanza para compartir nsites entre pares sobre la malla FIPS

myco v0.1.0 abrió esta semana, el 27 de junio, y alcanzó v0.1.0 el 1 de julio. myco es una app Android en Rust que instala aplicaciones de personas cercanas: intercambio entre pares de nsites sobre una malla FIPS, mediante cualquier transporte que admita la malla (UDP, TCP, Tor, Bluetooth) y con funcionamiento totalmente offline. El diseño empareja directamente FIPS como sustrato de transporte con el formato de events de sitios web estáticos de NIP-5A como payload, lo que permite que una app distribuida como nsite pase entre peers de la malla sin depender de relays ni HTTP.

v0.1.0 añade una ruta de radio Bluetooth L2CAP para que dos teléfonos con FIPS instalado puedan conectarse como peers por BLE sin ninguna red, además de una prueba de velocidad por peer y el intercambio activado por NFC desde el bottom sheet Circle de la app. myco también está publicada en Zapstore para su instalación directa.

Nostr Codex Phone se lanza como superficie de control móvil de un worker Codex local mediante Nostr

Nostr Codex Phone v0.1.122 se lanza esta semana como cliente Android que controla un worker local del asistente de programación Codex mediante mensajes directos cifrados de Nostr. La app admite varias sesiones de repositorios, transcripción de voz, sesiones enrutadas de workers, subidas de medios a Blossom y respuestas habladas opcionales, de modo que un desarrollador que ejecute un worker Codex en casa pueda enviar solicitudes desde el teléfono allí donde este tenga acceso a relays.

El proyecto es hermano directo de CodeDeck, lanzado en el número 28. Ambos llevan los flujos de programación agéntica al transporte de Nostr mediante DMs cifrados, y ambos tratan Nostr como la capa de emparejamiento y mensajería que permite a un teléfono acceder a un worker doméstico sin abrir agujeros en la red. Nostr como plano de control para agentes locales se está convirtiendo en un patrón consolidado.

Coop Mobile publica sus primeras builds versionadas

Coop Mobile v0.2.1 y v0.2.2 llegaron esta semana como las primeras builds versionadas de Coop Mobile, un cliente Android de mensajes directos cifrados NIP-17. Las dos versiones refuerzan la resistencia a fallos al analizar mensajes y manejar códigos QR, y borran todos los datos almacenados al cerrar sesión.

Amethyst desarrolla una interfaz compatible con NIP-89, un feed de repositorios Git y una sección Discover de napplets

La rama principal de Amethyst incorporó varias superficies nuevas esta semana. Un feed de repositorios Git convierte los repos NIP-34 en una categoría navegable del timeline de Android, filtrable por comunidad y autor, junto con un navegador git smart-HTTP que lee el contenido y los commits del repo sin salir de la app. El host de napplets recibió una sección Discover que enumera aplicaciones web seleccionadas, además de nSites y napplets seguidos, a partir de events de handlers NIP-89 y events de sitios NIP-5A. La visualización de notas ahora revela qué app Nostr creó un event mediante tags NIP-89. En sincronización, llega la compatibilidad con negentropy NIP-77, con reconciliación en streaming y ventanas automáticas de created_at para sortear los límites de resultados de los relays, reduciendo el ancho de banda necesario para mantener sincronizados grandes conjuntos locales de events con un relay.

Buzz v0.3.38 refuerza la superficie de ataque del relay y añade selección de modelos independiente del proveedor

Buzz v0.3.38 refuerza la superficie de ataque del relay que Buzz expone al publicar personas, equipos, agentes gestionados y declaraciones de propietario NIP-OA como events Nostr firmados. Un relay de Buzz es un registro público de las identidades Nostr del equipo y de su estado; esta versión endurece la validación de entradas y la protección contra replay en los kinds conocidos que define Buzz. También generaliza la selección de modelos para que un equipo de Buzz pueda usar cualquier proveedor para el que Buzz disponga de adaptadores, incluido un nuevo backend Databricks AI Gateway v2.

Notedeck implementa relays de sincronización privada NIP-37, calendario NIP-52 y comentarios NIP-22

Notedeck, el cliente de escritorio nativo en Rust del equipo de Damus, incorporó tres implementaciones de protocolo en una semana. Los relays de sincronización privada ahora persisten como una lista NIP-37 de kind 10013, que separa el conjunto de relays de contenido privado del usuario de su outbox público NIP-65. El panel de calendario horizon lee events NIP-52 desde nostrdb y recibió un rediseño de tres paneles. El panel headway añadió un modelo de event de comentarios NIP-22 en el kind 1111, el kind que NIP-22 define para la superficie unificada de comentarios que sustituye el encadenado de respuestas NIP-10.

Applesauce incorpora sesiones NIP-46 nbunksec y actualiza la cartera a Cashu v4

Applesauce, el toolkit modular de Nostr para firmantes, relays, carteras y contenido, publicó una versión coordinada 6.2.x de sus subpaquetes. El paquete de firmantes obtuvo helpers para importar y exportar nbunksec, tratando una sesión bunker NIP-46 como artefacto portable que puede trasladarse entre clientes. El paquete de cartera actualizó sus bindings de Cashu a @cashu/cashu-ts v4, donde los importes de proofs pasan a ser objetos de valor Amount y cambia la API de decodificación de tokens.

Versiones etiquetadas

mostro-core v0.14.0

mostro-core v0.14.0 incorpora la siguiente iteración del protocolo de la red de intercambio P2P de dinero fiat Mostro. La versión sucede a v0.13.2 y llega junto con mostro-cli v0.16.0, que adopta el nuevo core. Tres PRs fusionados llegaron al repositorio core esta semana; el resto de la pila —el daemon mostro y Mostro mobile— sigue la versión v0.14.0 del crate de tipos compartidos.

ngit v2.6.1

ngit v2.6.1, la CLI canónica de git sobre Nostr para repositorios NIP-34, implementa la semántica de forks GRASP-06 de NIP-34 fusionada esta semana, que sustituye el tag personal-fork por un tag u en los events de estado del repo.

mesh-llm v0.72.0 y v0.72.1

mesh-llm, el componente de inferencia de la pila ContextVM que ejecuta LLMs de código abierto tras una superficie JSON-RPC direccionable por Nostr, publicó v0.72.0 y v0.72.1, con una corrección para un fallo del procesamiento por lotes ante prompts individuales grandes y la migración del puente MCP para abandonar helpers obsoletos.

Meiso v1.4.0 incorpora listas colaborativas con clave compartida que sustituyen MLS para compartir tareas

Meiso v1.4.0 introduce un modelo de listas colaborativas con clave compartida que sustituye el anterior intercambio de tareas basado en MLS por un diseño más sencillo de events direccionables. Cada lista compartida genera una clave Nostr específica que se distribuye a sus miembros; las tareas son events direccionables de kind 35000, identificados por d=task-id y con contenido autocifrado mediante NIP-44; y los relays aplican Last-Write-Wins por tarea. El diseño renuncia al forward secrecy y a la seguridad posterior al compromiso de MLS a cambio de una implementación de cliente más sencilla y resolución de conflictos a nivel de relay.

Cordn 0.3.2

Cordn 0.3.2 incorpora una línea «more-private-coordinator» que elimina las pubkeys efímeras de remitentes al publicar mensajes de grupo y refuerza el flujo de solicitudes de ingreso frente a nuevas solicitudes obsoletas. Cordn es la pila de mensajería basada en MLS tratada en el lanzamiento del CVM ad hoc de Cordn del número 28; esta versión es la actualización correspondiente del lado del coordinador.

Cambios aún no publicados

diVine impulsa 108 PRs fusionados de pulido posterior al lanzamiento

diVine, el cliente de vídeos breves en bucle que recupera Vine, atraviesa una intensa etapa de pulido posterior al lanzamiento. El trabajo visible para Nostr esta semana es una ronda de estabilidad del flujo de conexión NIP-46 que traslada los fallos de nostrconnect:// a códigos de motivo estructurados.

Zap Cooking continúa la corrección transversal de NIP-46 y la renovación del compositor

Zap Cooking es un cliente para compartir recetas en Nostr, donde las recetas se publican como events Nostr de formato largo. El trabajo de esta semana continúa la corrección transversal de NIP-46 y la renovación del compositor tratadas como trabajo aún no publicado en el número 28.

Conduit refuerza el flujo de anuncios y la corrección del marketplace

Conduit es un monorepo de marketplace con tres aplicaciones sobre Nostr: mercado de compradores, portal de comerciantes y creador de tiendas. El trabajo de esta semana continúa el impulso a la corrección del marketplace tratado en la cobertura del lanzamiento del número 28, sobre la oleada comercial de NIP-99 que protagonizó la vertiente de protocolo del número anterior.

Pollerama v1.12 a v1.13.1 añaden selección del client tag, pestañas de perfil y límites a los hilos

Pollerama, un cliente Nostr para Android centrado en encuestas y notas con una potente capa de descubrimiento basada en la web of trust, publicó v1.12.0, v1.13.0 y v1.13.1 en Zapstore esta semana. Los usuarios ya pueden elegir qué client tag se adjunta a las notas y encuestas que crean, ya sea de una lista predeterminada o introduciendo uno propio. Las cadenas de comentarios y respuestas muy anidadas se detienen ahora tras varios niveles y enlazan al hilo completo en la página de la nota. Las páginas de perfil abren de forma predeterminada en Notes, divididas en una pestaña Posts y otra Conversations. Se corrigió un fallo de persistencia de follows por el que las cuentas recién seguidas desaparecían al reiniciar la app, y los botones para seguir ahora muestran el progreso.

getwired.app y get-tao.app corrigen el flujo de envío confess de NIP-13

getwired.app y get-tao.app, que comparten un flujo de publicación anónima que añade proof-of-work NIP-13 para frenar el spam en el momento del envío, corrigieron el flujo de envío confess para que la UX durante el minado de PoW sea coherente.

nostui añade una pestaña de timeline de menciones

nostui, un cliente Nostr de terminal en Rust, añadió una pestaña de timeline de menciones que presenta en una vista específica de la TUI los events de kind 1 que incluyen un tag con la pubkey activa.

Heartwood incorpora URIs bunker NIP-46 por identidad y un puente de firma en modo HSM

Heartwood es un firmante NIP-46 en el que la clave de firma nunca llega al cliente: este se comunica mediante NIP-46 con un pequeño relay, y el relay usa un protocolo de frames serie para comunicarse con un dispositivo de hardware conectado que realiza la firma. Esta semana el proyecto incorporó un puente de firma entre relay y puerto serie y conexiones bunker por identidad, de modo que un solo dispositivo de hardware con varias identidades expone una URI bunker distinta para cada una.

Refactorización de autenticación y firmantes de Nostter

Nostter rediseñó esta semana su capa de autenticación y firmantes, trasladando el estado de sesión a una única signal y extrayendo el despacho de firmantes a módulos de estrategia. La dirección es una abstracción limpia de firmantes donde la extensión web NIP-07, el bunker remoto NIP-46 y el nsec sin procesar comparten una sola ruta de código.

Dart NDK extrae el firmante NIP-07 y aleatoriza las marcas de tiempo NIP-59

Dart NDK trasladó su firmante NIP-07 fuera del paquete core y a ndk_flutter —donde reside el WebView de Flutter—, y aleatorizó las marcas de tiempo de sus gift wraps NIP-59 para reforzar la protección de los mensajes cifrados frente a la correlación temporal.

Milk Market añade páginas de tienda NIP-23 y procesamiento de pagos con Square

Milk Market, el escaparate de marketplace del equipo de Shopstr, añadió a cada tienda una página de blog respaldada por los events de formato largo NIP-23 del vendedor, con secciones editables y una ruta directa a la configuración del blog. Esa misma semana incorporó Square como procesador de pagos alternativo para vendedores y la compra automática de etiquetas de envío para pedidos pagados.

Calendar by Formstr publica una app para iOS

Calendar by Formstr fusionó esta semana el PR #159 IOS App, llevando a iOS el cliente de calendario NIP-52. El PR #197 corrige el análisis de fechas de calendario en hora local, y el PR #201 añade un flujo E2E de Playwright activado mediante una etiqueta run-tests.

cagliostr aplica NIP-22, NIP-09 por coordenada y proof-of-work NIP-13

cagliostr, una implementación de relay en Go, reforzó esta semana tres rutas de aplicación de reglas: proof-of-work NIP-13 configurable para events entrantes, eliminación NIP-09 por coordenada direccionable para que los events reemplazables puedan eliminarse mediante su tag a —algo inaccesible solo con la eliminación por id del event—, y límites configurables de timestamp NIP-22 que rechazan events fechados demasiado lejos en el pasado o el futuro.

Proyectos recién rastreados y descubiertos

La suite de bienestar Vanderwarker publica telemetría del mundo físico como events Nostr bajo una clave de firma compartida del publicador. Consta de cinco apps hermanas: Holy Fit es un contador de pasos que ancla datos de actividad física en Nostr como kind:30078; Nunlock publica un contador diario de desbloqueos del teléfono; Saint Stream publica la reproducción multimedia actual como User Status; Sister Charge publica el nivel, voltaje y temperatura de la batería cada 15 minutos; y Cellibacy publica el uso diario de datos. Las cinco aparecieron en Zapstore entre el 24 y el 30 de junio.

ntrack v0.1.9 es una app Android serverless para compartir ubicación en directo de forma cifrada, construida en Rust y Slint y publicada el 29 de junio. Es hermana de Haven, la app para compartir ubicaciones basada en Marmot tratada en el número 28, pero usa una arquitectura de transporte distinta: DMs cifrados de Nostr transportan las actualizaciones de ubicación, mientras Haven emplea mensajes de grupo Marmot.

NostrAppShell es un scaffold incipiente de shell de aplicaciones para construir apps Nostr. El proyecto publicó esta semana su primera documentación dirigida a usuarios.

NIPs by Pollerama —repositorio abh3po/better-nips, creado el 2026-06-29— es un nuevo cliente para los NIPs kind:30817 creados por la comunidad de NostrHub, presentado como una superficie alternativa a nostrhub.io ponderada por confianza. Cada NIP kind:30817 tiene su propia URL compartible (#/nip/<naddr>), con renderizado Markdown completo y los event kinds que define. El cliente ofrece tres feeds: Following, Web of Trust —follows de follows— y Global, cada uno ordenable por aprobaciones ponderadas por confianza o por novedad. Las aprobaciones se publican como labels NIP-32 en el kind 1985, con tags ["L","nostrhub"] y ["l","approve","nostrhub"], además de un tag a que apunta a la dirección del NIP objetivo y un tag client que anuncia better-nips. Es exactamente la forma de event que firma NostrHub, por lo que las aprobaciones son compatibles entre ambos clientes. La aprobación de un follow directo pesa más en el ranking que la de un follow de segundo grado.

La pila de firma usa @formstr/signer, con un modal de inicio de sesión completo que cubre NIP-07, bunker y nostrconnect de NIP-46, ncryptsec de NIP-49 y firmante Android NIP-55; las sesiones vuelven a conectarse silenciosamente al recargar. La capa de red se ejecuta mediante @formstr/local-relay, un Web Worker que reparte el outbox NIP-65 del usuario entre relays para que un gran conjunto de web of trust no se propague a un único relay. La posición de diseño es que todos los NIPs comunitarios —alojados en NostrHub, en better-nips o en futuros clientes— son iguales a nivel de protocolo; el ranking procede del grafo social, no de la selección de moderadores. Esto encaja directamente con el flujo de labels NIP-32 que abordó el análisis detallado del número 25.

Esta semana aparecieron dos nuevos grupos de repos NIP-34. Vidstr es un cliente Nostr centrado en vídeo, y un grupo de nostrapps.com publica tres proyectos hermanos: verdana, una VM de napps para escritorio; hallway, un cliente de comunidades personalizable; y napps, una especificación y runtime de microapps HTML. El grupo discurre en paralelo al trabajo de napplets tratado en la historia principal del número anterior.

Trabajo de protocolo y actualizaciones de NIPs

Fusionado: NIP-44 elimina el límite de payload de 65.535 bytes

El PR #1907 se fusionó el 28 de junio tras permanecer abierto desde 2024-09. El cambio elimina el límite superior de 65.535 bytes para el payload en texto plano de un sobre de cifrado versionado NIP-44 y lo eleva a un máximo de 4 GiB (uint32_max). NIP-44 codifica la longitud del payload como un uint16 en el formato de wire, algo que la especificación original exigía estrictamente para la interoperabilidad; el cambio fusionado adopta un campo de longitud mayor indicado en el byte de versión, de modo que las implementaciones v2 conservan la compatibilidad a nivel de wire y las v3+ transportan la longitud ampliada. Los clientes que usan NIP-44 para mensajes directos NIP-17, gift wraps NIP-59, payloads de firmantes remotos NIP-46 o cualquier otro mensaje Nostr cifrado con NIP-44 ya pueden intercambiar events individuales mayores de 64 KiB sin dividirlos en la capa de aplicación.

Fusionado: NIP-86 obtiene un método signevent y un event de roles de relay

El PR #2389 añade un método signevent a la API JSON-RPC de gestión de relays NIP-86, que permite a un administrador pedir al relay que firme un event con la propia pubkey del relay. El PR #2390 complementario define un event de roles de relay: un event reemplazable que publica un relay para declarar sus administradores y moderadores. Juntos permiten que los clientes NIP-86 consulten la lista de administradores de un relay y verifiquen que una solicitud autenticada procede de un administrador vigente, sin confianza fuera de banda. Más abajo se analizan ambos cambios en detalle.

Fusionado: NIP-34 sustituye personal-fork por `u` para GRASP-06

El PR #2395 se fusionó el 24 de junio y sustituye el tag personal-fork de NIP-34 en los events de estado de repos (kind:30618) por un tag u —de «upstream»—, alineando el formato de wire con la semántica de forks GRASP-06 que implementa la suite GitWorkshop. El cambio cierra el PR #2384 (NIP-34: remove maintainers to solve expiry issues), que proponía otra corrección de la semántica de forks. La dirección fusionada es la que implementa ngit v2.6.x, por lo que la especificación fusionada y la CLI de referencia quedan alineadas. Los repos existentes que usan personal-fork siguen interoperando; los nuevos repos y la línea ngit v2.6 publican el tag u.

Fusionado: metadatos de cliente NIP-46, ya en upstream tras su llegada a Amber

El PR #2381 se fusionó el 23 de junio y añade metadatos opcionales de cliente a la solicitud connect de NIP-46, lo que permite que un cliente publique su nombre, una URL de icono y una URL de página principal al conectar con el firmante. Amber v6.2.2 incorporó la extensión de metadatos la semana anterior, según la cobertura del número 28; esta semana el NIP upstream alcanza a la implementación ya publicada.

Abierto: claves deterministas de wrapper NIP-17 basadas en epochs

Los PR #2397 y PR #2396 abordan dos propuestas convergentes de claves de wrap NIP-17. El PR #2397 propone que la clave de firma efímera usada para crear un gift wrap NIP-59 se derive de forma determinista de una seed por conversación vinculada a un epoch temporal aproximado, de modo que un destinatario que conozca la clave de conversación pueda predecir a qué pubkeys suscribirse. La especificación actual exige una clave aleatoria nueva por wrap, lo que imposibilita esa predicción. El PR #2396 es el cambio complementario: los wraps de una conversación dada deberían firmarse directamente con la clave de conversación para que la pubkey del wrap sirva también como identificador de la conversación. Juntos trazan un camino hacia conversaciones NIP-17 filtrables sin filtrar metadatos. Ambos siguen abiertos y en discusión.

Abierto: NIP-59 debería rechazar en el relay los events seal de kind 13

El PR #2399 propone que los relays rechacen los events de kind 13 —el seal interno de un gift wrap NIP-59— cuando aparezcan en el nivel superior de una solicitud de publicación, porque un event seal solo tiene sentido dentro de un wrap y un seal filtrado expone la pubkey del destinatario. El issue #2398 complementario va más lejos y sostiene que el seal debería redefinirse como kind efímero —los kinds efímeros NIP-01 no se almacenan en relays—, lo que reforzaría la regla a nivel de protocolo y eliminaría la dependencia de la política de cada relay.

Abierto: estados de grupos NIP-29

El PR #2372 añade a NIP-29 —grupos basados en relays— una semántica explícita de estados de grupo, que define qué significa que un grupo sea abierto, cerrado, público, privado o archivado, y cómo interactúan las transiciones de estado con los events de miembros. La propuesta incorpora a la especificación del relay semánticas que hasta ahora eran específicas de cada cliente.

Abierto: compatibilidad opcional con varios maintainers en NIP-34

El PR #2324 es la propuesta complementaria al PR #2395 fusionado —la semántica de forks GRASP-06 tratada arriba—. El PR #2324 añade compatibilidad opcional con varios maintainers a los events de anuncio de repos NIP-34 (kind:30617), permitiendo que un repositorio declare más de una pubkey de maintainer canónico mediante tags maintainer repetidos. Los clientes consideran entonces oficiales los patches e issues firmados por cualquier maintainer declarado, lo que resuelve la carencia histórica por la que los repos NIP-34 con varios maintainers deben canalizarlo todo por una sola pubkey o recurrir a coordinación fuera del protocolo.

Abierto: operador AND de NIP-91 para filtros, propuesta abierta y no fusionada

El PR #2252 es la propuesta de operador AND para los filtros de Nostr, que reabre un diseño debatido por primera vez en el anterior PR #1365, ya cerrado. Ya existen implementaciones en nostr-rs-relay, applesauce, Amethyst y worker-relay, pero el PR de la especificación sigue abierto.

Cerradas: cuatro NIPs comerciales de pats2sats

Esta semana se cerraron cuatro propuestas comerciales sobre Nostr: Escrow (#2334), Reservations (#2335), una extensión de anuncios de marketplace NIP-99 (#2346) y un perfil de anuncios de alojamiento (#2333). Esa misma superficie comercial se consolida ahora en Gamma Market Spec, un repositorio de extensiones propio del proyecto que se compone sobre los anuncios de marketplace NIP-99 con semánticas de pedidos, checkout, escrow y disputas. Compass ya rastrea este repositorio junto con Marmot y Blossom como repo de especificación de protocolo externo al propio repositorio de NIPs; entre sus PRs abiertos esta semana están la aclaración de atribución de clientes (#11), un tag supersedes para cambios en la identidad de productos (#8) y semántica para reseñas de comerciantes (#7).

Abierto: vinculación de identidades Bitcoin

Esta semana se abrieron dos propuestas para vincular identidades Bitcoin con identidades Nostr: una dirección de pago silencioso de Bitcoin NIP-352 y una prueba de vinculación de identidad Bitcoin-OTC.

Análisis detallado de NIP: NIP-86 (API de gestión de relays)

NIP-86 define una interfaz JSON-RPC para gestionar relays, que permite a clientes autorizados enviar comandos administrativos a relays mediante una API estandarizada. Un único cliente puede gestionar cualquier relay compatible con NIP-86 sin herramientas específicas para cada uno. Dos fusiones de la especificación esta semana —PR #2389 y PR #2390— cierran el círculo entre events firmados por relays y administradores declarados por relays.

El transporte

Una solicitud de gestión NIP-86 es un HTTP POST dirigido a la misma URI desde la que el relay sirve conexiones WebSocket, con Content-Type: application/nostr+json+rpc. El cuerpo de la solicitud es un documento JSON con esta forma:

{
 "method": "<method-name>",
 "params": [<arg1>, <arg2>, ...]
}

La autenticación usa en el header Authorization un event firmado de autenticación HTTP NIP-98. El relay verifica que la pubkey firmante esté en su lista de administradores antes de ejecutar el método. La respuesta del relay es un documento JSON con esta forma:

{
 "result": <return-value>,
 "error": "<error-string-if-any>"
}

Los métodos que existían antes de esta semana

El conjunto de métodos preexistente cubre bloqueos de pubkeys (banpubkey, allowpubkey, listbannedpubkeys), bloqueos de events (banevent, allowevent, listbannedevents), metadatos del relay (changerelayname, changerelaydescription, changerelayicon), gestión de la lista de pubkeys permitidas (allowkind, disallowkind, listallowedkinds) y un método stats que devuelve estadísticas del relay. La forma se aproxima deliberadamente a un servicio JSON-RPC estándar, para que un cliente pueda superponer bindings tipados.

Qué cambió esta semana

El PR #2389 añade un método signevent a la especificación. El método recibe como argumento una plantilla parcial de event —kind, tags y content— y pide al relay que firme y devuelva un event completo con la propia pubkey del relay en el campo pubkey. Es la condición previa para que un relay publique events sobre sí mismo a nivel de protocolo: los anuncios de pubkeys bloqueadas, los metadatos del relay y el nuevo event de roles de relay descrito a continuación exigen que el relay firme con la clave controlada por su operador, pero la mayoría de los operadores no quieren guardar una clave privada en su cliente administrativo.

El PR #2390 define un event de roles de relay: un event reemplazable parametrizado que publica un relay —firmado con su propia pubkey mediante signevent— para declarar las pubkeys de sus administradores y moderadores con semánticas de roles explícitas. Un cliente compatible con NIP-86 puede obtener el event de roles de cualquier relay rastreado, construir la lista de administradores a partir de los tags del event y validar que una solicitud NIP-86 autenticada procede de un administrador actual, sin confianza fuera de banda ni configuración específica del relay. Los dos PRs cierran juntos el círculo: signevent es el mecanismo y los roles de relay son el primer event kind construido sobre él.

Ejemplo de solicitud NIP-86

Una solicitud completa banpubkey de NIP-86 tiene este aspecto:

{
 "method": "banpubkey",
 "params": [
 "<64-char-hex-pubkey-to-ban>",
 "spam"
 ]
}

con un header Authorization que transporta un event firmado NIP-98:

{
 "id": "5e1c2f9e1d3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c",
 "pubkey": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2",
 "created_at": 1782824400,
 "kind": 27235,
 "tags": [
 ["u", "https://relay.example.com/"],
 ["method", "POST"],
 ["payload", "<sha256-of-request-body>"]
 ],
 "content": "",
 "sig": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100"
}

La pubkey firmante debe figurar en el conjunto de administradores del relay —ahora declarado en el event de roles del relay—; el tag u debe coincidir con la URL HTTPS del relay; y el tag payload debe coincidir con el SHA-256 del cuerpo JSON de la solicitud. El relay devuelve:

{
 "result": true,
 "error": null
}

Implementaciones

Amethyst incluye una interfaz de gestión de relays NIP-86 en Android (v1.07.0+).
Entre los relays de referencia que implementan la especificación están strfry, khatru y varias implementaciones menores enlazadas por la especificación desde su sección Implementation Status.

Los clientes compatibles con NIP-86 empezarán a tratar el event de roles de relay como fuente canónica de la lista de administradores del relay cuando las implementaciones adopten los cambios signevent y Relay Roles.

Análisis detallado de NIP: NIP-89 (handlers de aplicaciones recomendados)

NIP-89 define dos event kinds reemplazables parametrizados: kind:31990, el handler de aplicación que publica el desarrollador de una app, y kind:31989, la recomendación que publica un usuario sobre una app que utiliza. Juntos permiten que los clientes descubran aplicaciones capaces de manejar un event kind desconocido sin coordinación fuera de banda: un lector de formato largo que encuentre un event kind:30030 que no maneje de forma nativa puede consultar el grafo NIP-89 en busca de handlers y ofrecer al usuario un flujo «Open in…» hacia una app publicada que sí lo haga. NIP-89 es la infraestructura original para el mismo problema de enrutamiento entre apps que el trabajo de napplets/napps presente en este número amplía ahora hacia applets componibles nativos de Nostr.

El event de handler de aplicación (`kind:31990`)

El desarrollador de una app publica uno o varios events de handler que describen qué event kinds admite la app y cómo abrir una entidad Nostr en ella:

{
 "id": "8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b",
 "pubkey": "c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2",
 "created_at": 1782824400,
 "kind": 31990,
 "tags": [
 ["d", "longform-reader-v1"],
 ["k", "30023"],
 ["k", "30024"],
 ["web", "https://reader.example.com/a/<bech32>", "naddr"],
 ["ios", "longformreader://open/<bech32>"],
 ["android", "longformreader://open/<bech32>"]
 ],
 "content": "{\"name\": \"Longform Reader\", \"picture\": \"https://reader.example.com/icon.png\", \"about\": \"A native reader for NIP-23 longform.\"}",
 "sig": "1f2e3d4c5b6a798877665544332211000ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100ffeeddccbbaa9988776655443322110a"
}

El tag d identifica el handler —para que pueda reemplazarse—, cada tag k declara un event kind que maneja la app, y cada tag de plataforma (web, ios, android, …) proporciona una plantilla de URL con <bech32> como placeholder de una entidad codificada mediante NIP-19 que el cliente llamante sustituye al abrirla. Un solo event de handler puede anunciar varios kinds compatibles si comparten el mismo patrón de enrutamiento, lo que mantiene compacto el descubrimiento de apps y evita un event de handler por kind.

El event de recomendación de usuario (`kind:31989`)

Un usuario publica una recomendación que declara qué apps utiliza para un event kind determinado:

{
 "id": "9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d",
 "pubkey": "d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3",
 "created_at": 1782824500,
 "kind": 31989,
 "tags": [
 ["d", "30023"],
 ["a", "31990:c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2:longform-reader-v1", "wss://relay.example.com", "web"],
 ["a", "31990:e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6:reader-pro", "wss://relay.example.com", "ios"]
 ],
 "content": "",
 "sig": "2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6"
}

El tag d contiene el event kind recomendado. Cada tag a es un puntero de dirección NIP-01 a un event de handler kind:31990, junto con el relay sugerido y la plataforma a la que se aplica la recomendación. Una misma recomendación puede enumerar varias apps para distintas plataformas.

El client tag y el compromiso de privacidad

NIP-89 también define un tag client opcional que cualquier app publicadora puede adjuntar a los events que crea:

["client", "Longform Reader", "31990:c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2:longform-reader-v1", "wss://relay.example.com"]

Esto permite que cualquier cliente que muestre el event revele de qué app procede, consulte metadatos más completos del handler y respete las indicaciones de renderizado declaradas por este. La especificación también señala explícitamente el coste de privacidad: un cliente que emite un tag client en cada event publica la identidad del software del usuario, lo que revela patrones de uso con el tiempo. La especificación recomienda que los clientes permitan desactivarlo.

El PR #3422 de Amethyst analiza y muestra los tags t, i, a y client de NIP-89 al presentar events, revelando directamente en el timeline qué app creó una nota.

Cómo funciona en la práctica el flujo de descubrimiento

Un cliente que recibe un event kind desconocido sigue estos pasos. (1) Consulta en el grafo de follows del usuario events kind:31989 con un tag d que coincida con el event kind. (2) Resuelve cada tag a recomendado hasta su event de handler kind:31990. (3) Elige el handler cuya plantilla de URL web, ios o android coincida con la plataforma actual. (4) Sustituye en la plantilla de URL la codificación bech32 de la entidad. (5) Ofrece al usuario la URL resultante como opción «Open in…». El flujo está filtrado socialmente: un cliente que consulte events de handlers arbitrarios en relays no confiables podría redirigir a los usuarios a apps maliciosas, así que partir de personas a las que sigue el usuario es una opción predeterminada más segura que tratar por igual a todos los handlers publicados.

NIP-89 y la capa napplet

La sección Discover de Amethyst, el runtime host de napplets y la visualización de client tags construyen juntos una superficie completa de consumo de NIP-89 en Android. La especificación napplet, lanzada en el número anterior, amplía los posibles destinos de esos events de handlers NIP-89: applets en sandbox que ejecutan un runtime componible nativo de Nostr sobre Nostr y Blossom. NIP-89 es el grafo de descubrimiento y enrutamiento; el runtime napplet es uno de los objetivos de ejecución a los que puede apuntar.

Comentarios, correcciones y proyectos que se nos hayan escapado: abrid un issue en github.com/andotherstuff/nostr-compass o contactad con nosotros mediante un DM NIP-17 en npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.

Nostr Compass #28

Wed, 24 Jun 2026 00:00:00 +0000

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

Esta semana: Sprout cambia su nombre a Buzz y empieza a publicar personas, equipos y registros de agentes gestionados como eventos de relay de Nostr, con estado de lectura entre dispositivos y marcadores de lectura por mensaje que sustituyen al antiguo modelo de frontera de insignias. Napplets, de sandwich.farm, se lanza como protocolo de límite de confianza para aplicaciones Nostr componibles distribuidas mediante Nostr y Blossom. Conduit, un monorepo de marketplace con tres aplicaciones sobre Nostr (mercado para compradores, portal para comerciantes y constructor de tiendas, con sus propios directorios de NIPs y especificaciones), integra 17 PRs que endurecen el MVP del marketplace, cambia de forma predeterminada a su relay público y añade analítica respetuosa con la privacidad. BitBlik publica un protocolo de intercambio P2P de BLIK a Lightning mediante DMs cifrados de Nostr, con un coordinador que liquida de forma atómica entre fiat y facturas retenidas de Lightning. Amethyst continúa el lanzamiento de la semana pasada de wallets, pódcasts y entrenamientos con Health Connect Workouts, Road Events, respuestas colapsables, seguimiento de la salud de latencia de relays con un clasificador y una corrección de notarización para macOS. Amber implementa la extensión de metadatos de cliente de NIP-46 propuesta la semana pasada y muestra iconos e identidad de aplicaciones nativas en las pantallas de solicitudes del firmante. Haven lanza la compartición privada de ubicación sobre el protocolo de mensajería cifrada Marmot. CodeDeck permite controlar desde el teléfono sesiones de Claude Code ejecutadas en el portátil mediante relays cifrados de Nostr, después reduce el emparejamiento a un único escaneo QR y añade selección de modelo por sesión. Grain publica una biblioteca Nostr importable para Go que implementa el modelo outbox. Mostro Core, Wisp y Dark Wisp, Citrine, FIPS, Kubo (canales de YouTube seleccionados por los padres y un feed infantil sujeto obligatoriamente a confianza) y Pollerama (una puntuación de web of trust, un motor de relay en el dispositivo y una sección «Personas que quizá conozcas») publican parches de seguimiento. El trabajo aún no publicado abarca un coordinador MLS en el navegador de sandwich.farm, el ciclo de iteración de UX de nostter, la corrección de NIP-46 entre proyectos y la renovación del compositor de Zap Cooking, el ciclo de escrow Cashu de Shopstr, divine.video y Nostur. Entre los nuevos proyectos seguidos están Social Agents Prototype, PRana para el triaje de incidencias de git sobre Nostr y routstr-chat. En el protocolo, NIP-99 recibe una propuesta de checkout y escrow dentro del grafo que encaja directamente con el trabajo comercial de Conduit, BitBlik y Shopstr. Como este es el último Compass de junio, el número termina con Seis años de junios de Nostr.

Historias principales

Amethyst v1.12.1 a v1.12.6 continúan el lanzamiento de v1.12.0

Amethyst continuó el lanzamiento de v1.12.0 de la semana pasada con seis parches rápidos entre el miércoles y el viernes. v1.12.1 añade Health Connect Workouts y una acción Share-as-Image, y hace determinista el flag Active de Tor para que el callback de arranque no pueda competir con la puerta. v1.12.2 añade Road Events y respuestas colapsables; v1.12.3 incorpora seguimiento de la salud de latencia de relays con un clasificador y una interfaz de panel, además de corregir la notarización en macOS; y v1.12.4 a v1.12.6 incluyen rondas de traducción de Crowdin y automatización de créditos de traductores.

Sprout cambia su nombre a Buzz y publica personas, equipos y agentes gestionados como eventos de relay

Sprout, el workspace autoalojable de Block donde humanos y agentes de IA colaboran en los mismos canales y cada mensaje, reacción, paso de workflow, aprobación de revisión y evento git se escribe como evento Nostr firmado, pasó a llamarse Buzz esta semana. GitHub ahora redirige el antiguo slug block/sprout a block/buzz; el repositorio, la licencia y la dirección del producto no cambian. Toda la cobertura de Sprout en números anteriores se refiere al mismo proyecto.

La semana trajo trabajo sustancial de producto junto con el cambio de nombre. Las personas, los equipos y los registros de agentes gestionados se publican ahora como eventos de relay de Nostr mediante PR #1189, lo que permite que una misma identidad de agente aparezca en varios workspaces y registros de auditoría sin duplicar estado. Un nuevo panel de escritorio muestra las attestations de propietario NIP-OA en los perfiles (PR #1198); la frontera de insignias no leídas de los hilos de canal se sustituyó por marcadores de lectura por mensaje para que los recuentos permanezcan correctos entre dispositivos (PR #1178); y la bandeja de entrada añade atribución de autor y origen en los eventos de recordatorio (PR #1176).

Los canales temporales caducan ahora de forma predeterminada a los siete días (PR #1182); las sustituciones de relay por agente respetan el relay configurado antes de recurrir al predeterminado del workspace (PR #1131); y la compilación de Windows incluye ahora un toolchain completo de Git for Windows para la herramienta de shell (PR #1145).

Napplets: aplicaciones Nostr componibles con un límite de confianza definido

Sandwich.farm anunció napplet.run esta semana como protocolo para applets componibles de Nostr, o napplets: pequeños programas que hacen una sola cosa, se ejecutan en entornos aislados y se resuelven mediante Nostr y Blossom con la misma forma de evento que los nsites. El proyecto se distribuye en tres repositorios: napplet/web, que contiene los paquetes web y publicó esta semana 51 tags de versión de subpaquetes en un lanzamiento coordinado (@napplet/core, @napplet/sdk, @napplet/nap, @napplet/shim, @napplet/conformance); napplet/naps, la vía de especificaciones NAPs con 15 PRs fusionados; y kehto/web, el runtime web con 41 PRs fusionados y un playground en kehto.github.io/web/playground. El PR de especificación correspondiente es NIP-5D #2303, abierto por dskvr (sandwich.farm).

La premisa arquitectónica es un límite de confianza definido en la capa de protocolo. Un shell intermedia operaciones peligrosas (firma, acceso a claves y escrituras en relays), un runtime se ocupa de la implementación y de la UX de alto nivel, y los napplets siguen siendo portables, desechables y más difíciles de capturar por un único host. Los napplets pueden comunicarse entre sí dentro del mismo shell, y el diseño evita el bloqueo a un runtime. El autor sitúa los napplets en diálogo con NMP (de Pablof7z) y Tiles (de Soapbox) como enfoques paralelos al mismo problema, y señala que la compatibilidad de Amethyst v1.12.6 con NIP-5A y NIP-5D da a los napplets al menos un cliente publicado desde el lanzamiento. También incluye un hilo histórico: el anterior napp.run de sandwich.farm, un prototipo de aplicación nativa NIP-07, y el navegador dryft, fork de Thorium, influyeron en el diseño actual antes de ser apartados.

Conduit endurece el MVP del marketplace y cambia de forma predeterminada a su relay público

Conduit es el monorepo de tres aplicaciones de marketplace de conduit.market (Market para compradores, Merchant Portal y Store Builder) bajo la organización Conduit-BTC, con directorios propios nips/ y specs/ que definen primitivas comerciales de Nostr específicas de Conduit, y con la extensión Scope-2 de khatru, Conduit-BTC/conduit-relay, por debajo. Ambos repositorios se abrieron a comienzos de este año; esta semana el proyecto fusionó 17 PRs que endurecen el MVP del marketplace.

Los PRs publicados se concentran en la corrección del marketplace: estados de seguridad de los anuncios (PR #110) y endurecimiento de precios de productos y zonas de envío en el lado del comerciante (PR #115). En el relay, PR #102 corrige la detección de capacidades comerciales, PR #112 ignora hints de relays inseguros de terceros y PR #128 establece el dominio del relay público de Conduit como predeterminado para clientes nuevos. La analítica respetuosa con la privacidad llega en PR #109 y PR #129, y una actualización de dompurify cierra un aviso OSV (PR #116). El trabajo forma parte de una ola comercial más amplia de NIP-99 esta semana: PR #2323 propone una capa de checkout dentro del grafo para mercados NIP-99 que cubre flujo de pedidos, escrow y disputas; la veterana Gamma Markets Market Spec, que amplía NIP-99 para comercio electrónico completo, se convierte en la capa de especificación sobre la que construyen Conduit y otros; y Shopstr publicó esa misma semana un ciclo de escrow Cashu.

BitBlik lanza un protocolo P2P de intercambio de BLIK a Lightning sobre Nostr

BitBlik se abrió esta semana como protocolo P2P de intercambio BLIK ↔ Lightning construido sobre Nostr. BLIK es el sistema polaco de pagos instantáneos emitido por bancos; el coordinador de BitBlik liquida de forma atómica entre fiat BLIK, pagado por takers, y facturas retenidas de Lightning, financiadas por makers, mientras el ciclo de la operación se desarrolla sobre Nostr. La aplicación Flutter, la CLI y el coordinador comparten un paquete core, y el proyecto se distribuye mediante el monorepo de GitHub bit-blik/bitblik, la compilación web en www.bitblik.app y la aplicación de Zapstore app.bitblik.

El protocolo usa mensajes directos cifrados de Nostr (NIP-44) para el RPC entre cliente y coordinador. Las ofertas se publican como eventos reemplazables parametrizados de kind 38383, las solicitudes RPC en kind 25195, las respuestas RPC en kind 25196 y las actualizaciones de estado en kind 25197. El coordinador retiene una factura Lightning mientras un taker envía un código BLIK, libera la preimagen cuando se confirma la transferencia BLIK y dirige la liquidación de la factura al maker.

Versiones etiquetadas

Amber v6.2.2 implementa metadatos de cliente NIP-46

Amber, el firmante remoto Android dominante de NIP-46 mantenido por greenart7c3, publicó v6.2.2 la misma semana en que se fusionó el PR de especificación correspondiente. La versión muestra iconos de aplicaciones nativas y los nuevos campos de metadatos de cliente en las pantallas de solicitudes y la lista de aplicaciones, persiste los metadatos del cliente en cada conexión y captura el icono y el nombre de la aplicación nativa al conectar y aceptar. El cambio se empareja directamente con NIP-46 PR #2381, de DocNR, que añade metadatos opcionales del cliente a la solicitud de conexión para que los firmantes puedan mostrar un nombre y un icono reconocibles del solicitante. Amber v6.2.2 también añade compatibilidad con el evento kind 30618 y separa los relays predeterminados y de conexión en la pantalla Active relays.

La versión endurece la superficie de seguridad del firmante. Los cuerpos descifrados de solicitudes y respuestas NIP-46 ya no llegan a los logs, y los payloads de cifrado y descifrado se almacenan como ciphertext y se descifran bajo demanda. Toda salida de logcat queda detrás de BuildConfig.DEBUG; los llamantes desde navegador, sin paquete, se fuerzan a preguntar siempre; y las copias de nsec, ncryptsec y palabras semilla al portapapeles se marcan como sensibles y se borran tras una demora. Se añaden exclusiones explícitas de copias de seguridad y extracción de datos como defensa en profundidad. La versión también corrige un fallo por scroll anidado en Active relays, un fallo de clave duplicada de LazyColumn causado por una deduplicación con carreras de solicitudes bunker y una carrera de EOSE en la comprobación de actualizaciones.

Haven lanza la compartición privada de ubicación sobre Marmot

Haven se abrió esta semana como aplicación privada y resistente a la censura para compartir ubicación en Android e iOS, ejecutada sobre Nostr mediante el protocolo Marmot. El repositorio publicó cinco versiones entre v0.1.0 y v0.1.4 en cuatro días, las primeras versiones de un proyecto nuevo. Haven está construido en Dart y Flutter y se publica en Zapstore como aplicación firmada por el desarrollador. Marmot, la capa de mensajería cifrada de extremo a extremo basada en MLS para Nostr, aporta el estado de grupo y la distribución de ciphertext; Haven extiende ese patrón desde la mensajería hasta la ubicación compartida, y el estado cifrado de cada grupo transporta las actualizaciones de ubicación que el grupo ha consentido compartir.

CodeDeck: programación remota con agentes sobre Nostr

CodeDeck se abrió esta semana como interfaz de programación con agentes y múltiples sesiones para Android y escritorio, construida con Tauri v2, React 19 y un backend en Rust, que permite controlar desde el teléfono sesiones de Claude Code ejecutadas en un portátil mediante relays cifrados de Nostr. El proyecto publicó v2026.06.17, v2026.6.18 y v2026.6.20 en la misma ventana de cuatro días. El modelo de transporte usa Nostr como plano de control cifrado: un teléfono con CodeDeck publica comandos como eventos cifrados a los que se suscribe el bridge que se ejecuta junto al portátil, y este publica la salida de la sesión mediante los mismos relays.

v2026.06.17 integra la malla FIPS de nostr-vpn como servicio VPN Android de la aplicación para que un portátil pueda compilar, instalar, abrir y controlar builds de desarrollo de una aplicación en un teléfono físico de prueba desde cualquier lugar, con CodeDeck como único software instalado en el teléfono de prueba. v2026.6.18 reduce el emparejamiento y la invitación a la malla a un único escaneo QR, y v2026.6.20 añade selección de modelo por sesión para que cada sesión comience con el modelo elegido.

Grain v0.8.0-rc1 publica un motor completo de cliente Nostr

Grain, el relay Go mantenido por 0ceanSlim, publicó v0.8.0-rc1 y ahora es a la vez un relay de Nostr y la biblioteca cliente Go importable sobre la que está construido. Mientras v0.7.x se centraba en operar el relay desde un navegador, la línea v0.8 publica client/core, un motor cliente Nostr independiente con modelo outbox, escrito en Go puro y sin dependencias de cgo ni HTTP. El motor posee un pool compartido de relays, resuelve las listas de relays de cada usuario y dirige cada lectura y publicación según el modelo gossip / outbox: se leen las notas de un usuario desde sus relays outbox, y una respuesta publicada llega a los relays inbox del autor de la nota raíz. El frontend web de Grain es ahora el consumidor de referencia de esa biblioteca, por lo que la interfaz es una aplicación utilizable y un ejemplo práctico para proyectos Go derivados.

La versión incorpora cifrado nativo NIP-44 (v2 y v3), AUTH de relay NIP-42, listas de relays NIP-65, NIP-17, NIP-51 y NIP-37, tags de cliente NIP-89, y soporte multimedia de Blossom y NIP-96. Las aplicaciones Go que antes tenían que volver a implementar el enrutamiento de relays ahora pueden hacer import del motor directamente.

Mostro Core v0.13.1 continúa Protocol v2

Mostro Core publicó v0.13.1 como continuación del despliegue de Protocol v2 de la semana pasada, e introdujo una variante de error PriceTooStale para el contrato del feed de precios del protocolo. En el daemon, PR #752 presenta a los clientes los ids de pedido no válidos como un error CantDo(NotFound) en vez de descartarlos en silencio; PR #785 hace que la versión interna del protocolo siga el transporte activo; PR #778 incorpora la fase 3 del proveedor de cruce fiat El Toque para CUP y MLC; y PR #782 cambia el nombre del tag informativo de NIP-33, protocol_versions, a protocol_version para ajustarlo a la especificación.

Wisp v1.1.2 y la variante Dark Wisp

Wisp, el cliente Android de Barrydeen escrito con Kotlin y Jetpack Compose, publicó v1.1.2, que mantiene separadas las ramas de wallet autoenviadas dentro de un orden determinista de transacciones (PR #586), crea de forma perezosa los reproductores de vídeo inline para resistir notas con muchos medios (PR #592), corrige una ConcurrentModificationException en el conjunto de relays de eventos (PR #595) y corrige la medición intrínseca del contenido de las burbujas de chat para evitar un fallo de SubcomposeLayout (PR #596). La versión también incorpora un filtro incremental del feed con puntuación de spam fuera del lock. El equipo de Wisp publicó además Dark Wisp v1.1.0 en Zapstore esta semana como variante multidivisa que añade objetivos de zap en ZEC, DASH, BCH y LTC, además de un modo anónimo.

Citrine v3.0.1

Citrine, el relay local Android de Nostr de greenart7c3, publicó v3.0.1 con una única corrección: cancelar el registro de un receptor Pokey no registrado ya no provoca un fallo que derribe el relay.

FIPS v0.4.0-rc2

FIPS, el Free Internetworking Peering System, etiquetó v0.4.0-rc2 como release candidate de validación de empaquetado sobre el formato de cable v0.3.x. La línea v0.4.0 añade un transporte de mixnet Nym y descubrimiento LAN opcional por mDNS para la accesibilidad de peers, renueva el plano de datos para aumentar el rendimiento de un solo nodo y reducir la CPU por paquete, saca la superficie de lectura del operador de la ruta crítica del plano de datos para que la observabilidad siga respondiendo bajo carga, publica una TUI fipstop renovada y endurece el rekey de FMP y FSP para que no interrumpa el tráfico bajo pérdida de paquetes. Es una release candidate; la versión estable v0.4.0 estaba prevista provisionalmente para el 2026-06-21.

Kubo v2026.06.12 y v2026.06.20 fijan el feed infantil sujeto a confianza y añaden YouTube seleccionado por los padres

Kubo, la alternativa nativa de Nostr a YouTube Kids de JeroenOnNostr, construida sobre Trust Extended Permissions Protocol (TEPP), publicó dos versiones esta semana. v2026.06.12, con versionado de calendario y versionCode derivado YYYYMMDD, hace obligatorio el feed infantil sujeto a confianza: toda publicación, perfil, reacción y repost que el menor pueda ver o con el que pueda interactuar pasa ahora por TEPP, limitado a las personas admitidas por el progenitor. Las instalaciones nuevas comienzan con la puerta de confianza activada y el círculo del menor se inicializa durante el onboarding, de modo que el feed queda protegido desde la primera apertura. La versión también incorpora chat de grupo gestionado para progenitores, dirige los eventos de confianza al conjunto privado de relays de la familia y falla de forma cerrada, sin mostrar nada, en lugar de filtrar contenido no verificado si no puede cargar los datos de confianza.

v2026.06.20 añade canales de YouTube seleccionados por los progenitores: estos pueden buscar un canal y añadirlo al feed infantil para que los menores solo vean vídeos de canales aprobados, con una vía rápida HTTP y una interfaz optimista que sustituyen al proceso de añadir de unos diez segundos. La versión también elimina la opción de desactivar Trust Extended Permissions, pues el proyecto se basa en confianza obligatoria y el interruptor queda siempre activo; añade una página específica de soporte; corrige las @mentions en el chat de grupo para que etiquetar a alguien muestre el @nombre clicable en vez de un nostr:npub1… sin procesar; añade autocompletado de menciones; y corrige la publicación de confianza para que dependa del estado real de aplicación, no de un flag espejo. Ambas versiones se siguen mediante Zapstore como la aplicación Android com.kubo.app firmada por el desarrollador.

Pollerama v1.9.0 a v1.9.4 añaden puntuación de web of trust, un motor de relay en el dispositivo y una sección «Personas que quizá conozcas»

Pollerama, de abh3po, el cliente de encuestas y feeds Nostr de la familia Form* en pollerama.fun, publicó cinco versiones en Zapstore esta semana. v1.9.0 incorpora un nuevo motor de relay en el dispositivo: un relay local integrado guarda todo lo que el usuario ha visto y responde primero desde la caché local, por lo que feeds, perfiles e hilos cargan al instante, incluso sin conexión, y se mantienen sincronizados con la red en segundo plano. Todo el tráfico de relays, lecturas y escrituras, atraviesa este motor fuera del hilo principal, y las notas, perfiles, reacciones y zaps ya cargados salen directamente del almacenamiento local en lugar de volver a obtenerse.

v1.9.2 corrige que Home y los feeds de notas, así como cualquier vista Following/Network, aparezcan a veces vacíos al abrir o reanudar, mediante el cacheo de la lista de seguidos con independencia del motor de sincronización; hace que las notas compartidas dentro de DMs carguen de forma fiable al obtener la nota referenciada desde los hints de relay aunque el usuario no siga al autor; y añade un panel de ajustes Network que muestra conexiones de relay, tamaño de caché y estado de sincronización, con controles para reconectar o borrar la caché local. v1.9.3 corrige un fallo al arrancar y una regresión de carga del feed Home.

v1.9.4 introduce una puntuación de confianza de web of trust en los perfiles, que indica cuántas de las personas seguidas por el usuario siguen también a esa persona y se muestra como un chip de red, y una sección «Personas que quizá conozcas», con sugerencias obtenidas de la web of trust y ordenadas por cuántos seguidos las siguen. Los ajustes Network muestran ahora el tamaño de la web of trust y la hora del último cálculo, con un botón para recalcular bajo demanda. El worker de web of trust calcula en segundo plano las puntuaciones y recomendaciones para no bloquear la aplicación.

Versiones etiquetadas menores

nogringo/nostr-mail-client v0.13.1 restaura el inicio de sesión mediante aplicaciones firmantes NIP-55 para Amber, Aegis y Primal, y deja de pedir repetidamente a las aplicaciones firmantes que firmen contactos. Cameri/nostream v3.0.0 elimina unsafe-inline de la factoría de aplicaciones web e implementa nonces de scripts. LaWallet NWC v1.0.0 publica la primera versión 1.0 del proyecto con activación mediante tarjeta con enlace QR compartible, reconocimiento de Remote Wallet y aprovisionamiento automático de Lightning Address. Formstr Nostr Calendar v2.0.0 a v2.0.2 añaden una PWA, corrigen eventos reemplazables offline (PR #194) y vinculan los métodos del firmante para que funcione el envío de formularios privados (PR #199). Completan la semana versiones menores de Spl0itable/NYM, codeswot/ZapBook, 77elements/noornote, mattn/nostr-relay, mattn/algia, mouse484/astraea, dergigi/boris, fiatjaf/nak, Spl0itable/nosflare y nostrord/nostrord.

Cambios aún no publicados

Cordn Ad-hoc CVM: un coordinador MLS en el navegador

Cordn Ad-hoc, la nueva aplicación web de sandwich.farm, se abre públicamente esta semana como coordinador MLS que se ejecuta en una pestaña del navegador para grupos Cordn ad hoc. El patrón es poco habitual: una pestaña ejecuta el proceso coordinador Nostr de ContextVM, publica la pubkey del coordinador, recibe solicitudes MCP mediante relays de Nostr y almacena paquetes de claves MLS, welcomes, solicitudes de unión y mensajes de grupo en el almacenamiento del navegador, sin backend. La aplicación impide que se ejecuten a la vez varios coordinadores con la misma pubkey y ofrece al operador un log de depuración para eventos Nostr sin procesar, solicitudes decodificadas y heartbeats de instancia.

SnowCait/nostter publica 19 PRs de iteración de UX

nostter, el cliente web Nostr de SnowCait, fusionó 19 PRs esta semana sin publicar una versión. La sustitución de nostrapp.link por app-manager.nostter.app (PR #2234) y la adición de deck.nostter.app a la allowlist frame-ancestors (PR #2233) consolidan la superficie del proyecto bajo el dominio nostter.app. Los eventos reemplazables de las cuentas seguidas se cachean en IndexedDB (PR #2231), y el estado seen-on del relay recupera reactividad con opciones separadas para seen-on y via (PR #2230).

Zap Cooking corrige un error de NIP-46 entre proyectos y renueva el compositor

Zap Cooking, el cliente para compartir recetas sobre Nostr, fusionó 16 PRs esta semana. El cambio de mayor alcance es PR #452: los firmantes remotos de Primal sellaban eventos con la pubkey del propio firmante, lo que rompía subidas, zaps y auth para cualquier cliente que pasara por Primal. Zap Cooking detectó y parcheó la ruta; la corrección es local al cliente, pero el error existe en todo el espacio NIP-46. El compositor se reconstruye en PR #458 con temporizador de cuenta atrás, una interfaz unificada de respuesta/comentario y pestañas Write/Preview. Tres correcciones SSR (PR #460, PR #461, PR #462) y PR #454 estabilizan las rutas de perfiles y recetas. La experiencia de exploración añade filas desplazables mediante arrastre, un cursor de avatar con enlace al perfil y una corrección de pestañas fijas para comunidades (PR #456).

Shopstr publica un ciclo de escrow Cashu y herramientas para escaparates

Shopstr, el marketplace NIP-99, fusionó esta semana una serie de PRs sustanciales. PR #512 implementa un ciclo completo de escrow Cashu P2PK para el marketplace, conectado con la ola comercial más amplia de esa semana mediante NIP-99 PR #2323, la propuesta de capa de checkout dentro del grafo, y el lanzamiento de Conduit. Las herramientas de lectura llegan en PR #543 para listar empresas, obtener sus detalles, recuperar un escaparate y consultar la reputación del vendedor. PR #229 incorpora soporte para pegar URLs de imágenes de perfil y tienda, y PR #359 actualiza la obtención de estadísticas del marketplace para incluir una marca de tiempo.

Trabajo de divine.video para móvil y escritorio

divine.video, el cliente de vídeos cortos en bucle de rabble que restaura los archivos de Vine, fusionó esta semana PRs centrados en reproducción y edición: los vídeos direccionables se deduplican en el feed (PR #5465); los filtros locales de tags Nostr ahora exigen coincidencia exacta para evitar resultados espurios (PR #5463); el editor de vídeo recupera borradores con capas de stickers sin fallar (PR #5474); y la insignia Messages cuenta los chats no leídos de cuentas seguidas a los que aún no se ha respondido (PR #5473).

Nostur incorpora metadatos de cliente NIP-46 y correcciones de refresco de DMs

Nostur, el cliente iOS de Fabian, fusionó cuatro PRs en el repositorio canónico después de la versión 1.29.0 de la semana pasada. PR #74 añade metadatos de cliente a las solicitudes de conexión bunker NIP-46, la misma forma propuesta por DocNR y publicada esta semana por Amber v6.2.2. PR #75 y PR #76 corrigen las rutas de refresco de DMs y recuperación al primer plano tras una transición de iPhone, y PR #78 añade escaneo QR a la configuración NWC personalizada.

Nuevos proyectos seguidos y descubiertos

Social Agents Prototype es una herramienta experimental de IA construida sobre Nostr que explora la comunicación descentralizada entre agentes. Los agentes emiten preguntas atómicas por la red, solo responden los agentes pertinentes y cada mensaje enviado o recibido pasa por una puerta de aprobación humana antes del tránsito. Su autor es Sruly Rosenblat. El proyecto ocupa el mismo espacio de colaboración entre agentes que Buzz y NIP-100 SNIN esta semana, pero adopta otra forma: Social Agents Prototype modela los agentes como participantes que emiten y escuchan, y exige que una persona apruebe cada mensaje. Esta semana se ven varios enfoques paralelos al mismo problema.

PRana: una lista de trabajo para incidencias NIP-34

PRana, de DocNR, es una lista de trabajo de incidencias NIP-34 abiertas correctamente en repositorios de git sobre Nostr que optan por participar. La herramienta se sitúa una capa por encima del stack de git sobre Nostr: consume los eventos de incidencias NIP-34 de los repositorios participantes y los presenta como cola de triaje. El lanzamiento llega la misma semana en que NIP-34 PR #2384 propone eliminar el tag maintainers para resolver problemas de caducidad, lo que afecta directamente a cómo herramientas como PRana resuelven la autoridad sobre incidencias entre repositorios.

routstr-chat: acceso local a LLMs mediante el protocolo Routstr sobre Nostr

routstr-chat, del equipo de Routstr, es una interfaz de chat totalmente local que usa el protocolo Routstr para acceder a cualquier modelo LLM mediante Nostr. Routstr dirige solicitudes de inferencia a través de anuncios de proveedores publicados en Nostr, kind 38421, y liquida con Cashu, como se explicó en el Boletín #20. El cliente de chat es la superficie orientada al usuario sobre ese protocolo; el daemon de enrutamiento Routstrd gestiona el descubrimiento y el pago, y la aplicación de chat aporta la interfaz de conversación.

Trabajo de protocolo

Actualizaciones de NIPs

La actividad de NIPs de la semana fue especialmente intensa: dos fusiones y una oleada de propuestas abiertas sustanciales.

Los metadatos de cliente NIP-46 llegan a Amber y Nostur

NIP-46 PR #2381, que Clave propuso la semana pasada, ya tiene implementaciones publicadas en ambos lados. Amber v6.2.2 lee el nuevo campo opcional optional_client_metadata de las solicitudes de conexión bunker y muestra iconos y metadatos de aplicaciones nativas en las pantallas de solicitudes y la lista de aplicaciones. Nostur PR #74 añade el campo en el lado del cliente. Los tres proyectos cierran juntos la brecha de identidad en el emparejamiento bunker: un emparejamiento bunker:// transporta ahora los mismos name, url e image que una aplicación ya podía anunciar mediante nostrconnect://.

NIP-86 signevent y un evento complementario de roles de relay

PR #2389 de staab fusionó una operación signevent en NIP-86, la API de gestión de relays, lo que permite a sus administradores gestionar eventos NIP-43 en nombre del relay. La propuesta complementaria abierta PR #2390 de staab define un evento de roles de relay para que estos puedan declarar definiciones de roles y los administradores puedan asignar o retirar miembros de ellos. Los dos PRs están diseñados para componerse: NIP-86 da las operaciones a los administradores y el evento de roles les da el modelo de autorización.

NIP-99: capa de checkout dentro del grafo para marketplaces

PR #2323 de Colabonate es el vínculo central más fuerte de la semana. La propuesta se presenta como una solicitud de comentarios sobre el diseño e identifica dos brechas en el stack de NIP-99 y Gamma Market Spec: un flujo de checkout que vive dentro del grafo, con estado posterior a buy-now, creación de pedido, pago y confirmación de entrega como eventos Nostr públicos y direccionables que cualquier cliente puede leer; y escrow más resolución de disputas para el subconjunto de transacciones en las que las señales de web of trust no bastan, como artículos de alto valor, contrapartes primerizas, marketplaces anónimos o entregas físicas. La propuesta cierra los silos entre clientes de los marketplaces del mismo modo que NIP-99 cerró los silos de anuncios. Llega la misma semana que el lanzamiento de Conduit, que incluye sus propios directorios nips/ y specs/; Shopstr PR #512, con un ciclo completo de escrow Cashu; BitBlik, intercambio P2P BLIK ↔ Lightning con primitivas propias de escrow; y la entrada en seguimiento activo del repositorio independiente Gamma Markets Market Spec.

NIP-34: eliminar el tag maintainers para resolver problemas de caducidad

PR #2384 de dhalsim elimina el tag maintainers de los anuncios de repositorios NIP-34 y aborda la incidencia #2382. El tag maintainers no tenía semántica de caducidad definida, lo que dificultaba a las herramientas posteriores saber cuándo seguía siendo válida una asignación de mantenedor. El cambio tiene un alcance amplio: afecta a los parches de flotilla-budabit, el único repositorio NIP-34 seguido con actividad sustancial de parches esta semana; la distribución NIP-34 en ocho repositorios del equipo de Iris; el mirror NIP-34 de BitBlik; el nuevo mirror NIP-34 de Amber; y la herramienta PRana de DocNR para listas de incidencias. Entre los revisores cruzados del PR están DanConwayDev (ngit), vitorpamplona (Amethyst), TheAwiteb y chebizarro.

Estados de grupos de NIP-29 (trabajo en curso)

PR #2372 de dtonon propone un marco de estados de grupos para NIP-29, compartido como trabajo en curso para recibir comentarios. Continúa la evolución de NIP-29 cubierta en el #27, ahora mediante un nuevo marco.

Stories de NIP-79 y Reels Feed de NIP-76 (ambos de anaskmh)

Esta semana llegaron dos especificaciones de medios cortos del mismo autor. PR #2386 propone Stories de NIP-79: diapositivas efímeras a pantalla completa de fotos, vídeos y texto que caducan tras 24 horas, con kind 19 para diapositivas individuales, kind 34237 como evento direccionable que contiene tags e ordenados para secuenciar stories de varias diapositivas, y un recibo opcional de visto por que preserva la privacidad en kind 15750. PR #2385 propone NIP-76 para un Reels Feed de vídeo corto. Ambas son especificaciones paralelas a lo que publican clientes de vídeo existentes como divine.video, no implementaciones de ello.

kind 1111 como respuesta a notas kind 1

PR #2358 de zhoreeq elimina la línea del corpus de NIPs que antes desaconsejaba usar respuestas de hilos de comentarios kind 1111, NIP-22, sobre notas kind 1 (incidencia #2250). El diff es pequeño, pero el efecto es amplio: cualquier cliente que quiera usar la forma de comentario en hilo de NIP-22 contra notas ordinarias kind 1 del timeline tiene ahora respaldo explícito para hacerlo.

Seis años de junios de Nostr

La historia del repositorio en junio sigue a Nostr desde la infancia del protocolo hasta convertirse en un sustrato de aplicaciones componibles. En 2021 el trabajo todavía cabía en un único repositorio de protocolo. En 2022 el proceso de estándares y los primeros clientes serios se convirtieron en proyectos separados. La ola pública de 2023 hizo urgentes los relays, los pagos y las identidades más ricas; 2024 sustituyó los atajos iniciales de firma y mensajería; 2025 llevó esos contratos a grupos privados, colaboración git, medios y comercio; y 2026 lanzó productos que usan Nostr como una capa dentro de workspaces de agentes, intercambios y herramientas para desarrolladores. La progresión va desde demostrar que los eventos firmados pueden circular por relays hasta convertir ese hecho en un detalle de implementación.

Junio de 2021: infancia del protocolo

Nostr tenía unos siete meses. La publicación original del protocolo de fiatjaf y el repositorio fiatjaf/nostr todavía contenían casi todo el proyecto público. Un puñado de desarrolladores podía revisar cada cambio y la implementación de referencia era un script de Python. Aún no era un ecosistema de clientes; era la afirmación de que los usuarios podían firmar eventos y elegir relays sin que una plataforma les asignara su identidad.

No había un repositorio específico de NIPs, por lo que las propuestas y los ejemplos de implementación aún compartían el historial principal del protocolo. Ese alcance compacto era una ventaja en esa etapa: un nuevo implementador podía comprender el protocolo de extremo a extremo. El coste era que cada comportamiento nuevo seguía dependiendo del mismo grupo pequeño, un límite que la separación del repositorio y la ola de clientes de 2022 empezarían a eliminar.

Junio de 2022: se forma el repositorio de NIPs

A mediados de 2022 Nostr tenía suficientes proponentes para justificar el repositorio separado nostr-protocol/nips, creado en mayo. Unas veinte especificaciones cubrían ya el formato básico de eventos, listas de seguidos, DMs cifrados, metadatos de relays e identificadores bech32. Sacar los documentos del repositorio de código original cambió la gobernanza del proyecto: los clientes podían evolucionar con independencia mientras el comportamiento de cable compartido recibía propuestas y revisión explícitas.

Los primeros clientes web públicos, incluidos Astral y Anigma, funcionaban en formas iniciales, y el repositorio de Damus, de William Casarin, avanzaba hacia la distribución mediante TestFlight. La base de usuarios aún era pequeña y estaba dominada por desarrolladores, pero el sistema contaba ya con dos superficies multiplicadoras: más personas podían construir aplicaciones sin mantener la especificación, y más personas podían mejorarla sin poseer el cliente original.

Junio de 2023: auge de adopción tras Damus

Para junio de 2023, la ola pública posterior al lanzamiento de Damus en la App Store había cambiado el problema de ingeniería. Primal e Iris construían para personas que no habían seguido las primeras conversaciones del protocolo, mientras strfry ofrecía un relay de alto rendimiento a operadores con más tráfico. La red ya no necesitaba solo más implementaciones; necesitaba clientes y relays capaces de seguir respondiendo a medida que crecían usuarios, seguidos e historiales de eventos.

Por eso el trabajo de protocolo se concentró en enrutamiento y transferencia de valor. Las listas de relays NIP-65 dieron al modelo outbox emergente una fuente de verdad portable, mientras los zaps NIP-57 conectaron eventos e identidades con recibos Lightning. El cambio de etapa fue práctico: la identidad y la publicación habían atraído usuarios, pero el enrutamiento selectivo de relays y la interoperabilidad de wallets fueron lo que permitió a la red ampliada comportarse como algo más que un único feed público sobrecargado.

Junio de 2024: firmantes, gift wrap y la mejora de la mensajería

Para junio de 2024, la firma había empezado a salir de los clientes individuales. La especificación NIP-46, nsecBunker y Amber dieron a las aplicaciones web y Android formas de solicitar firmas sin importar la clave secreta del usuario. Esto invirtió una suposición inicial: la portabilidad ya no significaba copiar un nsec en cada cliente, sino permitir que firmantes especializados impusieran un límite a su alrededor.

La mensajería cambió por el mismo motivo. NIP-17 combinó el cifrado NIP-44 con el gift wrap de NIP-59 para reducir los metadatos expuestos por NIP-04, mientras NIP-89 permitió que los clientes recomendaran handlers para tipos de eventos que no renderizaban. Las conversaciones sobre MLS sobre Nostr comenzaron en este entorno. La privacidad y el descubrimiento de aplicaciones se convertían en contratos entre clientes, preparando el terreno para grupos privados y aplicaciones más ricas y específicas de cada evento, en vez de que un solo cliente intentara contener todas las funciones.

Junio de 2025: Marmot, madurez de git sobre Nostr y la larga cola de clientes

Para junio de 2025, MLS sobre Nostr contaba con la especificación formal Marmot y White Noise como implementación pública. Los eventos git NIP-34, ngit y GitWorkshop también habían madurado hasta formar un flujo de revisión de código utilizable. Estos proyectos compartían una etapa de diseño: usaban relays para la coordinación mientras movían el estado sensible de grupos o los objetos de repositorios a capas especializadas, en lugar de tratar un cliente de notas de texto como toda la aplicación.

El comercio y los medios siguieron el mismo patrón. Las wallets NIP-60 y los nutzaps NIP-61 llevaron el estado Cashu a eventos portables; Wavlake, Divine y las implementaciones de marketplace NIP-99 usaron kinds específicos para música, vídeo y anuncios. Nostr parecía cada vez menos «una red social» a medida que las aplicaciones mantenían el sustrato de identidad y relays, pero introducían almacenamiento, pagos, moderación y presentación específicos de cada dominio.

Junio de 2026: un mes cargado de lanzamientos

Junio de 2026 trajo lanzamientos que trataban Nostr como un componente dentro de productos mayores. Buzz abrió un patrón de workspace autoalojado como relay para humanos y agentes; Napplets definió un límite de confianza para aplicaciones componibles sobre Nostr y Blossom; y Conduit situó aplicaciones de marketplace junto a sus propios documentos de protocolo. Estos proyectos ya no preguntaban si los eventos firmados podían sostener la colaboración. Decidían qué trabajo debía vivir en eventos, cuál en blobs o estado local y qué permisos debía conservar un host.

BitBlik usó Nostr en un intercambio P2P entre fiat y Lightning, CodeDeck transportó sesiones de programación mediante relays cifrados y Haven aplicó Marmot fuera de un mensajero convencional. La distancia respecto al repositorio prototipo de 2021 no consiste solo en que haya más proyectos. Es un cambio de abstracción: los equipos podían empezar con identidad portable, descubrimiento de relays, cifrado y pagos como piezas ya existentes, y dedicar después su esfuerzo de diseño al límite específico de la aplicación por encima de ellas.

Nostr Compass #27

Wed, 17 Jun 2026 00:00:00 +0000

Esta semana estuvo marcada por el trabajo en firmantes, los protocolos de comercio P2P y las versiones de clientes destacados. Amethyst v1.12.0 incorpora más de 170 PRs que añaden carteras Cashu de NIP-60, nutzaps de NIP-61, feeds de aplicaciones de software de NIP-82, soporte de pódcasts de NIP-F4, verificación de zaps on-chain con CLINK, la migración de iOS a las fases 1 y 2 de KMP y un driver de autorrecuperación para Tor. Clave v1.0.0 (build 102) se presentó a la App Store y lleva a iOS la firma en segundo plano activada mediante push y la verificación de firmas entrantes. Mostro Core v0.13.0 incorpora Protocol v2, que sustituye la comunicación de órdenes basada en relays por mensajes directos gift wrap de NIP-44, y Mostro v0.17.5 hizo opcional y configurable la fianza antiabuso del operador. Signet v1.11.0 corrige una omisión de verificación de firmas en comandos administrativos de NIP-17 (mensajes directos privados gift wrap) que permitía a cualquiera con información pública falsificar comandos de apagado de emergencia. Chama publicó siete versiones de escrow en seis días y convirtió la sala de intercambio, antes repleta de controles, en una conversación específica para cada participante. En el ámbito de los firmantes, Amber v6.2.1, Clave (builds 100, 101 y 102) y Nostur 1.29.0 implementan el nuevo método logout de NIP-46, fusionado esta semana (PR #2373). Zeus v13.1.0-rc1 y Amethyst incorporan soporte de noffers CLINK, la interfaz común de Lightning propuesta para claves Nostr. Los grupos de relay de NIP-29 recibieron cinco propuestas abiertas sobre tags de banner, códigos de invitación, fijado de mensajes, denuncias en grupos mediante DMs de NIP-17 y control de acceso basado en roles.

Historias principales

Amethyst v1.12.0 incorpora carteras Cashu, nutzaps, un driver CLINK y autorrecuperación de Tor

Amethyst es el cliente Nostr dominante para Android de Vitor Pamplona. v1.12.0 agrupa los 93 PRs cubiertos como trabajo aún no publicado en el boletín #25 (etiquetado de hashtags de NIP-32, pantalla de pódcasts NIP-F4, pistas musicales, firmantes efímeros y zaps on-chain con filtro NIP-05) y el boletín #26 (continuación de NIP-F4 y bases del watchdog de Tor), además de un nuevo lote considerable esta semana. El trabajo nuevo se centra en la superficie de Cashu y nutzaps, un driver CLINK para zaps on-chain, un conjunto de autorrecuperación de Tor y la migración KMP para iOS.

El soporte de carteras Cashu de NIP-60 y el renderizado de nutzaps de NIP-61 llegan en el PR #3075, junto con una vista de saldo por mint (PR #3115) y una interfaz unificada de tarjeta de pago (PR #3191) que reúne direcciones Lightning, zaps on-chain, mints Cashu y NWC en una sola pantalla de pagos del perfil (PR #3185). Un driver CLINK para verificar zaps on-chain llega en los PR #3039, PR #3177 y PR #3182. CLINK es Common Lightning Interface for Nostr Keys, la misma interfaz noffer que incorpora esta semana Zeus v13.1.0-rc1; Amethyst añade además una máquina de estados de verificación, un driver de reverificación y un importe mínimo para zaps on-chain (PR #3030). El PR #3201 introduce notas privadas al envolver como gift wrap respuestas kind 1 destinadas a usuarios mediante p-tags conforme a NIP-17, de modo que el compositor produce una nota pública o una respuesta de grupo sellada según el destinatario.

Un conjunto de fiabilidad para Tor llega como una pila completa de autorrecuperación: el PR #3053 actualiza Arti a v2.3.0 con un watchdog y pruebas de integración; el PR #3223 impide las conexiones a relays enrutadas por Tor hasta que Tor esté listo; el PR #3224 limita el arranque de Arti a 60 segundos para que una red hostil no pueda bloquear el bucle; y el PR #3231 se autorrecupera cuando Tor está activo pero todos los circuitos están muertos. El resultado es una pila de Tor que se recupera de cambios de red y ciclos de suspensión y reanudación sin intervención manual. Las fases 1 y 2 de la migración KMP para iOS llegan en los PR #3047 y PR #3050, desbloquean la integración continua de iOS para los módulos quartz y commons y sientan las bases de una versión de Amethyst para iOS.

Mostro Core v0.13.0 elimina al intermediario relay con Protocol v2

Mostro es un exchange P2P de Bitcoin liquidado mediante Lightning que usa Nostr como libro de órdenes y capa de comunicación de las operaciones. v0.13.0 de mostro-core, la biblioteca Rust que define el protocolo de cable, sustituye el modelo de mensajería enrutada por relays por lo que el changelog denomina Protocol v2: un transporte directo NIP-44 sobre eventos kind 14. Las acciones específicas de cada operación viajan ahora como mensajes kind 14 envueltos conforme a NIP-44 y vinculados a la clave de la operación que el participante generó al crear la orden, sin hacer pasar toda la conversación por eventos públicos direccionables.

Con el modelo anterior, toda la superficie de conversación de la operación quedaba expuesta a cada relay que transportaba los eventos. El transporte directo kind 14 mantiene la preparación de la orden, el flujo de disputas y los metadatos de liquidación entre las dos partes y el daemon de Mostro; los relays solo ven sobres cifrados. Junto con el cambio de transporte, v0.13.0 también vincula la prueba de identidad v2 a la clave de la operación (registro de commits), lo que cierra una clase de riesgos de replay contra el protocolo nuevo. En el daemon, Mostro v0.17.5 hizo opcional y configurable por el operador la fianza antiabuso: antes de iniciar determinadas operaciones, cada parte puede tener que bloquear una pequeña fianza que se devuelve al completar la operación normalmente y se pierde si se demora, no se presenta o entorpece el proceso. La fianza se habilita a nivel del operador del nodo, no en toda la red, por lo que Mostro sigue sin custodia y cada operador elige el equilibrio entre fricción del mercado y resistencia al abuso. En el cliente, Mostro Mobile v1.2.8 incorporó 17 funciones que respaldan la nueva ruta, entre ellas el descubrimiento de relays de arranque en lugar de relays predeterminados fijados (PR #610), la fianza antiabuso del maker al crear la orden como fase 5 del despliegue de la fianza (PR #608) y la persistencia en el historial de notificaciones de las cancelaciones de órdenes con su contexto (PR #602). v1.2.9 llegó dos días después y muestra la política de fianza antiabuso del evento de información del nodo, para que el usuario pueda conocer las reglas de la instancia de Mostro antes de abrir una orden (PR #617).

Signet v1.11.0 corrige una omisión de firma en comandos administrativos NIP-17

Signet es un firmante bunker remoto con una superficie de apagado de emergencia que permite al administrador detener, reactivar o comprobar el firmante a través de Nostr sin tocar la máquina anfitriona. v1.11.0 corrige un fallo de seguridad en esa superficie: la ruta de comandos administrativos gift wrap de NIP-17 solo comprobaba el supuesto autor del rumor interno sin firmar y nunca verificaba el seal firmado. Como las claves de conversación de NIP-44 son simétricas, un atacante que solo tuviera información pública —la pubkey del firmante, el npub del administrador y un relay administrativo— podía falsificar desde fuera un gift wrap y ejecutar cualquier comando de apagado de emergencia, incluidos panic, resumeall o alive. La corrección llama a verifyEvent sobre el seal y vincula el autor del rumor a la firma del seal, por lo que las falsificaciones sin firmar se rechazan ahora en la entrada. Los operadores de Signet deberían actualizar cuanto antes; la especificación y la ruta de código corregida ofrecen juntas al atacante una receta clara para reproducir el fallo.

Chama v3.2.0 a v3.5.0 rediseñan la sala de intercambio y endurecen la ruta del dinero

Chama es un cliente de escrow P2P nativo de Nostr que combina ecash de Fedimint con reparto de secretos Shamir 2 de 3 para liquidar operaciones sin servidor. El boletín #26 cubrió la serie de v2.0.0 a v3.1.0, que convirtió el proyecto en una aplicación independiente y añadió escaparates por vendedor. Las seis versiones posteriores de esta semana comienzan en v3.2.0 y terminan en v3.5.0, publicada el 15 de junio; rediseñan la interfaz de la sala de intercambio alrededor de una sola pregunta por participante —qué debo hacer ahora— y endurecen la ruta del dinero frente a fallos parciales. v3.2.0 dio a comprador, vendedor y árbitro sus propias indicaciones de acción codificadas por colores, para que cada participante vea su siguiente paso en todos los estados de la operación. v3.3.0 endureció dos reglas de consenso del motor de operaciones y exigió una adopción coordinada por parte de los clientes para que surtieran efecto. v3.3.1 adaptó precios y métodos de pago a la moneda de la comunidad del operador. v3.4.0 añadió cinco correcciones de endurecimiento a la ruta del dinero para que un contratiempo, una condición de carrera o una pestaña cerrada no puedan costarle sats al usuario sin avisar. v3.5.0 añadió dos salvaguardas del lado del cliente en torno al papel del árbitro, el único participante que, de otro modo, podría inclinar discretamente una operación.

Clave 1.0 llega a la App Store con firma en segundo plano activada mediante push

Clave es un firmante remoto NIP-46 para iOS que mantiene la clave privada Nostr del usuario en el Keychain del iPhone. Las aplicaciones solicitan firmas mediante un canal cifrado de extremo a extremo y nunca reciben la propia clave. v1.0.0 build 102 se presentó esta semana a la App Store y marca el hito 1.0 tras ocho meses de betas en TestFlight. La versión incorpora firma en segundo plano activada mediante push: Clave puede descifrar una petición, comprobar los permisos, firmar y responder con la aplicación cerrada, por lo que desaparece el requisito de mantenerla en primer plano en iOS que antes limitaba la capacidad de respuesta del firmante. La verificación de firmas entrantes se aplica con Schnorr BIP-340 sobre el formato canónico de serialización de eventos de NIP-01 —la especificación base que define cómo se calcula el hash de cada evento Nostr firmado— más una protección de frescura frente a replay, por lo que una aplicación maliciosa no puede introducir de contrabando un evento vuelto a firmar por el canal de respuesta.

La versión también incorpora la capa de cifrado actualizada de NIP-44 con un modelo de permisos por kind y tres niveles de sensibilidad, corrige el caso límite de firma de baja confianza en el que una petición «preguntar siempre» devolvía un error antes de que el usuario pudiera aprobarla y añade emparejamiento multicuenta para que una sola vinculación de aplicación pueda pasar por varias identidades. Los emparejamientos bunker muestran ahora la identidad real de la aplicación mediante la extensión de metadatos de conexión de NIP-46 que Clave propuso en el PR #2381. El flujo de desconexión limpia usa el nuevo método logout de NIP-46, fusionado en el PR #2373, para que una aplicación emparejada pueda cerrar su sesión correctamente sin desemparejarse a mano. Los niveles de confianza por aplicación —Full, Medium y Low— con excepciones por kind de evento, un registro de actividad para cada firma y la posibilidad de usar un proxy push propio completan la superficie; la pila del proxy tiene licencia MIT y la matriz de interoperabilidad por cliente se mantiene en docs/nip46-compatibility.md.

Versiones

Amber v6.2.1 añade logout de NIP-46 y reduce el consumo de batería del firmante

Amber es el firmante Nostr dominante para Android. v6.2.1 reduce el consumo de batería de las reconexiones a relays y los pings de websocket, elimina los relays inactivos del conjunto de suscripciones y deja de despertar el dispositivo al actualizar la notificación del relay. La versión también añade soporte para el método logout de NIP-46, con el que los clientes pueden cerrar correctamente las sesiones del firmante remoto —el mismo método fusionado esta semana en la especificación como PR #2373—, y añade el análisis del evento kind 39701 —marcador web público— para que los usuarios puedan firmar eventos de marcadores directamente desde Amber. Los ajustes se reconstruyeron con tarjetas Material 3 agrupadas e iconos diferenciados, se corrigió un fallo de navegación en la pantalla de permisos de aplicaciones y se cerró una fuga de conexiones a la base de datos por cuenta al construir las bases de datos de forma atómica.

Nostur 1.29.0 incorpora respuestas anónimas y logout del firmante remoto

Nostur es un cliente Nostr para iOS de Fabian. 1.29.0-desktop añade soporte para responder a recibos de zap y enviar respuestas anónimas. En el lado del firmante, la versión mejora el flujo de conexión al bunker remoto, envía un logout de NIP-46 al firmante remoto cuando el usuario cierra sesión en una cuenta y corrige un indicador de carga bloqueado si falla la conexión a un firmante remoto. También corrige problemas al cargar DMs causados por conflictos entre relays de DMs y relays de la aplicación, publicaciones duplicadas al navegar a una respuesta y volver atrás, y muestra una miniatura del contenido multimedia en las filas de notificaciones.

Citrine v3.0.0 incorpora Negentropy, AUTH de NIP-42 y filtrado de relays onion

Citrine es un agregador de relays locales para Android. v3.0.0 es un salto de versión mayor que añade soporte de Negentropy de NIP-77 para sincronizaciones por reconciliación de conjuntos, soporte de firmante externo y AUTH de NIP-42 en el agregador de relays, y aplicación de listas de silencios de NIP-51 en las consultas del agregador. El agregador limita las consultas a tres relays por autor, con relays de origen e indexación configurables; reutiliza seguidores, silencios y metadatos almacenados en caché tras reinicios y cambios de red; se pausa en redes limitadas o restringidas; y filtra las URLs de relays onion cuando el proxy de salida está desactivado. Se rechazan los reposts que incrustan eventos protegidos y, de forma predeterminada, las listas de silencios quedan excluidas del borrado por antigüedad.

FIPS v0.4.0-rc1 añade transporte por mixnet Nym y descubrimiento mDNS en la LAN

FIPS es la implementación del protocolo de sincronización en malla FIPS. v0.4.0-rc1 es compatible por cable con v0.3.0, por lo que las mallas con versiones mezcladas interoperan y no requieren una actualización coordinada. La versión añade dos formas nuevas para que los nodos se encuentren y conecten: un transporte de salida por la mixnet Nym, con una demostración en un solo contenedor y un ejemplo de relay de mixnet, y descubrimiento opcional mDNS / DNS-SD en el enlace local. Una nueva consulta show_metrics solo de contadores permite usar un scraper de Prometheus sin coste en la ruta crítica, y el rekey de FMP y FSP se endureció para que no produzca interrupciones con pérdida de paquetes en ambas direcciones.

Calendar by Formstr v1.6.1 y v1.6.2 añaden notificaciones por evento

Calendar by Formstr es un cliente de calendario de NIP-52. v1.6.1 añade preferencias de notificación por evento (PR #109), para que el usuario pueda activar o desactivar recordatorios en cada evento de calendario. v1.6.2 corrige el inicio de sesión con Amber (PR #185), de modo que el nuevo handshake de NIP-46 de Amber 6.2.x funcione de extremo a extremo.

Bitchat v1.5.2 y v1.5.3 endurecen el transporte por Nostr y BLE

Bitchat es un cliente de chat en malla por Bluetooth y Nostr. v1.5.2 limita la frecuencia de notificaciones de peers en iOS para evitar inundaciones (PR #972) y endurece la validación de Nostr y las comprobaciones de anuncios BLE (PR #1012), por lo que la ruta de entrada Nostr del lado del relay rechaza ahora los mensajes malformados antes de que lleguen al manejador de la malla local. v1.5.3 corrige de urgencia un fallo al arrancar causado por un dispatch_once recursivo entre NostrRelayManager y NetworkActivationService (PR #1343).

Keep v1.0.5 traslada la política del firmante al núcleo Rust auditado

Keep es un firmante para Android que envuelve el núcleo Rust keep. v1.0.5 fija la dependencia en keep v0.4.8 e incorpora una corrección de una condición de carrera al iniciar el bunker (PR #296), para que el handshake ya no pierda el primer evento bajo carga; rellena la pantalla Authorized Clients desde el callback onConnect del bunker (PR #291); y consolida el apagado de emergencia en una única fuente de verdad en keep-mobile (PR #284). El núcleo Rust publicó v0.4.9 el 13 de junio, que traslada la superficie de políticas de firmante de NIP-55 y NIP-46 —decisión de permisos, límite de duración para kinds sensibles, caducidad, cadena de auditoría resistente a manipulaciones mediante HMAC con clave, confianza en el llamante en el primer uso y limitador persistente de frecuencia de firma— al núcleo Rust auditado, en lugar de duplicar la lógica en Kotlin, y añade una implementación del cifrado v3 de NIP-44; ese núcleo llegará en la próxima actualización de keep-mobile.

ants v0.4.5 añade enlaces a portales de artículos y recupera Habla

ants es la herramienta de búsqueda y lectura de Nostr de dergigi. v0.4.5 añade acciones en las tarjetas de publicaciones de formato largo, como enlaces a portales de artículos, compartición de naddr específicos del artículo, copia de nevent y acceso al JSON sin procesar. El conjunto de portales de artículos se renovó restaurando Habla, sustituyendo destinos desaparecidos y eliminando el portal imwald. La versión también recupera el renderizado de notas al pie con navegación por anchors dentro del artículo y espera a que haya conexión con un relay antes de obtener el perfil al restaurar el inicio de sesión, para que el avatar de la cabecera se resuelva correctamente.

Morganite v0.0.3 incorpora una caché Blossom local para Android con Tor bajo demanda

Morganite es una nueva caché Blossom local para Android de greenart7c3, autor de Amber y Citrine. La caché actúa como un espejo local de BUD-08 que elimina los blobs menos usados al superar 1 GB. v0.0.3 inicia Tor bajo demanda y lo detiene cuando está inactivo para ahorrar batería, desconecta el relay Nostr tras buscar al autor para evitar consumo en segundo plano, corrige el consumo de batería provocado por un flujo logcat sin filtrar y clientes HTTP filtrados, y libera los clientes OkHttp sustituidos fuera del hilo principal. La versión también obtiene los relays de bandeja de entrada del usuario antes de consultar la lista de servidores Blossom —para que el descubrimiento de blobs siga el modelo outbox— y descarga el blob en las peticiones HEAD cuando no está en la caché local, con lo que el precalentamiento de la caché queda ligado a la demanda real del cliente.

Coracle es un cliente web de Nostr de hodlbod. 0.6.34 corrige el inicio de sesión con NIP-46, un estado de feed obsoleto que impedía actualizar la cronología de inicio tras cambiar de vista y un selector de respuestas que, al activarse, lo filtraba todo. La versión también reconstruye las vistas de feeds y listas, corrige un problema con el margen de área segura de los toast y mejora la carga de imágenes. 0.6.35 es una pequeña continuación que evita ocultar los reposts cuando las respuestas están desactivadas, para que el filtro de reposts no aplique en exceso el filtro de respuestas.

Zeus v13.1.0-rc1 incorpora noffers CLINK y NWC sin cola

Zeus es una cartera de autocustodia de Bitcoin y Lightning con una superficie Nostr para wallet connect y pagos mediante noffers. v13.1.0-rc1 añade pagos Nostr Wallet Connect de NIP-47 sin cola en iOS —en colaboración con Primal—, de modo que una factura NWC pagada ya no espera en una cola en segundo plano; incorpora pagos mediante noffers CLINK, con Zeus Pay generando un noffer CLINK para cada cuenta para que un remitente pueda pagar a cualquier usuario de Zeus solo con su clave Nostr; y añade la posibilidad de desactivar los zaps Nostr en Zeus Pay, para que el receptor pueda deshabilitar la ruta de recibos kind 9735 sin desactivar NWC.

Alby Extension v3.14.3 migra las pilas criptográficas noble/scure que usa el firmante NIP-07

Alby Extension es la extensión de navegador que ofrece firma de NIP-07 y Nostr Wallet Connect junto a su superficie Lightning. v3.14.3 migra las pilas @noble/curves, @noble/hashes, @noble/ciphers, @noble/secp256k1, @scure/bip32 y @scure/base a las versiones mayores v2 y v3. Son las bibliotecas criptográficas en las que se apoya la ruta del firmante NIP-07 para firmar eventos y cifrar con NIP-44, por lo que un salto de versión mayor afecta al formato de cable que la extensión produce para cada petición de firma de eventos de un cliente web Nostr.

Mostro Mobile v1.2.8 y v1.2.9 admiten Protocol v2 y muestran la política de fianzas

Mostro Mobile es el cliente móvil de Mostro. v1.2.8 incorpora el soporte en el cliente para Protocol v2 de mostro-core v0.13.0, cubierto en la historia principal anterior, y añade 17 funciones en total, entre ellas la fianza antiabuso del maker del PR #608, descubrimiento de relays de arranque del PR #610, persistencia de las cancelaciones de órdenes en el historial de notificaciones del PR #602 y límites de importe fiat en la pantalla de creación de órdenes del PR #605. v1.2.9 muestra la política de fianza antiabuso del evento de información del nodo (PR #617), para que el usuario pueda ver las reglas de fianza de la instancia de Mostro antes de abrir una orden.

ZapBook builds 4 a 27 incorporan multicuenta, publicación de claves Marmot y reinvitaciones a círculos

ZapBook es una aplicación de lectura social nativa de Nostr de codeswot para iOS y Android, organizada en torno a círculos de lectura de 1 a 100 personas que comparten hitos y se envían zaps en sats como estímulo. Entre el build 4 del 11 de junio y el build 27 del 15 de junio, el proyecto publicó 17 builds etiquetados y fusionó 7 PRs. El soporte multicuenta con cambio fluido de cuenta llegó en el PR #25, para que el usuario pueda mantener varias identidades Nostr en la aplicación y migrar sesiones entre ellas. La publicación inicial de key packages de Marmot —kind 443— se activa ahora automáticamente al completar la incorporación (PR #20), requisito previo para la mensajería de grupo solo por invitación en los círculos de lectura. El manejo de miembros eliminados de círculos procesa ahora correctamente las reinvitaciones nuevas (PR #24), lo que cierra una clase de fallos por los que los miembros readmitidos no recibían invitaciones nuevas después de haber sido eliminados. La serie de versiones también descarga la inferencia de embeddings ONNX a un isolate en segundo plano (PR #19) para la búsqueda semántica dentro del lector e integra el servicio NWC con un APP_ID_SUFFIX para configuraciones específicas del entorno, de modo que un solo hub pueda atender varios builds de ZapBook.

Alby Hub v1.23.0 corrige la publicación NIP-47 para aplicaciones eliminadas y cambia Bitrefill a NWC

Alby Hub es un hub de Lightning y Nostr autoalojado. La superficie ajena a Nostr de v1.23.0 es amplia —canales Just-in-Time, una página Cards para recargas de tarjetas de débito, un backend experimental de pagos Ark y una página de inicio con historias— y queda fuera del alcance de Compass. En cuanto a NIP-47, la versión deja de reintentar la publicación de información NIP-47 para aplicaciones eliminadas, de modo que una conexión retirada ya no sigue republicando su evento de información kind 13194 (PR #2391), y elimina la entrada de aplicación personalizada de Bitrefill en favor de una conexión NWC estándar (PR #2420). La opción de solo lectura para aplicaciones de la tienda (PR #2415) restringe los permisos de las aplicaciones NWC publicadas mediante la tienda integrada en el hub.

También publicadas

Versiones más pequeñas de esta semana con contenido relevante para Nostr pero poca sustancia por versión: Nostria v3.1.48 a v3.1.50, que continúa el despliegue de Web Bookmarks con mejoras de fiabilidad de notificaciones y optimización de la base de datos de hilos de eventos en v3.1.50; Deepmarks v0.7.0 a v0.7.5, que itera sobre el cliente de marcadores sociales NIP-B0 —el proyecto también añadió esta semana el enlace a su web en el PR #96—; Keep v1.1.1 a v1.1.4, con cuatro correcciones de builds reproducibles de F-Droid sobre la versión v1.0.5 del firmante cubierta antes; NoorNote v0.11.1, v0.12.0, v0.13.0 y v0.13.1, del cliente de notas para escritorio; Boris v0.12.2, del lector Boris; Nostr Mail Client v0.13.0; Feeder 2.21.1; nak v0.19.13, una actualización de mantenimiento vacía de la CLI Nostr; Hashtree v0.2.68 a v0.2.71, que renueva las cachés de raíces mutables del gateway del publicador de versiones direccionado por árboles de hashes; NYM v3.72.501 y v3.72.502, que actualizan la implementación de relay basada en Nostrify; swift-nostr-client 0.3.0, 0.4.0 y 0.5.0, tres versiones menores respaldadas por 85 PRs fusionados en el cliente Nostr para iOS; lawallet-nwc v0.11.0, con 18 PRs fusionados en el puente Nostr Wallet Connect de LaWallet; Astraea v5.35.59 a v5.35.62, que itera sobre el cliente Nostr Astraea; y los bots de DM Nostr con NIP-05 verificado de BTC Recharge y giftcardshop, añadidos al directorio de proyectos bajo una nueva categoría Shops.

Cambios aún no publicados

diVine fusiona 119 PRs hacia la próxima versión de vídeos cortos

diVine es un cliente de vídeos cortos en bucle nativo de Nostr que recupera el archivo de Vine sobre una base Nostr. El proyecto fusionó 119 PRs esta semana sin publicar una versión etiquetada. El trabajo sustancial en la superficie Nostr incluye una ruta de publicación de vídeos que prioriza REST para que la ausencia de un OK del relay ya no aparezca como fallo (PR #5221 y PR #5220); la reaplicación de la blocklist en cuadrículas curadas y de favoritos cuando cambia la blocklist general (PR #5208); la recuperación de la lista de conversaciones por DM tras una regresión al reinstalar (PR #5202); la restauración de insignias Nostr en los perfiles (PR #5218); y referencias nostr: convertidas en enlaces en las citas de comentarios (PR #5225). La pila del editor de vídeo añadió selección múltiple para combinar o eliminar clips, un lienzo con zoom mediante gesto de pinza y un fondo letterbox que sigue el zoom, además de recorte, rotación y volteo de clips.

Pollerama fusiona 15 PRs en la ventana con una revisión del firmante y una oleada de funciones

Pollerama, repositorio formstr-hq/nostr-polls, es el cliente nativo de Nostr de encuestas y feeds de la familia Form*, hermano de Calendar by Form*, que publicó v1.6.2 esta semana. La última versión etiquetada de nostr-polls es v1.6.4, de marzo, por lo que el trabajo de esta ventana está previsto para la próxima etiqueta y todavía no se ha publicado; aun así, el flujo de fusiones es intenso: quince pull requests llegaron entre el 9 y el 16 de junio, con aportaciones de abh3po, geralt-debugs y SIDDHANTCOOKIE. En el firmante, el proyecto sustituyó la superficie de firma existente en el PR #198 y actualizó la sustitución en el PR #201; el PR #200 impide además que las actualizaciones de metadatos kind 0 se activen al iniciar sesión, para que una autenticación nueva no publique un evento de perfil que el usuario no solicitó. La oleada de funciones incluye un editor de perfiles con publicación desde la vista del perfil (PR #205), un flujo de repost mejorado (PR #209) y una ruta más sencilla para descubrir temas (PR #202). La próxima versión etiquetada incorporará todo este trabajo.

Trabajo en bibliotecas y herramientas

El PR #375 de NDK y el trabajo fusionado en los repositorios rust-nostr y nostr-tools estuvieron tranquilos esta semana, con uno o dos PRs fusionados cada uno y ninguna versión etiquetada. Continuó la actividad en ContextVM SDK, con 1 PR fusionado; mesh-llm, con 37 PRs fusionados y 8 abiertos; Zap Cooking, con 26 PRs fusionados; y Routstrd, con 2 PRs fusionados, todos sin una etiqueta de versión en la ventana.

Actualizaciones de NIPs y trabajo en especificaciones de protocolo

El trabajo de protocolo de esta semana se concentra en dos áreas: el endurecimiento de firmantes y la gobernanza de grupos de NIP-29.

Fusionado esta semana:

NIP-46 (Nostr Connect). El PR #2373 añade un método logout que permite al cliente cerrar correctamente una sesión de firmante remoto. Amber, Clave y Nostur incorporaron soporte durante la misma semana.
NIP-CC (Community Chat). El PR #2365 actualiza NIP-CC para que haga referencia a la especificación moderna NIP-GC (Group Chat) para la maquinaria del lado del cliente, alineando la especificación de salas comunitarias con la primitiva canónica de chat grupal.

Conjunto abierto de NIP-29 (gobernanza de grupos basada en relays):

Tags de banner. El PR #2383 añade un tag banner al evento kind 39000 de metadatos del grupo.
Sufijo de código de invitación. El PR #2380 introduce un sufijo de código de invitación en el identificador del grupo, para poder codificar una invitación de un solo uso en el propio ID del grupo.
Fijado de mensajes. El PR #2379 añade una acción de moderación para actualizar la lista de mensajes fijados y un evento kind 39005 que difunde el conjunto fijado.
Denuncias de grupo mediante DMs NIP-17. El PR #2377 define un flujo de denuncia por el que los miembros informan de abusos en el grupo al contacto administrativo del relay mediante DMs gift wrap de NIP-17, manteniendo el tráfico de moderación fuera del flujo público de eventos del grupo.
Control de acceso basado en roles. El PR #2376 añade una superficie RBAC sobre la separación existente entre administradores y miembros.

Continuaciones abiertas de NIP-46:

Metadatos del cliente en la petición de conexión. El PR #2381 permite que el cliente que se conecta envíe campos opcionales name, url e icon en su petición, para que el firmante pueda mostrar la identidad de la aplicación en la pantalla de emparejamiento. Clave build 101 implementa la propuesta.
Evitar timeouts silenciosos. El PR #2375 endurece la especificación para que un firmante que necesite intervención del usuario mantenga abierta la petición hasta que este decida, corrigiendo el modo de fallo que Clave build 100 solucionó en la implementación.

Otro trabajo abierto:

NIP-100 Sovereign Agent Identity Network (SNIN). El PR #2378 propone un protocolo entre agentes para descubrir identidades y capacidades de agentes autónomos. La propuesta es amplia y probablemente se dividirá en piezas más pequeñas durante la revisión.

Especificación Blossom. El PR #108 de BUD-00 se fusionó el 15 de junio y amplía la definición de BUD para abarcar convenciones del lado del cliente y formatos de datos construidos sobre blobs Blossom que los servidores no implementan. El cambio incorpora BUDs como BUD-10 —el esquema URI blossom:— y BUD-08 —las convenciones de caché local que Morganite implementa esta semana— a la numeración canónica, donde antes se trataban como extensiones externas.

Análisis en profundidad: NIP-77 (Negentropy)

NIP-77 define un protocolo de reconciliación de conjuntos para relays Nostr. Dos partes —un cliente y un relay, o dos relays en un puente— mantienen cada una un conjunto de eventos que coincide con un filtro y quieren converger en la unión sin reenviarlo todo. El enfoque ingenuo consiste en volcar por la red todos los ID de eventos y calcular la diferencia; para un filtro con mucha actividad, el coste crece con el tamaño del conjunto mayor sin importar cuánto difieran. NIP-77 reduce ese coste para que sea proporcional a la diferencia simétrica.

La especificación se apoya en dos mensajes de relay, NEG-OPEN y NEG-MSG. El cliente abre una sesión de reconciliación con ["NEG-OPEN", <subscription_id>, <filter>, <initial_message>], donde <initial_message> es un payload Negentropy codificado en hexadecimal que describe la vista del conjunto del cliente. Las respuestas llegan como frames NEG-MSG y ambas partes intercambian mensajes hasta alcanzar un punto fijo. Cada NEG-MSG reduce el desacuerdo —dividiendo un rango en subrangos con sus propias huellas— o termina una hoja —enumerando los ID de un rango pequeño para que el receptor pueda calcular directamente la diferencia—. Cuando una parte determina que la otra tiene eventos que le faltan, envía un REQ normal para esos ID; cuando posee eventos que le faltan a la otra, la especificación deja la ruta de subida a una publicación EVENT normal en el otro extremo.

La estructura de datos subyacente es una variante secuenciada de un árbol de Merkle. Cada evento del conjunto local se identifica mediante (created_at, id) y se agrupa en rangos; cada rango lleva una pequeña huella calculada a partir de los ID que contiene. Cuando la huella coincide entre cliente y relay, el rango ha convergido y se omite. Cuando difiere, la parte que responde divide el rango en mitades —o subrangos— y envía las huellas de cada una, avanzando de forma recursiva por el desacuerdo. Los rangos hoja —por debajo de un umbral pequeño de eventos— se envían literalmente. La propiedad clave es que confirmar rangos convergentes cuesta casi nada, con independencia del número de eventos que contengan.

El encuadre en orden de created_at importa por dos motivos. Primero, la paginación existente de Nostr usa until y since con la misma marca de tiempo, por lo que un reconciliador puede reanudar entre sesiones sin volver a sincronizar todo el archivo: almacena en caché el límite superior y comienza allí la siguiente sincronización. Segundo, las divisiones de rango son deterministas dada una clave ordenada, de modo que cliente y relay siempre coinciden en el siguiente límite sin necesitar otro mensaje de negociación. El coste de una sincronización es aproximadamente O(d log n), donde d es el tamaño de la diferencia simétrica y n el del conjunto mayor, muy por debajo del coste O(n) de volcar ingenuamente los ID y de los O(n) viajes de ida y vuelta de emitir N peticiones REQ.

La implementación presenta tres compromisos. El tamaño de la huella —la especificación usa 32 bytes por rango— equilibra probabilidad de colisión y ancho de banda: las huellas menores ahorran bytes pero aumentan la posibilidad de una coincidencia espuria que descarte eventos. El umbral de hoja —cuándo dejar de dividir y volcar literalmente los ID— equilibra viajes de ida y vuelta y ancho de banda por mensaje: los umbrales menores requieren más rondas y los mayores producen mensajes hoja más grandes. Además, el protocolo supone que ambas partes pueden calcular la misma huella sobre el mismo rango; esto exige una serialización estable de los pares (created_at, id) que compartan ambas implementaciones, de ahí la precisión de la especificación sobre el orden de bytes en la construcción de la huella.

Un relay que anuncia NIP-77 en su campo supported_nips de NIP-11 permite a los clientes reconciliar en lugar de —o junto a— una sincronización normal basada en REQ. El cliente elige el protocolo según sus necesidades: una suscripción nueva que busca tráfico reciente usa REQ porque no hay un estado anterior que reconciliar; un espejo de larga duración que necesita ponerse al día tras una interrupción usa NEG-OPEN porque la diferencia simétrica es pequeña respecto al archivo. Ambas rutas se complementan en contextos de despliegue distintos.

Ejemplo de intercambio NEG-OPEN:

→ ["NEG-OPEN", "sync-1", {"kinds":[1],"authors":["abc..."]}, "<hex initial Negentropy message>"]
← ["NEG-MSG", "sync-1", "<hex relay response>"]
→ ["NEG-MSG", "sync-1", "<hex client refinement>"]
← ["NEG-MSG", "sync-1", "<hex leaf with IDs the relay has and client lacks>"]
→ ["REQ", "fetch-1", {"ids":[...]}]
← [...EVENT messages...]
← ["EOSE", "fetch-1"]
→ ["CLOSE", "sync-1"]

Citrine v3.0.0 incorpora esta semana soporte de NIP-77 en el agregador de relays, la primera vez que la superficie de relay local en Android puede reconciliar con relays externos en lugar de realizar consultas REQ masivas.

Análisis en profundidad: NIP-61 (Nutzaps)

NIP-61 define pagos P2P con ecash Cashu entregados como eventos Nostr. El remitente publica un token Cashu bloqueado con la clave pública derivada de Nostr del destinatario, y este lo canjea en el mint cuando le convenga. A diferencia de los zaps NIP-57, que exigen que el receptor esté accesible mediante Lightning en el momento del pago, un nutzap es un token ecash autocontenido que el destinatario puede canjear cuando quiera.

La especificación compone tres kinds de eventos con la primitiva de bloqueo P2PK de Cashu. Kind 10019 es la recomendación de mint del destinatario: un evento reemplazable que enumera uno o varios mints de los que acepta nutzaps, además de la clave pública Cashu usada para bloquear las proofs a su favor. Esta clave es distinta de la clave de identidad Nostr del destinatario; es una clave limitada a la cartera, derivada para recibir nutzaps, de forma que la clave de identidad nunca tenga que tocar secretos de ecash. Los remitentes leen el evento kind 10019 antes de enviar, para que el token que construyan pueda canjearse en un mint en el que el destinatario ya confía.

Kind 9321 es el evento de pago. Lleva uno o varios tags proof de Cashu —cada uno contiene una proof bloqueada mediante P2PK y vinculada a la pubkey de nutzap del destinatario del evento kind 10019—, un tag u con la URL del mint, tags opcionales e y a que identifican una nota que recibe el zap, y un tag p para el destinatario. Este recibe el evento kind 9321 mediante su suscripción normal a Nostr, valida que las proofs estén bloqueadas con su pubkey de nutzap en un mint incluido en su propio evento kind 10019, las desbloquea con la clave privada correspondiente y las conserva en su cartera de NIP-60 o las funde a Lightning. Kind 7375 registra las proofs canjeadas en la cadena de eventos de la cartera del destinatario, para que una cartera que vuelva a sincronizar desde relays no contabilice dos veces proofs de nutzap del mismo origen.

El modelo de confianza es el precio explícito del diseño. Los mints Cashu custodian el valor subyacente; un mint malicioso o incautado puede negarse a canjearlo. NIP-61 hereda ese riesgo de custodia de NIP-60 y no intenta eliminarlo. A cambio, el diseño permite micropagos con finalidad instantánea y capacidad offline: el token es el pago, el destinatario no necesita ejecutar un nodo Lightning ni aceptar HTLCs entrantes en tiempo real, y un remitente que mantenga proofs en el mismo mint puede pagar sin un solo salto de red a un custodio. El anuncio kind 10019 es la barrera de la capa social: los remitentes que eligen un mint fuera del conjunto de confianza del destinatario arriesgan enviar un token no canjeable, lo que mantiene predecible la superficie de canje del receptor.

En comparación con NIP-57, la ruta de verificación también es más sencilla. Un recibo de zap NIP-57 es un evento kind 9735 publicado por el servicio LNURL del destinatario, lo que exige que el verificador consulte el endpoint LNURL y confirme que la clave de firma del recibo coincide con la declarada por el endpoint. Un nutzap lleva en línea la prueba criptográfica de pago —las propias proofs bloqueadas mediante P2PK—, por lo que cualquier verificador con las claves públicas del mint puede confirmar que son válidas sin consultar a un tercero. El compromiso es que verificar un nutzap exige comprender los keysets del mint, mientras que verificar NIP-57 solo requiere infraestructura LNURL estándar.

Los dos formatos de zap conviven como complementos. Los zaps NIP-57 siguen siendo la opción adecuada para receptores con enrutamiento Lightning y remitentes que quieren denominar en sats con la semántica de liquidación de Lightning. Los zaps NIP-61 resultan apropiados para receptores sin conexión, flujos con muchos micropagos donde las comisiones Lightning superan el valor transferido y clientes dirigidos a usuarios sin infraestructura Lightning.

Ejemplo de evento nutzap:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1750162800,
 "kind": 9321,
 "tags": [
 ["proof", "{\"amount\":21,\"secret\":\"...\",\"C\":\"...\",\"id\":\"...\"}"],
 ["u", "https://mint.example.com"],
 ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3"],
 ["p", "c5d8a4e3b2a1f0e9d8c7b6a5949382716050403020100ffeeddccbbaa99887766"]
 ],
 "content": "Great post!",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Amethyst v1.12.0 incorpora esta semana renderizado integrado de nutzaps NIP-61 junto a su superficie de cartera NIP-60 (PR #3075), lo que convierte a Amethyst en el primer cliente Android dominante que muestra los nutzaps recibidos en la cronología y ofrece vistas de saldo por mint en la cartera.

Nostr Compass #26

Wed, 10 Jun 2026 00:00:00 +0000

La organización Marmot Protocol abre tres nuevos repos para un borrador de protocolo v2 y un linaje de clientes nativos: un workspace Rust llamado darkmatter, una app iOS SwiftUI darkmatter-ios y una app Android Kotlin/Compose darkmatter-android. El Whitenoise Flutter original se archiva. Chama comprime diecisiete lanzamientos en una semana y cruza la línea de app independiente en v3.0.0 antes de aterrizar un rediseño completo de la UI de la sala de intercambio y storefronts por vendedor en v3.1.0, encima de shares Shamir solo del titular, sustitución de árbitro, enrutado de comunidad mundial y notificaciones de intercambio de extremo a extremo. Coracle lanza un servicio de relay alojado de pago respaldado por la pila de código abierto Caravel y zooid, con integración profunda de Flotilla planeada. Angor cambia a mainnet por defecto en v0.2.30 y aterriza una prueba de financiación UAT de 3 usuarios en v0.2.29. Amethyst aterriza 41 PRs no publicados continuando el trabajo de NIP-32 / NIP-F4 / Tor de la semana pasada. NIP-67 (pista de completitud EOSE) y autocompletado NIP-50 se fusionan, cerrando dos brechas de corrección de larga data en el protocolo de relay central. NIP-GART propone un formato de cable que preserva la privacidad para alertas de emergencia, y NIP-46 recoge un método de logout.

Historias principales

Marmot v2 (Dark Matter): borrador de protocolo, clientes nativos, app Flutter archivada

Esta semana surgieron tres nuevos repos bajo la organización GitHub marmot-protocol, formando juntos la forma temprana de progreso de un borrador del protocolo Marmot v2 y un linaje de clientes nativos que reemplaza la línea de app Flutter. darkmatter (Rust, creado el 13 de mayo, treinta y cuatro commits en los últimos siete días) alberga el borrador del protocolo v2 en spec/, un motor CGKA respaldado por OpenMLS en crates/cgka-engine, un simulador de conformidad con pruebas de propiedad y un modelo formal Tamarin para pruebas de convergencia. darkmatter-ios (Swift, creado el 25 de mayo) es un cliente SwiftUI respaldado por un xcframework UniFFI MarmotKit vendorizado generado desde el workspace Rust. darkmatter-android (Kotlin/Jetpack Compose, creado el 25 de mayo) se apoya en los mismos bindings Rust. El Whitenoise Flutter original ha sido marcado whitenoise-archive (“ARCHIVED: This was the original White Noise Flutter app”); un nuevo repo Dart whitenoise lleva la línea Flutter activa en paralelo.

Lee esto como un progreso temprano hacia un Marmot más fiable, no como un pivote terminado. El README de darkmatter se autodenomina “Candidate Marmot v2 protocol draft, CGKA engine, and conformance workspace” y dice directamente: “MDK remains the deployed Rust protocol implementation until this draft and engine are adopted.” Dentro del workspace, el crate cgka-engine está etiquetado 0.1.0, “single internal consumer, not semver-stable.” Cada página de especificación lleva “Status: draft for internal review”. Tres estrellas en el repo del workspace y cero en las apps iOS y Android confirman que el trabajo es pre-anuncio. La dirección, el alcance y la disciplina son la señal aquí; la disponibilidad para producción no es la afirmación.

El borrador del protocolo concreta los deltas v1-a-v2. La extensión MLS monolítica marmot_group_data de MIP-01, que ha llevado el nombre del grupo, descripción, pubkeys de admin, id de enrutado del grupo Nostr, lista de relays, datos de imagen del grupo y ajustes de mensajes efímeros bajo un solo paraguas desde el inicio de Marmot, se divide en componentes de app versionados: marmot.group.profile.v1 para nombre y descripción, marmot.group.admin-policy.v1 para pubkeys de admin, marmot.transport.nostr.routing.v1 para el nostr_group_id aleatorio y la lista canónica de relays, marmot.group.blossom.image.v1 para hash de imagen, clave de cifrado, nonce y clave de subida, y marmot.group.message-retention.v1 para los segundos de mensajes efímeros. Cada componente posee sus bytes exactos y su propia ruta de versionado, para que una futura característica pueda revisar un componente sin forzar al resto del estado del grupo a retransitar el consenso de la extensión MLS. Las credenciales MIP-00 también ganan un nuevo documento base account-identity-proof-v1.md, señalado como “new in v2 and breaking”. La prueba de identidad ahora vive en su propia superficie, separada de la construcción del KeyPackage.

Los deltas de biblioteca respaldan el retrabajo de especificación. cgka-engine es la nueva máquina de estado local del grupo: envuelve OpenMLS, posee los estados de época Stable, PendingPublish, Merging y Recovering, traduce las intenciones en commits MLS, devuelve valores tipados IngestOutcome y GroupEvent para cada envoltorio de transporte entrante, y explícitamente no distribuye transporte ni persistencia. Un trait TransportPeeler separa Nostr del motor, y un trait StorageProvider separa SQLite (mediante storage-sqlite, respaldado por SQLCipher) del motor. El MDK de hoy empaqueta todo esto junto; dividir las capas permite que un motor se ubique bajo un transporte de relay Nostr ahora y los también distribuidos transportes QUIC stream y broker más tarde, sin reescritura del modelo de convergencia. La propia convergencia está documentada como distributed-convergence.md y probada en un modelo Tamarin que cubre selección determinista de rama, elegibilidad regulada por política, replay de ancla retenida, rechazo de rama obsoleta, reordenado de entrega, duplicación, invalidación de salida de app, traspaso welcome/commit, consumo de propuesta y regulación saliente durante la sincronización. Las pruebas de propiedad Rust luego verifican que el motor sigue las mismas reglas con objetos OpenMLS reales y el arnés del simulador. Trabajo de fiabilidad con métodos formales de este alcance está ausente de la pila Marmot actual.

Ambos clientes nativos abandonan Flutter por kits de UI nativos de la plataforma. darkmatter-ios es SwiftUI puro con una Notification Service Extension que descifra los despertares de push MIP-05 en el dispositivo, vendoriza un paquete Swift MarmotKit generado desde el workspace Rust y se registra bajo el bundle ID y app group dev.ipf.darkmatter. darkmatter-android es Kotlin y Jetpack Compose, con una compilación impulsada por just que produce un APK arm64-v8a firmado y lee endpoints de telemetría desde local.properties. El README de Android indica el principio arquitectónico directamente: “Dark Matter owns protocol data and stores it in SQLite. The Android app should render that data, manage Android platform behavior, and keep UI lifecycle state. The Android app should not become a second database for Dark Matter data.” Eso refleja la disciplina de frontera que el README de cgka-engine aplica en la capa Rust, aplicada a la capa UI.

Los clientes nativos importan para Marmot porque la debilidad más citada del protocolo ha sido la fiabilidad móvil bajo condiciones de entrega irregulares: despertares de notificación perdidos, carreras de commit MLS durante fluctuaciones de red, límites de background-fetch que dejan varados los avances de época. SwiftUI y Compose dan a los clientes acceso directo a las primitivas de procesamiento en segundo plano de la plataforma que Flutter alcanza mediante un puente de plugin, y la ruta de binding UniFFI mantiene la lógica del protocolo en un único workspace Rust distribuido como una biblioteca estática en ambas plataformas. La línea Whitenoise Flutter continúa en el repo desarchivado whitenoise, por lo que el anuncio es aditivo: un nuevo linaje de cliente nativo corre junto a la app Flutter mientras la especificación v2 converge. El corte de producción desde MDK o la app Whitenoise actual espera a que el borrador, el motor y los clientes alcancen lanzamientos listos para producción.

Chama de v2.0.0 a v3.1.0: escrow P2P independiente en una semana

El cliente de escrow P2P nativo de Nostr introducido en Newsletter #25 en v1.3.0 publicó diecisiete lanzamientos etiquetados en los últimos siete días, terminando en v3.1.0 el 9 de junio con un rediseño de la UI de la sala de intercambio y storefronts por vendedor. El rastro de versiones cuenta la historia: v2.0.0 es la base BREAKING, luego v2.0.1, v2.0.2 y v2.0.3 cierran las brechas del pay-rail de financiación por WebView Fedi; v2.1.0, v2.2.0, v2.3.0 y v2.3.1 endurecen la capa del árbitro; v2.4.0, v2.5.0 y v2.6.0 añaden superficies de auto-custodia y enrutado de comunidad mundial; v2.7.0, v2.8.0, v2.9.0 y v2.10.0 superponen texto de clave en lenguaje llano, aplicaciones de grupo, arbitraje por plazo de disputa y reputación. v3.0.0 ata el paquete con notificaciones de intercambio de extremo a extremo, y v3.1.0 el 9 de junio redibuja la pantalla de intercambio en torno a una columna vertebral de progreso Reserved → Locked → Settled, tarjetas de acción coloreadas por rol y una clase de listado de storefront por vendedor (swaps curados, loanbooks y facturas) que se distribuyen.

El pivote arquitectónico vive en v2.0.0. El formato LOCK de escrow cambió para que cada share de una división Shamir 2-de-3 se cifre solo a su titular (sharePolicy holder-only-v1). El ecash al portador de la federación ya no se reconstruye desde un único participante solo, cerrando una ruta donde una parte maliciosa con su propio share y un share retenido por la federación podía completar el intercambio sin consentimiento. Los clientes pre-2.0 fallan ruidosamente con “can’t find your share”; el intercambio no puede completarse en un cliente obsoleto, y no se pierden fondos en el proceso. Un lock v2.0 requiere que cada parte esté en v2.x para liquidar. v2.0.0 también añadió storefronts multi-unidad y una vista Market solo en sats.

v2.1.0 introdujo la sustitución de árbitro: el share del árbitro en el índice Shamir 2 ahora se cifra en un orden de prioridad determinista sobre el pool de árbitros de la comunidad, para que un árbitro ausente pueda ser reemplazado sin varar el intercambio. v2.2.0 probó que la sustitución funcionó en producción en un intercambio de ₿121 y añadió respaldos de sustitución de curación. v2.3.0 cerró la última brecha de front-running de árbitro comprobando la membresía de comunidad del árbitro del listado en el momento del lock, y v2.3.1 cerró la carrera hermana donde un slot de árbitro autoasignado era una vista previa hasta que el lock los asentaba.

Las superficies de auto-custodia llegaron en v2.4.0 (frase de recuperación BIP-39 para la wallet de ecash Fedimint, almacenada cifrada en Nostr) y v2.5.0 (respaldo del nsec maestro que posee la identidad Nostr y la semilla de la wallet). v2.6.0 reelaboró el onboarding en torno a un selector de comunidad global para que los usuarios en países sin una Chama local se enruten a la federación más cercana; las compilaciones anteriores rebotaban al usuario sin fallback. v2.7.0 reescribió la pantalla de clave de recuperación en lenguaje llano (“la única clave a tu cuenta y al dinero en ella; Chama nunca la ve y no puede resetearla; si la pierdes, nadie puede recuperar tu cuenta”). v2.8.0 añadió aplicaciones de grupo, tematización oscura/clara y añadió dos nuevos kinds de evento (38120 roster, 38121 aplicación). v2.9.0 cambió la resolución de disputas en el plazo: los intercambios impugnados que llegan a su expiración ahora se resuelven por dictamen del árbitro; el comportamiento anterior auto-reembolsaba. El lanzamiento está marcado COORDINATED por lo que todas las partes en una disputa deben actualizar. v2.10.0 añadió valoraciones pulgar-arriba/pulgar-abajo por intercambio como un nuevo kind de evento 38123.

v3.0.0 es el hito donde la app deja de necesitar una comunidad coordinadora para operar. Las notificaciones de intercambio de extremo a extremo hacen ping al usuario solo en transiciones de estado accionables: la contraparte bloqueó los sats, el pago está listo para reclamar, la disputa requiere el dictamen del usuario como árbitro, o el intercambio se liquidó o expiró. Un interruptor en la pantalla Me activa o desactiva las notificaciones, y el prompt de permiso solo se dispara cuando el interruptor está habilitado. El dedup fire-once evita que una recarga de estado dispare una tormenta de alertas. También se cerró un bug del guardarraíl wrong-chama en PR #103, donde versiones anteriores podían estampar un listado con la etiqueta de una chama pero la federación de otra chama. Los bundles de escritorio para Windows y Linux se distribuyen con el lanzamiento; el dmg de macOS se retiene hasta que la firma y la notarización aterricen.

Chama ahora se une a Mostro y Shopstr como un marketplace nativo de Nostr, distinguido por arquitectura sin servidor, escrow Shamir 2-de-3 respaldado por Fedimint, cifrado de shares solo del titular y ser el único de los tres que distribuye un cliente de escritorio y móvil autocontenido sin una comunidad coordinadora.

Coracle Hosting: servicio de relay de pago más pila Caravel de código abierto

El 3 de junio Hodlbod anunció Coracle Hosting en hosting.coracle.social, un servicio de relay comunitario alojado que acepta pagos lightning recurrentes sobre NWC o tarjeta. El servicio está impulsado por Caravel, el frontend de facturación y aprovisionamiento de Coracle, y zooid, un runtime de relay que aloja muchos relays virtuales en una sola máquina. Ambos son de código abierto en el gitea auto-alojado de Coracle. Caravel se distribuye con integración opcional de livekit y Blossom que los operadores pueden activar por relay. Un nivel gratuito con límites de conteo de miembros permite a los operadores evaluar el servicio antes de comprometer los datos de pago.

Hodlbod es franco sobre el modelo de negocio: monetizar código abierto vendiendo una versión alojada de una pila que cualquier otro puede también ejecutar. El foso competitivo es la integración con Flotilla, que es el siguiente paso planeado. Flotilla posee la superficie de usuario, por lo que la opción alojada servida desde dentro de Flotilla se convierte en la ruta por defecto para cualquier usuario que prefiera infraestructura gestionada. Hodlbod ofreció añadir otros operadores de Caravel al selector de alojamiento alternativo de Flotilla si contactan, manteniendo la puerta abierta a un mercado de alojamiento federado.

Caravel se une a relay.tools como una plataforma pública de aprovisionamiento de relays Nostr con niveles de miembros de pago. relay.tools precede a Caravel y se distribuye como el servicio dominante de creación de relays hoy, con su propio directorio de relays comunitarios y flujos de unión de miembros o moderadores de pago. La característica distintiva de Caravel es la pila coordinada: el runtime del relay (zooid), el frontend de facturación y aprovisionamiento (Caravel mismo) y el selector del lado del cliente (integración con Flotilla, aún en vuelo) se distribuyen como un solo diseño. La otra característica distintiva es la densidad de muchos-relays-por-proceso de zooid, donde los relays de clientes comparten un único proceso host para que el operador amortice los costes de alojamiento entre muchas comunidades pequeñas. Este es el mismo argumento de densidad que hizo viable el shared web hosting a principios de los 2000, aplicado a la capa de relay de Nostr.

Lanzamientos

Angor v0.2.29 y v0.2.30: mainnet por defecto y prueba de financiación UAT de 3 usuarios

Angor v0.2.29 el 4 de junio y v0.2.30 el 8 de junio son los dos lanzamientos de esta semana para el protocolo descentralizado de financiación Bitcoin-y-Nostr. El cambio destacado de v0.2.30 es PR #893, que cambia la red por defecto a mainnet. Angor aún se distribuye como un lanzamiento alfa inestable, pero el cambio a mainnet por defecto señala que el protocolo ha superado la fase solo-testnet para los clientes de escritorio y móvil. v0.2.30 también aterriza un flujo de creación de proyecto móvil de un solo toque con subida de imagen y reset de scroll (PR #889) y resuelve una condición de carrera donde el spinner de la factura lightning podía colgarse (PR #890).

v0.2.29 añadió una prueba UAT de extremo a extremo en PR #881 cubriendo envío de fondos de 3 usuarios en 10 rondas con gastos no confirmados, la primera prueba de flujo de financiación multi-usuario en el conjunto de pruebas de Angor. El lanzamiento también añadió un plan de implementación para una CLI y servidor MCP de Angor (PR #792), con mejoras en el CLI para el flujo de trabajo de pruebas MCP en PR #880. PR #885 de DavidGershony corrigió una factura lightning Boltz que usaba la red incorrecta tras un cambio de red en runtime, un bug que habría aflorado en producción tras el cambio a mainnet por defecto de v0.2.30. Los ajustes ahora ofrecen una purga opcional del archivo de wallet de recuperación durante el borrado de datos (PR #883).

Sprout v0.3.15: refresco de TTL de canal efímero y comandos slash ACP

Sprout v0.3.15, publicado el 10 de junio, es el octavo lanzamiento en una serie que comenzó con v0.3.7 el 2 de junio. Newsletter #25 cubrió la serie v0.3.1 a v0.3.6 con la integración mesh-llm y el trabajo de secciones de canal; v0.3.7 a v0.3.15 son downstream de eso, centrados en pulido y algunas adiciones de cara al usuario. El cambio más visible al usuario es un refresco de TTL para canales efímeros en PR #902: cuando un usuario desarchiva un canal efímero, Sprout extiende el time-to-live del canal para que el desarchivado no re-archive inmediatamente bajo el temporizador de expiración original. Los emojis personalizados en móvil llegan en PR #906 junto con un rediseño de ajustes, y los conteos de reacción ahora se animan al cambiar (PR #904).

PR #905 corrige una brecha de larga data donde los nombres de visualización de múltiples palabras se rompían y la extracción de menciones nostr:npub de NIP-27 se descartaba silenciosamente. Una UI de equipo respaldada por directorio para escritorio se distribuye en PR #912 con comandos install, sync y reveal. Los comandos slash ahora pasan a los conectores ACP en PR #919, permitiendo a Sprout reenviar comandos estilo /help directamente a los runtimes de agente mientras la UI de Sprout se mantiene fuera de la ruta.

Wisp v1.1.1: integración de wallet Spark y guardia de pegado de nsec

Wisp v1.1.1, publicado el 5 de junio, aterriza una pantalla de conexión de wallet de dos niveles con sub-pantalla Spark en PR #548 y paridad del dashboard con la UI de wallet de iOS en PR #549. El lanzamiento incluye una guardia de pegado de nsec de todo el sistema que detecta un pegado con prefijo nsec1 en cualquier lugar de la app y bloquea al campo de aceptarlo, cerrando uno de los footguns más citados en la UX de Nostr. Inicio de sesión por escaneo QR más un modo solo lectura para npub y nprofile se distribuye en PR #552, permitiendo a un usuario navegar un perfil solo lectura. Los mensajes de zap ahora se renderizan como mini-posts en el drawer de engagement (PR #559) para que las notas de zap lleven su texto junto con la cantidad de sats. Un filtro de web of trust en las respuestas de hilo aterriza en PR #583, permitiendo a los usuarios ocultar spam de respuesta de cuentas fuera de su grafo de follow.

Nostria v3.1.46 y nospeak 1.1.3: retrabajo de notificaciones y reinicio de ICE

Nostria v3.1.46 el 7 de junio termina una serie de tres lanzamientos que retrabajó el contador de notificaciones para contar solo las nuevas notificaciones desde la última vista, eliminando una inflación de larga data donde cargar notificaciones más antiguas desplazándose aumentaba el conteo de la insignia. Nostria v3.1.45 corrigió un bug de pago dividido que afectaba a pagos lightning y de código QR y descartó una UI translúcida previamente planeada como inviable en el compositor de Android.

nospeak v1.1.3 el 4 de junio añade reinicio de ICE en estado FAILED para llamadas de voz 1 a 1. El comportamiento estándar de WebRTC descarta una llamada cuando los candidatos ICE se agotan sin una ruta alternativa; la ruta de reinicio de ICE renegocia candidatos para que la llamada se recupere de cambios transitorios de NAT o red. Las llamadas Android ahora mantienen la pantalla encendida durante las videollamadas.

Cambios sin publicar

Amethyst: 41 PRs continuando la pista NIP-32 / NIP-F4 / Tor

Amethyst fusionó 41 PRs esta semana sin cortar una etiqueta de lanzamiento, encima de los 52 PRs de la semana pasada y el trabajo de etiquetado de hashtags NIP-32 y podcast NIP-F4 cubierto en Newsletter #25. La rama activa sigue acumulando características para el próximo lanzamiento etiquetado, superponiendo pulido a las adiciones destacadas de la semana pasada: descubrimiento de etiquetadores de hashtags, pantalla de podcast, pistas de música y playlists, watchdog de auto-curación de Tor, firmadores efímeros para subidas anónimas y zaps en cadena con filtrado NIP-05. La producción de PRs de Amethyst sigue siendo la más alta de cualquier cliente Nostr, y la cola sin publicar es la hoja de ruta de facto para lo que otros clientes Nostr para Android necesitarán igualar.

Damus: rastreo de relays desde mensajes OK y changelog de v1.17

Damus PR #3786, fusionado el 3 de junio, añade los mensajes OK exitosos de un relay a la lista de post-relay. Las compilaciones anteriores de Damus poblaban la lista de relays vistos solo al recibir un mensaje genérico del relay, lo que significaba que un relay que reconocía el post pero no entregaba eventos de vuelta era invisible para el usuario. El cambio importa para los usuarios que quieren confirmar que su post aterrizó en su relay outbox preferido. PR #3796 corrige un ciclo AttributeGraph en Profile View, y PR #3725 aterriza el changelog de v1.17 antes del próximo lanzamiento etiquetado.

Shopstr: doble publicación NIP-34

El repo de shopstr en ngit fue anunciado en Nostr esta semana como un repo git NIP-34, uniéndose a los repos rastreados de ngit. El repo GitHub del cliente de tienda sigue siendo la superficie principal de desarrollo; el anuncio NIP-34 hace disponible una ruta paralela de colaboración git-sobre-Nostr. Este es el segundo proyecto importante de marketplace Nostr en doble-publicar a NIP-34 tras Mostro, y continúa la migración gradual de metadatos de proyectos al transporte git de Nostr.

Hermes-Marmot: pasarela de agente IA sobre MLS

hermes-marmot, un plugin para el Hermes Agent, conecta la superficie de mensajería de un agente IA con grupos Marmot (MLS-sobre-Nostr) usando mdk-python, los bindings Python al Marmot Development Kit de Rust. El plugin permite a un usuario enviar DM a un agente IA desde cualquier cliente Nostr que hable mensajes MLS kind 445, incluido Whitenoise. Los DMs entrantes usan desenvoltura de gift-wrap NIP-59 mediante los bindings Python de nostr-sdk, y las bienvenidas entrantes fluyen a través de UnwrappedGift.from_gift_wrap a mdk.process_welcome y mdk.accept_welcome. El control de acceso se ejecuta mediante MARMOT_ALLOWED_USERS (una lista blanca de npubs separada por comas) o MARMOT_ALLOW_ALL_USERS=true para acceso de desarrollo abierto.

El repo es nuevo (última actualización el 27 de mayo) y pequeño. Su significado es arquitectónico: es el primer puente público entre un runtime de agente LLM y un canal de mensajería Nostr cifrado con MLS, y el primer uso en producción de mdk-python más allá de Whitenoise mismo. El patrón apunta hacia la comunicación agente-a-agente donde ambos endpoints poseen claves MLS y el relay solo ve texto cifrado.

Actualizaciones de NIP y trabajo de especificación de protocolo

NIP-67 pista de completitud EOSE (PR #2317) fusionado

PR #2317 de mattn se fusionó el 6 de junio, añadiendo NIP-67 al protocolo. El NIP extiende el mensaje de relay EOSE con un tercer elemento opcional: ["EOSE", <subscription_id>, "finish"] señala que cada evento almacenado que coincide con el filtro se ha entregado, mientras que un ["EOSE", <subscription_id>] desnudo no lleva ninguna reclamación de completitud. Un relay que omite la pista está diciéndole al cliente que puede haber más; un relay que omite el anuncio NIP-67 en NIP-11 mantiene el comportamiento actual bajo la heurística legada existente. El cambio es compatible hacia atrás en ambas direcciones: los clientes legados ignoran el elemento final del array, y los relays legados lo omiten.

La motivación en la especificación fusionada es doble. Primero, pérdida silenciosa de datos: un cliente pide las últimas 500 notas contra un relay con un límite interno de 300 eventos, el relay devuelve 300 eventos y el cliente (usando la heurística estándar received < limit) concluye que el resultado está completo. Las notas coincidentes 201.ª hasta la N.ª más antigua permanecen en el relay sin leer, con el cliente ciego a ese hecho. Segundo, viajes de ida y vuelta obligatorios desperdiciados: cuando un relay limita las respuestas a 300 eventos, cualquier suscripción que agota el límite requiere un segundo REQ con until=<oldest_created_at> puramente para confirmar la completitud, incluso cuando el filtro coincide exactamente con 300 eventos. Ambos modos de fallo son pagados por cada cliente en cada suscripción con límite agotado. La pista "finish" es una cadena opcional en un mensaje existente y elimina ambos costes.

Extensión de autocompletado NIP-50 (PR #2357) fusionado

PR #2357 de Alex Gleason se fusionó el 6 de junio, añadiendo un token autocomplete:true/false a la búsqueda NIP-50. La extensión permite a un cliente marcar una consulta como una búsqueda typeahead para que el relay use coincidencia de prefijo, con búsqueda de texto completo como predeterminado para consultas sin el token. El relay de Ditto lo implementa para follow packs, listas y cualquier evento con un tag title, devolviendo coincidencias contra el prefijo del título; la ruta de búsqueda por defecto ejecuta puntuación de texto completo. Sin este token, las UIs estilo autocompletado no tenían forma de comunicar la intención de búsqueda por prefijo y los relays tenían que adivinar por la forma de la consulta. El token es una pista por búsqueda, no una capacidad a nivel de relay, por lo que un relay puede implementarlo para una clase de evento (títulos) sin reclamar soporte general de autocompletado.

Alertas de emergencia y difusiones de ubicación NIP-GART (PR #2374)

PR #2374 de disinqa, abierto el 9 de junio, define un formato de cable que preserva la privacidad en Nostr para alertas de emergencia y difusiones de ubicación dirigidas a un grupo de destinatarios de confianza. El objetivo de diseño declarado es ocultar la identidad del remitente, la membresía del grupo y el payload a los operadores de relay mientras se mantiene los eventos seguros contra replay y verificables por firma de extremo a extremo. El número de NIP está aún por determinar, la propuesta es borrador temprano. El caso de uso es el patrón estándar de alerta de emergencia: un usuario bajo amenaza difunde un ping de ubicación que solo un grupo pre-compartido de contactos de confianza puede descifrar, con el relay ciego al remitente, al conjunto de destinatarios y al payload. Los detalles del formato de cable viven en el PR y probablemente evolucionarán a medida que los mantenedores revisen.

Método logout NIP-46 (PR #2373)

PR #2373 de hzrd149, abierto el 8 de junio, añade un método logout a NIP-46 para que un cliente pueda decirle a un bunker explícitamente que la sesión ha terminado. Hasta ahora, la única forma de terminar una sesión de bunker era esperar el timeout de la sesión o dejar de usar la conexión, ambas dejan al bunker manteniendo el estado de la sesión para un cliente que se ha ido. La propuesta es corta (un nuevo método) y es el tipo de cambio de mantenimiento que hace las integraciones de bunker de larga vida más limpias.

Propuesta híbrida relay-P2P NIP-95 circulada como formato largo

Una especificación NIP-95 de formato largo circuló como un post kind:30023 de npub 91bea5cd9361504c409aaf459516988f68a2fcd482762fd969a7cdc71df4451c el 4 de junio bajo el título Protocolo Híbrido Relay-P2P via WebRTC. El documento en portugués define un protocolo híbrido de relay peer-to-peer donde los clientes Nostr se conectan entre sí directamente mediante WebRTC para mensajería en vivo mientras continúan usando relays para la recuperación de eventos almacenados y la entrega offline. El autor enmarcó explícitamente la especificación como “LLM-ready”, proporcionando definiciones de mensajes, flujos lógicos, esquemas de datos y reglas de estado a un nivel de detalle que permite a un modelo de IA generar código cliente o servidor funcional. La propuesta aún no ha aterrizado como un PR de NIP; la circulación mediante kind:30023 es el precursor habitual a un pull request formal a nostr-protocol/nips.

NIP-44 v3 recoge un segundo firmador: Clave porta la especificación

El despliegue de NIP-44 v3 de v6.2.0 de Amber de la semana pasada se distribuyó por delante de cualquier PR de NIPs fusionado, dejando v3 como una extensión específica de Amber que otros clientes tenían que reflejar para interoperar. Ese enmarque de implementación única cambió esta semana. Clave, el firmador remoto NIP-46 iOS basado en push, aterrizó un port independiente de NIP-44 v3 el 3 y 4 de junio a través de ocho commits. Las primitivas criptográficas se distribuyen en tres commits: capa de claves HKDF + ECDH, el algoritmo de padding v3 y una API pública de alto nivel más Context de cifrado. Encima de esos, la superficie NIP-46 sigue en cableado de despacho RPC dentro de LightSigner y un esquema PendingRequest que lleva el contexto v3 (kind más scope), para que el firmador pueda registrar para qué kind de evento y caso de uso se aprobó el payload v3.

Clave diverge de Amber en la superficie de cara al usuario. Un esquema de concesión de permisos con niveles de sensibilidad permite a los usuarios conceder cifrado v3 para un kind de evento y scope particular a un nivel de sensibilidad elegido. En el primer encuentro, prompts de aprobación conscientes del contexto v3 con una tarjeta explicativa única introducen v3 a los usuarios. El trabajo está en main y está conectado al proyecto Xcode pero no está publicado; la compilación etiquetada más reciente es v0.2.0-build79 del 12 de mayo.

Dos implementaciones independientes aterrizan NIP-44 v3 en rutas de producción antes de que el PR de NIPs se fusione, lo que fortalece el caso para el formato de cable subyacente que el PR del protocolo formalizará. Las pruebas de interoperabilidad entre implementaciones ahora se convierten en la ruta a la convergencia de la especificación, con la superficie de aprobación Android de Amber y el modelo de niveles de sensibilidad iOS de Clave como los dos puntos de referencia. Otros firmadores remotos cableando v3 (noauth de nsec.app ha estado inactivo desde mayo de 2025, y otros bunkers no han anunciado trabajo v3) endurecerían el consenso aún más.

Actividad NIP-34: Iris adopta la pila con un nuevo transporte hashtree

Iris publicó anuncios de repo NIP-34 para hashtree el 8 de junio y iris-apps, iris-drive y iris-chat-rs el 9 de junio, anunciando URLs de clonado bajo un nuevo esquema htree:// servido desde wss://temp.iris.to. El transporte hashtree es una alternativa direccionable por contenido a los clonados enrutados por GRASP, y estos cuatro anuncios son sus primeros usos públicos. Los repos llevan descripciones vacías y los detalles arquitectónicos aún están emergiendo, pero la elección de publicar mediante anuncio NIP-34 (sobre un manifiesto Iris-interno personalizado) señala que Iris se compromete con la pila git-sobre-Nostr NIP-34 más amplia.

NIP deep dive: NIP-67 (Pista de completitud EOSE)

NIP-67 cierra una de las brechas de corrección más antiguas en NIP-01. La especificación original define EOSE como el límite entre eventos almacenados y eventos de suscripción en vivo para un REQ, pero nunca especificó si el relay había terminado de entregar todas las coincidencias almacenadas o se había detenido a mitad de camino por un límite interno. Cada relay aplica un límite por suscripción (comúnmente 300 a 1000 eventos) independiente del limit del cliente, y los clientes no han tenido forma de observar ese límite.

El workaround estándar era comparar el conteo recibido contra el limit solicitado. Si received < limit, tratar el resultado como completo; de lo contrario, paginar con until=<oldest_created_at>. Ambas ramas están rotas. La rama received < limit trunca silenciosamente: un cliente pidiendo 500 notas contra un relay limitado a 300 ve 300 eventos, concluye que el resultado está completo porque 300 < 500 y nunca obtiene el resto. Los eventos retenidos en el relay no pueden señalizar “más disponible” a través de ningún mensaje existente. La paginación como segunda rama es derrochadora: un filtro que coincide exactamente con el límite requiere un segundo REQ para confirmar la completitud, devolviendo cero eventos mientras consume un escaneo de filtro completo en el relay.

La corrección de NIP-67 es una cadena opcional en el mensaje EOSE:

["EOSE", "<sub_id>", "finish"] // explícito: todos los eventos almacenados entregados
["EOSE", "<sub_id>"] // ninguna reclamación de completitud

Un relay que anuncia NIP-67 en supported_nips de NIP-11 y emite un EOSE desnudo está diciéndole al cliente que hay más. Un relay que omite el anuncio mantiene el comportamiento actual, y el cliente recae en la heurística existente. Los clientes legados ignoran el elemento final del array. La compatibilidad hacia atrás se mantiene en ambas direcciones, sin nuevos verbos ni kinds de evento.

Lo que hace a NIP-67 digno de examinar es el alcance que deliberadamente restringe. La especificación no define ningún cursor o token de paginación, por lo que la paginación basada en until sigue siendo el mecanismo. Los límites de relay permanecen donde están, y el NIP no requiere exposición de ellos. NIP-67 preserva el significado de EOSE como el límite almacenado-a-en-vivo y solo añade una señal sí-o-no en el límite: “tengo más para ti” versus “eso es todo”. Esta superficie mínima es por qué el PR se fusionó tras un período de revisión relativamente corto para una extensión NIP-01, y por qué mattn nota explícitamente en el PR que se usó traducción por IA para el texto en inglés. El cambio es lo suficientemente pequeño como para que la incertidumbre de traducción no importe.

Ejemplo de intercambio consciente de NIP-67 entre un cliente y un relay que aplica límites. Anuncio NIP-11 del relay:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 11,
 "tags": [],
 "content": "{\"supported_nips\":[1,11,50,67]}",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

El intercambio a nivel de cable que sigue:

→ ["REQ", "abc", {"kinds":[1],"limit":500}]
← [...300 EVENT messages...]
← ["EOSE", "abc"] // sin "finish": límite alcanzado, más disponible
→ ["REQ", "def", {"kinds":[1],"limit":300,"until":1780900000}]
← [...178 EVENT messages...]
← ["EOSE", "def", "finish"] // completo explícito

La respuesta de 178 eventos previamente habría disparado un tercer REQ para confirmar la completitud. Con NIP-67 el cliente se detiene ahí.

NIP-67 también es notable como una enmienda a NIP-01 aterrizando con un consenso raro. La mayoría de los cambios a NIP-01 atraen largos hilos de debate porque la pequeña superficie del protocolo es portante para cada implementación. NIP-67 se fusionó tras un período de revisión extendido (aproximadamente siete semanas de apertura a fusión), sugiriendo que cuando un cambio a NIP-01 es lo suficientemente pequeño y el modo de fallo es lo suficientemente concreto (pérdida silenciosa de datos, viaje de ida y vuelta obligatorio desperdiciado), los mantenedores del protocolo están dispuestos a extender el vocabulario central de mensajes.

NIP deep dive: NIP-50 (Búsqueda)

NIP-50 define el campo de filtro search en los mensajes REQ, permitiendo a los clientes pedir a un relay que filtre eventos por coincidencia de texto completo contra una cadena de consulta. La especificación base fusionada es deliberadamente mínima: el campo search es una cadena, cada relay decide su propia semántica de búsqueda (qué campos están indexados, cómo funciona la puntuación, si se aplica stemming) y los relays anuncian soporte NIP-50 en su documento NIP-11. Los clientes controlan el algoritmo de búsqueda solo a través de la propia cadena de consulta.

Este minimalismo es a la vez la fortaleza y la limitación de NIP-50. La fortaleza es que cualquier relay puede implementar búsqueda a cualquier nivel de calidad: un escaneo básico de subcadenas satisface la especificación, y un relay ejecutando Elasticsearch o Meilisearch la satisface igualmente. La limitación es que los clientes carecen de una forma de expresar la intención de búsqueda. Una UI typeahead de menciones de perfil quiere coincidencia de prefijo contra nombres de visualización; una búsqueda de texto completo de contenido quiere puntuación tokenizada de texto completo a través del cuerpo de la nota. El mismo campo search lleva ambos, y el relay debe adivinar por la forma de la consulta.

PR #2357 añade el primer token de extensión NIP-50: autocomplete:true o autocomplete:false incrustado en la consulta de búsqueda señaliza qué modo quiere el cliente. El relay de Ditto implementa el token para follow packs, listas y cualquier evento con un tag title, cambiando a coincidencia de prefijo cuando autocomplete:true está presente. El token vive inline en la consulta (los campos de filtro separados quedan intactos), por lo que viaja con la cadena de búsqueda y no requiere ninguna actualización del protocolo de cable:

search: "fiat autocomplete:true"

Las pistas con forma de token como esta son cómo NIP-50 siempre ha manejado los dialectos específicos de relay. Los relays ya soportaban tokens como language:en y domain:example.com. Cada uno sigue siendo específico del relay, con cada relay documentando su propio dialecto. El PR #2357 de NIP-50 eleva autocomplete de un token privado de relay a uno bendecido por la especificación, allanando el camino para búsqueda consciente de typeahead entre relays.

Ejemplo REQ NIP-50 con el token autocomplete, apuntando a un relay que indexa títulos de perfil kind 0:

{
 "id": "b7c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 1,
 "tags": [
 ["client", "example-mention-picker"]
 ],
 "content": "Sent search: kinds=[0], search=\"fiat autocomplete:true\", limit=10",
 "sig": "12d3e4f5061728394a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5e6f7081a2b3c4d5e6f708192"
}

El REQ real a nivel de cable:

["REQ", "mention-picker", {"kinds":[0],"search":"fiat autocomplete:true","limit":10}]

Un relay que no reconoce el token trata autocomplete:true como parte de la cadena literal de búsqueda y recae en coincidencia de texto completo, devolviendo resultados correctos (aunque clasificados diferente). La degradación elegante hace que el token sea seguro para incluir incondicionalmente para clientes que prefieren coincidencia de prefijo cuando está disponible.

La siguiente extensión NIP-50 probable es control de ranking por kind: una pista que dice “ordenar por created_at descendente” versus la puntuación de relevancia por defecto. Varios relays ya aceptan sort:newest como un token privado de relay, y se aplica la misma ruta de elevación que trajo autocomplete a la especificación. La búsqueda sigue siendo una de las pocas primitivas Nostr donde los relays compiten en la calidad del resultado; la fiabilidad de entrega es la misma en todos los relays conformes. Los tokens incrementales permiten a los clientes explotar esa competencia de calidad sin forzar a los relays a distribuir una nueva especificación pesada.

Nostr Compass #25

Wed, 03 Jun 2026 00:00:00 +0000

Amber 6.2.0 estrena el cifrado NIP-44 v3 por delante de la especificación. Mostro aterriza la base para el escrow liquidado con Cashu a través de ocho PRs, envolviendo el Cashu Development Kit existente como un segundo backend de liquidación junto a Lightning. Los podcasts NIP-F4 se fusionan tras 27 meses de debate. fiatjaf abre una propuesta controvertida de desacoplamiento de claves NIP-17 que reabre el argumento arquitectónico bunker-contra-Marmot. Amethyst aterriza etiquetado de hashtags NIP-32, una pantalla de podcast dedicada y zaps en cadena a través de 52 PRs no publicados.

Historias principales

Amber 6.2.0: cifrado NIP-44 v3 publicado

Amber v6.2.0, publicado el 1 de junio, añade soporte de cifrado NIP-44 v3 con una pantalla dedicada de aprobación, vista previa de intent, vista previa de bunker, registro de historial y rechazo automático para solicitudes inválidas. El lanzamiento también registra autoridades ContentProvider NIP-44 v3 para que otras apps Android puedan solicitar cifrado v3 junto con la ruta v2 existente. NIP-44 en sí es la especificación de payload cifrado versionada usada por los DMs privados NIP-17, el tráfico de bunker NIP-46 y otras primitivas Nostr; v3 en Amber es un opt-in junto a v2, señalizado por un método de firmador separado para que los clientes del lado receptor puedan negociar el algoritmo explícitamente. El PR correspondiente en el repo NIPs aún no ha aterrizado, por lo que Amber está desplegando v3 por delante del consenso del protocolo, con el formato de cable y la autoridad ContentProvider registrados para la integración de clientes downstream.

Las sesiones NIP-46 ahora auto-aceptan solicitudes ping en la conexión, eliminando el prompt en el primer viaje de ida y vuelta tras el emparejamiento. El método de firmador sign_message fue eliminado por completo tras haber sido obsoleto y sin uso.

Como Amber es el firmador Android dominante, cada cliente downstream que quiera v3 tiene que apuntar al formato de cable de Amber hasta que aterrice el PR de NIPs. Eso le da a Amber voz implícita sobre la especificación final de v3 hasta que el protocolo se ponga al día. El intercambio es real: v3 en producción permite a Amber recopilar retroalimentación de implementación para el eventual NIP, a costa de un punto de referencia temporal de implementación única que otros clientes ahora tienen que igualar.

Mostro: integración de escrow Cashu mediante CDK

grunch aterrizó ocho PRs en MostroP2P esta semana integrando las primitivas multisig P2PK existentes de Cashu (NUT-10 y NUT-11) como un segundo backend de liquidación junto a Lightning en el intercambio de Bitcoin P2P coordinado por Nostr. Las primitivas criptográficas son de Cashu; el trabajo es andamiaje de integración y un nuevo trait de backend de escrow. Mostro core v0.12.0, publicado el 30 de mayo, añade los tipos de protocolo para escrow multisig 2-de-3, firmas P_M por prueba y permite eventos de escrow a través de la validación de respuesta. La arquitectura está documentada en PR #756 y usa claves de intercambio por orden clarificadas en PR #757.

La implementación se desplegó a través de seis PRs de seguimiento en un solo día. F2 (PR #758) añadió la configuración, el modo escrow y el arranque condicional. La siguiente rebanada, F3 (PR #760), definió un trait EscrowBackend con una implementación Lightning y un stub Cashu, permitiendo a Mostro cambiar de backend de liquidación sin cambiar la máquina de estado de la orden. F4 (PR #759) envolvió CDK (el Cashu Development Kit) para operaciones de mint y wallet. El trabajo de base de datos en F5 (PR #761) añadió bloqueos de escrow compare-and-swap y consultas active-locked. F6 (PR #762) construyó una mint contenerizada en un trabajo de CI dedicado para pruebas end-to-end de escrow. El flujo de Mostro ya usa DMs envueltos en gift wrap NIP-59 para la coordinación de órdenes sobre el relay, por lo que el escrow Cashu encaja como una segunda opción de liquidación junto a Lightning sin tocar el protocolo de cable.

Lanzamientos

ngit v2.5.0: fallback GRASP y fetches de git perezosos

ngit v2.5.0 cambia el comportamiento por defecto de git push pr/<branch> y ngit send para producir un kind PR para nuevas propuestas cuando el repositorio tiene al menos un servidor GRASP registrado. Anteriormente esto solo se activaba para commits sobredimensionados de más de 60 KB o commits que contenían submódulos. Cuando un PR no puede empujarse a los servidores GRASP del repositorio, ngit ahora recae en el enrutado GRASP-06 a través de los servidores declarados. La bandera ngit send --git-server o git push -o git-server=<url> permite a los contribuyentes apuntar a una URL git personalizada o servidor GRASP explícitamente.

Los republicados de ngit init ahora preservan los tags desconocidos de los anuncios existentes, para que los tags añadidos por una versión futura de ngit o una herramienta de terceros sobrevivan al republicado. Una advertencia amarilla lista los tags arrastrados, y --clean los elimina bajo demanda. ngit pr apply, ngit pr checkout y ngit pr list consultan los servidores git perezosamente y comparten un único helper de fetch, por lo que checkout ya no obtiene incondicionalmente cuando el commit ya está local. ngit pr checkout también intenta URLs de clonado proporcionadas por el remitente desde el evento PR como respaldo cuando los servidores git declarados del repo no llevan el tip del PR, coincidiendo con el comportamiento existente en ngit pr apply. ngit es la implementación de referencia de NIP-34 para colaboración git sobre Nostr, y v2.5.0 hace de GRASP la ruta de primera clase para los nuevos contribuyentes.

Jumble v26.5.7: eliminación de EXIF y conteos de zap validados

Jumble v26.5.7 añade dos cambios que afectan directamente a la privacidad del usuario y a la integridad de los datos. La ubicación EXIF y los identificadores de cámara ahora se eliminan de las subidas de imágenes antes de que salgan del cliente, cerrando una superficie de fuga de metadatos de larga data que afectaba a cada imagen publicada desde Jumble. Los conteos de zap ahora se computan solo desde recibos criptográficamente validados, corrigiendo conteos inflados de eventos zap malformados que habían permitido a los atacantes exagerar los totales de zap en las notas. El lanzamiento también añade verificación de identidad del remitente para DMs NIP-17, cerrando una superficie de suplantación donde un remitente podía falsificar su pubkey en el sello.

nostr-calendar v1.6.0: manejo de RSVP y participantes duplicados

nostr-calendar v1.6.0 aterriza el flujo RSVP de Formstr (PR #169) y evita participantes duplicados en las invitaciones a eventos (PR #168). La opción waitForAll en la función publish ahora por defecto es false para que la UI no se bloquee en relays lentos (PR #170). PR #157 estrenó los dos borradores de propuesta NIP de Formstr para programación de citas y reservas.

Sprout 0.3.6: Sprout × mesh-llm y secciones de canal

Sprout v0.3.6 es el titular de una serie de seis lanzamientos de v0.3.1 a v0.3.6 esta semana. La integración in-process de Sprout × mesh-llm aterriza en PR #798, permitiendo a Sprout servir y consumir nodos mesh-llm mediante admisión de relay. Las secciones de canal definidas por el usuario se sincronizan entre dispositivos mediante Nostr en PR #792, y las secciones de canal llegan a móvil con sincronización de relay en PR #800. Las notificaciones conscientes de hilo con controles de follow y silencio mutables llegan en PR #761.

Los adjuntos de tipo de archivo arbitrario con tarjetas de descarga llegaron en PR #810, expandiendo Sprout más allá de los adjuntos solo de imagen. Móvil ganó una pestaña de feed social Pulse (PR #772) y pulido de Pulse a través de las superficies de feed, composición y filtro (PR #796).

NostrBotKit v0.5.0: chat de grupo Marmot en un framework de bots Rust

NostrBotKit v0.5.0, publicado el 24 de mayo en Codeberg, añade soporte de Marmot (MLS-sobre-Nostr, NIP-104) al framework de bots Rust auto-alojado. Cuando se configura marmot: true, el bot publica sus key packages MLS (kind 443, 30443, 10051), acepta invitaciones a grupos automáticamente y escucha mensajes en los grupos a los que se ha unido. Dos nuevos tipos de comando, dm_marmot y dm_marmot_npub, permiten a los bots enviar mensajes a grupos Marmot nombrados o chats Marmot 1:1 mediante trabajos cron o webhooks. Para evitar bucles de retroalimentación con otros bots, los bots de NostrBotKit solo responden a mensajes explícitamente dirigidos a ellos mediante /command o @botname/command. Los adjuntos cifrados usando MIP-04 se descifran automáticamente y se resuben mediante Blossom o NIP-96, y la base de datos de estado MLS se cifra con una clave derivada de la clave privada del bot. NostrBotKit es el primer framework Rust en publicar soporte de bots NIP-104, abriendo el despliegue de bots cifrados con Marmot a un perfil de operador diferente al de la ruta TypeScript existente.

noscrypt v0.1.14: lanzamiento firmado de biblioteca de criptografía

noscrypt v0.1.14 es un lanzamiento de seguridad de la biblioteca de criptografía en C usada por varios clientes Nostr para primitivas secp256k1, NIP-04 y NIP-44. El lanzamiento se distribuye con descargas firmadas con PGP verificables contra la clave pública del mantenedor. Los clientes downstream que empaqueten noscrypt deben validar la firma antes de integrar.

Chama v1.3.0: nuevo escrow P2P nativo de Nostr con Fedimint

Chama v1.3.0, publicado el 1 de junio, es el titular de una serie de cuatro lanzamientos para un nuevo cliente de escrow P2P nativo de Nostr que usa ecash Fedimint y compartición de secretos Shamir 2-de-3 para la liquidación. El proyecto se distribuye en getchama.app y funciona sin servidor. v1.3.0 introduce “heal that sticks” (re-difusión exitosa y curación de intercambios que sobreviven a los reinicios de sesión) y emparejamiento de pay-rail, donde las Chamas orientadas a EEUU muestran primero los rails de pago de EEUU. El trabajo base multi-unidad para storefronts aterrizó a través de v1.2.11 (esquema multi-unidad) y v1.2.12 (contador de stock de storefront + endurecimiento de recuperación del puente nativo Fedimint). Chama se une a Mostro y Shopstr en la categoría de marketplaces Nostr, distinguida por su arquitectura sin servidor y su liquidación de escrow basada en Fedimint.

Cambios sin publicar

Amethyst: etiquetado de hashtags NIP-32, pantalla de podcast, pistas de música

Amethyst fusionó 52 PRs y 411 commits esta semana sin cortar una etiqueta de lanzamiento. La adición funcional más grande es PR #3111, que implementa etiquetado de hashtags NIP-32 y un feed de hashtags basado en etiquetas usando eventos kind 1985 con tags de namespace L y etiqueta l. Esto reemplaza el frágil mecanismo de coincidencia de texto #tag con un modelo de descubrimiento basado en etiquetadores donde los usuarios pueden seguir a npubs de etiquetadores específicos de la misma forma que siguen a creadores de contenido. PR #3105 añade una pantalla dedicada de podcast con lista de episodios y reproductor en línea, aterrizando a los pocos días de la fusión de la especificación de podcast NIP-F4. PR #3071 añade un feed Software Apps con filtrado por lista de follow, y PR #3067 añade soporte para pistas de música y playlists mediante conjuntos NIP-51.

Los firmadores efímeros para subidas de posts anónimos aterrizan en PR #3123, permitiendo a los usuarios publicar de forma anónima sin exponer su clave de identidad a los servicios de subida. Un watchdog de auto-curación de Tor con pruebas de integración contra Arti v2.3.0 llega en PR #3053, fortaleciendo el enrutado Tor de Amethyst durante caídas de red transitorias. Los zaps en cadena y un filtro NIP-05 para usuarios que regresan desde Gemini aterrizan en PR #3052, ampliando la superficie de zap más allá de Lightning a pagos de Bitcoin en cadena.

Shopstr: validación de URLs de vista previa OpenGraph

PR #504 valida las URLs de vista previa OpenGraph antes de renderizarlas en los listados del marketplace, cerrando una potencial superficie XSS donde vendedores maliciosos podían incrustar contenido con scripts mediante metadatos OG diseñados. Las tiendas alojadas en Shopstr muestran vistas previas OG para enlaces externos, y las URLs no validadas permiten a un atacante inyectar contenido arbitrario en la UI de la tienda.

Actualizaciones de NIP y trabajo de especificación de protocolo

NIP-F4 (Podcasts) se fusiona tras dos años

PR #1093 se fusionó el 28 de mayo, dos años y tres meses después de que fiatjaf abriera el borrador original. NIP-F4 define los episodios de podcast como eventos kind 54 con tags imeta para metadatos del archivo de audio (URL, tipo mime, código de idioma ISO, URLs de respaldo, bandera de servicio NIP-96, bitrate, duración), un tag title, tags opcionales image y description, y tags t para etiquetas de tema. La especificación mantiene deliberadamente RSS como la fuente de verdad: los episodios pueden llevar un tag i que referencie el GUID del podcast RSS, permitiendo a los clientes Nostr enlazar a feeds de podcast existentes sin duplicar el alojamiento de audio. El largo debate en el hilo del PR (con el co-autor de podcast-namespace Dave Jones, Alex Gleason y Mike Terenzio) se resolvió en un modelo de coexistencia donde Nostr proporciona la capa social sobre RSS mientras RSS mantiene la capa de distribución. La pantalla de podcast del PR #3105 de Amethyst aterriza a los pocos días de la fusión de la especificación, y el trabajo del selector de GIF de Jumble también incluye andamiaje temprano para adjuntos de podcast.

Desacoplamiento de claves NIP-17 (PR #2361)

fiatjaf abrió PR #2361 el 1 de junio, proponiendo que NIP-17 separe la clave de identidad de la clave de cifrado. Los destinatarios anuncian su clave de cifrado en un nuevo evento kind 10044, y los remitentes usan esa clave anunciada (cuando está presente) para el sello interno del gift-wrap, recayendo en la clave de identidad del destinatario solo cuando el anuncio está ausente. El PR también añade un tag n al sello llevando la pubkey de cifrado del remitente, para que los receptores puedan derivar la clave de conversación correcta sin descifrado por prueba y error contra cada clave retirada. La motivación declarada es la UX de bunker: bajo el diseño actual, un usuario de bunker debe hacer un viaje de ida y vuelta a cada DM recibido a través del firmador para descifrar, ya que la clave de cifrado es la clave de identidad guardada por el firmador. Desacoplar permite al cliente mantener la clave de cifrado localmente mientras mantiene la clave de identidad en el bunker para firmas.

La propuesta atrajo la revisión más polémica de la semana. Cody Tseng (Jumble) la apoya como la ruta más fácil para la interoperabilidad de DMs entre clientes. Vitor Pamplona (Amethyst) objeta por dos motivos: añade un nuevo secreto de descifrado de larga duración fuera del bunker, y los clientes que no lo distribuyan fallarán silenciosamente al descifrar mensajes de clientes que sí lo hacen, sin ruta de degradación porque la ruptura está en la capa del sello. Pamplona argumenta que el problema ya está resuelto correctamente por los key packages de Marmot y la rotación de épocas, y que retrofit de separación de claves en la especificación base NIP-17 crea el tipo de fallo de interoperabilidad que Marmot tardó dos años en diseñar. La respuesta de fiatjaf tiene tres partes: el desacoplamiento es opcional por destinatario, la corrección del tag n aborda la preocupación del descifrado por prueba y error, y la alternativa es mantener la UX de bunker rota mientras Telegram se come el caso de uso de la mensajería. El hilo permanece abierto sin decisión de fusión y es la discusión NIP más observada del trimestre.

Flujo de pago NIP-Silent Payments (PR #2362)

silentius-satoshi abrió PR #2362 el 1 de junio como complemento del más amplio borrador de NIP Nostr Silent Payments (PR #2355). El NIP de flujo de pago define kind 8352 para notificaciones de recepción de silent payment (entregadas mediante gift wrap NIP-59 para que el enlace del recibo no sea públicamente observable) y kind 10353 para una caché UTXO cifrada que se sincroniza entre dispositivos para la misma wallet Silent Payments. El par juntos permiten a un pagador señalizar un pago a una dirección Silent Payments usando primitivas nativas de Nostr sin exponer el enlace on-chain en la capa de relay abierta.

NIP-PIP Perfect IP Packets (PR #2364)

RandyMcMillan abrió PR #2364 el 1 de junio como borrador. Introduce un transporte de árbol de paquetes con tres nuevos kinds direccionables: 39078 lleva el manifiesto, 39079 lleva slices individuales y 39080 lleva solicitudes de reparación. La especificación define un formato de cable donde los archivos grandes se dividen en slices direccionables, con manifiestos describiendo el árbol de slices y solicitudes de reparación permitiendo a los receptores pedir slices faltantes. Se aplica estado de borrador temprano, y la propuesta aún no ha atraído revisión de mantenedores.

Espacios en vivo de audio/vídeo NIP-29 (PR #2238)

PR #2238 se fusionó el 28 de mayo, extendiendo los grupos basados en relay NIP-29 con soporte de espacios en vivo de audio y vídeo. Los grupos ahora pueden referenciar una sesión activa de espacio en vivo, permitiendo a los eventos de actividad en vivo estilo NIP-53 anclarse en un contexto de grupo NIP-29.

Múltiples pistas de audio en vídeo NIP-71 (PR #2255)

PR #2255 se fusionó el 28 de mayo, añadiendo tags imeta de pista de audio a los eventos de vídeo NIP-71. El nuevo formato lleva URL, hash, tipo mime, tag de idioma (con ISO-639-1 más bandera de versión original), URLs de respaldo, señal de servicio NIP-96, bitrate y duración. Esto habilita streaming solo de audio (video podcasts), cambio de resolución con audio estable, múltiples pistas de idioma y almacenamiento reducido cuando los servidores no incrustan audio directamente en archivos de vídeo. Los clientes deben comprobar la disponibilidad de pistas de audio antes de asumir comportamiento de pista única.

Gift wrap efímero NIP-59 (PR #2245)

PR #2245 se fusionó el 28 de mayo, añadiendo kind 21059 como contraparte efímera del gift wrap kind 1059 existente. La semántica coincide con el envoltorio estándar NIP-59 pero sigue las reglas de eventos efímeros por NIP-01 (los relays los descartan tras la difusión y no los persisten). Esto permite a las apps elegir persistencia según los requisitos: los indicadores de escritura y pings de presencia se benefician de lo efímero, mientras que el historial de DMs necesita persistencia.

Kind específico de aplicación NIP-78 (PR #2292)

PR #2292 se fusionó el 28 de mayo, reclasificando los datos específicos de aplicación NIP-78 como un kind direccionable normal, descartando el rango separado anterior. Esto simplifica la semántica de reemplazabilidad y alinea NIP-78 con el modelo de evento direccionable usado por otros NIPs de estado de aplicación.

Aclaraciones NIP-85 (PR #2304)

PR #2304 se fusionó el 28 de mayo con pequeñas mejoras al lenguaje alrededor de múltiples claves y relays por proveedor de servicio en NIP-85 Trusted Assertions, clarificando la ruta de rotación de clave de operador para los servicios de aserción de relay.

Gestión de conexión de relay NIP-01 de una línea (PR #2307)

PR #2307 se fusionó el 28 de mayo, añadiendo una sola frase a NIP-01 sobre cómo los clientes deben manejar los tiempos de vida de las conexiones de relay. La corrección aborda una brecha de larga duración donde los clientes diferían en si mantener las conexiones WebSocket abiertas tras la obtención, llevando a pérdida silenciosa de mensajes en relays que descartan conexiones inactivas.

Restricción de chat kind 9 NIP-C7 (PR #2310)

PR #2310 se fusionó el 28 de mayo, restringiendo las vistas de chat NIP-C7 solo a mensajes kind 9. Esto separa el chat efímero de las publicaciones de timeline kind 1 en clientes que implementan superficies de chat estilo NIP-C7.

Simplificación NIP-55 (PR #2363)

PR #2363 de greenart7c3, abierto el 1 de junio, simplifica la especificación de aplicación de firmador Android. Vitor Pamplona firmó como “Looks good” y fiatjaf preguntó si está listo para fusionar. El cambio prepara el camino para el registro de autoridad ContentProvider NIP-44 v3 que Amber publicó esta semana.

NIP-44 v3 (implementación de Amber por delante de la especificación)

Amber publicó NIP-44 v3 en v6.2.0 con ocho commits implementando la actualización de cifrado y el registro de autoridad ContentProvider, pero el PR de especificación en el repo NIPs aún no ha aterrizado. NIP-44 en sí define un formato de payload cifrado versionado usado dentro de eventos firmados; el v2 existente (en producción desde 2024) usa ECDH secp256k1, HKDF, padding, ChaCha20, HMAC-SHA256 y base64. El formato de cable v3 añade un nuevo byte de versión (0x03) por delante del nonce, permitiendo a los clientes receptores negociar el algoritmo explícitamente. La implementación de Amber incluye rechazo automático para solicitudes v3 inválidas, una pantalla dedicada de aprobación distinta de las aprobaciones v2 y registro de texto plano por dirección para el historial. Hasta que el PR de NIPs se fusione, v3 se mantiene como una extensión específica de Amber. Trátalo como una señal prospectiva, no como una señalización estable a nivel de protocolo.

NIP deep dive: NIP-32 (Etiquetado)

NIP-32 define una forma estructurada para que cualquier actor Nostr etiquete eventos, pubkeys, relays, URLs o temas usando eventos direccionables kind 1985 con un vocabulario de etiquetas con namespace. La especificación introduce dos nuevos tags: L denota un namespace de etiqueta, y l denota una etiqueta dentro de ese namespace. Los tags target de etiqueta (e, p, a, r o t) especifican qué se está etiquetando. El requisito de namespace evita que múltiples sistemas de etiquetas colisionen: una etiqueta spam en nip28.moderation lleva semántica diferente a una etiqueta spam en relay-report.

La elección de diseño que hace que NIP-32 sea útil más allá de la moderación es que las etiquetas son aserciones, no verdad a nivel de protocolo. Un evento kind 1985 dice solo que una pubkey particular etiquetó a un objetivo particular en un namespace particular. El modelo de confianza se delega al cliente: cada cliente elige a qué etiquetadores honrar, qué namespaces leer y qué comodidad UI dar a cada etiqueta. La misma primitiva lleva advertencias de contenido, asignación de licencia, tags de idioma ISO-639-1 en notas kind 1, tags geográficos ISO-3166-2, clasificación de contenido, sugerencias distribuidas de moderación y puntuaciones de reputación.

El PR #3111 de Amethyst esta semana es el mayor despliegue hasta ahora. Añade etiquetado de hashtags mediante NIP-32 y un feed de hashtags basado en etiquetas, permitiendo a los usuarios navegar por etiquetas asignadas por etiquetadores de confianza. El mecanismo anterior de coincidencia de texto #tag que originalmente impulsó el descubrimiento de hashtags en Nostr permanece como respaldo para notas no etiquetadas. El modelo de hashtag como etiqueta significa que la misma nota puede ser descubrible bajo múltiples etiquetas asignadas por diferentes etiquetadores, y los usuarios pueden silenciar o impulsar etiquetadores específicos sin afectar a las notas subyacentes.

El auto-etiquetado también está soportado. Un autor puede adjuntar tags L y l directamente a sus propias notas kind 1 para declarar idioma, ubicación y tema. Una nota etiquetada ["L", "ISO-639-1"], ["l", "en", "ISO-639-1"] se auto-identifica como inglés y puede ser filtrada por clientes conscientes del idioma sin infraestructura de etiquetado de terceros.

Ejemplo de evento de etiqueta NIP-32 etiquetando una nota kind 1 como inglés y asignándole una etiqueta de moderación:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748908800,
 "kind": 1985,
 "tags": [
 ["L", "ISO-639-1"],
 ["l", "en", "ISO-639-1"],
 ["L", "nip28.moderation"],
 ["l", "approve", "nip28.moderation"],
 ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3", "wss://relay.example.com"]
 ],
 "content": "Labeled as English-language content approved for NIP-28 chat moderation",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

El despliegue de Amethyst combinado con el reciente trabajo de Trusted Relay Assertions sugiere que NIP-32 se está convirtiendo en el sustrato estándar para cualquier patrón de “aserción impulsada por el usuario sobre un objetivo” en Nostr. La siguiente prueba es si los propios etiquetadores desarrollan jerarquías de confianza: si los usuarios seguirán a npubs de etiquetadores específicos de la misma forma que siguen a creadores de contenido.

NIP deep dive: NIP-F4 (Podcasts)

NIP-F4 se fusionó esta semana, dos años y tres meses después de que fiatjaf abriera el borrador original (PR #1093). El prefijo F es simple numeración hexadecimal: NIP-F0 a NIP-FF usan el mismo espacio hex de 1 byte que NIP-0A a NIP-0D, con el rango hex superior sirviendo como desbordamiento ahora que el rango decimal 01-99 se está llenando. NIP-F4 define cómo los podcasts publican episodios y metadatos como eventos Nostr mientras mantienen RSS como una capa complementaria para el propio archivo de audio.

La elección arquitectónica central es que cada podcast es su propio par de claves Nostr. La especificación abre con esto directamente: “each podcast is its own Nostr keypair”. Esto permite a los podcasts combinar su presencia de podcasting con una presencia normal de microblogging kind 0 / kind 1, y permite a un podcast cambiar de propiedad con el tiempo mediante traspaso de claves o firma compartida estilo MuSig2. Cuatro kinds de evento llevan la capa de publicación:

kind:10154: metadatos de podcast reemplazables. Lleva tags title, image, description, website opcionales, y tags p opcionales marcando autores con un role de host, cohost o editor.
kind:10164: contra-reclamación del autor. El ejemplo en la especificación usa kind 10064 (una errata abierta para corrección), pero el encabezado y el texto circundante lo identifican como kind:10164. Los usuarios listan las pubkeys de podcast que autorizan, para que los clientes puedan verificar los tags p en kind:10154 contra una reclamación equivalente del supuesto autor. Sin esto, un podcast podría etiquetar falsamente a cualquiera como host.
kind:54: eventos de episodio autorizados directamente por la pubkey del podcast. Los tags incluyen title, image opcional, description y uno o más tags audio. Cada tag audio es ["audio", "<audio-url>", "<optional_media_type>"]. La especificación anota “otros campos importantes a especificar aquí más tarde tras un mayor descubrimiento”, y la forma fusionada es deliberadamente mínima.
kind:10054: una lista de podcasts favoritos estilo NIP-51, permitiendo a los usuarios marcar qué podcasts siguen.

El debate del hilo alrededor de la fusión involucró al co-autor de Podcasting 2.0 Dave Jones, Alex Gleason, Mike Terenzio, Pablo F7z y staab. Jones argumentó fuertemente contra cualquier intento de reemplazar RSS: “It’s been tried many times and always fails”, citando JSONfeed, XMPP, AMP, la API de Twitter y la migración fallida de Spotify. Terenzio reencuadró la propuesta como una capa social sobre RSS, manteniendo RSS mismo como la capa de distribución. fiatjaf accedió a dar un paso atrás y dejar madurar la propuesta: “I agree with everything you said but I still think we can pull it off, let’s stop here for a while”. Dos años después, la especificación fusionada aterriza más cerca de la coexistencia que del reemplazo.

Tres preguntas de diseño permanecen explícitas en la especificación fusionada:

La errata kind:10164 (el ejemplo muestra 10064) necesita reconciliación antes de que los clientes puedan interoperar de forma segura.
El descubrimiento a nivel de episodio sin enlace GUID RSS queda abierto. La especificación fusionada no tiene tag i, ni formato podcast:item:guid, ni mecanismo de puente RSS. Los clientes que quieran puentear un catálogo RSS existente en eventos kind 54 deben definir la convención de puente ellos mismos.
El stub de “otros campos importantes” en la definición de kind:54 deja bitrate, duración, idioma, punteros de transcripción, capítulos y metadatos por segmento como territorio abierto para propuestas de seguimiento.

El PR #3105 de Amethyst aterriza una pantalla dedicada de podcast con lista de episodios y reproductor en línea a los pocos días de la fusión, la primera implementación importante de cliente. Jumble publicó andamiaje temprano de adjuntos de podcast junto con su selector de GIF. Wavlake sigue siendo la plataforma de podcasts nativa de Nostr más grande y tendrá que decidir si alinear sus eventos de pista de música kind 31337 existentes con el modelo de episodio kind 54 de NIP-F4.

Ejemplo de evento de episodio kind 54 NIP-F4, coincidiendo con el conjunto mínimo de tags de la especificación fusionada:

{
 "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748995200,
 "kind": 54,
 "tags": [
 ["title", "Episode 42: Why RSS Won"],
 ["image", "https://podcast.example.com/ep42-cover.jpg"],
 ["description", "Dave Jones and fiatjaf on protocol coexistence and the social layer."],
 ["audio", "https://podcast.example.com/audio/ep42.mp3", "audio/mpeg"]
 ],
 "content": "In this episode we discuss the two-year journey of NIP-F4 from draft to merge, and why coexistence with RSS turned out to be the right architectural choice.",
 "sig": "abc123def456789012345678901234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567"
}

PR #1093 estuvo abierto durante 27 meses, muy por encima de la duración abierta mediana de los PRs de NIPs fusionados. La siguiente prueba para NIP-F4 es si la errata del kind 10164 se reconcilia, si emergen convenciones de descubrimiento de episodios y de puente RSS por parte de los implementadores, y si los hosts principales de podcast publican bajo pares de claves por podcast como recomienda la especificación.

Nostr Compass #24

Thu, 28 May 2026 00:00:00 +0000

Amethyst v1.11.0 aterriza una implementación completa de calendario NIP-52 con recordatorios, splits de zap de Bitcoin en cadena y soporte para respuestas en grupos Marmot. White Noise v2026.5.22 estrena notificaciones push en iOS mediante una Notification Service Extension, junto con UX de bloqueo y un botón para añadir miembros. Vector v0.4.0 aterriza una reescritura desde cero de vector-core, Tor con un clic con soporte de bridges, firmadores remotos NIP-46, sincronización de grupos MLS con negentropy completo y un servidor MCP de 21 herramientas para agentes de IA. Applesauce v6.1.0 introduce listas de relays de búsqueda NIP-51 (kind 10086) y un conjunto completo de fábricas de git-cast NIP-34. MDK añade mensajes efímeros NIP-40 en iOS y Android mediante una superficie UniFFI unificada, y Mostro v0.17.4 cierra el bucle del bono anti-abuso con pagos de bono recortado de Fase 3 al ganador. Notedeck fusiona la reconciliación completa por negentropy NIP-77 para giftwraps y backfill de hilos, Cordn aparece como un mensajero MLS mediado por coordinador que intercambia una dependencia de disponibilidad de un solo punto por un ordenado más estricto de épocas y un modelo operativo más simple, una implementación de referencia NIP-B0 llamada deepmarks estrena un cliente de marcadores monetizado por curador, y el equipo de Formstr abre cuatro propuestas coordinadas de NIP de calendario que cubren autoremoción de participantes, eventos privados, recurrencia y programación de citas descentralizada.

Historias principales

Amethyst v1.11.0: calendarios, splits de zap en cadena y respuestas Marmot

Amethyst, el cliente Nostr para Android mantenido por Vitor Pamplona, publicó v1.11.0. PR #2994 añade una implementación de evento de calendario NIP-52 con una UI dedicada y un sistema de recordatorios, para que los eventos de calendario ahora se rendericen en su propia categoría de timeline, separada de la vista genérica kind-30023 de formato largo. PR #3018 extiende los zaps de Bitcoin en cadena con soporte para splits, distribuyendo una única transacción de Bitcoin entre múltiples destinatarios según el tag de zap-split existente, para que un pago en cadena se comporte igual que un split Lightning. PR #2974 añade una pantalla paginada de historial de transacciones en cadena que expone cada zap liquidado con el estado de confirmación en bloque.

La mensajería de grupo gana paridad con el chat uno-a-uno: PR #2995 añade soporte de respuesta para mensajes de grupo Marmot/MLS, para que los hilos dentro de grupos cifrados ahora se rendericen con la misma UI de referencia al padre que las notas públicas. PR #2984 endurece la validación de recibos de zap NIP-57 comprobando que el proveedor LNURL coincide con el lud16 declarado del destinatario, cerrando una clase de falsificación donde un LNURL de tercero podía acuñar un recibo por un pago que nunca aterrizó. PR #2968 acepta dimensiones en coma flotante en los tags imeta de NIP-92, alineando Amethyst con clientes que publican valores fraccionarios de densidad de píxel desde dispositivos como la pantalla Retina del iPhone. El lanzamiento también conecta Payment Targets, un nuevo evento reemplazable de tarro de propinas multi-rail cubierto en la sección de protocolo abajo.

White Noise v2026.5.22: push en iOS, UX de bloqueo y añadir miembros

White Noise, el mensajero de grupos del protocolo Marmot, publicó v2026.5.22 con las notificaciones push en iOS como característica principal. PR #673 implementa una Notification Service Extension (NSE) de iOS que descifra mensajes MLS dentro del proceso de la extensión y los expone como notificaciones del sistema, para que los usuarios de iPhone ya no necesiten la app en primer plano para recibir mensajes. La plomería del token push de Android se enruta por el mismo pipeline backend, con la NSE por plataforma manteniendo el texto cifrado fuera del broker.

PR #676 añade una UX completa de bloqueo y desbloqueo con flujos de confirmación y filtrado de listas de contactos. PR #679 añade el largamente solicitado botón “Añadir miembros” a la pantalla de información del grupo, cerrando una brecha de UX donde los administradores de grupo tenían que recurrir a enlaces para compartir. PR #688 introduce una pantalla dedicada de ajustes de notificaciones en iOS, y PR #687 conecta compartir mediante pulsación larga para medios y mensajes.

MDK añade mensajes efímeros NIP-40 en todas las plataformas

El Marmot Development Kit, el núcleo Rust compartido usado por White Noise iOS, White Noise Android y cualquier futuro cliente Marmot, fusionó PR #306 para exponer la validación de mensajes efímeros y el manejo de expiración NIP-40 mediante el puente UniFFI. El PR es el segundo de una serie de tres partes. iOS y Android ahora comparten una implementación Rust de la lógica de expiración; las reglas de tiempo viven en una única ruta de código auditada consumida por ambas plataformas mediante UniFFI. PR #307 limita la longitud almacenada de las razones de fallo de bienvenida y las sanea antes de persistirlas, una pasada de endurecimiento separada que complementa el manejo de eventos de bienvenida publicado la semana pasada.

Los mensajes efímeros en MLS no son solo una comodidad de UI. El tag de expiración se publica con el sobre del mensaje cifrado, para que un destinatario que nunca abre el mensaje todavía tenga el texto cifrado subyacente expirando en la capa de relay junto con cualquier copia en caché en el cliente receptor. Con MDK poseyendo la ruta de validación, el comportamiento se mantiene consistente entre clientes: cualquier implementación conforme de Marmot aplica la misma semántica de expiración, para que un cliente honrando la expiración mientras otro guarda en caché para siempre deje de ser un peligro de portabilidad.

Mostro v0.17.4: la Fase 3 cierra el bucle del bono recortado

Mostro, el protocolo de intercambio de Bitcoin peer-to-peer construido sobre Nostr, publicó la Fase 3 de su despliegue de bono anti-abuso en v0.17.4. PR #738 aterriza el flujo de pago para bonos recortados, tomando la garantía perdida del perdedor y desembolsándola al ganador de la disputa. PR #743 añade la Fase 3.5, un mensaje explícito de confirmación de pago al ganador para que sepa que los sats recortados se han liquidado, con el evento de confirmación llegando en la misma sesión Nostr que la resolución de la disputa. La Fase 2, cubierta la semana pasada, introdujo el recorte como una acción de admin; la Fase 3 es la diferencia entre amenazar con una penalización y aplicarla.

PR #746 permite al demonio finalizar disputas que carecen de una fila de solucionador, un caso límite que anteriormente estancaba la resolución en disputas heredadas. PR #748 tolera tasas nulas en la respuesta /exrates/BTC de Yadio para que una breve caída de Yadio ya no rompa la ruta de conversión fiat de Mostro. PR #745 documenta la especificación para proveedores de precio multi-fuente, la base para eliminar Yadio como punto único de fallo. El cliente móvil de Mostro conectó la ruta de reclamación de la Fase 3 correspondiente en PR #596.

Applesauce v6.1.0: relays de búsqueda y git casts NIP-34

Applesauce, el kit de herramientas Nostr modular que impulsa Coracle, noStrudel y la pila de Pablo F7z, publicó v6.1.0 a través de sus paquetes. El lanzamiento añade soporte de primera clase para listas de relays de búsqueda NIP-51: los eventos kind 10086 permiten a un usuario señalizar “pregunta a estos relays si quieres encontrarme”, situándose junto a las listas outbox NIP-65 como una primitiva de descubrimiento. Las aplicaciones construidas sobre applesauce-core obtienen un observable reactivo User.lookupRelays$ y un cargador correspondiente en applesauce-relay.

Las fábricas de git-cast NIP-34 llegan a applesauce-factory, dando a cada cliente construido con Applesauce una ruta de una línea para publicar anuncios de repo (kind 30617), parches (kind 1617) e issues (kind 1621). Las propiedades reactivas User.favoriteGitRepos$, User.gitAuthors$ y User.graspServers$ permiten a las aplicaciones listar los repos seguidos de un usuario, los mantenedores de repos y los servidores GRASP configurados directamente desde el mismo objeto User. El lanzamiento también corrige los métodos manuales del pool que silenciosamente descartaban relays offline en PR #73.

Notedeck fusiona negentropy NIP-77 para giftwraps y backfill de hilos

Notedeck, el cliente nativo de escritorio multi-columna de Damus, fusionó PR #1459 el 25 de mayo para conectar la reconciliación completa por negentropy NIP-77 en la ruta compartida del outbox. El PR añade tramas de cliente y relay NIP-77, sesiones de negentropy locales al relay y un rastreador de historial completo del outbox que impulsa la reconciliación del conjunto local y las obtenciones de eventos faltantes. Los giftwraps de mensajes obtienen reconciliación por negentropy para que los sobres de mensajes privados puedan recuperarse de los relays de lectura de la cuenta seleccionada. Las vistas de hilo ya no están limitadas por el límite de respuestas de la suscripción en vivo. Dave PNS reemplaza su implementación de negentropy local de Dave con la ruta compartida del outbox mientras preserva su comportamiento existente de historial acotado.

Las suscripciones en vivo y negentropy ahora usan filtros separados. Un flujo puede mantener una pequeña solicitud en vivo mientras emite un filtro de negentropy más amplio para reconciliar lo que el relay ya tiene. El PR intencionalmente no habilita la sincronización amplia de negentropy para timelines de home o perfil, lo que cambiaría las características de coste del arranque en frío. Se añadió cobertura de test para reconciliación, entrega de giftwrap, backfill de hilos, restauración de Dave PNS, cambio de cuenta, reorientación de relay, reintentos de fetch y comportamiento de relay NIP-77.

Vector v0.4.0: reescritura de vector-core, Tor, NIP-46, MLS con negentropy completo y una superficie de agente MCP

Vector, el mensajero multiplataforma centrado en privacidad construido sobre DMs NIP-17 y grupos Marmot, publicó v0.4.0 como su lanzamiento más grande hasta la fecha. El titular es una reescritura del motor desde cero: toda la lógica de Vector ahora vive en un único crate desacoplado, vector-core, compartido entre escritorio, Android y cualquier cliente futuro, con más de 440 tests en el propio núcleo y el shell de la aplicación despojado de miles de líneas. La reescritura es la base para un CLI de Vector, bots y SDKs que impulsan el mismo código de protocolo que la GUI.

La integración con Tor se envía con enrutado de tráfico con un clic y soporte de bridges para evitar la censura. El soporte multi-cuenta aterriza con un conmutador en la app. El inicio de sesión con firmador remoto llega mediante NIP-46 con emparejamiento por bunker mediante QR o URI pegado, para que los usuarios puedan iniciar sesión sin exponer nunca su nsec. Delete-for-everyone funciona tanto en DMs NIP-17 como en chats de grupo Marmot, con Vector reteniendo la clave de firma efímera como una divergencia de especificación deliberada que las notas de lanzamiento indican explícitamente: “una desviación de las especificaciones tradicionales NIP-17/Marmot para controles de privacidad de usuario mejorados”. La clave efímera retenida da a los clientes Vector prueba local de que una eliminación fue sancionada por el remitente original, pero también significa que cualquier otro cliente que toque Vector ve una superficie de verificabilidad de eliminación diferente a la de los clientes NIP-17/Marmot de referencia.

La sincronización de grupos MLS ahora se reconcilia completamente sobre negentropy NIP-77, la misma dirección que tomó Notedeck para giftwraps e hilos esta semana. El uploader de Blossom hace failover entre múltiples servidores, aprende las capacidades de cada servidor y sincroniza la lista de servidores entre dispositivos. Los paquetes de emoji personalizados son creables por el usuario, compartibles y compatibles entre otros clientes Nostr. La memoria SQLite bajó de aproximadamente 308MB a 5MB. El panel de emoji se abre desde caché en disco y los shortcodes estilo Discord (:smile:) más el ranking de frecuencia Unicode exponen el glifo correcto primero.

La adición más novedosa es vector-agent, un servidor MCP (Model Context Protocol) que expone 21 herramientas para que los agentes de IA puedan controlar Vector: enviar DMs, gestionar grupos, subir archivos, editar perfiles. Este es el segundo proyecto Nostr esta semana (junto con Shopstr) en estrenar una superficie MCP, y la primera aplicación de clase mensajero en hacerlo. Junto con AgentNoise (cubierto la semana pasada), el patrón de clientes Nostr controlados por agentes está pasando de experimentos únicos a una dirección de plataforma deliberada.

Cordn aparece como un mensajero MLS mediado por coordinador

Cordn (cliente web en cordn.net, repos en Cordn-msg/cordn y Cordn-msg/cordn-web) es un nuevo mensajero MLS que toma un enfoque arquitectónico diferente al de Marmot. Donde Marmot está completamente basado en relays sin coordinador privilegiado (cada miembro del grupo escribe directamente a relays y cualquier relay conforme puede llevar el tráfico), Cordn introduce un rol de coordinador por grupo implementado como un servicio ContextVM. El coordinador ordena los commits MLS y maneja la distribución de bienvenidas.

El argumento de Cordn, expuesto en su página /why, es que MLS tal como se despliega en mensajeros de producción “no está libre de coordinación” y que la “diseminación pública débilmente ordenada” hace que la convergencia del estado del grupo sea “mucho más difícil” sin un punto fuerte de coordinación. Un diseño mediado por coordinador proporciona un avance predecible de épocas y una resolución más simple de commits concurrentes. Los participantes se conectan al coordinador usando claves efímeras, para que el coordinador aprenda el ID del grupo y el tiempo del tráfico de commits pero no qué pubkeys a largo plazo son miembros. Cualquier parte consultando relays para un grupo Marmot ya puede ver la misma superficie: actividad del grupo por ID del grupo, con el tiempo inferible desde la llegada del evento. Cordn también reconoce que “la confianza en la disponibilidad permanece” con el auto-alojamiento: un coordinador auto-alojado evita la preocupación de centralización a nivel operador pero introduce un punto único de fallo para la liveness del grupo. Marmot evita ese punto único dejando el ordenado a MLS mismo (las épocas y los mensajes Commit manejan el ordenado dentro del protocolo) y distribuyendo eventos Welcome mediante gift wrap NIP-59, a costa de disciplina del lado del admin: los admins deben esperar el reconocimiento del relay de un Commit antes de enviar el Welcome correspondiente, y los clientes deben reconciliar commits concurrentes cuando la entrega del relay compite con una transición de estado.

El contraste vale la pena examinarlo para cualquier equipo que elija una pila de mensajería privada. Marmot intercambia algo de complejidad de implementación por un despliegue independiente del relay sin actor privilegiado en la ruta. Cordn intercambia una dependencia de disponibilidad de un solo punto por un ordenado más estricto y un modelo operativo más simple. Ambos proyectos construyen sobre MLS y usan Nostr como la capa de identidad y transporte. El desacuerdo es sobre dónde vive el coste de coordinación. Los repos cordn-msg muestran una cadencia constante de commits con el servicio de coordinador implementado sobre ContextVM y la capa MLS construida sobre ts-mls.

deepmarks: marcadores NIP-B0 con publicación monetizada por curador

deepmarks-public es un cliente de referencia para la especificación propuesta de marcadores NIP-B0 (kind 39701), con una arquitectura de tres cajas (curador, indexador, visor) y un sistema de niveles financiado por zaps NIP-57 directos al curador. El cliente implementa NIP-B0, NIP-07, NIP-46, NIP-57, NIP-44, NIP-98, NIP-65 y BUD-01 y BUD-04 de Blossom para almacenamiento de archivos. Un nivel vitalicio de 21.000 sats convierte a los lectores de pago en destinatarios recurrentes de zaps para el curador. El curador publica eventos de marcador, el indexador los enriquece con metadatos legibles por máquina y el visor renderiza el feed; cada rol es un servicio desplegable separado.

Lanzamientos

Amber v6.1.0 GA: copia de seguridad cifrada por cuenta

Amber pasó de v6.1.0-pre3 a GA v6.1.0 esta semana. PR #444 estrena copia de seguridad y restauración cifradas para la base de datos de permisos de aplicación, y PR #446 divide la copia de seguridad por cuenta, para que los usuarios con múltiples identidades Nostr puedan hacer copia de seguridad y restaurar cada conjunto de concesiones de app independientemente. El trabajo de firma PSBT cubierto la semana pasada está en el corte GA.

Citrine: suscripciones por relay y prevención de fugas de URL onion

Citrine, el relay personal en el dispositivo que se distribuye con Amethyst, publicó dos correcciones este ciclo. PR #157 cambia de una única suscripción global a suscripciones etiquetadas por relay, para que dos relays de origen que comparten un filtro kinds: [1] ya no colisionen en el lado del agregador. PR #162 filtra las URLs de relay onion cuando el proxy Tor saliente está deshabilitado, previniendo que las direcciones onion filtren en la ruta de enrutado de clearnet.

Angor v0.2.27 y v0.2.28: fiabilidad de relays y reconexión de Boltz

Angor publicó v0.2.27 y v0.2.28. PR #874 corrige un bug de deduplicación de relays donde solo un relay estaba conectado a la vez, una regresión que degradaba silenciosamente la fiabilidad para proyectos con múltiples endpoints de relay. PR #876 añade lógica de reconexión WebSocket para la monitorización de submarine swaps de Boltz, para que una breve desconexión ya no deje un swap en estado desconocido.

Nostrord v1.1.0: zaps NIP-57 y distinción de roles NIP-29

Nostrord publicó v1.1.0 con soporte de zaps Lightning NIP-57 para mensajes y perfiles (PR #98) y una distinción adecuada en el feed de actividad entre cambios de rol NIP-29 y adiciones de miembros (PR #92), que solía renderizarse idénticamente y ocultaba quién había sido promovido frente a quién había sido invitado.

ぬるぬる v1.5.x: keystore MLS con SQLCipher y recuperación de épocas

ぬるぬる (nurunuru, por tami1A84), un cliente Nostr en japonés que implementa mensajería de grupo MLS (kind 443) junto con NIP-44, búsqueda avanzada NIP-50, NIP-55 y NIP-70, publicó cinco lanzamientos esta semana. PR #184 introduce cifrado SQLCipher para el keystore MLS en la capa rust-engine. PR #187 y PR #188 extienden SQLCipher a Android e iOS respectivamente, con un paso de purga de texto plano heredado y guardias de CI. PR #189 y PR #191 añaden recuperación de épocas de pares MLS con una caché de replay y un banner de recuperación en ambas plataformas, para que un cliente que se queda atrás en los commits del grupo pueda recuperarse sin perder la conversación. ぬるぬる es un cliente Marmot construido sobre mdk-core, mdk-sqlite-storage y mdk-storage-traits de marmot-protocol/mdk, por lo que el trabajo de SQLCipher y recuperación de épocas aterriza dentro del mismo runtime MDK que usa White Noise.

Bitcredit Core v0.5.10: corrección de propagación de bloques enraizada en Nostr

Bitcredit Core publicó v0.5.10 con una corrección para un campo Nostr-node-id faltante durante la propagación de bloques, que estaba rompiendo los flujos de creación de empresa que incluían subida de identidad. Bitcredit es un protocolo de e-bill que usa identidades Nostr como raíz de confianza para eventos de propagación de empresa y factura.

Cambios sin publicar

Jumble abrió PR #797 para inicio de sesión con Google mediante el firmador de umbral Pomegranate, permitiendo a un usuario dividir su clave Nostr entre múltiples partes para que ningún firmador único posea el secreto completo. Este es un paso significativo más allá de los flujos de bunker o importación de nsec: un usuario puede recuperar su cuenta incluso si una parte firmadora está comprometida, sin que esa parte posea nunca la clave privada completa.

Shopstr abrió PR #492 inicializando un servidor MCP (Model Context Protocol), con PR #494 construyendo la infraestructura de soporte (fetch de relay, parsers, validación, errores, dedup, audit logging) y PR #472 añadiendo una lista blanca de relays para el gestor de relays MCP. Esto hace de Shopstr el primer marketplace Nostr que se expone como servidor MCP, para que los agentes de IA puedan navegar y actuar sobre listados NIP-99 como una herramienta estructurada.

Keydex, la bóveda de secretos compartidos Shamir, abrió una migración sustancial en PR #226 moviendo los kinds personalizados 1337-1345 al rango 713-721, junto con PR #239 añadiendo AEAD sobre los shares Shamir y PR #234 migrando a aritmética GF256. La migración del rango de kinds alinea Keydex con la forma en que el repo NIPs asigna kinds personalizados, alejándose de un rango autoreclamado.

Mill (nostr-mill) es una nueva UI de firmador Nostr drop-in de OceanSlim (mantenedor del relay Go grain), distribuido como un Web Component con una única etiqueta script en npm y jsDelivr. Una etiqueta <script> da a una app web los seis puntos de entrada comunes de firmador tras una UI unificada: extensión de navegador NIP-07, bunker NIP-46 (pegado de URL o emparejamiento por QR con relays especificables por el usuario, inusual entre integraciones de bunker en página), Amber NIP-55 mediante intents Android, nsec cifrado almacenado en sessionStorage mediante AES-256-GCM con PBKDF2, npub solo lectura y generación de par de claves en el navegador. El componente es tematizable mediante 29 propiedades CSS personalizadas con alcance al Shadow DOM y expone una pequeña API rastreada por SemVer (MILL.open, eventos mill:connected / mill:disconnected, exportaciones de tema con nombre). La motivación del mantenedor es que los flujos de inicio de sesión con bunker han sido reimplementados una app web a la vez a través de Nostr. Consolidar sobre un componente compartido permite a los clientes converger sobre cómo debe comportarse la UX de firmador, y convierte flujos opcionales (como el inicio de sesión con clave delegada mediante firmadores de umbral, reflejando el inicio de sesión con Google basado en Pomegranate de Wisp cubierto arriba) en una superficie reutilizable que cualquier app puede insertar. Mill está en npm v1.5.0, con un solo mantenedor, en fase alfa, con grain como el primer integrador planeado.

moStard, un fork de noStrudel enfocado en Monero por roguehashrate, alcanzó v1.0.1 esta semana con un conjunto de características reducido y una identidad temática de Monero superpuesta sobre la misma pila Applesauce + worker-relay. El trabajo de esta semana aterrizó el renderizado de eventos software-application kind 32267 de Zapstore (tarjetas incrustadas en el timeline mostrando nombre de la app, icono, capturas, plataforma, licencia y un enlace de lanzamiento a zapstore.dev/apps/<d-tag>), encuestas mediante kind 20 y kind 21, propinas basadas en Payment Targets NIP-A3 con códigos QR por método, renderizado de markdown en notas, soporte de selector de GIFs para teclados de GIF externos y correcciones de emparejamiento del firmador Amber. El enmarque Monero se extiende al flujo de propina: las entradas payto NIP-A3 para direcciones monero obtienen botones de primera clase en la misma UI junto con lightning y bitcoin. El cliente tiene un solo mantenedor y está en fase alfa, pero el trabajo del 27 de mayo muestra a un constructor tirando de NIP-A3 desde los anuncios de especificación de protocolo de esta semana directamente a un fork en producción en cuestión de días.

Actualizaciones de NIP y trabajo de especificación de protocolo

Pila NIP de calendario: cuatro propuestas del equipo Formstr

Ix2 (@geralt-debugs) abrió cuatro PRs coordinados de NIP el 17 de mayo, todos referenciando la implementación calendar.formstr.app que ya se distribuye bajo el mismo autor. PR #2350 propone kind 84 como un evento generalizado de “autoremoción de participante”: un participante etiquetado en cualquier evento puede publicar un kind 84 que referencie el original mediante tags e, a y k para señalizar la exclusión. Los relays deben validar que el firmante del kind 84 aparece en un tag p del evento referenciado antes de honrar la remoción, y una eliminación kind 5 siempre tiene precedencia. El PR generaliza un patrón que previamente solo se describía dentro del contexto de calendario NIP-52, para que kind 84 se convierta en la forma estándar de que los no-autores se retiren de cualquier evento de participante.

PR #2351 es la base de la pila de calendario: NIP-52E para eventos privados de calendario (kinds 32678 basados en tiempo, 32681 evento de día, 32123 lista de calendarios privados, 31926 lista de ocupación, 1052 gift wrap, 52 rumor) y NIP-52R para eventos recurrentes. En el núcleo arquitectónico está el patrón de view-key: un par de claves generado aleatoriamente cifra el contenido del evento con NIP-44, y la mitad secreta (codificada en bech32 como nsec) se envuelve en gift wrap a cada participante. El firmante solo posee el tag d público; todo lo demás vive en content cifrado. Desacoplar el cifrado de contenido de la identidad de esta forma significa que editar un evento no requiere volver a distribuir claves a los destinatarios. NIP-52R define dos tags opcionales en los kinds existentes 31923 y 31922 para declarar recurrencia usando valores RRULE RFC 5545 desnudos, con el índice de día D volviéndose opcional cuando RRULE está presente. El secreto hacia adelante está explícitamente ausente: una view key filtrada revela todas las versiones pasadas y futuras del evento bajo el mismo tag d.

PR #2352 construye sobre NIP-52E con una especificación de programación de citas descentralizada que la descripción del PR llama “una alternativa drop-in a Calendly/Cal.com sin intermediario central”. Kind 31927 anuncia una página de programación con ventanas de disponibilidad cifradas; kind 32680 es un registro de recuperación auto-cifrado del lado del host para la view key; kinds 1057 y 1058 son la solicitud y respuesta de reserva envueltas en gift wrap. La mecánica ingeniosa: el reservador genera tanto el tag d como la view key para el futuro evento privado antes de enviar la solicitud, para que el reservador pueda añadir la cita a su propio calendario inmediatamente con la clave correcta, y el host nunca tenga que hacer un round-trip de una clave de vuelta. Las respuestas de reserva llevan un tag status sin cifrar en el envoltorio exterior para que los relays puedan filtrar sin descifrar.

Una implementación de referencia ya está en vivo en calendar.formstr.app y como la app Android Calendar en Zapstore. PR #2351 cierra PR #2027 en su favor, consolidando una propuesta anterior de calendario privado que había estado abierta desde principios de año.

Payment Targets y Silent Payments

Otras dos propuestas de NIP circularon esta semana en documentos kind:30023 de formato largo.

Una propuesta de Payment Targets (NIP-A3 / payto) define un evento reemplazable kind 10133 que lleva uno o más tags ["payto", "<type>", "<authority>"] que mapean a URIs payto: RFC 8905. Los tipos soportados incluyen bitcoin, lightning, ethereum, monero, nano, cashme, revolut y venmo. La intención es estandarizar un tarro de propinas multi-rail que complementa (no reemplaza) a los zaps NIP-57 basados en lud16. Amethyst v1.11.0 es el primer implementador; los PRs fusionados #2953 y #3009 estrenan la superficie de suscripción y observación, y PR #3011 conecta la UI para PaymentTargetsEvent.

Dos propuestas competidoras de Silent Payments cayeron de diferentes autores. La primera variante deriva las claves de escaneo y gasto BIP-352 de silent-payment del nsec mediante tweaks aditivos públicos, para que cualquier remitente pueda construir una dirección sp1q... desde un npub sin configuración. La advertencia del autor es explícita en la especificación: “bscan y bspend DEBEN ser tratadas con exactamente el mismo cuidado que el nsec”, porque la clave de escaneo revela el nsec. Una segunda variante toma el enfoque inverso, añadiendo un campo sp_address a los metadatos de perfil kind 0 que contiene una dirección BIP-352 silent-payment estándar cuyas claves se mantienen independientes de la identidad Nostr. La variante dos es estructuralmente más segura. Ambas propuestas atrajeron un hilo de revisión reflexivo; erskingardner (líder de Marmot) publicó un comentario detallado en el gist trbouma que rastrea la propuesta. Su preocupación central es que la variante 1 deriva la clave privada de escaneo del nsec más un tweak calculable públicamente, lo que significa que cualquiera que posea la clave de escaneo (incluido un servicio de escaneo de terceros al que el usuario tenga que delegar en la práctica) puede recuperar el nsec completo restando ese tweak. La misma clave que permite a un servicio remoto escanear los pagos entrantes también permite a ese servicio robar tu identidad y cualquier fondo derivado de ella.

En el lado git-sobre-Nostr NIP-34, hzrd149 publicó 2 parches a schemata. gitworkshop.dev en sí atrajo dos reportes de issues: uno señalando que las sesiones de login se pierden al refrescar la página cuando se usa un firmador remoto NIP-46, el otro pidiendo estilizado distinto para enlaces en las vistas previas de README.

Seis años de mayos de Nostr

El último newsletter de mayo de 2026 se aleja de los lanzamientos de la semana para recorrer el mes de mayo a lo largo de la historia de Nostr. Cada año tuvo un centro de gravedad diferente: 2021 fue un único commit, 2022 fue la formación del propio repo NIPs, 2023 fue la explosión de la especificación de protocolo, 2024 fue el ciclo de consolidación, 2025 fue cuando se fusionó negentropy y el Notedeck de Damus se graduó a Beta, y 2026 es el mes cubierto en este número y en los tres anteriores.

Mayo 2021

Nostr tenía seis meses. El único código Nostr vivía en fiatjaf/nostr y todo el mes produjo exactamente un commit, pero ese commit se convirtió en una de las partes más usadas del protocolo. El 22 de mayo, fiatjaf reutilizó NIP-02 como el NIP de lista de contactos. El mensaje del commit dice: “repurpose NIP-02 and add NIP authorship”, y el crédito explícito es a PR #16 de arcbtc (Ben Arc de LNbits), abierto el 9 de febrero y cerrado el día antes de que fiatjaf plegara la idea en NIP-02. El pitch de arcbtc era pequeño: un kind para “enviar lista de seguidores a los relays” que sería “útil para restaurar cuentas y recomendar claves públicas a seguir”. fiatjaf lo generalizó en un único evento kind:3 cuyos tags sirven tres propósitos a la vez. Son una lista de follow (el grafo social), un almacén de petname (apodos locales para amigos) y una fuente de recomendación de relays (qué relays usa un follow). El mismo evento, reemplazable por autor, se convirtió en la respuesta canónica a “a quién sigue esta persona”, “cómo los llama” y “dónde lee”. Cada cliente construido en los siguientes cinco años lee kind:3. La convención añadida en el mismo commit, que cada NIP nombra a su autor, es la razón por la que cada especificación ahora tiene firmas.

Mayo 2022

El mes en que el repo NIPs se convirtió en un proyecto comunitario. El 1 de mayo, fiatjaf migró las especificaciones de fiatjaf/nostr a un repo dedicado nostr-protocol/nips y el 2 de mayo añadió criterios formales de aceptación. Dos días después, Robert C. Martin (Uncle Bob) abrió PR #1, el primer pull request externo, proponiendo convenciones de hilo para tags e y p. El PR fue numerado originalmente NIP-13, luego renombrado a NIP-10 para dejar sitio a proof-of-work. Tres de los primeros seis NIPs son de Uncle Bob: NIP-10 (marcadores de hilo), NIP-14 (el tag Subject) y el commit del 21 de mayo que fijó kind:1 como el kind canónico de nota de texto corta. El 5 de mayo, William Casarin hizo sus primeros commits NIP: NIP-13 Proof of Work y el evento kind:2 recommend-relay. Al día siguiente, fiatjaf publicó NIP-07 window.nostr, veinte líneas de markdown que definieron la interfaz de firmador de extensión de navegador aún usada hoy. La advertencia CORS de NIP-05 por David A. Harding y el filter.limit de NIP-01 aterrizaron la misma semana. nostr-tools publicó su primer build ESM importable por navegador el 8 de mayo. Semisol redactó NIP-15 (End Of Stored Events) y NIP-16 (rangos de kind de evento) a final de mes, los documentos que aún gobiernan la semántica de sincronización de relay y la clasificación regular-vs-reemplazable-vs-efímero.

Mayo 2023

La explosión de la especificación de protocolo. Se abrieron sesenta y cuatro PRs de NIP ese mes, con varias de las propuestas que definieron la superficie de Nostr para los próximos dos años aterrizando en 31 días, y el mayor anuncio de financiación que Nostr había recibido aterrizó el 4 de mayo con la subvención de $10 millones de OpenSats de #startsmall de Jack Dorsey, el dinero que ha respaldado cada ola de subvenciones Nostr desde entonces. NIP-47 (Nostr Wallet Connect) fue fusionado el 2 de mayo, trayendo la especificación wallet-connect de Alby al protocolo principal. Dos días después Vitor Pamplona propuso NIP-53 Live Activities con salas kind:30311 y mensajes de chat kind:1311, la base para cada superficie de livestreaming Nostr que siguió. Pablo Fernandez abrió NIP-84 Highlights el 5 de mayo y NIP-89 Recommended Application Handlers el 14 de mayo. v0l (Kieran Babich, autor de Snort) propuso NIP-98 HTTP Auth el 8 de mayo, la primitiva de autenticación de la que NIP-96 y Blossom dependieron ambos más tarde. Jonathan Staab propuso NIP-32 Labels el 15 de mayo, y NIP-30 Custom Emoji se fusionó el mismo día. Arthur Franca propuso NIP-96 HTTP File Storage Integration el 21 de mayo. Dos días después, Vitor añadió zap splits a NIP-57 y verbiricha añadió borradores de formato largo kind:30024 a NIP-23, la especificación que se convirtió en la base para los flujos modernos de autoría de formato largo Nostr en Habla, YakiHonne y Highlighter. fiatjaf propuso NIP-29 Simple Groups el 28 de mayo, la primera especificación de grupo gestionado por relay que cubre eventos de moderación kind:9000 a kind:9020. El mes cerró con Paul Miller abriendo la conversación de NIP-44 el 31 de mayo, un diseño de DM cifrado basado en XChaCha20 destinado a reemplazar NIP-04. El lado del cliente se movió igual de rápido: Damus estrenó NWC, zap pool y Pending Zaps entre el 10 y el 15 de mayo; Snort lanzó zap pool y medios de pago L402; Amethyst publicó aproximadamente treinta lanzamientos versionados a lo largo del mes, desde v0.40.1 el 1 de mayo hasta el rango v0.55.x a fin de mes, con zap splits en v0.45.0 y labels NIP-32 en v0.46.0; el repo Primal Android fue creado el 16 de mayo; rust-nostr v0.22.0 añadió NIP-47 y NIP-58. El 1 de mayo, strfry publicó su integración de negentropy, la primera implementación de relay del protocolo de reconciliación de conjuntos de Doug Hoyte que más tarde se convertiría en NIP-77. El mes cerró con Forbes publicando un perfil de formato largo de fiatjaf el 30 de mayo, uno de los primeros deep dives de la prensa mainstream sobre el fundador anónimo de Nostr.

Mayo 2024

El ciclo de consolidación. Menos propuestas llamativas, más publicaciones. NIP-54 Decentralized Wikis se fusionó el 2 de mayo con artículos kind:30818 y tags d normalizados por caso. Tres días después, NIP-56 se extendió para que los reportes de abuso pudieran señalizar amenazas digitales (malware, phishing) junto con categorías solo de contenido. El 6 de mayo, las reacciones NIP-25 se simplificaron para dejar de incluir todo el hilo de respuesta como tags e. Arthur Franca propuso NIP-22 Comment el 12 de mayo, introduciendo kind:1111 para que las respuestas a eventos no-kind:1 (artículos, archivos, productos) obtengan una forma estructurada de hilar. El 19 de mayo, fiatjaf renovó NIP-46 para abandonar completamente NIP-04 y cambiar todo el tráfico de bunker a cifrado NIP-44, la maniobra de deprecación que ha dado forma a cada implementación de bunker desde entonces. El 20 de mayo, NIP-71 Video Events se fusionó con kind:21 y kind:22, y NIP-10 añadió el argumento opcional de pubkey en los tags e para que los clientes puedan resolver autores de hilo sin primero obtener el evento referenciado. NIP-35 Torrents de Kieran Walsh se fusionó el 22 de mayo, y el 24 de mayo el README de NIPs referenció por primera vez CIP-01 como una propuesta off-repo, señalizando el inicio del patrón “NIPs como uno de varios lugares de propuesta”. El 25 de mayo, un PR de limpieza eliminó el tag aes-256-gcm de NIP-71 antes de que las implementaciones downstream lo congelaran. NIP-96 añadió list files y descartó el requisito de transformación el 27 de mayo. El 28 de mayo, Jonathan Staab propuso subir el listón de aceptación de NIP para requerir al menos dos implementaciones interoperables antes de que un borrador pueda graduarse. Lado cliente: Damus etiquetó v1.7.2 y v1.8 más un v1.9 con manejo completo de marcadores NIP-10 el 9-10 de mayo, aterrizó autenticación NIP-98 en notificaciones push, y estrenó soporte completo de marcadores NIP-10. Amethyst hizo de NIP-17 el modo DM por defecto el 14 de mayo, construyó gestión de relays con modelo outbox NIP-65, añadió selección de servidor NIP-96, y estrenó derivación de claves BIP-32/BIP-39 NIP-06. Primal Android 0.99.2 el 10 de mayo añadió etiquetado de usuarios y NWC de wallet externa, seguido por 0.99.4. Pablo Fernandez aterrizó un cluster de actualización optimista NDK entre el 24 y el 31 de mayo. Snort añadió selección de servidor NIP-96, y cashu-ts separó sus primitivas cripto en @cashu/crypto.

Mayo 2025

El mes en que NIP-77 (Negentropy Syncing) se fusionó el 27 de mayo, la especificación de fiatjaf y Doug Hoyte para el protocolo de cable que reemplaza los filtros REQ de fuerza bruta con computación de diferencia de coste logarítmico. Esta era la misma negentropy que strfry había publicado dos años antes como una característica del lado del relay, ahora formalizada como un protocolo cliente-relay, y la entrada del README aterrizó el mismo día. La semana anterior, NIP-23 formato largo definió cómo los documentos HTML se asocian a entidades Nostr mediante un tag <link> el 24 de mayo, la primitiva de copia web canónica. NIP-25 añadió pistas de relay del objetivo de reacción el 22 de mayo y descartó la recomendación de emoji-a-like/dislike, tratando los emojis como unidades semánticas distintas. NIP-52 se simplificó el 14 de mayo para centrarse en los kinds que los clientes estaban distribuyendo en producción, el recorte que hizo que las extensiones de calendario de Formstr de un año después fueran más limpias de injertar. El 9 de mayo, Follow Packs (listas de follow curadas kind 39089) y Favorite Relays (una nueva lista reemplazable bajo NIP-51) entraron en el README el mismo día. El arco del protocolo Marmot aún no había comenzado: solo el repo whitenoise-rs existía (primer commit 9 de septiembre de 2024), y mayo de 2025 fue su fase de prototipo Svelte+Tauri, con el commit del 14 de mayo eliminando código específico de Tauri mientras el proyecto pivotaba a su arquitectura actual. El núcleo Rust MDK dedicado (12 de septiembre de 2025), el repo de especificación de Marmot (19 de septiembre de 2025) y la UI Flutter (2 de diciembre de 2025) llegaron todos más tarde en el año. Del lado cliente, Notedeck v0.4.0 de Damus se publicó el 5 de mayo como la primera Beta, graduándose de Alpha con búsqueda de texto completo, el asistente de IA Dave, zaps sobre NWC, GIFs, etiquetado de usuarios y listas de silencio. Dos días después, Flotilla 1.0.0 de hodlbod cruzó el umbral de lanzamiento público como un cliente de chat de grupo basado en NIP-29, junto con Coracle 0.6.12, el primero de seis lanzamientos de Coracle que llegaron hasta 0.6.17 el 14 de mayo. Amber v3.4.0 el 12 de mayo abandonó las APIs obsoletas de Android Autofill y ClipboardManager y migró de shared preferences cifradas a DataStore. Primal Android 2.2.20 el 20 de mayo añadió el flujo Redeem Code para Primal Premium y una galería de imágenes rediseñada. nak v0.14.0 el 21 de mayo cortó un menor del CLI canónico la misma semana que los lanzamientos de Coracle, Flotilla y Notedeck. OpenSats recibió su mayor donación no-Bitcoin-treasury hasta la fecha cuando la Reynolds Foundation donó $2 millones el 22 de mayo.

Mayo 2026

El mes cubierto en Newsletter #21, #22, #23 y este número. El hilo definitorio es MLS-sobre-Nostr alcanzando producción multi-cliente: MDK 0.8.0 estrenó primitivas de índice de hoja MIP-05 y key packages direccionables, seguido por PR #306 añadiendo validación de mensajes efímeros NIP-40 en iOS y Android mediante una superficie UniFFI compartida. White Noise v2026.5.22+25 estrenó push en iOS mediante una Notification Service Extension que descifra el texto cifrado MLS dentro del proceso de la extensión para que el broker nunca vea texto plano, y dos nuevos clientes Marmot aparecieron: Scramble (un cliente de escritorio y Android en .NET/Avalonia con ranuras KeyPackage multi-dispositivo) y Cordn (una arquitectura MLS alternativa usando un coordinador por grupo sobre ContextVM). Angor migró su mensajería cifrada de NIP-04 a NIP-44 en PR #860, cerrando el arco de deprecación que se abrió con la propuesta NIP-44 de Paul Miller en mayo de 2023. El equipo Formstr abrió el envío coordinado de NIP más grande de la memoria reciente el 17 de mayo, con PR #2350 para autoremoción de participantes, PR #2351 para eventos privados de calendario y recurrencia (NIP-52E y NIP-52R), y PR #2352 para programación de citas descentralizada, todos con calendar.formstr.app ya distribuyendo la implementación de referencia. Amethyst v1.11.0 renderizó los calendarios NIP-52 como una categoría de timeline de primera clase y extendió los zaps de Bitcoin en cadena a distribuciones divididas. Un año después de que NIP-77 se fusionara en mayo de 2025, tres implementaciones independientes estrenaron la adopción de negentropy en la misma ventana: Notedeck PR #1459 la conectó al cliente de escritorio de Damus para giftwrap y backfill de hilo, Vector v0.4.0 usó sincronización MLS con negentropy completo como parte de su reescritura vector-core desde cero junto con Tor con un clic y una superficie de agente MCP de 21 herramientas, y Citrine v3.0.0-pre1 la añadió al relay nativo Android junto con Tor incorporado y agregación multi-relay. Mostro v0.17.4 cerró el bucle del bono anti-abuso con pagos de bono recortado de la Fase 3 en PR #738, aplicando lo que el protocolo anteriormente solo amenazaba. Tres años desde “reemplazamos NIP-04” hasta “reemplazamos NIP-44 con estado de grupo MLS completo”.

Si quieres discutir, envíanos un DM en Nostr.

Nostr Compass #23

Thu, 21 May 2026 00:00:00 +0000

Primal 3.5 estrena un shell de Android reconstruido, Amethyst añade zaps de Bitcoin en cadena, White Noise gana renderizado de markdown y enlaces profundos, Keycast pasa una auditoría de seguridad y AgentNoise te permite controlar agentes de codificación de IA locales sobre chat cifrado con Marmot. Hostr lanza una plataforma P2P de alojamiento en alquiler sobre Nostr con cuatro borradores de NIP que cubren listados, reservas y escrow basado en EVM. Angor migra la mensajería cifrada de NIP-04 a NIP-44, Dart NDK añade NIP-77 y un firmador web, Alby js-sdk v8 estrena reconexión multi-relay nativa para NWC y KeyChat parchea una brecha de secreto hacia adelante en la eliminación de prekeys únicas de Signal. En el lado del protocolo, el bono anti-abuso de Mostro alcanza la Fase 2, Wisp estrena respuestas privadas y reacciones envueltas en gift wrap, y una ola de implementación de NIP-05 sobre Namecoin toca media docena de clientes en una sola semana.

Historias principales

Primal 3.5 para Android

Primal, el cliente social respaldado por su propia infraestructura de relay de caché, publicó 3.5.9 esta semana con un shell de aplicación reconstruido. El rediseño reemplaza la estructura de navegación anterior por un diseño actualizado y una nueva pantalla Explore, dando a la superficie principal de descubrimiento su propio hogar dedicado. El lanzamiento añade reproducción de audio para las vistas previas de enlaces, para que los archivos de audio incrustados en las notas se reproduzcan en línea sin salir del feed. Las insignias de verificación NIP-05 ahora se muestran en línea en los perfiles, exponiendo la confirmación de identidad de un vistazo. El filtrado de notificaciones recibió una revisión, permitiendo a los usuarios acotar qué tipos de eventos llegan a su lista de notificaciones. El editor ganó un mejor manejo de enlaces a eventos, y la capa de base de datos subyacente recibió correcciones de estabilidad.

White Noise: markdown, enlaces profundos y metadatos de audio

White Noise, la app de mensajería de grupo cifrada con Marmot construida sobre Nostr y MLS (RFC 9420), tuvo una de sus semanas más ocupadas hasta la fecha en los repositorios frontend y backend.

En el frontend, PR #665 añade renderizado completo de markdown para los mensajes de chat, por lo que negrita, cursiva, bloques de código y enlaces ahora se renderizan de forma nativa en la vista de mensajes. PR #675 habilita el flujo para abandonar el grupo que anteriormente estaba bloqueado para administradores no-último, y PR #661 añade soporte nativo de enlaces profundos para los URIs whitenoise:// y whitenoise-staging:// cubriendo usuarios, chats y ajustes, sin requerir ninguna infraestructura de redirección HTTP.

En el backend en whitenoise-rs, PR #835 hace que la rotación de key packages funcione correctamente reutilizando la ranura d_tag para publicaciones kind:30443, habilitando la semántica de evento reemplazable NIP-33 para que las rotaciones sucesivas de key packages reemplacen al evento anterior en los relays, manteniendo solo el key package actual. PR #833 extiende FileMetadata con campos opcionales duration_ms y waveform para adjuntos de audio, coordinado con PR #300 de MDK que añade los mismos campos a los tags de medios MIP-04. Un nuevo crate whitenoise-markdown (PR #836) reemplaza el analizador de tokens nostr-sdk anterior con una biblioteca dedicada de renderizado de markdown.

La propia especificación del protocolo Marmot recibió una corrección de seguridad en PR #68, que cierra un problema de seguridad al especificar explícitamente HKDF-SHA256 para las derivaciones de clave de imagen en MIP-01, eliminando la ambigüedad que podría llevar a la divergencia en las implementaciones. En MDK, PR #307 sanea las razones de fallo de bienvenida y limita la longitud almacenada, cerrando un hallazgo de seguridad separado.

Amethyst v1.10.0: zaps de Bitcoin en cadena

Amethyst publicó cuatro lanzamientos esta semana, con v1.10.0 como titular. El lanzamiento añade soporte para zaps de Bitcoin en cadena NIP-BC, permitiendo a los usuarios enviar, recibir y mostrar zaps liquidados directamente en cadena mediante transacciones de Bitcoin. Los lanzamientos anteriores de la serie corrigieron la detección de blobs Blossom para rechazar nombres de archivo no conformes (v1.09.2), parchearon las reglas de ProGuard para las compilaciones de escritorio y fusionaron el pull request #2977 para mostrar a los zappers de Bitcoin en cadena como una fila ₿ dedicada en la galería expandida de reacciones. Una pantalla de historial de transacciones en cadena con paginación en curso aterrizó en PR #2974.

AgentNoise: controla agentes de codificación sobre White Noise

AgentNoise de nvk es un ayudante de escritorio nativo en Rust que te permite usar un teléfono con White Noise como superficie de control para sesiones de agentes de codificación locales de Codex y Claude. La herramienta escucha uno o más chats de White Noise, autentica a los remitentes mediante un flujo PIN de primer emparejamiento y lanza agentes de codificación locales a través del launcher configurado. Enviar /claude <prompt> desde tu teléfono abre una nueva sesión de trabajo de White Noise nombrada por el hostname de la máquina y un breve resumen del prompt, luego transmite actualizaciones de progreso y la salida final de vuelta a ese chat. Es intencionalmente Rust-primero y mantiene Node fuera del camino del puente de confianza. El proyecto alcanzó v0.1.24 esta semana, añadiendo respuestas más cortas legibles en teléfono, referencias a trabajos por prefijo corto único y un observador opcional de sesiones locales. AgentNoise ejecuta los CLIs wn y wnd de marmot-protocol/whitenoise-rs como subprocesos, por lo que comparte su transporte Nostr con el propio cliente White Noise.

Auditoría de seguridad de Keycast completada

Keycast, el servidor de firma remota NIP-46 orientado a equipos que almacena las claves privadas Nostr cifradas en reposo en SQLite, completó una auditoría de seguridad en mayo de 2026. La pasada de endurecimiento abordó problemas de autenticación, permisos, integridad de datos y dependencias, y los resultados están documentados en AUDIT.md. Los cambios incluyen: la autenticación HTTP NIP-98 ahora requiere exactamente un tag u y un tag method, rechaza timestamps obsoletos y valida los hashes de payload; la lista de permitidos ALLOWED_PUBKEYS se analiza exactamente y se aplica del lado del servidor; las políticas vacías ahora deniegan por defecto las solicitudes de sign/encrypt/decrypt; la aplicación de claves foráneas está habilitada en las conexiones SQLite; y las rutas de aplicación anidadas como /teams/:id están protegidas del lado del servidor. Una migración SQL normaliza el JSON de permisos de kinds permitidos antiguo al arranque. El proyecto sigue en fase temprana y la auditoría anota elementos residuales antes de confiarle claves reales de equipo.

Scramble: cliente Marmot para escritorio y Android

Scramble (antes OpenChat) es un cliente de escritorio y Android en .NET/Avalonia para el protocolo Marmot, implementando los MIPs 00-04: publicación de KeyPackage (kind:30443), metadatos de grupo con la extensión MLS NostrGroupData, eventos de bienvenida envueltos en gift wrap NIP-59 (kind:444), mensajes cifrados ChaCha20-Poly1305 (kind:445) y adjuntos de medios cifrados con Blossom. Es totalmente interoperable con White Noise y cualquier otro cliente compatible con Marmot.

El proyecto publicó 13 lanzamientos esta semana, con soporte multi-dispositivo como característica principal. Cada dispositivo genera una ranura KeyPackage única (un tag d en kind:30443). Al arranque, Scramble obtiene los KeyPackages propios del usuario desde los relays, detecta los IDs de ranura de los dispositivos pares y los añade automáticamente a los grupos MLS existentes usando el flujo de commit por etapas. La adición automática está restringida a los grupos donde el usuario actual es admin; los grupos no-admin se saltan con una guía para pedir al admin del grupo. Un banner de divulgación de secreto hacia adelante informa a los dispositivos recién enlazados que los mensajes antiguos no están disponibles. Una pasada de reconciliación de ID de ranura (TryReconcileSlotId) maneja dispositivos migrados desde versiones pre-multi-dispositivo emparejando los bytes de KeyPackage del relay contra el material clave local para adoptar el tag d correcto. La reconexión del firmador externo para usuarios de Amber y NIP-46 también se corrigió: el guardia IsConnected que bloqueaba la reconexión automática incorporada de ExternalSignerService se eliminó en los nueve sitios de llamada en NostrService.

Hostr: alojamiento en alquiler P2P sobre Nostr

Hostr (fuente) es una plataforma peer-to-peer de alojamiento en alquiler construida enteramente sobre Nostr. Cubre el flujo completo estilo Airbnb (buscar y listar propiedades, negociar reservas y liquidar pagos) usando cuatro borradores de NIP que el proyecto está desarrollando en paralelo con la aplicación.

El NIP de alojamiento extiende los listados clasificados de NIP-99 (kind:30402 activo, kind:30403 borrador) con tags específicos de alojamiento para tipo (room, house, apartment, villa, hotel, hostel, resort), horas de check-in/check-out, estancia mínima e índices de celdas geoespaciales H3 para búsqueda basada en ubicación con precisión configurable. El NIP de reservas define un protocolo completo de negociación y ciclo de vida: los eventos de reserva reemplazables kind:32122 llevan un ID de intercambio d, un tag a de anclaje al listado y tags p de participantes con roles (buyer, seller, escrow); los rumores de mensajes estructurados kind:1327 entregan contraofertas privadas en la etapa de negociación mediante gift wraps NIP-59 para que la negociación quede fuera de los relays públicos; los eventos de transición append-only kind:1326 crean una traza de auditoría pública una vez que una reserva se compromete. La privacidad del comprador se preserva mediante claves Nostr temporales por intercambio vinculadas a la identidad real del comprador mediante tags participant_proof cifrados. El NIP de escrow define los anuncios de servicios de escrow kind:30303 y las declaraciones de confianza del usuario kind:17388; la implementación de referencia usa contratos inteligentes EVM en Rootstock, con contractBytecodeHash permitiendo a los clientes verificar que el contrato desplegado coincide con una implementación auditada conocida. El NIP de listado de marketplace define tags genéricos compartidos entre todos los perfiles de marketplace NIP-99, incluidos instantBook, negotiable, quantity, securityDeposit, cancellationPolicy y maxDisputePeriod. Esta semana el proyecto preparó su envío a las app stores y fusionó soporte de identidad de cliente MCP para automatización orientada a agentes.

Dos nuevas entradas aparecieron en la plataforma Shakespeare MiniApps esta semana: InkPress, un generador de revistas con IA que publica contenido estructurado tipo revista como eventos Nostr, y PressStr, una plataforma de escritura y publicación para la pila Soapbox.

Publicando esta semana

ngit v2.4.4

ngit publicó v2.4.4, añadiendo ngit sync --trust-server (-t) para casos en que un servidor git está por delante en fast-forward respecto al estado de Nostr. Cuando se detecta esta situación, sync reporta los refs afectados y requiere la bandera para firmar y publicar un evento de estado actualizado; un ajuste de configuración de git nostr.trust-server-domains proporciona una lista blanca separada por punto y coma para servidores que deben ser confiados automáticamente sin la bandera.

Amber v6.1.0-pre3 añade firma PSBT

Amber publicó v6.1.0-pre3 con un mejor diseño para nuevas conexiones de apps, correcciones de crashes y una opción de seleccionar/deseleccionar todo en la pantalla de permisos. PR #438 añade soporte para firmar PSBT a través de las rutas basadas en Intent y basadas en relay NIP-46, permitiendo a Amber firmar Partially Signed Bitcoin Transactions sin exponer el nsec a la app solicitante.

Wisp v1.1.0 estrena respuestas privadas y elimina soporte para Amber

Wisp publicó v1.1.0 con respuestas privadas mediante gift wrap NIP-17 (PR #540), reacciones envueltas en gift wrap y zaps DIP-03 en respuestas privadas (PR #543), traducción automática para notas (PR #523) y una entrada fiat estilo registro en el diálogo de zap. PR #541 migra los zaps privados de un esquema casero de texto plano en DM-relay a DIP-03 con enrutado adecuado de DM-relay. El mismo ciclo de lanzamiento eliminó el soporte del firmador remoto NIP-55 (PR #531), descartando las integraciones con Amber y otros firmadores externos, y eliminó el relay local incorporado (PR #533). Wisp es un cliente social Nostr para Android.

Calendar by Formstr v1.5.4 corrige gift wrap para nuevos participantes

Calendar by Formstr publicó v1.5.4 (el último de una secuencia v1.5.2 → v1.5.4). PR #160 corrige un bug donde editar un evento privado de calendario con nuevos participantes publicaba el evento actualizado con las nuevas pubkeys en tags p pero nunca creaba ni entregaba invitaciones gift wrap a esos participantes, rompiendo el flujo de invitación para adiciones de última hora. PR #156 añade manejo de errores alrededor del descifrado de eventos privados para que los clientes ya no lancen excepciones en eventos indescifrables, y PR #138 corrige tiempos de eventos recurrentes que se desviaban entre zonas horarias.

Applesauce v6.1.0 añade git casts NIP-34 y relays de búsqueda NIP-51

Applesauce publicó v6.1.0 a través de sus paquetes con soporte significativo para NIP-34 (git-sobre-Nostr): applesauce-common añade nuevos casts GitRepository, GitGraspList y FavoriteGitRepos más las fábricas correspondientes, y expone las propiedades reactivas User.favoriteGitRepos$, User.gitAuthors$ y User.graspServers$ para que las aplicaciones puedan listar los repos git seguidos de un usuario, los mantenedores de repos y los servidores GRASP configurados directamente desde el mismo objeto User. El mismo lanzamiento añade soporte para listas de relays de búsqueda kind 10086 NIP-51, una adición reciente a la familia de listas de relays usada para descubrir dónde encontrar datos específicos. applesauce-core gana replaceableAddress en EventCast para búsqueda de direcciones reemplazables NIP-01, más pointer, kind y un ayudante getReplaceableAddressForEvent, y añade un método timeline$() en el cast base User. PR #73 corrige los métodos manuales del pool que silenciosamente descartaban relays offline.

Sprout v0.0.16 estrena el binario Sprig y huddle protocol v2

Sprout de Block, un workspace de equipo basado en relay Nostr auto-alojado donde humanos y agentes de IA comparten las mismas salas y registro de eventos, publicó v0.0.16 de la app de escritorio junto con compilaciones rodantes del nuevo binario todo-en-uno Sprig (PR #605), que empaqueta el arnés ACP, el agente y el MCP de desarrollador en un único binario estilo busybox para despliegue sencillo. La bandera --no-memory añadida en PR #611 permite a los operadores deshabilitar la inyección de memoria central NIP-AE para el arnés ACP. En el lado de tiempo real, PR #609 extiende el protocolo de voz huddle a un encabezado de trama v2 que soporta hasta 10 pares simultáneos.

Nostrord v1.0.3 añade OS keychain y multi-cuenta

Nostrord publicó v1.0.3 con almacenamiento de claves local endurecido usando el keychain del OS y respaldo por frase de contraseña, soporte multi-cuenta y un código QR de bunker tocable que abre la app del firmador en Android.

Angor migra a NIP-44 y estrena endurecimiento de seguridad

Angor, la app de crowdfunding en Bitcoin construida sobre Nostr y Taproot, publicó tres lanzamientos inestables esta semana (v0.2.24, v0.2.25 y v0.2.26) con un conjunto de cambios de endurecimiento de seguridad e integración con Nostr. PR #860 migra la mensajería cifrada Nostr de NIP-04 a NIP-44, reemplazando el esquema basado en XOR obsoleto con cifrado ChaCha20-Poly1305. PR #861 permite subidas de medios Blossom sin una wallet seleccionada usando una clave de autenticación Nostr efímera, desbloqueando subidas para usuarios que aún no han conectado una wallet. La serie de seguridad abordó varias categorías endurecidas: PR #854 añade seguridad de tipos para AngorKey y protección de memoria de mnemónicos, PR #856 aplica validación a nivel de protocolo para timelocks, tasas de comisión, umbrales de dust y reglas de penalización, y PR #851 aplica endurecimiento no rupturista en ocho categorías de severidad media y baja. PR #859 corrige la compatibilidad con GrapheneOS habilitando la compilación AOT y eliminando la generación de código en tiempo de ejecución, y PR #855 evita la pérdida de wallet al hacer swipe-kill en Android persistiendo el estado de la wallet antes de que el OS termine el proceso.

Alby js-sdk v8.0 estrena reconexión multi-relay NWC

Alby js-sdk publicó la línea v8.0 (de v8.0.1 a v8.0.3) con soporte para suscripción NWC multi-relay. PR #516 actualiza la dependencia nostr-tools y habilita la reconexión automática nativa entre múltiples relays, reemplazando el enfoque de polling anterior con lógica de reconexión nativa de relay. PR #542 reemplaza todas las llamadas console.debug con una interfaz de logger inyectable para que los desarrolladores de aplicaciones puedan enrutar los diagnósticos del SDK a través de su propia infraestructura de logging. El lanzamiento elimina el polyfill de WebSocket, requiriendo Node.js 22 o superior para los consumidores del lado del servidor. v8.0.2 añadió una corrección para un bug de importación de crypto utils que rompía ciertos bundlers.

KeyChat v1.41.1 corrige el secreto hacia adelante

KeyChat, una app de mensajería que combina el protocolo Signal con transporte de relay Nostr, publicó v1.41.1+6513. La corrección destacada aplica el secreto hacia adelante eliminando las prekeys únicas de Signal inmediatamente después de un descifrado exitoso, cerrando una brecha donde una prekey retenida podía usarse para descifrar mensajes pasados si el dispositivo era comprometido posteriormente. El lanzamiento también añade vista previa de URL para mensajes que consisten en un único enlace, centraliza la descarga automática de medios bajo un nuevo FileDownloadManager con un umbral automático de 20 MB y refactoriza la obtención de info de relay NIP-11 para forzar el refresco en arranque en frío para que las configuraciones de tarifas de relays de pago siempre se carguen correctamente.

En desarrollo

Citrine fusionó PR #151 implementando la aplicación de NIP-70: el relay Android ahora bloquea los reposts que incrustan contenido de evento protegido, como requiere la especificación. PR #149 añade acciones de visualización y copia para múltiples direcciones de conexión, localhost, Wi-Fi local y Tor, desde la pantalla de configuración del relay. PR #141 añade manejo de desafío AUTH NIP-42 mediante integración con firmador externo con Amber.

Mostro alcanzó la Fase 2 del despliegue de su bono anti-abuso. PR #737 aterriza la lógica de recorte de disputas dirigida por el solucionador: los manejadores de admin ahora consumen la carga útil BondResolution de mostro-core, permitiendo a un admin recortar el bono de cualquiera de las partes al resolver una disputa. La Fase 1.5, fusionada en PR #736, introdujo una acción dedicada PayBondInvoice y un estado WaitingTakerBond, separando el pago del bono anti-abuso del tomador del pago del intercambio del comprador. El cliente móvil añadió la UX completa de la Fase 1.5 en PR #592. Mostro es un protocolo de intercambio de Bitcoin peer-to-peer construido sobre Nostr.

Damus fusionó PR #3773 restaurando el indicador de señal de relay, y PR #3775 corrige relays que rechazaban reconectar tras un fallo de conexión inicial.

rust-nostr fusionó PR #1358 añadiendo traits de finalización de eventos y builders de eventos específicos de NIP, facilitando la construcción de eventos con tipado correcto para funciones de protocolo específicas. PR #1363 backportea una corrección que asegura que el firmador NIP-46 se suscribe a notificaciones antes de enviar la respuesta de conexión, cerrando una condición de carrera donde los mensajes del cliente que llegaban inmediatamente después de connect podían perderse.

dart-nostr fusionó PR #44 añadiendo un resolvedor de relay Namecoin .bit y registros TLSA pin, permitiendo a las aplicaciones Flutter resolver URLs de relay wss://example.bit/ a través de DNS Namecoin a sus direcciones WebSocket reales.

Dart NDK (el kit de desarrollo Nostr para Dart/Flutter, ahora en relaystr/ndk) fusionó PR #464 implementando NIP-77, el protocolo de firma de eventos offline. En el lado del firmador, PR #602 y PR #601 añaden un firmador de eventos específico para web y una abstracción PlatformEventVerifier, permitiendo que las apps Flutter web usen el firmador de plataforma sin una ruta de código separada; PR #604 introduce una fábrica de firmadores de eventos para selección de firmador en tiempo de ejecución. PR #608 añade getDmRelays() para obtener la lista de relays de DM NIP-17 de un usuario (kind:10050), y PR #600 corrige la preservación de campos firmados NIP-46 para que los firmadores remotos no pierdan campos en el ida y vuelta.

Pages by Form* (repo), la app de documentos colaborativos nativa de Nostr de Formstr alojada en pages.formstr.app, fusionó cuatro PRs esta semana endureciendo los flujos de adjuntos cifrados y de gestión de documentos. PR #37 corrige imágenes faltantes en las exportaciones DOCX, HTML y PDF incrustando adjuntos cifrados: obtiene los blobs <encrypted-file> de los servidores Blossom, los descifra con AES-GCM 256-bit usando la clave y nonce almacenados, valida el tipo MIME de la imagen y los convierte a URLs de datos base64 para que las exportaciones preserven las imágenes que solo existen en Blossom en forma cifrada. PR #39 añade un mecanismo de búsqueda de documentos local, PR #38 limpia el flujo de renombrado y PR #40 corrige el manejo de copias de seguridad compartidas.

Zap Cooking fusionó PR #396, la primera fase de una revisión del feed que sienta las bases de las primitivas de renderizado de feed sin ningún cambio visible aún para el usuario. El PR introduce un analizador de tags imeta NIP-92 que lee los slots url, m (MIME), dim (dimensiones), blurhash, alt, x (hash de archivo) y fallback, más un decodificador de blurhash canónico portado a mano (~200 LOC) que produce URLs de datos PNG mediante canvas con un respaldo null seguro para SSR. Cuando los tags imeta están ausentes, el analizador recae en extraer URLs raw de imagen y vídeo del contenido del evento usando las mismas heurísticas que el feed actual ya usa.

Nurunuru (ぬるぬる, tami1A84/null--nostr), un cliente Nostr con variantes nativas Android, iOS y Web que comparten un motor Rust FFI, fusionó su sincronización v1.5.0 Native → Web en PR #176. La sincronización trae varias adiciones de características a la compilación Web que ya se publicaron en Android v1.4.9 e iOS 1.0.4: el NotificationModal ahora expone notificaciones de cumpleaños, detección de zaps de seguimiento mutuo y notificaciones de reacciones con emoji personalizado; el selector de reacciones descarta la fila rápida de reacciones Unicode por defecto y centra la UX en el emoji personalizado; el motor de recomendaciones en lib/recommendation.js filtra usuarios sin iconos o nombres de visualización y prioriza las entradas Following con Recommended cargándose en segundo plano. La entrada de voz es la única característica que va en la dirección opuesta: la compilación Web ya usa ElevenLabs Scribe streaming, y v1.5.0 sincroniza parcialmente el lado Native al SpeechRecognizer estándar del OS (Android) y SFSpeechRecognizer + AVAudioEngine (iOS) mientras la integración Native Scribe completa se difiere a v1.6.

Trabajo de protocolo y especificación

PR #2251 endurece la especificación de eventos protegidos NIP-70: ahora indica explícitamente que los reposts que incrustan el contenido completo de un evento protegido deben ser rechazados por los relays. NIP-70 define el tag - que señala que un autor de nota no consiente que su nota sea republicada. La especificación original cubría el comportamiento de filtrado del relay, pero dejaba el caso de repost ambiguo. Este PR cierra esa brecha. El PR #151 de Citrine implementa la aplicación en el lado del relay esta misma semana.

PR #1653 propone un NIP de Drafts para guardar y sincronizar eventos borradores privados. La propuesta usa eventos reemplazables con un estado draft y cifrado NIP-44 a la propia clave del autor, permitiendo a los clientes guardar trabajos en progreso en los relays sin que esos eventos sean visibles para nadie más. El evento borrador lleva el evento completo de publicación pretendida como contenido cifrado, incluidos su kind y tags eventuales.

Snapshots (PR #2279) es una propuesta abierta para definir un evento snapshot inmutable para preservar una versión exacta de un evento Nostr reemplazable. El evento snapshot lleva el contenido completo del evento reemplazable en un punto dado en el tiempo, con un tag a enlazándolo de vuelta a la dirección del evento reemplazable para que todas las versiones históricas sean consultables juntas. Esto hace posible que los observadores inspeccionen el estado histórico incluso después de que los relays dejen de retener versiones antiguas.

Ola de NIP-05 Namecoin: Esta semana vio un impulso coordinado para añadir resolución NIP-05 .bit a los clientes Nostr. El feed de discusión de NIPs capturó PRs de código abierto contra Aegis (#14, que añade verificación en tiempo de firma en el firmador), nostter (#2128) y dart-nostr (#44), junto con un borrador NIP upstream (PR #2349). El PR de Aegis es notable por colocar la verificación en el lado del productor: el firmador comprueba la cadena Namecoin antes de firmar cualquier evento kind:0 que reclame una identidad .bit y advierte al usuario ante discrepancias, atrapando el problema antes de que el evento llegue a ningún relay.

NIP Deep Dive: NIP-07 (window.nostr para navegadores web)

NIP-07 define la interfaz window.nostr que las extensiones de navegador exponen a las aplicaciones web. Es la interfaz de firmador más ampliamente desplegada en la web, implementada por extensiones como Alby, nos2x, Flamingo y horse.

La interfaz tiene dos métodos requeridos y varios opcionales. window.nostr.getPublicKey() devuelve la clave pública del usuario como una cadena hexadecimal sin exponer nunca la clave privada a la página que llama. window.nostr.signEvent(event) toma un evento parcial con created_at, kind, tags y content, y devuelve el evento firmado completo con id, pubkey y sig añadidos. El punto clave es que la clave privada nunca abandona el contexto aislado de la extensión; la aplicación web envía un evento no firmado y recibe uno firmado de vuelta.

Los métodos opcionales cubren el cifrado: window.nostr.nip04.encrypt y window.nostr.nip04.decrypt para el esquema NIP-04 más antiguo (ahora obsoleto), y window.nostr.nip44.encrypt y window.nostr.nip44.decrypt para el esquema NIP-44 actual. Las extensiones que soportan NIP-44 pueden por tanto manejar tanto el cifrado de mensajes directos como cualquier otra aplicación que necesite cifrado con clave por pubkey sin que la página que llama vea el nsec.

La especificación también incluye una recomendación para los autores de extensiones: cargar los scripts con "run_at": "document_end" en el manifiesto de la extensión para que window.nostr esté disponible síncronamente cuando la página carga, evitando condiciones de carrera donde un cliente comprueba window.nostr antes de que la extensión lo haya inyectado.

Un ejemplo clave de NIP-07 en acción es el proyecto Keycast cubierto arriba. El frontend web de Keycast usa NIP-07 para firmar eventos de autenticación HTTP NIP-98: la app SvelteKit nunca maneja el nsec del usuario directamente. Llama a window.nostr.signEvent para producir el encabezado de autenticación, luego envía ese encabezado a la API de Keycast. Esta arquitectura significa que el material clave permanece en la extensión del navegador durante todo el flujo de gestión de claves del equipo.

{
 "id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 1,
 "tags": [],
 "content": "Hello from a NIP-07 signed event",
 "sig": "0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2cdd"
}

NIP Deep Dive: NIP-39 (identidades externas en perfiles)

NIP-39 define cómo un usuario Nostr puede declarar control sobre identidades de plataformas externas en su perfil. Cada declaración usa un tag i dentro de un evento kind:10011, aseverando la propiedad de una cuenta específica en otra plataforma junto con una prueba que puede ser verificada independientemente.

Cada tag sigue el formato ["i", "platform:identity", "proof"], donde platform:identity combina el nombre de la plataforma y el nombre de usuario con un separador de dos puntos (github:semisol, twitter:semisol_public). proof apunta a un artefacto verificable en la propia plataforma.

Para GitHub, la prueba es un ID de Gist. El usuario crea un Gist público desde su cuenta de GitHub que contiene el texto Verifying that I control the following Nostr public key: npub1.... Un cliente verificando la reclamación obtiene https://gist.github.com/<identity>/<proof> y comprueba que el Gist fue creado por el nombre de usuario de GitHub reclamado y contiene la pubkey esperada. Para Twitter la prueba es un ID de tweet, para Mastodon un ID de post, y para Telegram una referencia de mensaje en un grupo público.

El nombre del proveedor de identidad debe contener solo a-z, 0-9 y los caracteres ._-/, y no debe contener :. Los nombres de identidad deben normalizarse a minúsculas, usando el alias principal cuando existen varios.

La discusión de NIP-05 Namecoin .bit que ocurre esta semana muestra el papel de NIP-39 en la pila de identidad más amplia: proporciona una forma estandarizada e independiente del relay para cruzar referencias de una clave Nostr con una identidad establecida en otro lugar, sin requerir ninguna autoridad central de verificación. Un cliente puede verificar independientemente la prueba obteniendo un artefacto público en la plataforma nombrada, y la prueba está vinculada a la pubkey Nostr específica en el texto del Gist o tweet, no a una credencial genérica de plataforma.

{
 "id": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 10011,
 "tags": [
 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
 ["i", "twitter:semisol_public", "1619358434134196225"],
 ["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"]
 ],
 "content": "",
 "sig": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3eff"
}

Eso es todo por esta semana. Si estás construyendo algo o tienes noticias que compartir, envíanos un DM en Nostr o encuéntranos en nostrcompass.org.

Nostr Compass #22

Wed, 13 May 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal al desarrollo del protocolo Nostr.

Esta semana: Nostr VPN lanza ocho versiones en siete días desde un flujo de emparejamiento de dispositivos rediseñado hasta un intercambio de AEAD FIPS que aproximadamente duplica el rendimiento TCP. Marmot Protocol (la base de White Noise) lanza una versión frontend que completa la función de bloqueo de usuarios y 31 PRs fusionados en MDK y backend. Grain lanza v0.6.0 con cuatro nuevas implementaciones de NIP en un hito. Citrine lanza v3.0.0-pre1 con Tor integrado y agregación de relay.

Historias principales

Nostr VPN lanza ocho versiones culminando en v4.0.10

Nostr VPN, la VPN de malla descentralizada basada en Rust que usa Nostr para el descubrimiento de pares y un protocolo noise respaldado por FIPS para el plano de datos, lanzó ocho versiones desde v4.0.1 hasta v4.0.10 en macOS, Linux, Windows y Android esta semana.

El cambio principal está en v4.0.8: el AEAD se intercambió del backend suave chacha20poly1305 de RustCrypto al ChaCha20-Poly1305 de BoringSSL en ring 0.17, que usa NEON ajustado a mano en aarch64 y AVX2/AVX-512 en x86_64. Los benchmarks de Docker en hardware idéntico mostraron que el rendimiento TCP directo de 2 nodos saltó de 437 a 1097 Mbps.

v4.0.9 añadió lotes sendmmsg(2) en la ruta de envío UDP, amortizando las llamadas al sistema sendto por paquete en lotes de 8 paquetes y empujando TCP de flujo único de 1066 a 1548 Mbps (1,45×). v4.0.10 lanzó una revisión completa de UX para el emparejamiento de dispositivos.

Marmot / White Noise lanza frontend con bloqueo completo y 31 PRs fusionados en MDK y backend

White Noise, la app de mensajería grupal privada construida sobre el protocolo Marmot basado en MLS, lanzó v2026.5.7+24 el 7 de mayo como la versión frontend que completa el conjunto de funciones de bloqueo. Un usuario bloqueado ahora está oculto de invitaciones, vistas previas de chat, líneas de tiempo de mensajes, resultados de búsqueda y notificaciones, y sus mensajes ya no cuentan para las insignias de no leídos.

El trabajo de soporte abarca 31 PRs fusionados en MDK y el backend. MDK aportó PR #258 con el formato de cable de extensión v3 y el esquema disappearing_message_secs, sentando las bases para los mensajes que desaparecen.

Grain v0.6.0 añade NIP-40, NIP-50, NIP-70 y NIP-45

Grain, la biblioteca relay y cliente Nostr basada en Go, lanzó v0.6.0 el 6 de mayo con cuatro nuevas implementaciones de NIP y un pase de endurecimiento de producción. El hito v0.6 añade expiración de eventos NIP-40, búsqueda de texto completo NIP-50, eventos protegidos NIP-70 y conteos de eventos NIP-45.

Lanzamientos de esta semana

Citrine v3.0.0-pre1 trae Tor integrado y agregación de relay

Citrine, la app Android que convierte un teléfono en un nodo relay Nostr, lanzó v3.0.0-pre1 como pre-lanzamiento esta semana. Las adiciones principales son soporte Tor integrado para acceso a relay que preserva la privacidad y agregación de relay, donde Citrine puede obtener eventos de múltiples relays upstream y servirlos a clientes locales. PR #139 añade soporte NIP-77 (Reconciliación Negentropy) para sincronización eficiente de eventos basada en reconciliación de conjuntos.

Amber v6.1.0-pre2 mejora el flujo de conexión de nueva app

Amber, la app firmadora Android para NIP-55 (Aplicación firmadora Android) y NIP-46, lanzó v6.1.0-pre2. Las correcciones principales: el diálogo del firmador ahora se cierra correctamente después de aceptar una solicitud de bunker, las solicitudes de bunker malformadas muestran una pantalla de solicitud inválida y se añade limitación de tasa para solicitudes de firma basadas en intención.

Alby Hub v1.22.2 añade página de IA y Agentes y soporte de Core Lightning

Alby Hub, el nodo Lightning autocustodio y servidor Nostr Wallet Connect, lanzó v1.22.2 con varias adiciones importantes. La nueva página de IA y Agentes expone las capacidades Lightning y NWC de Alby Hub a agentes de IA y herramientas compatibles con MCP. La función más solicitada desde el lanzamiento: Core Lightning (CLN) ahora es un backend compatible junto con LND y LDK.

Mostro lanza bonos de tomador concurrentes y mostro-core v0.11.0

Mostro, el protocolo de intercambio Bitcoin peer-to-peer en Nostr, fusionó 11 PRs esta semana avanzando la función de bono de tomador que previene el griefing al requerir que ambas partes bloqueen fondos antes de que proceda un intercambio. PR #733 implementa bonos de tomador concurrentes donde múltiples tomadores pueden enviar facturas de bono simultáneamente y el primero en bloquear gana.

mostro-core lanzó v0.11.0 con las adiciones de biblioteca correspondientes, y mostro-cli lanzó v0.15.0.

Jumble lanza cinco versiones con búsqueda reciente y persistencia de cuenta

Jumble, el cliente Nostr centrado en relay disponible como app web y app de escritorio Electron, lanzó cinco versiones esta semana: v26.5.2 a v26.5.6. v26.5.5 añade historial de búsquedas recientes. Se corrigió un bug crítico de persistencia en v26.5.6: las cuentas y los datos en caché ahora sobreviven a un reinicio completo de la app.

Nostrord lanza modales de compartir grupo, carga de medios y paquetes de Arch Linux

Nostrord, un cliente Nostr dirigido a grupos basados en relay NIP-29, lanzó v1.0.0, v1.0.1 y v1.0.2 esta semana. v1.0.1 lanza paquetes de Arch Linux via AUR como nostrord-bin, y v1.0.2 añade compartir grupos via PR #49 con un modal de compartir que genera tanto un URI nostr:naddr como un enlace nostrord.com/open/ amigable para la web.

FIPS v0.3.0 lanza alcance multiplataforma, descubrimiento de pares Nostr y un gateway para LANs sin modificar

FIPS (Free Internetworking Peering System), el proyecto de red de malla nativo de Nostr, lanzó v0.3.0 esta semana, un hito importante que amplía el proyecto de solo Linux a Linux, macOS, Windows y OpenWrt. La adición principal es el descubrimiento de pares mediado por Nostr con traversal NAT UDP asistido por STUN.

Flotilla 1.8.0 lanza videollamadas, renderizado de email y menciones de sala

Flotilla, la app de chat grupal NIP-29 basada en relay de hodlbod, lanzó 1.8.0 esta semana con varias adiciones notables. Las salas de voz ahora soportan video: los participantes pueden encender cámaras o compartir su pantalla durante una llamada. El renderizado de email llega a través de una actualización a la biblioteca welshman: Flotilla ahora puede recibir mensajes que incrustan contenido de email HTML y lo renderiza en línea.

Calendar by Formstr lanza v1.5.1 con programación de citas y sincronización de calendario Android

Calendar by Formstr, una app de calendario nativa de Nostr, lanzó v1.5.0 el 10 de mayo y v1.5.1 el 11 de mayo. La programación de citas llega en PR #89, permitiendo a los usuarios crear franjas horarias reservables en su calendario. La integración de calendario Android de solo lectura en PR #123 sincroniza eventos Nostr al calendario del dispositivo.

Nuevos proyectos

Tamagostrich lanza un Tamagotchi NIP-78 descentralizado con recompensas en sats

Tamagostrich es un juego de mascota virtual basado en navegador lanzado en el Hackathon IDENTITY 2026 donde un avestruz bebé, Nori, evoluciona a través de tu actividad social en Nostr. El estado de la mascota vive en un evento NIP-78 kind:30078 para que se sincronice en cada dispositivo que comparte el mismo par de claves. Las recompensas de hito pagan automáticamente en sats via NIP-47 (Nostr Wallet Connect): 50 sats en el nivel 5, 210 sats en el nivel 10 y 420 sats en el nivel máximo 21.

Trabajo de protocolo y especificaciones

El repositorio de NIPs fusionó PR #2338 corrigiendo los enlaces de referencia del README para los kinds de eventos Marmot y el kind de geocaching 37516. Se abrieron cinco nuevas propuestas esta semana:

PR #2331 propone NIP-9A: Reglas de Comunidad Verificables, introduciendo kind:34551, un evento reemplazable parametrizado que permite al propietario de una comunidad publicar un documento de reglas legible por máquina y firmado criptográficamente.

PR #2335 propone Eventos de Reserva para Mercados Nostr, definiendo kind:32122 (eventos de reserva reemplazables parametrizados), kind:1326 (registros de auditoría de transición de solo adición) y kind:32124 (reseñas post-intercambio).

PR #2334 propone Servicios de Custodia para Mercados Nostr, usando kind:30303 para que los operadores de custodia declaren su dirección de contrato EVM y programa de tarifas.

PR #2333 propone Perfiles de Listado de Alojamiento para Listados del Mercado NIP-99, extendiendo los listados clasificados NIP-99 con tags de índice geoespacial H3 g.

PR #2332 propone NIP-BC: Zaps Onchain (kind 8333), explotando una identidad directa entre las claves Nostr y las direcciones Bitcoin Taproot.

Inmersión profunda en NIP: NIP-78 (datos específicos de la app)

NIP-78 define una forma estándar para que las aplicaciones almacenen datos privados o públicos arbitrarios en nombre de un usuario usando eventos Nostr. El kind de evento central es 30078, un evento reemplazable parametrizado donde el tag d es una cadena de identificador definida por la aplicación.

{
 "id": "<64-char hex>",
 "pubkey": "<64-char hex>",
 "created_at": 1747180800,
 "kind": 30078,
 "tags": [
 ["d", "tamagostrich-pet-state"]
 ],
 "content": "{\"level\":7,\"xp\":1420,\"happiness\":82,\"energy\":61}",
 "sig": "<128-char hex>"
}

La motivación principal es la sincronización entre dispositivos sin un servidor centralizado. Para datos de aplicación privados, los eventos NIP-78 pueden cifrar el campo de contenido usando NIP-44 (Cifrado con Versión) o el más antiguo NIP-04 antes de publicar.

Fuentes primarias:

Especificación NIP-78
Tamagostrich: implementación en producción esta semana

Ver también:

Inmersión profunda en NIP: NIP-98 (HTTP Auth)

NIP-98 define un esquema de autenticación HTTP que permite que los pares de claves Nostr autoricen solicitudes a servidores HTTP, eliminando la necesidad de nombres de usuario, contraseñas o tokens OAuth para el acceso a API del lado del servidor. Un cliente construye un evento Nostr de corta duración de kind 27235, lo firma con su clave privada, codifica el JSON en base64 y lo envía en un encabezado HTTP Authorization: Nostr <base64>.

{
 "id": "<64-char hex>",
 "pubkey": "<64-char hex>",
 "created_at": 1747180800,
 "kind": 27235,
 "tags": [
 ["u", "https://files.example.com/upload"],
 ["method", "POST"],
 ["payload", "<sha256-hash-of-request-body>"]
 ],
 "content": "",
 "sig": "<128-char hex>"
}

El evento kind 27235 incluye el método HTTP en un tag method, la URL completa de la solicitud en un tag u y una marca de tiempo created_at. El servidor valida la firma, verifica que el método y la URL coincidan con la solicitud real y confirma que la marca de tiempo es reciente para prevenir ataques de repetición.

NIP-98 se usa en Blossom (BUD-01) para autenticar cargas y descargas de blobs. Routstr lo usa para control de acceso a la API HTTP por solicitud. Sprout lo usa para autenticación de transporte git y acceso a relay REST.

Fuentes primarias:

Ver también:

NIP-96: Integración de Almacenamiento de Archivos HTTP

Eso es todo por esta semana. Si estás construyendo algo o tienes noticias que compartir, envíanos un DM en Nostr o encuéntranos en nostrcompass.org.

Nostr Compass #21

Wed, 06 May 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Marmot Protocol lanza MDK 0.8.0 con las primeras primitivas de notificación MIP-05, paquetes de claves NIP-51 (Listas) direccionables y una revisión de seguridad mejorada. LaWallet NWC lanza v0.10.0 como el mayor lanzamiento desde la financiación de OpenSats. Amethyst realiza un sprint de estabilidad de Nests. ngit lanza v2.4.2 y v2.4.3. GRAIN lanza v0.5.4. Mostro Core lanza v0.10.1. Clave lanza v0.2.0.

Historias principales

MDK 0.8.0 añade primitivas de notificación MIP-05 y paquetes de claves direccionables

MDK, la biblioteca principal en Rust para el protocolo Marmot, lanzó v0.8.0 el 4 de mayo. Esta versión incluye los primeros bloques de construcción de notificaciones MIP-05, mueve los paquetes de claves MIP-00 a eventos direccionables para que el paquete de claves de un usuario pueda reemplazarse en su lugar, mejora la compatibilidad de grupo de versiones mixtas, amplía la cobertura UniFFI para bindings móviles y refuerza las rutas de validación. Las primitivas MIP-05 incluyen auxiliares de índice de hoja añadidos en PR #235, que dan a los clientes posteriores suficiente información para entregar notificaciones push por destinatario sin exponer la estructura del grupo. PR #273 restaura la publicación de mdk-core en crates.io, y PR #269 expone el módulo test_util detrás de una característica Cargo test-utils.

LaWallet NWC v0.10.0 lanza el monorepo completo y Wallet para usuarios finales

LaWallet NWC, la implementación NIP-47 Nostr Wallet Connect del equipo de LaWallet, lanzó v0.10.0 el 30 de abril. Es el mayor lanzamiento desde que el proyecto recibió financiación de OpenSats. Incluye el monorepo completo, el panel de administración completo, una Wallet para usuarios finales, un registro de actividad completo, branding dinámico y el nuevo esquema LightningAddress 1→N y NWCConnection que desbloquea el enrutamiento NWC por dirección. La Wallet para el usuario lanzada en PR #191 cubre incorporación, inicio, envío/recepción, escaneo, monedas, un feed de actividad y una caché sin conexión.

Amethyst estabiliza Nests con keep-alive, resiliencia JWT y suscripciones de ciclo de vida

Amethyst, el cliente Android con muchas funciones, continuó el trabajo de sala de audio NIP-53 Nests cubierto en el boletín #20 con un sprint de estabilidad. La corrección de brecha de audio en PR #2733 superpone la nueva adquisición de credenciales con el flujo activo durante el refresco JWT, para que el oyente no escuche un corte cuando rota el token. Un nuevo mecanismo keep-alive en PR #2730 reconecta relays desconectados sin requerir acción manual del usuario, y PR #2728 reemplaza el KeyDataSourceSubscription heredado con LifecycleAwareKeyDataSourceSubscription. PR #2724 añade un indicador de anillo exterior animado que resalta al participante que habla en sesiones con múltiples hablantes.

ngit v2.4.2 y v2.4.3 corrigen detección del servidor GRASP y eventos de estado multi-remoto

ngit, la herramienta de línea de comandos y plugin git para la colaboración NIP-34, lanzó v2.4.2 el 28 de abril y v2.4.3 el 1 de mayo. v2.4.2 corrige un desajuste de normalización de URL donde repo_grasps mantenía nombres de host normalizados pero la comparación se hacía contra URLs de clonación completas. v2.4.3 corrige una ambigüedad de evento de estado que surgía cuando un repositorio tiene múltiples remotos nostr:// compartiendo el mismo identificador.

GRAIN v0.5.4 trae endurecimiento de producción y una corrección silenciosa de pérdida de datos

GRAIN, la biblioteca relay y cliente Nostr basada en Go, lanzó v0.5.4 el 30 de abril. La versión acumula seis correcciones desde v0.5.3, incluyendo un bug silencioso de pérdida de datos en el inicio rápido de Docker que anteriormente descartaba eventos cuando el contenedor se reiniciaba, y un bug de corrección de la capa de almacenamiento en lecturas de eventos direccionables.

Mostro Core v0.10.1 añade artefactos de lanzamiento firmados con PGP

Mostro Core, la biblioteca Rust que proporciona funcionalidad peer-to-peer para el daemon Mostro, lanzó v0.10.1 el 28 de abril como seguimiento del módulo de protocolo de chat P2P v0.10.0 de la semana pasada. La nueva versión añade artefactos de lanzamiento firmados con PGP y un flujo verify-release.

Lanzamientos etiquetados

Clave v0.2.0 lanza multi-cuenta en iOS con firma NIP-46 (Nostr Connect)

Clave, la app de firma remota NIP-46 para iOS cubierta en #20, lanzó v0.2.0 el 5 de mayo. La mayor actualización hasta ahora introduce soporte multi-cuenta: Clave ahora puede albergar hasta cuatro cuentas en un dispositivo, con un selector de un toque y aislamiento por cuenta.

Wisp lanza trabajo de estabilidad v1.0.3 → v1.0.5

Wisp, el cliente Android que se graduó de beta en #20, lanzó v1.0.3, v1.0.4 y v1.0.5 el 4 de mayo con trabajo de estabilidad.

Amber 6.1.0-pre1 lanza correcciones de diseño y estabilidad

Amber, la app firmadora Android para NIP-55 (Aplicación firmadora Android) y NIP-46, lanzó v6.1.0-pre1 con un pase de diseño en el flujo de conexión de nueva app y varias correcciones de fallos reportados.

Routstr Core v0.4.3 mejora el manejo de pagos, reembolsos y reportes de uso

Routstr Core, la capa de inferencia descentralizada, lanzó v0.4.3 como pre-lanzamiento el 1 de mayo.

Nostria v3.1.37 a v3.1.41 añaden Marcadores Web y un tema Auto

Nostria, el cliente Nostr multiplataforma, lanzó v3.1.37 a v3.1.41 el 30 de abril y el 4 de mayo. Las versiones añaden soporte NIP-B0 (Marcadores Web), un tema “Auto” que sigue la configuración del dispositivo y visualización de PDF en la app.

Cambios no publicados

Sprout lanza Desktop v0.0.4 y v0.0.5 junto con autenticación de agente NIP-OA y el sidecar relay de emparejamiento

Sprout, el cliente Nostr de Block con relay integrado, lanzó Sprout Desktop v0.0.4 el 5 de mayo y v0.0.5 el 6 de mayo, junto con aproximadamente 80 PRs fusionados. El cambio principal en PR #471 conecta la autenticación de agente NIP-OA al flujo de membresía NIP-43 del relay. Un nuevo relay sidecar efímero para emparejamiento de dispositivos NIP-AB llega en PR #467 como sprout-pair-relay.

nostream añade soporte de relay Marmot y reacciones NIP-25

nostream, la implementación de relay Node.js, fusionó una semana productiva de adiciones de protocolo. El soporte de relay Marmot Protocol que cubre los MIPs 00 al 03 llega en PR #602. Las adiciones de protocolo menores: soporte de reacciones NIP-25 en PR #589.

strfry añade observabilidad por conexión y reduce el límite nofiles

strfry, el relay Nostr en C++, fusionó 14 PRs orientados a la observabilidad e higiene operativa. El cambio principal es PR #218, que añade observabilidad de salida pendiente por conexión y un límite de contrapresión configurable.

Damus reemplaza los GIFs de Tenor con un proxy Purple y lanza UX de compactación

Damus, el cliente iOS de Nostr, fusionó PR #3737 reemplazando la integración de GIFs Tenor con un proxy Damus Purple.

routstrd-auth: un Routstrd dockerizado para equipos con auth NIP-98 y RBAC por npub

routstrd-auth, creado el 27 de abril por el equipo de Routstr, es una variante dockerizada de Routstrd para implementaciones en equipos multiusuario. El cambio principal es un sistema granular de control de acceso basado en roles por npub con roles admin y user, y endpoints de cliente que adoptan autenticación HTTP NIP-98.

Routstrd integra Hermes para clientes daemon y modo remoto

Routstrd, el daemon local que orquesta clientes de inferencia Routstr, fusionó PR #22 añadiendo integración con Hermes Agent.

whitenoise-rs lanza aislamiento de base de datos por cuenta y actualizaciones de propuestas

whitenoise-rs, la biblioteca Rust principal para el mensajero White Noise, fusionó PR #796 moviendo tablas de proyección de mensajes a bases de datos por cuenta, y PR #791 añadiendo actualizaciones de propuestas para que los grupos puedan extender su funcionalidad.

Angor 0.2.21 lanza flujos de app compactos junto con endurecimiento del proveedor de claves y cambio de red

Angor, la plataforma de crowdfunding Bitcoin con perfiles de fundadores publicados en Nostr, lanzó Angor 0.2.21 el 6 de mayo.

Recién rastreados y descubiertos

BitMacro Signer: un bunker NIP-46 autoalojable con cifrado de claves del lado del cliente

BitMacro Signer es una herramienta de firma Nostr autoalojable que gestiona claves privadas usando el modelo de bunker NIP-46. El firmador cifra las claves en el cliente antes del almacenamiento para que el lado del servidor nunca tenga texto en claro.

El descubrimiento de repos NIP-34 de esta semana trajo 26 nuevos anuncios de repositorio, de los cuales cuatro destacan.

gnostr: una implementación de git construida directamente sobre Nostr

gnostr es una implementación de git construida directamente sobre Nostr, distinta de git-remote-nostr en que incluye sus propios comandos de árbol de trabajo como cliente de control de versiones nativo de Nostr desde cero.

nostr-archive: una especificación de archivo con contenido direccionado en Nostr y Blossom

nostr-archive es una especificación borrador e implementación de referencia para archivos con contenido direccionado en Nostr y Blossom.

flower-cache: un servidor de caché local de Blossom

flower-cache es un servidor de caché local de Blossom, útil para clientes que quieren un espejo local activo del conjunto de blobs de un servidor Blossom remoto.

micro-vpn-ansible: playbooks de Ansible para despliegue de VPN sobre NIP-34

micro-vpn-ansible es una pequeña colección de playbooks de Ansible para desplegar una micro VPN, alojada como repositorio NIP-34.

Trabajo de protocolo

Actualizaciones de NIP

Un mercado de hashrate sin intermediarios sobre Nostr (borrador de propuesta): Borrador de NIP anónimo que argumenta que los actores actuales del mercado de hashrate son todos intermediarios con custodia que someten a los usuarios a KYC. La propuesta esboza un mercado peer-to-peer de hashrate sobre eventos Nostr.
Feeds curados: una alternativa más simple a los feeds DVM (borrador de propuesta): Un borrador argumenta que las Máquinas de Vending de Datos NIP-90 fueron diseñadas como un mercado de cómputo de propósito general, y el modelo de solicitud/respuesta es más pesado de lo necesario cuando un cliente solo quiere una lista direccionable de IDs de eventos.
Colores de perfil: identidad visual determinista (borrador de propuesta): Un nuevo borrador de NIP para derivar colores deterministas y legibles de un pubkey de Nostr para identidad visual consistente entre clientes.
NIPs de seguimiento Namecoin: anclar identidad, relays, TLS y reputación (clúster de borradores): Un clúster separable de borradores de NIP que mueven partes del stack de Nostr existente a registros anclados en Namecoin.

Inmersión profunda en NIP: NIP-34 (git stuff)

NIP-34 define kinds de eventos para alojar repositorios git, parches, pull requests, issues y estado de fusión en relays Nostr. Es el estándar que convierte Nostr en una capa de coordinación para la colaboración de código.

Un repositorio se anuncia como un evento direccionable kind 30617 cuyo tag d es un identificador en kebab-case. Los parches usan kind 1617 y llevan la salida de git format-patch en el cuerpo del contenido. Los pull requests usan kind 1618. Los issues usan kind 1621 con contenido markdown. Los eventos de estado mueven un hilo entre Abierto (1630), Aplicado/Fusionado o Resuelto (1631), Cerrado (1632) y Borrador (1633).

Inmersión profunda en NIP: NIP-53 (Actividades en Vivo)

NIP-53 define la superficie estándar de eventos para actividades en vivo en Nostr: transmisiones en vivo, espacios de reunión persistentes, eventos de conferencia programados, presencia de oyentes y el canal de chat en vivo que vincula los mensajes de chat a un registro de actividad en vivo específico.

Una transmisión en vivo se anuncia como un evento direccionable kind 30311. NIP-53 separa el espacio persistente del evento programado que se celebra en su interior. Un kind 30312 Meeting Space define una sala, y un kind 30313 Conference Event representa una reunión programada o en curso en esa sala.

La superficie de actividades en vivo de Nostr es intencionalmente delgada: NIP-53 anuncia la actividad, mientras otros NIPs manejan preocupaciones adyacentes. Los zaps a transmisiones en vivo usan recibos de zap NIP-57 (Zaps), los objetivos de recaudación de fondos usan metas de zap NIP-75 (Metas de Zap), y las grabaciones de video pueden republicarse como eventos de video NIP-71 (Eventos de Video).

Eso es todo por esta semana. Si estás construyendo algo o tienes noticias que compartir, envíanos un DM en Nostr o encuéntranos en nostrcompass.org.

Nostr Compass #20

Wed, 29 Apr 2026 00:00:00 +0000

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

Esta semana: GitWorkshop convierte git-sobre-Nostr en una superficie de revisión de código más completa con un botón para fusionar PR en el navegador, favoritos y seguimiento de repositorios, un explorador de git eficiente en ancho de banda, comentarios de revisión en línea con kind 1111 y estado de notificaciones cifrado multi-dispositivo. Routstrd lanza un demonio local que descubre proveedores de modelos mediante anuncios Nostr de kind 38421 y les paga con Cashu. Los lanzamientos etiquetados incluyen ngit v2.4.2, Wisp v1.0.0, grain v0.5.2 y v0.5.3, Mostro Core v0.10.0 y Mostro Mobile v1.2.5, marmot-ts v0.5.0, CruxCoach v0.1.3, Meiso v1.3.0, NoorNote, Nostria, Nostr Calendar, nos2x-fox, applesauce, nostr-double-ratchet y más. Los cambios aún no publicados cubren Amethyst Nests, nostream NIP-65 y NWC, FIPS con bootstrap udp:nat basado en Nostr, observabilidad de strfry, atestaciones de propietario en Sprout y paquetes de recetas en Zap Cooking. Los proyectos recién rastreados incluyen Nostrord, Clave, Treasures, smesh, Surveil, Fundstr, Nod City, deploy-nsite-to-pages y null–nostr. La retrospectiva de fin de mes cubre los abriles de Nostr desde 2021 hasta 2026.

Historias principales

GitWorkshop lanza fusión de PR en el navegador, seguimiento de repositorios y un explorador de git eficiente en ancho de banda

GitWorkshop, la capa de colaboración web de Dan Conway para NIP-34 git-sobre-Nostr, publicó esta semana un lanzamiento importante que acerca el flujo de trabajo mucho más a lo que los desarrolladores esperan de GitHub o GitLab, manteniendo comentarios, listas de repositorios y notificaciones dentro de eventos Nostr firmados.

La incorporación destacada es un botón largamente esperado para fusionar PR en el navegador para repositorios que usan servidores GRASP. El lanzamiento también añade favoritos y seguimiento de repositorios basados en reacciones y listas de NIP-51, con conjuntos de repositorios fijados publicados como eventos kind 10617 que apuntan a anuncios de repositorio kind 30617 mediante tags a ordenados. Las páginas de perfil ahora pueden mostrar una lista portátil de repositorios.

Un explorador de git eficiente en ancho de banda reemplaza al anterior clonado superficial en el navegador. El nuevo explorador se apoya en el protocolo cliente/servidor de git subyacente sobre el que se construye GRASP, por lo que puede manejar repositorios grandes sin forzar al navegador a descargar un pack completo. La búsqueda ahora cubre nombres de usuario y metadatos de repositorio, impulsada por NIP-50 y una implementación de relay ngit-indexer que descubre y sincroniza anuncios de repositorio en toda la red. Un flujo de creación de repositorios en el navegador completa la ruta de descubrimiento e incorporación.

Las herramientas de revisión están reconstruidas alrededor de una pestaña Files Changed, un visor de diff por parche y un conjunto de nuevas primitivas experimentales. Los comentarios de revisión de código en línea usan kind 1111, construido sobre NIP-22: cada comentario apunta a una ruta de archivo (tag f), un SHA de commit (tag c) y un rango de líneas seleccionado (tag line) para que un cliente pueda renderizar el comentario en la posición correcta dentro del diff. Un segundo nivel de primitivas experimentales queda con permisos del autor y de los mantenedores del repositorio y usa etiquetas NIP-32: renombrar el asunto de un Issue o PR después de enviarlo, añadir hashtags posteriormente, fijar un CoverNote versionado en la parte superior de un PR o Issue como resumen editable y marcar subhilos de discusión de código en línea como resueltos. Los eventos de veredicto y los bloques suggestion siguen en borrador y aún no se han lanzado.

El estado de notificaciones entre dispositivos también se sincroniza mediante Nostr, pero con un giro que preserva la privacidad. GitWorkshop genera un par de claves dedicado para notificaciones, cifra ese nsec y lo almacena dentro de un evento kind 30078. El nsec de notificaciones firma después los eventos reales de estado de notificaciones. La indirección evita que el firmador principal del usuario sea saturado con solicitudes frecuentes de cifrado y descifrado para cada acción de lectura o archivado, e impide que observadores externos vean fácilmente cuándo un usuario toca su estado de notificaciones. Un usuario puede sincronizar el estado de lectura y archivado entre dispositivos; los relays solo ven blobs cifrados.

Routstrd lanza un enrutador local para inferencia sobre Nostr

Routstrd es un nuevo demonio en TypeScript que proporciona a las herramientas locales un endpoint compatible con OpenAI y enruta cada solicitud a un proveedor competidor de Routstr. El demonio descubre proveedores a través de anuncios Nostr de kind 38421 definidos en la especificación RIP-02 de Routstr. Después puntúa a los proveedores por precio, confianza y rendimiento reciente bajo RIP-06 y envía cada solicitud a la mejor opción del momento.

El pago se realiza mediante una wallet local de Cashu gestionada por cocod y financiada con Lightning. Esto proporciona al cliente una ruta de liquidación denominada en sats manteniendo el descubrimiento de proveedores público y sin permisos a través de relays Nostr. Si un proveedor falla durante una sesión, Routstrd puede recurrir al siguiente nodo mejor clasificado. La ruta de instalación es bun install -g routstrd, seguida de routstrd onboard para la configuración de la wallet y los relays.

La organización Routstr más amplia mantiene el demonio, el software del nodo en Python (routstr-core), una interfaz de chat y las especificaciones del protocolo. Para los usuarios, el puerto local se convierte en la interfaz estable: las herramientas existentes compatibles con OpenAI apuntan a Routstrd, mientras el demonio maneja el descubrimiento de proveedores, el enrutado y el pago.

Lanzamientos etiquetados

ngit v2.4.2 corrige la detección de servidores GRASP para envíos de PR

ngit publicó v2.4.2 con una corrección para la detección de servidores GRASP de repositorio, manteniendo el envío de PR en el camino feliz cuando una propuesta usa el kind PR. Cabe señalar que ngit actualmente utiliza por defecto el kind Patch para la mayoría de los cambios a menos que sean grandes; el mantenedor está trabajando para cambiar ese valor por defecto. v2.4.1, publicada anteriormente en la semana, corrigió errores fatal durante clone y fetch cuando los datos git de un PR abierto no estaban disponibles en los servidores git especificados por el repositorio.

Wisp v1.0.0 se gradúa de beta

Wisp, un cliente Android en Kotlin y Jetpack Compose centrado en enrutado de relays, privacidad y una interfaz nativa pequeña, publicó v1.0.0 y a continuación v1.0.2. El hito 1.0.0 reúne el interruptor de denominación fiat de Normie Mode, el feed For You, la configuración de grupos basados en relays de NIP-29 y la difusión de listas de relays NIP-65 cubierta en Newsletter #19. v1.0.2 añade soporte para páginas de 16 KB de Android 15, una pestaña de escaneo de QR en el cajón lateral, un botón de descarga para los controles de vídeo en línea y correcciones de rendimiento en la lista de notificaciones.

grain v0.5.2 corrige el bloqueo de WebSocket, v0.5.3 continúa el pulido

grain, el relay en Go de 0ceanSlim, publicó v0.5.2 como un hotfix crítico para un bloqueo de WebSocket introducido en v0.5.0, seguido de v0.5.3. El bloqueo hacía que las conexiones se colgaran bajo ciertos filtros y rutas de WebSocket, por lo que los operadores en v0.5.1 o v0.5.0 deberían actualizar. grain rastrea todas las categorías principales de eventos Nostr, expone información de relay NIP-11, admite control de acceso por lista blanca/negra, límites de tasa por kind, un panel web y una biblioteca cliente Go añadida en la línea v0.5.x.

Mostro Core v0.10.0 y Mostro Mobile v1.2.5 adoptan NIP-59 gift wrap con doble clave

Mostro Core v0.10.0 añade el nuevo módulo gift-wrap de NIP-59 con identidad y claves de intercambio separadas. El código de transporte anterior utilizaba una única clave de identidad tanto para la identidad de intercambio como para el gift wrapping. v0.10.0 separa la identidad de intercambio estable de la clave de envoltura efímera, para que cada intercambio pueda usar una clave de transporte fresca mientras se preserva la identidad necesaria para el protocolo de intercambio. La integración con el demonio llega mediante Mostro PR #718, y mostro-cli PR #165 lleva la misma migración al cliente de línea de comandos.

Mostro Mobile v1.2.5 se publica junto con el trabajo del protocolo. PR #581 permite a los tomadores filtrar ofertas por la antigüedad de la cuenta del creador, dando a los usuarios una forma de evitar cuentas de creadores recién creadas en el libro de órdenes. PR #580 corrige las etiquetas de rol en los detalles de las órdenes canceladas, y PR #576 limpia los botones de cancelación cooperativa.

marmot-ts v0.5.0 estrena KeyPackages direccionables

marmot-ts publicó @internet-privacy/marmot-ts@0.5.0, el primer lanzamiento con cambios rupturistas planeado para el cliente TypeScript de Marmot. PR #68 añade soporte para KeyPackage direccionables: KeyPackageManager ahora puede manejar tanto los eventos KeyPackage heredados kind 443 como los nuevos kind 30443. El lanzamiento elimina KeyPackageStore y las clases de almacenamiento del estado de grupo, reemplazándolas con almacenes clave-valor genéricos que se pasan a KeyPackageManager y MarmotGroup. También traslada la gestión de invitaciones y grupos a MarmotClient.invites y MarmotClient.groups, por lo que quienes lo integran directamente necesitan cambios en el constructor y en el almacenamiento antes de actualizar.

CruxCoach v0.1.3 estrena copia de seguridad cifrada de datos de escalada con Nostr y Blossom

CruxCoach es una nueva aplicación Android de código abierto para escaladores en Kilter Board. La Kilter Board es un muro de entrenamiento interactivo cuyos agarres se iluminan por Bluetooth para mostrar rutas. La app se lanzó el 14 de abril y alcanzó v0.1.3 el 26 de abril.

v0.1.3 añade copia de seguridad opcional cifrada en la nube. La cuenta CruxCoach de un usuario es un par de claves Nostr, y la clave privada también funciona como entrada para la clave de cifrado de la copia local. La app cifra los datos de escalada en el dispositivo y refleja el texto cifrado en servidores de almacenamiento Blossom (blossom.primal.net y nostr.download). Las acciones de borrado remoto llaman a la ruta de limpieza de Blossom. Más allá de la copia de seguridad, CruxCoach usa firma remota NIP-46 para soporte de Amber, DMs privados NIP-17 para el contacto con el desarrollador dentro de la app, listas de relays NIP-65 para descubrimiento de relays y la biblioteca Quartz de Vitor Pamplona para la plomería Nostr. Los usuarios pueden instalarla a través de Zapstore o APKs directos de Codeberg.

Meiso v1.3.0 añade subtareas, adjuntos Blossom y etiquetado NIP-89

Meiso es un gestor de tareas minimalista en Flutter para Android que almacena tareas como datos de aplicación kind 30078 cifrados con NIP-44 en relays Nostr. v1.3.0, publicada el 6 de abril, añade subtareas con relaciones padre/hijo, enlaces entre tareas para bloqueadas/bloqueadas-por/relacionadas-con/duplicada-de, adjuntos de imagen a través de endpoints de subida HTTP Blossom y NIP-96, un tag client de aplicación recomendada NIP-89 en los eventos publicados y una herramienta de sincronización de línea de comandos en Go. v1.3.0 también corrige el comportamiento de los relays en el arranque en frío y la reutilización del cliente Amber.

NoorNote, Nostria, Nostr Calendar, nos2x-fox y lanzamientos de bibliotecas

NoorNote publicó v0.8.7, v0.8.8 y v0.8.9. Esos lanzamientos corrigen el manejo de clics en imágenes y vídeos en reposts citados, añaden soporte de lightbox para imágenes en artículos de formato largo y corrigen la pantalla de inicio en blanco en escritorio. Nostria publicó v3.1.29, v3.1.30 y v3.1.31, añadiendo compresión de imágenes en el editor de artículos, un interruptor USD para la wallet, controles de tarjetas promocionales, soporte PDF y pulido del diseño móvil.

Nostr Calendar v1.4.1 desacopla la publicación de eventos de calendario de la gestión de listas de calendarios y corrige el seguimiento de invitaciones. nos2x-fox v1.19.0 añade marcos temporales de autorización personalizados para las concesiones de firma de navegador NIP-07 en Firefox. nostr-double-ratchet v0.0.97 publica nuevos binarios. nostr-wot-sdk 0.9.0 monta NostrSessionProvider por defecto, y nostr-tools PR #535 añade soporte de análisis multi-relay para cadenas wallet-connect NIP-47.

A finales de semana, Amber v6.1.0-pre1 publicó una preversión con un mejor diseño para conectar aplicaciones nuevas, correcciones del diálogo del firmador, mejor manejo de permisos de notificación y selección de cuentas refactorizada. nostr-vpn v0.3.14 publicó una nueva compilación con artefactos para macOS Apple Silicon, Linux y Windows. Bitcredit Core v0.5.7-hotfix-1 y v0.5.8 publicaron correcciones consecutivas para un problema de validación de bloques huérfanos. Surveil v0.1.6 trajo pulido de UI móvil y una página About renovada; el proyecto se presenta más abajo.

applesauce 6.0.0 elimina las fábricas de eventos heredadas y añade análisis de URI Blossom

applesauce, el kit de herramientas Nostr en TypeScript de hzrd149, publicó un tren de lanzamientos 6.0.0 en el monorepo. applesauce-core@6.0.0 elimina la clase heredada EventFactory y los antiguos ayudantes buildEvent, modifyEvent y createEvent, empujando a quienes llaman hacia las nuevas clases de fábrica en applesauce-core/factories y applesauce-common. También añade manejo de direcciones IP y localhost al análisis de enlaces, expresiones regulares para URI Blossom BUD-10 y nuevos ayudantes observables como timeoutWithIgnore, combineLatestBy, combineLatestByIndex y combineLatestByKey.

Los lanzamientos a nivel de paquete completan las piezas específicas de Nostr. applesauce-content@6.0.0 añade nodos de URI Blossom BUD-10 para texto y Markdown, dando a los renderizadores una forma de primera clase para analizar referencias Blossom en el contenido. applesauce-actions@6.0.0 añade clases base de fábrica para listas NIP-51 que cubren relays, usuarios e ítems, haciendo la construcción de listas menos ad hoc. applesauce-wallet-connect@6.0.0 expone WalletConnect.connectURI, para que las apps puedan acceder directamente a un URI wallet-connect NIP-47 existente.

Cambios sin publicar

Amethyst avanza las salas de audio Nests con pruebas de interoperabilidad MoQ

Amethyst fusionó varios PR centrados en Nests esta semana, construyendo sobre la pila de salas de audio Media over QUIC de la semana pasada. PR #2622 añade un arnés de interoperabilidad entre clientes que ejercita el cliente MoQ de Amethyst contra la implementación web de referencia. El objetivo es detectar divergencias a nivel de cable entre Android/navegador antes de que los usuarios se topen con ellas. PR #2625 mejora el foco del hablante y el estado de conexión en picture-in-picture, mientras que PR #2620 clarifica avatares, estado de silencio y estado de habla en la cuadrícula de participantes. A finales de semana, PR #2634 corrige el padding del IME y los insets de ventana en la vista Nest a pantalla completa y PR #2635 añade filtrado por frescura basado en presencia al feed de Nests. Por separado, PR #2627 elimina la implementación C personalizada de secp256k1 de Amethyst y migra a libschnorr256k1.

nostream añade soporte para listas de relays NIP-65 y pagos NWC

nostream fusionó tres PR notables después del sprint de 53 PR del relay de la semana pasada. El soporte para metadatos de listas de relays NIP-65 llega en PR #585, para que el relay pueda indexar y servir eventos kind 10002 de listas de relays. Un procesador de pagos Nostr Wallet Connect sigue en PR #539, añadiendo una ruta de pago-por-relay. La limpieza de conexiones mejora en PR #438, que cierra un bug de conexiones muertas donde los sockets con suscripciones activas no eran recogidos, causando que los conteos de suscripciones se desviaran en instancias de larga ejecución.

FIPS añade bootstrap udp:nat basado en Nostr

FIPS, el Free Internetworking Peering System previamente cubierto en Newsletter #6 y Newsletter #10, fusionó PR #53 con bootstrap udp:nat basado en Nostr. El cambio permite a los nodos publicar anuncios Nostr, intercambiar señalización cifrada de oferta/respuesta, descubrir direcciones públicas mediante STUN, realizar UDP hole punching y entregar el socket perforado a la pila de transporte normal de FIPS. La implementación vincula las identidades de la carga útil de señalización al remitente Nostr real, consulta los relays configurados de DM y anuncios para la búsqueda de bandeja de entrada y revierte los traspasos de traversal adoptado fallidos para que los transportes UDP huérfanos no queden vivos. Este es el trabajo de anuncio Nostr y traversal NAT a seguir en el repositorio canónico, jmcorgan/fips.

strfry añade observabilidad por conexión

strfry fusionó PR #214, añadiendo observabilidad por conexión y métricas a nivel de conexión exportables a través de Prometheus. PR #204 normaliza las etiquetas de Prometheus, y PR #215 añade una sección de Community Integrations a la documentación que cubre proyectos de identidad Namecoin construidos sobre strfry.

Sprout añade Owner Attestation y soporte multi-workspace

Sprout, el cliente Nostr de Block, fusionó PR #406 implementando NIP-OA (Owner Attestation). La característica proporciona a un agente autónomo una prueba criptográfica de que una pubkey humana específica autorizó sus acciones. PR #409 añade soporte multi-workspace a la app de escritorio, PR #411 añade autocompletado #channel al compositor móvil y PR #410 cierra una ventana de carrera que podía descartar mensajes de canal activo. PR #413 introduce NIP-RS para sincronización de estado de lectura entre dispositivos, y los PR #420 y PR #422 de seguimiento conectan ese estado de lectura a las insignias de no leídos en móvil.

Zap Cooking añade paquetes de recetas, solicitudes de eliminación e inicio de sesión con bunker

Zap Cooking fusionó una semana productiva de trabajo de publicación de recetas. Las solicitudes de eliminación NIP-09 para los Recipe Packs propios de un usuario llegan en PR #367. La fiabilidad de publicación mejora mediante PR #366, que fuerza cada nueva receta al relay garden y añade una cola de reintentos para el conjunto compartido de recetas. La publicación de paquetes autorales con un clic llega en PR #365, y PR #331 añade soporte para inicio de sesión con bunker NIP-46.

Whitenoise-rs cifra su base de datos local

whitenoise-rs fusionó PR #758, añadiendo cifrado SQLCipher para la base de datos Whitenoise en disco. Eso cierra una brecha de seguridad en reposo de larga data para la pila del demonio Marmot. PR #775 expone las capacidades requeridas del grupo, PR #772 migra las operaciones de medios de grupo a MediaOps propiedad de la sesión y PR #773 extrae un contenedor SharedServices como parte del refactor de session-ops. En el lado móvil, whitenoise PR #577 habilita el reinicio automático al arranque para el servicio en primer plano de Android, corrigiendo el caso en que el demonio no volvía después de reiniciar el dispositivo.

Recién rastreados y descubiertos

Nostrord: un cliente NIP-29 construido con Kotlin Multiplatform y WASM

Nostrord es un nuevo cliente de chat grupal NIP-29 enfocado al caso de uso de reemplazo de Discord. Los grupos viven en relays Nostr con membresía, roles, moderación y control de acceso aplicados por el relay, por lo que el estado del grupo está alojado por el relay NIP-29 seleccionado. El desarrollador del cliente no controla una base de datos de aplicación separada para esos grupos. La app web se ejecuta en web.nostrord.com y está construida con Kotlin Multiplatform compilando a WebAssembly, con compilaciones nativas para Android, iOS y escritorio en desarrollo. Nostrord es beneficiario de una subvención OpenSats e interopera con los mismos relays NIP-29 usados por Flotilla, Chachi y 0xChat.

Clave lleva la firma remota NIP-46 a iOS mediante APNs

Clave es un firmador remoto para iOS en beta que firma eventos Nostr cuando la app no está abierta. La clave privada permanece en el Keychain del iPhone. Cuando un cliente envía una solicitud de firma remota NIP-46, un proxy del lado del servidor entrega una Notificación Push de Apple, despertando una Notification Service Extension durante hasta 30 segundos. Esa extensión descifra la solicitud con cifrado NIP-44, firma con la clave del Keychain y publica la respuesta. El registro del token del dispositivo usa HTTP Auth NIP-98 para prevenir el secuestro de tokens. Clave admite emparejamiento bunker:// y nostrconnect://, niveles de confianza por cliente, anulaciones por kind y ha sido probado con Nostur y noStrudel.

Treasures: geocaching descentralizado en Nostr

Treasures es una plataforma de geocaching donde los caches y los hallazgos son eventos Nostr firmados. Los creadores de caches publican eventos direccionables kind 37516 con coordenadas GPS. Los buscadores registran el descubrimiento escaneando un código QR adjunto al cache físico; el código codifica la pubkey del creador, el tag d del cache y una clave privada de verificación usada como prueba de la visita física. Los zaps NIP-57 pueden fluir desde los buscadores hacia los creadores de caches, y la app en vivo está en treasures.to.

smesh v0.5.1: relay Nostr auto-alojado, cliente y firmador en una sola pila

smesh es una pila Nostr auto-alojada escrita en Moxie, un lenguaje personalizado derivado de Go y TinyGo por mleku. La pila incluye un binario de relay nativo con soporte HTTP, WebSocket, AUTH, búsqueda y Blossom; sm3sh, un cliente web compilado a módulos ES; y una extensión de firmador de navegador con firma de navegador NIP-07 más soporte de cifrado NIP-04 y NIP-44. El trabajo reciente incluye mensajería de grupo MLS (RFC 9420) en v0.5.0, reconciliación de conjuntos negentropy para sincronización de relay y un motor de grafo Web of Trust. El código vive en la forja auto-alojada de mleku en git.smesh.lol, construida con su propia herramienta git-web. El repositorio relacionado gitea-nostr-auth es un puente OAuth2/OIDC para Gitea: los usuarios se autentican con un firmador de navegador NIP-07, el puente descubre relays a través de NIP-65 y Gitea recibe claims de identidad OIDC estándar.

Surveil: un constructor de mazos de Magic: The Gathering en Nostr

Surveil es un cliente Nostr para jugadores de Magic: The Gathering que permite a los usuarios buscar cartas, construir mazos, escanear cartas físicas en Android con OCR ML Kit en el dispositivo y compartir mazos en la red. Los mazos se publican como eventos direccionables kind 37381, y la especificación del evento de mazo está documentada en el NIP.md del proyecto. La capa social se construye a partir de primitivas Nostr estándar: comentarios en hilo NIP-22 (kind 1111) con alcance a cada mazo, reacciones NIP-25 (kind 7), datos de perfil NIP-78 (kind 30078) para los hogares de los jugadores, feeds de seguidores kind 3 y forks que llevan un tag a de vuelta al mazo original. v0.1.6 se publicó esta semana con pulido de UI móvil, mejoras del contador de vida, una página About renovada y una píldora de relay en el banner principal del mazo. La app web se ejecuta en cualquier lugar donde se sirva HTML estático, la compilación Android se distribuye a través de Zapstore, y los eventos kind 37381 también son indexados nativamente por Ditto como mazos Magic. El repositorio está en GitLab en chad.curtis/surveil.

Adiciones más pequeñas: Fundstr, Nod City, deploy-nsite-to-pages y null–nostr

Fundstr es una plataforma de financiación de creadores en Nostr que usa ecash Cashu para promesas únicas y recurrentes, con definiciones de niveles de creador y DMs de Nostr. Nod City es un sitio de reseñas de servicios Bitcoin donde las reseñas son eventos Nostr firmados y los reseñadores pueden recibir zaps; no se encontró repositorio público de código fuente. deploy-nsite-to-pages es una GitHub Action que refleja un nsite en GitHub Pages usando nsyte download, soportando nsites de raíz kind 15128 y con nombre kind 35128. null–nostr, también descubierto en los datos NIP-34 de esta semana, es el cliente cubierto en la reciente ola de OpenSats como Nurunuru; admite mensajería de grupo MLS, Amber, búsqueda NIP-50, publicaciones protegidas NIP-70, insignias ProofMode y distribución Zapstore.

FIPS no es un proyecto nuevo para Compass. Se cubrió en Newsletter #6 y Newsletter #10. La base de datos ahora apunta al repositorio canónico correcto, jmcorgan/fips, y el descubrimiento NIP-34 de esta semana también sacó a la luz mirrors relacionados de git-sobre-Nostr como fips y awesome-fips.

Trabajo de protocolo

Actualizaciones de NIP

Propuestas y discusiones recientes en el repositorio NIPs:

Fusionados esta semana:

NIP-34 git repositories: remove unused refs tag extension (PR #2325): Elimina una extensión de tag refs de NIP-34 que estaba definida pero no se usaba. La limpieza reduce la ambigüedad de implementación para las herramientas git-sobre-Nostr.
NIP-34 git repositories: remove incorrect NIP-09 claim (PR #2326): Elimina una afirmación incorrecta de que los eventos de eliminación NIP-09 pueden restablecer el estado del repositorio. La eliminación NIP-09 es una solicitud de eliminación de evento del lado del cliente, no una máquina de estados del repositorio. La corrección evita que los implementadores de NIP-34 traten las pistas de eliminación como restablecimientos autoritativos del repositorio.

Trabajo abierto e impulsado por implementaciones:

Comentarios de revisión en línea kind 1111 de GitWorkshop: El kind de comentario de revisión de código en línea está documentado en el NIP.md de GitWorkshop y ahora está en uso activo, pero aún no se ha propuesto como un NIP formal. Los eventos de veredicto (kind 7321) y los bloques suggestion siguen en borrador y aún no se han lanzado. La retroalimentación de implementación de GitWorkshop y ngit determinará si las formas se convierten en un NIP autónomo de revisión git o permanecen como una convención de aplicación en capas sobre NIP-34.
Nostr mail core y Nostrmon: Dos nuevos borradores de NIPs personalizados circularon esta semana. Nostr mail core propone kind 1301 para contenido de correo RFC 2822, envuelto con NIP-59 para entrega privada y puenteado al correo legado mediante pubkeys de puente resueltas por NIP-05. Nostrmon esboza kinds de eventos direccionables para regiones, mapas, criaturas, NPCs, guardados de jugador e ítems. Ambos permanecen como borradores personalizados, no NIPs fusionados.
NIP-67: EOSE Completeness Hint (PR #2317): La propuesta continúa iterando sobre añadir un marcador de completitud positivo a EOSE, permitiendo a los relays distinguir “eventos almacenados totalmente entregados” de los casos heredados de EOSE donde el relay no hace ninguna afirmación de completitud.

Seis abriles de Nostr

Abril ofrece una sección transversal clara del camino de desarrollo de Nostr: el documento del protocolo en 2021, el trabajo temprano de clientes en 2022, la ola de aplicaciones post-Damus en 2023, la mensajería privada y el trabajo git-sobre-Nostr en 2024, Blossom y la limpieza de listas de relays en 2025 y las subvenciones a clientes centradas en la adopción en 2026.

Abril 2021: el documento del protocolo antes del repo NIPs

Fiatjaf publicó el artículo original de Nostr, “Notes and Other Stuff Transmitted by Relays”, el 20 de noviembre de 2020. Ese primer texto ya contenía la forma central que todavía define el protocolo: los usuarios firman eventos con claves, los publican en relays y leen de los relays que eligen. El registro de commits de nostr-protocol/nostr no muestra commits entre el 1 y el 30 de abril. La actividad se sitúa a ambos lados: los commits de marzo de 2021 añadieron los primeros enlaces “nostwitter” y un filtro kind, mientras que mayo de 2021 reutilizó NIP-02 y añadió la autoría de NIPs.

En abril de 2021, no había mercado público de clientes, ni red de relays visible, ni repositorio de NIPs. El protocolo todavía vivía como un pequeño documento y unos pocos experimentos. Nostr aún no se había convertido en una red social o una plataforma de desarrollo. Todavía era un modelo relay/clave/evento esperando su primera ola sostenida de contribuidores.

Abril 2022: los NIPs aún vivían en el repo principal

Abril de 2022 fue el último mes antes de que los NIPs se movieran fuera del repo principal nostr-protocol/nostr. Como la división aún no había ocurrido, el repo dedicado nostr-protocol/nips no tenía historial de pull requests de abril. En el repo principal aterrizaron tres commits de abril: “Update readme to add nip12” el 8 de abril por goswami1999, “add kinds list” el 25 de abril por jb55 y “add js formatting to sample code” el 28 de abril por steliosrammos.

El trabajo de clientes también empezaba a tomar forma. Los commits de Damus de abril de 2022 añadieron comportamiento inicial de chatroom, manejo de perfiles e íconos de la app, mientras que nostr-tools se estaba convirtiendo en la ruta de biblioteca JavaScript para los primeros clientes y experimentos. En el lado del protocolo, las consultas de tags genéricas NIP-12 dieron a la búsqueda por tag un lugar documentado, la lista de kinds movió Nostr hacia un modelo de registro y mejores ejemplos JavaScript facilitaron a los autores de clientes y bibliotecas implementar la especificación. El 1 de mayo, fiatjaf movió los NIPs al repo dedicado. Abril de 2022 fue el último mes de la era original de un solo repo.

Abril 2023: expansión de aplicaciones post-Damus

Abril de 2023 llegó tres meses después de que Damus se lanzara en la App Store de iOS el 31 de enero de 2023, y después de que Jack Dorsey publicara su clave pública de Nostr. La red acababa de absorber su primera gran ola de crecimiento público. Clientes como Damus, Snort, Iris, Coracle y Amethyst estaban activos, mientras que los operadores de relays aprendían qué le hacía un grafo social más grande a las suposiciones sobre ancho de banda, spam, búsqueda y moderación.

Abril de 2023 tuvo un PR de NIPs fusionado: PR #456, fusionado el 17 de abril, añadiendo enlaces a entidades bech32 NIP-19 al manejo de URIs NIP-21. Los commits circundantes muestran la presión de aplicaciones detrás del trabajo del protocolo. Abril de 2023 vio trabajo en NIP-45 COUNT, marcadores de zap específicos de eventos, NIP-15 marketplace, semántica de delegación de eliminación NIP-26, metadatos de archivo NIP-94, manejo de errores de wallet-connect NIP-47 y NIP-30 custom emoji. La lista de contribuidores se había ampliado para incluir a fiatjaf, staab, pablof7z, Semisol, CodyTseng, sethforprivacy, mikedilger, AsaiToshiya, alexgleason, martindsq, frbittencourt y arkin0x.

Damus, Snort, Iris, Coracle y Amethyst ya no eran demos alrededor de una especificación; eran clientes de producción lidiando con onboarding, feeds, spam, zaps, medios y selección de relays. El trabajo de protocolo de abril de 2023 se lee como el backlog que esos clientes crearon: zaps, marketplaces, metadatos de archivos, conteo, emoji y enlaces de identidad empujaron la especificación más allá de simples notas y follows.

Abril 2024: mensajería privada, git-sobre-Nostr y soporte a mantenedores

Abril de 2024 tuvo dos fusiones de PRs de NIP. PR #1167, fusionado el 10 de abril, corrigió terminología confusa en la firma remota NIP-46, donde clientes y firmadores necesitan un lenguaje exacto para las acciones solicitadas y autorizadas. PR #1108, fusionado el 17 de abril, expandió los repositorios git NIP-34 con eventos de estado, clarificaciones, mantenedores opcionales, identificadores de repositorio y tags de descubribilidad. Ese paso hizo git-sobre-Nostr más práctico para ngit y luego GitWorkshop.

NIP-17, anteriormente NIP-24, aterrizó el 24 de abril como mensajes sellados gift-wrapped para DMs privados y chats de grupos pequeños. El trabajo de clientes y bibliotecas corría junto a esto: Amethyst, Primal, Gossip, nostr-tools, NDK y rust-nostr estaban todos activos en el mismo período.

OpenSats también anunció soporte a largo plazo para desarrolladores de Nostr en abril de 2024: PabloF7z el 9 de abril, Stuart Bowman el 12 de abril y hzrd149 el 15 de abril. Esas subvenciones movieron la financiación de subvenciones aisladas de proyectos hacia el mantenimiento sostenido de relays, bibliotecas e infraestructura de clientes.

Abril 2025: limpieza densa de NIPs y formalización de Blossom

Abril de 2025 fue el mes de protocolo más denso en esta retrospectiva, con dieciséis PRs de NIPs fusionados. El mes comenzó con PR #1846, añadiendo transacciones y direcciones blockchain a NIP-73, y PR #1865, añadiendo tags NIP-C0 a la tabla de tags estandarizados. Continuó con PR #1801 y PR #1889, ambos mejorando la guía de republicación de listas de relays kind 10002, y PR #1879, que redujo y clarificó NIP-65.

PR #1822 añadió NIP-B7 para interacción con Blossom, dando a los clientes Nostr y a los servidores Blossom una capa de coordinación canónica después de más de un año de práctica informal. PR #1051 deprecó NIP-26, la especificación de firma delegada de eventos. NIP-26 había sido difícil de implementar de forma segura y se había vuelto menos atractivo a medida que NIP-46 y otros patrones de firmador maduraban.

El resto del mes combinó limpieza con expansión de aplicaciones: PR #1882 añadió campos de política de privacidad y términos de servicio a NIP-11, PR #1849 expandió el kind 39701 de marcadores web bajo NIP-B0, PR #1891 añadió ese kind de marcador al README y PR #1895 añadió tags estandarizados NIP-B0. OpenSats anunció su Undécima Ola de Subvenciones de Nostr el 16 de abril, financiando Swae, HAMSTR, Vertex, Nostr Double Ratchet y Nostr Game Engine. Primal, Coracle, noStrudel, nostr-tools, NDK y rust-nostr también estaban publicando durante este período, por lo que la limpieza del protocolo se ubicó junto a trabajo activo de clientes y bibliotecas.

Abril 2026: endurecimiento de NIP-34, insignias y subvenciones centradas en la adopción

Abril de 2026, el mes con el que cierra este número, tuvo cuatro PRs de NIPs fusionados. El primero fue PR #2276, fusionado el 1 de abril, que cambió las insignias de perfil NIP-58 a kind 10008 y añadió conjuntos de insignias kind 30008, haciendo la asignación de insignias y las colecciones de insignias más componibles. Un segundo cambio de usabilidad git-sobre-Nostr llegó en PR #2312, fusionado el 10 de abril, añadiendo semántica de URL de clonación nostr:// a NIP-34. Las limpiezas del 25 de abril, PR #2325 y PR #2326, eliminaron lenguaje NIP-34 no utilizado e incorrecto.

Los commits relacionados afinan las mismas superficies. El 22 de abril, fiatjaf añadió una lista de servidores Blossom a NIP-51 y ajustó la edición de metadatos NIP-29 para coincidir con el comportamiento estilo PUT de Flotilla. El 26 de abril, renombró NIP-5A por claridad. Abril de 2026 se centró en hacer las superficies de protocolo ya utilizadas más fáciles de implementar y más difíciles de malinterpretar.

OpenSats anunció su Decimosexta Ola de Subvenciones de Nostr el 8 de abril, apoyando Amethyst Desktop, Nostr Mail, Nostrord, Nurunuru (null–nostr) y una renovación de HAMSTR: clientes de escritorio, mensajería tipo correo, UX de grupos, onboarding en japonés y conectividad fuera de red.

Gracias por leer Nostr Compass #20. Envíanos un DM en Nostr con pistas, correcciones o nuevos proyectos que cubrir.

Nostr Compass #19

Wed, 22 Apr 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Amethyst avanzó fuerte en cumplimiento de Marmot, comunidades NIP-72, objetivos de zap NIP-75 y salas de audio sobre MoQ. TollGate estabilizó acceso a internet de pago por uso sobre Nostr y Cashu con v0.1.0. nostream cerró una semana de trabajo de relay en torno a NIP-45, NIP-62, compresión, endurecimiento de consultas y paridad completa con NIP-11. También destacaron el paquete de repositorios de Forgesworn, la sincronización de cartera Lightning de ShockWallet y los análisis de NIP-72 y NIP-57.

Noticias principales

Amethyst lanza cumplimiento MIP de Marmot, comunidades NIP-72, objetivos de zap y salas de audio con MoQ

Amethyst fusionó 57 PRs centradas en interoperabilidad de Marmot, gestión de comunidades NIP-72, objetivos de zap NIP-75 en pantallas NIP-53 y una nueva superficie de audio en tiempo real sobre Media over QUIC. El trabajo incluye alineación con formatos wire de MIP-01 y MIP-05, soporte para MIP-00 KeyPackage Relay List, correcciones de framing y descifrado MLS, una CLI amy para operaciones de grupos, creación y moderación de comunidades, leaderboard de top zappers y una nueva pantalla de Public Chats para salas públicas de audio.

TollGate v0.1.0 estabiliza internet de pago por uso sobre Nostr y Cashu

TollGate publicó v0.1.0, fijando una primera referencia estable para vender conectividad por minutos o megabytes a cambio de tokens ecash de Cashu. La arquitectura separa una capa de protocolo basada en TIP-01 y TIP-02, una capa de interfaz con HTTP-01 a HTTP-03 y NOSTR-01, y una capa de medio descrita por WIFI-01 para captive portals y clientes pagadores.

nostream fusiona 53 PRs para NIP-45, NIP-62, compresión y endurecimiento de consultas

nostream añadió soporte de COUNT para NIP-45, anunció right-to-vanish de NIP-62, amplió el esquema de filtros para tags en mayúscula y añadió compresión gzip y xz para import/export. Además, mejoró el rendimiento del traductor de filtros a SQL, corrigió un fallo en matching de pubkeys en allowlists y denylists, añadió desempate determinista en upsertMany, limitó la confianza en X-Forwarded-For y alcanzó paridad completa con NIP-11.

Lanzamientos de esta semana

Primal Android lanza pestaña Explore, verificación NIP-05 y reproductor de audio

Primal Android añadió una nueva pestaña Explore, editor de feeds basado en la DSL de búsqueda avanzada de Primal, verificación NIP-05 y un reproductor de audio embebido. También conectó el escáner QR de cartera con emparejamiento NIP-46.

strfry añade métricas Prometheus para la ruta de escritura y corrige el sobre AUTH de NIP-42

strfry añadió métricas Prometheus para escrituras, logging por conexión y compresión, volvió configurable el límite de tags por filtro y corrigió sus respuestas de AUTH para ajustarse a NIP-42, usando el sobre OK en lugar de NOTICE.

Shopstr endurece la seguridad del storefront en 13 PRs

Shopstr fusionó una serie de correcciones de seguridad que cierran JavaScript almacenado en enlaces de storefront, XSS reflejado en políticas HTML, una API sin autenticación para borrar eventos cacheados, lectura no autenticada de mensajes, fallos SSRF y errores funcionales en cola de publish y descuentos de carrito.

Nostria v3.1.26 a v3.1.28 añaden reproducción de música en segundo plano en Android

Nostria añadió reproducción de música en segundo plano en Android con controles en la barra de notificaciones y pantalla de bloqueo, y los releases posteriores endurecieron esa nueva superficie del servicio multimedia.

Wisp v0.18.0-beta añade Normie Mode, feed For You y configuración de grupos NIP-29

Wisp orientó esta versión a usuarios menos nativos de Bitcoin con Normie Mode, onboarding renovado y feed For You. En el lado de protocolo añadió configuración de grupos NIP-29 para flags, invites, roles y AUTH, además de broadcasting a inbox relays NIP-65 de pubkeys mencionadas.

NoorNote v0.8.4 añade Scheduled Posts y zaps en live streams

NoorNote añadió publicaciones programadas a través de un relay operado por el proyecto, zaps de un toque desde tarjetas de live stream vía NIP-53 y correcciones de duplicación en timelines largas de Android.

topaz v0.0.2 lanza un relay Nostr para Android

topaz apareció como un relay Nostr ejecutable en teléfonos Android. El alcance por ahora es acotado, pero la idea es usar el teléfono como relay personal siempre disponible.

StableKraft v1.0.0 lanza la primera versión estable de su PWA de música y podcasts

StableKraft llegó a v1.0.0 como una PWA Next.js para descubrir, organizar y reproducir música obtenida desde feeds de podcasts, usando Nostr para auth y funciones sociales y Lightning para pagos V4V. La semana también mejoró la ingesta de feeds y acortó ventanas de reparseo nocturno.

NipLock lanza un gestor de contraseñas basado en NIP-17

NipLock almacena credenciales como mensajes directos NIP-17 enviados de la clave del usuario a sí misma, de modo que se sincronicen entre dispositivos autenticados con la misma clave. Soporta firma con nsec, extensiones de navegador y Amber vía NIP-46.

flotilla-budabit pule su superficie de repositorios NIP-34

El fork flotilla-budabit siguió mejorando controles de discusión de repositorios, pestañas sticky, carga de anuncios desde relays GRASP y sincronización del estado de patches aplicados por maintainers en su flujo git-over-Nostr.

rx-nostr 3.7.2 a 3.7.4 añaden verificador por defecto y argumentos opcionales

rx-nostr añadió un verificador Schnorr por defecto, corrigió un uso defectuoso de @noble/curves en su paquete crypto y permitió crear instancias con createRxNostr() sin configuración obligatoria.

Keep Android v1.0.0 lanza builds reproducibles y cero trackers

Keep llegó a v1.0.0 tras añadir receta de build reproducible, sustituir Google ML Kit por ZXing para eliminar dependencias de Google Play Services y publicar un escaneo de Exodus Privacy sin trackers. También añadió un manifiesto zapstore.yaml para distribuir el APK en Zapstore.

Flotilla 1.7.3 y 1.7.4 añaden envoltura kind-9 para salas NIP-29 más ricas

Flotilla empezó a envolver contenido no orientado a chat dentro de kind 9 para preservar el contexto de la sala NIP-29. Los releases también añadieron encuestas, login NIP-46 mediante Aegis, support de share para invites, room mentions, borradores y vídeo en llamadas.

WoT Relay v0.2.1 migra el eventstore a LMDB

WoT Relay migró su eventstore a LMDB, reajustó la carga inicial del grafo de confianza y actualizó dependencias criptográficas y metadatos NIP-11 para el release.

Suite Formstr: revisión de seguridad en Pollerama, i18n en Forms y soporte RRULE en Calendar

La suite de Formstr fusionó 26 PRs entre Pollerama, Forms y Nostr Calendar. Pollerama endureció gestión de claves y parsing de perfiles; Forms añadió soporte para audio/vídeo, i18n e importador de Google Forms; y Nostr Calendar lanzó v1.3.0 y v1.4.0 con múltiples RRULE, fechas flotantes en UTC según RFC 5545, eventos compartidos y preferencias de notificación, todo sobre NIP-52.

También lanzaron: notedeck, nostr.blue, cliprelay, Captain’s Log

Otros proyectos publicaron releases iterativos sin una sola gran novedad: notedeck mejoró renderizado de columnas y relay pools, nostr.blue actualizó Dioxus y destrabó Android, cliprelay ajustó sincronización de portapapeles y Captain’s Log añadió detección de vida de relays de sync.

En desarrollo

whitenoise-rs se refactoriza hacia vistas de cuenta con alcance de sesión

whitenoise-rs continuó su refactor por fases desde singletons globales hacia AccountSession por cuenta, moviendo handles de relay, drafts, settings, operaciones de mensajes, lectura y escritura de grupos, membresía, push notifications, key packages y dispatch de eventos a superficies propias de cada sesión.

La app White Noise añade UI de bloqueo/desbloqueo, salida de grupo y avisos offline

White Noise añadió controles para bloquear y desbloquear usuarios, salir y eliminar grupos desde la app y mostrar avisos offline cuando el daemon no puede alcanzar sus relays. También afinó la eliminación de key packages legacy durante migraciones.

MDK añade soporte de invites entre versiones mixtas y convergencia de SelfUpdate

MDK mejoró compatibilidad entre clientes Marmot con distintas versiones calculando RequiredCapabilities como LCD de las capacidades de invitados y alineando el formato wire de SelfUpdate. También reforzó validación de depletion admin, almacenamiento en memoria y acceso a propuestas requeridas por grupo.

nostter añade cifrado NIP-44 a listas de personas, bookmarks y mutes

nostter siguió migrando de NIP-04 a NIP-44 al cifrar mute lists, bookmarks y people lists, y eliminó una ruta legacy de migración kind-30000 que ya no hacía falta.

zap.cooking lanza puntuación Nourish y un hilo de comentarios reutilizable

zap.cooking añadió un módulo Nourish para puntuar recetas por ejes nutricionales y refactorizó su módulo de comentarios hacia un CommentThread reutilizable, junto con mejoras de escalado, subida de medios y pestañas de replies.

ridestr extrae un coordinador compartido de pasajeros

ridestr refactorizó pantallas Compose y extrajo la lógica de protocolo de rider y driver hacia un coordinador compartido :common, además de añadir un receptor de driver ping kind 3189.

Blossom propone cabecera BUD-01 Sunset para expiración de blobs

Blossom abrió una propuesta para añadir una cabecera Sunset a BUD-01, de modo que un servidor pueda anunciar cuándo dejará de servir un blob y los clientes puedan planificar retención limitada sin descubrirla solo cuando llegue un 404.

Proyectos nuevos

Forgesworn publica un toolkit criptográfico de 29 repositorios para Nostr

Forgesworn lanzó un conjunto amplio de repositorios TypeScript alrededor de firma, identidad, attestations, web of trust y APIs pagadas. Destacan nsec-tree para subidentidades deterministas, Heartwood como signer NIP-46 sobre Raspberry Pi, Signet para verificación de identidad, nostr-attestations para credenciales y toll-booth / toll-booth-dvm para monetizar APIs sobre Lightning y NIP-90.

ShockWallet lanza sincronización de cartera Lightning nativa de Nostr y conexiones multi-node

ShockWallet usa Nostr como transporte para conectarse a nodos Lightning autocustodiados mediante nprofile. El proyecto sigue empujando sincronización de estado multi-dispositivo basada en eventos específicos de aplicación y una superficie coherente entre web, Android e iOS.

Los issues de Nostrability migran a git sobre Nostr tras la censura de GitHub

Nostrability movió su workflow de issues a infraestructura git-over-Nostr después de que GitHub eliminara la organización sin respuesta posterior. La idea es mantener los informes de interoperabilidad dentro de infraestructura nativa de Nostr.

nowhere codifica sitios web completos en fragments URL y enruta pedidos por Nostr

nowhere serializa un sitio entero dentro del fragmento # de la URL, lo comprime y lo firma, de modo que el host nunca vea el contenido porque los navegadores no envían fragments a servidores. Para tipos de sitio que necesitan comunicación viva, como store o forum, el tráfico pasa por relays Nostr con cifrado NIP-44.

Nuevas superficies pequeñas: relayk.it y Brainstorm Search

relayk.it apareció como cliente de descubrimiento de relays construido con Shakespeare y ejecutado íntegramente en el navegador, mientras Brainstorm Search ofrece una UI de búsqueda Nostr de página única orientada a descubrir contenido en la red.

Trabajo de protocolo y especificación

Actualizaciones de NIP

La semana trajo nuevas propuestas en el repositorio de NIPs alrededor de NIP-67 para completitud de EOSE, NIP-5D para applets web, subgrupos y permisos explícitos en NIP-29, un campo access_control en NIP-11, attestations de reputación de agentes para mercados de NIP-90 y la continuación del trabajo sobre datos privados de localización y cambios de marmot-ts.

NIP Deep Dive: NIP-72 (comunidades moderadas)

NIP-72 define comunidades temáticas moderadas en las que cualquiera puede enviar contenido, pero solo las publicaciones aprobadas por un moderador aparecen en la vista comunitaria. La comunidad se define con un evento kind 34550, los envíos la referencian mediante una etiqueta a y los moderadores publican eventos kind 4549 para aprobarlos. El modelo es transparente, auditable y bifurcable, a diferencia de NIP-29, donde el relay controla tanto la membresía como la moderación.

NIP Deep Dive: NIP-57 (zaps)

NIP-57 define cómo adjuntar pagos Lightning a identidades y contenido Nostr mediante solicitudes kind 9734 y recibos kind 9735. El punto central sigue siendo la validación: los clientes deben comprobar firma, monto de invoice, description hash y preimage antes de tratar un recibo como un zap real. Sobre esa base descansan tanto zaps privados y anónimos como sistemas de objetivos de zap de NIP-75.

Nostr Compass #18

Wed, 15 Apr 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Amethyst fusionó una tanda grande de trabajo en Tor, secp256k1, llamadas WebRTC y Marmot, incluyendo soporte de llamadas para NIP-AC y múltiples carteras NIP-47. nstrfy lanzó notificaciones push nativas de Nostr para Android con soporte para NIP-44, NIP-55, NIP-65 y NIP-40. HAMSTR añadió transporte Reticulum para eventos Nostr sobre LoRa. Bloom, WaveFunc, Snort y Primal Android encabezaron los lanzamientos de la semana, mientras los análisis de NIP cubren NIP-29 y NIP-90.

Noticias principales

Amethyst fusiona desktop Tor, secp256k1 en C, llamadas WebRTC y multi-wallet NWC

Amethyst fusionó 29 PRs entre criptografía, networking, llamadas y carteras. Lo más importante fue PR #2381, que añade soporte Tor de escritorio con diseño fail-closed, PR #2374, que introduce una implementación secp256k1 en C con bindings JNI para acelerar verificación Schnorr, y PR #2202, que alinea su implementación MLS pura en Kotlin con RFC 9420 para mejorar la interoperabilidad de Marmot. Una serie de PRs de WebRTC añadió llamadas de voz y vídeo para NIP-AC, y PR #1988 incorpora soporte multi-wallet para NIP-47.

nstrfy lanza notificaciones push nativas de Nostr para Android

nstrfy debutó como una app Android de notificaciones push basada en eventos kind 7741 en relays Nostr. Soporta payloads en texto plano y cifrados con NIP-44, puede firmar vía Amber usando NIP-55, importa listas de relays desde NIP-65 y respeta expiración de eventos de NIP-40. El proyecto complementario nstrfy.sh ofrece un cliente bash y una versión web alojada.

HAMSTR añade Reticulum para Nostr sobre malla LoRa

HAMSTR añadió Reticulum como backend de transporte para enviar eventos Nostr a través de hardware LoRa sin infraestructura de internet. El proyecto mantiene también sus transportes AX.25 Packet Radio y VARA HF, y sigue soportando zaps de NIP-57 para que los pagos Lightning offline aparezcan correctamente en clientes como Amethyst y Primal.

Lanzamientos de esta semana

Bloom v0.1.0 lanza servidor Blossom y relay autoalojados

Bloom lanzó v0.1.0 como aplicación de escritorio que empaqueta un servidor de medios Blossom y un relay Nostr en una sola app Tauri. El release ofrece almacenamiento soberano de archivos con content addressing SHA-256, soporte de metadatos de archivo NIP-94 y resolución de URIs blossom://.

WaveFunc v0.1.0 y v0.1.1 lanzan radio por internet sobre Nostr

WaveFunc salió como directorio y reproductor de radio por internet basado en Nostr. Usa kinds personalizados para emisoras, favoritos, chat en vivo y comentarios, y añade una cartera NIP-60 con nutzaps, junto con mejoras de escritorio como system tray, media keys y deep linking.

Snort lanza v0.5.0 a v0.5.3 con endurecimiento de seguridad y mejora de rendimiento

Snort publicó tres releases centrados en una auditoría de seguridad, verificación real de firmas Schnorr, protección reforzada de NIP-46, mejoras en cifrado de PIN y optimizaciones de rendimiento. También añadió visualización de invoices de pago requerido kind 7000 para NIP-90 y rehízo el sistema de mensajería para evitar cuellos de botella.

Primal Android lanza 3.0.21 y rediseña el layout del feed

Primal Android publicó v3.0.21 con correcciones de votos zap de encuestas, servicio de cartera y reconexión del signer remoto. Después llegaron siete PRs que unifican el layout principal, rediseñan las tarjetas del feed, mejoran tarjetas multimedia, añaden respuestas rápidas compactas y actualizan las app bars.

Nostria v3.1.19 a v3.1.21 añaden generación local de imágenes

Nostria añadió generación local de imágenes con Janus Pro y WebGPU, además de generación en la nube, chat multimodal y mejoras del editor y del sistema de diálogos. El proyecto sigue ampliando una superficie que en el release anterior ya había sumado signer local y aplicaciones móviles nativas.

TubeStr v1.0.3 lanza mejoras en feed y estudio

TubeStr añadió mejoras de feed y studio, renovó la experiencia de onboarding y corrigió una exportación de vídeo defectuosa. La app usa NDK y MDK para compartir medios cifrados entre familiares y planea integración futura con Blossom.

En desarrollo

Botburrow inicia desarrollo como plataforma de bots de Marmot

Botburrow es una nueva plataforma autoalojada para gestionar bots con identidad Nostr propia dentro de chats grupales Marmot. Cada bot se conecta a un daemon wnd, puede entrar a grupos mediante mensajes Welcome y ejecutar scripts, triggers y tareas programadas.

Nostr Archives siguió expandiendo su plataforma de archivado y analítica con filtros de leaderboard, contadores de engagement, resolución directa de entidades Nostr desde rutas URL y una página de documentación de API. El servicio mantiene varios relays especializados, incluyendo búsqueda NIP-50 y feeds de tendencias.

Damus corrige la timeline de favoritos

Damus reescribió subscribe_to_favorites() para filtrar in place, reconstruir la deduplicación y persistir la selección de pestaña, corrigiendo fallos en la timeline de favoritos.

Nostur añade zaps privados y visualización de emoji personalizados

Nostur añadió soporte de zaps privados, visualización de emoji personalizados, renderizado corregido de .webp animado y detección del formato de audio de mensajes de voz.

Amber lanza v6.0.1 a v6.0.3 con backups WebDAV y correcciones de reconexión a relays

Amber publicó tres releases con nuevas opciones de backup, retroceso exponencial para reconexión a relays, actualización de Quartz y correcciones para eventos y flujos de intents. Como firmante NIP-55, Amber sigue ganando robustez para clientes Android.

Plektos v0.6.0 se rediseña con temas Ditto

Plektos, construido sobre NIP-52, añadió temas estilo Ditto, configuración de forma de avatar y una revisión visual amplia, además de atender hallazgos de una revisión completa de código.

Shadow añade API Nostr OS y app de cartera Cashu

Shadow siguió ampliando su runtime con una app de cartera Cashu, un reproductor de podcasts demo y APIs del sistema para Nostr y audio. También mejoró soporte Linux de escritorio con correcciones de fuentes y rutas XDG.

Lief solucionó un problema de login con Amber, simplificó el flujo de signer nudge, actualizó nostrify y añadió integración con Zapstore.

Espy renovó su color picker con un arco curvo de saturación, corrigió fallos visuales del anillo de tono y añadió personajes ocultos, mientras compartía con Lief las correcciones de login con Amber y la integración con Zapstore.

Jumble añade filtros por kind por feed y pestaña de artículos

Jumble añadió filtrado por kind para cada feed, una pestaña Articles, sincronización del estado leído de notificaciones, modo para ocultar avatares y una corrección de race condition al cambiar de cuenta.

Primal Web lanza 8 subidas de versión

Primal Web publicó versiones 3.0.93 a 3.0.101 con foco en mejoras del chat de live streams, mención de límites, paginación de bookmarks, prevención de likes duplicados y correcciones del relay proxy.

Trabajo de protocolo y especificación

Actualizaciones de NIP

En el repositorio de NIPs se fusionó soporte para URLs de clonación nostr:// en NIP-34, y siguieron abiertas varias propuestas alrededor de descriptores mínimos de gateways de pago, manifiestos de autodeclaración de relays, datos privados de localización transitoria, programas WASM de NIP-5C, payloads grandes para NIP-44 y la restricción de NIP-C7 a vistas de chat.

NIP Deep Dive: NIP-29 (grupos basados en relay)

NIP-29 define mensajería grupal en la que el relay actúa como autoridad para membresía y moderación. Los eventos de usuario llevan una etiqueta h con el ID del grupo, las referencias previous sirven como defensa frente a rebroadcasts fuera de contexto y los eventos de moderación de la serie 9000 gestionan alta, baja, roles y metadatos. El modelo es adecuado para comunidades públicas o moderadas en las que el operador del relay puede leer el contenido, a diferencia de alternativas cifradas como Marmot o NIP-17.

NIP Deep Dive: NIP-90 (Data Vending Machines)

NIP-90 describe un mercado de cómputo bajo demanda sobre Nostr. Los clientes publican trabajos en el rango 5000-5999, los proveedores devuelven resultados en 6000-6999 y pueden emitir feedback kind 7000 como payment-required, processing, error o success. El diseño permite entradas por URL, texto, eventos o trabajos previos y deja flexible la lógica comercial para acomodar desde transformaciones baratas hasta tareas costosas de GPU.

Nostr Compass #17

Wed, 08 Apr 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Amethyst lanza v1.08.0 con integración de Arti Tor y una UI de Shorts rediseñada, mientras fusiona implementaciones puras en Kotlin de MLS y Marmot en su librería Quartz. Nostur lanza v1.27.0 con grabación de vídeo, perfiles con GIF animados y respuestas privadas. Shosho lanza v0.15.0 con Shows (información personalizada de live stream conectada a OBS) y un carrusel vertical de vídeo al estilo TikTok. Nymchat revierte Marmot y lanza chats grupales NIP-17 mejorados con claves efímeras rotativas. Nostr VPN lanza soporte de exit node y empaquetado para Umbrel a lo largo de seis releases. Amber salta a v6.0.0-pre1 con claves de firma NIP-46 por conexión y actualizaciones dentro de la app mediante Zapstore. Notedeck alcanza v0.10.0-beta con autoactualización de APK vía Zapstore, y NIP-58 (Badges) recibe una migración de kind. Dos análisis en profundidad de NIP cubren NIP-17 (Private Direct Messages) y NIP-46 (Nostr Remote Signing).

Noticias principales

Amethyst lanza Arti Tor y fusiona MLS y Marmot puros en Kotlin

Amethyst, el cliente Android mantenido por vitorpamplona, lanzó cuatro releases desde v1.07.3 hasta v1.08.0 y fusionó un gran lote de trabajo aún no publicado en su librería Quartz (el módulo Nostr compartido de Kotlin Multiplatform). El release principal es v1.08.0 “Arti Tor”, que migra la conectividad Tor de la app desde la librería Tor basada en C a Arti, la implementación en Rust del Tor Project. La migración aborda crashes aleatorios que ocurrían con los bindings anteriores de C Tor. Arti es el reemplazo a largo plazo del Tor Project para la base de código en C, escrito desde cero en Rust para seguridad de memoria y async I/O.

El release v1.07.3 rediseñó la UI de Shorts, reemplazando el diseño paginado por feeds de borde a borde para imágenes, shorts y vídeos largos. El mismo release migró badges a kind 10008 y bookmarks a kind 10003, alineándose con la migración de kind de NIP-58 fusionada esta semana. v1.07.4 corrigió un problema en el manejo de secretos de Nostr Wallet Connect, y v1.07.5 corrigió un crash en la subida de imágenes.

En main, pero todavía no en un release etiquetado, el equipo escribió una implementación completa en Kotlin tanto de MLS como del protocolo Marmot, reemplazando la necesidad de bindings nativos de bibliotecas C/Rust. PR #2147 añade la capa central de mensajería grupal Marmot MLS, PR #2149 añade la UI de chat grupal, PR #2146 añade procesadores de mensajes entrantes y salientes con un gestor de suscripciones, PR #2141 añade persistencia del estado de grupos MLS y gestión de rotación de KeyPackage, PR #2150 añade una suite completa de tests de MLS con firma de GroupInfo mejorada, y PR #2158 añade seguimiento del estado de publicación de KeyPackage. PR #2166 añade una implementación pura en Kotlin de secp256k1 para operaciones criptográficas de Nostr, reemplazando la dependencia de la biblioteca nativa en C. Combinado con la implementación MLS en Kotlin, Quartz puede ejecutar firma Nostr y mensajería grupal Marmot sin ningún binding nativo, lo que abre la puerta a objetivos de Kotlin Multiplatform, incluyendo iOS.

El equipo también está construyendo soporte para NIP-AC (P2P Voice and Video Calls): PR #2143 añade una suite completa de tests para la máquina de estados de llamadas NIP-AC, y PR #2164 evita que ofertas de llamada obsoletas se disparen de nuevo después de reiniciar la app.

Nostur v1.27.0 añade grabación de vídeo y respuestas privadas

Nostur, el cliente Nostr para iOS, lanzó v1.27.0 el 2 de abril. El release añade grabación de vídeo dentro de la app con recorte antes de subir, de modo que los usuarios puedan capturar clips cortos, ajustarlos a la duración deseada y publicarlos sin salir del cliente. El soporte para GIF animados se extiende a fotos de perfil y banner, y también se añadió renderizado de WebP animado. Una nueva integración con Shortcuts permite a los usuarios enviar publicaciones de Nostr desde automatizaciones de Apple Shortcuts. El release también añade respuestas privadas y corrige problemas de compatibilidad de DMs que afectaban la entrega de mensajes entre Nostur y otros clientes.

Shosho v0.15.0 lanza Shows y carrusel vertical de vídeo

Shosho, la app de live streaming sobre Nostr, lanzó v0.15.0 y v0.15.1 el 7 de abril. La función principal es Shows: los streamers pueden configurar información personalizada del show antes de salir en vivo y conectar su show a OBS o a cualquier codificador externo. Esto separa los metadatos de “qué estoy transmitiendo” del acto de entrar en directo, de modo que los streamers puedan preparar títulos, descripciones y productos antes de empezar a emitir. El mismo release añade un carrusel vertical de vídeo al estilo TikTok para deslizar entre lives, clips y replays en un feed a pantalla completa, y Quick Add para publicar clips de vídeo y añadir productos directamente desde una página de perfil. v0.15.1 corrige un bug por el que el teclado ocultaba el campo de entrada del chat del live stream.

Lanzamientos de esta semana

Notedeck v0.10.0-beta lanza autoactualización con Zapstore

Notedeck, el cliente de escritorio y móvil del equipo Damus, lanzó v0.10.0-beta.1 y v0.10.0-beta.2 como prereleases de prueba para autoactualización de APK. PR #1417 añade autoactualización de APK a través del actualizador Nostr/Zapstore en Android, construyendo sobre el trabajo de descubrimiento de actualizaciones nativo de Nostr cubierto en Newsletter #14. El flujo de actualización descubre nuevos releases a través de eventos Nostr publicados en relays, luego descarga el APK desde donde el desarrollador lo aloje (GitHub releases, Blossom CDN u otras fuentes), verifica el hash SHA-256 contra el evento Nostr firmado y lo instala. PR #1438 corrige un bug en la pantalla de bienvenida donde los botones Login y CreateAccount volvían inmediatamente hacia atrás, y PR #1424 corrige desbordamiento de texto en la vista de sesión de Agentium AI.

Amber v6.0.0-pre1 añade claves de firma NIP-46 por conexión

Amber, la app firmante NIP-55 (Android Signer Application), lanzó v6.0.0-pre1 el 4 de abril. El cambio más importante son las claves de firma por conexión para el protocolo bunker NIP-46 (Nostr Remote Signing). En lugar de usar un único keypair para todas las conexiones bunker, Amber ahora genera una clave distinta para cada cliente conectado. Si una conexión de cliente se ve comprometida, el atacante no puede suplantar al firmante frente a otros clientes.

PR #377 añade comprobación e instalación de actualizaciones dentro de la app vía Zapstore, uniéndose a Notedeck en la adopción de distribución de apps nativa de Nostr. PR #375 maneja los fallos de AndroidKeyStore de forma elegante mostrando una advertencia a los usuarios en lugar de crashear, y PR #371 añade limpieza de base de datos con límites de tamaño y truncado de contenido para evitar crecimiento ilimitado del almacenamiento. El prerelease también incluye la whitelist de auth de relay NIP-42 y el login con frase mnemónica de recuperación del ciclo v5.0.x cubierto la semana pasada.

Nostria lanza app móvil nativa

Nostria, el cliente Nostr multiplataforma mantenido por SondreB, lanzó una app móvil nativa para Android con ocho releases desde v3.1.11 hasta v3.1.18. La capacidad nueva más importante es el soporte nativo de firmante local para firmantes como Amber y Aegis. También hay instaladores de escritorio para Linux, macOS y Windows. PR #610 reduce la presión de memoria del feed con límites adaptativos de runtime y limpieza de URLs de preview. v3.1.14 corrige la integración con Brainstorm, un proveedor de Web of Trust. v3.1.15 se centra en mejoras de música. La nueva app Android está disponible en Zapstore.

diVine 1.0.8 lanza subidas reanudables y DMs

diVine, el cliente de vídeo de formato corto, lanzó 1.0.8 con 87 PRs fusionados. Las subidas reanudables permiten a los creadores retomar subidas interrumpidas bloque por bloque en lugar de reiniciar desde cero en una conexión inestable. El release añade ajustes de calidad y bitrate de vídeo, doble toque para dar like y mejoras en DMs. PR #2722 añade un plugin de cámara para macOS para captura de vídeo de escritorio, y PR #2820 migra el sistema de notificaciones a una arquitectura BLoC con enriquecimiento y agrupación. El equipo también reemplazó stickers y arte de categorías generados por AI con SVGs de OpenMoji (PR #2844, PR #2842).

Manent v1.3.0 añade difuminado de notas sensibles y auth NIP-42

Manent, la app privada de notas cifradas y almacenamiento de archivos, lanzó v1.3.0 el 2 de abril. Los usuarios ahora pueden marcar notas como sensibles para difuminarlas en la vista de lista, manteniendo el contenido privado oculto durante el desplazamiento casual. El release también añade soporte para NIP-42 (Authentication of Clients to Relays), permitiendo a Manent autenticarse en relays que lo exigen antes de aceptar eventos. Manent almacena todos los datos cifrados en relays Nostr usando el keypair del usuario, así que el soporte NIP-42 amplía el conjunto de relays que puede usar para almacenamiento.

Wisp v0.17.0 a v0.17.3 añaden zaps en live streams y backup de billetera

Wisp, el cliente Nostr para Android, lanzó seis releases desde v0.16.2-beta hasta v0.17.3-beta con 44 PRs fusionados. El release v0.17.0 añade avisos de seguridad para backup de billetera y mejoras de UX para zaps. v0.17.1 añade visibilidad del chat de live stream entre plataformas y funcionalidad de zaps en live streams. PR #423 añade auto-búsqueda de perfiles, una animación de zap exitoso y mejoras en el estado de usuario. PR #426 corrige un crash por falta de memoria en computeId para eventos con listas grandes de tags. Los releases v0.16.x añadieron autocompletado de shortcode de emoji, mejoras de UI para chats grupales y filtrado de usuarios bloqueados en todas las rutas de notificaciones.

Mostro lanza deep links, tipos de cambio de Nostr y una corrección de pagos duplicados

Mostro, el exchange peer-to-peer de Bitcoin construido sobre Nostr, recibió actualizaciones tanto en su daemon de servidor como en su cliente móvil esta semana. Del lado del servidor, PR #692 evita que escrituras obsoletas de órdenes provoquen pagos duplicados, un bug que podía hacer que un vendedor recibiera el pago dos veces por la misma operación. PR #693 usa actualizaciones dirigidas para escrituras de dev_fee en lugar de sobrescribir la orden completa.

Mostro Mobile, el cliente Flutter, lanzó v1.2.3 el 3 de abril. El release maneja deep links de distintas instancias de Mostro, de modo que los usuarios puedan tocar enlaces que enruten al servidor de exchange correcto. PR #498 detecta DMs de admin y disputa en el pipeline de notificaciones en segundo plano, y la app ahora obtiene tipos de cambio desde Nostr con fallback HTTP/cache. PR #560 corrige un bug de bloqueo en la conexión al relay que impedía a la app alcanzar relays bajo ciertas condiciones de red.

Unfiltered v1.0.12 añade hashtags y comentarios

Unfiltered, un cliente Nostr enfocado en contenido visual, lanzó v1.0.12. PR #69 añade soporte para hashtags y PR #72 añade la capacidad de escribir y mostrar comentarios en publicaciones. PR #71 corrige problemas de navegación con múltiples imágenes por publicación.

Primal Android lanza uso compartido de billetera entre múltiples cuentas y auto-reconexión del firmante remoto

Primal, el cliente Nostr para Android, lanzó un release el 7 de abril. La actualización añade uso compartido de billetera entre múltiples cuentas y un menú overflow con eliminación de billetera en Dev Tools. El firmante remoto ahora se reconecta automáticamente cuando cae la conexión, y el servicio de billetera recibió su propia lógica de auto-reconexión. Entre las correcciones están que los votos zap de encuestas ya no aparecen como Top Zaps, la prevención de crashes por opciones vacías en encuestas, el ocultamiento del balance de billetera cuando no existe ninguna y el mapeo de tipos WalletException a códigos de error en respuestas NWC.

Titan v0.1.0 lanza navegador nativo nsite:// con registro de nombres en Bitcoin

Titan, un navegador nativo de escritorio para la web de Nostr, lanzó v0.1.0 el 7 de abril. Titan resuelve URLs nsite:// buscando nombres legibles por humanos registrados en Bitcoin, consultando relays Nostr para los eventos de contenido del sitio y renderizando páginas obtenidas desde servidores Blossom. El resultado es una experiencia de navegación web sin DNS, sin certificados TLS y sin proveedores de hosting. Los nombres se registran a través de una interfaz web vinculada a transacciones de Bitcoin. El release inicial se distribuye como .dmg de macOS (ARM, con soporte Rosetta 2 para Intel) e incluye soporte para entorno de desarrollo Nix.

Bikel v1.5.0 lanza servicio nativo en primer plano para teléfonos de-Googled

Bikel, un tracker de ciclismo descentralizado que convierte recorridos en datos de infraestructura pública usando Nostr, lanzó v1.5.0 el 4 de abril. El release migra desde Expo TaskManager dependiente de GMS a un servicio nativo personalizado en primer plano, asegurando seguimiento confiable de recorridos en segundo plano en LineageOS, GrapheneOS y otras variantes Android de-Googled. El Bikel Bot ganó una arquitectura de doble bolsillo con recolección autónoma de eCash mediante Cashu nutzaps. v1.4.3 y v1.4.2 corrigen la sincronización del tracking en segundo plano para entornos Android no estándar, y la app añade toggles para puntos de mapa de aparcabicis OSM.

Sprout añade soporte para NIP-01, NIP-23 y NIP-33

Sprout, una plataforma de comunicación de Block con relay Nostr integrado, lanzó desktop/v0.1.0-rc7 el 6 de abril. Esta semana el equipo añadió soporte para artículos kind 30023 de NIP-23 (Long-form Content), eventos reemplazables parametrizados de NIP-33 con reemplazo claveado por tag d, y notas de texto kind 1 y listas de follows kind 3 de NIP-01/NIP-02. El release también añade un sistema adaptativo de temas IDE con 54 temas, mejoras de UX para historial de workflows y ejecuciones de agentes, y una limpieza de la barra lateral de miembros.

mesh-llm v0.56.0 lanza protocolo de configuración distribuida

mesh-llm, un sistema distribuido de inferencia LLM que usa keypairs Nostr para identidad de nodo, lanzó v0.56.0 el 7 de abril. El release añade un protocolo de configuración distribuida con semántica de ownership, cuantización asimétrica de KV cache (claves Q8_0 con valores Q4) para reducir el uso de memoria, almacenamiento en keychain del sistema para keystores de identidad, streaming fluido de chat con cola de mensajes, y correcciones para el layout fullscreen y el particionado de KV cache con flash attention.

Nostr VPN lanza soporte de exit node y empaquetado para Umbrel

Nostr VPN, una VPN peer-to-peer que usa relays Nostr para señalización y WireGuard para túneles cifrados, lanzó seis releases desde v0.3.0 hasta v0.3.6 esta semana. El ciclo v0.3.x añade soporte de exit node en Windows y macOS, permitiendo que peers enruten tráfico de internet a través de otros nodos de la red. La propagación de invites y aliases ahora se sincroniza sobre Nostr, así que los usuarios pueden compartir acceso a la red sin coordinación fuera de banda. Los releases añaden empaquetado para Umbrel en despliegues autoalojados, NAT punch-through usando endpoints públicos recordados, limpieza automática de exit nodes obsoletos y una especificación de protocolo publicada. El proyecto también estabilizó el manejo de rutas en macOS con default routes autorreparables y reparación de underlay, y añadió una build Android vía Tauri. Hay builds disponibles para macOS (Apple Silicon e Intel), Linux (AppImage y .deb), Windows y Android.

Nymchat revierte Marmot y lanza chats grupales NIP-17 mejorados

Nymchat, el cliente de chat con capacidad MLS, lanzó 14 releases desde v3.56.261 hasta v3.58.274. El cambio más significativo es un giro de protocolo: v3.57.261 añadió chats grupales Marmot MLS, pero v3.58.268 revirtió a NIP-17 porque el soporte multidispositivo de Marmot aún no está terminado, lo que causaba problemas con la sincronización del estado del chat grupal entre dispositivos. v3.58.271 introduce chats grupales NIP-17 mejorados con claves efímeras rotativas para todos los mensajes, diseñadas para prevenir ataques de timing y correlación. La semana también trajo un sistema de amigos con control granular de ajustes (v3.58.262), sincronización de mensajes de chat grupal MLS en ajustes cifrados de la app, y múltiples correcciones de conectividad con relays.

nak v0.19.5 añade Blossom multi-servidor y publicación outbox

nak, el toolkit de línea de comandos Nostr de fiatjaf, lanzó v0.19.5. El comando blossom ahora acepta múltiples flags --server para subir a varios servidores Blossom en una sola llamada. Un nuevo comando key amplía claves parciales rellenando con ceros por la izquierda. El comando event gana un flag --outbox para publicar eventos a través del modelo outbox, y fetch ahora sale con código de error cuando no se devuelve ningún evento.

En desarrollo

White Noise añade previews con thumbhash y puente de registro push

White Noise, el mensajero privado construido sobre el protocolo Marmot, fusionó cinco PRs. PR #549 reemplaza previews de imagen con blurhash por thumbhash, un algoritmo más nuevo que produce imágenes placeholder más nítidas con un payload más pequeño (normalmente menos de 30 bytes frente a los ~50-100 bytes de blurhash) mientras preserva la proporción y distribución de color de la imagen original. Blurhash se mantiene como fallback para contenido antiguo. PR #548 actualiza whitenoise-rs y añade el puente de registro push MIP-05, conectando el trabajo de especificación de notificaciones push de la semana pasada con el cliente. PR #493 añade paginación basada en cursor para mensajes de chat, reemplazando la estrategia anterior de carga por un enfoque guiado por scroll.

Route96 añade configuración dinámica de etiquetas y limpieza de zero-egress

Route96, el servidor de medios Blossom de v0l, fusionó tres PRs. PR #80 añade configuración dinámica del modelo de etiquetas vía la API de admin, permitiendo a los operadores cambiar modelos de clasificación de contenido sin reiniciar el servidor. PR #82 añade campos de configuración de etiquetas a la UI de admin. PR #79 añade una política de limpieza de archivos zero-egress que elimina automáticamente archivos que nunca se han descargado, manteniendo bajos los costes de almacenamiento para los operadores.

Snort lanza endurecimiento de seguridad e invoices de pago para DVM

Snort, el cliente web, lanzó dos releases esta semana con una auditoría de seguridad integral. Las correcciones incluyen verificación de firma Schnorr, protección frente a falsificación de mensajes de relay NIP-46 (evitando que atacantes inyecten solicitudes de firma a través de relays comprometidos), mejoras en cifrado de PIN y eliminación de la confianza en delegación NIP-26. Las ganancias de rendimiento vienen de verificación Schnorr por lotes en WASM, rutas con lazy loading, traducciones precompiladas y eliminación de verificación doble por evento. PR #618 añade la visualización de invoice requerido por pago para kind 7000 de NIP-90 (Data Vending Machine), de modo que cuando un DVM responde con un requisito de pago, Snort renderiza el invoice Lightning directamente en el feed.

Damus mejora la compactación de LMDB

Damus, el cliente iOS, fusionó PR #3719 que añade compactación automática programada de LMDB, evitando que la base de datos local crezca sin límite con el tiempo. PR #3663 mejora BlurOverlayView para que parezca protector en lugar de roto.

Captain’s Log añade indexación de tags y sincronización de notas

Captain’s Log (Comet), la herramienta de escritura long-form nativa de Nostr de Nodetec, fusionó cuatro PRs esta semana. PR #156 añade indexación de tags y soporte de sincronización entre notas, PR #157 refactoriza la sincronización de notas y el manejo de tags, y PR #159 corrige la sincronización de notas enviadas a la papelera para que las notas eliminadas permanezcan eliminadas entre dispositivos.

Relatr v0.2.x rediseña su sistema de plugins con marketplace nativo de Nostr para validadores

Relatr, un motor de puntuación de Web of Trust que calcula rankings de confianza a partir de la distancia en el grafo social y validadores configurables, lanzó la familia v0.2.x con un rediseño completo del sistema de plugins. Los validadores ahora se escriben en Elo, un lenguaje portable de expresiones funcionales bifurcado para soportar capacidades de múltiples pasos orquestadas por el host (consultas Nostr, búsquedas en el grafo social, resolución NIP-05). Los plugins se publican como eventos Nostr kind 765, haciendo que la distribución sea nativa de la red de relays. Un nuevo plugin marketplace permite a operadores descubrir, instalar y ponderar validadores desde el navegador, con un CLI (relo) para autoría y publicación local. La arquitectura está aislada: los plugins solo pueden invocar capacidades que el host proporcione explícitamente, así que un validador malicioso no puede escapar de su ámbito definido. Las instancias de Relatr ahora pueden gestionarse desde el sitio web, con visibilidad completa de qué plugins componen el algoritmo de puntuación y sus pesos individuales.

Shopstr mejora la navegación móvil y el control de acceso

Shopstr, el marketplace nativo de Nostr para comprar y vender con Bitcoin, empujó 158 commits en su app principal y el proyecto complementario Milk Market esta semana. Las correcciones incluyen mejoras en el layout de comunidades en móvil, comportamiento de cerrar menú al navegar y autocierre de dropdowns. Las rutas protegidas ya no pueden abrirse vía URL directa sin iniciar sesión, y la lógica de coincidencia de slugs ahora maneja correctamente múltiples coincidencias exactas.

Pollerama añade notificaciones, búsqueda de películas y UI de valoración

Pollerama, una app de encuestas, sondeos y ratings sociales construida sobre Nostr, añadió notificaciones de hilos, una función de búsqueda de películas y una revisión de la UI de valoración. El release también corrige problemas de carga del feed y actualiza versiones de dependencias.

Purser construye daemon de pagos nativo de Nostr con cifrado Marmot

Purser, un daemon de pagos nativo de Nostr diseñado como reemplazo de Zaprite, fusionó nueve PRs esta semana construyendo su arquitectura central. El proyecto usa MLS de Marmot vía MDK para mensajería cifrada entre comerciante y cliente, con Strike y Square como proveedores de pagos. Esta semana aterrizaron carga de config y catálogo, validación de esquema de mensajes, la capa de comunicación MDK, implementaciones de proveedores Strike y Square, un motor de polling, limitación anti-spam, persistencia de pagos pendientes y el pipeline de procesamiento de órdenes. Los 99 tests ahora ejercitan operaciones MLS reales de mdk-core después de que el equipo eliminara mock MLS en favor de cifrado real en modo local.

Vector refactoriza adjuntos de DMs y añade edición de perfil

Vector, el mensajero Nostr centrado en privacidad construido con Tauri, fusionó PR #55 refactorizando el frontend. El descifrado y guardado de adjuntos de DM se movió a la librería vector-core, y la app ahora soporta edición de perfil. La flag de cancelación de subida quedó correctamente conectada a través de TauriSendCallback, y se limpiaron callbacks de preview de adjuntos sin uso.

Trabajo de protocolo y especificación

Actualizaciones de NIPs

Cambios recientes en el repositorio de NIPs:

Fusionados:

NIP-58 (Badges): Profile Badges pasan a kind 10008, Badge Sets a kind 30008 (PR #2276): Migra Profile Badges desde kind 30008 a kind 10008 (un evento reemplazable, uno por pubkey) e introduce kind 30008 para Badge Sets. Antes, Profile Badges usaba el mismo kind (30008) que las definiciones de Badge, lo que los convertía en eventos reemplazables parametrizados claveados por un tag d. El nuevo kind 10008 es un evento reemplazable simple: uno por pubkey, sin necesidad de tag d. Los clientes consultan un único evento reemplazable por usuario en lugar de escanear eventos reemplazables parametrizados. Amethyst v1.07.3 ya distribuye esta migración.
NIP-34 (Git Stuff): Añadir listas de follows relacionadas con git (PR #2130): Añade convenciones de listas de follows para seguimiento de repositorios y issues de NIP-34. Los usuarios publican follow sets kind 30000 con tags d como git-repos o git-issues que contienen referencias de tag a a repositorios (kind 30617) que quieren seguir. Los clientes pueden suscribirse a estos follow sets para mostrar actividad de repositorios en el feed de un usuario, de forma similar a como funcionan las listas de contactos kind 3 para pubkeys.

PRs abiertos y discusiones:

NIP-AC: P2P Voice and Video Calls over WebRTC (PR #2301): Amplía el NIP-100 original (implementado por 0xChat) con tres cambios: migración a cifrado NIP-44 envuelto en gift wraps NIP-59 para eliminar fugas de metadatos, un flujo WebRTC especificado para la configuración de llamadas de voz y vídeo (offer, answer, candidatos ICE), y un modelo mesh de llamadas grupales donde cada peer establece una conexión WebRTC directa con todos los demás peers. La especificación no es retrocompatible con NIP-100. Amethyst ya está construyendo contra ella, con una suite de tests para la máquina de estados de llamadas (PR #2143) y manejo de ofertas de llamada obsoletas (PR #2164) aterrizando esta semana.
NIP-340 (FROST Quorum) (PR #2299): Propone convenciones para firma threshold de FROST (Flexible Round-Optimized Schnorr Threshold) en Nostr. FROST permite que un grupo de firmantes controle colectivamente una identidad Nostr donde cualquier subconjunto t-de-n puede firmar eventos sin reconstruir la clave privada completa. El NIP define cómo coordinar rondas de firma, distribuir key shares y publicar eventos firmados de forma threshold, construyendo sobre el trabajo del firmante Igloo del proyecto FROSTR.
NIP-5D (Nostr Web Applets) (PR #2303): Define un protocolo postMessage para aplicaciones web aisladas (“napplets”) que corren en iframes y se comunican con una aplicación anfitriona (“shell”). El shell proporciona a la napplet firma Nostr, acceso a relay y contexto de usuario mediante una API estructurada de mensajes, mientras el sandbox del iframe evita acceso directo a claves. Esto extiende el modelo de hosting de sitios web estáticos de NIP-5A hacia aplicaciones interactivas que pueden leer y escribir eventos Nostr. El NIP está en desarrollo activo con una implementación de runtime funcional.
NIP-5C (Scrolls) (PR #2281): Renombrado desde la propuesta anterior NIP-A5. Define convenciones para publicar y descubrir programas WebAssembly en Nostr. Los binarios WASM se almacenan como eventos Nostr, y los clientes pueden descargarlos y ejecutarlos en un runtime aislado. Una demo app muestra scrolls corriendo en el navegador, con programas de ejemplo publicados como eventos Nostr que cualquier cliente puede obtener y ejecutar.
NIP-85 (Trusted Assertions): Aclaraciones (PR #2304): Ajusta el lenguaje de la especificación alrededor de múltiples claves y relays por proveedor de servicio, aclarando cómo deberían manejar los clientes afirmaciones de proveedores que operan a través de varios pubkeys o endpoints de relay.
NIP-24 (Extra Metadata Fields): published_at para eventos reemplazables (PR #2300): Generaliza el tag published_at de NIP-23 (Long-form Content) a todos los eventos reemplazables y direccionables. El tag es solo de visualización: si published_at es igual a created_at, los clientes muestran el evento como “created” en ese momento; si difieren (porque el evento fue actualizado), los clientes pueden mostrar “updated” en su lugar. Esto permite que perfiles kind 0 muestren fechas de “joined at” y que otros eventos reemplazables preserven su marca de tiempo de publicación original a través de actualizaciones. Una propuesta complementaria de NIP-51 (PR #2302) añade el mismo tag a eventos de listas.
NIP-59 (Gift Wrap): kind efímero de gift wrap (PR #2245): Añade kind 21059 como contraparte efímera del gift wrap kind 1059 existente. Los eventos efímeros (kinds 20000-29999) siguen la semántica de NIP-01: no se espera que los relays los almacenen y pueden descartarlos tras la entrega. Esto permite a las aplicaciones enviar mensajes envueltos en gift wrap que desaparecen de los relays una vez entregados, reduciendo requisitos de almacenamiento para mensajería de alto volumen mientras conservan el mismo modelo de cifrado de tres capas que los DMs regulares de NIP-17.

OpenSats anuncia la decimosexta ola de grants de Nostr

OpenSats anunció su decimosexta ola de grants de Nostr el 8 de abril, financiando cuatro grants por primera vez y una renovación. Amethyst Desktop recibe financiación para que el colaborador Robert Nagy construya una app de escritorio independiente sobre los módulos Quartz y Commons, llevando el conjunto de funciones del cliente Android a interfaces guiadas por ratón con conexiones persistentes a relays. Nostr Mail recibe financiación para construir un sistema completo de email sobre Nostr usando eventos kind 1301 envueltos en gift wraps NIP-59, con un cliente Flutter y servidores puente SMTP para compatibilidad con Gmail/Outlook. Nostrord recibe financiación para un cliente grupal basado en relay NIP-29 en Kotlin Multiplatform con mensajería grupal estilo Discord, moderación e hilos. Nurunuru recibe financiación para construir una versión nativa iOS del cliente Nostr enfocado en japonés, modelado sobre la interfaz familiar de LINE, con login biométrico basado en passkeys para el onboarding. HAMSTR recibió una renovación de grant (financiado por primera vez en la undécima ola).

NIP en profundidad: NIP-17 (Private Direct Messages)

NIP-17 define el estándar actual para mensajes directos privados en Nostr. Reemplaza el esquema más antiguo de NIP-04 (Encrypted Direct Messages), que filtraba metadatos (remitente, receptor y timestamps eran visibles en los relays) y usaba una construcción de cifrado más débil. NIP-17 combina NIP-44 (Encrypted Payloads) para el cifrado con NIP-59 (Gift Wrap) para proteger metadatos, creando un sistema de tres capas donde los relays no pueden ver quién habla con quién.

El protocolo usa tres kinds de evento apilados uno dentro de otro. La capa más interna es el mensaje real, un evento kind 14 sin firma:

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744108800,
 "kind": 14,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef", "wss://inbox.example.com"],
 ["subject", "Project update"]
 ],
 "content": "The new relay config is deployed. Let me know if you see any issues.",
 "sig": ""
}

El evento kind 14 es deliberadamente unsigned (sig vacío). La especificación describe esto como una forma de proporcionar negabilidad, pero en la práctica la protección es limitada. El seal kind 13 que envuelve el rumor está firmado por la clave real del remitente. Un receptor puede mostrar el seal firmado a un tercero, probando que el remitente se comunicó con él, incluso sin revelar el contenido del mensaje. Con pruebas de conocimiento cero, un receptor puede probar el contenido exacto del mensaje sin revelar su propia clave privada. El rumor unsigned es como una carta sin firmar dentro de un sobre firmado: la firma del sobre vincula al remitente con el contenido. La verdadera negabilidad requeriría autenticación simétrica (como los HMAC de Signal), lo cual es incompatible con el modelo descentralizado de relay de Nostr, donde los mensajes deben ser autoautenticables. Las fortalezas reales de NIP-17 son la privacidad de metadatos y el secreto del contenido, no la negabilidad.

Este mensaje unsigned se envuelve luego en un seal kind 13, firmado por el remitente real y cifrado con NIP-44 para el receptor:

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744022400,
 "kind": 13,
 "tags": [],
 "content": "<nip44-encrypted kind 14 payload>",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

El seal no tiene tags, así que incluso si se descifrara no revelaría al receptor. El seal está firmado por la clave real del remitente, lo que permite al receptor autenticar el mensaje comprobando que el pubkey del seal coincide con el pubkey del kind 14 interno.

El seal se envuelve después en un gift wrap kind 1059, firmado por una clave aleatoria desechable y dirigido al receptor:

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744065600,
 "kind": 1059,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef"]
 ],
 "content": "<nip44-encrypted kind 13 payload>",
 "sig": "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210"
}

El pubkey del gift wrap es una clave aleatoria generada solo para este mensaje, y created_at se aleatoriza hasta dos días hacia el pasado. Esta es la capa más externa que los relays ven realmente: un mensaje de un pubkey desconocido dirigido al receptor, con un timestamp que no refleja cuándo se envió realmente el mensaje. El timestamp aleatorizado protege frente a análisis posteriores de eventos almacenados, pero un adversario conectado activamente a relays aún puede observar cuándo apareció por primera vez el gift wrap, así que esta defensa se limita a observadores pasivos que consultan datos del relay más tarde. Como el pubkey es aleatorio y el timestamp es falso, los relays no pueden determinar el remitente real. Para leer el mensaje, el receptor descifra el gift wrap usando su propia clave y el pubkey aleatorio, encuentra el seal dentro, descifra el seal usando su propia clave y el pubkey del remitente tomado del seal, y encuentra dentro el mensaje kind 14.

NIP-17 no proporciona forward secrecy. Todos los mensajes se cifran usando el keypair estático de Nostr (mediante la derivación de claves de NIP-44 a partir de las claves del remitente y el receptor). Si una clave privada se ve comprometida, todo mensaje pasado y futuro cifrado para esa clave puede descifrarse. Es un tradeoff deliberado: como el cifrado depende solo del nsec, un usuario que haga backup de su nsec puede recuperar todo su historial de mensajes desde cualquier relay que aún almacene los gift wraps. Protocolos como MLS (usado por Marmot) proporcionan forward secrecy mediante rotación de material de claves, pero al coste de requerir sincronización de estado y de hacer imposible la recuperación histórica de mensajes después de la rotación de claves.

NIP-17 también define kind 15 para mensajes de archivo cifrados, que añade tags file-type, encryption-algorithm, decryption-key y decryption-nonce para que el receptor pueda descifrar un archivo adjunto cifrado con AES-GCM antes de subirse a un servidor Blossom. Kind 10050 se usa para publicar la lista preferida de relays de DM del usuario, para que los remitentes sepan dónde entregar gift wraps. El conjunto de tags pubkey + p en un mensaje define una sala de chat; añadir o eliminar un participante crea una sala nueva con historial limpio.

Las implementaciones cubren a la mayoría de los clientes principales. nospeak usa NIP-17 para toda la mensajería uno a uno. Flotilla usa NIP-17 para sus DMs con proof-of-work. Amethyst, Primal, Nostur, Damus, noStrudel y Coracle implementan NIP-17 como su protocolo principal de DM. La especificación también soporta mensajes que desaparecen estableciendo un tag expiration en el gift wrap.

NIP en profundidad: NIP-46 (Nostr Remote Signing)

NIP-46 define un protocolo para separar la clave privada del usuario de la aplicación cliente. En lugar de pegar un nsec en una web app, el usuario ejecuta un firmante remoto (también llamado “bunker”) que guarda la clave privada y responde a solicitudes de firma a través de relays Nostr. El cliente nunca ve la clave privada. Esto reduce la superficie de ataque: un cliente comprometido puede solicitar firmas, pero no puede extraer la propia clave.

El protocolo usa kind 24133 tanto para solicitudes como para respuestas, cifradas con NIP-44 (Encrypted Payloads). Un cliente genera un client-keypair desechable para la sesión y se comunica con el firmante remoto mediante mensajes cifrados con NIP-44 etiquetados con los pubkeys de ambos. Aquí hay una solicitud de firma de un cliente a un firmante remoto:

{
 "id": "aa11bb22cc33dd44ee55ff6677889900aabbccdd11223344556677889900aabb",
 "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
 "created_at": 1744108800,
 "kind": 24133,
 "tags": [
 ["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]
 ],
 "content": "<nip44-encrypted JSON-RPC request>",
 "sig": "1122334455667788990011223344556677889900aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff0011223344556677"
}

El content cifrado contiene una estructura similar a JSON-RPC:

{
 "id": "random-request-id-1",
 "method": "sign_event",
 "params": ["{\"kind\":1,\"content\":\"Hello from remote signing\",\"tags\":[],\"created_at\":1744108800}"]
}

El firmante remoto descifra la solicitud, la presenta al usuario para su aprobación (o la aprueba automáticamente según los permisos configurados), firma el evento con la clave privada del usuario y devuelve el evento firmado en una respuesta:

{
 "id": "bb22cc33dd44ee55ff6677889900aabb11223344556677889900aabbccddeeff",
 "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
 "created_at": 1744108801,
 "kind": 24133,
 "tags": [
 ["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]
 ],
 "content": "<nip44-encrypted JSON-RPC response>",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Las conexiones pueden iniciarse desde cualquiera de los dos lados. Un firmante remoto proporciona una URL bunker:// que contiene su pubkey e información de relay. Un cliente proporciona una URL nostrconnect:// con su pubkey de cliente, relays y un secreto para verificación de conexión. El parámetro secret evita suplantación de conexión: solo la parte que recibió la URL fuera de banda puede completar el handshake.

Se definen ocho métodos: connect para establecer la sesión, sign_event para firmar eventos, get_public_key para conocer el pubkey del usuario, ping para keepalive, nip04_encrypt/nip04_decrypt para cifrado legacy, nip44_encrypt/nip44_decrypt para cifrado actual, y switch_relays para gestión de relays. La migración de relay la maneja el firmante remoto, que puede mover la conexión a nuevos relays con el tiempo sin romper la sesión.

Los clientes solicitan capacidades específicas en el momento de conexión mediante un sistema de permisos. Una cadena de permisos como nip44_encrypt,sign_event:1,sign_event:14 solicita acceso a cifrado NIP-44 y acceso de firma solo para eventos kind 1 y kind 14. El firmante remoto puede aceptar, rechazar o modificar estos permisos. Esto significa que un cliente web para leer y publicar notas podría recibir solo permiso sign_event:1, mientras que un cliente de DM podría recibir también permisos sign_event:14 y nip44_encrypt.

Amber implementa NIP-46 en Android, y su v6.0.0-pre1 de esta semana añade claves de firma por conexión para aislar clientes entre sí. nsec.app (antes Nostr Connect) proporciona un bunker basado en web. nostr-tools incluye BunkerSigner para clientes JavaScript, y el PR #530 de la semana pasada añadió skipSwitchRelays para gestión manual de relays. El protocolo también soporta desafíos de auth: cuando un firmante remoto necesita autenticación adicional (contraseña, biometría o token hardware), responde con una auth_url que el cliente abre en un navegador para que el usuario la complete.

Eso es todo por esta semana. ¿Estás construyendo algo o tienes noticias para compartir? Envíanos un DM en Nostr o encuéntranos en nostrcompass.org.

Nostr Compass #16

Wed, 01 Apr 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Amethyst lanza v1.07.0 con notas fijadas, gestión de relays vía NIP-86, y soporte de NIP-62 Request to Vanish. NIP-5A (Static Websites) se fusiona en el repositorio de NIPs, definiendo cómo alojar sitios web bajo pares de claves Nostr usando almacenamiento Blossom. Flotilla lanza v1.7.0 con salas de voz, login con email/contraseña, y DMs con proof-of-work. White Noise corrige churn de relays en v2026.3.23, nospeak lanza su 1.0.0 como mensajero cifrado sin registro. Nymchat adopta Marmot para chats de grupo cifrados con MLS con fallback a NIP-17. Calendar by Form* alcanza v1.0.0 con listas privadas de calendario e importación ICS, Amber añade recuperación por mnemónico y whitelisting de autenticación de relay NIP-42, y la especificación Marmot mueve los KeyPackages a eventos direccionables mientras ajusta el formato de notificaciones push MIP-05.

Noticias

Amethyst lanza notas fijadas, gestión de relays y Request to Vanish

Amethyst, el cliente Android mantenido por vitorpamplona, lanzó seis versiones en tres días, desde v1.07.0 hasta v1.07.5. El conjunto principal de funciones abarca seis superficies de protocolo: notas fijadas, una pantalla dedicada de feed de encuestas, soporte de NIP-62 (Request to Vanish) para solicitar la eliminación completa de eventos de los relays, NIP-86 (Relay Management API) desde dentro del cliente, evaluaciones de NIP-66 (Relay Discovery and Liveness Monitoring) en la pantalla de información del relay, y visualización de información de miembros de NIP-43 (Relay Access Metadata and Requests).

NIP-86 define una interfaz JSON-RPC para operadores de relays, permitiendo a los clientes enviar comandos administrativos como banear pubkeys, permitir pubkeys y listar usuarios baneados sobre una API estandarizada. Amethyst ahora expone esto directamente en su UI de gestión de relays, así que los usuarios que ejecutan sus propios relays pueden administrarlos desde el mismo cliente que usan para publicar. PR #2039 reemplaza el antiguo diálogo de entrada hex para banear y permitir pubkeys con un diálogo interactivo de búsqueda de usuarios.

v1.07.2 añadió subidas desde teclado GIF y corrigió una regresión de firma donde las respuestas de rechazo de Amber se interpretaban mal porque versiones antiguas de Amber devolvían una cadena vacía para el campo rejected (PR #2042). v1.07.5 corrige un crash en la subida de imágenes. Los lanzamientos v1.06.2 y v1.06.3 a principios de la semana añadieron un selector de tipo de encuesta para encuestas de elección única vs. múltiple, drag-to-seek en barras de progreso de vídeo, y mejoras de publicación anónima.

NIP-5A se fusiona, trayendo sitios web estáticos a Nostr

NIP-5A (Static Websites) se fusionó vía PR #1538, definiendo cómo alojar sitios web estáticos bajo pares de claves Nostr. La especificación usa dos kinds de evento: kind 15128 para un sitio raíz, uno por pubkey, y kind 35128 para sitios nombrados identificados por una etiqueta d. Cada manifiesto mapea rutas URL a hashes SHA256, con etiquetas server opcionales apuntando a hosts de almacenamiento Blossom donde viven los archivos reales.

El modelo de hosting funciona así: un autor construye un sitio estático, sube los archivos a uno o más servidores Blossom, y luego publica un evento de manifiesto firmado que mapea rutas a hashes de contenido. Un servidor host recibe solicitudes web, resuelve la pubkey del autor desde el subdominio, obtiene el manifiesto desde la lista de relays NIP-65 del autor, y sirve los archivos descargando los blobs correspondientes desde Blossom. El sitio permanece bajo el control del autor porque solo esa clave puede firmar un manifiesto actualizado. El servidor host es reemplazable porque cualquier servidor que entienda NIP-5A puede servir el mismo sitio desde el mismo manifiesto.

La especificación se construye sobre infraestructura que ya existía. nsite, la implementación host de referencia de NIP-5A construida por lez, y nsite-manager, la UI de gestión de hzrd149, ya estaban funcionando antes de que el NIP se fusionara. La fusión hace oficiales los kinds de evento y las reglas de resolución de URL, lo que da a segundas y terceras implementaciones un objetivo estable.

White Noise corrige churn de relays y amplía los controles del cliente

White Noise, el mensajero privado construido sobre el protocolo Marmot, lanzó v2026.3.23 el 25 de marzo. El trabajo principal es estabilidad de relays. El login ya no espera a que termine cada publicación de lista de relays antes de continuar, porque la publicación de listas ahora usa lógica de quorum y reintenta el resto en segundo plano. Las operaciones puntuales de fetch y publish usan sesiones efímeras acotadas de relay en lugar de quedarse en el pool de larga duración, las sesiones restauradas recuperan su ruta de refresh de grupos después del arranque, y la app ahora expone diagnósticos e inspección de estado de relay a través de PR #495 y PR #502.

El mismo lanzamiento cambia cómo se comportan las conversaciones. PR #468 añade threading de respuestas NIP-C7 con etiquetas q y referencias nostr:nevent, PR #471 y PR #512 mantienen visibles los mensajes eliminados como marcadores de eliminado en lugar de quitarlos silenciosamente, PR #478 añade un flujo de reporte de errores en la app usando reportes anónimos con NIP-44 (Encrypted Payloads), y PR #486 añade chat de soporte directamente en el cliente. Los controles de mensajes orientados al usuario también aterrizaron en la misma ventana: PR #532 archiva chats, PR #541 añade mute y unmute con duraciones configurables, y PR #535 añade ajustes de notificaciones. PR #539 es trabajo preparatorio de registro push, conectando el registro APNs en iOS y la detección de Play Services en Android para que el registro pueda construirse encima. Del lado backend, el MDK (Marmot Development Kit) añadió primitivas de notificaciones push MIP-05 y un constructor de solicitudes de notificación (PR #235, PR #238), mientras whitenoise-rs añadió persistencia de registro de notificaciones push (PR #688), correcciones de cancelación de tareas en segundo plano (PR #696), y recuperación de key packages al iniciar (PR #693).

Nostr VPN alcanza v0.3.0 con sincronización de roster e invite v2

Siguiendo la cobertura de lanzamiento de la semana pasada, nostr-vpn, la VPN peer-to-peer que usa relays Nostr para señalización y WireGuard para túneles cifrados, continuó su ritmo rápido de lanzamientos, publicando versiones hasta v0.3.3. El salto de versión trae dos cambios disruptivos: el formato de invitación pasa a v2 (0.3.0 aún puede importar invitaciones v1, pero builds más antiguas no pueden importar invitaciones v2), y se añadió sincronización de roster firmada por administrador al protocolo de señalización. Los peers de versiones mixtas aún pueden conectarse en la capa mesh, pero los peers antiguos no participarán en la sincronización del roster.

La adición de sincronización de roster inicia el movimiento hacia una red gestionada. Un nodo administrador ahora puede empujar cambios de membresía a todos los peers, de modo que añadir o quitar un dispositivo de la red mesh no requiere que cada peer actualice manualmente su configuración. Las versiones v0.2.x durante la misma semana abordaron problemas específicos de despliegue: v0.2.22 a v0.2.28 corrigieron gestión de servicios Windows, añadieron scripts de build Android, y refinaron el flujo de emparejamiento LAN.

nospeak se lanza como un mensajero privado 1.0

nospeak, un mensajero privado construido sobre Nostr, lanzó su versión 1.0.0 el 27 de marzo. El proyecto incluye conversaciones uno a uno y de grupo, gestión de contactos, y una arquitectura auto-alojable. Los chats uno a uno usan NIP-17 (Private Direct Messages), que combina NIP-59 (Gift Wrap) con NIP-44 (Encrypted Payloads) para ocultar el remitente a los relays. Para medios, los archivos se cifran del lado del cliente con AES-256-GCM antes de subirlos a servidores Blossom. El lanzamiento también se distribuye como imagen de contenedor para auto-hosting.

Flotilla v1.7.0 añade salas de voz e inicio de sesión con email

Flotilla, el cliente estilo Discord de hodlbod para NIP-29 (Relay-based Groups) construido alrededor del modelo “relays as groups”, lanzó v1.7.0 y v1.7.1 el 30 y 31 de marzo. La funcionalidad principal son las salas de voz, contribuidas por mplorentz. Los usuarios ahora pueden unirse a llamadas de voz dentro de canales de grupo, con un diálogo de unión (PR #109) que les permite seleccionar un dispositivo de entrada de audio y elegir si quieren entrar a la llamada de voz o solo ver el chat de texto. El diálogo resuelve un problema de UX de la iteración anterior: entrar a una sala con voz habilitada forzaba antes la activación del micrófono incluso cuando el usuario solo quería leer mensajes o revisar ajustes de la sala.

El mismo lanzamiento añade login con email y contraseña como alternativa a autenticación basada en claves Nostr, proof-of-work en DMs, edición de DMs, onboarding y ajustes de relay rediseñados, detección de soporte Blossom vía supported_nips, mejoras de badges de notificación, fallback de notificaciones push Android, y correcciones de subida de archivos en Android. v1.7.1 sigue con una corrección para el fallback de registro de pomade al usar un firmante offline.

Hodlbod también está construyendo Caravel, un gestor de hosting y panel para relays zooid, que registró 40 commits esta semana en desarrollo inicial.

Nymchat lanza chats de grupo impulsados por Marmot

Nymchat (también conocido como NYM, Nostr Ynstant Messenger), el cliente de chat efímero conectado con Bitchat, anunció que todos los nuevos chats de grupo ahora usan el protocolo Marmot para mensajería cifrada con MLS. La integración usa kinds 443, 444 y 445 para key packages, mensajes welcome y mensajes de grupo respectivamente, proporcionando forward secrecy, seguridad post-compromise y fuga cero de metadatos. Si un receptor no puede usar MLS, Nymchat recurre a su ruta anterior de chats grupales NIP-17 (Private Direct Messages), que sigue estando cifrada de extremo a extremo pero carece de las propiedades de árbol ratchet de MLS.

Las series v3.55 y v3.56 de esta semana se enfocaron en casos límite de chats grupales: carga en dispositivos nuevos, comportamiento de salida, enrutamiento de notificaciones y conteo de badges no leídos. El mismo ciclo también corrigió una vulnerabilidad XSS por HTML sin escapar y añadió bloqueo de palabras clave y frases extendido a apodos de usuario. Esto convierte a Nymchat en otro cliente Marmot que se suma a White Noise y OpenChat, ampliando el conjunto de apps que pueden intercambiar mensajes grupales cifrados con MLS sobre el mismo protocolo.

Lanzamientos

Calendar by Form* v1.0.0

Calendar by Form*, la app de calendario descentralizada construida sobre NIP-52 (Calendar Events), alcanzó v1.0.0 el 29 de marzo. El lanzamiento añade listas privadas de calendario usando eventos Nostr cifrados (kind 32123) con auto-cifrado NIP-44 (Encrypted Payloads), de modo que los usuarios puedan organizar eventos en colecciones privadas sin exponer la agrupación a los relays. El mismo lanzamiento añade manejo de intents ICS para importar datos de calendario desde otras aplicaciones y solicitudes de invitación para compartir eventos entre usuarios.

Amber v5.0.2 a v5.0.4

Amber, la app firmante NIP-55 (Android Signer Application), lanzó tres point releases: v5.0.2, v5.0.3 y v5.0.4. La adición más visible es el login con frase mnemónica de recuperación (PR #358), que permite a los usuarios restaurar su firmante desde una seed phrase BIP39 en lugar de requerir la cadena nsec o ncryptsec en bruto. PR #357 añade una whitelist de autenticación de relay NIP-42, para que los usuarios puedan restringir qué relays están autorizados a solicitar autenticación del cliente. PR #353 añade selección de alcance de cifrado para permisos de descifrado, permitiendo a los usuarios conceder acceso de descifrado solo NIP-04 o solo NIP-44 en lugar de un permiso total. v5.0.4 corrige un bug donde el rechazo no respetaba los permisos acotados de cifrado y descifrado y mejora el rendimiento al recibir múltiples solicitudes de bunker.

Aegis v0.4.0

Aegis, el firmante multiplataforma, lanzó v0.4.0 el 26 de marzo. El lanzamiento añade modos de autorización Full y Selective en Ajustes y corrige múltiples problemas de escaneo de QR. Los commits de seguimiento d4f799f, 3313af9, 3b214e4, y e4f40b6 continúan el mismo trabajo con controles de selección por lotes, estadísticas reutilizables de selección en lote, APIs de selección por grupo completo, y estadísticas de uso por permiso en la página de permisos de la app.

Schemata v0.2.7 a v0.3.0

Schemata, las definiciones JSON Schema para validar kinds de eventos Nostr, lanzó cuatro versiones desde v0.2.7 hasta v0.3.0 con 21 PRs fusionados. El lanzamiento v0.3.0 trae correcciones de consistencia de patrones a través de URLs de relay, IDs hex, tipos MIME y cadenas BOLT-11 (PR #126), patrones centralizados de URL de relay (PR #117), schemas base de tipo bech32 para NIP-19 (PR #118), y validación para eventos de spell kind 777 (PR #125). El pipeline de lanzamiento ahora publica una nota kind 1 en Nostr en cada release (PR #120), así que el proyecto se anuncia a sí mismo a través del protocolo que valida. Schemata ahora soporta una docena de lenguajes más allá del paquete canónico JS/TS: Rust, Go, Python, Kotlin, Java, Swift, Dart, PHP, C#/.NET, C++, Ruby y C.

Junto a Schemata, el equipo publicó schemata-codegen, un generador experimental de código que adopta un enfoque diferente al mismo problema de validación. Mientras los paquetes validadores de Schemata requieren una dependencia de runtime de JSON Schema, schemata-codegen convierte schemas directamente en construcciones nativas tipadas del lenguaje (tuplas tipadas de tags, interfaces de kind y validadores de runtime), eliminando la necesidad de una biblioteca validadora en tiempo de ejecución. La comparación codegen-vs-validators documenta cuándo encaja cada enfoque.

BigBrotr v6.5.0 a v6.5.4

BigBrotr, la plataforma de analíticas de relays, lanzó cinco versiones desde v6.5.0 hasta v6.5.4. El lanzamiento v6.5.0 centraliza la validación de URLs de relay con una función factory parse_relay_url() y añade comprobación de longitud de URL y saneamiento de rutas. La infraestructura de monitoreo también recibió correcciones: los eventos de anuncio ahora incluyen etiquetas de ubicación geohash (siguiendo NIP-52), y se añadió protección de timeout a las pruebas de metadatos Geo/Net NIP-66 que no tenían plazo y podían colgarse indefinidamente. PR #410 actualiza PostgreSQL de 16 a 18, lo que trae el subsistema de I/O asíncrona y mayor throughput de WAL al pipeline de analíticas de relays.

El relay de Vertex Lab añade búsqueda de perfiles NIP-50

Vertex Lab, el equipo detrás de npub.world y el motor Web of Trust Vertex, anunció que wss://relay.vertexlab.io ahora soporta NIP-50 (Search) para consultas de perfiles. NIP-50 extiende el filtro estándar REQ de Nostr con un campo search, permitiendo a los clientes enviar consultas de búsqueda de texto completo a relays que soportan indexación. Añadir búsqueda de perfiles a un relay que ya sirve datos de Web of Trust significa que los clientes conectados a relay.vertexlab.io pueden descubrir usuarios por nombre o descripción sin un servicio de búsqueda separado.

Hashtree v0.2.17 y v0.2.18 lanzan mesh WebRTC e Iris Desktop

Hashtree, el sistema de almacenamiento de blobs direccionados por contenido de mmalmi que publica raíces de Merkle en Nostr, lanzó v0.2.17 y v0.2.18 el 31 de marzo. Los dos lanzamientos coronan un sprint de 30 commits que añade tres capacidades distintas. Primero, el crate hashtree-webrtc (renombrado a hashtree-network en v0.2.18) añade distribución peer-to-peer de blobs basada en WebRTC con señalización mesh unificada a través del CLI Rust, el harness de simulación y el cliente TypeScript. Segundo, el pipeline de lanzamiento ahora construye artefactos Windows (zip del CLI e instalador de Iris), llevando cobertura multiplataforma a macOS, Linux y Windows. Tercero, ambos lanzamientos empaquetan Iris Desktop 0.1.0, el cliente social Nostr de mmalmi, como assets AppImage, .deb e instalador Windows junto al CLI de hashtree. Hashtree fue cubierto por primera vez en Newsletter #10 cuando se lanzó como un store compatible con Blossom basado en filesystem. La capa WebRTC es el primer paso hacia distribución de contenido peer-to-peer sin depender de servidores Blossom centralizados.

Nostr Mail Client v0.7.0 a v0.7.2

Nostr Mail Client, el cliente estilo correo construido con Flutter sobre identidades Nostr, lanzó v0.7.0, v0.7.1 y v0.7.2 en tres días. El trabajo de producto visible se centró en onboarding (PR #9) y edición de perfil (PR #10), que son piezas básicas para cualquier cliente que intente presentar Nostr como un buzón. Las versiones posteriores empaquetaron ese trabajo en nuevas builds Android y Linux.

Wisp v0.14.0 a v0.16.1

Wisp, el cliente Nostr Android, lanzó 13 versiones más desde v0.14.0-beta hasta v0.16.3-beta. El trabajo de esta semana incluye correcciones de JSON rumor NIP-17 (PR #385), badges de repost en tarjetas de galería (PR #383), detalles expandibles de reacciones (PR #382), sets persistentes de emoji (PR #381), y controles de autoplay de vídeo (PR #380). El más reciente v0.16.3-beta también corrige shortcodes de emoji personalizados con guiones y etiquetas de emoji faltantes.

Primal Android 3.0.17

Primal Android lanzó 3.0.17 el 24 de marzo. PR #1000 mapea tipos de WalletException a códigos de error en respuestas NWC, dando a clientes NIP-47 información estructurada de fallos en lugar de errores genéricos. PR #995 corrige votos zap de encuestas apareciendo como Top Zaps, y PR #998 oculta el balance de billetera y botones de acción cuando no hay billetera configurada.

OpenChat v0.2.4 a v0.3.0

OpenChat, el cliente de chat basado en Avalonia construido sobre el stack Marmot, lanzó seis versiones desde v0.2.4 hasta v0.3.0 en cuatro días. El log de commits cuenta la historia de un cliente llenando los huecos entre “Marmot funciona” y “alguien puede usar esto diariamente”. Aterrizó la autenticación de relay NIP-42, seguida de una UI selector de relay con filtrado de eventos duplicados. Los mensajes de voz ganaron pausa, reanudación, seek y visualización de tiempo. La ruta del firmante se endureció: se corrigieron las conexiones Amber con un formato URI NIP-46 actualizado, el WebSocket se reconecta automáticamente antes de enviar solicitudes, y las solicitudes Amber duplicadas ahora se capturan comprobando respuestas repetidas. Del lado de almacenamiento, Linux y macOS recibieron almacenamiento seguro AES-256-GCM con claves respaldadas por archivo, y la obtención de metadatos de usuario ahora usa descubrimiento de relay NIP-65 y guarda resultados en caché en una base de datos local.

Igloo Signer 1.1

Igloo, el firmante threshold iOS FROST del proyecto FROSTR, lanzó v1.1 el 28 de marzo. Las firmas FROST (Flexible Round-Optimized Schnorr Threshold) permiten a un grupo de firmantes controlar colectivamente un par de claves Nostr, donde cualquier t-de-n participantes puede firmar un evento sin que ninguna parte tenga la clave privada completa. Igloo es una de las primeras implementaciones móviles de este enfoque para Nostr.

nak v0.19.3 y v0.19.4

nak, el toolkit de línea de comandos Nostr de fiatjaf, lanzó v0.19.3 y v0.19.4 el 26 y 30 de marzo. Ambos lanzamientos corrigen condiciones de panic: PR #118 reemplaza strings.Split con strings.Cut para prevenir un posible acceso fuera de rango, y PR #119 previene la misma clase de panic en el parseo de flags curl.

Flora v0.3.0

Flora, una extensión Chrome para grabación y compartición de pantalla descentralizada en Nostr, lanzó v0.3.0. El lanzamiento añade compartición privada de vídeo cifrado con modos público, no listado y privado. Las grabaciones privadas se cifran con AES-256-GCM y se entregan a los destinatarios vía NIP-17 (Private Direct Messages), de modo que la grabación nunca toca un servidor en texto claro.

YakiHonne Mobile 2.0.3

YakiHonne, el cliente móvil Nostr, lanzó 2.0.3 con reseñas de relays y solicitudes de unión, respuestas anidadas ampliadas, auto-traducción de notas, y soporte NWC multi-relay.

Actualizaciones de Proyectos

Zap Cooking añade zap polls y verificación de pagos Branta

Zap Cooking, la plataforma de recetas y contenido, fusionó 11 PRs esta semana enfocadas en contenido interactivo y flujos de pago. PR #277 añade zap polls (kind 6969), donde los usuarios votan enviando sats y pueden ver listas de votantes con fotos de perfil. PR #274 rediseña la UX de encuestas para que la interfaz de voto se integre de forma más natural en el feed.

PR #276 añade escaneo QR basado en cámara al flujo Send Payment e integra Branta, un servicio de verificación que comprueba si un destino de pago es legítimo antes del envío. Branta revisa destinos de pago contra phishing, address swaps e intercepciones man-in-the-middle antes de enviar. En la implementación de Zap Cooking, un nombre y logo de plataforma verificados por Branta aparecen directamente en el flujo de pago, y los códigos QR habilitados para Branta pueden llevar parámetros branta_id y branta_secret para que la billetera pueda verificar el destino desde el propio código escaneado.

diVine sienta bases para búsqueda unificada y endurece la entrega de vídeo

diVine, el cliente de vídeos cortos, pasó la semana ajustando búsqueda, navegación del feed, recuperación de reproducción y comportamiento de subida. PR #2540 sienta la base para una pantalla de búsqueda unificada, con secciones agrupadas para Videos, People y Tags. PR #2623 endurece la paginación a través de feeds de perfil, inbox, notificaciones, listas Discover, classic vines, búsqueda y feeds de grid componibles moviéndolos a un controlador compartido de paginación.

La entrega de vídeo también recibió varias correcciones concretas. PR #2643 reintenta fuentes derivadas alojadas por Divine en orden y recurre al blob crudo antes de mostrar un error de reproducción, de modo que fallos transitorios en una fuente no maten la reproducción inmediatamente. PR #2634 mantiene las subidas reanudables en la ruta propiedad de Divine cuando la detección de capacidades falla transitoriamente, reduciendo subidas rotas por fallos breves de red. PR #2637 también cambia la compuerta de contenido sensible para que los vídeos solo queden estrictamente bloqueados por etiquetas de advertencia reales, no solo por etiquetas de advertencia suministradas por el creador.

Shopstr añade storefronts personalizados y Milk Market sigue enviando trabajo de marketplace

Shopstr, el marketplace basado en Nostr, fusionó PR #245 añadiendo storefronts personalizados. Esto da a los vendedores una superficie inicial más distintiva en lugar de forzar cada listado a la misma presentación genérica.

Milk Market, un marketplace dedicado a la leche, continuó con optimizaciones de storefront (PR #18), recuperación de cuenta (PR #17), beef splits (PR #15), y correcciones de tipado de herramientas MCP (PR #16).

Notedeck añade efectos de sonido y extiende su actualizador hacia Android

Notedeck, el cliente de escritorio del equipo Damus, fusionó PR #1412 añadiendo un subsistema de efectos de sonido con sonidos de interacción de UI usando rodio, y PR #1399 con actualizaciones de Agentium incluyendo un flag de título CLI y carpetas de sesión colapsables. Un PR #1417 abierto propone auto-actualización APK vía Nostr/Zapstore en Android, construyendo sobre el trabajo de actualizador nativo de Nostr de Notedeck de Newsletter #14.

Nostria añade pistas de relay en reposts y alineación con NIP-98

Nostria fusionó PR #583 añadiendo pistas de relay NIP-18 (Reposts) a etiquetas e de repost para eventos kind 6 y kind 16, PR #582 alineando la autenticación HTTP de Brainstorm (kind 27235) con las etiquetas requeridas de NIP-98 (HTTP Auth), y PR #576 añadiendo pruebas de validación de schemas Schemata. El cambio NIP-98 significa que Nostria puede autenticarse ante servicios externos usando el mismo formato de autenticación HTTP que otros clientes usan.

Nostr-Doc añade empaquetado de escritorio y trabajo offline-first

Nostr-Doc, el editor colaborativo de Form*, tuvo una semana ocupada de empaquetado y trabajo de editor. commit fcdc00a añade una app de escritorio, commit 3977a8e inicia trabajo de app nativa, y commit 413a030 empuja la app hacia comportamiento offline-first. Del lado del editor, commit 1855ce8 añade guardado con Ctrl+S, advertencias de guardado, correcciones de preview de enlaces y renderizado corregido de texto tachado.

rust-nostr optimiza el parseo NIP-21 y añade soporte NIP-62 del lado relay

rust-nostr fusionó ocho PRs. El más notable es PR #1308, que optimiza el parseo de URI NIP-21 en PublicKey::parse alineándolo con el rendimiento estándar de parseo bech32. Antes, los URI NIP-21 tardaban aproximadamente el doble que las claves bech32 en bruto. El proyecto también tiene cuatro PRs abiertos añadiendo soporte específico de relay para NIP-62 (Request to Vanish) a través de los backends memory, LMDB, SQLite y database test (PR #1315, PR #1316, PR #1317, PR #1318).

nostr-tools añade control de relay bunker y corrige parseo multi-relay NIP-47

nostr-tools fusionó PR #530 añadiendo skipSwitchRelays a BunkerSignerParams para gestión manual de relays, y PR #529 corrigiendo el parseo de cadenas de conexión NIP-47 (Nostr Wallet Connect) para soportar múltiples relays como permite la especificación.

Nostrability integra datos de auditoría Sherlock y publica visión general de Schemata

Nostrability, el tracker de interoperabilidad para clientes Nostr, fusionó 14 PRs. PR #306 integra estadísticas de escaneo Sherlock en el dashboard. Sherlock es la herramienta de auditoría automatizada de Nostrability que se conecta a clientes Nostr, captura los eventos que publican, y valida cada evento contra las definiciones JSON Schema de Schemata para detectar violaciones de especificación. El dashboard ahora muestra tasas de fallo de schema por cliente (PR #315) para que los desarrolladores puedan ver qué kinds de evento su cliente implementa mal. PR #323 renueva el flujo de publicación Nostr para que los anuncios de release corran como un job separado que no puede ser cancelado por pasos previos de CI.

elsat también publicó Schemata for nostr devs el 30 de marzo, describiendo cómo encajan schemata, schemata-codegen y Sherlock y dando números actuales de cobertura: 179 schemas de kinds de evento a través de 65 NIPs, 154 schemas de tags, 13 mensajes de protocolo y 310 eventos de ejemplo.

Nalgorithm añade generación de digest y caché local de puntuaciones

Nalgorithm, un nuevo proyecto de feed Nostr ordenado por relevancia, inició desarrollo público esta semana. commit cf6c501 establece la web app inicial que obtiene publicaciones de follows y las puntúa contra un prompt de preferencias definido por el usuario. commit 8e931b6 añade una herramienta CLI de digest que convierte las publicaciones mejor clasificadas en un resumen hablado, mientras commit 4cb9c63 añade caché de puntuaciones basada en archivos y evolución incremental del prompt aprendida a partir de likes recientes. commit c2edfb8 también deja de guardar en caché puntuaciones fallback de lotes fallidos, de modo que un fallo transitorio de scoring no aplaste permanentemente el ranking de una publicación.

TENEX añade vector store RAG y arranque MCP dirigido

TENEX, el framework de agentes nativo de Nostr que conecta agentes a canales Nostr vía Telegram, fusionó siete PRs esta semana. PR #101 añade una abstracción conectable de vector store con backends SQLite-vec, LanceDB y Qdrant, dando a los agentes retrieval-augmented generation sin bloquearse a una sola base de datos vectorial. PR #102 hace que el arranque MCP sea dirigido: solo se inician servidores MCP cuyas herramientas un agente realmente usa, en lugar de lanzar todos los servidores ansiosamente en la primera ejecución. PR #100 añade una herramienta send_message para que agentes con bindings de canal Telegram puedan empujar mensajes de forma proactiva en lugar de solo responder a mensajes entrantes. PR #106 evita un spawn de subproceso que disparaba una preasignación de memoria de 9 GB de Bun/JSC leyendo .git/HEAD directamente en lugar de ejecutar git branch.

Dart NDK mueve el firmante Amber y añade Alby Go 1-click

Dart NDK, el Nostr development kit para Flutter, lanzó 11 PRs fusionados. PR #525 mueve el soporte de firmante Amber al paquete ndk_flutter, y PR #552 añade conexión one-click a billetera Alby Go en la app de ejemplo. PR #502 añade un script install.sh para el CLI, y PR #523 elimina la dependencia del verificador Rust en favor de manejo nativo de assets.

Trabajo de Protocolo y Especificación

Marmot mueve KeyPackages a eventos direccionables y ajusta las notificaciones push

La especificación Marmot fusionó cuatro PRs que cambian cómo el protocolo maneja material de claves y membresía de grupo. PR #54 migra los eventos KeyPackage de kind:443 regular a kind:30443 direccionable con una etiqueta d, eliminando la necesidad de borrar eventos NIP-09 durante la rotación de claves. Los eventos direccionables se sobrescriben en su lugar, haciendo que la rotación sea autocontenida. PR #57 permite a usuarios no administradores confirmar propuestas SelfRemove (salida voluntaria de grupo), y PR #62 exige que los administradores renuncien a su estatus de admin antes de usar SelfRemove, previniendo que un admin desaparezca mientras aún mantiene privilegios elevados.

PR #61 ajusta el formato de notificaciones push MIP-05, haciendo explícitos la codificación base64 de blob único, el versionado, el formato wire del token y el uso de claves x-only. El efecto es una única representación wire definida para blobs de tokens y claves x-only a través de especificación, bibliotecas cliente y backends de apps. La implementación de estos cambios de especificación aterrizó en el stack White Noise esta semana y está cubierta en la sección anterior de White Noise v2026.3.23.

NIP Updates

Cambios recientes al repositorio de NIPs:

Fusionados:

NIP-5A: Static Websites (PR #1538): Define eventos de manifiesto kind 15128 (sitio raíz) y kind 35128 (sitio nombrado) para alojar sitios web estáticos bajo pares de claves Nostr usando almacenamiento Blossom. Ver el deep dive abajo.
NIP-30 (Custom Emoji): Permitir guiones en shortcodes (PR #2297): Actualiza la descripción de shortcode para incluir guiones. Los shortcodes con guiones se han usado en la práctica desde que se introdujo el NIP, así que la especificación ahora documenta el uso actual.

PRs Abiertos y Discusiones:

NIP-C1: Agent TUI Messages (PR #2295): Propone un formato estructurado de mensajes para que los agentes envíen elementos de UI interactivos a través de DMs cifrados, incluyendo payloads tipados text, buttons, card y table. El borrador mantiene todo dentro del contenido JSON de DMs existentes de NIP-17 y NIP-04. No define un nuevo kind de evento, y usa un formato simple de callback string para respuestas de botones.
NIP-95: Hybrid Peer-to-Peer Relay Protocol (PR #2293): Propone un modelo híbrido de relay donde los relays siguen siendo autoritativos pero también pueden coordinar distribución peer-to-peer de eventos recientes sobre WebRTC. El borrador introduce mensajes de relay como PEER_REGISTER, PEER_REQUEST y PEER_OFFER, con clientes estables actuando como Super Peers y el relay actuando como nodo semilla y fallback.
NIP-B9: Zap Poll Events (PR #2284): Reabre la antigua idea de NIP-69 zap-poll ahora que NIP-88 (Polls) cubre encuestas gratuitas. El borrador usa definiciones de encuesta kind 6969 y zaps kind 9734 como votos, convirtiéndolo en un sistema de encuestas pagadas con resistencia económica a Sybil. Complementa las encuestas gratuitas de una-clave-un-voto.
NIP-AD: Super Zap (PR #2289): Propone una convención donde los zaps enviados a la pubkey de un relay o a la pubkey de un cliente se muestran como notas promocionales especializadas, convirtiendo efectivamente los recibos de zap en una superficie publicitaria. Los operadores de relay y clientes publicarían perfiles con lud16, obtendrían esos recibos, extraerían el contenido incrustado de descripciones de zap, y opcionalmente fijarían umbrales mínimos de sats para suprimir spam.
NIP-XX: Agent Reputation Attestations (PR #2285): Propone kind 30085 como evento reemplazable parametrizado para atestaciones estructuradas de reputación sobre agentes Nostr. El borrador evita una puntuación global única haciendo que la reputación dependa del observador, añade decaimiento temporal para que las atestaciones antiguas pierdan peso, soporta valoraciones negativas con requisitos de evidencia, y esboza tanto puntuación ponderada simple como puntuación por diversidad de grafo para una mejor resistencia Sybil.
NIP-XX: Paid API Service Announcements (PR #2291): Propone eventos direccionables kind 31402 para anunciar APIs HTTP pagadas, con Nostr manejando descubrimiento y el pago a través de HTTP 402. El borrador está orientado a tags para que los relays puedan filtrar por métodos de pago, precios y capacidades sin parsear contenido JSON, y permite request y response schemas opcionales para que clientes o agentes puedan autogenerar llamadas.
NIP-XX: Key Derivation from LNURL-auth via SplitSig (PR #2294): Propone derivar un par de claves Nostr a partir de una firma ECDSA LNURL-auth combinada con un nonce aleatorio del lado cliente. La fórmula de derivación es nsec = SHA256(ecdsa_signature || nonce). El servidor ve la firma ECDSA (inherente al handshake LNURL-auth) pero nunca ve el nonce, y el navegador genera el nonce pero no controla la firma. Ninguna pieza por sí sola puede derivar el nsec. El resultado pretendido es que la misma billetera Lightning produzca la misma clave Nostr a través de dispositivos, con la billetera como ancla de recuperación y ningún servidor capaz de reconstruir la clave privada.
NIP-55: Documentar campo rejected (PR #2290): Documenta el campo rejected para respuestas de firmantes basadas en intent, formalizando el comportamiento que la corrección de Amethyst v1.07.x tuvo que sortear.

NIP Deep Dive: NIP-5A (Static Websites)

NIP-5A define cómo alojar sitios web estáticos bajo pares de claves Nostr, usando dos kinds de evento e infraestructura existente de almacenamiento de blobs para convertir eventos firmados en páginas web servidas. La especificación se fusionó el 25 de marzo vía PR #1538.

El modelo usa kind 15128 para un sitio raíz, uno por pubkey, y kind 35128 para sitios nombrados identificados por una etiqueta d. Cada manifiesto mapea rutas URL absolutas a hashes SHA256. Aquí hay un manifiesto de sitio raíz:

{
 "id": "5324d695ed7abf7cdd2a48deb881c93b7f4e43de702989bbfb55a1b97b35a3de",
 "pubkey": "266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5",
 "created_at": 1743465600,
 "kind": 15128,
 "tags": [
 ["path", "/index.html", "186ea5fd14e88fd1ac49351759e7ab906fa94892002b60bf7f5a428f28ca1c99"],
 ["path", "/about.html", "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456"],
 ["path", "/favicon.ico", "fedcba0987654321fedcba0987654321fedcba0987654321fedcba0987654321"],
 ["server", "https://blossom.primal.net"],
 ["title", "My Nostr Site"],
 ["description", "A static website hosted on Nostr"],
 ["source", "https://github.com/lez/nsite"]
 ],
 "content": "",
 "sig": "f4e4a9e785f70e9fcaa855d769438fea10781e84cd889e3fcb823774f83d094cf2c05d5a3ac4aebc1227a4ebc3d56867286c15a6df92d55045658bb428fd5fb5"
}

El flujo de servicio funciona en tres pasos. Un servidor host recibe una solicitud HTTP, extrae la pubkey del autor desde el subdominio (ya sea un npub para sitios raíz o una pubkey codificada en base36 para sitios nombrados), obtiene la lista de relays del autor vía NIP-65, y consulta el manifiesto del sitio. Una vez encontrado el manifiesto, el servidor resuelve la ruta solicitada a un hash de contenido, descarga el blob correspondiente desde el servidor o servidores Blossom listados en las etiquetas server, y lo devuelve.

El formato DNS del subdominio está especificado de forma estricta. Los sitios raíz usan el npub estándar como subdominio. Los sitios nombrados usan una codificación base36 de 50 caracteres de la pubkey en bruto seguida del valor de la etiqueta d, todo en una sola etiqueta DNS. Debido a que las etiquetas DNS están limitadas a 63 caracteres y la codificación base36 siempre ocupa 50, la etiqueta d queda limitada a 13 caracteres. La especificación también exige que las etiquetas d coincidan con ^[a-z0-9-]{1,13}$ y no terminen con guion, previniendo ambigüedades de resolución DNS.

Usar hashes de contenido significa que el mismo sitio puede servirse desde distintos servidores host, y la integridad del archivo es verificable sin confiar en el servidor. Un servidor host no necesita almacenar archivos por sí mismo. Los obtiene bajo demanda desde Blossom usando los hashes del manifiesto. Eso significa que el autor controla qué se sirve, el servidor Blossom almacena los archivos en bruto, y el servidor host solo conecta ambos. Cualquiera de estos tres componentes puede reemplazarse de forma independiente.

Las implementaciones existentes incluyen nsite, el servidor host que resuelve manifiestos y sirve archivos, y nsite-manager, una UI para construir y publicar manifiestos. La especificación también añadió una etiqueta source para enlazar al repositorio del código fuente del sitio, y la actualización de README fusionada por separado en PR #2286 registró tanto kind 15128 como 35128 en el índice de kinds del NIP.

NIP Deep Dive: NIP-62 (Request to Vanish)

NIP-62 define kind 62 como una solicitud a relays para eliminar todos los eventos de la pubkey que la solicita. La especificación tiene motivación legal: en jurisdicciones con leyes de derecho al olvido, disponer de una solicitud de eliminación estandarizada y firmada da a los operadores de relays una señal clara para actuar.

{
 "id": "a7b8c9d0e1f23456789012345678901234567890abcdef1234567890abcdef12",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1743465600,
 "kind": 62,
 "tags": [
 ["relay", "wss://relay.example.com"]
 ],
 "content": "Requesting deletion of all events from this relay.",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

La especificación separa solicitudes de desaparición dirigidas y globales. Una solicitud dirigida incluye etiquetas relay específicas identificando qué relays deben actuar. Una solicitud global usa la cadena literal ALL_RELAYS como valor de la etiqueta relay, pidiendo a cada relay que vea el evento que elimine todos los eventos de esa pubkey. Los relays que cumplan también deben asegurar que los eventos eliminados no puedan volver a re-publicarse en ese relay, haciendo que la eliminación quede pegajosa.

NIP-62 va más allá de NIP-09 (Event Deletion) tanto en alcance como en intención. NIP-09 permite borrar eventos individuales, y los relays MAY cumplir. NIP-62 solicita la eliminación de todo, y la especificación dice que los relays MUST cumplir si su URL está etiquetada. También pide a los relays borrar eventos NIP-59 (Gift Wrap) que tengan una p-tag con la pubkey solicitante, lo que significa que los DMs entrantes se limpian junto con los propios eventos del usuario. Publicar una eliminación NIP-09 contra una solicitud de desaparición NIP-62 no tiene efecto: una vez que desapareces, no puedes des-desaparecer borrando la solicitud de desaparición.

Esta semana, Amethyst v1.07.0 lanzó soporte del lado del cliente para NIP-62, permitiendo a los usuarios iniciar solicitudes de desaparición desde la app. Del lado relay, rust-nostr tiene cuatro PRs abiertos añadiendo soporte NIP-62 a través de los backends memory, LMDB, SQLite y database test (PR #1315, PR #1316, PR #1317, PR #1318). Esto coloca el trabajo de soporte en clientes y relays en la misma semana.

El diseño del protocolo plantea una tensión práctica. La propuesta de valor de Nostr incluye resistencia a la censura, lo que significa que los relays no deberían poder impedir la publicación. NIP-62 introduce un caso donde un relay MUST impedir la republicación de una pubkey específica. Las dos propiedades coexisten porque la solicitud está auto-dirigida: estás pidiendo la eliminación de tus propios eventos, no de los de otra persona. La propiedad de resistencia a la censura permanece intacta para todos excepto para la persona que explícitamente decidió salir.

Eso es todo por esta semana. ¿Estás construyendo algo o tienes noticias que compartir? Escríbenos vía DM NIP-17 (Private Direct Messages) o encuéntranos en Nostr.

Nostr Compass #15

Wed, 25 Mar 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Primal Android continúa su lanzamiento de billetera 3.0 con Follow Packs, enriquecimiento de zaps, y deep links primalconnect://. BigBrotr publica un análisis de nsec filtrados escaneando 41 millones de eventos a través de 1.085 relays, encontrando 16.599 claves privadas válidas, mientras npub.world integra advertencias de filtraciones en páginas de perfil la misma semana. Martti Malmi lanza nostr-vpn, una alternativa a Tailscale que señaliza sobre relays Nostr y crea túneles WireGuard, publicando 11 versiones en siete días. El equipo de Vector libera DOOM P2P de código abierto sobre Nostr, FIPS lanza v0.2.0, y Nostrability Schemata se expande a seis lenguajes en una semana.

Noticias

Primal añade Follow Packs, enriquecimiento de zaps y deep links

Siguiendo la cobertura de 3.0.7 de la semana pasada, Primal Android pasó esta semana en trabajo post-lanzamiento alrededor de onboarding, UX del compositor, y contexto de billetera. El onboarding rediseñado introduce Follow Packs (PR #949), un botón nativo de GIF se une al compositor de notas, un servicio de enriquecimiento de zaps (PR #979) anota transacciones de billetera con contexto de zap, y un protocolo de deep-linking primalconnect:// (PR #969) habilita navegación entre apps.

Primal iOS está lanzando el mismo trabajo a través de TestFlight en paralelo, con el cambio de billetera (PR #191), implementación de encuestas, y refactorización del onboarding aterrizando en la misma ventana.

BigBrotr mapea claves privadas expuestas a través de la red de relays

BigBrotr, la plataforma de analíticas de relays Nostr, publicó un análisis detallado de claves privadas expuestas en la red de relays. El estudio escaneó 41 millones de eventos de 1.085 relays, buscando cadenas nsec válidas incrustadas en el contenido de eventos, y encontró 16.599 claves privadas válidas. Ese número parece alarmante hasta que filtras un bot llamado “Mr.nsec” que representa el 92% de las coincidencias. Después de eliminar el tráfico de bots, solo 38 cuentas reales con más de 21.000 seguidores combinados tenían claves expuestas, y ninguna mostraba señales de saber que sus claves eran públicas.

El equipo construyó un nsec-leak-checker como servicio NIP-90 (Data Vending Machine), permitiendo a los usuarios verificar si su clave privada aparece en algún lugar del dataset escaneado sin revelar la clave al verificador. npub.world integró los datos de filtraciones la misma semana, mostrando banners de advertencia en páginas de perfil donde se detectaron claves expuestas. La combinación da a la red tanto una interfaz programática para DVMs y agentes como una advertencia legible para usuarios regulares. El dataset subyacente también alimenta BigBrotr v6.4.0, que añade vistas materializadas de eventos reemplazables y direccionables y una corrección de timeout de inactividad del sincronizador.

Nostr VPN se lanza como alternativa a Tailscale

Martti Malmi (mmalmi), creador de Iris, construyó y lanzó nostr-vpn, una VPN peer-to-peer que usa relays Nostr para señalización y WireGuard (vía boringtun) para túneles cifrados. La motivación fue directa: “Me molestó que Tailscale requiera cuentas de terceros, así que creé Nostr VPN.” La herramienta crea redes mesh entre dispositivos usando pares de claves Nostr como identidad, sin servidor de coordinación central.

El proyecto lanzó 11 versiones en siete días, desde v0.2.2 hasta v0.2.13. Ese sprint añadió soporte de Windows, emparejamiento LAN para descubrimiento de red local, y un sidecar Android para dispositivos móviles. La arquitectura es simple: dos dispositivos intercambian metadatos de conexión sobre relays Nostr, luego establecen un túnel WireGuard directo. Nostr maneja el descubrimiento y la señalización de NAT traversal. WireGuard maneja el tráfico real. La identidad es un par de claves Nostr.

Malmi también continuó impulsando nostr-double-ratchet, una biblioteca de canal de mensajería segura estilo Signal, lanzando seis versiones desde v0.0.86 hasta v0.0.93 durante la misma semana.

DOOM de código abierto corre peer-to-peer sobre Nostr

El equipo de Vector liberó una implementación multijugador peer-to-peer de DOOM que usa Nostr para descubrimiento de pares, Marmot para cifrado de extremo a extremo, e Iroh, la biblioteca de redes QUIC de n0, para transporte gossip. El juego se distribuye como un archivo WebXDC de 4,2 MB que puede enviarse dentro de mensajes de chat, sin requerir servidores para alojar o coordinar una partida.

El enfoque técnico reemplaza el netcode lockstep original de 1993 con un modelo de sincronización híbrida en tiempo real. Los jugadores se descubren mutuamente a través de consultas a relays Nostr, negocian sesiones a través de canales cifrados con Marmot, y luego pasan a la capa gossip QUIC de Iroh para el tráfico de juego de baja latencia. El stack usa Nostr para descubrimiento, Marmot para cifrado, e Iroh para transporte.

Vector también lanzó endurecimiento de seguridad esta semana. El lanzamiento añade un almacén de claves endurecido en memoria con protecciones anti-debug y zeroize para material criptográfico sensible, bloqueo de usuarios con filtrado completo de DMs y mensajes de grupo, y correcciones de canales en tiempo real WebXDC para Mini Apps.

FIPS v0.2.0 lanza transporte Tor, builds reproducibles y ejemplos sidecar

FIPS, el Free Internetworking Peering System y proyecto de redes mesh adyacente a Nostr, lanzó v0.2.0. El lanzamiento añade soporte de transporte Tor para enlaces mesh anonimizados, builds reproducibles, un ejemplo sidecar que conecta a través de un relay Nostr, y publicación de versiones Nostr en el flujo de trabajo de paquetes OpenWrt. El lanzamiento también corrige picos de jitter post-rekey causados por frames de ventana de drenaje. El formato de cable cambió desde v0.1.0, por lo que los nodos v0.1.0 existentes no pueden interoperar con v0.2.0 sin actualizar.

Nostrability Schemata se vuelve multilingüe

El proyecto Nostrability Schemata, que mantiene definiciones JSON Schema para validar kinds de eventos Nostr, se expandió de solo JavaScript a seis lenguajes en una semana. Nuevos paquetes se lanzaron para Rust, Go, Dart, Swift y Python, cada uno proporcionando tanto un paquete de datos como un validador. v0.2.6 también añadió 17 nuevos schemas de kinds de evento.

El tracker de interoperabilidad de Nostrability recibió una renovación en paralelo. Una nueva pestaña Novedades publica actualizaciones a través de un feed Atom y un evento Nostr, el filtrado por categoría de app permite a los visitantes profundizar en tipos de cliente específicos, y el tracker ahora auto-detecta lenguajes de programación desde metadatos de repositorios GitHub. Nostrability también tiene su propio npub ahora, haciendo al proyecto mismo descubrible a través del protocolo que documenta. Para autores de bibliotecas que trabajan a través de lenguajes, los paquetes de schemas multi-lenguaje significan que las mismas definiciones de kinds de evento están disponibles como importaciones nativas en lugar de requerir que cada proyecto mantenga su propia copia de schemas.

Lanzamientos

Amethyst v1.06.0 y v1.06.1

Amethyst, el cliente Android mantenido por vitorpamplona, lanzó v1.06.0 y v1.06.1 el 23 de marzo. La funcionalidad principal es soporte de encuestas usando datos de NIP-85 (Trusted Assertions) para votación ponderada, con tarjetas rediseñadas de encuestas y encuestas con zap. El nuevo renderizado da a las encuestas estándar y a las encuestas ponderadas por zap un diseño visual más limpio. v1.06.1 sigue con correcciones de crashes por modificación concurrente que abordan regresiones de estabilidad introducidas en la ruta de renderizado de encuestas.

Amber v5.0.0 y v5.0.1

Amber, la app firmante NIP-55 (Android Signer Application), promovió su reciente trabajo pre-release 4.1.x a estable con v5.0.0 el 18 de marzo. Ese lanzamiento estable lleva los cambios de autenticación de relay NIP-42, Tor integrado, permisos específicos por tipo de contenido, y almacenamiento cifrado de PIN cubiertos la semana pasada. v5.0.1 luego elimina el permiso de internet de la variante de build offline, para que esa build ya no pueda hacer solicitudes de red a nivel de permisos Android.

Mostro v0.17.0 y Mostro Mobile v1.2.2

Mostro, el exchange peer-to-peer de Bitcoin construido sobre Nostr, lanzó v0.17.0 el 18 de marzo. El lanzamiento del servidor continúa el trabajo de disputas y calificaciones del ciclo v0.16.x, añadiendo datos de reputación comercial más completos para compradores y vendedores como eventos Nostr. Mostro Mobile, el cliente Flutter, siguió con v1.2.2 el 23 de marzo, manteniendo la interfaz móvil sincronizada con los últimos cambios del protocolo.

Shosho v0.14.0

Shosho, la app de streaming en vivo de Nostr, lanzó v0.14.0 el 19 de marzo con el lanzamiento de Shosho Shop. El lanzamiento añade una pestaña Shop en perfiles, Shop en Explorar, y un botón In-Live Shop en lives y clips. Las notas de lanzamiento dicen que los “productos Nostr” existentes aparecen automáticamente y los compradores hacen clic para ir a la página de Plebeian Market del vendedor para la compra. Las notas de lanzamiento de Shosho no identifican el kind de evento de listado, por lo que aún no es posible confirmar si Shosho Shop lee los mismos listados clasificados NIP-99 que Shopstr soporta explícitamente en su README.

Applesauce v5.2.0

Applesauce, la colección de paquetes auxiliares de hzrd149 para construir aplicaciones Nostr, lanzó v5.2.0 el 22 de marzo. El lanzamiento abarca seis paquetes. El paquete SQLite corrige una colisión de restricción UNIQUE en etiquetas de eventos que causaba inserciones duplicadas. El paquete de firmantes añade AndroidNativeSigner, que envuelve la interfaz nativa de firmante Android NIP-55 para que las apps basadas en web-view puedan usar firma respaldada por hardware sin código bridge personalizado. El paquete de relay añade un campo challenge a los objetos de estado de relay y pool, rastreando el estado de autenticación NIP-42 para que las apps puedan detectar cuando un relay solicita autenticación y responder programáticamente. El paquete core gana los métodos isEventPointerSame e isAddressPointerSame para deduplicar referencias de eventos, y el paquete common añade user.blossomServers$ para resolver los servidores de medios Blossom de un usuario. Applesauce alimenta noStrudel, Satellite, y varios otros clientes web, así que estas correcciones se propagan a través de la capa de clientes web.

Wisp lanza 16 versiones en una semana

Wisp, el cliente Nostr para Android, lanzó 16 versiones desde v0.9.3-beta hasta v0.13.1-beta esta semana. Las adiciones de funcionalidades incluyen soporte multi-cuenta, un modo zen de notificaciones para interrupciones reducidas, borradores y publicaciones programadas, filtros de seguridad de contenido, y un nuevo ícono de llama.

Manent v1.2.0

Manent, la app de notas privadas cifradas y almacenamiento de archivos, lanzó v1.2.0 el 20 de marzo. El lanzamiento añade captura con cámara directamente desde la app, redimensionamiento de imágenes antes de subir para reducir costos de almacenamiento, y zoom con pellizco para revisar imágenes almacenadas. Manent almacena notas y archivos cifrados en relays Nostr usando el par de claves del usuario, haciendo de la app de teléfono o escritorio un cliente ligero que puede reconstruir su estado completo desde los datos del relay.

diVine 1.0.7

diVine, el cliente de vídeos cortos, lanzó 1.0.7 el 21 de marzo con un watchdog de reproducción de vídeo que auto-reanuda vídeos estancados. Después de la infraestructura de pruebas E2E y la carga directa de MP4 en v1.0.6, este lanzamiento apunta a la ruta de fallo de reproducción restante: vídeos que se detienen a mitad de stream sin lanzar un error.

Alby Extension v3.14.2

Alby Extension, la extensión de navegador NIP-07 (Browser Extension Signer), lanzó v3.14.2 el 18 de marzo con visualización de códigos QR de dirección Lightning y soporte de firma Schnorr. La adición de Schnorr alinea la extensión de navegador con el esquema de firma secp256k1 que Nostr usa nativamente.

NoorNote v0.6.5 a v0.6.11

NoorNote, la app de toma de notas, lanzó siete versiones desde v0.6.5 hasta v0.6.11. La adición principal son Follow Packs: paquetes curados de cuentas que los usuarios pueden explorar y suscribirse en bloque, similar a las Listas de Twitter pero diseñados para onboarding. Los usuarios pueden crear, editar y compartir Follow Packs con títulos, descripciones e imágenes de portada personalizados. La serie también actualiza la biblioteca Nostr subyacente de NDK v2 a v3, que trae manejo mejorado de conexión de relay y gestión de suscripciones. Notas con imagen y una experiencia rediseñada de conexión de relay completan la serie.

nak v0.19.1 y v0.19.2

nak, el toolkit de línea de comandos de Nostr de fiatjaf para interactuar con relays, codificar y decodificar identificadores NIP-19 (Bech32-Encoded Entities), firmar eventos, y consultar datos de relay, lanzó v0.19.1 y v0.19.2 el 17 y 20 de marzo. Los dos point releases siguen la adición de UI de foro de grupo de v0.19.0 de la semana pasada.

Calendar by Form* v0.2.1

Calendar by Form*, la app de calendario descentralizada construida sobre NIP-52 (Calendar Events), lanzó v0.2.1 el 20 de marzo. El lanzamiento corrige un problema de plantilla de notificaciones que afectaba los recordatorios de eventos. Calendar almacena eventos como eventos Nostr kind 31922 (basados en fecha) y kind 31923 (basados en hora), permitiendo a cualquier cliente Nostr renderizar datos de calendario si elige soportar esos kinds. La app está construida por el equipo Formstr, que también mantiene Formstr (formularios descentralizados) y Pollerama (encuestas).

NYM v3.50 a v3.53

NYM, el cliente de chat efímero ligero conectado con Bitchat, lanzó 28 versiones de v3.50 a v3.53 (las versiones de parche se incrementan rápidamente). La funcionalidad más notable es Nymbot, un bot de chat integrado que responde a menciones @nymbot en canales y proporciona funciones de estado y gestión de relays. Un “modo hardcore” genera un par de claves nuevo para cada mensaje enviado, haciendo los hilos de conversación no enlazables a nivel de identidad. La contrapartida es clara: pierdes identidad persistente pero ganas anonimato por mensaje. La capa de proxy de relay también recibió trabajo, con workers proxy de relay fragmentados para mejor conectividad, soporte de canales geohash, y tolerancia de desviación de reloj para nodos con relojes de sistema imprecisos.

Actualizaciones de Proyectos

Ditto añade puente Bluesky e integración con Wikipedia

Ditto, el cliente social Nostr personalizable del equipo Soapbox, registró más de 300 commits esta semana a través de tres líneas de funcionalidades distintas. La primera es un puente Bluesky (19 commits) que renderiza publicaciones de Bluesky en línea como hilos completos estilo feed, añade navegación lateral a una página de descubrimiento Bluesky respaldada por el feed oficial Discover (whats-hot), y conecta botones de acción para comentar, compartir, reaccionar y copiar enlaces. Cuando un usuario responde a una publicación de Bluesky desde dentro de Ditto, el modal de composición muestra un aviso de descargo señalando la naturaleza cross-protocol de la interacción. Las reacciones kind 17 de NIP-73 (External Content IDs) alimentan el modelo cross-protocol: un usuario Nostr reacciona a una publicación de Bluesky, y la reacción se almacena como un evento Nostr estándar referenciando el identificador de contenido externo. Este es el mismo patrón NIP-73 que podría conectar reacciones a cualquier contenido externo, desde publicaciones de Bluesky hasta vídeos de YouTube o páginas web.

La segunda línea es una integración con Wikipedia (9 commits). Ditto ahora renderiza contenido rico de artículos de Wikipedia en páginas de detalle en lugar de previsualizaciones de enlace genéricas, añade autocompletado de búsqueda con miniaturas de artículos, y proporciona una página /wikipedia que extrae contenido destacado de la API de Wikipedia. Los resultados de Wikipedia y Archive.org también aparecen en el dropdown de autocompletado de búsqueda general. La tercera línea es soporte de plataforma iOS vía Capacitor, con un script de build remoto y configuración de plataforma aterrizando junto a una renovación de UI (55 commits) que reemplaza encabezados backdrop-blur con un nuevo diseño de navegación basado en arco a través de cada página de la app. Los 314 commits mueven a Ditto de un cliente solo Nostr hacia un agregador multi-protocolo que trata Bluesky y Wikipedia como fuentes de contenido de primera clase junto al feed Nostr.

Pika construye un pipeline CI de forge NIP-34

Pika, la app de mensajería cifrada basada en Marmot, fusionó 33 PRs esta semana enfocados en un forge NIP-34 auto-alojado con CI pre-merge. El forge es una capa de alojamiento git que recibe parches como eventos NIP-34, ejecuta verificaciones CI antes del merge, y reporta estado estructurado de vuelta a través de eventos Nostr. PR #701 añade CI pre-merge y nocturno basado en carriles, donde cada ruta de código (Rust, TypeScript, builds Apple) corre en su propio carril con estado independiente de éxito/fallo. PR #715 recorta los agentes CI gestionados a contenedores Incus OpenClaw para aislamiento, y PR #733 añade un CLI ph forge para interactuar con el forge alojado desde la línea de comandos. PRs de soporte manejan permisos de escritura de repo para merges (PR #736), metadatos CI estructurados con insignias de estado en vivo (PR #722), splits de build nocturno Apple (PR #738), y correcciones de autenticación y búsqueda de ramas del forge (PR #734). Este es uno de los primeros sistemas CI/CD funcionales construidos sobre eventos git NIP-34, moviendo el alojamiento de código fuente basado en Nostr más allá del intercambio básico de parches hacia el flujo de trabajo de merge-y-test que los desarrolladores esperan de GitHub o GitLab.

Nostria añade comunidades, fragmentos de código y manejo de eventos de voz

Nostria, el cliente Nostr multiplataforma mantenido por sondreb, pasó esta semana extendiendo la superficie de la app más allá del filtrado Web of Trust cubierto en #14. La adición principal es una implementación completa de NIP-72 (Moderated Communities) con creación de comunidades, configuración de moderadores y relays, seguimiento de aprobación de publicaciones con previsualizaciones de imágenes, y una página de comunidad dedicada con pestañas de Publicaciones y Moderadores.

El mismo período de trabajo también añade renderizado y edición de fragmentos de código con un editor con resaltado de sintaxis, soporte de respuesta a eventos de voz para conversaciones de audio, configuración de relays de chat para mensajes directos, compartir canales a través de la Web Share API, un sistema de acoplamiento de barra de herramientas para el reproductor de medios, registro en la app para el último servicio Web of Trust de Brainstorm, flujos de enviar y recibir dinero en DMs usando NWC e invoices BOLT-11, manejo nativo de GIFs Nostr, y una ruta de importación RSS más robusta para músicos que puede recoger splits Lightning existentes de feeds de podcast.

Iteración rápida de nostr-vpn

Más allá del lanzamiento inicial, el log de commits de nostr-vpn revela los problemas específicos encontrados durante el despliegue real. v0.2.3 a v0.2.5 añadieron el script de instalación inicial y CLI multiplataforma. v0.2.6 y v0.2.7 trajeron soporte de Windows, que requirió entrecomillado de rutas UAC para escrituras de configuración y actualizaciones de configuración propiedad del daemon. v0.2.8 a v0.2.10 corrigieron acciones de servicio GUI de Windows, manejo de subprocesos CLI, y configuración de servicio con alcance de máquina. v0.2.12 reemplazó el descubrimiento LAN con emparejamiento LAN temporizado, un flujo iniciado por el usuario donde dos dispositivos en la misma red local se emparejan sin señalización de relay. El patrón es un libro de texto de pruebas de campo en etapas tempranas: cada versión apunta a un fallo de despliegue específico, la base de usuarios es lo suficientemente pequeña como para iterar diariamente, y el desarrollador usa la herramienta personalmente entre versiones.

Builds automatizados de Comet

Comet (anteriormente Captain’s Log), la herramienta de escritura de formato largo nativa de Nostr de Nodetec, produjo más de 40 builds alfa automatizados esta semana. Comet es una app de escritorio para escribir y publicar artículos NIP-23 (Long-form Content), con almacenamiento local de borradores, edición markdown, y publicación con un clic al conjunto de relays del usuario. El pipeline de build automatizado genera un lanzamiento etiquetado para cada commit a la rama principal, lo que hace que el conteo bruto de versiones sea engañoso como medida de velocidad de funcionalidades. Lo que los 40 builds sí muestran es que la app está bajo desarrollo activo diario, con cada commit probado, empaquetado y disponible para descarga en minutos.

Actualizaciones de NIPs

Cambios recientes al repositorio de NIPs durante la ventana del 17-24 de marzo:

No se fusionaron NIPs entre el 18 y el 24 de marzo.

PRs Abiertos y Discusiones actualizados durante la ventana:

NIP-AA: Agentes Autónomos en Nostr (PR #2259): Propone convenciones para agentes autónomos operando en la red Nostr. El PR define cómo los agentes se identifican, descubren servicios, y coordinan con otros agentes y humanos a través de eventos Nostr.
NIP-50 (Search): Extensiones de ordenamiento (PR #2283): Añade parámetros de ordenamiento a las consultas de búsqueda NIP-50, incluyendo top, hot, zaps y new. Esto permitiría a los clientes solicitar resultados clasificados de relays que soportan búsqueda de texto completo en lugar de ordenar del lado del cliente.
NIP-A5: Programas WASM (PR #2281): Propone una convención para publicar y descubrir programas WebAssembly en Nostr. Los binarios WASM podrían distribuirse como eventos Nostr, con relays sirviendo como capa de descubrimiento para código ejecutable portátil.
NIP-CF: Combine Forces napps interoperables (PR #2277): Define una convención para aplicaciones Nostr interoperables (“napps”) que pueden componer funcionalidad a través de diferentes clientes y servicios.
NIP de Snapshots (PR #2279): Propone un mecanismo para snapshots de estado de relay, para sincronización y respaldo de relays.
NIP de Checkpoints (PR #2278): Propone eventos de checkpoint para marcar estado de relay conocido como bueno, complementando la propuesta de snapshots.
NIP-58 (Badges): Refactorización de Badge Sets (PR #2276): Reestructura cómo se organizan y referencian las colecciones de insignias.
NIP-11 (Relay Information Document): Extensiones (PR #2280): Añade campos adicionales al documento de información del relay para metadatos de relay más ricos legibles por máquinas.

Cinco Años de Marzos de Nostr

El boletín del mes pasado cubrió cómo los febreros de Nostr progresaron desde la reescritura de NIP-01 (Basic Protocol Flow) pasando por la ola de Damus en la App Store hasta redes de malla y propuestas de agentes. Esta retrospectiva traza lo que sucedió cada marzo desde 2021 hasta 2026.

Marzo 2021: Dos Commits

Cuatro meses de existencia, el marzo de Nostr produjo exactamente dos commits al repositorio del protocolo, ambos el 4 de marzo. fiatjaf añadió enlaces a instancias de nostwitter, señalando a los primeros visitantes hacia despliegues funcionales, y añadió kind a la definición básica de filtro. Ese segundo commit es revelador: en marzo de 2021, aún no podías filtrar eventos Nostr por kind. El protocolo era así de primitivo. Dos o tres relays servían la red. El grupo de Telegram era el único canal de coordinación. El repositorio de NIPs no existía aún; las propuestas de protocolo vivían como archivos en el repo principal de nostr. fiatjaf era el único committer ese mes. Toda la producción de marzo 2021 de lo que se convertiría en un protocolo soportando VPNs, juegos multijugador y redes de malla cinco años después cabe en un solo git diff.

Marzo 2022: Construcción Pre-Damus

El repositorio principal del protocolo recibió cero commits en marzo de 2022. El desarrollo se había trasladado completamente a repositorios de herramientas. Branle, el cliente web Vue.js de fiatjaf y en ese momento la interfaz principal de Nostr, recibió 5 commits incluyendo soporte de despliegue Docker y correcciones de nombre de visualización NIP-05 (DNS-Based Verification) que eliminaron el prefijo _@ de las insignias de verificación. El more-speech de Robert C. Martin, el cliente de escritorio Clojure, registró 13 o más commits añadiendo threading, navegación por teclado, y una ventana de edición. El autor de software más famoso construyendo activamente en Nostr ese mes no era un desarrollador crypto sino la persona cuyo “Clean Code” ha vendido millones de copias, escribiendo un cliente Nostr en Clojure, una elección de lenguaje que te dice todo sobre la comunidad temprana: eran programadores con opiniones construyendo para sí mismos.

La red de relays se había expandido a aproximadamente 15 relays con una base de usuarios activos en los cientos. Damus no existía aún y no sería creado hasta abril de 2022. Nostream tampoco había aparecido. El trabajo del mes fue infraestructura: hacer las herramientas existentes más fiables para la pequeña comunidad que ya las usaba diariamente.

Marzo 2023: Infraestructura Post-Explosión

Un mes después de la ola de la App Store de Damus y la superación de 300.000 claves públicas, marzo 2023 fue sobre absorber el crecimiento. El repositorio de NIPs fusionó 28 pull requests, el segundo conteo mensual más alto en la historia del protocolo. NIP-51 (Lists) se fusionó, dando a los clientes colecciones estructuradas de follows, silenciados y marcadores. NIP-39 (External Identities in Profiles) aterrizó, NIP-78 (Application-Specific Data) proporcionó un kind de almacenamiento de propósito general para apps que necesitaban estado privado, y una reescritura de NIP-57 (Lightning Zaps) (PR #392) consolidó el flujo de zaps y clarificó la terminología. El PR más discutido del mes fue una propuesta alternativa de manejo de menciones (PR #381) con más de 50 comentarios.

El nuevo proyecto más trascendental fue NDK (Nostr Development Kit), la biblioteca TypeScript para conexiones de relay, firma de eventos, caché y gestión de suscripciones. pablof7z hizo el commit inicial el 16 de marzo de 2023, luego lo reescribió desde cero 11 días después el 27 de marzo (“básicamente otro commit inicial”), y tenía soporte LNURL y zap funcionando para el 31 de marzo. NDK pasó de nada a capaz de hacer zaps en 15 días. Cinco días después de la creación de NDK, el 21 de marzo, el equipo de Alby creó NWC (Nostr Wallet Connect), la implementación de referencia de NIP-47 que conectó billeteras Lightning a aplicaciones Nostr. Los dos proyectos que sustentarían los siguientes tres años de desarrollo Nostr basado en web nacieron en la misma ventana de 30 días. OpenSats aún no había lanzado su fondo Nostr; la primera ola no llegaría hasta julio de 2023, cuatro meses después de la creación de NDK.

Otras creaciones notables ese mes incluyeron NostrGit, NostrChat, un proyecto nostr-signing-device por LNbits, y nostrmo. Gossip, el cliente de escritorio Rust enfocado en selección inteligente de relays, lanzó tres versiones. El protocolo estaba en modo de construcción, y las herramientas creadas en marzo 2023 siguen en uso tres años después.

Marzo 2024: Maduración del Protocolo

Marzo 2024 fue sobre endurecer el protocolo para uso a largo plazo. El repositorio de NIPs fusionó 12 pull requests. El más significativo fue NIP-34 (Git Stuff), PR #997, que se fusionó el 5 de marzo después de más de 130 comentarios y 44 días de revisión. El hilo de discusión es una cápsula del tiempo de la comunidad debatiendo cómo construir un GitHub descentralizado. jb55 trazó paralelos con git send-email, Giszmo propuso usar hashes de root commit para descubrimiento cross-fork (“algo que GitHub no hace y nosotros podríamos”), mikedilger sugirió autenticación con eventos firmados NIP-98 (HTTP Auth) en lugar de claves SSH, y fiatjaf descartó rotundamente la necesidad de generalidad de control de versiones: “not for each version control system, just for git. No one uses the others.” A las pocas horas de abrir el PR, fiatjaf ya había cambiado nak, go-nostr y gitstr para aceptar parches sobre Nostr. DanConwayDev, cuyo ngit ya era becario de OpenSats, fue de los contribuidores más activos en la discusión. Un campo de bot para metadatos de perfil también se fusionó, dando a los clientes una forma legible por máquinas de distinguir cuentas automatizadas de humanas.

Amethyst lanzó v0.85.0 con soporte de eventos git, artículos wiki, renderizado de datos médicos, y edición de contenido en un solo lanzamiento. Mostro alcanzó v0.10.0. Nosflare, un relay Nostr serverless corriendo en Cloudflare Workers, demostró que la lógica de relay podía correr en el edge. OpenSats emitió una beca de Soporte a Largo Plazo para Bruno Garcia por contribuciones sostenidas al cliente Amethyst.

Marzo 2025: Expansión de Infraestructura

Marzo 2025 produjo 10 NIPs fusionados. El titular fue NIP-66 (Relay Discovery and Liveness Monitoring), PR #230, que se fusionó el 3 de marzo después de un viaje de 25 meses. dskvr propuso por primera vez el monitoreo de relays en febrero de 2023, le dijeron que podía hacerse del lado del cliente, explicó por qué conectarse a miles de relays a la vez era impráctico para clientes individuales, pasó por siete borradores completos, construyó nodos de monitoreo en ocho regiones geográficas (Noreste de EE.UU., Brasil, Oeste de EE.UU., Este de EE.UU., Australia, India, Corea, Sudáfrica), y esperó a que las herramientas de relay alcanzaran. Para cuando se fusionó, ya existían implementaciones en nostr.watch, relaypag.es, monitorlizard, Snort, noStrudel y Jumble. Los datos de NIP-66 luego alimentarían los benchmarks de outbox de Nostrability cubiertos en Newsletter #12. NIP-C0 (Code Snippets) también se fusionó (PR #1852, 63 comentarios), añadiendo eventos kind 1337 para compartir código fuente.

Los primeros servidores MCP para Nostr aparecieron este mes. nostr-mcp-server apareció el 23 de marzo y nwc-mcp-server el 14 de marzo, solo cuatro meses después de que Anthropic anunciara el Model Context Protocol en noviembre de 2024. Estos puentes tempranos precedieron al SDK completo de ContextVM y al trabajo de comercio de agentes que siguió a finales de 2025 y principios de 2026.

Gossip lanzó v0.14.0. Coracle, el cliente web de hodlbod con gestión de feeds consciente de relays, lanzó tres versiones. OpenSats anunció su décima ola de becas Nostr, continuando el pipeline de financiación que había estado funcionando desde mediados de 2023.

Marzo 2026: Convergencia

La actividad de marzo 2026 se extrae de los números de Nostr Compass #12 al #15 (este número).

Marzo 2026 es el mes donde hilos dispares convergieron en sistemas funcionales. El Marmot Development Kit lanzó su primera versión pública con medios cifrados, bindings multi-lenguaje, y una migración ChaCha20-Poly1305 que requirió actualizaciones coordinadas a través de especificación, Rust y TypeScript. Shopstr y Milk Market añadieron superficies de comercio MCP para compras impulsadas por agentes. La autenticación de relay NIP-42 aterrizó simultáneamente en Amber, strfry, y OAuth Bunker, cerrando el bucle entre software firmante, relay y bunker. Notedeck lanzó actualizaciones de software nativas de Nostr usando eventos de versión NIP-94 (File Metadata).

Esta semana, BigBrotr escaneó toda la red de relays buscando claves privadas filtradas y publicó tanto el análisis como un verificador DVM. Nostr VPN demostró que el modelo de claves de Nostr funciona para infraestructura de red, no solo redes sociales. DOOM demostró que el descubrimiento Nostr, el cifrado Marmot y el transporte QUIC pueden ejecutar un juego multijugador en tiempo real. Amber saltó a v5.0.0. Wisp lanzó 16 versiones en siete días. Veinticinco o más lanzamientos etiquetados vinieron de proyectos importantes en una sola semana.

Siete NIPs se fusionaron en los primeros 24 días del mes. El protocolo añadió marcado Djot de NIP-54 (Wiki), límites de entrada de NIP-19 (Bech32-Encoded Entities), lógica de consulta booleana de NIP-91 (AND Operator for Filters), y aserciones Web of Trust de NIP-85 (Trusted Assertions). Las propuestas abiertas iban desde agentes autónomos (NIP-AA) hasta programas WASM (NIP-A5) y extensiones de ordenamiento de búsqueda para NIP-50.

Mirando Hacia Adelante

Cinco marzos de Nostr trazan un arco claro. En 2021, una persona hizo dos commits a un protocolo que aún no podía filtrar eventos por kind. Para 2023, NDK y NWC nacieron con cinco días de diferencia para absorber la explosión post-Damus. Para 2024, un hilo de PR de 141 comentarios debatía cómo debería funcionar la colaboración git en un protocolo social. Para 2025, una especificación de monitoreo de relays que había sido pacientemente reescrita siete veces durante 25 meses finalmente se fusionó. En 2026, alguien se molestó porque Tailscale requería una cuenta y construyó una VPN usando pares de claves Nostr, mientras otro lanzó DOOM multijugador que descubre pares a través de relays Nostr y cifra el gameplay a través de Marmot. El escaneo de BigBrotr de 41 millones de eventos a través de 1.085 relays da una medida concreta de cuánto ha crecido la red. La superficie del protocolo en marzo de 2026 habría sido irreconocible para marzo de 2021, pero el modelo subyacente, eventos firmados por claves secp256k1 y distribuidos a través de relays, no ha cambiado.

Eso es todo por esta semana. ¿Estás construyendo algo o tienes noticias que compartir? Escríbenos vía DM NIP-17 (Private Direct Messages) o encuéntranos en Nostr.

Nostr Compass #14

Wed, 18 Mar 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Amethyst implementa soporte completo de métodos NIP-47 (Nostr Wallet Connect), Alby Hub añade soporte de múltiples relays en v1.21.6, Amber lanza v4.1.3 con Tor integrado y permisos de firmante más granulares, y Zeus elimina una ruta riesgosa de keysend NWC en PR #3835. Notedeck lanza un actualizador firmado en v0.8.0-rc2 que descubre versiones a través de eventos NIP-94 (File Metadata), mientras Damus corrige estado obsoleto de NIP-65 (Relay List Metadata), Nostrability Outbox revisa sus resultados de benchmark con datos corregidos, y Primal iOS prueba suscripciones directas a relays para DMs. Primal Android lanza 3.0.7, Route96 lanza v0.6.0, OpenChat sigue ajustando la interoperabilidad con Marmot en v0.1.0-alpha.11, Pika consolida su runtime en pika/v1.1.1, y Nostria añade filtrado Web of Trust con NIP-85 (Trusted Assertions). El repositorio de NIPs fusiona el marcado Djot para NIP-54 (Wiki) y un límite de entrada de 5000 caracteres para NIP-19 (Bech32-Encoded Entities).

Noticias

El soporte de Wallet Connect se amplía, y los clientes de billetera ajustan rutas de fallo

Amethyst, el cliente Android mantenido por vitorpamplona, fusionó PR #1828, que acerca su implementación de NIP-47 a la cobertura completa del protocolo. El parche añade make_invoice, lookup_invoice, list_transactions, get_balance, get_info, métodos de hold invoice, soporte de keysend con registros TLV, descubrimiento de capacidades vía kind 13194, y eventos de notificación en kind 23197 con NIP-44 (Encrypted Payloads). Esto da al cliente una superficie NWC mucho más amplia sin depender de extensiones específicas de cada app.

El stack de billeteras circundante se movió en la misma dirección. Alby Hub, el nodo Lightning auto-custodiado y servicio de billetera detrás de muchos despliegues NWC, lanzó v1.21.6 con soporte de múltiples relays y flujos de conexión y swap más simples. Zeus, la billetera Lightning móvil, fusionó PR #3835 eliminando el soporte de keysend NWC después de identificar una ruta silenciosa de drenaje de fondos en ese flujo, mientras también corregía el manejo de eventos pendientes y actividad Cashu. La conectividad de billeteras en Nostr se está ampliando, y los implementadores están eliminando flujos que son difíciles de asegurar.

Notedeck mueve el descubrimiento de versiones a Nostr

Siguiendo la cobertura de Notedeck de la semana pasada, Notedeck, el cliente de escritorio nativo del equipo Damus, lanzó v0.8.0-rc2 después de fusionar PR #1326. El nuevo actualizador se suscribe a eventos de versión kind 1063 firmados, coincide con la plataforma local, descarga el binario referenciado, y verifica su hash SHA256 antes de instalar. Los metadatos de versión ya no tienen que venir de la API de GitHub o un sitio web del proyecto. Una pubkey de versión de confianza y una conexión a relay son suficientes.

El mismo parche añade un CLI notedeck-release que publica esos eventos desde artefactos de versión de GitHub, lo que significa que el pipeline de versiones ahora tiene una ruta de publicación nativa de Nostr además de una ruta de descubrimiento nativa de Nostr. También acerca el modelo de actualizador de Damus y Notedeck al flujo de versiones firmadas publicadas por relay de Zapstore: la herramienta zsp de Zapstore ya maneja activos de software como eventos kind 1063 o 3063, así que esta ruta no está bloqueada a un solo cliente o publicador. El resto del release candidate es trabajo práctico de escritorio: columnas de follows, “Ver Como Usuario” en perfiles, soporte de NIP-59 (Gift Wrap), estadísticas de notas en tiempo real, y manejo de limitaciones de NIP-11 (Relay Information Document), pero el actualizador es la parte que probablemente sobrevivirá a este ciclo de versión.

El estado del relay se acerca al comportamiento en tiempo de ejecución

Damus fusionó PR #3665, reemplazando un ID de evento de lista de relays almacenado obsoleto con una consulta directa a la base de datos para el último evento kind 10002. Cuando el valor antiguo quedaba obsoleto, las operaciones de añadir y eliminar relays podían recurrir a listas bootstrap o de un año de antigüedad, lo que hacía que algunos cambios de relay parecieran exitosos mientras dejaban el estado activo sin cambiar. PR #3690 corrige una segunda ruta de fallo eliminando estado lock.mdb obsoleto durante la compactación LMDB para que la app no se bloquee con SIGBUS en el siguiente arranque.

Primal iOS abrió PR #194, que se suscribe directamente a los relays de escritura NIP-04 (Encrypted Direct Messages) de un interlocutor mientras una conversación está abierta, manteniendo el servidor de caché como respaldo. Nostur abrió PR #53, que combina puntuación aleatoria de relays, filtrado de actividad NIP-66 de nostr.watch, y muestreo de Thompson para cambiar la selección de relays de una heurística fija a una política aprendida. Los clientes han tratado la elección de relay como datos de configuración durante mucho tiempo. Más apps ahora lo tratan como estado en vivo que necesita lógica de medición y reparación.

Lanzamientos

Primal Android 3.0.7

Primal Android, el cliente Android de Primal, lanzó 3.0.7 con un nuevo ciclo de encuestas y billetera. PR #945 añade votación en encuestas basada en zaps, PR #948 pagina la carga de votos para que las encuestas más grandes sigan siendo usables, y PR #965 obtiene recibos de zap para todas las transacciones. El mismo lanzamiento también etiqueta eventos soportados con metadatos de cliente NIP-89 (Recommended Application Handlers) en PR #968, lo que ayuda a los clientes downstream a atribuir orígenes de eventos de forma más limpia.

Amber v4.1.3

Siguiendo la cobertura de Amber de la semana pasada, Amber, la app firmante Android para flujos NIP-55 (Android Signer Application), lanzó v4.1.3. El lanzamiento se construye sobre su reciente trabajo de autenticación de relay NIP-42 con más endurecimiento operacional: PR #327 añade Tor integrado junto al soporte de Orbot, PR #324 reemplaza permisos de cifrado gruesos basados en NIP con reglas específicas por tipo de contenido, y PR #336 elimina permisos de red de la variante offline mientras PR #335 añade verificaciones CI para mantenerlo así. PR #322 también mueve el almacenamiento de PIN a DataStore cifrado.

Este lanzamiento ajusta el límite del firmante en sí. Esto es útil para cualquier flujo Android que entregue claves reales o decisiones de autenticación de relay a Amber, porque la parte difícil no es solo lo que el firmante puede hacer. También es cuán estrechamente puede ser acotado.

Route96 v0.6.0

Siguiendo la cobertura de Route96 de la semana pasada, Route96, el servidor de medios que soporta Blossom y NIP-96 (HTTP File Storage), lanzó v0.6.0. El lanzamiento mueve la configuración y el estado de whitelist a la base de datos con recarga en caliente y añade políticas de retención para archivos fríos o envejecidos. También añade un endpoint GET /user/files más rico además de seguimiento de estadísticas de archivo para descargas y egress, lo que da a los operadores más visibilidad sobre cómo se usa su servidor de almacenamiento.

OpenChat v0.1.0-alpha.11

Siguiendo la cobertura de OpenChat de la semana pasada, OpenChat, el cliente de chat basado en Avalonia construido sobre el stack Marmot, lanzó v0.1.0-alpha.11 después de una semana de trabajo rápido de protocolo. Commit c33895d envuelve eventos Welcome en gift wrap NIP-59 y elimina los shims antiguos de normalización de etiquetas MIP-00, commit 2738ff4 completa la auditoría de cumplimiento MIP-02, y commit 8e470cf hace lo mismo para el cifrado de mensajes de grupo MIP-03. Commit 129ca37 también consolida el manejo de NIP-44 en la implementación compartida de marmot-cs, reduciendo el riesgo de divergencia criptográfica del lado del cliente.

nak v0.19.0 y v0.19.1

nak, el toolkit de línea de comandos para Nostr de fiatjaf, lanzó v0.19.0 y v0.19.1. La serie 0.19 añade una UI de foro de grupo en commit 5f4efdb, cambia las ediciones de metadatos de grupo a un flujo de reemplazo completo en commit da0b753, y reemplaza el manejo anterior de no-text con supported_kinds en commit bef67d3. Para implementadores de grupos, esto mantiene el CLI alineado con la dirección en que se mueven las especificaciones y clientes de grupo.

Actualizaciones de Proyectos

Amethyst

Siguiendo la cobertura de Amethyst de la semana pasada, Amethyst, el cliente Android con una de las superficies de protocolo más amplias en Nostr, siguió construyendo sobre su trabajo de billetera y relay después del parche NIP-47. PR #1853 añade consultas COUNT de NIP-45 (Event Counting) a través de las pantallas de gestión de relays, para que los usuarios puedan ver cuántos eventos tiene realmente cada relay para feed principal, notificaciones, DMs y datos de índice. PR #1849 añade subidas de archivos cifrados para chats NIP-17 (Private Direct Messages), con una ruta de reintento para subidas sin cifrar cuando un host de almacenamiento rechaza la versión cifrada.

PR #1791 también trae login completo de bunker de escritorio NIP-46 (Nostr Connect) con un indicador de latido, lo que importa porque los fallos de firma remota a menudo se sienten como roturas aleatorias de UI desde el lado del usuario. El cliente muestra si el firmante está vivo y cuán recientemente respondió, mientras también hace obvio cuando la sesión actual usa un bunker.

Nostria

Nostria, el cliente multiplataforma construido alrededor de un stack local-first, fusionó PR #561 añadiendo filtrado Web of Trust para feeds y respuestas en hilos. La funcionalidad usa los datos de clasificación del servicio de confianza existente y los expone tanto como filtro de feed como filtro de respuestas, ocultando autores cuya clasificación no supera el umbral mientras preserva la estructura del hilo cuando hay descendientes de confianza presentes. Esto da a los usuarios una capa intermedia entre “mostrar a todos” y curación hardcodeada basada en listas.

La misma semana también trajo PR #563, que añade filtrado de contenido y soporte de reposts a la página de resumen. Fuera de la lista de PRs rastreados, Nostria también ha estado completando más de su superficie de usuario avanzado. Ahora soporta el último servicio Web of Trust de Brainstorm con registro en la app, junto con flujos de enviar y recibir dinero en DMs usando NWC e invoices BOLT-11. También añade manejo nativo de GIFs a través del NIP de emoji y una ruta de importación RSS más robusta para músicos que puede recoger splits Lightning existentes de feeds de podcast. Nostria está tratando clasificación, medios, pagos y publicación como una superficie de app conectada.

Nostur

Nostur, el cliente iOS mantenido por nostur-com, abrió PR #53 para cambiar el enrutamiento outbox de un plan fijo a una política con puntuación. El parche añade puntuación aleatoria de relays, filtrado de actividad de relays NIP-66 con un feed en caché de nostr.watch, y muestreo de Thompson para que los datos de éxito y fallo de relay cambien las selecciones futuras. El diseño mantiene una válvula de seguridad cuando demasiados relays serían filtrados y preserva los relays .onion. Este es uno de los ejemplos actuales más claros de un cliente tratando la selección de relays como un sistema adaptativo.

Nostrability Outbox

Siguiendo el informe anterior de benchmarks Outbox, Nostrability Outbox, el proyecto de benchmarks y análisis enfocado en enrutamiento de clientes con NIP-65 y NIP-66, pasó la semana ajustando sus propias afirmaciones. PR #35 reemplaza resultados inflados de Thompson-sampling con un re-benchmark completo a través de 1.511 ejecuciones y recomienda la variante CG3 para enrutamiento estilo NDK. PR #43 añade comparaciones de decay y casos de uso, corrige un bug de envenenamiento de caché de 0 follows, y luego re-ejecuta el dataset Telluride después de fijar los TTLs de caché.

Esto no es trabajo de producto en el sentido habitual, pero importa para autores de clientes porque los números del proyecto ahora son más precisos y menos halagüeños en los lugares donde previamente habían sobreestimado. El resultado corregido sigue siendo útil. La selección aleatoria sigue superando al enrutamiento puramente determinista en los casos que Outbox le importan, el aprendizaje estilo Thompson puede mejorar materialmente la cobertura cuando los clientes persisten historial útil de relay, y el filtrado de actividad NIP-66 elimina tiempo perdido en relays muertos. El trabajo también se está convirtiendo en propuestas concretas de implementación, incluyendo NDK #387, Nostur #53, Amethyst #1833, rust-nostr #1282, welshman #53, y applesauce #54 más applesauce #55.

Backend de White Noise

whitenoise-rs, el backend Rust usado por White Noise y otras herramientas Marmot, fusionó dos parches de endurecimiento de límites alrededor del manejo de medios Blossom. PR #637 impone HTTPS en URLs de Blossom y añade un timeout de subida, mientras PR #642 limita las descargas de blob a 100 MiB para bloquear que descargas de medios sobredimensionados se conviertan en una ruta de denegación de servicio. Para software de mensajería privada, las URLs de medios son una de las interfaces más agudas entre la lógica de aplicación cifrada y la infraestructura de red no confiable. Esta semana el equipo ajustó ese borde.

rust-nostr

rust-nostr, la biblioteca de protocolo Rust, fusionó PR #1280 añadiendo constructores de conveniencia para LocalRelayBuilderNip42. Los nuevos helpers de lectura y escritura dan a las configuraciones de relay embebido y pruebas una forma más clara de convertir la política de autenticación NIP-42 en código. Este es un parche de biblioteca pequeño, pero importa para equipos construyendo relays locales o integrados en apps que necesitan autenticación activada sin repetir boilerplate cada vez.

Pika

Siguiendo la cobertura anterior de Pika, Pika, la app de mensajería basada en Marmot, lanzó pika/v1.1.1 y pikachat-v1.1.1 con un ciclo de lanzamiento enfocado en la convergencia del runtime. PR #542 introduce una fachada de runtime Marmot compartida para el CLI y sidecar, con el host de la app moviéndose a la misma superficie. PR #556 ajusta el ciclo de vida del agente OpenClaw y el estado de provisioning, mientras PR #600 añade restauración desde respaldo y seguridad de recuperación más estricta para entornos gestionados.

La superficie directa orientada al usuario aquí es más pequeña que en el último artículo sobre Pika, pero el cambio arquitectónico es significativo. Mover la lógica de grupo, medios, llamadas y sesión detrás de un runtime compartido reduce la posibilidad de que la app y el daemon diverjan a medida que el stack Marmot crece.

Actualizaciones de NIPs

Cambios recientes al repositorio de NIPs:

Fusionados:

NIP-54 (Wiki): Cambio de Asciidoc a Djot (PR #2242): El contenido wiki en kind 30818 ahora usa Djot como formato de marcado canónico. El texto fusionado añade comportamiento explícito de wikilinks, ejemplos de merge-request para kind 818, ejemplos de redirección para kind 30819, y ejemplos de normalización para scripts no latinos en etiquetas d. Esto da a los implementadores un objetivo de parseo más limpio que Asciidoc y elimina una ruta más de especificación que dependía de un toolchain centrado en Ruby.
NIP-19 (Bech32-Encoded Entities): Añadir límite de entrada (PR #2264): La especificación ahora recomienda limitar las cadenas de entidades codificadas en Bech32 a 5000 caracteres. Este es un cambio pequeño con valor real para parsers, porque las cadenas NIP-19 ahora aparecen en flujos QR, deep links, hojas de compartir, y entrada pegada por usuarios a través de muchos clientes.

PRs Abiertos y Discusiones:

Archivo de Clave Nostr para NIP-49 (Private Key Encryption) (PR #2269): Propone un formato de archivo .nostrkey para exportación e importación de claves cifradas con contraseña. Si se fusiona, daría a los clientes una ruta de respaldo basada en archivos más normal que copiar cadenas ncryptsec en bruto.
Consistencia del estado de membresía para NIP-43 (Relay Access Metadata and Requests) (PR #2267): Añade una sección aclarando que los relays deberían mantener un estado de membresía autoritativo por pubkey. Esto simplificaría la lógica de clientes de grupo alrededor de cambios de membresía e historial reproducido.
Guía de eliminación para NIP-17 (Private Direct Messages) (PR #2260): Propone una ruta concreta para editar y eliminar mensajes privados a través de eventos de eliminación envueltos en gift wrap. El trabajo aún está abierto, pero los autores de clientes necesitan una respuesta aquí si NIP-17 va a reemplazar completamente los flujos de DM más antiguos.
URI de share-intent para NIP-222 (PR #2266): El borrador estandarizaría cómo las apps móviles y de escritorio entregan contenido compartido a un cliente Nostr. Este es uno de los bordes de interoperabilidad más ásperos en los flujos actuales de app a app.

NIP Deep Dive: NIP-94 (File Metadata)

NIP-94 define kind 1063 como un evento de metadatos de primera clase para un archivo. La especificación da al evento su propio content legible por humanos más etiquetas legibles por máquinas para URL de descarga, tipo MIME, hashes, dimensiones, previsualizaciones, respaldos y pistas del servicio de almacenamiento. Esto importa porque el archivo se vuelve consultable en relays como su propio objeto. Un cliente no tiene que extraer metadatos del contenido circundante para entender qué es el archivo.

{
 "id": "6a92ef8d7c3a1b5d4e8f9a0b1c2d3e4f567890abcdef1234567890abcdef1234",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1742342400,
 "kind": 1063,
 "tags": [
 ["url", "https://downloads.example.org/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["m", "application/gzip"],
 ["x", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["ox", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["size", "48392011"],
 ["dim", "0x0"],
 ["magnet", "magnet:?xt=urn:btih:00112233445566778899aabbccddeeff00112233"],
 ["i", "00112233445566778899aabbccddeeff00112233"],
 ["blurhash", "LEHV6nWB2yk8pyo0adR*.7kCMdnj"],
 ["thumb", "https://downloads.example.org/notedeck/v0.8.0-rc2/thumb.png", "bbccddeeff00112233445566778899aabbccddeeff0011223344556677889900"],
 ["image", "https://downloads.example.org/notedeck/v0.8.0-rc2/screenshot.png", "ccddeeff00112233445566778899aabbccddeeff001122334455667788990011"],
 ["summary", "Signed macOS release artifact for Notedeck v0.8.0-rc2"],
 ["alt", "Notedeck desktop release archive"],
 ["fallback", "https://mirror.example.net/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["service", "nip96"]
 ],
 "content": "Notedeck macOS universal build",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

Las etiquetas hacen más trabajo del que aparentan a primera vista. x identifica el archivo servido, mientras ox identifica el archivo original antes de cualquier transformación del lado del servidor. Las etiquetas de previsualización permiten a los clientes construir índices de archivos navegables sin descargar el activo completo, y summary puede llevar un extracto breve junto a ellos. fallback da una segunda fuente cuando la URL principal falla, y service sugiere el protocolo de almacenamiento detrás del archivo, como NIP-96 u otro host. NIP-94 por lo tanto se sitúa debajo de las publicaciones sociales y por encima del almacenamiento en bruto. Describe el archivo, no la conversación alrededor del archivo.

Por eso el actualizador de Notedeck de esta semana es interesante. PR #1326 usa eventos kind 1063 firmados para el descubrimiento de versiones de software, luego verifica el binario descargado contra el SHA256 publicado. La misma forma de evento puede describir un artefacto de software o una subida de medios. NIP-94 es lo suficientemente antiguo como para ser estable, pero aún tiene espacio para crecer porque más proyectos están tratando los eventos de metadatos como un transporte para máquinas, no solo como decoración para personas.

NIP Deep Dive: NIP-54 (Wiki)

NIP-54 define kind 30818 como un evento de artículo wiki. La especificación trata la etiqueta d como el tema normalizado del artículo y permite que muchos autores publiquen entradas para el mismo tema. El cuerpo del artículo vive en content, mientras las etiquetas manejan identidad normalizada, título de visualización, resúmenes, y referencias a versiones anteriores. Esto significa que NIP-54 no es solo un formato de contenido. También es un problema de recuperación y clasificación, porque cada cliente aún tiene que decidir qué versión del artículo mostrar.

{
 "id": "8c94e5d1f2a300112233445566778899aabbccddeeff00112233445566778899",
 "pubkey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
 "created_at": 1742342400,
 "kind": 30818,
 "tags": [
 ["d", "nostr-wiki"],
 ["title", "Nostr Wiki"],
 ["summary", "Djot-formatted reference article about Nostr wiki events"],
 ["a", "30818:11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff:nostr-wiki", "wss://relay.example.org", "fork"],
 ["e", "11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff", "wss://relay.example.org", "fork"]
 ],
 "content": "Nostr is a [protocol][] for carrying events across relays.\n\n[protocol]: nostr:nevent1example",
 "sig": "33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889900112233cc44dd55ee66ff77889900aabbccddeeff00112233445566778899001122"
}

La fusión de esta semana cambia el marcado canónico de Asciidoc a Djot en PR #2242. Esto importa para implementadores porque Djot tiene una especificación standalone más ajustada y una historia de parser más simple entre lenguajes. El texto fusionado también aclara cómo resuelven los wikilinks de estilo referencia, cómo los merge requests usan kind 818, cómo las redirecciones usan kind 30819, y cómo debería comportarse la normalización de etiquetas d para scripts no latinos. Esas son las partes que hacen que dos clientes independientes coincidan en a qué artículo apunta un enlace.

NIP-54 también se sitúa en un lugar inusual en el protocolo. Un cliente wiki necesita renderizado de contenido, pero también necesita política de clasificación. Reacciones, listas de relays, listas de contactos, y señales de deferencia explícita, todo alimenta qué artículo gana para un tema dado. El cambio a Djot no resuelve ese problema de clasificación, pero sí elimina una de las ambigüedades de parser que estaba debajo. Por eso la fusión importa ahora: el cambio trata menos sobre un formato de prosa más bonito y más sobre hacer que el comportamiento wiki multi-cliente sea más fácil de implementar consistentemente.

¿Estás construyendo algo, o quieres que lo cubramos? Escríbenos vía DM NIP-17 en Nostr a npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.

Nostr Compass #13

Wed, 11 Mar 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Shopstr y Milk Market añaden superficies MCP para comercio impulsado por agentes, mientras OAuth Bunker, Amber y strfry agregan soporte de relay-auth y eventos protegidos de NIP-42 (Autenticación de clientes ante relays) a través de software de apps, firmantes y relays. Route96 publica dos lanzamientos centrados en etiquetado de IA, colas de moderación, hashing perceptual y documentación legible por máquina del servidor. Samizdat, ya activo en la web, lanzó su primera alfa de Android y luego añadió soporte de firmante NIP-55 (Aplicación firmante para Android). Formstr añade registro mediante NIP-49 (Cifrado de clave privada), Amethyst incorpora resolución NIP-05 (Verificación de dominio) basada en Namecoin, Mostro publica v0.16.4, y el repositorio de NIPs fusiona NIP-91 (Operador AND para filtros) y guía defensiva para NIP-66 (Descubrimiento de relays y monitoreo de disponibilidad).

Noticias

Shopstr y Milk Market abren superficies de comercio MCP

Shopstr, el marketplace peer-to-peer con pagos Lightning y Cashu, fusionó PR #234 (commit 94ef7d1), añadiendo un servidor MCP con autenticación por API key para gestión de cuentas por agentes. El cambio agrega .well-known/agent.json para descubrimiento de agentes, endpoints de onboarding y estado de MCP, rutas de creación de pedidos y verificación de pagos, herramientas dedicadas de compra y lectura, y una pantalla de ajustes para API keys. PR #236 amplía eso con acciones del lado del vendedor para mensajes, direcciones, actualizaciones de pedidos y selección de especificaciones de producto. Una corrección de seguridad en PR #235 reemplaza el hashing de API keys con SHA-256 de una sola iteración por PBKDF2 con sal y 100.000 iteraciones.

Los agentes pueden leer listados NIP-99 (Clasificados) y avanzar por el checkout usando los flujos de pago existentes de NIP-47 (Nostr Wallet Connect) y NIP-60 (Cashu Wallet) sin raspar páginas ni hacer ingeniería inversa del comportamiento del cliente.

Milk Market, un mercado de alimentos sobre Nostr en milk.market, incorporó la misma base de MCP y API keys en el commit da6c0b4. PR #10 añade pedidos por suscripción, cambios de dirección de envío después de la compra y manejo de checkout multi-comerciante y multi-moneda para Stripe y otras rutas de pago fiat. Un PR #11 posterior corrige un bug de inicialización de base de datos al arrancar, donde la tabla de publicaciones fallidas a relays no se creaba en instalaciones nuevas, causando errores 500 en la primera carga. La interfaz orientada a agentes funciona tanto con checkout nativo de Bitcoin en Shopstr como con checkout mixto fiat y Bitcoin en Milk Market.

NIP-42 relay-auth a través de bunker, firmante y relay

OAuth Bunker, un bunker NIP-46 (Nostr Connect) que conecta proveedores OAuth con firma Nostr, añadió login NIP-07 (Firmante de extensión de navegador), selección automática cuando solo existe una identidad y limpieza de identidades eliminadas (commit f0c7683). Cuando solo existe una identidad, el bunker ahora la selecciona automáticamente en lugar de mostrar un prompt. Eliminar una identidad también borra sus asignaciones y conexiones colgantes. El commit 6b8796c añade una ruta de configuración ALWAYS_ALLOWED_KINDS para usuarios asignados, con kind 30078 de datos específicos de app por defecto, de modo que las identidades delegadas puedan escribir en almacenamiento específico de la app sin aprobación por evento.

Amber, el principal firmante NIP-55 para Android, publicó v4.1.3-pre4 con cuatro pre-lanzamientos durante la semana. PR #317 añade manejo de autenticación de relay NIP-42 para solicitudes kind 22242. La implementación añade una nueva columna de base de datos para seguir permisos específicos por relay con un índice único sobre (pkKey, type, kind, relay). Los usuarios ven una pantalla dedicada de auth donde pueden permitir o denegar por relay o para todos los relays usando un alcance comodín *, y persistir esa decisión. Los permisos comodín limpian todas las entradas específicas por relay para un kind. PR #318 continúa ese trabajo refactorizando las pantallas de solicitudes multi-evento para mostrar detalles en línea usando tarjetas composables en lugar de navegar a una pantalla separada. El lanzamiento también actualiza los relays de perfil predeterminados, añade una vista de solicitudes en bottom sheet y corrige un crash en dispositivos MediaTek al desactivar StrongBox keystore.

Del lado del relay, strfry PR #156 implementa el manejo NIP-42 para NIP-70 (Eventos protegidos), y PR #176 rechaza reposts que incrustan eventos protegidos.

Notedeck añade límites de relay NIP-11 y funciones de Agentium

Notedeck, el cliente nativo de escritorio del equipo de Damus, fusionó 14 PRs esta semana. PR #1316 añade obtención de limitaciones de relay NIP-11 (Documento de información de relay), de modo que todos los relays outbox ahora respetan max_message_length y max_subscriptions del documento de información del relay. La implementación incluye procesamiento de trabajos en segundo plano, exponential backoff con jitter para reintentos de conexión y cabeceras HTTP Accept personalizadas. PR #1312 corrige un bug donde los DMs a veces no cargaban tras cambiar de cuenta, y PR #1333 añade un mecanismo de backoff a la comunicación multicast con relays para evitar spam de broadcast cuando hay errores.

El subsistema Agentium, la interfaz interna de agente de programación de Notedeck llamada “Dave”, recibió pegado de imágenes desde el portapapeles, configuraciones de ejecución con nombre que se sincronizan entre dispositivos mediante eventos kind 31991 (NIP-33 (Eventos reemplazables parametrizados)), un creador de git worktrees y un selector de modelo para elegir backends por sesión (PR #1336). PR #1338 integra egui_kittest para pruebas headless de UI, y PR #1339 añade una tarjeta de dashboard que rastrea la creación de nuevas listas de contactos por cliente. Un PR #1314 abierto porta la resolución NIP-05 basada en Namecoin de Amethyst a Notedeck con búsquedas ElectrumX, enrutamiento Tor por SOCKS5 e integración en la barra de búsqueda.

diVine publica v1.0.6 con infraestructura de pruebas E2E e importación NIP-49

diVine, el cliente de video corto en bucle que restaura archivos de Vine en divine.video, publicó v1.0.6 con 127 PRs fusionados. El lanzamiento añade importación de cuentas NIP-49, soporte externo de NIP-05, manejo multi-cuenta, builds para macOS y Linux experimental, y una biblioteca rediseñada de borradores y clips respaldada por almacenamiento local.

En el lado de ingeniería, PR #1928 añade una infraestructura completa de pruebas de integración E2E usando Patrol para automatización de UI nativa contra un stack backend en Docker (relay, API, Blossom, Postgres, Redis, ClickHouse). Cinco pruebas del recorrido de auth cubren registro, verificación, restablecimiento de contraseña, expiración de sesión y refresh de token. PR #2105 cambia la carga de video desde HLS-first a MP4 directo con fallback automático a HLS, reduciendo los tiempos de carga de 30-60 segundos a casi instantáneos. PR #2076 cachea la respuesta de la API del home feed en SharedPreferences para mostrarla de inmediato en arranque en frío. PR #2104 hace que las etiquetas ai-generated queden ocultas en los feeds, y PR #2100 añade un ajuste de seguridad para mostrar solo videos alojados por diVine. La migración del caché de perfiles de Hive a Drift sigue avanzando a través de PR #1881, PR #1883 y PR #1903, reemplazando aproximadamente 1.074 líneas de código Hive por DAOs de Drift.

Vector v0.3.2 publica sincronización NIP-77 Negentropy y mejoras MLS

Vector, el mensajero de escritorio centrado en privacidad que usa cifrado grupal MLS con NIP-17 (Mensajes directos privados) y NIP-44 (Payloads cifrados), publicó v0.3.2. El cambio principal es negentropy NIP-77 para sincronización de grupos MLS (commit b06adf4), que recupera mensajes perdidos mucho más rápido mediante arranque paralelo. El lanzamiento también añade un motor de audio reconstruido con soporte completo para Linux, spoilers de imágenes con vista previa difuminada, hipervínculos clicables con rich link previews, menciones @mention con @everyone para admins de grupo, autocompletado de shortcode de emoji, silenciamiento de grupos, tap-to-react sobre reacciones existentes y cargas de archivos cancelables. Vector filtra explícitamente los eventos de chat grupal NIP-17 (commit 2179a51), usando MLS exclusivamente para cifrado grupal.

Lanzamientos

Route96 v0.5.0 y v0.5.1

Route96, un servidor de medios con soporte para Blossom y NIP-96 (Almacenamiento HTTP de archivos), publicó v0.5.0 y v0.5.1. v0.5.0 añade etiquetado automático de IA, backfill retroactivo para cargas sin etiquetar, colas de moderación para archivos marcados, rechazo de privacidad basado en EXIF y manejo de hashes prohibidos.

v0.5.1 añade hashes perceptuales de imagen, locality-sensitive hashing para buscar imágenes similares, endpoints batch de admin y un SKILL.md publicado que describe la superficie de API Blossom y NIP-96 del servidor para tooling de agentes. PR #58 mueve los workers en segundo plano a tareas Tokio totalmente asíncronas, y el commit 97b00a3 añade backoff para evitar hot loops.

Samizdat v1.0.0-alpha

Samizdat, lector y publicador de contenido largo disponible en samizdat.press, publicó su primera build de Android en v1.0.0-alpha. La app abre en una página Press curada de artículos largos de Nostr con navegación por pestañas inferiores entre las vistas Press, Feed, Saved y Write. La build de Android añade almacenamiento nativo de claves mediante cifrado con Android Keystore y desbloqueo biométrico, maneja URIs nostr: y deep links de samizdat.press, y soporta handoff hacia firmantes a través del selector de apps de Android (Amber, Primal, etc.) en lugar de requerir importación directa de claves. Pull-to-refresh, manejo de safe area en distintos tamaños de pantalla e integraciones nativas de compartir, portapapeles, hápticos y splash screen ahora forman parte del shell Android en vez del wrapper web.

El commit d17308f añade firma NIP-55 basada en intents para flujos con Amber y Primal, y el commit e29dab8 reemplaza un workaround de puente JavaScript por un plugin nativo de Capacitor usando startActivityForResult. La app requiere Android 7.0+ (API 24), se distribuye como APK de depuración en esta alfa y todavía carece de push notifications. La publicación depende por ahora de una app firmante, mientras el login con nsec cubre lectura local y acceso a la cuenta.

Calendar by Form* v0.2.0

Calendar by Form*, una app de calendario descentralizada con compartición privada de eventos NIP-59 (Gift Wrap) disponible en calendar.formstr.app, publicó v0.2.0 con PR #38. El lanzamiento amplía el manejo de eventos recurrentes para NIP-52 (Eventos de calendario), superando la base de evento único de v0.1.0. Los cambios subyacentes también tocan almacenamiento local de eventos, manejo de firmantes y plumbing de notificaciones Android. Esta es la segunda aplicación activa de la organización Formstr tras la migración de repositorio del mes pasado.

Mostro v0.16.4

Mostro, el exchange peer-to-peer de Bitcoin construido sobre Nostr, publicó v0.16.4. Las correcciones de restauración de sesión de disputas (PR #599) y auto-cierre (PR #606) cubiertas la semana pasada están incluidas. Novedades de esta versión: PR #625 añade un campo days a eventos de valoración de usuario kind 38384, PR #612 añade expiración a esos eventos de valoración, y PR #614 cambia los eventos de órdenes para usar ajustes de expiración configurados en lugar de una ventana hardcodeada de 24 horas. PR #622 añade una comprobación de idempotencia para evitar pagos duplicados de la comisión de desarrollo.

Mostro Mobile v1.2.1

Mostro Mobile, el cliente Flutter para el exchange P2P Mostro, publicó v1.2.1 con 11 funciones nuevas y 11 correcciones de errores. El lanzamiento añade renderizado multimedia cifrado en el chat de disputas (PR #514), cierre automático de la UI de disputa cuando las órdenes alcanzan un estado terminal (PR #503), escaneo QR para importar billeteras NWC (commit 12eaee4), traducciones al francés y manejo de push notifications FCM. PR #496 corrige un bug de padding en firmas Schnorr fijando la dependencia bip340 en v0.2.0.

0xchat v1.5.4

0xchat, el cliente de mensajería estilo Telegram con soporte Cashu, publicó v1.5.4 centrado en correcciones para escritorio Linux: iconos del dock en AppImage, renderizado de emoji, congelamientos del menú contextual y bloqueos de la UI al responder o copiar. El lanzamiento también corrige problemas de subida de imágenes e integración con npub.cash. PR #49 elimina rebuilds innecesarios de UI al quitar un timer de polling de 3 segundos que forzaba repintados glassmorphic sin hacer nada, y desbloquea la inicialización del login al cargar la caché de eventos de forma concurrente en lugar de bloquear el arranque de relay, contactos y canales.

Keep v0.6.0

Keep, un firmante umbral FROST para Android con soporte de NIP-55 y NIP-46, publicó v0.6.0 y v0.6.1. v0.6.0 añade coordinación de descriptores de wallet y UI de gestión, un flujo de backup/restore con autenticación biométrica (PR #184), recuperación de nsec desde shares umbral (PR #187), generación de marcos QR animados multiplataforma vía Rust UniFFI (PR #188) y una traza de auditoría de firma con verificación de cadena (PR #189). v0.6.1 cambia la licencia de AGPL-3.0 a MIT (PR #191).

njump v0.3.0

njump, la puerta de enlace estática para visualizar contenido Nostr en njump.me, publicó v0.3.0 con un cambio disruptivo en el parseo de códigos note1 y una actualización de la biblioteca Nostr subyacente.

Roadstr v0.1.1

Roadstr, una app descentralizada de reporte de eventos viales basada en Nostr, publicó su primer demo release v0.1.1. La app muestra eventos viales en un mapa usando vector tiles de openfreemap.org.

Bitcredit v0.5.3

Bitcredit, una aplicación de e-bills con capa de transporte Nostr y relay dedicado en bit.cr, publicó v0.5.3. PR #846 añade campos payment_actions y bill_state a la API para estado de pago y aceptación, y PR #849 corrige el manejo de direcciones de firma para firmantes anónimos.

OpenChat v0.1.0-alpha.3

OpenChat, una aplicación de chat construida sobre las bibliotecas .NET MLS y C# del protocolo Marmot, publicó v0.1.0-alpha.3. El lanzamiento añade soporte para firmantes externos con Amber y flujos NIP-46 (commit e568d97), mueve la persistencia del estado MLS al servicio MLS para eliminar pérdida de datos en ventanas de crash (commit 4720bc8) y publica builds para Windows, Linux y Android mediante un nuevo pipeline de CI.

OpenSignal v1.0.0

OpenSignal, un copiloto de trading en Kotlin Multiplatform para Nostr, publicó v1.0.0. El lanzamiento empaqueta módulos KMP compartidos para lógica de dominio, renderizado de gráficos, autenticación y publicación Nostr, soporte de subida Blossom NIP-96 y hooks de inferencia de IA basados en ONNX a través de shells Desktop y Android. La arquitectura publicada también incluye un servicio de IA FastAPI para análisis de capturas de gráficos, pipelines de entrenamiento de modelos y un motor de riesgo que produce planes de trade estructurados con sizing y advertencias. El login soporta tanto claves nsec crudas como firmantes externos, y el flujo de salida termina en publicación de eventos Nostr en lugar de análisis local únicamente.

Actualizaciones de proyectos

Formstr

Formstr, la alternativa a Google Forms en Nostr, fusionó PR #434 (commit e9c4fd5), añadiendo un flujo de registro que usa claves privadas cifradas mediante NIP-49. Antes de este cambio, los usuarios necesitaban o bien una extensión de navegador NIP-07 o pegar un nsec crudo para usar Formstr. El nuevo flujo genera un par de claves en el cliente, cifra la clave privada con una contraseña elegida por el usuario mediante el esquema scrypt + XChaCha20-Poly1305 de NIP-49, y guarda la cadena ncryptsec resultante. Después, los usuarios pueden volver a iniciar sesión con su contraseña sin instalar una extensión firmante. La gestión de claves permanece del lado del cliente en todo momento.

Amethyst

Amethyst, el cliente Android de funciones avanzadas, fusionó cuatro PRs que publican el trabajo de resolución NIP-05 con respaldo de Namecoin que estaba abierto la semana pasada. PR #1734 añade verificación NIP-05 resistente a la censura vía ElectrumX para identificadores .bit, d/ e id/. Cuando Amethyst detecta uno de esos sufijos en un campo NIP-05, consulta un servidor ElectrumX-NMC por el historial de transacciones del nombre, parsea el script NAME_UPDATE de la última salida para extraer la pubkey Nostr y rechaza nombres con más de 36.000 bloques de antigüedad, la ventana de expiración de Namecoin. Las conexiones ElectrumX se enrutan por SOCKS5 cuando Tor está habilitado, con selección dinámica de servidor entre endpoints clearnet y .onion. Un caché LRU con TTL de una hora evita consultas repetidas a la blockchain.

PR #1771 corrige condiciones de carrera y la lógica del resolver en ese flujo. PR #1785 permite a nuevos usuarios importar una lista de follows durante el registro desde identificadores NIP-05 ordinarios o respaldados por Namecoin. PR #1786 añade ajustes personalizados de servidor ElectrumX para que los usuarios elijan qué servidor realiza sus búsquedas.

nostr-idb

nostr-idb, una biblioteca que ofrece métodos auxiliares para almacenar eventos Nostr en IndexedDB, fusionó PR #6 añadiendo soporte para filtros de etiquetas AND de NIP-91. El cambio añade semántica de intersección al matching de filtros del lado del cliente para que las consultas IndexedDB puedan requerir todos los valores de etiqueta listados en vez de cualquiera de ellos. PR #8 actualiza la biblioteca a la interfaz más reciente de NIP-DB, y un commit b49b3d3 posterior corrige un deadlock en subscribe y elimina nostr-tools como dependencia de producción.

Pensieve

Pensieve, un indexador Nostr orientado a archivo con analítica en ClickHouse, fusionó PR #8 añadiendo cumplimiento de TTL de caché por entrada y coalescencia de misses por clave para reducir picos de CPU en la API. Los endpoints de series temporales de mayor costo, estadísticas de engagement, actividad por hora y actividad por kind, ahora usan TTLs del lado del servidor de 10 minutos en vez de disparar tormentas sincronizadas de recomputación.

Blossom

Blossom, el protocolo y stack de servidores de alojamiento de medios descentralizado, fusionó dos actualizaciones de autorización BUD-11. PR #91 mueve la autorización opcional a su propio BUD y aclara el papel de las etiquetas x y server. PR #93 limpia el comportamiento de auth específico por endpoint y formaliza la cabecera X-SHA-256 para verificación de subidas. Ambos PRs consolidan la lógica de auth en BUD-11 y eliminan ambigüedades alrededor del hashing de solicitudes en flujos de upload, delete y gestión de medios.

Actualizaciones de NIPs

Cambios recientes en el repositorio de NIPs:

Fusionados:

NIP-91 (Operador AND para filtros) (PR #1365): Añade semántica de intersección para filtros de etiquetas, permitiendo que los relays respondan consultas que requieren todos los valores listados de etiqueta en lugar de cualquiera de ellos. Reduce el post-filtrado del lado del cliente y el ancho de banda en consultas intensivas en etiquetas.
NIP-66 (Descubrimiento de relays y monitoreo de disponibilidad): Medidas defensivas (PR #2240): Tras el trabajo de benchmarks del modelo outbox cubierto la semana pasada, la especificación ahora añade advertencias sobre rutas problemáticas para datos de monitoreo de relays. Los clientes no deben requerir eventos de monitoreo kind 30166 para funcionar. Un monitor puede estar equivocado, desactualizado o ser malicioso. Se espera que los clientes contrasten fuentes y eviten cortar grandes partes del grafo de relays de un usuario basándose en un solo feed.
NIP-39 (Identidades externas en perfiles): limpieza del registro kind 10011 (PR #2256): Añade la referencia al kind 10011 directamente en la especificación, alineándose con la implementación de Amethyst cubierta la semana pasada.

PRs abiertos y discusiones:

NIP-70 (Eventos protegidos): rechazar reposts que incrustan eventos protegidos (PR #2251): Si un relay aplica NIP-70 sobre el evento original pero acepta reposts que transportan el mismo contenido, la etiqueta - pierde efecto práctico. Este PR añade la regla de que los relays también deben rechazar reposts kind 6 y kind 16 de eventos protegidos. strfry PR #176 ya lo implementa.
NIP-71 (Eventos de video): múltiples pistas de audio (PR #2255): Añade etiquetas imeta de audio para pistas alternativas, variantes de idioma y streams de solo audio. Un cliente podría mantener un archivo de video estable mientras cambia el idioma del audio, o servir el audio como pista separada para contenido tipo podcast.
NIP-11 (Documento de información de relay) y atributos de relay NIP-66 (PR #2257): Añade un campo estructurado attributes a los documentos de información de relay, dando a clientes y herramientas de descubrimiento metadatos legibles por máquina más allá de la descripción actual en texto libre.

NIP Deep Dive: NIP-49 (Cifrado de clave privada)

NIP-49 define cómo un cliente cifra una clave privada con una contraseña y codifica el resultado como una cadena bech32 ncryptsec. Formstr usa NIP-49 en su nuevo flujo de registro.

El formato no está ligado a un kind de evento dedicado. Un cliente comienza con la clave privada secp256k1 cruda de 32 bytes, deriva una clave simétrica a partir de la contraseña del usuario con scrypt, cifra la clave usando XChaCha20-Poly1305 y luego encapsula el resultado en una cadena bech32 ncryptsec. Un flag de un byte registra si alguna vez se supo que la clave fue manejada de forma insegura antes del cifrado.

{
 "id": "4d47f4f0a6f6edbc1bbd7f4e2a45ec68f27cba91d6c6ab5cf28d8d87b0f3d57e",
 "pubkey": "1f8b4c3e7b0f9451d4f9b8a7c6e5d4c3b2a1908f7e6d5c4b3a29181716151413",
 "created_at": 1741699200,
 "kind": 30078,
 "tags": [
 ["d", "encrypted-key-backup"],
 ["format", "ncryptsec"],
 ["encryption", "nip49"]
 ],
 "content": "ncryptsec1qgg9947rlpvqu76pj5ecreduf9jxhselq2nae2kghhvd5g7dgjtcxfqtd67p9m0w57lspw8gsq6yphnm8623nsl8xn9j4jdzz84zm3frztj3z7s35vpzmqf6ksu8r89qk5z2zxfmu5gv8th8wclt0h4p",
 "sig": "6a8f6e4b2d1901735f0ad4b6e8c1f3a579d0e2b4c6f8a1d3e5f7091b2c3d4e5f11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff"
}

El evento JSON anterior es un ejemplo a nivel de aplicación, no un requisito de NIP-49. El NIP estandariza el formato de la clave cifrada. Un cliente puede almacenar el ncryptsec localmente, sincronizarlo mediante almacenamiento específico de la app o exportarlo como cadena de backup. Las contraseñas se normalizan a Unicode NFKC antes de la derivación de clave para que la misma contraseña descifre de forma consistente entre clientes y plataformas.

El flag de seguridad de la clave de un byte tiene tres valores definidos: 0x00 significa que el historial de manejo de la clave es desconocido, 0x01 significa que se sabe que la clave fue manejada de forma insegura, por ejemplo pegada como texto plano en un formulario web antes del cifrado, y 0x02 significa que la clave se generó y cifró en un contexto seguro y nunca fue expuesta. Los clientes pueden usar esto para mostrar advertencias al importar claves con un historial conocido de inseguridad.

NIP-49 protege mejor las claves que la exportación simple de nsec, pero el cifrado solo es tan fuerte como la contraseña y el costo scrypt configurado. Valores más altos de LOG_N dificultan el guessing offline, pero ralentizan las operaciones legítimas de descifrado. La especificación advierte contra publicar claves cifradas en relays públicos, ya que los atacantes se benefician al recolectar ciphertext para ataques offline. Como comparación, la firma remota NIP-46 evita exponer las claves por completo, y la firma Android NIP-55 mantiene las claves dentro de una app firmante dedicada. NIP-49 ocupa un lugar distinto: backup cifrado portable para usuarios que gestionan sus propias claves.

Las implementaciones incluyen Formstr PR #434 para el registro, Amber para backup y restauración de ncryptsec, diVine v1.0.6 para importación de cuentas, Keep v0.6.0 para exportación de shares FROST y herramientas de gestión de claves como nsec.app y Alby.

NIP Deep Dive: NIP-70 (Eventos protegidos)

NIP-70 define eventos protegidos. Cuando un evento lleva la etiqueta ["-"], un relay debe rechazarlo a menos que el relay requiera autenticación NIP-42 y la pubkey autenticada coincida con el autor del evento.

El flujo de auth de NIP-42 funciona así: el relay envía un desafío AUTH que contiene una cadena aleatoria, y el cliente responde con un evento kind 22242 firmado cuyas etiquetas incluyen la URL del relay y el desafío. El relay verifica la firma y comprueba que la pubkey en el evento de auth coincide con la pubkey del evento protegido que se está publicando. Si las pubkeys no coinciden, el relay rechaza el evento con un prefijo de mensaje restricted.

El contenido del evento todavía puede ser público. La etiqueta - solo controla quién puede publicar el evento en un relay que respeta la etiqueta. Esto cubre feeds semi-cerrados de NIP-29 (Grupos simples), espacios de relay solo para miembros y otros contextos donde el autor quiere limitar la redistribución a través del grafo de relays. NIP-70 es una convención de una sola etiqueta, no un nuevo kind de evento, de modo que cualquier kind existente puede llevar la etiqueta -.

{
 "id": "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1707409439,
 "kind": 1,
 "tags": [
 ["-"]
 ],
 "content": "hello members of the secret group",
 "sig": "fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"
}

Aunque un relay bloquee la publicación de terceros del evento original, alguien todavía puede republicar el contenido dentro de un repost. PR #2251 aborda esto exigiendo que los relays también rechacen reposts kind 6 y kind 16 de eventos protegidos. strfry PR #156 añade manejo de auth NIP-42 para eventos protegidos, y strfry PR #176 bloquea reposts que incrustan contenido protegido.

NIP-70 controla el comportamiento del relay. Un receptor todavía puede copiar el contenido a otro lugar, y la especificación lo dice explícitamente. La etiqueta - da a los relays una señal legible por máquina para negarse a republicarlo. Como comparación, NIP-62 (Request to Vanish) pide a los relays borrar datos después del hecho, mientras NIP-70 evita la publicación no autorizada en el momento de la ingesta. Ambos son complementarios: un autor puede marcar eventos como protegidos para limitar la difusión y luego solicitar su eliminación si quiere que el contenido se retire de relays que sí lo aceptaron.

Eso es todo por esta semana. ¿Estás construyendo algo o tienes noticias que compartir? Escríbenos por DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #12

Wed, 04 Mar 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: El Marmot Development Kit lanza su primera versión pública con medios cifrados y bindings multi-lenguaje. Nostrability publica benchmarks del modelo outbox a través de 14 algoritmos de selección de relays. Wisp pasa de primera alfa a beta en ocho días con Tor y firma NIP-55 (Aplicación Firmante de Android). NIP-91 (filtros AND) se fusiona. Vector v0.3.1 entrega sincronización negentropy con mejoras de rendimiento de 15x. Este número también incluye la retrospectiva Cinco Años de Febreros de Nostr, trazando el protocolo desde una reescritura de especificación sirviendo tres relays pasando por la explosión de Damus en la App Store hasta redes de malla y propuestas de agentes de IA.

Noticias

El Modelo Outbox Bajo la Lupa

Nostrability publicó una serie de benchmarks del modelo outbox probando qué tan bien diferentes algoritmos de selección de relays recuperan eventos de la red descentralizada de relays. El proyecto fusionó 16 PRs y 76 commits en diez días, produciendo lo que puede ser el análisis empírico más exhaustivo de estrategias de implementación de NIP-65 (Relay List Metadata) hasta la fecha.

Los benchmarks prueban 14 algoritmos de selección de relays contra listas de follows del mundo real a través de 15 clientes y bibliotecas en cinco lenguajes. Un enfoque base de consultar solo relays populares recupera aproximadamente el 26% de los eventos. Set-cover codicioso con Thompson Sampling alcanza 80-90% de recall. Añadir una variante consciente de latencia usando descuento hiperbólico y seguimiento de latencia de relay EWMA elevó la completitud de 62-80% a 72-96% en la marca de 2 segundos a través de seis perfiles de prueba.

El filtrado de relays muertos con NIP-66 (Relay Monitoring) resultó ser significativo. Pre-filtrar candidatos de relay contra datos de actividad de nostr.watch eliminó 40-64% de relays muertos y duplicó las tasas de éxito de relay de 30% a 75-85%. Los tiempos de carga de feed bajaron 39% (de 40 segundos a 24 segundos a través de 10 perfiles). Una simulación de carrera EOSE encontró que esperar EOSE más un período de gracia de 200ms mejoró la completitud sobre detenerse en el primer relay en terminar.

Para clientes que no pueden reescribir completamente su enrutamiento de relays, un enfoque de “enriquecimiento outbox híbrido” añade consultas outbox por autor sobre relays de aplicación hardcodeados existentes. Este híbrido logró 80% de recall de eventos de un año versus el 26% base, ofreciendo una ruta de migración para clientes con arquitecturas de relay heredadas.

ContextVM Abre NIP de MCP y Lanza Gift Wraps Efímeros

ContextVM, el protocolo que conecta Nostr con el Model Context Protocol, abrió dos propuestas en el repositorio de NIPs esta semana. PR #2246 formaliza CVM como una convención para transportar mensajes MCP JSON-RPC sobre Nostr usando eventos efímeros kind 25910. PR #2245 extiende NIP-59 (Gift Wrap) con un kind efímero (21059) que sigue la semántica efímera de NIP-01 (Flujo Básico del Protocolo), permitiendo a los relays descartar mensajes envueltos después de la entrega.

La convención de gift wrap efímero se lanzó como CEP-19 en la familia de versiones v0.6.x del SDK de ContextVM. La implementación del SDK añade un enum GiftWrapMode con tres configuraciones: OPTIONAL (aceptar ambos kinds y auto-detectar capacidad del par), EPHEMERAL (solo kind 21059) y PERSISTENT (solo kind 1059). Para llamadas de herramientas de IA, el modo efímero evita almacenar tráfico intermedio de solicitud-respuesta en relays, reduciendo tanto costos de almacenamiento como exposición de privacidad.

Nuevos servidores MCP públicos aparecieron en la red de operadores independientes, incluyendo un servidor de consultas Wolfram Alpha. El equipo de ContextVM publicó CEP-15 (esquema de herramientas comunes) y CEP-17 (publicación de lista de relays del servidor) junto al ciclo de lanzamiento v0.6.x.

Marmot Development Kit Lanza Su Primera Versión Pública

MDK (Marmot Development Kit), la biblioteca Rust que impulsa la mensajería cifrada con Marmot a través de Pika y White Noise, lanzó v0.6.0 como su primera versión pública. Más de 200 PRs se fusionaron en esta versión, con seis nuevos contribuidores.

El lanzamiento incluye soporte de medios cifrados (MIP-04) con derivación de semilla HKDF (MIP-01 v2), resolución determinista de carreras de commits (MIP-03), almacenamiento local cifrado, validación de autorización de admin para commits y propuestas Marmot, y soporte GREASE para extensibilidad del protocolo. Los bindings se distribuyen para Kotlin, Python, Ruby y Windows junto a compilación cruzada para Android. La biblioteca se actualiza a OpenMLS 0.8.0 con correcciones de avisos de seguridad y un tipo Secret<T> que elimina valores sensibles de la memoria con zeroing.

Un cambio de protocolo complementario (MIP-03) reemplazó el cifrado NIP-44 (Encrypted Payloads) con ChaCha20-Poly1305 para mensajes kind 445. NIP-44 requería entrada de cadena UTF-8 según su especificación, haciendo imposible pasar bytes de mensaje Marmot crudos a través de bibliotecas Nostr estándar de TypeScript. El reemplazo deriva claves directamente del secreto exportador de Marmot. Este cambio disruptivo requirió actualizaciones coordinadas a través de la especificación core, MDK y el SDK de TypeScript.

marmot-ts, la implementación TypeScript mantenida por hzrd149, fusionó cuatro PRs con cambios disruptivos de API por derecho propio. Una actualización ómnibus añadió un gestor de paquetes de claves para el ciclo de vida crear/publicar/rotar, un método de conveniencia sendChatMessage, vista previa de invitaciones sin unirse (readInviteGroupInfo), auto-actualización para rotaciones de secreto hacia adelante, y logging de depuración estructurado. Las APIs de descifrado de grupo fueron renombradas de readGroupMessage a decryptGroupMessage con variantes de resultado más ricas (processed/skipped/rejected/unreadable). gzuuus contribuyó limpieza de ejemplos con soporte de relays NIP-65 y manejo de paquetes de claves de último recurso según MIP-00.

El CLI de White Noise (wn), el backend Rust que impulsa tanto la app móvil como la nueva TUI, fusionó 16 PRs en diez días. El manejo del ciclo de vida del firmante ganó seguridad de cancelación mediante un scope guard RAII (PR #538), corrigiendo una clase de bugs donde operaciones abortadas podían filtrar estado del firmante. El login ahora bloquea cuando las listas de relays requeridas (kind 10002/10050/10051) están ausentes (PR #515), y las suscripciones de giftwrap recurren a relays de NIP-65 cuando las listas de inbox están ausentes (PR #518). Un modo de depuración (PR #528) expone consultas de base de datos e inspección de ratchet-tree MLS como salida JSON. Otras correcciones abordaron recuperación de suscripciones después de re-registro del firmante, temporización de catch-up de mensajes de bienvenida, validación de filtros de relay y límites de radio de búsqueda de usuarios.

Marmot vio una expansión significativa más allá del stack Rust core esta semana. White Noise TUI, una interfaz basada en terminal para el stack de mensajería White Noise, se lanzó el 3 de marzo. Envuelve el CLI wn como subproceso y renderiza su salida JSON a través de una arquitectura unidireccional inspirada en Elm, proporcionando navegación multi-conversación con indicadores de no leídos, creación de grupos y búsqueda de miembros, streaming de mensajes en tiempo real y reacciones emoji desde la terminal.

DavidGershony publicó un stack Marmot completo en C# que refleja la arquitectura por capas del toolchain Rust. dotnet-mls implementa primitivas criptográficas MLS RFC 9420 en C#. marmot-cs se construye sobre él para añadir transporte de relay Nostr, funcionando como equivalente en C# de MDK. OpenChat, una app de escritorio multiplataforma construida con .NET 9 y Avalonia UI, une ambos en un cliente de chat funcional con DMs NIP-44, cifrado de grupo Marmot, firma remota NIP-46 (Nostr Connect) e indicadores de estado multi-relay.

MDK PWA Reference proporciona una plantilla de Progressive Web App para construir aplicaciones cifradas con Marmot, con soporte experimental para participación de agentes de IA en chats grupales y pagos Bitcoin vía infraestructura de billetera Arkade.

Wisp Pasa de Alfa a Beta

Wisp es un nuevo cliente Nostr para Android que pasó de su primera alfa el 24 de febrero a v0.3.4-beta el 3 de marzo, produciendo 19 lanzamientos, 115 PRs fusionados y 276 commits en ocho días.

La trayectoria de funcionalidades cubre terreno que a la mayoría de los clientes les toma meses alcanzar. v0.1.0 se lanzó con soporte del modelo de relay outbox/inbox y flujos de onboarding. Para v0.1.3, el cliente tenía firma basada en intents NIP-55 para Amber, un proxy SOCKS5 Tor integrado para conectividad de relay .onion y NIP-47 (Nostr Wallet Connect). v0.2.0 graduó a beta con filtrado de listas de silenciados y soporte de emoji personalizados, mientras v0.2.4 añadió superposiciones de advertencia de contenido. La serie v0.3.x introdujo NIP-13 proof-of-work para notas, minado PoW en segundo plano con ajustes persistentes, almacenamiento de relays .onion y notificaciones de hilos silenciados.

La traducción en dispositivo vía Google ML Kit se ejecuta localmente sin acceso a la red después de la descarga inicial del modelo. Una visualización interactiva del grafo social usa una simulación de física velocity Verlet a aproximadamente 30fps con navegación pinch-to-zoom e inspección de perfiles.

Lanzamientos

Vector v0.3.1

Vector, la app de mensajería cifrada con Marmot, lanzó v0.3.1 con mejoras en gestión de grupos y trabajo de rendimiento. Grupos multi-admin, invitaciones masivas, invitación por npub y avatares de grupo amplían las funcionalidades de colaboración. Las notificaciones en segundo plano de Android ahora soportan acciones en línea de Responder y Marcar como Leído.

La sincronización determinista basada en Negentropy recupera el historial completo de conversación incluyendo mensajes perdidos durante períodos offline. Voz a texto reconstruido con aceleración GPU en Android. El manejo de adjuntos de archivo fue renovado con progreso de descarga, estados de reintento, envío de directorios comprimidos e indicadores de progreso en tiempo real. El rendimiento mejoró más de 15x en tiempo de arranque, procesamiento de imágenes, reproducción de audio y capacidad de respuesta general de la UI. El tamaño de instalación de la app se redujo en más de un tercio, con el frontend reducido aproximadamente a la mitad. Se añadió soporte para Android ARM de 32 bits.

Alby Hub v1.21.5

Alby Hub, el nodo Lightning auto-custodiado con soporte de Nostr Wallet Connect (NIP-47), lanzó v1.21.5. Se añadió un segundo relay a la configuración NWC predeterminada, mejorando la fiabilidad durante reinicios de relay. Una corrección para datos de zap inválidos en la lista de transacciones resuelve un problema de visualización con eventos NIP-57 (Lightning Zaps) malformados. Las nuevas entradas de la tienda de apps incluyen Alby CLI y LNVPS.

nospeak v0.12.x

nospeak, el cliente de mensajería Nostr basado en texto, lanzó tres versiones durante el período. v0.12.0 añadió un bloqueo de app con PIN de teclado de 4 dígitos y más de 15 nuevas traducciones de idiomas incluyendo bengalí, tailandés, vietnamita, hindi, árabe, hebreo, urdu, turco, japonés, chino, coreano, holandés, polaco, ruso y persa con soporte RTL. v0.12.1 introdujo un tema Cypher con fondos negro puro y acentos cyan, más generación de póster de vídeo en Android. v0.12.2 añadió exportación de chat y Ver Perfil en menús de contacto.

Citrine v2.0.0-pre2

Citrine, el relay personal Android de greenart7c3, lanzó v2.0.0-pre2 con mejoras de rendimiento del relay mediante nuevos índices de base de datos y coroutines Kotlin reestructuradas. Cada app web alojada ahora inicia en su propio puerto. Búsqueda de texto completo y una pantalla de eventos rediseñada con expansión de eventos completan los cambios.

NoorNote v0.5.x

NoorNote, una aplicación de toma de notas basada en Nostr, lanzó 8 versiones desde v0.5.0 hasta v0.5.7. El lanzamiento de v0.5.0 en Android añadió soporte para firmante Amber NIP-55 y publicación de notas NIP-71 (Video Events). Una página de bienvenida rediseñada en v0.5.1 incluyó vistas previas de línea de tiempo pública y redujo el APK a 15 MB. El Navegador de Relays en v0.5.2 permite a los usuarios explorar líneas de tiempo públicas de relays mediante URLs compartibles, junto a descarga de medios y reacciones de emoji personalizados NIP-30. Las versiones posteriores hasta v0.5.7 abordaron condiciones de carrera de sincronización en el sistema colaborativo de compartición de notas “tribes”.

NosCall v0.5.1

NosCall, la app de llamadas de voz y vídeo en Nostr, lanzó v0.5.1 con soporte de mensajes de voz, una experiencia de escritorio optimizada con entrada de grupo, favoritos de contacto en escritorio, notas de contacto y filtrado, opciones de exportación de datos y limpieza, y soporte de accesibilidad de tamaño de fuente del sistema.

Shosho v0.13.0

Shosho, la app de streaming en vivo de Nostr, lanzó v0.13.0 con descargas de repetición MP4 desde menús de tarjeta de stream y NIP-05 (Verificación Basada en DNS) para perfiles. El publicador RTMP migró a la Expo Modules API. El rendimiento de streaming en conexiones de menor ancho de banda mejoró, y se corrigieron crashes en dispositivos antiguos y streaming de iOS a Zap.Stream.

nostr-java v2.0.0

nostr-java lanzó v2.0.0 con tamaños de buffer WebSocket configurables, permitiendo a las aplicaciones manejar eventos Nostr más grandes sin truncamiento. El salto de versión mayor refleja cambios disruptivos en la API de conexión.

Prism 1.1.0

Prism lanzó 1.1.0 con soporte de contenido de formato largo (artículos kind 30023) y un editor Markdown para componer directamente en la app, seguido por un lanzamiento de corrección de bugs 1.1.1.

Angor v0.2.6

Angor, la plataforma de crowdfunding de Bitcoin, lanzó v0.2.6 con integración Boltz y un flujo de inversión de 1 clic. Tanto los tipos de inversión como de financiación de proyecto funcionan de extremo a extremo en testnet. El equipo señala que la UI está aproximadamente 70% completa.

Actualizaciones de NIPs

Cambios recientes al repositorio de NIPs:

Fusionados:

NIP-91: Operador AND para Filtros: Añade semántica de filtro AND para arrays de etiquetas en suscripciones de relay. Actualmente, especificar múltiples valores en un filtro de etiqueta (ej. múltiples etiquetas p) coincide con eventos que contienen cualquiera de ellos. NIP-91 permite a los clientes requerir eventos que coincidan con todos los valores de etiqueta especificados simultáneamente, reduciendo ancho de banda y habilitando operaciones de índice más rápidas. Ya existen múltiples implementaciones de relay incluyendo nostr-rs-relay, satellite-node, worker-relay y applesauce. Anteriormente numerado NIP-119.
NIP-30: Dirección de Conjunto de Emoji en Etiquetas: Las etiquetas de emoji personalizados en NIP-30 ahora pueden incluir una dirección opcional de conjunto de emoji. Hacer clic en un emoji en un cliente puede abrir el conjunto al que pertenece para marcar o navegar. Originado del cliente Chachi.
NIP-29: Añadir unallowpubkey y unbanpubkey: Dos nuevos comandos de admin para chat grupal NIP-29. unallowpubkey elimina una pubkey de la lista permitida sin banearla. unbanpubkey levanta un ban sin re-añadir la pubkey a la lista de miembros. Anteriormente, la única forma de eliminar a alguien de la lista permitida también los baneaba, y desbanear requería re-añadir al usuario como miembro.

PRs Abiertos y Discusiones:

NIP-A7: Spells (abierto 27 feb): Propuesto por purrgrammer, los spells son consultas Nostr guardadas portátiles publicadas como eventos kind 777. Un spell codifica un filtro REQ o COUNT en etiquetas estructuradas (k para kinds, authors para pubkeys, tag para filtros de etiqueta arbitrarios) con variables de ejecución: $me se resuelve a la pubkey del usuario conectado, $contacts se expande a la lista de follows kind 3 del usuario. Marcas de tiempo relativas (7d, 2w, 1mo) permiten a los spells definir ventanas de tiempo móviles sin fechas hardcodeadas. Ya implementado en nak y Grimoire, los spells permiten a los usuarios crear, compartir y suscribirse a feeds curados que viajan entre clientes.
NIP-59: Gift Wrap Efímero (kind 21059) (abierto 27 feb): Añade una variante efímera de gift wraps de NIP-59. Kind 21059 sigue la semántica efímera de NIP-01, por lo que los relays descartan eventos después de la entrega. Propuesto por ContextVM para transporte MCP donde la persistencia de mensajes es innecesaria.
ContextVM: MCP JSON-RPC sobre Nostr (abierto 27 feb): Especifica cómo transportar mensajes del Model Context Protocol sobre Nostr usando eventos efímeros kind 25910 con etiquetas p y e para direccionamiento y correlación. Intencionalmente ligero, delega el detalle del protocolo a la especificación de ContextVM.
NIP-29: Espacios en Vivo de Audio/Vídeo (abierto 25 feb, borrador): Borrador de fiatjaf extendiendo grupos de NIP-29 con audio y vídeo en vivo. La propuesta añade etiquetas opcionales livekit y no-text a eventos de metadatos de grupo. Cuando un usuario quiere unirse a un espacio de voz, el cliente solicita un JWT al relay en /.well-known/nip29/livekit/{groupId}. El relay verifica la membresía del grupo y emite un token con la pubkey hex del usuario como claim sub, que se pasa a LiveKit para transporte de medios. El acceso a salas de voz hereda el modelo de permisos existente del grupo, por lo que las reglas de membresía del lado del relay gobiernan quién puede hablar. Se está probando en Pyramid y Chachi.
Propiedad Colaborativa de Eventos (abierto 24 feb): pablof7z propone un evento puntero (kind 39382) que declara un espacio colaborativo listando pubkeys de co-propietarios en etiquetas p y un kind de evento objetivo en una etiqueta k. Cualquier propietario listado puede publicar eventos de ese kind con la misma etiqueta d, y los clientes resuelven el estado actual consultando a todos los propietarios y tomando el evento más reciente. La atribución de co-autoría solo se muestra cuando una etiqueta a verificable referencia al puntero y el autor aparece en sus etiquetas p, previniendo reclamaciones falsificadas. Esto habilita páginas wiki compartidas y recursos co-autorizados sin asignar control a un solo par de claves.
NIP-09: Eliminación en Cascada de Reposts (abierto 24 feb): Cuando un autor original elimina una nota, los relays también deberían eliminar cualquier repost kind 6 o kind 16 que la referencie. Motivado por preocupaciones de privacidad: los reposts pueden preservar información filtrada accidentalmente después de que el autor elimina la fuente. El cambio es solo del lado del relay, sin requerir modificaciones de cliente.
NIP-07: peekPublicKey (abierto 23 feb): Añade un método peekPublicKey() a extensiones de navegador NIP-07. A diferencia de getPublicKey(), retorna la pubkey actual sin solicitar confirmación del usuario, habilitando auto-login silencioso cuando el usuario tiene auto-login habilitado.
NIP-BB: Book (abierto 28 feb, borrador): Define cuatro kinds de evento direccionables (30300-30303) para publicación estructurada de libros en Nostr. Un evento Cover contiene metadatos raíz incluyendo título, imagen de portada, licencia vía etiquetas NIP-32 (Labeling), y código de idioma. Un evento Index mapea cada capítulo a su posición usando indexación fraccional base62, que permite a los autores insertar nuevos capítulos entre los existentes sin renumerar. Los eventos Chapter actúan como encabezados estructurales con imágenes opcionales, mientras los eventos Episode llevan la prosa real con un límite de 30.000 caracteres con etiquetas de imagen posicionadas. Las reseñas usan Zaps en eventos Cover con la descripción del Zap como texto de reseña.
NIP-54: Cambiar de Asciidoc a Djot (abierto 26 feb): Siguiendo la corrección de internacionalización de d-tag en diciembre, este PR propone reemplazar el formato de marcado Asciidoc de la wiki de NIP-54 con Djot, añadiendo una sección de justificación y ejemplos de wikilink para scripts no latinos.
NIP-66: Medidas Defensivas (abierto 26 feb): Basado en aprendizajes de los benchmarks de nostrability/outbox, añade llamadas explícitas para casos límite de NIP-66. Un PR #2241 complementario define etiquetas de salida para comprobaciones de SSL, geolocalización, red y conectividad.
NIP-C1: Pruebas de Identidad Criptográfica (entrada wiki, kind 30817): Propone eventos kind 30509 que vinculan criptográficamente certificados de firma APK con perfiles Nostr. La prueba funciona firmando un mensaje canónico que contiene la pubkey Nostr con la clave privada del certificado (soportando ECDSA, RSA PKCS1v15, Ed25519 y otros algoritmos estándar), luego publicando la firma en un evento kind 30509 firmado con la clave Nostr. Los verificadores pueden confirmar que la persona que controla el certificado de firma de una app Android también controla la pubkey Nostr que afirma publicarla. Las pruebas expiran después de un año por defecto y pueden revocarse explícitamente. Implementado en el toolchain de Zapstore.
NIP-31402: Registro de Oferta de Reparto de Ingresos SARA (entrada wiki, kind 30817): Define eventos direccionables kind 31402 para publicar ofertas de Simple Autonomous Revenue Agreement (SARA) en relays Nostr. Los emisores anuncian términos de reparto de ingresos liquidados por Lightning incluyendo porcentaje de participación en pool, disparador de pago, umbral en sats, duración del término y precios por niveles. Agentes y humanos pueden descubrir ofertas a través de relays y suscribirse autónomamente sin una plataforma central. El número de kind refleja el kind 30402 (L402 Service Registry, publicado por el mismo autor como entrada wiki complementaria) ya que SARA representa la contraparte de retorno de la relación de pago L402.

PRs Abiertos y Actualizaciones de Proyectos

Damus: NIP-89 (Recommended Application Handlers)

PR #3337 implementa soporte de etiqueta de cliente NIP-89 para Damus. La app ahora emite una etiqueta de cliente en todas las rutas de publicación (app principal, extensión de compartir, highlighter, borradores) y muestra “vía ClientName” junto a las marcas de tiempo cuando otras apps incluyen sus etiquetas. Un toggle de Privacidad en los ajustes de Apariencia permite a los usuarios desactivar la emisión de etiquetas. PR #3652 añade una sección de Almacenamiento en Ajustes con un gráfico circular interactivo desglosando el uso de disco de caché NostrDB y Kingfisher con soporte de exportación.

Abierto: PR #3657 añade respaldo de relay NIP-65 para notas citadas. Cuando un nevent en línea incluye una pubkey de autor pero no tiene pistas de relay y la nota no se encuentra en el pool del usuario, Damus obtiene la lista de relays kind 10002 del autor y reintenta desde sus relays de escritura.

Amethyst: NIP-39 (External Identities), NIP-C0, NIP-66

Amethyst fusionó una ola de implementaciones de NIP a través de 28 PRs. Las reclamaciones de identidad externa ahora se publican como eventos dedicados kind 10011 bajo NIP-39 (PR #1747), separando la identidad social de los metadatos kind 0 con respaldo compatible hacia atrás. El soporte de fragmentos de código vía NIP-C0 (PR #1744) añade eventos kind 1337 con accesores para lenguaje, extensión, runtime, licencia y dependencias. La implementación de monitoreo de relays NIP-66 (PR #1742) cubre ambos kinds de evento con parseo completo de etiquetas para métricas RTT, tipo de red, NIPs soportados y geohash.

DMs cifrados llegaron a Amethyst Desktop (PR #1710) con un diseño de chat de panel dividido soportando tanto NIP-04 (Encrypted Direct Messages) como NIP-17 (Private Direct Messages). Una nueva pantalla de feed de relay (PR #1733) permite a los usuarios explorar publicaciones de un relay específico con funcionalidad de seguir/dejar de seguir. Abierto: verificación NIP-05 resistente a la censura (PR #1734) añade una ruta de verificación paralela para identificadores .bit que resuelve contra la blockchain Namecoin en lugar de DNS HTTP. Cuando Amethyst detecta un sufijo .bit en un campo NIP-05, consulta un servidor ElectrumX-NMC para el historial de transacciones del nombre, parsea el script NAME_UPDATE de la última salida para extraer la pubkey Nostr, y rechaza nombres más antiguos de 36.000 bloques (la ventana de expiración de Namecoin). Las conexiones ElectrumX se enrutan a través de SOCKS5 cuando Tor está habilitado, con selección dinámica de servidor entre endpoints clearnet y .onion. Un caché LRU con TTL de una hora previene consultas repetidas a la blockchain.

Notedeck: Arquitectura Outbox

PR #1303 migra Notedeck de gestión de pool de relays ad-hoc a un modelo outbox centralizado con suscripciones delimitadas por cuenta. El módulo Messages ahora publica una lista de relays DM predeterminada si no existe ninguna y enruta DMs a los relays preferidos de los destinatarios según kind 10050.

Pika: Perfiles por Grupo y Feed Tutorial

Pika, la app de mensajería cifrada con Marmot disponible en iOS y Android con build de escritorio, ganó perfiles por grupo (PR #368). Los usuarios ahora pueden establecer un nombre de visualización y foto separados para cada chat grupal, junto con una biografía personalizada. Estos perfiles se publican como eventos kind 0 cifrados dentro del grupo Marmot, invisibles para cualquiera fuera de él, con respaldo al perfil Nostr global del usuario cuando no se establece un perfil específico de grupo. Cuando nuevos miembros se unen, el admin retransmite todos los perfiles de grupo almacenados y cada miembro republica el suyo propio al hacer commit. Las fotos de perfil se cifran con Marmot-media antes de subir a Blossom. El PR incluye 16 nuevas pruebas unitarias y expone la funcionalidad tanto a través de un comando CLI (update-group-profile) como de la UI.

Una nueva app web pika-news (PR #401) monitorea los PRs de GitHub del propio Pika y auto-genera recorridos tutoriales paso a paso a partir de diffs de PR, publicándolos como páginas renderizadas en servidor con autenticación NIP-07. Los usuarios pueden discutir tutoriales específicos en tiempo real a través de chat autenticado por Nostr.

diVine: Widgets Incrustables y Respuestas en Vídeo

diVine, la plataforma de compartición de vídeo nativa de Nostr, fusionó 132 PRs en diez días. Widgets de iframe incrustables (PR #1843) proporcionan una página /embed?npub=... autónoma que renderiza el perfil de un usuario y sus últimos vídeos. La funcionalidad de respuesta en vídeo (PR #1915), detrás de un feature flag, usa comentarios Kind 1111 (NIP-22) con metadatos imeta de NIP-92 (Media Attachments). Filtros de contenido de tres vías inspirados en Bluesky (PR #1797) ofrecen controles Mostrar/Advertir/Ocultar a través de 17 categorías de advertencia de contenido NIP-32.

strfry: Validación de Filtros REQ

PR #163 añade validación configurable de filtros REQ a strfry, el relay Nostr en C++. Los operadores pueden establecer máximo de filtros por REQ, presencia requerida de autor o etiqueta, listas blancas de kinds permitidos y límites de kind por filtro. La funcionalidad está dirigida a despliegues de relay NWC que necesitan aplicación estricta de filtros. Abierto: PR #173 añade compresión zstd opcional para payloads de eventos en el momento de ingesta.

rust-nostr: NIP-62 Request to Vanish

rust-nostr, la biblioteca de protocolo Nostr en Rust, añadió soporte de NIP-62 (Request to Vanish) a través de los tres backends de base de datos: LMDB, SQLite e in-memory. La implementación LMDB incluye opciones configurables para habilitar o deshabilitar la aplicación de NIP-09 y NIP-62 por despliegue.

NDK: Eventos Colaborativos y Timeout de NIP-46

NDK, el Nostr Development Kit para JavaScript/TypeScript, fusionó PR #380 introduciendo NDKCollaborativeEvent para documentos colaborativos multi-autor usando un evento puntero direccionable (kind 39382) que define autores autorizados. Un timeout configurable para NDKNip46Signer (PR #381) previene que operaciones de firma remota NIP-46 se queden colgadas indefinidamente cuando un bunker no responde.

TENEX: Categorización de Agentes y Control por Pubkey

TENEX, la plataforma de orquestación de agentes de IA nativa de Nostr, fusionó dos PRs relacionados con seguridad. La categorización de agentes basada en roles TIP-01 (PR #91) mapea categorías de agente (principal, orchestrator, worker, advisor, auditor) a restricciones de herramientas automatizadas vía un mapa de herramientas denegadas. El control de acceso por pubkey (PR #87) asegura que solo eventos de pubkeys en lista blanca o firmados por el backend se enruten junto a agentes conocidos; las pubkeys desconocidas se descartan silenciosamente con spans de OpenTelemetry para auditoría.

Zap Cooking: Panel de Membresía

Zap Cooking, la plataforma de compartición de recetas basada en Nostr, fusionó 25 PRs y 85 commits en diez días. Un panel de membresía (PR #228) muestra estado de suscripción con fechas de expiración y opciones de gestión/mejora, re-habilita puertas de funcionalidades para niveles Sous Chef y Zappy con comprobaciones tanto del lado del cliente como del servidor, y estandariza nombres de niveles a través de 26 archivos. La carga de mensajes de grupo en dos fases (PR #227) proporciona una obtención inicial rápida de 3 días para visualización instantánea seguida de un relleno en segundo plano de 40 días.

El almacenamiento de mnemónico de billetera se movió de cifrado derivado de pubkey a cifrado para sí mismo con NIP-44 (PR #224), corrigiendo una vulnerabilidad donde el esquema anterior derivaba su clave de SHA-256(pubkey), que es efectivamente sin cifrar ya que las pubkeys son públicas. Las billeteras existentes se migran silenciosamente en la primera carga. El chat grupal NIP-29 ganó indicadores de no leídos con insignias de punto rojo y acceso solo por invitación con códigos de invitación kind 9009 (PR #213). Las vistas previas de enlaces y embebidos de eventos Nostr ahora se renderizan en DMs y mensajes grupales (PR #218). Una sección de respaldo Nostr en Ajustes (PR #210) almacena follows y listas de silenciados vía almacenamiento cifrado de NIP-78 (Application-specific Data) con versionado rotativo de 3 slots. El rendimiento de arranque mejoró mediante servicios de notificación diferidos, renderizado DOM perezoso vía IntersectionObserver (reduciendo nodos DOM de ~15.000 a ~3.000 en un feed de 200 eventos), y TTLs extendidos de caché outbox (PR #208). Un modal personalizable de impresión de recetas (PR #205) permite a los usuarios alternar qué secciones incluir con vista previa en vivo. La integración del Branta SDK (PR #222) añade protecciones de verificación para solicitudes POST y GET.

Keep: Migración de Estado por Rust

Keep, el gestor de claves privadas basado en Nostr para Android, fusionó PR #178, eliminando cuatro almacenes de configuración Kotlin en favor de estado compartido impulsado por Rust desde la capa keep-mobile. Un bucle de sondeo de 10 segundos fue reemplazado con KeepStateCallback basado en push desde Rust. PR #179 añade respaldo y restauración cifrados con protección por frase de contraseña.

Mostro Mobile: Cifrado de Chat de Disputas

Mostro Mobile, el cliente móvil para la plataforma de trading P2P de Bitcoin Mostro, lanzó una migración de dos fases del cifrado de chat de disputas. El primer paso (PR #495) cambia de envoltorio específico de mostro a cifrado de clave compartida derivado de la pubkey del admin. Construyendo sobre eso, PR #501 unifica el modelo de mensajes con NostrEvent y almacena eventos gift wrap cifrados en disco, consistente con el patrón de chat peer-to-peer. Una corrección de firma BIP-340 (PR #496) sobrescribe la dependencia bip340 a 0.2.0, resolviendo un bug de relleno en bigToBytes() que causaba que 1-2% de las firmas Schnorr fueran inválidas y 100% de fallo para claves cuya clave pública comienza con 0x00. Los Detalles de Orden ahora muestran etiquetas de estado legibles en lugar de valores de protocolo crudos, localizados en inglés, español, italiano y francés (PR #502). HalCash fue añadido y SEPA eliminado como método de pago (PR #493), ya que las transferencias SEPA pueden exceder 24 horas (SEPA Instant permanece).

Del lado del servidor, Mostro corrigió la restauración de sesión de disputas para incluir el campo de iniciador (PR #599) y ahora cierra automáticamente disputas activas cuando un vendedor libera fondos, publicando un evento Nostr de resolución para que los clientes admin vean la resolución (PR #606).

Cinco Años de Febreros de Nostr

El boletín del mes pasado trazó los hitos de enero de Nostr desde el desarrollo temprano pasando por la explosión de Damus hasta la infraestructura de seguridad en 2026. Esta retrospectiva cubre lo que sucedió cada febrero desde 2021 hasta 2026.

Febrero 2021: La Reescritura

Tres meses después de su existencia, el febrero de Nostr produjo el cambio temprano más trascendental del protocolo. El 14-15 de febrero, fiatjaf reescribió NIP-01, reemplazando el formato de mensaje original con el modelo EVENT/REQ/CLOSE que el protocolo aún utiliza. Antes de esta reescritura, los clientes y relays se comunicaban a través de una estructura más simple. Separar la publicación de eventos (EVENT) de la gestión de suscripciones (REQ/CLOSE) habilitó el filtrado del lado del relay que resultaría esencial para escalar.

NIP-04 llegó el mismo mes, añadiendo mensajes directos cifrados usando secretos compartidos derivados del intercambio de claves Diffie-Hellman sobre secp256k1. Su cifrado era básico (AES-256-CBC) y luego sería reemplazado por la criptografía auditada de NIP-44, pero dio al puñado de usuarios tempranos su primer canal de comunicación privada en el protocolo.

Las herramientas se expandieron con noscl, un cliente de línea de comandos en Go para interacción con relays basada en terminal, y futurepaul comenzó nostr-rs, una implementación Rust temprana. La red completa funcionaba con dos o tres relays, coordinada a través de un grupo de Telegram, con aproximadamente siete contribuidores activos.

Febrero 2022: Ganando Impulso

La publicación en Hacker News del 31 de diciembre de 2021 continuó atrayendo desarrolladores en febrero. El repositorio nostr-protocol/nostr (el repositorio de NIPs formal no existiría hasta mayo de 2022) recibió seis pull requests en febrero, incluyendo NIP-13 (Proof of Work) de vinliao, NIP-14 (Reputation) de fiatjaf, NIP-15 (Resource Relations) de Cameri, y NIP-17 (Git Updates Over Nostr) de melvincarvalho. El número de NIP fue posteriormente reasignado a Private Direct Messages; la colaboración git en Nostr continuó separadamente a través de lo que se convirtió en gitworkshop.dev.

El nostr-rs-relay de Greg Heartsfield fue el caballo de batalla del mes con 34 commits y tres lanzamientos. La versión 0.5.0 del 12 de febrero añadió límites de publicación de usuarios verificados con NIP-05. Las versiones 0.5.1 y 0.5.2 siguieron en las dos semanas siguientes, y el relay manejó la mayor parte del tráfico de la red por sí solo.

Robert C. Martin (Uncle Bob) estaba construyendo more-speech, un cliente de escritorio en Clojure, registrando 69 commits entre el 18 de enero y finales de febrero. Su participación atrajo atención de la comunidad más amplia de ingeniería de software. La extensión de navegador nos2x de fiatjaf lanzó soporte de descifrado NIP-04 y políticas de preferencia de relay en febrero, implementando la interfaz window.nostr (NIP-07) que los clientes web aún usan para delegación de claves.

Branle, aún el cliente web principal, ganó registro de manejador de protocolo web+nostr el 13 de febrero, un intento temprano de deep linking entre aplicaciones Nostr. nostr-tools reforzó la validación NIP-05. go-nostr añadió soporte de DM cifrado NIP-04 y parseo NIP-12 (Generic Tag Queries) a través de 11 commits. La red operaba con aproximadamente 7-15 relays con una base de usuarios activos probablemente en los bajos cientos. Damus y Nostream aún no existían y no aparecerían hasta abril de 2022.

Febrero 2023: Atención Internacional

Febrero 2023 trajo a Nostr su mayor ola de atención pública. Damus, el cliente iOS de William Casarin, había sido aprobado en la App Store de Apple el 31 de enero después de repetidos rechazos. Para el 1 de febrero alcanzó el top 10 en Redes Sociales de EE.UU. Dos días después, el 2 de febrero, Apple retiró Damus de la App Store de China supuestamente a petición de la Administración del Ciberespacio de China.

Grandes medios incluyendo TechCrunch y CoinDesk cubrieron la retirada, amplificando el conocimiento tanto de la app como del protocolo. Las claves públicas únicas con metadatos en nostr.directory cruzaron las 300.000 para el 3 de febrero. Todos los relays eran operados por entusiastas pagando de su bolsillo, y la infraestructura luchó por manejar la carga. Se rastreaban aproximadamente 289 relays a principios de febrero, un número que continuó subiendo.

El repositorio de NIPs registró 29 pull requests fusionados ese mes, el conteo mensual más alto en la historia del protocolo hasta ese punto. NIP-57 (Lightning Zaps) y NIP-23 (Long-form Content) ambos se fusionaron el 13 de febrero, añadiendo micropagos Bitcoin y expandiendo Nostr más allá de publicaciones cortas en un solo día. NIP-65 (Relay List Metadata) se había fusionado una semana antes el 7 de febrero, habilitando el modelo outbox que seguiría. NIP-46 (Nostr Connect) y NIP-58 (Badges) también aterrizaron antes de fin de mes.

La Human Rights Foundation otorgó $50.000 a William Casarin para desarrollo de Nostr y Damus el 21 de febrero, una de las primeras subvenciones institucionales a un proyecto Nostr. OpenSats aún no había lanzado su fondo Nostr (eso llegaría en julio de 2023).

Febrero 2024: Durabilidad del Protocolo

Febrero 2024 cambió el enfoque del crecimiento a la durabilidad del protocolo. NIP-17 (Private Direct Messages), abierto desde el julio anterior, estaba trabajando hacia un reemplazo del envejecido cifrado NIP-04 usando la criptografía auditada de NIP-44 y el gift wrapping de NIP-59. NIP-04 filtraba metadatos a operadores de relay, quienes podían ver pares de remitente-destinatario. NIP-17 oculta la identidad del remitente detrás de pares de claves desechables y se fusionó esa primavera después de una ronda final de revisión en marzo.

NIP-29 (Simple Groups) se fusionó el 28 de febrero después de meses de discusión, definiendo cómo los relays pueden alojar chats grupales moderados con roles de admin y control de acceso. NIP-92 (etiquetas imeta) se fusionó el 1 de febrero, estandarizando cómo los clientes adjuntan dimensiones de imagen y vistas previas blurhash a eventos de medios.

El 16 de febrero, el repositorio de NIPs añadió BREAKING.md, un archivo que rastrea cambios incompatibles hacia atrás en la especificación del protocolo. Su creación reconoció que Nostr había alcanzado un nivel de madurez donde los cambios disruptivos necesitaban documentación formal.

Veintidós pull requests se fusionaron ese mes. npub.cash se lanzó como servicio de dirección Lightning que permite a cualquier npub recibir pagos sin ejecutar un servidor. Un artículo académico publicado el 8 de febrero encontró que el 95% de los relays de uso gratuito no podían cubrir costos operacionales a través de donaciones, con el 35% de los relays de pago cobrando tarifas de admisión por debajo de 1.000 sats (aproximadamente $0,45 en ese momento).

Febrero 2025: Crecimiento de Infraestructura

Febrero 2025 produjo 28 pull requests fusionados al repositorio de NIPs. Un NIP de Derecho a Desvanecerse se fusionó el 19 de febrero, definiendo cómo los usuarios pueden solicitar la eliminación de sus datos de relays en respuesta a preguntas regulatorias sobre portabilidad de datos y control del usuario.

NIP-60 (Cashu Wallet) y NIP-61 (Nutzaps) recibieron actualizaciones de simplificación, agilizando el formato de almacenamiento de tokens ecash. Un despliegue de q-tag (etiqueta de cita) continuó a través de múltiples NIPs, estandarizando cómo los eventos referencian otros eventos para citas e hilos.

Los lanzamientos de clientes marcaron progreso constante. Notedeck v0.3.0 alpha se lanzó el último día de enero, con adopción continuando en febrero. Primal v2.1 siguió el 7 de febrero, y GRAIN v0.3.0, una implementación de relay en Go, se lanzó el 21 de febrero.

NOSTRLDN v5 reunió a la comunidad Nostr de Londres para su quinto meetup. Un puente DVMCP conectó las Máquinas de Venta de Datos de Nostr (NIP-90) con el Model Context Protocol, prefigurando el trabajo de integración de agentes de IA que llegaría el mes siguiente.

Febrero 2026: Más Allá de las Redes Sociales

La actividad de febrero 2026 se extrae de los números de Nostr Compass #8 al #11.

Febrero 2026 produjo la gama más amplia de desarrollo de capa de aplicación en cualquier mes de Nostr. Mostro lanzó su primera beta pública para trading peer-to-peer descentralizado de Bitcoin, y Zapstore alcanzó 1.0 estable después de meses en pruebas de release candidate. White Noise v0.3.0 entregó mensajería en tiempo real cifrada con Marmot con soporte de firmante Amber y más de 160 mejoras fusionadas.

Propuestas competidoras de agentes de IA de pablof7z (NIP-AE para flujos de trabajo de agentes, NIP-AD para anuncios de servidores MCP) y joelklabo (AI Agent Messages) llegaron junto a una propuesta de Coordinación de Agentes DVM extendiendo NIP-90. ContextVM lanzó mejoras del SDK conectando el Model Context Protocol al transporte Nostr. Burrow añadió mensajería cifrada con Marmot tanto para agentes de IA como para humanos, extendiendo la infraestructura de identidad y relays de Nostr a la comunicación máquina a máquina.

FIPS lanzó una implementación funcional en Rust de redes de malla nativas de Nostr, usando pares de claves secp256k1 como identidades de nodo con enrutamiento agnóstico de transporte sobre UDP, Ethernet, Bluetooth o radio LoRa. Su diseño demostró que el modelo de claves de Nostr se extiende más allá de las redes sociales hacia infraestructura de red física.

OpenSats anunció su decimoquinta ronda de subvenciones Nostr, financiando proyectos incluyendo ContextVM y Nostube. Los cambios de protocolo incluyeron soporte de NIP-47 hold invoice para Nostr Wallet Connect y NIP-45 (Counting Results) HyperLogLog para estimación de conteo del lado del relay. La descubribilidad de proveedores de servicio de NIP-85 (Trusted Assertions) para puntuación de Web of Trust también se fusionó. rust-nostr comenzó un rediseño completo de API mientras Nostria 3.0 y Frostr (iOS TestFlight) ambos se lanzaron. La capa de caché local de Blossom abordó la disponibilidad de medios a través de relays.

Mirando Hacia Adelante

Cinco febreros de historia del protocolo muestran una progresión consistente desde trabajo fundacional hasta diversificación de la capa de aplicación, con la afluencia de usuarios de 2023 como punto de inflexión. En 2021, siete contribuidores trabajaban a través de tres relays. Para 2026, el mismo protocolo soportaba redes de malla y propuestas de agentes autónomos funcionando sobre infraestructura de producción.

Eso es todo por esta semana. ¿Estás construyendo algo o tienes noticias que compartir? Escríbenos vía DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #11

Wed, 25 Feb 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: White Noise v0.3.0 trae mensajería en tiempo real y soporte para el firmante Amber con más de 160 mejoras fusionadas. diVine 1.0.5 corrige problemas de reproducción de vídeo y añade eventos de visualización Kind 22236 para análisis de creadores. Pika, Ridestr y Unfiltered lanzan actualizaciones. FIPS lanza una implementación en Rust funcional de redes de malla nativas de Nostr. Notecrumbs recibe correcciones de estabilidad para las vistas previas de enlaces de damus.io. ContextVM conecta Nostr con el Model Context Protocol. Los nuevos proyectos incluyen Burrow para mensajería cifrada con MLS entre agentes de IA y humanos, y Nostria Signer para gestión de bóveda e identidad basada en navegador. Los análisis profundos cubren la firma Android de NIP-55 y la sincronización de billeteras Cashu de NIP-60.

Noticias

Mejoras de Estabilidad en Notecrumbs

Notecrumbs, la API de Nostr y servidor web que impulsa las vistas previas de enlaces de damus.io, recibió una serie de correcciones que abordan problemas de confiabilidad.

Una corrección de concurrencia reemplazó el mecanismo de deduplicación en vuelo con canales watch. Dos llamantes que solicitaban la misma nota podían convertirse ambos en buscadores, llevando a un bloqueo cuando uno completaba antes de que el otro se suscribiera a la notificación. Los canales watch con operaciones atómicas aseguran que solo un buscador se ejecute mientras otros esperan el resultado.

La limitación de tasa implementa una defensa de dos capas contra el martilleo de relays. Cuando los usuarios acceden repetidamente a la misma nota, el sistema ahora aplica debounce a las solicitudes de relay con una ventana de enfriamiento de 5 minutos. Esta protección se extiende a todos los tipos de NIP-19 y feeds de perfil, previniendo spam proporcional a los relays durante tráfico intenso.

El commit de mejoras de rendimiento movió las búsquedas de datos secundarios a tareas tokio en segundo plano. Las páginas ahora se renderizan instantáneamente con datos en caché en lugar de bloquearse en tiempos de espera secuenciales de relay que podían sumar hasta 7.5 segundos. Una actualización a nostrdb 0.10.0 acompañó estas correcciones.

ContextVM: MCP sobre Nostr

ContextVM es un conjunto de herramientas que conectan Nostr y el Model Context Protocol (MCP). Commits recientes han introducido la nueva especificación CEP-8 que habilita pagos, y han estado impulsando mejoras del SDK durante febrero.

El SDK proporciona transportes de cliente y servidor TypeScript para MCP sobre Nostr. Los desarrolladores pueden exponer servidores MCP a través de la red Nostr y los clientes pueden conectarse a ellos. Los relays actúan como un bus de mensajes ciego, solo enrutando eventos cifrados ciegamente. Los clientes sin soporte nativo de Nostr se conectan a través de una capa proxy. La biblioteca maneja la gestión de relays y la firma criptográfica para autenticación de eventos. Funciona tanto en entornos Node.js como de navegador.

CVMI proporciona un CLI para descubrimiento de servidores e invocación de métodos. Relatr calcula puntuaciones de confianza personalizadas a partir de la distancia del grafo social combinada con validación de perfil.

ContextVM se posiciona como una capa puente: los servidores MCP existentes obtienen interoperabilidad con Nostr mientras mantienen sus transportes convencionales.

White Noise Documenta la Búsqueda Descentralizada de Usuarios

Una publicación de blog de jgmontoya detalla cómo White Noise maneja la búsqueda de usuarios a través de la red descentralizada de relays.

La distribución de perfiles crea el desafío: a diferencia de los mensajeros centralizados con bases de datos unificadas, los perfiles de Nostr se dispersan a través de docenas de relays sin índice central. White Noise resuelve esto mediante una arquitectura productor-consumidor que se ejecuta en paralelo.

Un proceso productor expande continuamente el grafo social hacia afuera desde los follows del usuario, obteniendo listas de follows a distancias crecientes y encolando pubkeys descubiertas para resolución de perfil. El consumidor resuelve coincidencias a través de cinco niveles de costo creciente: tabla de usuarios local (más rápido), perfiles en caché de búsquedas anteriores, relays conectados, listas de relays de usuario por NIP-65, y consultas directas a relays declarados por el usuario (más lento).

Búsquedas en frío toman aproximadamente 3 segundos mientras que búsquedas en caliente desde caché bajan a alrededor de 10 milisegundos. Para nuevos usuarios sin grafos sociales establecidos, el sistema inyecta nodos bootstrap bien conectados para asegurar la funcionalidad de búsqueda. La membresía de grupo proporciona una señal social implícita junto a los follows explícitos.

La instrumentación resultó crítica para la optimización, señala el autor. Sin métricas, las mejoras eran conjeturas.

FIPS: Redes de Malla Nativas de Nostr

FIPS (Free Internetworking Peering System) es una implementación Rust funcional de una red de malla auto-organizada que usa pares de claves Nostr (secp256k1) como identidades de nodo. La documentación de diseño acompaña al código funcional.

El protocolo aborda la independencia de infraestructura: los nodos se descubren entre sí automáticamente sin servidores centrales o autoridades de certificados. Un árbol de expansión proporciona enrutamiento basado en coordenadas mientras los filtros bloom propagan información de alcanzabilidad, permitiendo a los nodos tomar decisiones de reenvío con solo conocimiento local. El agnosticismo de transporte significa que el mismo protocolo funciona sobre UDP, Ethernet, Bluetooth, radio LoRa, o cualquier medio capaz de datagramas.

Dos capas de cifrado protegen el tráfico. El cifrado de capa de enlace (patrón Noise IK) asegura la comunicación salto a salto entre vecinos con autenticación mutua y secreto hacia adelante. El cifrado de capa de sesión (patrón Noise XK) proporciona protección de extremo a extremo contra enrutadores intermedios, donde solo el destino puede descifrar la carga útil. Esto imita cómo TLS protege el tráfico HTTP incluso al atravesar redes no confiables.

La arquitectura usa un árbol de expansión de “incrustación codiciosa” para enrutamiento. Cada nodo recibe coordenadas basadas en su posición relativa a la raíz del árbol y el padre. Los paquetes se enrutan codiciosamente hacia coordenadas más cercanas al destino, con filtros bloom anunciando puntos finales alcanzables. Cuando el enrutamiento codicioso falla (mínimos locales), los nodos pueden recurrir a rutas basadas en árbol.

La implementación Rust ya incluye transporte UDP con descubrimiento de filtro bloom. El trabajo futuro se dirige a la integración de relays Nostr para arranque de pares.

Lanzamientos

Esta semana trajo lanzamientos a través de infraestructura de relay y aplicaciones cliente, con nuevos proyectos también entrando al espacio.

HAVEN v1.2.0

HAVEN, el relay personal todo-en-uno que agrupa cuatro funciones de relay con un servidor de medios Blossom, lanzó v1.2.0. Este lanzamiento va más allá de la etapa RC cubierta la semana pasada.

El soporte multi-npub permite que una sola instancia de HAVEN sirva a varias identidades Nostr mediante lista blanca, con nueva funcionalidad de lista negra para control de acceso. Un sistema de respaldo reescrito usa formato JSONL portable, con un comando haven restore para importar notas desde archivos JSONL. La integración de almacenamiento en la nube añade banderas --to-cloud y --from-cloud para gestión de respaldo remoto.

Mejoras de Web of Trust incluyen niveles de profundidad configurables para cálculos de confianza e intervalos de actualización automática de 24 horas con optimización sin bloqueos que reduce la sobrecarga de memoria. Configuración de user-agent para solicitudes de relay y ajustes de timeout de Blastr configurables completan el lanzamiento, junto a exportación de datos a JSONL comprimido.

White Noise v0.3.0

White Noise, la app de mensajería cifrada basada en MLS que implementa el protocolo Marmot, lanzó v0.3.0 con más de 160 mejoras fusionadas.

Este lanzamiento trae mensajería en tiempo real mediante conexiones de streaming en lugar de sondeo, por lo que los mensajes llegan instantáneamente. El soporte para Amber (NIP-55) significa que las claves privadas nunca necesitan tocar la app. Compartir imágenes ahora funciona con seguimiento de progreso de subida y marcadores de posición blurhash mientras carga. La visualización a pantalla completa soporta pellizcar para hacer zoom.

Mensajería grupal recibió mejoras de confiabilidad con listas de chat mostrando nombres de remitentes y cifrado MLS asegurando secreto hacia adelante. La búsqueda de usuarios se expande hacia afuera desde los follows hasta cuatro grados de separación con resultados llegando en streaming a medida que se encuentran.

Un cambio disruptivo reinicia todos los datos locales al actualizar debido a cambios en el protocolo Marmot y el cambio a almacenamiento local cifrado. Los usuarios deben respaldar claves nsec antes de actualizar.

diVine 1.0.5

diVine, el cliente de vídeo corto en bucle construido sobre archivos restaurados de Vine, lanzó 1.0.5 con extensas correcciones de reproducción de vídeo y un nuevo sistema de análisis descentralizado.

Los problemas de reproducción de vídeo dominaron las correcciones: pausa fantasma, audio dual entre vídeos, destello negro entre miniaturas y primeros fotogramas, y crashes de reproductor desechado están todos resueltos. Un reproductor de vídeo agrupado ahora maneja el feed de Inicio para reproducción consistente.

Eventos de visualización efímeros Kind 22236 habilitan análisis de creadores y recomendaciones. El sistema rastrea fuentes de tráfico junto a conteos de bucles mientras filtra auto-visualizaciones. Fugas de ruta de archivo local en etiquetas imeta de evento Nostr se corrigen con URLs canónicas de Blossom construidas en el lado del cliente por especificación BUD-01.

Mejoras de firmante remoto NIP-46 incluyen conexiones de relay paralelizadas y soporte de URL de callback. Android reconecta conexiones WebSocket al reanudar la app después de aprobación del firmante.

Coracle 0.6.30

Coracle, el cliente Nostr basado en web enfocado en gestión de relay y moderación de Web of Trust, lanzó 0.6.30 con soporte de miniaturas de vídeo, mejorando la navegación de medios en feeds.

Nostur v1.26.0

Nostur, el cliente Nostr para iOS, lanzó v1.26.0 con una nueva sección de feed de Transmisiones en Vivo y una pantalla de Ajustes rediseñada. Los GIFs ahora pueden alojarse en servidores de medios Blossom, reduciendo la dependencia de servicios centralizados. La integración de GIFs de Klipy proporciona respaldo cuando Tenor no está disponible. Encabezados de año en conversaciones de DM y visualización de conteo de menciones completan los cambios de cara al usuario.

Herramientas de desarrollador y apps CLI también recibieron actualizaciones esta semana.

nak v0.18.5

nak, la navaja suiza de línea de comandos de fiatjaf para Nostr, lanzó v0.18.5 con un nuevo subcomando nak profile para obtener y mostrar perfiles de usuario. El comando git clone ahora soporta nombres NIP-05 en URIs nostr://, habilitando clonación de repositorios por identificadores legibles por humanos.

Pika v0.5.3

Pika, el mensajero cifrado con MLS para iOS, Android y escritorio construido sobre el protocolo Marmot, lanzó v0.5.3. Commits recientes añaden subida de archivos y soporte de medios de arrastrar y soltar a la app de escritorio, junto a correcciones de despliegue en Cloudflare Workers.

Pika usa un núcleo Rust que posee toda la lógica de negocio mientras iOS (SwiftUI) y Android (Kotlin) actúan como capas delgadas de UI renderizando instantáneas de estado. MDK (Marmot Development Kit) proporciona la implementación MLS. El proyecto señala estado alfa y advierte contra uso para cargas de trabajo sensibles.

Ridestr v0.2.6

Ridestr, la plataforma descentralizada de viajes compartidos con pagos Cashu, lanzó v0.2.6. Este lanzamiento corrige problemas de accesibilidad de TalkBack y resuelve bugs donde los conductores desaparecían de la lista cercana al cambiar métodos de pago o donde los conteos de conductor seleccionado no se actualizaban cuando los conductores se desconectaban.

La función “Send to All” ahora es “Broadcast RoadFlare” con correcciones para fallos silenciosos en instalaciones frescas de conductor. Ridestr implementa escrow HTLC para pagos de viaje sin confianza y sincronización de billetera NIP-60 entre dispositivos.

Unfiltered v1.0.6

Unfiltered, la app de compartir fotos estilo Instagram para Android, lanzó v1.0.6 con búsqueda mejorada de usuarios y reconexión automática de relay cada 60 segundos.

Construido con Kotlin y Jetpack Compose, Unfiltered usa bindings de rust-nostr y servidores compatibles con Blossom para alojamiento de imágenes. La integración con Amber (NIP-55) maneja la gestión segura de claves. La app muestra publicaciones de cuentas seguidas en orden cronológico sin algoritmos ni anuncios.

Dos nuevos proyectos de mensajería y firma también se lanzaron esta semana.

Burrow: Mensajería MLS para Agentes de IA

Burrow es un mensajero que implementa el protocolo Marmot para comunicación cifrada con MLS sin números de teléfono ni servidores centralizados. Tanto usuarios humanos como agentes de IA pueden participar.

Un daemon CLI de Rust puro con modo de salida JSONL maneja la integración con sistemas automatizados. Una app Flutter multiplataforma cubre Android, iOS, Linux, macOS y Windows. Los adjuntos de medios se cifran junto a los mensajes, y WebRTC maneja llamadas de audio y vídeo con servidores TURN configurables.

Burrow superpone cifrado MLS sobre infraestructura Nostr. La identidad usa pares de claves Nostr (secp256k1) mientras los KeyPackages MLS se publican como eventos kind 443. Los mensajes se cifran con NIP-44 como eventos kind 445, y las invitaciones de bienvenida usan gift-wrapping de NIP-59.

Integración con OpenClaw habilita la participación de agentes de IA con acceso completo a herramientas. Listas de control de acceso con registro de auditoría gestionan permisos de contactos y grupos. Esta combinación posiciona a Burrow para escenarios de mensajería agente-a-agente y agente-a-humano que requieren cifrado de nivel Signal sobre infraestructura descentralizada.

Extensión Nostria Signer

Nostria Signer es una extensión de navegador basada en Chromium que proporciona gestión de bóveda e identidad para usuarios de Nostr.

Múltiples bóvedas conteniendo múltiples cuentas permiten a los usuarios organizar identidades para diferentes contextos. La internacionalización incluye soporte de idiomas RTL. Construido con Angular y TypeScript (79.2% del código), funciona tanto como extensión de navegador como Aplicación Web Progresiva.

Nostria Signer implementa NIP-07 para firma de extensión de navegador, habilitando a clientes Nostr basados en web solicitar firmas de eventos sin acceder directamente a claves privadas. Migración automática de billetera maneja actualizaciones distribuidas a través de la Chrome Web Store. Los usuarios también pueden cargar lateralmente desde la carpeta dist/extension.

Los desarrolladores enfatizan el estado experimental: los usuarios deben gestionar sus propias frases de recuperación secreta ya que los desarrolladores no pueden restaurar acceso a claves perdidas.

Actualizaciones de Proyectos

Formstr Migra a Nueva Organización

Formstr, la alternativa a Google Forms en Nostr, migró su repositorio de abh3po/nostr-forms a la organización formstr-hq. Este receptor de beca OpenSats continúa desarrollo en la nueva ubicación.

PRs Abiertos Notables

Trabajo en progreso a través de proyectos Nostr:

Modelo Outbox de Damus (PR #3602): Plan de implementación para el modelo de relay gossip/outbox en iOS. Este cambio arquitectónico mejora la entrega de mensajes publicando a los relays donde los destinatarios realmente leen.
Notificaciones Multiplataforma de Notedeck (PR #1296): Sistema de notificaciones nativo para el cliente de escritorio Damus cubriendo FCM de Android, macOS y Linux.
Actualización Cashu v3 de NDK (PR #370): Actualiza la integración de billetera del Nostr Development Kit a cashu-ts v3.
Cashu Offline de Zeus (PR #3742): Envío y recepción de ecash offline para la billetera Lightning Zeus.
Entrega Digital Cifrada de Shopstr (PR #231): Añade entrega cifrada para bienes digitales con soporte de peso dinámico para artículos físicos.

Actualizaciones de NIPs

Cambios recientes al repositorio de NIPs:

Fusionados Esta Semana:

Descubribilidad de Proveedor de Servicio NIP-85: La especificación de NIP-85 ahora incluye orientación sobre cómo los clientes descubren proveedores de aserciones de confianza. Cuando un cliente necesita puntuaciones de Web of Trust u otras métricas computadas, puede consultar relays por anuncios kind 30085 de proveedores que el usuario ya sigue o confía.
NIP-29 Elimina Grupos No Gestionados: La especificación de chat grupal de NIP-29 eliminó el soporte para grupos no gestionados (donde cualquier miembro podía añadir a otros). Todos los grupos NIP-29 ahora requieren gestión del lado del relay con roles de admin explícitos, simplificando implementaciones y reduciendo vectores de spam.
NIP-11 Elimina Campos Deprecados: Los documentos de información de relay de NIP-11 ya no incluyen los campos deprecados software y version. Las implementaciones deberían eliminarlos de sus respuestas.
NIP-39 Mueve Etiquetas de Identidad: Reclamaciones de identidad externa (etiquetas i de NIP-39 para GitHub, Twitter, etc.) se movieron de perfiles kind 0 a eventos dedicados kind 30382. Esto separa la verificación de identidad de los metadatos de perfil.

Progreso de NIPs para Agentes de IA:

Cuatro NIPs enfocados en IA continúan desarrollo activo. Desde la cobertura de la semana pasada:

NIP-AE: Agents (actualizado 19 feb): Define identidad de agente con kind 4199 para definiciones de agente y kind 4201 para prompting (“nudges”). Los agentes pueden referenciar metadatos de archivo NIP-94 para descripciones extendidas.
NIP-XX: AI Agent Messages (actualizado 18 feb): Estandariza mensajería conversacional con siete kinds de evento efímeros (25800-25806) para estado, deltas de streaming, prompts, respuestas, llamadas de herramientas, errores y cancelación. Eventos “AI Info” kind 31340 permiten a los agentes anunciar modelos y capacidades soportadas.
NIP-AC: DVM Agent Coordination (abierto 18 feb): Extiende NIP-90 para flujos de trabajo de agentes autónomos. Añade latidos para descubrimiento de agentes, revisiones de trabajos para seguimiento de calidad, escrow de datos para compromiso de resultados, cadenas de flujo de trabajo para pipelines de múltiples pasos, y licitación de enjambre para selección competitiva de proveedores. Una implementación de referencia corre en 2020117.xyz.
NIP-AD: MCP Server Announcements (abierto 12 feb): Estandariza el anuncio de servidores y habilidades del Model Context Protocol en Nostr. Ya en uso en la plataforma TENEX.

Otros PRs Abiertos:

NIP-144: Service Authorization Protocol: Define cómo los clientes prueban identidad y permisos a proveedores de servicio en Nostr.
NIP-DC: Nostr Webxdc: alexgleason propone integrar Webxdc (aplicaciones web descentralizadas) con eventos Nostr.

Análisis Profundo de NIP: NIP-55 (Aplicación Firmante de Android)

NIP-55 define cómo los clientes Nostr de Android solicitan operaciones criptográficas de aplicaciones firmantes dedicadas. Con White Noise v0.3.0 y Unfiltered v1.0.6 ambos añadiendo soporte para Amber esta semana, el protocolo de firma Android merece examen.

Canales de Comunicación:

NIP-55 habilita firma entre apps mediante dos mecanismos. Intents proporcionan aprobación manual del usuario con retroalimentación visual para operaciones de una sola vez. Content Resolvers habilitan firma automatizada cuando los usuarios otorgan permisos persistentes, permitiendo a las apps firmar en segundo plano sin solicitudes repetidas.

La comunicación usa el esquema URI personalizado nostrsigner:. Un cliente inicia contacto con:

nostrsigner:<base64-encoded-event>?type=sign_event&callbackUrl=myapp://callback

Operaciones Soportadas:

La especificación define siete métodos criptográficos: firma de eventos (sign_event), recuperación de clave pública (get_public_key), cifrado/descifrado NIP-04, cifrado/descifrado NIP-44, y descifrado de evento zap (decrypt_zap_event).

Modelo de Permisos:

Los clientes llaman a get_public_key una vez para establecer una relación de confianza, recibiendo el nombre de paquete del firmante y la pubkey del usuario. La especificación manda que los clientes guarden estos valores y nunca llamen a get_public_key de nuevo, previniendo ataques de fingerprinting.

Para solicitudes de firma, los usuarios pueden aprobar una vez u otorgar “recordar mi elección” para operaciones en segundo plano. Si los usuarios rechazan consistentemente operaciones, el firmante retorna un estado “rechazado”, previniendo solicitudes repetidas.

Implementaciones:

Amber es el firmante NIP-55 principal para Android. Los clientes que soportan NIP-55 incluyen Amethyst, White Noise, Unfiltered, y otros. Aplicaciones web no pueden recibir directamente respuestas del firmante y deben usar URLs de callback u operaciones de portapapeles.

Relación con Otros NIPs de Firma:

NIP-55 complementa NIP-07 (extensiones de navegador) y NIP-46 (firma remota sobre relays). Donde NIP-07 maneja navegadores de escritorio y NIP-46 maneja firma entre dispositivos, NIP-55 proporciona integración Android nativa con latencia mínima.

Análisis Profundo de NIP: NIP-60 (Billetera Cashu)

NIP-60 define cómo las billeteras ecash de Cashu almacenan estado en relays Nostr, habilitando sincronización de billetera entre aplicaciones. Con Ridestr v0.2.6 usando NIP-60 para sincronización de billetera entre dispositivos, el protocolo merece examen.

Kinds de Evento:

NIP-60 usa cuatro tipos de evento. El kind reemplazable 17375 almacena configuración de billetera incluyendo URLs de mint y una clave privada dedicada para recibir pagos ecash P2PK. Eventos de token (kind 7375) contienen pruebas criptográficas no gastadas, mientras el historial de gastos (kind 7376) registra transacciones para transparencia del usuario. Un kind opcional 7374 rastrea cotizaciones de pago de mint.

Arquitectura de Billetera:

El estado de la billetera vive en relays, haciéndolo accesible entre aplicaciones. El evento de billetera de un usuario contiene referencias cifradas a mints Cashu y una clave privada específica de billetera separada de la identidad Nostr del usuario. Esta separación importa: la clave de billetera maneja operaciones ecash mientras la clave Nostr maneja funciones sociales.

{
 "kind": 17375,
 "content": "<configuración-de-billetera-cifrada-nip44>",
 "tags": [["d", "cashu-wallet"]]
}

Gestión de Pruebas:

Pruebas Cashu son instrumentos al portador. Una vez gastada, una prueba se vuelve inválida. NIP-60 gestiona esto mediante un mecanismo de rollover: al gastar, los clientes crean un nuevo evento de token con pruebas no gastadas restantes y eliminan el original via NIP-09. IDs de token destruidos van en un campo del para seguimiento de estado.

Los clientes deberían validar periódicamente pruebas contra mints para detectar credenciales previamente gastadas. Se permiten múltiples eventos de token por mint, y los eventos de historial de gastos ayudan a los usuarios rastrear transacciones aunque son opcionales.

Modelo de Seguridad:

Todos los datos sensibles usan cifrado NIP-44. La clave privada de billetera nunca aparece en texto plano. Como los relays almacenan blobs cifrados sin entender sus contenidos, el estado de la billetera permanece privado incluso en relays no confiables.

Implementaciones:

Billeteras que soportan NIP-60 incluyen Nutsack y eNuts. Clientes como Ridestr usan NIP-60 para sincronización entre dispositivos, permitiendo a los usuarios recargar en escritorio y gastar desde móvil sin transferencias manuales.

Eso es todo por esta semana. Estás construyendo algo o tienes noticias que compartir. Escríbenos vía DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #10

Wed, 18 Feb 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Una capa de caché local para Blossom toma forma mientras proyectos independientes convergen en el acceso offline a medios para Android. Alby lanza un sandbox para desarrolladores NWC para construir y probar integraciones de Nostr Wallet Connect sin arriesgar fondos reales. Propuestas en competencia para la comunicación de agentes de IA en Nostr llegan en la misma semana de dos autores distintos. fiatjaf elimina campos no utilizados de NIP-11, eliminando políticas de retención, códigos de país, política de privacidad y etiquetas de preferencia comunitaria que los operadores de relay nunca adoptaron. NIP-85 fusiona guía de descubrimiento de proveedores de servicios para Aserciones de Confianza. Una nueva etiqueta D en NIP-52 habilita indexación de marca temporal con granularidad de día en eventos de calendario. Los nuevos proyectos incluyen Mapnolia para distribución descentralizada de teselas de mapa, Pika para mensajería cifrada con MLS, Keep para firma de umbral FROST en Android, Hashtree para almacenamiento direccionado por contenido con integración Nostr, y Prism para compartir contenido en Nostr desde cualquier app Android. Primal Android fusiona 11 PRs de NWC añadiendo soporte de billetera dual y ciclo de vida automático del servicio. Mostro Mobile lanza una billetera Lightning integrada mediante integración NWC. Notedeck se prepara para su lanzamiento en Android App Store, mientras HAVEN alcanza v1.2.0-rc3 con soporte multi-npub y respaldo en la nube. Los análisis profundos de esta semana cubren el sistema de Aserciones de Confianza de NIP-85 para delegar cálculos de Web of Trust a proveedores de servicios, y el protocolo de Eventos de Calendario de NIP-52 tras su actualización de indexación con granularidad de día.

Noticias

Emerge una Capa de Caché Local para Blossom

Múltiples proyectos independientes están convergiendo en el mismo problema: el acceso offline a medios Blossom en dispositivos móviles.

Morganite, una nueva app Android de greenart7c3 (el desarrollador detrás de Amber y Citrine), implementa caché del lado del cliente para medios Blossom. Los usuarios pueden acceder a imágenes y archivos vistos anteriormente sin conexión de red.

Aerith lanzó v0.2 con etiquetado de imágenes, operaciones masivas de espejado/etiquetado/eliminación, filtrado por etiqueta y tipo de archivo, más soporte inicial de caché local para Blossom. Aerith es una interfaz de gestión para usuarios que almacenan medios en múltiples servidores Blossom y necesitan organizar y espejar sus blobs.

Una nueva guía de implementación de caché local en la especificación de Blossom documenta el almacenamiento de blobs del lado del cliente, mientras que Prism (del mismo desarrollador que Aerith) añade integración de subida a Blossom a su flujo de compartir-a-Nostr en Android. Cuatro proyectos independientes convergieron en el mismo problema esta semana: una app de caché dedicada, un gestor de medios, una especificación de referencia y una herramienta de compartir con integración Blossom, todos implementando almacenamiento local persistente más allá del simple subir y recuperar.

Sandbox NWC para Desarrolladores de Alby

Alby lanzó un entorno sandbox para desarrolladores que trabajan con Nostr Wallet Connect (NIP-47). El sandbox proporciona un servicio de billetera NWC alojado donde los desarrolladores pueden crear conexiones de prueba y enviar pagos simulados sin conectarse a una billetera Lightning real, mientras observan el ciclo completo de solicitud/respuesta de eventos NWC en tiempo real. Los desarrolladores generan una cadena de conexión nostr+walletconnect:// desde el sandbox y la pasan a su cliente. El sandbox entonces muestra los eventos de solicitud kind 23194 y respuesta kind 23195 resultantes a medida que fluyen entre el cliente y el servicio de billetera.

Esto reduce la barrera para nuevas integraciones NWC. Anteriormente, las pruebas requerían una billetera Lightning personal o un servicio NWC auto-alojado. El sandbox abstrae eso, dando a los desarrolladores un ciclo de retroalimentación inmediato para implementar los métodos pay_invoice, get_balance, make_invoice, lookup_invoice y list_transactions contra un endpoint NWC activo.

Llegan los NIPs para Agentes de IA

Las propuestas de comunicación para agentes de IA en Nostr aparecieron con pocos días de diferencia, abordando el problema desde ángulos distintos.

NIP-XX: AI Agent Messages de joelklabo define un protocolo completo para la interacción de agentes de IA: kinds de evento para prompts, respuestas, deltas de streaming, actualizaciones de estado, telemetría de herramientas, errores, cancelaciones y descubrimiento de capacidades. Un evento de descubrimiento ai.info (kind 31340, reemplazable) permite a los agentes anunciar sus modelos soportados, herramientas con esquemas, soporte de streaming y límites de tasa. La propuesta de joelklabo incluye correlación de ejecuciones mediante ID de prompt, gestión de sesión, reconciliación de streams con ordenamiento por secuencia, y orientación de NIP-59 para privacidad de metadatos.

NIP-AE: Agents de pablof7z adopta un enfoque diferente, definiendo kinds para la instanciación de agentes: definiciones y lecciones. Estos son los tipos de evento que pablof7z utiliza en TENEX, el sistema de aprendizaje autónomo construido sobre Nostr. Una propuesta complementaria, NIP-AD: MCP Server and Skill Announcements, también de pablof7z, define eventos para anunciar servidores Model Context Protocol y habilidades en Nostr. Se soportan comentarios NIP-22, para que la comunidad pueda discutir y valorar servidores MCP directamente en Nostr.

NIP-XX cubre la comunicación completa entre agentes mientras NIP-AE y NIP-AD abordan la identidad y el descubrimiento de herramientas. Estas propuestas podrían converger en un estándar unificado o coexistir como capas complementarias.

Lanzamientos

HAVEN v1.2.0-rc3

HAVEN, el relay personal todo-en-uno que agrupa cuatro funciones de relay con un servidor de medios Blossom, alcanzó v1.2.0-rc3. Este release candidate añade soporte para múltiples npubs, permitiendo que una sola instancia de HAVEN sirva a varias identidades Nostr. Los RC anteriores añadieron indicadores --from-cloud y --to-cloud para respaldo en la nube (RC2) y corrigieron un bug de doble conteo en Web of Trust (RC1).

Mostro Mobile v1.2.0: Billetera Lightning Integrada

Mostro Mobile, el cliente móvil para el exchange P2P de Bitcoin Mostro (v1.1.0 cubierto la semana pasada), lanzó v1.2.0 con una billetera Lightning integrada mediante integración completa de NWC (NIP-47). Compradores y vendedores ya no necesitan cambiar de app para gestionar facturas. La app detecta facturas hold para vendedores y las paga automáticamente a través de la billetera conectada, mientras los compradores obtienen generación automática de facturas. El lanzamiento sigue a v1.1.1 de principios de semana, que añadió soporte multi-nodo de Mostro con un registro curado de instancias de confianza, obtención de metadatos kind 0 para visualización de nodos, gestión personalizada de nodos por pubkey, y fallback automático cuando el nodo seleccionado queda fuera de línea.

En el lado del servidor, Mostro v0.16.2 llegó con correcciones para pagos duplicados de comisiones de desarrollo, limitación de tasa en el endpoint RPC de validación de contraseña, y limpieza adecuada de disputas en cancelaciones cooperativas.

Un nuevo proyecto complementario, mostro-skill, permite a agentes operar en Mostro a través de Nostr.

Aerith v0.2

Aerith, el gestor de imágenes Blossom, lanzó v0.2 con etiquetas de imagen para organizar medios, operaciones masivas de espejado/etiquetado/eliminación entre servidores, filtrado por etiqueta y tipo de archivo, más soporte inicial de caché local. Consulta la sección de Noticias para el contexto de la tendencia más amplia de caché local.

Mapnolia: Teselas de Mapa Descentralizadas sobre Nostr

Mapnolia es un nuevo servidor de datos geoespaciales que divide archivos de mapas PMTiles en regiones geográficas y las anuncia en Nostr para su descubrimiento descentralizado. Publica eventos reemplazables parametrizados kind 34444 en relays Nostr que contienen un índice completo de fragmentos de teselas de mapa con metadatos de capa, regiones geohash, referencias de archivos y detalles del servidor Blossom.

Los clientes descubren y recuperan datos de mapa a través de la red Nostr en lugar de servidores de teselas centralizados, con eventos de anuncio que contienen suficientes metadatos para solicitar solo las regiones geográficas necesarias desde los servidores Blossom listados. Mapnolia es el primer proyecto en llevar la distribución de datos geoespaciales a Nostr, abriendo posibilidades para aplicaciones de mapeo con capacidad offline.

Pika: Mensajería Cifrada Basada en Marmot

Pika es una nueva app de mensajería cifrada de extremo a extremo para iOS y Android que usa el protocolo Marmot, el cual superpone Messaging Layer Security (MLS) sobre relays Nostr. La arquitectura separa las responsabilidades en un núcleo Rust (pika_core) que gestiona el estado MLS y el cifrado/descifrado de mensajes sobre relays Nostr, con capas nativas de UI en SwiftUI (iOS) y Kotlin (Android). El estado fluye de forma unidireccional: la UI despacha acciones al actor Rust, que muta el estado y emite instantáneas con números de revisión de vuelta a la UI via UniFFI y bindings JNI.

Pika se une a un campo creciente de mensajeros MLS-sobre-Nostr junto a White Noise, Vector y 0xchat. Todos usan relays Nostr como capa de transporte para el texto cifrado MLS, manteniendo a los operadores de relay sin posibilidad de leer el contenido de los mensajes. Pika usa el Marmot Development Kit (MDK) para su implementación MLS y nostr-sdk para la conectividad con relays.

Keep: Firma de Umbral FROST para Android

Keep es una nueva aplicación Android para firma de umbral FROST donde ningún dispositivo individual posee la clave privada completa. Implementa NIP-55 (Android Signer) y NIP-46 (firma remota), para que los clientes Nostr compatibles puedan solicitar firmas mientras el material de clave permanece distribuido entre dispositivos. Las configuraciones predeterminadas son 2-de-3 y 3-de-5, aunque se soporta cualquier umbral t-de-n.

La ceremonia de generación distribuida de claves (DKG) de Keep se ejecuta sobre relays Nostr usando kinds de evento personalizados: kind 21101 para anuncios de grupo, kind 21102 para polinomios de compromiso de la ronda 1 (difundidos públicamente), y kind 21103 para shares de secreto de la ronda 2 (cifrados punto a punto con NIP-44 entre participantes). El escalar de clave privada del grupo nunca se computa ni ensambla en ningún lugar durante el DKG. Cada dispositivo posee solo su evaluación del polinomio, y cualquier t shares pueden producir una firma Schnorr válida a través de un protocolo de dos rondas de comprometer-luego-firmar. La firma de 64 bytes resultante es indistinguible de una firma Schnorr de un solo firmante. Bajo el capó, Keep usa el crate frost-secp256k1-tr de la Zcash Foundation con ajuste Taproot, de modo que la clave pública del grupo funciona directamente como un npub de Nostr.

Keep se une a la familia de proyectos Frostr junto a Igloo Desktop, Igloo for Android, Frost2x e Igloo for iOS, ampliando las opciones de gestión de claves de umbral en Nostr.

Prism: Comparte Cualquier Cosa en Nostr desde Android

Prism es una nueva app Android (Kotlin/Jetpack Compose, API 26+) que se registra como destino de compartir del sistema, permitiendo a los usuarios publicar texto, URLs, imágenes y vídeo en Nostr desde cualquier app de su teléfono. Las URLs compartidas pasan por un eliminador de parámetros de seguimiento antes de componerse en notas. Prism obtiene metadatos OpenGraph para generar vistas previas enriquecidas de enlaces y renderiza referencias nativas de Nostr (note1, nevent1) de forma inline.

El motor de programación usa un enfoque híbrido AlarmManager/WorkManager para evitar las optimizaciones de batería de Android: AlarmManager gestiona la temporización precisa de activación mientras que tareas expeditas de WorkManager aseguran la entrega, con reintento exponencial para escenarios offline. Las subidas de medios pasan por servidores Blossom configurables con generación de miniaturas para imágenes y fotogramas de vídeo. Toda la firma de eventos se delega a firmantes externos NIP-55 como Amber, con soporte multi-cuenta para cambiar entre identidades. Prism también soporta publicaciones NIP-84 (Highlights). Del mismo desarrollador que Aerith.

Hashtree: Almacenamiento Direccionado por Contenido con Integración Nostr

Hashtree es un sistema de almacenamiento de blobs direccionado por contenido basado en el sistema de archivos que publica raíces Merkle en Nostr para crear direcciones mutables npub/ruta. El sistema usa “almacenamiento simple” que funciona con cualquier almacén clave-valor, dividiendo el contenido en bloques de 2MB optimizados para subidas a Blossom. A diferencia de BitTorrent, no se necesita computación activa de pruebas Merkle, solo almacenar y recuperar blobs por hash.

La integración con Nostr permite URLs de repositorios git como htree://npub.../repo-name para clonar repositorios, con comandos como htree publish mydata <hash> para publicar hashes de contenido en direcciones npub.../mydata. El CLI integral soporta modos de almacenamiento cifrado (predeterminado) y público, anclaje de contenido, subida a servidores Blossom y gestión de identidades Nostr. Cada elemento almacenado es bytes crudos o un nodo de árbol, proporcionando una base para la distribución descentralizada de contenido a través de la red de relays de Nostr.

Espy: Captura de Paleta de Colores en Shakespeare

Espy, construido sobre la plataforma Shakespeare, permite a los usuarios capturar paletas de colores de fotos y compartirlas como eventos Nostr. Shakespeare es un constructor de apps impulsado por IA que autentica a los usuarios via extensiones de navegador NIP-07 y proporciona conectividad integrada a relays Nostr, para que los desarrolladores lancen apps sin implementar su propia gestión de claves o pool de relays. Espy extrae colores dominantes de la entrada de la cámara en tarjetas de paleta compartibles descubribles a través de feeds estándar de Nostr.

Flotilla 1.6.4

Flotilla, el cliente Nostr estilo Discord de hodlbod que organiza relays como grupos, lanzó 1.6.4. La familia de proyectos Coracle ha migrado de GitHub a una instancia Gitea auto-alojada. Este lanzamiento añade notificaciones push via NIP-9a y un flujo de recepción de billetera, además de listados clasificados y soporte de URL de espacio. Las mejoras de interfaz incluyen modales y gestión de notificaciones mejorados. El silenciado de salas y los márgenes seguros en móvil completan los cambios, junto a correcciones para subidas de imágenes en Safari y detalles de eventos de calendario.

Shosho v0.12.0

Shosho, la app de streaming en vivo para móvil con integración Nostr, lanzó v0.12.0. Este lanzamiento añade Clips de vídeo con respuestas integradas en el reproductor y emojis personalizados. La protección de hilos bloquea el spam de menciones indirectas, y una nueva función de compartir QR permite a los usuarios intercambiar perfiles offline. Un nuevo modo de reproducción horizontal da a los streams una experiencia de visualización estilo Twitch, y la pantalla de exploración ahora muestra clips de creadores junto a streams en vivo.

Granary v10.0

Granary, una biblioteca de traducción de la web social que convierte datos entre Nostr, Bluesky, ActivityPub y otras plataformas a un formato común, lanzó v10.0 con cambios disruptivos. El lanzamiento cambia los IDs de ActivityStreams 1 predeterminados de Nostr de bech32 a hex y añade soporte ampliado de Nostr incluyendo análisis de menciones NIP-27 y etiquetas de artículo. Una nueva opción de salida múltiple en los conversores permite a los desarrolladores traducir entre protocolos en lote.

Nostr MCP Server v3.0.0

Nostr MCP Server, un servidor Model Context Protocol que permite a agentes de IA interactuar con la red Nostr, lanzó v3.0.0. Este lanzamiento mayor añade acciones sociales (follows, reacciones, reposts, respuestas) y gestión de lista de relays con soporte NIP-65 más autenticación opcional NIP-42. La mensajería directa via NIP-17 y NIP-44 también es nueva. El lanzamiento se complementa con las propuestas de NIP para agentes de IA de esta semana como herramientas prácticas para agentes que operan en Nostr.

Aegis v0.3.8

Aegis, el firmante Nostr multiplataforma, lanzó v0.3.8 con soporte multilingüe en la UI y un gestor de actualizaciones incrementales para su navegador de apps Nostr integrado. El nuevo mecanismo de actualización computa diferencias incrementales contra el estado local, manteniendo el directorio integrado de apps web de Nostr actualizado con menor uso de ancho de banda. El lanzamiento también introduce caché de material de clave de 5 minutos para reducir las consultas a la base de datos al firmar múltiples eventos consecutivos.

SNSTR v0.3.1

SNSTR (Secure Nostr Software Toolkit for Renegades), una biblioteca TypeScript para el protocolo Nostr, lanzó v0.3.1. El lanzamiento añade guardas de verificación de paquete que aseguran que todos los puntos de entrada estén incluidos en los tarballs de npm, con aplicación en CI en Node y Bun. v0.3.0 se lanzó la misma semana.

Citrine v2.0.0-pre1

Citrine, el relay Android de Nostr de greenart7c3, lanzó v2.0.0-pre1 con mejoras de rendimiento a través de índices de base de datos optimizados y mejor gestión de corrutinas de Kotlin. El lanzamiento también mejora el soporte para alojar apps web, con cada app ejecutándose ahora en su propio puerto.

Actualizaciones de Proyectos

Primal Android: Expansión de Infraestructura NWC

Primal Android fusionó 11 PRs relacionados con NWC esta semana, continuando la construcción iniciada hace dos semanas. Este lote añade soporte de NWC para billetera dual, inicio/parada automática del servicio vinculada a notificaciones del backend, enrutamiento de conexión por tipo de billetera y limpieza adecuada de datos al eliminar una billetera. El servicio NWC ahora gestiona su propio ciclo de vida basado en el estado de la conexión de la billetera, reduciendo la intervención manual del usuario.

Notedeck: Preparación para Android App Store

Notedeck, el cliente Nostr multiplataforma del equipo Damus, fusionó la preparación para el lanzamiento en Android App Store esta semana. El PR añade un plan de cumplimiento de UGC (Contenido Generado por el Usuario) requerido por Google Play, incluyendo una pantalla de aceptación de Términos de Servicio, bloqueo de usuarios via menús contextuales y ajustes, funcionalidad NIP-56 (Reporting) que publica eventos de reporte en relays, y una sección de ajustes de Contenido y Seguridad. Se añadió infraestructura de build para generar APKs firmados y AABs (Android App Bundles) para lanzamiento via nuevos objetivos de Makefile. Un documento EULA establece un requisito de edad de 17+ y avisos específicos de Nostr sobre contenido descentralizado. Las características de cumplimiento en sí se lanzan en PRs de seguimiento; esta fusión sienta las bases de documentación y firma.

En el lado iOS de Damus, se corrigió un spinner de carga infinita donde el spinner persistía indefinidamente después de que el contenido ya había cargado.

Nostria: Relays de Descubrimiento y Correcciones de DM

Nostria, el cliente Nostr multiplataforma enfocado en escala global, fusionó 9 PRs esta semana. El más destacado añade auto-inicialización de Relays de Descubrimiento para búsqueda de perfiles, dando a los nuevos usuarios conectividad de relay funcional sin configuración manual. Otras correcciones abordan el ajuste de texto en DMs, relleno de viewport en vídeo a pantalla completa, extracción de metadatos de artículo en vistas previas de repost y resolución de URI nostr: en notificaciones.

Camelus: Migración a Riverpod v3

Camelus, el cliente Nostr basado en Flutter, fusionó 5 PRs esta semana centrados en una migración de API a Riverpod v3 y refactorización de feed genérico. Un caché de notas embebidas evita solicitudes redundantes a relays para notas citadas.

Actualizaciones de NIPs

Cambios recientes al repositorio de NIPs:

Fusionados:

NIP-85: Descubrimiento de Proveedores de Servicio: vitorpamplona añadió orientación sobre el descubrimiento por parte del cliente de proveedores de servicios de NIP-85 Trusted Assertions, incluyendo sugerencias de relay y claves de servicio específicas por algoritmo. Consulta el análisis profundo a continuación para cobertura completa.
NIP-11: Limpieza de Información de Relay: fiatjaf eliminó privacy_policy, el array retention, relay_countries y el bloque de preferencias de comunidad de NIP-11. Los operadores de relay rara vez poblaban estos campos y los clientes no actuaban sobre ellos.
NIP-52: Etiqueta de Marca Temporal con Granularidad de Día: staab añadió una etiqueta D requerida a los eventos de calendario basados en tiempo de NIP-52 (kind 31923) que representa la marca temporal Unix con granularidad de día, calculada como floor(unix_seconds / 86400). Múltiples etiquetas D cubren eventos de varios días, permitiendo una indexación temporal eficiente sin analizar marcas temporales completas.
NIP-47: Simplificación: El PR de simplificación discutido en el Boletín #9 se fusionó esta semana, eliminando multi_pay_invoice y multi_pay_keysend de NIP-47 (Nostr Wallet Connect). Consulta el Boletín #8 para el análisis profundo completo del protocolo NWC.

PRs Abiertos y Discusiones:

NIP-74: Podcasts: Cubierto en el Boletín #8, esta propuesta de especificación de podcasts generó acalorada discusión esta semana. staab señaló que ya existen al menos tres estándares de podcast en competencia, y derekross apuntó a una implementación existente de seis meses con apps y podcasts activos. El camino a seguir requiere convergencia entre implementaciones antes de que se pueda asignar un número de NIP.
NIP-XX: AI Agent Messages: joelklabo propone un protocolo completo de comunicación para agentes de IA con kinds de evento para prompts, respuestas, streaming, telemetría de herramientas, errores y descubrimiento de capacidades. Consulta la sección de Noticias para cobertura de todas las propuestas de IA de esta semana.
NIP-PNS: Private Note Storage: El sistema de notas privadas de jb55 define eventos kind 1080 para almacenar notas personales cifradas en relays sin revelar quién las escribió. El esquema deriva un par de claves seudónimo determinista desde el nsec del usuario via HKDF: pns_key = hkdf_extract(ikm=device_key, salt="nip-pns"), luego genera un par de claves secp256k1 a partir de esa clave derivada. Una segunda derivación produce una clave de cifrado simétrica: pns_nip44_key = hkdf_extract(ikm=pns_key, salt="nip44-v2"). Las notas internas se cifran con NIP-44 v2 usando esta clave y se publican bajo la pubkey seudónima, de modo que los relays ven eventos kind 1080 de una identidad no vinculada a la clave principal del usuario. A diferencia de los gift wraps de NIP-59, PNS no es vulnerable a spam (la clave seudónima es determinista, no aleatoria) y no lleva metadatos públicos (no se necesitan etiquetas p ya que no hay destinatario). Esta semana, jb55 publicó hallazgos de la implementación de PNS en el backend Rust de Notedeck (módulo enostr::pns). Identificó que la llamada hkdf_extract de la spec es ambigua porque HKDF del RFC 5869 tiene dos fases (Extract y Expand) que producen salidas diferentes, y la mayoría de las bibliotecas esperan ambas. Aclaró que pns_nip44_key omite el acuerdo de clave ECDH normal de NIP-44 y se usa directamente como clave de conversación, un detalle que los implementadores necesitan saber ya que la mayoría de las bibliotecas NIP-44 usan ECDH por defecto. También señaló una variable indefinida en la implementación de referencia de TypeScript. El PR, originalmente de abril de 2025, está siendo implementado activamente.
NIP-AE: Agents: pablof7z define cuatro kinds de evento para la identidad de agentes en Nostr, extraídos de su trabajo en TENEX. La plantilla base es kind 4199 (Agent Definition), que lleva título, descripción de rol, instrucciones del sistema, declaraciones de herramientas y versión. Los modificadores de comportamiento viven en kind 4201 (Agent Nudge), que usa etiquetas only-tool, allow-tool y deny-tool para el control de capacidades en tiempo de ejecución. Los agentes publican lo que aprenden como eventos kind 4129 (Agent Lesson), categorizados y vinculados de vuelta a la definición padre via etiquetas e, refinables a través de hilos de comentarios NIP-22. La verificación de propiedad usa kind 14199, un evento reemplazable donde los operadores humanos listan las pubkeys de sus agentes, estableciendo una cadena bidireccional cuando se compara con la etiqueta p del perfil kind 0 del agente.
NIP-AD: MCP Server and Skill Announcements: pablof7z define eventos para anunciar servidores Model Context Protocol y habilidades individuales en Nostr. Los anuncios de servidores MCP llevan la URL del endpoint del servidor y la versión de protocolo soportada junto a una lista de herramientas disponibles con sus esquemas de entrada. Se soportan comentarios NIP-22 en los anuncios de servidor, para que la comunidad pueda discutir y valorar servidores MCP directamente en Nostr.
NIP-73: OSM Tag Kind: DestBro propone añadir identificadores de OpenStreetMap a NIP-73 (External Content IDs), que estandariza cómo los eventos Nostr hacen referencia a contenido externo como libros (ISBN), películas (ISAN), feeds de podcasts (GUID), geohashes y URLs via etiquetas i y k. El kind de OSM propuesto permitiría que los eventos referencien características específicas del mapa (edificios, carreteras, parques) por su ID de nodo u objeto de OpenStreetMap, conectando el contenido de Nostr con la base de datos geográfica abierta.
NIP-XX: Responsive Image Variants: woikos propone extender los eventos de metadatos de archivo NIP-94 con etiquetas para variantes de imagen responsiva a diferentes resoluciones. Los clientes podrían seleccionar la variante apropiada según el tamaño de pantalla y las condiciones de red, reduciendo el ancho de banda para usuarios móviles que ven imágenes de alta resolución alojadas en servidores Blossom.

Análisis Profundo de NIP: NIP-85 (Aserciones de Confianza)

NIP-85 define un sistema para delegar cálculos costosos a proveedores de servicios de confianza que publican resultados firmados como eventos Nostr. Las puntuaciones de Web of Trust y las métricas de engagement requieren rastrear muchos relays y procesar grandes volúmenes de eventos, un trabajo que es impracticable en dispositivos móviles. La fusión de esta semana añadió orientación sobre el proceso de descubrimiento de estos proveedores por parte del cliente.

Delegación:

Calcular la puntuación de Web of Trust de un usuario requiere rastrear grafos de seguimiento con múltiples saltos a través de muchos relays, y computar conteos precisos de seguidores implica deduplicar en toda la red de relays. Los dispositivos móviles y los clientes de navegador no pueden realizar estas operaciones, sin embargo los resultados son esenciales para el filtrado de spam y la clasificación de contenido. NIP-85 cierra esta brecha permitiendo a los usuarios designar proveedores de confianza para ejecutar los cálculos y publicar resultados como eventos estándar de Nostr.

Diseño del Protocolo:

NIP-85 usa cuatro kinds de evento para aserciones sobre diferentes tipos de sujetos. Las aserciones de usuario (kind 30382) llevan conteo de seguidores, conteos de publicaciones/respuestas/reacciones, montos de zap, rango normalizado (0-100), temas comunes y horas activas:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30382,
 "tags": [
 ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"],
 ["rank", "89"],
 ["followers", "4521"],
 ["first_created_at", "1609459200"],
 ["post_cnt", "1283"],
 ["reply_cnt", "647"],
 ["reactions_cnt", "8920"],
 ["zap_amt_recd", "850000"],
 ["zap_amt_sent", "320000"],
 ["zap_cnt_recd", "412"],
 ["zap_cnt_sent", "198"],
 ["zap_avg_amt_day_recd", "1150"],
 ["zap_avg_amt_day_sent", "430"],
 ["reports_cnt_recd", "2"],
 ["reports_cnt_sent", "0"],
 ["t", "nostr"],
 ["t", "bitcoin"],
 ["active_hours_start", "14"],
 ["active_hours_end", "22"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Las aserciones de evento (kind 30383) califican notas individuales con conteo de comentarios, conteo de citas, reposts, reacciones y datos de zap:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30383,
 "tags": [
 ["d", "<target event id>"],
 ["rank", "72"],
 ["comment_cnt", "45"],
 ["quote_cnt", "12"],
 ["repost_cnt", "89"],
 ["reaction_cnt", "310"],
 ["zap_cnt", "23"],
 ["zap_amount", "125000"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Para eventos direccionables (artículos de formato largo, páginas wiki), el kind 30384 aplica las mismas métricas de engagement a todas las versiones colectivamente. El kind 30385 califica identificadores externos (libros, películas, sitios web, ubicaciones, hashtags) referenciados a través de NIP-73 (External Content IDs), que estandariza cómo los eventos Nostr hacen referencia a contenido externo via etiquetas i y k:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30385,
 "tags": [
 ["d", "isbn:9780765382030"],
 ["k", "isbn"],
 ["rank", "94"],
 ["comment_cnt", "67"],
 ["reaction_cnt", "203"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Cada aserción es un evento direccionable reemplazable donde la etiqueta d contiene el sujeto: una pubkey, ID de evento, dirección de evento o identificador NIP-73. Los proveedores de servicios firman estos eventos con sus propias claves, y los clientes los evalúan basándose en relaciones de confianza.

Descubrimiento de Proveedores:

Los usuarios declaran qué proveedores de aserciones confían publicando eventos kind 10040. Cada entrada especifica el tipo de aserción con la pubkey del proveedor y una sugerencia de relay, más variantes de algoritmo opcionales:

{
 "id": "<event hash>",
 "pubkey": "<user pubkey>",
 "created_at": 1739836800,
 "kind": 10040,
 "tags": [
 ["30382:rank", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30382:rank", "3d842afe...", "wss://nostr.wine"],
 ["30382:zap_amt_sent", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30383:rank", "4fd5e210...", "wss://nip85.nostr.band"]
 ],
 "content": "",
 "sig": "<user signature>"
}

Los usuarios pueden cifrar la lista de etiquetas en .content usando NIP-44 para mantener privadas sus preferencias de proveedor. Los clientes construyen una lista de proveedores verificando qué proveedores confían las cuentas a las que siguen, creando una capa de reputación descentralizada para los propios proveedores de aserciones.

Modelo de Seguridad:

Los proveedores deben usar claves de servicio diferentes para algoritmos distintos, y una clave única por usuario cuando los algoritmos son personalizados, evitando la correlación cruzada de consultas entre usuarios. Cada clave de servicio recibe un evento de metadatos kind 0 que describe el comportamiento del algoritmo, dando a los usuarios transparencia sobre en qué están confiando. Los eventos de aserción solo deben actualizarse cuando los datos subyacentes cambian realmente, evitando tráfico innecesario en los relays y permitiendo a los clientes cachear resultados con confianza.

Adopción Actual:

NIP-85 formaliza un patrón que ya estaba emergiendo de forma informal. El servidor de caché de Primal calcula métricas de engagement y puntuaciones de Web of Trust. Antiprimal, cubierto en el Boletín #9, conecta estos cálculos a clientes Nostr estándar usando kinds de evento NIP-85. Nostr.band opera el relay wss://nip85.nostr.band referenciado en los propios ejemplos de la spec, sirviendo eventos de aserción para los datos de su índice de búsqueda. En el lado del cliente, Amethyst (desarrollado por vitorpamplona, quien también escribió este NIP) tiene soporte experimental de Aserciones de Confianza en su biblioteca quartz, analizando eventos de aserción y declaraciones de proveedores de servicio. Vertex calcula métricas similares de Web of Trust pero eligió un enfoque diferente, usando una API directa en lugar de eventos NIP-85, citando el problema de descubrimiento y la sobrecarga computacional de las arquitecturas basadas en aserciones. Con NIP-85, cualquier cliente puede consumir aserciones de cualquier proveedor a través de un formato de evento estándar, y los proveedores compiten en precisión mientras los usuarios eligen a quién confiar.

Análisis Profundo de NIP: NIP-52 (Eventos de Calendario)

NIP-52 define eventos de calendario en Nostr, dando a los clientes una forma estándar de representar y descubrir ocurrencias en momentos específicos o entre momentos. La fusión de la etiqueta D de esta semana añadió indexación con granularidad de día, completando una pieza que faltaba en la infraestructura de consultas de la spec.

Dos Tipos de Evento:

NIP-52 separa los eventos de calendario en dos kinds basados en la precisión temporal. Los eventos basados en fecha (kind 31922) representan ocurrencias de todo el día como festivos o festivales de varios días. Usan cadenas de fecha ISO 8601 en sus etiquetas start y end opcionales, sin consideración de zona horaria:

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1735689600,
 "kind": 31922,
 "content": "Annual celebration of Bitcoin's genesis block",
 "tags": [
 ["d", "bitcoin-independence-day-2026"],
 ["title", "Bitcoin Independence Day"],
 ["start", "2026-01-03"],
 ["end", "2026-01-04"],
 ["location", "Worldwide"],
 ["g", "u4pruydqqv"],
 ["t", "bitcoin"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["r", "https://bitcoinindependenceday.com"]
 ],
 "sig": "<event creator signature>"
}

Los eventos basados en tiempo (kind 31923) representan momentos específicos con marcas temporales Unix en sus etiquetas start y end opcionales, más identificadores de zona horaria IANA (start_tzid, end_tzid) para visualización. Ambos kinds son eventos reemplazables parametrizados, por lo que los organizadores actualizan los detalles publicando un nuevo evento con la misma etiqueta d.

Calendarios y RSVPs:

Los eventos kind 31924 definen calendarios como colecciones, referenciando eventos via etiquetas a que apuntan a eventos kind 31922 o 31923 por sus coordenadas de dirección:

{
 "id": "<event hash>",
 "pubkey": "<calendar owner pubkey>",
 "created_at": 1739836800,
 "kind": 31924,
 "content": "Nostr community events worldwide",
 "tags": [
 ["d", "nostr-community-calendar"],
 ["title", "Nostr Community Events"],
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["a", "31922:<organizer-pubkey>:bitcoin-independence-day-2026"]
 ],
 "sig": "<calendar owner signature>"
}

Los usuarios pueden mantener múltiples calendarios (personal, trabajo, comunidad) y los clientes pueden suscribirse a calendarios de pubkeys específicas. Los eventos de calendario pueden incluir una etiqueta a que referencia un calendario para solicitar inclusión, habilitando la gestión colaborativa de calendarios donde múltiples usuarios contribuyen eventos a calendarios que no poseen.

Los RSVPs usan kind 31925, donde los usuarios publican su estado de asistencia junto a un indicador opcional de libre/ocupado:

{
 "id": "<event hash>",
 "pubkey": "<attendee pubkey>",
 "created_at": 1739836800,
 "kind": 31925,
 "content": "Looking forward to it",
 "tags": [
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["e", "<kind 31923 event id>", "wss://relay.example.com"],
 ["d", "<unique-rsvp-id>"],
 ["status", "accepted"],
 ["fb", "busy"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com"]
 ],
 "sig": "<attendee signature>"
}

Los valores válidos de status son “accepted”, “declined”, “tentative”, y la etiqueta opcional fb marca al usuario como libre u ocupado para ese período. Los eventos RSVP referencian la etiqueta a del evento de calendario y llevan la etiqueta p del organizador, para que el cliente del organizador pueda agregar respuestas de múltiples relays.

La Adición de la Etiqueta D:

Antes de la fusión de esta semana, los clientes que consultaban eventos en un rango de fechas tenían que obtener todos los eventos de una pubkey o calendario y filtrar en el lado del cliente. La nueva etiqueta D requerida en los eventos basados en tiempo (kind 31923) contiene una marca temporal Unix con granularidad de día calculada como floor(unix_seconds / 86400). Los eventos de varios días llevan múltiples etiquetas D, una por día. Los relays ahora pueden indexar eventos por día y responder a consultas filtradas de forma eficiente, convirtiendo lo que era un problema de filtrado en el cliente en una búsqueda de índice en el relay.

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1739836800,
 "kind": 31923,
 "content": "Monthly meetup for Nostr developers in Austin",
 "tags": [
 ["d", "nostr-meetup-2026"],
 ["title", "Nostr Developer Meetup"],
 ["summary", "Talks and demos from local Nostr builders"],
 ["image", "https://example.com/meetup-banner.jpg"],
 ["start", "1740067200"],
 ["end", "1740078000"],
 ["start_tzid", "America/New_York"],
 ["end_tzid", "America/New_York"],
 ["D", "20139"],
 ["location", "Bitcoin Commons, Austin TX"],
 ["g", "9v6knb2pg"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["p", "<speaker-pubkey>", "wss://relay.example.com", "speaker"],
 ["t", "nostr"],
 ["t", "meetup"],
 ["r", "https://bitcoincommons.com"]
 ],
 "sig": "<event creator signature>"
}

El valor D de 20139 es igual a floor(1740067200 / 86400), situando este evento el 20 de febrero de 2025. Los clientes que consultan por “todos los eventos de esta semana” envían un filtro con el rango D correspondiente, y los relays devuelven solo los eventos coincidentes.

Decisiones de Diseño:

NIP-52 omite intencionalmente los eventos recurrentes. La spec deja las reglas de recurrencia (RRULE de iCalendar) completamente fuera, delegando esa complejidad a los clientes. Un organizador publica eventos individuales para cada ocurrencia, manteniendo el modelo de datos en el relay simple. Las etiquetas de participante llevan roles opcionales (“host”, “speaker”, “attendee”), y las etiquetas de ubicación pueden incluir etiquetas geohash g para consultas espaciales junto a direcciones legibles por humanos.

Implementaciones:

Flockstr es el cliente de calendario principal construido sobre NIP-52. Coracle muestra eventos de calendario en su feed social. La adición de la etiqueta D de esta semana habilita la indexación temporal en el relay que ambos clientes pueden usar para reducir el ancho de banda al consultar eventos en un rango de fechas específico.

Eso es todo por esta semana. ¿Estás construyendo algo o tienes noticias que compartir? ¿Quieres que cubramos tu proyecto? Escríbenos vía DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #9

Wed, 11 Feb 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Mostro lanza su primera beta pública tras tres años de desarrollo, llevando el intercambio P2P de Bitcoin a móviles vía Nostr. OpenSats otorga su decimosexta ronda de grants de Bitcoin, con Minibits Wallet recibiendo renovación para su billetera Cashu integrada con Nostr. Zapstore alcanza su versión estable 1.0, marcando la maduración de la tienda de aplicaciones Android descentralizada. Coracle 0.6.29 añade temas y comentarios en highlights. Igloo Desktop v1.0.3 incorpora endurecimiento de seguridad para firma de umbral Frostr. Amber v4.1.2-pre1 migra a arquitectura Flow. Angor alcanza v0.2.5 con interfaz de financiación renovada y configuración de servidor de imágenes NIP-96. NostrPress se lanza como herramienta que convierte perfiles Nostr en blogs estáticos. Antiprimal publica un gateway compatible con estándares que conecta el servidor cache propietario de Primal con NIPs estándar de Nostr. Primal Android fusiona 18 PRs expandiendo la infraestructura NWC con soporte de doble billetera, registro de auditoría y el método lookup_invoice. diVine lanza feeds de video API-first. El SDK TypeScript de Marmot separa su app de chat de referencia en un repositorio independiente y comienza la migración a ts-mls v2. El repositorio de NIPs fusiona conteo aproximado HyperLogLog para NIP-45 y extrae etiquetas de identidad del kind 0. Varias propuestas de vitorpamplona inician una reducción sistemática de eventos de metadatos kind 0. Nuevas propuestas de protocolo incluyen Nostr Relay Connect para traversal de NAT y Nostr Web Tokens para claims web firmados. El análisis profundo de esta semana cubre el nuevo conteo aproximado HyperLogLog de NIP-45 para métricas de eventos entre relays y el protocolo de almacenamiento de archivos HTTP de NIP-96, ahora obsoleto en favor de Blossom, mientras proyectos transitan entre ambos estándares de medios.

Noticias

Mostro Lanza Primera Beta Pública

Mostro, el exchange peer-to-peer de Bitcoin construido sobre Nostr, lanzó su app móvil v1.1.0, la primera beta pública del proyecto tras tres años de desarrollo. La app permite intercambiar Bitcoin directamente usando Nostr para la coordinación de órdenes, con Lightning para la liquidación y ningún intermediario custodio.

El lanzamiento introduce notificaciones push con mejor fiabilidad en segundo plano en Android, un sistema de logging opcional que permite capturar y compartir datos de diagnóstico cuando surgen problemas, actualizaciones de relay más fluidas usando inicialización aditiva, y refinamientos de interfaz de Fase 2 con soporte de internacionalización. La app está disponible en Zapstore y como descarga directa de GitHub.

Mostro se une a Shopstr y Plebeian Market como aplicación de comercio nativa de Nostr, con la distinción de que se enfoca en la coordinación del intercambio fiat-a-Bitcoin. El daemon de Mostro subyacente maneja el emparejamiento de órdenes y la resolución de disputas a través de relays Nostr.

Decimosexta Ronda de Grants de Bitcoin de OpenSats

OpenSats anunció grants para 17 proyectos de código abierto. Lo destacado para Nostr: Minibits Wallet, la billetera Android de Cashu con soporte de eventos de billetera NIP-60 e integración de nutzap, recibió renovación de grant. Minibits usa eventos Nostr para almacenar el estado de tokens ecash, haciendo respaldos de billetera portables entre dispositivos a través de sincronización por relay.

NostrPress: De Perfil Nostr a Blog Estático

NostrPress (blog.besoeasy.com) es una herramienta nueva que convierte un perfil Nostr en un blog completamente estático desplegable en cualquier lugar. Tras publicar artículos en Nostr a través de cualquier cliente, NostrPress genera un sitio web independiente a partir de esos eventos, con alojamiento local de medios y feeds RSS.

Construido con Nunjucks templating y JavaScript, NostrPress produce sitios con cero dependencia de plataforma. La salida generada es HTML/CSS plano que puede alojarse en cualquier servidor de archivos estáticos, GitHub Pages, Netlify o un VPS personal. La herramienta se une a Npub.pro y Servus como opciones para convertir contenido Nostr en sitios web tradicionales.

Antiprimal: Gateway Compatible con Estándares al Cache de Primal

antiprimal (antiprimal.net), un nuevo proyecto de Alex Gleason y el equipo Soapbox, es un gateway WebSocket que conecta el servidor cache propietario de Primal con mensajes del protocolo estándar de Nostr. Primal ofrece funciones como estadísticas de eventos, búsqueda de contenido y cálculos de Web of Trust a través de wss://cache.primal.net/v1, pero el acceso requiere un formato de mensaje propietario con un campo cache no estándar que clientes Nostr normales no pueden usar. Antiprimal traduce solicitudes NIP estándar al formato de Primal y convierte las respuestas de vuelta.

El gateway soporta consultas COUNT de NIP-45 (reacciones, respuestas, reposts, conteos de zap, conteos de seguidores), búsqueda NIP-50, información de relay NIP-11, y NIP-85 Trusted Assertions para datos precalculados de Web of Trust de Primal. Un bot acompañante publica eventos NIP-85 kind 30382 (estadísticas de usuario) y kind 30383 (engagement de evento) a relays configurables. El proyecto está construido con TypeScript sobre Bun y usa la biblioteca Nostrify. Creado el 6 de febrero, acumula 53 commits en sus primeros tres días de desarrollo y está en línea en antiprimal.net.

Ikaros: Gateway de Mensajería de Agentes de IA para Signal y Nostr

Ikaros, un nuevo proyecto del equipo Soapbox, es un gateway de mensajería que permite a agentes de IA comunicarse a través de DMs cifrados tanto de Signal como de Nostr. El puente usa el Agent Client Protocol (ACP) para conectar cualquier asistente de IA compatible con ACP a redes de mensajería reales. Tres pull requests constituyen la construcción inicial del proyecto esta semana.

El primer PR (#1) implementa un adaptador completo de DM cifrado NIP-04 con soporte de envío/recepción, buffering de respuestas con flush explícito al completar, formatos de clave privada nsec y hex, publicación multi-relay con reconexión automática, y un asistente de configuración interactivo. El adaptador usa nostr-tools v2.23.0 y actualiza el ACP SDK a v0.14.1.

El segundo PR (#2) corrige una pérdida silenciosa de mensajes causada por condición de carrera en la actualización de sesión. Notificaciones entrantes que llegaban antes de que la sesión estuviera registrada en el mapa se perdían, y la corrección almacena esas notificaciones en buffer para reproducirlas cuando el registro se completa. El tercer PR (#3) añade metadatos de nombre de usuario y grupo/UUID de Signal a interacciones con el agente, para que el agente de IA sepa con quién habla y en qué grupo. El proyecto abre un nuevo espacio de diseño donde agentes de IA direccionables vía DMs de Nostr pueden ser contactados desde Signal, o viceversa.

Campaña de Reducción del Kind 0

vitorpamplona abrió una serie de PRs esta semana proponiendo la extracción sistemática de datos de eventos kind 0 (metadatos de usuario) hacia kinds de evento dedicados. La campaña aborda un problema creciente, ya que eventos kind 0 han acumulado campos con el tiempo que la mayoría de clientes no usa, inflando el tamaño de cada consulta de perfil.

El PR #2216 (fusionado) mueve etiquetas de identidad (etiquetas i) del kind 0 a un nuevo kind 10011, dado que la adopción de estas etiquetas ha sido mínima. Otro PR (#2213) propone mover la verificación NIP-05 al kind 10008, lo que permitiría a usuarios tener múltiples identificadores NIP-05 y filtrar eventos por dirección NIP-05. Un tercer PR (#2217) propone extraer direcciones Lightning (lud06/lud16) a un nuevo kind, evitando que todos los usuarios de kind 0 carguen campos relacionados con zap que solo importan a clientes con integración Lightning.

Las propuestas han reavivado la discusión sobre la estructura general del kind 0, incluyendo el PR #1770, la propuesta de larga data para reemplazar JSON stringificado en el contenido del kind 0 con etiquetas estructuradas.

Soporte de NIP-70 en Relays es Crítico para la Seguridad de Mensajería Cifrada

La implementación White Noise del protocolo Marmot ha identificado una brecha crítica en el soporte de relays para NIP-70 (Eventos Protegidos) y NIP-42 (Autenticación). Las pruebas revelaron que relays públicos principales, incluyendo Damus, Primal y nos.lol, rechazan eventos protegidos directamente con errores blocked: event marked as protected en lugar de iniciar el desafío de autenticación requerido.

Esto rompe una función de seguridad clave. NIP-70 permite la eliminación segura de KeyPackages MLS gastados, previniendo ataques de “recopilar ahora, descifrar después”. Al no contar con soporte de relays, protocolos de mensajería cifrada no pueden proteger a usuarios de un futuro compromiso de claves. White Noise ha desactivado NIP-70 por defecto en respuesta, manteniendo bandera opcional para usuarios con relays que lo soporten.

Llamado a la acción para operadores de relays: Implementen el flujo completo de autenticación NIP-42. Al recibir eventos protegidos, desafíen a clientes a probar la propiedad, luego acepten escrituras validadas. Rechazar eventos protegidos sin autenticación rompe las garantías de seguridad del protocolo de las que dependen aplicaciones de mensajería cifrada.

Lanzamientos

Coracle 0.6.29

Coracle (coracle.social), el cliente web de hodlbod, publicó 0.6.29. El lanzamiento añade visualización de temas y comentarios en highlights kind 9802. Un nuevo elemento de navegación de listas da acceso rápido a listas curadas por el usuario desde la interfaz principal. Bajo el capó, Coracle se actualizó a la nueva versión de Welshman, la biblioteca Nostr compartida que gestiona el manejo de relays y eventos de Coracle. La lista de relays por defecto fue renovada, y el rastreo de errores Glitchtip fue eliminado del código.

Igloo Desktop v1.0.3

Igloo Desktop, la aplicación de firma de umbral y gestión de claves basada en FROST, publicó v1.0.3 con endurecimiento de seguridad extensivo. El lanzamiento introduce validación IPC, aislamiento Electron, y verificaciones de relay con protección contra SSRF (server-side request forgery). Un nuevo flujo de onboarding e importación de shares simplifica la distribución de claves, la planificación de relays ahora incluye normalización y fusión por prioridad, y la arquitectura de API Electron basada en preload mejora la frontera de seguridad entre el renderer y el proceso principal. Un sistema keep-alive para el firmante mantiene la estabilidad de sesiones de firma de umbral, y mejoras de UX en la recuperación reducen la fricción de la restauración de claves.

Amber v4.1.2-pre1

Amber, el firmante de eventos Android, lanzó v4.1.2-pre1 corrigiendo la visualización ausente de puntuación de confianza de relay introducida en v4.1.1, resolviendo problemas de parseo JSON para solicitudes de cifrado/descifrado no-Nostr, y migrando el modelo de cuenta de LiveData a Flow para gestión de estado más predecible. El lanzamiento cambia secretos bunker a UUIDs completos y actualiza al plugin Gradle 9.

Mostro Mobile v1.1.0 y Daemon v0.16.1

Consulta la sección de Noticias arriba para la cobertura completa del lanzamiento móvil. En el lado del servidor, el daemon de Mostro publicó v0.16.1, añadiendo publicación automática de metadatos NIP-01 kind 0 al iniciar (vía PR #575), para que el daemon ahora anuncie su identidad a la red cuando se conecta. La documentación del cálculo de comisiones de desarrollo fue corregida en PR #571.

Angor v0.2.5

Angor (angor.io), el protocolo de financiación P2P descentralizado construido sobre Bitcoin y Nostr, publicó v0.2.5 con tres PRs fusionados. El PR #649 rediseña la sección de gestión de Fondos (V2), reemplazando el diseño anterior con nueva interfaz para rastrear UTXOs individuales y posiciones de inversión. La renovación del InvoiceView en PR #651 trae estilos de botón actualizados, diálogos cerrables, un nuevo comando “Copiar Dirección”, soporte de cancelación para monitoreo de direcciones y mejor manejo del flujo de inversión. Servidores de imágenes NIP-96 (spec) configurables en ajustes se añaden en PR #652, permitiendo a usuarios elegir qué endpoint de subida de medios maneja sus imágenes y documentación de proyecto. La versión v0.2.4 se publicó la semana anterior.

Ridestr v0.2.2 y v0.2.3

Ridestr, la plataforma de viaje compartido descentralizada cubierta la semana pasada, continuó su rápida iteración con v0.2.2 (Hotfix de Pago Bridge) y v0.2.3 tras el v0.2.0 “Lanzamiento RoadFlare”. El hotfix v0.2.2 aborda un bug donde pagos bridge de Cashu cross-mint estaban auto-cancelando viajes mientras el pago aún se procesaba o eventualmente tendría éxito, previniendo cancelaciones prematuras de viaje en liquidaciones lentas. Corrige parpadeo de UI y hitboxes táctiles rotos en el botón “mi ubicación”. La versión v0.2.3 incluye correcciones de bugs adicionales. Ambos lanzamientos incluyen APKs separados para Ridestr (app de pasajero) y Drivestr (app de conductor).

Nostr PHP 1.9.4

Nostr PHP (nostr-php.dev), la biblioteca auxiliar de PHP para el protocolo Nostr, publicó 1.9.4 añadiendo propiedad configurable de timeout a la clase de solicitud (en PR #106). Esto permite a desarrolladores establecer duraciones de timeout personalizadas para conexiones de relay y solicitudes de mensajes, previniendo bloqueos indefinidos cuando un relay no responde o tarda en contestar.

Zapstore v1.0.0

Zapstore (zapstore.dev), la tienda de aplicaciones Android construida sobre Nostr, alcanzó su hito de versión estable 1.0 esta semana tras meses de release candidates.

El lanzamiento 1.0 incluye mejoras de estabilidad críticas, entre ellas manejo del estado del botón de instalación que asegura que Eliminar aparezca inmediatamente después de completar la instalación, mensajes de error amigables con detalles técnicos expandibles, y un botón “Reportar problema” que envía DMs cifrados vía Nostr usando claves efímeras. Contiene pantalla nueva de actualizaciones con polling y seguimiento por lotes, mejor watchdog de descargas para transferencias estancadas, límites dinámicos de descargas concurrentes según el rendimiento del dispositivo, sincronización más frecuente de paquetes instalados, y mejor lógica de comparación de versiones. El equipo corrigió un problema crítico de flutter_secure_storage y mejoró el manejo de casos límite del gestor de paquetes.

Este hito marca la maduración de la primera plataforma dedicada de distribución de apps de Nostr, permitiendo a desarrolladores publicar aplicaciones Android directamente a usuarios sin el control de acceso de tiendas de apps centralizadas.

ZSP v0.3.1

ZSP, la herramienta CLI en Go del equipo Zapstore que reemplaza las herramientas de publicación anteriores para firmar y subir apps Android a relays Nostr, lanzó v0.3.1. ZSP maneja la adquisición de APK desde GitHub, GitLab, Codeberg, F-Droid o archivos locales, luego parsea metadatos, firma eventos Nostr (vía clave privada, bunker NIP-46 o extensión de navegador NIP-07), y sube artefactos a servidores Blossom. La versión añade modo offline completo para vinculación de keystore sin conexión de red, cabeceras Content-Digest en subidas a Blossom para cumplimiento del protocolo, detección corregida de APK arm64-v8a desde repositorios F-Droid, correcciones de parámetros de consulta trailing de GitLab, y soporte completo de archivos .env para configuración.

Damus iOS 1.17

Damus, el cliente iOS de Nostr, se actualizó a la versión 1.17 (en PR #3606). El lanzamiento corrige un problema de RelayPool donde conexiones se cerraban tras liberar reservas efímeras (vía PR #3605), lo que podía causar que suscripciones se interrumpieran inesperadamente. Resuelve un bug donde la línea de tiempo de favoritos no mostraba eventos al cambiar entre pestañas (en PR #3603).

nak v0.18.3

nak, el Nostr army knife CLI, publicó v0.18.3 con tres correcciones de estabilidad: prevención de panic cuando etiquetas de desafío AUTH son nil o demasiado cortas, verificación de errores de dateparser antes de usar el valor parseado, y manejo de URLs de mint Cashu que carecen del separador ://.

Mi: Relay Local en el Navegador

Mi (mi.shakespeare.wtf), nueva MiniApp de Shakespeare, es un relay local en el navegador que archiva eventos Nostr del usuario en IndexedDB. Mi obtiene perfiles (kind 0), listas de contactos (kind 3), listas de relays (kind 10002) y eventos de billetera desde relays conectados y almacena todo localmente, dando acceso offline a los propios datos. Construido con React y nostr-tools 2.15.0.

Agora v1.0.2

Agora (agora.spot), plataforma de activismo y recaudación de fondos descentralizada del equipo Soapbox, publicó v1.0.2 con APK Android disponible para instalación directa. Primera mención de Agora en Compass. Lanzada el 17 de enero con declaración de misión: “Únete al movimiento global por la libertad. Envía apoyo a activistas en el terreno internacionalmente y participa en acciones locales.”

La plataforma se centra en un mapa mundial donde usuarios exploran por país, crean “acciones” geoetiquetadas (protestas, campañas, organización comunitaria) y las discuten en hilos de comentarios. Todo el contenido se propaga a través de relays Nostr, por lo que ningún servidor central puede ser desconectado para silenciar la coordinación. Agora soporta múltiples idiomas con paridad de traducción verificada por CI, integra servidores de medios Blossom para subidas, e incluye búsqueda, navegación por hashtags con alternancia global/regional, perfiles de usuario y sistemas de reacciones. El lanzamiento v1.0.2 es la build Android actual, disponible como descarga directa de APK.

xonos v0.1.6

xonos, el cliente experimental de Nostr en 3D construido con el motor de juego Bevy, publicó v0.1.6. xonos renderiza eventos Nostr en un entorno espacial 3D con capacidades de text-to-speech, explorando cómo datos del protocolo social podrían funcionar fuera de interfaces 2D convencionales.

Actualizaciones de Proyectos

Primal Android Expande Infraestructura NWC

Primal Android fusionó 18 PRs esta semana, continuando la construcción NWC iniciada la semana pasada. El PR #883 añade soporte para conexiones NWC en ambas billeteras (Spark y externa), y el PR #879 implementa el método NWC lookup_invoice para verificar el estado de pagos.

El registro de auditoría de solicitud-respuesta NWC para depuración de interacciones de billetera llega en PR #880. El soporte multi-cuenta para PrimalNwcService se incorpora en PR #877, permitiendo a usuarios con múltiples perfiles mantener conexiones de billetera separadas. La limpieza periódica de retenciones de presupuesto expiradas en PR #882 previene que reservas de pago obsoletas bloqueen operaciones de billetera.

El trabajo de UI incluye rediseños de la pantalla de actualización de billetera (PR #889), FAQ de actualización de billetera (PR #885), configuración de dirección Lightning durante onboarding (PR #888), y corrección para transacciones de zap que aparecían como pagos regulares en tipos no-Lightning (PR #887).

diVine Lanza Feeds de Video API-First

diVine, el cliente de video de formato corto, fusionó 19 PRs esta semana, orientándose hacia arquitectura API-first. Los feeds de video API-first llegan en PR #1468, y endpoints API de tendencias, recientes y home en PR #1466. La indexación de controladores de video específicos para renderizado eficiente de feeds se implementa en PR #1433.

El manejo de perfiles mejoró con un patrón cache-plus-fresh para ver otros perfiles en PR #1440, reduciendo tiempos de carga mientras asegura datos actualizados. El equipo envió correcciones de notificaciones (PR #1437), refactorización del flujo de comentarios (PR #1431), y deslizamiento de pestañas en la pantalla de Notificaciones (PR #1388).

White Noise: Unificación de Keyring y Búsqueda de Usuarios

El backend White Noise para el protocolo Marmot fusionó 4 PRs esta semana. Dos PRs mejoraron el manejo de keyring: el PR #468 hace el identificador del servicio de keyring configurable vía WhitenoiseConfig, y el PR #475 unifica la implementación en un solo crate keyring-core con almacenes nativos de plataforma, reemplazando código fragmentado específico por plataforma. Por separado, el PR #470 añade funcionalidad de búsqueda de usuarios.

Marmot TS Extrae la App de Chat de Referencia

El SDK TypeScript de Marmot (marmot-ts) fusionó el PR #40, eliminando la aplicación de chat de referencia integrada y separándola en un repositorio independiente: marmots-web-chat. El nuevo repositorio, creado el 6 de febrero, es implementación de referencia del SDK TypeScript de Marmot con su propio pipeline CI, vista de chat con pestañas y sistema de build independiente. La separación permite al SDK enfocarse en asuntos de biblioteca mientras la app de chat itera en UX de forma independiente.

Un PR abierto (#41) migra marmot-ts a ts-mls v2.0.0, trayendo API rediseñada con objetos de contexto unificados, nuevas utilidades de manejo de mensajes (creación de eventos, lectura, deserialización), helpers de metadatos de key package, y soporte de eventos de eliminación.

Actualizaciones de Alby Hub

Alby Hub fusionó 5 PRs esta semana. La adición de Alby CLI a la interfaz de la tienda de apps llega en PR #2049. El manejo de datos de zap inválidos en la lista de transacciones se corrige en PR #2033, y el método ListTransactions no utilizado de la interfaz LNClient se elimina en PR #2046.

Notedeck Lanza Dashboard y Agentium

Notedeck, el cliente Nostr multiplataforma de Damus, fusionó 6 PRs esta semana. La app de dashboard inicial llega en PR #1247. Agentium, un entorno de desarrollo multi-agente que transforma el asistente de IA Dave en un sistema con modos de IA duales y gestión de agentes basada en escenas, se introduce en PR #1293. Un compositor de mensajes multilínea con keybindings estilo Signal llega en PR #1276, y mejoras de rendimiento de medios en PR #1278. PRs abiertos a destacar incluyen infraestructura outbox y planificación de App Git NIP-34.

Agora Lanza Mayor Renovación de UI

Agora fusionó 7 PRs esta semana junto a su lanzamiento v1.0.2. El más grande es PR #106, cerrando 11 tareas de UI en ajustes, edición de perfil, interacciones de mapa, resultados de búsqueda, filtrado de comentarios y gestión de servidor Blossom. La fusión desactivó botones de reacción para usuarios no autenticados (que antes obtenían fallos silenciosos al intentar reaccionar a posts en el mapa), corrigió el paneo de mapa en la línea de fecha, y añadió texto coincidente en negrita en resultados de búsqueda.

Conteos de comentarios bajo posts del feed y en páginas de hilos llegan en PR #108. El reintento automático en fallos de carga de eventos con botón de recarga explícito cuando reintentos se agotan se añade en PR #107. La navegación de hashtags pasa a alcance global por defecto en PR #104, ya que el alcance por país anterior frecuentemente retornaba cero resultados.

Un paso CI que verifica paridad de traducción en todos los idiomas, fallando el build si alguna clave carece de valor, se incorpora en PR #109. El recorte de notas grandes en feeds para preservar el ritmo de scroll llega en PR #110, y la corrección de un problema de zoom en iOS móvil al comentar acciones causado por tamaños de fuente pequeños en PR #111.

Clawstr Lanza CLI y Botones de Lightning Zap

Clawstr, la plataforma inspirada en Reddit donde agentes de IA crean y gestionan comunidades en Nostr, fusionó 3 PRs esta semana. En PR #11, todos los comandos manuales de nak en definiciones de habilidades del agente de IA se reemplazan con el nuevo paquete @clawstr/cli (npx -y @clawstr/cli@latest), eliminando la construcción manual de eventos JSON a favor de comandos CLI y añadiendo operaciones de billetera (init, balance, zap, npc) y búsqueda de texto completo NIP-50.

La página de documentación “Para Humanos” y el componente ProfileZapDialog llegan en PR #13. El botón de zap aparece en páginas de perfil cuando el usuario tiene dirección Lightning configurada y funciona sin login, usando LNURL-pay directamente con cantidades preestablecidas de sats y visualización de código QR. La documentación del comando wallet sync en PR #12 explica cómo pagos a direcciones Lightning son retenidos por NPC hasta que agentes sincronizan explícitamente sus billeteras.

Actualizaciones de NIPs

Cambios recientes al repositorio de NIPs:

Fusionados:

NIP-45: Respuesta HyperLogLog de Relay - NIP-45 (Conteo de Eventos) ahora soporta conteo aproximado HyperLogLog (HLL). Relays pueden retornar valores de registro HLL de 256 bytes junto a respuestas COUNT. Al fusionar estos registros de múltiples relays, clientes computan cardinalidad aproximada sin descargar conjuntos completos de eventos. El caso de uso principal son conteos de seguidores y reacciones sin depender de un único relay como fuente autoritativa. Incluso dos eventos de reacción consumen más ancho de banda que el payload HLL de 256 bytes. Correcciones HyperLogLog++ mejoran la precisión en cardinalidades pequeñas.
NIP-39: Etiquetas de Identidad Movidas del Kind 0 - Las etiquetas de claim de identidad (etiquetas i) de NIP-39 han sido extraídas de eventos de metadatos kind 0 a un nuevo kind dedicado 10011. La razón: casi ningún cliente soporta estas etiquetas, por lo que añaden tamaño a cada consulta de kind 0 sin proporcionar valor. Primer PR de la serie de extracción del kind 0 de vitorpamplona (ver sección de Noticias).

PRs Abiertos y Discusiones:

NIP-XX: Nostr Relay Connect (NRC) - woikos propone un protocolo para acceder a relays Nostr a través de tunneling cifrado vía relay de rendez-vous público. El mecanismo permite acceso a relays detrás de NAT o firewalls, incluyendo relays personales ejecutándose en servidores domésticos o dispositivos móviles. El tunneling usa eventos kind 24891/24892 con cifrado NIP-44 vía relay de rendez-vous que no puede descifrar el tráfico. Aplicación práctica: cualquier cliente Nostr puede exponer almacenamiento local (IndexedDB, SQLite) como endpoint de relay para sincronización entre dispositivos. La semántica estándar de NIP-01 (REQ, EVENT, CLOSE, COUNT) pasa a través del túnel de forma transparente. Existen implementaciones de referencia en Go (ORLY Relay) y TypeScript (Smesh).
Nostr Web Tokens (NWT) - pippellia-btc propone Nostr Web Tokens, formato de evento Nostr para transmitir claims firmados entre partes web, inspirado en JSON Web Tokens (JWTs). NWT puede representar tanto NIP-98 (HTTP Auth) como eventos de autorización Blossom, dando a clientes flexibilidad en cómo y por cuánto tiempo los tokens permanecen válidos. Hay biblioteca de referencia en Go disponible. La explicación en video y la comparación detallada con NIP-98 y Blossom Auth están enlazadas en el PR.
Simplificación de NIP-47 - rolznz propone eliminar los métodos multi_ de NIP-47 (Nostr Wallet Connect), que eran complejos de implementar y no ganaron adopción. El PR reduce duplicación en cifrado y manejo de compatibilidad hacia atrás, limpiando la spec tras la adición de facturas hold de la semana pasada.
NIP-05: Mover a Kind de Evento Propio - vitorpamplona propone mover la verificación NIP-05 del kind 0 a nuevo kind 10008, habilitando múltiples identificadores NIP-05 por usuario y filtrado por dirección NIP-05. Parte de la campaña de reducción del kind 0.
NIP-57: Direcciones Lightning del Kind 0 - vitorpamplona propone extraer lud06/lud16 (direcciones Lightning) del kind 0 a kind de evento dedicado según NIP-57, continuando el esfuerzo de reducción del kind 0.
Hiperpersonalización de Perfiles - fiatjaf propone capacidades extendidas de personalización de perfil más allá de lo que el kind 0 soporta actualmente.

Análisis Profundo de NIP: NIP-45 (Conteo de Eventos) y HyperLogLog

NIP-45 (spec) define cómo clientes pueden pedir a relays que cuenten eventos que coincidan con un filtro sin transferir los eventos en sí. La fusión de soporte HyperLogLog esta semana añade estructura de datos probabilística que resuelve un problema fundamental: cómo contar cosas a través de múltiples relays independientes.

El Problema:

Contar eventos en un único relay es simple: envía solicitud COUNT, recibe un número. Contar a través de la red es más difícil. Si el relay A reporta 50 reacciones y el relay B reporta 40, el total no es 90 porque muchos eventos existen en ambos relays. Al no descargar todos los eventos para deduplicar, el cliente no puede calcular el conteo real.

HyperLogLog:

HyperLogLog (HLL) es un algoritmo probabilístico que estima el número de elementos distintos en un conjunto usando cantidad fija de memoria. La implementación de NIP-45 usa 256 registros de un byte cada uno, consumiendo exactamente 256 bytes sin importar cuántos eventos se cuenten. El algoritmo funciona examinando la representación binaria de cada ID de evento y rastreando la posición de ceros iniciales. Eventos cuyos IDs comienzan con muchos ceros son estadísticamente raros, por lo que su ocurrencia indica un conjunto grande.

Cómo Funciona en NIP-45:

Un relay que responde a solicitud COUNT puede incluir un campo hll conteniendo valores de registro codificados en base64:

["COUNT", "<subscription_id>", {"count": 4527, "hll": "<base64 encoded 256 bytes>"}]

El cliente recolecta valores HLL de múltiples relays y los fusiona tomando el valor máximo en cada posición de registro. El HLL fusionado representa la unión de todos los conjuntos de eventos a través de relays, manejando la deduplicación automáticamente. La estimación final de cardinalidad se calcula a partir de registros fusionados.

Precisión:

El error estándar con 256 registros es aproximadamente 5.2%. Para un conteo real de 1,000, la estimación típicamente caerá entre 948 y 1,052. Para conteos más grandes, el error relativo se mantiene constante: un conteo real de 100,000 estimará aproximadamente entre 94,800 y 105,200. Correcciones HyperLogLog++ mejoran la precisión para cardinalidades pequeñas (menores a ~200), donde el algoritmo básico tiende a sobreestimar.

Por Qué Importa:

Métricas sociales (conteos de seguidores, conteos de reacciones, conteos de reposts) son función central de clientes de redes sociales. El cliente que no cuente con HLL debe consultar un único relay “de confianza” (centralizando el conteo) o descargar todos los eventos de todos los relays (desperdiciando ancho de banda). HLL permite obtener buen conteo aproximado de múltiples relays con overhead total de 256 bytes por relay, sin importar el conteo real. Incluso dos eventos de reacción consumen más ancho de banda que un payload HLL completo.

La spec fija el número de registros en 256 para interoperabilidad. Todos los relays producen valores HLL que clientes pueden fusionar, sin importar qué implementación de relay ejecuten. Esta estandarización significa que el cliente puede implementar soporte HLL una vez y beneficiarse de cada relay que lo soporte.

Estado Actual:

El PR fue abierto por fiatjaf y había estado en discusión durante varios meses antes de fusionarse esta semana. Implementaciones de relay necesitarán añadir computación HLL a sus manejadores COUNT. Implementaciones de clientes necesitarán añadir fusión HLL a su lógica de agregación de conteos.

Análisis Profundo de NIP: NIP-96 (Almacenamiento de Archivos HTTP) y la Transición a Blossom

NIP-96 (spec) definió cómo clientes Nostr suben, descargan y gestionan archivos en servidores de medios HTTP. Ahora marcado como “no recomendado” en favor de Blossom (alojamiento de medios basado en BUD), NIP-96 sigue siendo relevante esta semana porque Angor v0.2.5 añadió configuración de servidor NIP-96 y ZSP v0.3.1 sube a servidores Blossom, ilustrando la transición de protocolo en curso.

Cómo Funciona NIP-96:

El cliente descubre las capacidades de un servidor de archivos consultando /.well-known/nostr/nip96.json, que retorna la URL de API, tipos de contenido soportados, límites de tamaño y transformaciones de medios disponibles:

{
 "api_url": "https://file-server.example/api",
 "download_url": "https://cdn.example/files",
 "content_types": ["image/jpeg", "video/webm", "audio/*"],
 "plans": {
 "free": {
 "is_nip98_required": true,
 "max_byte_size": 10485760,
 "media_transformations": {
 "image": ["resizing"]
 }
 }
 }
}

Para subir, el cliente envía POST multipart/form-data a la URL de API con cabecera de autorización NIP-98 (evento Nostr firmado que prueba la identidad del uploader). El servidor retorna estructura de metadatos de archivo NIP-94 conteniendo la URL del archivo, hashes SHA-256 original y transformado, tipo MIME y dimensiones:

{
 "status": "success",
 "nip94_event": {
 "tags": [
 ["url", "https://cdn.example/files/<hash>.png"],
 ["ox", "<original-file-hash>"],
 ["x", "<transformed-file-hash>"],
 ["m", "image/png"],
 ["dim", "800x600"]
 ]
 }
}

Las descargas usan solicitudes GET a <api_url>/<sha256-hash>, con parámetros de consulta opcionales para transformaciones del lado del servidor como redimensionamiento de imágenes (?w=320). La eliminación usa DELETE con auth NIP-98, y solo el uploader original puede eliminar sus archivos. Un endpoint de listado retorna resultados paginados de subidas del usuario.

Cada usuario declara sus servidores de subida preferidos publicando eventos kind 10096, permitiendo a clientes seleccionar automáticamente el servidor correcto sin configuración manual.

Por Qué Fue Obsoletado:

NIP-96 ataba URLs de archivos a servidores específicos. Si files.example.com dejaba de funcionar, cada nota Nostr que referenciaba las URLs de ese servidor perdía sus medios. El servidor era la dirección, y la dirección era frágil.

Blossom (Blobs Stored Simply on Mediaservers) invierte esto haciendo del hash SHA-256 del contenido del archivo el identificador canónico. Una URL de Blossom luce como https://blossom.example/<sha256>.png, pero cualquier servidor Blossom que aloje el mismo archivo lo sirve en la misma ruta de hash. Si un servidor desaparece, el cliente consulta otro servidor por el mismo hash. El direccionamiento por contenido hace datos portables entre servidores por defecto.

Blossom simplifica la API. NIP-96 usaba subidas multipart form con respuestas JSON, políticas de transformación y endpoint de descubrimiento. Blossom usa PUT simple para subidas, GET para descargas y eventos Nostr firmados (no cabeceras HTTP) para autorización. La especificación de Blossom se divide en documentos modulares: BUD-01 cubre protocolo de servidor, autorización y recuperación, BUD-02 cubre subida de blobs, BUD-03 cubre servidores de usuarios, y BUD-04 cubre espejeo entre servidores.

La obsolescencia ocurrió en septiembre 2025 vía PR #2047, que marcó NIP-96 como “no recomendado” en el índice de NIPs.

La Transición en la Práctica:

Servidores como nostr.build y void.cat soportaban NIP-96 y han añadido o migrado a endpoints Blossom. Cada cliente está en distinta etapa de adopción. El lanzamiento v0.2.5 de Angor esta semana añadió configuración de servidor NIP-96 para imágenes de proyecto, mientras el lanzamiento v0.3.1 de ZSP sube artefactos exclusivamente a servidores Blossom con cabeceras Content-Digest para cumplimiento del protocolo. Amethyst y Primal soportan subidas Blossom. La coexistencia probablemente continuará hasta que implementaciones restantes de NIP-96 completen su migración.

Qué Se Mantiene:

Eventos kind 10096 de preferencia de servidor siguen siendo útiles para la selección de servidor Blossom. Metadatos de archivo NIP-94 (eventos kind 1063) siguen describiendo propiedades de archivos con independencia de qué protocolo de subida los creó. El hashing SHA-256 que NIP-96 usaba para URLs de descarga se convirtió en la base del direccionamiento por contenido de Blossom. El diseño de NIP-96 informó lo que Blossom simplificó: la lección fue que el alojamiento de medios en red descentralizada requiere almacenamiento direccionado por contenido para igualar la resistencia a la censura de la capa de relays.

Eso es todo por esta semana. Envíanos noticias, sugerencias de cobertura o información sobre tu proyecto. Escríbenos vía DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #8

Wed, 04 Feb 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: rust-nostr lanza un importante rediseño de API con 21 PRs reformulando la arquitectura del SDK. Nostria 3.0 se lanza con navegación de panel dual, gestión de listas y una renovación completa de la interfaz. Vector añade aceleración SIMD logrando mejoras de velocidad de 65x-184x y lanza soporte del protocolo Marmot para mensajería grupal cifrada. Frostr trae firma de umbral a iOS vía TestFlight. Damus implementa pistas de relay NIP-19 (Entidades Codificadas en Bech32) para descubrimiento de contenido entre relays. Primal Android añade cifrado NWC y exportación de transacciones de billetera. nostr-tools y NDK reciben mejoras de confiabilidad. NIP-82 (Aplicaciones de Software) se expande para cubrir el 98% de plataformas de dispositivos. El repositorio de NIPs fusiona soporte de facturas hold para NIP-47 (Nostr Wallet Connect). Nuevas propuestas de protocolo incluyen NIP-74 para podcasting, NIP-DB para bases de datos de eventos en navegador, y una suite de Filtros TRUSTed para curación de contenido descentralizada. Nuevos proyectos incluyen Instagram to Nostr v2 para migración de contenido, Pod21 lanzando un marketplace descentralizado de impresión 3D, Clawstr introduciendo comunidades gestionadas por agentes de IA, y Shosho y NosCall expandiendo capacidades de streaming en vivo y videollamadas.

Noticias

rust-nostr Lanza Mayor Rediseño de API

El SDK rust-nostr experimentó una reformulación significativa de arquitectura esta semana con 21 PRs fusionados introduciendo cambios incompatibles en toda la biblioteca. El rediseño afecta APIs centrales de las que dependen la mayoría de los desarrolladores de Rust.

PR #1245 rediseña APIs de notificación, mientras PR #1244 reemplaza RelayNotification::Shutdown con RelayStatus::Shutdown para un manejo de estado más limpio. Las APIs de firmante ahora se alinean con otros patrones del SDK vía PR #1243. Los métodos de Client y Relay recibieron limpieza en PR #1242, y las opciones de cliente ahora usan un patrón builder (PR #1241).

Las APIs de envío de mensajes fueron rediseñadas en PR #1240, la desuscripción REQ en PR #1239, y la eliminación de relay en PR #1229. Un PR abierto #1246 añade soporte para APIs de bloqueo para completar el rediseño.

Los cambios traen consistencia al SDK pero requerirán esfuerzo de migración de proyectos existentes. Los desarrolladores que construyen sobre rust-nostr deberían revisar el changelog cuidadosamente antes de actualizar.

Instagram to Nostr v2 Habilita Migración de Contenido

Una nueva herramienta permite a los creadores migrar su contenido existente de plataformas centralizadas a Nostr. Instagram to Nostr v2 soporta importación desde Instagram, TikTok, Twitter y Substack sin requerir acceso a las claves privadas del usuario.

La herramienta aborda una barrera común de incorporación: usuarios reacios a empezar de cero en una nueva plataforma pueden ahora preservar su historial de contenido. También soporta regalar cuentas Nostr a nuevos usuarios o proponer contenido a cuentas existentes, haciéndola útil para ayudar a otros a transicionar al protocolo.

Pod21: Red Descentralizada de Impresión 3D

Pod21 (pod21.com) conecta operadores de impresoras 3D con compradores usando Nostr para coordinación de marketplace. La plataforma incluye un bot de DM compatible con NIP-17 (Mensajes Directos Privados) que maneja interacciones de marketplace, permitiendo a compradores solicitar impresiones y negociar con fabricantes a través de mensajes directos cifrados.

Los fabricantes listan su capacidad y características de impresión; los compradores navegan listados e inician órdenes vía el bot. La arquitectura sigue un patrón similar a otras aplicaciones de comercio Nostr: descubrimiento basado en relay, mensajería cifrada para coordinación de órdenes, y Lightning para liquidación. Pod21 se une a Ridestr y Shopstr como aplicaciones Nostr coordinando transacciones del mundo real a través del protocolo.

Clawstr se lanza como una plataforma inspirada en Reddit donde agentes de IA crean y gestionan comunidades en Nostr. La plataforma permite a agentes autónomos establecer comunidades temáticas, curar contenido e interactuar con usuarios. Las comunidades funcionan como subreddits pero con moderadores y curadores de IA guiando las discusiones. La arquitectura usa el protocolo abierto de Nostr para interacciones agente-a-agente y agente-a-humano, estableciendo un nuevo modelo para formación de comunidades en redes sociales descentralizadas.

Lanzamientos

Ridestr v0.2.0: Lanzamiento RoadFlare

Ridestr lanzó v0.2.0, denominado el “Lanzamiento RoadFlare”, introduciendo redes de viaje compartido personales. La característica permite a los pasajeros agregar conductores favoritos a una red de confianza. Los conductores aprueban seguidores y comparten ubicaciones cifradas, permitiendo a los pasajeros ver cuando conductores de confianza están en línea y cerca. Las solicitudes de viaje van directamente a conductores conocidos.

La confiabilidad de pagos mejoró con recuperación automática de depósito, mejor sincronización de billetera entre dispositivos, y procesamiento de pagos más rápido vía polling progresivo. PR #37 añade la infraestructura de Fase 5-6 soportando estas características. v0.2.1 siguió con correcciones para bugs del diálogo de pago y el flujo “Agregar a Favoritos” post-viaje.

Nostria 3.0

Nostria, el cliente multiplataforma de sondreb construido para escala global, lanzó la versión 3.0 con una renovación completa de UI, nuevo logo, y cientos de correcciones. El lanzamiento representa un ciclo de desarrollo intensivo de seis semanas.

La navegación de panel dual es el mayor cambio de UX, permitiendo a usuarios de escritorio reducir el cambio de contexto al moverse entre listas, detalles e hilos. Una nueva sección Home proporciona una visión general de todas las características disponibles, y todas las pantallas comparten barra de herramientas, diseño y funcionalidad unificados.

La gestión de listas es la actualización de característica más significativa, integrándose en toda la aplicación. Los usuarios pueden gestionar listas de perfiles y filtrar contenido en cualquier característica: Streams, Música o Feeds. ¿Cansado del spam en hilos? Filtra por favoritos para ver solo sus respuestas. Quick Zaps añade zapping de un toque con valores configurables. Copy/Screenshot genera capturas de pantalla al portapapeles para compartir eventos en cualquier lugar. Muted Words ahora filtra en campos de perfil (name, display_name, NIP-05), permitiendo a usuarios bloquear todos los perfiles de bridge con una sola palabra prohibida. Configuración se volvió buscable para cambios de configuración más rápidos.

El lanzamiento añade renderizado de solicitudes de pago BOLT11 y BOLT12, selección de tamaño de texto y fuente, y mensajería “Nota para Uno Mismo” en la sección de Mensajes con renderizado de contenido referenciado como artículos y eventos. El nuevo diálogo de Compartir permite compartir rápidamente vía correo electrónico, sitios web o mensajes directos a múltiples destinatarios. Características adicionales incluyen conjuntos de emoji personalizados, Intereses (listas de hashtags como feeds dinámicos), Marcadores, Feeds de Relay Públicos, y personalización completa del menú incluyendo qué opción abre el icono de Nostria.

Disponible en Android, iOS, Windows y web en nostria.app.

Applesauce v5.1.0

La suite de bibliotecas Applesauce de hzrd149 lanzó v5.1.0 en todos los paquetes. applesauce-signers añade soporte para métodos switch_relays y ping en firmantes remotos Nostr Connect, útil para gestionar conexiones de firmantes programáticamente. applesauce-loaders introduce loadAsyncMap para carga asíncrona paralela. applesauce-react añade argumentos de padding a useAction().run(). applesauce-core actualiza el mapeo de evento a store para manejar strings directamente sin requerir onlyEvents.

nak v0.18.3

nak (Nostr Army Knife) de fiatjaf alcanzó v0.18.3 con correcciones de estabilidad de mattn. El lanzamiento previene panics cuando URLs de mint carecen del separador ://, valida errores de dateparser antes de usar valores de fecha, y maneja casos límite en el parseo de etiquetas de desafío AUTH. Estas correcciones defensivas hacen el CLI más resiliente al procesar entradas malformadas.

Aegis v0.3.7

Aegis, el firmante de escritorio multiplataforma, lanzó v0.3.7 añadiendo soporte de Navegador de Apps Nostr con firma NIP-07 (Interfaz de Extensión de Navegador). El lanzamiento registra eventos de cifrado NIP-04 (Mensajes Directos Cifrados) y NIP-44 (Cifrado Versionado), permitiendo a usuarios rastrear qué aplicaciones solicitan operaciones de cifrado. El segmento de navegador ahora filtra por plataforma para mostrar solo apps web.

Bitchat v1.5.1 (iOS)

Bitchat, la app de mensajería con capacidad offline usando Nostr y mesh Bluetooth, lanzó v1.5.1 con endurecimiento de seguridad para iOS. PR #1012 valida firmas de eventos Nostr antes de procesar, rechaza giftwraps y paquetes incrustados inválidos, limita cargas sobredimensionadas, y bloquea IDs de remitente de anuncio BLE falsificados. PR #998 corrige autenticación de mesh BLE de iOS vinculando IDs de remitente a UUIDs de conexión, previniendo suplantación de identidad en la red mesh. PR #972 añade limitación de tasa de notificaciones para prevenir inundaciones de descubrimiento de peers cuando múltiples dispositivos mesh están cerca.

KeyChat v1.39.2

KeyChat lanzó v1.39.2 añadiendo soporte NIP-47 Nostr Wallet Connect vía PR #148. Los usuarios pueden ahora conectar billeteras Lightning externas para pagos dentro de la app de mensajería. El lanzamiento también añade notificaciones de escritorio macOS.

Nostrmo v3.5.0

Nostrmo, el cliente Flutter multiplataforma, lanzó v3.5.0 reformulando su sistema de feeds. La actualización reemplaza feeds fijos con alternativas personalizables: Feed General, Feed de Menciones y Feed de Relay, cada uno configurable a través de nuevas páginas de edición. El lanzamiento implementa soporte del modelo outbox para mejor enrutamiento de eventos y expande la funcionalidad de relay local con límites de tamaño configurables y soporte de suscripción.

Shosho v0.11.1

Shosho, la app de streaming en vivo para Nostr, lanzó v0.11.1 con capacidades de grabación y VOD. La actualización añade indicadores de presencia de sala mostrando quién está viendo streams, conversaciones de chat en hilos para mejor organización de discusiones, y soporte Nostr Connect en iOS vía NIP-46. Los streamers pueden ahora guardar sus transmisiones para visualización posterior mientras mantienen interacciones de chat en tiempo real con su audiencia.

NosCall v0.5.0

NosCall, la app de llamadas de audio y video para Nostr, lanzó v0.5.0 con grupos de contactos para organizar llamadas por categoría, gestión de relay para optimización de conexión, y configuración de servidor ICE configurable para mejor traversal de NAT. El lanzamiento también añade soporte de modo oscuro. NosCall usa Nostr para señalización y coordinación de llamadas, habilitando llamadas peer-to-peer sin servidores centralizados.

diVine 1.0.4

diVine, el cliente de video de formato corto en bucle de rabble, lanzó 1.0.4 como pre-lanzamiento alpha de Android antes de su envío a Zapstore. El lanzamiento se enfoca en probar gestión de claves Nostr, incluyendo importación de nsec, firma remota NIP-46 (Nostr Connect) con nsecBunker y Amber, y manejo de URLs nostrconnect://. El equipo está solicitando feedback sobre compatibilidad de relays e interoperabilidad de video con otros clientes. PR #1265 corrige el manejo de rutas de archivo iOS que causaba que clips de video se volvieran inutilizables después de actualizaciones de app almacenando rutas relativas en lugar de rutas absolutas de contenedor. PR #1251 corrige problemas de navegación al ver perfiles desde comentarios.

Zeus v0.12.2

Zeus lanzó v0.12.2 como lanzamiento estable, consolidando las correcciones NWC cubiertas en ediciones anteriores.

Frostr Igloo iOS TestFlight

Frostr (frostr.org) lanzó Igloo para iOS en TestFlight, expandiendo firma de umbral a dispositivos Apple. Frostr usa firmas FROST (Flexible Round-Optimized Schnorr Threshold) para dividir claves nsec en shares distribuidos entre dispositivos, habilitando firma k-de-n con tolerancia a fallos. Los usuarios que se unen en “modo demo” participan en un experimento de firma de umbral 2-de-2 en vivo, demostrando las capacidades de coordinación en tiempo real del protocolo. El lanzamiento iOS se une a Igloo para Android (v0.1.2), que se lanzó en diciembre con soporte NIP-55 (Firmante Android) para solicitudes de firma entre apps. Ambos clientes móviles complementan Igloo desktop y la extensión de navegador Frost2x.

Actualizaciones de Proyectos

Damus Implementa Pistas de Relay NIP-19

Damus fusionó PR #3477, implementando consumo de pistas de relay NIP-19 para obtención de eventos. La característica habilita ver notas en relays no incluidos en el pool configurado del usuario extrayendo pistas de referencias NIP-10 (Hilos de Respuesta), NIP-18 (Reposts) y NIP-19. La implementación usa conexiones de relay efímeras con limpieza contada por referencia, evitando expansión permanente del pool de relays.

Correcciones adicionales incluyen parseo de facturas Lightning (PR #3566), carga de vista de billetera (PR #3554), timing de lista de relays (PR #3553), y precarga de perfiles para reducir “popping” visual (PR #3550). Un borrador PR #3590 muestra soporte de DM privado NIP-17 en progreso.

Primal Android Lanza Cifrado NWC

Primal Android tuvo una semana muy activa con 18 PRs fusionados enfocados en infraestructura de billetera. La app ahora se integra con Spark, el protocolo Lightning auto-custodiado de Lightspark. PR #874 añade soporte de cifrado NWC, mientras PR #872 envía eventos de info NWC cuando se establecen conexiones.

PR #870 habilita exportación CSV para transacciones de billetera, útil para contabilidad e impuestos. PR #716 añade un cambiador de cuenta local en el Editor de Notas. Múltiples correcciones de restauración de billetera (PR #876, PR #875, PR #873) abordan casos límite para usuarios con configuraciones de billetera no-Spark.

SDK TypeScript de Marmot Añade Historial de Mensajes

La implementación TypeScript del protocolo Marmot continúa en desarrollo. PR #38 de hzrd149 implementa persistencia de historial de mensajes con paginación para la aplicación de chat de referencia, mientras PR #39 mejora la ergonomía de la biblioteca.

En el lado Rust, PR #161 implementa manejo de estado reintentable para preservar contexto de mensajes en fallos, y PR #164 cambia a std::sync::Mutex para evitar panics de tokio con SQLite. El backend whitenoise-rs añade integración con Amber (PR #418), actualiza a MDK y nostr-sdk 0.44 (PR #467), e introduce streaming de notificaciones en tiempo real vía PR #460 con tipos de evento NewMessage y GroupInvite.

HAVEN Añade Refresco Periódico de WoT

HAVEN, el relay personal, fusionó PR #108 añadiendo refresco periódico de Web of Trust. La característica asegura que las puntuaciones de confianza se mantengan actualizadas a medida que evolucionan los grafos sociales de los usuarios, mejorando la precisión del filtrado de spam con el tiempo.

nostr-tools

nostr-tools, la biblioteca principal de JavaScript, recibió múltiples mejoras esta semana. Los commits incluyen una corrección para parseo de hashtags después de saltos de línea en menciones NIP-27 (Referencias de Notas de Texto), poda automática de objetos de relay rotos con seguimiento de inactividad para limpieza de conexiones, eliminación de cola de mensajes para optimización de rendimiento de hilo único, y exportaciones de archivos fuente para mejores imports de TypeScript.

NDK

NDK lanzó beta.71 con una corrección para reconexión después de ciclos de suspensión/despertar del dispositivo y manejo de conexiones obsoletas, abordando problemas de confiabilidad para aplicaciones móviles.

Notedeck

Notedeck, el cliente de escritorio del equipo Damus, tiene un PR abierto #1279 añadiendo un visor NIP-34 (Colaboración Git). Esto habilitaría navegar repositorios git, parches e issues publicados en relays de Nostr directamente dentro del cliente, haciendo de Notedeck un potencial front-end para flujos de trabajo basados en ngit.

njump

njump, el gateway web de Nostr, añadió soporte para dos tipos de evento NIP-51 (Listas) vía PR #152. El gateway ahora renderiza kind:30000 Follow Sets, que son agrupaciones categorizadas de usuarios que los clientes pueden mostrar en diferentes contextos, y kind:39089 Starter Packs, que son colecciones de perfiles curadas diseñadas para compartir y seguimiento grupal. Estas adiciones permiten a njump mostrar listas curadas por la comunidad cuando usuarios comparten enlaces nevent.

Amethyst

Amethyst, el cliente Android, corrigió un bug que prevenía compartir video desde la vista del reproductor (PR #1695). La opción “Compartir video” estaba fallando al aparecer porque el parámetro de contenido no se estaba pasando al componente de botones de control. Los usuarios pueden ahora compartir contenido de video de Nostr a otras apps directamente desde el reproductor. PR #1693 corrige crashes de deserialización Jackson JSON que ocurrían al parsear ciertos eventos malformados.

Jumble

Jumble, el cliente web enfocado en navegación de feeds de relay, añadió cargas de archivos de audio vía portapapeles en PR #743. Los usuarios pueden ahora pegar archivos de audio directamente en el editor de publicaciones, que los sube a servidores de medios configurados e incrusta la URL en la nota. La característica refleja la funcionalidad existente de pegado de imágenes.

Flotilla

Flotilla, el cliente de comunidades NIP-29 (Grupos Basados en Relay) de hodlbod, lanzó notificaciones vía PR #270. La actualización refactoriza el sistema de alertas de polling basado en anchor a notificaciones pull locales para web y notificaciones push para móvil. La arquitectura implementa el estándar propuesto NIP-9a (ver PR #2194 abajo), donde usuarios registran callbacks de webhook con relays y reciben cargas de eventos cifradas cuando los filtros coinciden.

Formstr

Formstr, la aplicación de formularios nativa de Nostr, añadió importación de formularios y soporte de formularios cifrados en PR #422. Los usuarios pueden ahora importar formularios existentes mediante un enlace de respuesta o desde otras instancias de Formstr. La característica de cifrado permite a creadores de formularios restringir respuestas para que solo destinatarios designados puedan leer los envíos, útil para encuestas que recolectan información sensible.

Pollerama

Pollerama (pollerama.fun), construido sobre nostr-tools, añadió compartir encuestas vía DM NIP-17 en PR #141 y PR #142. Los usuarios pueden ahora compartir encuestas directamente a contactos a través de mensajes directos cifrados.

Nostrability Schemata

Nostrability schemata, la colección de esquemas de verificación JSON para eventos Nostr, añadió cobertura de NIP-59 (Gift Wrap) vía PR #59. La actualización incluye esquemas para eventos kind 13 (seal) y kind 1059 (gift wrap), complementando la cobertura existente de esquema NIP-17.

Vector

Vector, el mensajero de escritorio enfocado en privacidad usando NIP-17, NIP-44 y NIP-59 para cifrado sin metadatos, fusionó PR #39 introduciendo optimizaciones de rendimiento aceleradas por SIMD. La codificación hex corre 65x más rápido, la generación de vista previa de imágenes hasta 38x más rápida, y las búsquedas de mensajes 184x más rápidas vía indexación de búsqueda binaria. El PR añade intrínsecos NEON ARM64 para Apple Silicon y AVX2/SSE2 x86_64 con detección en tiempo de ejecución para Windows y Linux. El uso de memoria bajó con structs de mensaje reducidos de 472 a 128 bytes y almacenamiento de npub cortado en 99.6% mediante interning.

Vector v0.3.0 (diciembre 2025) integró MDK (Marmot Development Kit) para mensajería grupal basada en protocolo MLS, trayendo grupos cifrados de extremo a extremo con secreto hacia adelante al cliente. El compartir archivos MIP-04 ahora maneja adjuntos imeta para grupos MLS, diseñado para interoperabilidad con White Noise. El lanzamiento también introdujo una plataforma Mini Apps con juegos multijugador P2P basados en WebXDC, una tienda de apps descentralizada llamada The Nexus, integración de billetera PIVX para pagos en la app, edición de mensajes con seguimiento completo de historial, y reducción de memoria 4x durante subidas de imágenes.

Actualizaciones de NIPs

Cambios recientes al repositorio de NIPs:

Fusionados:

NIP-47: Soporte de Facturas Hold - NIP-47 (Nostr Wallet Connect) ahora soporta facturas hold, habilitando flujos de trabajo de pago avanzados donde los receptores deben liquidar o cancelar pagos explícitamente. El PR añade tres nuevos métodos RPC: make_hold_invoice crea una factura hold usando una preimagen pre-generada y hash de pago, settle_hold_invoice reclama el pago proporcionando la preimagen original, y cancel_hold_invoice rechaza el pago usando su hash de pago. Una nueva notificación hold_invoice_accepted se dispara cuando un pagador bloquea el pago. Esto habilita casos de uso como contenido de pago-para-desbloquear, sistemas de escrow de marketplace, y control de acceso por pago. Las implementaciones ya están en marcha en Alby Hub, Alby JS-SDK y dart NDK.
NIP-05: Requisito de Minúsculas - NIP-05 (Verificación de Dominio) ahora requiere explícitamente minúsculas tanto para claves públicas hex como para nombres locales en el archivo nostr.json. Esto era implícito en la especificación pero no estaba declarado, causando problemas de interoperabilidad cuando algunas implementaciones usaban mayúsculas mixtas mientras otras normalizaban a minúsculas. Los clientes validando identificadores NIP-05 deberían ahora rechazar cualquier respuesta nostr.json que contenga caracteres mayúsculas en claves o nombres.
NIP-73: Códigos de País - NIP-73 (Geoetiquetas) ahora soporta códigos de país ISO 3166 como alternativa a geohashes. Los eventos pueden incluir etiquetas ["g", "US", "countryCode"] para indicar ubicación a nivel de país sin requerir coordenadas precisas. Esto habilita filtrado y descubrimiento de contenido basado en país para aplicaciones donde la ubicación exacta es innecesaria o indeseable. El PR también añadió un ejemplo de geohash faltante a la documentación de la especificación.

PRs Abiertos y Discusiones:

NIP-82: Aplicaciones de Software - franzap anunció una actualización mayor a esta especificación borrador, que define cómo se distribuyen aplicaciones de software vía Nostr usando eventos de lanzamiento kind 30063. La actualización ahora cubre aproximadamente el 98% de las plataformas de dispositivos globalmente, incluyendo macOS, Linux, Windows, FreeBSD, entornos WASM, extensiones de VS Code, extensiones de Chrome, y Web Bundles/PWAs. El equipo se está enfocando ahora en soporte para Android, PWA e iOS, invitando a desarrolladores a converger en este estándar compartido. Zapstore planea migrar al nuevo formato en las próximas semanas.
NIP-74: Podcasts - Define eventos direccionables para programas de podcast (kind 30074) y episodios (kind 30075). Los programas incluyen metadatos como título, descripción, categorías e imágenes de portada. Los episodios referencian su programa padre e incluyen URLs de enclosure, duraciones y marcadores de capítulos. La especificación se integra con estándares de metadatos Podcasting 2.0 e incluye etiquetas de valor para monetización V4V (valor-por-valor) vía Lightning. Plataformas como transmit.fm, una plataforma de publicación de podcasts nativa de Nostr, pueden publicar directamente a relays usando este formato, permitiendo a podcasters distribuir contenido sin intermediarios.
NIP-FR: Notas Solo-Amigos - Propone un mecanismo para publicar notas visibles solo para una lista de amigos definida por el usuario, utilizando una clave simétrica compartida llamada ViewKey. El autor cifra notas (kind 2044) con el ViewKey usando NIP-44. El ViewKey se distribuye a cada amigo una sola vez mediante NIP-59 (Gift Wrap). Los amigos que poseen el ViewKey pueden descifrar y leer las notas; todos los demás solo ven texto cifrado. Cuando el autor elimina a un amigo, el ViewKey se rota: se genera una nueva clave y se redistribuye a todos los amigos restantes vía gift wrap, asegurando que el amigo eliminado pierda acceso a publicaciones futuras. Este enfoque separa el cifrado de contenido (simétrico, eficiente) de la distribución de claves (asimétrica, por amigo), manteniendo el protocolo liviano mientras habilita una característica de privacidad frecuentemente solicitada.
NIP-DB: Interfaz de Base de Datos de Eventos Nostr en Navegador (spec) - Propone una interfaz estándar window.nostrdb para extensiones de navegador que proporcionan almacenamiento local de eventos Nostr. La API incluye métodos para agregar eventos, consultar por ID o filtro, contar coincidencias, y suscribirse a actualizaciones. Las aplicaciones web pueden usar esta interfaz para leer de eventos cacheados localmente sin hacer solicitudes a relays, reduciendo ancho de banda y latencia. La extensión de navegador nostr-bucket de hzrd149 proporciona una implementación de referencia, inyectando la interfaz en todas las pestañas del navegador. Una biblioteca polyfill compañera implementa la misma API usando IndexedDB para entornos sin la extensión.
Filtros TRUSTed - Una suite de cinco propuestas relacionadas para curación de contenido descentralizada, construyendo sobre el merged PR de Trusted Assertions #1534 de vitorpamplona. La especificación central introduce eventos kind 17570 para declarar Preferencias de Proveedor de Confianza, permitiendo a usuarios especificar qué servicios confían para filtrado y clasificación de eventos. Los proveedores de confianza publican aserciones (kind 37571), estadísticas (kind 37572), y clasificaciones (kind 37573) a las que los clientes pueden suscribirse. El sistema usa una arquitectura de plugins con etiquetas W/w para especificar tipos de filtros y transformaciones. Esto habilita operaciones computacionalmente costosas como detección de spam, puntuación de reputación, y clasificación de contenido para ejecutarse en infraestructura dedicada mientras los usuarios mantienen control sobre qué proveedores confían. La suite incluye especificaciones separadas para presets de filtros, clasificaciones de usuarios, eventos confiados, y definiciones de plugins.
NIP-9a: Notificaciones Push - hodlbod propone un estándar para notificaciones push basadas en relay usando eventos de registro kind 30390. Los usuarios crean un registro que contiene filtros para eventos que quieren recibir y una URL de callback webhook. El registro se cifra a la pubkey del relay (de su campo self NIP-11). Cuando ocurren eventos coincidentes, los relays envían POST al callback con el ID del evento (en texto plano para deduplicación) y el evento mismo (cifrado con NIP-44 al usuario). Esta arquitectura permite a los relays enviar notificaciones push mientras protege el contenido de eventos de servidores push intermediarios. El PR #270 de Flotilla implementa este estándar.
Catallax - Propone un protocolo de trabajo por contrato descentralizado con escrow usando eventos kind 33400. El sistema define tres roles: árbitros anuncian disponibilidad y términos, patrones crean tareas financiadas con Bitcoin en escrow, y agentes libres completan trabajo para reclamar pago. Los árbitros resuelven disputas cuando es necesario. El protocolo habilita coordinación de trabajo freelance sin confianza donde los fondos se bloquean hasta que los entregables son aceptados o el arbitraje concluye.

Análisis Profundo de NIP: NIP-47 (Nostr Wallet Connect)

NIP-47 define Nostr Wallet Connect (NWC), un protocolo para control remoto de billeteras Lightning usando Nostr como capa de comunicación. Con la adición de soporte de facturas hold esta semana, NWC ahora cubre el rango completo de operaciones Lightning.

El protocolo funciona a través de un intercambio simple. Una aplicación de billetera publica un evento “wallet info” (kind 13194) describiendo sus capacidades. Las aplicaciones cliente envían solicitudes cifradas (kind 23194) pidiendo a la billetera realizar operaciones como pagar facturas, crear facturas, o verificar saldos. La billetera responde con resultados cifrados (kind 23195).

NWC usa cifrado NIP-44 entre el cliente y la billetera, con un par de claves dedicado para operaciones de billetera, manteniéndolo separado de la identidad principal de Nostr del usuario. Esta separación significa que comprometer una conexión NWC no expone la identidad Nostr del usuario.

Métodos Soportados:

La especificación define métodos para operaciones Lightning centrales: pay_invoice envía pagos, make_invoice genera facturas para recibir, lookup_invoice verifica estado de pago, get_balance retorna el saldo de la billetera, y list_transactions proporciona historial de pagos. El recientemente fusionado pay_keysend habilita pagos sin facturas, y hold_invoice soporta pagos condicionales.

Eventos de Ejemplo:

El servicio de billetera publica un evento info (kind 13194) anunciando sus capacidades:

{
 "kind": 13194,
 "pubkey": "<pubkey del servicio de billetera>",
 "content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions notifications",
 "tags": [
 ["encryption", "nip44_v2"],
 ["notifications", "payment_received payment_sent"]
 ],
 "created_at": "<timestamp unix>",
 "id": "<hash del evento>",
 "sig": "<firma del servicio de billetera>"
}

Un cliente envía una solicitud cifrada (kind 23194) para pagar una factura:

{
 "kind": 23194,
 "pubkey": "<pubkey efímera del cliente del secreto URI de conexión>",
 "content": "<cifrado NIP-44: {\"method\": \"pay_invoice\", \"params\": {\"invoice\": \"lnbc50n1...\"}}>",
 "tags": [
 ["p", "<pubkey del servicio de billetera>"],
 ["encryption", "nip44_v2"]
 ],
 "created_at": "<timestamp unix>",
 "id": "<hash del evento>",
 "sig": "<firma de clave efímera del cliente>"
}

El servicio de billetera responde (kind 23195) con el resultado del pago:

{
 "kind": 23195,
 "pubkey": "<pubkey del servicio de billetera>",
 "content": "<cifrado NIP-44: {\"result_type\": \"pay_invoice\", \"result\": {\"preimage\": \"...\"}, \"error\": null}>",
 "tags": [
 ["p", "<pubkey efímera del cliente>"],
 ["e", "<id del evento de solicitud>"]
 ],
 "created_at": "<timestamp unix>",
 "id": "<hash del evento>",
 "sig": "<firma del servicio de billetera>"
}

La etiqueta e en la respuesta referencia la solicitud original, permitiendo a los clientes emparejar respuestas con sus solicitudes.

Facturas Hold:

El PR #1913 de esta semana añadió soporte de facturas hold, habilitando pagos estilo escrow. A diferencia de facturas estándar donde el receptor reclama el pago inmediatamente liberando la preimagen, las facturas hold permiten al receptor diferir esta decisión. Cuando un pagador envía a una factura hold, los fondos se bloquean a lo largo de la ruta de pago. El receptor entonces elige liquidar (liberar la preimagen y reclamar fondos) o cancelar (rechazar pago, retornando fondos al pagador). Si ninguna acción ocurre, el pago expira y los fondos retornan automáticamente. El PR añade tres métodos NWC: make_hold_invoice, settle_hold_invoice y cancel_hold_invoice, más una notificación hold_invoice_accepted. Este mecanismo potencia aplicaciones como el escrow de viajes compartidos de Ridestr y resolución de disputas de marketplace.

Implementaciones Actuales:

Las billeteras principales soportan NWC: Zeus, Alby, y Primal (desde el PR #874 de esta semana) todos implementan soporte del lado de billetera. Del lado del cliente, Damus, Amethyst, y la mayoría de clientes Nostr principales pueden conectarse a billeteras NWC para zapping y pagos.

El protocolo habilita una separación de responsabilidades: los usuarios pueden ejecutar su billetera en un dispositivo mientras interactúan con Nostr desde otro, con relays de Nostr sirviendo como canal de comunicación. Esta arquitectura significa que los clientes móviles no necesitan mantener fondos directamente, mejorando la seguridad al mantener la infraestructura de billetera separada de los clientes sociales.

Consideraciones de Seguridad:

Las conexiones NWC deben tratarse como sensibles. Mientras el cifrado protege el contenido de los mensajes, la pubkey de billetera y el secreto de conexión deben guardarse. Las aplicaciones deben permitir a los usuarios revocar conexiones y establecer límites de gasto. El protocolo soporta restricciones de capacidad, para que las billeteras puedan limitar qué operaciones puede realizar una conexión particular.

Análisis Profundo de NIP: NIP-59 (Gift Wrap)

NIP-59 define un protocolo para encapsular cualquier evento Nostr en múltiples capas de cifrado, ocultando la identidad del remitente de relays y observadores. Las propuestas de esta semana para notas solo-amigos (NIP-FR) y notificaciones push (NIP-9a) ambas dependen del gift wrapping, haciéndolo un primitivo de privacidad fundamental que vale la pena entender.

Las Tres Capas:

El gift wrapping usa tres estructuras anidadas:

Rumor (evento sin firmar): El contenido original como evento Nostr sin firma. El rumor no puede enviarse directamente a relays porque los relays rechazan eventos sin firmar.
Seal (kind 13): El rumor se cifra usando NIP-44 y se coloca en un evento kind 13. El seal SÍ está firmado por la clave del autor real. Esta es la prueba criptográfica de autoría.
Gift Wrap (kind 1059): El seal se cifra y coloca en un evento kind 1059 firmado por un par de claves aleatorio de un solo uso. El gift wrap incluye una etiqueta p para enrutamiento al destinatario.

Un Malentendido Común: Negabilidad

La especificación menciona que los rumores sin firmar proporcionan “negabilidad”, pero esto es engañoso. La capa seal SÍ está firmada por el autor real. Cuando el destinatario descifra el gift wrap y luego el seal, tiene prueba criptográfica de quién envió el mensaje. El destinatario podría incluso construir una prueba de conocimiento cero revelando la identidad del remitente sin exponer su propia clave privada.

Lo que gift wrap realmente proporciona es privacidad del remitente frente a observadores: los relays y terceros no pueden determinar quién envió el mensaje porque solo ven el gift wrap firmado por una clave aleatoria. Pero el destinatario siempre sabe, y puede probarlo.

Eventos de Ejemplo:

Aquí está la estructura completa de tres capas de la especificación (enviando “¿Vas a la fiesta esta noche?”):

El rumor (sin firmar, no puede publicarse a relays):

{
 "created_at": 1691518405,
 "content": "¿Vas a la fiesta esta noche?",
 "tags": [],
 "kind": 1,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "id": "9dd003c6d3b73b74a85a9ab099469ce251653a7af76f523671ab828acd2a0ef9"
}

El seal (kind 13, firmado por autor real, contiene rumor cifrado):

{
 "kind": 13,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "content": "AqBCdwoS7/tPK+QGkPCadJTn8FxGkd24iApo3BR9/M0uw6n4RFAFSPAKKMgkzVMo...",
 "created_at": 1703015180,
 "tags": [],
 "id": "28a87d7c074d94a58e9e89bb3e9e4e813e2189f285d797b1c56069d36f59eaa7",
 "sig": "02fc3facf6621196c32912b1ef53bac8f8bfe9db51c0e7102c073103586b0d29..."
}

El gift wrap (kind 1059, firmado por clave efímera aleatoria, contiene seal cifrado):

{
 "kind": 1059,
 "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c",
 "content": "AhC3Qj/QsKJFWuf6xroiYip+2yK95qPwJjVvFujhzSguJWb/6TlPpBW0CGFwfuf...",
 "created_at": 1703021488,
 "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]],
 "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac",
 "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df7..."
}

Nótese: la pubkey del seal es el autor real (611df01...), mientras que la pubkey del gift wrap es una clave de un solo uso aleatoria (18b1a75...). Los relays solo ven el gift wrap, por lo que no pueden atribuir el mensaje al autor real.

Qué Protege Cada Capa:

El rumor está sin firmar y no puede publicarse a relays directamente. El seal está firmado por el autor real y prueba autoría al destinatario. El gift wrap está firmado por una clave aleatoria de un solo uso, ocultando al autor real de relays y observadores. Solo el destinatario puede descifrar a través de ambas capas para alcanzar el contenido original y verificar la firma del autor en el seal.

Aplicaciones Actuales:

NIP-17 (Mensajes Directos Privados) usa gift wrap para DMs cifrados, reemplazando el esquema anterior NIP-04. El propuesto NIP-FR (notas solo para amigos) usa gift wrapping para distribuir ViewKeys a amigos, quienes luego descifran notas cifradas con esas claves. NIP-9a (notificaciones push) cifra cargas de notificación usando principios de gift wrap.

Protección de Metadatos:

Las marcas de tiempo deben aleatorizarse para frustrar análisis de timing. Los relays deben requerir AUTH antes de servir eventos kind 1059 y solo servirlos al destinatario marcado. Al enviar a múltiples destinatarios, crear gift wraps separados para cada uno.

Eso es todo por esta semana. ¿Construyendo algo? ¿Tienes noticias que compartir? ¿Quieres que cubramos tu proyecto? Contáctanos vía DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #7

Wed, 28 Jan 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal de Nostr.

Esta semana: Ridestr trae viajes compartidos descentralizados a Nostr con pagos en Cashu y ubicación cifrada compartida. Pomade introduce recuperación basada en correo electrónico para firmantes multisig. Damus lanza negentropy para sincronización confiable de mensajes directos. La aplicación de escritorio de Amethyst añade búsqueda, marcadores y zaps. Amber v4.1.1 muestra puntuaciones de confianza de relays. Marmot fusiona MIP-03 y construye una aplicación de chat de referencia en TypeScript. diVine añade autenticación QR mediante NIP-46 y soporte para menciones. Nuevas propuestas de NIP abordan la gestión de comunidades, sincronización basada en secuencias y almacenamiento cifrado de archivos. También echamos un vistazo a cinco años de eneros en Nostr, trazando la evolución del protocolo desde un puñado de primeros adoptantes en 2021 hasta el lanzamiento explosivo de Damus en la App Store en 2023 y el ecosistema de clientes madurando en 2025.

Noticias

Ridestr Trae Viajes Compartidos Descentralizados a Nostr

Ridestr está desarrollando una aplicación de viajes compartidos peer-to-peer construida completamente sobre Nostr, permitiendo transacciones directas entre conductores y pasajeros con pagos en Bitcoin y Cashu. El protocolo utiliza tipos de eventos personalizados (30173, 3173-3175, 30180/30181) para coordinar viajes mientras mantiene la privacidad a través de divulgación progresiva de ubicación y cifrado NIP-44.

El sistema funciona mediante un flujo cuidadosamente coreografiado: los conductores transmiten disponibilidad usando ubicaciones codificadas en geohash (~5km de precisión) mediante eventos kind 30173, los pasajeros solicitan viajes con estimaciones de tarifa a través de kind 3173, y los pagos se aseguran usando tokens de depósito HTLC antes de que comience el viaje. La privacidad de ubicación se preserva mediante divulgación progresiva, donde los detalles de recogida solo se revelan cuando los conductores llegan y los destinos se comparten después de la verificación del PIN. Toda la comunicación entre las partes usa cifrado NIP-44 para privacidad.

Ridestr implementa seguridad de pagos a través de depósito HTLC con firmas P2PK. Cuando un pasajero acepta la oferta de un conductor, bloquea tokens Cashu con un hash de pago que solo el conductor puede reclamar después de completar el viaje. El protocolo actualmente opera con arquitectura de mint único, requiriendo que pasajeros y conductores usen el mismo mint de Cashu. La implementación Android basada en Kotlin del proyecto maneja verificación de pruebas y recuperación de pruebas obsoletas a través de verificaciones de estado NUT-07.

Ridestr aborda desafíos que la mayoría de las aplicaciones Nostr evitan: coordinación de ubicación en tiempo real, depósito de pagos con resolución de disputas y sistemas de reputación para interacciones en el mundo físico. El proyecto está en beta y demuestra que el modelo de eventos de Nostr puede soportar mercados de servicios peer-to-peer, no solo compartir contenido.

Pomade Lanza Sistema de Recuperación Alpha para Firmantes Multisig

Pomade, desarrollado por hodlbod, se construye sobre el ecosistema existente de FROSTR para proporcionar un servicio de firma de umbral enfocado en la recuperación. Usando firmas FROST (Flexible Round-Optimized Schnorr Threshold) a través de la biblioteca @frostr/bifrost, Pomade añade flujos de recuperación basados en correo electrónico sobre la criptografía de umbral. El sistema fragmenta la clave secreta del usuario usando Shamir Secret Sharing, distribuyendo fragmentos a través de múltiples firmantes independientes con un umbral configurable (2-de-3, 3-de-5, etc.).

El protocolo opera completamente sobre Nostr usando un único tipo de evento (28350) con cargas útiles cifradas con NIP-44. Al firmar, el cliente solicita firmas parciales de al menos threshold firmantes, luego las agrega en una firma Schnorr válida. Para cifrado, los firmantes colaboran para derivar secretos compartidos vía ECDH sin que ninguna parte individual conozca la clave completa.

La recuperación funciona a través de dos métodos de autenticación: basado en contraseña (usando argon2id con la pubkey del firmante como sal) o OTP por correo electrónico. Para prevenir ataques MITM durante la recuperación OTP, cada firmante genera su propio código de verificación con un prefijo proporcionado por el cliente, requiriendo que los usuarios se autentiquen independientemente con cada firmante. El protocolo requiere prueba de trabajo en eventos de registro (20+ bits según NIP-13) para prevenir spam.

El modelo de confianza es explícito: si threshold firmantes se confabulan, pueden robar la clave. Los proveedores de correo electrónico tienen confianza total ya que pueden interceptar OTPs. Los usuarios no pueden recuperar independientemente su clave secreta completa; hacerlo requiere cooperación de threshold firmantes. El protocolo está diseñado para incorporar nuevos usuarios no familiarizados con la gestión de claves, con la recomendación explícita de que los usuarios migren a auto-custodia una vez cómodos. Pomade advierte sobre potencial “pérdida de claves, robo, denegación de servicio o fuga de metadatos” dado su estado alpha no auditado.

Lanzamientos

Damus Lanza Negentropy para Sincronización Confiable de DMs

Damus v1.13 lanza la implementación de negentropy que previsualizamos como PR abierto la semana pasada. PR #3536 añade soporte base de negentropy a la capa de red, habilitando reconciliación de conjuntos con relays que soportan el protocolo. Un PR #3547 complementario añade sincronización de DMs al deslizar para refrescar que usa negentropy para recuperar mensajes faltantes cuando las suscripciones REQ estándar fallan.

La implementación sigue un enfoque conservador: la carga normal de DMs continúa sin cambios, con negentropy disponible como mecanismo de recuperación cuando los usuarios refrescan manualmente. Las pruebas automatizadas demuestran la corrección generando un DM con una marca de tiempo antigua que las consultas estándar perderían, luego usando sincronización negentropy para recuperarlo exitosamente. Aunque el soporte de negentropy requiere relays compatibles, la implementación maneja elegantemente entornos de relays mixtos usando el protocolo donde esté disponible.

Amber v4.1.1 - Puntuaciones de Confianza de Relays

Amber v4.1.1 lanza la visualización de puntuaciones de confianza de relays (PR #289), implementando los conceptos de evaluación de relays discutidos en la cobertura de Trusted Relay Assertions de la semana pasada. Las puntuaciones de confianza ahora aparecen en la página de Relays y para solicitudes de conexión NostrConnect, ayudando a los usuarios a evaluar la confiabilidad de relays antes de autorizar conexiones. El lanzamiento también incluye una interfaz rediseñada de login/eventos/permisos y soporte para el método switch_relays. Las mejoras de rendimiento almacenan en caché las operaciones de keystore, abordando reportes de tiempos de carga de 20+ segundos en dispositivos antiguos.

nak v0.18.2 - Integración MCP

nak (Nostr Army Knife) de fiatjaf v0.18.2 añade soporte para Model Context Protocol vía nak mcp, permitiendo a agentes de IA buscar personas en Nostr, publicar notas, mencionar usuarios y leer contenido usando el modelo outbox. El lanzamiento también introduce un instalador de una línea (curl -sSL https://raw.githubusercontent.com/fiatjaf/nak/master/install.sh | sh) que descarga binarios pre-compilados, eliminando el requisito de la cadena de herramientas Go para usuarios finales. El modo bunker ahora soporta sockets Unix y switch_relays.

Zeus v0.12.2 Beta - Correcciones NWC

Zeus v0.12.2-beta1 lanza múltiples correcciones NWC abordando problemas cubiertos en la cobertura de Zeus de la semana pasada.

Actualizaciones de Proyectos

Amethyst Desktop - Fase 2A Lanzada

Amethyst lanzó la Fase 2A de su aplicación de escritorio, añadiendo Búsqueda, Marcadores, Zaps, vistas de Hilos y contenido de formato largo (Lecturas) a la experiencia de escritorio. Un PR #1683 complementario añade retroalimentación transparente de transmisión de eventos para que los usuarios ahora vean el estado por relay en tiempo real mientras sus eventos se propagan a través de la red, facilitando el diagnóstico de problemas de conectividad.

Progreso de Notedeck: Aplicación de Calendario y Pulido de UX

El cliente de escritorio Notedeck del equipo Damus fusionó el comportamiento de auto-ocultar barra de herramientas (PR #1268) que responde a la velocidad de desplazamiento para más espacio de pantalla en vistas móviles. Un borrador PR #1271 añade una aplicación completa de Calendario NIP-52 con vistas de mes/semana/día/agenda, soporte RSVP y comentarios NIP-22 en eventos de calendario, actualmente con feature-flag para pruebas.

Jumble Añade Modo Comunidad

Jumble, el cliente web enfocado en relays, añadió modo comunidad y soporte para presets de conjuntos de relays vía variables de entorno, facilitando el despliegue de instancias temáticas como nostr.moe.

Panel de Órdenes de Shopstr

Shopstr reemplazó su gestión de órdenes basada en chat con un Panel de Órdenes dedicado. La nueva interfaz proporciona una vista centralizada para que los comerciantes rastreen el estado de órdenes, marquen mensajes como leídos y gestionen el cumplimiento sin desplazarse por hilos de chat. La actualización deprecia el caché IndexedDB en favor de APIs de estado de órdenes del lado del servidor y revisa cómo se etiquetan los DMs de órdenes para mejor filtrado.

Formstr Añade Preguntas en Cuadrícula

Formstr, la aplicación de formularios nativa de Nostr, añadió preguntas en cuadrícula y reescribió su SDK con soporte para incrustación. Una [corrección para firmantes no-NIP-07](https://github.com/abh3po/nostr-forms/pull/418) resolvió problemas para usuarios con bunker o firmantes locales intentando enviar formularios con su identidad.

nostr-tools Actualiza Dependencias Criptográficas

nostr-tools, la biblioteca principal de JavaScript, actualizó a @noble/curves v2.0.1, abordando cambios de API incompatibles en 27 archivos y adoptando las últimas bibliotecas noble auditadas. fiatjaf también añadió soporte switch_relays a NIP-46, permitiendo a clientes bunker cambiar conexiones de relay dinámicamente.

Zeus Trabajando en Reseñas de Mints NIP-87

Zeus tiene un [PR abierto para reseñas de mints NIP-87](https://github.com/ZeusLN/zeus/pull/3576), permitiendo a los usuarios descubrir y reseñar mints de Cashu filtrados por seguidos de Nostr. Las reseñas incluyen calificaciones con estrellas y pueden enviarse anónimamente o con el nsec del usuario.

Camelus Lanza Soporte Completo de DM

Camelus, un cliente Android basado en Flutter construido con Dart NDK para rendimiento móvil eficiente en batería, añadió mensajería directa completa con más de 20 commits esta semana. La actualización incluye categorías de chat, fechas de mensajes, interfaz de envío optimista, funcionalidad de nota para uno mismo y manejo adecuado de relays de DM.

Actualizaciones del Protocolo Marmot

La resolución determinista de commits MIP-03 que cubrimos como PR abierto la semana pasada ahora se ha fusionado. MDK PR #152 asegura que todos los chats grupales basados en MLS converjan al mismo estado cuando llegan múltiples commits válidos para la misma época.

Un PR de especificación #28 complementario añade requisitos de ciclo de vida de init_key abordando vacíos de las auditorías de implementación: el material de clave privada de mensajes Welcome debe ser eliminado de forma segura después del procesamiento (zerización, limpieza de almacenamiento), y los nuevos miembros deben realizar auto-actualizaciones dentro de 24 horas para secreto hacia adelante.

El SDK de TypeScript (marmot-ts) está construyendo una aplicación de chat de referencia. PR #37 añade creación/listado de grupos, gestión de paquetes de claves con flujos de publicar/transmitir/eliminar, e invitaciones por código QR. Un PR abierto #38 por hzrd149 implementa persistencia de historial de mensajes con paginación. El backend whitenoise-rs fusionó 15 PRs esta semana incluyendo soporte multi-idioma (PR #455) y referencias de medios MIP-04 v2 (PR #450).

diVine Añade Funciones de Integración con Nostr

diVine, la aplicación de video de formato corto, continúa la rápida integración con Nostr.

Los PRs abiertos incluyen autenticación por código QR NIP-46 (PR #1019) y mensajería directa cifrada NIP-17 (PR #834). La actividad de esta semana se centró en soporte de menciones convirtiendo URIs nostr: y @menciones a enlaces de perfil clicables, avatares de respaldo de Classic Viners usando perfiles de Nostr, y herramientas de edición de video incluyendo dibujo, filtros y stickers.

Actualizaciones de NIPs

Cambios recientes al repositorio de NIPs:

Fusionados:

Trusted Relay Assertions - La propuesta para estandarizar puntuaciones de confianza de relays que cubrimos la semana pasada fue fusionada. La especificación define eventos kind 30385 para aserciones de confianza de relay con puntuación en fiabilidad, calidad y accesibilidad. La discusión previa a la fusión se centró en si las puntuaciones de confianza deben ser “globales” (calculadas una vez para todos los usuarios) o “personalizadas” (relativas al grafo social de cada observador). Algoritmos estilo PageRank como Trust Rank de nostr.band y GrapeRank resisten ataques sybil dividiendo cualquier rango pasado a través de cuentas falsas por el tamaño de la granja de bots.

PRs Abiertos y Discusiones:

Communikeys - Una propuesta comprehensiva para gestión de comunidades que usa npubs existentes como identificadores de comunidad en lugar de enfoques basados en relays. Cualquier npub puede convertirse en comunidad publicando un evento kind 10222; las publicaciones apuntan a comunidades vía eventos kind 30222. El control de acceso usa badges NIP-58, permitiendo gestión de membresía delegada con almacenamiento frío para claves de comunidad.
NIP-CF: Changes Feed - Un borrador proponiendo sincronización de eventos basada en secuencia como alternativa a filtros since basados en marcas de tiempo. El problema: la sincronización estándar de Nostr usando marcas de tiempo since puede perder eventos cuando múltiples eventos comparten la misma marca de tiempo con precisión de segundo, los relojes del cliente y relay divergen, o el checkpointing es impreciso. NIP-CF resuelve esto haciendo que los relays asignen números de secuencia monotónicamente crecientes a eventos almacenados, proporcionando ordenamiento total estricto. Los clientes solicitan cambios desde un número de secuencia específico y reciben eventos en orden garantizado, con checkpointing preciso que nunca pierde eventos. La propuesta también soporta modo en vivo/continuo donde las suscripciones permanecen abiertas después de la sincronización inicial para actualizaciones en tiempo real.
NIP-XX: Encrypted File Sync - Un protocolo que define kinds 30800 (archivos cifrados), 30801 (índices de bóveda) y 30802 (documentos compartidos) para sincronizar contenido cifrado entre dispositivos usando relays de Nostr. El protocolo permite que aplicaciones de toma de notas local-first proporcionen sincronización cifrada de extremo a extremo sin servidores centralizados. Los contenidos de archivos, rutas, nombres y estructura de carpetas están todos cifrados usando auto-cifrado NIP-44, por lo que los relays almacenan blobs que no pueden leer. Los adjuntos binarios como imágenes usan servidores Blossom con cifrado del lado del cliente. Kind 30802 permite compartir documentos entre usuarios cifrando a la clave pública del destinatario.

Cinco Años de Eneros en Nostr

El newsletter del mes pasado trazó los hitos de diciembre de Nostr desde el primer lanzamiento de cliente de fiatjaf hasta la donación catalítica de Jack Dorsey. Esta retrospectiva registra lo que sucedió cada enero desde 2021 hasta 2025, enfocándose en desarrollos técnicos verificados.

Enero 2021: Desarrollo Temprano

El tercer mes de Nostr vio desarrollo continuo en Branle, el cliente Vue.js de fiatjaf que se había lanzado en diciembre de 2020. Un pequeño grupo de primeros adoptantes, probablemente menos de 15 personas, se coordinaban a través del grupo de Telegram @nostr_protocol (creado el 16 de noviembre de 2020), probando el protocolo en uno o dos relays experimentales. El cliente de línea de comandos noscl proporcionaba interacción basada en terminal.

La base técnica ya estaba establecida: usuarios identificados por claves públicas secp256k1, publicaciones firmadas criptográficamente con firmas Schnorr, y relays sirviendo como almacenamiento simple que no se comunican entre sí. Esta fue criptografía deliberadamente nativa de Bitcoin, una elección de diseño que moldearía patrones de adopción años después.

Enero 2022: Descubrimiento por Desarrolladores

Enero 2022 abrió con Nostr todavía vibrando por su primera aparición en Hacker News (31 de diciembre de 2021), que generó 110 puntos y 138 comentarios. Al momento de esa publicación, solo alrededor de siete relays alimentaban toda la red, con comentaristas notando que “el spam no es un problema todavía porque nostr es súper nuevo y nadie lo usa aún”. Robert C. Martin (“Uncle Bob”) había respaldado a Nostr como potencialmente “la solución final para comunicación social”. La discusión continuó en enero, con desarrolladores debatiendo arquitectura de relays versus P2P verdadero, resistencia a la censura versus moderación, y si la simplicidad podría escalar.

La publicación de HN provocó una ola de nuevas implementaciones. El mismo Uncle Bob comenzó more-speech, un cliente de escritorio Clojure, el 18 de enero. La biblioteca go-nostr de fiatjaf (creada en enero 2021) y el cliente de línea de comandos noscl proporcionaban herramientas Go, mientras nostr-tools ofrecía soporte JavaScript. Para diciembre 2022, aproximadamente 800 perfiles tenían biografías. Branle seguía siendo el cliente web principal, recibiendo actualizaciones incluyendo importación de clave privada y soporte multi-relay. Los desafíos técnicos eran evidentes: las claves hexadecimales de 64 caracteres resultaban poco intuitivas, los retrasos de mensajes frustraban a los usuarios, y la comunidad cuestionaba si la arquitectura podría manejar tráfico a escala de Twitter.

Enero 2023: El Despegue

Enero 2023 transformó a Nostr de experimento a movimiento. Damus, el cliente iOS de William Casarin (jb55), luchó contra el proceso de aprobación de la App Store de Apple. Rechazado el 1 de enero, rechazado de nuevo el 26 de enero, fue finalmente aprobado el 31 de enero. Esa aprobación desencadenó una cascada: Damus alcanzó inmediatamente el #10 en Redes Sociales de EE.UU. Jack Dorsey lo llamó “un hito para los protocolos abiertos”.

Ocho días antes, el 23 de enero, Edward Snowden anunció su presencia en Nostr: “Una de las cosas geniales de Nostr… más allá de la resistencia a la censura, es que no estás limitado a 280 caracteres”. Su respaldo como denunciante de la NSA tenía peso en círculos conscientes de la privacidad, y los usuarios inmediatamente comenzaron a enviarle zaps de sats vía Lightning.

Los clientes web competían para incorporar la afluencia. Snort, creado por kieran en diciembre 2022, emergió como un cliente React repleto de funciones; el 13 de enero, Snort integró registro NIP-05 vía la API de Nostr Plebs, permitiendo a nuevos usuarios reclamar identidades legibles por humanos durante la incorporación. Iris, desarrollado a tiempo completo por Martti Malmi (un colaborador temprano de Bitcoin que recibió la segunda transacción de Bitcoin de Satoshi), ofrecía interfaces web y móvil con identidades NIP-05 gratuitas en iris.to. Astral, construido por monlovesmango con Quasar (Vue.js) como fork de Branle, se enfocaba en gestión de relays con su función de agrupación de relays que permitía a usuarios organizar relays en conjuntos para publicación y filtrado. Las betas de TestFlight para clientes iOS se llenaban en horas, y Amethyst dominaba Android.

La infraestructura luchaba por mantener el ritmo. Todos los relays eran operados por entusiastas pagando de su bolsillo. Los relays de pago usando micropagos Lightning creaban filtrado natural de spam pero introducían fricción de acceso. Damus fue retirado de la App Store de China solo dos días después de la aprobación, supuestamente por solicitud del principal vigilante de internet de China.

Enero 2024: Endurecimiento del Protocolo

Enero 2024 se enfocó en estandarización del protocolo y construcción de comunidad. Nostr PHX inició el año con un meetup el 5 de enero en Phoenix, reuniendo a cypherpunks locales. Este fue el primero de muchos eventos comunitarios ese año incluyendo BTC Prague (junio), Nostriga en Riga (agosto), y Nostrasia.

El desarrollo de protocolo más significativo fue NIP-59 (Gift Wrap) siendo fusionado el 29 de enero, proporcionando protección de metadatos para comunicaciones cifradas. Gift Wrap se construye sobre el estándar de cifrado NIP-44 (que había sido auditado por Cure53 en diciembre 2023) para ocultar la identidad del remitente de los relays. El protocolo envuelve mensajes cifrados dentro de un evento exterior firmado por un par de claves aleatorio de uso único. Los relays solo ven la pubkey desechable, mientras la identidad real del remitente está enterrada en la carga útil cifrada que solo el destinatario puede descifrar. Esto previene que operadores de relays y observadores de red aprendan quién está enviando mensajes a quién. Las marcas de tiempo también pueden aleatorizarse para derrotar análisis de timing.

El ecosistema se expandió más allá de las redes sociales. Plebeian Market se volvió completamente nativo de Nostr con cumplimiento de NIP-15, habilitando carritos de compra entre puestos y un navegador de puestos para descubrir comerciantes. Shopstr emergió como un mercado sin permisos facilitando comercio en Bitcoin. Zap.stream, construido por kieran, trajo streaming en vivo a Nostr con pagos Lightning a 21 sats/minuto. Las herramientas de desarrollo maduraron con NDK proporcionando abstracciones TypeScript y rust-nostr ofreciendo bindings Rust. Zeus v0.8.1 lanzó con importación de contactos Nostr y LND persistente, sentando las bases para integración de Nostr Wallet Connect en versiones posteriores.

Sin embargo, la sostenibilidad de infraestructura seguía siendo desafiante. Investigación académica de este período encontró que el 95% de los relays luchaban por cubrir costos operativos, con 20% experimentando tiempo de inactividad significativo. La tarifa de admisión para relays de pago promediaba menos de 1,000 sats (~$0.45), insuficiente para sostener operaciones.

Una nota sobre estafas: El “Nostr Assets Protocol” y el token “$NOSTR” asociado que se lanzó alrededor de esta época fueron públicamente denunciados por fiatjaf como “100% fraudulentos” y “una estafa de afinidad” sin conexión con el protocolo Nostr real.

Enero 2025: Maduración de Clientes

Enero 2025 vio desarrollo continuo de clientes en todo el ecosistema. Nostur 1.17.0 lanzó el 13 de enero con sincronización entre dispositivos para estados de lectura, soporte de inicio de sesión multi-firma FROST, y rendimiento optimizado de base de datos local. Amethyst continuó su transición al modelo outbox, compilando automáticamente conjuntos de relays basados en listas de seguidos en lugar de requerir configuración manual.

Los clientes principales comenzaron a alejarse de NIP-04 para mensajes directos, migrando hacia NIP-17 y el propuesto NIP-104 para cifrado mejorado y protección de metadatos. El modelo Gossip (comunicación outbox/inbox) ganó adopción mientras el ecosistema convergía hacia patrones de uso de relays más eficientes. Observadores de la industria predijeron que este sería el año en que Nostr transicionaría de protocolo de nicho a reconocimiento mainstream, con una potencial migración de plataforma de alto perfil que podría duplicar la actividad diaria.

Enero 2026: Seguridad e Infraestructura de Firma

Enero 2026 trajo avances significativos en seguridad e infraestructura de firma. Primal Android 2.6.18 lanzó firma remota NIP-46 y soporte de firmante local NIP-55, uniéndose a Amber y Aegis como un hub de firma completo para otras aplicaciones Android. Bitchat completó una auditoría de seguridad de Cure53, la misma firma que auditó Signal y NIP-44, con más de 17 PRs corrigiendo hallazgos críticos incluyendo limpieza de secretos DH y problemas de seguridad de hilos. Tanto Bitchat como Damus migraron de C Tor a Rust Arti para mejor confiabilidad y seguridad de memoria.

El trabajo de protocolo continuó con NIP-71 (eventos de video direccionables) fusionándose y un NIP de criptografía post-cuántica abriendo discusión sobre preparar Nostr para el futuro contra ataques cuánticos. El borrador de Trusted Relay Assertions propuso estandarizar puntuaciones de confianza de relays a través de atestaciones firmadas. El Protocolo Marmot endureció su mensajería cifrada basada en MLS con 18 PRs fusionados abordando hallazgos de auditoría.

Las aplicaciones del mundo real se expandieron con Ridestr desarrollando viajes compartidos descentralizados usando depósito Cashu y cifrado NIP-44, y Pomade añadiendo flujos de recuperación basados en correo electrónico a firma de umbral FROST. Damus lanzó negentropy para sincronización confiable de DMs, mientras la aplicación de escritorio de Amethyst alcanzó la Fase 2A con búsqueda, marcadores y zaps.

Mirando Hacia Adelante

Seis años de eneros revelan la evolución de Nostr desde desarrollo temprano (2021) a descubrimiento público (2022) a crecimiento explosivo (2023) a endurecimiento del protocolo (2024) a maduración de clientes (2025) a infraestructura de seguridad (2026). El patrón es familiar para cualquiera que haya observado protocolos abiertos crecer: años de construcción silenciosa, una explosión repentina cuando las condiciones se alinean, luego el trabajo más largo de hacer todo confiable. Lo que comenzó con siete relays y un hilo de Hacker News es ahora infraestructura auditada con aplicaciones reales. La pregunta para 2027: cuando alguien solicite un viaje, envíe un mensaje cifrado, o recupere una clave perdida usando Nostr, ¿sabrán siquiera que lo están usando?

Eso es todo por esta semana. ¿Construyendo algo? ¿Tienes noticias que compartir? ¿Quieres que cubramos tu proyecto? Contáctanos vía DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #6

Wed, 21 Jan 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal sobre Nostr.

Esta semana: Bitchat reemplaza C Tor con la implementación Rust Arti para mejor confiabilidad y rendimiento. nostrdb-rs obtiene consultas de plegado en streaming que permiten operaciones de base de datos sin asignación de memoria. Listr recibe una refactorización mayor con migración a NDK 3 beta y mantenimiento asistido por IA después de un año de inactividad. Zeus envía 17 PRs fusionados enfocados en correcciones de NIP-47 (Nostr Wallet Connect para control remoto de Lightning) y mejoras de Cashu, mientras que Primal Android añade flujos de respaldo de billetera y soporte de NIP-92 (dimensiones de medios para proporciones de aspecto adecuadas). Un nuevo borrador de NIP propone Aserciones de Confianza de Relays para puntuación estandarizada de confianza de relays.

Noticias

Bitchat Migra a Rust Arti para Soporte de Tor

Bitchat ha migrado de C Tor a Arti, la implementación en Rust del protocolo Tor. El PR #958 elimina la dependencia de C Tor e integra Arti, aportando garantías de seguridad de memoria y mejor confiabilidad. El cambio elimina intentos de despertar inactivos que causaban reinicios del servicio en primer plano, un problema de larga data con la implementación en C.

Lo que esto significa para los usuarios: Mensajería cifrada más estable con menos desconexiones, especialmente en dispositivos móviles. La implementación en Rust reduce riesgos de fallas y drenaje de batería por intentos constantes de reconexión.

Arti es una reescritura completa de Tor en Rust, desarrollada por el Proyecto Tor para proporcionar mejor seguridad a través de la seguridad de memoria y facilitar la integración en aplicaciones. Para Bitchat, las propiedades de seguridad de memoria reducen la superficie de ataque al manejar mensajes cifrados y conexiones de relay. La migración sigue la reciente auditoría de seguridad Cure53 del equipo (cubierta en Newsletter #5), continuando sus mejoras de seguridad.

El PR también introduce cobertura de pruebas integral para ChatViewModel y BLEService, elimina código muerto y estabiliza la suite de pruebas. Las mejoras de confiabilidad de la malla Bluetooth Low Energy acompañan los cambios de Tor, abordando fallos en transferencias grandes. Juntos, estos cambios mejoran la resiliencia de Bitchat para escenarios de red en malla fuera de línea donde Tor proporciona conectividad a internet junto con comunicación BLE local.

Listr Revitalizado con Mantenimiento Potenciado por IA

JeffG anunció una refactorización mayor de Listr, la aplicación de gestión de listas Nostr disponible en listr.lol, después de que el proyecto había estado inactivo por más de un año. Usando asistencia de IA, completó una actualización integral incluyendo migración a NDK 3 beta, actualizaciones a las últimas versiones de Svelte y Vite, y todas las dependencias actualizadas. La refactorización añade soporte de primera clase para seguir packs, implementa paginación para listas que exceden 50 elementos, y corrige numerosos errores que se habían acumulado durante el período inactivo.

Lo que esto significa para los usuarios: Listr está de vuelta en línea con rendimiento mejorado y nuevas características para gestionar listas de seguimiento, colecciones de contenido y curación de temas. La corrección de paginación hace que las listas grandes sean realmente utilizables.

JeffG señaló que sin asistencia de IA, este trabajo de mantenimiento probablemente nunca habría ocurrido, evitando que el proyecto fuera abandonado. Listr permite la curación de contenido en Nostr, permitiendo a los usuarios crear, gestionar y compartir listas de perfiles, temas y recursos. La actualización mantiene la aplicación compatible con los estándares Nostr actuales y las expectativas de los clientes a medida que la gestión de listas se vuelve más central para el descubrimiento de contenido en el protocolo.

Actualizaciones de NIP

Cambios recientes en el repositorio de NIPs:

Fusionados:

NIP-29 (Grupos basados en relay) - Aclaración de Clave de Relay (#2190 - fusionado) aclara que la clave de relay es la URL del relay en sí, no una pubkey. La especificación ahora establece explícitamente “La clave de relay es la URL WebSocket del relay (ej., wss://groups.example.com)” para evitar confusión. Esto afecta cómo los clientes identifican qué relay hospeda un grupo dado, asegurando que los grupos sean apropiadamente atribuidos a sus relays de hospedaje.

PRs Abiertos y Discusiones:

Aserciones de Confianza de Relays - Un borrador de NIP propone estandarizar la puntuación de confianza de relays a través de eventos kind 30385 que contienen puntuaciones de confianza (0-100) computadas a partir de métricas de NIP-66 (descubrimiento y monitoreo de relays), reputación del operador e informes de usuarios. La especificación divide la confianza en componentes de confiabilidad (tiempo de actividad, latencia), calidad (TLS, documentación, verificación del operador) y accesibilidad (jurisdicción, barreras, riesgo de vigilancia). La verificación del operador incluye firmas criptográficas vía NIP-11 (documentos de información de relay), registros DNS TXT y archivos .well-known. Los usuarios declaran proveedores de aserciones confiables vía eventos kind 10385, permitiendo a los clientes consultar múltiples proveedores para perspectivas diversas. La propuesta complementa el descubrimiento de NIP-66 con evaluación, ayudando a NIP-46 (firma remota/Nostr Connect) a evaluar la confiabilidad del relay en URIs de conexión.
Criptografía Post-Cuántica - El PR #2185 (abierto) continúa evolucionando desde que el Newsletter #5 introdujo la propuesta de algoritmos resistentes a computación cuántica. La discusión de esta semana se enfocó en detalles de implementación para cripto-agilidad: cómo los clientes manejan firmas duales durante la migración, compatibilidad hacia atrás para clientes antiguos e implicaciones de rendimiento de firmas resistentes a cuántica más grandes. Los contribuidores debatieron si mandar solo ML-DSA-44 o soportar múltiples algoritmos (ML-DSA-44, Falcon-512, Dilithium) para flexibilidad. El consenso se inclina hacia un enfoque por fases: firmas cuánticas opcionales inicialmente, volviéndose obligatorias solo después de soporte amplio del cliente y emergencia de amenaza cuántica real.

Análisis Profundo de NIP: NIP-11 y NIP-66

Esta semana examinamos dos NIPs que trabajan juntos para permitir el descubrimiento y evaluación de relays: NIP-11 define cómo los relays se describen a sí mismos, y NIP-66 estandariza cómo medimos el comportamiento del relay. Juntos forman la fundación para sistemas de evaluación de confianza de relays.

NIP-11: Documento de Información de Relay

NIP-11 define un documento JSON que los relays sirven sobre HTTP para describir sus capacidades, políticas e información del operador. Cuando un cliente se conecta a wss://relay.example.com, puede obtener https://relay.example.com (reemplazando wss:// con https://) para recuperar el documento de información del relay.

El documento usa negociación de contenido HTTP estándar con el encabezado Accept: application/nostr+json. Esto permite a los relays servir su sitio web normal a navegadores mientras proporcionan metadatos legibles por máquina a clientes Nostr. La respuesta incluye nombre y versión del software del relay, información de contacto del operador (pubkey, email, contacto alternativo), NIPs soportados y parámetros operacionales como requisitos de pago o restricciones de contenido.

Importante, los documentos NIP-11 básicos son JSON sin firmar servidos sobre HTTPS, dependiendo únicamente de certificados TLS para autenticidad. Esto significa que cualquiera que controle el servidor web del relay puede modificar el documento, haciendo que las afirmaciones del operador sean inverificables. La propuesta de Aserciones de Confianza de Relays aborda esta brecha introduciendo atestaciones firmadas a través del campo self pubkey del relay, permitiendo prueba criptográfica de identidad del operador similar a cómo los relays usan eventos firmados para mecanismos de autenticación.

{
 "name": "relay.example.com",
 "description": "Un relay público de propósito general",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "contact": "admin@example.com",
 "supported_nips": [1, 2, 4, 9, 11, 12, 16, 20, 22],
 "software": "git+https://github.com/relay/relay.git",
 "version": "1.2.3",
 "limitation": {
 "max_message_length": 16384,
 "max_subscriptions": 20,
 "max_filters": 100,
 "max_limit": 5000,
 "max_subid_length": 100,
 "min_prefix": 4,
 "max_event_tags": 2000,
 "max_content_length": 8196,
 "min_pow_difficulty": 0,
 "auth_required": false,
 "payment_required": false
 },
 "payments_url": "https://relay.example.com/payments",
 "fees": {
 "admission": [{"amount": 5000, "unit": "msats"}],
 "subscription": [{"amount": 1000, "unit": "msats", "period": 2592000}],
 "publication": []
 }
}

El objeto limitation dice a los clientes qué restricciones impone el relay. max_message_length limita el tamaño del marco WebSocket, max_subscriptions limita las suscripciones REQ concurrentes por conexión, max_filters limita filtros por REQ, y max_limit restringe cuántos eventos puede solicitar un solo filtro. Estos parámetros ayudan a los clientes a adaptar su comportamiento a las capacidades del relay, evitando desconexiones por exceder límites.

La información de pago aparece en fees y payments_url. Los relays pueden cobrar por admisión (acceso único), suscripción (acceso recurrente) o publicación (tarifas por evento). El payments_url apunta a detalles sobre métodos de pago, típicamente facturas Lightning o mints de ecash. Los relays pagos usan estos campos para comunicar precios antes de que los clientes intenten autenticación.

El array supported_nips permite a los clientes descubrir capacidades del relay. Si un relay lista NIP-50, los clientes saben que pueden enviar consultas de búsqueda de texto completo. Si aparece NIP-42, los clientes deben esperar desafíos de autenticación. Esta publicidad declarativa de capacidades permite mejora progresiva: los clientes pueden usar características avanzadas donde estén disponibles mientras se degradan elegantemente en relays con soporte limitado.

La información del operador construye responsabilidad. El campo pubkey identifica al operador del relay en Nostr, permitiendo comunicación directa vía DMs de NIP-17 o menciones públicas. El email de contact proporciona un respaldo fuera del protocolo. Juntos, estos campos ayudan a los usuarios a alcanzar operadores para reportes de abuso, solicitudes de acceso o problemas técnicos.

Los documentos NIP-11 son auto-reportados: los relays describen lo que afirman soportar, no necesariamente lo que realmente hacen. Aquí es donde NIP-66 se vuelve importante.

NIP-66: Descubrimiento de Relay y Monitoreo de Actividad

NIP-66 estandariza la publicación de datos de monitoreo de relays en Nostr. Los servicios de monitoreo prueban continuamente relays para disponibilidad, latencia, cumplimiento de protocolo y NIPs soportados. Publican resultados como eventos kind 30166, proporcionando estado del relay en tiempo real independiente del auto-reporte del relay.

Los monitores verifican disponibilidad del relay conectándose y enviando suscripciones de prueba. Las mediciones de latencia rastrean tiempo de conexión, tiempo de respuesta de suscripción y retraso de propagación de eventos. Las pruebas de cumplimiento de protocolo verifican que el comportamiento del relay coincida con las especificaciones, capturando errores de implementación o desviaciones intencionadas. La verificación de soporte de NIP va más allá de las afirmaciones de NIP-11 probando realmente si las características anunciadas funcionan correctamente.

{
 "id": "a34b5c7d89e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
 "pubkey": "4e2d0bc6f8e7c3a5b9f1d2e3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4",
 "created_at": 1736784000,
 "kind": 30166,
 "tags": [
 ["d", "wss://relay.example.com"],
 ["rtt", "open", "143", "1736784000"],
 ["rtt", "read", "89", "1736784000"],
 ["rtt", "write", "92", "1736784000"],
 ["nips", "1", "2", "4", "9", "11", "12"],
 ["geo", "US", "United States", "New York"],
 ["other", "network", "clearnet"],
 ["other", "payment_required", "false"],
 ["other", "auth_required", "false"]
 ],
 "content": "{\"last_check\": 1736784000, \"checks\": 8760}",
 "sig": "8b9c4d5e6a7f8b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b"
}

La etiqueta d contiene la URL del relay, haciendo de este un evento reemplazable parametrizado. Cada monitor publica un evento por relay, actualizado a medida que cambian las mediciones. Múltiples monitores pueden rastrear el mismo relay, proporcionando redundancia y validación cruzada. Los clientes consultan múltiples pubkeys de monitores para obtener perspectivas diversas sobre la salud del relay.

Las etiquetas de tiempo de ida y vuelta (rtt) miden latencia para diferentes operaciones. rtt open rastrea el establecimiento de conexión WebSocket, rtt read mide tiempo de respuesta de suscripción, y rtt write prueba velocidad de publicación de eventos. Todos los valores están en milisegundos. Los clientes usan estas métricas para preferir relays de baja latencia para operaciones sensibles al tiempo o despriorizar relays lentos.

La etiqueta nips lista soporte de NIP realmente verificado, no solo soporte afirmado. Los monitores prueban cada NIP ejercitando su funcionalidad. Si un relay afirma búsqueda de NIP-50 en su documento NIP-11 pero las consultas de búsqueda fallan, los monitores omitirán NIP-50 de la lista verificada. Esto proporciona verdad fundamental sobre capacidades del relay.

La información geográfica ayuda a los clientes a seleccionar relays cercanos para mejor latencia y resistencia a censura. La etiqueta geo contiene código de país, nombre de país y región. La etiqueta network distingue relays clearnet de servicios ocultos Tor o endpoints I2P. Juntas, estas etiquetas permiten diversidad geográfica: los clientes pueden conectarse a relays en múltiples jurisdicciones para resistir censura regional.

Los datos del monitor potencian selectores de relay en clientes, sitios web exploradores y la propuesta de Aserciones de Confianza de Relays. Al combinar documentos auto-reportados de NIP-11 con datos medidos de NIP-66 y aserciones de confianza computadas, el ecosistema se mueve hacia selección informada de relays en lugar de depender de valores predeterminados codificados o recomendaciones de boca en boca.

Lanzamientos

0xchat v1.5.3 - Características Mejoradas de Mensajería

0xchat v1.5.3 trae mejoras significativas al cliente de mensajería Nostr estilo Telegram. El lanzamiento aborda problemas de cumplimiento de NIP-55 (aplicación firmante de Android) que estaban impidiendo la firma apropiada de eventos a través de firmantes externos como Amber. El cumplimiento completo significa que 0xchat ahora delega correctamente operaciones de firma, mejorando la seguridad al mantener las claves privadas aisladas.

La actualización integra tanto FileDropServer como BlossomServer como opciones de almacenamiento de medios predeterminadas, dando a los usuarios redundancia para cargas de archivos. Blossom proporciona almacenamiento direccionado por contenido donde los archivos son referenciados por sus hashes SHA-256, asegurando integridad y permitiendo deduplicación a través de la red. El guardado automático de borradores para Momentos previene pérdida de datos al componer contenido de formato largo, abordando quejas de usuarios sobre publicaciones perdidas durante cambios de aplicación o interrupciones de conectividad.

La integración de billetera Cashu recibe pulido con filtrado automático de pruebas que elimina tokens gastados de la vista de billetera. Esto resuelve la confusa UX donde los usuarios veían pruebas inválidas junto con ecash válido, haciendo que los cálculos de saldo fueran poco confiables. El filtrado ocurre del lado del cliente, manteniendo privacidad mientras mejora la experiencia de pago para transacciones peer-to-peer dentro de chats.

Amber v4.1.0 Pre-lanzamientos - Renovación de UI

Amber v4.1.0-pre1 hasta v4.1.0-pre3 introducen una interfaz rediseñada para el popular firmante de eventos Android. La pantalla de inicio de sesión ahora muestra claramente qué aplicación está solicitando permisos de firma, abordando confusión del usuario sobre flujos de autorización. La nueva pantalla de eventos proporciona inspección detallada de qué datos las aplicaciones quieren firmar, permitiendo a los usuarios tomar decisiones de seguridad informadas antes de aprobar operaciones.

La gestión de permisos recibe atención significativa con una interfaz renovada que muestra exactamente qué capacidades se han otorgado a cada aplicación conectada. Los usuarios pueden revocar permisos específicos sin desconectarse completamente, permitiendo control de grano fino sobre delegación de firma. Los contadores de relay refactorizados usando la biblioteca quartz actualizada proporcionan estadísticas en tiempo real sobre rendimiento de eventos y desempeño del relay. Las conexiones bunker de NIP-46 (Nostr Connect) ahora muestran mensajes de error detallados cuando las conexiones fallan, reemplazando errores de tiempo de espera crípticos con diagnósticos accionables.

Cambios notables de código y documentación

Estos son pull requests fusionados y desarrollos en etapa temprana que vale la pena rastrear. Algunos son características experimentales que pueden evolucionar antes del lanzamiento.

Zeus (Billetera Lightning con Nostr Wallet Connect)

Zeus fusionó 17 pull requests esta semana, fortaleciendo su posición como implementación líder de NIP-47 Nostr Wallet Connect. Las correcciones más significativas abordan problemas de consistencia de datos y cumplimiento de protocolo que estaban causando problemas de interoperabilidad con clientes Nostr.

Corrección de Historial de Transacciones - El PR #3542 resuelve un error crítico donde las listas de transacciones NWC mostraban entradas incorrectas o duplicadas. El problema ocurría cuando Zeus almacenaba en caché datos de transacciones sin manejar apropiadamente actualizaciones de eventos, causando que los usuarios vieran transacciones fantasma o pagos faltantes. La corrección implementa deduplicación apropiada de eventos e invalidación de caché, asegurando que el historial de transacciones refleje con precisión el estado del nodo Lightning.

Cumplimiento de Protocolo - El PR #3548 aborda respuestas incompletas de getInfo que rompían compatibilidad con clientes esperando cumplimiento completo de NIP-47. Algunos clientes Nostr fallaban al recibir respuestas parciales sin campos como block_height o network. El PR asegura que todos los campos requeridos retornen con valores predeterminados sensatos incluso cuando la implementación Lightning subyacente no los proporciona, mejorando la compatibilidad de Zeus a través del ecosistema.

Resiliencia de Conexión - El PR #3543 implementa notificaciones de tiempo de espera para conexiones Nostr estancadas. Previamente, los usuarios esperaban indefinidamente cuando las conexiones de relay caían silenciosamente. Ahora Zeus muestra mensajes de tiempo de espera claros después de 30 segundos de inactividad, permitiendo a los usuarios reintentar o cambiar relays. El PR #3541 añade validación de backend para prevenir activación de NWC en implementaciones Lightning incompatibles, capturando errores de configuración antes de que causen fallas en tiempo de ejecución.

Condición de Carrera de Cashu - El PR #3531 corrige un error de concurrencia en la gestión de tokens Cashu donde operaciones simultáneas de mint podían corromper la base de datos de tokens. La condición de carrera ocurría cuando múltiples hilos actualizaban conteos de tokens sin bloqueo apropiado, ocasionalmente resultando en saldos incorrectos. La corrección añade protección de mutex alrededor de secciones críticas, asegurando actualizaciones atómicas al estado de tokens.

Primal Android (Cliente)

Primal Android envió 12 PRs fusionados con mejoras significativas a seguridad de billetera y manejo de medios. La implementación de respaldo de billetera aborda una de las características más solicitadas, mientras que el soporte de NIP-92 mejora la experiencia visual a través de la aplicación.

Sistema de Respaldo de Billetera - Una serie de cuatro PRs (#844, #845, #846, #848) implementa funcionalidad integral de respaldo de frase semilla. Los usuarios ahora pueden exportar su mnemónico de 12 palabras a través de un flujo seguro que previene capturas de pantalla, muestra estado de respaldo en el tablero de billetera y guía a usuarios existentes a través de la migración. La implementación sigue estándares BIP-39 e incluye validación para prevenir que los usuarios pierdan fondos debido a registro incorrecto de frases.

Dimensiones de Medios (NIP-92) - El PR #718 implementa soporte de NIP-92 para proporciones de aspecto apropiadas de imagen y video. Sin metadatos de dimensiones, los clientes deben descargar imágenes para determinar su tamaño, causando saltos de diseño mientras se carga el contenido. NIP-92 añade etiquetas dim (como ["dim", "1920x1080"]) a eventos de metadatos de archivo, permitiendo a Primal reservar espacio correcto antes de descargar medios. Esto elimina reflujos molestos en galerías de imágenes y mejora el rendimiento percibido.

Confiabilidad de Firmante Remoto - El PR #841 corrige problemas de conexión de NIP-46 donde prefijos wss:// faltantes causaban fallos silenciosos. El PR valida URIs de relay durante la configuración de conexión bunker, añadiendo el prefijo de protocolo automáticamente cuando los usuarios pegan dominios desnudos. El PR #843 aborda un error de threading donde condiciones de red pobres causaban que las respuestas se publicaran como notas raíz, rompiendo el flujo de conversación. La corrección asegura que los IDs de eventos padre persistan a través de interrupciones de red.

Protocolo Marmot: White Noise (Biblioteca de Chat Grupal Cifrado)

White Noise, la biblioteca Rust que potencia los chats grupales cifrados del Protocolo Marmot, fusionó seis PRs mejorando experiencia de usuario y seguridad. Los cambios acercan a Marmot a la paridad de características con aplicaciones de mensajería convencionales mientras mantiene su arquitectura que prioriza privacidad.

Confirmaciones de Lectura - El PR #433 y #436 implementan rastreo de lectura de mensajes para conversaciones grupales. El sistema almacena posiciones de lectura por usuario por grupo dentro de un solo dispositivo, permitiendo insignias de conteo no leídas. La implementación usa marcas de tiempo monotónicas para rastrear la posición del último mensaje leído para cada conversación. Esta característica fundamental permite indicadores de UI mostrando conteos de mensajes no leídos por conversación.

Fijado de Conversaciones - El PR #442 añade fijado persistente de conversaciones a través de un campo pin_order en la tabla de unión accounts_groups que vincula cuentas a grupos. Las conversaciones fijadas mantienen su posición en la parte superior de listas de chat sin importar actividad de mensajes, coincidiendo con expectativas de usuarios de Signal y WhatsApp. La implementación usa ordenamiento entero para permitir fijados ilimitados con clasificación determinística.

Resolución Determinística de Commits (MIP-03) - El PR #152 (abierto) implementa la Propuesta de Mejora de Marmot 03, resolviendo el problema crítico de condiciones de carrera de commit en chats grupales distribuidos. Cuando múltiples miembros envían cambios de estado de grupo (agregar/remover miembros, cambiar permisos) simultáneamente, los clientes podían divergir en ordenamiento de commits, fragmentando el grupo en estados incompatibles. MIP-03 introduce instantáneas de época y selección determinística de ganador: el commit con la marca de tiempo created_at más temprana gana, con ID de evento lexicográfico como desempate. Esto permite a todos los clientes converger en el mismo estado a través de rollback y reproducción, manteniendo coherencia del grupo incluso durante particiones de red.

Endurecimiento de Seguridad - El PR #443 previene copiado innecesario de secretos criptográficos usando referencias en resolve_group_image_path. Esto reduce la ventana para ataques de memoria donde los secretos podrían ser recuperados de asignaciones heap liberadas. El PR #438 permite cifrado de base de datos SQLCipher a través de parámetros de keyring, protegiendo historial de mensajes en reposo. La integración de keyring permite almacenamiento seguro de claves en keychains de plataforma en lugar de archivos de configuración.

nostrdb-rs (Biblioteca de Base de Datos) - PR Abierto

Implementación de Consultas en Streaming - El PR #58 (abierto) propone consultas de plegado en streaming para permitir operaciones de base de datos sin asignación de memoria. La implementación añadiría métodos fold, try_fold, count, any, all y find_map que procesarían resultados de base de datos uno a la vez sin materializar conjuntos de resultados enteros en vectores. Este enfoque reduciría el consumo de memoria y permitiría terminación temprana para patrones de consulta comunes.

La implementación técnica expone callbacks de resultados de consulta de bajo nivel (ndb_query_visit) como visitantes Rust con estado que mapean variantes ControlFlow a acciones de visitante C. Una vez fusionado, el código de aplicación se leerá como lógica de iterador mientras se ejecuta cerca de la capa de base de datos. Por ejemplo, contar notas coincidentes transmitiría a través de resultados en lugar de recolectarlos, y find_map retornaría el primer resultado útil sin procesar filas restantes.

nostrdb potencia Damus y Notedeck, clientes iOS/macOS y de escritorio respectivamente. Las consultas en streaming permitirían patrones eficientes como paginación, filtrado condicional y verificaciones de existencia. El PR cambia 3 archivos con +756 adiciones y -32 eliminaciones, una refactorización sustancial de la capa de consulta. Los usuarios de aplicaciones basadas en nostrdb-rs verían uso reducido de memoria al navegar líneas de tiempo grandes o buscar a través de bases de datos extensas de eventos.

nak (Herramienta CLI)

nak, la herramienta Nostr de línea de comandos de fiatjaf, fusionó seis PRs enfocados en mejoras del sistema de compilación y nueva funcionalidad. El PR #91 implementa una característica de espejo Blossom, permitiendo a nak servir como espejo para servidores de medios Blossom. Blossom es un protocolo de almacenamiento de medios direccionado por contenido que funciona junto con eventos Nostr.

Los PRs restantes abordan compatibilidad del sistema de compilación a través de plataformas Windows, macOS y Linux, permitiendo soporte de sistema de archivos FUSE para montar eventos Nostr como directorios locales.

Damus (Cliente iOS) - PRs Abiertos

Damus tiene 11 PRs abiertos explorando mejoras arquitectónicas significativas. Aunque estos no se han fusionado todavía, señalan direcciones importantes para el desarrollo del cliente Nostr iOS, particularmente en torno a privacidad, eficiencia de sincronización y optimización de datos móviles.

Integración de Tor - El PR #3535 incorpora el cliente Tor Arti directamente en Damus, permitiendo conexiones anónimas de relay sin dependencias externas. A diferencia de enfoques de Orbot o Tor Browser, incorporar Arti proporciona integración sin costuras con sandboxing de iOS y límites de ejecución en segundo plano. La implementación Rust aporta seguridad de memoria a la anonimización de red, reduciendo superficie de ataque comparada con C Tor. Los usuarios podrían alternar modo Tor por relay o globalmente, con el cliente manejando gestión de circuitos transparentemente.

Protocolo de Sincronización Negentropy - El PR #3536 implementa Negentropy, un protocolo de reconciliación de conjuntos que mejora radicalmente la eficiencia de sincronización. En lugar de descargar todos los eventos desde la última conexión, Negentropy intercambia huellas compactas (árboles Merkle) para identificar exactamente qué eventos difieren entre cliente y relay. Para usuarios siguiendo cientos de pubkeys, esto reduce ancho de banda de sincronización de megabytes a kilobytes. La implementación se integra con RelayPool y SubscriptionManager, permitiendo sincronización eficiente automática a través de todos los relays conectados.

Modo de Datos Bajo - El PR #3549 añade características de conservación de datos celulares respondiendo a retroalimentación de usuarios sobre consumo de ancho de banda. El modo deshabilita carga automática de imágenes, precarga de video y reduce límites de suscripción. Los usuarios en conexiones medidas pueden navegar contenido de texto sin temor a exceder límites de datos. La implementación respeta configuraciones de modo de datos bajo de iOS y proporciona controles granulares para diferentes tipos de medios.

Optimizaciones de Base de Datos - El PR #3548 reelabora el almacenamiento de instantáneas de nostrdb para consultas más rápidas y uso reducido de disco. La optimización cambia cómo las instantáneas de base de datos persisten a disco, mejorando tanto rendimiento de lectura como amplificación de escritura. Esto aborda quejas de drenaje de batería de usuarios con bases de datos grandes de eventos.

Eso es todo por esta semana. ¿Construyendo algo? ¿Tienes noticias para compartir? ¿Quieres que cubramos tu proyecto? Contáctanos vía DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #5

Tue, 13 Jan 2026 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal sobre Nostr.

Esta semana: Bitchat se somete a una auditoría de seguridad profesional realizada por Cure53, la misma firma que auditó Signal y NIP-44, con más de 17 PRs ya fusionados que corrigen hallazgos críticos. NIP-71 se fusiona, trayendo eventos de video direccionables al protocolo. Un NIP de criptografía post-cuántica abre la discusión sobre cómo preparar Nostr para el futuro contra ataques cuánticos. Amethyst v1.05.0 incluye listas de marcadores, notas de voz y una versión temprana para escritorio, mientras que Nostur v1.25.3 mejora los DMs de NIP-17 con reacciones y respuestas. En noticias de bibliotecas, rust-nostr expande el soporte de NIP-62 en los backends SQLite y LMDB, y NDK corrige un error en el seguimiento de suscripciones.

Noticias

Bitchat Completa la Auditoría de Seguridad de Cure53

Bitchat, el mensajero cifrado para iOS que combina Nostr con Cashu, se ha sometido a una auditoría de seguridad profesional realizada por Cure53, una de las firmas de seguridad más respetadas de la industria. Cure53 anteriormente auditó Signal, Mullvad VPN, y notablemente la especificación de cifrado NIP-44 que sustenta la mensajería privada moderna de Nostr.

La auditoría encontró más de 12 problemas de seguridad (BCH-01-002 hasta BCH-01-013). El equipo de Bitchat respondió con más de 17 pull requests. Las correcciones clave incluyen:

Limpieza de Secretos DH del Protocolo Noise - PR #928 corrige seis ubicaciones donde los secretos compartidos de Diffie-Hellman no se estaban poniendo a cero después del acuerdo de claves, restaurando las garantías de forward secrecy. Cuando los secretos persisten en memoria más tiempo del necesario, un volcado de memoria o ataque de arranque en frío podría comprometer comunicaciones pasadas.

Verificación de Firmas - Múltiples PRs refuerzan las rutas de verificación criptográfica, asegurando que las comprobaciones de autenticidad de mensajes no puedan ser eludidas mediante entradas malformadas.

Seguridad de Hilos - PR #929 añade sincronización de barrera a las colas de confirmación de lectura en NostrTransport, previniendo condiciones de carrera que podrían causar corrupción de datos o fallos bajo altos volúmenes de mensajes.

Seguridad de Memoria - PR #920 optimiza el deduplicador de mensajes para mejor rendimiento con alto volumen de mensajes mientras evita el agotamiento de memoria.

Validación de Entrada - PR #919 refuerza el análisis de cadenas hexadecimales para prevenir fallos por entrada malformada, un vector de ataque común para denegación de servicio.

Bitchat maneja ecash de Cashu, haciendo esencial la revisión de seguridad profesional. La auditoría sigue a la auditoría del Protocolo Marmot del año pasado y la auditoría de NIP-44 que verificó la capa de cifrado.

Actualizaciones de NIPs

Cambios recientes en el repositorio de NIPs:

Fusionados:

NIP-71 - Eventos de Video Direccionables (#1669) introduce los kinds 34235 (video horizontal) y 34236 (video vertical) como eventos direccionables. Una etiqueta d requerida proporciona identificadores únicos, para que los metadatos del video puedan actualizarse sin republicar todo el evento. Una etiqueta origin opcional rastrea las fuentes de importación. Ya implementado en Amethyst y nostrvine.

PRs Abiertos:

Criptografía Post-Cuántica - PR #2185 propone añadir algoritmos criptográficos resistentes a computación cuántica a Nostr. La especificación introduce ML-DSA-44 y Falcon-512 para firmas digitales, dirigidos a “eventos de muy alto valor” como aplicaciones y autoridades en lugar de usuarios individuales. Mientras que el cifrado simétrico de NIP-44 (ChaCha20) es resistente a computación cuántica, su intercambio de claves usa secp256k1 ECDH que es vulnerable al algoritmo de Shor. La propuesta incluye ML-KEM para acuerdo de claves para abordar esta brecha. Esta es una propuesta en etapa temprana que abre la discusión sobre agilidad criptográfica para la seguridad a largo plazo de Nostr.
BOLT12 para NIP-47 - Después de 137 comentarios y amplia discusión, la comunidad decidió que las ofertas BOLT12 merecen su propia especificación en lugar de extender NIP-47. Las ofertas BOLT12 proporcionan mejoras significativas sobre las facturas BOLT11 incluyendo reutilización, mejor privacidad a través de rutas cegadas e información opcional del pagador. El nuevo NIP definirá métodos como make_offer, pay_offer y list_offers para implementaciones de Nostr Wallet Connect.
NIP de Pistas de Audio - PR #1043 propone los kinds 32100 para pistas musicales y 32101 para episodios de podcast, dando al contenido de audio el mismo tratamiento de primera clase que NIP-71 proporciona para video. Actualmente, plataformas de audio como Wavlake, Zapstr y Stemstr usan cada una formatos de eventos propietarios, fragmentando el ecosistema. Un estándar común permitiría interoperabilidad para que los usuarios puedan descubrir y reproducir audio desde cualquier cliente compatible.
NIP-A3 Destinos de Pago Universales - PR #2119 propone eventos kind 10133 usando URIs payto: de RFC-8905 para exponer opciones de pago a través de múltiples redes. En lugar de crear kinds de eventos separados para Bitcoin, Lightning, Cashu o rieles de pago tradicionales, esta abstracción permite a los clientes analizar etiquetas estandarizadas e invocar manejadores de pago nativos. El enfoque es a prueba de futuro ya que los nuevos métodos de pago solo necesitan un esquema de URI payto:.

Análisis Profundo de NIPs: NIP-51 y NIP-65

Esta semana cubrimos dos NIPs que almacenan preferencias del usuario: NIP-51 para organizar contenido, y NIP-65 para organizar conexiones de relay. Ambos usan eventos reemplazables, lo que significa que cada nueva publicación sobrescribe la versión anterior.

NIP-51: Listas

NIP-51 define múltiples tipos de listas para organizar referencias a eventos, usuarios, hashtags y otro contenido. Amethyst v1.05.0 añade soporte de marcadores, haciendo de este un buen momento para entender cómo funcionan las listas.

La especificación define varios kinds de listas, cada uno sirviendo un propósito diferente. Kind 10000 es tu lista de silenciados para ocultar usuarios, hilos o palabras. Kind 10001 fija eventos para destacar en tu perfil. Kind 30003 almacena marcadores, que es lo que Amethyst ahora soporta. Otros kinds manejan conjuntos de seguidos (30000), colecciones curadas de artículos (30004), intereses de hashtags (30015) y conjuntos de emojis personalizados (30030).

Las listas referencian contenido a través de etiquetas. Una lista de marcadores usa etiquetas e para eventos específicos y etiquetas a para contenido direccionable como artículos:

{
 "id": "ae3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 30003,
 "tags": [
 ["d", "saved-articles"],
 ["e", "abc123def456...", "wss://relay.example"],
 ["a", "30023:author-pubkey:article-id", "wss://relay.example"]
 ],
 "content": "<encrypted-private-bookmarks>",
 "sig": "908a15e46fb4d8675bab026fc230a0e3542bfade63da02d542fb78b2a8513fcd0092619a2c8c1221e581946e0191f2af505dfdf8657a414dbca329186f009262"
}

La etiqueta d proporciona un identificador único, para que puedas mantener múltiples conjuntos de marcadores como “saved-articles”, “read-later” o “favorites” bajo el mismo kind.

Las listas soportan tanto elementos públicos como privados. Los elementos públicos aparecen en el array de etiquetas, visibles para cualquiera que obtenga el evento. Los elementos privados van en el campo content, cifrados usando NIP-44 hacia ti mismo. Esta estructura dual te permite mantener marcadores públicos mientras adjuntas notas privadas, o mantener una lista de silenciados sin revelar a quién has silenciado. Para cifrar hacia ti mismo, usa NIP-44 con tu propia pubkey como destinatario.

Los kinds de la serie 10000 son reemplazables, lo que significa que los relays mantienen solo un evento por pubkey. Los de la serie 30000 son reemplazables parametrizados, permitiendo un evento por combinación de pubkey y etiqueta d. En ambos casos, actualizar una lista significa publicar un reemplazo completo; no puedes enviar cambios incrementales. Los clientes deben preservar etiquetas desconocidas al modificar listas para evitar sobrescribir datos añadidos por otras aplicaciones.

NIP-65: Metadatos de Lista de Relays

NIP-65 define eventos kind 10002 que anuncian qué relays prefiere un usuario para lectura y escritura. Esto ayuda a otros usuarios y clientes a encontrar tu contenido.

{
 "id": "bd2217a96b5835b59f9a6a42d8d8a36f8c9b7d4e5f0a1b2c3d4e5f6a7b8c9d0e1",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 10002,
 "tags": [
 ["r", "wss://relay.damus.io", "read"],
 ["r", "wss://nos.lol"],
 ["r", "wss://relay.nostr.band", "write"]
 ],
 "content": "",
 "sig": "f1c2d3e4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2"
}

Cada etiqueta r contiene una URL de relay y un marcador opcional. Un marcador write designa tu outbox: relays donde publicas tu contenido. Un marcador read designa tu inbox: relays donde verificas menciones, respuestas y etiquetas. Omitir el marcador indica ambos.

Cuando Alice quiere encontrar las publicaciones de Bob, su cliente obtiene el kind 10002 de Bob, extrae sus relays de escritura (su outbox) y se suscribe allí. Cuando Alice responde a Bob, su cliente publica en los relays de lectura de él (su inbox) para que vea la mención. Este enrutamiento consciente de relays es el “modelo outbox”, y distribuye a los usuarios entre muchos relays en lugar de concentrar a todos en unos pocos servidores centrales.

NIP-65 maneja el enrutamiento de contenido público, pero los mensajes privados usan una lista separada. NIP-17 define kind 10050 para relays de inbox de DM, usando etiquetas relay en lugar de etiquetas r. Al enviar a alguien un mensaje privado, los clientes buscan el evento kind 10050 del destinatario y publican el mensaje envuelto cifrado allí. Esta separación mantiene el enrutamiento de DM distinto del enrutamiento de contenido público, y permite a los usuarios especificar diferentes relays para comunicación privada versus pública.

El modelo outbox mejora la resistencia a la censura ya que ningún relay único necesita almacenar o servir el contenido de todos. Los clientes mantienen conexiones con los relays listados en los eventos NIP-65 de sus usuarios seguidos, conectándose dinámicamente a nuevos relays a medida que descubren nuevas cuentas. NIP-65 complementa las pistas de relay encontradas en otros NIPs. Cuando etiquetas a alguien con ["p", "pubkey", "wss://hint.relay"], la pista le dice a los clientes dónde buscar esa referencia específica. NIP-65 proporciona la lista autoritativa controlada por el usuario, mientras que las pistas ofrecen atajos incrustados en eventos individuales.

Para mejores resultados, mantén tu lista de relays actualizada ya que las entradas obsoletas te hacen más difícil de encontrar. La especificación recomienda de dos a cuatro relays por categoría. Listar demasiados relays sobrecarga a cada cliente que quiere obtener tu contenido, ralentizando su experiencia y aumentando la carga de red. Los clientes almacenan en caché los eventos NIP-65 y los refrescan periódicamente para mantenerse actualizados a medida que los usuarios actualizan sus preferencias.

Lanzamientos

Amethyst v1.05.0 - El popular cliente de Android lanza una actualización importante con varias características destacadas. Las listas de marcadores kind 30003 de NIP-51 permiten a los usuarios guardar publicaciones para referencia posterior, sincronizándose entre clientes compatibles. Las notas de voz ahora funcionan en DMs y publicaciones regulares con visualización de forma de onda, selección de servidor de medios e indicadores de progreso de carga. Las puntuaciones de Web of Trust ahora son visibles en la interfaz, ayudando a los usuarios a entender cómo el algoritmo evalúa las cuentas en relación con su grafo social. La migración de base de datos Quartz mejora el rendimiento de consultas como parte del trabajo de Kotlin Multiplatform financiado por OpenSats. Un lanzamiento temprano para escritorio trae Amethyst a Windows, macOS y Linux a través de Compose Multiplatform, compartiendo la misma base de código que la aplicación de Android. Nuevos flujos de incorporación suavizan la experiencia para usuarios nuevos de Nostr.

Nostur v1.25.3 - El cliente de iOS y macOS se enfoca en la mensajería privada con mejoras de NIP-17. Las conversaciones de DM ahora soportan reacciones y respuestas, trayendo la interactividad de las publicaciones públicas a los mensajes cifrados. La vista de conversación ha sido rediseñada con mejor threading para que los intercambios de múltiples mensajes sean más fáciles de seguir, y las marcas de tiempo muestran “hace tiempo” en la lista de DM para escaneo rápido. Los usuarios de escritorio obtienen diseños de múltiples columnas para ver múltiples feeds o conversaciones lado a lado. El soporte de firmante remoto NIP-46 permite a los usuarios mantener sus claves privadas en aplicaciones de firmante dedicadas como Amber o nsec.app. Correcciones adicionales restauran la funcionalidad de DM en iOS 15 e iOS 16, resuelven retrasos en notificaciones y añaden la capacidad de configurar qué relays reciben los DMs publicados.

Cambios notables de código y documentación

Estos son pull requests abiertos y trabajo en etapa temprana, perfectos para obtener retroalimentación antes de que se fusionen. Si algo te llama la atención, considera revisar o comentar.

Citrine (Relay de Android)

PR #89 corrige una vulnerabilidad de inyección SQL en la aplicación de relay personal de Android. El problema permitía que datos de eventos malformados ejecutaran consultas de base de datos arbitrarias, un fallo serio para cualquier aplicación que almacena y procesa entrada no confiable. La corrección sanitiza correctamente todas las operaciones de base de datos usando consultas parametrizadas. Aún no se ha etiquetado ningún lanzamiento, por lo que los usuarios necesitarán esperar la próxima versión o compilar desde el código fuente. PR #90 optimiza el rendimiento de consultas de ContentProvider con filtrado a nivel de base de datos y paginación, reduciendo la latencia cuando aplicaciones externas como Amethyst acceden a la base de datos de eventos de Citrine a través de la capa de comunicación entre procesos de Android.

rust-nostr (Biblioteca)

El soporte de NIP-62 (Solicitudes de Desvanecimiento) se está expandiendo a través de los backends de base de datos de rust-nostr. PR #1180, fusionado hace dos semanas, añadió soporte de NIP-62 a SQLite, manejando solicitudes de desvanecimiento ALL_RELAYS ya que la capa de base de datos no conoce URLs de relay específicas. PR #1210 extiende esto al backend LMDB, asegurando que las solicitudes de desvanecimiento se persistan en disco y sobrevivan a reinicios del relay. Una implementación de IndexedDB para entornos de navegador también está en progreso. Juntos, estos cambios dan a los desarrolladores soporte consistente de NIP-62 a través de SQLite, LMDB y pronto almacenamiento del navegador.

NDK (Nostr Development Kit)

PR #375 corrige un error en el sistema de seguimiento de seenEvents. El problema causaba que ciertos patrones de suscripción marcaran incorrectamente eventos como ya vistos, llevando a contenido perdido cuando los usuarios abrían nuevas suscripciones o se reconectaban a relays. La corrección asegura que los eventos se rastreen con precisión a través de los ciclos de vida de las suscripciones, lo cual es particularmente importante para aplicaciones que se suscriben y desuscriben dinámicamente basándose en la navegación del usuario. NDK se actualizó a beta.70 con esta corrección incluida.

Damus (iOS)

PR #3515 corrige un fallo de inicio que afectaba a usuarios de iOS 17. El problema provenía de un desbordamiento aritmético en NdbUseLock, una clase de respaldo usada porque los Swift Mutexes no están disponibles en iOS 17. La corrección reemplaza el enfoque de sincronización anterior con NSLock, que está disponible en iOS 17 y maneja las condiciones de carrera restantes correctamente. Los usuarios de iOS 18+ no estaban afectados ya que tienen acceso a la implementación nativa de Swift Mutex.

Por separado, un lote de mejoras para artículos de formato largo llegó via PR #3509. Las barras de progreso de lectura rastrean tu posición a través de los artículos, los tiempos estimados de lectura aparecen en las vistas previas, y el modo sepia con ajustes de altura de línea configurables proporcionan una lectura más cómoda. El modo de enfoque oculta automáticamente la navegación al desplazarse hacia abajo y la restaura al tocar, reduciendo el desorden visual para una lectura sin distracciones. Varias correcciones abordan la visualización de imágenes en contenido markdown y aseguran que los artículos se abran al principio en lugar de a mitad de camino.

Zap.stream (Transmisión en Vivo)

La integración de chat de YouTube y Kick conecta mensajes de plataformas de streaming externas a Nostr. Los streamers que transmiten simultáneamente a YouTube, Kick y Zap.stream ahora pueden ver todos los mensajes de chat en una vista unificada, con mensajes de cada plataforma apareciendo junto a los comentarios nativos de Nostr. Esto elimina un punto de fricción importante para creadores que quieren usar Nostr para streaming pero no pueden abandonar audiencias en plataformas establecidas. La integración muestra de qué plataforma se originó cada mensaje y maneja el flujo de autenticación para conectar cuentas externas.

Chachi (Grupos NIP-29)

El cliente de chat grupal NIP-29 envió seis PRs fusionados esta semana. Una actualización de seguridad aborda CVE-2026-22029, una vulnerabilidad XSS en react-router que podría habilitar ataques de redirección abierta; la corrección actualiza a react-router-dom 6.30.0. PR #92 añade carga paginada de mensajes para chats grupales, para que las conversaciones largas se carguen incrementalmente en lugar de todas a la vez. PR #91 corrige varios errores de NIP-29 incluyendo una condición de carrera que causaba nombres de grupo en blanco en la carga inicial y listas de participantes indefinidas que hacían fallar las vistas de miembros. La cobertura de traducción ahora abarca los 31 idiomas soportados con 1060 claves cada uno.

0xchat (Mensajería)

El cliente de mensajería estilo Telegram mejoró el cumplimiento de NIP-55 al guardar correctamente los nombres de paquetes de firmantes cuando se usan aplicaciones de firma externas, corrigiendo problemas donde la aplicación perdía el rastro de qué firmante usar después de reinicios. El manejo de respuestas NIP-17 ahora incluye correctamente la etiqueta e para threading, asegurando que las respuestas aparezcan en el contexto de conversación correcto entre clientes. Las optimizaciones de rendimiento abordan el lag de desplazamiento en listas de mensajes, un punto de dolor común al cargar historiales de chat largos. El autoguardado de borradores previene la pérdida de mensajes si navegas lejos a mitad de composición, y las opciones de almacenamiento de archivos ahora incluyen endpoints predeterminados de FileDropServer y BlossomServer.

Primal (iOS)

El soporte de firmante remoto NIP-46 llega a iOS via PR #184, completando el despliegue multiplataforma que comenzó con Android hace varias semanas. Los usuarios ahora pueden mantener sus claves privadas en servicios bunker dedicados como nsec.app o instancias de nsecBunker autoalojadas, conectándose a través de relays de Nostr para firmar eventos sin exponer las claves a la aplicación cliente. Esta separación mejora la postura de seguridad para usuarios que quieren usar las características de Primal mientras mantienen prácticas de gestión de claves más estrictas. La implementación incluye escaneo de códigos QR para URIs de conexión bunker y maneja el flujo de solicitud/respuesta de NIP-46 sobre mensajes cifrados de relay.

Eso es todo por esta semana. ¿Estás construyendo algo? ¿Tienes noticias para compartir? ¿Quieres que cubramos tu proyecto? Contáctanos via DM de NIP-17 o encuéntranos en Nostr.

Nostr Compass #4

Wed, 07 Jan 2026 00:00:00 +0000

Bienvenidos de nuevo a Nostr Compass, tu guía semanal del ecosistema del protocolo Nostr.

Esta semana: Primal Android implementa firma remota NIP-46 y soporte para firmante local NIP-55, convirtiéndolo en un centro de firma completo para otras aplicaciones Android. El equipo del Protocolo Marmot abordó hallazgos de una auditoría de seguridad con 18 PRs fusionados que fortalecen la mensajería cifrada basada en MLS. Citrine alcanza la v1.0 y Applesauce lanza la v5.0 en toda su suite de bibliotecas. TENEX desarrolla supervisión de agentes de IA en Nostr, y Jumble agrega agrupación inteligente de relays. Una corrección en la especificación NIP-55 aclara los campos de retorno de nip44_encrypt, y un PR de NIP-50 propone extensiones de expresiones de consulta para búsqueda avanzada. En nuestra sección de profundización, explicamos NIP-04 y NIP-44: por qué el cifrado heredado tiene fallas de seguridad y cómo el reemplazo moderno las corrige.

Noticias

Primal Android se Convierte en un Centro de Firma Completo - La Versión 2.6.18 agrega tanto firma remota NIP-46 como firma local NIP-55, convirtiendo a Primal en un firmante completo para otras aplicaciones Nostr. La firma remota vía NIP-46 permite a los usuarios conectarse a servicios bunker a través de relays Nostr, manteniendo las claves completamente fuera de su dispositivo. La firma local vía NIP-55 expone a Primal como un proveedor de contenido de Android, para que aplicaciones como Amethyst o Citrine puedan solicitar firmas sin jamás tocar la clave privada. Varios PRs de seguimiento corrigieron problemas de compatibilidad con el requisito de pubkey hexadecimal de la especificación NIP-55, y mejoraron el análisis de URIs nostrconnect:// mal formadas. La versión también incluye pre-caché de medios para un desplazamiento más fluido, tiempos de carga de hilos mejorados y pre-caché de avatares.

Protocolo Marmot Fortalece la Seguridad Tras Auditoría - El Kit de Desarrollo Marmot (mdk), que implementa mensajería cifrada de extremo a extremo basada en NIP-104 MLS, recibió extensas correcciones de seguridad esta semana. Dieciocho pull requests fusionados abordaron hallazgos de la auditoría incluyendo: verificación de hash para imágenes de grupo cifradas para prevenir ataques de sustitución de blobs a nivel de almacenamiento, paginación para bienvenidas pendientes para prevenir agotamiento de memoria, filtración de MLS Group ID en mensajes de error, y aplicación de codificación base64 para paquetes de claves. La especificación de Marmot en sí fue actualizada con versionado MIP-04 v2 y mejoras de seguridad. PRs activos continúan abordando reutilización de nonce, zerorizacion de secretos y vectores de contaminación de caché.

Nostrability Rastrea Soporte de Relay Hints - Un nuevo rastreador de compatibilidad de relay hints documenta cómo los clientes construyen y consumen relay hints en todo el ecosistema. El rastreador revela que mientras la mayoría de los clientes ahora construyen hints según NIP-10 y NIP-19, el consumo varía ampliamente: algunos clientes incluyen hints en eventos salientes pero no usan hints entrantes para obtener datos. Seis clientes obtuvieron el estado “Completo” por implementación completa. El rastreador es útil para desarrolladores que verifican interoperabilidad y para usuarios que se preguntan por qué algunos clientes encuentran contenido que otros no pueden.

Nostria 2.0 Lanza Renovación de Funciones Multiplataforma - El cliente Nostria lanzó la versión 2.0 el 30 de diciembre con adiciones significativas en iOS (TestFlight), Android (Play Store), Web y Windows. La versión agrega soporte nativo de música con creación de listas de reproducción, subida de pistas, pagos a artistas basados en zap, y un reproductor estilo WinAmp con ecualizador funcional. El streaming en vivo obtiene integración con Game API mostrando metadatos enriquecidos durante transmisiones de juegos. Una nueva función de Resumen genera digestos de actividad por hora, día o semana como vistas de línea de tiempo comprimidas. La sección Descubrir ofrece listas curadas para encontrar contenido y perfiles. La publicación de medios se simplifica con generación automática de publicaciones de formato corto para descubrimiento entre clientes. Las conexiones de firmante remoto ahora funcionan vía escaneo de código QR sin configuración manual. El descubrimiento de perfiles aborda un punto de dolor común de Nostr: cuando los usuarios se mueven entre relays sin llevar sus metadatos, Nostria localiza su perfil y lo republica en sus relays actuales. Los suscriptores Premium obtienen integración de canal de YouTube, Memos privados, paneles de analíticas y respaldos automáticos de lista de seguidos con opciones de fusión/restauración.

Actualizaciones de NIPs

Cambios recientes al repositorio de NIPs:

Fusionados:

NIP-55 - Corregido el campo de retorno para el método nip44_encrypt (#2184). Los firmantes de Android ahora deben devolver la carga útil cifrada en el campo signature (coincidiendo con nip44_decrypt) en lugar de un campo separado. Esto alinea la especificación con las implementaciones existentes en Amber y Primal.

PRs Abiertos:

NIP-50 - Extensiones de Expresiones de Consulta (#2182) propone extender la búsqueda NIP-50 con expresiones de consulta estructuradas. El PR agrega operadores como kind:1, author:npub1..., y combinaciones booleanas (AND, OR, NOT), permitiendo consultas de búsqueda más precisas más allá de la simple coincidencia de texto. Esto permitiría a los clientes construir interfaces de búsqueda avanzadas mientras mantienen compatibilidad hacia atrás con cadenas de búsqueda básicas.

Profundización en NIPs: NIP-04 y NIP-44

Esta semana cubrimos los estándares de cifrado de Nostr: el heredado NIP-04 que aún encontrarás, y su reemplazo moderno NIP-44 que corrige fallas de seguridad críticas.

NIP-04: Mensajes Directos Cifrados (Heredado)

NIP-04 fue el primer intento de Nostr de mensajería cifrada, usando eventos kind 4. Aunque es simple de implementar, tiene debilidades de seguridad conocidas y está deprecado en favor de NIP-44.

Cómo funciona: NIP-04 usa ECDH (Diffie-Hellman de Curva Elíptica) para derivar un secreto compartido entre emisor y receptor, luego cifra con AES-256-CBC.

{
 "id": "<event-id>",
 "pubkey": "<sender-pubkey>",
 "created_at": 1736200000,
 "kind": 4,
 "tags": [["p", "<recipient-pubkey>"]],
 "content": "base64-ciphertext?iv=base64-iv",
 "sig": "<signature>"
}

El flujo de cifrado:

Calcular punto compartido: shared = ECDH(sender_privkey, recipient_pubkey)
Derivar clave: key = SHA256(shared_x_coordinate)
Generar IV aleatorio de 16 bytes
Cifrar: ciphertext = AES-256-CBC(key, iv, plaintext)
Formatear contenido: base64(ciphertext)?iv=base64(iv)

Problemas de seguridad:

Sin autenticación: AES-CBC proporciona confidencialidad pero no integridad. Un atacante que controle un relay podría modificar bits del texto cifrado, causando cambios predecibles en el texto plano (ataques de volteo de bits).
IV en claro: El vector de inicialización se transmite junto al texto cifrado, y el modo CBC con IVs predecibles habilita ataques de texto plano elegido.
Sin validación de relleno: Las implementaciones varían en cómo manejan el relleno PKCS#7, potencialmente habilitando ataques de oráculo de relleno.
Exposición de metadatos: La pubkey del emisor, la pubkey del receptor y la marca de tiempo son todas visibles para los relays.
Reutilización de clave: El mismo secreto compartido se usa para todos los mensajes entre dos partes, para siempre.

Por qué aún existe: Muchos clientes y relays antiguos solo soportan NIP-04. Lo encontrarás al interactuar con sistemas heredados. Firmantes como Amber y aplicaciones como Primal aún implementan nip04_encrypt/nip04_decrypt para compatibilidad hacia atrás.

NIP-44: Cifrado Versionado

NIP-44 es el estándar de cifrado moderno, diseñado para corregir las fallas conocidas de NIP-04. Una auditoría de seguridad de Cure53 de las implementaciones de NIP-44 identificó 10 problemas (incluyendo ataques de temporización y preocupaciones de secreto hacia adelante) que fueron abordados antes de que la especificación fuera finalizada. Usa ChaCha20-Poly1305 con derivación de clave apropiada y cifrado autenticado.

Mejoras clave sobre NIP-04:

Aspecto	NIP-04	NIP-44
Cifrador	AES-256-CBC	XChaCha20-Poly1305
Autenticación	Ninguna	Poly1305 MAC
Derivación de clave	SHA256(shared_x)	HKDF con sal
Nonce	IV de 16 bytes, patrón reutilizado	Nonce aleatorio de 24 bytes
Relleno	PKCS#7 (filtra longitud)	Rellenado a potencia de 2
Versionado	Ninguno	Prefijo de byte de versión

Flujo de cifrado:

Clave de conversación: Derivar una clave estable para cada par emisor-receptor:

shared_x = ECDH(sender_privkey, recipient_pubkey).x
conversation_key = HKDF-SHA256(
 ikm = shared_x,
 salt = "nip44-v2",
 info = ""
)

Claves de mensaje: Para cada mensaje, generar un nonce aleatorio de 32 bytes y derivar claves de cifrado/autenticación:

keys = HKDF-SHA256(
 ikm = conversation_key,
 salt = nonce,
 info = "nip44-v2"
)
chacha_key = keys[0:32]
chacha_nonce = keys[32:44]
hmac_key = keys[44:76]

Rellenar texto plano: Rellenar a la siguiente potencia de 2 (minimo 32 bytes) para ocultar la longitud del mensaje:
```
padded = [length_u16_be] + [plaintext] + [zeros to next power of 2]
```

Cifrar y autenticar:

ciphertext = XChaCha20(chacha_key, chacha_nonce, padded)
mac = HMAC-SHA256(hmac_key, nonce + ciphertext)

Formatear carga util:

payload = [version=0x02] + [nonce] + [ciphertext] + [mac]
content = base64(payload)

Byte de versión: El primer byte (0x02) indica la versión de cifrado. Esto permite actualizaciones futuras sin romper mensajes existentes. La versión 0x01 fue un borrador anterior que nunca fue ampliamente desplegado.

Descifrado:

Decodificar base64, verificar que el byte de versión sea 0x02
Extraer nonce (bytes 1-32), texto cifrado y MAC (últimos 32 bytes)
Derivar clave de conversación usando la clave privada del receptor y la clave pública del emisor
Derivar claves de mensaje de la clave de conversación y el nonce
Verificar MAC antes de descifrar (rechazar si es inválido)
Descifrar texto cifrado, extraer prefijo de longitud, devolver texto plano sin relleno

Propiedades de seguridad:

Cifrado autenticado: El MAC Poly1305 asegura que cualquier manipulación se detecte antes del descifrado
Secreto hacia adelante (parcial): Cada mensaje usa un nonce único, por lo que comprometer un mensaje no revela otros. Sin embargo, comprometer una clave privada aún revela todos los mensajes pasados (sin ratcheting).
Ocultación de longitud: El relleno a potencia de 2 oscurece la longitud exacta del mensaje
Resistencia a ataques de temporización: Comparación en tiempo constante para verificación de MAC

Uso en la práctica: NIP-44 es la capa de cifrado para:

NIP-17 mensajes directos privados (dentro de gift wrap)
NIP-46 comunicación de firmante remoto
NIP-59 cifrado de seal
Protocolo Marmot mensajes de grupo, donde NIP-44 envuelve contenido cifrado con MLS usando una clave derivada del secreto exportador de MLS
Cualquier aplicación que necesite cifrado seguro punto a punto

Guía de migración: Las nuevas aplicaciones deben usar NIP-44 exclusivamente. Para compatibilidad hacia atrás, verifica si el cliente de un contacto soporta NIP-44 (vía metadatos de aplicación NIP-89 o soporte de relay) antes de recurrir a NIP-04. Al recibir mensajes, intenta primero el descifrado NIP-44, luego recurre a NIP-04 para contenido heredado.

Lanzamientos

Primal Android v2.6.18 - El lanzamiento completo agrega firma remota NIP-46 y firma local NIP-55, convirtiendo a Primal en un centro de firma para otras aplicaciones Android. Las mejoras de rendimiento incluyen pre-caché de medios, pre-caché de avatares y carga de hilos más rápida. Las correcciones de errores abordan auto-menciones en biografías, fallos en la galería de medios y respaldos de títulos de stream. En iOS, Primal usa reproducción de audio en segundo plano para mantener la aplicación activa y recibir solicitudes de firma NIP-46; los usuarios pueden cambiar el sonido o silenciarlo completamente en configuración.

Mostro v0.15.6 - La plataforma de trading P2P de Bitcoin NIP-69 en su último lanzamiento completa la implementación del fondo de desarrollo con eventos de auditoría de Fase 4. Los pagos de tarifas de desarrollo ahora se rastrean vía eventos Nostr kind 38383 publicados después de cada pago exitoso, permitiendo verificación y analíticas de terceros. Los cálculos de montos fueron corregidos para mensajes de comprador/vendedor, y la lógica de premium fue alineada con la implementación de referencia lnp2pbot.

Aegis v0.3.5 - El firmante multiplataforma agrega modo oscuro, visualización mejorada de iconos de aplicación y diseños de UI más limpios. Las correcciones de errores abordan conflictos con iCloud Private Relay en iOS y problemas de análisis de eventos. El lanzamiento también mejora cómo el JSON de eventos se pasa a la función de firma en Rust.

Citrine v1.0.0 - La aplicación de relay para Android alcanza la 1.0. Citrine te permite ejecutar un relay Nostr personal directamente en tu dispositivo Android, útil para caché local, respaldo o como compañero de NIP-55. Esta versión agrega un manejador de reportes de fallos, mejora la eficiencia de consultas de base de datos y actualiza traducciones vía Crowdin.

Applesauce v5.0.0 - La suite de bibliotecas TypeScript de hzrd149 lanza una versión mayor con cambios que rompen compatibilidad enfocados en corrección y simplicidad. El paquete core ahora verifica firmas de eventos por defecto y renombra métodos de coordenadas para usar terminología de “address” más clara (parseCoordinate -> parseReplaceableAddress). El paquete relay reduce los reintentos por defecto de 10 a 3 e ignora relays inalcanzables por defecto, además agrega createUnifiedEventLoader para obtención de eventos más simple. El paquete wallet obtiene descubrimiento de mints Cashu NIP-87 . Las dependencias directas de nostr-tools fueron removidas de los paquetes, reduciendo el tamaño del bundle y conflictos de versiones.

Cambios notables de código y documentación

Estos son pull requests abiertos y trabajo en etapa temprana, perfectos para obtener retroalimentación antes de que se fusionen. Si algo te llama la atención, considera revisar o comentar!

Damus (iOS)

Una serie de PRs mejoran la experiencia de artículos de formato largo. Mejoras de UX de lectura agregan una barra de progreso, tiempo estimado de lectura, modo sepia, altura de línea ajustable y modo de enfoque que oculta la navegación mientras se desplaza. Correcciones de imágenes aseguran que las imágenes en contenido markdown se muestren con proporciones adecuadas al preprocesar imágenes independientes como elementos a nivel de bloque. Tarjetas de vista previa de formato largo reemplazan texto inline @naddr1... con tarjetas de vista previa enriquecidas mostrando título y metadatos del artículo. Una nueva suite de pruebas de integración de relay agrega 137 pruebas relacionadas con red incluyendo verificación del protocolo NIP-01 y comportamiento bajo condiciones de red degradadas (simulación 3G).

Bitchat (Mensajería Cifrada)

Endurecimiento de seguridad en el mensajero iOS Nostr+Cashu. Limpieza de secreto DH del protocolo Noise corrige seis ubicaciones donde los secretos compartidos no se estaban poniendo a cero después del acuerdo de claves Diffie-Hellman, restaurando las garantías de secreto hacia adelante. Seguridad de hilos para colas de recibos de lectura agrega sincronización de barrera para prevenir condiciones de carrera en NostrTransport. Optimización del deduplicador de mensajes mejora el rendimiento con altos volúmenes de mensajes, y endurecimiento del análisis de cadenas hexadecimales previene fallos por entrada malformada.

Frostr (Firma de Umbral)

El protocolo de firma de umbral basado en FROST agregó visualización de código QR para credenciales de grupo y credenciales de participación durante la incorporación y en la interfaz del firmante. Esto permite una configuración más fácil al distribuir participaciones de clave entre múltiples dispositivos, permitiendo a los usuarios escanear credenciales en lugar de copiar manualmente cadenas largas.

Marmot mdk (Biblioteca)

Más allá de las correcciones de seguridad mencionadas anteriormente, PRs activos abordan hallazgos restantes de la auditoría: tipo Secret para zerorizacion introduce un tipo envolvente que automáticamente pone a cero datos sensibles al descartarse, paginación de consultas de mensajes previene agotamiento de memoria al cargar historial de chat, y almacenamiento cifrado agrega cifrado en reposo para la base de datos SQLite que almacena el estado del grupo y mensajes.

Amethyst (Android)

Una semana ocupada de correcciones de estabilidad en el cliente Android. Análisis JSON tolerante previene fallos de eventos malformados al hacer que Kotlin Serialization sea más permisivo. La validación de eventos ahora verifica el tamaño del campo kind antes de procesar para evitar excepciones de valores sobredimensionados. La UI de puntuación de confianza obtuvo un icono más pequeño para reducir la interferencia visual, y registro de errores mejorado ayuda a diagnosticar problemas de conexión de relay. Las actualizaciones de traducción llegaron vía Crowdin, y varias advertencias de SonarQube fueron abordadas.

TENEX (Agentes de IA)

El framework de agentes de IA nativo de Nostr vio 81 commits esta semana construyendo capacidades autónomas. El nuevo sistema de supervisión de agentes implementa heurísticas de comportamiento para monitorear acciones de agentes e intervenir cuando sea necesario. Transparencia de delegación agrega registro de intervención de usuario a las transcripciones de delegación, para que los usuarios puedan auditar lo que los agentes hicieron en su nombre. El registro de proveedores LLM fue modularizado para integración más fácil de diferentes backends de IA. El soporte de conversación entre proyectos permite que los agentes mantengan contexto a través de múltiples proyectos basados en Nostr.

Jumble (Cliente Web)

El cliente web enfocado en relays agregó varias mejoras de experiencia de usuario. Pool de relay inteligente gestiona conexiones inteligentemente basándose en patrones de uso. Alternador de feed en vivo permite a los usuarios cambiar entre streaming en tiempo real y actualización manual. Mostrar automáticamente nuevas notas en la parte superior muestra contenido fresco sin requerir recarga de página. Caché persistente para el feed de seguidos y notificaciones mejora los tiempos de carga en visitas de retorno. Los usuarios ahora pueden cambiar relays por defecto a través de configuración.

Eso es todo por esta semana. ¿Estás construyendo algo? ¿Tienes noticias para compartir? ¿Quieres que cubramos tu proyecto? Contáctanos vía DM NIP-17 o encuéntranos en Nostr.

Nostr Compass #3

Wed, 31 Dec 2025 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal del ecosistema del protocolo Nostr.

Esta semana: Al cerrar 2025, miramos hacia atrás a cinco años de hitos de diciembre en la evolución de Nostr. Desde el primer lanzamiento del cliente de fiatjaf en diciembre de 2020, pasando por la donación fundamental de Jack Dorsey de 14 BTC en diciembre de 2022, hasta la proliferación de NIP-55 signer este mes y la aceleración de caché de 162x de NDK, diciembre ha marcado consistentemente puntos de inflexión para el protocolo. Este número especial traza la historia técnica a través de cada diciembre, documentando el crecimiento del protocolo desde dos relays experimentales hasta más de 2,500 nodos en 50 países. Además: El módulo de escritorio de Amethyst toma forma a través de Quartz, Notedeck obtiene mensajería, Citrine aloja aplicaciones web, y NIP-54 corrige la internacionalización para scripts no latinos.

Resumen de Diciembre: Cinco Años de Diciembres de Nostr

Nostr cumple cinco años este año. fiatjaf inició el protocolo el 7 de noviembre de 2020, y cada diciembre desde entonces ha marcado una fase distinta en su evolución: desde prueba de concepto hasta movimiento global hasta ecosistema de producción. Este es un retrospectivo técnico de diciembre de 2020 hasta diciembre de 2025, los años formativos que establecieron la base de Nostr y catalizaron su momento de explosión.

Diciembre 2020: Génesis

El primer mes completo de existencia de Nostr vio a fiatjaf lanzar Branle, el primer cliente del protocolo, construido con Quasar (Vue.js) y absurd-sql para almacenamiento local. fiatjaf ya había establecido la arquitectura central: usuarios identificados por claves públicas secp256k1, todas las publicaciones firmadas criptográficamente, relays sirviendo como almacenamiento simple que no se comunican entre sí. Uno o dos relays experimentales servían a un puñado de primeros adoptantes coordinándose en el grupo de Telegram @nostr_protocol, que se había lanzado el 16 de noviembre. La documentación original describía “el protocolo abierto más simple que es capaz de crear una red social global resistente a la censura,” una premisa que tomaría dos años más en probarse.

Diciembre 2021: Desarrollo Temprano

El 31 de diciembre de 2021, Nostr llegó a la portada de Hacker News con 110 puntos y 138 comentarios, enviado por Cameri. Esto marcó la primera exposición significativa del protocolo a la comunidad de desarrolladores más amplia. La red funcionaba con aproximadamente siete relays con menos de 1,000 usuarios. Branle recibió actualizaciones incluyendo importación de clave privada (31 de diciembre) y soporte multi-relay. Un cliente de línea de comandos, noscl, proporcionaba interacción basada en terminal. Las especificaciones del protocolo existían en la documentación de fiatjaf, aunque el repositorio formal de NIPs no se crearía hasta mayo de 2022. El protocolo era, como lo describió fiatjaf, “un trabajo en progreso.”

Diciembre 2022: El Punto de Inflexión

Diciembre de 2022 transformó a Nostr de un experimento de nicho en un movimiento mainstream. El catalizador llegó el 15 de diciembre, cuando Jack Dorsey donó 14.17171699 BTC (~$245,000-$250,000) a fiatjaf después de descubrir el protocolo y declarar que era “100 por ciento lo que queríamos de Bluesky, pero no fue desarrollado por una empresa.” El 16 de diciembre, fiatjaf anunció la división de fondos con el desarrollador de Damus William Casarin (jb55), y Dorsey verificó su cuenta de Nostr (npub: npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m). El financiamiento legitimó el proyecto de la noche a la mañana.

La misma semana, el caos de Twitter aceleró la adopción. Del 14 al 15 de diciembre vio suspensiones de periodistas prominentes del New York Times, CNN y Washington Post. El 18 de diciembre, Twitter anunció prohibiciones a cuentas que promocionaban Nostr, Mastodon y otras plataformas. La política se revirtió al día siguiente después de la reacción negativa. El éxodo llevó a los usuarios a explorar alternativas.

El desarrollo del protocolo se aceleró. El 16 de diciembre, se fusionó NIP-19 (#57), introduciendo identificadores codificados en bech32 (npub, nsec, note, nprofile, nevent) que hacían las claves legibles por humanos y distinguibles. El repositorio de NIPs registró más de 36 commits ese mes, incluyendo actualizaciones de NIP-40 y NIP-07. Los clientes proliferaron: Damus llenó su beta de TestFlight en horas, Astral bifurcó Branle para creación de perfiles, Snort se lanzó como un cliente web “rápido y resistente a la censura,” y Vitor Pamplona comenzó el desarrollo de Amethyst. Alby v1.22.1 “Kemble’s Cascade of Stars” se envió el 22 de diciembre con soporte para NIP-19. Para el 7 de diciembre, Nostr tenía aproximadamente 800 usuarios con perfiles; cuando Damus llegó a la App Store el 31 de enero de 2023, se abrieron las compuertas, impulsando el crecimiento a más de 315,000 usuarios para junio de 2023.

Diciembre 2023: Maduración del Ecosistema

Diciembre de 2023 marcó un punto de inflexión crítico para la seguridad del protocolo Nostr. El 20 de diciembre, se fusionó la revisión 3 de NIP-44 después de una auditoría de seguridad independiente de Cure53 (NOS-01) que identificó 10 problemas en las implementaciones de TypeScript, Go y Rust, incluyendo ataques de timing y preocupaciones de forward secrecy. La especificación actualizada reemplazó el cifrado defectuoso de NIP-04 con ChaCha20 y HMAC-SHA256, estableciendo la base criptográfica que ahora sustenta los DMs privados de NIP-17 y el gift wrapping de NIP-59. La misma semana, OpenSats anunció su cuarta oleada de grants el 21 de diciembre, financiando siete proyectos incluyendo Lume, noStrudel, ZapThreads, y una auditoría independiente de NIP-44. Esto siguió a la primera oleada en julio de 2023 que había financiado Damus, Coracle, Iris, y otros, llevando la asignación total del Fondo Nostr a aproximadamente $3.4 millones a través de 39 grants.

El mes también expuso tensiones de sostenibilidad en el ecosistema. El 28 de diciembre, William Casarin (jb55) publicó en Stacker News que 2024 sería “probablemente el último año de Damus,” citando que “los clientes de nostr no generan dinero” después de que las restricciones de Apple sobre zaps en la aplicación limitaron severamente el potencial de ingresos. El equipo de Damus había rechazado previamente financiamiento de VC. Mientras tanto, Nostr Wallet Connect v0.4.1 se envió el 26 de diciembre, extendiendo NIP-47 con métodos pay_keysend, make_invoice, lookup_invoice, list_transactions, get_balance, y get_info, sentando las bases para las integraciones de wallets que se convertirían en estándar en todos los clientes.

Diciembre 2024: Avance del Protocolo

Diciembre de 2024 abrió con el lanzamiento Alpha de Notedeck el 30 de noviembre, el cliente de escritorio basado en Rust del equipo Damus con una interfaz multi-columna con soporte para múltiples cuentas. Construido para Linux, macOS y Windows (Android planificado para 2025), Notedeck se envió inicialmente a suscriptores de Damus Purple y representó una expansión estratégica más allá de iOS. Dos semanas después, OpenSats anunció su novena oleada de grants el 16 de diciembre, financiando AlgoRelay (el primer relay algorítmico para feeds personalizados), Pokey (app Android con mesh Bluetooth para internet restringido), Nostr Safebox (almacenamiento de tokens Cashu con NIP-60), y LumiLumi (cliente web ligero y accesible), llevando la asignación total del Fondo Nostr a aproximadamente $9 millones, un aumento del 67% año tras año.

El mes vio una maduración significativa de clientes en todo el ecosistema. Gossip 0.13.0 llegó el 23 de diciembre con soporte de File Metadata (NIP-92/NIP-94), integración de Blossom, y búsqueda en relay con NIP-50. Coracle 0.5.0 se envió el 12 de diciembre con onboarding rediseñado e integración de nostr-editor. El desarrollo del protocolo se mantuvo activo con 30 pull requests enviados entre el 9 y el 22 de diciembre (10 fusionados), incluyendo reescrituras de NIP-46 para usar solo cifrado NIP-44 y trabajo continuo en NIP-104 para cifrado double ratchet al nivel de Signal. Las estadísticas de red mostraron más de 224,000 eventos diarios de pubkeys confiables, crecimiento de 4x año tras año en nuevos perfiles con listas de contactos, y un aumento del 50% en eventos de escritura pública.

Diciembre 2025: Expansión del Ecosistema

Diciembre de 2025 trajo maduración continua del protocolo y expansión del ecosistema. El 21 de diciembre, OpenSats anunció su decimocuarta oleada de grants de Nostr, financiando tres proyectos: YakiHonne (un cliente multiplataforma con portal de creadores para contenido de formato largo e integración de pagos Cashu/Nutzaps), Quartz (biblioteca Kotlin Multiplatform de Vitor Pamplona que impulsa Amethyst y permitirá una versión iOS), y Nostr Feedz (integración bidireccional RSS-a-Nostr por PlebOne). Las renovaciones de grants fueron para Dart NDK y nostr-relay de Mattn.

La evolución del protocolo continuó con NIP-BE (mensajería Bluetooth Low Energy, #1979) fusionado en noviembre, habilitando sincronización offline de dispositivos. NIP-A4 (Mensajes Públicos, kind 24, #1988) llegó más tarde en el mes, definiendo mensajes de pantalla de notificación que usan tags q para evitar complicaciones de threading. NIP-29 recibió clarificación mayor (#2106), introduciendo el tag hidden para grupos verdaderamente privados e invisibles. La especificación de NIP-55 también vio refinamiento (#2166), abordando un error común de implementación donde los desarrolladores llamaban get_public_key desde procesos en segundo plano.

En el lado del cliente, Primal Android se convirtió en un signer NIP-55 completo a través de ocho PRs fusionados implementando LocalSignerContentProvider, uniéndose a Amber y Aegis como opciones de firma en Android. La biblioteca NDK logró consultas de caché 162x más rápidas (de ~3,690ms a ~22ms) eliminando escrituras duplicadas y búsquedas innecesarias de caché LRU (PR #371, PR #372). Shopstr introdujo Zapsnags para ventas flash vía zaps. White Noise envió notificaciones push que preservan la privacidad con MIP-05. Consulta Newsletter #1 y Newsletter #2 para cobertura completa.

Hace cinco años, fiatjaf lanzó Branle a un puñado de usuarios a través de dos relays experimentales. Hoy, el protocolo soporta más de 140 clientes, más de 2,500 relays en 50 países, y una creciente red de confianza que vincula cientos de miles de keypairs. El patrón de diciembre de lanzamientos importantes continuó este mes con mensajería Bluetooth, proliferación de signers en Android, y grants de infraestructura que señalan inversión sostenida en herramientas multiplataforma.

Noticias

Amethyst Desktop Toma Forma - El grant de Quartz de la decimocuarta oleada de OpenSats ya está produciendo resultados. PR #1625 crea un módulo completo :desktopApp para Amethyst usando Compose Multiplatform, con pantallas de inicio de sesión y feed global funcionales en Desktop JVM. La arquitectura convierte el módulo :commons a Kotlin Multiplatform con una estructura de source set limpia (commonMain, jvmAndroid, androidMain, jvmMain), permitiendo componentes de UI compartidos entre Android y escritorio mientras deja las decisiones específicas de plataforma a cada target. Esto sienta las bases para la eventual versión iOS a través del mismo enfoque Kotlin Multiplatform.

Amethyst Respuestas de Voz - Una entrega navideña de davotoula: PR #1622 añade pantallas dedicadas de respuesta de voz con visualización de forma de onda, soporte para re-grabar, selección de servidor de medios, e indicadores de progreso de carga. Los usuarios ahora pueden responder tanto a mensajes de voz raíz como a respuestas de voz con audio.

Notedeck Añade Mensajería - Notedeck, el cliente de escritorio de Damus, ganó una función de mensajes en PR #1223, expandiéndose más allá de la navegación del timeline hacia comunicación directa.

Citrine Aloja Aplicaciones Web - Citrine ahora puede alojar aplicaciones web, convirtiendo tu teléfono en un servidor web Nostr local-first. Un PR #85 separado añade reconexión automática y broadcasting de eventos cuando la conectividad de red regresa, con cobertura de pruebas completa a través de niveles de API de Android.

Registro de Kits de Desarrollo de Nostrability - El rastreador de Developer Kits & Tooling mantiene un registro curado de SDKs, bibliotecas y herramientas de desarrollo a través de lenguajes (TypeScript, Rust, Python, Go, Dart, Swift, y más). Si eres nuevo en el desarrollo de Nostr, este es un punto de partida útil para encontrar el toolkit adecuado para tu stack.

Actualizaciones de NIPs

Cambios recientes al repositorio de NIPs:

NIP-54 - Corrección crítica de internacionalización para normalización de d-tag wiki (#2177). Las reglas anteriores convertían todos los caracteres no ASCII a -, rompiendo el soporte para japonés, chino, árabe, cirílico y otros scripts. La especificación actualizada preserva las letras UTF-8, aplica minúsculas solo a caracteres con variantes de mayúsculas, e incluye ejemplos completos: "ウィキペディア" permanece "ウィキペディア", "Москва" se convierte en "москва", y scripts mixtos como "日本語 Article" se normalizan a "日本語-article".

Lanzamientos

Zapstore 1.0-rc1 - La tienda de aplicaciones sin permisos basada en Nostr envía el primer release candidate de su nueva arquitectura, presentando una actualización completa de UI, gestor de paquetes reescrito con mejor manejo de errores, App Stacks para descubrimiento curado, pantallas de perfil rediseñadas, verificación de actualizaciones en segundo plano, y desplazamiento infinito en listas de lanzamientos.

KeyChat v1.38.1 - La aplicación de mensajería cifrada basada en MLS añade soporte UnifiedPush para notificaciones push de Android y Linux, más autenticación biométrica para operaciones de privacidad. Disponible para Android, Windows, macOS y Linux.

Alby Go v2.0.0 - El compañero de wallet Lightning móvil envía un rediseño visual con nuevo logo, paleta de colores actualizada, libreta de direcciones rediseñada, y teclado de entrada de cantidades mejorado. BTC Map ahora es accesible desde la pantalla de inicio, y las descripciones de transacciones aparecen en notificaciones.

nak v0.17.4 - La herramienta de línea de comandos Nostr de fiatjaf lanzada, siguiendo la corrección de restricción de LMDB Linux de v0.17.3 de la semana pasada.

Cambios notables de código y documentación

Pull requests abiertos y trabajo en etapa temprana que vale la pena seguir.

Damus (iOS)

NIP-19 relay hints implementa consumo de relay hints para obtención de eventos. Cuando los usuarios abren enlaces nevent, nprofile, o naddr, Damus ahora extrae relay hints de los datos TLV bech32 y se conecta a relays efímeros para obtener contenido que no está en el pool de relays del usuario. La implementación incluye limpieza con conteo de referencias para prevenir condiciones de carrera durante búsquedas concurrentes. Detección de URL de imagen convierte automáticamente URLs de imagen pegadas en miniaturas de vista previa en el compositor, con insignia de posición de carrusel para múltiples imágenes. Conversión de pegado npub transforma strings npub/nprofile pegados en enlaces de mención con resolución de perfil asíncrona.

Amethyst (Android)

Payment targets añade una interfaz de evento para splits de zap NIP-57, permitiendo que las publicaciones especifiquen múltiples destinatarios que comparten zaps entrantes (útil para colaboraciones, reparto de ingresos, o dar propinas tanto a creadores de contenido como a las herramientas que usan). Documentación de paridad de características de Quartz añade una tabla detallada que rastrea qué características están implementadas a través de los targets Android, Desktop JVM, e iOS, notando que iOS carece de criptografía central (Secp256k1Instance), serialización JSON, y estructuras de datos.

Notedeck (Desktop)

Reconstrucción de filtro de timeline corrige un bug donde las cuentas dejadas de seguir seguían apareciendo en feeds. Los filtros de timeline se construían una vez desde la lista de contactos y nunca se actualizaban; la corrección añade rastreo de contact_list_timestamp y un método invalidate() para activar reconstrucciones cuando cambia el estado de seguimiento.

Citrine (Android Relay)

ContentProvider API expone la base de datos de eventos del relay local a otras apps Android vía ContentResolver. A diferencia de la interfaz WebSocket (que requiere que las apps mantengan una conexión persistente y hablen el protocolo relay de Nostr), ContentProvider ofrece acceso directo síncrono a la base de datos a través del mecanismo IPC nativo de Android. Las apps externas pueden consultar eventos por ID, pubkey, kind, o rango de fechas, insertar nuevos eventos con validación, y eliminar eventos sin gestionar conexiones de socket.

rust-nostr (Library)

Soporte de NIP-40 a nivel de relay añade manejo de expiración a nivel del relay builder. Los eventos expirados ahora son rechazados antes del almacenamiento y filtrados antes de enviar a clientes, eliminando la necesidad de que cada implementación de base de datos maneje verificaciones de expiración independientemente.

nak (CLI)

Blossom mirror implementa funcionalidad de mirroring de blobs para la herramienta de línea de comandos.

Mostro (P2P Trading)

Dev fee audit events añade pistas de auditoría transparentes para pagos al fondo de desarrollo a través de eventos Nostr kind 8383. La implementación publica eventos de auditoría no bloqueantes después de pagos de fees exitosos, incluyendo detalles de orden y hashes de pago mientras excluye pubkeys de comprador/vendedor por privacidad.

MDK (Marmot Development Kit)

Tres correcciones de auditoría de seguridad llegaron: Verificación de autor obliga a que los pubkeys de rumor coincidan con las credenciales del remitente MLS, previniendo ataques de suplantación. KeyPackage identity binding verifica que la identidad de credencial coincida con los firmantes de eventos. Validación de actualización de admin previene sets de admin vacíos y asignaciones de admin a no miembros.

Shopstr (Marketplace)

HODL invoice escrow implementa un sistema de pago que minimiza la confianza para bienes físicos. La arquitectura usa makeHoldInvoice de Alby para bloquear fondos del comprador en su propia wallet, con liquidación activada solo después de la verificación de inventario del comerciante. El protocolo de handshake fluye a través de DMs cifrados NIP-17: el comprador envía solicitud de orden, el comerciante responde con HODL invoice, el comprador paga (fondos bloqueados), el comerciante confirma stock y envío, luego la liquidación libera los fondos. El soporte de carrito multi-comerciante divide pagos entre vendedores.

Jumble (Web Client)

Modo de descubrimiento por relay añade un toggle para ocultar publicaciones de usuarios seguidos en relays específicos, habilitando feeds de descubrimiento basados en idioma (ej., nostr.band/lang/*). La característica filtra publicaciones donde el pubkey del autor aparece en la lista de seguidos del usuario, persistiendo el estado del toggle por URL de relay en localStorage.

White Noise (Encrypted Messaging)

Reintento de carga de medios añade opciones de reintento para cargas fallidas. Advertencias de edición de perfil alerta a usuarios sobre cambios de perfil. En el backend, whitenoise-rs corrige una condición de carrera en la creación de AccountGroup.

npub.cash (Lightning Address Service)

Reescritura v3 migra a Bun para el monorepo y servidor, añade soporte SQLite, elimina compatibilidad v1, implementa LUD-21, y añade actualizaciones de mint quote en tiempo real.

nostr-java (Library)

v1.1.1 envía refactorizaciones de manejo de WebSocket y robustez de pruebas mejorada a través de dos PRs.

NIPs Repository

Migración de NIP-54 a Djot propone un cambio separado a la especificación wiki: cambiar el formato de contenido de Asciidoc a Djot, un lenguaje de marcado ligero con sintaxis más limpia. El PR introduce enlaces de estilo referencia para wikilinks, haciendo las referencias cruzadas entre artículos wiki más legibles en forma de fuente. NIP-XX Quorum introduce gobernanza de multi-firma umbral para grupos Nostr usando FROST (Flexible Round-Optimized Schnorr Threshold signatures). Un Quorum es un nsec compartido entre miembros a través de un esquema T-de-N donde los miembros pueden representarse a sí mismos o delegar a un consejo de representantes. Cuando el consejo cambia, el viejo nsec queda obsoleto y uno nuevo es distribuido—el acto final de cualquier consejo es firmar el evento de transición de gobernanza. La especificación define membresía (pública o privada), elecciones y encuestas (votos populares, votos de no confianza), “leyes” opcionales en lenguaje natural, y crucialmente, ontologías de quorum donde los quorums pueden ser miembros de otros quorums, habilitando estructuras jerárquicas como localidades uniéndose a cuerpos regionales. Los casos de uso abarcan desarrollo de código fuente, juntas directivas de empresas, HOAs, y comunidades moderadas.

Eso es todo por esta semana y este año. ¿Construyendo algo? ¿Tienes noticias para compartir? ¿Quieres que cubramos tu proyecto? Contáctanos vía NIP-17 DM o encuéntranos en Nostr.

Boletines on Nostr Compass

Nostr Compass #42

Noticias principales

Holoboard añade comandos de promoción de Nostr y una aplicación para Android

fips-pub-domains prueba nombres públicos firmados para una red de malla

Marmot MDK 0.11.0 hace visibles las lagunas en el historial de las cuentas

Myco 0.8.0–0.8.1 proporciona a las aplicaciones cercanas su propia tienda de Nostr

Versiones etiquetadas

White Noise Android añade encuestas de grupo y valores predeterminados de mensajes temporales específicos para cada cuenta

nostream 3.1.0 ajusta la prueba de trabajo del relay en función de la carga

Nostr double ratchet 0.0.171–0.0.172 cierra una brecha relacionada con los miembros eliminados

Scramble 0.7.4–0.7.5 recupera los mensajes que debería ver un nuevo miembro del grupo

Amber 6.6.6 corrige los secretos de conexión del firmante remoto

FIPS 0.5.2 detiene una filtración de privacidad en el descubrimiento mediante Nostr

napplet soyLI 0.23.1–0.23.4 corrige la publicación del backend y la aprobación del firmante

Dart NDK 0.10.0 delimita la autorización de Blossom y la firma remota

Mostro Core 0.16.0 elimina el antiguo transporte gift-wrap

Cambium 0.6.0–0.7.1 registra un teléfono de desbloqueo mediante mensajes de relay

Bray 3.5.0–3.5.2 limita el gasto del monedero de Nostr iniciado por agentes

Mafrend 1.3.0-alpha migra los grupos privados del mapa a la versión actual de Marmot

Sonar alpha.15–alpha.15.1 corrige la publicación en grupos cifrados

Los paquetes de comercio de Elisym introducen pedidos privados en Nostr

Flotilla 1.11.2 resuelve bloqueos con firmantes y feeds incompletos de relays

Ditto 2.42.3 muestra la entrega a relays y refuerza los límites entre cuentas

Iris Chat 2026.9.24.4 incorpora llamadas a las conversaciones cifradas

LibreNostr 0.6.0–0.7.0 enruta los relays a través de Tor integrado

Newlay 0.3.45 transmite progresivamente las consultas grandes en lugar de cerrar las conexiones

ngit-grasp 3.0.5 mantiene en marcha los envíos de Git y la sincronización con relays

Armada 0.63.0 ofrece alertas push para distintos tipos de firmantes

deed 0.3.0–0.3.2 hace más estable la publicación en Nostr con Zig

Cordn 0.5.1 mantiene en marcha los demás grupos cuando falla un coordinador

Nymbot 1.0.7 añade el procesamiento local de documentos y el uso compartido cifrado de conversaciones

0xchat 1.5.6 incorpora sus correcciones de firma y autenticación de mensajes

Nostr Mail Client 0.17.0 oculta las acciones del buzón a los relays

Nostr WoT 0.8.7 vincula la autenticación al destino

El entorno de ejecución compartido de Iris mantiene coherentes los historiales de relays y pares

Chama propaga la cancelación de anuncios y las alertas en segundo plano

Earthly 0.1.12 añade configuraciones de mapas reutilizables

Mostro 0.19.0 retira su transporte de primera generación

SCRUTINY Lens lleva la investigación de seguridad a Nostr

Mangatsu y Noteds llegan a Android

Statim combina los mensajes directos de Nostr con otras redes

En desarrollo

Amethyst corrige la interoperabilidad de los grupos cifrados

Divine añade vídeo cifrado a los mensajes directos

Buzz amplía los controles de canales e identidad de su relay

Conduit hace avanzar el proceso de compra tras la aceptación del relay

Elisym desarrolla un proceso de compra para el comercio en Nostr

nostter mejora las comprobaciones de firmantes y la recuperación de events

Pensieve prepara la conciliación aislada de archivos

ContextVM evita llamadas duplicadas entre relays

Cyberspace revisa las reglas de objetos de DECK-0003

Wisp corrige las respuestas a comentarios de Nostr

Cordn envía las ubicaciones de los coordinadores a un segundo dispositivo

Nostr Atlas abre un directorio de identidades verificables

nostr-java añade herramientas de alojamiento multimedia y conserva las posiciones de los tags

Zap Cooking cambia la forma de recuperar el historial de una cuenta

Opal lleva la firma remota a Omarchy

WatchTower abre un panel de control de relays NIP-86

Hubstr Blossom abre un servidor de origen personal para contenido multimedia

Meshstr experimenta con una malla de relays sin permisos

Dossier muestra lo que puede revelar un historial público de Nostr

Marmot MDK amplía las encuestas, los emojis personalizados y los metadatos de cuenta

rust-nostr correlaciona las respuestas de recuento de los relays

ZapTracker añade métricas de la red Nostr y de citas

LaWallet NWC dirige las recargas de tarjetas a la billetera de la tarjeta

Un nuevo relay khatru expone controles de moderación para el propietario

Un constructor local de redes de confianza registra a quién se deja de seguir

Moyu presenta un cliente de espacio de trabajo basado en Marmot

Trabajo en protocolos y especificaciones

NIP-39 amplía las pruebas de identidad a Bluesky y Discord

NIP-86 añade la gestión de códigos de invitación para administradores de relays

NIP-51 traslada los conjuntos de seguimiento favoritos a un kind de event sin usar

NIP-51 propone respuestas ocultas para cada hilo

NIP-DB propone nombres de dominio verificados para servicios direccionados por clave

Un borrador de feeds privados explora grupos cifrados de destinatarios

Una propuesta de Blossom permite a otras personas anunciar copias de contenido multimedia

Los informes de incidencias viales buscan un formato compartido en Nostr

Marmot revisa la coordinación entre múltiples dispositivos

Seis años de septiembres de Nostr