Replies (27)

There are probably a lot of reasons behind that. First, people aren't necessarily using the same relays they used a few years ago. I know I'm not. When they switch, they rarely export their notes from their old relays and import them to their new ones. Relays also don't necessarily keep notes for that long. Popular relays may have automatic deletion of old notes, or then theres the Damus relay, which gets fully nuked from time to time. If the note does still exist somewhere, it might be on a relay that is currently offline, or that the client is having trouble connecting to, or that doesn't support search, or that has rate-limited requests, or... You can see where this is going. So long as notes can live on various different relays that aren't all following exactly the same policies, it's going to be unpredictable whether you can find a specific note.
That is AWESOME. I'm sure searching is one of the least praised feature that takes some of the most work for this sort of system, just bast on my experience even doing joins on large CENTRALIZED datasets. You're a rockstar @Vitor Pamplona
I'm sure you're beyond me. I've usually just done bare manual SQL searching on a good size data lake and performance can really care about exactly how you do things. I do have a very little good abstract knowledge from the first few lectures of the old MIT 6.001 using the wizard book. GREAT comp sci intro. @Vitor Pamplona you know what the asymptotic growth is? I'd assume no matter what you're doing this has gotta be complex. The lecture on tree recursion comes to mind when enumerating Fibonacci numbers and the number of Nostr relays dizzies me..
The relays Amethyst can successfully connect to do factor in, though. It would be doing text search via your search relays. If the note isn't on the ones Amethyst was able to connect to, and is only on a search relay it could not connect to, then it won't find it.
It's complex but not that much... It just takes a few relays as inputs, downloads all events from them, collects all references to other relays and keeps growing the list of relays to check. Then it just dedupes by ID. Takes about 1hr to generate the report with about 2.5M events.
Unfortunately many Nostr relays index fediverse stuff, while fediverse doesn't give a fuck about Nostr. Very dumb imo
There are all sorts of reasons that a client may not be able to connect to a relay besides it just being down. I won't say that it couldn't be a client performance issue, but most of the time inconsistencies on Nostr in general are due to not being connected to the same relays for one reason or another. No one's fault. Just the nature of working with multiple relays rather than a centralized server.
Hmm probably is O(n) then. Guess no need to do any elaborate cross indexing. Of course, with all the zaps on comments on likes on zaps on commments on likes...it could still get silly.
I don't know about good ones. These are the current default search relays in Amethyst, which are the ones I have been using. image Don't mind the slow ping numbers. That's just because I have Tor turned on. The main thing is the relay needs to support NIP-50, and it should ideally be aggregating notes that you would be interested in. Unfortunately, finding relays on the basis of the NIPs they support isn't an easy task.