tcheeric / nostr-java

A nostr library, written in java, for generating, signing and publishing events.
MIT License
71 stars 23 forks source link

genericTagQueryList does not correctly serialize #144

Closed kuiperanon closed 7 months ago

kuiperanon commented 7 months ago
        String new_geohash = "2vgddg";
        List<String> geohashList = new ArrayList<String>();
        geohashList.add(new_geohash);
        genericTagQuery.setValue(geohashList);
        Filters filters = NIP01.createFilters(null, null, null, null, null, null, null, null, new GenericTagQueryList(genericTagQuery));

If you send this, then the sent serialized REQ string looks like this:

INFO: Sending serialized message: ["REQ","de3daa94-ff45-496f-b1a4-13d6ba50abe6",{"genericTagQueryList":[{"nip":1,"#g":["2vghde"]}]}]

When it should be more like:

INFO: Sending serialized message: ["REQ","de3daa94-ff45-496f-b1a4-13d6ba50abe6","#g":["2vghde"]}]}]
kuiperanon commented 7 months ago

@tcheeric I added the @JsonUnwrapped annotation to genericTagQueryList, but that hasn't changed the behavior, I don't know why.

https://fasterxml.github.io/jackson-annotations/javadoc/2.8/com/fasterxml/jackson/annotation/JsonUnwrapped.html

It seems like it's exactly what I want. But it's not working.

tcheeric commented 7 months ago

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>

tcheeric commented 7 months ago

I think you are referring to the serialiser, right? Please confirm. (deserialising is not supported)

kuiperanon commented 7 months ago

I meant serialize.

tcheeric commented 7 months ago

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, GenericTagQuerys 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.