feat: Create links from/to ExternalHash

[c12i]

Closes #254
Closes #389

[matthme]

I noticed that the [None] option provided by get_or_choose_optional_reference does not make sense to me (I see that this was already there before this PR). Here, why would a link only optionally point to a target? The actual behavior now when a link-type is scaffolded with target [None] is that the target is the same as the base which seems not useful in any real case I can think of. It seems to me that for link-types, both base and target should always be non-optional.

And as another remark, I think it might be worth adding ExternalHash as an explicit option as well. AnyLinkable hash is the more generic type which entails ActionHash, EntryHash and ExternalHash but sometimes it might be desirable to be explicit that one wants to point to an ExternalHash.

[matthme]

It might even make sense to replace AnyLinkableHash with ExternalHash since if all ActionHash, EntryHash, AgentPubKey and ExternalHash are available as options then AnyLinkableHash is covered implicitly as well.

[matthme]

It might even make sense to replace AnyLinkableHash with ExternalHash

I'm not sure though...maybe there are cases where this flexibility is desired, i.e. that you'd want to allow for a link that can point to either of these types and is not hard-coded. So keeping AnyLinkableHash as an option as well (alongside ExternalHash and the others) might not hurt.

[c12i]

I noticed that the [None] option provided by get_or_choose_optional_reference does not make sense to me (I see that this was already there before this PR)

Yes this [None] option has always existed, it's exact usecase is actually not documented, perhaps @guillemcordoba can shed some light. Decided to keep it to not potentially break anything that might depend on it.

why would a link only optionally point to a target?

From my understanding of the previous code, I think the term optional doesn't really communicate the purpose correctly. I see that the optional check just adds more options to the default list of all entries that can have links created to it. The difference between get_or_choose_referenceable and get_or_choose_optional_reference_type fundamentally ends up being that the latter contains extra options i.e None and ExternalHash that are not provided by get_or_choose_referenceable to make sure that these two options are only assignable to the "to referenceable"

[c12i]

It might even make sense to replace AnyLinkableHash with ExternalHash since if all ActionHash, EntryHash, AgentPubKey and ExternalHash are available as options then AnyLinkableHash is covered implicitly as well.

I was actually torn between these, but it makes sense to be explicit in this case.

[guillemcordoba]

The [None] option is to be able to support "metadata" only links. In holochain, the only way to attach a small piece of extra information to a hash is creating a link from that hash and add the information as the tag. In this case the target is actually irrelevant, because the only point of the link is to attach is link tag to the hash. This is the use case I wanted to support with the None option.

You might argue that this use case could be done by targeting any other entry hash. But then the scaffolding tool would scaffold validation to make sure that the target entry exists, which is not what I want if I only want to attach metadata to that hash.

Hope this helps!

[matthme]

Oh interesting, yes this helps. Maybe this could be described a bit more clearly in the option then. Something like [None] (use this link to attach meta-data only) or something.

[matthme]

I think it looks good to me know. I did notice some things that I think should be addressed at some point but they can be addressed independently of this PR:

• if you create a link type, the file name and function names have the target link in plural (I think this is because it uses the same naming logic as for collections where an anchor points to multiple entries). For example validate_create_link_book_to_pages instead of validate_create_link_book_to_page

• There is a general problem it seems that files can get overwritten in case of name collisions. This can happen most easily with meta-data-only links whose file names are single word names, e.g. book.rs if the link type is named book. So in this case it would overwrite an existing book.rs file from a scaffolded book entry-type. Or the other way around, whichever is scaffolded first.

[c12i]

Yes, I noticed an issue with the naming, will address it separately