I’m very excited to introduce to the holochain community a new initiative we are bringing forward: Llavors Mútues (“Mutual Seeds”).
Llavors Mútues (“Mutual seeds”) is an open source working group centered around mutual-credit infrastructure on holochain . It’s not an application or set of happs, but instead open source zomes and libraries that can be composed to build one.
We think that this makes sense because writing a mutual-credit DNA is hard, but at the same time every community will have different needs and requirements to tune their current-see to their use case. So, instead of developing one “size fits all” solution, we think it’s best to develop small modular building blocks that implement different patterns, and make them available so that different communities can find their own way as easy as possible.
In a way, we already started with the previous mutual-credit holochain community experiment, which we completed but encountered some blockers on the holochain core side. But nevertheless the code is good and works with a few known issues, so we have our first building block to build from.
Next steps include building and publishing more UI to see the flows of the current-see, and building a public-transactions mutual-credit zome with demurrage.
The main reason for this post is that we need help! There is a ton of work to be done, and if you want to get involved in any way, PM me and let’s talk
Brilliant. I’d love to help in thinking through different architectures and currency designs, so we can adapt the zomes to work for the different designs.
Honest question: Why not execute these designs using the Holo-REA framework? Mapping this off the top of my head: credits could be expressed as ‘Economic Resources’ with a dynamic spending limit to go negative (could also be a function of reputation), transactions would be Processes and the Observation module could be used to expose data to appropriate networks.
Asking purely with my entrepreneur hat on. The trade off is that I have to ‘speak’ the H-REA language and have some modules in my app bundle, but that seems to be worth the effort, because I can customize libraries for my need. What am I missing?
Hi @sidsthalekar! This is a great question indeed, we even already talked with @pospi about this.
So, from my perspective, in these modules there is too much complexity and custom behavior to encapsulate with a generic module as holo-REA, not so much in terms of ontology, but in terms of implementation. There are a lot of custom mechanisms used in them, such as direct messages to agree on private transactions, counter-signature processes in which you can only execute if you know that is safe to, or preventing agents from rolling back their chain, that really depend on the flavor of mutual-credit you want to implement.
Also, things like fees, demurrage or the dynamic credit limit you are mentioning need to be encoded in the validation rules, and we can’t expect holo-REA to implement those validation rules for us, it would be too big an ask I think.
Another entirely different matter is recording the flows in holo-REA. Once the transaction has occurred, recording it as an EconomicEvent is trivial, and makes it compatible with the REA framework and ontologies, so we get the best of both worlds.
Anyway, from these initial thoughts I think a lot of experimentation will need to happen, to see what is possible maintining the security guarantees we need. Open to continuing the discussion!
@raphisee I am not a coder, but have thought about different ways to organize mutual money. Would be happy to see your thoughts and see if I could add anything.
Having not seen anything on the subject of design alternatives here yet, just to start discussion on the issue of different ways that mutual money can be implemented, I put forward the following variables as some that are available to consider. This list is not to be seen as either exhaustive or correct. However it is put forward as a place to start. Additions and/or corrections are welcomed.
What backs the money issue?
a. A commodity or basket of commodities.
b. Money of a standard money system.
c. The promise of users to provide their goods or services.
d. Something else.
e. Some combination of the above.
How is system management paid for?
a. Periodic fee on all accounts.
b. Interest charge on negative balances.
c. Demurrage (negative interest) on positive balances.
d. Foundation or other grant. (not sustainable if funding runs out)
e. Borrowed money (not sustainable)
f. Volunteers (not very sustainable)
g. Fees for service
h. Some other source
i. Some combination of the above.
How are system rules enforced?
a. Agreed upon system structure (eg limits baked into dna of computer programming, or formal or informal rules enforced by its users)
b. An authority
I. Chosen and responsible to members
II. An independent authority
III. Some other mechanism
c. A combination of the above
How does the value of the money change over time?
a. It simply retains its value over time.
b. It looses value over time through demurrage; negative interest. This charge can respond to the need for funds to cover computer time, management, and any surplus can fund community organizations.
c. Some combination of the above. (Chiemgauer have current accounts that have demurrage, and savings accounts that simply maintain value.)
d. Some other possibility. Gaining value over time through interest is not listed, as it has never been used historically in mutual systems that I have encountered. It also leads in the long term to system instability. Provision for discounting might be considered.
Thanks to those who made the connections above. In an attempt to articulate further-
Because REA is so low-level, when you’re a practitioner of it these things usually become a case of implementing the custom abstraction on top of REA. The linked issue shows the constraints that would need to be implemented on top of the model in order to make an REA-powered DNA behave in the manner of a classical mutual credit system.
But @guillemcordoba is not wrong- demurrage, credit systems etc are starting to become more complex beasts that you certainly wouldn’t want in REA core.
If you were not a practitioner of REA, you could implement things the other way around- build the domain-specific system you need first, then translate its logics into REA after the fact and add in API calls to Holo-REA’s modules to drive an “REA shadow” of the data. And I generally think that’s better at this level of experimentation because it leads to diversity in implementations and ensures that nobody is lead into an incorrect domain-specific way of thinking early on that blinkers their creativity as they continue down the path.
I think there is a likelihood, as hinted by some of the linked issues in the above regarding further modularisation of EconomicResource, that Holo-REA may end up making a lot of the same design decisions as the mutual credit systems and needing a lot of the same base functionality (counter-signature processes, private transactions etc). Things like a pluggable demurrage module for currencies in REA networks could also well be useful down the path. Hell, you could even encode things like water being drained from a lake as demmurage?
Yep that’s exactly what I had in mind. Honestly, I think there’s way too much hoopla around the custom abstractions (it seems to attract more academic discussion than traction on the ground). I would much rather have standard infrastructure in place, from which we can rapidly iterate, tweak and roll out custom designs like demurrage/perishability/reputation-backed-issuance etc. in an intuitive way. As someone who’s lived with and experimented with these currencies, I can say each context is different and no one knows the right design for monetary or reputational currencies going in. It kinda ‘evolves’ as the community finds its way.
Having said that, I acknowledge Pospi’s point about blinkers and everyone buying into a domain specific way of doing things. I guess it’s a tension everyone in the HC eco-system is learning to hold
I’d love your feedback to make it better before we publish it on Hacker Noon (trying to snag some interest from both the “crypto fanboi” and “exhausted blockchain refugee” camps there).
The second article will be about designing them (including how to use Holochain to do it), and I’m also going to feature Llavors Mútues. I’d love to gather some talking points – what do you all think are worth discussing?
I would be excited and available to work on UI and to visualize flow patterns for this. I have very limited rust experience (currently enrolled in the Dev Camp 7, so hopefully this will be a bit better soon) but understand holochain architecture and patterns. I was part of the Commons Engine currency design workshop some months ago so I’ve been already thinking in current flows for a while, and have some ideas of how to translate this to interactions design. I have experience in front-end web development (still learning GraphQL though). Specially for experimental and non-traditional applications. Let me know how I can help!
