amduat-api/notes/Re-anchoring any node can become a system.md

That sentence — “any node can become a system” — is actually the right mental hook for what you’re building. You’re just applying it at the PEL + TGK semantic layer, not the SystemRescue layer. That’s an important shift, and it exposes exactly the missing piece you’re feeling: identity, authority, and certification.

Let’s align the layers cleanly and then answer your question about users, ownership, and whether ZFS helps.

---

1. Re-anchoring “any node can become a system”

In your architecture, a system is not a machine and not a filesystem. A system is:

A domain that can produce, seal, snapshot, and attest to deterministic artifacts and executions.

So:

• A laptop
• A rescue USB
• A build farm node
• A CI runner
• A forensics machine

…can all “become a system” if they can:

1. Produce artifacts/PERs
2. Seal them
3. Attach provenance
4. Publish them under a domain identity

SystemRescue gives you capability. PEL + TGK give you meaning. What’s missing is authority.

---

2. What ZFS can and cannot do here

What ZFS can help with

ZFS gives you:

• Snapshot identity (strong, immutable)
• Retention pins
• Integrity guarantees
• A natural “domain-local root of persistence”

This makes ZFS an excellent substrate for authority anchoring.

What ZFS cannot do

ZFS does not provide:

• Users
• Identities
• Ownership semantics
• Certification
• Trust relationships

ZFS can host trust anchors — it cannot define them.

---

3. Users are not UNIX users (important)

If you try to map this to:

• /etc/passwd
• UID/GID
• POSIX permissions

You will break your own model.

In your system:

Users are cryptographic principals, not OS accounts.

That’s the key.

---

4. The missing layer: Domain Identity & Authority (DIA)

You are missing a small but crucial layer that sits above ASL/PEL/TGK and below federation.

Let’s call it (name optional):

Domain Identity & Authority (DIA)

This layer defines:

• Who may assert artifacts
• Who may seal snapshots
• Who may publish state
• Who may certify execution receipts

---

5. What a “user” actually is in your system

A user is:

A keypair that is authorized to act for a domain under specific roles.

Not a login. Not a shell. Not a UID.

Example roles

• producer — may generate artifacts
• executor — may emit PERs
• publisher — may publish snapshots
• auditor — may verify, not write

Roles are semantic, not filesystem permissions.

---

6. Where identity lives (and yes, ZFS helps here)

Domain identity root (per domain)

/asl/domain/
├── domain.id
├── domain.pubkey
├── authorities/
│   ├── root.pub
│   ├── ci.pub
│   └── rescue.pub
├── policies/
│   └── publish.policy
└── attestations/

This lives:

• On ZFS
• Inside a snapshot
• Pinned
• Immutable once sealed

This is your domain root of trust.

---

7. Certification: what gets certified?

Not machines. Not users. Not files.

You certify statements.

Examples:

• “This snapshot represents /home as of logseq X”
• “This PER was executed from these inputs”
• “This artifact corresponds to this path”

These certifications are artifacts themselves.

That’s the big insight.

---

8. Execution receipt certification (PEL + TGK)

A PER becomes authoritative only when:

1. Inputs are snapshot-bound
2. Execution is deterministic
3. PER is signed by an authorized key
4. Signature is stored as an artifact
5. TGK edge links PER → signature → snapshot

This gives you:

• Non-repudiation
• Replayable verification
• Cross-domain trust

No mutable ACLs. No global PKI required.

---

9. Ownership is about who can publish

Ownership in your system is:

The right to publish artifacts into a domain’s visible state.

That’s it.

• Anyone can produce internally
• Only authorized keys can publish
• Federation only sees published state

This matches your federation spec perfectly.

---

10. What SystemRescue becomes in this model

SystemRescue is just:

A transient node that can temporarily act under a domain identity.

It may:

• Import a domain key (hardware token, USB)
• Produce recovery artifacts
• Emit PERs
• Publish a recovery snapshot

Then disappear.

The authority lives in the domain, not the machine.

---

11. Why this completes “any node can become a system”

Because now:

• A node + tools + a key = a system
• Without a key, it’s just a reader
• With a key, it can assert truth
• ZFS ensures what was asserted cannot be silently altered

That’s the closure you were missing.

---

12. The minimal thing you need to add (not a big system)

You do not need:

• LDAP
• OAuth
• POSIX ACLs
• Distributed consensus

You need:

• Domain keypairs
• Signed artifacts
• Snapshot-pinned authority state
• Simple role policies

That’s it.

---

13. One-sentence takeaway

ZFS gives you immutability; ASL gives you determinism; PEL gives you meaning; TGK gives you structure — but only cryptographic domain identity turns a node into a system.

If you want, next we can:

• Specify a minimal Domain Authority Manifest
• Define the PER signature format
• Walk through “archived home directory” as a certified execution
• Show how federation validates authority without trusting nodes

This is the missing keystone — and you were already circling it.