Обзор недели: девять pull request слиты в nostr-protocol/nips

NIP-59: новый тип эфемерного gift wrap для сообщений в реальном времени

PR #2245 добавляет kind:21059, эфемерный аналог уже существующего gift wrap kind:1059. Он имеет ту же структуру, что и kind:1059, но следует семантике эфемерных событий, определённой в NIP-01, а значит релеи НЕ ДОЛЖНЫ его хранить. NIP-59 теперь явно описывает предполагаемое разделение: kind:1059 предназначен для сохраняемой асинхронной переписки, например для разговоров по NIP-17, которым нужна доставка в офлайне, а kind:21059 предназначен для контекстов реального времени, таких как живой чат или игры, где важны только получатели, подключённые прямо сейчас. Это не меняет то, как сегодня работают личные сообщения NIP-17: добавляется второй, не сохраняемый тип gift wrap для сценариев, которым не нужна история сообщений.

NIP-17: у личных сообщений в gift wrap появляется раздел об удалении и редактировании

PR #2260 добавляет в NIP-17 раздел "Delete and Edit". В нём говорится, что в дополнение к поведению удаления, уже описанному в NIP-59, где gift wrap может быть удалён получателем, указанным в p-теге, клиенты МОГУТ позволить пользователю удалить сообщение, обернув событие удаления kind:5 в gift wrap kind:1059 и отправив его получателю как часть переписки. Клиентам СЛЕДУЕТ затем убрать удалённое сообщение из переписки или пометить его как удалённое. Тот же раздел также разрешает реализовать редактирование сообщений как удаление с последующей публикацией нового события с той же временной меткой. Это новое указание, добавленное поверх существующего формата gift wrap, а не изменение самого шифрования.

NIP-01: релеи должны считать дополнительные сегменты пути тем же эндпоинтом

PR #2307 добавляет в NIP-01 одно предложение: "Relays MUST only accept connections to a single endpoint when additional path segments do not influence its behavior". В описании PR отмечается, что URL релея вроде wss://relay.example/<random-string> на большинстве работающих релеев был функционально идентичен wss://relay.example/, и эта неоднозначность затрудняла клиентам определение идентичности релея и дедупликацию.

NIP-29: живые аудио- и видеопространства для групп

PR #2238 добавляет в NIP-29 раздел, позволяющий группе анонсировать голосовую и видеокомнату на базе LiveKit через тег livekit в событии анонса группы, наряду с новым тегом supported_kinds, который перечисляет, какие типы событий группа принимает (пустой список означает, что группа не поддерживает ни один kind, только AV-комнату). Клиенты запрашивают токен для входа через эндпоинт релея /.well-known/nip29/livekit/<group-id>, используя событие авторизации NIP-98, а релеи могут публиковать список тех, кто сейчас находится в комнате, через новое событие участников kind:39004.

NIP-71: несколько аудиодорожек на одно видео

PR #2255 расширяет соглашения по тегу imeta в NIP-71, чтобы одно видео могло содержать несколько аудиодорожек в виде отдельных тегов imeta, каждый со свойством l для языка и свойством ov, отмечающим дорожку на языке оригинала. Также добавляется свойство waveform, короткий список значений амплитуды через пробел, чтобы клиенты могли отрисовать форму волны аудиодорожки.

NIP-78: обычный, неадресуемый kind для данных конкретного приложения

PR #2292 добавляет в NIP-78 kind:78 как обычное событие, рядом с уже существующим адресуемым kind:30078. Различие важно для приложений, которым нужно хранить и запрашивать несколько событий одного типа: адресуемый kind хранит только последнее событие для каждого тега d, а обычный kind хранит все события. PR также добавляет новый kind в таблицу типов событий в README репозитория NIP.

NIP-85: переформулированное описание kind:10040

PR #2304 переформулирует один абзац в NIP-85. Формулировка, описывавшая kind:10040 как список "доверенных провайдеров услуг", меняется на описание списка как предпочитаемого пользователем источника для каждого результата, а также уточняется, что провайдер услуги может использовать несколько ключей и релеев, включая ключ, выданный для конкретного пользователя, когда результаты персонализированы именно под него.

C7: чат-представления ограничены kind 9

PR #2310 добавляет в соглашение C7 одну строку: клиенты, отображающие "чат-представление" как упорядоченный поток событий, ДОЛЖНЫ получать только события kind:9, чтобы не терять контекст между разными реализациями. Другие типы контента по-прежнему можно упоминать внутри сообщения kind:9 через цитирование, согласно NIP-18.

NIP-F4: новый черновой NIP для подкастов

PR #1093 стал самым крупным изменением дня с большим отрывом: он добавляет полноценную черновую спецификацию объёмом более ста новых строк. Он вводит NIP-F4, черновой, необязательный NIP, описывающий, как шоу и эпизоды подкастов публикуются в релеи и считываются из них в виде событий Nostr, устроенный так, чтобы вписаться в существующие сценарии работы подкаст-плееров. В NIP-F4 каждый подкаст представляет собой отдельную пару ключей Nostr, что позволяет совместить подкаст-присутствие с обычным профилем kind:0/kind:1. Информация уровня шоу, такая как название, обложка, описание и сайт, публикуется как заменяемое событие kind:10154, которое также может указывать ведущих, соведущих и редакторов по их публичным ключам. Отдельные эпизоды представляют собой отдельные события kind:54, публикуемые напрямую собственным ключом подкаста, каждое с названием, описанием и одним или несколькими тегами audio, указывающими на медиафайл эпизода. Поскольку иначе кто угодно мог бы ложно заявить себя автором подкаста, NIP-F4 добавляет событие kind:10064, через которое настоящие авторы подкаста публикуют собственный список подкастов, которые они авторизуют, чтобы заявленное авторство можно было проверить по этому встречному подтверждению, а не принимать на веру. PR также обновляет NIP-51, добавляя список "Favorite podcasts" типа kind:10054, позволяющий любому пользователю публично отметить, какие подкасты он слушает, используя теги p для публичных ключей подкастов и теги url для URL RSS/XML-фидов, и добавляет новые kind событий в таблицу kind в README репозитория NIP.

Просто пакет изменений, а не скоординированный релиз

Помимо двух изменений, касающихся личных сообщений, у этих девяти pull request нет общей нити. Они затрагивают не связанные между собой части протокола, от обработки подключений к релеям до видео в группах, хранения данных приложений и распространения подкастов, и просто прошли проверку в одном и том же окне длиной около девяноста минут 28 мая. Это был пакет изменений, а не тематический релиз, хотя самое крупное изменение дня с большим отрывом, новый NIP для подкастов, попало в то же окно, что и восемь гораздо более мелких.