NIP-86 получает семь методов и забирает приглашения NIP-43

Четыре метода, замыкающие существующие пары

PR #2477 был слит в 17:16 UTC 23 сентября как коммит 5b99209. Он добавляет двенадцать строк в 86.md и не удаляет ни одной. Каждый из четырёх добавленных методов представляет собой недостающую половину того, что уже было в документе.

unallowevent и unbanevent обратны allowevent и banevent. Оба принимают ["<32-byte-hex-event-id>", "<optional-reason>"] и возвращают true. В части API, работающей с pubkey, уже были unallowpubkey и unbanpubkey, так что оператор мог отменить решение по автору. В части, работающей с событиями, отменить внесение ни в один из двух списков было нельзя.

listallowedevents дополняет listbannedevents, который можно было прочитать и до этого изменения, тогда как список разрешённых прочитать было нельзя. listdisallowedkinds дополняет listallowedkinds: метод disallowkind существовал, но ничего не позволяло прочитать его результат.

Переработка час спустя

PR #2481 был слит в 18:21 UTC как коммит 182a13e и оказался крупнейшим из трёх: 202 добавленные строки и 87 удалённых в одном файле. Он превращает плоский список пунктов в отдельный раздел ### на каждый метод, и в каждом из них над строками params и result стоит фраза описания.

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

banpubkey:     Should automatically remove the pubkey from the allow list.
unbanpubkey:   Should not automatically add the pubkey to the allow list.
allowpubkey:   Should automatically remove the pubkey from the ban list.
unallowpubkey: Should not automatically add the pubkey to the ban list.

Те же четыре утверждения теперь появились и для методов работы с событиями, которые часом ранее дополнил #2477. Вместе они отвечают на вопрос, оставленный открытым прежним списком: являются ли список разрешённых и список запрещённых независимыми множествами или двумя положениями одного переключателя. Ответ асимметричен. Добавление в один список удаляет из другого, а удаление из одного не добавляет в другой, так что pubkey или событие могут не находиться ни в одном из них.

Метод supportedmethods тоже получил фразу. Теперь она гласит: "Lists the methods supported by the relay. May be customized to match permissions assigned to the authenticated user." Сам метод не изменился, и документ уже разграничивал операторов через assignrole, но ответ, зависящий от вызывающей стороны, означает, что два оператора, опрашивающие одно реле, могут получить разные списки методов.

Все эти фразы используют "should" и "may" строчными буквами. В файле нет ни одного ключевого слова RFC 2119 в верхнем регистре ни до переработки, ни после неё.

Коды приглашений уходят за административное API

PR #2408 был слит в 01:14 UTC 24 сентября как коммит 62d5fed и затрагивает два файла. В 86.md он добавляет listclaims, createclaim и deleteclaim для кодов приглашений, описанных в NIP-43. В 43.md он удаляет семнадцать строк и добавляет одну.

Удалённые строки составляют весь раздел "Invite Request", который описывал, как пользователь получал код:

{
  "kind": 28935,
  "pubkey": "<nip11.self>",
  "tags": [
    ["-"],
    ["claim", "<invite code>"],
  ],
  // ...other fields
}

Пользователь запрашивал это событие у реле, а реле подписывало его ключом из поля self своего документа NIP-11. Вместо этого в 43.md теперь стоит одна фраза: "Users can request a claim using the NIP 86 createclaim method."

Эти два пути ведут не в одно и то же место. kind 28935 был запросом, который шёл по собственному соединению пользователя с реле. NIP-86 представляет собой похожий на JSON-RPC протокол поверх HTTP на том же URI, что и websocket, и его раздел авторизации требует действительного события NIP-98 в заголовке Authorization, возвращая 401 при его отсутствии. createclaim находится за этим заголовком, а этим путём пользуется оператор реле, а не будущий участник.

Ссылка на событие, которое больше не описано

Раздел Implementation в 43.md по-прежнему гласит: "Clients MUST only request kind 28935 events from and send kind 28934 events to relays which include this NIP in the supported_nips section of its NIP 11 relay information document."

Эта фраза пережила удаление. Событие, порядок запроса которого она описывает, больше нигде в файле не определено, и это одно из немногих требований NIP-43, записанных в верхнем регистре.

Что замена не переносит

Удалённый абзац заканчивался пояснением, почему запрос был эфемерным событием: реле должны были явно включить это поведение, генерируя claim по запросу, что позволяло им выдавать разный claim на каждый запрос, выдавать их только определённым пользователям или задавать им срок действия.

Ничего из этого в трёх новых методах не сохранилось. createclaim принимает [claim] и возвращает true, то есть код предоставляет вызывающая сторона, а не получает сгенерированный. listclaims возвращает "an array of NIP 43 invite codes". Ни формат, ни длина, ни срок действия, ни одноразовость claim в добавленном тексте не указаны, а deleteclaim остаётся единственным описанным способом отозвать код.