292 lines
6 KiB
Markdown
292 lines
6 KiB
Markdown
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
|
||
|
||
```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)**
|
||
|
||
You’re no longer mixing projects here — this is now one coherent system.
|
||
|