search

nbd-wtf / go-nostr

Nostr library for Golang
MIT License
364 stars 102 forks source link

Potentially malformed EOSE messages can't be parsed #110

Closed boreq closed 11 months ago

boreq commented 11 months ago

Today I found out that wss://relay.noswhere.com replies with the following EOSE messages:

["EOSE","01HF733A3WE8PDSY39FP5AZ206",{"debug":["filters: not planned (non-search queries)","no applicable filters"]}]

The returned array contains an extra element which specifies the reason behind this EOSE message. This causes the ParseMessage function to return nil as EOSEEnvelope.UnmarshalJSON returns an error. The question is: should we do something about this and change the code so that this message is correctly parsed?

In my opinion the situation is unclear because I'd view this as violating NIP-01 which is something I don't want to encourage.

fiatjaf commented 11 months ago

I agree we shouldn't encourage these violations and support these extra fields as they threaten to become a new standard on their own.

In this case, however, I'm thinking that it wouldn't hurt to just ignore all extra fields aside from the first 2 and I'd say the good thing of having these arrays is that you can shove stuff on them after the first mandatory fields and no one should care. Maybe we should do that for all envelopes.

But I am now questioning my sanity and if this is really not harmful.

fiatjaf commented 11 months ago

Let me ask Semisol why isn't he using a NOTICE. That would have been more idiomatic.

fiatjaf commented 11 months ago

I've changed EOSE and NOTICE to not break when an array of more than 2 elements is passed.