Skip to content

docs: split the alternatives comparison into two tables #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Mearman merged 1 commit into from
Sep 9, 2026
Merged

docs: split the alternatives comparison into two tables #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 21 additions & 10 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,16 +17,27 @@ Rather than have agent-comms couple to Cascade's specific implementation, or hav

Several existing protocols cover overlapping ground. None combines wire-mesh's specific set of properties — direct P2P topology, public-key identity, capability-token authorisation, and an opaque per-application content domain — in one protocol.

The first five columns are objective presence checks — does the protocol have this specific mechanism at all (🟢 present, 🟡 present via a different layer or only partially, 🔴 absent) — tracking the bullets from [What the protocol specifies](#what-the-protocol-specifies) not otherwise implied by the remaining five columns. Hover any emoji for the detail behind the rating. The remaining five columns describe each protocol's own approach in prose, for direct comparison against wire-mesh's own choice as described in that same section.

| Protocol | Handshake / capability negotiation | Relay / NAT traversal | Domain & capability registry | Handle discovery | Federation | Topology | Peer identity | Authorisation | Application content | Wire encoding |
|---|---|---|---|---|---|---|---|---|---|---|
| **wire-mesh** | <abbr title="Explicit capability-domain negotiation; the usable set for a connection is the intersection of what both sides advertise">🟢</abbr> | <abbr title="A relay carries traffic as an opaque, unreadable byte pipe when peers cannot connect directly">🟢</abbr> | <abbr title="A registry so unrelated applications' own capability domains and verbs don't collide">🟢</abbr> | <abbr title="DNS-anchored resolution to a self-certifying record, mirroring WebFinger">🟢</abbr> | <abbr title="Selective, explicit cross-mesh sharing, distinct from ordinary intra-mesh relay">🟢</abbr> | Direct P2P mesh, with relay for NAT traversal and optional cross-mesh federation | Hash of a self-signed public key | Signed, revocable, delegatable capability tokens; delegation can only narrow authority | Opaque per-application payload; only identity, handshake, tokens and relay are protocol-native | CBOR/DAG-CBOR, signed via COSE, schema in CDDL |
| [libp2p](https://libp2p.io/) | <abbr title="multistream-select negotiates supported protocols per connection, but as protocol selection, not a capability-domain intersection">🟡</abbr> | <abbr title="Circuit relay v2 and hole punching">🟢</abbr> | <abbr title="Protocol IDs are free-form strings; no formal collision-avoiding registry">🔴</abbr> | <abbr title="DHT/peer-routing discovery exists, but no DNS-anchored self-certifying handle scheme">🔴</abbr> | <abbr title="One flat overlay network; no concept of federation between independent meshes">🔴</abbr> | Direct P2P mesh, with circuit relay and hole punching for NAT traversal | Multihash of a public key | Not built in; left to the application or its own protocols | Defined per protocol via multistream-select and application-registered protocol IDs | Protocol-specific; commonly Protobuf, which is not canonical across languages or library versions |
| [Secure Scuttlebutt](https://scuttlebutt.nz/) | <abbr title="No negotiation; a connection is direct feed replication">🔴</abbr> | <abbr title="No relay primitive; pubs provide store-and-forward replication, not a transport relay">🔴</abbr> | <abbr title="None">🔴</abbr> | <abbr title="Invite codes and pub identifiers, not DNS-anchored resolution">🔴</abbr> | <abbr title="None">🔴</abbr> | P2P gossip replication of append-only logs; no relay primitive for NAT traversal | Ed25519 public key | None; a feed's own author key is its sole authority | Fixed: an append-only log of an identity's own signed messages | JSON, hashed for signing; no CBOR-style canonical encoding standard |
| [Syncthing](https://docs.syncthing.net/specs/bep-v1.html) (BEP) | <abbr title="Protocol-version negotiation only, not a capability-domain intersection">🔴</abbr> | <abbr title="Dedicated relay servers for NAT traversal">🟢</abbr> | <abbr title="None">🔴</abbr> | <abbr title="Device IDs plus discovery servers, not DNS-anchored resolution">🔴</abbr> | <abbr title="None">🔴</abbr> | Direct P2P mesh, with relay servers for NAT traversal | SHA-256 of a self-signed certificate | Access is device-list based, not token-scoped | Fixed: file blocks and index metadata for folder sync | Protobuf; not canonical across languages or library versions |
| [Matrix](https://spec.matrix.org/) | <abbr title="None">🔴</abbr> | <abbr title="Not peer-to-peer; homeservers are expected to be directly reachable">🔴</abbr> | <abbr title="None">🔴</abbr> | <abbr title="DNS-based homeserver discovery (.well-known/SRV) resolves to a server, not a self-certifying signed record">🟡</abbr> | <abbr title="Federation between homeservers is the primary topology itself, not a distinct selective layer on top of direct peering">🟡</abbr> | Federated client-server and server-server; not peer-to-peer | Homeserver-issued user ID; no peer key | Room-level power levels and access-control lists, not bearer capability tokens | Fixed: room events under a defined event-type schema | JSON, with a canonical-JSON scheme used specifically for event signing and federation |
| [ActivityPub](https://www.w3.org/TR/activitypub/) | <abbr title="None">🔴</abbr> | <abbr title="Not peer-to-peer; 'relay' actors rebroadcast activities between servers, not a transport relay">🔴</abbr> | <abbr title="None">🔴</abbr> | <abbr title="WebFinger handle discovery is standard in Fediverse deployments (e.g. Mastodon), but not part of the ActivityPub spec itself">🟡</abbr> | <abbr title="Unconditional inbox delivery to every known follower, not selective cross-mesh sharing">🔴</abbr> | Federated server-to-server, one-to-many broadcast | Server-hosted actor URI; no peer key | None; visibility is addressing-based (public, followers, etc), not capability tokens | Fixed: JSON-LD activity vocabulary | JSON-LD; no canonical signing scheme built into the base spec |
The first table is a set of objective presence checks — does the protocol have this specific mechanism at all (🟢 present, 🟡 present via a different layer or only partially, 🔴 absent) — tracking the bullets from [What the protocol specifies](#what-the-protocol-specifies). Hover any emoji for the detail behind the rating.

| Protocol | Handshake / capability negotiation | Relay / NAT traversal | Domain & capability registry | Handle discovery | Federation |
|---|---|---|---|---|---|
| **wire-mesh** | <abbr title="Explicit capability-domain negotiation; the usable set for a connection is the intersection of what both sides advertise">🟢</abbr> | <abbr title="A relay carries traffic as an opaque, unreadable byte pipe when peers cannot connect directly">🟢</abbr> | <abbr title="A registry so unrelated applications' own capability domains and verbs don't collide">🟢</abbr> | <abbr title="DNS-anchored resolution to a self-certifying record, mirroring WebFinger">🟢</abbr> | <abbr title="Selective, explicit cross-mesh sharing, distinct from ordinary intra-mesh relay">🟢</abbr> |
| [libp2p](https://libp2p.io/) | <abbr title="multistream-select negotiates supported protocols per connection, but as protocol selection, not a capability-domain intersection">🟡</abbr> | <abbr title="Circuit relay v2 and hole punching">🟢</abbr> | <abbr title="Protocol IDs are free-form strings; no formal collision-avoiding registry">🔴</abbr> | <abbr title="DHT/peer-routing discovery exists, but no DNS-anchored self-certifying handle scheme">🔴</abbr> | <abbr title="One flat overlay network; no concept of federation between independent meshes">🔴</abbr> |
| [Secure Scuttlebutt](https://scuttlebutt.nz/) | <abbr title="No negotiation; a connection is direct feed replication">🔴</abbr> | <abbr title="No relay primitive; pubs provide store-and-forward replication, not a transport relay">🔴</abbr> | <abbr title="None">🔴</abbr> | <abbr title="Invite codes and pub identifiers, not DNS-anchored resolution">🔴</abbr> | <abbr title="None">🔴</abbr> |
| [Syncthing](https://docs.syncthing.net/specs/bep-v1.html) (BEP) | <abbr title="Protocol-version negotiation only, not a capability-domain intersection">🔴</abbr> | <abbr title="Dedicated relay servers for NAT traversal">🟢</abbr> | <abbr title="None">🔴</abbr> | <abbr title="Device IDs plus discovery servers, not DNS-anchored resolution">🔴</abbr> | <abbr title="None">🔴</abbr> |
| [Matrix](https://spec.matrix.org/) | <abbr title="None">🔴</abbr> | <abbr title="Not peer-to-peer; homeservers are expected to be directly reachable">🔴</abbr> | <abbr title="None">🔴</abbr> | <abbr title="DNS-based homeserver discovery (.well-known/SRV) resolves to a server, not a self-certifying signed record">🟡</abbr> | <abbr title="Federation between homeservers is the primary topology itself, not a distinct selective layer on top of direct peering">🟡</abbr> |
| [ActivityPub](https://www.w3.org/TR/activitypub/) | <abbr title="None">🔴</abbr> | <abbr title="Not peer-to-peer; 'relay' actors rebroadcast activities between servers, not a transport relay">🔴</abbr> | <abbr title="None">🔴</abbr> | <abbr title="WebFinger handle discovery is standard in Fediverse deployments (e.g. Mastodon), but not part of the ActivityPub spec itself">🟡</abbr> | <abbr title="Unconditional inbox delivery to every known follower, not selective cross-mesh sharing">🔴</abbr> |

The second table describes each protocol's own approach in prose, for direct comparison against wire-mesh's own choice as described in [What the protocol specifies](#what-the-protocol-specifies).

| Protocol | Topology | Peer identity | Authorisation | Application content | Wire encoding |
|---|---|---|---|---|---|
| **wire-mesh** | Direct P2P mesh, with relay for NAT traversal and optional cross-mesh federation | Hash of a self-signed public key | Signed, revocable, delegatable capability tokens; delegation can only narrow authority | Opaque per-application payload; only identity, handshake, tokens and relay are protocol-native | CBOR/DAG-CBOR, signed via COSE, schema in CDDL |
| [libp2p](https://libp2p.io/) | Direct P2P mesh, with circuit relay and hole punching for NAT traversal | Multihash of a public key | Not built in; left to the application or its own protocols | Defined per protocol via multistream-select and application-registered protocol IDs | Protocol-specific; commonly Protobuf, which is not canonical across languages or library versions |
| [Secure Scuttlebutt](https://scuttlebutt.nz/) | P2P gossip replication of append-only logs; no relay primitive for NAT traversal | Ed25519 public key | None; a feed's own author key is its sole authority | Fixed: an append-only log of an identity's own signed messages | JSON, hashed for signing; no CBOR-style canonical encoding standard |
| [Syncthing](https://docs.syncthing.net/specs/bep-v1.html) (BEP) | Direct P2P mesh, with relay servers for NAT traversal | SHA-256 of a self-signed certificate | Access is device-list based, not token-scoped | Fixed: file blocks and index metadata for folder sync | Protobuf; not canonical across languages or library versions |
| [Matrix](https://spec.matrix.org/) | Federated client-server and server-server; not peer-to-peer | Homeserver-issued user ID; no peer key | Room-level power levels and access-control lists, not bearer capability tokens | Fixed: room events under a defined event-type schema | JSON, with a canonical-JSON scheme used specifically for event signing and federation |
| [ActivityPub](https://www.w3.org/TR/activitypub/) | Federated server-to-server, one-to-many broadcast | Server-hosted actor URI; no peer key | None; visibility is addressing-based (public, followers, etc), not capability tokens | Fixed: JSON-LD activity vocabulary | JSON-LD; no canonical signing scheme built into the base spec |

## Architecture

Expand Down