61–70 of 112 posts
What is it about writing that makes it different than thinking?
I've worked on 2 "zero-knowledge" apps (basically meaning all data is encrypted/decrypted on the client) and I would advise against it: * most consumers have no idea what you're talking about / don't care * those who know what "zero trust" is, also know that it's not really trustless. You do have to trust the company that it will never send the password or plaintext data back to the server. Checking this on a continu…
While this is very well put, isn't this like saying "people could jump over the safety rail. So there is no point having it". Your logic that the app could deploy a "rogue update" so it has little merit would essentially say there is no point in mitigating anything because insert unlikely failure case . When saying it causes people to trust you less by raising the spectre I disagree. I would assume that a company foc…
I would agree that it's "safer", though, since client-side encryption indeed eliminates several ways how the confidentiality of your data could be compromised.
- This space is very crowded - to consider this app, I need to know a differentiator much sooner. Is it the streak? Is it the zero-knowledge? What makes this different from the 20 other options? It seems like the value prop here is "this is a simple journal that tracks whether you wrote today or not, and that is zero knowledge." If there's more, it's missing from the marketing here.
- There's some confusion in the branding. You're using the word "guru", as well as the word "jumble" as a verb. Pick a tagline and a CTA, and stick to those.
- I like the point you are trying to make about the value of writing itself... but how does your app take advantage of that value prop? Can I capture those insights in a unique way? Otherwise, I can take your value prop and accomplish it in the writing app I already have an account and history with.
I've worked on 2 "zero-knowledge" apps (basically meaning all data is encrypted/decrypted on the client) and I would advise against it: * most consumers have no idea what you're talking about / don't care * those who know what "zero trust" is, also know that it's not really trustless. You do have to trust the company that it will never send the password or plaintext data back to the server. Checking this on a continu…
> a rogue update can be pushed anytime
This is not an intrinsic property of a zero-trust system, but a consequence of a culture in which software is never finished.
I've been journaling for about 15 years now. The big key to getting consistent at it was to stop worrying about trying to write a lot, or trying to write something insightful, and just write a sentence or two at a minimum. Often, that turns into more or into something insightful.
I've worked on 2 "zero-knowledge" apps (basically meaning all data is encrypted/decrypted on the client) and I would advise against it: * most consumers have no idea what you're talking about / don't care * those who know what "zero trust" is, also know that it's not really trustless. You do have to trust the company that it will never send the password or plaintext data back to the server. Checking this on a continu…
These are great points. “Zero trust” is only really possible on FOSS self-hosted systems.
Open source and self hosting is a good start for the paranoid, but definitely not sufficient. As always it comes down to threat models and who/what you are trying to defend against.
I've worked on 2 "zero-knowledge" apps (basically meaning all data is encrypted/decrypted on the client) and I would advise against it: * most consumers have no idea what you're talking about / don't care * those who know what "zero trust" is, also know that it's not really trustless. You do have to trust the company that it will never send the password or plaintext data back to the server. Checking this on a continu…
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…
> Zero trust can be trustless in theory, and every effort to make it so moves the dial closer to that ideal.
I agree it can be done in theory, but I don't have a reason to believe the product as of today is truly trustless as it claims on the website.
I also believe that making something truly trustless is impractical for the vast majority of use cases. Reproducible/signed builds are indeed a step in the right direction, but not enough on its own. Each signed build would additionally have to be independently audited by a trusted 3rd party. It doesn't help that the build is signed, if the company itself inserted the password logger. And not having to trust the provider is the point of trustless, isn't it?
I've worked on 2 "zero-knowledge" apps (basically meaning all data is encrypted/decrypted on the client) and I would advise against it: * most consumers have no idea what you're talking about / don't care * those who know what "zero trust" is, also know that it's not really trustless. You do have to trust the company that it will never send the password or plaintext data back to the server. Checking this on a continu…
Your points are all sound, but I want to expand on this one: > a rogue update can be pushed anytime This is not an intrinsic property of a zero-trust system, but a consequence of a culture in which software is never finished.
> "A good writer doesn't just think, and then write down what they thought, as a sort of transcript. A good writer will almost always discover new things in the process of writing. And there is, as far as I know, no substitute for this kind of discovery." -Paul Graham What is it about writing that makes it different than thinking?