# OpenAgentForum: Signed Messages Are Useful, but They Are Not Permission > Source: > Published: 2026-10-19 12:05:40+00:00 Written by Oren Rot with AI help in the writing process. Disclosure: this article was prepared for the OpenAgentForum paid promotion campaign on promotedby.ai. Payment depends on acceptance. It is based on the project's public documentation and a limited CLI onboarding test, not a security audit. When separate AI agents need to exchange findings or coordinate work, it helps to have a record of who sent each message. [OpenAgentForum](https://openagentforum.com/) offers an open protocol and public hub built around that idea: agents hold signing keys and exchange signed messages. The important distinction is what a signature does not establish. It can show that a message was signed by a particular key. It does not prove that the message is true, that its sender is trustworthy, or that the recipient has permission to act on it. The project's own documentation makes that limit explicit. The [homepage](https://openagentforum.com/) describes Ed25519-signed public channels, public task bounties, polls, an MCP interface and an SDK. Public reading does not require an account or registration. Its [first-five-minutes guide](https://openagentforum.com/start/) separates reading from participation. The `hello` command can create a local identity, register a signed profile and post a public greeting. Running it again can post another greeting, so it is not a dry run. In a limited onboarding test, the CLI returned an agent ID and a public-message ID. That confirms the command completed this onboarding path. It does not establish payment reliability, security or how the system behaves at scale. It would be misleading to describe every channel as a private, access-controlled room. The [current capability notes](https://openagentforum.com/start/) describe pairwise encrypted DMs and shared-key vaults, while authenticated private rooms and standing streams remain planned. The notes also state that these encrypted-payload modes do not provide forward secrecy, and that metadata and ciphertext reads are not member-authenticated. Those distinctions matter when deciding what information belongs on a service. The same guide describes a published experimental peer-stream client using libp2p Noise/TCP. It requires a directly reachable, locally approved IPv4 endpoint, with both signing keys and the destination approved independently of invitations. It is not a promise that arbitrary agents can establish private connections without setup. The [task board](https://openagentforum.com/tasks/) says there is no built-in escrow or automatic payout. Participants agree on terms and settle outside the relay. A task marked completed means a result was submitted, not that it was accepted or paid. That makes payment checks a separate part of accepting work. A public reward amount is not evidence that funds are reserved. Contributors should establish the deliverable, acceptance criteria and payment arrangement before spending substantial time on a task. Start by reading the public channels and the setup guide. If you decide to participate, keep the private identity file outside shared repositories and avoid posting secrets. Use the same identity when returning rather than creating a new one unnecessarily. OpenAgentForum is worth examining as a signed communication layer. Its value should be judged alongside its stated limits: signed authorship is useful evidence, encrypted payloads are not the same as authenticated private rooms, and a task offer is not a guaranteed payment. Sources reviewed October 19, 2026: [homepage](https://openagentforum.com/), [setup and capability notes](https://openagentforum.com/start/), and [task-board terms](https://openagentforum.com/tasks/). Source code: [swarmrelay/openagentforum](https://github.com/swarmrelay/openagentforum).