Frequently Asked Questions

ContextVM is a protocol that liberates the Model Context Protocol by running it over Nostr—a simple, open communication network built on cryptographic, censorship-resistant, and permissionless foundations. It enables anyone to run computational services from any device without centralized dependencies.

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. It transforms any computational service into a discoverable, accessible, and monetizable resource—while preserving privacy, security, and user sovereignty.

This is more than technology—it is a movement. ContextVM represents a fundamental shift in how we think about computation and infrastructure, building the foundation for a more equitable decentralized internet.

No, you don't need an LLM to use ContextVM. ContextVM presents a unique dual API that lets you write your server once and make it accessible to both humans and machines through one protocol.

You can use it programmatically to build the backend of any application and consume it through a custom interface or web app, while the same service can be operated by LLMs without any changes because it is built on MCP, the first common language for large language models.

All the power from MCP is available out of the box as ContextVM plugs into the transport layer—AI compatibility, input and output schemas, rich primitives like tools, static resources, prompts, real-time communication, and bidirectional communication are all there. As MCP advances, ContextVM advances at the same pace.

The Dual API Advantage

• For Developers: Build web apps, desktop applications, or command-line tools that interact with ContextVM servers directly. Call remote functions as if they were local.
• For AI Agents: LLMs operate the same service naturally through MCP's self-documenting capabilities.
• Build Once, Deploy Everywhere: Your service becomes a reusable component in any language or platform—accessible through code, web interfaces, or AI agents.

Not necessarily. While developers can build and deploy servers using the SDK, end users can access ContextVM services through:

• Nostr-enabled apps
• MCP hosts or AI agents in platforms like Cursor, Claude, or other MCP-compatible tools

All users need is:

• A Nostr identity (npub)
• An internet connection
• Optional: A Lightning wallet for paid services

1. Learn: Explore the full documentation at docs.contextvm.org
2. Install skills:

   npx cvmi add
   npx cvmi add --skill overview

3. Deploy a server:

   npx cvmi serve -- npx -y @modelcontextprotocol/server-filesystem /tmp

4. Connect a client:

   npx cvmi use npub1...

5. Build: Use the TypeScript SDK for custom integrations: github.com/contextvm/ts-sdk
6. Engage: Follow us on Nostr or join community channels to contribute and stay updated.

Running MCP over Nostr eliminates traditional infrastructure barriers:

• No need for a domain name, DNS setup, or static IP
• No OAuth, API keys, or centralized authentication
• No public hosting, server provisioning, or port forwarding

Nostr provides:

• Identity via public/private key cryptography
• Discovery through service announcements on relays
• Transport via signed and encrypted Nostr events
• Payments (optional) using Bitcoin and the Lightning Network

This enables a new model: you can run your own infrastructure, from any device, and expose it securely to the world—or keep it private—without depending on third parties.

ContextVM uses Nostr relays as a distributed message bus. Servers publish service announcements (or not, if private), and clients discover and connect to them using only public keys.

There is no central directory, gatekeeper, or required service provider. Anyone can run a server, announce it (or not), accept requests, and optionally receive payments—without permission.

By minimizing trust and removing infrastructure gateways, ContextVM creates a truly permissionless environment for computation.

ContextVM communication flows through three main actors:

Client ⇄ Nostr Relay(s) ⇄ Server

Here's how they interact:

• Client: Runs an MCP client (e.g., an AI agent). Uses the ContextVM Proxy or SDK to send encrypted requests via Nostr relays.
• Relay(s): Public or private WebSocket servers that route encrypted events. They act as intermediaries, not end points.
• Server: Runs your service (e.g., a tool, script, or AI function). Uses the ContextVM Gateway or SDK to listen for incoming requests on relays.

Flow:

1. Server (optional) publishes a signed service announcement to one or more relays
2. Client discovers the service (if public) by querying relays—or knows the server's public key in advance (if private)
3. Client sends an encrypted request to the server's public key via relays
4. Server receives, decrypts, processes, and sends an encrypted response back
5. All messages are signed and end-to-end encrypted

This model lets you be your own infrastructure provider. No third-party hosts your code, controls access, or sits in the middle.

Deploying a remote MCP server the traditional way involves significant setup. ContextVM dramatically simplifies and secures this process.

Example: Consider an SSH server. With standard MCP, you'd need a domain, static IP, DNS, TLS, and OAuth. With ContextVM, generate a private key, pick relays, run the gateway. It's instantly reachable—without exposing your network. Authentication? Your Nostr public key. Payment? Optional. No middlemen.

And you can keep it private: Just omit --public, share your public key with your team, and you have a secure, zero-config remote access solution.

MCP is often associated with AI agent tooling—but it's much broader. MCP is a protocol for invoking remote functions, which means it can wrap any computational task, not just AI operations.

With ContextVM, you can turn any script, process, or service into a secure, callable, and globally accessible API—and optionally monetize it.

Examples of General Computation Use Cases

• SSH Access Portal: Securely access remote machines via signed Nostr requests
• Encryption as a Service: Offer file or text encryption via GPG in a sandboxed environment
• Data Processing Engine: Validate, transform, or analyze data on demand
• Code Sandbox: Execute untrusted code safely and return results
• IoT Command Hub: Trigger physical actions (e.g., "turn on lights") from anywhere
• Math & Simulation Engine: Run complex calculations or symbolic math remotely

Be Your Own Infrastructure Provider

With ContextVM, you are the infrastructure. There's no need to rent servers, configure cloud firewalls, or rely on SaaS platforms.

This empowers individuals and communities to reclaim control over computation, data, and value exchange. Success looks like communities running their own infrastructure without relying on corporate providers, individual developers launching services from their garages reaching global audiences instantly, and creators earning Bitcoin directly from their computational work without intermediaries.

This is the foundation for a new computational commons where the right to compute is as fundamental as the right to speak.

Deploying a service is simple:

Deploying an existing MCP server:

1. Run CVMI alongside your existing MCP server using cvmi serve
2. Provide your private key, relay configuration, and the command to start your server
3. Choose whether to publish a public announcement

Example:

npx cvmi serve -- npx -y @modelcontextprotocol/server-filesystem /tmp

You can also configure cvmi serve with a config file or environment variables for keys, relays, remote MCP URLs, and visibility.

Creating a MCP server with Nostr Transport:

1. Write the functionality of your server using the MCP SDK
2. Instead of using one of the default MCP transports, use NostrServerTransport from @contextvm/sdk
3. Run it

Your service is instantly accessible—no public IP, DNS, or firewall configuration needed.

ContextVM supports two modes of service operation:

In short: private servers offer the same capabilities as public ones—they just don't broadcast their existence. This is ideal for personal, team, or closed-group use.

Example: Run an SSH wrapper as a private MCP server. Only you and your team can access it—securely from anywhere, no more hassle.

• Public servers: Clients query Nostr relays for service announcements.
• Private servers: Clients must know the server's Nostr public key (npub) in advance. No discovery—only direct connection.

Once connected, the interaction is identical: secure, bidirectional, and encrypted.

No. ContextVM operates at the transport layer, so existing MCP servers and clients can be used without code changes.

You can:

• Use the ContextVM Gateway to expose a standard MCP server over Nostr
• Use the ContextVM Proxy to let a standard MCP client access Nostr-hosted services

These tools act as transparent bridges, translating between standard transports and Nostr transport.

Authentication is built into Nostr's public key cryptography:

• Every request is signed by the client's private key
• Servers verify the signature to confirm identity
• Server operators can:
  • Allow all signed requests (open access)
  • Whitelist specific public keys (private access)
  • Require payment before processing

This replaces OAuth, passwords, and API keys with a simpler, more secure model.

Yes. ContextVM communication is always signed, and it supports end-to-end encryption using Nostr's NIP-44 encryption standard when encryption is enabled by the client and server.

When encrypted, messages are encrypted to the recipient's public key, so only the intended party can decrypt them.

Even if a relay is compromised, attackers cannot:

• Read message content
• Impersonate sender or receiver
• Modify messages without detection

This ensures confidentiality, integrity, and non-repudiation across untrusted networks.

Payments are optional and designed for creators who wish to monetize their services.

• Supported: Bitcoin, especially via Lightning Network microtransactions
• Mechanism: Servers can trigger Lightning invoice requests before fulfilling an operation
• Validation: Servers validate the payment to unlock service access
• Flexibility: Pricing models (per call, time-based, etc.) are configurable

The ContextVM TypeScript SDK (@contextvm/sdk) enables native integration with the protocol. It includes:

• NostrServerTransport: It allows an MCP server to expose its capabilities to the Nostr network, making them discoverable and usable by any Nostr-enabled client
• NostrClientTransport: It enables MCP clients to communicate with remote MCP servers over the Nostr network.
• Built-in support for encryption, signing, relay management, and discovery

With the SDK, you can build servers and clients that are born on Nostr, maximizing control, security, and performance.

CVMI (ContextVM Interface) is the CLI tool for working with the ContextVM ecosystem.

• cvmi add: install ContextVM skills and guidance
• cvmi serve: expose an MCP server to the Nostr network
• cvmi use: connect to a remote ContextVM server from a standard MCP client workflow

It is the most practical way to get started today if you want to explore the protocol without building everything from scratch.

Yes. ContextVM is fully open source and community-driven. The protocol specification, SDKs, gateway, proxy, and tooling are all publicly available

You can view, contribute to, or fork the code on GitHub: github.com/contextvm

ContextVM is the evolution of the earlier project known as DVMCP. The rebrand was driven by:

• Clarity: Avoiding confusion with similarly named projects like "Damn Vulnerable MCP"
• Focus: Emphasizing its role as a context-aware transport layer, not a virtual machine
• Technical evolution: Reflecting a more modular, MCP-compliant architecture
• Governance: Signaling a shift to a community-governed, open standard

The underlying vision—democratizing decentralized AI and general computation—remains unchanged.

Scalability is inherited from the Nostr ecosystem:

• Redundancy: Servers can connect to multiple relays for high availability
• Client Resilience: Clients can subscribe to many relays to ensure message delivery
• Stateless Design: Requests are self-contained and verifiable
• Decentralized Discovery: No single point of failure for service lookup

Services can go offline and come back online without breaking references—only the current connection state matters.