Loomio
Thu 5 Feb 2015 5:35PM

Design - What it does

H Harper Public Seen by 121

We've talked about this a bit in the rippleusers group.
Adam kicked off the design discussion with the first post. Adam's design has the following key features that distinguish it from Ripplepay:
1. IOUs can be accepted ("bought") and redeemed ("sold") at less than face value, depending on how valuable they are to the holder.
2. converting between currencies (e.g. for through transactions) occurs at a price specified by the converter.
3. trust connections do not necessarily have to be reciprocated or even approved.
4. interest rates (and potentially other terms) are specified per IOU "type" instead of per trust connection.

Zecrets/Ben likes Adam's ideas.

Alessio proposed a simpler design, without interest and with all IOUs being treated at face value.
Adam's proposed design supports Alessio's proposed design, but not vice versa. Alessio shares Adam's vision, mostly, but has a different focus.

Giovanni proposed an alternative (as opposed to e.g. traditional compound interest payments) way of implementing interest.

Of possible usefulness for reference:
Adam's design notes which contain almost no explanation.

Is that a fair summary of context? did I miss anything important?

AS

Alessio Stalla Fri 6 Feb 2015 9:40AM

I think it's fair and quite complete, thanks!

H

Harper Sat 7 Feb 2015 2:40PM

I realised recently that my WorkFlowy design notes were written for the early stages of an employer/employee relationship, in which there was no need to discuss the reasoning behind each design choice (I just needed to say "make it like this").

Now that this is a community project I'm thinking that a thorough explanation for every major design decision I made, might be helpful. I mean, since I've already explored the consequences of various design options, I could write it up and save everyone else the trouble (or at least provide a starting point for further discussion).

It might take a while.

Thoughts?

AS

Alessio Stalla Thu 12 Feb 2015 8:25AM

I agree - the more explanation, the better. Skimming your design notes, I think I would like to simplify some things (in terms of a simplified UI, which can exist alongside a more complex/complete one). But before proposing anything, I'd like to read your explanations.

I also think we (I?) should write a use-case document that summarises what can be done on the system and who can do it. More or less, each use-case should translate to a separate web page, form, or screen.

When we have such a document, it'll be easier to reason about what to do, how and when, and to assess progress.

Do you think I should write a proposal for that?

MGG

Mario G. Gurgel Sat 21 Feb 2015 12:25PM

I'm thinking that we should write a prototype that does one thing well and expand from there. Of course, to do anything well the prototype must have an internal consistent model of nodes, trust relationships, debt relationships, debt cancelling and interest over debts.

I propose that the first thing that the prototype should do, then, is to serve Adam most immediate purposes, that are, as I understand it: debt management. Adam wants to know, and modify, who owes who and how much, and add/remove debt from the system whenever someone pays each other with real money (or buy things from the market for each other), and have the debts increase themselves with compound interest whenever they are active.

MGG

Mario G. Gurgel Sun 22 Feb 2015 4:59AM

Just one quick question, because I've never actually used Ripplepay: from the design goals of this project, what is missing from Ripplepay?

H

Harper Sun 22 Feb 2015 3:01PM

A non-exhaustive list (off the top of my head) of essential (i.e. cannot be easily worked around) things Ripplepay doesn't let you do:
1. set a buy price other than 1 for counterparty IOUs.
2. set a sell price other than 1 for counterparty IOUs.
3. set lower limits on balances.
4. set prices for converting between currencies, choose which currencies to convert and in which directions
5. discard IOUs.
6. revoke IOUs.

I think that might actually be an exhaustive list. Everything else is a either an efficiency/simplicity tweak, or a logical consequence of these requirements. E.g. lowest cost pathfinding (which Ripplepay doesn't do) is necessary because of 1. and 2.

That was a really helpful question; thanks Giovanni.

MGG

Mario G. Gurgel Wed 25 Feb 2015 8:56PM

I've just tested Ripplepay for the first time, with fake accounts (I know I tried do it before, but don't know why I didn't complete the test). So, here are my thoughts:

  1. Adam said that Ripplepay doesn't allow selling IOUs for less than 1, but I don't see any market for IOUs at all (I thought there was a market for IOUs at 1). Is there one?
  2. There is also no concept of an IOU, everything is mixed in a "balances" account (I mean, the IOUs are of course there, but they're not exposed to the user as IOUs).
  3. The whole "payment" thing is a bit odd to me. I know the main goal of the classic ripple system is to enable people to pay others (really pay, like money in exchange for goods) using only p2p credit, but in the scale Adam is using, it is not about paying, it is more about managing a network of debt.

That said, I think we should focus more on debt. I don't know if that is the best word, but I am convinced that it is not "payment". We should focus on debt management, encouraging small loans between friends, making your money yield some interest without handling it to banks etc. There's a slogan somewhere on Ripplepay: "be your own bank", this should be our slogan (can we, @ryanfugger?)

I am working on a prototype here that treats IOUs as first-class citizens. In the way I am modelling the data, each user should have a dashboard with not various balances, but with various independent IOUs, issued at different dates and each one capable of yielding interest at different rates. (I don't know if this is scalable, but I like it and if it is not scalable we can think about it later).

With my approach, it is easy, for example, to

a. Implement IOU markets, of any way you like.
b. Manage, mix and merge different IOUs with different interest rates (for example, you can lend a small quantity of money to a friend for 0 interest, but then later when he asks you for a bigger amount, you decide that you will lend only at a bigger interest rate).
c. Change credit limits granted to other users.
d. Visualize paths, tell the user to whom he is linked and how much he can pay (ok, not pay, but create a chain of IOUs) to each person at each time, let him choose paths based on the total interest rate of the path, pay through different paths.
e. Discard IOUs.
f. Revoke IOUs.

Nothing said here is impossible to do in Ripplepay, I believe (in fact some of these are actually done there), but anyway they easy to do in my prototype.

However, I am still struggling to find the proper way of doing currency conversion and proper IOU cancellation and I would like some light on these topics.

MGG

Mario G. Gurgel Wed 25 Feb 2015 9:11PM

Ok, let me clarify. Imagine we have the following IOU:

{
      "bearer": "ana", 
      "issued_at": "2014-05-02T00:00:00", 
      "issuer": "geraldo", 
      "rate": 10.0, 
      "value": 300
}

Then "geraldo" enters a payment of 200 to "ana" (or to someone else, but with the payment path passing through "ana"). What should happen?

This IOU should stay? Probably not. But should it be deleted and replaced with a newer IOU, with value of 100 (300 - 200)? We should create the two IOUs, one from "ana" to "geraldo" and one from "geraldo" to "ana", then later merge them and generate a new one?

What if we have the following (like explained in the comment above):

{
      "bearer": "ana", 
      "issued_at": "2014-05-02T00:00:00", 
      "issuer": "geraldo", 
      "rate": 10.0, 
      "value": 300
}
{
      "bearer": "ana", 
      "issued_at": "2014-05-03T00:00:00", 
      "issuer": "geraldo", 
      "rate": 0, 
      "value": 5
}

Then, when "geraldo" enters a payment of 20 to "ana", from which IOU we should subtract these 20 (note that the two IOUs have different interest rates)?

H

Harper Thu 26 Feb 2015 11:58AM

@fiatjaf (Giovanni) I was thinking of Ripplepay in terms of my vision of wuush (hereafter just "wuush"). So, if you built Ripplepay on top of wuush (which is entirely possible by the way) those are the essential functions of wuush that you wouldn't have access to.

I don’t see any market for IOUs at all (I thought there was a market for IOUs at 1). Is there one?

Ripplepay doesn't have a separate trading tab, and neither does wuush. That kind of trading (one currency for one currency) is a micromanagement system created long before the age of computers i.e. for situations where each trade must be decided upon by a human. Now that we have (fast) computers we can do much, much better. We can tell the computer how much everything is worth to us and what we want, and let the computer trade for us.

So, in wuush, the market itself is invisible. All you do is say how much of a particular IOU you want, how much you want to buy and sell it for.

In Ripplepay it's the same, you say how much of an IOU you want (by extending credit to the issuer of those IOUs) but unlike wuush you don't specify a buy and sell price. But it is as if the price for buying and selling is always 1. You also can't set lower limits. You can't say "actually I want to keep some of these IOUs, thanks", so you can't stop IOUs you hold from being spent in a payment or a throughpayment.

Also, because all counterparty IOUs are face value, the wuush system that we've hypothetically built Ripplepay on doesn't actually trade anything because it's all worth the same to you. It just waits for payments to utilize its debts and extended credit.

There is also no concept of an IOU, everything is mixed in a “balances” account (I mean, the IOUs are of course there, but they’re not exposed to the user as IOUs).

Yup. This comes under "efficiency/simplicity tweaks". Although one of the problems here is that by combining, what in wuush would be two unrelated trustlines, into one "balance", Ripplepay forces both trust lines have e.g. the same interest rate. In wuush, there is no such thing as a negative balance. IOUs held and IOUs issued are displayed separately.

The whole “payment” thing is a bit odd to me. I know the main goal of the classic ripple system is to enable people to pay others (really pay, like money in exchange for goods) using only p2p credit, but in the scale Adam is using, it is not about paying, it is more about managing a network of debt.

Sort of. It's both really. The goal is high liquidity for payments. The powerful debt/credit management controls make that high liquidty possible. instant payments and debts go hand in hand; you can't have one without the other. We could call payments "transfers" if that makes you feel better. That could be nice. You transfer value through the network. That's one type of transaction. The other is a trade, which is really a transfer through the network with both origin and destination being yourself. I'm rambling now.

We should focus on debt management, encouraging small loans between friends, making your money yield some interest without handling it to banks etc.

I think wuush has many selling points and will appeal to different people for completely different reasons. One user might want a cheap loan to start a business, another might want to get better interest than they would from a bank, yet another might want to trade currencies, another might want to recieve global payments in their online shop in their own currency. There's no need to limit our focus to debt management.

That said, I think you are correct that the first ability wuush must have is to handle debt. Without that, payments are impossible. The first step taken by the first user would be to set up issuance of their own IOUs. The second step, taken by the second user would be to extend trust to the first user. Only then are payments possible.

Imagine we have the following IOU:

{
"bearer": "ana", 
"issued_at": "2014-05-02T00:00:00", 
"issuer": "geraldo", 
"rate": 10.0, 
"value": 300
}

Your vision of wuush is different to mine. And since I don't understand it, I can't tell you what should happen. I don't know what "rate" is.

Also, this discussion is getting very "implementation". Do we need to make a new topic? or is this something for "development, programming languages, databases"? perhaps a "code" discussion? I don't know.

Edit: I've made a new discussion with the title of "Back end design - how it does it".

AS

Alessio Stalla Thu 26 Feb 2015 12:39PM

Ok, so I'll continue there.

H

Harper Mon 9 Mar 2015 11:32AM

@alessiostalla

before proposing anything, I’d like to read your explanations.

I'm looking at this now. Writing a full explanation for all of it is just not on the cards right now (and may not be for years). But if you have specific questions, that would narrow the field considerably. My trouble is, I don't know which things are obvious and which things are not, because to me they are all obvious.

I also think we (I?) should write a use-case document that summarises what can be done on the system and who can do it. More or less, each use-case should translate to a separate web page, form, or screen.

When we have such a document, it’ll be easier to reason about what to do, how and when, and to assess progress.

Do you think I should write a proposal for that?

I don't know what such a thing would look like. It sounds like it would be useful and it sounds like the "next step" or something (I'm not a software developer, I don't know how these things go). Either make a proposal, or if it's easy then just do it and show us.