Re: WIP: Interledger Architecture

@Nicholas: Thanks and that's a good suggestion. An invalid payee account
would actually be detected at the Discovery or Query stages. But a setup
call could fail for instance because of receiving limits. (Some wallets
might limit the amount an unverified account can receive per day for
instance.) I'll make sure to add some examples for both of those cases.

@Jehan:

Great observation. Currently we use what in the Internet Protocol (IP)
would be called "source routing". IP actually also supports source routing,
meaning the sender specifies the route ahead of time. However, it is rarely
used and mostly comes into play for debugging and exploits.

While reading about the history of IP routing [1], I noticed that the
Internet Protocol makes a very deliberate choice to put the burden of
routing on the connector, not the sender.

If you asked me right now, I would say that we should enable source routing
as an option, so that a sender who wants to do their own pathfinding can do
so. However, it's a really nice feature to be able to have a
five-bells-sender which does not require the relatively complex
five-bells-pathfind and instead can rely on connectors to do the routing.

I think there will be a lot more senders than connectors and senders should
be able to be simple and stable. Think of a IoT smart device trying to make
payments, you probably don't want that to have a payment stack that needs
to be upgraded every time somebody makes an improvement to the routing
algorithm.

It's very interesting to read about IP and its history. [2]

I'm planning to write up our current thinking around routing soon, but for
now I'll say that there is a lot we like about the Internet's approach to
routing (which many networking experts may disagree with, but defending my
view would take more time than I have right now), except that we don't want
any central authority like IANA.

When you get down to it, IANA's function is essentially 1) to have small
identifiers without collisions and 2) to control the growth of routing
tables. Regarding 1), slightly larger identifiers are totally fine for our
use case. Bandwidth has increased dramatically since IP was created.
Regarding 2), we can use micropayments to prevent routing table spam.
(Which is actually also a great example of an ILP use case.)

[1]
http://www.routerfreak.com/ggp-egp-and-25-years-of-bgp-a-brief-history-of-internet-routing/
[2] http://spectrum.ieee.org/computing/networks/osi-the-internet-that-wasnt

On Mon, Mar 21, 2016 at 2:51 PM, Jehan Tremback <jehan.tremback@gmail.com>
wrote:

> I noticed "Routing complexity should be in the connectors". Does this mean
> that you will be moving away from the proposal phase as a necessary part of
> ILP?
>
> On Mon, Mar 21, 2016 at 1:09 PM, Nicholas Addison <
> nick@addisonbrown.com.au> wrote:
>
>> That’s a pretty fleshy strawman you have there, Stefan. Well done.
>>
>> I assume there can be a failure response to the Setup call in the OWPS
>> layer. This would be needed when the Payer had made a mistake and entered
>> an invalid Payee account.
>>
>> Regards
>> Nick
>>
>> On 22 Mar 2016, at 5:52 AM, Stefan Thomas <stefan@ripple.com> wrote:
>>
>> Based on the requests for information about the layers in Interledger and
>> how the different protocols relate to each other I've put together a
>> strawman over the weekend:
>>
>>
>> https://stackedit.io/viewer#!provider=gist&gistId=f534bfb53dfffb980c66&filename=interledger-architecture.md
>>
>> There isn't much totally new stuff in there. It takes the ideas that are
>> floating around in our team, gives names to everything and makes a bunch of
>> arbitrary choices, all just to give us a starting point. Note that we're
>> still very actively working on this doc.
>>
>> If you're easily confused by changing specs, maybe you'll want to wait
>> until the doc settles down a bit more before diving in. :)
>>
>> Source for the doc is tracked on Github:
>> https://gist.github.com/justmoon/f534bfb53dfffb980c66
>>
>>
>>
>