Economy App Document - Eager to contribute

[akurnya]

I am new to edgeryders, My name is Akul and I came web hopping via a facebook group on charles eisensteins proposals.

This project as I would put it, clicks with what I had in my mind. I’ve checked on the Multi swap site earlier this year and was hoping to find a group that could pull off an exchange engine to implement it.

I would like to point out and ask a few things based on the https://edgeryders.eu/system/files/EconomyApp-DetailedDescription.pdf pdf doc:

• The businesses on a large scale don't always follow an instant barter or product transportation. The essence of keeping some form of bill in exchange of service "monetized" and controlled by few eventually led to a debt based economy in a way. But the idea of keeping a digital transaction or a reciept of services in a local economy run off by a local currency has two advantages:
  • The two agencies/party are reachable - The Trust factor prevails
  • The problem of local currency can be sold by Interfacing local currency with fiat money
• The transaction can happen digitally as offered in a closed loop circuit, as outlined in the document but in real life, people/organizations usually don't "trade stuff" instantly as far as raw/natural resources is concerned. As in the case of overseas transportation. The flypside of local collaborative consumption are many. And we shouldn't ignore the benefits a globalized economy offers, the medical,products based,tertiary and secondary market lifestyle and health benefits that people get are mostly due to a global network of trade. I understand this probability of forming closed loops greatly increases when a larger set of elements is gamed together - in our case the whole businesses in the current economy

My Proposal is - An effective prototype of “Trust Calculator” based P2P barter between 2 users exchanging in any desired currency  local/nonlocal and their ability to send and accept it in any of their desired currency by interfacing alternatve currencies with fiat money.

21The tolerance can be provided by (1) users configuring an “acceptable loss” percentage for their barter deals, (2)

users pre-charging an account once with a moderate amount of legal tender (<100 EUR), which the algorithm then

uses as a buffer for generating barter deals, keeping the money on the account fluctuating around its original

amount, (3) a combination of the previous.

As I understand it (but I would like to understand it with a demo if someone can clarify “Tolerance for dummies”) Tolerance Point 2 - Users pre charging with a nominal amt of legal tender - Which means there is an option to fill in my proposal- If local currencies can be interfaced with this nominal amt in the same unified account of that user, he is free to to exchange services as a bill/voucher.

This is particularly for B2B Network exchanges and alternative trading exchanges where organizations lend their services or products and esp is there is a shipment ordered, you know, say in the case of amazon.com, that you have paid for a “Big Costly Something” and it is supposed to reach you by this date XXYY. Similary, if exisiting B2B trade could be implemented using the system being offered by economy app, while still keeping the currency, localized currencies would just act as receipts and vanquish once the order is dealt with/received.

Extension of the proposal:

I am working on a network prototype that monitors the trading histories and builds trust between trading elements and gives each element/user/organization to monitor/track “trading strength” with all the other users - Which is a personal call for each organization/party/user to make; so if we provide a way to show this insight, the User lets say using a mobile app is better able to “Pay/Trust” ( Currency as a form of Trust?) the Seller/Buyer; the more they exchange the dense this bond grows and it actually enchaces local trade - a local body /network is a local union and transparent market exchange, digitally transacted and shown in that local marketplace helps everyone keep in check all the transactions happening between parties (FIgures and Things traded still abstracted ofcourse); But just like a Right to Information - for any corrupt practice during any transaction detected, the users/parties exchanging could be requested to show their record; THis is a proposed platform model Economy App could extend its features with.

Thus this kind of automated trust building could enchance business dealings more while keeping local currencies in the flow and inflation proof(since they are local and not being imposed upon some far off economy with any interests rates). THe second feature is insights into trust building.

The closed loop network offered can scale globally keeping these vouchers as proof of transactions actually while actual items might take time to be transported (esp in big business dealings); The idea is when a “Scale of Trust” is formed within a closed circle, as also suggested in CMB/Economy App, the Actual Figure of Dealings with all the concerned parties could be better decided by the offerings/buying parties. Otherwise the problem as I find it is not just solving the matter of network bartering to Close the loop and suffice everybody’s wants but to actually make sure the other person actually gets/offers what they have promised to - Unless you want it to remian in a closed room, very limited known market with people already knowing each other, bigger models usually require interactions where people don’t know each other and the Need to Buy something is an “Immediate One”; people wouldn’t wait to find out when the network loop closes; Until the Loop closes you keep a voucher with you - Some Method could be devised how the value of that voucher devaluates - you get what you want, the seller still sells his product /service on time - the moment a loop closes and everybody’s exchange is balanced out - the Bill/Voucher/Local Currency devaluates logarithmically;

This is a very interesting path im willing to work on. And I am going over the code provided in the repo as well (although im not a Ruby person prefer c++/python and would love to contribute)

[matthias]

Welcome to Edgeryders

Hey Akul, Matt here from Economy App. Thanks a lot for your input … great ideas among it, and I’m sure we can collaborate on something! Note that going through the Economy App network barter code that we released so far is not a worthy investment at the moment: that code is our first (working, but really slow) prototype. We later implemented a much more mature version. Now my teammate Daniel is finishing the interface and implementation of that implementation, and we will release that code open source again when we’re done with it (ask me in at most four weeks if I forgot).

Some initial feedback for the ideas you have:

• Trust building mechanisms. As I understand it, you propose an advanced and efficient system for gauging and building up of trust for trading. That sounds promising, since we definitely need a trust-building mechanism in Economy App (and so far only use a "one to five star" scoring of sales, similar to how they do on ebay.com). The simple star-based mechanism of course has the advantage of being ... well, simple ... saving the users from needing to learn any new concept (which would hinder voluntary adoption of the software). But explaining a feature is of course also something about a good user interface. So if you have ideas / sketches for the user perspective of the automated trust building feature, I'd be really interested :)
• Vouchers. Your idea would indeed solve the issue of wanting a security until the shipment arrives, and also the additional problem of how to handle product returns. (Because for B2C sales over the Internet, the option of returning a product for any reason is mandatory in most European countries. Which is a big issue, as we don't want to, and can't, reverse a whole loop / network barter deal with maybe 60-100 people on average just because one person wants to return their stuff.) However, adding currency again into the equation (or trust-based P2P debt) also creates new problems. Some of which I found out about when doing the interview "Mental and cultural aspects of struggling with the crisis in Spain" on my blog. Means, debt between people knowing each other can be a cultural no-go, and local currencies can be an issue for voluntary adoption of a new software again. Anyway, I'd like to hear your opinion if and how one could route around these issues using your idea of vouchers.
• Voucher, again. Just remebered that we also thought about vouchers lately, resulting in a proposal for a feature in a later version. I am just going to copy&paste the feature proposal here, hope it's understanable with so little context, and maybe it inspires some more ideas in you (let me know!):

  Vouchers, to redeem in brick-and-mortar shops. The brick-and-mortar shop would offer vouchers for sale on the online barter platform, and customers can purchase them as usual, either completely in barter or partially in money (and even the latter is attractive compared to buying in the shop for all in money).

  The special thing about these vouchers is that they are treated as fluid (non-atomic) products, and thus can be used by the deal finder as “filler” material, leading to more deals being found. This also means, however, that there indeed has to be a special feature for this: the individual transactions should not be a voucher each as they are possibly just cent amuounts, but the user should be able to obtain vouchers from this “accounting” system in desired amounts, to spend when shopping. These vouchers would use QR codes or similar technology to be redeemable automatically at POS terminals in the shop. They could also be cryptographically signed by the issuing shop (using an API call to the shop’s website, which also would track balances of the shop’s barter customers and would confirm with the signature that the customer is eligible to this voucher).

  The vouchers would be spent by showing a printed version at a POS terminal, or by generating a voucher exactly for the payable amount right on spot, then showing it on the smartphone’s screen to be scanned at the POS terminal.

  In effect, these vouchers enable buy-now purchases in brick-and-mortar shops. And that in a better way than when using the “buy-now, partially in money” on a smartphone right in the shop: because there, one never knows before what kidn of offer one will get, and a good offer (like: 90% in barter) that was available right before going to the shop can be gone when getting to the cashier. This unpredictability regarding how much money one will have to spend, combined with the need to spend at least some money in every purchase, makes this alternative impractical.

On another note, have you looked into Ripple currency transaction system? Tech-wise, I find it very inspiring (and the only reason we decided for bartering instead was to work around the cultural implications of debt.) Ripple has a P2P trust system, expressed in credit lines with credit limits that you extend to your “friends” according to how much you trust them to pay you back. Using that system, any currency and other unit of value, including local currencies, can be routed across it. Before the current Ripple.com system got started, there was an open source project by the same name, with a very similar concept, now known as Ripple Classic. If you want to experiment with Ripple.com, let me know and I’ll send you 30 XRP for free.

[akurnya]

On the case of Vouchers

Hi Matt, its a privilege writing to you!

Vouchers. -  Imagine if having more of Money was a burden rather than a luxury? If Instead of currency, I offer it(rebrand it) as a token of transaction - which means the follwing User Story:

Matt bought from Akul X quantities of greetings cards made of recycled paper. Matt has just obtained a token which matches with the token Akul has. The token has an expiry limit: When the token devaluates (Again inflates just like monetary system) the Deal breaks. If the actual product/service is received and the Deal finishes off before the Voucher is anulled, thats an actual Barter in B2C as well. Got the catch?

Now, Matt and Akul are part of a local collaborative platform that does online exchange - digital transactions (You may use your phone for that, Samsung gears or a card -its basically a SaaS running over it)

which follows a network bartering mechanism. The Network of Trust based Bartering mechanism rather.

1. Compute all possible closed loops
2. offer the user which loops to choose
   1. How to devise the rule of choosing networked loops - Compute over all Need based loops and calculate their earlier Social Reputation - A Social Reputation based network is nothing new. Ask the researchers at Multi Swap to work on and refer to Sporas Zacharia algorithm: Refer to Amazon,ebay or any feedback based rating system. My proposal here is based on past histories of trade the 1 to 5 star rating has its flaws - but automated feedback mechanism helps you find the Best Paths out of the closed loops and gives you then the option to continue the flow of trade. 
   2. Once users choose their preferred networked paths, the Social Reputation is Proportional to the level of trust: The levle of trust decides the Amt. of Time it will take to Set a Deal Period. Two things
      1. If I am in Mexico and you are in Italy - And if shipment will take 10 days while the Deal Period is only 5 days? So Amt of Time and distance as well. I am not sure. I am just brainstorming
      2. The good thing is Business Transactions can be Prioritized because now they know which Deals are FIrst based on the Mutual Level of Social Reputation. SOcial Reputation is computed dynamically and is relative to Peers.
   3. Make the Deal and your Voucher = Bill of Transaction starts its countdown. There is no debt here. It is not money. It is just a token.
3. I checked out this gentleman with username - elf or some scandinavian nickname I suppose is contributing to this online marketplace site - sharetribe.com; that could be a good starting point to integrate economy app as the basic engine to run off
4. While Economy App could use in return, the Reputation calculator mechanism that I offer. You don't need anything more. Just a database I could design and all yoru queries could be called via a json-rpc or i prefer REST bases queries and it will compute over all supplied input users, what is the possible reputation relative to each other.

This way your transaction is digitally PAID & Stored in the Payment Gateway while the Token starts the counter backwards. If Deal is made, the PAID status sets to True. and thats paid. thats about it. no money exchanged actually but its just a Monitor. What that means is unlike current payment exchange like paypal, there is nothing being transffered in a bank account rather when the PAID = True, the token expires if its before the actual token deadline. Its actually a system to monitor Input and output bound resources across a closed community so you could see its also a resource exchange logger/monitor keeping track of the bartering parties across all existing communities.

PS: Dont use QR. nobody is venturing into it. Google has rolled out card based transactions. QR is passe and cumbersome.

Wearable tech running off this online service is more like it. less of a screen based touch click n scroll. more of real life credit card like transaction. Think of extending the app to smartphones that pay by using something like the following:

I see the network barter graph is using a Currency Value as the edges between peers. good stuff. this Project is like a dream manifested and i wouldnt waste time writing literatures about it.rather would be interested in talking to you. You can add me on skype: akulfund

I would be happy to understand the core logic if you could explain the math behind it. this way I could add to it and offer the abckend social rep solution to it.

social reputation and voucher are inherently the same thing here. no monetary currency involved or needed.

[matthias]

Some more notes:

• "offer the user which loops to choose": I know that some barter platforms like Netcycler allow this, or other forms of negotiation, before a loop is closed. In our analysis, this manual coordination effort (and the ensueing frustration when no deal results from it) is a reason why such platforms do not work well. So we designed ours to close loops completely automatically, informed by the previously obtained information about wishes and offers.
• Network of trust based bartering: I like your idea to calculate loops (in our terminology: network barter deals) so that not just the flow of value, but also the flow of trust is maximized. So a user would always buy from the seller with the best reputation that can be made to fit into the deal. However, these two optimization goals contradict one another. And from our experiments with the network barter algorithm, it seems utopian (for now) to even think about trust-optimized deals: we can be happy that we get deals at all, hopefully in sufficient amount. Because different from a case wher ecurrency is involved, such deals can only match offers and demand that exist simultaneously. So we just ask users to order products from all sellers they trust enough with the delivery of the concerned product or service. Anyway, thanks for the idea: I did not think of this before, and it may lead to other ideas in the future ...
• Reputation calculator mechanism: While we can't integrate trust maximization into actual deal finding (too many constraints ...), calculating reputation from a user's perspective is a good idea nonetheless. I would tie it to product reviews however, not to users: like on Amazon, we will have reviews of individual products and services. However, not all reviews can be trusted the same, and here your idea of scoring this by the reputation of the reviewer could come in. A quick outline of how this feature could look like in my view:Not all reviews are the same: their score given to a product or service should be treated differently when it comes from a trustable user rather than a non-trustable user, from a personal friend or from an unknown user, from a picky user doing mostly negative reviews or from a user tolerating more or less everything, and so on. These differences, as seen by the user looking at the reviews, can be taken into account automatically, creating an agreegate review score from all the reviews weighted by their importance to the viewing user. This would be very different from creating an arithmetic average.
• "I would be happy to understand the core logic if you could explain the math behind it.": The problem is a circulation problem in the variant with one commodity ("value"). The upper and lower bounds of the value flow correspond to the (private) reserve prices and (public) offer prices, so to the price range in which somebody is happy to sell an offered product or service. Having this as a range rather than just one price tag is important, since else the problem becomes an IP (integer programming) problem rathern than an MILP (mixed integer linear programming) problem. And IP problems need much more computing power to solve it for networks of comparable size. Ok, given such a problem and a specific graph of users, offers and orders, the solver algorithm tries to solve it for maximum flow, corresponding to maximum turnover in a network barter deal. Because there may be many possible "loops" (deals) that can be found, but for markets to clear as much as possible, we want the highest turnover. (Ok, not just that. We later also score proposed delas by other parameters like "time since last deal" to prevent user frustration and steer the barter economy. It feels like being the Plannig Office of the former Soviet economy :D )

I don’t understand the proposal about newguinea-gov.com though: that site looks like from a self-declared micronation.

Also I don’t get (yet) the complete idea of these tokens you are talking about. I understand that they should somehow safeguard against non-delivery. But if I get the delivery and simply say I did not get it, just to keep the token and be able to redeem it for its value in addition to having the product delivery? Also, as the dealmaking would already be optimized based on trust relationships, having the tokens is just making matters more complex, no? The simple solution would be to just say: in circular barter and network barter, every member of a deal has to provide a sold item immediately, independent from receiving the item for them or not before, and the reviews will evaluate compliance with this requirement (and be added to the reputation profile, affecting future chances for business in turn). Also, tokens are currency if they are resellable, and tokens are P2P credit if they are not. In Economy App, we avoid both (as much as possible). That’s also why Cyclos, or any other account-keeping software, was not a useable basis for ours.

Yet I like the feel of the MoneyDrop feature and can imagine something similar that can be combined with network bartering (using voucher codes). You mentioned that you work on something similar. Is there a web demo of it?

offer the user which loops to choose

[akurnya]

Hi Mathias,

It would be better if we talk over it on a net conference. you can add my skype id: akulfund (I had already dropped it earlier)

These matters are better clarifyied when discussed. As of our remote situation, we can coordinate on how you want to steer this application service and other matters revolving around it plus I can answer you much better while talking rather than writing. We waste less time and get more output.

Let me know. You can add me there and leave me a msg with a time and I’ll get back to you. You can leave me your cellphone contact as well and I will call you back.

Thanks in advance!

[akurnya]

More on Voucher implementation for digital transaction

Iteration 1

Register with us to become a cyber citizen: Open a Universal Trading/Benign Banking Account

Ref:

http://newguinea-gov.com/register.php?PHPSESSID=bdf1aed58d27c0eb26857ad972891cc0

Implementation : Above idea As a Mobile Economy App Integration to create a universal bank account. This is barter bank not money bank and its just a name.use bench if you like since thats where bank comes from, the word.

Advantage? : No spending and investing money and time on creating full fledged site. Test the user capture rate faster, on the idea.

Iteration 2: Integrating with above app : This Prototype feature only

Follow this story : simples moneydrop + bluehood social bluetooth = An app that exchanges money via non-internet digital communication (w/,w/o BLE)

Easy Digital Currency Transfer. please note as i mentioned earlier in our case, its HANDSHAKE of TOKENS Only! Coding the Token may include featuers like: encryption of users’ credentials + type of transaction-product/service + time of delivery,distance,mode of transportation all encrypted to make a unique token ID.

Ref:

moneydrop: http://techcrunch.com/2013/10/09/simples-moneydrop-will-soon-let-users-transfer-funds-using-bluetooth/

bluehood: https://play.google.com/store/apps/details?id=com.mobile.bluehood&hl=en

Implementation: 2 Core features of the Android App:

 

 

1. Lets you search nearby app users
2. Select anyone Peer for transaction
3. Select transactions from this list:
   1. Me and my colleague can demonstrate 4 basic market Deals:

      1. Negotiate/Deal Done

      2. Handshake

      3. Buy/Sell

      4. Give gift/

   2. Select any one action. Perform Fake Transaction. This is just a Game Demo of actual implementation.a one web page demo which could then be integrated in the economy app.

Thus, we are able to show basic functionality as well as bring application to every smartphone across the globe.

 

 

Point 3 In Actual Prototype Implementation : A ready to deploy Cyclos Trade Exchange module on the server. Understanding the conversion rates between Local community currency to $ USD/ Euros & interfacing with other Int’l  currencies (Ecommerce built in Cyclos) and then perform any of the Market/Transaction related actions.

More on cyclos: http://www.cyclos.org/

Iteration 3

Internet Data GPRS/Wifi synchronizes your transactions from mobile app to the cloud bank.

User Implementation Steps :

Easy 3 : Select. Barter Deal between the two; Confirm & Press Exchange.