Documentation

Mesyx (/'mi siks), a contraction derived from the words message exchange, aims to be a distributed message exchange system enabling secure communication between multiple parties.

Mesyx is a message server and client in one, exposing it's client functionality through an API (REST, IMAP, etc.) for clients to consume.

The server part of Mesyx accepts messages (e.g. emails or IRC messages) and ensures that they are stored encrypted on the server using the configured public keys. Mesyx then exchanges the message store with other Mesyx instances in the clusters, forwarding details about read-status of the message or wether a client has chosen to delete the message and other message operations. The client access part of Mesyx then allows decrypting the message so that the client can display the message to the user.

There are many messaging systems in existance, and all have certain pros and cons. Mesyx attempts to relieve some of the cons that we feel are important, while building upon the pros of existing systems and enabling interaction with those systems.

Features & Goals

Mesyx has the following goals and features in mind when it is fully implemented:

• Open Source and Open Protocols: allowing contributions and auditting of all the components.
• Secure: Audited code, secure protocols, e2e encrypted with no/minimal cleartext metadata.
• Anonymity Aware: Tor & Smorph support.
• Trust & Reputation.
• Federated: run an own instance while being able to exchange messages with other systems.
• Distributed, Replicated & Redundant: multiple instances can operate independently while staying in sync with the other instances in your cluster of instances.
• Use anywhere: Usable online and offline (sneakernet-style).
• Filtering: SIEVE-style filters built-in, spamassassin integration is likely.
• Stats: anonimized graphs for a variety of metrics.
• Ease of installation and use.

Protocols

Initial interactions with other protocols:

• Mail:
  • SMTP
  • IMAP
  • SPF, DKIM, DMARC
  • ARC: Authenticated Received Chain
• Chat:
  • IRC with ZNC-playback extensions
  • XMPP
  • Twitter
• Transports:
  • HTTPS
  • Tor
  • Smorph
  • Sneaker sync (Local in-person sync)

Of course these protocols are complemented with PGP, TLS, OTR and Ratchet protocols for security and privacy.

Mesyx operating modes & key management

Mesyx can operate in a combination of distinct modes, thus allowing functionality and more importantly cryptographic secrets to be split between functions which could minimize security implications. One can of course choose to run all components in the same place of one desire that, though we recommend against it from a security concept.

• Accept: In accept mode Mesyx receives messages from outside networks and encrypts these messages with the public keys that it has available. In this mode, it only has the public keys needed for encryption.
• Exchange: In exchange mode Mesyx only exchanges messages with other Mesyx servers. No encryption/decryption happens, except for instance when using TLS for transport encryption.
• Client: In client mode Mesyx requires both the public and private keys. A Mesyx client typically runs on a highly secure machine where having a private key is not a risk.
• Re-encrypt: in re-encrypt mode a Mesyx client has both public and a limited few private keys. This mode is primarily used to re-encrypt messages from a short-term key to a long-term key. It can also be used to perform key rotation in the case that a key has been compromised. (Though a MITM entity that has a copy of the message store would have a copy of all messages to decrypt; hence why TLS and Perfect Forward Secrecy and encrypted storage is still important). One scenario where this mode can be useful is where one can have Mesyx client with only short term key on a not-very-secure device like a phone. The short term key is used for messages that have recently been received (e.g. the last week). As that device does not have the long-term key it is unable to read those messages and only short-term messages are available to it.

Each message store will have multiple keysets. A keyset can be configured to cover a timeframe of messages and the importance of a message. e.g. one mailstore could be encrypted for the year 2017 with keyset-A, while keyset-B is used for all messages in 2018. This enables a good rotation of keys. The Mesyx client will automatically select the right key for the message. Time intervals could be as short as 'last week'.

This allows storing the private keys offline for messages that one does not want to decode often.

Messaging styles

Messaging styles can be split into various groups that are primarily separated by how quickly a message arrives at the recipient and how the message is retrieved.

• Post Messaging: blog style.
• Delayed Messaging: email style.
• Instant Messaging: IRC / XMPP.
• Live Messaging: Audio/Video/Whiteboard.

Initially we'll be addressing Delayed Messaging with Instant Messaging following shortly after. Post Messaging will be addressed in the second phase of the project. Live Messaging is a much bigger problem and is relegated to the third phase of the project.

Mesyx will support both 1:1 and group-style multi-party messaging.

Mesyx Clients

Initially the backend will be reachable using standard SMTP, IMAP and IRC protocols. (thus avoiding the initial need for us to have to write proper clients for these interactions).

A web interface (HTML, CSS and minor Vanilla Javascript) that can be run locally on the client and allows interaction with the backend service will follow shortly. A custom client will be required to unleash all the full power and options of Mesyx.

Secondary focus will then become a native Swift iOS app that will provide full functionality as the webinterface provides. Android will not easily be considered till untheir security model (read: timely updates on all devices) has been resolved: one can't have a secure messenger when the base OS is broken.

All frontends will in the end use the HTTPS-based REST API that the server provides, as such, any frontend can be built by a third party.

Client Recommendations

For IRC access we recommend Mutter IRC for the iOS platform and irssi for shell based access.

For Email (SMTP&IMAP) we recommend using Thunderbird or your iOS native Mail.app.

Interaction with Legacy Infrastructure

Mesyx can interact with standard established protocols like SMTP and IRC. Messages will be able to get into and out of Mesyx. Of course the primary concern there will be encryption of which most of these protocols have little standardized. For SMTP messages will be PGP encrypted to the recipient, which thus does leak some metadata (headers, subject, from/to etc). For IRC messages will likely be cleartext unless we are able to establish an OTR session.

Pronounciation

Pronounciation of words is always a challenge, especially when the word is not common yet and made up.

Mesyx is a contraction of the words Message and Exchange and came from a brainstorm session around Message IX. One simple way to pronounce is by saying "Message" but ending in an "X", thus "Messix".

The International Phonetic Alphabet (IPA) way of describing how to pronounce Mesyx is (/'mi siks).