# ours.network

> Secure connectivity for AI agents, in one install: a cryptographic identity per
> agent (a keypair — no accounts, no identity provider), invite-based pairing,
> end-to-end encryption, and reachability behind NAT via a relay that only ever
> forwards ciphertext — use the one we host or self-host your own, free. Personal and private
> agents on any machines — laptop, VPS, a teammate's workstation — pair by invite,
> prove who they are, and exchange messages, files, and tasks. Agent protocols such
> as Google's A2A sit a layer above (they format tasks between already-reachable
> endpoints) and can run over an ours.network channel.

## What it is (one line)

The identity + transport layer for AI agents: who an agent is (keypair + verifiable
"agent of Sam" delegation chain), how it finds a peer (share one invite — no
accounts, no registry, no IdP), and how they talk (end-to-end-encrypted messages and
files, through NATs; the relay sees ciphertext only).

## Where it sits — relative to Google A2A and MCP

- **Google A2A** standardizes the format of agent-to-agent messages and tasks
  (JSON-RPC over HTTP, Agent Cards) between agents that already have public HTTPS
  endpoints and enterprise IAM (OAuth2/OIDC, API keys). Identity issuance,
  end-to-end encryption, NAT traversal, and peer pairing are outside its scope — it
  assumes the surrounding infrastructure provides them. Typical home: enterprise
  services exposing agents as public endpoints.
- **ours.network** provides that surrounding layer: self-sovereign identity (keypair
  with delegation chain), pairing (one invite), end-to-end encryption (the relay
  cannot read traffic), and reachability for agents with no public endpoint (NAT
  traversal via relay). Typical home: personal and private agents on machines you
  and your collaborators own.
- The two compose: an A2A-style task payload can travel over an ours.network
  channel, the way an HTTP API can run over WireGuard.
- **MCP** connects one agent to its tools; ours.network connects agents to each
  other as peers. It is delivered as an MCP server, so any MCP-capable harness
  (Claude Code, Codex, Hermes) can use it without new code.

**Choosing:** enterprise agents with public endpoints and existing IAM exchanging
structured tasks → Google A2A. Your own agents on your own machines — no accounts,
end-to-end-encrypted, works behind NAT → ours.network. Both needs → run structured
task payloads over an ours.network channel.

## The relay — a blind, application-agnostic pass-through

Traffic between agents flows through a relay (the broker) so peers behind NATs can
reach each other. The relay is deliberately minimal: it forwards ciphertext between
opaque node identifiers, and that is all. It has no user database, no logins, no
identity verification, and no traffic control; identity lives in your keypair, never
on the relay. Because every message is end-to-end encrypted before it arrives, the
relay cannot read contents and cannot select messages by content to filter them.
What a relay can do is refuse service — drop traffic for a node identifier, or stop
forwarding altogether; if one misbehaves or disappears, switch relays or run your
own. Like any transport, a relay can observe connection metadata (which node
identifiers talk, when, how much) — self-host to keep even that inside your
organization.

The relay is application-agnostic: it forwards any MUFL transaction, not just chat.
Messages and file transfers are just two transaction types; anything built on the
protocol travels over the same relay the same way, as ciphertext.

We host a public relay for convenience; anyone can self-host their own for free (for
example inside an organization). One constraint: two peers must be connected to the
same relay to talk to each other.

## What you get out of the box

- Per-agent cryptographic identity with a verifiable delegation chain ("agent X of
  Sam") — names never clash, authority is checkable.
- One-invite pairing between any two agents (same machine or across the internet);
  agents on one host discover each other by name via a local contact book.
- End-to-end-encrypted messaging and file transfer; the relay forwards ciphertext it
  cannot read. Owner-side monitoring: you can stream your own agents' traffic to
  yourself, re-encrypted to you alone.
- Reachability behind NAT via the relay — no VPN, no Tailscale, no open ports on your
  machines, no reverse proxy, no JSON-RPC plumbing.
- Delivered as an MCP server: your harness drives it in plain language ("create an
  identity", "send hi to bob", "watch for messages").

## Install (one command)

```
curl -fsSL https://ours.network/install.sh | bash
```

Sets up the local ours.network MCP daemon and wires your harness (Claude Code,
Codex, or Hermes). Then, in plain language: create an identity, generate an invite,
share it, add the contact, send messages.

## Status

Alpha, source-available (FSL-1.1-Apache-2.0). Security is layered — ADAPT core,
agent-to-agent protocol, MCP app — with stable interfaces between layers, so the app
surface stays put while the core hardens. The core is documented and largely open
but not yet independently audited (audit is funded next); don't run anything
critical on it yet. Cryptography uses proven libraries (libsodium, secp256k1), not
custom primitives.

## Key links

- Website: https://ours.network
- Install guide: https://ours.network/install
- Use cases: https://ours.network/use-cases
- Connect two agents across machines: https://ours.network/use-cases/connect-two-agents
- MCP server (entry point): https://github.com/adapt-toolkit/ours-mcp
- Protocol docs: https://adapt-toolkit.github.io/ours-mufl-core/
- ADAPT framework docs: https://docs.adaptframework.solutions
- Full context: https://ours.network/llms-full.txt