Connecting OpenClaw AI Agents to Nostr - Decentralised Messaging for Bots

Nostr is one of those technologies that most businesses haven't heard of, but the people who have heard of it tend to feel very strongly about it. It's a decentralised social protocol - no company owns it, no single server runs it, and messages are cryptographically signed by the sender. Think of it as the protocol layer that apps like Damus and Amethyst are built on.

So why would you want to connect an AI agent to it? Fair question. For most Australian businesses, Slack or Microsoft Teams is where the action is. But there's a growing community of developers and early adopters who live on Nostr, and if your AI agent needs to be reachable through encrypted direct messages on a protocol that doesn't depend on any single vendor, OpenClaw now supports that.

The official OpenClaw Nostr channel documentation covers every configuration detail. Let me walk through the practical setup and share some honest thoughts on where this fits.

What This Actually Does

OpenClaw's Nostr integration lets your AI agent receive and respond to encrypted direct messages (DMs) via the NIP-04 protocol. Someone on Nostr sends a DM to your bot's public key, OpenClaw decrypts it, processes it through your agent pipeline, encrypts the response, and sends it back.

It's direct messages only - no group chats, no public posts, no media attachments. This is an MVP integration and it's honest about its limitations. NIP-17 (gift-wrapped DMs with better metadata privacy) and NIP-44 (newer encryption standard) are on the roadmap but not implemented yet.

For the types of use cases this supports today - personal assistant bots, notification handlers, simple query-response agents - DMs are the main interaction pattern anyway.

Installing the Plugin

Nostr isn't bundled with OpenClaw by default. It's an optional plugin, which makes sense given that most deployments won't need it.

The easiest way to install is through OpenClaw's onboarding process. Run openclaw onboard or openclaw channels add and select Nostr from the list of optional channels. It'll prompt you to install the plugin from npm or from a local path if you're running a development build.

For manual installation:

openclaw plugins install @openclaw/nostr

If you're working on the plugin itself or need a local checkout:

openclaw plugins install --link <path-to-openclaw>/extensions/nostr

Restart the gateway after installing. The plugin won't activate until you do.

Key Generation and Configuration

Nostr uses public-key cryptography. Every identity on the network is just a keypair - a private key (nsec) that you keep secret and a public key (npub) that others use to find and message you.

If you don't already have a keypair, generate one:

# Using nak (a Nostr command-line tool)
nak key generate

Then configure OpenClaw. The minimal setup looks like this:

{
  channels: {
    nostr: {
      privateKey: "${NOSTR_PRIVATE_KEY}",
    },
  },
}

Export the key as an environment variable:

export NOSTR_PRIVATE_KEY="nsec1..."

Never commit private keys to version control. I shouldn't have to say this, but I've seen it happen enough times that it bears repeating. Use environment variables or a secrets manager.

For non-interactive setups (CI/CD pipelines, automated deployments), you can configure everything from the command line:

openclaw channels add --channel nostr --private-key "$NOSTR_PRIVATE_KEY"

You can also pass custom relay URLs at setup time:

openclaw channels add --channel nostr --private-key "$NOSTR_PRIVATE_KEY" --relay-urls "wss://relay.damus.io,wss://relay.primal.net"

Relays - How Messages Get Delivered

Nostr doesn't have a central server. Instead, it uses relays - independent WebSocket servers that store and forward messages. When your bot connects, it connects to one or more relays and listens for DMs addressed to its public key.

The defaults are relay.damus.io and nos.lol, which are two of the most popular public relays. For most setups, this is fine. You can customise the list:

{
  channels: {
    nostr: {
      privateKey: "${NOSTR_PRIVATE_KEY}",
      relays: ["wss://relay.damus.io", "wss://relay.primal.net", "wss://nostr.wine"],
    },
  },
}

A few practical tips on relay selection. Two to three relays gives you good redundancy without creating problems. Too many relays means higher latency and duplicate messages (though OpenClaw deduplicates by event ID, so it handles this gracefully). Paid relays like nostr.wine tend to be more reliable and have less spam. For testing, you can run a local relay using strfry:

docker run -p 7777:7777 ghcr.io/hoytech/strfry

Then point OpenClaw at ws://localhost:7777. Note the ws:// instead of wss:// for local connections.

Access Control - Who Can Talk to Your Bot

This is the part that matters most for any production deployment. OpenClaw provides four DM policies, and choosing the right one depends on your use case.

Pairing mode (default) is clever. When an unknown sender DMs your bot, they get a pairing code instead of a response. This prevents random Nostr users from consuming your AI compute. The user presents the pairing code through another channel to verify their identity, and then they're allowed to interact going forward. It's similar to how you pair a Bluetooth device - a small friction step that prevents abuse.

Allowlist mode is stricter. Only public keys explicitly listed in your config can DM the bot. Everyone else is ignored silently.

{
  channels: {
    nostr: {
      privateKey: "${NOSTR_PRIVATE_KEY}",
      dmPolicy: "allowlist",
      allowFrom: ["npub1abc...", "npub1xyz..."],
    },
  },
}

Open mode accepts DMs from anyone. You need to explicitly set allowFrom: ["*"] as a safety check - OpenClaw won't let you accidentally leave the door open.

Disabled mode ignores all inbound DMs entirely. Useful if you want the bot to have a Nostr presence (maybe for outbound notifications later) without accepting inbound messages.

One security detail worth noting: sender policy checks happen before OpenClaw even attempts to decrypt the message. Unknown senders in allowlist mode can't force your server to do the cryptographic work of decryption. That's a thoughtful design choice that prevents a class of denial-of-service attacks.

Setting Up a Profile

Your bot's Nostr identity can have a profile - display name, avatar, bio, website, and other metadata published as a NIP-01 kind:0 event. You can manage this through the OpenClaw Control UI or set it directly in config:

{
  channels: {
    nostr: {
      privateKey: "${NOSTR_PRIVATE_KEY}",
      profile: {
        name: "myagent",
        displayName: "My AI Agent",
        about: "AI assistant for our team",
        picture: "https://example.com/avatar.png",
        website: "https://example.com",
      },
    },
  },
}

Profile URLs must use HTTPS. If you import profile data from relays, local overrides are preserved - the merge is non-destructive.

When Does This Make Sense for Australian Businesses?

Honestly? For most Australian businesses right now, Nostr isn't where their customers or employees are. If you're building AI agents for internal operations, Slack and Teams are the obvious choices. For customer-facing agents, WhatsApp and web chat are where the volume is.

But there are a few scenarios where Nostr makes genuine sense:

Developer-facing products. If your target audience includes developers, crypto-native users, or privacy-focused communities, they're more likely to be on Nostr than the average person. Meeting them on their preferred protocol shows you understand their values.

Vendor-independent infrastructure. Some organisations want their AI agent reachable through a protocol that isn't controlled by a single company. If Slack changes their API pricing or WhatsApp updates their terms of service, your Nostr channel keeps working regardless.

Privacy-first use cases. NIP-04 encrypted DMs mean the relay operators can't read message content. For AI agents handling sensitive queries, this provides an additional layer of privacy beyond what you get with most commercial messaging platforms.

Experimentation and prototyping. If you're exploring decentralised protocols and want to test how an AI agent behaves in that environment, OpenClaw makes it straightforward to add Nostr alongside your existing channels without disrupting anything.

Testing Your Setup

The quickest way to test:

1. Start the gateway. Note the bot's npub from the logs.
2. Open a Nostr client (Damus on iOS, Amethyst on Android, or any web client).
3. Send a DM to the bot's npub.
4. Check that a response comes back.

If messages aren't arriving, check the basics: is the private key valid, are the relay URLs reachable, is the channel enabled in config? Gateway logs will show relay connection status and any errors.

If you're getting duplicate responses, that's expected when using multiple relays. The same message arrives via each relay, but OpenClaw deduplicates by event ID, so only the first arrival triggers a response. The duplicates are dropped silently.

Where This Is Heading

The current implementation is DMs only with NIP-04 encryption. The roadmap includes NIP-17 (gift-wrapped DMs, which hide metadata from relays) and NIP-44 (versioned encryption with better security properties). Both would make the Nostr channel more suitable for privacy-sensitive production use.

For now, it's a solid foundation. If your AI agent strategy includes reaching users on decentralised protocols - or if you just want to experiment with what's possible - this is an easy channel to add to an existing OpenClaw deployment.

If you're building AI agents and want help with the architecture - choosing the right channels, setting up access control, designing the agent pipeline - our AI agent development team works with Australian organisations on exactly this. We also offer OpenClaw as a managed service if you'd rather not run the infrastructure yourself. And for broader AI strategy conversations, our AI consulting practice can help you figure out where AI agents fit into your business.