Analyze migrate away from non-utf8 DealProposal Labels

[jennijuju]

filecoin-project/builtin-actors#69
analyze the lotus & market API changes

[jennijuju]

This currently is out of the ntwk v16 scope, but its possible that we need to consider this cuz proper IPLD and cbor usage in builtin actor

[jennijuju]

EOMarch 9th:

• in actor, we will have a label struct that supports both string and bytes. Then we shall expand the cbor support so it understands both string and bytes during signature validation and such, then store everything on chain in bytes (convert string to label)
  • there will be a state migration over all clientdealproposal (PSD)
• In lotus we may keep the top level API signature the same, and do the conversion in API impl, before it passes to gfm. or both supports both as well. We still need to confirm:
  • the proposed actor approach will break gfm or not
  • how labels are used for retrieval in lotus & gfm

As of today - we figured out a workable solution that won't require a pause in Filecoin storage market (no need to ban PSD or worry about invalid in fly PSD around the upgrade), however, we also haven't quantified the work detailed enough to decide if this should be within the ntwk v16 scope.

To be continued tmr.

[ribasushi]

that supports both string and bytes

that's inaccurate: there can be only one ( type-wise )

The point is that rust-land really wants this to be byte, yet all our public facing APIs have string.

The rest is 👌

[jennijuju]

@magik6k if the label becomes a byte array - what's the impact / how much changes will be needed for retrieval, in lotus & in gfm?

[arajasek]

The analysis is complete, and the prototype implemented. There is more info to come out of conversations, but this issue can be closed.