<!-- vim: set ft=markdown: -->
AEW: The Ætherwind protocol and how its parts fit together.
## Purpose of this document
There are a number of different components to the Ætherwind protocol:
- AEW.1TO1: communication between devices
- AEW.WRAP: message wrapping
This document describes how these pieces fit together without going into too
much detail about how each piece works internally. Each component is described
in detail in its own document.
## Fundamental concepts
Ætherwind (AEW) is a federated end-to-end-encrypted chat protocol.
Federation means that AEW does not rely on a single server or server operator
but a network of servers operated by different parties that are not required to
trust each other. However, federation does not mean that AEW is a peer-to-peer
protocol like BitTorrent. It is still a client-server protocol, in which client
identity is tied to their "home" server.
End-to-end encryption (E2EE) in the case of AEW means that if Alice
<example.net:~alice> sends Bob <example.org:~bob> a message, and Bob receives
and verifies the authenticity of that message, then that message is guaranteed
to have been sent by Alice (authenticity) and nobody other than Bob and Alice
can read it, as long as Alice and Bob's devices have not been compromised. AEW
uses a variant of the Double Ratchet algorithm to obtain these security
The following concepts are important:
Servers: A server is an untrusted repository for certain pieces of information
needed to allow people to receive messages and initiate communications while
not simultaneously online. Servers are also a way to namespace users, groups
and rooms. It must be emphasised that while servers are NOT trusted third
parties for the purposes of ensuring message encryption and authenticity (i.e.
servers can't listen in on or forge messages to or from their users), an
uncooperative, malicious or buggy server can delay or block message delivery,
may ban users and may block users or blanket block users from entire servers.
Equivalent elsewhere: a matrix server, an email server, a web host
User: A user is AEW's conception of a particular identity of a person.
It is assumed that a person may have more than one identity. For example, a
person might have a personal identity (Bruce <example.net:~bruce>), a work
identity (Bruce <example.com:~BruceWayne>) and a secret identity (Batman
<example.org:~batman>). These identities can be separate, and clients must
support multiple identities in a secure way that cannot be used by third
parties to tie the identities together. Every user is tied to a particular
server. However, identities may also be tied together by a user intentionally.
For example, a person may do so as part of a process to transfer their identity
from one server to another. In the description of AEW, identity and user are
used interchangeably, identity mainly being used when particular support for a
person having multiple identities is being emphasised.
Example: Miles Rout <aewind.net:~miles>
Equivalent elsewhere: a matrix identity, an email address, a phone number
Devices: A device is AEW's conception of a computer, mobile phone, etc. It is
assumed that a person may have more than one device and that any of their
devices represents and is trusted by them entirely unless and until it is
expressly revoked. Any device of a user may read any message sent to them, and
every device of a user may send a message on behalf of that user. If a user
installs multiple copies of a client, those copies are separate devices. If a
client supports multiple user identities being logged into the same
installation of the client, each login is treated as a separate device.
Equivalent elsewhere: a device in the Signal protocol
Groups: A group is a collection of users, one or more of which are owners of
the group. Ownership of a group may be transferred between users. Owners
control groups by approving the entry or exit of members to or from the group.
Like a user, each group has a home server, which must be the home server of at
least one of its owners.
Example: Æther Developers <aewind.net:@devs>
Equivalent elsewhere: a Discord "server"
Chats: A chat is an exchange of messages between one or more users. A user
may belong to any number of chats. Chats do not have a user-facing identity or
name. More than one chat may have the same or overlapping sets of
participants. Chats do not have a home server. Chats do not have an owner.
Rooms: A room is an exchange of messages between one or more users. A user
may be in any number of rooms. Rooms may be owned by a group or by one or more
users. Rooms have an identity and a home server.
User rooms: A room owned directly by one or more users is called a user room,
or just a room. They are namespaced at the server level. There may only be
one room per server with a particular name at any point in time.
Example: Æther Development <aewind.net:#dev>
Equivalent elsewhere: an IRC channel
Group rooms: A group room is a room whose owner is a group. A room owned by a
group is special because it is namespaced differently, its existence is only
visible to the members of that group, every member of that group is
automatically a member of the room, and the room is controlled by the group's
admins. Note that group non-members may be invited to the room as well.
Example: Æther Security <aewind.net:@devs#security>
Equivalent elsewhere: a Discord channel
## An Overview of the Protocol
AEW.IDENT is the protocol used to establish user and device identity. Roughly,
.IDENT involves a user publishing certain public keys signed by certain other
keys to their home server. These keys establish the user's set of devices.
.IDENT also includes the mechanisms for tying together user identities in the
form of 'I AM' certificates.
AEW.1TO1 is used for communication between devices. In the case of chats, .1TO1
is essentially used directly on top of .IDENT.
AEW.QUORUM is the protocol used for multi-party decisions. It is used to
implement shared room ownership and shared group ownership.
AEW.NTON is the protocol used for N-to-N communication. It is used to implement
## Example: One-to-one chat, third-party server.
Say that Alice and Bob wish to chat. They each register on their mutual friend
Eve's server eve.example using the method described in AEW.IDENT. They register
their devices AAAA and BBBB respectively under the identities
eve.example:~alice and eve.example:~bob. Part of this involves each publishing
certain public cryptographic keys to the server.
Alice wishes to initiate the chat with Bob. Alice requests the information
from Eve's server that would allow her do this, and proceeds to use the 1TO1
protocol to start a conversation with Bob.
How does Alice know that:
1. The information she downloaded from Eve's server is the information Bob
published to the server, and
2. The chat established using that information is secure?
The latter is simpler to answer: it is ensured by the properties of the double
ratchet algorithm at the heart of the AEW.1TO1 protocol.
The former is trickier. What Alice thinks of as "eve.example:~bob" is really a
public identity key. There is no inherent way for Alice to ensure that the
identity key for Bob provided to her by Eve's server is legitimate. However
there are some tools Alice and Bob can use to verify the legitimacy of these
The simplest is for Alice and Bob to compare their key fingerprints through
some existing trusted channel. For example, Bob could email Alice his public
identity key's fingerprint using a GPG-signed email. Or they could meet in
real life to compare these values. These are out-of-band methods. What would
be better would be if there were some way to integrate other forms of identity
into the eve.example:~bob identity to endorse its legitimacy. This is what
AEW.IDENT is all about it. It provides a method by which persons can use things
like DNS and GPG to certify the legitimacy of their public identity keys. This
comes in the form of 'I AM' certificates, which are signed statements of the
form "I am [SERVER]:~[USER]" (or more accurately: "[SOME-ARBITRARY-IDENTITY] is
[AEW-PUBLIC-IDENTITY-KEY]", but generally the first identity is also the signer
of the certificate, and in most cases is also in the form of an AEW public
As a general rule, chains of 'I AM' certificates should only be trusted
recursively if all but one element of the chain is of the form "[AEW-IDENTITY-1]
certifies that [AEW-IDENTITY-2] is [AEW-IDENTITY-1]". However, the
interpretation and presentation of 'I AM' certificates is left entirely up to
the client implementation. Different clients for different types of users may
wish to treat trust in different ways.
There is an exception: clients SHOULD use a Trust-On-First-Use (TOFU) trust
policy when tying public identity keys to names. The mechanism by which a
server hands out names can result in a server authorising more than one user to
use the same name. Servers SHOULD NOT hand out the same name to more than one
user at once, but may reuse names if a user is deleted, transferred to another
server, banned from the server, or in any other way no longer able to use the
name. Clients MUST ensure that distinct users registered under the same name
cannot be confused.
If you trust the operator of your server (i.e. you operate your own server) you
do not need to do anything special.
## Example: Multi-party chat, third-party server.
After a few weeks of using AEW enjoyably, Alice invites a second friend,
Charlie, to join Eve's server. Alice and Charlie chat away on Alice wishes to
create a group chat to discuss the ongoing Ashes series with Bob and Charlie.
Alice and Charlie were in the same room when Alice invited Charlie to Eve's
server, and they have checked