\chapter{Trust Networks}

This system is built off some amount of trust in the other nodes of
the servnet.  In particular, the protocol supports some enforcement of
good practice by the other nodes, but there is still plenty of
opportunity for nodes to obey the rules until they are sufficiently
trusted, and then start breaking the rules in subtle ways. For
instance, a node might sometimes fail to provide a receipt to a
share's buddy during a trade, introducing confusion as to whether the
other side is trying to trick the buddy into believing that the share
had been traded away. More destructive would be for a node to never
query the buddy shares for any of the shares it possesses, or even
wrongly accuse a different node of losing that share. The list goes on
and on. However, with careful trust management, each node ought to be
able to keep track of which nodes it trusts; with the cushioning
provided by Rabin's information dispersal algorithm, only a
significant fraction of the nodes turning evil at once will result in
actual loss of files.

\section{Protocols for informing neighbors}
Each node needs to keep two values describing each other node it knows
about: trust and metatrust.  The first, trust, signifies a belief that
the node in question will obey the dictates of the Free Haven
Protocol.  The second, metatrust, signifies a belief that the
utterances of that node are valuable information.  For each of these
two values, each node also needs to maintain a confidence rating.
This serves to represent the ``stiffness'' of the trust value.  For
example, a node which has Trust 100 but Confidence 1 will be trusted
with a great deal of data, but will lose or gain trust rapidly in
response to the utterances of other nodes.  Exactly how these values
are used is left entirely up to each node.

Some nodes may wish to set all meta-trusts to zero, thus ignoring all
outside utterances.  Other nodes may wish to set confidence values
very high, ignoring not only outside utterances but also direct
evidence of wrongdoing.

Nodes should broadcast referrals in several circumstances:
\begin{itemize}
\item When they log the honest completion of a trade.
\item When they fail to verify that a buddy\footnote{See the Free Haven protocol design.} of a share they hold is safely held.
\item When the trust or metatrust in a node otherwise changes substantially.
\end{itemize}

\section{Getting information}
In addition to referrals, the trust system should gain information
from the operation of its own node.  Such information must be treated
as having a very high metatrust --- as we're talking to ourselves, why
would we lie?

The trust system should log all transactions between its own node and
others.  It needs this information to determine both when shares have
successfully expired and when shares have been deleted before their
expiration date.  

\section{Introducing new nodes}
One of the most important parts of the design of Free Haven is the
capacity to seamlessly integrate new servers. These servers need to be
able to join and participate in the servnet simply by installing some
simple packages and making contact with public servnet nodes.  Such
nodes (e.g. \texttt{freehaven.org} itself) have the option to
configure themselves as \emph{introducers}.  While nodes configured
with the default settings should ignore communications from unknown
nodes, introducers respond to such communications by querying the new
node for its public key and return address\footnote{Presumably this is
some sort of anonymous communications channel, such as a Mixnet.}.

Provided with this data, the introducer adds the new node to its
database, then broadcasts a referral of that node.  Other nodes are
welcome to do what they like with this information.  It is suggested
that the initial trust and metatrust values both be zero, with some
small amount of confidence in each.  The introducer may also wish to
send to the new node a referral for each node it knows about, thus
assisting in keeping the network as fully connected as possible.

From this point, it is expected that existing nodes will attempt to
offer trades to the new node, and vice versa.  

\section{Purging old nodes}

Old nodes need to be removed from use after a while, since continued
mail bombardment from the mixnet to a closed account will eventually slow
down the service (as well as anger a lot of systems administrators). 
On the other hand, any operation which can remove nodes from the servnet
must be handled very carefully, because it's easy to introduce security
vulnerabilities that let an adversary disable a node.

One solution is to allow the trust network to gradually lose trust in a
given node to the point that it doesn't ever send trade requests to it.
On the other hand, broadcast requests will still go to it. This means that
we might consider a sort of `ping' query for a node, to make sure that
it's still responding to its mail. On the other hand, this introduces new
denial of service attacks where a node might answer pings but not other
queries.  

Therefore, we've chosen to add a new behavior to the trust system.  As
the trust database logs all transactions, it is in a position to
notice when a multistage transaction fails to complete.  In cases
where such a transaction fails to complete, the trust system should
notice and mark that host as ``potentially dead.''  After a
potentially dead host continues to ignore queries for some time, it
should be marked ``presumably dead.''  A host should be removed from
the ``dead'' lists as soon as it reopens communications.

\section{When to trade}
While individual node administrators should be free to change this as
they wish, the default Free Haven installation should base its unit of
trust currency on the product of share size and storage duration:
megabyte-months.  Each host should also grant a small amount of
leeway.  This allows new nodes, for example, to be able to trade small
shares despite their 0-trust rating.  

A reasonable policy will balance trust-increasing trades with
low-confidence nodes against guaranteed-safe trades with high-trust,
high-confidence nodes.
