@npub19hg...yv9p For NWC implementations, do you recommend any specific relay implementation, or, more specifically, any particular settings or configuration with the relay? We're using #nostream for our NWC-only relay, and it does work, but also we're fighting an issue where our application loses contact with the relay, typically after 24+ hours up of uptime. (Note: I have no evidence that this is nostream's fault, could very well be something wrong we are doing on our end.)
When our app loses connection with the relay, we stop getting events from the relay, but can easily restore it just by restarting our relay-listening-script.... but we need to find a better solution.
At first our issues with #nostream were easily explained by various rate-limiting stuff that #nostream has in its default conf... but even after working through those issues, we're finding that it's hard to keep up a solid websocket connection with our relay for multiple days at a time. Seems like NIP-47
@npub19hg...yv9p is maybe unusual because it requires a SERVER to have a LONG-LIVED connection with a relay... whereas typically relays are designed to talk to clients who probably won't be subscribing for more than a few hours at a time?
The problem is very likely in our code, we're using a lot of Ruby nostr stuff
https://github.com/wilsonsilva/nostr -- and I think Ruby is just not great for long-lived event-based websocket stuff. So we're thinking of building a nodejs layer that intermediates between our Ruby app and the relay....... .. but in general, are most NWC server-side implementations using a particular relay implementation or settings?