Add read status NIP

[staab]

This is simple, and granular. It uses e tags, not a tags to allow clients to differentiate versions of replaceable events. It allows for expiration and tagging multiple events at once to reduce storage requirements. It's not a replaceable list, so there won't be conflicts between writes. It allows for public and private read receipts, so it covers DM/group chat read receipts as well as user notification read status.

[jb55]

nice!

[basantagoswami]

We can also use a similar scheme to save drafts of all kinds of events can't we?

[staab]

Coracle now supports this for marking notifications as read. I currently use NIP 59 to wrap the events. If the user's signer doesn't support NIP 44 I fall back to encrypting with NIP 04 for now.

Edit: rather than encrypting with nip 04 I decided to simply not encrypt read receipts if nip 44 isn't enabled. This is a minor privacy problem for users, but it's probably better than the alternative in this case.

[fiatjaf]

Is this implemented anywhere?

[fiatjaf]

Do you think this could be used for the "counting views" flow like what is described in #923 @staab?

[staab]

Is this implemented anywhere?

Coracle uses it for keeping track of notifications that have been seen. I'm still trying to decide if it's a good idea, because small bugs can result in loops that create many copies of the same event. These all have to be decrypted (since notification read status are private), which is a lot of load on clients.

Do you think this could be used for the "counting views" flow like what is described in #923 @staab?

Maybe, it depends on what the semantics are. But probably not, because it could end up confusing one use case with another (I saw that I was mentioned in this video, vs I watched some arbitrary threshhold of the video).

[vitorpamplona]

I tested this in batches of 100 events. It works well. Two issues:

• It uses a lot of memory to represent a boolean. The phone has to get rid of them as fast as possible.
• Private events should not have these.

In the end, I reverted it to a route-based system that simply stores the .created_at of the newest post visible on the screen or the phone's local time if the user is at the top of each feed. It's not as granular, there are some issues with past posts showing up, but it is quite private and compact, and solves most of the need.

[staab]

simply stores the .created_at of the newest post

This is what I used to do, and it might be the better option. We should specify where to store this information in an interoperable way, which was the point of this NIP. Clients can handle the out-of-order edge case if desired by storing event ids locally.

[vitorpamplona]

I think we all represent routes slightly differently (like I use Java's hash integer of the event_ids in a group DM to Route to the group), but it could work.

[staab]

Yeah, we could also break it down pretty granularly with canonical names, e.g. mentions_last_checked but there would probably always be views that departed from our expectations 🤔

[vitorpamplona]

I am back on this. The way to use this PR is with a private "outbox" relays: A relay type that only allows the signer to download their own posts. It's ideal for things like App settings, Drafts, and these read statuses. It could be a local relay, like using Citrine on Android, or a Remote but Authed one.

[staab]

After having this implemented for about 6 months, I'm abandoning it because it creates a whole lot of 1059-wrapped events that I don't want to download when asking for DMs. I created another attempt based on replaceable events, and only encrypting the content here: #1405.