Track checked across devices #252

New Issue

2026-04-29T18:29:23Z

hodlbod commented

2026-04-29 18:29:23 +00:00

It's annoying to open your phone and have to clear all the same badges as you already cleared on desktop. We'll want to create a companion server for storing this information encrypted. It might make sense to deploy an authenticated flotilla relay and use nip 78 for this kind of thing.

hodlbod added this to the Current milestone 2026-04-29 18:29:23 +00:00

hodlbod added the dev label 2026-04-29 18:29:23 +00:00

nayan9617 commented

2026-04-30 20:42:55 +00:00

@hodlbod The NIP-78 approach makes sense for this. One thing worth thinking through before implementation: the read cursor needs to encode both the space relay URL and the room #h tag together as the key, otherwise a user in two different spaces that happen to have identically-named rooms would get their cursors mixed up. So the stored structure would be something like { [relayUrl + ":" + roomH]: lastReadTimestamp }, encrypted and published as a NIP-78 app-specific event.

The trickier part is probably the write cadence — you don't want to publish a new NIP-78 event every time a message is read (that's a lot of relay writes for an active user). A debounced write, maybe 5–10 seconds after the last read action, would batch cursor updates across rapid message viewing into a single relay publish.
Happy to take a stab at this if it's useful.

@hodlbod The NIP-78 approach makes sense for this. One thing worth thinking through before implementation: the read cursor needs to encode both the space relay URL and the room #h tag together as the key, otherwise a user in two different spaces that happen to have identically-named rooms would get their cursors mixed up. So the stored structure would be something like { [relayUrl + ":" + roomH]: lastReadTimestamp }, encrypted and published as a NIP-78 app-specific event. The trickier part is probably the write cadence — you don't want to publish a new NIP-78 event every time a message is read (that's a lot of relay writes for an active user). A debounced write, maybe 5–10 seconds after the last read action, would batch cursor updates across rapid message viewing into a single relay publish. Happy to take a stab at this if it's useful.

hodlbod commented

2026-05-04 21:22:07 +00:00

We should actually make a bespoke server for this so we don't have to sign events all the time. However, we should still authenticate with it for read/write to avoid leaking metadata. Using the nip 98 auth approach from caravel would probably make sense. Just dump checked into it from app/util/notifications

We should actually make a bespoke server for this so we don't have to sign events all the time. However, we should still authenticate with it for read/write to avoid leaking metadata. Using the nip 98 auth approach from caravel would probably make sense. Just dump `checked` into it from app/util/notifications

hodlbod modified the milestone from Current to Next

2026-05-06 20:09:16 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coracle/flotilla#252