Nostr Web Client

Now that grain 0.4.1 is released, should I switch gears back to nostr hero? Or should I add blossom to grain, so that it's a relay and a blossom server?

ChipTuner 5mo ago

Depends on your target audience. If you want the average pleb to be able to install an all-in-one tool sure. From the commercial perspective, I think apps are far more sell-able if they are independent. You can always put together an application later that combines the two.

For example. I develop a massive scratch-built cross-platform framework for .NET and C. I has some applications part of the core mono-repo. I build multiple applications on top of the core framework and the reference apps inside core. That means commercial entities can easily choose what components they want AND plebs can pull pre-packaged, self-contained applications.

Reply to this note

Please Login to reply.

Discussion

OceanSlim 5mo ago

Everything is all tied together in some sense. I don't really have an audience 😂 I mostly build stuff for myself and hope others can use it to help themselves too. Cool though is the front end is just a www folder with js and html and could theoretically be swapped to build your own front end with grain.

ChipTuner 5mo ago

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.

OceanSlim 5mo ago

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.

ChipTuner 5mo ago

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.

OceanSlim 5mo ago

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.

ChipTuner 5mo ago

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?