Oddbean new post about | logout
 nostr:nprofile1qyfhwumn8ghj7ur4wfcxcetsv9njuetn9uq3jamnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kz7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qg3waehxw309ahx7um5wgh8w6twv5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qyw8wumn8ghj7un9d3shjtnzd96xxmmfdecxzunt9e3k7mf0qqsx3kq3vkgczq9hmfplc28h687py42yvms3zkyxh8nmkvn0vhkyyusg2aq6x  what is the difference between a `RelayPoolNotification::Event` and a `RelayPoolNotification::Message`? based on the docs, i assumed it was just whether i wanted to be notified about my own messages. however, i'm noticing that there are some valid events that i should be notified about that the relay is sending but then does not have the Event type and has the Message type instead. 
 The `Event` variant is sent only if the event ID was never seen. The `Message` variant is sent always, except for the `EVENT` msg if you have a persistent database enabled and the event was already stored. 
 very cool. is whether an Event variant is considered "seen" or not persistent between client runs even if the persistent database is not enabled? 
 No, if persistent database is not enabled the "seen" set is stored in RAM. So, if you stop and re-start the client you'll receive the Event notification again. 
 hmmm okay. I may have to dive into it more because that is not the behavior I was seeing. it appeared to remember what I had seen on subsequent restarts when using Event, but perhaps I am, how you say, a dipshit. will test again and inform.  
 Mh, that's weird. Is it in this project that you're having issues?

https://github.com/w3irdrobot/remindme 
 indeed. I've moved it to use the Message variant since. so it currently seems to be working fine. I'm just curious at to what my deal was. there's a good chance I was doing something incorrect.  
 Try to move the `client.subscribe` code and filter in the `process_reminder_notifications` func, between the `let mut notifications = client.notifications();` and `info!("listening for notifications");`

 
 I'll give that a shot here in a bit. what are you thinking the issue might be? 
 so nostr:nprofile1qy28wumn8ghj7un9d3shjctzd3jjummjvuhszymhwden5te0wp6hyurvv4cxzeewv4ej7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3jamnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kz7qgkwaehxw309ajkgetw9ehx7um5wghxcctwvshsqgrgmqgktyvpqzma5slu9rmarlqj24zxdcg3tzrtneamxfhktmzzwgaa0eg5  it looks like putting the subscribe after the notification receiver creation appears to be the key i needed. i appreciate the help. 
 When you call the 'notifications' method, you subscribe to the notification channel from that precise moment. Anything sent before that moment is not included in the channel.

In the code you were subscribing to the relays very early and then you were sending the metadata event (if one of the relays is offline it may take some seconds to continue). Therefore, when the `notifications` method was finally called, it's likely that the events had already been received (but not included in the notification channel).

---

I'll update the documentation of the "notifications" method. 
 ahh good call. classic race condition. well that makes alot of sense. thanks for the help!