---
# System prepended metadata

title: Secure Messages

---

# Secure Messages

> Twtxt / Twt.social is continuing to gain traction and quite a few folks find it useful everyday. One thing we're now missing is a way for users on a Pod to messages each other. This document is to outline a design for how to achieve secure messaging between users whilst also ensuring message integrity, authenticity and privacy (_including privacy from the server itself_).

## Goals

- Users to be able to securely and privately messages each other.
- Server cannot see the content of messages
- No other users can eavesdrop on a message between two users
- Users are assured the content of their messages has not been tamprted with in any way

## Scope

For the time being the scope of this design will be limited to a pair of users, Bob and Alice on a single Pod.

Cross-Pod Messaging wil be out-of-scope.

This messaging scheme is **NOT** designed to complete with the likes of Signal or Session or any other more secure messaging protocol. It shall be made clear to users that the best form of security and privacy for messaging are things like Signal or Sessions. The amount of time/effort required to have more sophisticated secure mssaging in Twtxt is too costly at this stage.

## Cryptographic Functions

The [TweetNaCL](http://tweetnacl.cr.yp.to/) library shall be used on any Javascript based client / frontend.

The [box](https://pkg.go.dev/golang.org/x/crypto/nacl/box) library shall be used by any Go clients such as the `twt` command-line client.

## Key Management

As this is a new feature, initially users will not have a key pair at all. The next time a user logs in the backend will automatically generate a new key pair, encrypt the private key with the user's password and store the encrypted private key and plaintext public key against the user's account.

## Messages

For simplicity a single private/public key pair will be used to encrypt and sign all messages.

# [@dbohdan](https://github.com/dbohdan)'s feedback

[@prologic](https://github.com/prologic) requested my feedback on this proposal.  Here goes.

## Analysis

1. If you can at all avoid it, you should not design your own secure end-to-end-encrypted instant messaging protocol from scratch.  It is difficult, and people who try to do it without experience in cryptography end up with a flawed protocol.  Examples: [Tox](https://github.com/TokTok/c-toxcore/issues/426), [Telegram](https://news.ycombinator.com/item?id=10713064).
2. If you do, it is likely to take over the project.  The instant messaging part of your service will take more effort to develop and to keep running than the twtxt host part.

## What I would suggest instead

Run an existing server based on a protocol like [Matrix](https://en.wikipedia.org/wiki/Matrix_protocol) or [XMPP](https://en.wikipedia.org/wiki/Xmpp).  Automatically give your twtxt users accounts on the IM server.  Tell them how to connect with an external client with end-to-end encryption such as [Element](https://element.io/) in the case of Matrix.  Element is open source, and you can run it on your own servers, though I haven't.