Ploinky Wormhole
Ploinky Wormhole is a decentralized communication protocol built for an agentic world. It replaces the traditional client-server paradigm with direct peer-to-peer connections between autonomous agents, enabling modern messaging, secure file transfer, and cross-organizational choreography — all without a central authority controlling your data.
Why P2P in an Agentic World
The rise of AI agents changes everything about how systems communicate. When software agents act on behalf of humans, projects, or organizations, the old client-server model becomes a bottleneck. Every message routed through a central server adds latency, creates a single point of failure, and forces trust in infrastructure you don't control.
Wormhole flips this model: agents connect directly to each other. There is no central mailbox, no server-side inbox, no cloud storage of your conversations. Instead, each agent runs locally in its workspace, owns its identity, and negotiates directly with peer agents what to share, how to share it, and under what conditions.
This is not just a technical improvement — it is a fundamental shift in how decentralized systems should communicate when autonomy, privacy, and sovereignty matter.
Two Components, One Protocol
Wormhole has exactly two moving parts:
- Ploinky Server Wormhole — a lightweight rendezvous and signaling service. It does not store messages, does not read content, does not decide who is trusted. Its only job is to help agents find each other and establish a direct WebRTC connection. Think of it as a phone book and a dial tone, not a post office.
- Ploinky Agent Wormhole — the local service running inside each workspace. It owns identities, manages contacts, enforces policies, negotiates with peer agents, and transfers content directly over P2P channels. All decisions about trust, acceptance, and data handling happen here — at the edge, under your control.
The server makes the introduction. The agents do the actual work. Once connected, the server is out of the picture entirely.
DIDs: Modern Identity for Decentralized Communication
Every participant in Wormhole is identified by a Decentralized Identifier (DID) in the form:
did:wormhole:<server-domain>:<identifier>
A DID is not an email address, not a username, not an account on someone else's platform. It is a cryptographic identity that you control. The server only publishes the public key — the private key never leaves your agent.
DIDs support key rotation with cryptographic proof, so if you need to change keys, the history is verifiable. Your contacts can see that the key changed and decide whether to re-confirm trust. This is how identity works when no central authority vouches for you: the cryptography speaks for itself.
A single workspace can have many DIDs — one per user, one per agent, one per project, one per functional inbox. Each has its own identity, its own policies, and its own mailbox.
A Modern Replacement for Email
Wormhole Mail gives you the structured communication experience of email — subjects, recipients, CC/BCC, attachments, threads, tags, filters — but without the infrastructure baggage. No IMAP servers, no spam filters you don't control, no provider lock-in.
When you send a Wormhole message, your agent contacts the recipient's agent directly. If the recipient knows you, the message flows through. If not, it arrives as a connection request — the recipient sees who wants to talk and decides whether to accept, reject, or block. No spam, no guessing, no server-side filtering that might lose important messages.
Messages are signed and encrypted end-to-end. The server never sees the content. The recipient's agent organizes everything locally in a SQLite mailbox that you own and can back up, migrate, or audit.
Communication and Choreography Between Organizations
Wormhole is not just for person-to-person messaging. It is designed for inter-organizational communication — companies talking to companies, workspaces talking to workspaces, agents talking to agents.
Imagine a research consortium where five organizations collaborate without sharing their raw data. Each organization runs its own DPU Agent with local data. The Wormhole protocol enables them to coordinate federated learning rounds: the coordinator sends model updates through Wormhole, each participant trains locally, and only the approved model updates travel back — never the data.
Or consider a supply chain where manufacturers, suppliers, and logistics providers need to exchange documents, status updates, and automated task requests. Each party controls its own workspace, its own policies, and its own data. Wormhole provides the communication layer that makes this possible without a central platform.
This is organizational choreography: independent entities coordinating through a protocol that respects their autonomy, enforces their policies, and keeps their data local.
Federated Learning Over Wormhole
One of the most powerful use cases for Wormhole is federated learning — training AI models across organizations without centralizing data. The architecture works like this:
- Coordinator Agent defines the federation, invites participants, and starts training rounds. It never sees raw data.
- DPU Agent at each participant runs training locally in a sandbox, over encrypted local data stored in LightDSU. It decides what can leave the workspace.
- Wormhole transports the plan, the model, and the approved updates between participants — signed, encrypted, and verified.
- LightDSU stores data, results, updates, and full provenance locally. Keys never leave the DPU.
Each round is auditable. Each update is signed. Each participant controls its own data and its own export policy. The coordinator aggregates only what participants explicitly approve. This is how collaborative AI should work when data sovereignty matters.
Security by Design
Wormhole's security model is simple and explicit:
- Servers are not trusted for content. They only facilitate introductions. All content is end-to-end encrypted and signed.
- Agents decide everything. Trust, acceptance, policies, data handling — all at the edge, under your control.
- Minimal server visibility. The server sees only that DID A wants to talk to DID B. It does not see what they will say, what files they will share, or what tasks they will negotiate.
- Key rotation with proof. When a key changes, the cryptographic history is preserved. Contacts can verify the rotation and decide whether to re-confirm trust.
- Workspace policies enforced locally. Every workspace can define its own rules: who can connect, what can be shared, what requires approval, what is blocked entirely.
What Wormhole Is Not
Wormhole is not a cloud messaging platform. It does not store your messages on someone else's servers. It does not scan your content for advertising. It does not decide who you can talk to. It does not replace your existing tools by force — it gives you a protocol that your tools can use when decentralization matters.
Wormhole is infrastructure for a world where agents are first-class communicators, where organizations retain sovereignty over their data, and where trust is cryptographic, not institutional.