Scope

This milestone inherits all goals, limitations, development constraints, evolution constraints, and no-goals from C0. Tended Tunnels. Below are only the additions and changes C1 introduces.

Real Service Mesh (Multi-hop)

C0 is a set of 1-hop tunnels — every initiator reaches every target by a direct QUIC connection to the target's host node. C1 adds the actual mesh:

• Mesh layer on top of the link layers. The data plane is implemented by two separate flor instances per node (referenced as mesh-flor and link-flor), communicating over FlorIO (a local datagram socket). This is the first milestone that exercises our recursive architecture.
• Multi-hop forwarding between mesh-vertices (using MPLS-style labels).

Mesh Vertex

Let's look into core services of this vertex.

Transport service originates and terminates connections between workloads. Mandatory features:

• stream (TCP-like)
• mutual authentication, confidentiality & integrity (mTLS-like): required for Zero Trust architecture

These will be inherited from C0 implementation.

Optional:

• dgram (UDP-like): needed for recursiveness and other apps that are not in scope of C1
• multi-stream (QUIC-like): can be useful for some apps, but not in C1
• convergent (streams + dgram, QUIC-like): same

Connection service uses link vertex-provided Portal API to establish connections (links). Mandatory features:

• Originate or accept connections
• Manual role configuration (originator/acceptor)
• Disconnect detection and reconnect functionality: mandatory from UX PoV

Optional, out of scope for C1:

• Automatic role selection and connection deduplication

Forwarding service handles packets: locally originated or destined, and transit packets. Mandatory features:

• addressless, label-based forwarding engine (transport's ConnectionId + Forward and Backward labels)

Mesh Vertex As a Third Principal Kind

C0 has only user and service principals. C1 adds mesh-vertex identities — one per node per Florete rete — used for inter-vertex mTLS on mesh links. A node joining multiple retes runs multiple vertex identities. Everything else about the identity model (CA, enrollment bundles, revocation) carries over unchanged.

Link Vertex

Let's look into core services of this vertex.

Transport service has mandatory features:

• dgram (UDP-like)
• mutual authentication, confidentiality & integrity (mTLS-like)

Requiring dgram service is already a design decision, but rather obvious one: stream over stream usually works bad, so we aim for sound combination at the beginning. The transport of link vertex itself may be stream-based though and provide dgram service on top (not in C1, ofc) - not optimal, but possible.

Forwarding service is degenerate: no special routing info is needed, packets are just sent to / read from underlying medium of the link. Target medium is UDP/IP, will be inherited from C0.

Actual published services in links will be mesh-vertices, usually one per each link end. This may be taken in account and optimized for (i.e. no need for multi-service links really - they are not useful in practice).

Platform and Operational Additions

C1 also picks up scope deferred from C0:

• Windows support. C0 targets Linux and macOS; Windows is a C1 deliverable. This is deliberately more work in C1 than it would have been in C0: it must cover C1's FlorIO local sockets (a Windows named-pipe story in place of Unix datagram sockets) and a Windows service story for flor agent (a Windows Service wrapper alongside the systemd/launchd ones). That trade was accepted knowingly when Windows was cut from C0. The design stays OS-agnostic at the core with thin OS-specific service wrappers.
• enrollment.log. C1 introduces an append-only enrollment audit log — one sign-event per issued cert and one revoke-event per removal (cert fingerprint, timestamp, operator identity), committed alongside the YAML source. It supersedes C0's reliance on plain git commit history as the audit trail. Because C1 retes are stood up by a clean reinstall (there is no live C0→C1 migration), the log simply starts fresh at C1 enrollment — no backfill of C0-era events and no validator grace path for logless retes.
• Commit-timeout / auto-rollback on flor agent sync. C1 adds the Cisco-IOS-style commit confirmed safety net that C0 left out: a sync activates the new artifacts under a confirm-within-a-window guard and auto-rolls-back to the previous artifacts if the operator doesn't --confirm in time; the rollback state must survive an agent crash mid-window. In C0 the blast radius of a bad sync was bounded only by the out-of-band emergency-access path — C1 makes rollback a first-class mechanism.
• Binary rollback in the installer. The same milestone, deliberately: C0 goes back by installing the older release, which needs the network and a version the operator has to read off the receipt first (C0 · Installer § Downgrade). C1 adds retained previous binary sets and a network-free flor install --rollback. Landing it beside the artifact guard gives one confirm-or-roll-back story covering binaries and state, rather than two mechanisms designed apart. The layout-compatibility marker it would once have needed belongs with the node-state migration design instead, which is the agent's rather than the installer's.

Evolution Constraints

Link Protocols

For future evolution there is a requirement to support various link protocols:

• QUIC connections (the basics in C0)
• VPN tunnels (WireGuard, OpenVPN, VLESS + Reality, Hysteria, TUIC and others)
• Custom protocols (e.g. for raw radio links we cannot use QUIC, need special ARQ-based protocol)

So we need a design where we'd be able to integrate different link protocols easily. But for C1 we need only single link protocol (QUIC, as implemented in C0). Support of QUIC will be introduced via FlorIO. But Connection service of the mesh-vertex must be link-agnostic.

No-goals

In addition to C0's list:

• Automatic multi-hop path derivation. In C1, operators write paths by hand. Declarative derivation from topology + access is deferred post-C1.
• Priority / fallback paths. Reserved syntax in path configuration, not implemented.
• Automatic role selection on mesh-vertex links. Manual role configuration (originator / acceptor) is the only mode.

Open Questions

Deferred from C0 without a firm C1 decision yet — to be resolved as C1 is scoped:

• Flow B / CSR-based enrollment. Should C1 add the principal-generated-keypair path (the principal makes its own keys, sends only CSRs, the operator signs them) so private keys never leave the principal's machine? C0 enrolls via Flow A only; the low-level flor id create primitive already exists but isn't wired into onboarding. See C0 · Enrollment and C0 · CLI Surface.
• Encrypted bundle & one-time-URL delivery. Should C1 replace C0's plain out-of-band bundle file with an encrypted, short-lived, personalized-URL delivery? In C0 the bundle is bearer material (it carries private keys in Flow A) handed over any channel the operator trusts; hardening it adds a delivery/hosting mechanism to design.
• Hosted landing page. Should C1 ship a per-rete, zero-backend landing page with platform install one-liners for end users, in place of C0's docs install guide?