the default has not changed
By default, Aethereum stores only interface contracts and one-line intent, never your source code. Code sharing is a separate, opt-in capability. A team can leave it off forever and lose nothing about the coordination you already rely on.
the honest scope
What is encrypted, and what is not
End-to-end encryption applies to shared code only. Contracts and intent stay readable by the server on purpose, because that is what powers collision alerts, the dashboard, and search. We will not tell you everything is encrypted, because it is not, and the parts that are matter more when you know exactly where the line sits.
what we actually store
The same record, encrypted the moment it leaves your machine
the same construction, one more payload
Session handoffs travel the same way
When you move a live session to another machine with aethereum handoff, the transcript is encrypted on your machine with the same keys that power encrypted code sharing. The server stores a handoff artifact as ciphertext plus a minimal envelope: author, time, a size class, and the target. Your working directory, branch, commit, and session id travel inside the ciphertext, never in the envelope, so the server cannot read them. The same safety-number verification applies: a room verified with aethereum verify keeps the stronger guarantee for handoffs too, and an unverified room gets the narrower one, that the server stores only ciphertext it cannot read.
trust model
Verified rooms, and the honest limit of unverified ones
Every member has completed an out-of-band safety-number check, the same idea Signal uses. Once a room is verified, the end-to-end guarantee holds even against a fully compromised server. A server that turned hostile still cannot read your shared code, and cannot slip in a key it controls without the safety numbers failing to match.
Before anyone verifies, keys are exchanged on a trust-on-first-use basis. The honest claim here is narrower: the server stores only ciphertext it cannot read. We do not claim compromise resistance for an unverified room, because a server that tampered with the very first key exchange could not be ruled out until you complete the safety-number check.
the check that upgrades a room
The safety-number check
Aethereum shows each member a safety number derived from the room's keys. It is a one-time check per pair of members.
room safety number · compare out of band
full honesty
What the server still learns
Even in a verified, encrypted room we are honest that the content is private but the shape of the activity is not. Our server can see:
- that a share happened, and when
- a size class of the payload
- which contract it relates to
- which agent authored it
- the access graph of who can read it
It never sees the code itself. We tell you this plainly, because a guarantee you cannot inspect the edges of is not one you should trust.
do not take our word for it
The claim is inspectable, not asserted
The encryption engine is an open, MIT-forked codebase. Read the client, confirm it encrypts before the network call, and confirm the server only ever holds ciphertext.
questions
Encryption, answered plainly
Is everything in Aethereum end-to-end encrypted?
No, and we will not pretend otherwise. End-to-end encryption covers shared code and session handoffs only, and code sharing only when a team opts in. Contracts and intent stay server-readable so coordination features work. By default no source code is stored at all.
Are session handoffs encrypted too?
Yes, the same way as shared code. A handoff artifact is ciphertext plus a minimal envelope (author, time, size class, target). Your working directory, branch, commit, and session id travel inside the ciphertext, so the server never learns them. The same safety-number verification applies.
Can Aethereum read code shared in a room?
No. Your client encrypts it before it leaves your machine, and the server and mirror store only ciphertext. The keys never leave your client.
What does compromise-resistant mean here?
It is true for verified rooms, where members have completed an out-of-band safety-number check. For an unverified room the honest, narrower claim is that the server stores only ciphertext it cannot read.
What can the server still see in a verified room?
The metadata around a share: that it happened, when, a size class, which contract, which author, and who can read it. Never the content.
Can I verify these claims myself?
Yes. The engine is an MIT-forked open codebase, so you can inspect that the client encrypts before the network call and that the server only holds ciphertext.