nostr:npub1marcan0laywmjprf4m8d34dr8m724a6jxxa56a5wwygcgj23q7nskfwmfg and nostr:npub1vppdwqmhlzhftstq5exturmry4u0pdfm93mqj4zfuuznhclxygfsdatk8w You discussed in your "rails" episode the basic challenge of using rails with Nostr -- rails is just not really made "out of the box" for highly async use cases like Nostr. I have recently had two biggish projects where I has to integrate Rails with nostr -- https://rizful.com/docs/connecting-apps#nostr-wallet-connect-send-and-receive and https://docs.megalithic.me/lightning-services/nsfw-image-detection-for-nostr .... both required a lot of SERVER SIDE communication between Rails and Nostr relays.

I used quite a lot of this https://github.com/wilsonsilva/nostr -- but you'll notice there are a few serious issues -- for one thing, there's no explicit way to actually close a connection with a relay! ( https://github.com/wilsonsilva/nostr/issues/19 ) ....

So after trying a couple different architectures I have currently hit on these rules for server-side development with rails and nostr.

1) Never try to communicate with Nostr relays directly from rails

2) Instead, use a purpose-build "intermediary" application written in Node.js/Typescript... this could be built many different ways but in my case, I have this Node.js application listening to a queue, where it consumes requests from rails....

3) This intermediary application allows your rails application (using multiple threads with something like Puma or many concurrent background jobs) to be "conservative" in its usage of Websocket connections.... you can design this intermediary application so it "re-uses" existing connection to relays, to avoid overwhelming relays, and also, in some cases, to keep connections alive so you can have very low latency with relays -- i.e. not need to constantly connect and disconnect from them.

4) This is just what I have come up with, but I've noticed better latency and better reliability after switching to this strategy.

So Rails can still construct the events, and handle the business logic (Because, as you point out, NOTHING beats Rails + Ruby + Active Record for business logic!), but then it always hands off communication with relays to the intermediary app. (Also, rails will have to listen on a queue to read from the intermediary app, I am using Redis in some cases, RabbitMQ in other cases, and SQS in still other cases, I have found each of these has certain strengths and weaknesses....)