\chapter{Advogato}
\label{advogato}

We have implemented the group trust metric described in
Chapter~\ref{groupmetric}, and deployed it as the key part of the
Advogato website. In this chapter, we describe the implementation,
analyze the data collected, and present some observations on lessons
learned.

The Advogato website launched in November 1999, and has been in
continuous operation since. It serves as a community message board
for free software developers. The heart of Advogato is the
certification mechanism, essentially a straightforward implementation
of the group trust metric.

\section{Implementation overview}

Advogato is implemented as a C-language Apache module, available under
the GNU General Public License.

Internally, mod\_virgule is heavily based on XML. All of the account
information (including the peer certifications), diary entries,
articles, responses, and project information is stored in the
filesystem in XML format. To handle a request, mod\_virgule
dynamically generates HTML from these XML files. The content varies
slightly if the user is logged in, as determined by the standard HTTP
cookie mechanism.

Advogato extends the yes/no evaluation of the trust metric presented
in Chapter~\ref{groupmetric} to three levels, entitled Apprentice,
Journeyer, Master. Each certification edge has an associated
level. The underlying trust metric is run once for each level. For a
given level, edges below that level are discarded. For example, to
compute the Journeyer level, the underlying trust metric is run on the
subset of the trust graph consisting of Journeyer and Master
edges. The final certification assigned to the node is the maximum
level for which the node is accepted.

Trust ``seed'' is hard-wired. In practice, hard-wired seed hasn't
caused problems, but it is a concern. Providing user-configured
alternate seeds is a possible extension, but the need for it hasn't
been strongly felt.

\section{Implementation details}

One motivation for the implementation choices was to experiment with
the platform provided by the Apache module interface. C is not a
popular language for implementing Web sites. Yet, our experience has
been quite good.

A core feature of the Apache platform is the use of resource
\emph{pools}. In a pool discipline, memory and other resources are
allocated from an explicitly identified pool. At some later time, when
all memory allocated in the pool is known to be unreachable, the
entire pool is freed.

Pools have been used for
a long time. Ross\cite{Ross67} presented a storage package with
explicitly identified \emph{zones}, roughly equivalent to Apache's
pools. There has been a fair amount of recent interest in providing
explicit language support for pools, including extensions to the C
language\cite{gay01language}, theoretical language
designs\cite{crary99typed}, and the ML Kit compiler for Standard
ML\cite{tofte97regionbased}.

In the case of Apache, there is no explicit language support. Rather,
allocation functions take an additional explicit pool argument, and
are called using the standard C runtime discipline. For example, the
low level memory allocation function is:

\begin{texttt}
void *ap\_palloc (struct pool *p, int nbytes)
\end{texttt}

In the context of mod\_virgule, most allocation is done in a
\emph{request pool}, which has a lifetime exactly equal to one Web
request. When the request is complete, the Apache process frees the
request pool, and typically becomes available to serve the next
request.

The pool discipline is appealing in many ways. When properly used,
memory management is nearly painless. Further, memory leaks are rare.
These advantages are similar to those provided by garbage collecting
runtimes, but with several advantages:

\begin{itemize}

\item Finalization is deterministic.

\item There is no need for language or runtime support.

\item Time and space overhead is minimal.

\item The discipline interoperates easily with external libraries.

\end{itemize}

The last of these points is demonstrated by mod\_virgule's use of
libxml\cite{DV}.

\section{Experimental results}

Provide data about graph: number of active nodes in trust graph (>
1000), number of Apprentice, Journeyer, and Master nodes. Also present
distribution of capacities of nodes. Average capacity of accepted
nodes is related to vulnerability of trust metric in the face of
random attack.

Maybe visualize Master sub-graph, although it's already too tangled to
see much.

One conclusion: manually creating certifications to build a trust
graph is realistic, if there is some expected payoff.