Implement `listNotifications`'s `seenAt` param

[snarfed]

Hi all! Minor request, just filing to track. Looks like neither the TS AppView nor the Go AppView currently support seenAt:

https://github.com/bluesky-social/atproto/blob/828dfa8a8af523858ebd4dc164c996a8884c50b9/packages/pds/src/app-view/api/app/bsky/notification/listNotifications.ts#L29-L31

https://github.com/bluesky-social/indigo/blob/251fff6498dc6f44378fa155620d9ccd77cfac67/pds/handlers.go#L250-L251

seenAt would be easier for me to use than cursor, which I assume is per user.

Not a big deal. Thanks in advance!

[snarfed]

Ooh, its cursor looks like a combination of timestamp and CID, eg 1694028501407::bafyrei.... Are cursors translated to simple lexicographic inequality, ie something like WHERE ... >= cursor? If so, I wonder if I could pass in a bare timestamp, eg 1694028501407::. Let's see...

...not quite. I got it to return me notifications with cursor=1695064595407::... (59 .s), where that timestamp is yesterday, but it still returned me a full page of notifs, going back before yesterday. So it's actually using the CID. Ah well.

[dholms]

Thanks for filling! seenAt was actually meant for statelessly providing the last notification seen time to a service that lists notifications (or returns unread count) so that that service doesn't have to implement updateSeenAt

Turns out we're not really using it yet tho as we moved that state up to the appview.

On the note of cursors: Nearly all of our cursors are composite cursors. Many are time::cid. we sort by time & use cid as a tie-breaker. If you just want to get notifs since a previous time, I recommend using the time & any random cid or cid looking thing

[snarfed]

Nearly all of our cursors are composite cursors. Many are time::cid. we sort by time & use cid as a tie-breaker. If you just want to get notifs since a previous time, I recommend using the time & any random cid or cid looking thing

Thanks! And hmm, I'm only getting an empty notifications array from listNotifications on the sandbox AppView when I give it a cursor, any cursor. Here are a few examples, all fabricated except the first:

• 1694996366691::bafyreigi5fsc3mafmsiv2okym4awdsriky3lrzabgshtmpya3mgj6oef24 (returned by listNotifications just now, so I wouldn't expect any results)
• 1694909966000::bafyrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxoef24
• 1694823566000::bafyrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxoef24
• 1694737166000::bafyrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxoef24
• 1694737166000::bafyreigi5fsc3mafmsiv2okym4awdsriky3lrzabgshtmpya3mgj6oef24
• 1000000000000::bafyreigi5fsc3mafmsiv2okym4awdsriky3lrzabgshtmpya3mgj6oef24
• 0::bafyreigi5fsc3mafmsiv2okym4awdsriky3lrzabgshtmpya3mgj6oef24

Not a big deal! Just curious.

[snarfed]

Interesting changes since I last looked at this! listNotifications on api.bsky.app is no longer returning cursor at all now.

Also interesting, for comparison, getAuthorFeed on api.bsky.app is returning a plain datetime string as cursor, no CID, eg 2024-04-07T16:07:40Z. The plot thickens.

Fwiw, due to this ^, I'm now just storing the most recent indexedAt and discarding all notifications before that. I'll happily start using cursors again once they're available!

[snarfed]

Huh, I take it back, I'm now seeing cursor in the output after all. And I don't get seenAt if I pass a cursor, but I get it if I don't. Not sure why that one call earlier didn't give me back either.