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

This is a foundational question, and you’re asking it at exactly the right abstraction level. I’ll 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 brother’s “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. That’s 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

That’s 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

That’s 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. It’s 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 don’t 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

You’re very close to something that feels obvious once it exists — which is the sign you’re doing it right.