mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-06 11:48:24 +00:00
davotoulaandClaude Opus 5
f150696a26
Review feedback on the PR: created_at has second resolution, so nothing on nostr can replace an address more than once per second — and a client that keeps out-stamping the previous version drifts a second further into the future per republish, which relays may reject. That is right, and it points at a better guard than `+ 1`. One second is the real floor on how often an address can be replaced, so a client that replaces one faster should wait for the clock rather than invent a timestamp. awaitCreatedAtToSupersede suspends until the second the previous version claimed has passed, then stamps the real time — the new version still wins, and no event is ever dated ahead of the clock. The wait is bounded (MAX_SUPERSEDE_WAIT_SECONDS). A version further ahead than that came from another device's skewed clock rather than this client's own burst, and sleeping it out could take hours, so past the bound out-stamping is still the only way to supersede. Applied to the two paths that can accumulate drift across repeated edits and were already suspending under a mutex: the NIP-78 settings blob and the per-d-tag app recommendations. RoomParticipantActions keeps the non-suspending form — it is reached from Compose click handlers, and its stamp derives from the single event being acted on, so it sits at most one second ahead and cannot drift. Note the debounce added earlier already keeps the settings pickers from publishing sub-second at all (measured on device: 23 rapid toggles → 3 events, each stamped at the true wall-clock second, the `+ 1` never firing). This makes that a guarantee rather than a consequence of timing, and extends it to the settings paths that are deliberately not debounced. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Voa2KcknNffhvPqsRG92hx