Struct ZoneRegistry 

pub struct ZoneRegistry {
    zones: Vec<Zone>,
}

Several Zones under one server. They may nest — a zone at dev.agents.bot under a deployment that also mints from agents.bot is fine — because nesting is not actually ambiguous: a wildcard certificate matches exactly one label, so *.agents.bot covers foo.agents.bot and does not cover foo.dev.agents.bot. The two namespaces do not intersect. The single point of contact between them is dev.agents.bot itself, which the outer zone could otherwise mint as an agent name, and that is guarded separately — by reserving the inner zone’s apex label in the outer zone’s own name registry, not by refusing the pair here. What this type does check is what only a set of zones can violate: the same hostname configured twice.

A deployment with one zone is the common case and stays exactly as simple as it always was: ZoneRegistry::single wraps it.

A zone here mints agents; the server’s own hostname might not be one

Zone::new(pds_host) makes pds_host itself an agent-minting zone — every label under it is a candidate agent name. A deployment delegating subzones keeps its own identity — its service DID, its own pages — as a Zone held separately, outside this registry.

Nested zones each need their own certificate

One wildcard cannot span both depths: agents.bot plus *.agents.bot is one certificate pair, and dev.agents.bot plus *.dev.agents.bot is another. A deployment nesting zones needs a certificate pair per zone.

Fields

zones: Vec<Zone>

The zones offered to ZoneRegistry::new, in order. None of them share a hostname; see ZoneRegistry::new.

Implementations

impl ZoneRegistry

pub fn new(zones: Vec<Zone>) -> Result<Self, ZoneRegistryError>

Assembles a registry, refusing a set with the same hostname twice.

zones is ordered; the first entry is the registry’s ZoneRegistry::default_zone. Each zone must already be independently valid — that is Zone::new and Zone::delegated’s job, not this one’s. Nesting is allowed; see the struct docs on why it is not the ambiguity a naive reading suggests, and on where the real protection against an outer zone minting an inner zone’s apex actually lives.

pub fn single(zone: Zone) -> Self

A registry holding exactly one zone. Cannot fail: one zone can never duplicate itself.

pub fn zones(&self) -> &[Zone]

Every configured zone, in the order they were offered.

pub fn default_zone(&self) -> &Zone

The registry’s default zone: the first one offered to ZoneRegistry::new, and where provisioning lands when nothing more specific routes it elsewhere.

Not to be confused with the server’s own identity, which is a separate Zone a deployment holds outside this registry — see the module docs on why a zone that mints agents and the PDS’s own hostname are not required to be the same hostname once subzones exist.

pub fn find(&self, host: &str) -> Option<&Zone>

The configured zone named host, if any.

pub fn containing(&self, host: &str) -> Option<&Zone>

The most specific configured zone host sits at or below, if any.

Zones may nest — see the struct docs — so a host can sit at or below more than one configured zone at once: everything under dev.agents.bot is, trivially, also under agents.bot. The deepest match, by label count, is the one that actually minted it, so that is what this returns. Two zones can never tie at the same depth without being the same zone, since a duplicate hostname is refused at construction.

Trait Implementations

impl Clone for ZoneRegistry

fn clone(&self) -> ZoneRegistry

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ZoneRegistry

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.