Scope

Goals

Use Case

The resulting Florete system must be suitable for production usage in a small IT company (design partner) which has:

One or more infrastructure sites (cloud, on-prem)
3-5 server nodes, 10-20 services, 10-20 users

Limitations:

No dynamic control plane: a passive coordinator (Coordinator) stores and serves operator-signed state, but makes no runtime traffic decisions
Enrolled & maintained manually by an operator (member of Florete Core Team) with the help of IT admin of the design partner
All initiators (users, and services acting as callers) can reach targets (services) by 1-hop connections (i.e. no relaying is supported)
Only TCP services are supported (can be located at the nodes as well as in internal IP LAN)
Only SOCKS5 inbound is supported (i.e. users must use clients with SOCKS5 support; services that connect to other services - too)
No NAT Traversal; server nodes must be Internet-facing (have a routable public IP)

Success criteria: the use case works stable for daily use.

In order to create a service mesh, we need per-node proxies. This is a common service mesh design pattern we follow. Our per-node workload is flor, split into two processes: a flor agent (supervisor — owns the node principal, syncs signed state, launches and restarts the data plane) and a flor vertex (the data-plane proxy that terminates mTLS and forwards traffic). C0 runs one flor vertex per node under one flor agent; see Management Plane for the split.

The C0. Tended Tunnels milestone doesn't include real multi-hop mesh. It does include a simple set of tunnels between initiators and targets - QUIC connections over UDP. But from the user PoV it already looks like a service mesh. The only visible limitation is the tunnels are 1-hop. We expect that for up to 90% of small IT companies this is actually enough.

Internally there are more important differences:

there will be no links between nodes (or, rather rete vertices) - the connections will be between initiators and targets directly
the targets (services) will be visible publicly (i.e. anybody will be able to attempt connecting), secured by mTLS

This differs from C1. Manual Mesh - there only rete vertices will be visible publicly, not the targets. Aside from this information disclosure, security guarantees between C0 and C1 will be the roughly the same, provided by mTLS (two layers of it for C1, but managed in the same manual control plane).

Vertex

In C0. Tended Tunnels there will be only single vertex per node. Formally, it is a link vertex. But we won't call it this way because here it isn't used to create links between vertices of the higher layer, as there is none. It will serve workloads directly, just like mesh vertex will in C1. So effectively in C0 we will test

inbound and outbound interfaces
links over UDP and tunnels between initiators and targets (these will be the same in C0; separated in C1)

This vertex must provide following services.

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

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

Forwarding service in a degenerate form: provides UDP packet delivery between nodes, used by transport service directly. This UDP service provides star-like topology of UDP peers and services located at them.

Local Proxy Interface

We need local proxy interface for user workloads running at the node. The scope limitation of C0: user workloads use TCP/IP. Later on we may want to add support for UDP, local sockets, shared memory and whatever other means (e.g. MASQUE).

We need the ability to map workload, its identity, and the destination identity for outgoing connections.

Gateway Interface

We need an ability to support clients and servers from IP LAN - like smart home devices that cannot be nodes for some reason, or servers within corporate LAN that don't need Florete network protection (can be served by TCP/IP within LAN). The latter is especially important for C0, because it lacks routing - this way we'd be able to publish internal services that are not located at the Internet-facing nodes. Later on we'd develop a Distributed IP Gateway Service, but for the beginning we may just expose our local proxy to the LAN.

Configuration

We need config files for manual configuration of the rete. And CLI utilites to manage it. What must be configurable:

identities of users and services
UDP links of vertices (IPs and ports)
location of services at vertices (no service discovery; the operator compiles this into per-node artifacts)

We need automated user and node enrollment, and config deploy to manage production environments.

Maintenance

We need means to detect and resolve problems that arise in production environments. Especially important events:

loss of connectivity
crashes, abnormal terminations
slowdown of traffic flows
excessive resource usage (memory leaks, CPU consumption)
security issues (unauthenticated, unauthorized access, DoS)

For C0 we need the bare minimum to run the production pilots successfully.

C0 observability is node-local. Every flor process logs to the host's syslog socket — /dev/log on Linux, a real syslog daemon on macOS (Installer § Logging); the user guide documents how to view and export those logs, and flor agent status gives a local state readout. Nothing is shipped to an external collection server in C0 — that upload path arrives with B1's coordinator. The full design — log conventions, metrics-ready counters, and their readout — is Observability.

Environments

Dev Env

We need a local dev environment for the system. Minimally we can have it emulated as multiple processes at the same PC. Optionally, we may implement container-based testbed (container nodes). This testbed will be mandatory later, but for initial development of C0 may be omitted - until we start testing disconnects/reconnects, packet loss and so on.

Test Env

We need a test environment that is not limited to a single PC nor local containers/VMs. Minimally we require a pilot-like Florete rete with multiple VMs (2 cloud providers will be nice), services, users. Optimally we'd need a CI/CD process to deploy to them.

Deliverables

What C0 ships, one line each:

retectl — the operator's authoring CLI (CA operations, validate, compile, issue-bundle, publish). See CLI Surface.
flor — the per-node CLI and supervisor (agent), which owns the node principal, launches and restarts the vertex and coordinator (on the management node). See Management Plane and CLI Surface.
flor-vertex — the data-plane proxy that terminates mTLS and forwards traffic. See Data Plane.
flor-coordinator — the store-and-serve management-node service. See Coordinator.
Installer — install.sh bootstrapping a flor install core: one channel, GitHub Releases, two targets (linux-x86_64, macos-arm64; no Windows in C0 — see Cross-platform). Design: Installer.
Example my-rete repo — a template rete with reserved roles/groups seeded, used for dogfooding. See Source Layout.
Operator playbook — bootstrap, issuing bundles, publishing a service, rolling out a change, emergency rollback.
User guide — installing flor, enrolling, and how to view/export logs when reporting a problem.

Release Gate

C0 ships when it passes our own internal tests and we are dogfooding it — running our own rete for our daily-work services. That is the gate.

The design-partner pilot happens after C0 ships, not before: it validates the release in the field, and the issues it turns up and feedback it gathers shape C1. The pilot is deliberately not a pre-ship gate — we ship first, then pilot.

Tracking

The concrete C0 work items live on GitHub:

rete-labs C0 progress board — the cross-repo release phase plan.
rete-labs/florete · C0. Tended Tunnels — design & docs.
rete-labs/flor · C0. Tended Tunnels — code.

Development Constraints

Implementation must be done mainly in Rust language, in an async fashion using Tokio runtime.

Evolution Constraints

We must design the C0 version in a way to be extensible for future work, but without over-engineering.

Security

Core security feature, mTLS, is mandatory for C0 release. Because we're going to use this prototype in production: dogfooding and for pilots with design partners. Also not doing Zero Trust from ground up can result in architectural oversights and non-upgradable solutions (e.g. we could have used insecure MPLS, but it isn't clear how to secure it properly later).

So we must produce a design and implementation that is secure from day one.

Cross-platform

For C0, our target OSes are Linux and macOS (macOS on Apple Silicon only — see Installer § Platforms). Windows will be added in C1 — the design stays portable (OS-agnostic core, thin OS-specific service wrappers), but a Windows deliverable is not part of C0. Later on (B1+) we'd like to support mobile OSes (Android, iOS, even HarmonyOS).

So we need to design our implementation in a way that is portable to different OSes without much effort, even where a given OS is not a C0 target yet.

No-Goals

We don't want to check "recursive hypothesis": it was successfully checked in previous prototype, the approach is working and with known limitations.

We don't want to build abstract Portal APIs in Rust. That was checked and it works, but is very clunky. It seems Rust isn't designed for such trait-based APIs. It works best with typed, struct-based APIs.

We don't want to make an execution environment for workloads and dynamic components etc. This task is out of scope for C0.

We are not doing active control plane features, service discovery and various adaptive mechanics in C0.

Deferred to later milestones

These are deliberately out of C0 and picked up (or decided) later:

Windows support — lands in C1. C0 targets Linux and macOS.
enrollment.log (append-only sign/revoke audit) — introduced in C1. In C0 the git history of the rete repo is the audit trail.
Flow B / CSR-based enrollment (principal-generated keypairs) — an open question for C1. C0 enrolls via Flow A only (operator-generated keypairs).
Encrypted bundles & one-time-URL delivery — an open question for C1. In C0 the enrollment bundle is a plain file the operator delivers over any out-of-band channel; it is bearer material.
Hosted landing page — an open question for C1. C0 ships an install guide in the docs instead.
External metrics collection & upload — an upload/collection server is C1+/B1 (B1's coordinator becomes the consumer). C0 keeps observability node-local (see Maintenance).
flor agent sync commit-timeout / auto-rollback — the Cisco-IOS-style "confirm within a window or auto-roll-back" safety net moves to C1. In C0 the blast radius of a bad sync is bounded by keeping an out-of-band emergency-access path (see Distribution & Reload · Safety Net), not by auto-rollback — pilots are limited and never rely on Florete as the single access path.
Binary rollback in the installer — retained previous binary sets and a --rollback that needs no network move to C1 with the sync guard above, for the same reason and as one story. C0 needs no guard of its own: any release installs over any other, so going back is installing the older one (see Installer · Downgrade).
Node-state migrations — the agent's and an operator-invoked command's, not the installer's; nothing in C0 has anything to migrate from (see Installer · Migrations).
ACL-only hot reload — near-term post-C0. C0's update mechanism is a plain restart on sync; the agent is built with swappable ACL tables so this can land later without a redesign.