correct. When I started writing nostr.watch there were 6 public relays (there were quite a few more but they were experimental/not published)
It's two chars after all.
Does it exist: highlights only relay
nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr
no clue
is a very good question.
well if we really want to get down to the meat of the issue its an abundance of missing information from NIP-11.
If we added nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnhd9hx2tcewvzaw's relay categories to NIP-11, this would not be an issue, because relays could be properly organized and filtered based on purpose. People would not use them on their list simply because it would be obvious that it is of not benefit to them. Services like nostr.watch and more importantly, NIP-66 would optimize delivery based on these values.
the most common use of nostr.watch is finding online relays is to assist with relay lists and outbox model. The issue here has everything to do with a bad implementation, and little to do with nostr.watch. if you're not on nostr.watch and a spammer wants to spam, they'll still do without the API.
I had a full implementation of NIP-66 completed in NDK, but the PR being open for 5 months and maintaining a fork holding me back so I had to abandon it and have been working to create a toolkit agnostic full implementation. All my existing implementations right now are hardcoded. You can check that PR in NDK for implementation hints.
As a side note: I'm not aware of anyone who has done the ad-hoc implementation that leverages web-of-trust (`some.relay.xyz` was seen by `dan` 2 days ago) As for me ad-hoc reports will be the very last thing I implement. Would make sense that a social client would implement such a thing...
Waaaay more than Khatru. Here's the config for a good idea of the current capability. My objective is a highly configurable relay to cover a multitude of use cases. Uses mongodb but more databases are planned, way later...
https://github.com/0ceanSlim/grain/blob/main/app%2Fstatic%2Fexamples%2Fconfig.example.yml
Ah, ok, so much different. Khatru is more of a framework whereas this looks something closer to nostream where there are baked in policies you can configure. I like that there's fine grained control over resources. Can't wait to try it!
nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr does nostrudel have docs?
found something called "blindspot" and idk wtf half of these things do -
blindspot shows you notes you may have missed. Not sure about the inner workings, but I suspect it's popular notes from your extended networks' feeds.
Looks cool! Something like Khatru?
Cool! Have you considered running a monitor and publishing NP-66 events by chance? Also: 
When you start crawling relay lists to aggregate relays, you realize how all sorts of fucked up a lot of relay lists are.
Parsing all this and throwing out everything that's not a valid clearnet websocket server is a lot of crap to clean up. Getting closer though. Finding about 890 online clearnet relays.
https://tenor.com/view/rookie-numbers-gif-26135237
#crawlr
Yep... Welcome to the club. That number sounds right
I respect the no dependencies thing, but notemine on a single thread is almost 2x faster, maxing out threads it's `n` times faster.
