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

On 3 June 2016 at 11:47, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

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

Just to give an idea the components I have been prototyping

Ledger -- the root class of all financial systems

Faucet -- accepts payments, and pays out a % after successful challenge

Basic Income -- Will pay a set amount one per user on a regular cadence

402 -- Paywalls for resources

Media -- media server with paid access control

Balance -- example module which just shows a balance

Deposit -- deposit crypto currency coins onto a ledger

Withdrawals -- withdraw crypto currency and request withdrawal

HDWallets -- heirarchical deterministic wallets to generate securely
accounts and one per user

Each of these components took me under a day to prototype and Im starting
to be able to fit them together into demos.  Im hoping, as a group, we'll
be able to evolve a similar type eco system where we reuse components from
each other to make next generation work flows!


>
>
>>
>> --
>> Evan Schwartz | Software Architect | Ripple
>> [image: ripple.com] <http://ripple.com>
>>
>
>