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
I was told the standard way to write an app (like ipfspics, coopcache) on ipfs includes running its own separate daemon. But if several daemons pin the same thing, memory usage unnecessarily duplicates (right?). OTOH if an app uses the 5001 port API instead, there's no guarantee that the things the app pinned will stay pinned: other apps or the user can manually unpin them, unaware of implications to apps that may rely on those blocks.
A potential solution is to identify apps when they connect to the API, then make the effects of API calls like "pin add" and "pin rm" independent between apps as well as the manual "ipfs pin add" and "ipfs pin rm" commands. I.e. the block would be stored as long as at least one app pins it. As a bonus, uninstalling ipfs apps would become cleaner - they'd be able to free all their pins.
The text was updated successfully, but these errors were encountered:
I was told the standard way to write an app (like ipfspics, coopcache) on ipfs includes running its own separate daemon. But if several daemons pin the same thing, memory usage unnecessarily duplicates (right?). OTOH if an app uses the 5001 port API instead, there's no guarantee that the things the app pinned will stay pinned: other apps or the user can manually unpin them, unaware of implications to apps that may rely on those blocks.
A potential solution is to identify apps when they connect to the API, then make the effects of API calls like "pin add" and "pin rm" independent between apps as well as the manual "ipfs pin add" and "ipfs pin rm" commands. I.e. the block would be stored as long as at least one app pins it. As a bonus, uninstalling ipfs apps would become cleaner - they'd be able to free all their pins.
The text was updated successfully, but these errors were encountered: