That's a slick interface, I like it a lot. The main reason I wouldn't use this implementation is that a lot of the policy is baked in, which might need to be configurable by the application. I have a bunch of policy stuff here: https://github.com/coracle-social/welshman/blob/net2/packages/net2/src/policy.ts which is mostly reasonable defaults, but if users wanted to configure auth policy per relay I don't see how that could be done in applesauce. Also, why no`subscribe` ?
nostr:npub1cesrkrcuelkxyhvupzm48e8hwn4005w0ya5jyvf9kh75mfegqx0q4kt37c nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn I did a little more work on my implementation and id like to get your feedback. Its still missing re-connection logic but personally I really excited with how it turned out
https://github.com/hzrd149/applesauce/tree/master/packages/relay
Discussion
My idea is that it could be built on top if the relay communication is flexible enough. most nostr libraries build the auth, limitations, and connection policies at the "new WebSocket()" level, but that makes it difficult to add additional types of behavior that a different client might want later
For example you could implement a relay blacklist at the websocket level so that it would throw an error (or make it look offline) if the client connected to a blacklisted relay. or you could extend that relay pool class to ensure it never even tries to connect to blacklisted relays. all of this is just a theory though, I still have to put it into practice to see if it works
