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.