Skip to content

Integration notes: Autonomous agent (OpenClaw) + White Noise + nostr-rs-relay — lessons learned #53

@sloaner0

Description

@sloaner0

Integration notes: Autonomous agent + White Noise + nostr-rs-relay — lessons learned

I recently completed a working integration of marmotd with an autonomous AI agent (OpenClaw), which communicates bidirectionally with White Noise Android (v0.3.0) via a self-hosted nostr-rs-relay. The path to a working setup involved several non-obvious gotchas that cost significant debugging time. Documenting them here in hopes of saving others from the same pain.


Environment

  • marmotd v0.5.2
  • White Noise Android v0.3.0
  • nostr-rs-relay (self-hosted, behind Caddy reverse proxy with TLS)
  • OpenClaw autonomous agent framework v2026.2.26

Issue 1: White Noise requires kind 0, 10050, 10051, and 10002 — not just kind 443 keypackages

White Noise validates a user before allowing you to initiate a chat. It checks for the presence of kind 10050 (NIP-17 DM relay list) and kind 10051 (MLS key package relay list) events. If these are missing, the app shows "user not on White Noise" even if valid kind 443 keypackages exist on relays.

Fix: Publish kind 0 (profile metadata), kind 10050, kind 10051, and kind 10002 for your agent's nostr identity before attempting to initiate any conversations from the client side.


Issue 2: nostr-rs-relay pubkey whitelist blocks NIP-59 giftwrap delivery

If you run a private nostr-rs-relay with pubkey_whitelist configured, outbound messages from White Noise will silently fail. White Noise uses ephemeral random key pairs for NIP-59 giftwrap (kind 1059) outer wrappers — these ephemeral keys are not in any whitelist and will be rejected by the relay.

Fix: Remove pubkey_whitelist from your relay config, or find a way to allow kind 1059 from any pubkey while restricting other kinds. The relay can still be kept private via network-level controls (e.g., localhost-only binding + TLS reverse proxy).

Note: White Noise publishes kind 445 MLS messages directly for group messages — verify which event kinds your relay needs to accept for your specific client.


Issue 3: groupPolicy: "allowlist" blocks messages by group ID, not sender pubkey

If your agent config uses groupPolicy: "allowlist" with groupAllowFrom set to a sender pubkey, messages will still be silently dropped. The allowlist check operates on the nostr group ID, not the sender's pubkey. The log entry that reveals this:

drop message (group not allowed) group=<nostr_group_id>

Fix: Use groupPolicy: "open" if you want the agent to respond in any group it has joined.


Issue 4: Agent requires requireMention: false for 1:1 style conversations

By default, marmotd requires an @mention to dispatch a message to an agent in a group context. White Noise does not support typed @mentions, so messages will be silently buffered and never dispatched.

The isOneOnOneGroup() check looks for groups with 2 or fewer members, or a group named "DM" (as set by the Pika desktop client). White Noise does not set this name, so all groups are treated as multi-person groups requiring mentions.

Fix: Add to your agent config:

"groups": {
  "*": {
    "requireMention": false
  }
}

The "*" wildcard applies to all groups globally.


Issue 5: Cross-context messaging must be explicitly enabled for agent replies

If your agent receives messages on a marmot channel but is session-bound to a different channel (e.g. Signal), replies will fail with:

Cross-context messaging denied: action=send target provider 'marmot' while bound to 'signal'

Fix:

"tools": {
  "message": {
    "crossContext": {
      "allowAcrossProviders": true
    }
  }
}

Working minimal marmot channel config for an autonomous agent

"marmot": {
  "enabled": true,
  "relays": [
    "wss://your-private-relay.example.com",
    "wss://relay.damus.io",
    "wss://nos.lol"
  ],
  "autoAcceptWelcomes": true,
  "groupPolicy": "open",
  "groups": {
    "*": {
      "requireMention": false
    }
  },
  "owner": "<your_nostr_pubkey_hex>"
}

Hope this helps. Happy to answer questions about the setup.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions