W3C home > Mailing lists > Public > public-interledger@w3.org > July 2016

Re: newcomer "random" doubts about ILP

From: Evan Schwartz <evan@ripple.com>
Date: Sat, 23 Jul 2016 12:15:43 +0200
Message-ID: <CAONA2jWRK=prL=sG0NHz+-r8Ctyz7OY=CckkypcP2bhmxUAC1A@mail.gmail.com>
To: Lucas Huber <lh@codoo.io>
Cc: "Romero, Javier (ISBANUK)" <Javier.RomeroColomo@isbanuk.com>, Enrique Arizon Benito <enrique.arizon.benito@everis.com>, "public-interledger@w3.org" <public-interledger@w3.org>
Hi Enrique,

Great questions.


> DOUBT: By reading the available docs/RFC, looks to me that the use of the
> JSON+REST protocols are enforced by the ILP/SPSP/ITP/.. protocol/s.
>        Reuse of any existing transport/communication protocol/s, between
> client and servers is not contemplated.


Lucas is correct. To integrate an existing system you would probably want
to have a backend service that sends and receives ILP payments. You could
have any communication protocol you want between the client and server.

DOUBT: Does this use-case [integrating payouts to external networks] makes
> sense within the current ILP protocol?
>

Sure, why not? I think we'll end up seeing higher level protocols built on
ILP that resolve some kind of human-friendly names into ILP addresses. I
would want the user experience where I don't even have a drop-down of
places I can send to. Instead, I just type in who I want to send money to
and it just works.

 DOUBT: The server used to process the client/wallet SPSP requests
> (Discovery, Query, Quoting, Setup) can be isolated from the ledger?
>     Looks to me that only the information in the Setup stage must "arrive"
> to the ledger.


Correct, SPSP is not part of ILP and that server is distinct from the
ledger.

DOUBT: Is there any error handling predefined strategy?
>          for example, all messages from the ledger to the connector must
> check first if  the response contains payload or exception.
>
>   DOUBT: Does/will the protocol define a set of predefined exceptions from
> server to server in case of connector internal error ?


Error handling across the path of connectors is one of the areas where
there is more work to be done. We have some ideas how it will happen but
they aren't fully fleshed out or documented yet. There's an issue
<https://github.com/interledger/rfcs/issues/42> here about that.

DOUBT: Can the five-bells-wallet/five-bells-connector and related tests be
> reused while developing a new java-testing-ledger or would it be any
> technical issues?


With a little bit of modification you could probably drop a different
implementation of the ledger into the integration tests
<https://github.com/interledger/five-bells-integration-test>. The unit
tests for the five-bells-ledger are currently coupled with that
implementation. However, we have talked about having a kind of
"recommended" ledger API that would look something like the
five-bells-ledger API. If we do that it would be useful to have a test
suite that is decoupled from the implementation, but we haven't gotten to
working on that yet.

Hope that helps,
Evan

On Sat, Jul 23, 2016 at 11:56 AM, Lucas Huber <lh@codoo.io> wrote:

> Enrique I think you can reduce a lot of your doubts, if you limit the
> usecase for an implementation to a ledger to ledger communication. If you
> start to look at ILP for wallets/clients and apps I would express similar
> doubts as you have.
>
> Lucas
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
>
> Am 23. Juli 2016 10:23:35 MESZ, schrieb "Romero, Javier (ISBANUK)" <
> Javier.RomeroColomo@isbanuk.com>:
>>
>> imho...
>>
>> You are always going to need some sort of plugin to 'connect' legacy systems to the 'protocol'.
>> These could be JSON/RPC as far as ILP is concern but could communicate as you like internally.
>>
>> I think, correct me guys if I am wrong, what's important here is the protocol itself.
>> There are a few proposed demo's and reference implementations as a starting point but each developer would have to adapt them to their needs as long as the protocol is respected.
>>
>>  On 22 Jul 2016, at 21:40, Enrique Arizon Benito <enrique.arizon.benito@everis.com> wrote:
>>>
>>>  Hi all,
>>>
>>>  I'm new to Interledger. I just got a first look at the RFC and the five-bells demo.
>>>
>>>  Some doubts arise after reading the docs. I post then next. Fell free to answer if you consider it worth the effort, ignore
>>> them or request for more details.
>>>
>>>  Some previous context:
>>>   - I'm interested in the possibility to create an interface connecting existing ledger systems ("banks") with any other ledger/payment system/blockchain technology that accepts the ILP protocol.
>>>  In practice that means implementing a set of JAVA APIs/libraries/servers to "automate" the integration bank <-> ILP connector, front-end <-> bank, ...
>>>   - For development/testing purposes I was thinking to develop a keep-it-simple-and-stupid in-memory ledger/database
>>>   and implement around it the different interfaces to interact with the ledger client ("wallet") and the ILP connector.
>>>
>>>  My doubts come next:
>>>
>>>
>>>  * ABOUT THE CLIENT WALLET:
>>>
>>>   - Ussually the ledger (bank) o payment network (paypal, crypto-currency bloc-chain, ...) already has one or more UI front-ends (HTML5, Mobile App, telephone channel, bitcoin-wallet, ... ).
>>>     For example in
>>> the case of a "normal" bank it could be a MVC architecture, with an already established communication protocol/s (XML, JSON, RMI, REST, SOAP...)  and an intermediate application server (JEE, ...) with users connecting through their web browsers/mobile clients.
>>>
>>>     Let's suppose now that we want to add to my already existing apps the functionality  for a ILP compliant wallet:
>>>
>>>     DOUBT: By reading the available docs/RFC, looks to me that the use of the JSON+REST protocols are enforced by the ILP/SPSP/ITP/.. protocol/s.
>>>        Reuse of any existing transport/communication protocol/s, between client and servers is not contemplated.
>>>
>>>
>>>   - Suppose a bank already offers an mobile app for final users to simplify payments to other internal/external bank accounts. Now I would like to reuse such app to allow final users to pay to external payment networks like Paypal, Ripple, Bitcoin, ...(supposing such networks already offer ILP connector
>>> support).
>>>
>>>     The user interface will offer the option to pay to:
>>>         - Internal bank account
>>>         - External bank account
>>>         - ILP URI account (receiver)
>>>         - ...
>>>
>>>     DOUBT: Does this use-case makes sense within the current ILP protocol?
>>>
>>>
>>>
>>>  * ABOUT THE SPSP PROTOCOL:
>>>   - As I understand it, the SPSP protocol is used to fetch the previous INPUT (payment details, crypto-conditions, ILP connector path) to the ILP protocol, but is not part of the ILP protocol itself.
>>>
>>>     DOUBT: The server used to process the client/wallet SPSP requests (Discovery, Query, Quoting, Setup) can be isolated from the ledger?
>>>     Looks to me that only the information in the Setup stage must "arrive" to the ledger.
>>>
>>>
>>>
>>>  *  ABOUT ERROR HANDLING:
>>>
>>>   DOUBT: Is there any error handling predefined strategy?
>>>          for example, all messages from the ledger to the
>>> connector must check first if  the response contains payload or exception.
>>>
>>>   DOUBT: Does/will the protocol define a set of predefined exceptions from server to server in case of connector internal error ?
>>>
>>>  * ABOUT DEVELOPMENT:
>>>   I observed that many work has already been done in the five-ledger demo to test the correct behavior. (five-bells-*/test/*).
>>>   I'm wondering what will be the easier path to start implementing the five-bells-ledger equivalent in java
>>>
>>>   DOUBT: Can the five-bells-wallet/five-bells-connector and related tests be reused while developing a new java-testing-ledger or would it be any technical issues?
>>>
>>>
>>>  Best Regards,
>>>
>>>  Enrique Arizón Benito
>>>  Tel: +34 976 482 080, ext 117064
>>>  http://www.everis.com
>>>
>>> ------------------------------
>>>
>>>
>>>  AVISO DE CONFIDENCIALIDAD.
>>>  Este correo y la información contenida o adjunta al mismo es privada y confidencial y
>>> va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.
>>>
>>>  CONFIDENTIALITY WARNING.
>>>  This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.
>>>
>>>
>>> **********************DISCLAIMER*****************
>> This message is private and confidential and it is intended exclusively for the addressee. If you receive this message by mistake, you should not disseminate, distribute or copy this e-mail. Please inform the sender and delete the message and attachments from your system. No confidentiality nor any privilege regarding the information is waived or lost by any mistransmission or malfunction.
>> Any views or opinions contained in this message are solely those of the author, and do not necessarily represent those of ISBAN, unless otherwise specifically stated and the sender is authorized to do so.
>> E-mail transmission cannot be guaranteed to be secure, confidential, or
>> error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. ISBAN does not accept responsibility for any changes, errors or omissions in the contents of this message after it has
>> been sent.
>> This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
>>
>> *********************AVISO LEGAL **********************
>> Este mensaje es privado y confidencial y solamente para la persona a la que va dirigido. Si usted ha recibido este mensaje por error, no debe revelar, copiar, distribuir o usarlo en ningun sentido. Le rogamos lo comunique al remitente y borre dicho mensaje y cualquier documento adjunto que pudiera contener. No hay renuncia a la confidencialidad ni a ningun privilegio por causa de transmision erronea o mal funcionamiento.
>> Cualquier opinion expresada en este mensaje pertenece unicamente al autor remitente, y no representa necesariamente la opinion de ISBAN, a no ser que expresamente se diga y el remitente este autorizado para hacerlo.
>> Los correos electronicos no son seguros, no garantizan la confidencialidad ni la
>> correcta recepcion de los mismos, dado que pueden ser interceptados,
>> manipulados, destruidos, llegar con demora o incompletos, o con virus. ISBAN no se hace responsable de los cambios, alteraciones, errores u omisiones que pudieran hacerse al mensaje una vez enviado.
>> Este mensaje solo tiene una finalidad de informacion, y no debe interpretarse como una oferta de venta o de compra de valores ni de instrumentos financieros relacionados.
>> Ref:[PDB#015]
>>
>>


-- 
Evan Schwartz | Software Architect | Ripple
[image: ripple.com] <http://ripple.com>
Received on Saturday, 23 July 2016 10:16:34 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 23 July 2016 10:16:35 UTC