[BUG] Check: Requesting storage for already-encoded CID

[benbierens]

When I request storage for a basic (unprotected) CID:

• Apply erasure codes
• Build slots, trees, get verification hashes
• Post contract on chain

What is the expected flow when I request storage for an already-encoded (protected) CID? Should it be double-encoded? Should it be used as-is? What if the new EC params are different? Should it be decoded and re-encoded?

Quick look at current implementation: double-encoding.

[gmega]

I don't think I see a use case where it'd make sense to request storage for an already-encoded CID, unless you're trying to "renew" an old storage request or extend a current one, in which case I'd argue you should not be allowed to change EC parameters, or any parameters, and should probably have a way to communicate via API that this is what you want to do (renew/extend).

[benbierens]

I'm convinced the root of this issue is: our current API call to request storage is in fact encode-this-dataset-and-request-storage. If we had a call to encode/decode separately, and we could request storage separately (returning an error when called on unencoded datasets) then there would be no problem.

[dryajov]

This isn't going to be a problem once encryption is added, every persistent dataset will be unique.