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

[Feature Request]: Simplify blob.Submit API #4058

Open
cmwaters opened this issue Jan 22, 2025 · 1 comment
Open

[Feature Request]: Simplify blob.Submit API #4058

cmwaters opened this issue Jan 22, 2025 · 1 comment
Labels
enhancement New feature or request external Issues created by non node team members

Comments

@cmwaters
Copy link
Contributor

Implementation ideas

A few minor ideas to simplify blob submission for users:

The api.Blob type (different to internal representations) should consist of just the Namespace and Data

ShareVersion should be an option that is default v0. If the user sets it to v1, the signer should automatically be populated. The user shouldn't need to do that. NOTE: By including it in the options rather than the blob, it implies we don't support multiple blobs in the same transaction with different share versions.

Commitment shouldn't be a part of the input. It should be internally computed and returned to the user. Alternatively the user could also compute it themselves.

@walldiss perhaps we can consider some of these ideas for the gRPC API

@cmwaters cmwaters added the enhancement New feature or request label Jan 22, 2025
@github-actions github-actions bot added the external Issues created by non node team members label Jan 22, 2025
@vgonkivs
Copy link
Member

vgonkivs commented Jan 24, 2025

canonical-api PR already had such method for submitting the data. Also, what happens if the user wants to submit blobs with different namespaces in a single transaction? if it fails then it does not make sense to keep SubmitBlobs(initially I thought it was possible to submit blobs with different namespaces).

ShareVersion should be an option that is default v0. If the user sets it to v1, the signer should automatically be populated

For now, we can differentiate versions by checking the signer(that is already an option in the config).

Commitment shouldn't be a part of the input.

Do you mean output? if yes, then we wanted to avoid any additional actions from the user to get the commitment as it could add complexity for the user. After submitting the blob, the user gets the response with the height and the commitment, so he can easily request the blob to e.g. get its index.

Alternatively the user could also compute it themselves.

It requires the user to find a proper method(or implement it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request external Issues created by non node team members
Projects
None yet
Development

No branches or pull requests

2 participants