[samiur1204]

Nope, we haven't. Part of that is we are trying to help you save content from many places and be able to provide great search for you as well, which means we need to be able to index the content server side. We do encrypt the content server side, making the content inaccessible to anyone at Journal without explicitly accessing the decryption keys, for which we have an audit trail. Also makes it harder for someone to access your content if for some reason we got hacked.

[nwienert]

You don’t need to make it server side, but it certainly is easier. But client side is totally doable. You can compress word embeddings and search them with great accuracy.

[ramraj07]

I'm not sure how foolproof the encryption is if I can know every word you have typed in each note. Sure I can't make sense of the full structure but I'll know exactly what you've written about, so I'm not sure that's any more effective.

The way I see it, if you want your notes to be encrypted while also cloud synced and searchable, there are only two options I can think of:

1. Store your notes in an encrypted file (sqlite) on the cloud and sync the entire file locally every time you login (and push updates somehow). Roam does this but wirhout encryption and it sucks so bad (opening the site takes tens of seconds if not more) because of that.

2. The product promises to store everything encrypted; data is instantly written to an encrypted personal sqlite db on the cloud (you alone have the decryption key, it's not saved in the server). Much more seamless experience.

Im _also_ trying to create my own notes app, because I'm convinced I can create an app that can support a thousand users for the same cloud cost as a single roam research subscription. Current immediate plan is not to encrypt the notes, but my eventual plan is to try 2. If there are any other workflows that don't degrade user experience that can still encrypt everything client side, I'm interested to know more!

[The_Colonel]

> The product promises to store everything encrypted; data is instantly written to an encrypted personal sqlite db on the cloud (you alone have the decryption key, it's not saved in the server)

It's not really clear where does the encryption/decryption happen in this scenario (client/server).

Any way, in my app (https://github.com/zadam/trilium), I encrypt on the client (not the whole database, on a per-note basis), sync with the server already encrypted data when internet is available (fine granularity so small and fast sync) and search happens completely on the client (which has full offline database and decryption key).

As a self hosted app encryption protects against a bit different threats so encryption is done only on request for particular notes (since it implies annoying "enter password").

[samiur1204]

We actually do use this technique in our search (nearest neighbors on document embeddings). Collaboration is a big part of what we want to do as well, so client side encryption gets even hairier. It might be doable, but I think the effort to get that to work properly may not be the best use of time for a small company trying to build a valuable product first :).

[nwienert]

Sure, that is clear, just wanted to clarify for any future ambitious hackers it’s not a technical limitation.

[samiur1204]

Totally! Thanks for sharing and we'll keep it in mind for the future.

[mucholove]

Do you have a link to something that describes this technique in more detail?

[nwienert]

Look up tf-idf. We used this technique to build a similar product (now open sourced[0]) to Journal actually, building off an improved version of tf-idf called CoSaL[1].

Orbit is actually an insanely ambitious take on this problem space. The CoSaL algorithm is in there, it even runs using a forked version of Spotify’s C optimized algorithm.

[0] https://github.com/motion/orbit

[1] https://arxiv.org/abs/1803.08493