You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: