Les demandes de suppression NIP-09 ne prouvent pas l’effacement

Le kind 5 identifie ce que l’auteur veut retirer

Un tag e nomme l’identifiant précis d’un événement. Un tag a désigne un événement remplaçable par son kind, sa clé publique et son identifiant d. La NIP-09 indique aussi que la demande devrait inclure un tag k pour chaque kind référencé. Son contenu peut expliquer la raison du retrait.

Pour une référence e, la demande n’est valable que si l’événement référencé et la demande de kind 5 ont la même clé publique. Un client doit vérifier cette correspondance avant de masquer ou supprimer quoi que ce soit. Sans cette règle, n’importe qui pourrait signer une demande pour faire disparaître la publication d’un autre auteur dans les interfaces conformes.

Une référence a a une portée plus large. Les relais devraient supprimer toutes les versions de cet événement remplaçable jusqu’au created_at de la demande. Les versions plus récentes restent hors de cette portée. L’horodatage fait donc partie de la limite.

Les relais reçoivent une demande, pas un contrôle à distance

La NIP-09 dit que les relais devraient supprimer les événements correspondants ou cesser de les publier. Elle ne dit pas qu’un relais peut être forcé. Il peut ne jamais recevoir la demande, ne pas stocker l’événement visé ou appliquer une autre politique de conservation.

Le protocole demande aussi aux relais de continuer à publier indéfiniment la demande de suppression elle-même. Les clients qui possèdent déjà l’événement original peuvent ainsi apprendre que son auteur l’a retiré. Les clients peuvent retransmettre la demande vers d’autres relais qui ne l’ont pas encore vue.

Cette asymétrie est volontaire : le contenu original doit devenir moins disponible, tandis que la demande signée de ne plus l’afficher doit rester disponible. Une demande visant une autre demande de suppression n’a aucun effet. Il n’existe pas d’opération standard pour annuler la demande.

Une signature prouve l’auteur, pas une suppression globale

La NIP-01 fait de chaque événement un objet signé indépendant dont l’identifiant dérive de son contenu sérialisé. Lorsqu’un événement a été copié, une signature ultérieure ne peut pas modifier cet objet. Elle peut seulement ajouter une instruction que d’autres logiciels peuvent respecter.

Les relais sont indépendants et les clients peuvent recevoir des événements par plusieurs abonnements. Une capture d’écran, une base locale, un export ou un relais d’archive peut survivre même si tous les relais habituels de l’auteur acceptent la demande. La NIP-09 permet donc aux clients d’avertir que la suppression ne peut pas être garantie sur tous les relais et clients.

La même limite vaut pour les événements chiffrés. Retirer le texte chiffré des relais coopératifs réduit sa disponibilité future, mais ne révoque pas les copies déjà téléchargées. Chiffrement et suppression répondent à des problèmes différents.

Ce qu’un client peut vérifier

Un client peut valider la signature du kind 5, vérifier que chaque événement référencé par e a le même auteur et enregistrer les relais qui ont accepté la demande. Il peut ensuite les interroger et confirmer qu’ils ne renvoient plus la cible. Ces contrôles donnent une preuve utile pour un ensemble défini de relais.

Ils ne produisent pas un reçu de suppression global. La réponse d’un relais ne dit rien sur les serveurs non interrogés, les clients hors ligne ou les copies extérieures au réseau de relais.

La règle pratique consiste à considérer une publication Nostr comme durable. Utilisez le kind 5 pour retirer du contenu, diffusez-le aux relais qui ont reçu l’original et laissez les clients masquer les cibles valides. Mais ne publiez pas de secret en supposant qu’une demande ultérieure récupérera chaque copie. La NIP-09 coordonne le retrait. Elle ne transforme pas un réseau distribué en système d’effacement à distance.