Module federation 

v0.39: Hub federation — peer registry + conflict detection.

Pre-v0.39, every Vela frontier had exactly one source of truth: the single hub it was published to (vela-hub.fly.dev). The substrate claimed the kernel was content-addressed and signed, but the distribution layer was centralized — there was no way for a second hub to mirror a frontier and detect when its view diverged from the original.

v0.39.0 lands the schema layer of federation. A frontier can now register peer hubs (id + URL + public key) in Project.peers, and the kernel knows two new event kinds:

• frontier.synced_with_peer — append-only record of a sync pass: what we exchanged, what hash we ended up agreeing on, how many findings differed.
• frontier.conflict_detected — emitted per finding when our view and the peer’s view disagree on a substantive field (review verdict, confidence, retraction, presence).

The actual sync runtime (HTTP fetch, manifest verification, conflict-resolution proposal emission) ships in v0.39.1+. Same staging discipline as v0.32 (Replication object) → v0.36.1 (Project.replications becomes authoritative) and v0.38.0 (causal schema) → v0.38.1 (causal math).

Doctrine for v0.39.0:

• The peer registry is a frontier-local declaration. Adding a peer does not yet trust their state; it just establishes who we know about.
• Peer signatures still verify under the same Ed25519 discipline as actors. A peer’s frontier.merged event signed by their key can be replayed locally only when their pubkey is in our peers registry.
• Conflicts are recorded, not auto-resolved. v0.39.1+ will surface them through proposals so a human reviewer chooses which side to accept.

Structs

Conflict

One per-finding disagreement detected during sync.

PeerHub

v0.39: A registered peer hub the local frontier knows about. Content-addressed by (id, public_key) so two registry entries for the same peer with different keys can be detected as a material change rather than silent overwrite.

SyncReport

Result of one sync_with_peer pass.

Enums

ConflictKind

v0.39.1: Conflict taxonomy. The kinds of disagreement two hubs can have over the same vfr_id. v0.39.0 left kind as an open string; v0.39.1 pins it to this closed set, derived from auditing every substantive field-level disagreement we expect to see.

DiscoveryResult

v0.41.0: Result of trying to discover a peer’s frontier through the hub’s /entries/<vfr_id> endpoint. The runtime needs to distinguish three failure modes — peer unreachable, registry entry signature invalid, and locator URL dead — because each one has a different remediation.

Functions

classify_peer_event_set

v0.85: Classify the merge action for a peer event set against our local event log. Pure event-level algebra: takes peer event summaries (id, parents) and our local pool, and decides whether merge can proceed or whether ancestors must be fetched first.

diff_frontiers

v0.39.1: Diff two frontiers and produce a list of conflicts. Pure function, no I/O. The peer’s state is passed in directly so the sync orchestrator can be unit-tested without HTTP.

discover_peer_frontier

v0.41.0: Discover a peer frontier by routing through the hub’s /entries/<vfr_id> endpoint. Verifies the registry entry’s signature against expected_owner_pubkey, then follows entry.network_locator to fetch the actual manifest.

fetch_peer_frontier

v0.39.1: Fetch a peer’s frontier JSON over HTTP. The URL is expected to serve a JSON-serialized Project. Blocking call — vela federation sync is a one-shot CLI verb, not a service.

record_locator_failure

v0.41.0: Record a single broken-locator conflict against a peer. Emits one frontier.synced_with_peer event with divergence_count = 1 plus one frontier.conflict_detected event of kind broken_locator. Used when the peer hub is reachable, its registry entry signature verifies, but the locator URL the entry points at returns 4xx/5xx — common for stale published locators after a repo move.

record_unverified_entry

v0.41.0: Record an unverified-peer-entry conflict. Same shape as record_locator_failure but for when the peer’s registry entry signature did not verify against the registered owner pubkey. Sync halts before any content is fetched — the kernel won’t trust unsigned-or-misverified state.

sync_with_peer

v0.39.1: Run a full sync pass against a peer’s already-fetched frontier state. Diffs, emits one frontier.synced_with_peer event recording the pass, and one frontier.conflict_detected event per disagreement. Returns the report; caller persists the project.