NullClaw speaks Nostr natively via NIP-17 (gift-wrapped private DMs) and NIP-04 (legacy encrypted DMs), enabling decentralized, censorship-resistant AI assistant communication.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/nullclaw/nullclaw/llms.txt
Use this file to discover all available pages before exploring further.
Prerequisites
nakCLI tool installed and in$PATH- Your Nostr public key (npub or hex format)
- Access to Nostr relays
Installation
Install nak
- Go Install
- Homebrew
- Binary Download
Quick Setup
Provide Owner Pubkey
Enter your personal Nostr pubkey (npub or hex) - this is always allowed through DM policy.
enc2:... in config.
Configuration
Basic Setup
Edit~/.nullclaw/config.json:
config.json
Complete Configuration
config.json
Configuration Options
private_key (required)
Your bot’s Nostr private key (nsec or hex), encrypted at rest:Manual key generation
Manual key generation
nsec1... value in config. NullClaw will encrypt it on first run if secrets.encrypt is enabled.owner_pubkey (required)
Your personal Nostr public key (always allowed regardless ofdm_allowed_pubkeys):
relays (required)
Nostr relays for publishing and listening:Recommended relay sets
Recommended relay sets
General purpose:Paid relays (better spam filtering):Privacy-focused:
dm_allowed_pubkeys
Pubkeys allowed to DM the bot:- Allow All
- Specific Users
- Owner Only
owner_pubkey is ALWAYS allowed, regardless of this setting.Profile Fields (Optional)
Configure bot’s Nostr profile metadata:How It Works
NIP-17 Gift Wrapped DMs
NullClaw’s primary DM protocol:- Listening: Bot subscribes to kind:10050 inbox relays
- Receiving: Unwraps gift-wrapped DMs using
nak gift unwrap - Deduplication: Tracks rumor IDs to prevent duplicate deliveries across relays
- Sending: Wraps replies with
nak gift wrapand publishes to sender’s relays
NIP-04 Legacy DMs
Backward compatibility for older clients:- Receiving: Listens for kind:4 events
- Decrypting: Uses
nak decrypt - Sending: Mirrors sender’s protocol (NIP-04 reply to NIP-04 sender)
Protocol Mirroring
Bot automatically remembers which protocol each sender used and replies using the same protocol.Startup Flow
Running the Channel
Gateway Mode
Standalone Channel
Check Status
- Connection status
- Active relays
- Message count
- Last activity
Security
Encrypted Private Keys
Encrypted Private Keys
Private keys are encrypted with ChaCha20-Poly1305:Keys are only decrypted into memory while channel is running.
Pubkey Allowlists
Pubkey Allowlists
Restrict who can message your bot:Empty array = owner only.
Key Zeroing
Key Zeroing
On channel stop, private keys are zeroed in memory before free:
Rumor Deduplication
Rumor Deduplication
Prevents replay attacks by tracking seen rumor IDs with timestamps.
Troubleshooting
nak command not found
Bot Not Receiving Messages
Duplicate Messages
If you receive duplicate responses:- Check if same rumor is delivered via multiple relays
- NullClaw should deduplicate automatically
- Check logs for “duplicate rumor” messages
Private Key Decryption Failed
Relay Connection Issues
Advanced Usage
External Signing (bunker://)
Use external signer instead of embedded private key:config.json
bunker:// URIs directly to nak --sec.
Multiple Nostr Accounts
Currently, Nostr channel doesn’t support multiple accounts (unlike Telegram/Discord). To run multiple bots:- Run separate NullClaw instances
- Use different config directories
- Different ports for each instance
Kind:10050 Inbox Relays
Bot automatically publishes kind:10050 (inbox relays) on startup, announcing where it listens for gift-wrapped DMs. Clients following NIP-17 will look up your inbox relays and publish there.Protocol Details
Event Kinds
| Kind | Protocol | Description |
|---|---|---|
| 4 | NIP-04 | Legacy encrypted DMs |
| 14 | NIP-17 | Rumor (inner event) |
| 1059 | NIP-17 | Gift wrap (outer event) |
| 10050 | NIP-17 | Inbox relay list |
Timestamps
Bot discards events withcreated_at before channel start time, preventing old messages from being processed on restart.
Session Keys
Session keys are derived from:- Sender pubkey
- Channel account ID
- Protocol type (nostr)
nostr:main:<sender_pubkey>
Performance
- Startup: <2ms (excluding nak subprocess spawn)
- Message latency: Depends on relay response time (typically 100-500ms)
- Memory: ~500KB per active session
- Relay connections: Persistent WebSocket to each relay
Next Steps
Sandboxing
Configure security sandboxing
Memory Backends
Set up vector memory