nostr-protocol
add prefix matching filters to NIP-13
prefix matching was removed from NIP-01 a long time ago and that makes a lot of sense because it is awkward/difficult to implement and has limited, if any, relevance for most cases.
This PR adds prefix matching into NIP-13, using the same text that used to be in NIP-01, only slightly reworded.
Rationale: There is no way to filter against NIP-13 events
Impact on relays: None, not a single relay flags support for NIP-13.
Impact on clients: None, no client details have been changed in this PR.
ship it
I think we should just bring prefix matching back entirely as a new NIP that relays can flag support for.
agree with @staab
a new NIP just for prefix search that at least specialized relays can opt-in to support is probably the best approach for bringing this back. I really wish we had this option in our toolkit to properly enable POW use cases.
@staab @eskema Prefix filters are well suited for NIP-13. There is nothing stopping relays from flagging NIP-13 support.
Another NIP only makes sense if there is a use case that is not PoW related that can make use of prefixes.
Does anyone have an example for why you would want to filter against an author or id prefix for any purpose other than PoW related activities?
Reminder: The text in this PR is a slightly modified version of what used to be in NIP-01; the only actual, non-theoretical case that was affected by the removal was NIP-13.
after a bit more consideration, prefix search of ids and authors is tightly coupled with NIP13 and NIP13 is severely crippled without it, so it makes sense to add it here as there's really no other use case for it other than pow
maybe add a part about NIP11 flag for NIP13 to indicate relay support?
If it makes everyone feel better I can remove authors from the modification since technically NIP-13 only mines note ids, that makes it purely NIP-13. Unless ofc someone can identify an actually use case that isn't related to PoW for filtering against id prefixes.
Why not just pass a new property for pow filters? In that way, you don't need to check if they relay accept prefixes or not.
Instead of
{
ids: ['000'],
kinds: [1],
limit: 100
}
Which will return nothing in all relays that don't support prefixes, leave the main filter alone but add a property:
{
pow: 24,
kinds: [1],
limit: 100
}
All relays will just ignore the pow property and reply with all events. NIP-13 supporting relays will parse pow and only return those events. This also means that PoW should be pre-cached and indexed per event to avoid startsWith queries that are extremely slow.
The prefix approach needs to work with any prefix, not only PoW's 000.... Which means startsWith filters are required, and indexing becomes quite a hack.
@vitorpamplona ~Because that requires both de-serialization and a math operation, filtering against a string does not.~ I suppose the relay could derive the prefix from the pow and could match against the string.
Not opposed to it.
My primary reason for using ID prefixes was to reduce friction to being merged by using language that was almost identical to original language. But if this is the path of least resistance then lfg.
My primary reason for using ID prefixes was to reduce friction to being merged by using language that was almost identical to original language. But if this is the path of least resistance then lfg.
I don't know if this is the path of least resistance, but what I do know is that the old spec wasn't really well supported. So, bringing it back without addressing the reasons it wasn't supported is not that useful. I think prefixing was too generic and affected too many subsystems in Nostr without any major gains. If you are going to do this for PoW alone, you can specialize it to extract the most out of it. Hopefully, the gains from the chosen approach will outweigh the added complexity.
I like a dedicated filter better because what is does is give the relay developer freedom in how they implement it (in addition to already mentioned points). I'll update the PR.
@vitorpamplona Something we didn't think of is this:
Prefix matching against 000 for example is implicitly greater-than/equal to [>=]
whereas ['pow': n] is implicitly an equality check [=]
It starts to get messy on the api side if this is clarified.
#options
['pow':32] # >= by default, but not intuitive <- would be my pick if any.
['pow': '>=32'] # operand in string value, messy
['pow>=': 32] # operand in key, even messier
Still like the idea of a pow tag but something to consider.
I think any pow player will understand this property as the minimum pow for the filter.