Question for the nostriches:
You are a nostr media enjoyer considering paying for a DVM/algo service. This service scans all media linked in notes for something you really don’t want to see.
How long would you wait for this service to screen an image for this one thing you don’t want to see on your feed? The image cannot be shown to you before the screening is complete.
1) competitive FPS gamer tens of milliseconds
2) 100-300 ms (blink of an eye)
3) 860 ms (one heartbeat)
4) ??
#asknostr
I wouldn’t wait to see what I don’t wanna see. Doesn’t make sense.
Say there are technological and performance constraints to this service.
Would you be ok with a one second “screening” time? Is that too slow?
I dunno … if you’re trading off filter accuracy for completion time … I don’t think there is a solution… different users will want differently.
The “implementation standard” that allows users to subscribe to such an algo SHOULD be able to accomodate “options” sent along with the query.
If a developer is concerned that their algo is loosing users cause it “takes too long” then they could simply provide an option to toggle for speedier results.
Thanks for this feedback, will refine the user story.
Let me re-ask the question: what if the fastest performance and result was no less than one (1) second - would you use this reverse DVM service in this case?
Yea. I’m not gonna budge. 💜 Build what you think is best… and iterate options in as it gets used. MHO
If I'm understanding the question correctly, I wouldn't want to wait at all 😅. Especially if I was paying for it, I would just expect no images like that to be in my feed and for me to not even press a "screen image" button
Yeah you got it. I didn’t write the prompt clearly enough.
What if I told you that due to tech constraints you would have to wait one second for each image to be screened (meaning images loading that dont have the thing you are screening for have one second lag times)?
I'm having a hard time thinking through a scenario like this because I would think the page might load with a cache of posts ready to go and have to load more in chunks. So, if a chunk of posts took a second longer to load, I probably wouldn't notice/care. But, if a chunk of posts took a second longer for every post in the chunk, that might be significant.
Love it. Looks like there’s a way to reduce the impact
nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn nostr:npub14f0xen78ed7rgvw39v82fwp7tv65yasz2gsgpf4gvxy4q5nlsydsk37k3l nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 nostr:npub1a7n2h5y3gt90y00mwrknhx74fyzzjqw25ehkscje58x9tfyhqd5snyvfnu what do yall think?
Realistically I think #2
But if you’re thinking of building such a “paid algo” service … I wanna know what you think of a NIP standard for subscribing to such an algo. How wd that work?
nostr:note1q2a2stds7ndxe9h9xz82u20szgur0yyp2gmdkz853dvdvl66stqsgj6awd
Will take a read.
My primitive understanding is that if DVMs can return something (e.g. text, or an image) DVMs can also return if an image contains a certain thing or not (e.g. a cat).
I would thus pay a DVM to screen all images and expect an answer if an image contains the thing or not.
Right. This same challenge will be encountered by clients and relays as well. All three architectures currently have active development in this space.
How to filter for desired content?
IMHO, framing this as a DVM challenge will only contribute to fractured solutions. So, there’s that.
And otherwise… honestly… if users have free choice and the tools to choose … let the market decide what works and what doesn’t.
So my answer is a question:
What wd we build if we were to let users subscribe to (and share) content filters, delivered by any vendor, and applicable across all clients?
