Re: newcomer "random" doubts about ILP

https://github.com/interledger -- the demo is a decent place to start

On Jul 24, 2016 11:46 AM, "Jacob Ninan" <jacob_kn@yahoo.com> wrote:

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