Re: Promise App

How is this notion different from the standard approach of a payment
including remittance detail, which refers / links back to other documents
(typically one or more invoices, but potentially also a PO or agreement),
which in turn relate to the contract? Or specifically, how would the
payment content / standard differ in such a scenario where the "full
contract" *is* described?


On Tue, Apr 18, 2017 at 9:06 AM, Andrew Bransford Brown <andrewbb@gmail.com>
wrote:

> I concur and can participate in a new group defining contract terminology
> and structure.  All transactions are contracts and payments only describe
> the delivery of one side.
>
> In my opinion, that leads to complexity in describing the payment, because
> the full contract isn't described.
>
> On Tue, Apr 18, 2017 at 8:07 AM, Adrian Hope-Bailie <adrian@hopebailie.com
> > wrote:
>
>> > Maybe it's worth creating a separate mailing list that discusses topics
>> more around 'Conversations for Action' (promises, offers, etc.), and keep
>> this mailing list strictly about Interledger?
>>
>> Not a bad idea. I am surprised by the lack of coherence around standards
>> for "smart contracts" and this probably fits in that category. Do any of
>> the other W3C folk on this list know of any CGs addressing this kind of
>> thing?
>>
>>
>> On 18 April 2017 at 10:58, Michiel de Jong <michiel@ripple.com> wrote:
>>
>>> Hi Andrew,
>>>
>>> Thanks for your post - I totally agree with you that it's important to
>>> understand the terminology around 'promise', 'want', 'offer', 'terms', and
>>> 'counter' that lead up to a payment.
>>>
>>> However, this community group was created for discussing Interledger,
>>> and its scope is therefore limited to payments, and the ledger transfers
>>> involved in making these payments work across ledgers (hence the name
>>> "inter"-"ledger").
>>>
>>> 'Why' a payment occurs, 'how' the two parties agreed on the payment
>>> amount, 'what' service or goods the payment is for, and even whether it's
>>> an up-front payment (creating a debt) or an afterwards payment (resolving a
>>> debt), is out of scope.
>>>
>>> I recently added a glossary to the RFCs repo, which might be of
>>> interest: https://github.com/interledger/rfcs/blob/master/00
>>> 19-glossary/0019-glossary.md
>>> <https://github..com/interledger/rfcs/blob/master/0019-glossary/0019-glossary.md>
>>> - as you can see, it only discusses terminology surrounding Interledger
>>> payments.
>>>
>>> Do you think Interledger should describe more than just payments?
>>> Personally, I think it would make the scope to broad.
>>>
>>> Maybe it's worth creating a separate mailing list that discusses topics
>>> more around 'Conversations for Action' (promises, offers, etc.), and keep
>>> this mailing list strictly about Interledger?
>>>
>>> What do others think?
>>>
>>>
>>> Cheers,
>>> Michiel.
>>>
>>> On Mon, Apr 17, 2017 at 12:18 AM, Andrew Bransford Brown <
>>> andrewbb@gmail.com> wrote:
>>>
>>>> Understanding adversarial contract disputes and resolution:
>>>> http://34.208.7.206/ContractsPage.aspx
>>>>
>>>>
>>>>
>>>
>>
>