October 12, 2005
The Mojo Nation Story - Part 2
[Jim McCoy himself writes in response to MN1] Hmmm..... I guess that I would agree with most of what Steve said, and would add a few more datapoints.
Contributing to the failure was a long-term vision that was too complex to be implemented in a stepwise fashion. It was a "we need these eight things to work" architecture when we were probably only capable of accomplishing three or four at any one time. Part of this was related to the fact the what became Mojo Nation was originally only supposed to be the distributed data storage layer of an anonymous email infrastructure (penet-style anonymous mailboxes using PIR combined with a form of secure distributed computation; your local POP proxy would create a retrieval ticket that would bounce around the network and collect your messages using multiple PIR calculations over the distributed storage network....yes, you can roll your eyes now at how much we underestimated the development complexity...)
As Bram has shown, stripping MN down to its core and eliminating the functionality that was required for persistent data storage turned out to create a pretty slick data distribution tool. I personally placed too much emphasis on the data persistence side of the story and the continuing complexity of maintaining this aspect was probably our achilles heel, if we had not focused on persistence as a design goal and let it develop as an emergent side-effect things might have worked but instead it became an expensive distraction.
In hindsight, it seems that a lot of our design and architecture goals were sound, since most of the remaining p2p apps are working on adding MN-like features to their systems (e.g. combine Tor with distributed-tracker-enabled BitTorrent and you are 85% of the way towards re-creating MN...) but the importance of keeping the short- term goal list small and attainable while maintaining a compelling application at each milestone was a lesson that I did not learn until it was too late.
I think that I disagree with Steve in terms of the UI issues though. Given the available choices at the time we could have either created an application for a single platform or use a web-based interface. The only cross-platform UI toolkit available to us at the time (Tk) was kinda ugly and we didn't have the resources to put a real UI team together. If we were doing this again today our options would include wxWidgets for native UI elements or AJAX for a dynamic web interface, but at the time a simple web browser interface seemed like a good choice. Of course, if we had re-focused on file-sharing instead of distributed persistent data storage we could have bailed on Linux & Mac versions and just created a native win32 UI...
The other point worth mentioning is that like most crypto wonks, we were far too concerned with security and anonymity. We cared about these features so we assumed our users would as well; while early adopters might care the vast majority of the potential user base doesn't really care as much as we might think. These features added complexity, development time, and a new source of bugs to deal with.
Back to Part 1 by Steve.
Posted by iang at October 12, 2005 01:19 PM
In the brainstorm/study phase of ePointSystem development, we had a hard look at MojoNation, as our primary goal was -- and to some extent remains -- a workable community currency for p2p services.
As a reason of failure, we pinpointed hyperinflation. MN had no anti-inflation measures and in due course, mojo got inflated into oblivion.
It's interesting, that you don't even mention this financial aspect.
I would probably disagree with this point. The reason inflation occurred is that we swallowed too much "open market" BS and let users set their own prices for services. For core messaging protocols (e.g. our "Hello" message used to establish a connection) some clever users figured out that they could steal everyone else's credits by setting an outrageously high price for responding to this message. Responding to this problem required us to hand out more credits to existing users.
OTOH, there is a good case to be made that dynamic pricing is a losing proposition with boom and bust cycles in a network where most services are zero-cost (e.g. if I don't use my bandwidth now I can't save it up for later use.) Take a look at the problems encountered by the early deregulation of the electricity market as an example and then remove the high capitalizatoin costs for bringing new capacity online and you have an idea of how hard this would have been to actually accomplish.
In the later iterations of the tech the pricing was divided into two categories: respond to this request "whevener" (no cost to purchaser) and "do it now" (dynamic pricing.) The intention here was to keep a lid on the dynamic prices. Unfortunately we never really had a chance to test this bit out in the wild for very long.
I could probably have spent more time discussing the "financial" failures of the system, but I think that some of the issues are still being resolved, some lack any real data to back up conclusions, and the rest would have required another long posting that I don't really have time for...
Price control provably results in market failuers. Capping prices does not prevent inflation, just transforms it into shortages (been there, seen that -- again and again).
Inflation is always caused by the issuer. People putting high pricetags on certain services should have not been able to sell them at that price. The mojo hyperinflation was a textbook case of issuer failure, in our opinion. What you describe is perfectly consnistent with this assessment.
I think there is a big difference between macro theory and practice, and that which is seen in startup and evolving markets. Yes, capping prices and overissuance causes all sorts of problems, but when a market has not reached a full competitive status, normal competitive pressures won't be felt.
I'd say given all I've read that Mojo Nation never made it to the point where it exposed full competitive market processes. Somewhere someone said one of the problems was that very few people ever downloaded any content; in such a place, the market wasn't one of supply and demand, it was more one of download and hack the system.
So I'm not convinced about inflation and prices. Still, I wasn't there, which was why I was bothering these gentlemen to get it down on paper in the first place :)
Before sketching the design for ePoints, we sat down with Agnes in her apartment and analyzed the stories of as many failed on-line payment systems as we could, in order to avoid their mistakes. It took several all-day brainstorming sessions. Mojonation was one of these systems, and what information was accessible about it suggested that they got sucked into the vicious circle of self-perpetuating hyperinfation:
First, they allowed some unbacked currency into the market -- mojo was handed out without any service in exchange.
Then prices started crawling up, as those gouging the prices did not feel the pressure of diminishing demand.
Suddenly, precisely as described above by Jim, the operators found a system with an insatisfiable thirst for mojo, and they had to keep pumping mojo into it, just to keep it running. Classic case of a runaway hyperinflation, IMO.
I think, the lack of content was not the root cause of failure, but a consequence of mojo monetary policy. Offering valuable content for download should have been the only way of earning mojo.
Then I would suggest that you have taken the wrong lesson from MojoNation or have bought into some sort of vision about how what the world really needs is a p2p digital cash system... (I know that we did at one point.) Inflation really had nothing to do with the problem, and if that is the lesson you take away from our experience you might end up repeating our mistakes.
You might want to check out the essay written by Bryce Wilcox-O'Hearn (aka zooko), one of our key coders at the time, that you can find at http://zooko.com/zooko_stuff.html for more info on the structural & implementation problems we encountered and how this turned the micropayment system into a development distraction rather than a useful feature.
Eiither way, good luck.
Thanks for the link! And yes, I have bought into the vision that the world desperately needs a p2p cash system. Without one, e-commerce will remain a major PITA.
The thing that disappointed me about MN was that originally, Mojo was going to be worth something. There would be genuine value and scarcity associated with it. Then everything went wrong. Due to bugs in the system and some shady operators, people found ways to steal Mojo from other players. They were hacking their clients to exploit features of the protocol that didn't work well in an adversarial environment. So MN had to start giving Mojo away to its testers, and pretty soon you could get as much as you wanted.
The ironic thing is that the only reason people tried to steal and horde it was because they hoped it would someday be valuable. That never happened, in part because of the effects of their own actions.
I agree with Daniel that the lesson isn't that markets don't work or that financial mechanisms can't allocate scarce resources. Rather, the MN software was just too immature and buggy, and it had too many built-in assumptions and automatic responses that could be exploited by a savvy peer.
Related to this inflexibility, some desirable Mojo flows were restricted by the system. It distinguished between publishers, who provided disk space and bandwidth, and content creators. That's good. But sometimes content creators might want to pay publishers to get their content out there, and other times publishers might want to pay content creators for supplying valuable content. But the system didn't allow both directions of Mojo flow, it had a built in assumption about which one people would want to use (I don't even remember any more which one it was, but apparently the MN people never even thought of the other case).