To prevent IP leaks?
Discussion
no, because it’s 99.9% likely to get you a result and will take 5x less latency than all those steps
That's true. Would be faster.
The goal with Nostr.land is to eventually make the latency fast enough that the user can’t tell if it is a local cache relay or an NFDB relay.
Extended queries 🤔
What many people forget is adding layers and layers and layers and layers for “performance”.
By the time you get to asking relays that have it, you spent more time on other useless caches compared to waiting for relays.
Use NostrDB by nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s which is already optimized for client caches and can work multiprocess, and then ask every relay you think might have it.
Nah, his DB doesn't do what we need. We are local-first and we have plans.
What does it not do?
It's not a local relay or an HTTP API.
It would take you 5-10 minutes to build it yourself.
I already built it. 😂 That's why I'm interested.
Take NostrDB and build a relay wrapper around it. Not hard.
How about you do that, and I go build what I actually want?
Sure, you can, but I don’t understand why you are dismissing it immediately as not suitable because it lacks something that requires minimal effort to fix.
Though I like the idea of an in-browser cache relay… 🤔
Something that could be done after NFDB is done.
Because I already have an integrated relay with a Badger DB *and* a indexedDB cache.
I don't need 15 different local caches. I already have 3 🫠 and the fastest is just the normal cache.
What I am suggesting is an option for the non-indexedDB, local cache.
NostrDB does this much better as it has dedicated indexes for things like profiles, which relays had a note, etc.
I think it may have negentropy as well so you could be more efficient there.
We can offer either, in the installer, and let the user choose. 🤷🏻♀️ But this one is pretty cool, so it's staying.
Sorry, not sorry.
This stuff is all open-source, man, and the AIs are all stuffed with Everything Damus.