NIP-92 добавляет резервные URL и blurhash для изображений профиля
Изображения профиля и баннеры теперь могут нести те же встроенные медиаданные, что и вложения, не перемещая свои URL из документа профиля kind 0.
Nostr WoT Newsroom
Материал подготовлен редакцией Nostr WoT на основе указанных первоисточников и опубликован автоматически, без индивидуальной проверки человеком.
Pull request #2494 был включён в спецификации Nostr 5 октября 2026 года. Он добавляет в NIP-92 раздел о профилях: событие метаданных kind 0 теперь может связывать теги imeta с URL полей picture и banner.
Патч невелик: 35 новых строк в NIP-92 и одна перекрёстная ссылка в NIP-24. Но он закрывает практический пробел. Заметка уже могла описать вложенное изображение через размеры, MIME-тип, хеш, альтернативный текст, blurhash и резервные адреса. Изображение профиля могло передать только основной URL внутри JSON-строки в поле content.
URL остаётся в профиле
Изменение не заменяет существующую форму kind 0. picture остаётся в JSON профиля, а banner остаётся необязательным полем из NIP-24. Новые данные находятся в обычных тегах того же события.
Тег imeta относится к полю профиля только тогда, когда его значение url в точности равно значению picture или banner. Сокращённый URL, конечный адрес перенаправления или URL, отличающийся только строкой запроса, совпадением не считается. Теги, не соответствующие ни одному полю, следует игнорировать.
Точное сравнение создаёт однозначную связь между двумя представлениями внутри одного подписанного события. Оно также не позволяет применить старый тег к новой картинке только потому, что обе размещены на одном хосте.
В примере спецификации для фото указаны MIME-тип, SHA-256, размеры, blurhash и резервный URL, а для баннера указаны MIME-тип, хеш и размеры. NIP-92 разрешает любое поле из NIP-94, поэтому издатель может добавить alt, size, миниатюры и другие метаданные. Для тега imeta обязательны лишь url и ещё одно поле; расширенные данные остаются необязательными.
Сбой хоста больше не обязан оставлять пустой аватар
Самое заметное дополнение называется fallback. Если основное изображение не загружается, клиенты должны попробовать объявленные резервные URL. Аватар или баннер сможет пережить сбой хоста или перенос файла, если автор опубликовал ещё одну доступную копию.
Остальные поля решают другие задачи. blurhash даёт компактную заглушку на время загрузки. dim позволяет заранее выделить место с правильными пропорциями. alt предоставляет описание для доступности. Поле x может содержать SHA-256 файла, но NIP-92 не делает его обязательным, а клиенту всё равно нужно проверить хеш, чтобы он служил контролем целостности.
Это подписанные подсказки автора профиля, а не слой хранения. Изменение не загружает зеркало, не доказывает, что резервный адрес останется доступным, и не заставляет клиента использовать какое-либо поле. В нормативном тексте в основном стоят MAY и SHOULD; профилю по-прежнему нужен рабочий основной URL, а совместимость зависит от реализаций.
Заменяемые события требуют правила обслуживания
Kind 0 является заменяемым: более новое событие того же открытого ключа вытесняет старый профиль. Поэтому сохранение метаданных становится частью публикации.
Новый раздел говорит, что клиент при публикации нового kind 0 должен переносить теги imeta для неизменившихся фото и баннеров и удалять теги изображений, которые больше не используются. Без этого правила изменение отображаемого имени могло бы случайно стереть резервные адреса и альтернативный текст. Перенос всех старых тегов был бы хуже, поскольку оставил бы подписанные данные для картинок, на которые профиль уже не ссылается.
Клиенты без поддержки дополнения могут по-прежнему читать picture и banner. Они вправе игнорировать новые теги, поэтому формат обратно совместим. Однако некоторое время поведение будет различаться: один клиент покажет fallback или blurhash, а другой отобразит сломанное основное изображение.
Что изменилось, а что нет
Принятый текст задаёт общий формат описания медиа профиля. Он не сертифицирует хосты, не переводит профили на контентно-адресуемое хранение и не делает хеш обязательным. Существующие профили также не обогащаются автоматически. Теги появятся лишь после публикации нового kind 0, который их содержит.
В pull request сказано, что Ditto и Armada уже реализуют эту форму, но это заявление автора предложения, а спецификация не ведёт реестр совместимости. Другим клиентам нужно внедрить и публикацию, и отображение, прежде чем метаданные будут надёжно перемещаться по экосистеме.
Безопасная последовательность для разработчика узка: оставить канонический URL в JSON профиля, публиковать не более одного подходящего тега imeta для каждого изображения, сравнивать URL точно, сохранять теги только для неизменившихся полей и считать каждый fallback недоверенным сетевым вводом. Это постепенное улучшение, но оно даёт изображениям профиля те же средства восстановления и представления, которые уже были у вложений Nostr.
Источники
Каждое утверждение в этом материале ссылается на первоисточник.
- NIP-92: imeta-теги для picture и banner в kind 0 — nostr-protocol/nips (5 октября 2026 г.)
- NIP-92 Метаданные медиавложений — nostr-protocol/nips (5 октября 2026 г.)
- NIP-24 Дополнительные поля и теги метаданных — nostr-protocol/nips (5 октября 2026 г.)
- NIP-94 Метаданные файлов — nostr-protocol/nips (5 октября 2026 г.)