Problem
Some applications benefit from global registries of things, such as music genres, usernames, or discussion topics. But you can’t query an entire DHT for this data, because data is spread across many nodes.
Solution
Define a special anchor entry type for each set that the DNA needs to know about and query, e.g., an entry of type usernames_anchor and another of type discussion_topics. Only one entry of each type can be created. You can enforce this by specifying that the content for these types should be empty — entry hashes are based on the entry type plus the content. Because the DHT stores data by its hash, no matter how many people create and publish these root anchor entries, only one of each type will exist on the DHT.
Define a link type connecting this anchor type to the entry type it corresponds to; e.g., a registered_username link type from usernames_anchor to username.
Once you’ve defined a type for each anchor, you need to create an actual entry for it. This can happen in the init function, or it can happen ‘lazily’ the first time someone needs to use it.
Once the anchor has been created, users can start publishing links from it to the entries they create. When someone needs to query all entries of a certain type, they calculate the hash of the anchor type and ask it for its links.
Warnings
- The same warning about DHT hot spots in Anchor applies to this and all other types of anchor.
- This pattern should only be used in cases where your app knows about the ‘buckets’ of globally queryable data in advance. If your ontology is undefined and needs to grow over time, use Anchor Tree instead.
- Currently Holochain doesn’t enforce any per-zome encapsulation of entry types. That means that two zomes might accidentally create a symbol anchor of the same type and create a collision. Consider namespacing your anchor types with the zome name to prevent this.