[tahoe-dev] Resurrecting Mojo Nation

[James A. Donald]

On 2012-06-14 6:00 AM, Brian Warner wrote:
> On 6/9/12 9:07 PM, Jack Byer wrote:
>    Users were
>    accidentally encouraged to hoard Mojo (the client displayed your
>    balance like a game score, users sought to maximize that number more

This was an incorrect diagnosis of the problem.  The Mojo Nation team 
were thinking like Keynesians.

If markets are failing to clear, prices should fall.  Even if users are 
hoarding mojo, at some sufficiently low price point, supply and demand 
will match.

Hoarding money can never be a problem, for that is what money is for. 
You are *supposed* to hoard money, otherwise it would not be worth 
anything.  Gold is not good for much, other than hoarding, and 
government paper is good for even less.

Failure of price discovery is frequently a very large problem.  Price 
discovery is always arduous, laborious, costly, slow, and not very 
accurate, something Keynesians blissfully ignore.

> For Tahoe, we reduced the scope, threw out the economic games, and
> narrowed the use-case to commercial grids and friendnets (where uptime
> is more predictable). Bittorrent did the same, reducing the scope to
> short-term transfers instead of long-term storage. Both have achieved
> their own smaller goals.

Bittorrent, by focusing on short term exchange of like data for like 
data, has, as was expected, a permanent and massive seeding problem.

It is not apparent to me that Tahoe has achieved the goal of reliable 
storage on friendnets.  Too large a friendnet, anti social behavior 
makes the net unreliable, too small a friendnet, k of n storage runs 
into the problem that k and n are small making the net unreliable.

The problems that Mojo Nation sought to solve are still there, unsolved, 
and pissing people off.


> * overambition is still a big problem.

Xanadu disease.

> * measuring/predicting reliability of storage nodes is still an unsolved
>    (and possibly unsolveable) problem. You need servers to stick around
>    for a long period of time, otherwise repair costs will swamp your
>    bandwidth and leave you no room for real traffic. Needing long-term
>    servers interacts badly with adoption (you want to encourage
>    experimentation, folks who want to install it just to play around with
>    it should be able to do that quickly, but you can't afford to use them
>    as servers, since many of them will get bored and delete it or let it
>    break the next day, so they don't really get the full experience, so
>    they may not really be motivated to stick around). As a client you
>    need to distinguish between good servers and transient ones, so you
>    really want everyone to monitor and publish uptime data on each other,
>    but they could be lying, which gets you back into the reputation graph
>    thing. There's been a lot of work on reputation graphs (starting with
>    Raph Levien's Advogato, and motivated by EBay and Amazon), but I don't
>    know how much of it is buried in proprietary/closed codebases (since
>    it's easier to game a system when you have the source) vs being
>    available as an off-the-shelf library.

Any reputation system will have good inputs, evil inputs, insane inputs, 
and evil insane inputs.  The evil or insane inputs will be rated as good 
by fellow members or sibyls of each evil or insane faction, so we will 
get graphs that are by some measure, in some sense, disjoint.  If one 
starts at a good node in the good faction, reflecting a well known good 
guy, everyone well linked will be good, thus connection analysis of the 
reputation graph generates faction subgraphs.  Faction subgraphs will 
typically have important highly connected nodes.  Mencius refers to such 
nodes as Kings.  You give your allegiance to a good King, and your 
problem is solved.  You give your allegiance to a bad King, you are 
hosed.  The graph analysis system may help you find a good King, but 
cannot reliably find one for you, because whatever criteria it uses will 
be gamed by the evil.

A simple solution is to bake a single king node into the client software 
- otherwise known as a central point of failure.  A default king node 
will, however, work, or at least fail less disastrously than a baked in 
king node.


> * do people really want remote storage? Why? One reason is to get access
>    from their data from elsewhere (sharing with friends, using it from
>    someone else's computer,

People don't really want remote storage.  They want file sharing, in 
some cases highly controlled sharing - sharing with only with themselves 
at different logins, only with other instances of themselves, being a 
special case of controlled sharing.

Thus, it is a communication and publication system, not a hard drive.