[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.
_______________________________________________
tahoe-dev mailing list
tahoe-dev at tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE