deal making FRC added #693
Conversation
aashidham
requested review from
momack2,
arajasek,
jennijuju,
kaitlin-beegle,
anorth and
raulk
as code owners
|
@aashidham would you like to present this FRC at our next Core Devs Call? Might be a good place to gather initial feedback and comments. |
Absolutely! I'll follow up on Slack. |
|
Following up on this -- what is pending before approval can be granted? Started a discussion for this PR to solicit more feedback: #721 |
|
Hi @aashidham there is no "approval" as such as all FRCs at the moment remain as open drafts. However, if you like, I can share this widely and solicit feedback and engagement for you. Let me know thanks. |
|
That would be great @luckyparadise thanks! |
Reviewed for language and completeness. No substantial changes to the content or intent of the PR.
FRCs/frc-nnnn-deal-making.md
Outdated
|
|
||
| A valid client contract implementation would minimally support either the `OneToOneDealProposer` or `WildcardDealProposer` interface. Both of these inherit the `BaseDealProposer` interface. | ||
|
|
||
| In particular, the `OneToOneDealProposer` interface is for client contracts that have specified a single Boost SP for every deal proposal. Developers implementing this interface will likely have to reach out and coordinate with Boost SPs specified for a particular deal. Boost SPs with address `x` can then listen to `OneToOneDealProposalCreate` events with the provider field set to `x`. This flow is tremendously simplified, since it only deals with one client contract and one Boost SP per deal proposal. |
There was a problem hiding this comment.
I don't think reference to "Boost" belongs in this FRC. Boost is just one implementation of deal-making.
There was a problem hiding this comment.
I largely agree -- however there are some references to Boost that are useful for context. Have a look at the latest draft.
| uint64 extra_params_version; | ||
| ExtraParamsV1 extra_params; |
There was a problem hiding this comment.
I think the idea here is to have the version of the params (currently we have only one version, namely ExtraParamsV1) in the extra_params_version field, and for the extra_params to be generic, such as bytes, and not of specific type as it is defined now.
The way it is defined now make the parameter extra_params_version redundant, no?
| uint64 extra_params_version; | ||
| ExtraParamsV1 extra_params; |
There was a problem hiding this comment.
Same comment here - https://github.com/filecoin-project/FIPs/pull/693/files#r1277406267
|
@kaitlin-beegle can you merge this PR and assign the FRC number? |
@luckyparadise yes, but please follow up @aashidham next week and make sure they are able to follow up @nonsense's feedback. |
No description provided.