On 6/9/12 9:07 PM, Jack Byer wrote:
Is it practical to go back to the original goal of MN instead of a limited subset if the reasons for the project's failure are addressed?
Great question! So, I wasn't at Mojo Nation (I was fascinated by the concept in 97 or 99 or whenever it made a splash, but never worked there, and only joined its descendant AllMyData in 2005, many years after MN ran aground). But my understanding was that many of the following contributed to its failure: * overly ambitious scope, would have required an impossibly good engineering and management team to implement everything * too much science needed inventing to make it work * real markets require diverse motivated players. MN users didn't bother tweaking agent behaviors, so you didn't get diversity. Users were accidentally encouraged to hoard Mojo (the client displayed your balance like a game score, users sought to maximize that number more than actually using it), so motivations were broken. * nodes were transient, so reliability was unpredictable 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.
Now, ten years later, automated trading algorithms are common so perhaps it would be possible for a network to use dynamic pricing to allocate hard drive space, bandwidth, and CPU power.
Are there any fundamental reason why a system like Mojo Nation couldn't work now that certain capabilities are available that weren't a decade ago?
I think Mojo Nation is still a promising idea, and I think it's got a better chance of working today than 15 years ago. Many of the challenges are still there, but yeah, some of them are easier to address: * overambition is still a big problem. Personally I'm trying to build Tahoe up to the point where we can re-introduce MN ideas, but it'll be a long road. Strive to break it into smaller pieces, make sure you can tolerate missing parts (if you fail to make progress on component A, are components B and C still usable?), develop some plausible use-cases first, start with the simplest thing that could possibly work, let the UI and user feedback drive the design * Bitcoin makes automated payment easier, for the tiny fraction of the world that is willing to use it, but it's probably the right way to go, and removes a big centralized engineering hassle (the MN bank). We need some better/safer wallet-control protocols (you want your storage node to have control over some small stash of BTC, and most of the bitcoin clients I've seen are aimed at human-scale transactions), like Purses in the Waterken/E/SES examples, but that's just engineering. I think MN's extend-pairwise-credit amortization is still important, since even with BTC's reduced friction (transaction fees) you don't want to be shuffling pennies every few minutes. * 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. * disk capacity and broadband speeds are faster. Unfortunately people are creating more data than ever, and disk speeds (seek times) are pretty flat. One metric is how long it takes to read out the full contents of a disk, or how long it takes to copy a disk over your internet connection: both numbers are kind of sobering (usually measured in days or months). Home internet connections remain very asymmetric, upload speeds are lousy. Disk prices are dropping, so distributed storage has to compete with cheaper local storage, which can be a hard sell. * 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, publishing to the world). Another reason is for backup. Both are handled pretty well by centralized solutions, especially when that solution (e.g. Facebook, Flickr) comes with some nice integrated display/edit/discovery/search tools for the data. A distributed storage solution has to compete with the incumbents, and many of the benefits of Tahoe/MojoNation-style storage aren't compelling ("no SPOF" isn't exciting when Facebook never goes down, "private" is not something a lot of those folks want or care about, "cheap" is competing with free-as-in-eyeballs). * backup is a question of inspiring confidence. Random servers run by strangers does not inspire confidence. Anyways, I think it's still a fun idea, but still big and difficult. I'd love to see someone charge ahead on it, but as a business I'd still consider it pretty risky. cheers, -Brian _______________________________________________ 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