Mon 4 May 2020 1:25PM

[Webinar Proposal] Mutual Credit / REA Accounting

A Aleeza Public Seen by 141

Edit: Converting this webinar into a session to discuss mutual credit and REA accounting.

Hello! I'm hoping to convert this proposal to an Open:2020 webinar: Working Session: Using Trustlines for People Powered Money In Your Community.

I find Loomio a bit confusing to navigate. I haven't found where the other webinars were organized, so please correct me if this is the wrong format for a proposal.

It seems the Open:2020 webinars are occurring on Thursday afternoons, and the next available Thursday appears to be June 4. Would it be ok if we scheduled this webinar on June 4? I am tentatively adding it to this excel doc.

I know there are similar projects here, so I'm interested to hear your thoughts about how to focus this session to make it also useful for others working on systems for mutual credit and alternative currencies.

Here is the text for the original proposal:

Trustlines Protocol is a free, open-source technology stack designed for financial inclusion. It enables blockchain-based, peer-to-peer mutual credit which can be created and used entirely without an ID, bank account, or knowledge of digital currencies.

It can be used to build a medium of exchange that supports 1) accessibility, 2) censorship resistance, and 3) human-centered monetary design. Its ideal use case is for community-driven, local or alternative economies, as well as people who lack access to financial services.

In this session, we will be demoing the Trustlines mobile app, a free platform on which users can pay each other with mutual credit via the Trustlines Protocol. We plan to:

  • Give a brief background presentation on Trustlines Protocol

  • Onboard you to the Trustlines App, so you can send and receive mutual credit with people at Open 2020 and beyond

  • Brainstorm and co-design strategies for using Trustlines within your community

  • Receive feedback for improving the app to meet the needs of suggested communities

We hope not just to spread awareness of the technology we are working on, but to give people a chance to see it in action and try it out—especially those who never had the opportunity to use a digital currency before. This is free and open-source technology, and we want to share it in a way so that you can understand why it was built, give feedback or contribute to its design, and potentially use it in your community.

Here are some additional resources:


Oli SB Wed 6 May 2020 9:21PM

I think maybe a session about Mutual credit in general, or about ways of empowering groups with a means of value exchange more generally, might be good.

Would anyone else be interested in contributing to / co-creating a session along those lines?


Les Moore Fri 8 May 2020 9:03AM

I'd be happy to support Michael, I'm looking at how the covid mutual-aid whatsapp groups could become mutually aiding, rather than gifting


Michael Linton Thu 7 May 2020 6:32PM

I would like to join and/or offer a session that respects REA accounting - Accounting for a New Economy - economicgroups and reviews - in practice - mutual commitment (aka mutual credit) as an immediate available and testable method for enabling "our" money globally and locally.

This is necessarily a commons venture, or it won't work.

openmoney.cc demonstrates at this server, and delivers what is shown here and here


Oli SB Mon 11 May 2020 9:24PM

It was really interesting how the conversation at the end of the last webinar moved on to money and specifically mutual credit ... which seems like something lots of people are interested in discussing... So I am penciling in the 4th June (the last webinar session before the main OPEN 2020 event on 11th and 12th June - full plan still TBC) as a slot for everyone who is interested in this topic to come together and discuss ...

We should aim to be clever with our time together tho - and, as I mentioned after the last webinar - not to use this time to promote our own, or different projects (which would take ages and not necessarily get us anywhere), but to instead talk about an 'open protocol for money'.

At the Open Credit Network we are working towards the vision outlined by Matt Slater and Tim Jenkins in the Credit Commons - which is an open protocol which aims to network together different mutual credit networks. It is not a technology, or a platform, but the first steps towards a set of rules for 'value flow' which are truly platform & technology agnostic ... however, it leaves some HUGE gaps, which clearly need addressing for it, or anything like it, to become a reality - namely: Governance (no small issue!) and how to manage 'trade balances' (i.e. what do you do when all the credit flows from e.g. the UK to e.g. China - because the goods flow the other way - and the UK network reaches it's 'credit limit'!?)

I would like to see if we can focus our discussions on some of these specific challenges, to provide input into the Credit Commons protocol (for which a few test networks are currently being deployed) or any other open protocol for "money".

I like the look of REA accounting - but don't know enough about it, or why specifically it's necessary for an open protocol for 'money'? But I'm keen to explore all ideas which help accelerate the transition to a collaborative economy... so maybe we can keep exchanging ideas here in the lead up to the 4th June?



Michael Linton Mon 11 May 2020 11:19PM

Oli - transcription (and notes) on the end of the last webinar. I've highlighted and indented parts I thought relevant.

And, on the demo openmoney server, a timebank (or any other m/c currency form) and wallet does install in secs. Governance and such, not so fast.


Oli SB Tue 12 May 2020 3:20PM

Hi Michael,
Can you explain a bit more about what the demo openmoney server provides...?
How it works? How people can use it etc?
I logged in and saw the attached but struggled to know what I was looking at exactly!

Could you also explain a bit more about this comment in the doc:

Oli -  but obviously Michael's open API is an API for a specific type of money that works in a specific way, 

Michael - (not so - the openmoney API applies to ALL money, no matter how it works, or is designed - michael)

i.e. how does it apply to ALL money? Maybe you could give an example of how an existing mutual credit network, and/or an existing currency, could plug in and use it? And how trades between different networks would work?



John Waters Wed 13 May 2020 5:45AM

The OM API provides a way to manage recursively-nested closures (namespaces), each enclosing an arbitrary set of stewards (users) and accounts (scalar ledgers). The interface illustrated above is just one example, convenient for payments/transfers between metrically-(/dimensionally-)equivalent accounts but constraining usage to that application ... implementing open money principles (and, as such, a variety attenuator). The API (rather than this interface) can be used to build much richer structures, including compound/vector measures - open metrics. (The start of a "development roadmap" can be seen at https://github.com/jethro-swan/om_development_roadmap - but the overall vision is much larger.)


Aleeza Mon 25 May 2020 11:46AM

Something I've been thinking about: I think the vision of the Credit Commons differs from the vision behind Trustlines Protocol mainly because it excludes the possibility for bilateral credit relationships, and (as I understand it) really only wants multilateral relationships. That was also my takeaway from this interesting blog post in which Matthew Slater discusses differences in the definition of mutual credit, and offers his own definition: https://matslats.net/definition-mutual-credit.

So I'd be interested in having a discussion on this particular question: whether it's necessary to mutualize the risk of default, or whether doing so creates a higher barrier to entry and thus makes it more difficult for the average person to participate.

A corollary question is whether we should design technology that guides (or restricts) people into setting up credit systems based on these agreed principles, or instead design technology that gives them more freedom to participate in whatever systems they can think of... even if we disagree with the principles behind certain system designs (i.e. focusing on technical interoperability vs. ideals-based interoperability).

As I see it, Trustlines Protocol is halfway to realizing the vision of the Credit Commons, as it can host multilateral credit relationships in addition to bilateral credit relationships. Trustlines, as it is used right now, is essentially the meta-exchange or "public" layer suggested in Credit Commons vision, but it is also compatible with other suggested features.

I'd be interested in discussing which other tech platforms are similar, and what specifically differentiates them, whether it be vision/governance/user base/___. While I understand the hesitance to spend too much time on the details of each platform, I still think it's very worthwhile to talk about them, especially because I'm still unsure whether the diversity of platforms reflects a healthy diversity of ideas, or instead a need to improve collaboration methods and knowledge-sharing.

And I think we should expect to do follow-up sessions that go into more depth on individual projects. There was some enthusiasm the previous time I posted this session proposal for Trustlines Protocol, so I suspect there is still interest.


Michael Linton Tue 12 May 2020 4:53PM

Can you explain a bit more about what the demo openmoney server provides...?
How it works? How people can use it etc?
I logged in and saw the attached but struggled to know what I was looking at exactly!

So you went to htttps://om-18.lrc.org.uk, and clicked "Sign up"

(note email is irrelevant, not used - so xx@yy.zz is good enough / save your passward, it may not be recoverable)

Now you are on the payments screen

Enter "olisb.cc" in "To Account" , any text in "Description", key or text any amount, and hit the + button

Check your Accounts page, see the time-stamped entry in your ledger (and one from testa.cc, who is i)

You can use this interface to direct any REA type statement - from, to, description, currency, amount is "ftdca" - from your account name to anyone else (whose account name you know) registered in that currency on this server.

It works like a checkbook, for both expense and income.

On starting cc there's further explanation on how to upload datasets, for instance to start a bio-regional ecosystem of currencies, including timebanks, LETSsytems, b2b, joint ventures, and anything that is REAlisable. Not just one timebank in a few clicks, but as many of them as you like.

Could you also explain a bit more about this comment in the doc:

Oli -  but obviously Michael's open API is an API for a specific type of money that works in a specific way, 

Michael - (not so - the openmoney API applies to ALL money, no matter how it works, or is designed - michael)

My point here is that what you think obvious - and assert - is actually quite wrong, and misleading you. But not at all uncommon - as the other highlights in the transcript show.

The openmoney api can be applied to record / account for the stocks and flows of any nameable resources between any nameable agents in any series of conceivable events - open metrics (Les Moore - 2013) is the most comprehensive description.

Metrics can be money, if those who write them choose to say so

i.e. how does it apply to ALL money?

think of it as a personally configurable REAbacus for instance (ftdca)

from knitter, to blacksheep, received - black and full, bags of wool, 3

what it does NOT do is handle assets - openmoney is NOT a bank

it just keeps accounts between agents as agents record and means to them what they say it means to them

Maybe you could give an example of how an existing mutual credit network, and/or an existing currency, could plug in and use it?

any system currently running as a singular, if they want to go wider, further, smaller, more variety. more autonomy for users could add this to what they have

a system administration can either move their data there, or open a link to it for their trusted users, or apply the api in their own user service

even a bank - or credit union - can manage this. Really.

Or a poker game, or indeed a bio-regional simulation role playing game - which is the current focus of short term development

And how trades between different networks would work?

in my experience trades between different systems is a problem - but it's your problem, not mine.

when you think of systems as incorporations (whether cooperative or not) whose group behaviour sustains the value of their currency, you are entering a world of pain and problems my friend - governance, standards, balance of payments, bancor and beyond

personally - I don't think it's important anyway, there are immediate work-arounds for any two agents each with accounts in two systems to counter-trade as they choose in their own terms and without entailing others in their affairs.

I think it comes down to whether to co-operate by organization or organise by co-operation. Both are of course possible, and indeed compatible - but they are quite different approaches from different perspectives.

Let's continue to explore the distinctions, by all means.


Oli SB Thu 14 May 2020 9:43AM

Thank Michael,

Really useful explanations - so from what I understand, this system is simply another 'ledger'...
It's not a protocol.

It does have an API, which means you could possibly use it to handle exchanges between different exchanges - but that would be pretty complicated to set up and very complicated to use up since AFAIKS there is no way mechanism to handle 'exchange rates' (or 'conversion rates' in Credit Commons language) between different currencies, is that right?

As far as I can tell the CC system could be useful for handling value exchanges if everyone was using that system - but the same could be said for Trustlines (and almost every other MC ledger) many of which also come with "Directory" systems showing and matching "offers" and "wants" which (to me at least) seems essential to enabling trade.... and many of the other systems I have seen have much nicer UI (no offense!) - which (again, imho) is essential for user uptake.

So, from what I can tell, the Credit Commons proposal remains the closest thing I have seen to "an open protocol for money".


John Waters Fri 15 May 2020 9:57AM

@Oli SB The name "OpenMoney API" is misleading. This is simply a software component that provides an API through which to interact with a database (currently implemented using Couchbase). The API constrains what can be written to or read from that database, by whom, and under what conditions. Specifically, it allows for the creation or removal of enclosures ("namespaces"), users ("stewards") and scalar records ("accounts") or scalar values ("currencies"); the enclosure of namespaces within namespaces (therefore recursively), and the enclosure of stewards and currencies within namespaces; the relocation of such "objects" from one namespace to another; the simultaneous and equal adjustment of the value recorded in two metrically-/dimensionally-equivalent accounts (i.e. using the same currency). In the special case of a currency representing a money type, we're used to calling this a payment; therefore the term payment is used for all such simultaneous adjustments. This is the only purpose of this component, but as such it provides an arbitrarily expanding set of what in the special case of a money might be called a payment channel - a pipe with a number at each end - but what makes it a payment is what the users choose to do with these numbers (each in its own account), and that is a matter of protocol - a human protocol.

The namespaces (enclosures) provide a variety management mechanism, and therefore the potential to separate modalities of interaction. I don't have time to go into that in detail, but some notes I wrote with Trevor Hilder in 2016/2017 (https://www.lrc.org.uk/files/TH_JW_Insights_From_Cybernetics_2017-04-14.pdf) will go some way to explaining the why putting everything into one huge collection of interconnecting buckets, equating anything to anything else in terms of "value" leads inevitably to the formation of conditioned hierarchies at the expense of of other modalities - especially unconditional care and learning networks. (NB, that "paper" had to be written in a hurry under rather difficult circumstances, and the 8000 word limit was a severe constraint. Expansion upon the points raised here remains very much a collection of works in progress. It should also be noted that at the time this was written I hadn't yet realized that the OM recursively-nested "namespaces" proposed by Michael are essentially isomorphic to the type of structures I'd been thinking about for a while, but, like many people, I had difficulty breaking through this particular language barrier to identify the synergy.)

Getting back to the OM software ...

The "OpenMoney network" component is a proof-of-concept user interface, usable (with some help and guidance) to demonstrate a concept ("open money" - note the use of two words in lower case letters). It was written very quickly by a skilled programmer with very limited time, so some bugs still remain and it lacks the built-in help system it really needs.

The "OpenMoney network" interacts with the "OpenMoney API" using familiar protocols - HTTP, SSL, Oauth2, TCP/IP, etc. - nested (or "stacked") as such protocols always are. The "human protocols" are another layer in a "protocol stack". The decoupling of these components means that all manner of alternative components, including much flashier user interfaces, can be added in due course. It also means that alternative implementations can be built on the other side of the API - for example using Holochain, an option consistent with the OM objective of placing responsibility for, and control of, data in the hands of its "owner" while also offering other advantages at scale. It also means that the API itself can be expanded functionally as and when useful. The API is both a transducer and a variety attenuator.

The "OpenMoney Gift API" is a variant with its own proof-of-concept/demonstration client - "OpenMoney Gift" - designed specifically to demonstrate concepts of "covestment", a special case of open money in which feedback loops between altruistic bodies, humans and locally-enclosed trade components create a pump mechanism. ("OpenMoney Gift" could have been designed to work with "OpenMoney API" rather than "OpenMoney Gift API", the latter perhaps having been designed as a temporary step.)

To describe this as "simply another 'ledger'" is simply wrong. Users are called "stewards" because each holds responsibility for her/his/its own collections of namespaces, accounts and even currencies - within the bounds of name-collision) - and can create, manage and destroy these to the extent allowed by whatever rules (protocols) are imposed at a meta-level.

Open money is a special case of open metrics, a domain within a domain. Open metrics encloses everything we can measure (even rather fuzzy measures such as satisfaction, happiness, eudemony, ...) as well as compound/vector measures relating to the physical world, while open money encloses everything we can control.

The idea of using the OM system to provide a gateway between other enclosures - especially using exchange mechanisms - makes no sense in the OM framework. Any "money" that can be equated to another "money" through an exchange mechanism immediately opens both up to commodification and speculation - the money become a commodity in its own right rather than simply a representation of things, it enables (and even requires) the externalization of SEP ("Somebody Else's Problem", to use Douglas Adams's term) in the form of uncontrolled extraction of non-renewable resources, uncontrolled destruction and toxification of our shared natural resources, slavery, and all the reinforcing loops which drive us towards global destruction. Just because Elinor Ostrom can show us ways to mitigate the Tragedy of the Commons given the right conditions, that doesn't mean that we currently have any agreed approach to work at even national or regional scale, far less at global scale. The limits to what we afford (collectively, globally) are set by the planet itself and the energy received externally. Our needs, as humans and as life more generally, have a lower bound - and Manfred Max-Neef and his colleagues, as well as Maslow and others, cast light here. Bridging the gap between these upper and lower bounds is, in essence, a mutidimensional control problem - and finding a compromise between the "needs" of humans and those of lifekind more widely, makes this also a problem in optimal control. This is where Mick Ashby's work on "ethical regulators", helps to shine a light on how to bridge the gap between the multivariable control problem (very much the domain of Ross Ashby and Roger Conant in the Good Regulator Theorem). But I digress ...

Any money which is isomorphic to legal tender will ultimately be part of the problem, even if it can be tweaked to provide narrowly-useful remedial solutions.

Comparing OM and one-type-fits-all currencies/monies (such as legal tender, OCN, credit commons, Ripple/Trustlines, etc.) makes no sense. The objectives are deeply and fundamentally different.

Don't take this as a re-interpretation of Michael's ideas. Michael expresses his thoughts in his own way - as we each should, negotiating a shared language as needed, and depending on the who and whom and context in any particular conversation. What I've written above reflects my own perspective, and touches upon the points of synergy I have established with Michael's approach. Michael's perspective will be different on many points because because we have converged here along very different paths, driven by different sets or configurations of concerns, but I have have found far more synergy here than elsewhere.