The sort of read capabilities Kahn is talking about were the conerstone of the Xanadu project and its plans for handling copyright protection and payments for creators. Systems like Mojo Nation and Freenet create these sorts of absolute references (usually based on SHA1 hashes and the like) and flexible addressing schemes a la SPKI/SDSI deal with all of the namespace issues Kahn is talking about. This is basically a not-well-researched rehash of some old ideas; the bits of those old ideas which are of value are already being incorporated into systems, but the central registry/indirection via tollbooths bit is new and does not seem to add much real value to the users of such system.
jim
Swarm delivery is the way around bandwidth limits
on
Gnutella's Challenge
·
· Score: 4
One of the best features of Mojo Nation is that it breaks files up into smaller pieces so that when you want to download a huge file you are not blocked on the limited upstream capacity of the peer at the other end; each agent sends a small chunk of the file, allowing the peer retrieving a file to request multiple pieces in parallel and moving the download speed restriction back to the downstream capacity of the local connection. This sort of distribution system turns a pool of peers into a swarm of ants carrying small pieces of the content. RAID-like error correction protects against peers disappearing and allow for flexible choices about where to go for the pieces to the file. The new 0.920 release of the client starts to demonstrate the advantages this has over conventional peer delivery systems.
One downside to swarm delivery systems is that data is "published", simple sharing of a common filebase (a la Napster and Gnutella) is not possible. Someone has to upload the pieces to the system in the first place for them to be available because the system does not do the "let me take a look through your hard disk for things to give to others" kind of file sharing found in other P2P systems.
jim
Unfortunately, in my experience, MojoNation is still too early in development to be usable. It also seems to be too centralized.
Check out the new 0.920 version, just released yesterday! A much better install, faster and a lot less buggy as well. The centralization issue is being worked on (there is a single bank, although peers use micro-credit between any two counterparties so bank failure != system failure) and we are pushing things out to the edges as quickly as we can.
Part of the advantage we think we have with a market-based structure is that it is easy for us to be flexible about control decisions and letting local choices provide emergent behavior. For now, some stuff is centralized just because it was easier for us to do it that way and move on to the important bits that needed to get coded -- we are paying the price of this and going back to replace certain centralized features with most distributed solutions, but in the end it is simple for anyone to build a better mousetrap to solve a problem within Mojo Nation and replace an existing market actor by offering the other agents a better deal.:)
jim
What metric do you expect to use for this problem? There is a finite amount of space in which to store information and more information that we have space for. Something has to give. In the end it will always come down to making this sort of a choice. The name for this problem is "distributed resource allocation" and Freenet and Mojo Nation are two systems that at least consider this problem and provide a stab at an answer. Popularity is actually a pretty good metric for most things, and if you really want eternity storage then check out Mojo Nation where you can spend your credits to make sure that the one file you really care about sitcks around regardless of whether or not someone else reads it (by paying others for its storage of course...)
This is not erecting new barriers to publishing, it is lowering them and letting anyone get in on the action. Nothing is for free, but if people work together we can make the cost so close to free that no one will really care. In the end, you need to have at least some cost for publication or else you are just shifting the problem from one of publishing to one of filtering out all of the crap that everyone else is publishing (which turns into its own set of messy problems.)
The problem with doing dynamic content is that the P2P model fights against a lot of the basic simple assumptions a content provider can make in the current web model. We deal with these same problems in Mojo Nation and have been working on a few simple hacks for mutable content. Our data is basically a hash tree to preserve integrity (what you get is exactly what you asked for) but this means that when one comment changes the whole tree changes and the top-level ref is somewhere else; we could just point people to the new "master ref" for this tree and provide a slashdot-like experience but the tradeoff is that we are back to centralization.
The next step for these systems are to pass around the code to turn the database of objects (which P2P systems like Mojo Nation and Freenet are good at distributing) into something dynamic and structured on the local client. Imagine giving the user a chunk of the/. database for an article along with code to explain how everything should be formatted, etc. The presentation and organization is local (along with any dynamic effects) while the data is just a selection from the pool of possible objects. This would also mean that when you download the articles you can pre-load the higher ranked articles or use collaborative filters to trim out the bits you are not interested in and avoid having to download these in the first place.
Freenet has some good cacheing mechanisms in there but there is a balance which needs to be maintained between de-centralization (which provides the censorship resistant features of systems like Mojo Nation and Freenet) and dynamic information features that require a trusted codebase for execution. If Java had lived up to some of its hype perhaps we could be passing around dynamic objects that contained information and presentation all in one bundle and we would run these in our browsers without fear, but it just didn't turn out that way...
In Mojo Nation we deal with the same problems of herding cats, in this case it is a problem of how you can cache content effeiciently and effectively without knowing what is really going on. Markets are one such distribution system that has a very long history of people tweaking (and trying to cheat, therefore building up its protections against most types of fraud) and it actually does solve some of the problems you address. We are not as gung-ho on the whole "information must be free" bit as Ian, but we do know that these sorts of P2P systems are the ideal infrastructure for the next step in internet content distribution.
jim
Collaborative filtering is coming to P2P
on
Scour is Dead
·
· Score: 2
Being able to determine what is signal and what is noise within P2P networks (or any information system for that matter) is a non-trivial problem. Some efforts to make sense of everything are actually starting to become useful and get applied to these problems. RDF/XML (esp. the Dublin Core) is beginning to deliver some of the most basic claims made by the "Metadata uber alles!" crowd (which is one reason our metadata in Mojo Nation is XML based) and there are a few really sharp people out there who have been working on the distributed trust management necessary to pull off the rest of this trick. Raph Levien has some really good things to say about distributed trust metrics at Avagato that people interested in these sorts of issues should take a look at.
jim
Mojo Nation solves the leeching problem
on
Scour is Dead
·
· Score: 3
In Mojo Nation users must contribute some service to the system and thereby earn "Mojo" (karma) to exchange for download or relay credits. Everything is market-driven (bitstreams become just a commodity to be passed around) and the market is the best system yet devised to take a bunch of selfish, dishonest/distrustful actors and work towards a collective goal -- the market works.
The digital tokens used are the internet equivalent of the old upload/download ratios of BBS days applied to a distributed, decentralized P2P system. This isn't a "sharing" system, so it doesn't walk through your disk looking for things to give away; instead other users publish data to the system and it gets broken up into pieces, these pieces get RAID-like error correction and then they are sent out to other peers in the system. Downloads can use a swarm approach to pulling in data, taking a small piece from lots of peers (including those who might be on slow connections) rather than trying to shove the whole file down someone's (already overloaded) narrow upstream link.
Previous releases were a bit unstable, but the new 0.920 release that is available for download has a much better installer and significantly faster publishing and downloads. Check it out!
It is hard not to take this opportunity to point out that Mojo Nation (http://www.mojonation.net) is already out there providing most of what Bertelsman is demanding of Napster but with more flexibility and future potential. Check out our updated beta (version 0.919.0) for significantly improved download/publication speed and a much easier installation process. Win2k/NT support has also been added!
If Mojo Nation had a feature to limit total bandwidth used per day, or even better, throttle bandwidth (perhaps even dynamic throttling as a certain maximum is reached), it would be far more preferable to people in my situation!
We hear you. The first two bandwidth throttling features which will appear will be a flat "cut the line after X many bits in and out" and will soon be followed by the much nicer "just raise prices as we get closer and closer to the X bits/hour|day|week limit." One advantage of having a market behind things is that we can use pricing to signal resource availability. We will probably not have this in our.920 release for this week but it will be in the release following (e.g. it is on someone's to do list but the code is not done/checked-in yet so it won't be fully tested for our release later this week.)
The currency centralization issue is really the last hurdle we will need to clear and you bring up several good points about how we could screw this up if we wanted to. I will first try to answer your last two objections (because I think you are making a few incorrect assumptions about what is happenind and these are not really problems) and then hit the first two, which are potential problems that need to be addressed.
The anonymity/privacy of transactions are handled through two mechanisms, cryptography and credit. We use signed tokens as our "coins" and it takes a simple three line modification to the coin builder code to create blinded coins. This prevents us from watching our users' spending habits. The blinded coins are the crypto solution, but credit between peers makes observation difficult as well. Each agent actually establishes a line of credit with another agent and begins conducting transactions. A token exchange does not occur until the balance between two agents drifts outside the credit limit. This means that the bank sees only occasional bursts of activity. Determining what the coin exchange was for will be very, very difficult (and in fact it will probably be for lots of different services and transactions that occurred over a long period of time.)
Shutting down the token server will be harder than it first seems. For starters, you are incorrect in assuming that we are a US corporation. Autonomous Zone Industries is a Cayman exempt company, this choice was made a while ago because it made following the PGP/NAI crypto export route (publish a book and scan it in over in Europe) easier when US crypto laws were a problem. It is also quite simple for us to distribute the token servers. While a denial of service attack is not trivial we have tried to make the system less brittle than it first appears, for example the microcredit system that is running the show is lenient about the token server disappearing for a while, it will just up the credit limits a little and see if things keep working.
The fairness problem is an issue of trust. We plan on having third-party auditing of our procedures and simple issued vs. redeemed checks should prevent insider problems (a bigger cause for worry in terms of what happens in the real world.) We have bigger plans for this than something as simple as just another Napster clone, but for the moment we are asking people to trust us that we are not going to burn any credibility we have for a quick cash-out. If you crunch the numbers you will eventually see that there is not really much money in being the token server, but the marketplace which is created by the existence of a single token server can have all sorts of useful properties. I want to enable Intel to buy CPU cycles from you and everyone else in Mojo Nation on an as-needed basis and purchase a support contract for this service from yours truly...burning the consumer market is the last thing I want to do.
If AZI goes out of business then people would be able to create thier own coin systems, slot them in to existing code, and pick up the dropped baton.
Multiple currencies will be supported as a licensing option, but after giving this way too much thought over the past decade or so I am not so certain that people really want to make the "do I trust this currency choice." Our original plan during the design phase of the marketplace was that _everyone_ would act as a token mint, creating reputation-backed coins that others would exchange and redeem for services. This turns out to be a general nightmare in terms of system complexity. Trying to figure out a solution to this is what led to the insight that what was really needed was micro-credit between the peers. This peer to peer credit is reputation-based and uses the digital coins for settlement; what is happening in the background is that agents are trying to make these same sorts of trust and reputation decisions that you are talking about in a multiple-currency world but by using a credit system the agent only needs to deal with the currencies of agents with whom it actually conducts transactions. By tweaking the business logic you could create the sorts of trust distinctions you desire without breaking interoperability with the rest of the marketplace.
If you wanted to create your own little world of Mojo agents that traded their own currency nothing would prevent this. We are only creating a currency for use in the public market and are not trying dictate all of the possible uses for this system.
The voluntary part is our (still hidden from the UI and non-operational in Beta) PayLars function. This will let a user send a tip to the registered publisher and/or digital rights holder for a particular piece of data. That publisher/creator then converts this Mojo to dollars (or euros or cowrie shells depending on the local cost of a double espresso) or they can use it to make the cost of their next publication and content distribution cheap or even free.
You always have to pay for the download. That is the cost of getting service. Once you have the data things are a little fuzzier. If Sony wants to distributed a bunch of files locked up using InterTrust boxes then we work just great for moving the data efficiently. If the content escapes into "the wild" we still offer a backup solution. We also offer a solution to those who are not big name artists and who can't necessarily get Akamai to return their phone calls and who aren't willing to sell the car to pay for an InterTrust distribution license.
We know that this is not a final solution, but we are trying to keep future options open. If a good digital rights management solution is developed that people think is fair and just then we are ready. If nothing happens then we are still ready, albeit with a less optimal solution. If anyone else has a suggestion let us know and we will try to include it.
Will there be any means of increasing the redundancy on the basis of content type in future versions?
Yes. As you have noticed, the filesystem is market-based so that which is most popular is the most widely replicated data. An agent in progress(the "eternity agent") will let you give it a bit of Mojo and it will run around making sure that your blocks are still available and if it finds any of of the shares are missing it will reconstruct and republish the missing shares.
There is also a _lot_ of idle space out there. Back of the envelope predictions seem to indicate that once we pass the ignition point where the whole range of this SHA1 address space is covered in depth there will be enough spare disk blocks out there that any data which is even mildly interesting will stick around. One market opportunity for users who are sitting on lots of disk space but small connections to the net is to collect a narrow range of the filesystem but to great depth, then just charge a higher price for access to the less popular blocks.
Oh yeah, you can also increase the number of shares for each block to whatever you want, so that downloading a particular block is a "get 32 out of 64" operation for example. The particular error correciton code we are using means that 50% is still the target for number of pieces, but by making more pieces you spread the data across more of the SHA1 address space and increase the probability that someone is online who has the share you need.
Ah, yes there is a minor problem in that when you publish (do a good thing for the network as a whole) you get punished by being charged Mojo for the cost of publication. This is necessary to prevent the flooding attacks that could otherwise result from open/free publication.
The trick we are going to use in the short-term is that when you publish blocks you first publish them to your own agent to try to get the first resale hits from the blocks. If your agent has a reputation for posting blocks which tend to get resold then it is likely that this publish-to-self option will continue to work and your agent profits from the act of putting valuable data into the system. If you agent has no reputation or a bad reputation as a publisher then this will not work and you will have to front the cost of publication yourself.
One should also keep in mind that while we are tossing around numbers like 10,000 mojo for a publish or download these are intended to be very, very small numbers. We are hoping that publishing or downloading costs pennies per Gb as more participants join the network and competition drives down prices.
Mojo Nation always trys to act on local information (it is all that you can really trust) and if there is an economic incentive for a better strategy or new service then market pressure will favor anyone who creates it. For example, right now the network is rather flat and gnutella-like. Obviously this is a bad thing. The saving grace here is that as the network gets larger and there is an actual need to make smarter message distribution and cache choices these services will be possible.
Right now it does not make sense for the market to try to select the closest source unless it has a significant impact on performance. Making choices based on network topology, selecting what price lists you will present to a agent depending on its identity (e.g. being able to locally subsidize a worthwhile project or effort), these sorts of things are basic business logic decisions. We have created a skeleton set of these little rules, but as the market matures it will support whatever clever rules people can think up.
You are correct that there are problems with the fast and shallow analysis that you seem to present, so here are the fast answers to why these problems will not be the major problem that you claim:
1) You get credit for content you publish so there is an incentive to publish lots of random crap.
This is untrue. You do not get Mojo to posting content, you get Mojo for reselling blocks of data to others. In fact, in Mojo Nation there is a minor cost imposed for publication to prevent people from doing the sorts of stupid attacks which you mention. Mojo Nation is built assuming a society of dishonest, distrustful agents. Your agent doesn't get paid (by my agent) until you deliver the goods.
We are also working on a simple collaberative filtering system to allow users to filter out the bad metadata in the system. If someone publishes 3 gb of random noise it will get a few hits and the users will be able to pass back to the content tracker a complaint that the description did not match the content, as a few of these pile up the content description gets fewer hits on search requests and eventually the blocks fade away because no one will buy them.
2) What is the "price" of Mojo.
The reason I tried to avoid that question is that the answer is a little too complex to distill into a sound bite. A unit of Mojo represents a slice of the current capabilities of the system as a whole. If you perform work for me now I give you credits, in the future when the network is larger those credits will represent a slice of a much larger pie and so have increased in value when you spend them. If the network collapses (as you predict) then the only value of those credits are that the company running Mojo Nation will redeem them for storage/message passing service on our own systems.
The problem with quoting a "price" is that everyone will dig it up later and call you a liar for not being able to successfully predict the future product of several different unknown variables in this equation (how large is the network vs. total tokens in circulation, what is the raw replacement cost of the resources, what sort of discount are users willing to make on these resources to attract customers, what is the current demand for each resource in our basket [is bandwidth scare this hour, perhaps disk space?])
Mojo is a mechanism for keeping score in peer to peer systems. The real-dollar value depends on the demand for the services and the supply in the pool. Please don't claim that I am an idiot just because I have a basic understanding of which claims one can and cannot make regarding a future market condition.
...who own printing presses. In Mojo Nation there is no "big iron and bandwidth to host this stuff", that is all provided by the Mojo Nation infrastructure. In other words everyone contributed a part of this big iron and bandwidth and gets "paid" for the percentage they are throwing in to answering a request.
How about this for a possibility: what if the cost of pulication was next to nothing (but not zero or else it is too easy to flood the network) and the cost of distribution was paid for by the user who actually download the data. In other words almost no cost to publish to the net. In return for the faustian bargain I will allow users to be fair (by leaving a tip) which is about the only thing we have come up with yet for artist compensation, but if others have better ideas please let us know
Ryan knows this stuff, but for those in the audience who have not been hanging out in crypto and cypherpunk circles for the last ten years:
> Mojo Nation is from the same intellectual heritage
> as BlackNet/Eternity/etc., but I believe the
> foundations were laid at about the same time as
> the others, with implementation waiting quite
> a while for resources to be available.
The original genesis was the "Internet is a Brown Paper Bag" system created by myself, Doug Barnes, and Jerry Porter back in Austin and presented at the HoHoCon '94 conference. Things sat around for a while because we were waiting for two things: digital cash and a raison d'etre. At the time we did this early work connectivity and storage costs were expensive and there was no digital content to speak of. The growth of broadband and flood of digital content(music, video, images, etc.) made this arena more interesting several years ago so that is why we starting talking to lawyers to see if it would be possible to actually implement some of the wacky ideas we used to have.
A digital cash system was the sticking point. All great cypherpunk projects seem to begin with the line "when we have digital cash, we will be able to do X..." Our insight was in realizing that for a distributed system like what we really needed was a method for fairly allocating resources. We combined a cool idea to base a form of currency on payment in kind with a reputation-backed microcredit system to cut down on token clearing overhead and thus was born Mojo Nation.
One insight that Ryan has made which I hope others pick up on is that Mojo Nation is about more than just swapping music or pushing data. We are trying to create a basic infrastructure for any kind of peer to peer transaction, we just happen to think that trust management and resource allocation are the two important problems that need to be dealt with in this space and have targetted our micropayment system in this direction.
When content is published in Mojo Nation it goes through three steps before it becomes a small block of data which might be published on your host.
1) The file will be encrypted with the hash of the file. (feature in release 0.920 which will be out this week)
2) The encrypted file is broken into fixed-length segments.
3) These segments are pushed through an error-correction code, expanding the N bits into 8 N/4 length segments. (any 4 of the 8 shares are sufficient to reconstruct the orginal block)
These resulting block fragments are then published and are passed through the system. Each block fragment is only identified by its SHA1 hash, to reconstruct a piece of data you need a sharemap which tells you that if you collect a certain set of blocks and reverse the publication process using the instructions contained in the map you get the original file.
If you are holding blocks you have no idea what they are, it is effectively random noise on your system. If you have a map which contains a reference to block that you are holding locally you can figure out that small part of the puzzle, but looking at what is stored locally and knowing what you have is more than just searching for a needle in a haystack...
Mojo Nation does not try to open security holes. The service is actually as content-blind as we can make it. That means that it does not know if it is downloading a image, a text file, or a trojan; we expect users to take appropriate steps in watching the content. We do intend on adding additional features which will make "bad data" less of a problem, the first of which is reputation filtering for content descriptions -- does this search result point to data that other people have given a thumbs-up to. The current reputation system is internal and used for performing activities like selecting who to buy from and whether it is worth it to pay additional credits to download that block from someone who has low-latency delivery, but we are working on scaling it up to let users make the basic reputation/filtering decisions. We provide the infrastructure, it is up to the users to provide and manage the content.
For preventing problems like eating up all of your CPU time or a rogue agent running rampant through your filesystem, we are trying very hard to do the right thing (for starters by not even trying to execute distirbuted code, CPU cycle costs are included in the costs of reselling or delivering a message.) We have used strong crypto where appropriate and we are aware that all control and trust boundaries are local so we are trying to create the basic infrastructure which takes advantage of this fact.
The market was chosen as our model for resource allocation and trust management because it seems to work. No one trusts other agents in the game, everyone is (usually) trying to selfishly maximize the utility of the system for their own needs, and successful cheating can carry great reward so risk management is built into the basic assumptions about how things work. Still this distributed system ticks right along without Alan Greenspan needing to keep track of where each dollar is spent or the local shoe factory needing to know exactly who is going to be buying the shoes it is creating.
In Mojo Nation you don't trust anyone, your agents are very paranoid about what is outside of their direct control, and choices about trust, performance, and privacy/anonymity can become economic choices on the part of the user.
The "income" is stored locally, but it is not as easy to cheat as you may think. Each agent in the system has an account at the token server to which "income" gets directed. The agents withdraw digitally signed tokens from this token server and store them locally. Peer to peer transactions first starts with simple book-entry credit accounting. Once the balance between agents reachs the credit limit it will need to send a coin to the other party.
By using microcredit between the peers as a transaction history is built between the agents it is possible to do a lot within the system just exchanging credits with other peers before you need to clear a coin. The token servers can be de-centralized and only need a small channel between them to deal with possible double-spending (and agents who double-spend end up burning reputation and starting off at zero again, with the small credit limits and higher transaction costs that will involve.) This peer to peer microcredit allows each agent to, in effect, issue its own currency backed by its reputation and then settle transactions using the an agreed upon standard. In this case Mojo tokens are used for settlement between agents.
Even if the token server disappeared it would take a while for the system to grind to a halt because of the inherent liquidity the microcredit system provides. We are also working on better ways to further de-centralize the market so that these limits become less of a potential problem.
* For every file downloaded off a user's server, give that user a point[...]
* Same system as above, but base on file size instead of number of downloads. Or perhaps a combination of the two?
Mojo Nation solves part of this tragedy of the commons problem by doing just what you are proposing. Instead of keeping track of this through a centralized system we use a micropayment system in which users exchange secure digital tokens in return for services. Those who consume without providing resources to the system will eventually run out of credit and be forced to either contribute some resources of their own or buy tokens from someone else.
For the Mojo Nation design we intend on using a reputation-based trust system (similar to Avagato or slashdot moderation) which will allow users to give a thumbs-up or thumbs-down to the accuracy and/or quality of the content. We intend for these "reputation servers" to act as a sort of rating system, directing users to the content that they want and letting the users reinforce the importance of a piece of content
The reason it is not there right now is that we have been spending more time on fixing a few of those bumps in the road that Raph mentioned and less time putting in the features we really want. Our current release is fairly stable and once we have the last annoying bugs hammered out this week we will be adding additional features that make finding content easier.
One little side note: right now all Mojo Nation content can be referenced as a standard URL, so any URL/website rating system could start performing this function now...
> And the people getting screwed again? The
> musicians. Trade those mp3s, and make sure
> other people have to give some back, you don't
> want people wasting your precious bandwidth
> and hard drive space, eating your cycles, but
> do anything to prevent giving to the artists.
There is a big problem looming and you have addressed one of the big problems: compensating the creators of content. For Mojo Nation we have moved in the direction of a tipping feature. The actual data service uses Mojo as a means of keeping score of contribution/consumption but it can also be used to provide compensation for artists and creators. We are not just talking about music creators here either, but web site creators (donate a few cycles to Freetibet.com perhaps?), shareware authors, etc.
This can be set up as a "tipster" on steriods. Mojo Nation can keep track of a regeistered digital rights holder and will be able to transfer tips easily via the browser UI to the appropriate account. The recipient of the tip can use it to pay for more publishing and browsing on Mojo Nation (I am sure Lars listens to more than just his own music:) or they can sell the Mojo to those who consume more than they provide and need to buy more tokens.
Solving this problem will require three pieces: a technical solution, a legal solution, and a social solution. Mojo Nation has made progress on the technical solution, creating a micropayments system for tipping and an efficient content publication system (the code is written but not in the source tree on SourceForge.) The legal solution will require effort from the current digital rights holders to get payments where they should go (I would not even know where to send Lars his check:) and the social component is for people to learn to be fair and leave a tip. The latter part may be the hardest, but for some reason people seem to leave a tip at a restaurant even if they know they are not legally required to do so and if people are given a chance to be honest and support the artist I think that enough will leave a tip to keep Lars from starving to death.
Instead of trying to send a 3Mb file up a puny 33.6 connection to the net Mojo Nation is designed to break the file up into lots of small pieces so that you ask 300 servers for for a little piece of data; the design was created to take advantage of the assymetric nature of current network connections. Users have less upstream bandwidth than downstream bandwidth, by splitting the load for sending data across lots of hosts Mojo Nation can minimize the impact on any single peer and still be able to deliver high bitrate downloads through the larger downstream side of the connection.
Slashdot Mirror
jim
One downside to swarm delivery systems is that data is "published", simple sharing of a common filebase (a la Napster and Gnutella) is not possible. Someone has to upload the pieces to the system in the first place for them to be available because the system does not do the "let me take a look through your hard disk for things to give to others" kind of file sharing found in other P2P systems. jim
Check out the new 0.920 version, just released yesterday! A much better install, faster and a lot less buggy as well. The centralization issue is being worked on (there is a single bank, although peers use micro-credit between any two counterparties so bank failure != system failure) and we are pushing things out to the edges as quickly as we can.
Part of the advantage we think we have with a market-based structure is that it is easy for us to be flexible about control decisions and letting local choices provide emergent behavior. For now, some stuff is centralized just because it was easier for us to do it that way and move on to the important bits that needed to get coded -- we are paying the price of this and going back to replace certain centralized features with most distributed solutions, but in the end it is simple for anyone to build a better mousetrap to solve a problem within Mojo Nation and replace an existing market actor by offering the other agents a better deal. :)
jim
This is not erecting new barriers to publishing, it is lowering them and letting anyone get in on the action. Nothing is for free, but if people work together we can make the cost so close to free that no one will really care. In the end, you need to have at least some cost for publication or else you are just shifting the problem from one of publishing to one of filtering out all of the crap that everyone else is publishing (which turns into its own set of messy problems.)
jim
The next step for these systems are to pass around the code to turn the database of objects (which P2P systems like Mojo Nation and Freenet are good at distributing) into something dynamic and structured on the local client. Imagine giving the user a chunk of the /. database for an article along with code to explain how everything should be formatted, etc. The presentation and organization is local (along with any dynamic effects) while the data is just a selection from the pool of possible objects. This would also mean that when you download the articles you can pre-load the higher ranked articles or use collaborative filters to trim out the bits you are not interested in and avoid having to download these in the first place.
Freenet has some good cacheing mechanisms in there but there is a balance which needs to be maintained between de-centralization (which provides the censorship resistant features of systems like Mojo Nation and Freenet) and dynamic information features that require a trusted codebase for execution. If Java had lived up to some of its hype perhaps we could be passing around dynamic objects that contained information and presentation all in one bundle and we would run these in our browsers without fear, but it just didn't turn out that way...
In Mojo Nation we deal with the same problems of herding cats, in this case it is a problem of how you can cache content effeiciently and effectively without knowing what is really going on. Markets are one such distribution system that has a very long history of people tweaking (and trying to cheat, therefore building up its protections against most types of fraud) and it actually does solve some of the problems you address. We are not as gung-ho on the whole "information must be free" bit as Ian, but we do know that these sorts of P2P systems are the ideal infrastructure for the next step in internet content distribution.
jim
jim
The digital tokens used are the internet equivalent of the old upload/download ratios of BBS days applied to a distributed, decentralized P2P system. This isn't a "sharing" system, so it doesn't walk through your disk looking for things to give away; instead other users publish data to the system and it gets broken up into pieces, these pieces get RAID-like error correction and then they are sent out to other peers in the system. Downloads can use a swarm approach to pulling in data, taking a small piece from lots of peers (including those who might be on slow connections) rather than trying to shove the whole file down someone's (already overloaded) narrow upstream link.
Previous releases were a bit unstable, but the new 0.920 release that is available for download has a much better installer and significantly faster publishing and downloads. Check it out!
It is hard not to take this opportunity to point out that Mojo Nation (http://www.mojonation.net) is already out there providing most of what Bertelsman is demanding of Napster but with more flexibility and future potential. Check out our updated beta (version 0.919.0) for significantly improved download/publication speed and a much easier installation process. Win2k/NT support has also been added!
jim
If Mojo Nation had a feature to limit total bandwidth used per day, or even better, throttle bandwidth (perhaps even dynamic throttling as a certain maximum is reached), it would be far more preferable to people in my situation!
.920 release for this week but it will be in the release following (e.g. it is on someone's to do list but the code is not done/checked-in yet so it won't be fully tested for our release later this week.)
We hear you. The first two bandwidth throttling features which will appear will be a flat "cut the line after X many bits in and out" and will soon be followed by the much nicer "just raise prices as we get closer and closer to the X bits/hour|day|week limit." One advantage of having a market behind things is that we can use pricing to signal resource availability. We will probably not have this in our
jim
The currency centralization issue is really the last hurdle we will need to clear and you bring up several good points about how we could screw this up if we wanted to. I will first try to answer your last two objections (because I think you are making a few incorrect assumptions about what is happenind and these are not really problems) and then hit the first two, which are potential problems that need to be addressed.
The anonymity/privacy of transactions are handled through two mechanisms, cryptography and credit. We use signed tokens as our "coins" and it takes a simple three line modification to the coin builder code to create blinded coins. This prevents us from watching our users' spending habits. The blinded coins are the crypto solution, but credit between peers makes observation difficult as well. Each agent actually establishes a line of credit with another agent and begins conducting transactions. A token exchange does not occur until the balance between two agents drifts outside the credit limit. This means that the bank sees only occasional bursts of activity. Determining what the coin exchange was for will be very, very difficult (and in fact it will probably be for lots of different services and transactions that occurred over a long period of time.)
Shutting down the token server will be harder than it first seems. For starters, you are incorrect in assuming that we are a US corporation. Autonomous Zone Industries is a Cayman exempt company, this choice was made a while ago because it made following the PGP/NAI crypto export route (publish a book and scan it in over in Europe) easier when US crypto laws were a problem. It is also quite simple for us to distribute the token servers. While a denial of service attack is not trivial we have tried to make the system less brittle than it first appears, for example the microcredit system that is running the show is lenient about the token server disappearing for a while, it will just up the credit limits a little and see if things keep working.
The fairness problem is an issue of trust. We plan on having third-party auditing of our procedures and simple issued vs. redeemed checks should prevent insider problems (a bigger cause for worry in terms of what happens in the real world.) We have bigger plans for this than something as simple as just another Napster clone, but for the moment we are asking people to trust us that we are not going to burn any credibility we have for a quick cash-out. If you crunch the numbers you will eventually see that there is not really much money in being the token server, but the marketplace which is created by the existence of a single token server can have all sorts of useful properties. I want to enable Intel to buy CPU cycles from you and everyone else in Mojo Nation on an as-needed basis and purchase a support contract for this service from yours truly...burning the consumer market is the last thing I want to do.
If AZI goes out of business then people would be able to create thier own coin systems, slot them in to existing code, and pick up the dropped baton.
Multiple currencies will be supported as a licensing option, but after giving this way too much thought over the past decade or so I am not so certain that people really want to make the "do I trust this currency choice." Our original plan during the design phase of the marketplace was that _everyone_ would act as a token mint, creating reputation-backed coins that others would exchange and redeem for services. This turns out to be a general nightmare in terms of system complexity. Trying to figure out a solution to this is what led to the insight that what was really needed was micro-credit between the peers. This peer to peer credit is reputation-based and uses the digital coins for settlement; what is happening in the background is that agents are trying to make these same sorts of trust and reputation decisions that you are talking about in a multiple-currency world but by using a credit system the agent only needs to deal with the currencies of agents with whom it actually conducts transactions. By tweaking the business logic you could create the sorts of trust distinctions you desire without breaking interoperability with the rest of the marketplace.
If you wanted to create your own little world of Mojo agents that traded their own currency nothing would prevent this. We are only creating a currency for use in the public market and are not trying dictate all of the possible uses for this system.
jim
The voluntary part is our (still hidden from the UI and non-operational in Beta) PayLars function. This will let a user send a tip to the registered publisher and/or digital rights holder for a particular piece of data. That publisher/creator then converts this Mojo to dollars (or euros or cowrie shells depending on the local cost of a double espresso) or they can use it to make the cost of their next publication and content distribution cheap or even free.
You always have to pay for the download. That is the cost of getting service. Once you have the data things are a little fuzzier. If Sony wants to distributed a bunch of files locked up using InterTrust boxes then we work just great for moving the data efficiently. If the content escapes into "the wild" we still offer a backup solution. We also offer a solution to those who are not big name artists and who can't necessarily get Akamai to return their phone calls and who aren't willing to sell the car to pay for an InterTrust distribution license.
We know that this is not a final solution, but we are trying to keep future options open. If a good digital rights management solution is developed that people think is fair and just then we are ready. If nothing happens then we are still ready, albeit with a less optimal solution. If anyone else has a suggestion let us know and we will try to include it.
The only
Will there be any means of increasing the redundancy on the basis of content type in future versions?
Yes. As you have noticed, the filesystem is market-based so that which is most popular is the most widely replicated data. An agent in progress(the "eternity agent") will let you give it a bit of Mojo and it will run around making sure that your blocks are still available and if it finds any of of the shares are missing it will reconstruct and republish the missing shares.
There is also a _lot_ of idle space out there. Back of the envelope predictions seem to indicate that once we pass the ignition point where the whole range of this SHA1 address space is covered in depth there will be enough spare disk blocks out there that any data which is even mildly interesting will stick around. One market opportunity for users who are sitting on lots of disk space but small connections to the net is to collect a narrow range of the filesystem but to great depth, then just charge a higher price for access to the less popular blocks.
Oh yeah, you can also increase the number of shares for each block to whatever you want, so that downloading a particular block is a "get 32 out of 64" operation for example. The particular error correciton code we are using means that 50% is still the target for number of pieces, but by making more pieces you spread the data across more of the SHA1 address space and increase the probability that someone is online who has the share you need.
jim
Ah, yes there is a minor problem in that when you publish (do a good thing for the network as a whole) you get punished by being charged Mojo for the cost of publication. This is necessary to prevent the flooding attacks that could otherwise result from open/free publication.
The trick we are going to use in the short-term is that when you publish blocks you first publish them to your own agent to try to get the first resale hits from the blocks. If your agent has a reputation for posting blocks which tend to get resold then it is likely that this publish-to-self option will continue to work and your agent profits from the act of putting valuable data into the system. If you agent has no reputation or a bad reputation as a publisher then this will not work and you will have to front the cost of publication yourself.
One should also keep in mind that while we are tossing around numbers like 10,000 mojo for a publish or download these are intended to be very, very small numbers. We are hoping that publishing or downloading costs pennies per Gb as more participants join the network and competition drives down prices.
jim
Mojo Nation always trys to act on local information (it is all that you can really trust) and if there is an economic incentive for a better strategy or new service then market pressure will favor anyone who creates it. For example, right now the network is rather flat and gnutella-like. Obviously this is a bad thing. The saving grace here is that as the network gets larger and there is an actual need to make smarter message distribution and cache choices these services will be possible.
Right now it does not make sense for the market to try to select the closest source unless it has a significant impact on performance. Making choices based on network topology, selecting what price lists you will present to a agent depending on its identity (e.g. being able to locally subsidize a worthwhile project or effort), these sorts of things are basic business logic decisions. We have created a skeleton set of these little rules, but as the market matures it will support whatever clever rules people can think up.
jim
You are correct that there are problems with the fast and shallow analysis that you seem to present, so here are the fast answers to why these problems will not be the major problem that you claim:
1) You get credit for content you publish so there is an incentive to publish lots of random crap.
This is untrue. You do not get Mojo to posting content, you get Mojo for reselling blocks of data to others. In fact, in Mojo Nation there is a minor cost imposed for publication to prevent people from doing the sorts of stupid attacks which you mention. Mojo Nation is built assuming a society of dishonest, distrustful agents. Your agent doesn't get paid (by my agent) until you deliver the goods.
We are also working on a simple collaberative filtering system to allow users to filter out the bad metadata in the system. If someone publishes 3 gb of random noise it will get a few hits and the users will be able to pass back to the content tracker a complaint that the description did not match the content, as a few of these pile up the content description gets fewer hits on search requests and eventually the blocks fade away because no one will buy them.
2) What is the "price" of Mojo.
The reason I tried to avoid that question is that the answer is a little too complex to distill into a sound bite. A unit of Mojo represents a slice of the current capabilities of the system as a whole. If you perform work for me now I give you credits, in the future when the network is larger those credits will represent a slice of a much larger pie and so have increased in value when you spend them. If the network collapses (as you predict) then the only value of those credits are that the company running Mojo Nation will redeem them for storage/message passing service on our own systems.
The problem with quoting a "price" is that everyone will dig it up later and call you a liar for not being able to successfully predict the future product of several different unknown variables in this equation (how large is the network vs. total tokens in circulation, what is the raw replacement cost of the resources, what sort of discount are users willing to make on these resources to attract customers, what is the current demand for each resource in our basket [is bandwidth scare this hour, perhaps disk space?])
Mojo is a mechanism for keeping score in peer to peer systems. The real-dollar value depends on the demand for the services and the supply in the pool. Please don't claim that I am an idiot just because I have a basic understanding of which claims one can and cannot make regarding a future market condition.
jim
...who own printing presses. In Mojo Nation there is no "big iron and bandwidth to host this stuff", that is all provided by the Mojo Nation infrastructure. In other words everyone contributed a part of this big iron and bandwidth and gets "paid" for the percentage they are throwing in to answering a request.
How about this for a possibility: what if the cost of pulication was next to nothing (but not zero or else it is too easy to flood the network) and the cost of distribution was paid for by the user who actually download the data. In other words almost no cost to publish to the net. In return for the faustian bargain I will allow users to be fair (by leaving a tip) which is about the only thing we have come up with yet for artist compensation, but if others have better ideas please let us know
jim
Ryan knows this stuff, but for those in the audience who have not been hanging out in crypto and cypherpunk circles for the last ten years:
> Mojo Nation is from the same intellectual heritage
> as BlackNet/Eternity/etc., but I believe the
> foundations were laid at about the same time as
> the others, with implementation waiting quite
> a while for resources to be available.
The original genesis was the "Internet is a Brown Paper Bag" system created by myself, Doug Barnes, and Jerry Porter back in Austin and presented at the HoHoCon '94 conference. Things sat around for a while because we were waiting for two things: digital cash and a raison d'etre. At the time we did this early work connectivity and storage costs were expensive and there was no digital content to speak of. The growth of broadband and flood of digital content(music, video, images, etc.) made this arena more interesting several years ago so that is why we starting talking to lawyers to see if it would be possible to actually implement some of the wacky ideas we used to have.
A digital cash system was the sticking point. All great cypherpunk projects seem to begin with the line "when we have digital cash, we will be able to do X..." Our insight was in realizing that for a distributed system like what we really needed was a method for fairly allocating resources. We combined a cool idea to base a form of currency on payment in kind with a reputation-backed microcredit system to cut down on token clearing overhead and thus was born Mojo Nation.
One insight that Ryan has made which I hope others pick up on is that Mojo Nation is about more than just swapping music or pushing data. We are trying to create a basic infrastructure for any kind of peer to peer transaction, we just happen to think that trust management and resource allocation are the two important problems that need to be dealt with in this space and have targetted our micropayment system in this direction.
jim
When content is published in Mojo Nation it goes through three steps before it becomes a small block of data which might be published on your host.
1) The file will be encrypted with the hash of the file. (feature in release 0.920 which will be out this week)
2) The encrypted file is broken into fixed-length segments.
3) These segments are pushed through an error-correction code, expanding the N bits into 8 N/4 length segments. (any 4 of the 8 shares are sufficient to reconstruct the orginal block)
These resulting block fragments are then published and are passed through the system. Each block fragment is only identified by its SHA1 hash, to reconstruct a piece of data you need a sharemap which tells you that if you collect a certain set of blocks and reverse the publication process using the instructions contained in the map you get the original file.
If you are holding blocks you have no idea what they are, it is effectively random noise on your system. If you have a map which contains a reference to block that you are holding locally you can figure out that small part of the puzzle, but looking at what is stored locally and knowing what you have is more than just searching for a needle in a haystack...
jim
Mojo Nation does not try to open security holes. The service is actually as content-blind as we can make it. That means that it does not know if it is downloading a image, a text file, or a trojan; we expect users to take appropriate steps in watching the content. We do intend on adding additional features which will make "bad data" less of a problem, the first of which is reputation filtering for content descriptions -- does this search result point to data that other people have given a thumbs-up to. The current reputation system is internal and used for performing activities like selecting who to buy from and whether it is worth it to pay additional credits to download that block from someone who has low-latency delivery, but we are working on scaling it up to let users make the basic reputation/filtering decisions. We provide the infrastructure, it is up to the users to provide and manage the content.
For preventing problems like eating up all of your CPU time or a rogue agent running rampant through your filesystem, we are trying very hard to do the right thing (for starters by not even trying to execute distirbuted code, CPU cycle costs are included in the costs of reselling or delivering a message.) We have used strong crypto where appropriate and we are aware that all control and trust boundaries are local so we are trying to create the basic infrastructure which takes advantage of this fact.
The market was chosen as our model for resource allocation and trust management because it seems to work. No one trusts other agents in the game, everyone is (usually) trying to selfishly maximize the utility of the system for their own needs, and successful cheating can carry great reward so risk management is built into the basic assumptions about how things work. Still this distributed system ticks right along without Alan Greenspan needing to keep track of where each dollar is spent or the local shoe factory needing to know exactly who is going to be buying the shoes it is creating.
In Mojo Nation you don't trust anyone, your agents are very paranoid about what is outside of their direct control, and choices about trust, performance, and privacy/anonymity can become economic choices on the part of the user.
jim
The "income" is stored locally, but it is not as easy to cheat as you may think. Each agent in the system has an account at the token server to which "income" gets directed. The agents withdraw digitally signed tokens from this token server and store them locally. Peer to peer transactions first starts with simple book-entry credit accounting. Once the balance between agents reachs the credit limit it will need to send a coin to the other party.
By using microcredit between the peers as a transaction history is built between the agents it is possible to do a lot within the system just exchanging credits with other peers before you need to clear a coin. The token servers can be de-centralized and only need a small channel between them to deal with possible double-spending (and agents who double-spend end up burning reputation and starting off at zero again, with the small credit limits and higher transaction costs that will involve.) This peer to peer microcredit allows each agent to, in effect, issue its own currency backed by its reputation and then settle transactions using the an agreed upon standard. In this case Mojo tokens are used for settlement between agents.
Even if the token server disappeared it would take a while for the system to grind to a halt because of the inherent liquidity the microcredit system provides. We are also working on better ways to further de-centralize the market so that these limits become less of a potential problem.
jim
* Same system as above, but base on file size instead of number of downloads. Or perhaps a combination of the two?
Mojo Nation solves part of this tragedy of the commons problem by doing just what you are proposing. Instead of keeping track of this through a centralized system we use a micropayment system in which users exchange secure digital tokens in return for services. Those who consume without providing resources to the system will eventually run out of credit and be forced to either contribute some resources of their own or buy tokens from someone else.
The market works.
jim
Guilty as charged. (*hang head in shame*)
For the Mojo Nation design we intend on using a reputation-based trust system (similar to Avagato or slashdot moderation) which will allow users to give a thumbs-up or thumbs-down to the accuracy and/or quality of the content. We intend for these "reputation servers" to act as a sort of rating system, directing users to the content that they want and letting the users reinforce the importance of a piece of content
The reason it is not there right now is that we have been spending more time on fixing a few of those bumps in the road that Raph mentioned and less time putting in the features we really want. Our current release is fairly stable and once we have the last annoying bugs hammered out this week we will be adding additional features that make finding content easier.
One little side note: right now all Mojo Nation content can be referenced as a standard URL, so any URL/website rating system could start performing this function now...
jim
> And the people getting screwed again? The
:) or they can sell the Mojo to those who consume more than they provide and need to buy more tokens.
:) and the social component is for people to learn to be fair and leave a tip. The latter part may be the hardest, but for some reason people seem to leave a tip at a restaurant even if they know they are not legally required to do so and if people are given a chance to be honest and support the artist I think that enough will leave a tip to keep Lars from starving to death.
> musicians. Trade those mp3s, and make sure
> other people have to give some back, you don't
> want people wasting your precious bandwidth
> and hard drive space, eating your cycles, but
> do anything to prevent giving to the artists.
There is a big problem looming and you have addressed one of the big problems: compensating the creators of content. For Mojo Nation we have moved in the direction of a tipping feature. The actual data service uses Mojo as a means of keeping score of contribution/consumption but it can also be used to provide compensation for artists and creators. We are not just talking about music creators here either, but web site creators (donate a few cycles to Freetibet.com perhaps?), shareware authors, etc.
This can be set up as a "tipster" on steriods. Mojo Nation can keep track of a regeistered digital rights holder and will be able to transfer tips easily via the browser UI to the appropriate account. The recipient of the tip can use it to pay for more publishing and browsing on Mojo Nation (I am sure Lars listens to more than just his own music
Solving this problem will require three pieces: a technical solution, a legal solution, and a social solution. Mojo Nation has made progress on the technical solution, creating a micropayments system for tipping and an efficient content publication system (the code is written but not in the source tree on SourceForge.) The legal solution will require effort from the current digital rights holders to get payments where they should go (I would not even know where to send Lars his check
jim
Instead of trying to send a 3Mb file up a puny 33.6 connection to the net Mojo Nation is designed to break the file up into lots of small pieces so that you ask 300 servers for for a little piece of data; the design was created to take advantage of the assymetric nature of current network connections. Users have less upstream bandwidth than downstream bandwidth, by splitting the load for sending data across lots of hosts Mojo Nation can minimize the impact on any single peer and still be able to deliver high bitrate downloads through the larger downstream side of the connection.
jim