NIP-30 распространяет пользовательские эмодзи на комментарии kind 1111

Что делает правка

Первое предложение NIP-30 раньше говорило, что пользовательские эмодзи можно добавлять к событиям kind 0, kind 1, kind 7 и kind 30315. Теперь оно читается так:

Custom emoji may be added to kind 0, kind 1, kind 1111 (NIP-22), kind 7 (NIP-25) and kind 30315 (NIP-38) events by including one or more "emoji" tags.

Пул-реквест добавляет также новый подраздел, такой же, как уже имеющиеся для kind 0, 1 и 7:

Kind 1111 events

In kind 1111 events, the content should be emojified.

В нём приведён разобранный пример: событие kind 1111, у которого content равен "Let's party! :hyves_banaan:", и один тег emoji, содержащий шорткод, URL изображения и адресный указатель на набор эмодзи kind 30030.

Больше в NIP-30 ничего не изменилось. Форма тега прежняя:

["emoji", <shortcode>, <image-url>, <emoji-set-address>]

Прежними остались и правила вокруг неё. Шорткод по-прежнему ДОЛЖЕН состоять только из букв и цифр, дефисов и подчёркиваний. Третий элемент остаётся необязательным указателем kind:pubkey:d-tag на набор эмодзи kind 30030, категоризированную группу эмодзи из NIP-51. NIP-30 сохраняет пометки draft optional.

До каких событий это доходит

Kind 1111 представляет собой событие-комментарий, определённое в NIP-22. Комментарий всегда привязан к корневому событию или к тегу I из NIP-73: на корневую область он указывает тегами в верхнем регистре, а на непосредственного родителя их эквивалентами в нижнем. Это примитив ветвления, применяемый для ответов на события, не являющиеся текстовыми заметками kind 1: комментарии под длинными статьями, под файлами, под внешним контентом, обозначенным тегом I.

Этот охват вырос вчера. Отдельное слияние, описанное в предыдущем выпуске, убрало из NIP-22 строку, запрещавшую использовать комментарий для ответа на заметку kind 1. Комментарий kind 1111 теперь может находиться и под текстовой заметкой. Сегодняшняя правка означает, что шорткоды в любом из таких комментариев опираются на спецификацию, а не остаются недокументированным поведением клиента.

Простой текст и шорткоды

NIP-22 указывает, что kind 1111 использует "plaintext .content (no HTML, Markdown, or other formatting)". Пользовательские эмодзи не противоречат этому правилу, и дело в том, где NIP-30 размещает данные. Поле content хранит только буквальные символы :hyves_banaan:. URL изображения и указатель на набор эмодзи находятся в теге. В поле содержимого нет никакой разметки, и клиент, ничего не знающий о NIP-30, отобразит шорткод как обычный текст, каким тот и является.

Именно поэтому изменение дёшево реализовать клиенту, который уже поддерживает пользовательские эмодзи в других местах. Шаг разбора идентичен применяемому для заметок kind 1: прочитать теги emoji и заменить каждое вхождение :shortcode: в content соответствующим изображением. Не хватало не механизма, а строки в спецификации о том, что механизм применим и здесь.

Разработчикам клиентов

Клиенту, показывающему комментарии, теперь следует ожидать теги emoji на событиях kind 1111 и эмодзифицировать их содержимое. Клиент, где комментарии пишут, может предложить тот же выбор пользовательских эмодзи, что и для заметок, добавляя тег emoji на каждый вставленный шорткод. Релеев это не касается: emoji является обычным тегом, и NIP-30 ничего от них не требует.

В спецификации стоит глагол "should", а не "must", и на стороне отображения, и на стороне составления. Комментарий с неразрешёнными шорткодами остаётся допустимым комментарием и читается как буквальные двоеточия у всех, чей клиент этого не реализовал.