4.7 KiB
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.