This is good feedback, for a few years ago, and even for now. You should try it again, you will see I have made gradual progress with no funding over these years. Part of my recent proposal was to uplift completely what I've done so far into a new code harness, android native app and vision. I agree, UI is not my strong suit, but functionality, stability and usability is. Much like many open source projects, if they get actually used, then the UI becomes what they're used to. Since no other relay management exists, that's why relay-tools is still pretty much the leader here on UI (because we've tested for years, against REAL use cases in the wild, and real users that have real needs). Design and wizard, updated, and entire feedback loops completed. (I am not a designer and no designers from opensats or otherwise would help me, they would only give me some figma jpegs and then toss me into the wind). With AI I can accomplish much more faster. @Bohemia made an awesome relay explainer video here documenting how we see relay UIs working in the wild, and what they can do: As you are aware, relay UIs are not easy to make, nor is provisioning and managing them. Your paused relay, will always accumulate balance, but it will never go into someone else's hands (eg, it cannot be camped). I serve tons of traffic for long dead relays, and to activate them, requires the balance to top up. I did try to partner with you, but you immediately went off into an area you knew I could not support (non-strfry, untested relay software that requires me holding private keys and much QA with a maintainer that is not available nor cares). I was willing to explore this possibility but you would not even implement NIP86 relay management for moderation and were hell-bent on nip29 only. I tried to meet you half-way here, but the reality is, nip29 was de-prioritized for many reasons, not just those I mentioned here. You may find that running relays, there are a lot of operational costs involved. Many days, of debugging and support, education and non-coding tasks. I am spread thin. Custom domain names: Yeah I will not support this on my own relay hub for nostr1.com, you can run the software yourself on your own domain (if you do support this in caraval, you will find out why this is hard). Multiple Implementations of relays: Yes, I want to support this so badly, and will do so, and included this in my opensats proposal, but, see above about QA and operational cost for now I am left to fend for myself and my customers, I have to be ruthless about priorities. This is awesome feedback tho man, I appreciate it. A well-rounded take of what my failings are and have been. The cool thing is I still spend lots of time moving forward, but to the outside world it will look extremely slow. I have an entire native android app now, and that is the new flagship UI. I am tired of getting dicked around by client devs, so I was required to write my own clients as well. This is probably similar to what you felt, but about relays. If there were no grants involved, that probably would have forced us to partner earlier. But with everyone doing whatever they want, well, this is my point is that it's not really working well for nostr as a whole. I am happy to have pioneered this far.. Remember, I have been off grant since October 2024. Yet, progress still is being made and I am proud of it. I am sorry you have to take the brunt of some of this Opensats feedback, I had no idea that you are/were on the advisory committee (and zero clue who else), and you putting yourself out there, yeah that's gonna be rough :) Cause I coulda probably used this back and forth, years ago.