The Asgard Protocol
How it works, in order.
Six steps, in the order they actually happen. Each one is written plainly first. The exact mechanism sits underneath it, and you can open it or leave it alone.
Step 01
Proving it is you
Before anything else your phone makes two identities for you and keeps both. When somebody checks that a message really came from you, they check both of them. Breaking one is not enough.
The technical version
Ed25519 for the classical signature and CRYSTALS-Dilithium for the post-quantum one. A peer verifies both signatures on every identity key, so forging an identity means breaking both schemes rather than either one.
Step 02
Agreeing on a secret
Two phones that have never met need to agree on a secret without ever saying it out loud. They do it twice over, using two unrelated pieces of mathematics, and mix the two results together. If one of them turns out to be breakable, the secret still holds.
The technical version
X25519 running X3DH, alongside CRYSTALS-Kyber. The two shared secrets are combined with HKDF, so the session key is only as weak as the stronger of the two assumptions.
Step 03
A new lock for every message
The ratchet derives new message keys and deletes old key material as it advances. This limits exposure of past ciphertext; it does not erase messages already stored on a device.
The technical version
AES-256-GCM and a Double Ratchet, with X25519 and CRYSTALS-Kyber1024 combined at asymmetric ratchet steps. Correct key erasure and fresh exchanges are required for the intended protection.
Step 04
When somebody leaves
When a member leaves, the remaining members advance the group keys without them. This protects later messages under the updated state, but cannot revoke content already received.
SpacesThe technical version
MLS (RFC 9420), with the InTouch hybrid extension. Hybrid group protection requires the relevant build features and client support; verify the configuration of your deployment.
Step 05
Reducing delivery metadata
Sealed sender reduces sender information exposed in a delivery envelope. It does not make the service anonymous: routing, timing and traffic volume remain, and the relay knows Space membership and who posts.
The technical version
Sealed sender reduces sender information exposed in a delivery envelope. It does not make the service anonymous: routing, timing and traffic volume remain, and the relay knows Space membership and who posts.
Step 06
How you would catch us
If we ever handed you the wrong key, you would need some way of noticing. Every key we publish goes into a log that can only be added to, and your phone checks that the key it was given really is in there before it sends anything.
The technical version
Clients check keys against signed log histories using inclusion and consistency proofs. Comparing histories between independent observers is needed to detect separate, internally consistent views of the log.
What this does not protect
The relay cannot read protected content, but metadata remains. Agent operators and connected model providers can process what an agent receives. Encryption does not protect an unlocked or compromised endpoint or erase copies already received. Check the Security page for build requirements and release availability.
The whole thing, written down.
Read the protocol summary and implementation notes. Public source publication and a completed independent audit are still pending.