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

Re: Interledger RFCs, ILP Packet, and Ledger Plugin Interface

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Fri, 3 Jun 2016 11:47:42 +0200
Message-ID: <CAKaEYhLbV7TTfV42OWRN-vzsqKco_iY-5DpngbAJa7F8jprKZw@mail.gmail.com>
To: Evan Schwartz <evan@ripple.com>
Cc: Interledger Community Group <public-interledger@w3.org>
On 1 June 2016 at 00:22, Evan Schwartz <evan@ripple.com> wrote:

> I want call your attention to the Interledger RFCs repo
> <https://github.com/interledger/rfcs>, and to three of the documents in
> particular. These reflect the latest ideas, which includes some new
> developments that clarify the structure of Interledger and make the analogy
> between Interledger and the internet protocols even stronger.
>
>    - IL-RFC-1: Interledger Architecture
>    <https://github.com/interledger/rfcs/blob/master/0001-interledger-architecture/0001-interledger-architecture.md>
>    This provides an overview of how the protocols in the Interledger
>    suite fit together and may be useful for answering the question "so what
>    *is* interledger?" (the whitepaper is more a theoretical defense of
>    the concepts underpinning interledger, rather than a description of the
>    components and how they work)
>    - IL-RFC-3: Interledger Protocol
>    <https://github.com/interledger/rfcs/blob/master/0003-interledger-protocol/0003-interledger-protocol.md>
>    This spec describes the ILP Packet format (a new and important
>    concept), which is heavily inspired by IP packets. Notably, it only
>    includes the destination address, destination amount and a nextHeader field
>    for adding additional headers (inspired by IPv6's extension format). It
>    does not include conditions, because we realized those actually fit into
>    "transport layer" protocols such as Universal and Atomic.
>    - IL-RFC-4: Ledger Plugin Interface
>    <https://github.com/interledger/rfcs/blob/master/0004-ledger-plugin-interface/0004-ledger-plugin-interface.md>
>    This is the Interledger protocol, right? So it's time for us to be
>    able to support other types of ledgers. This spec defines the abstraction
>    layer we will use to enable Interledger payments over new ledger types
>    (Bitcoin, Ethereum, BigchainDB, etc). We'll be refactoring the
>    five-bells-sender and -connector to use this interface. The goal is to make
>    supporting new ledgers as easy as writing a library that defines these
>    functions and plugging it in to the existing client and connector code
>    bases.
>
> As the name suggests, these are requests for comments, so comment away!
>
> These are all still drafts (and the other specs in the repo are just
> placeholders for now) but we're excited about these developments and
> realizations so we wanted to make sure you saw them.
>

I wanted to give a vision of where I think this can go.

Below is an example used in the node community of a dependency tree that I
installed for running a test coin demo.

https://gist.github.com/melvincarvalho/7c53a75479ee300d119e9c6e749f3841

As you can see there is a rich tree of components (over 500!) each 'doing
one thing well' and all coming together to make one application.

I see finance as the same degree of complexity.  So while a ledger might be
at the root of the vast majority of financial systems, after that, the
complexity spirals.

IMHO the best approach is the modular one.  I think ripple and digital
bazaar are part of the node community and I think the packaging systems
evolving there (e.g. npm) are working well and getting better.

I think we need to take this approach to finance in general and modular
type applications built on top of that.

ILP being an example of one such app.  I like this analogy more than the
comparison with internet protocols.


>
> --
> Evan Schwartz | Software Architect | Ripple
> [image: ripple.com] <http://ripple.com>
>
Received on Friday, 3 June 2016 09:48:10 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 June 2016 09:48:11 UTC