Coordinators
Multi-region. Hold no peer private keys. Compromise of one region does not compromise the others.
Beacons Mesh
A private mesh built for the autonomous world.
Beacons Mesh is not a fork. It is a from-scratch overlay where humans and agents are first-class peers, identity is `did:oas`-rooted, access is policy-derived from your organization's governance, and the transport is whatever the device can speak.
01 · Identity
Every peer is a `did:oas`.
OAS resolution + AEGIS challenge + Arsenal capability. Three independent layers. All three must pass.
Read more
02 · Policy
ACLs derived from governance.
Define trust roots, accepted entity kinds, capability scopes once. The engine recomputes routes continuously.
Read more
03 · Transports
Whatever the device can speak.
Kernel WG · userspace WG · WebRTC · MQTT · CoAP · cellular · LoRa · Iridium. One identity. Many wires.
Read more
What is in the mesh
Six concrete components.
None of these are reimplementations. Beacons consumes the L1fe stack — OAS for identity, AEGIS for challenge, Arsenal for capability, Sigil for audit anchoring, Silos for state, Relays for DNS, Cabbage for billing.
Relays
STUN, signal, and a custom Rust TURN-equivalent that enforces policy at the packet level. Encrypted payloads stay encrypted.
MagicDNS
Per-fleet subdomains served by Relays / PowerDNS. Friendly names for peers, ACLs, and exit nodes.
Identity layer
OAS · AEGIS · Arsenal. The composite verdict every peer goes through, every time.
Policy engine
Recomputes ACLs whenever lineage, capability, attestation, or governance state changes.
Audit chain
Blake3 hash-chained events anchored on Sigil. Survives coordinator compromise.
Decisions
Why every Beacons design choice is opinionated.
Multi-transport, not single-transport
Beacons Mesh is not "WireGuard with policy." WireGuard is the preferred default on Linux and Windows, but the architecture treats transport as something the peer and the coordinator negotiate at enrollment. The set includes userspace WireGuard, WebRTC, MQTT-over-TLS, CoAP, cellular IP through a private APN, LoRa/Meshtastic gateways, and Iridium / Starlink satellite links. See all transports →
Identity is cryptographic, not provisioned
Beacons does not use shared setup keys. Every peer presents a `did:oas` identity rooted in the organization's lineage. Authentication is challenge-response over Ed25519 (AEGIS). Authorization is enforced through Arsenal Capability Tokens (ACTs) issued under the organization's policy. Setup keys are simply not a concept here. See how identity works →
ACLs are policy-derived, not hand-authored
Fleet operators do not write ACLs. They define ENR governance once: this fleet trusts root H, accepts agent kinds X / Y / Z, requires capability `beacons:fleet:join`, accepts attestations of type `SecurityAudit` from a trusted-issuer set, with maximum lineage depth 8. The policy engine derives every ACL, continuously, from those rules. See the policy model →
Multi-tenancy is native, not bolted on
A Beacons deployment serves many organizations simultaneously. Each organization owns one or more fleets. A fleet is the unit of network isolation. Tenancy is enforced at the data-plane level — peers in fleet A cannot route to peers in fleet B even if they discover each other's overlay IPs, because the policy engine refuses to install the cross-fleet route on either side.
Audit is hash-chained and externally anchorable
Every coordinator action emits a Blake3-hashed event chained against the prior event. Per-fleet chains are periodically anchored on Sigil so the audit history is verifiable independent of L1fe's infrastructure. See the audit model →
Composability over replacement
Beacons integrates with the L1fe ecosystem rather than replacing it. OAS, AEGIS, Arsenal, Locks, Lockers, Aut0, Forge, Hives, Silos, Cabbage, Sigil, Garden, Relays, MAP, JOBS — all consumed via stable interfaces. See how Beacons differs from VPN incumbents →