OpenAgentForum：Signed Messages Are Useful, but They Are Not Permission

When multiple AI agents need to exchange discoveries or coordinate tasks, a common approach is to make every message traceable to its sender. OpenAgentForum is an open protocol and public hub built around exactly this idea — agents hold signing keys and exchange signed messages.

But there is a key distinction here: a signature only proves that a given message was issued by a certain key. It cannot prove that the message content is true, that the sender is trustworthy, or that the recipient has permission to act on it. The project's own documentation explicitly acknowledges this boundary. This article, based on its public documentation and a limited CLI hands-on test, sorts out its capabilities and limitations.

What the Protocol Offers: Signed Public Channels and an Onboarding Flow

According to the OpenAgentForum homepage, it offers Ed25519-signed public channels, public task bounties, voting, an MCP interface, and an SDK. Reading public content requires no account or registration, which lowers the barrier to observing.

Its "First Five Minutes" guide separates "reading" from "participating." The hello command creates a local identity, registers a signed profile, and publishes a public greeting. Note that running the command again will publish another greeting, so it is not a "dry run" — each execution produces a real public message.

In a limited hands-on test, the CLI returned an agent ID and a public message ID. This only shows that the command completed this onboarding path; it does not prove payment reliability, security, or how the system behaves at scale.

Ed25519 is a digital signature algorithm based on elliptic curves, known for short signatures (64 bytes), fast verification, and small keys, and is widely used in SSH, Signal, TLS certificates, and similar scenarios. Its security relies on the difficulty of the discrete logarithm problem on a specific curve. In the context of OpenAgentForum, each agent's private key is used to sign messages, and other parties can use the corresponding public key to verify that the message was indeed issued by the holder of that private key. It is important to emphasize that Ed25519 guarantees integrity and verifiability of origin, not the truthfulness of the message content or the real-world identity of the sender — binding keys to real-world entities still requires external mechanisms (such as profile registration or a web of trust).

Encryption Has Clear Limits: Not All Channels Are Private Rooms

Describing every channel as a private, access-controlled room would be misleading. The current capability statement notes that the system provides pairwise-encrypted direct messages (DMs) and shared-key vaults, while authenticated private rooms and persistent streams remain on the roadmap.

The statement also makes clear that these encrypted payload modes do not provide forward secrecy, and that metadata and ciphertext reads have no member authentication. These distinctions matter when deciding what information can be placed on the service.

The same guide also describes a published experimental peer-to-peer stream client using libp2p Noise/TCP. It requires a directly reachable, locally approved IPv4 endpoint, and both the signing key and target endpoint must be approved independently of the invitation. This does not mean that any agent can establish a private connection without configuration.

Forward secrecy means that even if a long-term key is compromised, an attacker still cannot decrypt previously recorded session ciphertext. Its implementation typically relies on per-session ephemeral key exchange (such as ephemeral Diffie-Hellman keys), which are destroyed when the session ends. The article notes that OpenAgentForum's encrypted payload modes do not provide forward secrecy, meaning that if a long-term private key or shared key is leaked, historical ciphertext may be retroactively decrypted. For communications requiring long-term confidentiality, this is a substantive limitation, and users should evaluate accordingly which information is suitable for the service.

libp2p is a peer-to-peer networking stack that provides modules for transport negotiation, connection encryption (such as the Noise protocol), multiplexing, and peer discovery, and is used by projects such as IPFS. Noise is a family of handshake frameworks based on Diffie-Hellman that can establish encrypted channels without relying on a certificate system. The article mentions that the experimental peer-to-peer stream client uses libp2p Noise/TCP and requires a directly reachable IPv4 endpoint and independent approval, indicating that this path is closer to a peer-to-peer direct-connection experiment than an out-of-the-box private room; NAT traversal, endpoint reachability, and the key approval process all affect practical usability.

Bounties Are Quotes, Not Escrow

The task board explicitly states that there is no built-in escrow or automatic payment. Participants agree on terms themselves and settle outside the relay. A task marked "completed" only means the result has been submitted, not that the result has been accepted or paid for.

This means that payment checks are a separate step from taking on work. A public bounty amount is not evidence that funds have been reserved. Before investing significant time, contributors should clarify deliverables, acceptance criteria, and payment arrangements.

Escrow is a third-party custody mechanism: the payer first deposits funds into a neutral account, and releases them to the payee once agreed conditions (such as delivery acceptance) are met, thereby reducing the risk of default by either party. In decentralized scenarios, smart contracts can also implement similar logic. OpenAgentForum explicitly has no escrow or automatic payment, so a bounty amount is merely a quote and does not constitute evidence that funds are locked. Participants need to design their own settlement processes (such as on-chain multisig or third-party guarantees) and confirm deliverables and acceptance criteria in writing before starting, to fill the trust gap left by the absence of escrow.

A Reasonable First Round of Testing

It is recommended to start with reading the public channels and the setup guide. If you decide to participate, keep private identity files outside shared repositories and avoid publishing secret information. When returning, use the same identity rather than unnecessarily creating a new one.

OpenAgentForum is worth examining as a signed communication layer. Its value should be judged in light of its stated limitations: signed authorship is useful evidence, encrypted payloads are not the same as authenticated private rooms, and task quotes are not guaranteed payment.

The sources reviewed for this article (as of October 19, 2026): the homepage, the setup and capability statement, and the task board terms. The source code is located at swarmrelay/openagentforum.

Disclosure: This article is based on the project's public documentation and a limited CLI hands-on test, and is not a security audit.

One-line Summary

OpenAgentForum offers signed public channels and a task board, but signatures are not trusted authorization, encryption is not a private room, and bounties are not escrowed payments.

Paragraph Summary

OpenAgentForum is an open protocol and public hub for AI agents, offering Ed25519-signed public channels, public task bounties, voting, an MCP interface, and an SDK, with public content readable without registration. Based on its public documentation and a limited CLI hands-on test, this article clarifies three key boundaries: a signature only proves a message was issued by a certain key, not that the content is true or that the recipient has permission to act; encrypted DMs and shared-key vaults do not provide forward secrecy, metadata and ciphertext reads have no member authentication, and authenticated private rooms remain a planned feature; and the task board includes no escrow or automatic payment — marking a task complete only means the result has been submitted, and a public bounty amount does not mean funds are reserved. The article also notes that the hello command publishes a real public message every time it runs, identity files should be kept away from shared repositories, and a first round of testing should be limited to reading public channels and checking documentation.