Fair concern. We have at-rest encryption on our roadmap and our goal is build a profitable business, so maybe we'll earn your trust later on as we iterate.
I'm not the OP, but you should know that for security-conscience people the idea of earning trust does not exist. I should never have to trust you, your web dev, your software engineer, your CTO, your devops guy, your cloud provider, your cleaning staff, and your interns. Rather, provide to me a service that is secure even assuming that the aforementioned entities are compromised, then you'll earn my business and my money.
Yeah, I can understand that perspective, but it does require some trade-offs on the product side.
Given that we're targeting technical teams using Slack, we focused on productivity features and usability first, but our roadmap is open to change based on user feedback :)
i'm not sure whether you understood the term "at-rest", all that would imply is that the data disk (or perhaps the database) is fully encrypted, but the server holds the decryption key at runtime. that would add no security because anyone who hacked into the application server will still be able to dump + decrypt all the notes, all they have to do is also dump the key from the running server. what you need is end-to-end encryption, so the server only receives the encrypted notes from the client.
Fwiw, I don't think end-to-end encryption would be a great default for our product since it would handicap a bunch of features (like server-side search), but it could be an opt-in feature for specific notes. We do take security seriously and the plan is to do more in the future.