Buyer-facing stack

How SkyeMail is put together at the architecture level.

This is the public overview for buyers and clients. It names the operating layers, trust boundaries, and proof surfaces without publishing private implementation source.

Stack layers

SkyeMail is a sovereign mail workspace, not an implementation dump.

Identity and accessSkyeGate FS27/Free99 owns the gate session. SkyeMail consumes that shared 0S session and applies mailbox access rules inside the mail workspace.
Mailbox routing connectorThe hosted mailbox connector handles SkyeMail sync, outbound send, inbound webhook intake, reply import, and mailbox status without displaying private routing secrets to buyers.
Citadel data layerCitadel carries sovereign mail records, delivery receipts, proof state, encrypted payload metadata, mailbox identities, and operational evidence.
SkyeNet mail laneSkyeNet supports the live app lane: inbox refresh, send/read proof, mailbox switching, route compatibility, and scheduled sync.
SkyeMail app surfaceThe user-facing app contains inbox, compose, sent, contacts, settings, monitoring, proof, and onboarding views tied to the selected mailbox.
Proof surfacesLive Proof, Security, and this page are the buyer-facing architecture surfaces. Internal implementation details stay private.

Mail flow

The high-level mail path.

1. Gate sessionThe user enters through the shared 0S gate, and SkyeMail receives the mailbox context for the session.
2. Send or syncCompose, reply, inbound webhook, and scheduled refresh paths move through the hosted mailbox connector.
3. Sovereign recordCitadel and SkyeNet keep delivery, receipt, sync, and encrypted inbox state aligned for the app and proof surfaces.