Expand description
The embedding handle: a running liminal server with no listener, whose one
connection-granting surface is the in-process loopback
(design docs/design/IN-PROCESS-TRANSPORT.md §2, §4, §9 ruling 4).
What an EmbeddedServer secures is the RECORD PATH (hardened
face-substrate draft r2 §5). A connection minted here is admitted by the
same door a socket connection is admitted by: the same
try_reserve_admission against the same slot pool, a real durable
connection incarnation from the same authority, the same registry record,
the same Connect/ConnectAck handshake with the same constant-time token
compare, the same frame preflight, the same participant gate, and the same
apply_frame seam. No append reaches the record except through that door,
and the door does not know which mount knocked. An embedded caller with the
wrong token is refused on its own loopback, and an embedded caller arriving
at capacity is refused exactly as a socket connect is.
What an EmbeddedServer does NOT secure is the mount. A co-resident
caller is TRUSTED CODE: it reaches the host process’s heap, its descriptors,
and its store handle without ever calling this type, so the record vouches
for a co-resident mount only as far as the host process itself is trusted.
That is inherent to the mount, not a defect of it. Every append admitted
here carries the mount fact the admitting door stamped
(MountKind::Loopback, §10)
precisely because the mount is what a consumer must weigh; this type is not
a sandbox and must never be read as one.
The surface is deliberately one door wide. This handle exposes no
supervisor, no services, no store, no handler, no registry, and no scheduler
— the module privacy that keeps those unreachable is the structural half of
the no-side-door guarantee, and a convenience accessor here would undo it as
surely as a public spawn seam would. connect_loopback is the whole grant.
Structs§
- Embedded
Server - A running liminal server with no listener, granting in-process connections.