Is your data somewhere someone else can delete?
Ordinary cloud is convenient, but one company can delete it, read it, or shut it down.
A way nobody can delete is now something you can choose.
What's a server? What's hosting? What is “censorship resistance”? — from the basics to comparing today's options, laid out in diagrams.
A server is “a computer that's always on and reachable”
A website or a piece of data is, in the end, a file inside some computer. For anyone but you to see it, that box has to be (1) always powered on and (2) reachable from the internet. Keeping a box like that running is what hosting is.
Cloud (Google Cloud, AWS, etc.) = handing everything to one company
The easiest option is to rent a big company's data center. A few clicks, fast, cheap, and pleasant to use — but that box belongs to that company. Your data is, in effect, deposited with them.
“Censorship resistance” = removing anyone who can delete it alone
Censorship resistance means no single place or person, if seized, can delete, read, or shut down your data. The trick is to remove the central admin — share the load across many participants instead. It's easiest to see on a centralized ↔ distributed scale.
Censorship resistance actually has three separate properties. Separating them makes each service's strengths and weaknesses clear.
The “two shapes” of a censorship-resistant server
There are broadly two ways to remove “the central company.” Both assume you encrypt it yourself (making it unreadable is your job).
Today's main options, on six measures
• Deletion resistance…how hard it is to delete / • Privacy…is the content unreadable (all of these assume you encrypt it yourself) / • Payment…can you pay with crypto / • Simplicity…how easy to set up / • Ops burden…the load of keeping it running / • Cost shape…how the money works
| Where | Deletion resist. | Privacy | Payment | Simplicity | Ops burden | Cost shape |
|---|---|---|---|---|---|---|
| Ordinary cloudGoogle Cloud / AWS | ✗one company can delete it | △the company can read it | ✗fiat only | ◎ | ◎hands-off | ○monthly / usage-based |
| Arweavepermanent distributed storage | ◎permanent by protocol | ○encrypt before upload | ○AR, multiple currencies | ○ | ◎pay once, done | △one-time buy-in (cumulative) |
| Filecoin / IPFSdistributed storage | ○depends on contract / replication | ○encryption supported | ○FIL | ○ | ○ | ○ongoing billing |
| Sia / StorjS3-compatible distributed storage | ○Storj leans centralized | ◎encrypted by default | ○SC, STORJ | ◎drop-in S3 | ○ | ○usage-based |
How to read it: if you want “hands-off and forever,” that's Arweave. Only Arweave gets ◎ on deletion resistance — “it keeps living whether or not you run it.” A self-hosted node is strong “as long as you keep it running” — a different kind of strength.
Cypher Brain's approach: encrypt first, then park it somewhere it can't be erased
The key insight: if you encrypt the content first, the place you park it can just be a simple storage that can't be deleted or tampered with. Making it unreadable is your job; making it undeletable is storage's job — that division of labor is what keeps this design simple.
- Parking it on gcloud = Google can delete it
- Terms change, a report, a legal order — it can stop in one shot
- The company could read the content
- The content is encrypted (only you hold the key = unreadable)
- The storage is censorship-resistant (can't be deleted)
| Decision | Current choice | Reason |
|---|---|---|
| Storing the content | Arweave, first | “Pay once, permanent = never deleted” matches the brand — low effort |
| Cloud (gcloud) | Not used | Convenient, but “can be deleted” — contradicts the whole premise of this project |
The idea has already become working code
The explanation above — encrypt it (unreadable) and park it somewhere it can't be erased — hasn't stayed a concept. It's already assembled into a working tool (cypher-brain). We've run it end-to-end on a real, growing brain snapshot; here's where things honestly stand.
Being honest about what's done and what's left —
| Item | Current status |
|---|---|
| Encrypt and restore | Verified with real data (a whole brain): encrypt → store → retrieve → decrypt, content matches exactly |
| Push, pull back, decrypt | Ciphertext pushed, deleted locally, pulled back, decrypted, and matches |
| Key recovery / operations | Backup-key restore, versioning, and the restore runbook are documented and covered by automated tests |
| Even at large sizes | Verified with a whole brain (~630MB → 268MB encrypted). Streamed, not buffered, in memory |
| Proving “never deleted” in production | Actually paid ($7.68) to upload a whole brain to mainnet Arweave, then retrieved it via a path with no access to the key and confirmed a byte-for-byte match |
| How the production key is protected | Chose not to use a backup key, since it adds complexity. Instead, the single key is passphrase-protected, and a recovery note (key + location + restore steps) is kept off the machine. Retrieving and decrypting the full brain was measured and confirmed |
The core has already been proven for real — encrypted a whole brain, actually paid to upload it to mainnet Arweave, retrieved it without the key, and confirmed a byte-for-byte match. The key is passphrase-protected and kept off-machine (we chose not to use a backup key, since it adds complexity). The direction hasn't changed: the content lives on Arweave, and encryption is yours alone, from the start.