the secure1, distributed platform for social applications
Get the Code · Read the Specification · Roadmap and Changelog

Think of AirDispatch just like email but with some subtle changes. By improving on email for the modern web, we are able to create a richer ecosystem of compatible applications.


  • Address - A public signing key and encryption key.
  • Address Fingerprint - A hexadecimal representation of an address often used for convenience.
  • Identity - A private signing key and encryption key. Generally contains an Address.
  • Router - A system that translates addresses (or address fingerprints) into server locations.
  • Server - The AirDispatch server which collects and sends a user's mail.


A fully qualified AirDispatch address fingerprint looks just like this: 4073f3dff85852fc8c0c206599b7e221d8c7a77f085a9497. Nobody else in the world can have the same address. However, after picking a routing framework, you can reduce the large size of the address to something more familiar like [email protected] or even hunter.leath. Because there is no server information embedded in the address fingerprint itself, you are able to freely change AirDispatch providers without having to alert everyone you communicate with. AirDispatch routing takes care of it all.

Address Fingerprint Algorithm

  1. Create ECDSA Public Key (32-byte X and Y).
  2. Create 65 Byte String a = {0x03} ++ X ++ Y.
  3. b = RIPEMD160(SHA256(a))
  4. c = SHA256(SHA256(b))[:4]
  5. The final address is constructed by: b ++ c.


AirDispatch doesn't actually send any messages. Instead, it sends recipients a location of a message. This way, messages up to arbitrary sizes may be sent, and users can choose to edit or delete messages before a recipient views them. This enables some pretty unique messaging capabilities. For example, one could just publish a message without sending any alerts with the location. We consider this to be a public message. Because the message must eventually be retrieved by an AirDispatch users, one could limit access to this messages by a blacklist or whitelist.


If you understand JSON, then you understand how an AirDispatch message works internally. It behaves just like a key-value dictionary where the keys are strings and the values are bytes. This allows us to algorithmically filter messages out of the all-encompassing inbox and put them in the appropriate context where they are needed. For example, photos could go to a photo application, events could arrive at a calendar, and newsletters could live somewhere else entirely.

  "": "My First Time with AirDispatch",
    "Well, the _first_ time I heard of AirDispatch..."

A Sample Blog Post in AirDispatch (Where the value strings are secretly ASCII byte arrays.)


Since addresses don't give any information away about where the user is located in the system, we must create a routing layer that translates the addresses into server locations. Since this part of the system is going to be very important for an attack, it was designed as a framework so that routers can be swapped out. We are currently working on two routing implementations, as seen to the right.


All messages are signed and encrypted by default to ensure that attackers cannot read or spoof messages. AirDispatch attempts to follow good encryption standards without venturing into the wild west of security. However, we know that any new protocol will be looked at with skepticism before it is proven secure.

We will try to be as responsive as possible with security-related questions or concerns.

  • Signing Algorithm: ECDSA - NIST Curve P256
  • Encryption Algorithm:
    1. Key: 2048-bit RSA OEAP SHA256
    2. Data: 256-bit AES CFB Mode

For those looking to take a peek at the crypto implementation, all relevant files are here.

To Send a Message:

  1. The Message, From Address, To Address, and Timestamp are signed (optionally by multiple parties).
  2. That data is encrypted by generating a random AES key and encrypting that with the user's public RSA key.
  3. Tack on the recipient's address to the encrypted message so that multi-user servers know what to do with it.

Message sending protocol is located here.


v0.3 - Summer 2014

v0.3 will include the creation of a codified protocol error response.

v0.4 - Fall 2014

v0.4 will include a Data framework to enable sending messages of arbitrary size (currently messages are limited to 1MB due to protections in Google's Protocol Buffers).