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
{{ message }}
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.
(old idea. document cause i cannot find it elsewhere) pins on ipns names would pin the name and it's target. So re-targetting the name would orphan the previous content, for gc to free.
eg:
ipfs pin add [-r] /ipns/$name# at this point, $name is pinned recursively. but say it points to nothing.
ipfs name publish /ipns/$name /ipfs/$content1# /ipfs/$content1 is pinned indirectly
ipfs name publish /ipns/$name /ipfs/$content2# /ipfs/$content2 is pinned indirectly# /ipfs/$content1 is no longer pinned indirectly
ipfs repo gc
# /ipfs/$content1 is freed
The text was updated successfully, but these errors were encountered:
@jbenet thoughts on having a 'link' type object in unixfs that would reference an ipns entry, but also cache the resolved value until an explicit 're-resolve' is called?
i realize without my thought process that might seem off topic. I'm thinking that we could link to ipns entries within a unixfs directory, and use that for pinning. You could then 'update' the pin explicitly, which would update the cached value, and change the dag
yeah i imagine we will have to do ipns links within ipfs objects eventually. part of why i pushed for links to be proper full links (with the scheme).
and yes we likely can make ipns links be stored with a resolution at a given time. so a somewhat merkelized property still holds-- when the resolution changes, it still bubbles to the top changing the root.
(old idea. document cause i cannot find it elsewhere) pins on ipns names would pin the name and it's target. So re-targetting the name would orphan the previous content, for gc to free.
eg:
The text was updated successfully, but these errors were encountered: