Platform
The architecture that is actually running
The old page invented a named capability matrix and guarantees that were not present in the current source. This page now follows Core's real guild-state, Nexus-auth and network contracts.
Architecture
Core, Network and Nexus
Guild-keyed state
Core state reads and writes use the active Discord guild ID, including the public HQ bridge and native Nexus domains.
Tenant registry
Kingdom Network keeps registered tenant records and combines them with Discord guilds currently connected to the runtime.
Discord session auth
Nexus uses Discord OAuth sessions, revalidates them, and applies additional operator authorization to sensitive control surfaces.
Server-side secrets
Bot tokens, OAuth secrets, session secrets and private HQ bridge tokens remain in server/runtime configuration rather than browser bundles.
Optional infrastructure
The default runtime can use Kingdom JSON state and local Vault snapshots; PostgreSQL and Redis adapters are optional.
Native live stream
Kingdom Live exposes a Server-Sent Events stream with snapshot fallback through the authenticated Nexus API.
Nexus access model
Nexus first validates the Discord session. Operator-only reads then apply an operator authorization check, while protected write methods also require a valid CSRF token.
- Public health endpoint
- Public session-discovery endpoint
- Authenticated operational API
- Operator-only sensitive reads
- Operator authorization on privileged mutations
- CSRF checks on protected write methods
Network model
The current network summary combines live Discord guild connections with tenant records stored in Nexus state, then reports connected and registered counts from those actual records.
Open the current Kingdom Core stack
Add the Discord application, preview the current /setup3 layout before applying it, and use the production Nexus for authenticated web operations.