Use monotonic created_at when publishing replaceable events #122

New issue

Closed

opened 2026-06-18 11:20:56 +00:00 by padreug · 0 comments

padreug commented

2026-06-18 11:20:56 +00:00

Owner

From the nostr-patterns review — and directly the lesson from the ticket-count live-update debugging.

Problem

Relays only push a replaceable update to open subscriptions when created_at is strictly newer (verified against our relay). Publishers that stamp created_at = floor(Date.now()/1000) (second resolution) can emit two versions in the same second — the relay treats the second as not-newer and won't propagate it to live subscribers (it only shows on a reload/re-query).

useBookmarks (NIP-51 kind-10003) republishes the whole list on every toggle with second-resolution created_at — rapid toggles can collide. (The aiolabs/events extension's nostr_publisher uses int(time.time()) too — tracked separately.)

Proposed fix

When publishing a replaceable event, use a monotonic timestamp: created_at = max(floor(Date.now()/1000), lastKnownCreatedAt + 1). Apply in useBookmarks (webapp); file/flag the same for the events extension.

Testing

Unit test the timestamp helper: two publishes "in the same second" produce strictly increasing created_at; a publish after a future-dated prior bumps past it.

To be done as a PR (gap #2 of the review).

From the nostr-patterns review — and directly the lesson from the ticket-count live-update debugging. ## Problem Relays only **push a replaceable update to open subscriptions when `created_at` is strictly newer** (verified against our relay). Publishers that stamp `created_at = floor(Date.now()/1000)` (second resolution) can emit two versions in the **same second** — the relay treats the second as not-newer and won't propagate it to live subscribers (it only shows on a reload/re-query). `useBookmarks` (NIP-51 kind-10003) republishes the whole list on every toggle with second-resolution `created_at` — rapid toggles can collide. (The `aiolabs/events` extension's `nostr_publisher` uses `int(time.time())` too — tracked separately.) ## Proposed fix When publishing a replaceable event, use a **monotonic** timestamp: `created_at = max(floor(Date.now()/1000), lastKnownCreatedAt + 1)`. Apply in `useBookmarks` (webapp); file/flag the same for the events extension. ## Testing Unit test the timestamp helper: two publishes "in the same second" produce strictly increasing `created_at`; a publish after a future-dated prior bumps past it. _To be done as a PR (gap #2 of the review)._

padreug added the

app:webapp

bug

labels

2026-06-18 11:21:14 +00:00

padreug referenced this issue from a commit

2026-06-18 11:30:54 +00:00

fix(events): publish bookmarks with monotonic created_at (#122)

padreug referenced this issue

2026-06-18 11:31:15 +00:00

chore(test): add vitest runner + smoke test #124

padreug referenced this issue from a pull request that will close it,