I’m only using NIP-42 on filter which is only for paid subscribers so I don’t really see why I need to differentiate… AUTH on connect is a much easier flow than AUTH after receiving a specific REQ and then counting on the client to handle it correctly.
I lobbied for an auth header because auth on connect is dumb too.
Filter doesn’t work with blastr today because you have to either auth or use the paid users /npub path (and the event pubkey must match) so I don’t really know what new problem this would cause for you?
For these specialized implementations we essentially store state about the connection to do user specific functions. Knowing “who” the connection is with, is integral for initializing that state and maintaining it. Essentially allowing us to drop the pubkey from the url and also support a lot more sophisticated user level configurations. What we do with the events you send, could depend specifically on the user configuration for the paid user who is connecting. There is nothing really natively preventing (rightfully so) a connection from being opened and valid and signed events that aren’t associated with the connected party being sent through that tunnel. So who signed the event and who is trying to use this service aren’t necessarily the same.
