246 lines
4.7 KiB
Markdown
246 lines
4.7 KiB
Markdown
Yes — this is exactly the *right* point to be at.
|
||
What you’re describing is **domain nesting + scoped publication**, not special cases. And your architecture already supports it — you just need to *name the rules*.
|
||
|
||
Below is the **clean, general solution** that works for:
|
||
|
||
* Personal rescue missions
|
||
* Group domains
|
||
* Organizational domains
|
||
* Cross-user federation
|
||
* Selective publication
|
||
* Zero impersonation
|
||
|
||
---
|
||
|
||
# Personal Domains, Group Domains, and Safe Publication
|
||
|
||
---
|
||
|
||
## 1. First principle (this makes everything work)
|
||
|
||
> **Domains are not hierarchical by default — trust is.**
|
||
|
||
There is:
|
||
|
||
* No implicit parent/child authority
|
||
* No inherited permissions
|
||
* No automatic visibility
|
||
|
||
Everything is **explicit and pinned**.
|
||
|
||
---
|
||
|
||
## 2. Your personal domain (root of agency)
|
||
|
||
You have a **personal root domain**:
|
||
|
||
```
|
||
domain_id: me.example
|
||
```
|
||
|
||
This is:
|
||
|
||
* Your cryptographic identity in the system
|
||
* Anchored by *your* offline roots
|
||
* The ultimate source of authority for *your* actions
|
||
|
||
All other domains you control are **authorized by this domain**, not children of it.
|
||
|
||
---
|
||
|
||
## 3. Rescue domain (ephemeral, scoped)
|
||
|
||
For the rescue mission:
|
||
|
||
```
|
||
domain_id: me.example/rescue/laptop-2014
|
||
```
|
||
|
||
This domain:
|
||
|
||
* Is freshly minted
|
||
* Has its own DAM
|
||
* Has limited policy
|
||
* Is authorized *by you*
|
||
* Can be destroyed or archived later
|
||
|
||
It does **not** inherit authority — it is **delegated**.
|
||
|
||
---
|
||
|
||
## 4. Historical domain (referenced, inert)
|
||
|
||
The old laptop becomes:
|
||
|
||
```
|
||
domain_id: me.example/legacy/laptop-2014
|
||
```
|
||
|
||
This domain:
|
||
|
||
* Has no active authority
|
||
* No DAM
|
||
* No roots
|
||
* Exists only as a provenance subject
|
||
|
||
This avoids impersonation while preserving meaning.
|
||
|
||
---
|
||
|
||
## 5. How you safely create your own domain
|
||
|
||
### Step 1 — Mint a new domain key
|
||
|
||
On an online or offline machine:
|
||
|
||
* Generate domain root key
|
||
* Generate DAM
|
||
* Define policy hash (likely restrictive)
|
||
|
||
### Step 2 — Certify it with your personal root
|
||
|
||
On offline ORA:
|
||
|
||
* Issue AuthorityCertificate:
|
||
|
||
* subject_type: domain_root
|
||
* domain_id: me.example/rescue/laptop-2014
|
||
* Sign with *your* personal offline root
|
||
|
||
This is delegation, not inheritance.
|
||
|
||
---
|
||
|
||
## 6. Group domains and org domains (same model)
|
||
|
||
A group domain:
|
||
|
||
```
|
||
domain_id: friends.example/photos
|
||
```
|
||
|
||
* Has its own roots
|
||
* Its own DAM
|
||
* Its own policy
|
||
* You may or may not be a principal
|
||
|
||
If you are:
|
||
|
||
* You hold a **principal certificate** issued by that domain’s roots
|
||
* Your personal domain does *not* override group authority
|
||
|
||
This prevents privilege bleed.
|
||
|
||
---
|
||
|
||
## 7. Publishing rescued material (the key part)
|
||
|
||
You can publish **selectively**, **safely**, and **without confusion**.
|
||
|
||
### 7.1 Publish inside your personal domain
|
||
|
||
```
|
||
me.example/rescue/laptop-2014
|
||
──publish──> me.example/archive
|
||
```
|
||
|
||
Mechanism:
|
||
|
||
* Federation with trust pin
|
||
* Scope-limited (READ_ARTIFACTS)
|
||
* Snapshot-pinned
|
||
|
||
---
|
||
|
||
### 7.2 Publish to a group domain
|
||
|
||
```
|
||
me.example/rescue/laptop-2014
|
||
──publish──> friends.example/photos
|
||
```
|
||
|
||
Only if:
|
||
|
||
* friends.example has pinned your rescue domain
|
||
* Scope allows READ_ARTIFACTS
|
||
* Policy hashes are compatible
|
||
|
||
No unilateral publishing.
|
||
|
||
---
|
||
|
||
### 7.3 Publish publicly (one-way)
|
||
|
||
```
|
||
me.example/rescue/laptop-2014
|
||
──publish──> public.example/archive
|
||
```
|
||
|
||
* Public domain pins *you*
|
||
* You never pin them
|
||
* One-way trust
|
||
|
||
---
|
||
|
||
## 8. Safe defaults (important)
|
||
|
||
### By default:
|
||
|
||
* New domains are **private**
|
||
* Nothing federates
|
||
* Nothing publishes
|
||
* Nothing is trusted
|
||
|
||
You must explicitly:
|
||
|
||
* Publish snapshots
|
||
* Pin trust
|
||
* Declare scope
|
||
|
||
This prevents accidental leakage.
|
||
|
||
---
|
||
|
||
## 9. Why this works for *all* users
|
||
|
||
This model scales because:
|
||
|
||
✔ Individuals control their own roots
|
||
✔ Groups define their own authority
|
||
✔ Domains don’t impersonate each other
|
||
✔ Publication is opt-in
|
||
✔ Provenance stays intact
|
||
|
||
And critically:
|
||
|
||
> **You never need global user accounts.**
|
||
|
||
---
|
||
|
||
## 10. Mental model (keep this one)
|
||
|
||
* **Personal domain** = identity
|
||
* **Rescue domain** = action
|
||
* **Historical domain** = subject
|
||
* **Group domain** = collaboration
|
||
* **Publication** = explicit federation
|
||
* **Trust** = pinned, not assumed
|
||
|
||
---
|
||
|
||
## 11. One-sentence takeaway
|
||
|
||
> **You act through scoped domains you control, assert claims about history without impersonation, and publish only what you choose — all under explicit, cryptographically pinned trust.**
|
||
|
||
---
|
||
|
||
If you want next, we can:
|
||
|
||
* Specify **domain delegation certificates**
|
||
* Define **publication workflows (CLI-level)**
|
||
* Model **revocation without retroactive damage**
|
||
* Walk through a **full personal rescue → archive → share flow**
|
||
|
||
You’re now designing a system that treats *personal computing history* as first-class, verifiable data — and you’re doing it the right way.
|
||
|