Just making my first adventure into HoloChain!
We are a non-profit which focuses on community currencies and community driven basic income. Here is an example Solidity contract we are using Grassroots Economics / sarafu-token Ā· GitLab that is is a simple mint-able token that has Demurrage (holding tax) and redistribution.
Would anyone want to take a whack at tutoring me and the Grassroots Economics team on how these concepts would translate into HoloChain / Rust?
I would be very excited to play with you around this. We have a small commoning group in this community, and we already have some prototype in ongoing development for mutual-credit currencies. You can even play with it in the compository right now if you feel like it.
We have already thought about implementing demurrage, it is a very interesting topic to me (I have technical expertise, but very little experience with community currencies). Also, it would be interesting to see how we can adapt a holochain application to fit your specific needs.
Awesome! Iām really behind in even understanding how HoloChain is different from how we develop for BlockChain right now - and I thought just making a Demurrage token on HoloCHain would be a good starting point. (we currently have over 40k users using such a token now in Kenya ā¦ just moving them over to HoloChain would be amazing)
Hello Will,
I would love to be part of this conversation. We are a non-profit organization from Germany and we support social startups. We have already launched over 300 social startups since 2014. Now we have a community of many small social founders who are struggling to fund or even to collaborate with each.
I would like to develop a local cooperative infrastructure that allows this community to cooperate, help each other and at the same time involve the local community, e.g. volunteers.
For me, a mutual credit system is the only thing that makes sense and I love your idea of introducing a fee %, collect it in a reserve fund and redistribute it as a universal basic income - as I understand, you did it with the Sarafu.network.
I would like to know more about that.
For the last few months Iāve been getting a feel for whatās going on in the community currency space and Iām excited to see that thereās so much happening! Iām hoping to learn as much as I can to launch a project in Puerto Rico where the levels of food insecurity are staggering for an island with so much potential for farming.
@wor The Safaru project is truly inspirational (THANK YOU) and I find it somewhat serendipitous that the first forum thread I read here is yours after watching your MOOC just a few days ago. The more I learn about HoloChain the more Iām drawn to it, but Iām not a dev and have only a superficial understanding of how blockchain works and how HoloChain is different. So I wonder, what is your motivation to move from blockchain to HoloChain? Were there any experiences or bottlenecks that led you to explore this transition?
Hi @oscar and thanks. I really have just gone with what was available to use in a village. Starting with paper vouchers and eventually going digital with cyclos and a ussd front end and now a POA bockchain and a USSD front end. I started another thread here HoloChain vs POA Blockchain just to talk about the difference between the two. I believe HoloChain will offer a lot more decentralization and easy bridging between apps/blockchains but Iām also a newbie here. Hence the idea of learning while doing and understanding HoloCHain by moving over a particular Solidity contract (Sarafu). Iām an activist and very active in humanitarian circles - and I would love to champion a system that can fit the bill of Humanitarian Infrastructure and isnāt a get rich scheme, Pepe the Frog to the Moon club, or only available to universities or people who stake $$ to own a validation node etc.
picking up here @guillemcordoba So - for a basic income we have a contract that mints new tokens when a user is validated (we validate phone numbers here in Kenya).
There is a continuous (minute resolution) demurrage (which just alters the display of that users available balance) then a periodic (weekly) redistribution of those tokens evenly to all active users. āTrade Balanceā (like: Volume in - volume out) is something we deal with at the user interface level.
Translating that to HoloChain (thinking out loud):
So rather than each user having a wallet on a blockchain. In HoloChain each user is an agent. (We may have a super user/agent that manages custodial accounts where the user is only using USSD (no internet) - but lets assume we are dealing with users with andriod phones here.)
These agents (users) can be validated and on their own HoloApp they get these Sarafu tokens - and those tokens automatically decay (demurrage) - and report back to eachother how much decay happened and redistribute that amount back to active users.
When users trade with each other - their is a handshake and protocol for them to exchange tokens.
With a data sharing layer - users can choose to share their tx history, meta data (gender, age) with specific orgs. It could be that all tx data is made public by default (like on a public blockchain).
If someone wants to create a or add to a liquidity pool (holding 2 of these or other tokens) - that would be a separate HoloApp - which can interface with the others - so you can send a token to a pool and so on.
Right, so mostly yes, although I have some comments.
The best way to think about this in my experience is as accounting: you donāt commit your balance or the number of credits you have, but rather only the amounts of each transaction (ala bitcoinās UTXO). Then, transactions have in their validation rules something like:
Get all transactions that this agent has made and aggregate the balance
Check against the limit they have at the moment of making the transaction (in the case of mutual credit, this is a negative credit limit). If the transaction amount violates the limit, reject the transaction.
Iāve never thought about āminting tokensā in a holochain context, but I guess you can achieve the same result by hardcoding in the validation rules that everyone started with some amount of credits, and aggregate the amounts from there.
The ādecaymentā of credits I would also encode in the validation rules, relying on the transactions being counter-signed and thus preventing someone from cheating about their timestamp. And yes, this counter-signature is the handshake protocol that the agents do p2p.
The easiest way to achieve this is to have the transaction history public inside the currencyās DHT, since if they are private the validation rules canāt access that data and we may be adding attack vectors. And yes, outside people canāt observe it if there is a membrane, but the participants can always choose to share it with the outside world.
If Iām understanding the pools correctly, I think it looks more like one agent (or multiple) having installed the DNAs for the two currencies, and thus being able to swap one for the other. Then, these agents can be managed by some authority; the point here is that in holochain you canāt ācall a DNAā in abstract, you are always executing an action as an agent inside that DNA. Also, sending credits from one DNA to another is really tricky since validation rules do not cross DNA boundaries.
Thanks - this all sounds like it will solve a lot of issues - like data privacy and decentralized scaling.
More on context/interfaces: For our current users in Kenya we operate a custodial wallet system - where their private keys are stored, encrypted and unlocked via a USSD interface on feature phones with no internet. When a user looses their pin we have a phone support team that validates their identity and can initiate a pin change request to the user. Some kinda of social account / password recovery system would be great.
For these (non internet connected) users - I assume we would have a centralized HoloApp that they are all accessing?
~60% of our users have some access to internet (generally via android phones) - but we donāt yet have any web based interface/wallet.
For web based users, would we develop a webApp interface usable with an andriod phone browser - or is that really just running a HoloApp?
MVP we donāt really need liquidity pools to start with. But thinking toward the ability for people to hold multiple currencies and decide to create automated exchanges for them with a given rule set. Some examples of such pools are here https://www.grassrootseconomics.org/post/static-vs-bonded-liquidity-pools-for-cics
A liquidity provider is anyone that decides to create or add their tokens to such a pool.
It doesnāt sounds like too much of a stretch to call these DNA ācontractsā ā¦
Iām so used to the language of āsmart contractā in defining these primitives concept. If we take the Solidity ācontractā here https://gitlab.com/grassrootseconomics/sarafu-token for a demurrage and redistributive token-system - something like this then becomes the DNA for what lives on a HoloApp and is fully agent centric? And the DNA for various application or ācontractsā - have interfaces such that they can communicate with each other.
We have migrated (custodial) users onto new blockchains (because of gas costs and DDoS attacks) by simply creating new tokens on a new blockchain to match their balances. Doing the same thing and pointing the USSD interface onto a HoloApp sounds possible. But dealing with custodial issues is a bit more complex in a way than going straight to a webBased (non-custodial) system first - then bringing over our custodial users later.
Should we start a GitLab repo and start specing this all out?
One point of friction may be the CAL license which basically requires that holochain is used in a way that end users are holding the private keys, or at least they derive them somehow, but not that an external user is holding them. Not at all an expert here thought, maybe @zippy wants to chim in?
I have no idea what ussd interfaces are capable of doing. I assume in your current system they send signals to some service you have running that is holding the private keys, and that is the one that makes the request to the blockchain?
Mobile is tricky: yes, holochain could be installed there, but there are concerns about the OS killing processes due to background gossiping and so on. So, for now the tendency is to build for holo to target mobile. Holo is a hosting infrastructure for holochain apps, in which users can access without running themselves the holochain node. I think the interesting thing here is that the identity mechanism of holo is deriving private keys in the browser from an email&password that the user can enter, thus preserving the CAL license and also enabling good UX for the users. Then, there is a DeepKey app which is worked on that provides public/private key infrastructure with which things like revoking private keys is enabled (this documentation is old but good enough here I think).
Hum the thing that doesnāt really fit with the smart contract concept in my mind is that a smart contract is called as if it was an external thing you interact with, while in holochain everything is done in the context of an agent. As in, instead of having tokens in this smart-contract, you are a peer agent doing a counter-signed transaction with another peer. In here, it becomes really important on cross-DNA communication, which is totally different that in a smart-contract context: if you want to call from a DNA to another, you have to have installed both DNAs and be a valid agent in both (this is called a bridge call). You cannot ācall a DNAā, you always are calling āthe instance of this agent running this DNAā.
Iām not really sure about how the āliquidity poolā translates here: isnāt an agent with the two exchanging currencies DNAs installed already all we need? This agent would be the liquidity provider I assume, but I donāt see why we need anything else. We could even create a āliquidity provider roleā, to make visible in the network who are the agents ready to do exchanges at any point in time with enough credits in the two exchanged currencies.
Yep! Letās start a repo if thatās whatās best, as I said we already have some mutual-credit code working so it shouldnāt be difficult to get going
Love the conversation here. Thanks @guillemcordoba for diving in deep and @wor for all your working and thinking on this stuff.
Re CAL: the intent of the CAL license is to address the issues of maintaining user autonomy in distributed environment. OpenSource is about user autonomy and visibility into the code they operate and the assumptions have been about centralized systems where typically ācentralizedā meant on your own computer. In the case of decentralized systems where operation of the code exists across many running machines the source of autonomy and agency lands on who controls the keys. So the CAL is meant to make that explicit so as to maintain the intent. I donāt think that the issue is about where the keys actually live, the issue is who has control over them. So as long as the running use of the code guarantees that the agent has control of the keys even if they live in a custodianās machine, thatās ok.
Re Liquidity Pools: It sounds like a liquidity pool is an agreement between two (or more) parties who live in two dfiferent mutual credit currencies to behave a certain way. That way seems to be about locking up certain amount of a currency for a time on behalf of it being āusedā in another currency. It seems quite plausible that you could add a transaction type to your currency which is a ālock-untilā which includes an unlock-token that must be signed by an external party. I.e. you promise, inside one currency, to not use a portion of your balance until you commit to your chain as a signing of the unlock token. That signature can be from an external source, because itās purpose is to guarantee to the external source that you arenāt transacting in your own currency what youāve locked up, and the rules of your currency prevent that. Make sense?
Iāve been following your initiatives from a distance, and always thought that Holochain would be really good candidate for your digital infrastructureā¦ and here you are!
Iām not a coder and have a hard time to follow that particular part of the conversation, but Iām an activist of sorts working on a concept for a Community Credit Cooperative in the slums of Payatas, Quezon City, Philippines. The funding will come from other more commercial projects Iām also involved in, but itās still quite uncertain as everything is in these pandemic times.
Anyways, just thought to give a a shout out of appreciation now, and maybe, once we get our funding done collaborate on the digital infrastructure. Youāll find more at jala.io
Thanks @wor for that info, Iām starting to get a sense of the technical elements needed to build something. In terms of the the currency design, one thing Iām not clear on with Sarafu is the role that the outside aid plays in supporting the minting of new tokens, could you comment on that or point me some where? Also, would holochain enable any benefits to that interaction?
Just getting into the liquidity pool/bonding curve concepts as well, thought you might get some ideas from this post on augmented bonding curves if you havenāt seen it already.
Totally agree with the importance of championing the right infrastructure! In Puerto Rico crypto and blockchain are rather controversial because itās become a tax haven for crypto folks and thereās been some culture clash. I feel like the ways in which holochain is different offers opportunities to build trust around a cryptographically-based community currency. And I really appreciate the thinking about value flows that has gone into the project, its leading to interesting and actionable conversations.
@guillemcordoba thanks so much for the all work here and else where! I saw your video demo of the mutual credit app (zome?) and Iām eager to watch these developments and participate when I am technically able. For the purposes of exploring project planning and funding, is there a timeline on how long it would take until Sarafu or similar projects could be built on holochain? About how many technical people would be needed to maintain/update a system at that scale?
CAL is new to me, but I love the standard. If the private keys remain encrypted and can only be accessed by the USSD (feature phone users) unlocking them with a PIN and their SIM card - that would be great. And technically that is what we do now - although if you have full access to the server with the encrypted private keys and you are able to brute force the encryption ā¦ any way there can be a lot of improve here.
for liquidity pools - yes essentially there is a locking and unlocking going onā¦ You lock 2 tokens, then to unlock them you send one token or the other. (I see a comment from @oscar below) The unlocking rule could have some variable rate, fixed rate or bonding curve (diminishing returns equation)
@guillemcordoba this is a very basic diagram of the community driven basic income program in Kenya. People start with a small inital allotment after validation, and there is a tax and simply redistribution scheme. Weāre at nearly 45,000 registrations and about ~2000 weekly users. (allowing people to make their own currencies is a main focus and Sarafu here was just meant to be a bootstrap - but gained a life of its own)
Hi Will. A pleasure to see you here. We met about 2 years ago when we met at the IXO workshop in Zurich. Still have your banknotes any carry them around. Best, Peter
Hi @guillemcordoba weāre more than happy to use some existing modules that have been written already. Looking at https://github.com/llavors-mutues/public-transactor I need more of an operational description to understand what you have and how it could replace or be customized for what weāre using in Kenya.
Humanitarian Infrastructure 
In Puerto Rico crypto and blockchain are rather controversial because itās become a tax haven for crypto folks and thereās been some culture clash. I feel like the ways in which holochain is different offers opportunities to build trust around a cryptographically-based community currency. And I really appreciate the thinking about value flows that has gone into the project, its leading to interesting and actionable conversations.
