NIP-84 добавляет теги i в выделения и ослабляет r

Раздел ссылок становится списком

Прежний текст состоял из двух предложений и охватывал два случая:

a or e tags should be used for nostr events and r tags for URLs.

На замену пришёл список из трёх пунктов:

• a and/or e tags for nostr events
• i tags for structured sources per NIP 73
• r tags for anything else (may contain a URL or text)

Здесь одновременно произошли две вещи. Один случай добавили, а другой, уже существовавший, переопределили.

Что даёт тег i

NIP-73 это спецификация внешних идентификаторов контента. Она задаёт для тегов i фиксированный словарь идентификаторов, существующих за пределами nostr: isbn: для книг, doi: для научных статей, isan: для фильмов, geo: для геохешей, iso3166: для стран и их частей, podcast:guid: вместе с вариантами для выпуска и издателя, а также формы для транзакций и адресов в блокчейне и нормализованную форму URL под типом web.

При прежней формулировке выделение из книги никак не могло об этом сообщить. Единственным слотом не для nostr был r, определённый как URL, а у печатной книги URL нет. Отсылка i к NIP-73 даёт такому выделению идентификатор, по которому другие клиенты могут делать запросы, а это и есть смысл реестра идентификаторов: все события с ["i", "isbn:9780123456789"] находятся как одна группа.

Одна деталь, которую новая строка опускает. NIP-73 сопровождает каждый тег i тегом k, называющим тип идентификатора, и именно это делает возможным запрос по типу. NIP-84 говорит о тегах i согласно NIP-73, не повторяя требование о k, так что про эту пару придётся читать в самом NIP-73.

Что теряет тег r

r больше не тег для URL. Теперь это запасной вариант, и спецификация прямо говорит, что он может содержать URL или текст. Pull request описывает ситуацию, которая к этому привела: выделения, опубликованные с источником, который не является URL, и которые клиенты, предполагавшие корректный URL, не могли разобрать.

Читать его как URL на практике никогда не было безопасно, и это изменение перестаёт оправдывать реализации, продолжавшие так его разбирать. Оно же кое от чего отказывается. Клиент больше не может считать значение r в выделении ссылкой, не проверив его сначала.

Та же правка убрала рекомендацию, которая шла вместе со старым определением:

When tagging a URL, clients generating these events SHOULD do a best effort of cleaning the URL from trackers or obvious non-useful information from the query string.

Это было единственное указание про трекеры в NIP-84, и из файла оно исчезло. Ничто в диффе не перенесло его в другое место. Клиенты, вычищающие параметры отслеживания из источников выделения, теперь делают это по собственному усмотрению, а не по SHOULD из спецификации, а нормализованная форма URL из NIP-73, которую теперь покрывает путь через i, отбрасывает фрагмент, но ничего не говорит о строке запроса.

Остался и хвост. Заключительный абзац NIP-84, которого этот pull request не касался, по-прежнему гласит, что URL в тегах r, взятые из комментария, MUST иметь атрибут mention, чтобы отличать их от URL выделенного источника, и что URL источника MUST иметь атрибут source. Этот текст предполагает, что r содержит URL, чего раздел ссылок выше уже не требует.

MUST становится SHOULD

Второе нормативное изменение находится в разделе про выделения с цитатой. Тег comment превращает выделение в выделение с цитатой, и правило отображения было безусловным:

This MUST be rendered like a quote repost with the highlight as the quoted note.

Теперь там стоит SHOULD. Причина, изложенная в окружающем тексте, не изменилась: эта конструкция существует, чтобы одно действие выделения не порождало две заметки, выделение и kind 1, идущие подряд в микроблогинговых клиентах. Клиент, отображающий выделения с цитатой иначе, больше не нарушает спецификацию.

Оставшаяся правка это исправление опечатки, creation and multiple notes на creation of multiple notes, в том же абзаце.

Больше в NIP-84 ничего не изменилось. Он по-прежнему draft и optional, событие по-прежнему kind:9802, а теги p, context и comment сохраняют прежние значения.