Promise table
Type of entry (Initiating promise, promise, notification)
Id (GUID for that promise or a GUID corresponding to the person)
Description (describes what was promised)
TimeStamp
So.. it would work like this:
[transaction]
[promise]
1 banana
[endpromise]
[promise]
1 orange
[endpromise]
[endtransaction]
One entry for the Initiating Promise: my Id, his Id, "1 banana", 12/21/2003 12:15:34
One entry for the Promise: his Id, my Id, "1 orange", 12/21/2003 12:15:45
One entry for the Delivery: his Id, my Id, "1 orange", 12/21/2003 12:15:48
One entry for the final Delivery: my Id, his Id, "1 banana", 12/22/2003 8:23:32
That's it.
Now. That shows you made good on your promise. That's your rep. Now you can go anywhere in the world with the Promise App that shows your history of promises.
It's free. No transaction fees. Works with any currency on earth.
Hi Andrew, robdashu from econpoint here.
ReplyDeleteThe concept is very reasonable. The implementation is complex.
The approach is very information intensive, requiring rules and procedures for keeping track of all of these promises. How does info on delivery promises get gathered and maintained? It makes buying a pack of gum at the convenience store a complex process. Each party must be sure of the other integrity before committing to the transaction. Accounting as to the health of a firm becomes impossible without checking the reliability of all participants.
Not to be a curmudgeon, but perhaps there is the seed of something there if you address some conceivable mechanics in a closer level of detail. It seems administratively an order of magnitude more complex than using currency.
I agree that in practice, it appears overly verbose. It is intended as an electronic protocol. I posted some more info above.
ReplyDeleteTo the purchaser at the grocery store, they would not even know. If they use currency there will be no record of the transaction. If they use their debit or credit card, the transaction will be remembered.
Delete