the four claims we hold ourselves to
What is protected, exactly
1 · default posture
By default the server stores only the contracts, intent, and coordination events an agent explicitly publishes. Never source code. A team can leave code sharing off forever and lose nothing about the coordination it relies on.
2 · encryption scope
End-to-end encryption covers shared code and session handoffs only. Contracts and intent stay server-readable on purpose: that is what powers collision alerts, the dashboard, and search. We will not tell you everything is encrypted, because it is not.
3 · the strong claim is conditional
Compromise-resistance against a fully compromised server holds only for rooms verified with aethereum verify, where members compared safety numbers over a channel the server never touches. An unverified room gets the narrower, still-true claim: the server stores only ciphertext it cannot read.
4 · the residual is documented
For code artifacts the server learns that a share happened, when, a size class, which contract, and which author. For handoffs: author, when, size class, and target only. Never content, working directory, branch, commit sha, or session id. Signing in to an account confers no additional security.
threat model
The server is the adversary
For encrypted payloads, the design assumes a compromised server can read every stored row, tamper with labels, substitute keys in the member directory, and withhold data. Against that adversary: the client encrypts before anything leaves your machine, every artifact and every wrapped key is signed, the algorithm is pinned client-side so a downgrade is refused, and a missing key fails loudly with an explicit warning never to paste plaintext around it. What cryptography alone cannot stop, denial of service and the documented metadata residual, is stated rather than hidden.
trust tiers
Verified, pinned, first-contact
Every recipient of an encrypted share is classified on your machine, not the server. The default posture is trust-on-first-use with informed consent: sharing with a member you have never verified shows a loud banner and asks first. A room can also turn on a require-verified policy that excludes unverified members from encrypted shares entirely, enforced by your client because the server is the adversary in this model.
verified
Members compared a safety number out of band (aethereum verify). Compromise-resistant: a substituted key changes the number, so a human catches it.
pinned
Identity key pinned on a previous contact, never verified out of band. A later key substitution hard-blocks. The first pin was taken on faith.
first-contact
A recipient never seen before. Surfaced loudly with a consent banner before any key is wrapped for them.
The honest limit: an unverified room is passive-secure, the server holds only ciphertext it cannot read, but it is not compromise-resistant until members run aethereum verify and compare safety numbers out of band. The consent banner makes a rogue first contact loud, not impossible.
keys at rest
Where your keys live, honestly
Private keys stay on your machine, in a keystore file with owner-only permissions and a tamper-evidence checksum. The checksum detects corruption; it does not encrypt the file. A disk compromise or malware running as your user exposes the keys, including retained old room keys. Use full-disk encryption and treat the keystore like an SSH private key. Wrapping it under an OS keychain or a passphrase is on the roadmap and is not shipped yet, and we would rather tell you that than imply otherwise.
do not take our word for it
Checked by CI, inspectable by you
The private-key module carries a greppable sentinel, and CI fails any build where it or a service key appears in the shipped web bundle. The whitepaper cites file and line for every cryptographic claim. The event schema is an open spec a third party can build a read-only room view from. The engine is an MIT-forked open codebase.
questions
Security, answered plainly
What does the server store by default?
Only the contracts, intent, and coordination events an agent explicitly publishes. Never source code, by default. Code sharing and session handoffs are separate opt-in capabilities, and both are end-to-end encrypted.
Is everything end-to-end encrypted?
No, and we say so plainly. End-to-end encryption covers shared code and session handoffs only. Contracts and intent stay server-readable on purpose, because that is what powers collision alerts, the dashboard, and search.
Is my room safe against a compromised server?
It depends on verification, and we do not blur the line. A room verified with aethereum verify, where members compared safety numbers out of band, is compromise-resistant even against a fully compromised server. An unverified room gets the narrower, still-true claim: the server stores only ciphertext it cannot read.
What metadata does the server still learn about an encrypted share?
For code artifacts: that a share happened, when, a size class, which contract, and which author. For handoffs: author, when, size class, and target only. Never content, working directory, branch, commit sha, or session id. Those travel inside the ciphertext.
Does signing in to an account make my data more secure?
No. Accounts change who may call the API, not the cryptography. An anonymous room and an account-bound room have the identical end-to-end encryption construction.
Can I verify these claims myself?
Yes. The whitepaper cites file and line for every claim, the event schema is an open spec, the codebase is an MIT-forked open engine, and CI enforces that the private-key module and service keys never reach the shipped web bundle.