There are couple of millions of events today in entire nostr. Its around 10-20GB of data. Lets add the same for indexes. Any relational database on 64gb machine ($50-$500 a month) will give you microseconds today
Its
pubkey LIKE '%abc’
Instead of
pubkey = ‘full-64-char-long-author-pubkey’
According to NIP-01
(And of course searching by prefixes is more expensive)
I can see some implementations don’t support it and some act inconsistently
For example at nos.lol the dollowing works:
["REQ", "test", {"authors": ["000000000332c7831d9c5a99f183afc2813a6f69a16edda7f6fc0ed8110566e6"]}]
As well as
["REQ", "test", {"authors": ["000000000332c7831d9c5a99f183afc2813a6f69a1"]}]
But next
["REQ", "test", {"authors": ["000000000332c7831d9c5a99f183afc2813a6f6"]}]
Produces error:
["NOTICE","ERROR: bad req: uneven size input to from_hex"]
Pay per use is very difficult to manage for tech companies.
When you buy a car for example, you are fine to wait couple of months until its delivered to you. You are fine to wait for guarantee service in queues. You are fine to pay for a lot of things that are not covered by service guarantee.
When netflix doesn’t work for couple of hours you think they are bustards who do nothing but seat on top of gold piles.
I think you understand it well, but most of the (paying) clients don’t
Pay per use is what we should have more. And this is a simple concept. But as usual “its very difficult to make things simple”. So we should work towards finding solutions to make it work
Building a tool to check speed of relays. It sends complex queries and downloads several thousands of notes and reports the time it needed. It usually completes in a few seconds. So not much burden for relays!
If relay operators want I can include them in my tests and share the results. If relay operators don't want to be tested, also let me know.
For tests to work the relay has to be compatible with this library that I use (most are): https://github.com/holgern/pynostr
The relay should not have traffic shaping (throttling) active because it will make the communications slower.
Btw I thought my relays were fast, but they ranked 7th and 9th :(
Some client sent me REQ that filtered hundreds of authors by short prefix resulting into 180KB SQL generated, wasn’t it this tool?
21 million of events in general or kind-1 events?
https://github.com/viktorvsk/saltivka
Non-tech people could start with helping
Implementing Friendly Relay (https://saltivka.org). First by using it in their client, then testing, then improving documentation, making suggestions etc
And I wonder why eden.nostr is shutting down :)
I think so too but I didn’t find almost anything server-related in your list :)
Today Olga Kharlan (https://www.instagram.com/olgakharlan/?hl=en), Ukrianian fencer, won 15-7 against a rusian.
On the first video you can see how she refused to shake hands with a person who supports genocide and performs under a neutral flag.
rusian occupier decided to wait for 50 minutes alone waiting for Ukrainian winner to be disqualified. It indeed happened later.
It shows how rusian occupiers exploit every possibility in life to grab more regardless of circumstances.
In the second photo you can see how neutral she actually is. https://nostr.build/av/cd69573335f2c71d74046cdfec5c918670883fd1f3ea94acaf2e50de19ffe979.mov 
I looked through nostr.band and I can ser 2 “implementations” for NIP-50: page rank and spam filter
I was thinking on spam filter implementation but I dins straightforward solutions close to useless so I’m thinking about some complex methods instead for future
I thought to start with graphs first: saying that “if nobody follows author through X (3-7) handshakes then its a spam or something similar
Page rank is an interesting idea, will think about it
If interested, please see https://github.com/viktorvsk/saltivka/
Will be happy to answer any questions.
NIP-50 is not a top-10 priority for me right now but with some interest from others I would be glad to consider investing time into it
What keyword search do you mean? NIP-50 compliant relays strictly don’t have to implement any additional search functionalities except for “recognizing” existence of keyword “search”
For example if you want to search by some “risk of span rate” on a NIP-50 compliant relay, relay has to implement this custom search (thats not a part of any NIP)
I’m working on another relay implementation and I had thoughts to “support nip50” but did’t find any demand for specific search criterias yet
nostr:npub1qqqqqqyz0la2jjl752yv8h7wgs3v098mh9nztd4nr6gynaef6uqqt0n47mhello Cameri, I was curious if you have any plans to implement NIP-50 on Nostream. I look forward to hearing from you. #relays
What exactly do you mean by NIP-50? The spec itself only describes a new keyword in filters object.
Do you want this keyword so that you can implement your own queries on top of it?
Or do you have some specific queries in mind you would like relays to support?