314 lines
5 KiB
Markdown
314 lines
5 KiB
Markdown
Yes — this is exactly the right pressure point, and you’ve named it correctly.
|
||
|
||
You’re seeing the **only place where coordination is actually required**, and it’s much narrower than it first appears.
|
||
|
||
Let me be very precise and a bit formal here, because this is subtle and important.
|
||
|
||
---
|
||
|
||
## 1. First: your observation is correct
|
||
|
||
If Alice and James are both on:
|
||
|
||
```
|
||
common@1
|
||
```
|
||
|
||
and both independently “add something”, then naïvely you get:
|
||
|
||
```
|
||
Alice → common@2a
|
||
James → common@2b
|
||
```
|
||
|
||
Those are **two different histories**.
|
||
|
||
That *would* be a fork **if** both were considered “Common”.
|
||
|
||
So yes:
|
||
👉 **something must serialize Common**.
|
||
|
||
---
|
||
|
||
## 2. The crucial clarification: who is allowed to advance Common?
|
||
|
||
> **Common is not advanced by participants.
|
||
> It is advanced by a witness.**
|
||
|
||
This is the architectural line that resolves the paradox.
|
||
|
||
---
|
||
|
||
## 3. Common is a *witnessed log*, not a shared workspace
|
||
|
||
Think of Common as:
|
||
|
||
* an append-only log
|
||
* with a **single logical writer**
|
||
* that accepts signed submissions
|
||
|
||
Participants **submit**, they do **not commit**.
|
||
|
||
---
|
||
|
||
## 4. The minimal roles (exactly three)
|
||
|
||
### 1. Proposers (Alice, James, anyone)
|
||
|
||
They can:
|
||
|
||
* create artifacts
|
||
* create snapshots in their own domains
|
||
* create **proposals for Common**
|
||
|
||
They cannot:
|
||
|
||
* advance Common’s snapshot number
|
||
|
||
---
|
||
|
||
### 2. Witness (one domain, possibly replicated)
|
||
|
||
The witness:
|
||
|
||
* verifies signatures
|
||
* checks policy
|
||
* assigns the next snapshot number
|
||
* emits `common@N+1`
|
||
|
||
This can be:
|
||
|
||
* a single offline authority
|
||
* a small quorum-backed authority
|
||
* a rotating authority (later)
|
||
|
||
But **logically** it is one voice.
|
||
|
||
---
|
||
|
||
### 3. Consumers (everyone, including Alice and James)
|
||
|
||
They:
|
||
|
||
* pin to specific `common@N`
|
||
* choose when to advance
|
||
* may ignore updates forever
|
||
|
||
---
|
||
|
||
## 5. Why this is still “distributed enough”
|
||
|
||
The witness does **not** need to be:
|
||
|
||
* online all the time
|
||
* fast
|
||
* highly available
|
||
|
||
Because:
|
||
|
||
* Common updates are **rare**
|
||
* nothing blocks local work
|
||
* proposals queue safely
|
||
|
||
This matches your rescue / offline-first worldview.
|
||
|
||
---
|
||
|
||
## 6. What actually happens in your scenario
|
||
|
||
Let’s replay it correctly.
|
||
|
||
### Initial state
|
||
|
||
```
|
||
common@1
|
||
```
|
||
|
||
Alice and James are both pinned to it.
|
||
|
||
---
|
||
|
||
### Alice acts
|
||
|
||
Alice creates:
|
||
|
||
```
|
||
alice@42
|
||
```
|
||
|
||
She then creates:
|
||
|
||
```
|
||
proposal_A
|
||
references: alice@42
|
||
signed by: Alice
|
||
```
|
||
|
||
She **submits** this proposal to the Common witness (USB, sync later, whatever).
|
||
|
||
---
|
||
|
||
### James acts
|
||
|
||
James independently creates:
|
||
|
||
```
|
||
james@17
|
||
```
|
||
|
||
He creates:
|
||
|
||
```
|
||
proposal_B
|
||
references: james@17
|
||
signed by: James
|
||
```
|
||
|
||
He submits it too.
|
||
|
||
---
|
||
|
||
### The witness (later, offline is fine)
|
||
|
||
The witness receives both proposals.
|
||
|
||
It chooses an order (any deterministic rule):
|
||
|
||
```
|
||
apply proposal_A
|
||
emit common@2
|
||
|
||
apply proposal_B
|
||
emit common@3
|
||
```
|
||
|
||
No fork.
|
||
No conflict.
|
||
No simultaneity problem.
|
||
|
||
---
|
||
|
||
## 7. What if the witness is offline for a month?
|
||
|
||
Nothing breaks.
|
||
|
||
* Alice and James continue working
|
||
* They exchange artifacts directly if they want
|
||
* Common just doesn’t advance
|
||
|
||
When the witness comes back:
|
||
|
||
* proposals are processed
|
||
* snapshots advance
|
||
|
||
Time is explicit, not implicit.
|
||
|
||
---
|
||
|
||
## 8. What about multiple witnesses?
|
||
|
||
You anticipated this correctly.
|
||
|
||
There are **two safe models**, and one unsafe one.
|
||
|
||
### ❌ Unsafe: multiple independent writers
|
||
|
||
This causes forks. We don’t do this.
|
||
|
||
---
|
||
|
||
### ✅ Safe model A: single designated witness
|
||
|
||
* Simplest
|
||
* Best for now
|
||
* Matches your offline authority laptop perfectly
|
||
|
||
This is what you should start with.
|
||
|
||
---
|
||
|
||
### ✅ Safe model B: quorum → single emitter
|
||
|
||
Multiple authorities may:
|
||
|
||
* co-sign approval
|
||
* vote on proposals
|
||
|
||
But **only one entity actually emits `common@N+1`**.
|
||
|
||
Quorum decides *what* is accepted.
|
||
Emitter decides *when* it is numbered.
|
||
|
||
Still no fork.
|
||
|
||
---
|
||
|
||
## 9. Why we do NOT use consensus protocols here
|
||
|
||
This is important philosophically.
|
||
|
||
Consensus (Raft, Paxos, blockchain):
|
||
|
||
* assumes frequent updates
|
||
* assumes always-on participants
|
||
* assumes global liveness
|
||
|
||
Your system:
|
||
|
||
* assumes **offline**
|
||
* assumes **slow social processes**
|
||
* assumes **human-scale trust**
|
||
|
||
So:
|
||
|
||
> **Serialization is intentional, not a limitation.**
|
||
|
||
---
|
||
|
||
## 10. How this fits your “SystemRescue + offline authority” story
|
||
|
||
Perfectly.
|
||
|
||
Your offline auth host is a **natural Common witness**.
|
||
|
||
* It boots rarely
|
||
* It accepts USB proposals
|
||
* It emits signed Common snapshots
|
||
* It goes dark again
|
||
|
||
That’s not a hack.
|
||
|
||
That’s the **ideal operating mode**.
|
||
|
||
---
|
||
|
||
## 11. Final mental model (keep this one)
|
||
|
||
> **Common is not a shared folder.
|
||
> It is a notarized ledger.**
|
||
|
||
People bring papers.
|
||
The notary timestamps them.
|
||
The archive grows.
|
||
No pages are torn out.
|
||
No two page numbers collide.
|
||
|
||
---
|
||
|
||
## 12. One-line answer to your concern
|
||
|
||
> Yes — without a witness you get forks.
|
||
> With a witness, simultaneity collapses into sequence, even offline.
|
||
|
||
---
|
||
|
||
If you want next, we can:
|
||
|
||
* formalize the Common Witness role in ASL-AUTH
|
||
* specify proposal artifact schemas
|
||
* define exact snapshot numbering rules
|
||
* design how a witness rotates or retires safely
|
||
|
||
You’re asking the *right* questions.
|
||
|