Below in an attempt at expressing a new, architecture for mutual credit. It allows for both intertrading for currencies with equivalent base measures of value, and multiple-currency approaches for currencies which might have floating exchange rates. It seeks to build on the networks which already exist, but by breaking up the components into separate pieces, to make them more extensible, and open to developers. Above all, this is a decentralised, scalable network, in which all the components are open to competition and only the server2server APIs are controlled.
Explanation
The green sites happen to be part of the same network. But the real control resides with the local community which owns the site and decides who its service providors are. They do their own content management and maybe manage their whole sites, but these groups belong to an umbrella organisation who provides them with hosting, and software. Although they can host their own accounting, like a traditional LETS, they are encouraged to outsource this work to specialists who guarantee security and reliability. In this example, all the lets currencies are based on time, and thus can be intertraded, within limits set down by their LETS standards body.
An accounting server can host currencies of all kinds. The point is to outsource the specialist software and secure web-hosting. Here the solid colors are time-based currencies while the gradient-fills are mutual_credit dollars. Each square is little more than a table of transactions and a cache for quick retrieval of balances. The API between the web server and the accounting server consists of remote database calls. The database may provide additional accounting services such as economic analysis, taxation, loan management, liquidity warnings etc, although these could also be provided at the application level.
All intertrading between currencies of the same type should be done via Clearing Central, at least while we have limited resources. Clearing central provides a single protocol and point of access for mutual credit groups to intertrade securely. It would be a nightmare managing 250,000 logins on a P2P system with 500 groups! With clearing central each accounting system needs to know only one login. This is the most vulnerable point in the network, so it would need to be especially secure and available. All the sites keep their offers and wants on a single global geolocated directory. That provides a seamless search experience whether users are looking in their village, city, or even a holiday destination. Each offer would hold coordinates, privacy settings, currency-types accepted / required. The directory would also put people in touch from different communities without revealing email addresses. This also would be mostly a database, with no front-end access required. The directory component of the web sites could just as easily interrogate 2 directories as one.
A B2B barter site, at the bottom, is using a similar technology set up. It has 2 currencies, hosted on different accounting servers, as it happens; a LETS and a dollar-denominated currency. These cannot be intertraded, but must be exchanged on an open market as currencies are today.
None of this is set in stone, but we are ready to begin building this, starting with the Drupal mutual_credit module which is currently being upgraded for Drupal 7. The easiest part to develop separately, would be Clearing Central, and in a while we'll know more about how the global directory will work. It doesn't need to be very complex, at least at first.