OpenClaw on Nostr

Nostr is a downloadable channel plugin that lets OpenClaw receive and answer encrypted direct messages over Nostr relays, using the NIP-04 encryption scheme, with one account per Gateway and direct messages only. Here is the setup, the configuration reference, the profile the bot publishes, the access policies and the security ordering the docs spell out, the relay advice, how to test against a local relay, and the limitations of the current plugin.

Setup

• Install the plugin from the registry, or link a local checkout for development; installing applies it to a running Gateway, and onboarding and the channel-add command surface Nostr once it is installed.
• Generate a keypair if you do not have one, put the private key in the config as an environment reference, export the variable, and restart; the non-interactive add command takes the key and optional relay URLs directly, with a use-env flag to keep the key in the environment for the default account.
• The reference is small: the private key in nsec or hex form with secret references allowed, a relay list defaulting to two public relays, the DM policy defaulting to pairing, the allow list, an enabled flag, a display name and a profile object.
• Profile metadata is published as a standard profile event and can be managed from the Control UI’s channel page or set in config: name, display name, about text, picture, banner, website and the two address fields, with URLs required to be HTTPS and relay imports merging fields while preserving local overrides.

Signatures are verified before sender policy, and sender policy is enforced before decrypt, so forged events are rejected early and unknown senders cannot force full crypto work.

Access control

Four DM policies: pairing, the default, where unknown senders get a pairing code; allowlist, where only the public keys in the allow list can message; open, which requires the wildcard entry; and disabled. The enforcement order is the quote above, and it has consequences the docs make explicit: pairing replies are sent without decrypting or processing the original message body, inbound messages are rate-limited globally and per sender, and oversized payloads are dropped before decryption. Keys come in the usual formats, a private key as nsec or 64-character hex and public keys as npub or hex.

Relays and testing

• Use two or three relays for redundancy and avoid too many, since each adds latency and duplication; paid relays can improve reliability, and a local relay is fine for testing.
• For a local test, run a relay container, point the config at it, note the bot’s public key from the logs or the channel status, and message it from a Nostr client; duplicate responses across several relays are expected and deduplicated by event id, so only the first delivery triggers a reply.
• When nothing arrives, check the key, the relay URLs and scheme, the enabled flag and the connection errors in the logs; when nothing goes out, check that the relay accepts writes, outbound connectivity, and relay rate limits.

OpenClaw pairing explains the approval code the default policy sends, and OpenClaw on Matrix is the other decentralised protocol in the channel list, with encryption of its own.

Limits and security

The plugin supports the basic event format with profile metadata and the NIP-04 encrypted direct message kind; gift-wrapped messages and versioned encryption are planned, not shipped. It is direct messages only, with no group chats and no media attachments. The security list is short: never commit private keys, keep them in environment variables, and consider the allowlist policy for production bots. OpenClaw secrets explains the reference syntax the private key accepts.

On Diali

Nostr is not among the channels Diali connects today: the ones we run are WhatsApp, Telegram, Discord, Slack, Mattermost, Matrix, SMS and voice, and a self-run instance is where this plugin lives for now. Connect your first channel in five minutes shows our connect flow, Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary.

• One key, two or three relays, DMs only.
• Verify, then policy, then decrypt.
• Gift wrap and versioned encryption are planned, not shipped.