Create fip-draft_askv2.md #224
Conversation
brendalee
requested review from
arajasek,
dignifiedquire,
jennijuju,
kaitlin-beegle,
momack2 and
whyrusleeping
as code owners
There was a problem hiding this comment.
Following the process discussion in #215, I do not think this proposal is sufficiently fleshed out to warrant a PR yet. Much more should be worked out in the discussion forum or off-Github drafts first.
|
|
||
| ## Change Motivation | ||
| <!--The motivation is critical for FIPs that want to change the Filecoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.--> | ||
| Clients need to be able to share details of the storage deal they want to make. Furthermore, they need to know what capabilities and features a Storage Provider supports, so as to understand what Storage Providers they can successfully make a deal with. |
There was a problem hiding this comment.
Please expand more on the shortcomings of the existing Ask protocol, and what problems this proposal addresses.
There was a problem hiding this comment.
Thanks Alex! With the existing ask protocol, the client does not have a method to share information about their storage deal; rather, only the storage provider can share precondition parameters by which they will choose to accept or reject a deal. Existing StorageAsk
FIPS/fip-draft_askv2.md
Outdated
| - Option for client to specify additional transfer protocols | ||
| - Will have a set of defined protocols, but allow SPs to add more | ||
| * Message freeform text | ||
| * Signature by client |
There was a problem hiding this comment.
It would really help to highlight the deltas from the existing Ask request.
FIPS/fip-draft_askv2.md
Outdated
| * Will accept or reject the deal | ||
| * Rejection code | ||
| - Need clearly defined rejection codes | ||
| - Start with HTTP codes and build from there |
There was a problem hiding this comment.
I don't think HTTP codes are appropriate for re-use here. They're a quite different application domain (mostly about fetching resources).
This FIP should probably specify the codes.
There was a problem hiding this comment.
@anorth - do you have additional suggestions for what error/rejection codes should be as an alternative to HTTP codes? Would be great to get your input/feedback in the discussion.
FIPS/fip-draft_askv2.md
Outdated
| * How long the offer is valid for | ||
| - Expiry time | ||
| - Not binding, just for client convenience | ||
| * Start epoch of deal |
There was a problem hiding this comment.
The client already chose this. Do you mean something like the earliest (or latest) start epoch for a similar deal that the provider would accept?
There was a problem hiding this comment.
Yes, that's correct. An example use case would be if clients want to make multiple deals with the same storage provider, then they would know what timing would be convenient to do dealmaking.
Co-authored-by: Jiaying Wang <42981373+jennijuju@users.noreply.github.com>
Co-authored-by: Jiaying Wang <42981373+jennijuju@users.noreply.github.com>
Co-authored-by: Jiaying Wang <42981373+jennijuju@users.noreply.github.com>
Co-authored-by: Jiaying Wang <42981373+jennijuju@users.noreply.github.com>
|
Closing this PR since an updated version (as an FRC) was just pushed and merged. |
|
@kaitlin-beegle this is not yet covered in boost, but hopefully can be worked on in the near future |
No description provided.