Re: newcomer "random" doubts about ILP

Hi Guys,

Are there some Reference Implementations which we can study for more information?

Thanks,
Jacob
--------------------------------------------
On Sat, 7/23/16, Evan Schwartz <evan@ripple.com> wrote:

 Subject: Re: newcomer "random" doubts about ILP
 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>
 Date: Saturday, July 23, 2016, 3:45 PM
 
 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
 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. 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

Received on Sunday, 24 July 2016 12:44:04 UTC