Not every service should live in the same place, replicate the same way, or be governed by the same rules. Community infrastructure gets safer when service placement, sync scope, and operator authority are documented as intentionally as the hardware.
A community node is not improved by pushing every function upstream or by insisting everything remain isolated forever. The useful middle ground is to classify services by what breaks if connectivity disappears, what information can safely travel, and what authority should remain local even when other systems federate.
The matrix below is not a product roadmap. It is an operator reference: where the source of truth lives, whether a service syncs or mirrors, who can change it, and what should happen when a node loses upstream connectivity.
The right placement question is not “can this be cloud-hosted?” It is “where should the authoritative copy live, who can change it, and what remains useful if connectivity drops?”
| Service | Placement | Federation / mirror policy | Governance note |
|---|---|---|---|
| Build library mirror | regional mirror | Mirror broadly; keep signed artifacts and docs in multiple regions. | Content updates can be delegated; integrity policy should be steward-controlled. |
| Community status dashboard | local primary | Local truth first; optionally publish read-only summaries outward. | Thresholds and public wording should be documented locally. |
| TheEtherNet relay / cache | local primary + sync | Queue and reconcile with peers when links return. | Moderation and trust policies should stay legible per node. |
| Identity / session broker | local-only or tightly scoped sync | Do not replicate secrets casually; define explicit federation rules. | Secret rotation and schema changes require named stewards. |
| Package / image cache | regional mirror | Mirror aggressively to improve rebuild speed and reduce WAN cost. | Integrity verification matters more than broad write access. |
| Public announcements | public edge | Safe to publish widely if sourced from documented local approval. | High-trust publication should still have a clear sign-off path. |
Governance is not bureaucracy for its own sake. It is how communities prevent accidental centralization, silent credential drift, and ambiguous responsibility. The useful version is lightweight but explicit: who can approve what, who holds secrets, who can declare an incident, and where the operator log lives.
Communities do not need corporate ceremony. They do need a repeatable path for changing service placement, federation policy, or credentials without losing track of what changed, why, and how to roll it back.
The service matrix becomes valuable when it shortens restore and escalation time. During an outage or dispute, operators should immediately know where the authoritative copy lives, whether a peer can help, which steward is allowed to authorize changes, and which runbook applies to the affected service class.
Use the matrix to identify which services must remain on-node, which can be temporarily served from mirror copies, and which public publications should be paused.
Trust-policy disputes should route through named stewards rather than ad hoc operator edits. Shared formats do not require shared unquestioned authority.
If secrets are rotated or suspected compromised, the matrix should already show which services are affected and which mirrored or public lanes can remain up safely.
The matrix and operator packet together should let a new steward see service ownership, sync scope, and approval boundaries without tribal knowledge.
Use the node spec for hardware, topology, and the baseline service set this matrix classifies.
Open Node SpecThe federation guide explains peer relationships. This page decides which services should actually use them.
Open Federation GuideThe runbook handles backups, restores, incidents, and handoff. The matrix gives those runbooks service-specific boundaries.
Open Operations RunbookService placement is only half the governance story. The identity guide defines credential custody, peer trust scope, and which stewards can re-establish authority when something breaks.
Open Identity & Trust GuideThe operator handbook defines who can reclassify a service, authorize risky degraded modes, or invoke custody and escalation procedures.
Open Operator HandbookThe runbooks turn placement policy into action by giving identity, mirror, relay, and backup services their own recovery and verification path.
Open Service RunbooksThe hardware matters because locality and authority decisions are only real when communities can host them on their own equipment.
Open Device BlueprintThe homepage now ties together blueprint, network stack, federation, operations, service governance, stewardship, and runbooks as one practical autonomy stack.
Open Homepage Network LayerService locality determines how the social layer remains useful during upstream loss without collapsing moderation and trust policy into one opaque center.
Open TheEtherNet