Revise semantics of out of band deal data transfer

[masih]

Boost "transfer params" is the primitive used to convey information about how a CAR is transferred from ISV to an SP as part of deal execution. This primitive is only permitted for online deals. For offline (also referred to as out of band ) deals no such standardisation exists.

One of the key objectives of Project Motion is to make it straightforward for ISVs to handle deal lifecycle end-to-end. Therefore, lack of standardised interfaces for out of band data transfer poses a challenge on how to encapsulate complexity for the ISVs. Further, out of band deals are the preferred method of deal making/data transfer for the SPs. Because, it gives them full control over their data ingestion flow in order to increase efficiency.

For the purposes of MVP, a documentation-only approach seems to suffice, where some human intervention is needed to then facilitate out of band data transfer. For example:

• There will be a configurable directory in which CAR files are written, named by their piece CID.
• It is the responsibility of the ISV to set up transfer of CAR files from that directory for the SPs.
  • e.g. set up nginx static content server with some credentials that are pre-communicated to the SPs.
• Once the deal appears on chain as published, Motion would delete the file from the directory.

[LaurenSpiegel]

Can we go a step beyond documentation and actually include this setup in the automated deployment for motion?

[angelo-schalley-p]

I agree with @LaurenSpiegel this should be included.

[masih]

Changing the label to m3.0 since milestone assignment is inconsistent with the label. Let us know if this is needed for M2.0 @celine3650 .

[masih]

@celine3650 this is unlikely to be delivered for Beta considering the timelines and the scope of work which will impact boost.

Product input is needed to determine proirity.

[rvagg]

Being able to configure boost to not trigger a download on receiving transfer params but be able to use it as an informational reference for their own fetch-and-onboard workflow may be a good option here because it provides us, as a client, with the ability to be flexible about the piece URL and not rely on out-of-band communication to set that up (which makes dynamic URLs difficult, e.g. fetch from another SP because I no longer have it locally).

Coupled with a special directory (or some other automatic onboarding once they have the piece) they could build straightforward workflows where they are in control but minimize (and eliminate) human interaction.

They would need to be able to inspect the proposals programatically to get at the transfer params though. Hopefully that's not hard with the GraphQL endpoint.