UTR is intended as a day-to-day chat application. This means it should be available on all major platforms and should be easy to use. It should protect user privacy at all times, both in the content of messages and their recipeints.
See Prior Art for why I’m writing a new tool and not using something that already exists.
These two goals are sometimes in direct conflict. A steering principle to inform these tradeoffs is that our primary goal is to guard against ‘dragnet’ style surveillance. UTR aims to stop your data and metadata being useful to attackers who are simply watching everything. It may not be possible for UTR as-designed to guard users against targeted individual inspection by sophisticated attackers. ie: If the NSA is interested enough in you that they’re going to install a keylogger on your devices, you need some more powerful magic.
For more detail on this, read about UTR’s architecture.
A key design consideration of UTR is that it should be simple. UTR does not aim to reinvent any cryptographic wheels, instead opting to use established techniques, proven libraries and well trodden paths. UTR also aims to be as small a codebase as possible. A review of the implementation should be a trivial exercise.
More about this in threats and tradeoffs.
UTR will provide a standard implementation of the client and a publicly available server. It should be trivial for users to build their own clients and build and host their own servers.
Read about the current UTR implementation details.
UTR should also have a way of supporting it’s costs. One of the best ways to ensure that UTR continues to be developed in the best interests of it’s users is to have it’s users support it financially.
This and other concerns are discussed in ecosystem.