Skip to content
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

Open
benbierens opened this issue Nov 27, 2024 · 6 comments
Open

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

benbierens opened this issue Nov 27, 2024 · 6 comments
Labels
bug Something isn't working Client See https://miro.com/app/board/uXjVNZ03E-c=/ for details

Comments

@benbierens
Copy link
Contributor

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.

@benbierens benbierens added bug Something isn't working Client See https://miro.com/app/board/uXjVNZ03E-c=/ for details labels Nov 27, 2024
@gmega
Copy link
Member

gmega commented Nov 27, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor

dryajov commented Nov 27, 2024

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

@dryajov
Copy link
Contributor

dryajov commented Dec 2, 2024

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.

@benbierens
Copy link
Contributor Author

I would like to refine this:
Requesting encoding for an already-encoded dataset should be an error.
Requesting a storage contract for an encoded dataset should be possible, so users can extend/renew their contracts.
If you agree, then I'd like to make two engineering tasks out of this:

  1. Error when trying to encode already-encoded datasets.
  2. Some (API?) changes that allow creating a storage contract for encoded datasets.

@AuHau
Copy link
Member

AuHau commented Dec 4, 2024

Agree with Ben here - it make sense to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Client See https://miro.com/app/board/uXjVNZ03E-c=/ for details
Projects
None yet
Development

No branches or pull requests

4 participants