Resumen semanal: los grupos NIP-29 suman fijado de mensajes, subgrupos, invitaciones y un banner

El fijado de mensajes llega primero (#2379)

El primero de los cinco, fusionado el 2026-07-15, #2379 suma el fijado de mensajes a NIP-29. Introduce una acción de moderación update-pin-list junto con un nuevo tipo de evento, kind:39005, para llevar registro de qué mensajes han fijado los administradores de un grupo. Es la adición conceptualmente más pequeña de la semana, pero también es la que retoma la última PR del lote, #2416, dos días después.

Un formato de código de invitación para identificadores de grupo (#2380)

#2380 suma un formato de sufijo que permite que el identificador de un grupo incluya un código de invitación. Con 8 líneas añadidas, le da a los grupos NIP-29 una forma a nivel de especificación de distribuir una invitación como parte del propio identificador, en lugar de como un enlace fuera de banda.

Subgrupos: el cambio más grande de la semana (#2319)

#2319 es estructuralmente el más grande de los cinco, con 62 líneas añadidas, y es el que más cambia la forma en que los grupos se relacionan entre sí. Suma una sección de Subgrupos a NIP-29 que permite organizar los grupos jerárquicamente. Lo hace sin introducir ningún tipo de evento nuevo: reutiliza el kind:39000 existente (metadatos de grupo) y el kind:9002 (edit-metadata), y suma dos nombres de etiqueta, parent y child.

Una etiqueta parent en el evento kind:39000 de un grupo apunta al identificador d del grupo padre. Sin etiqueta parent, el grupo es una raíz sin padre, y un evento edit-metadata enviado sin etiqueta parent es lo que desvincula un grupo de vuelta a raíz. Se espera que los clientes construyan el árbol de grupos localmente leyendo eventos kind:39000, en lugar de consultar un endpoint dedicado a la jerarquía.

Asignar padre, reasignarlo o promover un grupo de vuelta a raíz ocurre a través de un evento kind:9002 de edit-metadata. El relay es responsable de mantener sincronizados ambos lados de la relación: cuando cambia el padre de un grupo, el relay actualiza las etiquetas child tanto del padre anterior como del nuevo en sus eventos kind:39000. El kind:39000 del padre debe listar a cada uno de sus hijos como una etiqueta ordenada ["child", "<id>"], y la especificación hace que los relays rechacen ediciones de metadatos que eliminarían silenciosamente a un hijo existente. Como el orden proviene de la posición de la etiqueta, los administradores pueden reordenar la lista de sus hijos.

La relación se aplica desde el relay, no se negocia entre clientes. Un evento kind:9002 que establece ["parent", "X"] es rechazado a menos que su autor sea también administrador del grupo X, según la lista de administradores kind:39001 de ese grupo. Como editar el grupo hijo ya requiere ser administrador del hijo, ambos lados del vínculo, padre e hijo, deben dar su consentimiento de forma independiente antes de que un relay lo acepte. La especificación también hace que los relays rechacen ciclos, incluyendo un grupo que se liste a sí mismo como su propio padre, cerrando el tipo de árbol malformado que una validación puramente del lado del cliente podría pasar por alto.

Una etiqueta banner para los metadatos de grupo (#2383)

#2383 suma una etiqueta banner al evento de metadatos de grupo kind:39000. Con dos líneas añadidas y una eliminada, es el diff más pequeño de los cinco, y le da a los grupos un lugar a nivel de especificación para declarar una imagen de banner junto a los metadatos que ya llevan, como el nombre y la imagen de perfil.

La lista de fijados aprende a referenciar eventos direccionables (#2416)

#2416, fusionado a las 00:01:30 UTC del 17 de julio, retoma la lista de mensajes fijados que introdujo #2379 dos días antes. Extiende el formato para que la lista también pueda contener etiquetas a, la convención de NIP-01 para referenciar eventos direccionables por tipo, clave pública e identificador d, junto a las etiquetas e que ya admitía para referenciar eventos normales, no direccionables.

Lo que suma la semana

Ninguna de estas cinco pull requests es grande por sí sola, y las fuentes no dicen por qué los mantenedores las abordaron juntas ni qué sigue después. Lo que sí muestra es la forma del trabajo: en tres días, NIP-29 obtuvo una forma de fijar mensajes, una forma de invitar por identificador, una forma de anidar grupos dentro de otros grupos, una forma de establecer un banner, y una lista de fijados ampliada que se conecta con el primer cambio. Es una especificación llenando activamente las funciones que un protocolo de chat grupal necesita en cuanto la gente empieza a pedirlas.