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

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

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

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

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

Historias principales

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

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

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

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

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

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

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

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

El ecosistema Iris entrega una biblioteca pubsub, un runtime FIPS para el navegador y un social-graph 2.0 en una semana

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

Releases etiquetados

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

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

Seguimiento de Nostrord v2.2.0

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

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

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

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

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

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

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

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

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

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

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

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

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

Los lanzamientos menores de la semana

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

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

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

Cambios no publicados

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

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

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

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

Mostr conecta chats privados de ActivityPub y DMs de Nostr

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

nostream fusiona ocho PRs sin cortar un release

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

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

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

Trabajo de protocolo y actualizaciones de NIPs

Cambios recientes en el repositorio de NIPs:

Fusionados:

  • NIP-29 (Relay-based Groups): Subgrupos (PR #2319, fusionado 2026-07-16): NIP-29 define grupos alojados en relays donde la membresía, los roles y el historial de chat viven en un único relay como eventos direccionables de la serie kind:39000, con acciones de moderación transportadas por eventos admin de la serie kind:9000. Este PR permite que un grupo se declare subgrupo añadiendo una etiqueta parent a sus metadatos, apuntando al identificador d de otro grupo en el mismo relay. Los subgrupos son grupos ordinarios en todo lo demás: la membresía no cascada (unirse a un padre no otorga membresía en ningún hijo), los roles de admin no se heredan (la lista de admins kind:39001 de cada subgrupo es autoritativa para su propio ámbito), y cada subgrupo mantiene sus propios eventos de miembros kind:9000/kind:9001 independientes. Los relays que soportan la jerarquía lo anuncian en su documento de información de relay NIP-11 bajo un objeto nip29 con "subgroups": true, de modo que los clientes puedan descubrir la capacidad antes de intentar crear comunidades anidadas.

  • NIP-29: Fijado de mensajes (PR #2379, fusionado 2026-07-15; PR #2416, fusionado 2026-07-17): Los admins de grupo ahora pueden fijar mensajes dentro de un grupo basado en relay. El mecanismo añade un nuevo evento de moderación, kind:9010 update-pin-list, que transporta la lista completa y ordenada de fijados como etiquetas e que referencian ids de eventos regulares, y un nuevo evento opcional a nivel de grupo, kind:39005 group pinned events, que el relay regenera para reflejar la lista de fijados aceptada más reciente. Como cada kind:9010 reemplaza la lista entera en lugar de alternar entradas individuales, fijar, desfijar, reordenar y limpiar los fijados se expresan todos enviando una lista nueva. El PR de seguimiento #2416 extiende el formato para que también se acepten etiquetas a en la lista de fijados, permitiendo a los admins fijar eventos direccionables (posts de formato largo, páginas wiki y otro contenido reemplazable parametrizado) junto a mensajes de chat ordinarios. Los relays pueden limitar el número de fijados, y el texto de la spec fusionada recomienda mostrar los fijados en el orden en que aparecen las etiquetas.

  • NIP-29: Etiqueta banner y sufijo de código de invitación (PR #2383, fusionado 2026-07-16; PR #2380, fusionado 2026-07-16): Dos adiciones de visualización e incorporación a los metadatos de grupo. El PR #2383 añade una etiqueta banner opcional al evento de metadatos de grupo kind:39000, uniéndose a los campos existentes name, picture y about para que los clientes puedan renderizar una imagen de cabecera para la página de un grupo. El PR #2380 define un sufijo de código de invitación para los enlaces de compartir de grupo: un código de invitación puede añadirse al identificador naddr del grupo como naddr1...?invite=<code>. Como el conjunto de caracteres bech32 no incluye ?, la parte anterior al sufijo sigue siendo un naddr válido por sí sola, de modo que los clientes que no entienden la extensión aún pueden resolver el grupo. Los clientes que sí la entienden pre-rellenan la etiqueta code en la solicitud de unión kind:9021, que se combina con el evento de moderación kind:9009 create-invite existente para simplificar la admisión a grupos cerrados.

  • NIP-51 (Listas): Favorite follow sets, kind:10011 (PR #2413, fusionado 2026-07-15): NIP-51 define los kinds de lista estándar, divididos entre listas reemplazables de la serie kind:10000 (una por usuario) y conjuntos direccionables de la serie kind:30000 (muchos por usuario, claveados por etiqueta d). Este PR añade kind:10011, favorite follow sets, una lista reemplazable estándar cuyas etiquetas a apuntan a follow sets kind:30000. Como espejo de kind:10012 (relay feeds), que contiene etiquetas a que referencian relay sets kind:30002, el nuevo kind permite a un usuario marcar con nombre follow sets curados —como listas curadas de colecciones de pubkeys publicadas por él mismo o por otros— y hacer que los clientes los muestren para seguir con un toque o cambiar de feed. Nótese que este número de kind ya está disputado: véase el PR de renumeración abierto más abajo.

  • NIP-46 (Nostr Connect): Guía de timeout silencioso (PR #2375, fusionado 2026-07-15): NIP-46 es el protocolo de firma remota donde un cliente envía solicitudes cifradas estilo JSON-RPC a un firmante (bunker) a través de relays y espera una respuesta cifrada. El cambio fusionado es una frase de comportamiento de wire: las solicitudes hechas con métodos desconocidos o no soportados DEBEN responderse con un error. Antes, un firmante que recibía un método que no implementaba podía no responder nunca, dejando al cliente colgado hasta que su propio timeout saltara sin forma de distinguir “método no soportado” de “firmante desconectado”. La respuesta de error obligatoria permite a los clientes fallar rápido y mostrar un mensaje significativo al usuario en lugar de girar indefinidamente.

PRs abiertos y discusiones:

  • Renumeración de kind:10011 a kind:10021 (PR #2417): Mueve la lista favorite follow sets recién fusionada de kind:10011 a kind:10021, porque 10011 ya está en uso en otra parte. El PR de renumeración se abrió a los pocos días del merge original, así que los clientes que implementen favorite follow sets deberían seguir este PR y apuntar al número final, no a 10011.

  • NIP-47 (Nostr Wallet Connect): Simplificación del núcleo (PR #2419): Propone estrechar NIP-47, el protocolo wallet-connect que permite a las apps solicitar pagos Lightning desde una billetera remota vía Nostr, en una spec de núcleo más pequeña. La funcionalidad opcional y más especializada saldría de 47.md hacia un repositorio de extensiones dedicado, nostr-wallet-connect/nwc, donde las specs de extensión pueden evolucionar independientemente del núcleo. El objetivo declarado es mantener el núcleo pequeño, estable y fácil de implementar, siguiendo la dirección acordada en llamadas anteriores de NWC de separar una capa mínima de wallet-connect de comportamientos opcionales más ricos. Dado lo ampliamente desplegado que está NIP-47 en billeteras y apps, cualquiera que hable NWC debería seguir la discusión de reestructuración.

  • Trusted Relay Assertions (borrador, sin número asignado) (PR #2418): Propone un estándar para publicar evaluaciones de confianza sobre relays Nostr, posicionado como la capa de “lo que concluimos” junto a NIP-11 (lo que un relay afirma sobre sí mismo) y NIP-66 (lo que los monitores midieron). Los proveedores de assertions calcularían puntuaciones de confianza a partir de métricas observadas, reputación del operador e informes de usuarios; los clientes consultarían estas assertions al elegir a qué relays conectarse. El borrador introduce kind:30385 (Trusted Relay Assertion direccionable, con etiquetas de puntuación, fiabilidad, calidad, accesibilidad, operador, política y jurisdicción), kind:10385 (Trusted Provider List reemplazable, los proveedores de assertions elegidos por el usuario), y reutiliza las etiquetas NIP-32 para informes de relays y operadores. Aún no se ha asignado ningún número de NIP; es un borrador en etapa temprana.

  • Operador AND para filtros (“NIP-91”, propuesto, número aún no en el repo) (PR #2252): Bajo NIP-01, los filtros de etiquetas son solo OR: un filtro "#t": ["meme", "cat"] coincide con eventos que tengan cualquiera de las dos etiquetas. Esta propuesta añade un modificador & para etiquetas indexables, de modo que "&t": ["meme", "cat"] devuelve solo eventos que lleven ambas etiquetas, permitiendo a los relays hacer la intersección del lado del servidor en lugar de que los clientes sobre-descarguen y filtren localmente. Las reglas especifican que AND tiene precedencia sobre OR, que los valores de etiqueta usados en AND deberían ignorarse en OR por los relays que lo soportan, y que los clientes DEBEN incluir también las etiquetas OR estándar # por compatibilidad con relays que no soportan la extensión (esos relays devuelven el resultado OR más amplio, que el cliente interseca localmente). El PR es una continuación reabierta de una propuesta anterior y lista implementaciones de relay, incluida una imagen docker de nostr-rs-relay, netstr y un relay worker de Snort. El número NIP-91 aparece solo en la rama del PR; todavía no está en el índice de NIPs del README del repositorio, así que trátalo como provisional.

  • Nostr web applets (“NIP-5D”, propuesto, número aún no en el repo) (PR #2303): Define un protocolo postMessage para que aplicaciones web en sandbox (“napplets”) que corren en iframes o webviews se comuniquen con una aplicación anfitriona (“shell”). La spec es deliberadamente un núcleo delgado: especifica el sobre de mensajes, reglas de sandbox (los iframes de napplet DEBEN usar sandbox="allow-scripts" sin allow-same-origin, y las shells NO DEBEN exponer window.nostr NIP-07 dentro del iframe), identificación del emisor vía la referencia de ventana infalsificable MessageEvent.source, no event.origin, y negociación de capacidades basada en manifiesto. Los mensajes de protocolo reales para firma, acceso a relays, almacenamiento y comunicación entre napplets se delegan a specs de extensión NAP (Nostr Applet Protocol), cada una dueña de un dominio de capacidad, con la firma y el cifrado siempre mediados por la shell para que las claves nunca entren en el sandbox. La propuesta depende de la spec de manifiesto de napplet NIP-5A y es oportuna esta semana: el trabajo pre-release de v1.13.0 de Amethyst incluye aislamiento de cuentas de napplet, convirtiendo el alojamiento de napplets del lado del cliente en un área activa de implementación. Como con “NIP-91” arriba, el número 5D es provisional.

NIP Deep Dive: NIP-42 y NIP-43

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

NIP-42: Autenticación de clientes ante relays

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

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

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

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

NIP-43: Relay Access Metadata and Requests

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

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

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

Historia

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

Implementaciones

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

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