add technology subpages

docs/technology/consensus.md

@@ -0,0 +1,49 @@
+---
+title: consensus
+published: false
+---
+# The Logos Blockchain Network
+The Logos Blockchain Network is a heterogeneous blockchain network, specifically designed to enable communities to have digital infrastructure that is not only appropriate for them, but also owned by them. 
+
+This endeavor is currently under a heavy research phase as we explore the current best practices and possibilities that are under development or available across the industry. 
+
+## Motivation
+
+We find it useful to define a list of use cases that the technology should fulfill.
+
+### Use cases
+
+The main use case of the blockchain network infrastructure is to provide support for bootstrapping and maintaining **Common Interest Communities (CIC)**. CICs have the following key characteristics:
+
+-   We expect the range of network sizes to be wide. We can expect some CICs to be in the scale ~10 nodes, while others could (potentially) scale up to current blockchain limits.
+-   CICs will have varying degrees of inter-communication. Some will be existing in relative isolation (ie. no communication), while others could be very interdependent.
+-   Some CICs will exist as part of the Status Network (_i.e._ the Status Communities product), while others could exist completely independently as a separate infrastructure. In other words, the stark requirement to participate in a central network would be lifted. 
+
+In order to fulfill these use cases, we now define a set of requirements the blockchain technology should conform to.
+
+### Requirements
+
+-   **Must-have.** These requirements are non-negotiable, fundamental to satisfying the use cases.
+    -   **Sybil Resistant.** This is a fundamental requirement of any blockchain design, but we list it here as it is unique in our case. We potentially need to support different models of sybil resistance depending on the scale of the network, and for bootstrapping purposes.
+    -   **Crash & Byzantine Fault Tolerant.** These are fundamental requirements in a public blockchain.
+    -   **Fast Finality (ideally sub-second, or in the 2 sec range).** It is fundamental to the usability of the blockchain, and something within our reach considering the current state of the art (Avalanche).
+    -   **Leaderless / Weak Leadership**. In order to keep the network as decentralized as possible, we aim at mitigating the centralization effects of strong leadership (like leader selection algorithms).
+    -   **Individual participant scale ~ constant with respect to network size.** in similar spirit to the leaderless or weak leadership requirement, we establish the need to allow participants in the network to have the feel impact regardless of the scale of the network. In other words, the resources consumed for any given network decision should not vary in accordance to network size.
+    -   **Suitable for “social applications” (fast and efficient, modest computational resources).** It is key that we steer away from the centralization effects of high computation requirements.
+    -   **Ability to transition from a low node count to a large node count.** This is an important technical requirement in order to fulfill the use cases. The general idea is to be able to support networks from their inception at low scales to their growth and expansion phase.
+    -   **Ability to bootstrap small networks.** Either from scratch or as spin-off of a larger network. Closely related to the previous requirement, this refers to the process of growth from low to high scale networks, in a smooth manner.
+-   **Desirable or to be explored.** These requirements are initially considered as relevant to matching the use cases, but they aren’t required per se.
+    -   **Round-less.** This is usually associated to the lack of a leader election and distinct protocol phases as usually seen in classical BFT variants.
+    -   **Probabilistic.** Not a requirement per se, but a likely condition to achieve substantial improvements over classical BFT. The choice of a probabilistic approach to consensus is key in the Avalanche algorithm to achieve state of the art performance.
+    -   **Strong liveness (at the expense of partition tolerance).** A strongly live system makes progress under network partitioning conditions, and later on reconciles the forks.
+    -   **Asynchronous.** This is also associated with partition tolerance, in the sense that a chain can make progress even if a substantial part of the network is out of reach.
+    -   **Decoupled execution layer (as much as possible).** This is to allow for execution models to be interchangeable and/or extensible.
+    -   Explore the possibility of **highly partitioned blockchains with local views**. This takes inspiration from the Tangle (IOTA) and Hashgraph. The idea would be to explore these key points:
+        -   Could clients participate in consensus as well, in a very lightweight manner, by just synchronizing a small part of the blockchain.
+        -   By the same token, this would bring many partial local chains, perhaps only updated on-demand. Potentially client nodes can do this in a different way than verifier nodes, that hold larger portions of the blockchain.
+
+## Technicals
+
+As we harden our confidence around the various protocols that will come together to meet these requirements, we will update this site. Please check back regularly to learn more about how this network will be built. 
+
+Our intention is to be as rigorous and open as possible. You can read about [our development methodology](./process) to learn how we plan to make good on those intentions. 

docs/technology/overview.md

@@ -0,0 +1,39 @@
+# Logos is building a complete decentralised infrastructure stack - for everyone.
+
+Advancements in cryptography and peer-to-peer networking have unlocked the possibility of re-imagining the public internet infrastructure that we conduct our lives upon. These technologies allow us to drastically increase the cost of surveillance, censorship and coercion as a means of safeguarding our freedoms.
+
+The experiment begins with a decentralised autonomous organisation (DAO) dedicated to the construction of its user-owned, self-sovereign crypto network. The network is comprised of three primary modular peer-to-peer protocols for communication, file storage and trustless agreement.
+
+Together, these form the foundation required for the next-generation of voluntary governing services and social institutions to emerge.
+
+![overview](/subpages/logos-overview-graphic.jpg)
+
+**Logos** - *The trustless agreements layer*. 
+
+The first primary protocol of Logos is Logos Blockchain: a heterogeneous blockchain network utilizing its own consensus algorithm to provide fast, scalable and secure trustless agreement, with near-instant transaction finality in user-defined execution environments.
+
+The first two client implementations will be written in Nim and Rust once our first specification has been published.
+
+**Waku** - *The ephemeral communication layer.*
+
+Waku is a peer-to-peer communication layer. Waku removes centralized third parties from messaging - enabling private, secure, censorship-resistant communication. Waku is designed for generalized messaging, enabling both human-to-human or machine-to-machine communication.
+
+Waku has its origins in Ethereum’s Whisper protocol, but is optimized for scalability and better usability. Waku is in production and is actively being used by projects like [Status](https://status.im/) and [WalletConnect](https://walletconnect.com/). Waku’s economic spam protection is still under research, and a paper published on the topic can be found [here](https://raw.githubusercontent.com/vacp2p/research/master/rln-research/Waku_RLN_Relay.pdf).
+
+[[Current Specification]](https://rfc.vac.dev/spec/6/) [[Research Forum]](https://forum.vac.dev/) [[Github]](https://github.com/vacp2p/)
+
+**Codex** - *The storage layer.* 
+
+Codex is a decentralised storage protocol for durable information. Whilst p2p storage networks have been around for quite a long time, the lack of incentives, strong data availability, and durability guarantees make these networks unsuitable for a wide array of applications. In other words, without durability at the storage layer, it is impossible to build other reliable applications.
+
+Codex aims to solve this by supplying an incentivized p2p storage network with strong availability and durability guarantees, and a resource restricted friendly protocol that can endure higher levels of churn and large amounts of ephemeral devices. Codex has a working Proof-of-Concept.
+
+[[Github]](https://github.com/status-im/codex-research) [[PoC] ](https://github.com/status-im/nim-codex)
+
+---
+
+## Our Development Process
+
+We are creating this technology stack out in the open, as a public good. Check out our [process](https://logos.co/technology/process) section to learn more about how we are going about this. 
+
+Logos is not yet production ready across every protocol in its stack. A number of research and engineering problems remain. We have no illusions as to the magnitude of the undertaking, and the work that lies ahead of us. We would like to invite anyone who is serious about contributing research or code to join us (we will be adding information on how to do this soon).

docs/technology/process.md

@@ -0,0 +1,41 @@
+# Our Process
+
+We build public good protocols for everyone, then implement them the way that works for us.
+
+Public goods are for the people, and thus should be owned and controlled by them. How they are built influences this outcome. To this end, we have come up with a process that helps to ensure that the products of our effort are not solely controlled by us and our potentially limited self-interests and opinions. 
+
+In a nutshell, Logos projects will work hand-in-hand with our sister research organization, Vac, to create agnostic protocols for everyone to share and contribute to. You can read more about Vac and their mission [here](https://vac.dev). 
+
+The general flow of how a given project within Logos collaborates with Vac is summarized in the following diagram. 
+
+```mermaid
+flowchart
+    O1[Unopinionated Protocols]
+    O2[Users]
+    subgraph Project
+    L1[Engineering]-->|Delivers|L2[Opinionated Products]
+    L3[Research]-->|Delivers|L4[PoC Implementation]
+    end
+
+    subgraph Vac 
+    V1[Principles]-->|Aligns|V2[Agnostic Specifications]
+    V3[Protocol Development Process]-->|Structures|V2
+    click V3 "https://rfc.vac.dev" "Specifications"
+    click V1 "https://status.im/about/" "Principles"
+    end
+    
+    L3-->|Delivers|V2
+    V2-->|Informs|L1
+    V2-->|Allow for|O1
+    L2-->|Serves|O2
+    O2-->|Provides user feedback to|L1
+    L1-->|Updates|V2
+```
+
+A Logos project will perform research on a problem. Their initial deliverables will be a Proof of Concept (PoC) and a set of specifications that detail explicitely how that solution is built. Vac will provide resources to the Logos project by facilitating in the process writing and hardening the specifications being developed. 
+
+In addition to helping in the process of spec writing, they also serve as an embodiment of the foundational principles that maintain the ethical development of public good infrastructure. This means that specifications written, developed, and housed with Vac are not tied to any given chain, biased ideology, and the subsequent control that comes from it. These specifications can then be used by the general public in any way they see fit, free and open source. 
+
+The Logos project will then pull back an opinionated view of these specifications to implement their vision of how the product should be built for their particular use case. 
+
+This process is our commitment to build in the open and work to maintain an ethos of building for the public good while also allowing ourselves to create opinionated products that suit our specific needs.