Protocol paper v1.0 | Decent Network

Abstract

Decent Network is a permissionless communication substrate in which identity is a self-generated keypair, communication is authorized by relationships rather than a provider, and endpoints remain reachable across NAT and firewalls without platform accounts or public ports. This paper describes the system as deployed today: identity, friendship authorization, DHT discovery, direct and relayed transport, optional offline delivery, naming, the Peer SDK, Dora, DecentLAN, AgentNet, reference applications, the security boundary, and honest operational limitations.

1. Motivation: communication is still platform infrastructure

Bitcoin demonstrated that money does not require a central institution. Ethereum demonstrated that computation does not require a central platform. Identity, relationships, private communication, and device reachability are still normally supplied by platform accounts and centralized clouds.

An application needs more than storage and consensus. It needs a durable identity, a way to establish consent, discovery of changing network locations, delivery to devices behind NAT, offline behavior, and software that remains available on the user’s behalf. These capabilities became practical inside centralized services first, so even decentralized applications continued to rent their communication layer.

AI makes the missing layer visible. A durable agent role cannot safely depend on a consumer messaging account or one model vendor. A2A standardizes what agents say; MCP standardizes the tools they use. Neither defines who owns an agent identity, who may reach it, or how a packet reaches its machine privately. Decent Network supplies that identity and transport layer.

2. Communication-first architecture and Carrier lineage

The mainstream internet addresses public servers through IP and DNS, while most personal devices remain behind NAT and firewalls. That asymmetry pushes storage, compute, and always-on software into cloud accounts. Decent treats communication reachability as a first-principles capability and builds an identity-addressed overlay spanning cloud, private servers, and personal devices.

Decent Network is a direct evolution of the battle-tested Elastos Carrier design described by the Elastos SmartWeb work. Carrier supplied a permissionless DHT, public-key identities, friend relationships, onion discovery, relays, and application payloads. Decent preserves wire compatibility with the deployed network while modernizing the implementation and product surface for TypeScript, private service networking, and AI agents.

Lineage matters: @decentnetwork/peer starts from an installed protocol and production client network, not from an untested whitepaper wire format.

3. Three-layer architecture

The original Decent model separates product experience, communication infrastructure, and physical resources. Applications can change without replacing identity or relationships; endpoints can move between personal, private, and cloud machines without changing the application protocol.

Product Surface — mobile and desktop apps, web interfaces, services, and AI agents.
Decent Network Overlay — identity-addressed communication, friendship authorization, DHT discovery, messages, events, and private reachability.
Resource Nodes — personal devices, private servers, and cloud nodes that host users, roles, data, compute, and network services.

Product surfaces use personal, private, and cloud resources through the Decent communication overlay.

4. The Friend Network and DHT primitive

The Distributed Hash Table is the routing backbone of the Friend Network. Peers cooperate to maintain routing knowledge; no central database decides whether one identity may discover another. A peer searches by the friend’s public-key identifier and resolves the endpoint currently announced by that identity.

The DHT is not the social graph. Friendship remains local, mutual, and private to the endpoints. DHT keys are ephemeral, while the durable userid remains stable. Presence and capability information propagate only where the protocol and relationship permit it, and disappear when a peer goes offline rather than becoming a permanent public profile.

Identity — self-generated public-key address.
Relationship — explicit mutual friendship and local revocation.
Routing — permissionless DHT lookup of the current endpoint.
Presence — ephemeral online state shared with authorized peers.
Application payloads — messages, files, events, and private-network packets above the session.

5. Identity: a keypair, not an account

A Decent identity is created locally. There is no registration authority, account database, issuer, or platform-level revocation switch. The endpoint persists its long-term keystate in peer.save and presents two public forms.

The address is the long Base58 string distributed to receive friend requests. It includes the identity public key, checksum, and a rotatable request surface inherited from the Carrier/toxcore lineage. The userid is the shorter stable public-key identifier used after a relationship has been established.

The runtime separates long-term identity keys, ephemeral DHT keys, and per-session encryption keys. Friend traffic uses NaCl crypto_box (Curve25519 / XSalsa20 / Poly1305). The TypeScript implementation is wire-compatible with the native Carrier SDK and has been tested end-to-end with production Beagle iOS clients.

Address: shared to receive a friend request.
Userid: used to address an established friend.
DHT key: ephemeral discovery identity, separate from the durable role.
Session keys: protect each live peer connection.

Design consequence: no company or governance process sits between an endpoint and its identity. Key custody remains the endpoint operator’s responsibility.

6. Agent identity belongs to a durable role

For agents, the unit that receives a keypair should be both durable and accountable. A session, subagent, worktree, or temporary model process is too short-lived to own trust. A physical machine may host several unrelated duties and is therefore too broad.

The durable unit is the role: operator, referee, auditor, support agent, or another continuing duty. A model can change from Claude to GPT or Gemini; the role keeps its friendships, message history, and accountability trail. In frameworks with a persistent agent object, that agent maps naturally to one identity. In Claude Code, Codex, Cursor, or shell workflows, the configured daemon represents the role and concurrent sessions act through it.

Human-readable names should bind to these roles rather than to hardware or model vendors, allowing a role to move machines, rotate keys through an explicit process, or change the model on shift without rebuilding its social graph.

7. Friendship as authorization

Communication requires a mutual relationship. Peer A sends a friend request to Peer B’s address; B accepts; both endpoints persist the relationship. Before acceptance, A cannot send ordinary messages or route application traffic to B. The network begins unreachable and is opened by consent.

This single primitive serves as the anti-spam boundary, the scan-resistance boundary, and the first authorization boundary. Publishing an address is a local choice. Acceptance can be manual or automated through an operator-controlled allow-list. Revocation is unilateral: removing a friend stops new sessions from that identity.

AgentNet composes friendship with more precise policy. A friend can be granted one TCP or UDP service, a time window, or a named support capability instead of access to an entire machine. The relationship answers who; the ACL answers what and for how long.

Default: unknown identities are unreachable.
Grant: mutual friend handshake.
Automation: local allow-list, not a platform policy.
Revocation: unilateral and local.
AgentNet extension: service-, protocol-, and time-scoped ACL.

8. Transport across hard networks

The transport stack answers a practical question: how does encrypted traffic reach a device with no public IP, behind changing NAT and firewall conditions, without placing a platform in the trust path? The runtime chooses the best available path while the endpoint identity remains stable.

DHT discovery — bootstrap into a Kademlia-style Carrier DHT, announce the current endpoint, and locate a friend route.
Direct UDP — use NAT hole punching and a direct encrypted session when both networks permit it.
Onion control path — deliver friend discovery and presence through multi-hop paths so intermediate nodes do not learn the complete relationship query.
TCP relay — when UDP is unavailable, forward the end-to-end encrypted live session through a relay that cannot read its content.
Express store-and-forward — optionally hold an encrypted payload for a recipient that is temporarily offline.

The stack is deployed across the China–overseas corridor. Direct paths are preferred; relay and Express are availability services, not confidentiality authorities.

9. Naming and address allocation

Cryptographic identities are portable but not memorable. Dora is a normal Decent peer that provides name and private-address resolution for AgentNet. It maps userid, human-readable name, and 10.86.x.x address through a DHCP-like Discover, Offer, Request, Acknowledge flow.

Dora runs without root, privileged sockets, or a virtual interface. DecentLAN nodes friend a Dora identity and query it through encrypted text messages. Clients cache their assigned addresses; if every configured Dora is temporarily offline, existing routes continue and new clients can fall back to a local address policy.

External naming systems can act as integration surfaces. A holder of a crypto name can sign a binding from that name to a Decent userid. The registry retains its namespace; Decent adds the ability for the resolved identity to receive a relationship request and private message.

10. Reference implementations

Decent Network is not a whitepaper-only protocol. The following components are separately installable and deliberately divided by privilege and responsibility.

@decentnetwork/peer — pure TypeScript identity, DHT discovery, friendship, encrypted sessions, text, files, relay, and optional offline delivery.
@decentnetwork/dora — normal-user naming and private-address registry for AgentNet.
@decentnetwork/lan — TUN routing, 10.86.x.x private networking, IPAM, DNS, ACLs, audit, proxy, CLI/TUI, and local desktop console.
Beagle — the human-facing mobile and desktop communication application, interoperable with the same identity and message network.
OpenClaw Beagle Channel — a TypeScript channel plus local native sidecar that gives an OpenClaw agent a Beagle address, DMs, group context, and media.
agent-mesh — a daemon, CLI, files, and hooks that expose the messaging tier to Claude Code, Codex, Gemini, cron jobs, and other file-capable agents.

11. Developer-first adoption and network effects

Open communication networks face an adoption problem: a new identity network is only useful when applications and counterparties can use it. Decent addresses this by shipping infrastructure through immediate developer and operator utility rather than asking users to migrate a social graph first.

The Peer SDK lets an application embed identity and messaging. agent-mesh gives two coding agents a useful private channel in minutes. DecentLAN connects an existing SSH, HTTP, RDP, TCP, or UDP service without rewriting it. Beagle provides a human communication surface. Each entry point creates a real endpoint and relationship that remains compatible with the rest of the network.

Developer-first bootstrapping — installable SDKs, CLIs, and skills.
Utility before migration — solve a messaging or reachability problem immediately.
Interoperable applications — Beagle, AgentNet, channels, and third-party apps share identities and relationships.
Operator expansion — independent bootstrap, relay, Express, Dora, and exit roles improve reachability without owning users.

12. AgentNet: the machine-side network

AgentNet is the machine-side product surface rather than a new base protocol. It exposes Decent capabilities at three increasingly powerful tiers.

At the messaging tier, agent-mesh runs one peerd daemon for a durable role. The daemon keeps a warm DHT connection and services append-only inbox, outbox, request, and status files. Local agents use instant file or CLI operations while the daemon handles join latency, retries, announcements, and sessions.

At the network tier, DecentLAN creates a private virtual network. Existing SSH, HTTP, RDP, TCP, and UDP applications continue using their normal protocols through private addresses. At the support tier, a customer approves a provider identity and grants a specific service for a limited period, producing an auditable support path without public ports or screen sharing.

13. Case study: accountable agents on separate machines

The authors operate a live trading system with separated agent roles: an operator implements and deploys, a referee issues directives and verifies exchange truth, and an independent auditor performs adversarial review. The roles run on different machines and should not impersonate one another.

Before the mesh, a human copied tasks, file references, evidence, and replies between sessions. The human was the message bus. With agent-mesh, the referee sends a directive from its role identity, the operator returns a checkpoint or artifact, and the referee verifies the live result before approving the next action.

This workflow exposed concrete failures, including a phantom position that the exchange never held, post-hoc mutation of closed ledger rows, and risk logic that silently converted winners to breakeven exits. The general lesson is not about trading: accountable agent teams require durable identities, explicit relationships, tamper-resistant message transport, and independent verification.

14. Security posture and honest scope

Decent changes one important default. The public-IP internet begins reachable by everyone and attempts to secure services afterward. Decent begins unreachable and opens a route through an explicit relationship. This reduces the audience of a private service before its own authentication and hardening are considered.

The protocol provides identity unforgeability from key possession, end-to-end confidentiality and integrity for friend traffic, relationship-gated reachability, and no central plaintext message custodian. Relay, bootstrap, and Express operators are trusted for availability, not confidentiality.

It does not solve endpoint compromise, operating-system security, poor key custody, vulnerable services deliberately exposed to friends, or application-level authorization mistakes. Those responsibilities remain with the endpoint and application operator.

Observable metadata: DHT participation and traffic timing are not hidden completely.
Offline delivery: depends on an Express node’s retention and availability window.
Delivery semantics: instrumentation and behavior under churn are still maturing.
Cryptography: Curve25519-family keys; no post-quantum migration is implemented.
Infrastructure diversity: supported by the protocol, but default operator diversity still needs improvement.

16. Deployed status and roadmap

Deployed today: @decentnetwork/peer on npm; wire interoperability with Beagle iOS; agent-mesh in production multi-agent use; DecentLAN private networking; Dora naming and address allocation; Beagle on iOS and Android; and the OpenClaw Beagle Channel implementation.

Near-term work focuses on simpler invitation and pairing, delivery receipts, relay robustness, diversified default bootstrap operators, reproducible two-agent quickstarts, skill distribution, and external name-binding pilots.

Bootstrap, relay, Express, Dora, and regional exit roles are independently operable. Measurement, service quality, and sustainable operator economics remain future work. There is no token and none is required or planned in the current phase; usage and reliability precede financialization.

17. Conclusion

Decent Network makes a narrow, testable claim: a keypair is enough to be an identity; a mutual relationship is enough to open communication; and a network of such peers is enough to support private messaging, agent coordination, and service reachability without a platform account.

The standard for the project is working infrastructure. The protocol must be reproducible from a terminal, interoperable with deployed clients, honest about its limitations, and useful through applications without becoming owned by any one application.