nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h From a system engineering pespective, if we can all agree on the data structure of Nostr events, why do we have to have the same API? For example, a GraphQL API over a relay can be much more expressive than current filters API. Does it really make things more complex? Not necessarily. Mainstream web systems are request/response oriented and streaming API is added later. Nostr is the other way around. It does not have request/response model for its events.
Discussion
Weird, I didn't get this in my notifications but did see it in my feed.. weird amethyst bug I dunno.
anyway, ya I just see nostr as the infinity protocol.. there's no reason you couldn't do anything. When you make UIs you either end up polling, or using a websocket anyway, so why not just start with the nostr socket? 乁༼☯‿☯✿༽ㄏ
The previous note is just my frastration of that "get event by id" is a stream. It makes no sense because events are immutable.
A relay either has or does not have an given event id.
It makes client's network code a bit longer. Not a big deal but still could be better.
Ah, ya ic
it is the connection protocol for everything, just that almost nobody realises this yet, except you, because you are awesome
i can definitely agree with that, the filters are pretty crappy
they are very cheap to implement though
i haven't thought very much about how i would do it better, to be honest, but all the optional fields is a mess for parsing... it was probably the biggest job in my rewrite of the JSON parsing for my relay (i completely wrote it myself, took me about 3 weeks, and it's way faster and more efficient than any json parsing library could ever be)