mleku @mleku - 6mo
so i finally have figured out how i'm supposed to do this websocket listener/subscription thing already wrote most of it, just haven't plugged in the actual handlers to add the filters properly or when events arrive, to scan the events to find the sockets to fire them off to i think i might manage to get it working tomorrow it's all in the "listener.go" in relayer, which i remember being much similar in the khatru version except relayer doesn't use the fancy xsync maps my implementation also just uses a normal mutex, the different feature i'm adding is the filters get fingerprinted so if clients send them repeatedly the filter only has to be tested for matches once and then iterate the listeners to find the matching filter fingerprint for the websocket to send it to which i think is a bit more efficient when you scale it up and have to deal with dumbass clients that might send out the same stupid filter while it is already active, and even can deduplicate when multiple clients are watching for events from the same npub or whatever, it doesn't match on each of them, just the common one and then just iterate the subscribers list to send em it's not obvious at small scale but i'm well wary of how dumb clients can be will be a big smile on my face when the relay actually works with a client tho... right now it just passes all the relay tester tests that don't depend on subscriptions, so that will be first thing to get done #thoon
i also was thinking a lot about how there isn't a "canonical" sort ordering on filters... i'm gonna make one, first, so when a filter is the same but was constructed with different ordering it comes out the same
