niklas/amduat-api
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
amduat-api/notes/Clarify the differences between Common, Group, and Personal domains.md
Carl Niklas Rydberg 1d552bd46a Added some notes that needs to be analyzed.
2026-01-17 00:19:49 +01:00

6 KiB
Raw Blame History

Excellent question. This is exactly the right place to tighten the model.

I’ll do three things, in order:

  1. Specify how ASL-HOST enforces witness authority at boot (normative)
  2. Explain how this generalizes to non-Common domains
  3. Clarify the differences between Common, Group, and Personal domains (and why they are not fundamentally different)

I’ll keep it crisp and spec-like, but readable.

ASL-HOST Witness Enforcement at Boot (v0.1)

1. Purpose

This section defines how an ASL-HOST determines whether it is allowed to:

  • accept snapshots
  • advance CURRENT
  • emit new snapshots

for any domain, with Common as the canonical example.

The same mechanism applies to personal and group domains, with different policies.

2. Core rule (universal)

An ASL-HOST MUST NOT advance a domain unless it can prove authority to do so from domain-local artifacts.

There is no implicit authority, no “trusted runtime”, and no network trust.

Authority is always:

  • explicit
  • artifact-backed
  • snapshot-bound

3. Boot-time domain authority resolution

At boot, for each configured domain, ASL-HOST performs the following steps.

3.1 Load domain state

For each domain D:

  1. Mount domain store (filesystem, ZFS dataset, etc.)

  2. Load:

    • last sealed snapshot D@N
    • append-only log (if present)

  3. Reconstruct CURRENT(D) deterministically

If this fails → domain is read-only.

4. Authority discovery

4.1 Authority source artifacts

ASL-HOST MUST locate, for domain D:

  1. Domain Authority Manifest (DAM)
  2. Current Policy Artifact
  3. Witness-related artifacts (if any)

These MUST be:

  • sealed
  • visible at or below D@N
  • valid under ASL-STORE rules

5. Witness model (generalized)

Every domain operates under exactly one authority mode at any snapshot:

Mode Meaning
single-witness One domain/key may emit snapshots
quorum-witness A threshold of domains may authorize emission
self-authority This host’s domain is the witness

This is policy-defined, not hard-coded.

6. Common domain (special only in policy)

6.1 Common authority rules

For common:

  • Authority mode: quorum-witness

  • Emission rights:

    • granted only to the active witness domain

  • Witness rotation:

    • only via asl.common.witness-rotation artifacts

6.2 Boot enforcement

At boot, ASL-HOST MUST:

  1. Identify current witness from last snapshot

  2. Verify:

    • witness domain ID
    • witness public key

  3. Lock Common domain into one of:

State Meaning
Passive May consume Common snapshots
Active May emit Common snapshots
Invalid Must refuse Common entirely

An ASL-HOST MUST NOT emit Common unless explicitly Active.

7. Personal domains (important clarification)

Personal domains are not special.

They differ only in policy defaults.

7.1 Typical personal domain policy

authority_mode: self-authority
authorized_keys:
  - owner-key

This means:

  • Any host holding the private key may emit snapshots

  • Multiple machines can advance the domain

  • Conflicts are resolved via:

    • snapshot ordering
    • logseq
    • or explicit merge PELs

7.2 Boot behavior

At boot, ASL-HOST:

  • checks whether it holds a valid private key
  • if yes → Active
  • if no → Passive (read-only replica)

This allows:

  • laptops
  • desktops
  • VMs
  • rescue environments

to all participate safely.

8. Group domains

Group domains sit between Common and Personal.

8.1 Group authority models

Common patterns:

Model Use case
single-witness One maintainer
quorum-witness Shared governance
rotating-witness Time-based or role-based

8.2 Enforcement is identical

ASL-HOST does not care whether a domain is:

  • Common
  • Group
  • Personal

It only evaluates:

  • current snapshot
  • policy artifact
  • authority proofs

9. Snapshot emission decision (normative)

Before emitting a snapshot for domain D, ASL-HOST MUST verify:

  1. It holds a private key authorized by policy

  2. No conflicting authority artifact exists above D@N

  3. For quorum:

    • required endorsements are present and valid

  4. The snapshot references:

    • authority context
    • policy version
    • (if applicable) witness rotation artifact

If any check fails → emission is forbidden.

10. Read vs write separation (important)

An ASL-HOST may always:

  • store artifacts
  • verify snapshots
  • mirror domains

But may only:

  • emit snapshots
  • advance CURRENT

when authority is proven.

This allows:

  • mirrors
  • caches
  • rescue systems
  • offline nodes

to coexist safely.

11. Why this scales to “personal everywhere”

Your intuition is correct:

personal domains may live on many machines and need the same sync guarantees.

This model gives you:

  • snapshot identity
  • deterministic replay
  • conflict-free history by construction
  • explicit governance when needed

There is no need for a different mechanism.

12. One mental model to keep

Every domain is Common to someone. The difference is only who is allowed to speak for it.

13. What this enables next

With this in place, you can cleanly specify:

  • personal multi-device sync
  • offline-first workflows
  • rescue-domain bootstrap
  • federation without global servers
  • gradual transition from single-owner → group → common

If you want, next good steps would be:

  • formalize Domain Authority Manifest (DAM) enforcement at boot
  • specify multi-writer personal domain merge semantics
  • walk through one personal domain on 3 machines
  • or describe Common startup from zero (genesis)

You’re no longer mixing projects here — this is now one coherent system.