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

Revisit blob/allocate receipt "size" #23

Open
alanshaw opened this issue Nov 8, 2024 · 1 comment
Open

Revisit blob/allocate receipt "size" #23

alanshaw opened this issue Nov 8, 2024 · 1 comment

Comments

@alanshaw
Copy link
Member

alanshaw commented Nov 8, 2024

Currently the size value reflects whether the blob has been allocated in the space on the current node - a hangover from when there was only one node in the network.

Do we need to come to consensus in the network about whether a blob has been allocated in a space or is there a better way to do this?

Note that currently the upload service tracks this accurately but the allocation receipt is used for billing.

@volmedo
Copy link
Member

volmedo commented Nov 8, 2024

the indexing-service could be used as the source of truth of what spaces a blob is allocated in by adding that information to the blob's index metadata.

I'm assuming we ever only want to store a single copy of any given CID in the network to make the most efficient use of the contributed storage space (we already think of using replication in Filecoin to provide durability guarantees; we could also trade space for performance by storing different geographically distributed copies, but that's another discussion).

the indexing-service could be that point of coordination for the network no matter what storing strategy we decide to implement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants