Resumen de la Semana: Nueve Pull Requests Fusionados en nostr-protocol/nips

NIP-59: un nuevo tipo de gift wrap efímero para mensajes en tiempo real

El PR #2245 agrega kind:21059, una contraparte efímera del kind:1059 existente para gift wrap. Tiene la misma estructura que kind:1059, pero sigue la semántica de eventos efímeros definida en NIP-01, lo que significa que los relays NO DEBEN almacenarlo. NIP-59 ahora explica la división prevista: kind:1059 es para mensajería persistente y asíncrona, como las conversaciones de NIP-17 que necesitan entrega fuera de línea, mientras que kind:21059 es para contextos en tiempo real, como chats en vivo o videojuegos, donde solo importan los destinatarios conectados en ese momento. Esto no cambia cómo funcionan hoy los mensajes directos de NIP-17: agrega un segundo tipo de gift wrap, no persistente, para casos de uso que no necesitan historial de mensajes.

NIP-17: los mensajes directos envueltos en gift wrap obtienen una sección de eliminación y edición

El PR #2260 agrega una sección "Delete and Edit" a NIP-17. Establece que, además del comportamiento de eliminación ya especificado en NIP-59, donde un gift wrap puede ser eliminado por el destinatario marcado con la etiqueta p, los clientes PUEDEN permitir que un usuario elimine un mensaje envolviendo un evento de eliminación kind:5 dentro de un gift wrap kind:1059 y enviándolo al destinatario como parte de la conversación. Los clientes DEBERÍAN entonces quitar el mensaje eliminado de la conversación, o marcarlo como eliminado. La misma sección también permite implementar la edición de mensajes como una eliminación seguida de un nuevo evento publicado con la misma marca de tiempo. Esta es una guía nueva que se agrega sobre el formato de gift wrap existente, no un cambio al cifrado en sí.

NIP-01: los relays deben tratar los segmentos de ruta adicionales como el mismo endpoint

El PR #2307 agrega una sola frase a NIP-01: "Relays MUST only accept connections to a single endpoint when additional path segments do not influence its behavior." La descripción del PR señala que una URL de relay como wss://relay.example/<random-string> era, en la mayoría de los relays en funcionamiento, funcionalmente idéntica a wss://relay.example/, una ambigüedad que dificultaba a los clientes razonar sobre la identidad y deduplicación de relays.

NIP-29: espacios en vivo de audio y video para grupos

El PR #2238 agrega una sección a NIP-29 que permite a un grupo anunciar una sala de voz y video con LiveKit mediante una etiqueta livekit en el evento de anuncio del grupo, junto con una nueva etiqueta supported_kinds que enumera qué tipos de eventos acepta el grupo (una lista vacía significa que no admite ningún kind, solo la sala de audio/video). Los clientes solicitan un token de ingreso al endpoint /.well-known/nip29/livekit/<group-id> de un relay usando un evento de autorización de NIP-98, y los relays pueden publicar quién está actualmente en la sala mediante un nuevo evento kind:39004 de participantes.

NIP-71: varias pistas de audio por video

El PR #2255 extiende las convenciones de la etiqueta imeta en NIP-71 para que un solo video pueda listar varias pistas de audio como etiquetas imeta independientes, cada una con una propiedad l para su idioma y una propiedad ov que marca la pista en el idioma original. También agrega una propiedad waveform, una breve lista de valores de amplitud separados por espacios, para que los clientes puedan renderizar una forma de onda de una pista de audio.

NIP-78: un kind normal y no direccionable para datos específicos de aplicación

El PR #2292 agrega kind:78 a NIP-78 como evento normal, junto al kind:30078 direccionable ya existente. La distinción importa para las aplicaciones que necesitan almacenar y consultar varios eventos del mismo tipo: un kind direccionable conserva solo el evento más reciente por etiqueta d, mientras que un kind normal los conserva todos. El PR también agrega el nuevo kind a la tabla de tipos de eventos del README de NIPs.

NIP-85: descripción reformulada de kind:10040

El PR #2304 reformula un solo párrafo de NIP-85. Cambia el texto que describía kind:10040 como una lista de "proveedores de servicios confiables" para describirlo en cambio como la fuente preferida del usuario para cada resultado, y aclara que un proveedor de servicios puede usar varias claves y relays, incluida una clave emitida por usuario cuando los resultados se personalizan para ese usuario.

C7: vistas de chat restringidas a kind 9

El PR #2310 agrega una línea a la convención C7: los clientes que renderizan una "vista de chat" como un flujo ordenado de eventos DEBEN obtener únicamente eventos kind:9, para evitar perder contexto entre distintas implementaciones. Otros tipos de contenido aún pueden referenciarse dentro de un mensaje kind:9 citándolos, según NIP-18.

NIP-F4: un nuevo NIP en borrador para podcasts

El PR #1093 es, con mucha diferencia, el cambio más grande del día: agrega una especificación completa en borrador de más de cien líneas nuevas. Introduce NIP-F4, un NIP en borrador y opcional que define cómo se publican y se leen desde los relays los programas y episodios de podcast como eventos de Nostr, pensado para encajar en los flujos de trabajo de los reproductores de podcast existentes. Con NIP-F4, cada podcast tiene su propio par de claves de Nostr, lo que le permite combinar su presencia como podcast con un perfil normal kind:0/kind:1. La información a nivel de programa, como el título, la imagen de portada, la descripción y el sitio web, se publica como un evento reemplazable kind:10154 que también puede acreditar a presentadores, copresentadores y editores por su clave pública. Los episodios individuales son eventos kind:54 separados, publicados directamente con la clave propia del podcast, cada uno con un título, una descripción y una o varias etiquetas audio que apuntan al archivo multimedia del episodio. Como cualquiera podría hacerse pasar falsamente por el autor de un podcast, NIP-F4 agrega un evento kind:10064 mediante el cual los autores reales de un podcast publican su propia lista de los podcasts que autoran, de modo que una autoría reclamada pueda verificarse contra esa contra-afirmación en lugar de darse por buena sin más. El PR también actualiza NIP-51 para agregar una lista "Favorite podcasts" de tipo kind:10054, que permite a cualquier usuario indicar públicamente qué podcasts sigue usando etiquetas p para las claves públicas de los podcasts y etiquetas url para las URL de los feeds RSS/XML, y agrega los nuevos kinds de evento a la tabla de kinds del README de los NIPs.

Un lote, no un lanzamiento coordinado

Más allá de los dos cambios sobre mensajes directos, no hay un hilo común que conecte a estos nueve pull requests. Tocan partes no relacionadas del protocolo, desde el manejo de conexiones de relays hasta el video en grupos, el almacenamiento de aplicaciones y la distribución de podcasts, y simplemente pasaron revisión dentro de la misma ventana de unos noventa minutos el 28 de mayo. Fue un lote, no un lanzamiento temático, aunque el cambio más grande del día, con mucha diferencia, el nuevo NIP de podcasts, llegó en la misma ventana que otros ocho mucho más pequeños.