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 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 0.6.34 y 0.6.35 corrigen el login NIP-46, feeds obsoletos y el selector de respuestas

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 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.