Archived Text

This file contains draft text created for other wiki pages, but not currently incorporated.

Holon References

The need to express references to another object arises in multiple guises within the MAP. One example is Shared Property Descriptors. If they are to be shared, they need to be separately stored (i.e., as Holons) and referenced from multiple HolonDescriptor properties.

How should we represent such references? Is anything beyond ActionHash required? Do HolonReferences need to be a persistent EntryType (in the MAP Holons zome) or are they just in-memory data structures?

Reference as ActionHash:

The simplest way may be with a HolonReference type that simply contains the ActionHash for the latest action performed on the desired PropertyDescriptor holon.

pub struct HolonReference {
     id: ActionHash,
}

But ActionHash is only intelligible as an identifier within a DHT. So if a reference is simply an EntryHash, we can only reference types defined in the same DHT as the referrer.

Reference as Id + NameSpaceId

pub struct HolonReference {
     id: EntryHash,
     namespace: NamespaceId,
}

The NamespaceId could, perhaps by the applicationId of the DHT containing the desired property descriptor. But this just pushes the issue one level higher. How are NamespaceId's resolved? In other words, what namespace contains the directory of NamespaceIds? TODO: need to resolve this.

References to Foreign (non-holochain) Objects

The concept of Namespace could be generalized to allow references to objects not stored in holochain (i.e., with no concept of ActionHash or EntryHash). For example, in the semantic web, objects are referenced via URI.

While the ability to reference foreign objects will no doubt be required, generalizing the MAP Object Reference Model feels a step too far. Holochain offers many affordances on its entries, including built-in ways to resolve these ActionHashes and EntryHashes. References to such foreign objects can perhaps better be handled via a separate ExternalReference type. than by (over-)generalizing the MAP Object Reference Model.

Versioned References

ActionHash is the identity that corresponds to a specific version of an entry. What if new versions have been created? Might we want to update the reference to refer to a new version of this entry? Must this decision always be mediated by human intervention, or are there circumstances where we might want to automatically update the reference to a new version. This could specified via a version update policy.

It may make sense to store the EntryId as part of the HolonReference type and also way to specify the update policy. For now we can make the version update policy a simple enum.

pub struct HolonReference {
     id: EntryHash,
     namespace: NamespaceId,
     tid: ActionHash, // the ActionHash of the original version of this Type 
     version_update_policy: VersionUpdatePolicy,
}

pub enum VersionUpdatePolicy {
     Manual,
     AutoUpdate_Non_Breaking,
}

Typed References

Since all independent objects are stored as holons in the MAP, the generic HolonReference type defined above can suffice to refer to any type of object. This is very simple and flexible, but could lead to various kinds of errors. For example, when referring to a shared PropertyDescriptor via HolonReference, what if the type of the referenced holon is not PropertyDescriptor. These problems are similar to the issues encountered with dynamically typed vs. statically type programming languages. The advantage of statically types languages is that they can detect errors of this type at compile time vs. run-time. However, given the dynamic nature of the MAP, compile-time checking is not really an option. We_could_ define typed references and then check for type compatibility upon assignment by retrieving the referenced object and comparing its type, but this adds complexity and overhead to the updating transaction. A better option may be to defer such checking to validation functions. This approach favors the optimistic assumption that most of the time, the correct assignment happens.

Thus... for now, we will adopt the approach of just defining a single generic HolonReference type with type checking deferred to validation functions.