spams the local db for no reason. these are simply filter modifiers.
Discussion
but its not a bad point, its definitely simpler in that case
now that I think about it if local notedeck apps are generating lists (in your example citrine takes the place of nostrdb) then I don't really have a problem with it, and is much simpler. the problem is DVMs on public relays serving every cartesian product of personalized lists for every single person and all their feeds. thats the thing that is crazy to me.
This would be pretty cool actually, different local apps responding to different requests and generating responses. Ok I like them now (in this context)
Yeah, for these dumbs ones sure. But most DVMs are way more complicated than filter modifiers. They can do a lot. Think about the DVM spec as just an standarized interface to any algo the user wants.
We need an ephemeral job result type
I need a “send thread to ChatGPT and explain in normie language” button.
[expiration, now]
Literally just listened to you and nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s talking about this on the podcast while washing dishes. 😅
🤌 perfect timing.
Or expiration in the past, at least then i would know not to store it in nostrdb and just pass it around as an owned note in memory
is it logical to broadcast an expired event? why?
i think it won't work. for example in immortal relay, we just check if its expired or not. for expired ones we even don't broadcast them. other ones will be stored and broadcasted at the same time.
beacuse its not logical to broadcast expired events. also adding a third status of `now` is a little confusing since in the best situation we have only 1 sec.
Yeah, that's what I mean really, just expire "immediately" accounting for clock drift.
then there is a high possibility for it to get expired when relay process it. we can use a expiration of 10 secs for example or one minute. isn't that do the work?
expire: 0, i don’t want to store it
well this one needs to be defined in the spec.
Yeah it would be a way to make any event ephemeral
seems fun and useful for this kind of situation.
Unless we want expiring ephemeral events for some reason… then i guess you could just use an ephemeral kind
yes. we can define how someone should interpret the expiration on an ephemeral kind.