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

newcomer "random" doubts about ILP

From: Enrique Arizon Benito <enrique.arizon.benito@everis.com>
Date: Thu, 21 Jul 2016 10:56:51 +0000
To: "public-interledger@w3.org" <public-interledger@w3.org>
Message-ID: <C23179174213FF4A8B0ADF823E0D2DD04E41D885@MBXEUR04.usersad.everis.int>
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:


  - 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?

  - 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.


  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 ?

  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


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.

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.
Received on Friday, 22 July 2016 20:38:36 UTC

This archive was generated by hypermail 2.3.1 : Friday, 22 July 2016 20:38:36 UTC