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