Bilan de la semaine : les groupes NIP-29 gagnent l'épinglage de messages, les sous-groupes, les invitations et une bannière

L'épinglage de messages arrive en premier (#2379)

La première des cinq, fusionnée le 2026-07-15, #2379 ajoute l'épinglage de messages à NIP-29. Elle introduit une action de modération update-pin-list accompagnée d'un nouveau type d'événement, kind:39005, pour suivre les messages que les administrateurs d'un groupe ont épinglés. C'est l'ajout conceptuellement le plus petit de la semaine, mais c'est aussi celui que la dernière PR du lot, la #2416, vient prolonger deux jours plus tard.

Un format de code d'invitation pour les identifiants de groupe (#2380)

#2380 ajoute un format de suffixe permettant à l'identifiant d'un groupe de porter un code d'invitation. Avec 8 lignes ajoutées, il donne aux groupes NIP-29 un moyen, au niveau de la spécification, de distribuer une invitation directement dans l'identifiant plutôt que via un lien externe.

Sous-groupes : la modification la plus importante de la semaine (#2319)

#2319 est structurellement la plus grande des cinq, avec 62 lignes ajoutées, et c'est celle qui change le plus la manière dont les groupes se relient entre eux. Elle ajoute une section Sous-groupes à NIP-29, permettant d'organiser les groupes de manière hiérarchique. Elle le fait sans introduire aucun nouveau type d'événement : elle réutilise le kind:39000 existant (métadonnées de groupe) et le kind:9002 (edit-metadata), et ajoute deux noms de balises, parent et child.

Une balise parent sur l'événement kind:39000 d'un groupe pointe vers l'identifiant d du groupe parent. L'absence de balise parent signifie que le groupe est une racine sans parent, et un événement edit-metadata soumis sans balise parent est précisément ce qui détache un groupe et le ramène à la racine. Les clients sont censés construire l'arbre des groupes localement en lisant les événements kind:39000, plutôt qu'en interrogeant un point de terminaison dédié à la hiérarchie.

Attribuer un parent, le changer, ou promouvoir un groupe de nouveau au rang de racine se fait via un événement kind:9002 d'edit-metadata. Le relais est chargé de garder synchronisés les deux côtés de la relation : quand le parent d'un groupe change, le relais met à jour les balises child de l'ancien et du nouveau parent dans leurs événements kind:39000. Le kind:39000 du parent doit lister chacun de ses enfants sous la forme d'une balise ordonnée ["child", "<id>"], et la spécification prévoit que les relais rejettent les modifications de métadonnées qui supprimeraient silencieusement un enfant existant. Comme l'ordre provient de la position de la balise, les administrateurs peuvent réordonner la liste de leurs enfants.

La relation est appliquée par le relais, pas négociée entre clients. Un événement kind:9002 qui définit ["parent", "X"] est rejeté à moins que son auteur ne soit aussi administrateur du groupe X, selon la liste d'administrateurs kind:39001 de ce groupe. Comme modifier le groupe enfant exige déjà d'être administrateur de cet enfant, les deux côtés du lien, parent et enfant, doivent consentir indépendamment avant qu'un relais ne l'accepte. La spécification prévoit également que les relais rejettent les cycles, y compris un groupe qui se désigne lui-même comme son propre parent, ce qui ferme le type d'arbre malformé qu'une vérification purement côté client pourrait manquer.

Une balise bannière pour les métadonnées de groupe (#2383)

#2383 ajoute une balise banner à l'événement de métadonnées de groupe kind:39000. Avec deux lignes ajoutées et une supprimée, c'est le plus petit diff des cinq, donnant aux groupes un emplacement, au niveau de la spécification, pour déclarer une image de bannière aux côtés des métadonnées qu'ils portent déjà, comme le nom et l'image de profil.

La liste des épinglés apprend à référencer des événements adressables (#2416)

#2416, fusionnée à 00:01:30 UTC le 17 juillet, revient sur la liste des messages épinglés que #2379 avait introduite deux jours plus tôt. Elle étend le format pour que la liste puisse aussi contenir des balises a, la convention de NIP-01 pour référencer des événements adressables par kind, clé publique et identifiant d, en plus des balises e déjà prises en charge pour référencer des événements ordinaires, non adressables.

Ce que la semaine met en évidence

Aucune de ces cinq pull requests n'est grande à elle seule, et les sources ne disent pas pourquoi les mainteneurs les ont traitées ensemble ni ce qui vient ensuite. Ce qu'elles montrent, c'est la forme du travail : en trois jours, NIP-29 a gagné un moyen d'épingler des messages, un moyen d'inviter par identifiant, un moyen d'imbriquer des groupes les uns dans les autres, un moyen de définir une bannière, et une liste d'épinglés élargie qui se rattache à la première modification. C'est une spécification qui remplit activement les fonctions dont un protocole de chat de groupe a besoin dès lors que les utilisateurs commencent à les demander.