No reason. It's basically the same thing as event lookups.
Discussion
I'm game. Just need to get my account sorted with GitHub. It was flagged, likely due to signing up with an email alias instead of my actual email... Then figure out how to add a PR. 😂
nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhkcmmrdd3x77pwve5kzar2v9nzucm0d5hsh2c3z4 would know.. he was pushing for its removal from strfry.. i assume its harder to code.
Please, nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6, come tell us why we're out of our minds!
It's just unnecessary complexity. REQ filters are already too powerful, they should be simpler. The use cases are marginal and never important, often just "cool". They can all be implemented using custom relays with crazy logic, which is what we should be doing anyway for many other things.
Technically can't find an event even if you have the full ID anyway, because you don't know the relays the event is in. That's why we have nevent1 codes and relay and author hints in tags.
Choosing the relays for each client action is the most important part of Nostr but people have assumed that part away way too many times by hardcoding popular relays and expecting all events to be there, which works as long as we're ridiculously small, but kills the value proposition of Nostr entirely.
It's like assuming Bitcoin will always be zero: it's only true if the entire project is a failure, and in that case nothing matters anyway.
That was a major part of the reason I made the suggestion regarding partial pubkey queries. If you can query for a user's 10002 with just the first 6 characters of their pubkey, you can find their outbox relays where the event is likely stored, since 10002 events are intended to be shared far and wide.
That said, this could indeed be done with a custom relay. One that pulls in 10002 events from all known relays and allows for a query of just the first several characters of a pubkey. There is no need expect all relays to have this behavior. From there the client will have the relays it can expect to find the event, and relays DO currently support partial event ID queries, right nostr:npub1arkn0xxxll4llgy9qxkrncn3vc4l69s0dz8ef3zadykcwe7ax3dqrrh43w?
Not all relay implementations support partial id queries
I think it would be worthwhile to PR existing relay implementations. But if that fails, a custom relay implementation expressly for this purpose would be a great idea
I didn't mean custom implementation for this purpose, I think you can probably do better with a custom relay implementation.
I mean, if it's already custom you can assign a serial number to each event and map those numbers to real events in a custom database. Then convert those numbers into single or double-word mnemonics for users.
Or is that boring, doesn't contain cryptographic tricks, centralized? Maybe it is, but I think boring is good and centralized is fine as long as it plugs into the rest of the Nostr ecosystem.
Nothing else I know of can do this at a protocol level. It's like a compression cheat code. I think we should take advantage of it
the only thing I can think of is that there is an ambiguity, where for example 66675 could be the start of a pubkey, the end of a pubkey or the middle. to me the idea of partial searches is a good one regardless.
implementation wise, it does add some complication depending on the database engine the relay you're writing uses, but not that much.
I think it would be reasonable to limit these queries to prefix only. No searching the middle of a string for a partial hex value.