W3C home > Mailing lists > Public > public-interledger@w3.org > November 2015

Re: Webinar Slides

From: Evan Schwartz <evan@ripple.com>
Date: Tue, 17 Nov 2015 17:09:27 -0800
Message-ID: <CAONA2jXjot+k87Siv5_bHxXaHF1qghYyrpa_SD-KA+7s9f1iYw@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Stefan Thomas <stefan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
I'd think about it in terms of use cases. If you have a larger payment and
need the guarantee that money cannot be lost, it would be worth it to
involve notaries. For smaller payments between more disparate parties
Universal might make more sense.

You're right that atomicity is desirable rather than needed. If there is
more risk without it that will show up in higher fees though. In any case,
this tradeoff is precisely why there are the two modes.

On Tue, Nov 17, 2015 at 5:03 PM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 18 November 2015 at 01:40, Stefan Thomas <stefan@ripple.com> wrote:
>
>> For everyone who missed the webinar on Oct 20th, the slides are now
>> available on Slideshare:
>>
>> http://www.slideshare.net/Interledger/ilp-webinar-102015-55230856
>>
>
> Very good slides.
>
> Was easier to grok than the paper (though I like the paper too)
>
> Still not that cemented in my mind yet is the role of the notary vs
> universal mode.  At one point I was thinking notaries make sense, then the
> next slides I think universal mode makes sense, and notaries dont.  Why use
> one and not the other.
>
> Also slight nit, I would prefer to think of atomicity is "desirable"
> rather than "needed", but maybe that's just me ...
>
>
>>
>>
>> We were also hoping to post a video of the webinar, but unfortunately the
>> recording was lost. What we'll probably do is either hold the same webinar
>> again or just record the presentation by itself.
>>
>
>


-- 
Evan Schwartz | Software Architect | Ripple Labs
[image: ripple.com] <http://ripple.com>
Received on Wednesday, 18 November 2015 01:10:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 18 November 2015 01:10:16 UTC