Cutlass Design Overview - What's the point of this thing?

1 - Overview
2 - Goals
3 - Not-goals
4 - Design decisions

1. OVERVIEW
The cutlass project aims to encourage encryption use amongst average
Internet users.  It will do so by providing a set of useful services
via a cross-platform peer to peer tool. "Useful services" are defined
as services that

2. GOALS

Cutlass must be cross-platform, and the code must be as reusable as
possible. Underlying API usage should not rely on exotic functionality.

Cutlass should be easy to use, without excessive configuration required.

Cutlass should be expandable, offering the ability to add new
protocol types and services as new usage patterns pop into
existence.

Cutlass must be secure, with mandatory encryption, assuring
communication confidentiality and integrity.

Cutlass must use a respectable trust model, and keep it as
easy to use as possible.

Cutlass should provide a pathway for clients behind firewalls or
NAT servers to communicate with each other.

Cutlass must be useful, with support for at least the following types
of common use:
 - Messaging 
 - File transfer
 - Voice communication

Cutlass should not require a central server in order to

Cutlass traffic should be efficient, with minimal overhead beyond
that needed for session encryption/negotiation.

Cutlass traffic should be as resistant to traffic analysis as
feasible.

Cutlass should be easy to interface with, providing library bindings
to the functionality.  This will enable enterprising hackers to
code such delicacies as skinnable GUIs, search functionality, and other
things we haven't thought of yet.  We aim to provide a wonderful
vanilla client, but time is limited, and clean module interfaces will
enable us to focus on core functionality at start-up. Plus, clean
interfaces encourage good code hygene.

3. ANTIGOALS
Cutlass will not aim to provide the following functionality as prime
motivators, although where possible, it will allow for them:

Cutlass is not required to link all Cutlass peers deployed into a
large global "Cutlass space," similar to the Gnutella network. We're
aiming for usable networks of at least 50 nodes, but if we can
scale larger, we'll certainly try to. Aiming for trusted groups as
a first audience, however.

Cutlass does not require that all participants stay as anonymous as
possible with respect to each other. By default, all participants
connect directly to each other, obviating anonymity. Where possible,
we will provide anonymity options through the message forwarding
and chaffing options, but it is not considered primary functionality.

4. DECISIONS

One of the hardest decisions to make early on was to make Cutlass
UDP-based. This increases the programmer workload on certain
functionality, such as file and message transfer. Why, then?

The primary driver is the prevention of traffic analysis. TCP is
lousy for loss-tolerant communications, such as voice and video.
By running the whole thing over UDP, and providing our own reliability
services, we can drop packets on some capabilities, and retransmit on
others, while keeping the whole stream relatively opaque to outside
snoopers. (Not completely opaque. Timing analysis will likely reveal
info, but we can finesse the timing in later releases). Thus, UDP
it is.