Two of your arguments (1 and 4) are only narrowly applicable (i.e. you should rephrase to "I would advise against it if your sole goal is a large mainstream gro

Two of your arguments (1 and 4) are only narrowly applicable (i.e. you should rephrase to "I would advise against it if your sole goal is a large mainstream growth"), but even in that context, priorities of mainstream consumers have shifted over the decades as a direct result of people developing/failing/retrying building such niche projects, & those projects slowly making their way into mainstream consciousness over time. So I'd never recommend against doing something because the audience is small today. As to your other two points: - your third bullet amounts to "don't do X because it is difficult" - your second bullet isn't really true. Zero trust can be trustless in theory, and every effort to make it so moves the dial closer to that ideal. It's entirely conceivable for "effective trustlessness" to be achievable for a decent range of threat models. Sending plainttext/passwords back to the server could be mitigated by a broad selection of approaches: moving the "reproducible / verifiable / signed builds" efforts of native apps into the browser. Components of this are already conceivable with service workers, and with enough demand browsers could easily improve support for related measures. TL;DR what's easy to do today security-/privacy-wise is easy purely because people continued to work on it when it seemed impossible / not worthwhile. Discouraging these efforts is really poor form. --- Additionally, worth mentioning that all of the above applies to SaaS, and for open-source self-hostable projects (not applicable here), the reasons to continue working on it are even stronger.