Repository navigation
Community: presence replay records fill the 4,096 incoming table and stop intake #401
Description
Every accepted Community frame, including presence, leaves a replay tombstone kept for the maximum message lifetime + 2x clock skew (~24 h; collaboration_core.rs tombstone_retention_deadline ~:3159), and the incoming records+tombstones table refuses all intake at 4,096 (MAX_INCOMING_RECORDS_AND_TOMBSTONES :54, refusal :2003-2007). Presence is not rate limited (collaboration_rate_limit.rs:15-17). One Discovery-on peer at 15 s fills it in ~17 h, 20 peers in ~51 min, a hostile peer in minutes; Community intake then stops for up to a day. The alpha.21 watchdog (no-peer recovery) does not cover it.
0.8.0 blocker. Fix in progress (branch fix/080-community-replay): tombstones live until the frame's own expiry + skew (capped at the lifetime), expired tombstones are pruned before refusing, and presence is rate limited per sender.
Done means: tests show 20 peers sending presence every 15 s for 2 simulated hours never exhaust intake and a post still arrives; a hostile sender at 50 presence/s cannot exhaust intake; a replayed post within its lifetime is still refused; installed check on the release candidate.
Source: external audit of develop 55dcb79 (rev 3) verified independently by OMP and grook on 16 Oct. Related: #86, #139.
Activity
train: merge fix/080-community-replay at 73bbbb1 (presence leaves no …
changelog: [0.8.0-alpha.22]; 0.8.0 Community note covers the hub and #…
andersalm commentedon Oct 16, 2026
Installed finding on alpha.22 (16 Oct, read-only reads of Anders's Homes): his Mac and Jetson Homes, both updated alpha.21 → alpha.22, receive no Community posts. Both state-v1.json files hold incoming_tombstones = 4096 (the cap) and incoming = 0. On the Mac, 3685 of the 4096 come from one sender at 240/hour, which is one 15 s presence heartbeat, all accepted under alpha.21 with Discovery on. alpha.22 (73bbbb1) stops new presence tombstones but keeps existing ones until retain_until = accepted_at + 24 h + 60 s. A full table refuses new frames with a retryable error and evicts nothing (collaboration_core.rs:1190-1276, 2105-2109), so these Homes stay blocked until the alpha.21-era entries expire. On the Mac, the first 67 slots free about 4 h from 19:28Z, then about 240/hour. Fresh alpha.22 Homes are not affected (6 Homes across networks: every pair delivered in 1-3 s).
Decision (devil's advocate: MODIFY): no alpha.23 purge. Receipts carry no kind or expiry, so an early purge would drop replay protection, and expired-only pruning already exists. Testers are told. Posts sent while a Home was full are not re-sent; history loading (Discovery on) can fill some in.
#401 stays open until (1) an upgraded Home receives posts again (Mac/Jetson once slots free) and (2) Discovery-on alpha.22 Homes show no tombstone growth from presence over 30 min (running now).
andersalm commentedon Oct 16, 2026
Remaining limit split out to #409 (chat posts can still fill the 4096-entry intake table; open, no solution chosen, After 0.8.0; Anders 16 Oct: not a 0.8.0 blocker). #401 closes once (1) the Discovery-on alpha.22 Homes show no tombstone growth from presence over 30 min and (2) an upgraded Home receives posts again.
andersalm commentedon Oct 16, 2026
Milestone sweep (16 Oct, alpha.22): stays open.
Closes when: the 11–12 new tombstones are matched to posts (not presence) and Anders's Mac/Jetson receipt is recorded here. Owner: OMP (attribution), Anders (receipt).
andersalm commentedon Oct 16, 2026
Closing with installed evidence on 0.8.0-alpha.22 (f346147, fix 73bbbb1):
Remaining, not a 0.8.0 blocker (Anders): chat posts can still fill the table (Community: chat posts can still fill a Home's 4096-entry intake table (spam can stop Community for hours) #409).