Aleph Bootstrap Sequences

This page ties together the real implementation paths across:

• the browser Sponsor Relay UI
• the guest VM bootstrap publisher
• the reusable UC rootfs workflow
• the shared @le-space/node deploy and site runners

It is meant as a visual map for the parts that are easiest to lose track of:

1. who owns bootstrap publication at runtime
2. when CRN allocation and runtime checks happen
3. how the workflow, guest, and browser hand off responsibility
4. which profiles still use relay bootstrap posts versus direct service metadata

The current code now has three distinct handoff patterns:

• uc-go-peer Browser-orchestrated Aleph aggregate handoff plus guest-owned bootstrap publication.
• orbitdb-relay Direct guest /configure with preseeded publisher identity and owner authorization.
• ucan-store Bootstrap-package-driven service wiring with runtime metadata, not relay bootstrap posts.

uc-go-peer: Browser To Guest Bootstrap Ownership

The current target behavior is still guest-owned runtime bootstrap publication, but the browser handoff is now more explicit than the original flow.

The browser still orchestrates the deployment and waits for confirmation, but the uc-go-peer handoff is now a multi-phase flow:

1. wait for usable runtime networking
2. wait for 2n6 activation when proxy-backed HTTPS is possible
3. publish vm-bootstrap-config into Aleph
4. wait for the guest config signal
5. confirm secure relay metadata
6. wait for the guest bootstrap registration
7. publish a browser fallback only when the guest registration stays delayed

What This Means

• The owner wallet is still authoritative for deployment and authorization.
• The guest VM becomes authoritative for the runtime relay address set.
• Discovery clients should trust the newest guest-visible bootstrap state, not workflow-baked constants.

orbitdb-relay: Direct Guest Configure With Preseeded Identity

The shared deploy runner now front-loads more of the bootstrap material for orbitdb-relay than the earlier flow did.

Two implementation changes matter most here:

1. the deploy executor now derives or accepts a dedicated bootstrap publisher key
2. the first /configure call already carries the owner authorization, so the older second configure pass is only a fallback path now

This direct guest-configure path also keeps the new runtime checks for rootfs visibility retries, CRN fallback, and proxy activation before guest setup. The proxy hostname and libp2p AutoTLS hostname are intentionally separate:

• Caddy owns only the reserved 2n6 hostname on ports 80 and 443; it uses HTTP-01 by disabling TLS-ALPN challenge handling, so Caddy does not compete with the relay's libp2p AutoTLS listener.
• orbitdb-relay keeps AutoTLS enabled by default and the guest refresh helper later appends the discovered *.libp2p.direct secure websocket addresses to VITE_APPEND_ANNOUNCE.
• The initial announce set still includes the public plain websocket port so libp2p AutoTLS can observe the externally reachable listener before the secure websocket addresses are known.

ucan-store: Bootstrap Package And Public Service Wiring

ucan-store now follows a different deployment contract from the relay profiles:

• no relay bootstrap registry publication
• optional bootstrap package derivation from the Aleph private key
• service DID/origin validation inside the guest before the service is allowed to stay up
• runtime discovery through guest metadata and /.well-known/ucan-store.json

Implementation Anchors

These diagrams are derived from the current implementation in:

• relay-button/packages/node/src/deploy-executor.ts
• relay-button/packages/node/src/action-runner.ts
• relay-button/packages/node/src/ucan-store-bootstrap.ts
• relay-button/packages/ui/src/shared/controller.ts
• relay-button/packages/core/src/guest.ts
• relay-button/packages/core/src/bootstrap-registration.ts
• relay-button/packages/core/src/bootstrap-config.ts
• relay-button/packages/rootfs/reference/uc-go-peer/rootfs/uc-go-peer-bootstrap-refresh.py
• relay-button/packages/rootfs/reference/orbitdb-relay/rootfs/orbitdb-relay-bootstrap-refresh.py
• relay-button/packages/rootfs/reference/ucan-store/rootfs/ucan-store-configure.sh
• relay-button/packages/rootfs/reference/ucan-store/rootfs/ucan-store-service-start.sh
• relay-button/packages/rootfs/reference/ucan-store/rootfs/ucan-store-describe.py

Practical Reading Guide

If you are debugging a broken rollout, read the system in this order:

1. rootfs publish and manifest outputs
2. VM deploy and CRN allocation notification
3. runtime suitability checks for proxy-backed HTTPS, including public guest IPv6
4. guest configure handoff: uc-go-peer uses vm-bootstrap-config, orbitdb-relay uses direct /configure, ucan-store uses a bootstrap package
5. guest metadata confirmation: relay multiaddrs for uc-go-peer / orbitdb-relay, service DID and PWA env for ucan-store
6. relay bootstrap registration visibility on Aleph: required for uc-go-peer and orbitdb-relay, intentionally skipped for ucan-store
7. browser fallback publication and handoff cleanup, when the uc-go-peer guest registration is delayed
8. final discovery path: relay bootstrap registry for the relay profiles, /.well-known/ucan-store.json for ucan-store

Delete And Orphan Cleanup

The registration lifecycle does not end at publish time. The Sponsor Relay UI also cleans up linked and orphaned registrations explicitly.