search

valueflows / exchange

exchange has moved to https://lab.allmende.io/valueflows/exchange
3 stars 4 forks source link

sync vs. async exchanges #14

Closed elf-pavlik closed 4 years ago

elf-pavlik commented 8 years ago

Use Case to capture:

  1. Sofia & Pavlik receive dental health care from Dr. Cesar
  2. Sofia requires 3 sessions, Pavlik 2 sessions
  3. Pavlik pays to Cesar in cash after first sessions for his both sessions (current and next a week later)
  4. Sofia pays to Cesar in cash 10 days after session last session for all 3 sessions

As we see here we have exchanges where physical service gets exchanged for virtual currency. Async aspect works in both directions, one payment ahead of service and one payment after the service.

In both case we have promise that reciprocal Transfer will happen at certain point in the future.

fosterlynn commented 8 years ago

@elf-pavlik good use case. I'll try the simplest version here, for discussion.

Pavlik:

Sofia:

fosterlynn commented 8 years ago

^ A couple notes: In this case, the promises are implied, not recorded. They can be reported if Dr C needs to send a statement or Sofia needs to figure out what she owes. Also, note that these are probably not all recorded in the same place, maybe Sofia and Pavlik and Dr C each have their own records, which would include either the Give or Receive event that pertains to them.

elf-pavlik commented 8 years ago

thank you @fosterlynn

i would prefer not to say that service 'has value 200 currency', service can have time duration, location etc. but the 200 currency seems better to me expressed as what the other party after negotiation requests to have transferred in return to consider our economic relation levelled and/or what i promised to transfer. this way it will also work for barter scenarios while statement 'service has value of 3 smiles when given to John and 10 pumpkins when given to Jane' sounds less clear to me. maybe 'price' could work as mental shortcut for above, while still not emphasising the negotiation part and that different parties can expect different prices . most of all i would really prefer to not overload term 'value'

actually i think in this case, Cesar as old friend of family offered lower prices for his services than he normally requests (default price).

fosterlynn commented 8 years ago

@elf-pavlik thanks! Yes, the value is a secondary attribute, the main quantity and unit would be 1 dental session, or N hours, or 2 fillings, or whatever. And yes, "price" would be better for this, I agree. "Value" is indeed overloaded.

I put it to indicate that you can price a service if you want. Possibly a more clear way to say the price is to record a commitment or promise for the payment to happen, which we also need to support. We might need something to support line items price though, for multiple services or products delivered in the same order or time or package or whatever. Like maybe Dr C provided 2 fillings at price 44 and one cleaning at price 22. If you record a promise to pay, that is 66.

bhaugen commented 8 years ago

Or, alternatively, you could just record reciprocal commitments from the dentist to provide dental service and from Pavlik or Sofia to pay for it. Then you don't need to get into price or value, just the reciprocal commitments.

I don't know if this happened upfront or not. But for example if I take a car to a mechanic, when the mechanic knows what needs to be done, they will tell me roughly what they will do, and how much they expect me to pay. So both commitments are recorded before they do any work. Sometimes I pay first, sometimes I pay after the service.

elf-pavlik commented 8 years ago

Or, alternatively, you could just record reciprocal commitments from the dentist to provide dental service and from Pavlik or Sofia to pay for it. Then you don't need to get into price or value, just the reciprocal commitments.

:+1: i see that this way we can support currently common in the mainstream agreements based on one party needing to use a monetary currency to reciprocate, but we also support with the same modelling barter and other possible agreements which encourage reciprocity.

@fosterlynn I would also like to create example of the snapshot for each of the datasets (Pavlik, Sofia and Cesar each have their own domains) at each point of time. This way we will sometimes have pending promise, sometimes fulfilled promise and sometimes rejected promise - eg. Cesar had an accident and can't offer dental service which he promised.

I'll add parallel use case which introduces barter. So instead of Transfering monetary currency to reciprocate. Pavlik will help with concrete issue in the tracker of open source software for managing medical clinics and Sofia already gave 2 djambe percussion classes to a niece of Cesar.

fosterlynn commented 8 years ago

I'll add parallel use case which introduces barter.

:+1:

I would also like to create example of the snapshot for each of the datasets (Pavlik, Sofia and Cesar each have their own domains) at each point of time.

I can work on that tomorrow. Would like to start to include the promise/commitment part.

fosterlynn commented 8 years ago

Hey Sofia plays the djembe? Cool! :smile:

fosterlynn commented 8 years ago

(Hmmm I started this ages ago, and it still sits here not submitted. Looks sort of done, I'm just going to put it out there in case we want to pursue this more later.)

Separate datasets, still brainstorming, for discussion:

Pavlik:

Sofia:

Dr C:

elf-pavlik commented 8 years ago

Pavlik:

  • Exchange1
    • Transfer1
    • Receive (value flow) 3/1/2016 Pavlik from Dr C one dental service, price 100 currency,

Not sure if we even need a transfer here, I didn't received any rights, and Dr C just did a particular Service, which I benefited from.

Also once again I wouldn't use price here. We may need some kind of commitment from me to pay 100, or if we do it sync we don't even need that commitment.

  • Transfer2 * Give 3/8/2016 Pavlik to Dr C 150 currency

This one looks like a transfer of rights to virtual resource - monetary currency

  • Transfer3 * Receive 3/15/2016 Dr C to Pavlik one dental service, price 50 currency

Again, we don't have rights here. We might have need some kind of commitment (promise), which in a way would make async exchange a sync one. I transfer currency and Dr C transfers rights to a particular service he offers. Transfer of this commitment(promise) would happen on 3/8/2016 and than I would use those transferred rights to claim service on 3/15/2016

I very much appreciate that you made distinct separation between the three datasets. Can we please from now on always also add 'neutral' observer? For example I would like to keep records about all my economic flows fully transparent and available at some open public notary service. Also @bhaugen keeps mentioning taxation agents which might also like to keep the copy of records which he chooses to make available exclusively to them :wink:

bhaugen commented 8 years ago

@elf-pavlik please don't blame me for the taxation agents.

fosterlynn commented 8 years ago

Not sure if we even need a transfer here, I didn't received any rights, and Dr C just did a particular Service, which I benefited from.

I think there will often (always?) be a transfer when paid-for services are involved, although in many cases it may not be worth recording. The actual doing of the service is probably processes for the agent doing them, possibly with the service as an output resource, if you want to connect up the value flow. Same with shipping/transporting. Then when you pay, you pay for a resource that is just the service. I see what you are saying about rights, it is pretty indirect and unclear - so maybe we need to expand the definition of Transfer to make this clear.

Also once again I wouldn't use price here. We may need some kind of commitment from me to pay 100, or if we do it sync we don't even need that commitment.

Oh yeah, forgot about the price discussion, I'm good with leaving it off. You can get price elsewhere. And yes, we could record a commitment for the amount if you are going to pay later. (Or if we know the price, we could assume the commitment because a service was recorded, but no payment.)

or if we do it sync we don't even need that commitment

Agree.

gcassel commented 8 years ago

Not sure if we even need a transfer here, I didn't received any rights, and Dr C just did a particular Service, which I benefited from.

-- It may be reasonably proper to say that you received a service in that case. However, we really must create vocabulary which accounts for services which develop, maintain or modify commonly held resources, in addition to purely personal services...

elf-pavlik commented 8 years ago

Regarding price, I would really like that we make sure to model reciprocity in very generic way, this way avoid propagating monoculture of accounting systems as we see it today. If someone offers a Resource (Product, Service or MonetaryCurrency) person can define any number of possible resources it would like to exchange it for (also Product, Service or MonetaryCurrency). In that example we would have Dr C offering to exchange particular Service for certain amount of particular MonetaryCurrency. He could at the same time add any number of other options which could involve other monetary currencies, a time bank hours, barter for some Product or Service, or even reputation requirements e.g. "has volunteered at least 3 times in https://www.letsdoitworld.org actions". I really need to resurrect http://polyeconomy.info/ to keep clarifying that requirement.

fosterlynn commented 8 years ago

Regarding price, I would really like that we make sure to model reciprocity in very generic way

@elf-pavlik I agree, thanks for bringing it up! (I forgot to take it out earlier.)

elf-pavlik commented 8 years ago

I added this use case as markdown file https://github.com/elf-pavlik/valueflows/blob/master/use-cases/dental-care-md

Or, alternatively, you could just record reciprocal commitments from the dentist to provide dental service and from Pavlik or Sofia to pay for it. Then you don't need to get into price or value, just the reciprocal commitments.

@bhaugen how would you describe a Commitment to transfer ownership of monetary currency (aka. pay) and Commitment to provide a particular dental service? The last one seems like transferring rights to consume that service. We can add gift card aspect where I get commitment from Dr C for particular standard service and I give it to a friend to reclaim it at Dr C clinic and in a way consume that service.

bhaugen commented 8 years ago

how would you describe a Commitment to transfer ownership of monetary currency (aka. pay) and Commitment to provide a particular dental service? The last one seems like transferring rights to consume that service.

I wouldn't describe it that way, and if I was the dentist, would not like it. "What? You think you got a right to my dental services? Who do you think you are?" I think it is a simple Commitment from the dentist to provide service. What am I missing?

We can add gift card aspect where I get commitment from Dr C for particular standard service and I give it to a friend to reclaim it at Dr C clinic and in a way consume that service.

That's an odd one. A lot of people think gift cards are a type of currency...I'm thinking about it.

elf-pavlik commented 8 years ago

I wouldn't describe it that way, and if I was the dentist, would not like it. "What? You think you got a right to my dental services? Who do you think you are?" I think it is a simple Commitment from the dentist to provide service. What am I missing?

If you make a commitment that you will give a particular service to a particular person. For example "Give a ride from one town, to another town (~20km) on particular day". Maybe even as part of exchange where you have already consumed service of the other person (eg. got your car fixed). If you don't see that the other person has right to consumer the service which you promised (made commitment), how else do you describe it?

bhaugen commented 8 years ago

If you don't see that the other person has right to consumer the service which you promised (made commitment), how else do you describe it?

I suppose you could describe it that way, but it seems excessive and unnecessary to me. Then you'd need to define "right" in that situation. I would reserve rights in the vocab to relationships between agents and some kinds of resources, in which set I would not include services of humans.

as part of exchange where you have already consumed service of the other person (eg. got your car fixed)

In that case, you have a claim, which is stronger than a commitment. If you do your part of a set of reciprocal commitments, then you have a claim for the reciprocal event to happen.

gcassel commented 8 years ago

Some services create enduring resources which ought to have usage-rights associated with them, so that the intended recipient of those services feels secure about receiving (and maintaining access to) the resources they expect to get. Other services, however, do not.

For instance, part of the service in a dental checkup will be the cleaning of teeth. That's a process which is applied directly to the recipient's body. Technically, the service transforms the recipient's body -- a (very) personal resource-- slightly.

However, another part of the service in a dental checkup may be the creation of x-ray dental prints. These enduring resources should IMO be associated with usage-rights. (Typically, I think, to be shared by the dentist and by the recipient.)

elf-pavlik commented 8 years ago

@fosterlynn since we did 'cash payment', none vf:Transfer of MXN will have information about 'from stock' or 'to stock', just

Now we need record of cash delivery (vf:Transportation), each bill has tracking number and I used one 500MXN bill and one 100 MXN bill. Since bills don't act as resources, more as legacy proofs of ownership rights. we will need to deal somehow with them. I will create issue in main repo about dealing with various monetary currencies. Let's leave the delivery for later and focus on vf:Transfer used for defining vf:Exchange.

bhaugen commented 8 years ago

From an observable behavior viewpoint, cash money works fine as a resource. "Legacy proofs of ownership rights" is the kind of theoretical argument about money that I would prefer to avoid.

elf-pavlik commented 8 years ago

@bhaugen could you please propose in https://github.com/valueflows/currency/issues/1 a data structure to express cash payments from use case discussed here?

elf-pavlik commented 8 years ago

following my proposal in https://github.com/valueflows/valueflows/issues/122

'@context': https://w3id.org/valueflows/v1
'@id': did:74088536-5a09-4117-bf5c-25bb38757f2e
'@type': vf:Transfer
'vf:from':
  '@id': did:68aed952-05ee-433e-974b-e8713c163860
  'vf:name': elf Pavlik
'vf:to':
  '@id': did:a5aec17e-ddfd-46c7-bb1a-001632f57852
  'vf:name': Dr C
'vf:rightsTo':
  '@type': vf:Cash
  'qudt:numericValue': 600
  'qudt:unit': MXN

if we need to capture delivery of that cash, we need additional data structures for it

almereyda commented 4 years ago

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/14.

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