Added blog post template, Fleshed out holochain components.

.gitignore

@@ -1,2 +1,3 @@
 _site/
 .sass-cache/
+_templates/blog_template.md

_projects/holochain.md

@@ -34,23 +34,30 @@ articles:
 In other words, a holochain functions very much **like a blockchain without bottlenecks** when it comes to enforcing validation rules, but is designed to  be fully distributed with each node only needing to hold a small portion of the data instead of everything needing a full copy of a global ledger. This makes it feasible to run blockchain-like applications on devices as lightweight as mobile phones
 
 ## Architecture
-### Functional Domains
+Holochains have three main functional domains, plus whatever UI you provide to access your application. When you build a new holochain application, you need to code all of these systems.
+1. Shared data space setting (holochain identity, DHT settings, etc.)
+2. Data schema, chain entry types with associated application logic and validation rules for the authoring hashchain
+3. Application Layer: This is nucleus of the system which every other part interacts with. Author chains use the app logic and validation rules. DHT nodes use the validation rules to confirm data integrity and provenance before publishing, the UI interfaces with the methods provided here as well.
 
+### Functional Domains
 Holochains, by design, should be used in the context of a group operating by a shared set of agreements. Generally speaking, you don't need a holochain if you are just managing your own data.
 
 These agreements are encoded in the validation rules which are checked before authoring to one's local chain, and are also checked by every DHT node asked to publish the new data.
 
 In essence these ensure holochain participants operate according the same rules. Just like in blockchains, if you collude to break validation rules, you essentially have forked the chain. If you commit things to your chain, or try to publish things which don't comply with the validation rules, the rest of the network/DHT rejects it.
 
-#### Group DNA / Holochain configuration
+#### 1. Group DNA / Holochain configuration
 At this stage, a developer needs to set up the technical configuration of the collective agreements enforced by a holochain. This includes such things as: the holochain name, UUID, address & name spaces, data schemas, validation rules for chain entries and data propagation on the DHT,
 
-#### Individuals Authoring Content
+#### 2. Individuals Authoring Content
 As an individual, you can join a holochain by installing its holochain configuration and configuring your ID, keys, chain, and DHT node in accord with the DNA specs.
 
-#### Application API
+#### 3. Application API
 Holochains function like a database. They don't have much end-user interface, and are primarily used by an application or program to store data. Unless you're a developer building one of these applications, you're not likely interact directly with a holochains. Hopefully, you install an application that does all that for you and the holochain stays nice and invisible enabling the application to store its information in a decentralized manner.
 
+#### 4. Browser-Based UI
+One easy way to provide a UX/UI for people to interact with your Application layer is to have a browser connect via web socket. Our initial Application Engines support JSON data exchange. You can use HTML/CSS/JavaScript for whatever UX you'd like to create.
+
 ### Two Distinct Sub-Systems
 There are two modes to participate in a holochain: as a **chain author**, and as a **DHT node**. We expect most installations will be doing both things and acting as full peers in a P2P data system. However, each could be run in a separate
 container, communicating only by network interface.