Re: [Sat] Proposing more use cases for SATP

[VENKATRAMAN RAMAKRISHNA <[e-mail]>]

Hi Peter,

>>> Both fixed. But in which case, should there be an extra step of sending/redeeming this receipt from the user to the content owner before actually receiving contents?

Yes. In your current diagram, this can be represented by an arrow from the User to the Content Owner (4) preceding the streaming step (which will now be 5). If this were specifically a smart contract system, we could state this in a different way as “User submits payment receipts to contract, which will then prompt/enforce the Content Owner to deliver the goods”.

>>> I agree. And since there’s already a lot of atomic swap examples let’s just drop the case to avoid confusion.

Yes, I think that would be wise. The existing examples provide ample scope for readers to imagine equivalent dynamics in other scenarios, including carbon trading.


Everyone,

I’ll wait another day for more comments on this proposal. If I don’t hear any objections or concerns until then, I’ll insert these examples into the Use Cases draft with appropriate edits, so that I can push the next version before the current one expires. We can, of course, discuss this again on the mailing list and in the next interim meeting.


Rama

From: sat <[e-mail]> On Behalf Of Liuchunchi(Peter)
Sent: Tuesday, January 23, 2024 1:25 PM
To: VENKATRAMAN RAMAKRISHNA <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [Sat] Proposing more use cases for SATP

Hi Rama, In both 5 and 6, there are different ways in which the protocol could be implemented. Step 2 can be a “data sharing” example (not covered by the SATP-core protocol at this time, which only transfers assets). This is because a payment
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
    Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!2k-r4v9_IJm6kA-RWMGFDvxlrTvJ9Dp_WEnbTTQOiOBC626tbOcRm9go1ZURtt3z3hmmL5_r0oTlJLSTBMWSp7VuDbvy$>   ‌
ZjQcmQRYFpfptBannerEnd
Hi Rama,


In both 5 and 6, there are different ways in which the protocol could be implemented. Step 2 can be a “data sharing” example (not covered by the SATP-core protocol at this time, which only transfers assets). This is because a payment receipt is not an asset, strictly speaking, but info and evidence. Alternatively, we can eliminate Step 2 altogether and perform 1 and 3 atomically using a swap (this is also not covered by the present incarnation of SATP-core). I can list these alternatives in the use cases draft as examples of interoperability modes listed in the SATP architecture draft.

Cool. I added the alternative diagrams that eliminates step 2, please see attached.
I was thinking the payment receipt can work like “service vouchers” that may work like assets... but it works either way.


I think in each case, the arrow from Step 2 ought to go from User in Payment Network to Content Owner in IP Network, as the incentive for communicating this info lies with the User, who stands to lose stream rights if evidence of payment is not supplied.

(Minor nitpick) In Figure 3, we can re-number the steps to start from 1

Both fixed. But in which case, should there be an extra step of sending/redeeming this receipt from the user to the content owner before actually receiving contents?


So I suggest we drop this scenario and instead just retain the atomic swap one.

… examples of which are already specified in the draft

I agree. And since there’s already a lot of atomic swap examples let’s just drop the case to avoid confusion.

Best,
Peter

From: VENKATRAMAN RAMAKRISHNA <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 19, 2024 11:09 PM
To: Liuchunchi(Peter) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Proposing more use cases for SATP

Hi Peter (Chunchi)

Sorry for my very late follow-up on this topic.

I think 4.4 looks good now, and thanks for incorporating my feedback. I had the following thoughts on the other examples though, after a re-reading.

In both 5 and 6, there are different ways in which the protocol could be implemented. Step 2 can be a “data sharing” example (not covered by the SATP-core protocol at this time, which only transfers assets). This is because a payment receipt is not an asset, strictly speaking, but info and evidence. Alternatively, we can eliminate Step 2 altogether and perform 1 and 3 atomically using a swap (this is also not covered by the present incarnation of SATP-core). I can list these alternatives in the use cases draft as examples of interoperability modes listed in the SATP architecture draft.

A couple of other revisions:
- I think in each case, the arrow from Step 2 ought to go from User in Payment Network to Content Owner in IP Network, as the incentive for communicating this info lies with the User, who stands to lose stream rights if evidence of payment is not supplied.
- (Minor nitpick) In Figure 3, we can re-number the steps to start from 1

The setting of the  “7. Carbon Credit Trading” example is somewhat unclear. On one hand, this scenario resembles a standard Delivery-vs-Payment (DvP) involving an atomic swap across two networks, examples of which are already specified in the draft. We can add this as yet another example of a real-world atomic swap-based DvP, where there exist two networks: 1) a carbon credit trading network, and 2) a retail CBDC network; the buyer and the seller are members of both networks.

I don’t exactly remember my thinking around buyer and seller belonging to different networks. We can conjure a scenario where there exists a single retail CBDC network to facilitate payments but two separate carbon trading networks, one to which the seller belongs and another to which the buyer belongs. The credits can be transferred via SATP across network boundaries. But in this scenario, it is hard to guarantee the atomicity of the credits and payment transfer, and our current SATP architecture and protocol design don’t provide a solution. So I suggest we drop this scenario and instead just retain the atomic swap one.


Others on the mailing list, do you have any comments or questions about these use cases? If not, I plan to add them to the SATP Use Cases draft before the next Interim Meeting, after resolving the above issues with Peter on this forum.


Rama

From: Liuchunchi(Peter) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 23, 2023 1:39 PM
To: [e-mail]<mailto:[e-mail]>
Cc: VENKATRAMAN RAMAKRISHNA <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Proposing more use cases for SATP

Hello SATP, As suggested in the previous IETF sessions and previous mailing list discussion, I wrote some additional SATP use cases, including support to operating financial instruments (exercising options contract), pay-as-you-watch/use, etc. 

Hello SATP,

As suggested in the previous IETF sessions and previous mailing list discussion, I wrote some additional SATP use cases, including support to operating financial instruments (exercising options contract), pay-as-you-watch/use, etc.

The content is discussed off-list with @rama. Would the team have a look and see if you have comments or questions? The content is attached.

Best regards,
Peter (Chunchi) Liu