NIP-70 : les reposts qui intègrent des événements protégés doivent être rejetés

Ce qu'est un événement protégé

Un événement protégé porte le tag ["-"]. D'après le texte déjà existant du NIP-70, le comportement par défaut d'un relais DOIT être de rejeter tout événement contenant ce tag, sauf si le client complète d'abord le flux AUTH du NIP-42 et que la clé publique authentifiée correspond à celle de l'événement lui-même. En pratique, c'est l'auteur qui décide, relais par relais, si un événement protégé est accepté ou non. Publié vers un relais auquel l'auteur ne s'est jamais authentifié, ce relais est censé le refuser.

La lacune que la PR comble

Un repost, de kind 6, ainsi que le repost générique de kind 16, est un événement dont le champ content porte le JSON complet de l'événement reposté, afin qu'un client puisse afficher la note repostée sans requête séparée. C'est pratique pour une note ordinaire, mais cela laissait une ouverture pour une note protégée : rien dans le texte précédent n'empêchait d'envelopper un événement protégé dans un repost et de publier ce repost vers n'importe quel relais souhaité. Le tag de protection s'applique à l'événement protégé lui-même, pas à une copie de son contenu logée dans le champ content d'un événement différent.

La PR ajoute deux phrases à 70.md :

Reposts of protected events MUST NOT embed the reposted event. If a repost of a protected event embeds the event anyway, relays SHOULD summarily reject it.

C'est là tout le changement : deux lignes ajoutées, aucune supprimée. L'exigence joue dans les deux sens. La première phrase s'adresse à celui qui construit le repost : ne pas intégrer le contenu d'un événement protégé dans un repost, en aucun cas. La seconde s'adresse aux relais : si l'un d'eux apparaît quand même, avec le contenu d'un événement protégé logé dans le champ content d'un repost, il doit être rejeté sur le champ, même si l'événement de repost lui-même ne porte pas le tag ["-"].

Pourquoi c'est une limite de confidentialité, pas un détail de livraison

Sans cette règle, le tag d'événement protégé pouvait être contourné sans effort. Il suffisait de reposter l'événement pour que son contenu voyage vers chaque relais où ce repost était publié, aucun d'eux n'ayant exigé d'authentification de l'auteur original. Le choix de l'auteur quant aux relais autorisés à conserver l'événement, appliqué au niveau du relais via AUTH du NIP-42, ne vaudrait plus grand-chose dès lors que n'importe qui pourrait copier son contenu dans une enveloppe non protégée et la publier où bon lui semble.

Le correctif maintient le point d'application là où il doit se trouver. Un relais qui voit un repost intégrant un événement protégé dispose désormais d'un motif explicite, énoncé dans le texte même de la spécification, pour le refuser, tout comme si l'événement protégé avait été publié directement vers ce relais.

L'auteur de la PR, fiatjaf, a noté dans la description qu'il s'attendait à ce que cette règle existe déjà dans la spécification : "I thought we had this here already, but apparently not" (« Je pensais qu'on avait déjà ça ici, mais apparemment non »). L'ajout de deux lignes met le texte écrit en accord avec cette attente.