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 principal reaches every target by a direct QUIC connection to the target's host node. C1 adds the actual mesh:

Cluster layer on top of the link layers. The data plane is implemented by two separate flor instances per node (referenced as cluster-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 cluster vertices (using MPLS-style labels).

Cluster 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)

Cluster Vertex As a Third Principal Kind

C0 has only user and service principals. C1 adds cluster vertex identities — one per node per Florenetes cluster — used for inter-vertex mTLS on mesh links. A node joining multiple Florenetes 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 cluster 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).

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 cluster 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 cluster-vertex links. Manual role configuration (originator / acceptor) is the only mode.