If I read the code correctly, dht only remembers the time when the local node received the object. For use cases typical for enterprises (which may imply a private network), like data archiving and expiry, it is required that there is a concept of object creation time at the network level. While some use cases can get away with pinning to a local node (who is interested in keeping the object around), some other use cases which involve moving data between nodes (e.g. archiving and later recovering from the archive) cannot.
The text was updated successfully, but these errors were encountered:
Hi @RichardLitt , I have a requirement to expire data (and move to archive) after some time to live (TTL). TTL is likely to be global, but could also be per item. Storage is private to an organization, it is decentralized across geographic locations, hence IPFS could be a good fit. I see that IPFS records the time when data is stored locally, and uses it to remove data if it is not pinned. For my use case I need to store somewhere the time when data was originally created, or when they will expire. Would it make sense to extend IPFS DHT to store this information, or do you think this should be handled at the application level (in data itself)? In the latter case, there would be obviously a bit performance penalty as the archiving process would need to fetch and inspect data to figure out if it is the time to move it to archive.
alikic commentedJun 5, 2016
If I read the code correctly, dht only remembers the time when the local node received the object. For use cases typical for enterprises (which may imply a private network), like data archiving and expiry, it is required that there is a concept of object creation time at the network level. While some use cases can get away with pinning to a local node (who is interested in keeping the object around), some other use cases which involve moving data between nodes (e.g. archiving and later recovering from the archive) cannot.
The text was updated successfully, but these errors were encountered: