Video

I made my remarks in an email to Oli. Here they are for the record.
Bravo!
That video is very well done.
There are however a couple technical details that seem to me a bit off.
At the very beginning, "...a way for businesses to access interest-free loans...," jars me a bit.
Of course, MC does not loan anything, it simply provides a "space" within which buyers and sellers can find one another to transact trades. That "space" is not physical, but temporal and social: buy now, reciprocate later (temporal), and buy from one, sell to another (social).
My proposal is to substitute "interest-free credit" for "interest-free loans."
By the way, banks do not lend anything either, but they want us to think they do. In effect, they provide credit clearing services but charge interest on negative balances.

At 0:39 "...the more you offer in trade, the higher your credit limit...," isn't quite accurate.
In my view, the primary factor in the credit allocation algorithm should be the amount of value, not just "offered," but actually sold and delivered to members in the network.
My proposal is to substitute for the quoted phrase, "the more you sell to members of the network, the higher your credit limit."

I very much like the statement that "Mutual credit is the antithesis of blockchain because it builds trust instead of replacing trust with technology."

Finally, I think we need to give due consideration to Nick Brown's caveats about open source software.

Thanks for your good work.
Tom

Thanks I've tweeted the video link and will do so again in a while. It's a continual surprise (to me) how few people know/understand it. Something useful, I believe would be some 'do you want to know more?' links probably underneath the video for people that wanted to dig further into it. I 'discovered' it in about 2003 via the entry for LETS in the Encyclopedia of Social Inventions, then met Michael Linton in about 2005.

Yes, the difference between loan and credit is major, and should be 100% clear. Yes free rather than open software - the most radical way of stating this seems to be ‘free-libre’ as distinct from free-lunch (these terms are a bit klunky but the politics is important). There’s good energy in OCN development at the moment, keep it up :slight_smile:

@thomashgrecojr

I think we need to give due consideration to Nick Brown’s caveats about open source software.

May I ask, what are Nick Brown's caveats?

i'd like to know that too - not sure exactly what you / he are suggesting @thomashgrecojr ?

I'm referring to Nick's article at https://nextbillion.net/payment-fraud-and-mojaloop/, which was the subject of an email exchange. I copied Oli and others. Here's the pertinent excerpt:

The Dangers of Open Source

With the stakes this high, and the cost of failure this potentially catastrophic, it’s essential for payments providers in emerging markets to act with extreme caution when implementing interoperability. And this can impact the decisions they make throughout the process.

For instance, there are incredible benefits to using “open source” code. The sharing of technology reduces the cost of adoption, and the sharing of experiences, enhancements and fixes reduces the individual costs of maintaining systems.

However, financial payment processing is not the right industry for open source approaches, especially if it involves interoperability. It encourages those with insufficient applicable experience to enter an industry they do not fully understand.

Think like a criminal organization that has been involved in large-scale payment fraud for decades. With their years of experience, having access to the core code makes it easy for them to identify existing security holes. In addition, the very nature of open source software allows them to introduce new security holes disguised as enhancements or fixes, with the intention of exploiting those holes several years in the future with massive attacks.

interesting - and important points. Don't think we need to go there in the video tho. But I do question the wisdom of sharing MC source code openly, for those reasons, and because others might take what we have built and exploit it for profit (as has happened many times to previous open source projects). It is for this reason that I suggest we use a PPL and keep the source code closed but for free available "on application" to suitably cooperative / non-profit / values aligned Orgs: http://wiki.p2pfoundation.net/Peer_Production_License

Bruce Schneier, who knows more about security than most people in the world, disagrees: https://www.schneier.com/blog/archives/2011/06/open-source_sof.html

He thinks that the code needs to be bullet-proof no matter how much people know about it, and the way to get there is by collaboration among security researchers and coders.

If the code has holes, don't think that hackers can't find them just because you did not publish your source.

TL;DR:
https://www.schneier.com/crypto-gram/archives/1999/0915.html#OpenSourceandSecurity

In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. For us, open source isn't just a business model; it's smart engineering practice.

I'm not lobbying one way or the other, just sharing information. I yield to the wisdom of the software experts in the group.