From: "Jon Leonard" <jleonard@divcom.umop-ap.com>
Date: Sun, 8 Sep 1996 13:32:21 +0800
To: cypherpunks@toad.com
Subject: Re: MUD anyone?
In-Reply-To: <Pine.3.89.9609010948.I361-0100000@pegasus.unicorn.com>
Message-ID: <9609080251.AA22510@divcom.umop-ap.com>
MIME-Version: 1.0
Content-Type: text


Mark Grant wrote:
> On Tue, 27 Aug 1996, Jon Leonard wrote:
> 
> > I've been planning to run a MUD like that, at mud.umop-ap.com port 2121.
> > I just don't have enough coded to be worth announcing yet.
> 
> Cool. What's it running under? I was planning to base it around the latest
> version of the Nightmare library for MudOS, which I just downloaded. If I
> can get a copy somehow I could start hacking on it. 

I've written the server from scratch, and don't have much of a mudlib at
this point.  The language is lisp-ish, although I'm planning to write a
parser for a c-like syntax.  It's properly tail-recursive, has explicit
continuations, and has associative arrays as a native datatype.

It's probably easiest for me to create an account on umop-ap.com for
anyone interested in collaborating with me.  If the consensus is that
starting with an existing MUD is easier, that's fine too.

> > Pseudonyms
> > Anonymous digital cash (issued by any pseudonym, not just "banks")
> > Public and private keys
> > Secret sharing
> > Anonymous broadcast & message pools
> > Anonymous markets
> 
> All sounds like good stuff to me... DC Nets as well, of course. I guess we
> should also simulate the Net somehow, with Web servers, email, etc. 

Are DC-nets useful for anything besides anonymous broadcast?  I'd probably
cheat on implementation unless there is some other property that I'm missing.

For network-related stuff, I've been considering a fantasy setting, but one
that allows for "magical" instantaneous long-distance communication between
any two objects.  Web servers wind up being persistent spells, email is
really easy, and so on.

> Though the Nightmare library apparently lets you create Mud objects which
> can access the Web so perhaps we can use the real one somehow (with the 
> obvious security implications).

I'm reluctant to involve the outside world in a MUD except as a source
of players.  This is partially due to security and extra programming
complexity, but mostly because I'd want to isolate the game from the
pressures that being a remailer or anonymizer brings.

> What else?
> 
> Protection Agencies
> Escrow Agencies
> Private Law Courts (probably controlled by players rather than the
> 	computer)
> Reputation Agencies

With the possible exception of Escrow, I'd make these player functions
rather than server functions.  They are important, of course.

There are a number of things in "Applied Cryptography" that I missed,
significantly:

Timestamping
Subliminal channels
Secure multiparty Computation
Blind signatures
Oblivous Transfer

> > What am I missing?  Should there be direct support for Jim Bell's
> > assasination markets?  It'd provide a means of demonstrating its
> > ineffectiveness as a means of social control.
> 
> I think it should be incorporated, but I think that people can set them up
> easily themselves. Perhaps we should have an NPC-run 'Assasins Inc' which
> would run the lottery, and then players could do the actual 'wet work'. 

It could be PC-run, too.  Then again, how can you tell the difference?

> But yes, I'd really like to see how this would work in the game. As I 
> said I'm thinking of this more as a semi-scientific experiment than a 
> pure game. We have some idea of how this stuff should work in theory, but 
> little of how it works in practice.

I'm still primarily looking at the game aspect.  After all, if it isn't
an interesting game, then there won't be enough players to get meaningful
results.  We need real humans making the various economic decisions in
order to reduce the consequences of programmer bias.

Also, there's the teaching possibility.  Where a simulation would only
appeal to those who are already of a libertarian bent, a working anarchic
MUD might reach others.

> I do think though that we'd have to enforce some kind of rule against
> 'disposable characters', otherwise people could simply create a new
> character every time they were killed trying to assasinate someone. There
> would need to be some disadvantage to just going in guns-blazing and being
> killed ten times in a row. 

If a new character is significatly weaker than an experienced character,
then this may not be a problem.  They simply wouldn't have enough of
a chance against a real target to be more than an annoyance.  Alternately,
having the game prevent new characters from starting fights with other
players stops this quite quickly.  That's what we did on the LPmud I ran.

I'd prefer that the only rules be against trying to bring down the server,
though.  What's the point of an anarchy with rules?

For the general problem of making player death costly, I'd been planning
on having some abilities reside in a "soul" and some in the "body".  If
a body dies, that's it for that body.  The player has to start over with
a new, untrained, body.  This can be a problem if, for example, the soul's
main fighting skill is with a weapon that the body isn't yet strong enough
to lift.

> > I think that for purposes of simulation, it's reasonable to model
> > cryptographic primitives in a "Trust the server" mode, because you
> > need to trust the MUD server anyway (unlike a government), and it
> > puts a much lower load on the CPU.
> 
> Yep, I agree. I would like to include the real protocols but it's going to
> be far too slow. So we could create, say, remailer objects, anonymous
> digital cash objects, etc. As long as they have the same properties in
> 'SimAnarchy' as they would in real life then the actual behind the scene
> mechanics don't matter. We could, perhaps, allow characters to break 
> protocols if they could accumulate enough processing power.

Since real-world stuff is apparently nearly immune to brute force, I'd
go all the way and make the game stuff truly immune.  Breakability is
a feature that just isn't worth the effort to code, especially since
we're interested in the consequences of unbreakable crypto.

> I don't know how low a level we'd want to go to. I think that having an
> explicit group of remailers (and 'IP rerouters') would be a good idea as 
> it would allow people to try to crack messages and perform traffic analysis. 
> Some remailers could be run by NPCs (some of whom would be trustworthy and 
> some wouldn't), others by the players themselves (with or without logging 
> enabled).

I could go either with that, or a net that really is secure and unsnoopable.

> I'd like to also include some way by which players could write 'software'
> even if they weren't able to create new objects for the game. So they could
> perhaps write front-ends for remailers and give them away or sell them to
> other players.

The obvious analogue to software in a fantasy setting is spells.  This
requries security of the server from arbitrary player code, but that's
been one of my design goals for some time.

> > There's also the question of log policy.  Having run a MUD for a few
> > years, I want to keep logs for bug detection.  A declared policy that
> > they aren't released for n years would work though.  Opinions, anyone?
> 
> Part of me thinks that we should explicitly state that anything may be
> logged and used in sociological research. Perhaps we could create some
> kind of secure protocol to allow users to connect without revealing their
> real identities, so that it wouldn't matter if they were logged?

A general disclaimer that anything can be logged is almost mandatory.
Logs are too useful for debugging.  Still, I'd prefer to periodically
trim the logs so that no one can meaningfully demand them.  Besides,
writings from a player perspective are probably better anyway.

Now that I think about it, having a character (player or non) who acts
as a historian and news service would be good anyway.

As for logging without real identities, that's not enough -- pseudonyms
can be recognized and outed by textual analysis.  A certain amount of
caution is always necessary if you're doing something that you wouldn't
want made public, but I don't want the MUD to require any more than that
fundamental minimum.

> Anyone want to set up a mailing list for this discussion?

How about mud@umop-ap.com?  I'm currently the only subscriber, but that
can be fixed.

> 	Mark

Jon