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