transition towns
Bitcoin as Reserve Currency for a Local Currency?
I can't pretend to know a lot about avoiding the pitfalls of local currency systems, but I do know that two of the hurdles that you have to overcome are the questions:
- What happens when I'm the only person in the system with a useful skill, and everybody else is making scented candles, and I find myself with as many scented candles as I can ever imagine requiring, and my account enormously and uselessly in credit?
- What happens when the whole system collapses while I'm in credit; do I just lose the value of all that work?
It occured to me that adopting Bitcoin as a reserve currency in such a system might be useful in dealing with at least these two disincenctives to participation, and I was surprised to find very little discussion about it (in fact, I expected that as with most of my other brilliant ideas I would find people who had been already doing it for years, and I was the last person on Earth to know about it). There are some interesting comments in this thread, and a proposal to "fork" Bitcoin-like currencies for local use, which I think is technical overkill but interesting. Here are my initial thoughts:
Anything that makes it harder for the regulatory bodies that have screwed up your local economy in the first place to say "Your local currency is really just an IOU for the national currency so all you people now either owe us tax, or have lost your social security benefits" is a good thing.
Bitcoin would be a good medium for trades between local currency systems, in the same way US dollars are used for global commodities like oil. Note to self: think of an example with less of a bad vibe.
You will need strong capital controls; you're defeating the purpose having a local currency if it's freely exchangable for a global currency. So people should be able to cash out to Bitcoin if the system closes, or they move to another geographical area, or they can cash out a certain percentage of their balance once they've exceeded a threshold, but not willy-nilly. Sure you might then get black market exchanges, but I think you are much more likely to find they will trade in the national currency than Bitcoin, so I don't think controlled exchangability to Bitcoin changes this at all, and since some local currencies have avoided instant failure, I have to assume that under at least some conditions this is a managable problem.
You have to set inflation (and lending, if your system has lending) rates appropriately. A little bit of inflation is a disincentive to hoarding, thereby keeping the local economy moving. And since the value of Bitcoin is increasing relative to any major currency you care to name (and is likely to continue to do so for the forseeable future), you can decrease the value of your currency over time relative to the "real" value of the goods and services you purchase, and also relative to your reserve currency, and still give your participants a high degree of confidence that they're not trading away their efforts for a worthless asset. Worst case scenario is they've earned a bit of "interest" when they cash out, in the form of the difference between the decrease in value of the local currency versus the increase in value of Bitcoin. You can't count on the Bitcoin bubble inflating forever, but the evidence is that Bitcoin isn't going to burst altogether - smarter people than me are calling it "the local currency of the Internet" - so use this Bitcoin deflationary period while you can, I say.
A possible objection to the above interventionist monetary policy is that, depending on who you talk to, either fixed exhange rates (1:1 to Bitcoin, say) or an unregulated currency market will deliver better outcomes than rational planning, because Very Serious People say so. In response, I present the real world. Take a look at it for a while. Provided your system is transparent and democratic, I don't see a better solution than thinking very hard about hard problems. Certainly not faith in gold, dollars, Euros or "free" markets.
In the case of a crisis, the system is going to have to be able to both forgive debtors and pay off creditors. I suppose that means holding at least some Bitcoin reserves. Trouble is, that's an upfront cost for something that you're going to need less and less over time as your local currency becomes more robust. Do new participants "pay" for their initial local currency credit in Bitcoin (a disincentive to participation)? Do established local currency systems either lend their otherwise redundant Bitcoin reserves or go guarantor in order to bootstrap new systems elsewhere? If so, what's in it for them? Do they get to dictate policy to failing systems, like an alternative economy Angela Merkel? Tricky one, that.
Counceling wanted: Social Network dedicated to sustainable settlements
I'm part of the IT Team of GEN (Global Ecovillage Network) and actually working on a Drupal platform which will be used by CASA (American Councel of Sustainable Settlements) and RIE (Iberian Network of Ecovillages). In the future more affiliated networks might join and thematic sites about related subjects (permaculture, green building, etc.) might get integrated.
I created different social networks already (www.ecoaldeas.org - actual RIE site, www.sensaciones.de - artistic sustainability related to our own project), but never realized a project on this scale, which hopefully will get high traffic.
That's why I would appreciate to get feedback and advice about the sites architecture, and in the best case even collaborators for our IT work of the Global Ecovillage Network.
My main doubts are about the concept of abstaining from the modules 'Domain access', 'Panels', 'Spaces' and 'Context' and instead solving several of their functions on the theme level. It seems as a very simple solution in that very case and I hope to gain performance and flexibility.
The site is made with Drupal 7.
The prototype can bee see on http://www.rie.ecovillage.org.
General description to be found below.
Grafical plan of content relations: http://www.rie.ecovillage.org/sites/default/files/images/casa%20web%20st...
Entity translation:
It is multilingual, using entity translation while having i18n installed.
Organic groups:
The central content type is 'project', which is required to be a organic group.
Settlements, Organisations and misc projects are represented as project.
At the same time a project can be group content, so that projects can have subprojects and the real life structure of affiliated projects will get reflected.
All groups are public, some group content types are private (internal forums).
Organic group is the basic structure throughout all sites, while the different affiliated sites mainly get individualizes by promoting one of the groups and its subgroups and having an independent theme.
Multiple sites:
One Drupal instance with one single database will drive various different sites with an individual domain or subdomain each.
- Continental networks
- Regional networks
- Individual projects
- Thematic sites
Shared users, shared content, shared taxonomy. There is no access restriction per domain. Like that you can access the same content on every site. The structural differences of the sites are defined by the individual frontpage and individual menus. Lists can be filtered in an individual way by passing different URL arguments by the sites unique menu.
Each entity holds the information of the domain under which it was created as computed field.
Themekey
To keep things as simple as possible I abstained from using Domain access. Instead I use individual themes for each domain switched by Themekey.
One base theme defines the general site structure.
Each site has an individual css or a complete subtheme.
Individual front page as node
The content type 'frontpage' defines the frontpage of each domain. It can be configured by fields (for the moment just field UI), which affect the blocks which are shown on node-frontpage.tpl.php.
Grouped blocks directly in node.tpl
For having blocks holding several subblocks with subtitle each, they are created in an custom module instead of the core block module. Available blocks for each template are defined in template.php and pased to node.tpl.php as variables. The custom module is also creating 'edit' or 'create content' buttons on hovering the block to each user with the necessary permission.
Menus
Depending on the needs of each individual site they can have an individual menu provided by 'OG Menu' or the menu can be created manually in page.tpl.php.
Most other navigation structure is provided by block views filtered by gid.
Project spaces
To keep things as simple as possible I abstained from using Panels, Spaces or Context.
An individual header per group, composed by a header image uploaded to the group node and the group title, is printed into page.tpl.php.
There are no sidebars defined in page.tpl.php. Blocks beside the content are defined directly by the block-variables in each node-content_type.tpl.php.
Features:
A big variety of tools are available to each project to support its development and promotion. They are handled by the feature module so that they new features can be easily provided by collaborators.
Feel free to ask any more details.
Happy about feedback.
General description:
GEN Sites is offering a series of innovative and useful features and tools for upcoming and established projects in the fields of sustainability with special focus on Ecovillages, Permaculture, Green building, Eco technology and Communal living.
The main goal is an effective support of the critical prozess of getting new initiatives started and guided towards success.
The focus is on the dynamical process of project development, the active participation of users, the creation of compromised teams, and the relation between all elements involved. It aims to inspire a faith in each user, that we are actually in a communal path towards a new culture, and that he can feel part of initiatives which he can see developing, even if it is just giving support and translating texts.
This starts with offering a helping hand to interested people, giving them orientation and an appropriate space where to get in contact with likeminded people. Each user can create a detailed profile which is helping him to define his personal situation and query.
As a next step people will get invited to define their dreams, share them and allow other people to get engaged. This is the birth of a new ‘project’ on the site, which can offer a perfect space for learning, even if it will never get transformed into reality. The process of group building can already be supported by a experienced facilitator which also has access to fine graded search functions of the database of interested people.
While the dreams transform into a clearer concept and get a real life initiative, the project space will offer tools for collaboration and collective learning. Other supporting projects, like the ‘incubadora’ promoted by Alf Flaquer and supported by RIE and CASA are able to stay in close contact to this process and even design a individualized sequence of collective duties and teachings to animate the collective and individual growth.
In this phase real life meetings might start to accomplish the distance learning process . A map of available facilitators as much as places for meetings and temporary community experience will help to find the right frame.
The more concrete it gets, the more the project might take advance of practical tools, like the forum for thematically discussions about any concern, a database for available properties and abandoned villages, a database for human resources, a crowd funding page where to get support and offer rewards, a showcase where to promote products, a prepared application form for membership, and a ‘travel agency’ which organizes volunteer, trainee or ecotourism activities as much as the human interchange between different projects.
Each project automatically obtains its own attractive presentation with an easy to remember URL, which can be used as internet presence from the moment the project is created. Any related content, like activities, images, announcements, products, articles, etc. posted by the team will always be shown with the individual project header and its basic information, while all this is listed in the main project page.
As projects can get affiliated to other projects, we will create a interconnected structure which is reflecting the real life alliances. This is especially interesting for projects dedicated to networking. They can easily configure their presence the way that all affiliated projects, with their activities, announcements and any other content is shown.
The whole development process through the defined states of ‘dream/concept’ -> ‘initiative’ -> under construction’ -> ‘established’ and possibly to ‘in transformation’ or even ‘ended’, ‘failed’, or ‘brought to success’ will get documented in a project chronic and so made available to any following initiative. Especially the documentation of ‘crisis’ and ‘failure’ seems to be very valuable to me, as this helps to take full advantage of our collective process of trial and error towards a new human culture.
The site will get launched as multilingual platform from the beginning, to animate the intercultural exchange. Translation tools will allow to work collectively on the translation of content.
GEN Sites is designed as an open framework, which allows to easily set up individual sites integrated into the same CMS. Each site can be absolutely individualized, in graphical aspect, layout, menu structure, and available tools and listings. While any content and all features can be promoted on each site, which offers a growing pool of translated information and tools.
The first example of this fertile symbiosis is the collaboration of RIE and CASA, who will run their individual sites together on GEN Sites. Like this they will be able to reflect the dinamics of Ecovillage networking in the worlds Latin cultural area on each of them.
GEN Sites can connect to other platforms and systems, like GEN DB, for the synchronisation of Data about projects, activities, experts, etc.., even if the complexity of GEN Sites content and user referencing structure might not allow that remote sites can adapt most of the GEN sites tools.