Riepilogo della settimana: i gruppi NIP-29 ottengono fissaggio dei messaggi, sottogruppi, inviti e un banner

Il fissaggio dei messaggi arriva per primo (#2379)

Il primo dei cinque, unito il 2026-07-15, #2379 aggiunge il fissaggio dei messaggi a NIP-29. Introduce un'azione di moderazione update-pin-list insieme a un nuovo tipo di evento, kind:39005, per tenere traccia dei messaggi fissati dagli amministratori di un gruppo. È l'aggiunta concettualmente più piccola della settimana, ma è anche quella a cui torna, due giorni dopo, l'ultima PR del gruppo, la #2416.

Un formato di codice invito per gli identificatori di gruppo (#2380)

#2380 aggiunge un formato di suffisso che permette all'identificatore di un gruppo di contenere un codice invito. Con 8 righe aggiunte, dà ai gruppi NIP-29 un modo, a livello di specifica, di distribuire un invito come parte dell'identificatore stesso, invece che come link separato.

Sottogruppi: la modifica più grande della settimana (#2319)

#2319 è strutturalmente la più grande delle cinque, con 62 righe aggiunte, ed è quella che cambia di più il modo in cui i gruppi si relazionano tra loro. Aggiunge una sezione Sottogruppi a NIP-29, che permette di organizzare i gruppi gerarchicamente. Lo fa senza introdurre alcun nuovo tipo di evento: riutilizza il kind:39000 esistente (metadati del gruppo) e il kind:9002 (edit-metadata), aggiungendo due nomi di tag, parent e child.

Un tag parent sull'evento kind:39000 di un gruppo punta all'identificatore d del gruppo genitore. L'assenza del tag parent significa che il gruppo è una radice senza genitore, e un evento edit-metadata inviato senza tag parent è ciò che stacca un gruppo riportandolo a radice. Ci si aspetta che i client costruiscano l'albero dei gruppi localmente leggendo gli eventi kind:39000, invece di interrogare un endpoint dedicato alla gerarchia.

Assegnare un genitore, cambiarlo o promuovere un gruppo di nuovo a radice avviene tramite un evento kind:9002 di edit-metadata. Il relay è responsabile di mantenere sincronizzati entrambi i lati della relazione: quando il genitore di un gruppo cambia, il relay aggiorna i tag child sia del vecchio sia del nuovo genitore nei rispettivi eventi kind:39000. Il kind:39000 del genitore deve elencare ciascuno dei suoi figli come un tag ordinato ["child", "<id>"], e la specifica prevede che i relay rifiutino le modifiche ai metadati che rimuoverebbero silenziosamente un figlio esistente. Poiché l'ordine deriva dalla posizione del tag, gli amministratori possono riordinare l'elenco dei figli.

La relazione è applicata dal relay, non negoziata tra client. Un evento kind:9002 che imposta ["parent", "X"] viene rifiutato a meno che il suo autore non sia anche amministratore del gruppo X, secondo la lista amministratori kind:39001 di quel gruppo. Poiché modificare il gruppo figlio richiede già di essere amministratore del figlio, entrambi i lati del legame, genitore e figlio, devono dare il consenso in modo indipendente prima che un relay lo accetti. La specifica prevede inoltre che i relay rifiutino i cicli, incluso un gruppo che indica se stesso come proprio genitore, chiudendo il tipo di albero malformato che un controllo solo lato client potrebbe non rilevare.

Un tag banner per i metadati del gruppo (#2383)

#2383 aggiunge un tag banner all'evento di metadati del gruppo kind:39000. Con due righe aggiunte e una rimossa, è il diff più piccolo dei cinque, e dà ai gruppi un posto, a livello di specifica, per dichiarare un'immagine banner accanto ai metadati che già portano, come nome e immagine del profilo.

La lista dei fissati impara a riferirsi a eventi indirizzabili (#2416)

#2416, unita alle 00:01:30 UTC del 17 luglio, torna sulla lista dei messaggi fissati introdotta da #2379 due giorni prima. Estende il formato in modo che la lista possa contenere anche tag a, la convenzione di NIP-01 per riferirsi a eventi indirizzabili tramite kind, chiave pubblica e identificatore d, oltre ai tag e già supportati per riferirsi a eventi normali, non indirizzabili.

Cosa emerge dalla settimana

Nessuna di queste cinque pull request è grande da sola, e le fonti non dicono perché i maintainer le abbiano affrontate insieme né cosa venga dopo. Ciò che mostra è la forma del lavoro: in tre giorni, NIP-29 ha ottenuto un modo per fissare i messaggi, un modo per invitare tramite identificatore, un modo per annidare gruppi dentro altri gruppi, un modo per impostare un banner, e una lista dei fissati ampliata che si ricollega alla prima modifica. È una specifica che riempie attivamente le funzioni di cui un protocollo di chat di gruppo ha bisogno non appena le persone iniziano a chiederle.