Resumo da semana: grupos NIP-29 ganham fixação de mensagens, subgrupos, convites e banner

A fixação de mensagens chega primeiro (#2379)

O primeiro dos cinco, mesclado em 2026-07-15, #2379 adiciona a fixação de mensagens ao NIP-29. Ele introduz uma ação de moderação update-pin-list junto com um novo tipo de evento, kind:39005, para registrar quais mensagens os administradores de um grupo fixaram. É a menor adição conceitual da semana, mas também é a que a última PR do lote, a #2416, retoma dois dias depois.

Um formato de código de convite para identificadores de grupo (#2380)

#2380 adiciona um formato de sufixo que permite que o identificador de um grupo carregue um código de convite. Com 8 linhas adicionadas, dá aos grupos NIP-29 uma forma, em nível de especificação, de distribuir um convite como parte do próprio identificador, em vez de um link fora de banda.

Subgrupos: a maior mudança da semana (#2319)

#2319 é estruturalmente a maior das cinco, com 62 linhas adicionadas, e é a que mais muda a forma como os grupos se relacionam entre si. Ela adiciona uma seção de Subgrupos ao NIP-29, permitindo organizar grupos hierarquicamente. Faz isso sem introduzir nenhum tipo de evento novo: reutiliza o kind:39000 já existente (metadados de grupo) e o kind:9002 (edit-metadata), e adiciona dois nomes de tag, parent e child.

Uma tag parent no evento kind:39000 de um grupo aponta para o identificador d do grupo pai. Sem tag parent, o grupo é uma raiz sem pai, e um evento edit-metadata enviado sem tag parent é o que desvincula um grupo de volta à raiz. Espera-se que os clientes montem a árvore de grupos localmente lendo eventos kind:39000, em vez de consultar um endpoint dedicado à hierarquia.

Definir pai, trocar de pai ou promover um grupo de volta a raiz acontece por meio de um evento kind:9002 de edit-metadata. O relay é responsável por manter os dois lados da relação sincronizados: quando o pai de um grupo muda, o relay atualiza as tags child tanto do pai anterior quanto do novo em seus eventos kind:39000. O kind:39000 do pai deve listar cada um de seus filhos como uma tag ordenada ["child", "<id>"], e a especificação faz os relays rejeitarem edições de metadados que removeriam silenciosamente um filho existente. Como a ordem vem da posição da tag, administradores podem reordenar a lista de filhos.

A relação é aplicada pelo relay, não negociada entre clientes. Um evento kind:9002 que define ["parent", "X"] é rejeitado a menos que seu autor também seja administrador do grupo X, segundo a lista de administradores kind:39001 daquele grupo. Como editar o grupo filho já exige ser administrador do filho, os dois lados do vínculo, pai e filho, precisam consentir de forma independente antes que um relay o aceite. A especificação também faz os relays rejeitarem ciclos, incluindo um grupo que se liste como seu próprio pai, fechando o tipo de árvore malformada que uma checagem apenas do lado do cliente poderia deixar passar.

Uma tag banner para os metadados de grupo (#2383)

#2383 adiciona uma tag banner ao evento de metadados de grupo kind:39000. Com duas linhas adicionadas e uma removida, é o menor diff dos cinco, e dá aos grupos um lugar em nível de especificação para declarar uma imagem de banner junto aos metadados que já carregam, como nome e foto.

A lista de fixados aprende a referenciar eventos endereçáveis (#2416)

#2416, mesclado às 00:01:30 UTC de 17 de julho, retoma a lista de mensagens fixadas que a #2379 introduziu dois dias antes. Ela estende o formato para que a lista também possa conter tags a, a convenção do NIP-01 para referenciar eventos endereçáveis por kind, chave pública e identificador d, junto às tags e que já eram aceitas para referenciar eventos comuns, não endereçáveis.

O que a semana soma

Nenhuma dessas cinco pull requests é grande por si só, e as fontes não dizem por que os mantenedores as trataram juntas nem o que vem a seguir. O que ele mostra é o formato do trabalho: em três dias, o NIP-29 ganhou uma forma de fixar mensagens, uma forma de convidar por identificador, uma forma de aninhar grupos dentro de outros grupos, uma forma de definir um banner, e uma lista de fixados ampliada que se conecta à primeira mudança. É uma especificação preenchendo ativamente os recursos que um protocolo de chat em grupo precisa assim que as pessoas começam a pedi-los.