Add docs, correct URL

docs/infrastructure/coordinator.md

@@ -0,0 +1,19 @@
+---
+title: Coordinator
+layout: default
+nav_order: 3
+parent: Infrastructure
+---
+
+The coordinator is a local service which communicates with other validators'
+coordinators. It provides a verifiable broadcast layer for various consensus
+messages, such as agreement on external blockchains, key generation and signing
+protocols, and the latest Serai block.
+
+The verifiable broadcast layer is implemented via a blockchain, referred to as a
+Tributary, which is agreed upon using Tendermint consensus. This consensus is
+not as offered by Tendermint Core/CometBFT, as used in the Cosmos SDK
+(historically/presently), yet by our own implementation designed to be used as a
+library and not as another daemon. Tributaries are ephemeral, only used by the
+current validators, and deleted upon the next epoch. All of the results from it
+are verifiable via the external network and the Serai blockchain alone.

docs/infrastructure/index.md

@@ -0,0 +1,6 @@
+---
+title: Infrastructure
+layout: default
+nav_order: 5
+has_children: true
+---

docs/infrastructure/message_queue.md

@@ -0,0 +1,25 @@
+---
+title: Message Queue
+layout: default
+nav_order: 1
+parent: Infrastructure
+---
+
+The Message Queue is a microservice to authenticate and relay messages between
+services. It offers just three functions:
+
+1) Queue a message.
+2) Receive the next message.
+3) Acknowledge a message, removing it from the queue.
+
+This ensures messages are delivered between services, with their order
+preserved. This also ensures that if a service reboots while handling a message,
+it'll still handle the message once rebooted (and the message will not be lost).
+
+The Message Queue also aims to offer increased liveliness and performance.
+If services directly communicated, the rate at which one service could operate
+would always be bottlenecked by the service it communicates with. If the
+receiving service ever went offline, the sending service wouldn't be able to
+deliver messages until the receiver came back online, halting its own work. By
+defining a dedicated microservice, with a lack of complex logic, it's much less
+likely to go offline or suffer from degraded performance.

docs/infrastructure/processor.md

@@ -0,0 +1,19 @@
+---
+title: Processor
+layout: default
+nav_order: 2
+parent: Infrastructure
+---
+
+The processor performs several important tasks with regards to the external
+network. Each of them are documented in the following sections.
+
+# Key Generation
+
+# Scanning
+
+# Signing Batches
+
+# Planning Transactions
+
+# Cosigning

docs/infrastructure/serai.md

@@ -0,0 +1,6 @@
+---
+title: Serai
+layout: default
+nav_order: 4
+parent: Infrastructure
+---