NIP-19 получает ограничение

Зачем нужно ограничение длины

TLV-сущности NIP-19 по своей конструкции открыты и не ограничены. nprofile или nevent могут содержать произвольное число TLV-элементов, включая несколько подсказок о релеях, поэтому в прежней версии спецификации ничего не говорилось о том, насколько большой может стать такая строка, прежде чем декодер должен прекратить попытки её разобрать. Спецификация уже требовала от декодеров игнорировать нераспознанные типы TLV вместо того, чтобы выдавать ошибку. В сочетании с отсутствием верхней границы длины декодеру приходилось быть готовым пройти произвольно длинную строку только для того, чтобы обнаружить, что большую её часть нужно проигнорировать.

Установка рекомендованного потолка даёт разработчикам конкретное число для проверки перед тем, как выполнять какую-либо работу по разбору строки. Декодер, увидевший строку длиннее 5000 символов, может отклонить её сразу же, вместо того чтобы тратить время и память на прохождение TLV-записей, которые теоретически могут продолжаться бесконечно. Это стандартный защитный приём для любого формата, принимающего входные данные переменной длины, на которые может повлиять злоумышленник: ограничивать размер входных данных прежде, чем делать с ними что-либо затратное.

Что не меняется

Ограничение сформулировано как СЛЕДУЕТ, а не ДОЛЖНО, и никак не затрагивает саму кодировку. npub, nsec, note, nprofile, nevent и naddr сохраняют ту же структуру bech32 и тот же формат TLV для сущностей, которые его используют. Ничего не меняется в том, как создаются или декодируются уже существующие короткие сущности, вроде простого npub, поскольку при обычном использовании они и так далеко не дотягивают до нового потолка. Строка затрагивает лишь немногочисленные случаи, когда сущность -- как правило, nprofile или nevent, нагруженная несколькими подсказками о релеях -- иначе не имела бы определённой верхней границы.

Более широкий контекст

Строки NIP-19 предназначены для вставки в чат, встраивания в ссылки и кодирования в QR-коды -- в контекстах, где неограниченная строка представляет собой практическую проблему, а не просто неудобство при разборе. У QR-кода есть физические ограничения размера, а клиент, отрисовывающий произвольно длинную строку, выполняет неограниченную работу в ответ на неаутентифицированный пользовательский ввод. Рекомендация в 5000 символов даёт каждой реализации одно и то же число, вокруг которого можно проектировать систему, вместо того чтобы каждый клиент угадывал безопасную границу самостоятельно.

Это однострочное изменение в NIP, который уже содержит несколько подобных примечаний. NIP-19 также предписывает декодерам игнорировать нераспознанные типы TLV и ограничивает использование npub и nsec отображением и копированием, не допуская их в события NIP-01 и ответы NIP-05. Каждое из этих примечаний устраняет ситуацию, в которой реализация могла бы столкнуться с вводом, к которому она не была готова. Ограничение размера -- та же идея, применённая ко всей строке целиком, а не к одной части её содержимого.

Ничего из этого не меняет, как выглядит обычный, корректный npub, nprofile, nevent или naddr. Типичный ключ или ссылка на событие, даже с парой подсказок о релеях, занимает от силы несколько сотен символов. Строка про 5000 символов -- это подстраховка для случаев за пределами такого диапазона, а не изменение того, как эти сущности обычно строятся или читаются.