Closed kuiperanon closed 7 months ago
@tcheeric I added the @JsonUnwrapped
annotation to genericTagQueryList, but that hasn't changed the behavior, I don't know why.
It seems like it's exactly what I want. But it's not working.
I'll take a look -- Sent with Tuta; enjoy secure & ad-free emails: https://tuta.com
17 Apr 2024, 04:34 by @.***:
@tcheeric https://github.com/tcheeric> I added the > @JsonUnwrapped> annotation to genericTagQueryList, but that hasn't changed the behavior, I don't know why.
— Reply to this email directly, > view it on GitHub https://github.com/tcheeric/nostr-java/issues/144#issuecomment-2060282333> , or > unsubscribe https://github.com/notifications/unsubscribe-auth/ABQMG7DJG3X4LBS7V4SISI3Y5XUTVAVCNFSM6AAAAABGKGURKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRQGI4DEMZTGM> . You are receiving this because you were mentioned.> Message ID: > <tcheeric/nostr-java/issues/144/2060282333> @> github> .> com>
I think you are referring to the serialiser, right? Please confirm. (deserialising is not supported)
I meant serialize.
This made me realise a mistake in the implementation, due to a misinterpretation of the spec. NIP-01 defines Filters as follows:
{
"ids": <a list of event ids>,
"authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
"kinds": <a list of a kind numbers>,
"#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>,
"since": <an integer unix timestamp in seconds, events must be newer than this to pass>,
"until": <an integer unix timestamp in seconds, events must be older than this to pass>,
"limit": <maximum number of events relays SHOULD return in the initial query>
}
Filters do not accept GenericTagQueryLists
, as incorrectly assumed, but instead, GenericTagQuery
s
I have made the corrections in the Filters class, and adjusted the corresponding encoder and serializer.
More test cases are needed to ensure the current implementation is bullet-proof, but it looks promising.
I have pushed the changes in the branch feature/Issue_144
and will add more test cases tomorrow.
If you send this, then the sent serialized REQ string looks like this:
When it should be more like: