amduat-api/notes/The Domains You Are Actually Creating.md

350 lines
5.7 KiB
Markdown
Raw Normal View History

This is a *foundational* question, and youre asking it at exactly the right abstraction level.
Ill answer it in a way that **does not lock you into ZFS, POSIX, or any single worldview**, but shows how they *fit*.
What follows is a **clean domain topology**, **backend mapping**, and a **seeding story** that lets the “common” crystallize naturally instead of being designed top-down.
---
# 1. The Domains You Are Actually Creating
You are not creating “many domains”.
You are creating **three roles**, which may be instantiated multiple times.
## 1.1 The Common Domain (shared reality)
```
domain: common
```
**Purpose**
* Shared, boring, necessary facts
* Toolchains
* Base artifacts
* Shared schemas
* Canonical references
**Properties**
* Conservative
* Slow-moving
* High trust threshold
* Read-mostly
Think of this as:
* `/usr`
* `/nix/store`
* `/lib`
* Wikipedia, but frozen and replayable
This is where your brothers “Unity tree” intuition lives.
---
## 1.2 Personal Domain (agency)
```
domain: you
```
**Purpose**
* Your identity
* Your choices
* Your publications
* Your private state
**Properties**
* You own the roots
* You decide what to publish
* You may fork or disagree with “common”
This is:
* Your `$HOME`
* Your git identity
* Your signing authority
---
## 1.3 Working / Ephemeral Domains (action)
```
domain: you/work/…
domain: you/rescue/…
domain: you/experiment/…
```
**Purpose**
* Do things
* Run PEL
* Recover machines
* Import legacy data
**Properties**
* Delegated authority
* Narrow policy
* Often short-lived
* Results may be promoted upward
These are **verbs**, not nouns.
---
## 2. How These Domains Relate (Important)
They are **not hierarchical**.
Instead:
* Personal domain **pins** Common
* Working domains are **authorized by** Personal
* Publication is **explicit**
Graphically:
```
common
↑ (trust pin)
you
↓ (delegation)
you/rescue/laptop
```
No implicit inheritance.
No magical visibility.
---
# 3. Filesystems and Backends (Practical, Not Ideological)
You already have POSIX. Thats fine.
ASL **does not require** anything special — it requires **semantics**, not magic.
## 3.1 Minimum viable ASL backend
You need three things:
```
/asl/
blocks/
index/
log/
```
This can live on:
* ext4
* XFS
* ZFS
* tmpfs (for tests)
### Blocks
* Files named by BlockID
* Immutable once sealed
* Can be encrypted or plaintext
### Index
* Segment files
* Append-only
* Memory-mapped friendly
### Log
* Append-only
* Totally ordered
* Small
Thats it.
---
## 3.2 ZFS (where it helps, not dominates)
ZFS is *excellent* for:
* Snapshots as checkpoints
* Replication
* Retention
* Scrub / integrity
Recommended layout:
```
zpool/asl/common
zpool/asl/you
zpool/asl/you_work
```
Each dataset:
* Independent snapshots
* Independent GC
* Independent policy
ZFS is **not** your semantic layer.
It is your **reliable substrate**.
---
## 4. Seeding the Common Domain (this is subtle)
The common domain must **not** be “yours”.
It must start **empty or minimal**.
### 4.1 Initial common contents
Seed only:
* ASL schemas
* TGK schemas
* PEL operator definitions
* Hash algorithms
* Encoding specs
No opinions.
No personal data.
Think: *standards, not content*.
---
### 4.2 How common grows
Common grows when:
* Multiple personal domains independently publish the same artifacts
* Agreement is explicit
* Provenance is preserved
This is *emergent consensus*, not curation.
---
## 5. Seeding Your Personal Domain
Your personal domain starts with:
1. Your offline roots
2. Your DAM
3. Policy hash
4. Trust pin to common
Thats it.
Everything else is created via **working domains**.
---
## 6. The “Home Directory” Model (this matters)
Your intuition here is correct.
### `$HOME` is a domain, not a directory
```
domain: you/home
```
What lives here:
* Your files
* Your configs
* Your history
* Your backups
* Your recovered artifacts
This domain:
* Can publish subsets
* Can snapshot aggressively
* Can be encrypted-at-rest
The POSIX home directory is just a *view*.
---
## 7. The “Common Group” (rakeroots / unity)
Here is how the “common group” crystallizes **without central planning**.
### 7.1 Group domain
```
domain: you+brother/common
```
Properties:
* Multi-root authority
* Requires joint signatures
* Narrow scope
### 7.2 What goes here
* Family photos
* Shared documents
* Shared tooling
* Shared indexes
This is **not global common**.
Its *your* common.
Others will have theirs.
---
## 8. Why This Scales Socially
Different people will have:
* Different commons
* Different trust roots
* Different overlaps
But:
✔ Artifacts are immutable
✔ Provenance is explicit
✔ Publication is voluntary
✔ Conflicts dont corrupt history
This avoids the “one true tree” trap.
---
## 9. Mental Model That Locks It In
* **Common** = gravity
* **Personal** = agency
* **Working** = motion
* **Filesystems** = substrate
* **Domains** = meaning
* **Snapshots** = memory
---
## 10. One-sentence answer to your question
> You create a minimal Common domain for shared semantics, a Personal domain for identity and choice, and delegated Working domains for action — all backed by simple POSIX storage (optionally ZFS), with “home” and “common” emerging as published, snapshot-pinned domains rather than directories.
---
If you want, next we can:
* Draw the **exact on-disk layout**
* Specify **CLI flows** (`asl init-domain`, `asl publish`)
* Model **multi-user common domains**
* Define **GC across personal + common safely**
Youre very close to something that feels *obvious* once it exists — which is the sign youre doing it right.