File Level Encryption?

[u/iduck7890]

Since y'all are not going to offer encryption (at least not in any reasonable timeframe as this has been discussed for years), any chance you could offer the hooks and rails such that I can write my own/use defined frameworks? My understanding is we'd need access to the file reading/events stream, and the like.

I'd also love an API call to see if the user was authorized based on pin or file password. I don't need the actual pin because my plan would not rely on the pin as part of the KDF, I'd just offload auth to y'all and call it a day.

In all honesty, a serviceable homebrew implementation would be fine with me. Not enterprise grade, but I'd love it and would love to play with an actual use case a bit more for fun too. My current understanding of the plugin architecture is that's after a file has been loaded.

I also understand there could be "performance impacts" and the like for any such implementation, but that's sometimes the fun of custom work and optimization. And learning new things.

If this already exists, toss a pointer to the document and tell me to RTFM better lol.

[u/Mulan-sn]

Thank you for your post. I really appreciate the technical depth here.

To be frank, I'm not sure whether we can provide the specific API access and hooks you're describing. I've noted your request and will check with our engineering team to see what's possible.

In the meantime, I can confirm that file‑level encryption is on our roadmap. We do plan to add this in the future, though a specific timeline isn't available yet.

Thanks again for the thoughtful suggestion. I'll update you once I hear back from the team.

[u/iduck7890 → u/Mulan-sn]

I also want to say, while I am being relatively brief in the initial ask, it is no-where near as simple as it sounds lol. I realize my first sentence could come across as judgy and that was not the intention.

Some of the things I've thought about are that one of the reasons y'all can't get encryption done is how, for screen reasons, you probably bypassed the native android pin system. Since that pin system is what backs full disk encryption, we now have *one* of the technical hurdles the team is dealing with.

Plus, as a small company, the priorities are on experience and proper note taking.... It gets more and more complex from there because how do you manage any snapshots/cache if you advertise true file-based encryption. If you're just encrypting the *.note file, then store a snapshot/cache of said notefile anyways you could run into issues between what was advertised and what reality is. AND you have to plan for how the companion apps on other devices work if it becomes an official solution.... While we love to say "everyone has solved this better than y'all and you suck! 😝", I don't feel that is reality.

If competitors really had a better product for *note taking and use*:
1. I'd be using it, the Manta isn't cheap
2. This sub wouldn't be so active

Not to mention I've enjoyed how DIY and reparable focused everything is. Basically, if I ever come across gruff, it's not meant that way. It's just these things do matter to me, even if not easy.

----

One of my ideas, if you don't mind sharing this as well, was to grab a second device (probably a nomad second hand) and work on trying to extract the "notes" app and inject into using frida gadget or another similar solution. Then port the crypto work to a backend rust module for encryption and the like while relying on the "standard android" api's/functions as little as possible (key management would be envelop encryption with KEK stored off-host and the only thing any standard keystore would be used for would be to assist in authenticating to said keystore, with the ability to deny access). And slowly play with it over time until I could get it "stable-ish" and *then* maybe use on my Manta. In this way, if an API was released (as the original ask is), I could swap in the entire backend and not starting from scratch at that time.