How our decentralized storage works

In Aster, we have a setting called Storage Format. It has two options:

• Aster Server (the default), which is regular storage
• Decentralized IPFS storage

We are writing about the second option today. Switch it on and your encrypted attachments leave our main database for content-addressed storage. This setting will change where your files physically sit and how they get found, so before you turn it on, this is how it works.

Content addressing

Normal storage works by location, and a file will live at a path on a disk or in your folder. You will be able to find it because you know where it is. If you move it, the address breaks.

Content addressing works by identity instead. The system does not ask where the file is located. It asks what it is, and the answer is a hash of the bytes. The address comes from the content. If you were to change one byte, the address would change completely. If you were to ask for an address, the only thing you can get back is the bytes that produce it.

This is the most useful part. A file cannot be swapped or corrupted without the address no longer matching. The same file is the same file on any machine. It’s the idea behind IPFS (the InterPlanetary File System), and it’s what your storage moves on to whenever you change the settings.

Where your files actually go

The switch says IPFS. We want to be straight about what that means. IPFS is the model this is built on, and the plumbing lives in our open source. But the thing actually holding your encrypted files today is a content-addressed store running on our own hardware, on the same Hetzner Storage Box setup we wrote about in Why our storage costs so little. Same principle, our machines, ours to inspect. We’d rather tell you what’s running than let the label speak for it.

Here’s how the store handles a file. Every file is keyed by a BLAKE3 hash of its contents. We write it to a temp file, atomically rename it into place, then read it straight back and check it against the hash before trusting it. If the readback doesn’t match, the write doesn’t count.

It also won’t run on the wrong disk. Before storing anything it looks for a sentinel file with specific contents that only exists on the real Storage Box, and runs a small write-and-read-back probe to confirm the mount is there. If either check fails, it keeps your file encrypted in the database instead of risking a write somewhere it doesn’t belong. Your files don’t quietly end up in the wrong place.

It runs in the background

Whenever you turn this setting on, there is no manual action required from you. A background job will work through your existing attachments, a batch at a time, moving each one out of the database and into the store. Nothing will ever be wiped or lost while it runs. Over a little while, your files will migrate to match your settings.

One thing worth noting is that even on the default Aster Server, your bigger attachments already live in the same content-addressed store instead of bloating the database. Anything over 64 KB goes into it automatically because it is a better place to store large files, and the decentralized switch extends that to everything.

What we can see, and what we can’t

Everything inside of storage is already encrypted on your device before it is sent to our servers. By the time a file reaches us, it is completely ciphertext, and the storage layer never sees any of it. Your keys to decrypt this content are stored only on your device. The content address is a hash of your ciphertext and is never readable.

We can tell you that an encrypted file of a certain size exists, and we can hand back the encrypted bytes when your client asks for them, but we are unable to open it. This same zero-access guarantee applies to the rest of your mail, and content addressing does not change any of it.