I like KeePassXC because it’s written in C and is thus cross platform, while KeePass is written in C# and relies on Windows UI libraries. You can run KeePass on Linux (and I did without usability issue for years) but it will look god awful.
I won’t knock plugins, everyone has weird use cases, but I don’t know what people need KeePass to do that it doesn’t already do out of the box. I’ve certainly never felt the need for any.
Too many experts who value the deeper teaching potential angle seem to never want to acknowledge the bounce rate it will also have.
No, not everyone asking about how to get into the Linux ecosystem is doing so specifically because the knowledge itself is its own reward. Those who are will tighten their belts, whiten their knuckles, and figure it out just like you hoped they would. Those who aren’t will collapse under the sheer weight of all the bullshit and bail out. Frankly I’d consider the bulk of curious new users to be the latter and I default assume it for everyone who appears unless they indicate otherwise.
Some people think this kind of filtering based on willingness to learn is a good and healthy thing. I call it elitism and gatekeeping.
It stops bot FARMS from being feasible.
If preventing Jimmy Bumfuck from spinning up a couple sock puppets is your fear, yeah, PoW systems don’t help. But those are rarely the problem.
For a phishing scam or astroturf operation to be worth it, you need tens of thousands of accounts all running the same script. Those get filtered hard by PoW systems.
Phone validation works just as well, and stops Jimmy Bumfuck from making sock accounts. But now every user must be stapled to a phone number. Maybe that’s a worthwhile trade to you, but it sure doesn’t seem to be to everyone replying to you.
Provided that your key store password can be made very strong, all the risk posed by having all your eggs in that one basket are, speaking from the perspective of an average computer illiterate user like my mom, far outweighed by avoiding the inevitable alternative of one password (or a family of derivative passwords) used across all services.
One extremely good lock is a step up from two dozen shitty ones if it’s a cascade failure either way.
My thoughts exactly when reading this.
I believe people when they claim to develop free software. Often because it’s software the dev wants for themselves anyway and they’ve merely elected to share it rather than sell it. The only major cost is time to develop, which is “paid” for by the creation of the product itself.
You (OP) are proposing a service. Services have ongoing fees to run and maintain, and the value they create goes to your users, not you. These are by definition cost centers. You will need a stable source of funding to run this. That does not in any way mix with “free”. Not unless you’re some gajillionaire who pivoted to philanthropy after a life of robber baroning, or you’re relying on a fickle stream of donations and grants.
You indicate in other comments you will not open the source of your backend because you don’t want it scooped from you and stealing your future revenue. That’s fine, but what revenue? I thought this was free? What’s your business model?
It sounds like what you want to do here is have a free tier anyone can use, supported by a paid tier that offers extended features. That’s fine, I guess. But if you want to “compete with DuckDuckGo”, you are going to need to generate enough revenue to support the volume of freeloaders that DDG does. If your paid tier base doesn’t cover the bill, you will need to start finding new and exciting ways to passively monetize those non-revenue-generating users. That usually means one or more of taking features away and putting them behind the paywall to drive more subscriptions, increasingly invasive ads on the platform, or data-harvesting dark patterns.
Essentially what I’m saying here is, as-proposed, the eventual failure and/or enshittification of your service seems inevitable. Which makes it no better than DDG long term.
It is, at any rate, a very intriguing project.