niklas/amduat-api
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

Remove legacy ops drafts

Browse source
This commit is contained in:
Carl Niklas Rydberg 2026-01-17 09:23:15 +01:00
parent 74efedf62c
commit 4989baf623
14 changed files with 0 additions and 2744 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

291
ops/legacy/ASL SystemRescue Overlay – Intake Schema.md
View file

@ -1,291 +0,0 @@
Perfect — then let’s be very concrete and **treat the overlay itself as a specification**, not just “put binaries somewhere”.
Below is a **clean, minimal, opinionated overlay schema** for an **ASL intake / rescue environment**, aligned with everything you’ve defined (ASL, STORE-INDEX, federation, ZFS optional).
No diagrams, no fluff.
---
# ASL SystemRescue Overlay – Intake Schema
This overlay defines **what exists at boot**, **where state lives**, and **what is immutable vs runtime**.
---
## 1. High-level intent
The overlay must:
* Make ASL tools **always available**
* Be **stateless by default**
* Support **local ZFS intake OR remote ASL intake**
* Keep **semantic state out of the rescue image**
* Be safe on crashed systems
So the overlay provides:
* **executables**
* **configuration defaults**
* **service wiring**
* **well-known mount points**
Nothing else.
---
## 2. Canonical overlay layout
```
overlay/
├── usr/
│ └── local/
│ ├── bin/
│ │ ├── asl-intake
│ │ ├── asl-admin
│ │ └── asl-debug
│ └── lib/
│ └── libasl.so
│
├── etc/
│ └── asl/
│ ├── asl.conf # mode selection, endpoints
│ ├── federation.conf # domain + peer config
│ └── logging.conf
│
├── etc/systemd/system/
│ ├── asl-intake.service
│ └── asl-preflight.service
│
├── var/
│ └── lib/
│ └── asl/
│ ├── runtime/ # ephemeral runtime state
│ ├── cache/ # optional CAS cache
│ └── locks/
│
├── run/
│ └── asl/
│ └── sockets/ # if used (optional)
│
└── mnt/
└── asl/
├── local/ # local ZFS mount target
└── remote/ # optional remote FS
```
This is the **entire contract** between SystemRescue and ASL.
---
## 3. What each directory *means* (important)
### `/usr/local/bin`
**Immutable tools**
* `asl-intake`
Primary recovery/intake executable
* `asl-admin`
Inspection, snapshot listing, GC checks
* `asl-debug`
Low-level validation, block/segment inspection
> These must never write here.
---
### `/etc/asl`
**Declarative configuration only**
Example `asl.conf`:
```
mode = auto # auto | local | remote
local.mount = /mnt/asl/local
remote.endpoint = https://asl-backend
domain.id = rescue-domain
```
Rules:
* No secrets unless unavoidable
* No mutable state
* Safe to ship in ISO
---
### `/var/lib/asl`
**All mutable local state**
This is the *only* place your tools write to by default.
```
/var/lib/asl/runtime # PID files, temp metadata
/var/lib/asl/cache # optional local CAS cache
/var/lib/asl/locks # advisory locks
```
This may live:
* in RAM (default)
* on USB persistence
* never on the broken system disk
---
### `/mnt/asl/local`
**Local ASL backend mount (ZFS)**
If local intake is possible:
```
zpool import rescuepool
zfs mount rescuepool/asl → /mnt/asl/local
```
Your tool treats this as:
```
/mnt/asl/local/
├── blocks/
├── segments/
├── snapshots/
└── logs/
```
(Exact internal layout is backend-defined, not overlay-defined.)
---
### `/mnt/asl/remote`
Optional:
* NFS
* SSHFS
* Debug mounts
Not required for normal operation.
---
## 4. systemd services (minimal and safe)
### `asl-preflight.service`
Runs once at boot.
Responsibilities:
* Detect network
* Detect ZFS availability
* Detect importable pools
* Write decision to `/run/asl/mode`
No mutations.
---
### `asl-intake.service`
Starts the tool.
Example behavior:
* Reads `/run/asl/mode`
* Chooses:
* local ZFS backend
* or remote ASL endpoint
* Starts intake loop or waits for operator
This keeps **policy out of the binary**.
---
## 5. Local vs remote handling (explicit contract)
### Local ZFS mode
The overlay guarantees:
```
/mnt/asl/local exists
/var/lib/asl writable
/usr/local/bin contains tools
```
Your tool guarantees:
* Never mutate unsealed data
* Never auto-import pools without operator or config approval
---
### Remote ASL mode
The overlay guarantees:
* Network tools available
* TLS roots present
* Configurable endpoint
Your tool guarantees:
* Snapshot-bounded reads
* Deterministic uploads
* Idempotent retries
---
## 6. What is *explicitly forbidden* in the overlay
These rules prevent disasters:
❌ Writing to `/usr`, `/bin`, `/lib`
❌ Storing state in `/etc`
❌ Auto-mounting the crashed system root
❌ Assuming ZFS exists
❌ Assuming network exists
All assumptions must be **detected, not presumed**.
---
## 7. Why this schema works with your ASL design
This layout aligns perfectly with your specs because:
* **ASL-STORE-INDEX**
→ persistence lives outside the overlay
* **Federation**
→ domain identity is config, not state
* **PEL / TGK**
→ execution artifacts are handled like any other artifact
* **Determinism**
→ overlay never contains semantic state
The overlay is **pure capability**, not data.
---
## 8. Summary (the one-paragraph version)
> The SystemRescue overlay should contain **only tools, config, and wiring**.
> All mutable ASL state lives either in `/var/lib/asl` (ephemeral) or in a mounted backend (`/mnt/asl/local` or remote).
> The overlay never encodes semantic state, snapshots, or artifacts — only the ability to access and produce them.
If you want, next we can:
* Turn this into a **formal overlay contract doc**
* Define a **preflight decision table**
* Or map this schema directly onto your ASL backend spec
But this layout is already “correct by construction.”

116
ops/legacy/ASL-AUTH-HOST Configuration.md
View file

@ -1,116 +0,0 @@
Perfect! Here’s an example `config.yaml` for your `asl-auth-host`. This integrates domains, courtesy leases, snapshots, and SOPS bundle paths in a way that your host can start in “ready-for-pickup” mode or perform a rescue.
---
## `/etc/asl-auth-host/config.yaml`
```yaml
# ASL-AUTH-HOST Configuration
# Defines domains, policies, and SOPS bundles for bootstrap or rescue
host:
name: "asl-auth-host-01"
version: "0.1"
mode: "rescue" # modes: "rescue" | "admission" | "normal"
domains:
common:
id: "00000000-0000-0000-0000-000000000001" # Courtesy/common domain
type: "courtesy"
description: "Shared courtesy domain for new users or bootstrapped material"
path: "/var/lib/asl/common"
snapshot_retention: 30d
allowed_operations:
- read
- write
- append
courtesy_lease: 7d # Default grace period for newcomers
personal:
id: "00000000-0000-0000-0000-000000000002" # Personal private domain
type: "private"
description: "Private domain for rescued material or user-owned data"
path: "/var/lib/asl/personal"
snapshot_retention: 90d
allowed_operations:
- read
- write
- append
- seal
- gc
certificates:
root_offline_path: "/var/lib/asl/certs/root-offline"
domain_authority_path: "/var/lib/asl/certs/domain-authority"
sops_bundle_path: "/var/lib/asl/certs/sops"
policy:
hash_file: "/etc/asl-auth-host/policy.hash"
description: "Offline policy hash used to verify compliance before admission or rescue"
logging:
path: "/var/log/asl-auth-host.log"
level: "INFO"
store:
type: "zfs" # or "posix"
pools:
- name: "common_pool"
mount_point: "/var/lib/asl/common"
- name: "personal_pool"
mount_point: "/var/lib/asl/personal"
enable_snapshotting: true
snapshot_prefix: "asl_snap"
# Optional hooks for init scripts
hooks:
pre_start: "/bin/init-asl-host.sh"
post_start: "/bin/helper-mount.sh"
```
---
### Notes:
1. **`host.mode`**:
* `"rescue"` → SystemRescue boot with ready-for-pickup for old material.
* `"admission"` → Host expects to receive a DAM and SOPS bundle for new personal domain.
* `"normal"` → Standard operation with personal domain active.
2. **Domains**:
* **Common**: Courtesy domain, short-term leases for newcomers.
* **Personal**: Private domain, snapshots and sealing enabled.
3. **Certificates**:
* Paths to offline root certs, DAM bundles, and SOPS bundles.
4. **Policy hash**:
* Offline verification ensures host doesn’t act on incompatible policies.
5. **Store config**:
* Can be POSIX or ZFS-based.
* Supports snapshotting for deterministic recovery.
6. **Hooks**:
* Allows you to initialize ZFS pools, mount overlays, or start ASL binaries.
---
This config gives you a **bootable, ready-for-pickup SystemRescue node** that can handle:
* Receiving old data
* Creating your personal domain
* Storing material safely in courtesy/common domain
* Verifying offline DAM bundles before admission
---
I can also **draft the accompanying init script (`init-asl-host.sh`)** that reads this config, sets up domains, mounts pools, and prepares the store for immediate rescue or admission.
Do you want me to do that next?

112
ops/legacy/ASL-AUTH-HOST ISO + Overlay Directory Layout.md
View file

@ -1,112 +0,0 @@
Perfect! Here’s a **concrete directory layout blueprint** for your `asl-auth-host` ISO + overlay, ready to drop in binaries, certificates, and configuration. This integrates the concepts we discussed: domains, certificates, personal/common datasets, and the overlay structure.
---
## ASL-AUTH-HOST ISO + Overlay Directory Layout
```
/iso_root/ # Root of ISO filesystem (from debootstrap)
/bin/ # Executables
asl-auth-host # Main host binary
asl-rescue # Rescue binary
init-asl-host.sh # Init script to bootstrap datasets & services
helper-mount.sh # Optional helper scripts
/etc/
asl-auth-host/
config.yaml # Host config (domains, policies, SOPS paths)
policy.hash # Optional policy hash for offline validation
/var/lib/asl/ # ASL storage root
common/ # Courtesy/common domain data
blocks/ # Encrypted blocks or artifacts
index/ # Store index for common domain
snapshots/ # Snapshots for deterministic reconstruction
logs/ # Append-only log
personal/ # Personal domain data
blocks/ # Encrypted personal blocks
index/
snapshots/
logs/
pools/ # Placeholder directories for ZFS datasets if used
/var/lib/asl/certs/ # Certificates and DAM bundles
root-offline/ # Offline root certs
domain-authority/ # Signed DAM bundles
sops/ # Optional SOPS bundles
/var/log/ # Host logs
asl-auth-host.log
```
---
### Notes
1. **ISO Root (`/iso_root`)**
* Populated via debootstrap in Debian container. Overlay merges your binaries and directory structure.
2. **Binaries (`/bin`)**
* Place `asl-auth-host` and `asl-rescue` here.
* Init scripts can handle mounting ZFS datasets or preparing `/var/lib/asl` before starting the store.
3. **Host Configuration (`/etc/asl-auth-host`)**
* `config.yaml` contains domain IDs, policies, and SOPS bundle paths.
* `policy.hash` allows offline verification of policies before admission.
4. **ASL Storage (`/var/lib/asl`)**
* **Common**: Courtesy domain with pre-seeded blocks/artifacts.
* **Personal**: New private domain for rescued material.
* **Pools**: Reserved for mounting ZFS pools when booted.
5. **Certificates (`/var/lib/asl/certs`)**
* Offline roots for verifying DAM signatures.
* Domain authority DAM bundles received via SOPS.
6. **Logging (`/var/log`)**
* Minimal logs for host activity, index writes, and rescue operations.
---
### Optional: Overlay Sub-structure for Development
```
/overlay/
bin/
asl-auth-host
asl-rescue
init-asl-host.sh
etc/
asl-auth-host/config.yaml
asl-auth-host/policy.hash
var/
lib/
asl/
common/
personal/
pools/
certs/
log/
```
*This overlay merges into `/iso_root` during ISO build.*
---
This layout **supports bootstrapping a personal domain from scratch**, seeding the courtesy/common domain, and later integrating offline DAM bundles. It also keeps your binaries and helper scripts isolated in `/bin` and `/etc` configs clean.
---
I can also **draft an example `config.yaml` for the host** showing:
* Domain IDs
* Courtesy lease definitions
* Default SOPS bundle paths
* Snapshot/retention policies
…so your host is ready to pick up a new domain or rescued data.
Do you want me to draft that next?

291
ops/legacy/ASL-AUTH-HOST v0-1 - Threat Model.md
View file

@ -1,291 +0,0 @@
Absolutely. Below is a **formal threat model write-up** for the system as it now stands. This is **not theoretical**; it is written to match your exact design choices, maturity level, and operational reality.
I’ll keep it structured, explicit, and grounded.
---
# ASL-AUTH-HOST v0.1 — Threat Model
## 1. Scope and Assumptions
### 1.1 In Scope
This threat model covers:
* **Offline ASL-AUTH-HOST**
* USB-mediated intake and output
* PEL execution
* Receipt (PER) generation and signing
* Domain admission and rescue bootstrap
* Published artifact creation
### 1.2 Explicit Assumptions
1. **Physical access = ultimate trust boundary**
* The attacker may have physical access to USB media.
* The attacker may *not* have unsupervised access to the auth host hardware.
2. **Auth host is air-gapped**
* No network interfaces.
* No radios.
* No background services.
3. **Offline root keys are uncompromised**
* Root compromise is **out of scope** (catastrophic).
4. **Operator is present**
* Console interaction is intentional and visible.
---
## 2. Assets to Protect
| Asset | Description |
| ------------------------- | ------------------------------ |
| Root authority keys | Domain trust anchors |
| Domain signing keys | Used to mint DAMs and receipts |
| Execution receipts (PERs) | Portable truth of execution |
| Published artifacts | Immutable outputs |
| Domain identity | Correct domain binding |
| Policy hash | Guarantees semantic compliance |
---
## 3. Adversary Model
### 3.1 Adversary Capabilities
The attacker may:
* Supply malicious USB content
* Replay old requests
* Attempt malformed PEL programs
* Attempt filesystem abuse via USB
* Attempt to confuse domain identity
* Attempt to exfiltrate private artifacts
The attacker **cannot**:
* Inject network traffic
* Modify host binaries (unless physical compromise)
* Access signing keys without operator approval
---
## 4. Trust Boundaries
```
[ USB ] ────(read-only)────> [ AUTH HOST ]
|
| (PEL execution)
v
[ ASL Store ]
|
└──> (write-only) → [ USB RESPONSE ]
```
**Critical principle**:
> Data flows in one direction per phase, never bidirectional.
---
## 5. Threat Analysis (STRIDE-like)
### 5.1 Spoofing
**Threat:**
Fake domain requests or forged admission.
**Mitigations:**
* Manifest + signature verification
* Policy hash enforcement
* Offline root verification
* Domain IDs generated and signed by authority
---
### 5.2 Tampering
**Threat:**
USB content modified to alter inputs or outputs.
**Mitigations:**
* Intake is read-only
* Hashes over all inputs
* Response signature covers:
* Request manifest hash
* Receipt hash
* Published artifact hashes
---
### 5.3 Repudiation
**Threat:**
Requester denies what was executed.
**Mitigations:**
* Receipt includes:
* Program hash
* Input hashes
* Snapshot ID
* Receipt signed by authority
* Deterministic replay possible
---
### 5.4 Information Disclosure
**Threat:**
Private data leaks from auth host.
**Mitigations:**
* No shell access to arbitrary tools
* No network
* Explicit publish rules
* Unpublished artifacts never leave host
* Encrypted blocks allowed in public domains
---
### 5.5 Denial of Service
**Threat:**
USB floods, huge inputs, malformed PEL.
**Mitigations:**
* Operator-mediated execution
* Explicit size limits in manifest
* Deterministic PEL subset
* No automatic execution
---
### 5.6 Elevation of Privilege
**Threat:**
PEL program escapes sandbox or invokes host capabilities.
**Mitigations:**
* PEL is declarative
* No exec, no syscalls, no I/O primitives
* Host enforces operator whitelist of ops
* Canonical PEL interpreter only
---
## 6. Specific High-Risk Scenarios
### 6.1 Malicious USB with filesystem exploits
**Mitigation:**
* Mount read-only
* No traversal outside `/REQUEST`
* No symlink following
* No execution from USB
---
### 6.2 Replay of old admission request
**Mitigation:**
* `request_id` uniqueness
* Receipt records snapshot
* Authority tracks processed request IDs
---
### 6.3 Confused domain attack
**Threat:**
Attacker attempts to get artifacts bound to wrong domain.
**Mitigation:**
* Domain ID assigned by authority
* Domain binding part of receipt hash
* No requester-supplied domain ID is trusted
---
### 6.4 Side-channel via timing or output size
**Mitigation:**
* Coarse-grained execution
* Deterministic output
* Optional output padding
(Residual risk acknowledged but acceptable.)
---
## 7. What This Model Explicitly Does *Not* Protect Against
| Out of Scope | Reason |
| --------------------------- | -------------- |
| Physical compromise of host | Catastrophic |
| Malicious operator | Social problem |
| Root key exfiltration | Ends trust |
| Covert EM attacks | Beyond scope |
---
## 8. Security Posture Summary
**Strengths:**
* Minimal attack surface
* Explicit authority boundaries
* Deterministic execution
* Portable, signed truth (PER)
* No ambient trust
**Residual risks:**
* Physical compromise
* Operator error
* Supply-chain attacks on binaries
---
## 9. Alignment With Your Design Philosophy
This system:
* Treats **authority as a press, not a server**
* Treats **data as artifacts, not files**
* Treats **execution as a receipt, not a side effect**
* Treats **trust as explicit and finite**
It is **hard to misuse**, **easy to audit**, and **honest about its limits**.
---
## 10. Recommended Next Documents (in order)
1. **PEL canonical encoding spec**
2. **Receipt canonicalization & hash rules**
3. **DAM final schema**
4. **Operator checklist (human protocol)**
5. **Minimal reference implementation**
If you want, next I can write the **operator checklist**, which is often the missing piece that keeps systems like this safe in practice.
Just say the word.

182
ops/legacy/ASL-AUTH-HOST v0.1 — Authority Node Profile.md
View file

@ -1,182 +0,0 @@
Here’s a first draft for **ASL-AUTH-HOST v0.1** — the profile for an authority node that is structurally similar to a SystemRescue node but configured for offline, auditable domain authority operations.
---
# ASL-AUTH-HOST v0.1 — Authority Node Profile
## 1. Purpose
Defines the **host-level profile** for a Domain Authority Node (DAN) in the ASL ecosystem.
This profile ensures that the authority node:
* Operates **offline**
* Maintains an **internal ASL-HOST store**
* Produces **deterministic artifacts and receipts**
* Supports **domain admission and certificate management**
* Can bootstrap **new personal or group domains**
---
## 2. Core Principles
1. **All authority state is an artifact**: keys, DAM, policies, and environment claims are recorded in ASL.
2. **Offline-first**: no network dependency for core operations.
3. **Deterministic snapshots**: every operation is captured in a snapshot.
4. **Receipt-oriented**: outputs are PER artifacts ready for federation or personal import.
5. **Minimal trusted code**: authority functionality is limited to signing, sealing, and packaging artifacts.
---
## 3. Required Components
### 3.1 ASL-HOST Store
```
/asl-host/
/domains/
/<domain-id>/
/store/ # block store
/log/ # append-only log
/snapshots/ # snapshot markers
/certs/ # locally stored authority certificates
/policies/ # policy artifacts
/dam/ # Domain Admission Manifests
```
* Supports block and index operations according to ASL-STORE semantics.
* No external federation by default.
---
### 3.2 Authority Keys
* Root keypair generated locally per domain.
* Stored as:
* Public key artifact
* Private key artifact (encrypted on local storage)
* Optionally rotated with deterministic PEL DAGs.
---
### 3.3 Offline Environment Claim
* Records:
* Image hash
* Boot-time environment
* Installed tool versions
* Snapshot of ASL-HOST store
* Stored as **environment claim artifact**.
---
### 3.4 Domain Admission Manifest (DAM)
* Stored as an artifact.
* Includes:
* Domain ID
* Root key fingerprint
* Policy hash
* Optional courtesy lease references
* Signed with authority node’s root key.
---
### 3.5 PEL Programs
* Minimal offline PEL DAGs for:
* Signing DAMs
* Generating PER receipts
* Packaging SOPS bundles
* Executed **deterministically** from snapshots.
---
## 4. Operation Modes
| Mode | Description |
| --------------- | ------------------------------------------------------------------------------------ |
| **Genesis** | Create first domain for personal use; generate DAM, root keys, and policy artifacts. |
| **Rescue** | Accept input artifacts (old data, files, or device images) and produce PER receipts. |
| **Admission** | Sign DAMs and package SOPS bundles for new nodes entering the ecosystem. |
| **Maintenance** | Rotate keys, refresh policies, seal snapshots, audit artifacts. |
---
## 5. Snapshot and Logging
* Every operation produces:
* New blocks for artifacts
* Append-only log entries
* Snapshot marker capturing CURRENT state
* Snapshots are **immutable** and form the basis for deterministic PER generation.
---
## 6. Authority-Only Constraints
* No network communication.
* No automatic federation.
* All outputs are artifacts for later import or distribution.
* Garbage collection is disabled; nothing may be deleted from genesis snapshot onward.
---
## 7. Security Considerations
* Root private keys **must** remain offline.
* Environment claim artifacts allow **proof of image integrity** and operational reproducibility.
* Courtesy leases (optional) allow temporary storage for new personal domains under common domain supervision.
---
## 8. Output Artifacts
| Artifact Type | Description |
| -------------------------- | ---------------------------------------------------------------- |
| Root key artifact | Public/private keypair for domain signing. |
| DAM artifact | Domain Admission Manifest, signed. |
| Policy artifact | Hash of accepted policies and operational contracts. |
| Environment claim artifact | Immutable claim of offline environment state. |
| PER artifact | Receipt confirming DAM or policy execution. |
| SOPS bundle | Encrypted and portable bundle for admission or personal archive. |
---
## 9. Bootstrapping Flow
1. Boot ASL-AUTH-HOST image offline.
2. Initialize local ASL-HOST store.
3. Generate root keypair artifact.
4. Create DAM artifact, sign with root key.
5. Produce environment claim artifact.
6. Seal snapshot (`genesis snapshot`).
7. Generate PER receipts for DAM and environment.
8. Optionally export SOPS bundle for new nodes or personal import.
---
## 10. Relationship to SystemRescue Node
* Uses same OS image base.
* ASL-HOST store layout is identical.
* Only differs in:
* Authority keys presence
* Offline-only policy
* Deterministic signing and SOPS bundle generation
---
This draft defines the **authority node as a first-class ASL-HOST**, offline, deterministic, and auditable, ready to issue DAMs, PERs, and SOPS bundles for new personal domains or rescue operations.
---
If you want, I can **draft the exact on-disk block layout for ASL-AUTH-HOST**, showing directories, artifact blocks, log files, snapshots, DAMs, and policy files, similar to a precise filesystem blueprint for bootstrapping. This would make it fully tangible for your SystemRescue image.
Do you want me to do that next?

172
ops/legacy/ASL-HOST v0-1.md
View file

@ -1,172 +0,0 @@
Here’s a clean **v0.1 draft for ASL-HOST**, scoped to what we discussed — minimal, environment-focused, without touching semantics or storage encoding. This is the runtime/host interface layer that bridges ASL-STORE(-INDEX) to a real system.
---
# ASL-HOST v0.1 – Host/Runtime Interface for ASL Stores
## 1. Purpose
**ASL-HOST** specifies the **runtime contract** between an ASL store and the host environment.
It defines **what the host must provide** for an ASL store to operate correctly, without imposing:
* Storage semantics
* Encoding
* Policy
* Security beyond minimal integrity guarantees
It supports **POSIX filesystems, ZFS, object stores**, or other backing layers.
---
## 2. Core Concepts
| Concept | Definition |
| ----------------- | ------------------------------------------------------------------------- |
| **StoreHandle** | Opaque reference to a host-provided store instance |
| **StoreLocation** | Host-defined location where a store exists (path, URI, mount point, etc.) |
| **AppendUnit** | Minimum atomic write unit for the append-only log |
| **SnapshotID** | Opaque identifier of a host-provided snapshot |
| **HostClock** | Monotonic counter or timestamp source |
| **HostIdentity** | Unique machine or user identity for signing or domain minting |
---
## 3. Store Instantiation
### 3.1 Store Creation
* `CreateStore(location: StoreLocation) → StoreHandle`
* Must guarantee crash-consistent initialization.
* Location may be:
* POSIX path
* ZFS dataset
* Object store bucket
* StoreHandle is **opaque**, only valid while the store exists on host.
### 3.2 Store Open
* `OpenStore(location: StoreLocation) → StoreHandle`
* Host must provide durable, consistent view.
* Opening an existing store must not corrupt previous data.
### 3.3 Store Close
* `CloseStore(store: StoreHandle)`
* Ensures all writes are persisted to durable media.
* Optional: triggers host-specific flush or checkpoint.
---
## 4. Atomic Append / Log Operations
* Host must provide **atomic append** semantics.
* Minimum guarantees:
* Sequential ordering (logseq monotonicity)
* Crash consistency (partial writes are not visible)
* AppendUnit:
* Defined by host; could be page-size or object-size
* ASL-STORE must tolerate host’s granularity
---
## 5. Snapshot Management
* Optional but recommended.
* Host provides:
* `CreateSnapshot(store: StoreHandle) → SnapshotID`
* `MountSnapshot(store: StoreHandle, id: SnapshotID) → StoreHandle`
* Guarantees:
* Snapshot captures a consistent view of sealed blocks
* Mounting snapshot produces read-only store handle
* Host may use:
* ZFS snapshot
* POSIX filesystem copy-on-write overlay
* Object store versioning
---
## 6. Durability & Crash Semantics
* Host must ensure:
* Writes are durable after append or flush
* Crash recovery restores store to last durable state
* Open, unsealed blocks may be lost without breaking invariants
* StoreHandle and append-only log are **atomic units** visible to ASL-STORE
---
## 7. Minimal Identity & Logging
* Host must provide:
* `HostClock()` → monotonic timestamp / counter
* `HostIdentity()` → machine or user ID for signing / domain minting
* Optional log for debugging or auditing
---
## 8. Error Semantics
* Operations may return:
* `STORE_OK`
* `STORE_EXISTS`
* `STORE_NOT_FOUND`
* `STORE_IO_ERROR`
* `STORE_CONCURRENT_MODIFICATION`
* ASL-STORE must handle errors deterministically
---
## 9. Security Considerations
* ASL-HOST does **not enforce cryptography**.
* Host may provide optional:
* Encryption at rest
* Access control
* Secure snapshot mechanisms
* Certificates and trust are handled in **ASL-AUTH**, separate layer
---
## 10. Example Implementations
| Backend | How ASL-HOST maps |
| ---------------- | ---------------------------------------------------------------------------------- |
| POSIX filesystem | StoreLocation = path; append = write+fsync; snapshot = overlayfs copy |
| ZFS dataset | StoreLocation = dataset; append = zfs sync; snapshot = zfs snapshot |
| Object store | StoreLocation = bucket/namespace; append = object PUT; snapshot = versioned bucket |
---
## 11. Versioning
* Spec version: **0.1**
* Backward incompatible changes must bump major version.
* Minimal compliance: implement store creation/open/close and append guarantees.
---
## 12. Summary
**ASL-HOST v0.1**:
* Defines **runtime contract** between ASL store and host
* Provides **store handles, atomic append, snapshots, identity**
* Layered cleanly above ASL-STORE(-INDEX), below system or OS
* Keeps **semantics, encoding, and trust separate**
---
If you like, I can **draft ASL-AUTH v0.1** next, and then show how **SystemRescue could instantiate ASL-HOST with POSIX/ZFS to seed a personal domain**. That would give a complete view for your rescue scenario.
Do you want me to do that next?

317
ops/legacy/ASL-HOST v0-2.md
View file

@ -1,317 +0,0 @@
Good — this is the right integration point.
What follows is a **clean, minimal integration of DAP + DAM + Courtesy Leases into ASL-HOST**, without leaking authority into ASL-CORE or policy into ASL-STORE.
Think of **ASL-HOST as the membrane** where *authority, storage, and execution meet but do not mix*.
---
# ASL-HOST v0.1 (Integrated with Admission & Authority)
---
## 1. Purpose of ASL-HOST
**ASL-HOST defines the responsibilities of a node that hosts ASL domains.**
It is responsible for:
* Domain lifecycle
* Admission and recognition
* Block and log materialization
* Snapshot discipline
* Resource enforcement
* Separation of authority from storage semantics
It explicitly does **not** define:
* Artifact encoding (ASL-CORE)
* Index layout (ENC-ASL-STORE)
* PER or TGK semantics (PEL / TGK layers)
* Cryptographic algorithms (delegated to ASL-AUTH)
---
## 2. ASL-HOST Position in the Stack
```
+-------------------------+
| ASL-AUTH | ← identity, keys, policy
+-------------------------+
| ASL-HOST | ← THIS SPEC
+-------------------------+
| ASL-STORE / INDEX | ← blocks, logs, snapshots
+-------------------------+
| ASL-CORE / PEL / TGK | ← semantics & execution
+-------------------------+
| Filesystem / ZFS / POSIX|
+-------------------------+
```
ASL-HOST is where **domains become real**.
---
## 3. Domain Lifecycle in ASL-HOST
### 3.1 Domain States
```text
UNRECOGNIZED
ADMITTED (COURTESY)
ADMITTED (FULL)
SUSPENDED
REVOKED
```
ASL-HOST tracks domain state explicitly.
---
### 3.2 Domain Creation (Local)
A domain MAY be created locally without admission:
```text
asl-host domain create
```
This creates:
* DomainID
* Empty storage namespace
* Empty log
* No external recognition
This domain is **self-contained only**.
---
## 4. Domain Admission Integration (DAP)
### 4.1 Admission Request Handling
ASL-HOST MUST provide:
```c
AdmissionResult asl_host_admit(DAM, signature, request);
```
Responsibilities:
* Validate DAM schema
* Verify signature
* Check policy compatibility
* Decide admission outcome
ASL-HOST does **not** inspect artifacts.
---
### 4.2 Admission Outcome Effects
| Outcome | ASL-HOST Behavior |
| ---------------- | --------------------------------------- |
| ACCEPTED | Enable publishing, indexing, federation |
| ACCEPTED_LIMITED | Enable courtesy-only storage |
| DEFERRED | Domain exists but blocked |
| REJECTED | Domain remains isolated |
---
## 5. Courtesy Leases in ASL-HOST
### 5.1 Courtesy Lease Attachment
A courtesy lease is **attached to a domain in ASL-HOST**, not to ASL-STORE.
```text
Domain {
domain_id
admission_state
courtesy_lease?
}
```
---
### 5.2 Enforcement Responsibilities
ASL-HOST MUST enforce:
* Storage limits
* Snapshot count
* Lease expiry
* Encryption-only constraint (if specified)
ASL-STORE must **not** be aware of courtesy semantics.
---
### 5.3 Courtesy Lease Expiry
On expiry, ASL-HOST MAY:
* unpin snapshots
* block new writes
* mark domain as SUSPENDED
ASL-STORE is not required to preserve data.
---
## 6. StoreHandle Integration
### 6.1 StoreHandle Is Scoped to a Domain
ASL-HOST provides:
```c
StoreHandle *asl_host_open_domain(domain_id);
```
The StoreHandle is:
* domain-scoped
* snapshot-aware
* admission-aware
---
### 6.2 Admission-Gated Capabilities
Capabilities exposed via StoreHandle depend on admission state:
| Capability | Courtesy | Full |
| ---------------- | -------- | ---- |
| allocate_block | yes | yes |
| seal_block | yes | yes |
| append_log | yes | yes |
| publish_snapshot | no | yes |
| federate_log | no | yes |
ASL-CORE and PEL never see this distinction.
---
## 7. Snapshots and CURRENT (ASL-HOST Role)
ASL-HOST defines:
* Snapshot creation
* Snapshot pinning
* Snapshot association with log position
ASL-HOST guarantees:
```text
CURRENT = snapshot + replay(log)
```
This is **host-level truth**, not an ASL-CORE concern.
---
## 8. Block Ownership and Movement
### 8.1 Block Ownership
Every block belongs to exactly one domain.
Block ownership is enforced by:
* filesystem layout
* StoreHandle scoping
* ASL-HOST policy
---
### 8.2 Block Migration Between Domains
Block migration is an **ASL-HOST operation**:
```text
asl-host migrate-block --from A --to B
```
Rules:
* Source block must be sealed
* Destination domain must accept the block
* Policy compatibility enforced
* Provenance preserved
---
## 9. Federation Boundary
ASL-HOST is the **only layer allowed to federate**.
It decides:
* which logs may be exported
* which snapshots may be published
* which foreign roots are trusted
ASL-STORE and ASL-CORE remain oblivious.
---
## 10. Revocation and Suspension
ASL-HOST MAY:
* suspend a domain (stop new writes)
* revoke federation
* invalidate admission
Already-sealed artifacts remain immutable.
---
## 11. SystemRescue Mapping (Concrete)
Your patched SystemRescue image now hosts:
* ASL-HOST runtime
* Local domains (personal, courtesy, common)
* Admission client
* Offline authority material
On boot, SystemRescue may:
1. Create a local domain
2. Load DAM + keys
3. Submit admission request
4. Receive courtesy lease
5. Begin sealed ingestion
6. Snapshot and wait
You are *literally standing ready*.
---
## 12. Why This Integration Is Clean
✔ ASL-CORE untouched
✔ ASL-STORE unaware of authority
✔ Authority never touches block bytes
✔ Admission precedes trust
✔ Rescue and sovereign modes unified
---
## 13. Mental Model (One Sentence)
> **ASL-HOST is the constitutional layer that turns storage into a domain, and a domain into a participant.**
---
If you want next, we can:
* define **ASL-HOST on-disk layout**
* specify **revocation propagation**
* map **PEL execution to admission state**
* or walk a **full rescue → admission → federation scenario end-to-end**
Just point the direction.

90
ops/legacy/Bootable ASL-AUTH-HOST.md
View file

@ -1,90 +0,0 @@
Ah, yes — you’re right! The previous summary focused on ASL, PEL, domains, and blocks, but we also discussed **building an ASL-AUTH-HOST ISO and bootable USB workflow**. Here’s a compact recap integrated with your overall architecture:
---
# Bootable ASL-AUTH-HOST / USB Summary
## 1. Environment
* Start from a **minimal Debian root** (via `debootstrap`) inside a container.
* Set up:
* `$WORKDIR/iso_root` → ISO root filesystem
* `$WORKDIR/overlay` → ASL binaries, scripts, and configuration
## 2. Overlay contents
* `bin/` → `asl-auth-host`, `asl-rescue`, helper scripts
* `usr/local/bin/` → optional local tools
* `var/lib/asl/` → datasets, pools, personal/common directories
* `var/log/` → logs
* Bootloader configs (`isolinux/`)
---
## 3. Bootable ISO creation
* Copy overlay into `$ISO_ROOT`
* Create ZFS-like dataset directories:
```
var/lib/asl/{common,personal,pools}
```
* Generate ISO via `xorriso` (or `mkisofs`) with minimal bootloader
---
## 4. ASL Capture Integration
* **`asl-capture`** can wrap shell or program execution
* Capture occurs **during image creation**:
* Can log everything in the host root during debootstrap + `apt-get install`
* Produces artifacts (executed commands, receipts)
* Early capture allows **provenance from the very birth of the image**
---
## 5. USB boot workflow
1. Build ISO (`build_asl_auth_host_iso.sh`)
2. Write ISO to USB (`dd` or `rufus`/`balenaEtcher`)
3. Boot machine → `init-asl-host.sh` (custom init script)
* Mount ZFS or overlay store
* Initialize domains (Common, personal, rescue)
* Enforce witness authority / DAM at boot
* Run ASL capture to log host state
---
## 6. Storage & persistence on USB
* Personal domain: local USB store
* Root.alice or Common: mounted network or local store
* Snapshot management ensures deterministic state
* Blocks and artifacts are packed according to store policy
* Index/log replay reconstructs current state at boot
---
## 7. Key insights from discussion
* You **can capture the host from first boot** to have full provenance.
* Witness authority (DAM) is enforced **before userspace programs run**, even for Common.
* Blocks remain storage-level; artifacts remain semantic and authoritative.
* Publishing to Common happens **via root.alice**; private artifacts remain in `alice` domain.
* Bootable USB + ASL capture = deterministic, auditable host for rescue and auth purposes.
---
If you want, I can **draw a full flow diagram** that shows:
```
debootstrap → overlay → ISO → USB → boot → init-asl-host → domains → ASL capture → artifacts/logs
```
…including where **root.alice, Common, and personal domains** live, and how **blocks, artifacts, and logs** interact during boot.
Do you want me to do that diagram next?

225
ops/legacy/ENC-ASL-AUTH-HOST.md
View file

@ -1,225 +0,0 @@
Perfect! Here’s a draft specification for **ENC-ASL-AUTH-HOST v0.1**, the **on-disk layout and encoding** for the authority host. This complements ASL-AUTH-HOST by formalizing **how artifacts, blocks, logs, snapshots, and certificates are stored**.
---
# ENC-ASL-AUTH-HOST v0.1 — On-Disk Layout
## 1. Purpose
Defines the **physical and logical layout** of an ASL authority host’s storage.
Ensures:
* Deterministic artifact placement
* Snapshot-aware storage
* Offline-first operation
* Compatibility with ASL-HOST, PERs, and SOPS bundles
---
## 2. Root Layout
```
/asl-auth-host/
├─ /domains/
│ ├─ <domain-id>/
│ │ ├─ /store/
│ │ ├─ /log/
│ │ ├─ /snapshots/
│ │ ├─ /certs/
│ │ ├─ /policies/
│ │ └─ /dam/
├─ /tools/
│ └─ <binary-tools> # deterministic, versioned rescue/auth tools
├─ /env-claims/
│ └─ <snapshot-hash>.claim
└─ /sops-bundles/
└─ <bundle-id>.sops
```
---
## 3. Domains Directory
**`/domains/<domain-id>/`** contains all **domain-specific storage and authority artifacts**.
### 3.1 Store
```
/domains/<domain-id>/store/
├─ blocks/
│ ├─ <block-id>.bin # raw artifact bytes
│ └─ <block-id>.meta # metadata: size, type_tag, sealed_flag
├─ indices/
│ ├─ segment-<n>.idx # ASL-STORE index segments
│ └─ bloom-<n>.bf # optional bloom filters
```
* Each block is **immutable once sealed**
* Segment indices point to block IDs and offsets
* Encoding follows **ASL-STORE-INDEX + ENC-ASL-STORE(-INDEX)** rules
---
### 3.2 Log
```
/domains/<domain-id>/log/
├─ log-<seq>.aol # append-only log files
```
* Each log record contains:
* Artifact additions
* DAM signatures
* Snapshot seals
* Tombstone records
* Deterministic replay reconstructs **CURRENT** state
---
### 3.3 Snapshots
```
/domains/<domain-id>/snapshots/
├─ snapshot-<id>.meta
├─ snapshot-<id>.blocks # optional reference map
```
* Snapshot metadata includes:
* Logseq boundary
* Sealed segments
* Block references
* Environment claim artifact reference
* Snapshots are **immutable**
---
### 3.4 Certificates
```
/domains/<domain-id>/certs/
├─ root.pub # root public key
├─ root.priv.enc # encrypted private key
├─ dam-signer.pub # optional signing key for DAMs
├─ dam-signer.priv.enc
```
* All private keys are encrypted and **never leave offline host**
* Public keys are referenced in DAM artifacts
---
### 3.5 Policies
```
/domains/<domain-id>/policies/
├─ policy-<hash>.json
```
* Policy hash stored as artifact
* Policies include:
* Domain admission rules
* Courtesy leases
* GC / retention rules
---
### 3.6 Domain Admission Manifests (DAM)
```
/domains/<domain-id>/dam/
├─ dam-<seq>.json.sig # signed DAM artifact
```
* Each DAM artifact contains:
* Domain ID
* Root key fingerprint
* Policy hash
* Courtesy lease info (optional)
* Signed by root key
---
## 4. Tools
```
/tools/
├─ asl-auth-host # main authority binary
├─ asl-rescue # SystemRescue patched tools
└─ sops # for offline bundle creation
```
* Versioned, deterministic, immutable binaries
* Executables stored as ASL artifacts if desired
---
## 5. Environment Claims
```
/env-claims/
├─ <snapshot-id>.claim
```
* Contains:
* OS image hash
* Boot environment info
* Installed tool hashes
* ASL-HOST store checksum at snapshot
* Stored as artifact and optionally signed by root key
---
## 6. SOPS Bundles
```
/sops-bundles/
├─ <bundle-id>.sops
```
* Encrypted container for DAMs, PER receipts, and optionally policies
* Can be delivered to new nodes for **admission or rescue**
* Includes checksums for integrity
---
## 7. Encoding Conventions
1. **Blocks**: `<block-id>.bin` (raw bytes), accompanied by `<block-id>.meta`
2. **Indices**: segment-based index; segment files immutable after seal
3. **Log**: append-only, each entry:
* `logseq | artifact_key | block_ref | type_tag | operation | signature`
4. **Snapshots**: snapshot ID derived from hash of CURRENT log + block refs
5. **Certificates**: PEM or ASL-artifact wrapped keys
6. **SOPS Bundles**: standard encrypted JSON/YAML with embedded checksums
---
## 8. Security Notes
* Private keys must **never be exposed** or included in SOPS bundles unencrypted
* Blocks in store may be encrypted with **per-domain keys**
* Environment claims ensure **proof of offline execution**
* DAMs must be signed to be trusted
---
This layout allows the **authority host** to:
* Bootstrap personal or group domains
* Accept rescued artifacts
* Produce deterministic PERs and snapshots
* Create SOPS bundles for new nodes
* Operate fully offline
---
If you want, I can **draw a full diagram showing the ENC-ASL-AUTH-HOST tree, block-flow, snapshot integration, and PER generation**, so it’s easier to visualize the data flow during rescue or admission.
Do you want me to make that diagram next?

370
ops/legacy/ENC-ASL-HOST.md
View file

@ -1,370 +0,0 @@
Good — this is the right thing to pin down next.
Below is a **precise, minimal, authority-aware but storage-agnostic ASL-HOST on-disk layout**, designed to work on **ZFS, btrfs, or plain POSIX**, and to survive before ASL-STORE / ASL-CORE are fully implemented.
This layout defines **where things live**, not **how bytes are encoded**.
---
# ASL-HOST On-Disk Layout — v0.1
---
## 1. Design Goals (Normative)
The on-disk layout MUST:
1. Enforce **domain isolation**
2. Separate **authority, storage, and execution**
3. Support **append-only logs**
4. Support **snapshots as first-class**
5. Allow **courtesy leases and revocation**
6. Remain **forward-compatible** with ASL-STORE and ENC specs
The layout MUST NOT:
* Encode artifact semantics
* Encode index formats
* Encode cryptographic algorithms
---
## 2. Root Layout
```text
/asl-host/
├── host/
│ ├── host-id
│ ├── host-policy
│ └── trusted-roots/
│
├── domains/
│ ├── <domain-id>/
│ │ ├── domain.json
│ │ ├── admission/
│ │ ├── auth/
│ │ ├── store/
│ │ ├── index/
│ │ ├── log/
│ │ ├── snapshots/
│ │ ├── leases/
│ │ └── tmp/
│
├── federation/
│ ├── peers/
│ ├── exports/
│ └── imports/
│
└── quarantine/
```
Everything below this root is owned by ASL-HOST.
---
## 3. Host-Level Metadata
### `/asl-host/host/`
```text
host/
├── host-id # stable ID for this machine
├── host-policy # local admission & resource policy
└── trusted-roots/
├── root-A.pub
├── root-B.pub
└── ...
```
**Notes:**
* Trusted roots are **offline-established**
* Used for **admission verification**
* Not domain-specific
---
## 4. Domain Directory (Authoritative Boundary)
Each domain has **one directory**, nothing crosses this boundary implicitly.
```text
/domains/<domain-id>/
```
This directory MUST be the **sole owner** of:
* blocks
* logs
* snapshots
* indexes
* domain-local authority state
---
## 5. Domain Descriptor
### `/domains/<domain-id>/domain.json`
This is **host-owned metadata**, not part of ASL-CORE.
```json
{
"domain_id": "...",
"state": "COURTESY | FULL | SUSPENDED | REVOKED",
"created_at": "...",
"admitted_at": "...",
"root_key_fingerprint": "...",
"policy_hash": "...",
"current_snapshot": "...",
"current_logseq": 12345
}
```
This file is **not signed** — it is derived state.
---
## 6. Admission Records
### `/domains/<domain-id>/admission/`
```text
admission/
├── dam.cbor
├── dam.sig
├── admission-request.cbor
├── admission-decision.cbor
└── admission-decision.sig
```
This directory contains **immutable records** of how the domain was admitted.
---
## 7. Authority Material (Domain-Local)
### `/domains/<domain-id>/auth/`
```text
auth/
├── root.pub
├── operators/
│ ├── op1.pub
│ └── ...
├── device.pub
└── revocations/
```
**Rules:**
* Private keys MAY exist only temporarily (e.g. SystemRescue)
* ASL-HOST MUST NOT rely on private keys being present
---
## 8. Store Root (Blocks)
### `/domains/<domain-id>/store/`
```text
store/
├── blocks/
│ ├── open/
│ ├── sealed/
│ └── gc/
├── objects/ # optional future packing
└── encryption/
```
**Notes:**
* `open/` blocks may be lost
* `sealed/` blocks are immutable
* `gc/` is host-managed
* Encryption metadata is **opaque to ASL-STORE**
---
## 9. Index Area (Semantic-Free)
### `/domains/<domain-id>/index/`
```text
index/
├── segments/
│ ├── seg-000001/
│ └── ...
├── bloom/ # optional
└── tmp/
```
ASL-HOST only guarantees:
* sealed segments are immutable
* segments become visible only after seal record
---
## 10. Append-Only Log
### `/domains/<domain-id>/log/`
```text
log/
├── append.log
├── checkpoints/
│ ├── chk-000001/
│ └── ...
└── seal.log
```
**Rules:**
* append-only
* monotonic
* replayable
* seal.log records segment seals
---
## 11. Snapshots
### `/domains/<domain-id>/snapshots/`
```text
snapshots/
├── snap-000001/
├── snap-000002/
└── pinned/
├── snap-000001
```
**Host responsibility:**
* mapping snapshots to log positions
* enforcing pinning
* enforcing courtesy limits
---
## 12. Courtesy Leases
### `/domains/<domain-id>/leases/`
```text
leases/
├── lease-001.json
├── lease-002.json
└── active
```
Each lease file:
```json
{
"lease_id": "...",
"granted_by": "...",
"storage_bytes": 1073741824,
"expires_at": "..."
}
```
ASL-HOST enforces these.
---
## 13. Temporary / Execution Space
### `/domains/<domain-id>/tmp/`
Used for:
* Sedelpress staging
* PEL execution scratch
* unsealed buffers
**Never snapshot-pinned.**
---
## 14. Federation Area
### `/asl-host/federation/`
```text
federation/
├── peers/
│ ├── <peer-domain-id>/
│ │ ├── pinned-roots/
│ │ ├── imported-snapshots/
│ │ └── replay-state.json
├── exports/
└── imports/
```
Federation is **explicit and opt-in**.
---
## 15. Quarantine
### `/asl-host/quarantine/`
Used for:
* rejected domains
* policy violations
* forensic inspection
No domain in quarantine may execute or publish.
---
## 16. ZFS / Snapshot Mapping (Recommended)
If using ZFS:
| Path | ZFS Dataset |
| ------------------------- | ------------------- |
| `/domains/<id>` | dataset |
| `/domains/<id>/store` | child dataset |
| `/domains/<id>/snapshots` | ZFS snapshots |
| `/domains/<id>/tmp` | no-snapshot dataset |
This gives **real snapshot semantics** aligned with ASL rules.
---
## 17. Invariants (Non-Negotiable)
1. No block crosses domain boundaries implicitly
2. No snapshot without log position
3. No sealed block mutation
4. No admission without DAM
5. No federation without ASL-HOST approval
---
## 18. Why This Works
✔ Clean separation of concerns
✔ Domain sovereignty enforced by path
✔ Admission-first architecture
✔ Rescue and sovereign flows unified
✔ ASL-STORE can drop in later
---
## 19. One-Sentence Summary
> **ASL-HOST’s on-disk layout is a constitutional map: it tells every byte who it belongs to, why it exists, and when it may be trusted.**
If you want, next we can:
* write a **reference filesystem implementation**
* simulate a **full rescue → admission → publish flow on disk**
* define **revocation propagation on disk**
* or map this directly to **ZFS commands**
Just say where to push next.

172
ops/legacy/Rescue Node ASL Deployment.md
View file

@ -1,172 +0,0 @@
Perfect. Let’s map out a **Rescue Node ASL Deployment** for your scenario, integrating **personal domain, common domain (Unity/Rakeroot), foreign-domain trust, and ASL layers**. I’ll keep it clear and structured.
---
# Rescue Node ASL Deployment – Conceptual Diagram
## 1. Overview
Goal: A rescue node (e.g., old laptop booted with SystemRescue) can:
* Read old material and register it in a **new personal domain**
* Store **resurrected artifacts** safely
* Interact with **common/shared domains** (Unity / Rakeroot)
* Respect **foreign-domain trust** (read-only imported artifacts)
* Produce **signed PERs** for auditing and traceability
---
## 2. Layered Architecture
```
┌───────────────────────────────────────────────────────────────┐
│ Rescue Node / SystemRescue Runtime │
│ (ASL-HOST) │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ Store Handles / Filesystems (POSIX/ZFS) │ │
│ │ - personal domain store │ │
│ │ - common / Unity store │ │
│ │ - optional foreign domain caches │ │
│ └───────────────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ ASL-STORE(-INDEX) │ │
│ │ - Handles blocks, snapshots, sealed segments │ │
│ │ - CURRRENT reconstruction, GC │ │
│ │ - Uses store handles provided by ASL-HOST │ │
│ └───────────────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ ASL-AUTH │ │
│ │ - Domain authority (personal / common / foreign) │ │
│ │ - PER signing and verification │ │
│ │ - Policy hash and offline root enforcement │ │
│ └───────────────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ PEL / TGK Execution │ │
│ │ - Generates PERs from recovered artifacts │ │
│ │ - TGK edges record provenance │ │
│ │ - Deterministic DAG execution │ │
│ └───────────────────────────────────────────────────────────┘ │
└───────────────────────────────────────────────────────────────┘
```
---
## 3. Domains
| Domain | Purpose | Storage / Backing |
| ------------------------------ | ----------------------------------------------------------- | ------------------------------------------------ |
| **Personal Domain** | Newly minted domain on rescue node; stores rescued material | ZFS dataset or POSIX store, encrypted optionally |
| **Common / Unity Domain** | Group-shared artifacts; Unity / Rakeroot | ZFS dataset shared among users, snapshot-based |
| **Foreign Domains (optional)** | Imported read-only artifacts; pinned by trust | Cache store / ASL-HOST mount |
---
## 4. Domain Initialization
1. **Personal Domain**
* Create store: `CreateStore("/mnt/rescue/personal")`
* Generate DA manifest
* Sign manifest with offline root
* Mount snapshot overlay if needed
2. **Common / Unity Domain**
* Mount read-only: `OpenStore("/mnt/common")`
* Synchronize snapshot to local host
* Pin trusted foreign domains if group members exist
3. **Foreign Domains**
* Configure trust pin: Domain ID + Policy hash
* Mount local cache for imported artifacts
* Access **read-only**, verified via ASL-AUTH
---
## 5. Storage / Filesystem Layout
```
/mnt/rescue/
personal/ <-- personal domain store (ZFS/POSIX)
blocks/
segments/
logs/
common/ <-- Unity / Rakeroot (shared read-only store)
blocks/
segments/
logs/
foreign/ <-- optional cache for foreign domains
domainX/
blocks/
segments/
```
* **Blocks**: immutable, sealed by ASL-STORE
* **Segments**: index entries + metadata
* **Logs**: append-only, monotonic ordering
---
## 6. Snapshot Strategy
* ZFS snapshots (or overlayfs copies) per domain
* Personal domain snapshots allow **deterministic recovery**
* Common domain snapshots define **group-visible CURRENT**
* Foreign domain snapshots pinned by trust
```
personal@rescue-snap-2025-12-28
common@unity-snap-2025-12-28
foreign-domainX@snap-2025-12-01
```
---
## 7. PER Signing & Provenance
1. PEL executes DAG over rescued artifacts
2. Generates PERs
3. ASL-AUTH signs PERs with:
* Personal domain authority key
* Policy hash embedded
4. PERs stored in **personal domain**, optionally referencing:
* Common / Unity artifacts
* Foreign pinned artifacts (read-only)
---
## 8. Optional Encryption / Public Domain Courtesy
* Blocks from personal domain can be encrypted when storing in **common domain**
* Ensures **privacy while allowing shared indexing**
* Encryption keys managed by **personal DA**
---
## 9. Trust & Governance
* Offline root(s) provide deterministic trust
* Policy hash enforces publishing and cross-domain rules
* Personal domain can safely publish selected artifacts to Unity / Rakeroot
* Foreign-domain pins enforce **read-only deterministic import**
---
## 10. Summary
* Rescue node can bootstrap **personal + common + foreign domains**
* Storage handled by ASL-HOST (POSIX/ZFS)
* Indexing, snapshots, sealing by ASL-STORE(-INDEX)
* PER signing and cross-domain trust by ASL-AUTH
* Execution provenance tracked via PEL/TGK
* Flexible architecture for **personal, group, and federated domains**
---
If you want, I can **draw a fully labeled diagram** showing **how artifacts flow from the rescued home directory into personal domain, common domain, and PER generation**, including snapshots, seals, and trust pins. This would be a visual reference for your rescue mission.
Do you want me to do that next?

163
ops/legacy/Rescue Node Blueprint v0-1.md
View file

@ -1,163 +0,0 @@
Perfect — this is exactly the “first-person, first-rescue” scenario. I’ll extend the blueprint to reflect **a freshly minted SystemRescue user entering the ecosystem** with old personal data, no prior certificates, and the intention of building both a **personal domain** and seeding the **common / Unity tree**. I’ll tie together **PER generation, ASL blocks, snapshots, and trust setup** from scratch.
---
# Rescue Node Blueprint v0.1 — Fresh Entry Scenario
```
┌───────────────────────────────┐
│ Legacy Input Material │
│ - Home directory snapshot │
│ - App config / old data │
│ - Intent / contracts │
└─────────────┬─────────────────┘
│
▼
┌───────────────────────────────┐
│ Sedelpress / PER Engine │
│ - Deterministic execution │
│ - TGK edges & provenance │
│ - Snapshot boundaries │
│ - Generates initial PER(s) │
│ - Logs intent + provenance │
└─────────────┬─────────────────┘
│ PER + TGK edges
▼
┌───────────────────────────────────────────────┐
│ Bootstrap in Common / Courtesy Space │
│ - Encrypted personal blocks │
│ - ASL-STORE(-INDEX) organizes blocks & logs │
│ - Snapshot pinned for reproducibility │
│ - Acts as temporary “personal domain seed” │
└─────────────┬─────────────────────────────────┘
│ Optional trust / policy hash
▼
┌───────────────────────────────────────────────┐
│ Personal Domain (New) │
│ - Blocks copied from courtesy space │
│ - Own index segments, snapshots │
│ - PERs validated and linked to TGK edges │
│ - Certificates minted (ASL-AUTH) │
│ - Domain Authority Manifest created │
│ - Optional publication to Common later │
└─────────────┬─────────────────────────────────┘
│ Optional publication
▼
┌───────────────────────────────────────────────┐
│ Common / Unity Domain │
│ - Shared artifacts / PERs │
│ - Read-only pinned snapshots │
│ - Courtesy recognition of new user │
│ - Aggregates multiple bootstrap submissions │
└─────────────┬─────────────────────────────────┘
│ Cross-domain trust pins
▼
┌───────────────────────────────────────────────┐
│ Foreign / Other Domains │
│ - Imported artifacts read-only │
│ - Trust via offline roots & policy hash │
│ - Deterministic snapshots reconstructed │
└───────────────────────────────────────────────┘
```
---
## Key Concepts and Steps
### 1. Legacy Material Intake
* Old personal data is treated as **raw artifact input**.
* **Sedelpress** ingests everything deterministically, creating **PER(s) for provenance**.
* Intent and contract are encoded alongside data, defining what must be certified.
### 2. PER Generation
* **First-class operation**: PERs precede storage.
* TGK edges capture lineage and relationships.
* Snapshots of input material are **recorded for deterministic reconstruction**.
### 3. Bootstrap Personal Domain via Common
* **Encrypted blocks** are stored in the Common courtesy space.
* Blocks are **sealed and indexed** (ASL-STORE / ASL-STORE-INDEX).
* Common **pins snapshots** to ensure reproducibility.
* This bootstrap **does not require prior certificates** — Common allows “newcomer courtesy.”
### 4. Personal Domain Minting
* After bootstrap, blocks are copied into the new **personal domain**.
* **Certificates (ASL-AUTH)** are minted, forming your **authority root**.
* Domain Authority Manifest (DAM) is created with:
* Your domain ID
* Seeded artifacts / PERs
* Trust anchors (offline roots)
* PERs are now linked, validated, and can be optionally published to Common.
### 5. Common / Unity Tree
* Aggregates shared PERs and artifacts from multiple users.
* Maintains **read-only pinned snapshots**.
* Facilitates **cross-user consistency and cooperation**.
* Your encrypted bootstrap blocks remain private until you choose to publish.
### 6. Cross-Domain Trust
* Optional import/export of artifacts to other domains:
* **Read-only import**: deterministic reconstruction.
* **Policy hash** ensures correctness.
* **Offline roots** verify trust for foreign domains.
---
## Suggested ASL / Filesystem Layout
| Domain / Layer | Backend / FS | Notes |
| ------------------------- | --------------------- | ----------------------------------------------------------- |
| Legacy Material Intake | POSIX / tmp overlay | Raw input snapshots |
| Sedelpress / PER Engine | Memory + temp storage | Deterministic execution; generates TGK edges |
| Bootstrap Personal Domain | ZFS / ASL-STORE | Courtesy encrypted blocks; pinned snapshot; temporary index |
| Personal Domain (New) | ZFS / ASL-STORE | Full index, sealed blocks, PERs, certificates |
| Common / Unity Domain | ZFS / ASL-STORE | Shared artifacts / PERs; read-only; pinned snapshots |
| Foreign / Other Domains | N/A / imported | Read-only; trust via offline roots & policy hash |
---
### Notes on Certificates / ASL-AUTH
* **Initial certificate minting** occurs **after bootstrap**.
* Offline root keys are generated on a **secure Debian machine** (offline).
* **Personal Domain Authority** is tied to offline roots.
* PERs in bootstrap space can later be **retrospectively certified** once personal domain is minted.
---
### Snapshot & Sealing Flow
1. **Legacy snapshot** → PER generation
2. **Seal blocks** in courtesy space
3. **Pin snapshots** in bootstrap space
4. **Copy to personal domain** → seal and index
5. **Create DAM + Certificates** → retrospective trust assignment
6. Optional publication → **Common / Unity tree**
---
This **blueprint supports:**
* Fresh user / rescue node onboarding
* Deterministic provenance from legacy material
* Personal domain creation without prior certificates
* Courtesy bootstrap in Common for temporary storage
* Safe integration with Common / Unity tree and foreign domains
* PER-first philosophy ensuring traceability and auditability
---
If you want, I can **draw a “layered architecture diagram”**, showing **Sedelpress, ASL blocks, snapshots, PERs, and the hierarchy of domains**, highlighting **bootstrap, personal, common, and foreign layers**.
It would be a **visual rescue map**, perfect for planning the initial node setup.
Do you want me to do that next?

112
ops/legacy/Rescue Operation Architecture.md
View file

@ -1,112 +0,0 @@
Perfect — that gives us a **clear mission scenario**. Let’s formalize this into a **Rescue Node + Domain Architecture**, showing the **flow from personal rescue → common courtesy space → personal domain establishment**. I’ll also tie in snapshots, sealing, and PER generation.
---
# Rescue Operation Architecture: “Personal Rescue with Common Bootstrap”
```
┌───────────────────────────────┐
│ Input Material / Intent │
│ - Home directory snapshot │
│ - Certificates │
│ - Rescue intent / contract │
└─────────────┬─────────────────┘
│
▼
┌───────────────────────────────┐
│ Sedelpress / PER Engine │
│ - Deterministic execution │
│ - TGK edges & provenance │
│ - Snapshot boundaries │
│ - Generates PER(s) │
└─────────────┬─────────────────┘
│ PER + TGK edges
▼
┌───────────────────────────────────────┐
│ Personal Bootstrap Space (Common) │
│ - Courtesy space granted by Common │
│ - Encrypted blocks / sealed segments │
│ - Indexed via ASL-STORE(-INDEX) │
│ - Temporary / bootstrapped domain │
└─────────────┬─────────────────────────┘
│ Optional trust / policy hash
▼
┌───────────────────────────────────────┐
│ Personal Domain (User-owned) │
│ - Blocks copied from bootstrap │
│ - Own index segments & snapshots │
│ - PERs stored and validated │
│ - Full authority and certificate │
└─────────────┬─────────────────────────┘
│ Publishing optional
▼
┌───────────────────────────────────────┐
│ Common / Unity Domain │
│ - Shared artifacts & PERs │
│ - Read-only access for users │
│ - Snapshot pinned / immutable │
│ - Courtesy bootstrap space recognized │
└─────────────┬─────────────────────────┘
│ Cross-domain trust pins
▼
┌───────────────────────────────────────┐
│ Foreign / External Domains │
│ - Imported artifacts (read-only) │
│ - Trust enforced by offline roots │
│ - Policy hash verification │
└───────────────────────────────────────┘
```
---
### Key Principles for Rescue + Domain Integration
1. **Bootstrap via Common**
* A person or system without a pre-existing domain can store **encrypted blocks** in the Common courtesy space.
* Common recognizes the bootstrap, enforces **policy hash**, and pins snapshots.
2. **PER Generation is Primary**
* The Sedelpress stamps **everything deterministically**: home dir, certificates, intent.
* Store artifacts are secondary; the **receipt defines authority and provenance**.
3. **Snapshots & Sealed Blocks**
* Courtesy space blocks are **encrypted and sealed** for immutability.
* Once personal domain is established, blocks can be **copied or promoted** to private space.
4. **Domain Authority**
* Personal domain is **minted post-bootstrap**, with full authority.
* Policy hash ensures cross-domain trust for publishing or importing artifacts.
5. **Cross-Domain Trust**
* Common domain pins **read-only copies** of bootstrap artifacts.
* Foreign or other users’ domains require **offline root verification** before accepting artifacts.
---
### Suggested ASL / Store Layout for Rescue Operation
| Domain | Backend / FS | Notes |
| --------------------------- | ----------------- | -------------------------------------------------------------------- |
| Personal Bootstrap (Common) | ZFS / POSIX + ASL | Courtesy space; blocks encrypted; temporary storage; snapshot pinned |
| Personal Domain | ZFS + ASL | User-owned; full index; sealed blocks; PERs validated |
| Common / Unity | ZFS + ASL | Shared artifacts; read-only; courtesy recognition |
| Foreign Domains | N/A (imported) | Read-only; trust pinned via policy hash and offline roots |
---
If you like, I can **next draft the Rescue Node overlay schema**:
* How the **personal bootstrap** interacts with Common
* How **PER ingestion and sealing** happens
* How **snapshots + ASL blocks** are laid out on ZFS or POSIX
* How the **courtesy / Unity tree** is seeded
This would be a **working blueprint for your personal rescue operations**, fully tied to the ASL + PEL ecosystem.
Do you want me to do that?

131
ops/legacy/bootable authority host image.md
View file

@ -1,131 +0,0 @@
Absolutely — let's think this through step by step. The goal is a **bootable authority host image** that’s offline, deterministic, and ready to handle domain admission, DAM signing, SOPS bundles, and PER generation. Here's a blueprint for assembling it.
---
## 1. Base OS
* Choose a **minimal Debian/Ubuntu** or SystemRescue-based environment.
* Needs basic POSIX tools, filesystem utilities, and networking disabled (offline by default).
* Install **essential tools only**:
* `bash`, `coreutils`, `tar`, `gzip`, `xz`, `find`, `sha256sum`
* `sops` binary for offline bundle handling
* `git` optional, for versioning tools inside the image
* Disable unnecessary daemons (`sshd`, `cron`) for security.
---
## 2. Filesystem Layout
Create the **ENC-ASL-AUTH-HOST** structure inside the image:
```
/asl-auth-host/
├─ /domains/ # domain stores
├─ /tools/ # binaries
├─ /env-claims/ # environment snapshot hashes
└─ /sops-bundles/ # encrypted bundles
```
* Use **read-only overlay** for system files
* Persistent storage can be mounted as `/domains` or `/store` (ZFS, ext4, or Btrfs)
* Optionally, set up **ZFS pools** for:
* `/domains/<domain-id>/store`
* `/domains/<domain-id>/snapshots`
* The image itself is **immutable** — only mounted storage is written to.
---
## 3. Tools to Include
* **asl-auth-host** binary — main authority program
* **asl-rescue** binary — optional rescue support for SystemRescue-style data intake
* **sops** — offline encryption/decryption of bundles
* Optional helper scripts:
* `make-dam.sh` — create DAM artifacts
* `sign-bundle.sh` — sign SOPS bundles
* `verify-env.sh` — calculate env-claims
---
## 4. Boot Configuration
* Boot kernel options:
* Mount persistent storage for `/domains` (ZFS, ext4, etc.)
* Mount overlay read-only system (`/tools`, `/env-claims`, `/sops-bundles`)
* Auto-start a shell or **interactive prompt** for offline operation.
* Optional: menu for:
* Create new domain
* Sign DAM / issue certificates
* Prepare SOPS bundle
* Rescue/import artifacts
---
## 5. Domain Initialization
When first booting:
1. Generate **root key pair** for the domain.
2. Optionally generate **DAM signer keys**.
3. Create the domain directory:
```
/domains/<domain-id>/
├─ store/
├─ log/
├─ snapshots/
├─ certs/
├─ policies/
└─ dam/
```
4. Initialize **empty log**, empty store, and environment claim file:
```
/env-claims/<snapshot-id>.claim
```
5. Seed the domain with **common domain reference**, if applicable.
---
## 6. Certificates and Policies
* Root keys must be encrypted at rest.
* DAMs signed using offline authority host root keys.
* Policies included in `/domains/<domain-id>/policies/`.
* All signed artifacts stored in `/sops-bundles/` for delivery.
---
## 7. Optional Persistence
* If you want the host **bootable from USB**:
* Overlay FS (SquashFS or ISO) for system binaries
* Writable ZFS/Btrfs/EXT4 for `/domains` and `/sops-bundles`
* This allows the system to remain **fully offline** but store persistent artifacts.
---
## 8. Recommended Approach
* **Immutable image** for the offline host (SquashFS or ISO)
* **Writable storage** for domains (`/mnt/pool`) or USB disk
* Use **ZFS datasets** for:
* Block storage
* Snapshots of logs & store
* Pre-load binaries for deterministic PER generation, DAM signing, and rescue scripts.
* Environment claims stored and optionally signed before any DAM operation.
---
If you want, I can **write a concrete build script outline** (e.g., Debian-based ISO with overlay + ZFS pools + included binaries + directory structure), so you have a starting point to actually produce the bootable auth host image.
Do you want me to do that next?