{"action":"created","issue":{"url":"https://api.github.com/repos/interledger/rfcs/issues/408","repository_url":"https://api.github.com/repos/interledger/rfcs","labels_url":"https://api.github.com/repos/interledger/rfcs/issues/408/labels{/name}","comments_url":"https://api.github.com/repos/interledger/rfcs/issues/408/comments","events_url":"https://api.github.com/repos/interledger/rfcs/issues/408/events","html_url":"https://github.com/interledger/rfcs/pull/408","id":303989688,"number":408,"title":"Interledger Full Circle","user":{"login":"michielbdejong3","id":37227517,"avatar_url":"https://avatars3.githubusercontent.com/u/37227517?v=4","gravatar_id":"","url":"https://api.github.com/users/michielbdejong3","html_url":"https://github.com/michielbdejong3","followers_url":"https://api.github.com/users/michielbdejong3/followers","following_url":"https://api.github.com/users/michielbdejong3/following{/other_user}","gists_url":"https://api.github.com/users/michielbdejong3/gists{/gist_id}","starred_url":"https://api.github.com/users/michielbdejong3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/michielbdejong3/subscriptions","organizations_url":"https://api.github.com/users/michielbdejong3/orgs","repos_url":"https://api.github.com/users/michielbdejong3/repos","events_url":"https://api.github.com/users/michielbdejong3/events{/privacy}","received_events_url":"https://api.github.com/users/michielbdejong3/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2018-03-09T21:42:59Z","updated_at":"2018-03-19T16:02:14Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/interledger/rfcs/pulls/408","html_url":"https://github.com/interledger/rfcs/pull/408","diff_url":"https://github.com/interledger/rfcs/pull/408.diff","patch_url":"https://github.com/interledger/rfcs/pull/408.patch"},"body":"This is an idea I recently discussed with @BobWay and then adapted based on feedback from @emschwartz. It's still a bit raw, I could probably describe it more compellingly if I went over it a few more times, but I wanted to share it with the rest of you in this early version, before going on holiday next week (I'm actually posting this from a temporary github account while waiting for my 2FA to be reset):\r\n\r\n-----\r\n\r\nInterledger payments no longer travel over ledgers, they travel over bilateral connections like BTP/2.0.\r\nAt the same time, the individual chunks of an ILPv4 payment alter the balance of an account that implicitly exists between sender and receiver.\r\nTherefore, it makes sense to use Interledger along the entire circle: not only to connect the liquidity from sender to receiver, but also for connecting\r\nthe trust account that exists between them, and whose balance is adjusted by each chunk.\r\n\r\n```sh\r\nsender -> conn1 -> conn2 -> receiver\r\n  ^____________________________/\r\n```\r\nA chunked payment updates a number of balances: `sender - conn1`, `conn1 - conn2`, `conn2 - receiver`, and `receiver-sender`. In PSK, all but that last account run an ILPv4 link.\r\n\r\n## How it works\r\n\r\nThe receiver can request money from the sender, for instance in a `Pay` header or in a `window.monetization` call, by specifying a BTP server URL.\r\nThe sender connects and requests the Interledger address of its chunked payment account using IL-DCP.\r\nThe sender can now send chunks to its account \"at\" the receiver. So basically, `g.<receiverIlspPrefix>.<receiverId>.<senderId>`.\r\nBy sending chunks the sender can build up what `Pay-Balance` is in http-ilp, or what `Payment Amount` was in PSK 2, draft 1.\r\nThe sender receives all the chunks it sends, and provides the fulfillments one-by-one.\r\n\r\n## Advantages\r\n\r\n* no more need for condition generation with pre-shared keys and key derivation in the receiver, since the chunks are looped back to the sender, who can easily fulfill them.\r\n* no more need for separate concept of `Pay-Balance` in http-ilp\r\n* no more need for `Payment Amount` in chunked payments\r\n* no more need for request/response protocols on top of ILP, as sender and receiver are in direct communication with each other\r\n* no more need for data encryption and authentication in the transport layer, for that same reason\r\n* no more need for end-to-end quoting, as the sender can judge for itself how the source and destination amounts of each chunk compare to each other (this one is my favorite advantage, probably)\r\n* in short, this basically removes the need for a \"transport\" layer altogether - the receiver still needs to communicate its BTP URL to set up the connection, but that's more a \"setup flow\" than an actual \"transport layer\". The only layers on top of Interledger will now be things like a balance query protocol, IL-DCP, a routing protocol, etcetera.\r\n* a chunked payment updates a number of balances. In PSK, all but the receiver-sender account run an ILPv4 link. In Interledger Full Circle, we remove that imperfection, and it feels like with this, the very evolution of the Interledger protocol itself, also comes full circle! :)\r\n\r\n## Disadvantages\r\n\r\n* if the receiver is a client, they will need to run a hosted WebSocket server with something like localtunnel."},"comment":{"url":"https://api.github.com/repos/interledger/rfcs/issues/comments/374265602","html_url":"https://github.com/interledger/rfcs/pull/408#issuecomment-374265602","issue_url":"https://api.github.com/repos/interledger/rfcs/issues/408","id":374265602,"user":{"login":"emschwartz","id":3262610,"avatar_url":"https://avatars3.githubusercontent.com/u/3262610?v=4","gravatar_id":"","url":"https://api.github.com/users/emschwartz","html_url":"https://github.com/emschwartz","followers_url":"https://api.github.com/users/emschwartz/followers","following_url":"https://api.github.com/users/emschwartz/following{/other_user}","gists_url":"https://api.github.com/users/emschwartz/gists{/gist_id}","starred_url":"https://api.github.com/users/emschwartz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/emschwartz/subscriptions","organizations_url":"https://api.github.com/users/emschwartz/orgs","repos_url":"https://api.github.com/users/emschwartz/repos","events_url":"https://api.github.com/users/emschwartz/events{/privacy}","received_events_url":"https://api.github.com/users/emschwartz/received_events","type":"User","site_admin":false},"created_at":"2018-03-19T16:02:14Z","updated_at":"2018-03-19T16:02:14Z","author_association":"OWNER","body":"> To stop the flow, they would just not prepare the final hop back to the sender.\r\n\r\nAh, actually it's a bit trickier then that. If you're the sender, would you stop sending on any rejection or just on specific error codes? If you look for specific error codes but don't have a way to authenticate a message from the receiver, a connector that returns an F99 application error code (for whatever reason) could get you to stop sending when the receiver actually wants more money.\r\n\r\nAlso, it seems like this wouldn't work very well for streaming payments or ongoing interactions. Once the receiver has rejected one packet, how do they tell the sender to start sending again if they now want more money?"}}
{"actor":{"display_login":"emschwartz"}}