- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 3 Jun 2016 11:47:42 +0200
- To: Evan Schwartz <evan@ripple.com>
- Cc: Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CAKaEYhLbV7TTfV42OWRN-vzsqKco_iY-5DpngbAJa7F8jprKZw@mail.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 09:48:10 UTC