\documentstyle[12pt,timrom]{article}

% $Author: brlewis $
% $Source: /afs/athena.mit.edu/astaff/project/lucydev/design/RCS/lucy.tex,v $
% $Header: /afs/athena.mit.edu/astaff/project/lucydev/design/RCS/lucy.tex,v 1.1 90/12/05 16:32:04 brlewis Exp Locker: brlewis $
% Copyright (c) 1990, Massachusetts Institute of Technology

\title{Design issues for lucy}
\author{Bruce R. Lewis}
\date{\today}

\addtolength{\oddsidemargin}{-.5in}
\addtolength{\evensidemargin}{-.5in}
\addtolength{\textwidth}{1in}

\begin{document}
\maketitle
\tableofcontents
\newpage

\section{Overview}

This document is intended to speed the design of the lucy system; it
is not intended to be a publishable paper describing a finalized
design.  The goal here is to give readers a clear idea of what lucy is
trying to do, and what issues in the design need to be discussed.

A lot of what we eventually decide is ``a good thing'' for lucy to
have will not be possible to implement by January, when it is intended
that lucy come into actual use.  But knowing what we want to add later
will help lucy be designed in such a way as to facilitate later
expansion.

The lucy program is not yet available, but the following
paragraphs describe what it will be like:

Lucy is an electronic ombudsman, ready to receive questions of all
kinds from the community at large. Any member of the MIT community may
ask a question on-line, ranging from ``I'm new to the area. Where is a
good, moderately priced restaurant suitable for an evening out?'' to ``I
recently stole a small amount of cash from a fellow staff member. No
one suspects but I'm feeling horribly guilty. What should I do?''

Communications will be anonymous, unless the sender chooses otherwise.
A subset of lucy questions and answers will be available on-line to
the community for browsing (with the sender's permission only and with
all potential identifiers removed). Starting in late January, anyone
wanting to communicate with lucy will be able to submit a question by
running an application that will be available as a pre-login option on
any Athena workstation. (An Athena account is NOT required.) Even if
the user logs in before sending the question, the username will be
removed from the message before it is sent to lucy, so that it will be
sent anonymously unless a name or other identifier is explicitly
added.  Questions which include the sender's name may be answered
personally, while questions with no identifying information will need
to be read in browsing mode.

\section{User interface for asking a question}

\subsection{Requirements}

The entire MIT community needs to have anonymous access to lucy.  The
easiest way to implement this is through mail, but given universal
access to dialup machines, other channels might be possible.

The Athena interface needs to allow the user to edit a question
easily, and should include an explanation of how to get a private
reply.  Mail might be used as the underlying mechanism for the Athena
interface, or some other mechanism of better reliability and anonymity
might be used.  Either way, the interface needn't be any more
complicated than sendbug.  It should be usable from dialup or as a
pre-login application under xlogin.

The pre-login interface should allow an option for browsing.

\subsection{Xlogin issues}

Tty pre-login applications, like techinfo, come up in an xterm with a
very large font.  This may not be appropriate for lucy, in that such a
large font is easy to read from a distance.  Users entering questions
under xlogin should be able to be more discreet.

Xlogin prevents users from leaving a workstation idle with a pre-login
tty application running by periodically checking the idle time on the
tty, and killing the application if it's been idle too long.  Doing
the same thing with lucy means making users edit questions with
\verb+emacs -nw+, which makes sure emacs is connected to a tty, but
disables positioning the cursor with the mouse or arrow keys.  This
would probably be disconcerting for most emacs users.

\subsection{Present design}

The script \verb+/mit/lucydev/bin/ask+ fulfills the minimum
requirements, but doesn't address the xlogin issues.  The script
\verb+/mit/lucydev/.xlogin+ presently only tells the user that lucy
isn't ready yet, and what it is.  Here's a conversation with the
current \verb+ask+ script:

\begin{footnotesize}
\begin{verbatim}
Right now, lucy is being experimented with by Athena staff, so your
please don't send questions of any personal nature.  Only send a
question if you're testing the system.

You will edit your question in emacs.  To exit emacs, first hold down
the Ctrl key, then press the x and c keys in sequence, then release the
Ctrl key and press y.

Press Return or Enter when ready to compose your question.


Please enter a one-line subject for this question.  The subject line
will help Lucy handle your question better, and will help you find your
question if it should appear in the public discuss meeting later.
 --> 
Any subject will do (e.g. Perplexed in Peoria).
 --> Forced to Enter Subject line in Cambridge
If you have identified yourself in your message, lucy is able to reply
to you personally.  Would you like lucy to do so?
 --> 
Any answer will do (yes, no, maybe, only if ...).
 --> I haven't identified myself.
If you permit it, lucy will publish your question/answer with any
identifying information removed in a browser viewable by anyone.  If
you chose not to receive a personal reply, this is your only means of
seeing the answer to your question.  Would you like your
question/answer to be published?
 --> no thanks
Your question has been sent to Lucy.
\end{verbatim}
\end{footnotesize}

The above dialogue will produce a question that looks something like this:

\begin{footnotesize}
\begin{verbatim}
[0015] daemon@ATHENA.MIT.EDU  Lucy_experimental  12/06/90 10:34 (6 lines)
Subject: Forced to Enter Subject line in Cambridge
Date: Thu, 6 Dec 90 10:33:58 -0500
To: lucyx-mtg@euphrosyne.LOCAL

Like, do you really expect us to believe that this is anonymous?
SEND PERSONAL REPLY:  I haven't identified myself.
PUBLISH QUESTION/ANSWER IN BROWSER:  no thanks
\end{verbatim}
\end{footnotesize}

\section{Interface for Lucy administrator(s)}

\subsection{Basic requirements}

The interface should be usable from dialup, so that Lucy doesn't need
to have a workstation in her office or come to a public cluster to
work.  But Lucy shouldn't need to be especially quick with computers
to use the interface.

\subsection{Examining the queue of questions}

Lucy needs to be able to quickly see

\begin{itemize}

\item how many questions are in the queue
\item when each question was submitted
\item the status of each question
	\begin{itemize}
	\item new
	\item forwarded to an expert
	\item tentatively answered (not necessarily published or returned)
	\end{itemize}
\item the subject line for each question
\item the content of any individual question
\end{itemize}

\subsection{Forwarding a question}

Experts may not have athena accounts, so this has to be done by email
if it is to be done electronically at all.  It should work like
\verb+forw+ in mh, only instead of inserting a mail message, a
question, a space for an answer, and instructions for answering are
inserted.  Even if forwarding is done with, say, interdepartmental
mail, there still needs to be a command for logging the fact that a
question has been forwarded.

\subsection{Answering a question}

Should Lucy choose to answer a question herself, it should be easy to
bring up a form with the question and a space for the answer, so that
any identification can be removed before the question/answer pair is
published.

An answered question should be easy to publish in the browser, at
which point it should be removed from the queue and put in the
archive.

At the present time, lucy would like to be anonymous.  This presents a
problem in the current implementation of discuss, because anonymity,
although possible, is linked to inauthenticity.  However, users who
post things for the browser must be authenticated, or anyone could
post a bogus question/answer pair.

\subsection{Present design}

The plan is now to write Lucy's interface with the ss library, the
same library used for discuss.  That doesn't mean the interface will
be exactly like that of discuss; the syntax will be more like that of
mh.  Perhaps a curses interface would be more appropriate; if so,
effort would be best spent expanding the ss library to do curses,
rather than writing Yet Another Probably Flakey Curses Interface.

Here's what it looks like now:

\begin{footnotesize}
\begin{verbatim}
Available Lucy requests:

quit, exit, q            end this session
status                   count questions in queue
list, scan               list questions in queue
show                     display a question (and related info if appropriate)
answer, repl             answer a question
forward, forw            forward question to be answered by someone else
publish, post            publish question/answer
help, ?                  redisplay this menu
Lucy:
\end{verbatim}
\end{footnotesize}

\section{Implementing privacy}

The only mechanism implemented so far is to provide user anonymity by
having \verb+dsmail+ strip all the headers from a mail message except
the subject and date lines.  This mechanism is questionable for the
following reasons:

\begin{enumerate}

\item Email is not considered completely private, especially if for
some reason a message should become a dead letter.
\item Sendmail by default logs the senders of incoming messages before
the messages are piped to \verb+dsmail+.
\item There is no provision for someone who wants an anonymous
personal reply.
\item How does Lucy remain anonymous while authenticating herself to
discuss?  Does she want to remain anonymous when dealing with experts?
If so, where do their email replies go?
\end{enumerate}

[We'll have a group discussion about the relative seriousness of these
problems at the design review.]

The rest of this section introduces some possible solutions, none of
which are set in stone.  In fact, it may be too difficult to implement
any of them by January.  But it's good to discuss them now so that
whatever solutions are eventually implemented can be integrated
smoothly into what exists.

\subsection{Privacy through public-key encryption}

If the question-asking mechanism encrypts the question with lucy's
public key before sending the question across the network, lucy can
then use a private key to decrypt it.  The implementation of
such a scheme is completely open to discussion.

\subsection{Anonymity through an anonymous server}

Suppose a user doesn't want to identify himself to lucy, and also
doesn't want his question published in the browser.  The present
scheme doesn't allow for that, as the sender isn't stored anyplace
where the system can use it.

Say, for example, mail was used.  A server could be set up so that you
could send mail to lucy@anonymous.LOCAL, and your question would be
forwarded as if it were from, say, sender90125@anonymous.LOCAL.  It
could be replied to without Lucy ever learning who the sender was.

[This still leaves open the dead letter problem, but if mail is
unacceptable, we can come up with other means.]

\end{document}
