--- read_when: - Вы хотите, чтобы OpenClaw получал личные сообщения через Nostr - Вы настраиваете децентрализованный обмен сообщениями summary: Канал личных сообщений Nostr через зашифрованные сообщения NIP-04 title: Nostr x-i18n: generated_at: "2026-07-13T17:55:33Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 24 provider: openai source_hash: 31fa283f706036a37795ddad71602058ba94388a9cb01044927c4bb2d83ba4a8 source_path: channels/nostr.md workflow: 16 --- Nostr — это загружаемый плагин канала (`@openclaw/nostr`), который позволяет OpenClaw получать зашифрованные личные сообщения NIP-04 через ретрансляторы Nostr и отвечать на них. Одна учетная запись на Gateway; только личные сообщения. ## Установка ```bash openclaw plugins install @openclaw/nostr ``` Используйте спецификацию пакета без версии, чтобы получать текущий официальный тег выпуска. Закрепляйте точную версию, только если необходима воспроизводимая установка. Из локальной рабочей копии (для процессов разработки): ```bash openclaw plugins install --link ``` После установки или включения плагинов перезапустите Gateway. Первоначальная настройка (`openclaw onboard`) и `openclaw channels add` отображают Nostr из общего каталога каналов после установки плагина. ### Неинтерактивная настройка ```bash openclaw channels add --channel nostr --private-key "$NOSTR_PRIVATE_KEY" openclaw channels add --channel nostr --private-key "$NOSTR_PRIVATE_KEY" --relay-urls "wss://relay.damus.io,wss://relay.primal.net" ``` Используйте `--use-env`, чтобы хранить `NOSTR_PRIVATE_KEY` в окружении, а не сохранять ключ в конфигурации (только для учетной записи по умолчанию). ## Быстрая настройка 1. Создайте пару ключей Nostr (если необходимо): ```bash # С помощью nak nak key generate ``` 2. Добавьте в конфигурацию: ```json5 { channels: { nostr: { privateKey: "${NOSTR_PRIVATE_KEY}", }, }, } ``` 3. Экспортируйте ключ: ```bash export NOSTR_PRIVATE_KEY="nsec1..." ``` 4. Перезапустите Gateway. ## Справочник по конфигурации | Ключ | Тип | Значение по умолчанию | Описание | | ------------ | -------- | ------------------------------------------- | -------------------------------------------------------- | | `privateKey` | string | обязательно | Закрытый ключ в формате `nsec` или hex; допускаются ссылки на секреты | | `relays` | string[] | `['wss://relay.damus.io', 'wss://nos.lol']` | URL-адреса ретрансляторов (WebSocket) | | `dmPolicy` | string | `pairing` | Политика доступа к личным сообщениям | | `allowFrom` | string[] | `[]` | Разрешенные открытые ключи отправителей | | `enabled` | boolean | `true` | Включить или отключить канал | | `name` | string | - | Отображаемое имя | | `profile` | object | - | Метаданные профиля NIP-01 | ## Метаданные профиля Данные профиля публикуются как событие NIP-01 `kind:0`. Управлять ими можно в Control UI (Channels -> Nostr -> Profile) или непосредственно в конфигурации. Пример: ```json5 { channels: { nostr: { privateKey: "${NOSTR_PRIVATE_KEY}", profile: { name: "openclaw", displayName: "OpenClaw", about: "Бот-помощник для личных сообщений", picture: "https://example.com/avatar.png", banner: "https://example.com/banner.png", website: "https://example.com", nip05: "openclaw@example.com", lud16: "openclaw@example.com", }, }, }, } ``` Примечания: - URL-адреса профиля должны использовать `https://`. - При импорте из ретрансляторов поля объединяются, а локальные переопределения сохраняются. ## Управление доступом ### Политики личных сообщений - **pairing** (по умолчанию): неизвестные отправители получают код сопряжения. - **allowlist**: личные сообщения могут отправлять только открытые ключи из `allowFrom`. - **open**: общедоступные входящие личные сообщения (требуется `allowFrom: ["*"]`). - **disabled**: игнорировать входящие личные сообщения. Примечания о применении политик: - Подписи входящих событий проверяются до применения политики отправителей и расшифровки NIP-04, поэтому поддельные события отклоняются на раннем этапе. - Ответы для сопряжения отправляются без расшифровки или обработки исходного содержимого личного сообщения. - Частота входящих личных сообщений ограничивается глобально и для каждого отправителя, а сообщения слишком большого размера отбрасываются до расшифровки. ### Пример списка разрешенных отправителей ```json5 { channels: { nostr: { privateKey: "${NOSTR_PRIVATE_KEY}", dmPolicy: "allowlist", allowFrom: ["npub1abc...", "npub1xyz..."], }, }, } ``` ## Форматы ключей Допустимые форматы: - **Закрытый ключ:** `nsec...` или 64-символьный hex - **Открытые ключи (`allowFrom`):** `npub...` или hex ## Ретрансляторы Значения по умолчанию: `relay.damus.io` и `nos.lol`. ```json5 { channels: { nostr: { privateKey: "${NOSTR_PRIVATE_KEY}", relays: ["wss://relay.damus.io", "wss://relay.primal.net", "wss://nostr.wine"], }, }, } ``` Рекомендации: - Используйте 2–3 ретранслятора для резервирования. - Избегайте слишком большого количества ретрансляторов из-за задержек и дублирования. - Платные ретрансляторы могут повысить надежность. - Локальные ретрансляторы подходят для тестирования (`ws://localhost:7777`). ## Поддержка протоколов | NIP | Состояние | Описание | | ------ | ------------------ | ----------------------------------------- | | NIP-01 | Поддерживается | Базовый формат событий и метаданные профиля | | NIP-04 | Поддерживается | Зашифрованные личные сообщения (`kind:4`) | | NIP-17 | Запланировано | Личные сообщения в подарочной упаковке | | NIP-44 | Запланировано | Версионированное шифрование | ## Тестирование ### Локальный ретранслятор ```bash # Запустите strfry docker run -p 7777:7777 ghcr.io/hoytech/strfry ``` ```json5 { channels: { nostr: { privateKey: "${NOSTR_PRIVATE_KEY}", relays: ["ws://localhost:7777"], }, }, } ``` ### Ручная проверка 1. Найдите открытый ключ бота в журналах Gateway или в `openclaw channels status` (hex; при необходимости преобразуйте его в npub в своем клиенте). 2. Откройте клиент Nostr (Amethyst, Damus и т. п.). 3. Отправьте личное сообщение на открытый ключ бота. 4. Убедитесь, что получен ответ. ## Устранение неполадок ### Сообщения не поступают - Убедитесь, что закрытый ключ действителен. - Убедитесь, что URL-адреса ретрансляторов доступны и используют `wss://` (или `ws://` для локального подключения). - Убедитесь, что `enabled` не имеет значения `false`. - Проверьте журналы Gateway на наличие ошибок подключения к ретрансляторам. ### Ответы не отправляются - Убедитесь, что ретранслятор принимает запись. - Проверьте исходящее подключение. - Проверьте, не применяет ли ретранслятор ограничения частоты запросов. ### Дублирующиеся ответы - Это ожидаемо при использовании нескольких ретрансляторов. - Сообщения дедуплицируются по идентификатору события; ответ формируется только при первой доставке. ## Безопасность - Никогда не добавляйте закрытые ключи в репозиторий. - Используйте переменные окружения для ключей. - Для рабочих ботов рассмотрите возможность использования `allowlist`. - Подписи проверяются до применения политики отправителей, а политика отправителей применяется до расшифровки, поэтому поддельные события отклоняются на раннем этапе, а неизвестные отправители не могут принудительно запустить полный набор криптографических операций. ## Ограничения (MVP) - Только личные сообщения (без групповых чатов). - Медиавложения не поддерживаются. - Поддерживается только NIP-04 (поддержка подарочной упаковки NIP-17 запланирована). ## Связанные материалы - [Обзор каналов](/ru/channels) — все поддерживаемые каналы - [Сопряжение](/ru/channels/pairing) — аутентификация личных сообщений и процесс сопряжения - [Группы](/ru/channels/groups) — поведение групповых чатов и ограничение по упоминаниям - [Маршрутизация каналов](/ru/channels/channel-routing) — маршрутизация сеансов для сообщений - [Безопасность](/ru/gateway/security) — модель доступа и усиление защиты