# Holochain overview

### One app
_image from presentation by @RebeccaRachmany_

In the second part of this, l’ll use the example of the twitter clone. Mostly because it’s way simple, but also because there is was a working codebase for it around 6 months ago for people to look at.

In the first image, what we see there is how an app is based on the published entries that when they are created go first into what is called the source chain on the device and then onto the shared DHT.

* Every dot on the wheel is a user/player/agent
* Every agent has a source chain for each application
* Every source chain starts with a hash of the complete backend source code, called the DNA.
* it’s a published hash of the entire backend codebase, datastructures, functions, validations etc, this is also how we know that every actor is using the same codebase, if any bit of the code is changed, the resulting hash changes and the application is now in it’s own space and doesn’t share the same DHT
* following the DNA are entries, entries are all of the data that can be stored for an application
* the first entry of an application is the public key of the agent (user/device)
* entries can contain all sorts of data, the format of an entry, the structure or struct, is defined in each application
* all entries contain a header the H-part and an entry the E part
* headers contain the hash of the last header so that one cannot go back and change anything in the source chain without somebody noticing that the hashes have changed
* all headers are shared to the DHT even if the header points to an entry that is private, that means that the entry is not shared but peers can still validate that you have not altered your source chain
* in the structure of the entry you can set it to public (share this to the DHT) or private (don’t share this to the DHT)
* entries can not be edited or deleted but there is metadata on the header which can be updated to indicate that the entry is “modified”, this means that the entry now points to a new entry where the updated info is located
* entry headers can also indicate deleted, which basically just says do not retrieve this when getting entries in some query
* in order to relate data to each other so that we can use it a special type of entry called a link is used, I link basically just contains a base for the relationship (from) which is an entry hash, to a target (to) which is another entry hash a possibility to name the relationship between them (belongs_to, has_posted, of_genre, etc)

Here’s the flow of an application, and I will use twitter as the worn out simple use case example:

1. app starts
2. DNA hash is published to source chain
3. Agent ID (public key) is published to the source chain
4. user creates profile
5. username and photo is stored as the second entry (a profile type entry)
6. a link entry is also created that links from a static entry (called an anchor) “all_users” to the User ID (the public key of the user. This is done so that other people are able to find the user, there is no way to discover things in the DHT unless you have a starting point!
7. the profile entry is shared to the DHT and the link entry is also shared to the DHT
8. user tweets “hello”
9. “hello” is stored as the fourth entry (a “post” type entry
10. two link entries are also created: a link from the agent ID hash to the post entry hash, a link from the post entry hash to the agent ID hash. the reason for two is that each link only connects one way, sometimes we want to get the user from the post, sometimes we want to get the post from the user
11. the the post entry is shared to the DHT and so are the other two link entries

### Apps together
_image from developer docs, [core concepts](https://developer.holochain.org/docs/concepts/2_application_architecture/)_

* Holochain has a strong decoupling of the front and the backend. Any UI, script or other application (even an SSB one?) can call for data from any running HC app
* All of the backend code is packed and hashed into what is called a DNA, within the DNA the code is structured in one or more “zomes”, basically using the idea of a chromosome as a subsection of the cell DNA.
* A zome will contain the entry definitions, validation logic and functions that enable the UI to send a request and recieve data back.
* Multiple applications can send data to each other or to the UI where it can be stiched into a coherent user experience
* an app sometimes is a mix of several application back-ends, which are all their own network, but are both needed for the user to interact. These might then be bundled to be installed together. In another setting a user might just want one part of the application. An example of this would be if there is one application that is an image sharing service like google photo, and the other is a social network like twitter. The twitter may want to use the image service as storage and read the files from there. While saving the links to those files in the twitter app. The UI can request from both apps.
* the conductor is the service that knows what applications are running and that will direct incoming websocket requests to the right application (as well as requests/posts that just happen directly between applications)