Clients are servers; all endpoints are created equal

DHttp, a decentralized HTTP protocol built on QUIC and HTTP/3, aims to eliminate the client-server hierarchy by making any endpoint both a client and a server, addressing network fragmentation that hinders AI agent adoption. The protocol extends DNS to enable universal connectivity across private networks, supporting agent-to-agent communication, local data access, and embodied AI control, while emphasizing secure and trustworthy interactions.

DHttp —— The Omniconnectible Internet A network where any two endpoints can achieve full connectivity. The DHttp Decentralized HTTP protocol is built on QUIC and HTTP/3 H3 , preserving the strengths of HTTP while eliminating the hierarchy between clients and servers. By extending DNS, DHttp makes domain names and DNS services universally accessible, enabling any endpoint—regardless of its network environment—to both initiate requests as a client and process them as a server. Why DHttp? Due to the widespread presence of private networks—including home LANs, virtual private networks VPNs , carrier-grade NATs, and enterprise intranets—they are invisible to one another, leaving the Internet severely fragmented. Network environments are becoming increasingly divided, and packets are not globally routable across the Internet. This isolation of communication is becoming a deep-seated barrier to the large-scale adoption of AI agents. The era of AI agents demands a more open and secure Internet. Typical Internet of Agents use cases include: Agent-to-Agent Communication : Allowing a user's agent to seamlessly communicate with a friend's agent over the public network. Local Data Access : Enabling agents to access local data sources—such as calendars and journals—to accurately understand a user's schedule, preferences, and memories. Embodied AI Control : Assigning tasks to embodied robots over a local home network. Secure and Trustworthy Communication : Ensuring that all such communication remains secure and trustworthy, while preventing unauthorized access. Think About It: Where an agent is deployed matters significantly. Consider the following questions: - Isn't it difficult for a cloud-based agent to access your home network? - Is your home network isolated from, and invisible to, your friends' home networks? - If home networks were visible to each other, would you worry about privacy and demand an access authorization mechanism? Current agents demand the privacy of a home network while simultaneously expecting seamless cross-network communication, convenience, and security. What is often forgotten, however, is that a LAN is a natural security boundary. Trust is usually assumed within a private network; once communication crosses that boundary, trust between networks drops to near zero. In real-world scenarios, cross-network connectivity and trust are a classic trade-off—and when it comes to security, truly responsible agents are few and far between. In the era of AI agents, every conversation, tool invocation, and command must be secure, trustworthy, and auditable. Smart devices have already evolved from flat tablets into physical robots. Because these robots have physical forms, the consequences of executing a malicious instruction could be catastrophic. Agents and Tools as Services As AI advances rapidly, coding assistants, OpenClaw, and other intelligent agents are becoming widespread. Driven by MCP, A2A, and Agent Orchestration technologies, the capabilities of AI continue to expand. However, whether they are agents or tools, they are fundamentally services that expose capabilities through APIs. This is exactly where the deeper problems lie: - A Mac mini running an agent lacks a server-grade network environment; it cannot be accessed externally with ease and must instead rely on chat applications like Telegram or WhatsApp. - The MCP protocol requires tools to run on an MCP server, meaning these tools demand server-grade networking with a public static IP—effectively shutting out a vast number of physical devices and edge tools. - Agent-to-agent communication still relies on forum-like intermediaries, failing to achieve truly direct, free peer-to-peer exchange. - Authentication and authorization between agents and tools are overly complex, and traditional frameworks like OAuth are already being stretched to their limits. These bottlenecks are, in fact, the result of deep architectural limitations within HTTP that continue to make networks increasingly closed. Trying to patch this on top of HTTP yields no cure; the problem must be solved fundamentally at the source. The DHttp protocol /en/docs/protocol/dhttp exists for exactly this purpose. DHttp allows any endpoint to act as a server, whether it resides on a cloud host or a local machine. By simply giving an agent endpoint a name /en/docs/security/authority , it can communicate with other endpoints seamlessly and securely. What DHttp Is Not Not a cloud-host-dependent network : It does not rely on cloud hosts to maintain connectivity. In networks that depend on cloud hosts for interconnection, if you remove the cloud hosts, peer-to-peer interconnection collapses instantly. DHttp is explicitly designed to liberate endpoint connectivity from its reliance on centralized cloud infrastructure. Not a VPN : A VPN is a virtual private tunneling technology that connects devices across remote networks into a private overlay network, making them behave as if they were on a single LAN. However, VPNs possess inherent network isolation—different VPN networks are invisible to one another. Even when bridged, they still face severe inter-network trust barriers. DHttp, by contrast, provides open cross-network connectivity, with access strictly regulated via Unified Identity, authentication, and authorization. Not decentralized web hosting like Freenet or IPFS : It is not a platform for anonymous publishing where content remains alive purely based on viewership. With DHttp, participants connect directly to exchange information and interact dynamically while preserving privacy and security. It does not seek anonymity; on the contrary, it places a much higher premium on the verifiable reliability of information sources. How Does DHttp Do It? Full Connectivity True connectivity means that any two endpoints can directly connect and communicate with one another. While HTTP only provides a form of "partial connectivity," DHttp achieves true full connectivity. Since the dawn of the Internet, pioneering scientists have shared a foundational belief: all computers are born equal, and all software and hardware must be treated with absolute parity. Connection Is Power: As long as an agent can freely connect to information, connect with others, and connect to tools, they possess the power to change the world. Rebuilding Trust Trust has always been the core issue. Due to excessive centralization, today’s Internet is steadily losing public trust to structural privacy leaks. The upcoming Internet of Agents demands an even higher level of trust, especially as autonomous entities begin to operate in physical spaces. While DHttp inherently inherits the robust security architecture of QUIC and HTTP/3, the DHttp Gateway takes it a step further by bringing enterprise-grade privacy and security to personal user data. By utilizing a Unified Identity /en/docs/security/authority framework with digital signatures and strict authentication, DHttp eliminates excessive third-party access privileges. It strengthens security mechanisms across the entire path—from network transport and identity verification to data integrity protection and accountability auditing—establishing a truly responsible foundation for the Internet of Agents. About Excessive Third-Party Access: Excessive third-party access means that a service provider retains ultimate control over your private, physical devices—such as smart home systems, connected vehicles, and domestic robots. This vulnerability stems from an Internet model that depends on cloud hosts for interconnection: when you are away and your robot is at home, they cannot communicate without an intermediary. Because these cloud hosts are owned and managed by external providers, having a third party hold the keys to your physical environment is a deeply alarming reality. Everything Is a Service "Apps are dead" and "80% of apps will vanish" are rapidly becoming an undeniable reality. However, APIs will live forever: even if AI agents have no use for a GUI, they will always rely on CLIs and APIs. Local CLI tools are naturally compatible with AI agents and have already driven powerful agent capabilities. However, the inherently local nature of CLIs stifles broader, large-scale distributed collaboration, making open HTTP APIs a far superior choice. Moving forward, the primary consumers of any device or service will be AI agents. There is no longer any reason to build a GUI app for an agent; instead, developers must expose agent-friendly HTTP APIs. Ultimately, what defines a device or service will no longer be its static description, but rather the collective surface of the HTTP APIs it exposes. In the AI era, open APIs are the next unstoppable wave, and the DHttp is definitive choice for shaping HTTP APIs tailored for agents: - Decentralized Deployment: DHttp removes the restriction that agents and tool services must run inside cloud hosts. - Zero Platform Lock-in: It is completely decoupled from third-party ecosystems, meaning consumers never have to worry about platform monopolies. - Frictionless Access: Accessing a tool or service requires zero account registration; seamless usage is granted purely through secure authorization. - Robust Security: The underlying access control model is elegantly simple yet exceptionally secure, effectively eliminating the risk and damage of unauthorized access.