NIP-29 définit les groupes basés sur les relais, où un relais gère l’appartenance au groupe, les permissions et la visibilité des messages.

Fonctionnement

Les groupes sont identifiés par un hôte de relais associé à un identifiant de groupe, et le relais fait autorité pour l’appartenance et la modération. Les événements créés par les utilisateurs et envoyés dans un groupe portent un tag h contenant l’identifiant du groupe. Les métadonnées générées par le relais utilisent des événements adressables signés par la propre clé du relais.

L’événement de métadonnées principal est le kind 39000, tandis que les kinds 39001 à 39003 décrivent les administrateurs, les membres et les rôles pris en charge. Les actions de modération s’effectuent via des événements de la série 9000 tels que put-user, remove-user, edit-metadata et create-invite.

Modèle d’accès

  • private : Seuls les membres peuvent lire les messages du groupe
  • closed : Les demandes d’adhésion sont ignorées, sauf si le relais utilise un système de codes d’invitation
  • hidden : Le relais masque les métadonnées du groupe aux non-membres, rendant le groupe indécouvrable
  • restricted : Seuls les membres peuvent écrire des messages dans le groupe

Ces tags sont indépendants. Un groupe peut être lisible par tous mais accessible en écriture uniquement aux membres, ou entièrement masqué aux non-membres. Cette séparation compte, car les clients ne devraient pas traiter « private » comme un raccourci global pour toutes les règles d’accès.

Modèle de confiance

NIP-29 n’est pas un protocole de groupe sans confiance. Le relais hébergeur décide quels événements de modération sont valides, quels rôles existent, si les listes de membres sont visibles, et si les messages anciens ou hors contexte sont acceptés. Un client peut vérifier les signatures et les références de chronologie, mais il dépend toujours de la politique du relais pour l’état réel du groupe.

Cela rend la migration et le fork possibles, mais pas automatiques. Le même identifiant de groupe peut exister sur différents relais avec des historiques ou des règles différentes, de sorte que l’URL du relais fait partie de l’identité du groupe en pratique.

Notes d’implémentation utiles

  • Les clients devraient traiter l’URL du relais comme la clé d’hôte du groupe. Une clarification de janvier 2026 a rendu cela explicite dans la spécification et supprimé l’ambiguïté concernant l’utilisation d’une pubkey à la place
  • L’état du groupe est reconstruit à partir de l’historique de modération, tandis que les événements relais de la série 39000 sont des instantanés informatifs de cet état
  • Les références previous de la chronologie servent à empêcher la rediffusion hors contexte entre forks de relais, pas uniquement à améliorer le threading de l’interface

Travail récent sur la spécification

  • PR #2310 et les notes de release de Flotilla 1.7.3/1.7.4 proposent l’enveloppement kind-9 de types de contenu non orientés chat (événements calendrier, sondages, autres payloads) afin de préserver le contexte du salon lorsque ces objets sont envoyés dans un groupe.
  • PR #2319 étend la spécification avec une hiérarchie de sous-groupes afin qu’un seul groupe puisse héberger plusieurs canaux parallèles sans créer de groupes indépendants sur le même relay. L’identifiant de sous-groupe s’appuie sur le tag h existant, ce qui préserve les messages à tag h unique pour les anciens clients.
  • PR #2316 définit des permissions explicites sur l’événement de rôle kind 39003, afin que chaque rôle devienne un ensemble nommé d’opérations accordées (invite, add-user, remove-user, edit-metadata, delete-event, add-permission) avec une expiration optionnelle bornée dans le temps.

Implémentations

  • Flotilla est le principal client NIP-29 de hodlbod ; 1.7.3 et 1.7.4 ont livré l’enveloppement kind-9, les sondages, la connexion NIP-46 via le schéma d’URL Aegis, le support natif du partage pour les invitations d’espaces, les mentions de salons, le collage d’images depuis le presse-papiers mobile, les brouillons et la vidéo pendant les appels.
  • Wisp a ajouté la configuration de groupe NIP-29 pour les flags, invitations, rôles et prompts AUTH dans la PR #471 et a durci la séquence AUTH avant les événements de groupe 9021, 9007 et 9009 dans la PR #478.

Sources principales :

Mentionné dans :

Voir aussi :