Top 2 missing features that could make you leave anytype

From my knowledge… this is Electron cache, and I do not know if there is anything that can be done with it.

If there is such care for it, one can

  1. add the switch --disable-http-cache to the command line.
    OR
  2. patch the electron.js file:
diff --git a/electron.js b/electron.js
index 9f58f11d70..9bc83da9f7 100644
--- a/electron.js
+++ b/electron.js
@@ -48,6 +48,7 @@ for (let i in Cors) {
 app.commandLine.appendSwitch('ignore-connections-limit', 'localhost, 127.0.0.1');
 app.commandLine.appendSwitch('gtk-version', '3');
 app.commandLine.appendSwitch('js-flags', '--max-old-space-size=4096');
+app.commandLine.appendSwitch('disable-http-cache');
 
 app.removeAsDefaultProtocolClient(protocol);
 

This disabled the Electron cache, so Cache subfolder in the anytype profile directory is no more!

I guess maybe a “Vault” flag could be made on settings page.

I’ve found the mobile apps more user-friendly than the Obsidian app I used until the end of 2023, primarily due to the simple and fast synchronization. I left Evernote in 2022 after they deactivated multiple tabs. The fact that this feature is now coming soon to AnyType is fantastic news. It will make working on mobile devices so much more efficient. Keep up the good work!

Hi Code-Jack! Can you please check out the docs: Privacy & Encryption | Anytype Docs .

Anytype team explicitly says that “We decrypt these encrypted objects on the fly with your keys, perform some logic and then save the results (i.e. indexes) locally. These indexes are not encrypted, but here we assume that only you have access to your local data, i.e. the access to your local computer is not compromised”. This was never something that Anytype hidden from the users etc and they always said about it.

Encryption of indexes requires a lot of effort to be done properly (because when you have sorted indexes, the encrypted data will have inherently different order, so then you will have to make data structures more complex to allow both encryption and sorting).

Therefore the encryption should be done on a level below (e.g. on a file system level), that’s why Anytypes recommends enabling disk encryption. On MacOs it is enabled by default I guess, on Windows you can use BitLocker or any other applicable software.

[I can’t post two different replies one by one, and I don’t want to wait]

Ok, then a couple of words from me as a long-time Anytype user and contributor (a small rant).

I’m seeing a lot of emotional posts lately — frustration about missing features, disagreeing with the direction, expectations around open source, etc. And honestly, I get it. If it were just up to me, I’d prefer Anytype to stay closer to a collaborative productivity tool with fewer features, very polished, and focused toward small-team collaboration. But that’s just my opinion — it’s not something that was promised to me.

That said, I think people are forgetting some basic facts. Anytype is still a free tool that lets you sync an unlimited amount of documents in real time. How many tools like that exist? I genuinely don’t know any. It has native mobile apps, supports fast file transfers, offers real self-hosting that’s actually not a nightmare to set up — honestly, it’s a lot of free functionality.

Yet from the comments, some people seem perpetually frustrated with Anytype. One recurring complaint: “Why isn’t it fully open source?” Well… why should it be? Some parts are open under MIT (including any-sync, which we spent a lot of time writing and refining). Other components have their code visible but come with more restrictive usage, which is normal — Anytype is still a business. Also Notion is closed source, Obsidian is closed source, so…

Yes, Anytype needs users — traction matters. But the other direction matters too: people should also recognize what they’re getting here. Again it’s a free app that gives you control of your data, offers end-to-end encryption, works across platforms, and covers a wide range of use cases that many other tools don’t even attempt.

so IMO constructive criticism is great, expectations are understandable. But I still don’t get why we have so many negative feelings here

Yeah.
This is why I was perplexed when Anton mentioned, the local data would be encrypted.
So I asked “Since then is ist encrypted?”
And he answereds: Since day 1. So this assumption is wrong.

I was really perplexed about Anton’s answer, so I proved that there are not fullly encrypted data on the local hard disc, that can be read with a simple text editor.

If I’m not totally wrong, then this problem could easily be solved, of the cost of RAM usage.

  1. Load the encrypted data and decrypt them in the RAM.
  2. Work with the encrypted copy of the data in the RAM.
    The bigger problem is, that such a system needs more effort to make it resistent against failures like suddenly power lost.

And I partly agree: Harddisc encryption is the preferable way in many situations.
It helps against thieves and maybe even against the authorities.
BUT:
It doesn’t help against family members if they also use the PC.

I know, I know, someone who has access to the PC could install every imaginable spyware and so on.
Yeah, that is true, but this is a big shoe. Not even full disc encryption could save you against such determined faulty persons in your close environment, because the spyware could keylog the password and safe it somewhere else. etc. etc.
No, the much more likely scenario then such hardcore actions is simpler:
Someone simply looks into the local files with a text editor or a hex editor.
It can have a lot different and totally harmless reasons why someone does that.
But if someone does that (without bad intentions) and scrolls through the files, there may be a point when he sees something that bothers him (or her) a lot! Suddenly becoming suspicious, he/she will have a second and deeper look!
And in the end, it may ruin a marriage.

No hard-disc encryption would prevent that, if the family members have full access to the PC anyway.
But App-level encrypted local data would help.

every one has their own attack vectors they define themselves. if your family member who has access to your user account on your computer is one in your mind, then you might look for another solution to “protect yourself”. There are applications that fully encrypt the data at rest.

on my machine I am only able to see unencrypted strings in the .store files within the search index folder (fts_tantivy) when I open then with a hex editor. this should not be findable via a normal search via your operating system’s search functionality. and if you think a family member will specifically open a file within your anytype folder with a hex editor…

Forget the hex editor, I’ve mentioned it only because it is of course the much better tool for looking into strange files then a text editor.

I find it relative normal that someone looks with a text editor into some files in an App’s data folder.
I do that sometimes and for different reasons.
That there are for example the user names of my space guests in plain text s a bit too much for me to feel comfortable with it! Same with Space names.

Again each software has its limitations, Anytype specified that local indexes are not encrypted and recommended having encryption on your disk, because that is how the tech works to have balance between speed and security. Having encryption for all of the local indexes is not feasible right now, maybe in future some of them can be encrypted (e.g. full text ones), but might not be all of them. Therefore to allow Anytype to work with high speed AND have indexes encrypted you need a disk encryption and that’s it.

I think that sums up the discussion. We can say how bad it is if somebody can read the local indexes or that CIA can find that somebody is unfaithful to his wife, but I don’t think this is any useful, except for expressing frustration in that tech works not in the ideal way.

I can also provide this analogy. Imagine you go to your apartment and everything there is stored in a very large safe. Is it secure? Yes, because probably if robbers will break into your house they won’t be able to open the safe. But it will require a lot of energy to put all the things in this safe every time when you go out and it will slow you down a lot in your day to day life.

Probably the better approach would be to store only valuable things that you don’t need to access every day in the safe, but other things like notebooks store in other places to be able to access them quicker.

We should look at everything in comparison, for example to Obsidian, Notion. Does Anytype provide more security than them? Does the data stay encrypted on the servers? Do most of the data (including files) stay encrypted on device in Anytype?

I wondered just now that there are not only search indexes that are not encrypted but also the first parts of every object are also not encrypted at rest in the objects.db.

For example:

It’s not that the whole object is visible. In this case it is. In longer objects it’s capped at some point. As if this is used for a preview of an object.

also the source property is in plaintext.

It’s not that I’m shocked. Encryption is hard. But I thought that the objects itself are fully encrypted at rest and that only phrases and some words in the search index would not be encrypted at rest (so that one can’t puzzle together the context of those phrases). So I am a bit surprised.

Everything which is in object store (objectstore folder) you should treat as indexes, everything which is in space store (spaceStoreNew folder) is encrypted.

Again objects themselves are fully encrypted (in store.db) but the local indexes of these objects which is objects.db are not.

And you shouldn’t be shocked, because this is exactly what is written in the docs that local indexes ARE NOT encrypted.

got it, I thought the search index was stored in fts_tantivy

and I wrote that I’m not shocked but surprised (as I thought this is the database file with the objects themselves).

These are full text indexes, which are also not encrypted.

I get it, the only thing which bothers me a bit that people write with conviction that they found a problem in the software and frame it as such. Whereas in fact it is something that Anytype was open about.

this is true. if there are no counter forces hysteria and outrage can escalate quickly.

EDIT

@cheggaaa shared this in the nightly chat about the unencrypted search index just now:

So be sure, we’re working on it! Considering using sqlicipher for a local DB - but there are some performance issues, so still working on it. Also trying to contact the Tantivy team - Index encryption via Encrypted Directory [reopen] · Issue #2338 · quickwit-oss/tantivy · GitHub, they don’t answer, but anyway, we will try to make a pull request when we have time for this.

Basically we wanted to introduce encryption on the tantivy side, and I created an issue long ago wanting to implement it myself, but we just never got an answer and then never prioritized this due to complexity and having other pending issues.

Seems you didn’t get it how all this began.

  1. Anton stated that the local data are encrypted.
  2. Perplexed about his statement (that’s in contrast to the technical docu, as well to earlier discussions), I asked: “Since then is it encrypted?”
  3. He answered: “Since day 1. So this assumption is wrong:”

To be clear: If someone says to me “your local data is encrypted”, then I understand it of course so:
“ALL your data, really EVERYTHING, is encrypted!”.

After that conversation, it was easy to proof that his statement doesn’t hold that expectation.
But he, as one of the founders, strongly beliefs that the data are encrypted (no matter what the technical docu says), then must this issue be seen as a bug. This needs to be reported!

But if its bothers you, that I’ve reported a potential privacy/security issue, then I never need to do that.
Live with every issue that there may be, I don’t want to bother you again with reporting them.

Can you please next time link also the source?

Here is it for everyone to verify the statement “local indexes ARE NOT encrypted.”

  • We decrypt these encrypted objects on the fly with your keys, perform some logic and then save the results (i.e. indexes) locally. These indexes are not encrypted, but here we assume that only you have access to your local data, i.e. the access to your local computer is not compromised.
  • These indexes are not synced anywhere and they stay only on your computer. For example, if you have two devices, each of them will have its own index storage
  1. search & replace in the current document. plain and simple. ctrl+h would do fine :wink: (even on macos)

  2. search & replace advanced: with regex / wildcards, space-wide

I did link the source though - you can check my initial reply :slight_smile: Top 2 missing features that could make you leave anytype - #64 by mcrakhman

End-to-end encryption and real-time synchronization, but it seems that Anytype cannot cut off these two features hahaha🥰

What do you mean it can’t cut off this two features? In which way? Encryption works, local indexes - I think I already explained the trade offs, but the data is encrypted with indexes needed for faster processing. Can it be improved, yes it can? But it works. The synchronization also works even peer to peer in local networks. Everything works in real time.

So I don’t get your “hahaha” here, care to explain?

It was meant ironically.
Both features @HAN cares the most about are already in place. So they won’t leave and are a happy user.
Anytype “cannot cut off these two features” because both are core features. Those features won’t go away. So nothing will make HAN leave Anytype.