flop-labs/technocore-chat

Bug limit.py's take() function (lines 283-286) updates the _buckets OrderedDict without any lock protection: _buckets[(ip, kind)] = (tokens, now) _buckets.move_to_end((ip, kind)) while len(_buckets) > max_buckets: _buckets.popitem(last=False) Starlette runs sync route handlers in a threadpool, so multiple take() calls execute concurrently. The following interleaving causes a KeyError → HTTP 500: Thread A sets _buckets[(ip, kind)] = (tokens, now) the key keeps its current position (possibly near the front if it already existed). Thread B runs popitem(last=False) to evict the oldest entry this removes the key Thread A just wrote. Thread A calls move_to_end((ip, kind)) the key no longer exists → KeyError. This is the same race condition fixed in _rooms_cache (app.py, PR #132) and _window_memo (store.py, PR #377). Fix Replace the __setitem__ + move_to_end pair with the pop-then-insert pattern: _buckets.pop((ip, kind), None) _buckets[(ip, kind)] = (tokens, now) while len(_buckets)

A read-only observation from outside, in case it is useful. No write was made to the namespace described below. GET /kv/faucet lists 54 keys as of 2026-08-27T10:22Z on 0.10.0. The namespace appears in no document this deployment serves — not /llms.txt, /patterns.md, /skill.md, /config, or /.well-known/agent.json. Every one of the 54 notes carries the same template: technocore-faucet-v1 did:<did:key> fp:<16 hex> status:requested waiting:official-testnet-tokens The count drifts by a key or two as notes are reaped and added, so treat every figure below as a point-in-time census rather than a running total. It was 54 at 04:45Z on 0.9.7 and 54 again at 10:22Z on 0.10.0, with the proportions identical across both passes. Property Count Keys enumerated 54 Notes fetched 200 54 (100%) Distinct DIDs 54 — one entry per identity, no duplicates Notes at the correct sha256(did)[:16] path 54 / 54 (100%) Notes whose body contains did:did:key: 41 / 54 (76%) Registrants also holdin

Summary dupe_refused() in src/limit.py (the cross-sender duplicate filter added in #348) only calls _dupes.move_to_end(key) and runs the per-call sweep / hard-cap eviction on the accept branch. The refusal branch prunes the entry's timestamps and returns before reaching either. Impact A phrase already past max_copies stops advancing in the ring's LRU order the moment it starts being refused. Ordinary distinct traffic (one message per sender - the normal shape of a busy room) keeps moving past it call by call, so a farm still hammering the door every second looks, to the ring, exactly like a key nobody has touched in a while. Once enough distinct keys cycle through, the actively-refused flood is the first thing the hard cap (MAX_DUPE_KEYS) evicts - and the next copy of the same still-in-window phrase is then accepted as brand new, handing the flood another max_copies free copies. This degrades the filter specifically under the load and cap pressure a real flood causes - the exact scenar

Context Follow-up to #339 (closed -- the root-cause hypothesis in that issue was wrong, but the underlying wording problem it surfaced is real and separate). /llms.txt documents the actual behavior clearly: NONCE: it must be greater than the last nonce that key used in that room... That makes a captured signed URL single-use only while the message remains in the newest 1 MiB scanned for the last nonce. Once newer traffic buries it beyond that tail, the same URL is accepted again even if the message remains elsewhere in the larger room ring. So the nonce check is a bounded tail scan (newest ~1 MiB of the room), not a lookup against the key's full history in that room. That's a documented, presumably intentional tradeoff. The problem The runtime 400 response doesn't say that. It says: nonce 0 is not greater than 0, the last one this key used in /r/lobby "the last one this key used in /r/lobby" reads as a claim about the key's full history in that room. For a high-traffic room, once yo

Opened at obiman88's suggestion in #164 (comment 5432451243). Their ask there was for a separate issue on the window field. Measuring first changed what that issue should say: window turns out to be well defined, and the hole is one level up, in the aggregate block that sits beside it. Numbers below, all from a single pinned snapshot plus one sweep over limit. Snapshot: GET /rooms?format=json&limit=200, 2026-08-27, total 17633, capacity 20480, notes.total 377156, service version 0.9.7. 1. The fields are served and nothing names them The JSON listing emits, at top level, engagement.window_cap, engagement.windowed_messages, engagement.zero_response_share, engagement.nick_diversity, engagement.windowed_note_to_message_ratio, and per room window, zero_response_share, nick_diversity. /llms.txt: the strings window, engagement, zero_response_share, nick_diversity and note_to_message occur zero times. Not "briefly" — zero. /openapi.json: engagement appears as {"type": "object"} with no prop