Credit Commons

38 views
Skip to first unread message

Matthew Slater

unread,
Dec 10, 2021, 6:35:43 PM12/10/21
to Network Money
Greetings Michiel and anyone else,
I was just shown your work and it is highly congruent with my own. I'm guessing from what I've read that you are working with the Ripple network structure. The Credit Commons is very similar, but it uses a tree instead of a mesh, allowing for decentralised governance.

Could I invite you to look at the following
White paper (2016)
Briefly describes nested mutual credit, and the tree structure.

A one hour presentation made earlier this year presenting the Credit Commons as a strategy for change.

Circular Trade Analytics discussion group
I strongly recommend their first meeting about Slovenia and software for identifying trade loops https://www.youtube.com/watch?v=pptoX5HRkB8
We'd love to see you at the next meeting on Tuesday when we'll be hearing from another mutual credit expert, Susana Belmonte, https://www.meetup.com/circular-economy-analytics

Software
I've built a proof of concept and now working on a reference implementation of the Credit Commons protocol and would love to compare notes.

There's lots more to share but I don't want to overwhelm you.
Hope that interests you.
Matthew

cojulapa

unread,
Feb 2, 2022, 3:04:49 AM2/2/22
to Network Money
Thanks for sharing!

Is there any documentation about the software infrastructure used?
I mean the white paper is a lot about why and what (where I largly agree) but for me it is not so tangible how this should be achieved.

Br
Coju

Michiel de Jong

unread,
Feb 2, 2022, 3:49:59 AM2/2/22
to Network Money
Ah, sorry that I had missed this post in December and missed your invitation to join your meetup. Reading and watching it now!

Cheers,
Michiel.

Michiel de Jong

unread,
Feb 2, 2022, 8:29:36 AM2/2/22
to Network Money
Hi Matthew,

I loved all the presentations you sent, thanks a lot! Great to see if other people think about the same issues along the same lines. :)


Regarding mesh vs tree, I think both can work and they don't have to be exclusive.

There is one important issue about regulation: to act as a Money Transfer Agent, the parent ledger would need an appropriate license, and would need to comply with KYC and anti-money laundering regulations. Blockchain miners are exempt from this because they don't have a way of knowing whose transactions they are mining, and community currencies are exempt because they are local and small-scale, and therefore not so attractive for illegal goods traders and money launderers. But when we tried to set up the Interledger community network we basically had to stop due to this. The Interledger project then pivoted to streaming payments, part of its core team moved from Ripple to Coil, and I went back to thinking about "clearing" rather than about "payments". It's also why I started labeling my work as "Federated Bookkeeping" instead of "Federated Payments". It's the same thing, but under a less regulated label. :)

Regarding specific protocol and API details, we now try to take a polyglot approach where the bookkeeping protocol may be different at edge network edge. This doesn't work for loop detection and debt settlement (all participants in a loop settlement will have to use the same hashlock and the same understanding of the expectations and timeouts), but multiple settlement mechanisms could in theory exist in the same mutual credit network.

In our work at Ponder Source we are taking Peppol as a starting point (the e-invoicing network that is quickly becoming the standard in Europe and other parts of the world). The first thing we're working on now is making participation in Peppol easy and free for small businesses. It's XML in SOAP attachments, so not our first choice, but once we have the pipes working for invoicing we can add signals for supplier / consumer credit, and move the importance of payments to the background.

At the same time we're also experimenting with pre-journal bookkeeping (very early stages): https://github.com/federatedbookkeeping/world-ledger 

I'll check out https://gitlab.com/credit-commons-software-stack/cc-node/ and see what we can do to help you with that!

Cheers,
Michiel.

 


--
You received this message because you are subscribed to the Google Groups "Network Money" group.
To unsubscribe from this group and stop receiving emails from it, send an email to network-mone...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/network-money/3658db3c-9e4a-49fc-8c59-8e1b852a1659n%40googlegroups.com.

Matthew Slater

unread,
Feb 6, 2022, 12:14:32 PM2/6/22
to cojulapa, Dil Green
There is some history there...
The first attempt to build a credit commons exchange network was aimed towards the LowImpact type demographic. Geoff Turk offered to build the web site and the software, but at that point we hadn't specified an API or accounting engine. So MCCS is an open source lightweight business barter package with an API.
Then I built a proof of concept with a draft API and the gitlab CC-node above is a reference implementation. Its a pure accounting engine, and not a full platform for running a business barter network.

Regarding mesh vs tree, I think both can work and they don't have to be exclusive.
One network cannot embrace both architectural approaches. The difference is critical when it comes to how trade imbalances are resolved. The mesh approach seems elegant and obvious at first, but it allows for no collective / political activity.  Try resolving collective trade imbalances without any kind of group forum or ability to impose trading restrictions. The tree approach means every account is in a group and subject to group policy.
So saying, if these systems are not dominant, then trade imbalances can always be resolved with dollars. Mesh networks could be very useful, but that brings us to another difficulty, which is that it seems to be harder to get mesh networks to scale, because they are simply not useful until they attain a certain density.

There is one important issue about regulation: to act as a Money Transfer Agent, the parent ledger would need an appropriate license, and would need to comply with KYC and anti-money laundering regulations. Blockchain miners are exempt from this because they don't have a way of knowing whose transactions they are mining, and community currencies are exempt because they are local and small-scale, and therefore not so attractive for illegal goods traders and money launderers. But when we tried to set up the Interledger community network we basically had to stop due to this. The Interledger project then pivoted to streaming payments, part of its core team moved from Ripple to Coil, and I went back to thinking about "clearing" rather than about "payments". It's also why I started labeling my work as "Federated Bookkeeping" instead of "Federated Payments". It's the same thing, but under a less regulated label. :)
Good work.
I'm not sure why you bring up KYC though. In what we are doing, no money is changing hands on any ledger, only private, mutually assured promises to pay, like credit notes.

Regarding specific protocol and API details, we now try to take a polyglot approach where the bookkeeping protocol may be different at edge network edge. This doesn't work for loop detection and debt settlement (all participants in a loop settlement will have to use the same hashlock and the same understanding of the expectations and timeouts), but multiple settlement mechanisms could in theory exist in the same mutual credit network.
I would welcome expansion of this point, though I haven't looked in detail at the project yet.
Thomas Fleischman is the expert on different 'settlement mechanisms' and loop detection.
When you talk about the same 'understanding of expectations and timeouts' and the same hashlock, that sounds to me like the same 'protocol'. In which case it sounds like you are trying to bridge between different protocols. It feels like an awkward space.

In our work at Ponder Source we are taking Peppol as a starting point (the e-invoicing network that is quickly becoming the standard in Europe and other parts of the world). The first thing we're working on now is making participation in Peppol easy and free for small businesses. It's XML in SOAP attachments, so not our first choice, but once we have the pipes working for invoicing we can add signals for supplier / consumer credit, and move the importance of payments to the background.
this will interest Dil [cc'd but not in the group]

At the same time we're also experimenting with pre-journal bookkeeping (very early stages): https://github.com/federatedbookkeeping/world-ledger 
Wow that feels like an unwelcome diversion from the main mission! You want to change how businesses does accounting, but before that you've got to change how banks do accounting. Argh! I've been there.

I'll check out https://gitlab.com/credit-commons-software-stack/cc-node/ and see what we can do to help you with that!
This is a really challenging project for me. The main question at the moment is how to easily set up multiple instances of the web service in order to run the testing scripts on a federated network of web services. Currently if you follow the installation instructions you'll manually create the apache virtualhosts and /etc/hosts entries and then edit the default configuration files to set up a single instance. I'm wondering if I can create several connected instance on the fly just for the duration of the testing routine.

Michiel de Jong

unread,
Feb 7, 2022, 5:40:04 AM2/7/22
to Matthew Slater, cojulapa, Dil Green
On Sun, 6 Feb 2022 at 18:14, Matthew Slater <mats...@fastmail.com> wrote:

There is some history there...
The first attempt to build a credit commons exchange network was aimed towards the LowImpact type demographic. Geoff Turk offered to build the web site and the software, but at that point we hadn't specified an API or accounting engine. So MCCS is an open source lightweight business barter package with an API.
Then I built a proof of concept with a draft API and the gitlab CC-node above is a reference implementation. Its a pure accounting engine, and not a full platform for running a business barter network.

Regarding mesh vs tree, I think both can work and they don't have to be exclusive.
One network cannot embrace both architectural approaches. The difference is critical when it comes to how trade imbalances are resolved.

I think sometimes they can not be resolved, and this is not a failure of the IOU-passing system.
 
The mesh approach seems elegant and obvious at first, but it allows for no collective / political activity.  Try resolving collective trade imbalances without any kind of group forum or ability to impose trading restrictions. The tree approach means every account is in a group and subject to group policy.

Sure, but as a user I could have a positive account balance at more than one group, as well as at more than one individual, just in one-to-one relationships.
 
So saying, if these systems are not dominant, then trade imbalances can always be resolved with dollars. Mesh networks could be very useful, but that brings us to another difficulty, which is that it seems to be harder to get mesh networks to scale, because they are simply not useful until they attain a certain density.

There is one important issue about regulation: to act as a Money Transfer Agent, the parent ledger would need an appropriate license, and would need to comply with KYC and anti-money laundering regulations. Blockchain miners are exempt from this because they don't have a way of knowing whose transactions they are mining, and community currencies are exempt because they are local and small-scale, and therefore not so attractive for illegal goods traders and money launderers. But when we tried to set up the Interledger community network we basically had to stop due to this. The Interledger project then pivoted to streaming payments, part of its core team moved from Ripple to Coil, and I went back to thinking about "clearing" rather than about "payments". It's also why I started labeling my work as "Federated Bookkeeping" instead of "Federated Payments". It's the same thing, but under a less regulated label. :)
Good work.
I'm not sure why you bring up KYC though. In what we are doing, no money is changing hands on any ledger, only private, mutually assured promises to pay, like credit notes.

Regarding specific protocol and API details, we now try to take a polyglot approach where the bookkeeping protocol may be different at edge network edge. This doesn't work for loop detection and debt settlement (all participants in a loop settlement will have to use the same hashlock and the same understanding of the expectations and timeouts), but multiple settlement mechanisms could in theory exist in the same mutual credit network.
I would welcome expansion of this point, though I haven't looked in detail at the project yet.
Thomas Fleischman is the expert on different 'settlement mechanisms' and loop detection.
When you talk about the same 'understanding of expectations and timeouts' and the same hashlock, that sounds to me like the same 'protocol'. In which case it sounds like you are trying to bridge between different protocols. It feels like an awkward space.

In our work at Ponder Source we are taking Peppol as a starting point (the e-invoicing network that is quickly becoming the standard in Europe and other parts of the world). The first thing we're working on now is making participation in Peppol easy and free for small businesses. It's XML in SOAP attachments, so not our first choice, but once we have the pipes working for invoicing we can add signals for supplier / consumer credit, and move the importance of payments to the background.
this will interest Dil [cc'd but not in the group]

At the same time we're also experimenting with pre-journal bookkeeping (very early stages): https://github.com/federatedbookkeeping/world-ledger 
Wow that feels like an unwelcome diversion from the main mission! You want to change how businesses does accounting, but before that you've got to change how banks do accounting. Argh! I've been there.

I'll check out https://gitlab.com/credit-commons-software-stack/cc-node/ and see what we can do to help you with that!
This is a really challenging project for me. The main question at the moment is how to easily set up multiple instances of the web service in order to run the testing scripts on a federated network of web services. Currently if you follow the installation instructions you'll manually create the apache virtualhosts and /etc/hosts entries and then edit the default configuration files to set up a single instance. I'm wondering if I can create several connected instance on the fly just for the duration of the testing routine.

--
You received this message because you are subscribed to the Google Groups "Network Money" group.
To unsubscribe from this group and stop receiving emails from it, send an email to network-mone...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages