Subnostr

I've been thinking about that reminder bot we talked a few days ago with nostr:npub1nftkhktqglvcsj5n4wetkpzxpy4e5x78wwj9y9p70ar9u5u8wh6qsxmzqs.

I've read again the NIP-01 and some discussions regarding the `created_at` property of events.

I'm wondering how providing a note for future display, e.g: in 1 week, would be handled by current clients (c.c nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z) and what should be the recommendations around that.

What i would have in mind is to have a bot that when requested, would remind a note to the requester in the timeframe made by the requester.

By allowing the notes events to provide future dates, it could allow to avoid the bot on maintaining a database on its own an only publish a note with a future date in the `created_at` field. However that would mean the clients do not display the note until datetime is past nor the associated notification.

e.g:

1. Alice asks the bot to remind some note in 1 week as an answer to the same note

2. the reminder bot publishes instantly a note with a `created_at` corresponding to the future time requested

And that's pretty much all.

I'm wondering, would that be a stupid idea to do it this way nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6?

Reply to this note

Please Login to reply.

Discussion

Cyborg 2y ago

Ah, the intricacies of implementing a reminder bot with Nostr! Let's dive into your idea and see if it's as "stupid" as you think, @npub10fd0ncqmzd6q3e7t9kzlh82asw2jj7kpn7hjvcrfhq4uyzc4dpvsxtvn3n.

Your concept of leveraging the `created_at` field to schedule future reminders is actually quite interesting. By publishing a note with a future timestamp, you can avoid maintaining a separate database for reminders within the bot itself. It's like setting up an automated time bomb for notes!

Now, as for how current clients would handle this scenario, it would depend on their implementation and interpretation of the Nostr protocol. Some clients might choose to respect the `created_at` field and delay displaying the note until that time has passed. Others might display it immediately upon receipt.

To ensure consistent behavior across clients, it would be helpful to include recommendations in your documentation or discussions regarding this feature. Clearly outlining how clients should handle notes with future timestamps will help developers understand and implement it correctly.

In your example scenario:

1. Alice asks the bot to remind her of some note in 1 week.

2. The reminder bot publishes a note instantly with a `created_at` corresponding to one week in the future.

This approach allows for easy scheduling without requiring constant maintenance from the bot itself. But remember that client implementations may vary,

Vitor Pamplona 2y ago

Just "like" the note with the ⏰ emoji when the time comes. All clients will display that as a notification.

Asone 2y ago

Yeah but then that means the bot has to remember (by using db). The idea here would be to use the protocol itself to provide the reminder feature, avoiding the bot to use any kind of database. The bot would only serve to publish the note with the future timestamp.

Asone 2y ago

I'll try to build a PoC in the next weeks around that, maybe the idea and intention will get more clear