Boletines on Nostr Compass

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.

Nostr Compass #2

Wed, 24 Dec 2025 00:00:00 +0000

Bienvenido de nuevo a Nostr Compass, tu guía semanal del ecosistema del protocolo Nostr.

Esta semana: Tres implementaciones de firmadores NIP-55 reciben actualizaciones: Amber añade caché de rendimiento, Aegis obtiene soporte para URI nostrsigner:, y Primal Android se une a ellos como firmador local completo. Shopstr introduce “Zapsnags” para ventas flash vía zaps. Mostro añade un fondo de desarrollo. Cuatro actualizaciones de NIP aterrizan incluyendo Mensajes Públicos (kind 24) y mejoras de privacidad de grupos. Las consultas de caché de NDK se aceleran 162x, Applesauce añade reacciones y soporte de billetera NIP-60, y Tenex introduce arquitectura RAL para delegación de agentes IA. En nuestra profundización, explicamos NIP-02 (listas de seguidos) y NIP-10 (hilos de respuestas), especificaciones fundamentales para construir líneas de tiempo sociales y conversaciones.

Noticias

Primal Android Se Convierte en Firmador NIP-55 - Construyendo sobre el soporte de Nostr Connect de la semana pasada, Primal ha implementado capacidades completas de firma local a través de ocho pull requests fusionados. La implementación incluye un LocalSignerContentProvider completo que expone operaciones de firma a otras apps Android vía la interfaz de content provider de Android, siguiendo la especificación NIP-55. La arquitectura separa responsabilidades limpiamente: SignerActivity maneja flujos de aprobación cara al usuario, LocalSignerService gestiona operaciones en segundo plano, y un nuevo sistema de permisos permite a los usuarios controlar qué apps pueden solicitar firmas. Esto hace de Primal una alternativa viable a Amber para usuarios de Android que quieren mantener sus claves en una app mientras usan otras para diferentes experiencias Nostr.

Shopstr Zapsnags: Ventas Flash vía Lightning - El mercado nativo de Nostr introdujo “Zapsnags”, una función de venta flash que permite a los compradores adquirir artículos directamente desde su feed social con un solo zap. La implementación filtra notas kind 1 etiquetadas con #shopstr-zapsnag y las renderiza como tarjetas de producto con un botón “Zap para Comprar” en lugar del flujo de carrito estándar. Cuando un comprador zapea, el sistema genera una solicitud de pago usando NIP-57, consulta el recibo de zap kind 9735 para confirmar el pago, luego encripta la información de envío usando gift wrapping NIP-17 antes de enviarla de forma privada al vendedor. La función almacena detalles del comprador localmente para compras repetidas e incluye un panel de comerciante para crear listados de venta flash. Es una combinación inteligente de primitivos sociales, de pago y privacidad que demuestra cómo el diseño componible de Nostr permite patrones de comercio novedosos.

Mostro Introduce Fondo de Desarrollo - La plataforma de trading P2P de Bitcoin NIP-69 implementó tarifas de desarrollo configurables para apoyar el mantenimiento sostenible. Los operadores pueden establecer dev_fee_percentage entre 10-100% de la tarifa de trading de Mostro (por defecto 30%), que se enruta automáticamente a un fondo de desarrollo en cada operación exitosa. La implementación añade tres columnas de base de datos (dev_fee, dev_fee_paid, dev_fee_payment_hash) para rastrear contribuciones y valida el porcentaje al inicio del daemon. La documentación técnica en docs/DEV_FEE.md explica el sistema. Este modelo opt-in permite a los operadores apoyar el desarrollo continuo mientras mantienen total transparencia sobre la asignación de tarifas.

Actualizaciones de NIP

Cambios recientes al repositorio de NIPs:

Nuevos NIPs:

NIP-A4 (Mensajes Públicos, kind 24) - Un nuevo kind para mensajes de pantalla de notificación diseñados para amplio soporte de clientes (#1988). A diferencia de conversaciones con hilos, estos mensajes no tienen concepto de historial de chat o cadenas de mensajes. Usan etiquetas q (citas) en lugar de etiquetas e para evitar complicaciones de hilos, haciéndolos ideales para notificaciones públicas simples que aparecen en el feed de notificaciones de un destinatario sin crear estado de conversación.

Cambios Significativos:

NIP-29 - Clarificación mayor de semántica de grupos (#2106). La etiqueta closed ahora significa “incapaz de escribir” (solo lectura para no miembros), desacoplada de la mecánica de unirse. Una nueva etiqueta hidden previene que los relays sirvan metadata o eventos de miembros a no miembros, permitiendo grupos verdaderamente privados que son indescubribles sin invitación fuera de banda. La etiqueta private controla visibilidad de mensajes mientras permite metadata pública para descubrimiento.
NIP-51 - Añadido kind 30006 para conjuntos de imágenes curadas (#2170), siguiendo el patrón de 30004 (artículos) y 30005 (videos). Ya implementado en Nostria.
NIP-55 - Clarificado inicio de conexión para firmadores Android (#2166). Los desarrolladores implementando sesiones multi-usuario estaban usando mal get_public_key llamándolo desde procesos en segundo plano. La especificación actualizada recomienda llamarlo solo una vez durante la conexión inicial, previniendo un footgun de implementación común.

Profundización en NIP: NIP-02 y NIP-10

Esta semana cubrimos dos NIPs esenciales para funcionalidad social: cómo los clientes saben a quién sigues y cómo se estructuran las conversaciones en hilos.

NIP-02: Lista de Seguidos

NIP-02 define eventos kind 3, que almacenan tu lista de seguidos. Este mecanismo simple potencia el grafo social que hace posibles las líneas de tiempo.

Estructura: Un evento kind 3 contiene etiquetas p listando pubkeys seguidas:

{
 "id": "d7a8f...",
 "pubkey": "a3b9c...",
 "created_at": 1734912000,
 "kind": 3,
 "tags": [
 ["p", "91cf9..af5f", "wss://alicerelay.example.com", "alice"],
 ["p", "14aeb..8dad", "wss://bobrelay.example.com", "bob"],
 ["p", "612ae..982b", "", ""]
 ],
 "content": "",
 "sig": "e4f8a..."
}

Cada etiqueta p tiene cuatro posiciones: el nombre de la etiqueta, la pubkey seguida (hex), un hint de relay URL opcional, y un “petname” opcional (un apodo local). El hint de relay dice a otros clientes dónde encontrar los eventos de ese usuario. El petname te permite asignar nombres memorables a contactos sin depender de sus nombres de pantalla auto-declarados.

Comportamiento reemplazable: Kind 3 cae en el rango reemplazable (0, 3, 10000-19999), así que los relays mantienen solo la versión más reciente por pubkey. Cuando sigues a alguien nuevo, tu cliente publica un nuevo kind 3 completo conteniendo todos tus seguidos más el nuevo. Esto significa que las listas de seguidos deben ser completas cada vez; no puedes publicar actualizaciones incrementales.

Construyendo líneas de tiempo: Para construir un feed home, los clientes obtienen el kind 3 del usuario, extraen todas las pubkeys de etiquetas p, luego se suscriben a eventos kind 1 de esos autores:

["REQ", "home", {"kinds": [1], "authors": ["91cf9...", "14aeb...", "612ae..."], "limit": 50}]

El relay devuelve notas coincidentes, y el cliente las renderiza. Los hints de relay en kind 3 ayudan a los clientes a saber qué relays consultar para cada usuario seguido.

Petnames e identidad: El campo petname habilita un esquema de nombres descentralizado. En lugar de confiar en cualquier nombre que un usuario reclame en su perfil, puedes asignar tu propia etiqueta. Un cliente podría mostrar “alice (Mi Hermana)” donde “alice” viene de su perfil kind 0 y “Mi Hermana” es tu petname. Esto proporciona contexto que los nombres de usuario globales no pueden.

Consideraciones prácticas: Debido a que los eventos kind 3 son reemplazables y deben ser completos, los clientes deberían preservar etiquetas desconocidas al actualizar. Si otro cliente añadió etiquetas que tu cliente no entiende, sobrescribir ciegamente perdería esos datos. Añade nuevos seguidos en lugar de reconstruir desde cero.

NIP-10: Hilos de Notas de Texto

NIP-10 especifica cómo las notas kind 1 se referencian entre sí para formar hilos de respuestas. Entender esto es esencial para construir vistas de conversación.

El problema: Cuando alguien responde a una nota, los clientes necesitan saber: ¿A qué es esto una respuesta? ¿Cuál es la raíz de la conversación? ¿A quién se debe notificar? NIP-10 responde estas preguntas a través de etiquetas e (referencias de evento) y etiquetas p (menciones de pubkey).

Etiquetas marcadas (preferidas): Los clientes modernos usan marcadores explícitos en etiquetas e:

{
 "id": "f9c2e...",
 "pubkey": "a3b9c...",
 "created_at": 1734912345,
 "kind": 1,
 "tags": [
 ["e", "abc123...", "wss://relay.example.com", "root"],
 ["e", "def456...", "wss://relay.example.com", "reply"],
 ["p", "91cf9..."],
 ["p", "14aeb..."]
 ],
 "content": "¡Buen punto! Estoy de acuerdo.",
 "sig": "b7d3f..."
}

El marcador root apunta a la nota original que inició el hilo. El marcador reply apunta a la nota específica que se está respondiendo. Si respondes directamente a la raíz, usa solo root (no se necesita etiqueta reply). La distinción importa para el renderizado: el reply determina la indentación en una vista de hilo, mientras que root agrupa todas las respuestas juntas.

Reglas de hilos:

Respuesta directa a raíz: Una etiqueta e con marcador root
Respuesta a una respuesta: Dos etiquetas e, una root y una reply
El root permanece constante a lo largo del hilo; reply cambia según a qué estés respondiendo

Etiquetas pubkey para notificaciones: Incluye etiquetas p para todos los que deberían ser notificados. Como mínimo, etiqueta al autor de la nota a la que respondes. La convención es también incluir todas las etiquetas p del evento padre (para que todos en la conversación estén al tanto), más cualquier usuario que @menciones en tu contenido.

Hints de relay: La tercera posición en etiquetas e y p puede contener una URL de relay donde ese evento o contenido de usuario podría encontrarse. Esto ayuda a los clientes a obtener el contenido referenciado incluso si no están conectados al relay original.

Etiquetas posicionales deprecadas: Las implementaciones tempranas de Nostr inferían significado de la posición de etiquetas en lugar de marcadores: la primera etiqueta e era raíz, la última era respuesta, las del medio eran menciones. Este enfoque está deprecado porque crea ambigüedad. Si ves etiquetas e sin marcadores, probablemente son de clientes antiguos. Las implementaciones modernas siempre deberían usar marcadores explícitos.

Construyendo vistas de hilo: Para mostrar un hilo, obtén el evento raíz, luego consulta todos los eventos con una etiqueta e referenciando esa raíz:

["REQ", "thread", {"kinds": [1], "#e": ["<root-event-id>"]}]

Ordena resultados por created_at y usa marcadores reply para construir la estructura de árbol. Los eventos cuyo reply apunta a la raíz son respuestas de nivel superior; los eventos cuyo reply apunta a otra respuesta son respuestas anidadas.

Lanzamientos

Zeus v0.12.0 - Construyendo sobre el soporte de pagos paralelos NWC de la semana pasada, el lanzamiento mayor de la billetera Lightning incluye un servicio completo NIP-47 Nostr Wallet Connect con soporte de relay personalizado y seguimiento de presupuesto. Una corrección de recarga de presupuesto asegura que las conexiones usen límites actuales. Copiar dirección Lightning ya no incluye el prefijo lightning:, corrigiendo problemas de pegado en campos de perfil Nostr.

Amber v4.0.6 - El firmador NIP-55 de Android añade caché de rendimiento a operaciones de firma y mejora el manejo de errores al desencriptar contenido malformado. La confiabilidad de conexión mejoró con lógica de reintentos para eventos de conexión de relay, y varias correcciones de crash abordan casos extremos alrededor de URIs nostrconnect:// inválidos e interacciones de pantalla de permisos.

nak v0.17.3 - El último lanzamiento de la herramienta de línea de comandos Nostr restringe builds LMDB a Linux, corrigiendo problemas de compilación multiplataforma.

Aegis v0.3.4 - El firmador Nostr multiplataforma añade soporte para el esquema URI nostrsigner: definido en NIP-55, coincidiendo con el flujo de conexión de Amber. Los datos de relay local ahora pueden ser importados y exportados para respaldo, y el lanzamiento incluye correcciones de errores para errores de socket de relay y mejoras de UI para la interfaz de relay local.

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 fusionarse. Si algo te llama la atención, ¡considera revisar o comentar!

Damus (iOS)

Persistencia de lista de silenciados corrige un problema donde las listas de silenciados se borraban en inicio frío. La corrección añade guardas para prevenir sobrescrituras accidentales durante la inicialización de la app. Temporización de stream de perfil elimina un retraso de ~1 segundo antes de que los perfiles en caché aparecieran. Anteriormente, las vistas esperaban a que las tareas de suscripción reiniciaran; ahora streamProfile() inmediatamente devuelve datos en caché de NostrDB, eliminando la ventana donde pubkeys abreviadas e imágenes placeholder se mostraban.

White Noise (Mensajería Encriptada)

Streaming de mensajes en tiempo real reemplaza el mecanismo de polling anterior con una arquitectura basada en streams. El nuevo ChatStreamNotifier consume el stream de mensajes del SDK Rust directamente, manteniendo orden cronológico y manejando actualizaciones incrementales eficientemente. Las pruebas mostraron mejora significativa en capacidad de respuesta. Una API de lista de chat añade get_chat_list para recuperar resúmenes de conversaciones, y una corrección de ordenamiento estable previene loops de reordenamiento de mensajes usando createdAt con ID de mensaje como desempate.

NDK (Librería)

Dos pull requests entregaron mejoras dramáticas de rendimiento de caché. PR #371 corrigió un bug donde eventos leídos de caché SQLite se escribían inmediatamente de vuelta, causando 100% de escrituras duplicadas al iniciar la app. La corrección añade una guarda fromCache e implementa verificación de duplicados O(1) vía un Set en memoria. Para conjuntos de resultados pequeños (<100 eventos), la transferencia JSON directa reemplaza la sobrecarga de codificación binaria. PR #372 eliminó llamadas innecesarias a seenEvent para eventos en caché. La búsqueda en caché LRU costaba 0.24-0.64ms por evento; para 5,700 eventos en caché, esto añadía ~1.4 segundos de sobrecarga. Resultado: las consultas de caché bajaron de ~3,690ms a ~22ms (162x más rápido).

rust-nostr (Librería)

Soporte de REQ multi-filtro fue restaurado después de ser eliminado en un refactor previo. El SDK nuevamente acepta Vec<Filter> para solicitudes de suscripción, permitiendo consultas eficientes que combinan múltiples condiciones de filtro con lógica OR. Procedencia de relay fue añadida a métodos stream_events*, así que cada evento en stream ahora incluye el RelayUrl de donde vino y un Result indicando éxito o fallo, útil para rastrear confiabilidad de relay y depurar problemas de conexión. Una corrección de seguridad eliminó la dependencia url-fork siguiendo RUSTSEC-2024-0421, eliminando una vulnerabilidad conocida.

Applesauce (Librería)

La librería TypeScript que potencia noStrudel vio desarrollo significativo esta semana. Nuevos modelos incluyen un sistema de reacciones y casting de grupos de usuarios. La funcionalidad de billetera se expandió con soporte NIP-60, una pestaña de envío, y herramientas mejoradas de recuperación de tokens. Una nueva propiedad user.directMessageRelays$ expone configuración de relay DM. Todas las acciones fueron refactorizadas para usar interfaces async (eliminando generadores async), y correcciones de bugs abordaron restauración de contenido encriptado y casos extremos de filtros de eventos basados en tiempo.

Tenex (Agentes IA)

El sistema de coordinación multi-agente construido sobre Nostr introdujo arquitectura RAL (Request-Action-Lifecycle) en cinco PRs fusionados. RAL permite a los agentes pausar cuando delegan tareas y reanudar cuando llegan resultados, con persistencia de estado en alcance de conversación. Las herramientas de delegación (delegate, ask, delegate_followup, delegate_external) ahora publican eventos Nostr y retornan señales de parada en lugar de bloquear. El refactor incluye migración a AI SDK v6, infraestructura de testing VCR para grabación determinística de interacciones LLM, y soporte de imágenes multimodal.

Eso es todo por esta semana. ¿Construyendo algo? ¿Tienes noticias para compartir? ¿Quieres que cubramos tu proyecto? Contáctanos vía NIP-17 DM o encuéntranos en Nostr.

Nostr Compass #1

Mon, 15 Dec 2025 00:00:00 +0000

Bienvenido a Nostr Compass, un boletín semanal dedicado al ecosistema del protocolo Nostr. Nuestra misión es mantener informados a desarrolladores, operadores de relays y constructores sobre desarrollos importantes en toda la red. Documentamos la evolución del protocolo con precisión técnica, neutralidad y profundidad, cubriendo desde propuestas de NIP hasta lanzamientos de clientes y mejores prácticas de implementación.

Nostr Compass está inspirado en Bitcoin Optech, cuyo trabajo dedicado durante años avanzando el conocimiento técnico de Bitcoin estableció el estándar para boletines enfocados en protocolos. Estamos agradecidos por su ejemplo y esperamos aportar el mismo rigor al ecosistema Nostr.

Este número inaugural establece nuestro formato semanal. Cada miércoles te traeremos actualizaciones de NIP, notas de lanzamiento, destacados de desarrollo y guías técnicas. Ya sea que estés construyendo un cliente, operando un relay o contribuyendo al protocolo, Nostr Compass pretende ser tu fuente confiable sobre lo que está sucediendo en el ecosistema.

¿Qué es Nostr?

Dado que este es nuestro primer número, comenzamos con una introducción sobre cómo funciona Nostr. Los lectores habituales pueden saltar adelante.

Nostr (Notes and Other Stuff Transmitted by Relays) es un protocolo descentralizado para redes sociales y mensajería. A diferencia de las plataformas tradicionales, Nostr no tiene servidor central, ninguna empresa lo controla y no tiene un punto único de fallo. Los usuarios poseen su identidad a través de pares de claves criptográficas, y el contenido fluye a través de servidores relay independientes que cualquiera puede ejecutar.

Cómo funciona: Los usuarios generan un par de claves (una clave privada llamada nsec y una clave pública llamada npub). La clave privada firma mensajes llamados “eventos”, y la clave pública sirve como tu identidad. Los eventos se envían a relays, que los almacenan y reenvían a otros usuarios. Debido a que controlas tus claves, puedes cambiar entre clientes o relays sin perder tu identidad o seguidores.

Por qué importa: Nostr proporciona resistencia a la censura a través de la diversidad de relays (si un relay te banea, otros aún pueden servir tu contenido), portabilidad (tu identidad funciona en cualquier aplicación Nostr) e interoperabilidad (todos los clientes Nostr hablan el mismo protocolo). No hay algoritmo decidiendo qué ves, sin anuncios y sin recolección de datos.

El ecosistema hoy: Nostr soporta microblogging (como Twitter/X), contenido largo (como Medium), mensajes directos, mercados, streaming en vivo y más. Los clientes incluyen Damus (iOS), Amethyst (Android), Primal, Coracle y docenas más. La integración con Lightning Network permite pagos instantáneos a través de “zaps”. El protocolo continúa evolucionando a través de NIPs (Nostr Implementation Possibilities), especificaciones impulsadas por la comunidad que extienden la funcionalidad.

Noticias

NIP-BE Fusionado: Soporte para Bluetooth Low Energy - Una nueva capacidad significativa aterrizó en el protocolo. NIP-BE especifica cómo las aplicaciones Nostr pueden comunicarse y sincronizarse sobre Bluetooth Low Energy. Esto permite que las aplicaciones capaces de funcionar sin conexión sincronicen datos entre dispositivos cercanos sin conectividad a internet. La especificación adapta los patrones de relay WebSocket a las restricciones de BLE, usando compresión DEFLATE y mensajería fragmentada para manejar los tamaños MTU pequeños de BLE (20-256 bytes). Los dispositivos negocian roles basándose en la comparación de UUID, con el UUID más alto convirtiéndose en el servidor GATT.

MIP-05: Notificaciones Push que Preservan la Privacidad - El Protocolo Marmot publicó MIP-05 (especificación), una especificación para notificaciones push que mantienen la privacidad. Los sistemas push tradicionales requieren que los servidores conozcan los tokens de dispositivo e identidades de usuario; MIP-05 resuelve esto encriptando tokens de dispositivo con ECDH+HKDF y ChaCha20-Poly1305, usando claves efímeras para prevenir la correlación. Un protocolo gossip de tres eventos (kinds 447-449) sincroniza tokens encriptados entre miembros del grupo, y las notificaciones usan gift wrapping de NIP-59 con tokens señuelo para ocultar tamaños de grupo. Esto permite a WhiteNoise y otros clientes Marmot entregar notificaciones oportunas sin comprometer la privacidad del usuario.

Blossom BUD-10: Nuevo Esquema URI - El protocolo de medios Blossom está obteniendo un esquema URI personalizado vía BUD-10 (especificación). El nuevo formato blossom:<sha256>.ext incorpora hash de archivo, extensión, tamaño, múltiples hints de servidor y pubkeys de autor para descubrimiento de servidor BUD-03. Esto hace que los enlaces de blob sean más resilientes que las URLs HTTP estáticas al permitir fallback automático entre servidores.

Actualizaciones del Mercado Shopstr - El mercado nativo de Nostr implementó Nostr Wallet Connect (NIP-47) para pagos, añadió expiración de listados usando NIP-40, e introdujo códigos de descuento para vendedores.

Actualizaciones de NIP

Cambios recientes al repositorio de NIPs:

Nuevos NIPs:

NIP-BE - Mensajería Bluetooth Low Energy y sincronización de dispositivos (#1979)
NIP-63 - Estándar de Paywall/Contenido Premium para manejar contenido con acceso restringido dentro del protocolo (#2156)

Cambios Significativos:

NIP-24 - Añadido array opcional languages a metadatos de usuario Kind 0, permitiendo a los usuarios especificar múltiples idiomas preferidos usando etiquetas IETF BCP 47 para mejor descubrimiento de contenido y coincidencia de relay (#2159)
NIP-69 - Añadido soporte de expiración de órdenes para trading P2P con etiquetas expires_at y expiration (#2118)
NIP-59 - Los eventos gift wrap ahora pueden ser eliminados vía solicitudes NIP-09/NIP-62 (#2131)
NIP-51 - Eliminadas etiquetas de hashtag y URL de marcadores genéricos; hashtags ahora usan kind 30015 (#2133)
NIP-18 - Mejorados los reposts genéricos para eventos reemplazables con soporte de etiqueta a (#2132)
NIP-17 - Redacción refinada y añadido soporte de reacción kind 7 a DMs (#2098)
NIP-11 - Añadido campo self para identificación de clave pública del relay (#1764)

Profundización en NIP: NIP-01 y NIP-19

Para este número inaugural, cubrimos dos NIPs fundamentales que todo desarrollador de Nostr debería entender. Consulta nuestras páginas de temas para NIP-01 y NIP-19.

NIP-01: Protocolo Básico

NIP-01 define el protocolo central. Todo en Nostr se construye sobre esta especificación.

Los eventos son el único tipo de objeto. Cada evento contiene:

id: Hash SHA256 del evento serializado (el identificador único del evento)
pubkey: La clave pública del creador (hex de 32 bytes, secp256k1)
created_at: Marca de tiempo Unix
kind: Entero que categoriza el tipo de evento
tags: Array de arrays para metadatos
content: La carga útil (la interpretación depende del kind)
sig: Firma Schnorr probando que la pubkey creó este evento

Los kinds determinan cómo los relays almacenan eventos:

Eventos regulares (1, 2, 4-44, 1000-9999): Almacenados normalmente, todas las versiones se mantienen
Eventos reemplazables (0, 3, 10000-19999): Solo se mantiene el más reciente por pubkey
Eventos efímeros (20000-29999): No almacenados, solo reenviados a suscriptores
Eventos direccionables (30000-39999): Más reciente por combinación de pubkey + kind + etiqueta d

Kind 0 son metadatos de usuario (perfil), kind 1 es una nota de texto (la publicación básica), kind 3 es la lista de seguidos.

Kind 1: Notas de Texto son el corazón del Nostr social. Un evento kind 1 es una publicación corta, similar a un tweet. El campo content contiene el texto del mensaje (texto plano, aunque los clientes a menudo renderizan markdown). Las etiquetas permiten respuestas, menciones y referencias:

{
 "id": "<32-byte-hex>",
 "pubkey": "<32-byte-hex>",
 "created_at": 1734480000,
 "kind": 1,
 "content": "¡Hola Nostr! Mira el trabajo de @jb55 en Damus.",
 "tags": [
 ["e", "<replied-to-event-id>", "wss://relay.example.com", "reply"],
 ["p", "<jb55-pubkey>"]
 ],
 "sig": "<64-byte-hex>"
}

La etiqueta e con marcador “reply” indica que esto es una respuesta (ver NIP-10 para convenciones de hilos). La etiqueta p menciona a un usuario, permitiendo a los clientes notificarle y renderizar su nombre en lugar de la pubkey cruda. Los clientes obtienen el evento kind 0 del usuario mencionado para obtener su nombre de pantalla e imagen.

Para construir una línea de tiempo, un cliente se suscribe a eventos kind 1 de pubkeys seguidas: ["REQ", "feed", {"kinds": [1], "authors": ["<pubkey1>", "<pubkey2>", ...], "limit": 50}]. El relay devuelve notas coincidentes, y el cliente las renderiza cronológicamente.

Los eventos direccionables (30000-39999) funcionan como eventos reemplazables pero usan una etiqueta d como identificador adicional. El relay mantiene solo la última versión de cada combinación pubkey + kind + d-tag. Esto permite artículos editables, listados de productos, o cualquier caso donde necesites múltiples elementos reemplazables por usuario.

Las etiquetas son arrays donde el primer elemento es el nombre de la etiqueta. Las etiquetas estándar de una sola letra (e, p, a, d, t) son indexadas por relays para consultas eficientes. Por ejemplo, ["e", "<event-id>"] referencia otro evento, ["p", "<pubkey>"] referencia un usuario.

Comunicación Cliente-Relay usa conexiones WebSocket con arrays JSON como mensajes. El primer elemento identifica el tipo de mensaje.

De cliente a relay:

["EVENT", <event>] - Publica un evento al relay
["REQ", <sub-id>, <filter>, ...] - Suscribirse a eventos que coincidan con el/los filtro(s)
["CLOSE", <sub-id>] - Terminar una suscripción

De relay a cliente:

["EVENT", <sub-id>, <event>] - Entrega un evento que coincide con tu suscripción
["EOSE", <sub-id>] - “Fin de eventos almacenados” - el relay ha enviado todos los coincidentes históricos y ahora solo enviará nuevos eventos conforme lleguen
["OK", <event-id>, <true|false>, <message>] - Reconoce si un evento fue aceptado o rechazado (y por qué)
["NOTICE", <message>] - Mensaje legible por humanos del relay

El flujo de suscripción: el cliente envía REQ con un ID de suscripción y filtro, el relay responde con mensajes EVENT coincidentes, luego envía EOSE para señalar que está al día con el historial. Después de EOSE, cualquier nuevo mensaje EVENT es en tiempo real. El cliente envía CLOSE cuando termina.

Los filtros especifican qué eventos recuperar. Un objeto filtro puede incluir: ids (IDs de evento), authors (pubkeys), kinds (tipos de evento), #e/#p/#t (valores de etiqueta), since/until (marcas de tiempo), y limit (máximo de resultados). Todas las condiciones dentro de un filtro usan lógica AND. Puedes incluir múltiples filtros en un REQ, y se combinan con lógica OR - útil para obtener diferentes tipos de evento en una suscripción.

NIP-19: Identificadores Codificados en Bech32

NIP-19 define los formatos amigables para humanos que ves en todas partes en Nostr: npub, nsec, note, y más. Estos no se usan en el protocolo mismo (que usa hex), pero son esenciales para compartir y mostrar.

¿Por qué bech32? Las claves hex crudas son propensas a errores al copiar y difíciles de distinguir visualmente. La codificación bech32 añade un prefijo legible y suma de verificación. Puedes distinguir inmediatamente un npub (clave pública) de un nsec (clave privada) o note (ID de evento).

Formatos básicos codifican valores crudos de 32 bytes:

npub - Clave pública (tu identidad, segura para compartir)
nsec - Clave privada (mantener en secreto, usada para firmar)
note - ID de evento (referencia un evento específico)

Ejemplo: La pubkey hex 3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d se convierte en npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6.

Identificadores compartibles incluyen metadatos usando codificación TLV (Type-Length-Value):

nprofile - Perfil con hints de relay (ayuda a los clientes a encontrar al usuario)
nevent - Evento con hints de relay, pubkey de autor y kind
naddr - Referencia de evento direccionable (pubkey + kind + d-tag + relays)

Estos resuelven un problema clave: si alguien comparte un ID de nota, ¿cómo sabes qué relay lo tiene? Un nevent agrupa el ID de evento con relays sugeridos, haciendo más confiable compartir.

Importante: Nunca uses formatos bech32 en el protocolo mismo. Los eventos, mensajes de relay y respuestas NIP-05 deben usar hex. Bech32 es puramente para interfaces humanas: visualización, copiar/pegar, códigos QR y URLs.

Lanzamientos

Amber v4.0.4 - La aplicación firmadora de Android corrige un NullPointerException, mejora el rendimiento en la pantalla de actividad y añade traducciones para algunos tipos de evento. El lanzamiento anterior v4.0.3 añadió UI renovada de encriptación/desencriptación, exportación/importación de cuentas, manejo de relay por cuenta, soporte de ping bunker y reporte de errores. Lanzamiento

Coracle 0.6.28 - Lanzamiento de corrección de errores para el cliente web. Corregidos feeds de temas, manejo de imágenes cuando imgproxy está deshabilitado, y linkificación de fuentes de resaltado que no son enlaces. Lanzamiento

Flotilla v1.6.2 - El cliente de comunidades estilo Discord corrige scroll modal y problemas de estilo. Lanzamientos anteriores en este ciclo añadieron insignias y sonidos opcionales para notificaciones, renderizado de enlaces mejorado, escaneo de códigos QR para enlaces de invitación, y configuración simplificada de billetera. Lanzamiento

nak v0.17.2 - La herramienta de línea de comandos Nostr añadió un nuevo comando nip para búsqueda rápida de referencia NIP, más correcciones para manejo de repositorio git y procesamiento de eventos stdin. Lanzamiento

White Noise v0.2.1 - Lanzamiento mayor para la aplicación de mensajería encriptada basada en MLS añadiendo compartir imágenes vía Blossom, sincronización en segundo plano, notificaciones push, localización en 8 idiomas, y gestión de miembros de grupo. Lanzamiento

Amethyst v1.04.2 - Lanzamiento con nuevas características introduciendo listas/packs de seguidos, nuevos filtros de línea de tiempo, galería de imágenes, y compresión de video H.265 (archivos 50% más pequeños). Migración completa a Kotlin Multiplatform. Lanzamiento

Mostro v0.15.5 - Actualización de la plataforma de trading P2P con soporte de expiración de órdenes NIP-69 y respuestas mejoradas de historial de operaciones. Lanzamiento

Nosflare v8.9.26 - Relay Nostr serverless construido en infraestructura Cloudflare. Este lanzamiento entrega un hotfix crítico que aborda un error que podía causar fallos de websocket, asegurando conexiones más estables para usuarios y aplicaciones que dependen del relay. Lanzamiento

Noscall v0.4.1 - Aplicación de llamadas de audio y video seguras basada en Nostr. Este lanzamiento mejora la UI pop-up en la página Me y corrige varios problemas conocidos, resultando en mejor estabilidad y confiabilidad de llamadas. Lanzamiento

Gitplaza v0.25.0 - Cliente de escritorio Nostr enfocado en actividad relacionada con Git. Este lanzamiento introduce un filtro de kind avanzado para el feed del inbox, incluye zaps regulares en filtros, y simplifica el formato de texto de pestañas. Las mejoras de rendimiento optimizan la carga del árbol de comentarios, reducen consultas innecesarias a base de datos, y usan ramas de comentarios en caché para visualización más rápida. Lanzamiento

Cambios notables de código y documentación

Damus (iOS)

Enfoque en estabilidad con correcciones de crashes y UI: corrección de salto de cursor para la vista de composición, rediseño de interfaz NostrDB usando tipos ~Copyable de Swift para seguridad de transacciones, estabilidad de UI de hilos corrigiendo reinstanciación de barra de acciones, congelación de lista de silenciados por ciclos de AttributeGraph, y crash de perfil por limpieza de transacciones entre hilos. También añadió directrices AGENTS.md para agentes de código IA.

Notedeck (Escritorio/Móvil)

Almacenamiento seguro de claves mueve nsec al almacén seguro del SO con migración automática. Filtrado de notas futuras oculta eventos fechados 24+ horas adelante (anti-spam). Copia de nevent ahora incluye hints de relay. También: adición rápida de columna de perfil, navegación por teclado, optimización de carga de medios.

Amethyst (Android)

Soporte de firma remota NIP-46 para Nostr Connect. Organización de marcadores con gestión de listas públicas/privadas. Corrección de compatibilidad strfry para casos extremos de análisis de info de relay.

Primal (Android)

Deep links de Nostr Connect para URLs nostrconnect://. Inicio de sesión remoto vía escaneo QR para conexiones bunker. Corrección de condición de carrera de conexión.

White Noise (Mensajería Encriptada)

Corrección de retención de datos de app desactiva auto-backup de Android para privacidad. Comportamiento de scroll de chat preserva la posición al leer historial.

Zeus (Billetera Lightning)

Pagos paralelos NIP-47 para mayor rendimiento en zaps por lotes.

Mejores Prácticas para Desarrolladores

Valida Eventos Auth de Forma Defensiva - go-nostr corrigió un panic en validación NIP-42 cuando faltaba la etiqueta relay. Siempre verifica las etiquetas requeridas antes de acceder a ellas, incluso en flujos auth donde esperas eventos bien formados.

Limita Tasa por Estado de Autenticación - khatru añadió limitación de tasa basada en NIP-42, permitiendo a los relays aplicar diferentes límites para conexiones autenticadas vs anónimas. Considera límites escalonados basados en estado auth en lugar de restricciones generales.

Usa Paginación por Cursor para Listas - Blossom reemplazó paginación basada en fecha con paginación basada en cursor en el endpoint /list. La paginación basada en fecha falla cuando items comparten timestamps; los cursores proporcionan iteración confiable.

Validación de Esquema para Tipos de Evento - El proyecto nostrability/schemata proporciona esquemas JSON para validar eventos compatibles con NIP. Considera integrar validación de esquema en desarrollo para detectar eventos malformados antes de que lleguen a los relays.

Eso es todo por esta semana. ¿Construyendo algo? ¿Tienes noticias para compartir? ¿Quieres que cubramos tu proyecto? Contáctanos vía NIP-17 DM o encuéntranos en Nostr.