Oh boy, I swear I didn’t think it through or even planned for it at all. But seeing some major relays die, I felt that I had to step up at least for our paying customers 🚀🚀🚀 (Pre-release but can be used today) image

Replies (32)

So cool— did not know that we are having relay issues but I certainly was— paid for Primal and then Nostr.wine when nothing worked on primal but now that relay does not work either…. So will try yours!
This is written in TS and with my general idea about the architecture. I did see and read nosflare code in the past, and I am aware of its adventures through architecture changes and different approaches. I would consider this to be inspired by nosflare for sure, but not based on it.
Yes, Nosflare also written in TS 😉 You guys have a falling out with Nostr.land or something? btw, if it is entirely DO based, get ready for a very expensive relay. I’ve been down this road already with an entirely DO-only architecture and it didn’t end well. Now, it’s just using DOs for handling websocket and broadcasting the events to subscriptions. Not only that, but the cold starts of DOs can be problematic when they’re evicted and then hit with a SQLite or KV query. The current iteration of Nosflare is the best it could get imo. But would be curious to see what direction yours went.
I’ve been working with DOs for a long time and am aware of their pros and cons for sure. While what you say is true, there are ways to work with them cost-effectively and fast. You just need to look at them as shards for storage, nothing more. Eventually I’ll open source it once I tune the thing to scale and work properly, didn’t have much time to do that yet plus need to cleanup the code too.
I read it, yes. NL: no, we didn’t have any issues with them, all good and still part of our plan offering for higher tiers. This relay is for all, not only higher tier customers
But how does that work with web sockets? Don’t relays require a persistent connection?