Random observation: pubkey prefix search on nostr never made sense. If I take a contact list with 2054 entries and do a common prefix reduction for the first 2 bytes it only knocks the query down to 1991, and in that you would get tons of false pubkey results.

https://cdn.jb55.com/s/782e264a2a3eb6a9.txt

Reply to this note

Please Login to reply.

Discussion

Seems like it would only be useful for random PoW authors 🤷‍♂️

Queries need to be more advanced

First 6 digits as a hex color is kinda fun tho

💯

Not sure if I understood correctly. Do you say that people use randomly looking numbers as their pub keys? Good for radix sort, balanced trees, hash tables I guess.

There is a feature in nostr queries defined in nip01 for sesrching on prefixes of ids/pubkeys instead of the entire id. The rationale was to make queries smaller but that doesn’t really make any sense as I showed above because it doesn’t really reduce the query size.

I guess the idea would be similar to git short hashes?