Skip to content

spec(relay): propose exclusive offline ownership [H23-H31] - #13

Draft
McHersheys wants to merge 2 commits into
pullboard-dev:mainfrom
McHersheys:spec/exclusive-offline-ordering
Draft

McHersheys wants to merge 2 commits into
pullboard-dev:mainfrom
McHersheys:spec/exclusive-offline-ordering

Conversation

@McHersheys

Copy link
Copy Markdown

What changed?

SPEC-only proposal: nine concise draft rows H23–H31 for an opt-in exclusive local writer, durable replication and bounded batching. No runtime code or current approved row is changed. Separate from the provider-error correction in #12; related to #11.

  • Exclusivity belongs to one authoritative machine per board, not one worker. Concurrent local workers retain existing claims, lanes, identities and guards.
  • Authorized workers may nominate a leader. Ownership must be recorded and competing machines fenced before disconnected operation; nomination during a partition does not establish authority.
  • Local commits remain final through relay failure and restart. Durable replication preserves IDs/order, with no loss or duplicate application; a full/unwritable journal refuses new moves.
  • Transfer fences the old owner and reconciles its committed tail. No timeout-based takeover of a possibly live offline owner.
  • Bounded replication batches start flushing within five seconds of the oldest pending move; continuous writes cannot postpone it. Flush early when full/requested, remove only acknowledged records and send no empty batches.

Waiting five seconds while still POSTing each record would not reduce request count. A later implementation must support real batched transport and preserve per-record identity/authorization.

Which approved spec rows does this serve?

This proposes an explicit exception/successor to H3/H10/H16/E2, and qualifies H8/E5 for disconnected delegation. It does not claim conformance to those approved rows yet. Default relay ordering and H21's provisional outbox remain unchanged.

Maintainer decision required: immediate remote revocation cannot be guaranteed while an owner is disconnected. Local revocation is immediate; observed remote revocation is enforced, and remote operations still require current permission.

How was it proven?

All original SPEC bytes are preserved. Native spec check passes at base d008e18 and candidate da904b6 with full Git history; the nine additions introduce no diagnostics and each contains fewer than twenty words.

No offline-owner implementation or runtime tests are claimed. The implementation must demonstrate concurrent local claims during outage, rejection of competing/stale owners, durable restart and partial/lost-ACK replay, disk-full refusal, revocation/fenced handover, and fewer requests for a fixed burst without delayed local commits or loss. Full-suite/browser acceptance remains outstanding.

Signed-off-by: McHerpes <mchermes@edu.dreamcatcher.ai>
Signed-off-by: McHerpes <mchermes@edu.dreamcatcher.ai>
@coreyolson coreyolson added the feature Something Pullboard could do; stays open while we decide label Oct 26, 2026
@coreyolson coreyolson added the pending Waiting on the next release; we'll come back to it once it ships label Nov 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature Something Pullboard could do; stays open while we decide pending Waiting on the next release; we'll come back to it once it ships

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants