There aren't very many healthy and supported relay options, so I think you have an opportunity to target a more commercial use-case if you decide to go that route.
Discussion
I need more testing before I can make something commercial. If I can get it onto the app stores like umbrel I can get a lot more actual instances running and get more people interested in the code base. I've had 2 contributions to grain and they were very small 1 line changes fixing a bug that's now been refactored anyways. The entire code base of grain is really all just me and the testing in production is all just me. Hard to spot all the problems alone. My logging system is uncovering a lot for me though. I'll also be writing more integration tests going forward.
Were talking about nostr, shipping on app stores isn't type of the commercial I'm referencing. I mean targeting markets like nostr:npub1s3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqd975wz. Where we/I'm interested in large scale deployments where sysadmin and scalability is prioritized. Targeting, or at least placing yourself in that target market.
As I write this I realize, there is a reason larger companies end up writing their own everything anyway, and that is some edge case that is required for their deployment. I obviously have my own reasons for not deploying Grain right now, mostly, which I admit, is because of my own biases as to what I want to see in a software product, especially around application security and stability.
But yeah all you can do is write more tests and ship it imo. IMO keeping yourself on a CD release schedule allows you to be flexible when bugs come in as people adopt Grain and give your self the agility to get patches out regularly. Bugs are going to happen, imo it's regression that's killer.
What would you like to see most in grain then. What are your reasons for not deploying?
I wasn't referring to the app stores as commercial. I just meant it'll definitely create more users and unsurface more bugs.
I think the biggest reason, is that
- we don't have anyone that is familiar enough with mongodb to admin it without issues
- mongodb licensing is a bit uncomfortable, while from what I've read using mongo isn't really an issue, but apparently running it as a service might require a comercial license for us
The rest are more like questions
- I assume it's scalable base on a backing database, but is it somewhat tested for usage in a scaled deployment? Assuming mongo supports clutering and Grain is stateless?
- Is logging easily parseible and uniform? Like journald could capture it easily and I could use something like vector to capture and transform it?
- Is state easily shared either by database or with a small number of files?
- Would you consider implementing either docker secret store, secret files, or HCP vault integration for passwords/connection strings?