---------- Forwarded message ---------- Date: Thu, 20 Feb 2003 14:49:21 -0800 From: Jim McCoy <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [mnet-devel] A brief bit of history... [was Re: ecash]
On Wednesday, February 19, 2003, at 10:20 PM, Artimage wrote: [...] > Besides the fact that they didn't solve a specific problem. (I'm not > saying they didn't do cool things. But no one was hurting for a > solution > to the problems they seemed to solve. Or, also possible, I don't > understand the problem they were aiming at.) Ding! Ding! Give that man a cigar... There are really lots of problems to be dealt with in this space, ranging from legal/regulatory woes (are you a non-bank financial instrument or not, etc.) to the nitty-gritty implementation problems, to the inevitable "so what?" question to be answered. While I will avoid speaking about the Digicash case [okay, I won't :) -- DC was too early and did not want to deal with porn clearing, which is really the only money game in town at the time] I can say that part of the MN problem was looking at "p2p" too early. We were building a distributed storage architecture before Napster ever existed as the first step towards creating a sort of cypherpunk grid-services architecture to use a few buzzwords people might be more familiar with -- to put this in context, Doug and I were sketching out the basics of what would eventually become MojoNation back in '92 and were white-boarding ideas that later become MN in '95... The storage back-end (what eventually was MN and now lives on in HiveCache and Mnet) was needed as the first step towards a truly secure anonymous email solution I was working on. ZKS had received funding and seemed to be making waves, so we thought that a truly secure version of a penet-style anonymous email system might be a good idea. Besides, distributed storage had lots of potential uses if the mail idea didn't work. To do a decent distributed storage system among a group of completely untrusted peers you need some sort of distributed resource allocation mechanism, thus the need for Mojo. Along the way Napster rose up and we were swept along in the wake, thinking that Mojo would solve what was perceived as a big problem at the time: too many downloaders and not enough servers. Part of what made Napster possible (and why it didn't happen before, even though the ideas behind it are older than dirt and its architecture was only a small step beyond the simplest possible solution to the problem) was the fact that people suddenly had access to MP3 encoders and could rip CD collections. When Napster first appeared these encoders were complicated command-line tools so most people did not have their own CD collection ripped yet, with Napster's arrival it was easier to download your collection than to rip your own CDs. The consequence was that lots of people using Napster ran into slow downloads, overloaded servers, and a generally unsatisfying experience. Our new thinking at the time was that Mojo could solve this by compensating those providing the resources (in this case, bandwidth and the time needed to encode a music collection). By the time we had everything ready this problem had pretty much become a thing of the past. Encoders were a part of every music app and most people had already built up a sizable MP3 collection from either Napster or their own CDs. The first question should always be: what problem are you trying to solve here. This is why I think that micropayments and other distributed resource allocation systems are not a critical need for Mnet, but they might be worthwhile in the future and it is probably easier to re-attach the old code and keep it up to date than to rebuild this particular wheel when the time comes. This is also why I think the paris metro pricing model and "pay for preference" rather than "pay to play" that MN had at the end is going to be more useful and relevant to this discussion than the traditional ecash fantasies that sometime pop up when talking about this subject. Jim ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ mnet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mnet-devel
