Encryption and private servers - New Security and Privacy Features in DVMCP
Introducing New Security and Privacy Features in DVMCP
We're excited to announce a new update to DVMCP, bringing enhanced privacy and security with encryption for transport communication and the launch of private server discovery. These features are designed to offer greater flexibility, stronger data protection, and new ways to manage access within the DVMCP ecosystem.
Seamless Encryption for Private Communication
Security is at the core of this release. DVMCP now allows you to encrypt communications between clients and servers using nip-17 and giftwraps, ensuring that the communication stays confidential as it travels across the network. By default, DVMCP uses a flexible encryption system based on three straightforward modes:
- Disabled mode ensures backward compatibility or operation in trusted environments, with encryption turned off.
- Optional (the default) uses message format mirroring: if a client sends an encrypted message, the server responds in kind; if not, responses are unencrypted. This provides seamless compatibility without guesswork.
- Required mode enforces encryption on every message. Unencrypted messages are rejected.
Configuring the encryption mode is as simple as adding a line to your YAML configuration file, letting operators choose the right balance of security and accessibility for their needs. This configuration can be done in both packages, bridge and discovery, which means that whether you are consuming or serving, you can ensure that encryption suits your needs.
Due to this new feature, we also updated the DVMCP relay to accept events with kind 1059 giftwraps, which are stored temporarily as ephemeral events are, using the same ring buffer ephemeral events use. This ensures we can handle large loads of them efficiently. Note that giftwraps are sometimes rejected by some relays due to their strong encryption, as they could be a vector of spammy attacks. The DVMCP relay is free to use, and you can connect with this URL: 'wss://r.dvmcp.fun'.
Private (Unannounced) Servers
The update also introduces a new way to run and connect with servers privately. Private servers remain unannounced on relays, making them invisible to the wider network unless specifically targeted. Clients can connect to the servers from a provider by knowing the provider's public key, or target an individual server from a provider adding its server ID.
This is made possible by following the same MCP handshake pattern. Communication begins with the client sending an initialization request directly to the server. The server responds with its details and capabilities, and then the client can request to list available capabilities, tools, resources, or prompts. The handshake is completed when the client confirms successful initialization.
How Encryption and Private Discovery Work Together
Both encryption and private server discovery are fully compatible. If the client supports encryption it will attempt the handshake in a encrypted way, if the server the client is attempting to connect supports encryption, it signals this in the handshake to ensure all subsequent communication remains protected. If the server the client is attempting to connect doesn't support encryption but the client does in 'optional' (default) mode, it will fall back to unencrypted communication and stay unencrypted for the subsequent requests. If the client has 'required' encryption mode but the server doesn't support encryption, the handshake is rejected as the client will not fall back to unencrypted communication.
You can run a fleet of private, unannounced servers that only accept connections from trusted clients, and you can also ensure this authorization access using the pubkey whitelist configuration, with all data exchanges encrypted. This architecture is ideal for sensitive projects, custom enterprise deployments, or any environment where data privacy and controlled access are mission-critical.
Other updates: For this update, we also refactored the configuration wizzard of the packages to be more intuitive, also added the handling of kind 1059 giftwraps to the DVMCP relay, and we added a badge in dvmcp.fun for servers that support encryption, also all the servers offered by DVMCP have being updated to the latest version of DVMCP and now they support encryption.
Why These Changes?
Our goal is to make DVMCP both secure and adaptable. Encryption ensures that only intended recipients can interpret the payloads, while private server discovery puts you in control of the visibility in the network, and who can access your services. By combining these features, DVMCP offers a versatile platform for deploying MCP servers, whether you want to broadcast to the world or remain 'invitation only'.
Get started with the latest DVMCP today to take advantage of these privacy and security enhancements, and tailor your deployments for the world you want to build.
Next steps:
The next steps for DVMCP are, write documentation and create a docs page, to stay up-to-date with the MCP specification, as it recently received an update on 2025-06-18 that introduced new features such as structured tool output schemas, elicitation, and other enhancements. Also as part of this process, it is important to take a step back, review our current implementation, and understand how we can further improve it.
We are designing a refactor of the DVMCP packages, as the MCP protocol and its SDK have evolved. During the process of creating DVMCP, we have gained valuable insights that will help us structure our packages in a more lightweight and versatile manner, reducing some accumulated technical debt. This will allow us to make DVMCP more library-like, which is the direction we have already started to explore with the @dvmcp/commons package. We now have a clearer understanding of how to build a better architecture for our packages, and we are ready to fully implement these improvements.