Discovering data in a DHT is hard because data is spread out over many nodes and can’t be queried.


Create easy-to-find starting points that act as bases for links to other data. Eventually the entire DHT becomes a graph database.


  • Each agent has a built-in anchor: their agent ID entry. They can link to blog articles they’ve written, for example, or friends they know.
  • A hashtag: a simple string that links to all related content.
  • A short ‘ID code’ that can be shared via text messaging, printed materials, email, or other media that would require retyping or copy/pasting. This is a lot easier and less prone to corruption than sharing a full hash.
  • The hash of a known value in another DHT as a sort of ‘foreign key’.
  • A value that is hard-coded into the DNA itself (see Symbol Anchor).
  • A tree of values that link to their parents, allowing users to traverse the entire tree by starting at the root node (see Anchor Tree).


Antipattern : If you expect a given anchor to have a lot of links on it, this could create a ‘hot spot’ in the DHT neighbourhood that stores the anchor: the nodes in that neighbourhood will be responsible for storing all the links and responding to requests for them. Consider breaking up one anchor into multiple anchors (for instance, twenty-six anchors that link to entries starting with “a”, “b”, “c”, etc). This can increase query time but doesn’t usually hurt write time.



1 Like

Thanks @ThomasMiller! This example code is for a particular pattern that allows the app to create a traversable tree of anchors two levels deep, useful for defining an in-app ontology for your data. Especially helpful for when your ontology changes (that is, you introduce new data primitives). Example:

  • Users
    • Alice
    • Bob
    • Charlie
  • Pages
    • Welcome
    • About Us
  • Cities
1 Like