Further integrating mutual credit concepts into exchange

[fosterlynn]

This is undeveloped yet, but I want to get the thought out here.

In starting to work more with the mutual credit people around the MAN, and also with a network that wants to combine mutual credit and production (GoPacifia in Argentina @gopacifia), there has been some discussion of how this would work.

In mutual credit, you basically get credits in exchange for another resource or contribution or work/service. The credits can be used as currency within the scope of some context.

In #32 we are getting to a model of being able to exchange or reciprocate based on events of any kind, for example work. We have modeled Commitment and CommitmentEvent (vf names not determined) as being the way to manage the many-to-many relationships that happen (partial payments, payments for more than one shipment, etc. - using the standard business terms to get across the idea, of course it can be anything). For some use cases, this takes the place of Claim.

I think in addition, it would be useful to represent these commitments (or something) as something that can be transferred or issued, like mutual credit can. It couldn't apply to all Commitments, which have different strengths of commitment. And maybe it goes another direction.

This happens now in the conventional business world where companies can and do sell their accounts receivable.

For OVNs we know, who distribute income based on value equations, they don't trade their claims based on their contributions. But why couldn't they? What if you were issued some credit immediately on recording of your contribution based on the value equation (or any other agreement)? And then you could use your credit in other exchanges?

Like I said, this is just a high level concept right now. I think I would start with seeing how McCarthy handles it, and then think about the model @elf-pavlik and I have been working on together for how reciprocity works.

Thoughts? Crazy?

[fosterlynn]

This may be as simple as making sure that vf:Resources can go negative (or maybe a type of vf:Resource - probably most accounts can go negative, including bank accounts).

I'm asking around..... [edit]

I am trying to figure out if the qudt element we are using can go negative.....

[elf-pavlik]

This may be as simple as making sure that vf:Resources can go negative (or maybe a type of vf:Resource - probably most accounts can go negative, including bank accounts).

This sounds in a way like making commitment(s) to receive on that account (promising that to all peers in mutual credit system that this account belongs to) Later one needs to make agreements with others which would result in receive on that account and this way fulfilling that commitment. I think this interpretation fits how people think of mutual credit accounts - if someone has 'negative balance' others participants in that currency have expectation that this person will engage in exchanges which will bring that balance to > 0

EDIT: actually it looks more like promise to engage in transaction which will include receive on account of person making that commitment. So the person with negative balance can't simply say "i like it this way, why don't I just keep my little negative resource this way", because that would result on failing to fulfill commitment/promise made to other participants and leave record which other peers very likely will include when developing perception of that person's reputation. We could compare negative balance to a Claim.

Positive balances seems like commitments to issue (promising that to all peers in mutual credit system that this account belongs to).

EDIT: this also seems more like promise to engage in transaction which will include issue, actually positive balance represents "I have expectations toward others participants of that currency system that they will reciprocate my past contributions". so it just makes reciprocity between actual (non currency) events more indirect and 'liquid' which makes issue and receive on credit currencies not reciprocal event on it self but more just a promise that someone of the participants will provide events with actual reciprocity.

Since all one can do with credit currencies (including mutal credit) boils down to receive and issue it from accounts. In practice we don't have any meaningful resource which one can use/consume/produce but just bunch of commitments to do issue / receive events on particular accounts. https://github.com/valueflows/resource/issues/12 Credit currencies come as a way to express certain social agreement and have no 'resource like qualities' outside of that particular agreement.

[bhaugen]

Matthew Slater, who has worked on mutual credit systems as much as anybody we know, thinks of negative balances as IOU's to the community, and positive balances meaning you have an IOU from the community.. Which matches your description above.

I am also wondering if mutual credit would be a simple way to implement peerconomy...

[elf-pavlik]

I am also wondering if mutual credit would be a simple way to implement peerconomy...

I still aim at polyeconomy (plural economy) where everyone can choose to engage or not to engage in any number of those systems.

thinks of negative balances as IOU's to the community, and positive balances meaning you have an IOU from the community..

IOU ~= you have a Claim

but we have case on very unspecific Claims which require CfA to possibly render more specific Commitment which fulfilled by Event will satisfy part of that Claim. in a way big Claim major negative balance gets satisfied bite by bite, possibly each time splitting it in specific Commitment + reminder of original Claim. i think we should create scenario with small mutual credit network and analyze how it works.

[elf-pavlik]

but we have case on very unspecific Claims which require CfA to possibly render more specific Commitment which fulfilled by Event will satisfy part of that Claim

Timabanks make such IOU, Claims little more specific, person with negative hours in practice has commitment to work this amount of hours where work events will have any other member of the timebank as receive party.

@fosterlynn I think we could model timebanks and mutual credit banks as an agreement where negative balances stay modeled as broad commitments/claims and Events with Fulfillments help keeping the track on state of those commitments/claims. Similar to those 1-on-1 exchange cases where you had 'partial payments' and 'over payments' ('over payment' event will later have fulfillment on it for a commitment made chronologically after the 'over payment' event occurred)

[fosterlynn]

I think that there is no need to instantiate any claim or commitment for the negative timebank hours (IOUs). It is there in any case based on the events so far and there is no other need, especially since it is not specific. @elf-pavlik is that what you were saying?

[elf-pavlik]

Not really, while in case of mutual credit we have quite unspecific Claim, for timebank it seems much more specific. For 'negative balance' we would have All the rest of timebank participants, have claim that person with negative balance will work some of the requests from the rest of participants for number of hours equal the negative balance. For 'positive balance' we would have

• The person with 'positive balance' has claim that all the rest of timebank participants will work some of the requests from that person for the number of hours epal the positive balance.*

If we represent all the timebank participants as agent T, and each of those participants as P1, P2, P3 ... for the P2, 'all the rest of participants' means a group agent (T - P2) etc. While we can consider all the participants as group agent T we can also consider each of the rests o n participants as group agent (T - Pn). This way we have individual and group agents to represent those commitments.

[fosterlynn]

Wouldn't that get pretty messy? Instantiating a new commitment whenever someone goes negative; and whenever they go up, hooking up to some one or more earlier commitments?

Again, we don't need to instantiate a claim when the data already indicates one. This applies in any case, not just timebank.

In terms of the group agent (T - Pn), I don't think that is an agent. Did that group of people have some agreement without Pn?

[fosterlynn]

Re. can our quantity go negative, thanks to @elf-pavlik :

qudt:numericValue
  rdf:type owl:DatatypeProperty ;
  rdfs:isDefinedBy <http://qudt.org/2.0/schema/qudt> ;
  rdfs:isDefinedBy <http://qudt.org/schema/qudt> ;
  rdfs:label "numeric value" ;
  rdfs:range dtype:numericUnion ;

<rdfs:Datatype rdf:ID="numericUnion"><owl:equivalentClass><rdfs:Datatype>
<owl:unionOf rdf:parseType="Collection">
<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#float"/>
<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#decimal"/>
<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#integer"/>
<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#double"/>
</owl:unionOf></rdfs:Datatype></owl:equivalentClass

xsd:float can go negative so dtype:numericUnion can also

[elf-pavlik]

Just capturing some thoughts on this issue:

1) I think in mutual credit systems, all participants agree that they should increment their accounts if they have balance < 0 and decrement them if they have balance > 0, when they have balance = 0 the have no commitment to others. I think it matters that everyone goes towards 0, most mutual credit systems has some 'maximum level below zero' but I don't know if they have maximum level above zero for the accounts. If some % of participants goes hight above zero, and all there rests hits the negative floor, as long as that % with positive balances refuses to participate in exchanges that will decrement their accounts, all that rest can't use that mutual credit currency in exchanges any more.

2) The mutual currency gets used just as facilitation tool for asynchronous m:m matching of primary intents among all the participants.

3) One account can NOT issue it without other one that receive it and vice-versa, and 'the bank' that provides mutual credit (sort of facilitation service) needs to always have all the events that decrement one account and increment another one - if we have it as issue and receive process, those two events needs to get handled as atomic transaction. Also all the people who act as receiver on that facilitation service that 'the bank' acts as provider, they don't really "own" those accounts, they don't have full control over them e.g. they can not say "i will take 'my' account and move it to another bank". The bank owns all the accounts and in real 'mutual credit' sum of all the balances should always stay 0 - the issue and receive need to happen as part of single transaction, otherwise 'between' issue and receive sum would stay != 0. see model proposed in https://github.com/valueflows/valueflows/issues/143#issuecomment-283954197 which suggests single atomic 'transaction' and not independent event (even if they reference one another or a common process).

4) Since each agent can have at most one timebank / mutual credit account assigned, it suggests that the commitment making agency and trust/reputation matter here and not the 'content' of the account.

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/exchange/-/issues/33.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.