From: hal@finney.org
Date: Mon Jun 11 2001 - 12:30:19 MDT
Here is a posting from Jim McCoy, CEO of AZI, the company behind
MojoNation, talking about their efforts to downplay the visibility of
Mojo in the operation of their software. (Mojo is their "play money"
virtual cash.)
> Awful, bitter truth time: you are never going to see a mojo total again.
> We are aiming for a distributed load balancing system that uses the paris
> metro pricing model to direct queries to unloaded peers and attempt simple
> QoS (c.f. http://www.research.att.com/~amo/doc/paris.metro.minimal.txt)
>
> Some coins will still be moving around in the background, but users will
> only know that they have a mojo surplus by a small note on the broker
> telling you that "you have good network karma"; performance benefits should
> become the side-effect of reaching this point because your broker can start
> to jump ahead in queues and continue to get fast service from popular
> brokers.
>
> Yes, this does take some of the fun "game" aspects out, but we think that
> the long-term benefit is going to be worth it. For starters it means that
> the public prototype network will become less and less reliant upon AZI and
> our servers. Some recent chances in how contact info is cached and
> exchanged are our first steps toward the "gossip" metatracker system we have
> described in the past.
I don't fully understand the technical aspects of this change, how hiding
the Mojo totals will improve the load situation on AZI's servers, etc.
I think to some extent they have been plagued with people trying to hoard
and/or steal Mojo, perhaps in the hopes that it would be worth something
someday, and perhaps they are trying to discourage this behavior.
I think their current plans are to treat Mojo as more of a "tie-breaker",
with most requests handled by simple queueing, and the use of Mojo to
jump ahead in the queue only when there is congestion.
Andrew Odlyzko's Paris Metro pricing article referenced is interesting.
Seems that at one time, Paris Metro trains had identical cars for first
class and second class. Same number of seats, same basic quality, etc.
The only difference was that first class cost more. So automatically
the first class cars were less crowded and perhaps in slightly better
condition as a result.
MojoNation hopes to apply the same idea to the net. As an example,
lately Napster has gotten pretty hard to use. The filtering is in place
and you can't find any recent songs. Well, there are other servers
accessible using a program called Napigator (similar methods exist for
non-Windows OSs). However, these servers are usually full and you have
to try a bunch of them to find one which will let you in.
Imagine that these alternate servers, instead of providing say 1000 open
slots, had 500 free slots and 500 for-pay slots. The free slots would
be available as now, but the for-pay slots require you to give some Mojo
(or dollars, if ecash existed). Then automatically the for-pay slots
would be less crowded than the free ones. You could either be patient
and wait to get in on a free slot (probably via a script which hammers
the server with repeated requests), or you could pay and have a good
chance of getting in.
This seems like a pretty good model for MojoNation, but the part I don't
understand is why they would downplay the Mojo total. If this system
becomes popular, it's going to be very important to keep track of how much
Mojo you have, just as it is important now to keep track of how much money
you have. You can't just leave it up to your software to transparently
bid and pay on your behalf, you have to be guided by how much Mojo you
have left. Otherwise you'll be like the bumper sticker says, how can
I be overdrawn when I still have checks? Knowledge of your financial
status is crucial in determining how much you can afford to spend.
I'll have to ask about this on the MojoNation list. It might just be
a temporary measure to try to get people to stop cheating and stealing
Mojo. I don't see how it can work in the long term.
Hal
This archive was generated by hypermail 2.1.5 : Sat Nov 02 2002 - 08:08:04 MST