From 9268de2371b7f298dcfb2639b43e478c40e59c5b Mon Sep 17 00:00:00 2001 From: ddidderr Date: Sun, 9 Aug 2026 17:10:31 +0200 Subject: [PATCH] updated plan --- organize/planning/PEER_AUTH_PLAN.md | 33 +++++++++++++++++------------ 1 file changed, 20 insertions(+), 13 deletions(-) diff --git a/organize/planning/PEER_AUTH_PLAN.md b/organize/planning/PEER_AUTH_PLAN.md index 7cabd6f..03f7308 100644 --- a/organize/planning/PEER_AUTH_PLAN.md +++ b/organize/planning/PEER_AUTH_PLAN.md @@ -325,18 +325,24 @@ responder's own `(runtime_session_id, library_revision, call_to_play_revision)`. The initiator compares them against what it has cached for that endpoint generation and, on any mismatch or a new session ID, schedules exactly the coalesced pinned pull a hint would have scheduled. A hint that was dropped, -never sent, or discarded by rate limiting therefore converges within one ping -interval, with no new timer, no mDNS payload growth, and no periodic full-state -polling. +never sent, or discarded by rate limiting therefore converges within +`PEER_PING_IDLE_SECS + PEER_PING_INTERVAL_SECS`, because the idle threshold is +only evaluated on interval ticks; that is 50s at the current 30s/20s settings, +not one interval. Assert against the constants rather than a literal bound. +Reconciliation still adds no new timer, no mDNS payload growth, and no periodic +full-state polling, and 50s is acceptable for the rare lost-hint case. -Freshness for that check must be measured from the local peer's own last pinned -exchange with the remote peer, never from inbound activity. The current -`ping_idle_peers` skips any peer whose `last_seen` was refreshed by traffic -arriving from it (`update_last_seen_by_addr`), so a peer that keeps talking to -us would suppress the very check that detects our staleness about it. Track the -last completed outbound pinned exchange separately from `last_seen`, which -continues to serve stale-peer pruning. Inbound traffic is not evidence of -freshness, for the same reason it is not evidence of identity. +Freshness is tracked per peer as `last_revision_check`, stamped only by an +exchange that actually returned that peer's current revisions: a `Pong` or a +completed pull. Content transfers must not stamp it. A large download is a long +run of outbound pinned exchanges that carry no revisions, and it is exactly when +reconciliation must not be postponed. Inbound activity must not stamp it either: +`ping_idle_peers` currently gates on `last_seen`, which +`update_last_seen_by_addr` refreshes from traffic arriving from that peer, so a +peer that keeps talking to us would suppress the very check that detects our +staleness about it. `last_seen` keeps its existing stale-peer pruning role and +is not reused here. Inbound traffic is not evidence of freshness, for the same +reason it is not evidence of identity. Revisions on `Pong` are a staleness signal, not content authority; the pull remains the authoritative step. A responder that inflates its revision only @@ -557,8 +563,9 @@ This phase is not complete until: - a forged mDNS record or inbound hint cannot create/rebind/remove peer state, inject a library/Call-to-Play update, or bypass a pinned pull; - a change hint that is dropped, never sent, or rate-limited away still - converges within one ping interval, and inbound traffic from a peer does not - defer that peer's revision check; + converges within `PEER_PING_IDLE_SECS + PEER_PING_INTERVAL_SECS`, and neither + inbound traffic nor an in-flight content transfer defers that peer's revision + check; - an honest multi-source download swarms automatically and commits only the catalog bytes; - one bad source is quarantined and another source completes the chunk;