--
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.
What is the connection (if any) between https://gitlab.com/credit-commons-software-stack/cc-node and https://github.com/ic3network/mccs-alpha-api which I found through https://mutualcredit.services/about-us#about-team (Dave Darby) and https://opencredit.network/2020/07/09/an-open-source-api-for-mutual-credit-trading-groups/ ?
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!
What is the connection (if any) between https://gitlab.com/credit-commons-software-stack/cc-node and https://github.com/ic3network/mccs-alpha-api which I found through https://mutualcredit.services/about-us#about-team (Dave Darby) and https://opencredit.network/2020/07/09/an-open-source-api-for-mutual-credit-trading-groups/ ?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-ledgerWow 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/network-money/672beeb8-66f9-4bba-b41d-1b1098df88a4%40www.fastmail.com.