| name | concepts |
| description | Understand ContextVM core concepts, architecture decisions, and frequently asked questions. Use when users need clarification on what ContextVM is, why it uses Nostr, decentralization benefits, public vs private servers, network topology, or comparisons with traditional MCP. |
ContextVM Concepts
Core concepts, architectural decisions, and common questions about ContextVM.
What is ContextVM?
ContextVM is a protocol that liberates the Model Context Protocol (MCP) by running it over Nostr—a simple, open communication network built on cryptographic, censorship-resistant, and permissionless foundations.
Rather than relying on centralized infrastructure like domains, OAuth, or cloud hosting, ContextVM allows anyone to run or access services using only Nostr and an internet-connected device.
Key Insight: ContextVM operates at the transport layer, meaning existing MCP servers and clients can be used without code changes through the Gateway and Proxy tools.
Why Run MCP Over Nostr?
Running MCP over Nostr eliminates traditional infrastructure barriers:
| Traditional Requirement | Nostr Solution |
|---|
| Domain name + DNS | Not needed |
| Static IP address | Not needed |
| OAuth/API keys | Built-in public key cryptography |
| Public hosting | Any device with internet |
| Port forwarding | Outbound-only relay connections |
Nostr provides:
- Identity via public/private key cryptography
- Discovery through service announcements on relays
- Transport via signed and encrypted events
- Payments (optional) using Bitcoin and Lightning Network
Decentralization Model
ContextVM uses Nostr relays as a distributed message bus:
Client ⇄ Nostr Relay(s) ⇄ Server
- No central directory or gatekeeper
- Anyone can run a server and announce it (or keep it private)
- Servers can connect to multiple relays for redundancy
- Services can go offline and come back online without breaking references
The Dual API Advantage
ContextVM presents a unique dual API that lets you write your server once and make it accessible to both humans and machines:
For Developers: Build web apps, desktop applications, or CLI tools that interact with ContextVM servers directly using standard MCP patterns.
For AI Agents: LLMs operate the same service naturally through MCP's self-documenting capabilities (tools/list, schemas, etc.).
Build Once, Deploy Everywhere: Your service becomes a reusable component accessible through code, web interfaces, or AI agents.
Public vs Private Servers
| Feature | Public Server | Private Server |
|---|
| Announcements | Published to relays | Not published |
| Discovery | Via relay queries | Known public key only |
| Access Control | Open or whitelisted | Whitelisted |
| Encryption | E2E encrypted | E2E encrypted |
| Payments | Optional | Optional |
Use Private Servers For: Personal tools, team infrastructure, sensitive operations, development/testing.
Network Topology
Communication flows through three actors:
- Client: MCP client using ContextVM Proxy or SDK
- Relay(s): WebSocket servers routing encrypted events
- Server: Service using ContextVM Gateway or SDK
Flow:
- Server optionally publishes announcement to relays
- Client discovers service (public) or uses known pubkey (private)
- Client sends encrypted request via relays
- Server receives, decrypts, processes, responds
All messages are signed and end-to-end encrypted (NIP-44).
ContextVM vs Traditional Remote MCP
| Requirement | Traditional MCP (HTTP/SSE) | ContextVM |
|---|
| Domain name | Required | Not needed |
| DNS configuration | Required | Not needed |
| Static IP | Required | Not needed |
| Port forwarding | Required | Not needed |
| TLS certificate | Required | Implicit via encryption |
| Authentication | OAuth/API keys | Built-in pubkey crypto |
| Hosting | Cloud VM/VPS | Any device |
| Discovery | Centralized directories | Decentralized relays |
| Censorship resistance | Low | High |
Authentication
Authentication is built into Nostr's public key cryptography:
- Every request is signed by the client's private key
- Servers verify signatures to confirm identity
- Server operators can:
- Allow all signed requests (open access)
- Whitelist specific public keys (private access)
- Require payment before processing
No OAuth, passwords, or API keys needed.
Security
All client-server communication is end-to-end encrypted using NIP-44:
- Messages encrypted to recipient's public key
- Only intended party can decrypt
- Compromised relays cannot read content or impersonate parties
- Ensures confidentiality, integrity, and non-repudiation
MCP Possibilities Beyond AI
MCP is a protocol for invoking remote functions—any computational task, not just AI:
- SSH Access Portal: Secure remote machine access
- Encryption as a Service: GPG operations in sandboxed environment
- Data Processing: Validate, transform, analyze data on demand
- Code Sandbox: Execute untrusted code safely
- IoT Command Hub: Trigger physical actions remotely
- Math & Simulation: Complex calculations or symbolic math
Getting Started
Deploy a Server (Gateway)
gateway-cli --private-key "your-key" \
--relays "wss://relay.nostr.org" \
--server "python my-mcp-server.py" \
--public
Connect a Client (Proxy)
proxy-cli --private-key "your-key" \
--relays "wss://relay.nostr.org" \
--server-pubkey "npub1..."
Build Native (SDK)
Use @contextvm/sdk for TypeScript applications with NostrServerTransport and NostrClientTransport.
References
