[Enhancement] `must_get_link()` (singular) about holochain

[guillemcordoba]

Mmm is this really deterministic? When you do execute the same create_link twice, that's two links that now exist in the DHT, not just one. How is must_get_link going to differentiate between the two actions that created the two links?

[mattyg]

Mmm is this really deterministic? When you do execute the same create_link twice, that's two links that now exist in the DHT, not just one. How is must_get_link going to differentiate between the two actions that created the two links?

Yeah that's what I thought as well but @maackle said it wouldn't be a problem? I'm not clear on why. I originally brought it up thinking that we needed to make links entries again for this to be possible.

[maackle]

I was originally thinking this would be analogous to must_get_entry, which we already have. The idea there is that we just want to ensure an entry was created by some agent, no matter who. However, I'm wondering if that's even a good idea, since entries can be deleted, and I'm not sure what our long term plans are for garbage collection of dead entries.

This must_get_link concept is actually a little bit different still from must_get_entry. must_get_entry for a dead entry could still be useful if you need to see the content of an entry at a given hash. You could never know for sure if it's currently "live" or not, but you can ensure that the hash corresponds to some certain content. However with must_get_link, at least in the use case @mattyg was suggesting, you would typically be constructing a link from known content, meaning there's no need to verify that some particular content is at a certain hash, because you would already have the content available already. It seems that the intention of must_get_link is to check that a link is "live" (not deleted), but we can't do this deterministically. The only thing it could possibly check is that a link with that content was ever created, which is maybe not so useful.

The "liveness" of links and entries is not determinable in validation.

[mattyg]

thanks for clarifying that

The only thing it could possibly check is that a link with that content was ever created, which is maybe not so useful.

I think that's actually fine for my use case because the links I want to must_get are previous components of a path used as an index. Given the constraint I think it's okay for the index links to not be deletable, while the leafs links can be deleted.

The "liveness" of links and entries is not determinable in validation.

I'm assume with metadata hardening this becomes possible?

[maackle]

Given the constraint I think it's okay for the index links to not be deletable

I see how that works for your case since those links will never be deleted, it comes with a caveat for any delible links though.

I'm assume with metadata hardening this becomes possible?

The liveness right now will never be determinable (since it hasn't had time to harden), but yes liveness at some time in the past can be with hardened metadata if all goes well

[github-actions]

This item has been open for 30 days with no activity.

[github-actions]

This item has been open for 30 days with no activity.

[github-actions]

This item has been open for 30 days with no activity.

[github-actions]

This item has been open for 30 days with no activity.

[github-actions]

This item has been open for 30 days with no activity.

[github-actions]

This item has been inactive for 14 days since being marked as stale.