263 lines
5.4 KiB
Markdown
263 lines
5.4 KiB
Markdown
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.
|
||
|