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 12:28:01 +0200
Message-ID: <CAKaEYhJiX_o-_NbAQcTZpmTwH5zK9jLCopuVkueS8qe=XkrX6w@mail.gmail.com>
To: Dimitri De Jonghe <dimi@ascribe.io>
Cc: Evan Schwartz <evan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
On 3 June 2016 at 11:52, Dimitri De Jonghe <dimi@ascribe.io> wrote:

> Hi Melvin,
> I think the key difference between an npm tree, a blockchain tree and ILP
> would be the fact that ILP is indeed a protocol, a language/protocol to
> communicate between ledgers.
> So, I can imagine that a group of ledgers decide to create a blockchain
> network by themselves, but they would need to communicate...

I think the analogy of ledger to internet protocols makes sense to take to
the financial world, because almost everything is based on a ledger.

However I think that's where the analogy ends.  There's not one way in
which ledgers communicate or trade in the real world, there's dozens,
perhaps 1000s.  The ILP protocol is just one of these.  And there's no
reason to think it's any more special than another strategy, aside from the
fact that we are getting documentation and an implementation.

Breaking down the various parts of ILP in a modular way, but also in a way
that it can be run as a whole I think is going to be the way this work

The plus side is that the first to market with this kind of technology can
not just solve use cases, but take the whole financial world by storm.  At
the same time high quality solutions will get a user base, following and
funding to become the new giants in the field.

> Op vr 3 jun. 2016 om 11:49 schreef Melvin Carvalho <
> melvincarvalho@gmail.com>:
>> 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 10:28:30 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 June 2016 10:28:31 UTC