CLI for batch CIDs

[0xjona]

Improvement of #12

soon to be discussed ti define design docs

[turinglabsorg]

Going a little bit deeper on that, there's one thing we have discussed yesterday with @irenegia. Since this is not a pinning service, any provider should pin cids outside our CLI. So we should start thinking how providers will really use our service, since there's no actual pinning done by the code.

One idea can be create an endpoint that exports all the CIDs that's supposed to be pinned by the provider.

What do you think @irenegia @nicola?

[irenegia]

So, with adding the

endpoint that exports all the CIDs that's supposed to be pinned by the provider.

now for every deal proposal accepted by a provider our protocol will guarantee that the files corresponding to the CID in the deal are pin (saved) to some IPFS node somewhere. Correct?

I like the idea, with this the name "retrieval pinning" would be the perfect one.
But,

• with this change we will depend on the IPFS pinning service we choose, right? Are we okay with this @nicola?
  Note that we already have this dependency today to create a CID and to retrieve a file...

• Does this require the client always uploading the file? Or can we maintain the flexibility that we have now where deal proposal can also be done just about a CID, without any upload required? In other words, do we keep the possibility of "I can make a deal about a file I don't directly have"?

[turinglabsorg]

now for every deal proposal accepted by a provider our protocol will guarantee that the files corresponding to the CID in the deal are pin (saved) to some IPFS node somewhere. Correct?

I'm not sure it's correct to say "protocol will guarantee", because it's the provider that guarantees by putting some money on the table. The provider guarantees that the file will be publicly available at a specific endpoint (thing we talked about yesterday) and the protocol guarantees that money are returned to the client if provider lies.

So at the end of the day it's the provider that should pin in one (or several) IPFS nodes using the method he prefers, important thing is that the file will be available if referees are invoked by the client.

with this change we will depend on the IPFS pinning service we choose, right? Are we okay with this @nicola?
Note that we already have this dependency today to create a CID and to retrieve a file...

This is likely more an upgrade not a change, we don't need any pinning service at the moment (as protocol).

Does this require the client always uploading the file? Or can we maintain the flexibility that we have now where deal proposal can also be done just about a CID, without any upload required? In other words, do we keep the possibility of "I can make a deal about a file I don't directly have"?

Deals can be written directly on-chain by writing the CID, the upload part it's used to actually calculate the CID. File is not retained in any pinning service. So yes, you can create a deal for a file you don't directly have :-)

[nicola]

Agree with @turinglabsorg

The smart contract does not care how the delivery of the data behind a CID happened.

[turinglabsorg]

@0xjona this can be closed because it's part of the second epic (Provider UX - Software upgrades).

[0xjona]

#67 yes