(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.
jbenet commentedJan 13, 2016
(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: