-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Check: Requesting storage for already-encoded CID #1005
Comments
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). |
I'm convinced the root of this issue is: |
This isn't going to be a problem once encryption is added, every persistent dataset will be unique. |
Just to expand on this. We should not re-encode an already protected CID, the user should make a request for the original dataset if it requires different parameters. So, requesting storage for a protected CID should be an error. |
I would like to refine this:
|
Agree with Ben here - it make sense to me. |
When I request storage for a basic (unprotected) CID:
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.
The text was updated successfully, but these errors were encountered: