search

valueflows / exchange

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

payment method #25

Closed ahdinosaur closed 4 years ago

ahdinosaur commented 8 years ago

from https://github.com/elf-pavlik/currency/issues/3#issuecomment-217305124,

We also have the whole 'payment method' mess, which only relates to currencies and no other types of digital resources - cash, check, credit card, direct, transfer, payment gateway (paypal, satoshipay), or even https://www.w3.org/Payments/

here's a dedicate issue regarding "payment method".

elf-pavlik commented 8 years ago

Why do you see it as concern fitting `valuflows/exchanges'? It seems to me more as transportation of digital coins or transportation of analogue coins (or bills or cheques). IMO both seem a vf:Process.

Neither vf:Transfer nor vf:Exchange deal with physical or virtual location of resource, which rights to we vf:Transfer (vf:Exchange).

Just as vf:Exchange which involves rights to Cash or Credits in many cases will trigger vf:Transportation (vf:Process) of 'underlying resource'. vf:Exchange, which only involve rights to physical resources like apples and bolts, will in many cases trigger vf:Transportation (vf:Process) of 'underlying resource'. I understand we try to model vf:Currency as more specific type of vf:Resource, so we should treat the shipping/delivery aspect in similar way as for physical resources. As well as not mix rights to the resource with resource itself. To my understanding in this repo we focus on the rights aspect and not physical or virtual location of the resource. valueflow/process seems appropriate for modeling shipping/delivery.

ahdinosaur commented 8 years ago

@elf-pavlik says: Why do you see it as concern fitting `valuflows/exchanges'?

i understand payment to be a transfer of rights to the resources being used as payment, as opposed to the delivery of the resources being used as payment, but i do think your perspective on payment as a change in location of resources is interesting and keen to see it developed further.

elf-pavlik commented 8 years ago

@ahdinosaur AFAIK in VF we don NOT have explicit payment, we use reciprocal transfers. What current e-commerce systems call payment method relates a lot to how to deliver monetary currency.

Since ISO4217 monetary currencies as of today don't integrate nicely with The Web, so also not with valuflows, we have a mismatch and need for bridge to that legacy technology.

To my understanding ISO4217 don't have a way to specify explicit ownership rights (which we use in vf:Transfer). If you give me some cash to deliver to another agent which has vf ownership rights to that cash, I can go to any shop and buy beer with it, people will assume that I own it since I have it in my hand. Also if we don't share access to one bank account 'storing' ISO4217 currency, when I transfer you rights to some of the currency stored on one of the bank accounts i have access to. We still need some delivery mechanism to change the digital location to one of accounts you have access to.

IMO it does make sense if we want to align modelling of monetary currencies with other resources. I can vf:Transfer you rights to apples in my cellar, but you still need to somehow get them to your kitchen.

Only aspect of delivery which I see possibly relevant to valueflows/exchange - vf:Exchange can include agreement on the delivery method, and if it involves service of 3rd party than who needs to get vf:Claim #22 for that delivery. That would also in some way match one of the aspects of people commonly call a 'payment method'.

bhaugen commented 8 years ago

I think this is a non-problem that needs another event behavior specialization.

This is all money-of-account. A transaction takes place that deletes some numbers from one account and adds some numbers to another account, maybe subtracting a transaction fee.

The recipient already has rights to their account. I think transfers of rights only apply to certain types of resources. Will send my questions to the REA gang about this stuff some time today, the questions are getting formulated well enuf in my own mind to ask then somewhat coherently. If you have suggestions for how to formulate them, or want to be cc'ed on an email thread, please let me know.

elf-pavlik commented 8 years ago

This is all money-of-account. A transaction takes place that deletes some numbers from one account and adds some numbers to another account, maybe subtracting a transaction fee. The recipient already has rights to their account.

If you want to base vf:Transfer on accounts (or stocks in general), not directly on agents. We may need to define vf:Stock and ownership over it first.

In case where we go directly from: (agent) to: (agent), both agents can digitally sign the vf:Transfer and it acts as prove of ownership. In most cases we want to verify that from: (agent) actually has the ownership over resource which it transfers. If we transfer from: (stock) to: (stock), we need to verify if give agent has rights to transfer resources in that stock.

In above, can we also transfer ownership over whole stocks or accounts? (do stocks stay in stocks and accounts on accounts). Or we always transfer the resource and stocks can NOT change ownership. So agent and stock have one-to-one relationship which gets created together with creation of the stock. To change ownership we need to transfer resources from it to another stock. Also very unlikely agents can share ownership over stock, it may require defining distinct agent (union of all agents involved) who will own the stock/account.

What about cash? Stocks and accounts don't seem to apply to it.

What about services? Stocks and accounts also don't seem to apply to them clearly.

I think we need to continue writing concrete data examples based on use cases we work with to showcase clearly different approaches to modelling vf:Transfer and vf:Exchange.

Sometimes money also goes through proxy accounts, as with money delivery/shipping systems like https://transferwise.com/ When such shipping/delivery fails, we may need to rollback the vf:Transfer or retry delivery.

bhaugen commented 8 years ago

What we have done so far in NRP is name the economic event behavior differently when the behavior is in fact different: thus, so far,

I'm not saying VF needs to do it exactly like that, but renaming combined with some explanation makes it more clear to users what is happening.

So "wire transfers" of money might need some different well-defined named behavior.

elf-pavlik commented 8 years ago

give: in VF would give rights, receive: in VF would receive rights, where transfer is a container for give and receive.

Once again, since we transfer rights to a resource and not relocate the actual resource, I don't understand need for splitting it into two different events. Maybe

vf:Transportation might need Depart and Arrive event, but in case of transport we do describe what happens with the actual digital/analogue resource, not just conceptual rights to it.

I think we get used to in various scenarios that moving a resource implies change of rights to it eg. pass some cash from hand to hand. But as I exemplified, if I only help with delivering that cash to person who has ownership rights to it, even that I have those bills in my hand I don't own them and I shouldn't go buy some beer using them. I think we often assume that person who carries cash owns it or that person who has 'legal' ownership over a bank account, owns all the digital coins deposited on it.

bhaugen commented 8 years ago

See also https://github.com/valueflows/valueflows/blob/master/use-cases/digital_currency.md

fosterlynn commented 8 years ago

Once again, since we transfer rights to a resource and not relocate the actual resource, I don't understand need for splitting it into two different events.

A couple reasons:

  1. It is more consistent with process related events, which increment/decrement one resource, and I think involve one agent. I think it would be good to have as consistent model for events across the vocabulary as possible. (That's why I'm trying to nail Process first, it's much more concrete.)
  2. You need 2 edges for creating graphs where you have value flows. R > inflow > P > outflow > R > inflow > T > outflow > R > inflow > .....
bhaugen commented 8 years ago

Also, if you looked at that faircoin use case, the give event is significantly different from the receive event: the quantity is different (the network fee comes off the top), and the resource is different (one faircoin address vs another faircoin address).

This (the resource being different) will always be the case for stock resources, which are pretty much the same as @elf-pavlik 's indirectly identified resources: e.g. the faircoin quantity in the origin wallet.address, vs those in the destination wallet.address.

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

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