NIP-70: репосты, встраивающие защищённые события, должны отклоняться

Что такое защищённое событие

Защищённое событие несёт тег ["-"]. Согласно уже существующему тексту NIP-70, поведение релея по умолчанию ДОЛЖНО состоять в отклонении любого события с этим тегом, если только клиент сначала не пройдёт поток AUTH по NIP-42 и аутентифицированный публичный ключ не совпадёт с публичным ключом самого события. На практике именно автор решает, для каждого релея отдельно, будет ли принято защищённое событие вообще. Опубликованное на релей, к которому автор никогда не аутентифицировался, оно должно быть отклонено этим релеем.

Пробел, который закрывает PR

Репост, тип 6, а также обобщённый репост типа 16, это событие, чьё поле content несёт полный JSON репостируемого события, чтобы клиент мог показать репостнутую заметку без отдельного запроса. Это удобно для обычной заметки, но оставляло лазейку для защищённой: ничто в прежнем тексте не мешало обернуть защищённое событие в репост и опубликовать этот репост на любой релей по желанию. Тег защиты действует на само защищённое событие, а не на копию его содержимого, оказавшуюся в поле content другого события.

PR добавляет два предложения в 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.

Это всё изменение целиком: две добавленные строки, ни одной удалённой. Требование действует в обе стороны. Первое предложение адресовано тому, кто создаёт репост: не встраивать содержимое защищённого события в репост ни при каких обстоятельствах. Второе адресовано релеям: если такой репост всё же появился, с содержимым защищённого события внутри поля content, его следует немедленно отклонить, даже если сам репост не помечен тегом ["-"].

Почему это граница приватности, а не деталь доставки

Без этого правила тег защищённого события можно было обойти без труда. Достаточно было репостнуть событие, и его содержимое попадало на каждый релей, куда публиковался этот репост, ни один из которых не требовал аутентификации от исходного автора. Выбор автора о том, какие релеи вправе хранить событие, обеспечиваемый на уровне релея через AUTH по NIP-42, значил бы немного, как только кто угодно смог бы скопировать его содержимое в незащищённую обёртку и опубликовать где пожелает.

Исправление оставляет точку применения там, где ей и место. Релей, увидевший репост со встроенным защищённым событием, теперь имеет явное основание, прописанное прямо в тексте спецификации, отклонить его, точно так же, как если бы защищённое событие было опубликовано на этот релей напрямую.

Автор PR, fiatjaf, отметил в описании, что ожидал наличия этого правила в спецификации и раньше: "I thought we had this here already, but apparently not" ("Думал, у нас это уже было, но, видимо, нет"). Добавление двух строк приводит написанный текст в соответствие с этим ожиданием.