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@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