Express-Deals

[irenegia]

• ~Self~ Express-deal (”deal for everyone”, no proposal)
  • Why?
    • SP can better market their storage
    • Station nodes better market their retrieval

Estimated time

1 week

Effort

Write an MVP contract and design docs by simplyfing the retriev protocol, allowing self-dealing

[irenegia]

Design proposal 1:

• Add a field in the deal structure to signal if a deal is client-provider deal or a self-deal;
• Add to the retriev smart contract this function: CreateSelfDeal: specify data_uri, collateral, duration;
• Modify the CreateAppeal function, to allow any address to create an appeal for a self-deal;

Design proposal 2:

• Retriev contract is not modified
• Write a new sc that implements the CreateAppeal function

To have a self-deal, a provider will use the current CreateDealProposal + AcceptDealProposal functions from retriev, specyfing the new sc address as the one that can create appeals.

Comments:

• (2) has modular design, don't touch the retriev sc, but provider will have to pay more gas for a self-deal;
• (1) requires a new release of retriev, but is a cheaper solutions for providers;
• With (1) we can have a list of which deals are indeed self-deals!

[irenegia]

Suggested plan (@turinglabsorg @lucaniz @irenegia):

We use design 1, we will have only 1 retriev sc that will allows both for self-deals and client-provider deals.

@nicola any comments?

[irenegia]

New Design:

• Add to the retriev smart contract this function: CreateDealWithoutProposal: specify data_uri, collateral, duration, list of addresses that can call CreateAppeal;

• Change the createAppeal function, which allows anyone to run the transaction if the list is empty

• Create a new boilerplate contract which allows providers spin up a simple contract to create an allow list

[irenegia]

@turinglabsorg: I will add the following text to the spec.

createDealWithoutProposal( string data_uri, uint256 duration, array[] appeal_addresses ) -> uint256 deal_id

A provider can create a deal specifying:

• The identifier of the file (or folder of files) that is the subject of the deal, data_uri;
• The list of addresses that can later on send the “create appeal” transactions;
• The duration: for how long the deal is active, starting from when it is created (expressed in seconds); the deal is valid only if duration is in a range specified by the smart contract code (see “protocol parameters” section).
• The collateral (msg.value as input parameter): amount (in native tokens) that is “locked down” (ie, from the provider’s account deposited to the smart contract). Also, we timestamp this on-chain, and we consider the deal active from this moment (timestamp_start).

Note that if the list is empty, transaction will fail. Also, this list can point to a sc address that will manage the list of allowed addresses.

Questions [solved]:

• [sc] do we need to check if collateral in a range specified by the smart contract?
  • not needed
• [cli] a provider will check that he can access the files (as he does before accepting a proposal), correct? Should also check the file size is <= than the max_size specified in the policy? Or we do an exception here because it is a "self deal"?
  • we have this added as default to avoid providers' error, but it make sense to have a "force mode" that allows to skip the checks

[irenegia]

Open question: How do we prevent providers to create deals for which no one can create an appeal (eg, deal that has the address of a sc with "impossible condition" in the allow list").

Maybe she should add a "master address" that can create appeal for any deal?

[turinglabsorg]

@irenegia since we solve this last "issue" I can implement it and make changes to the contract, do you want to discuss sync with @nicola too?

[turinglabsorg]

@irenegia let's add this point to the weekly protocol call today please

[turinglabsorg]

@irenegia let's summarize our previous meeting:

• Is fine if provider can add any contract (even the empty one), no need for "master address"
• [ ] We have to work for a better naming, "self deal" doesn't fit use case
• We should create a simple contract which will be eventually added by default which allows anyone make appeals

If this is correct and we have a final 👍 from @nicola plan is:

• [x] Create a new branch to work on protocol changes
• [x] Create a new folder for this template contract (maybe on onchain.storage?, let's discuss)
• [x] Make provider-cli changes to allow providers do the deals from command line to automate processes

cc @lucaniz

[irenegia]

We have to work for a better naming, "self deal" doesn't fit use case

What about "programmable deal"? It is programmable in the sense that who can create the appeal is decide by a sc. Or maybe just "open deal" (like it is a deal from a provider to in principle many clients/appeal allowed users)?

Any preference here?

[irenegia]

Create a new folder for this template contract (maybe on onchain.storage?, let's discuss)

What is the motivation for going on the onchain.storage repo instead of staying the retriev one? @turinglabsorg

[lucaniz]

I like more open deal, but it's a matter of taste :)

[turinglabsorg]

What is the motivation for going on the onchain.storage repo instead of staying the retriev one? @turinglabsorg

@irenegia since we're not extending the contract itself but just providing a new "tool" for me makes sense to have it on onchain repo. We can see the "template appeal" as part of the ecosystem instead of this specific protocol (having also in mind we want to abstract the oracle contract)

[turinglabsorg]

I like more open deal, but it's a matter of taste :)

i like open deal too, in effect we don't have any owner (client).

One question, these deals should be listed inside the UI somewhere?

[turinglabsorg]

[sc] do we need to check if collateral in a range specified by the smart contract? not needed

I've another two questions:

• do we need to check if collateral is greater than 0? Or we can accept also 0 as collateral for these deals?
• we have a lock on the number of appeals (5), we need to maintain this lock? Or for these deals we have to make it higher?

cc @lucaniz @irenegia

[lucaniz]

do we need to check if collateral is greater than 0? Or we can accept also 0 as collateral for these deals?

My take is that in principle collateral could be 0 given that this is a "self promoting" deal which shows SP capabilities. Nevertheless having a collateral = 0 could open the door to SP self promoting without actually giving any service. That said, if we had a reputation system in place that is influenced by the failed appeals, then it is fine to have collateral = 0. If not, i'd set up a collateral != 0. It is true that one can always check how many failed attempts an SP went through (so there is an implicit reputation system somehow), but I guess it's kind of "convoluted". Let's discuss it together.

we have a lock on the number of appeals (5), we need to maintain this lock? Or for these deals we have to make it higher?

Good question....Is it possible to let the SP tune that parameter? I'm wondering if this is enough to self-regulate the market...

Happy to jump into a brainstorm

[irenegia]

do we need to check if collateral is greater than 0? Or we can accept also 0 as collateral for these deals?

I agree with what Luca said, accepting collateral = 0 is okay in my opinion. Moreover, we already accept collateral = 0 in the "standard" deal, so why should the open deal be different?

we have a lock on the number of appeals (5), we need to maintain this lock? Or for these deals we have to make it higher?

It make sense to have two different max, one for open deals e one for the standard deals. But notice that as soon as we add the pass system #90 , then I the real max should be the number of passes that a provider accept to give to the client. No?

One question, these deals should be listed inside the UI somewhere?

Like an open deal appears in the dashboard of any client? Or and adhoc public dashboard? In any case, we it would be nice to have a way to "show" the open deals!

[lucaniz]

It make sense to have two different max, one for open deals e one for the standard deals. But notice that as soon as we add the pass system https://github.com/protocol/retriev/issues/90 , then I the real max should be the number of passes that a provider accept to give to the client. No?

I agree. But I think that for an open deal we should decide if

• The number of passes holds overall and that's it. Here passes == max appeals
• a SP can "negotiate" in some way different number of passes with different client (maybe it's not possible) up to the total number of passes sums up to its maximum

I think the first option is the easier path (and maybe the only one that makes sense with open deals?)

Like an open deal appears in the dashboard of any client? Or and adhoc public dashboard? In any case, we it would be nice to have a way to "show" the open deals!

I like the idea of the open deal dashboard!

[turinglabsorg]

do we need to check if collateral is greater than 0? Or we can accept also 0 as collateral for these deals?

I agree with what Luca said, accepting collateral = 0 is okay in my opinion. Moreover, we already accept collateral = 0 in the "standard" deal, so why should the open deal be different?

ok!

we have a lock on the number of appeals (5), we need to maintain this lock? Or for these deals we have to make it higher?

It make sense to have two different max, one for open deals e one for the standard deals. But notice that as soon as we add the pass system https://github.com/protocol/retriev/issues/90 , then I the real max should be the number of passes that a provider accept to give to the client. No?

Agree, let's figure out later

One question, these deals should be listed inside the UI somewhere?

Like an open deal appears in the dashboard of any client? Or and adhoc public dashboard? In any case, we it would be nice to have a way to "show" the open deals!

Ok!

[turinglabsorg]

It make sense to have two different max, one for open deals e one for the standard deals. But notice that as soon as we add the pass system #90 , then I the real max should be the number of passes that a provider accept to give to the client. No?

I agree. But I think that for an open deal we should decide if

• The number of passes holds overall and that's it. Here passes == max appeals
• a SP can "negotiate" in some way different number of passes with different client (maybe it's not possible) up to the total number of passes sums up to its maximum

It can be a parameter in the deal proposal, so it can be negotiated like the price and the collateral

I think the first option is the easier path (and maybe the only one that makes sense with open deals?)

Like an open deal appears in the dashboard of any client? Or and adhoc public dashboard? In any case, we it would be nice to have a way to "show" the open deals!

I like the idea of the open deal dashboard!

Perfect, will start work on that next week with @gdelsi and @Steve-Rog!

[irenegia]

Update (taking notes from the call, please @turinglabsorg double check here)

@nicola proposes to show the express of deals should be visualised in the page of all clients that are in the appeal allow list.

Problem: what is an contente that you don't want shows up in your page?

configurable owner addresses?

or add assignTo field to express deal

[turinglabsorg]

After today's discussion I've another proposal, which is the following:

1) Simplifying naming by calling this new function simply createDeal 2) Add the parameter owner to this function so provider can assign deal to a client 3) Create onchain (and offchain) filters using the timestamp_request value because:

• 3a: A deal can be created using createDealProposal (client) and acceptDealProposal (provider); in this case the deal will have timestamp_request > 0
• 3b: A deal can be created using createDeal (provider); in this case the deal wil have timestamp_request == 0 4) Create a new function called getProposer which returns:
  • 4a: provider if deal is created with createDeal
  • 4b: client if deal is created with createDealProposal + acceptDealProposal

@nicola proposes to show the express of deals should be visualised in the page of all clients that are in the appeal allow list.

Regarding this, can be also done, but in the case we use a contract (like we're planning to do) we have to add these deals to all dashboards in any case so maybe I would create an entire new page to show those deals.

@irenegia @nicola @lucaniz what are your thoughts?