Decision — service property storage belongs in props

Status: accepted 2026-10-18.

The decision

libs/props owns the shared service property substrate: namespace schemas, capabilities, hooks, lifecycle, audit, storage, mutation routing and event dispatch. Its empty default feature set remains pure types and revisions; store, sqlite and router add the respective facilities.

libs/logging owns the reserved log namespace and live-filter watcher, behind its opt-in props feature. Services supply domain-table mappings and use their existing native Bus connection for subscription grants and publication. No new crate, transport or broker is introduced.

The condensed contract preserves capability strings, verb envelopes, errors, topic suffixes, audit canonicalisation and the five __props_* table names and DDL. Persisted databases require no migration. noded.props.subscribe_grant, already served by the broker, is registered as an intent because it installs a subscription for another peer. Concrete service verbs are registered when their owner adopts them.

Why

Service domain data and the logging bridge need the same schema, storage, audit and native routing contracts. Keeping those contracts beside the existing property read surface avoids duplicate stores and projection logic; replay and live delivery use the same functions. Optional features keep database and runtime dependencies out of pure readers. This is the deliberate shared API boundary for logging and the forthcoming mail service port, with other domain services able to use the same substrate.

Authority and secrets

settingsd continues to own desktop and session settings. This substrate owns each service's durable domain records: a mail server's mailbox accounts are distinct from the email application's email.accounts profile group. It creates no second authority for desktop preferences.

The email settings decision continues to govern app passwords. Fields declared secret are redacted on ordinary reads, public describe and passive events; audit keys never enter the Bus. An explicit secrets-read capability remains part of the existing privileged service contract. No application password publication is added.

This page as Markdown · This page describes the current main branch of MixOS.