[fc-discuss] Financial Cryptography Update: The Mojo Nation Story - Part 2

iang@iang.org iang@iang.org
Wed, 12 Oct 2005 18:23:15 +0100 (BST)


((((( Financial Cryptography Update: The Mojo Nation Story - Part 2 )))))

                            October 12, 2005


------------------------------------------------------------------------

https://www.financialcryptography.com/mt/archives/000572.html



------------------------------------------------------------------------

<i>[Jim McCoy himself writes]</i>  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.

<b>Jim</b>

-- 
Powered by Movable Type
Version 2.64
http://www.movabletype.org/