amduat-api/notes/Clarify the differences between Common, Group, and Personal domains.md

292 lines
6 KiB
Markdown
Raw Normal View History

Excellent question. This is exactly the right place to tighten the model.
Ill 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)**
Ill 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 hosts 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
```yaml
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)**
Youre no longer mixing projects here — this is now one coherent system.