It is a relay, yes, however the output is a new event kind which depends on the inputs of the request.
Yes, the same can technically be achieved by abusing a REQ filter, buuut it's different enough from the normal use that I am okay in using a new thing.
Why would it be "abusing" the REQ?
What's the difference in terms of conditions that you can put on the request?
Both can have a price.
Both can ID the requester.
nip-01 protocol is a mess that literally mashes 3 query APIs into one, incoherently
fetch events by id
search events by filter
search events by content keyword search
it's three API methods that are not clearly separated and this confusion is very obvious at least between the "ids" field and the rest except the "search" field
can we combine SEARCH and FILTER together? maybe yes, but that's a separate logic, and it is actually doable with a small enough result set out of the filter before you do a full text contains search
the nip-01 protocol was not designed as a proper API, and we aren't going to progress this protocol's capabilities without adopting age old "API" semantics
Hehe, I think nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9 and nostr:npub176p7sup477k5738qhxx0hk2n0cty2k5je5uvalzvkvwmw4tltmeqw7vgup would agree on that last point, yes.
> nip-01 protocol is a mess that literally mashes 3 query APIs into one, incoherently
fetch events by id
search events by filter
search events by content keyword search
Yes, If I were to re-make nip-01, I would use these 3 APIs + a general request/response API (DVM like).
However, as much as I don't like messy things, I don't think this is a big deal.
yeah, you only say that because you don't care as much as i do about auth and the private/paid relay use case, which i see as the main avenue of funding for development
