Might be too late for that. There has been an exodus of relay operators. The biggest cost is dev time, and we wont get many of those developers back. OpenSats can still do good, but the benefit would have been greater if they had acted earlier.
Discussion
It's not too late. Dev rotation is not good but it's also not the end of the world. Fresh ideas are helpful and virtually all devs in Nostr right now have a better understanding of the needs than what we had back in 2022/2023.
It really is. The relay dev landscape is dire. We're going the way of email with a few big providers. But that's OK. Primal is great, damus is great, and so on. I appreciate your attempts to turn the tanker, as I have tired to do, vut the relay part of the project is ded, w/o practical path to revival. I wish you very good luck and thanks for trying, I very much hope Im wrong and you're right!
We need to better optimize the relay implementations so they're as lightweight as possible. Some requesting relay operators to use a minimum of 4 vCPU and 8GB RAM VPS because Postgres is a chonker, might restrict someone wanting to contribute a free relay if the costs are too high.
Yes, but still doesnt change the fact that most of the relay operators that were willing to put in the effort have now left, and are not coming back. Retention is hard work, and it was needed 1-2 years ago. Something is always better than nothing, but the timing is also important.
How does a tiny relay hosted on a server no one knows about helps nostr? Is this outbox model here with us in this room?
Depending upon how you've set it up, my client could still send the tiny relay a REQ to retrieve notes, adding to the redundancy of the network.
Ok, lets imagine I’ve setup such a relay. How do you get its address? Why would you add it to your client? If no one sends EVENT, your REQ will always be empty, does it increase redundancy in this way?