End to end encryption

Even having the option of opting-in EE2E for specific objects would make Capacities viable for me across my workflow. Right now, it’s an app with nice features that I can’t really use because I need to be able to secure some data. I don’t need it for everything, but the things I need it for I really, really need it.

Just like team-collaboration, this feature is a must-have!

if I had to select a single most valuable feature I’d like to see, it would be this. As others have said in this thread, I understand the implications of E2EE but why not make it opt-in then and let users decide whether they’re ready to give up integrations and w/e else to get full E2EE? I’d do that without thinking because for me Capacities is my primary PKM and the knowledge I hold there is much more valuable than some integrations that save me like 30 seconds a few times a month (in my case). You’ve already laid a good foundation for potential E2EE by making a lot of features work locally so they can run against decrypted data. I don’t think making queries local will take much computational power as well considering the SQLite db implementation and the fact that it’s stored unencrypted on disc as of now

Adding my voice to this request – even after seeing it's been declined

I want to push back gently on the reasoning for declining E2EE here, because I think the trade-off is being framed the wrong way around.

The argument seems to be: E2EE would block features like the WhatsApp integration, AI assistants, server-side automations, and so on. That's technically correct. But it treats those features as the baseline and encryption as the cost. For a knowledge tool that holds personal notes, client work, research, half-finished ideas, contacts and meeting minutes, it's the other way around. Confidentiality is the baseline. Everything else is the cost.

I love what Capacities does on the modelling side. The object types, properties, relations and the overall structure match how I think better than anything else I've tried, Notion and Obsidian included. The fact that you're a German company with EU hosting and a transparent data protection memo makes it even more frustrating to walk away. I really wanted this to be my tool.

But I cannot put sensitive content into a cloud where the provider can technically decrypt it, no matter how well-meaning the provider is. The threat model isn't "Capacities is malicious" – it's subpoenas, breaches, future ownership changes, insider mistakes, and the simple principle that data nobody can read is data nobody can leak.

On the feature side: a WhatsApp integration is convenient, but it isn't differentiating. AI features are everywhere now, in every editor, every browser, every OS. "Just another AI feature" is genuinely how it reads from the outside in 2026. None of these are reasons to keep the architecture open-by-design.

What would actually be differentiating is a structured, object-based knowledge tool with proper zero-knowledge E2EE. That space is barely occupied. Anytype is the closest, but its modelling and polish are nowhere near where Capacities already is. You could own this niche.

A pragmatic path forward, if a full architecture change is off the table: an opt-in E2EE mode per space, where the user accepts that AI, integrations and server-side features are disabled for that space. Users who need those features keep them. Users who need confidentiality get it. The two camps coexist instead of one being told no.

If E2EE ever lands, even as an opt-in, I'll be the first one back. Until then I'm reluctantly moving on, and I suspect I'm not the only one in this thread who feels the same.

Given the state of Cyber threats these days you really need to rethink this option. It's common with the competing tools and not offering it is a deal breaker with many potential users.

I appreciate the transparency in explaining why Capacities hasn't implemented end-to-end encryption, and I want to engage with those reasons honestly rather than dismissively. But I think some of the arguments deserve pushback, and I'm in a somewhat unique position to offer it.

I'm currently a Reflect user who is trying to move to Capacities. Reflect is end-to-end encrypted, has a native Readwise integration, syncs with Google Calendar and Outlook, and has AI features built on top of all of it. I use all of these things. They work. So when the statement claims that E2EE is fundamentally incompatible with integrations like Readwise, or with AI features, or with a useful API, I can say from direct experience that this isn't a technical reality. It's a choice. Reflect has figured it out, and I live in that app every day.

The reason I'm looking to move isn't because Reflect fails on any of those fronts. It's because the founder's vision for the app is strictly note-based, and it doesn't offer the object-type capabilities that Capacities does. That's a product philosophy decision, not a technical limitation, and I respect it, even if it creates friction for me. But it also means I'm arriving at Capacities having already demonstrated, with my own workflow, that E2EE and a full integration ecosystem aren't mutually exclusive.

What makes this particularly important isn't just a general preference for privacy. A PKM tool is, by design, one of the most intimate digital spaces a person can have. It's where you store everything: your half-formed ideas, your personal notes, your research, your mental models, the fragments of thought you haven't shared with anyone yet. The whole point is to collect everything, and that's precisely what makes the security stakes so high. If a service provider can read that data, whether through a data breach, an internal access event, or a government compulsion, then the user has never truly owned their second brain. They've just been renting space in someone else's.

The traditional model of encryption in transit and at rest does provide real protection, but it has a fundamental vulnerability: the service provider can still access your data. If the backend of an application can read your notes, that access point becomes a potential vector for unauthorized parties, including hackers, government officials, or internal actors, to exploit. For a general-purpose SaaS tool, that trade-off might be acceptable. For a tool explicitly designed to capture the full scope of a person's thinking, it isn't.

The partial E2EE concept, encrypting the content section of specific objects, is a promising step, and it shows the team understands the problem. But the framing of the broader statement leans a little too heavily on "it's complicated" when other products in the same space are already doing the hard work. The complexity is real. The trade-offs are real. But so is the expectation that a tool asking to be the home for everything you think and know should protect that data from every entity you haven't explicitly authorized to see it.

While you are making significant efforts to prevent unauthorised access to user data, it cannot be ruled out entirely:

• Although the discs may be encrypted, data needs to be decrypted for authorised access. This may allow cyber criminals to get the data, even though that would require significant efforts. PKM data would be very valuable, warranting extra effort to get it.
• Your company or that owning the servers could come under US ownership and thus the CLOUD act at some point in the future, e.g. Meta may buy your company. You may then be obliged to hand over unencrypted user data to law enforcement or intelligence agencies upon request and may not even be allowed to inform anyone about that.
• The EU may change its stance on data protection in the future, e.g. to ease the use of available data for AI training or research purposes or to prioritise law enforcement access over privacy. The fights against terrorism, organised crime, money laundering, hate speech, or child abuse are classical reasons (pretexts) to limit privacy rights. The GDPR may be modified, so the protection it offers today may not be maintained indefinitely in the future. Laws and regulations can change, and so may your obligations with regard to user data on your systems.

Therefore, there are many groups that cannot currently use Capacities for professional purposes:

• People with obligation of professional secrecy, e.g. lawyers, clergymen, physicians, psychologists.
• Journalists and investigators who need to protect their sources.
• Freelancers or service providers, basically anyone bound by a non-disclosure agreement.
• Government agencies and ministries.
• Academic researchers working on subjects that may lead to patents or involve third-party funding or intellectual property.
• Companies (including yours!) that need to protect their intellectual property and business secrets from competitors.

While the absence of encryption allows some interesting features (and some that are not really adding much value, like the ability to WhatsApp or e-mail something to Capacities; there is not much benefit over simply opening the Capacities app), it excludes a wide array of potential users. These users would also not want to use an external AI to work with their data. If they require AI support on the Capacities data, it would have to be on (their) site. Because of that I'd strongly recommend that you implement E2EE.

E2EE could be an option that those users who need it (see above) can activate. However, preferably it should be on by default with the option to de-activate it, if the user wants to use specific features that are not compatible with E2EE. This would give the user the ability to balance privacy risk level against the value of specific features, based on their preferences.

Full End To End Encryption is unlikely with our current thinking. You can read more about this here.

We have ideas on enabling partial end-to-end encryption such as allowing you to encrypt the content section of specific objects. It would then be excluded from search and other features, but you could store sensitive information there. You can vote on that request here.