Re: The case for modularizing ILP

On 25 May 2016 at 16:04, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>
>
> On 25 May 2016 at 15:17, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
>
>> Hi Melvin,
>>
>> The timing is interesting :)
>>
>> There is a lot of refactoring going on at the moment to make implementing
>> ILP on existing ledgers (using the reference source code) easier and
>> possible through a kind of "plug-in" system.
>>
>> Also, the website will be relaunching this week (for a sneak preview see
>> the v2 branch on github) with a LOT more developer resources. Our focus for
>> the London workshop on 6 July is very slanted toward developing with ILP
>> (as opposed to purely development of core ILP components) and we've set
>> aside the whole afternoon for hacking projects together that use or extend
>> ILP.
>>
>> I hope you can join us in London on 6 July (interledger.org/workshop)
>>
>> What I think you'll find most interesting is the awesome work that Stefan
>> and Evan have been doing in organising the specs into an RFC-style set at
>> http://github.com/interledger/rfcs (WIP so please take as such)
>>
>> I did a presentation at WWWConf a few weeks ago which builds on the
>> architecture concepts you'll see there and explains the bridge from the
>> work being done in the W3C Web Payments WG and ILP (and how we are
>> architecting ILP to get the Internet of Value by creating direct analogies
>> with the Internet itself).
>>
>> https://www.w3.org/2016/Talks/future-payments-201604.pdf
>>
>
> Oh excellent!  I really hope we can find some common patterns and maybe
> code reuse!  I think this is a common problem many people have and no one
> really has the right answer, but lots of people getting close.
>
> I guess one of the points of standards is to get different things to all
> glue together.  I'd be really happy if we can make an eco system that does
> that.
>

Exactly. The proposed architecture does a few things.

1. It puts very few requirements on to ledgers. The complexity sits at the
connectors who abstract away the differences between ledgers. Ledgers that
don't support certain functions (like escrow) still fit into the
architecture but those limitations simply limit the available higher level
protocols that can be used with them.

2. It creates a good base for experimentation at different layers. We have
three transport layer protocols evolving but someone could come forward
with a new one that proves to be useful too.

3. There is a blank canvas for application layer protocols. We have
proposed one (which I know you are not crazy about because it uses
WebFinger) but you could propose and entirely different one that uses some
of the same building blocks or something entirely different.


>
> I like the idea of hacking projects ...
>

Hope you can join the workshop!


>
>>
>>
>> Adrian
>>
>> On 25 May 2016 at 10:28, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>> ILP is a great concept, and I was wondering if we could think about
>>> breaking it down into self contained modules.
>>>
>>> This seems to bet the way some folks are going.
>>>
>>> Here is the kind of idea I posted recently:
>>>
>>> Ledger
>>> Block chain -> Ledger
>>> Central Mint -> Ledger
>>> Trading -> Testnet3 -> Ledger
>>> Derivatives -> Trading -> Bitcoin -> Ledger
>>> Media player -> Block Chain -> Ledger
>>> Search -> Media Player -> Bitcoin -> Ledger
>>> DAO -> Smart Contracts -> Block Chain -> Ledger
>>> Equities -> DAO -> Ledger
>>> Crowd Funding -> Equities -> DAO -> Ledger
>>> Bounties -> Ledger
>>> Github -> Bounties -> Ledger
>>>
>>> I'll be implementing this kind of things hopefully over time via quantum
>>> payments
>>>
>>> Here's also an example of bedrock:
>>>
>>> https://github.com/digitalbazaar/bedrock
>>>
>>> I know that ripple labs impl. are to an extent modularized but I wonder
>>> if we could somehow formalize this a bit more.
>>>
>>> What would be the core componens of ILP?
>>>
>>> With Ledger as the core unit common to most systems.  Since I think
>>> we're almost all building via nodejs / npm I wonder if it would be of value
>>> to think about a package manager type thing also.
>>>
>>> Im hopefully going to create this over time, probably on a 1-2 year time
>>> frame, hopefully more in the 1 year than 2.  Would love to hear thoughts ...
>>>
>>
>>
>