content: Update overview to list some features

1 files changed, 64 insertions, 24 deletions

diff --git a/content/en/docs/Overview/_index.md b/content/en/docs/Overview/_index.md
index b5faa45..1c9f957 100644
--- a/content/en/docs/Overview/_index.md
+++ b/content/en/docs/Overview/_index.md
@@ -11,39 +11,79 @@ description: >
 Under construction.
 {{% /pageinfo %}}
 
-Ouroboros is a (prototype) **distributed system** for packet network
-communications. It consists of a C **library** that allows you
-to write ouroboros-native programs and the subsystem that consists of
-a bunch of **daemons** that allow you to easily create your own
-(overlay) networks using ordinary PC hardware (Linux, FreeBSD or MacOS
-X).
+Ouroboros is a prototype **distributed system** for packetized network
+communications. It is a redesign _ab initio_ of the current packet
+networking model -- from the programming API ("Layer 7") almost to the
+_wire_ ("Layer 1") -- without compromises. This means it's not
+directly compatible with anything currently available. It can't simply
+be "plugged into" the current network stack. Instead it has some
+interfaces into inter-operate with common technologies: run Ouroboros
+over Ethernet or UDP, or create tunnels over Ouroboros using tap or
+tun devices.
 
-The **Ouroboros library** implements the **application API** (the
-Ouroboros alternative to POSIX sockets) and the **management API**
-(the Ouroboros alternative to things like netlink sockets).
+Why? Because we think there are fundamental problems with the current
+model (referred to as the 4-Layer, 5-Layer or 7-Layer model --
+depending on who you ask). This problem is self-evident: a crippling
+lack of abstraction and a complete disregard for elegance that results
+in a technology that _works_ but can at best be described as an overly
+complicated mess.
 
-{{<figure width="60%" src="/docs/overview/intro.jpg">}}
+From an application perspective, Ouroboros network operates as a "black
+box" with a
+[very simple interface](https://ouroboros.rocks/man/man3/flow_alloc.3.html).
+Either it provides a _flow_, a bidirectional channel that delivers data
+within some requested operational parameters such as delay and
+bandwidth and reliability and security; or it provides a broadcast
+channel.
 
-From an application perspective, all that's needed is to link your
-application with Ouroboros and you can use the Ouroboros networking
-primitives.
+From an administrative perspective, an Ouroboros network is a bunch of
+_daemons_ that can be thought of as **software routers** (unicast) or
+**software _hubs_** (broadcast) that can be connected to each other;
+again through
+[a simple API](https://ouroboros.rocks/man/man8/ouroboros.8.html).
+Each daemon has an address, and they forward packets among each other.
+The daemons also implement their own internal name-to-address resolution.
 
-All **end-to-end transport functions** are implemented in the
-application library, such as **reliability** (packet ordering,
-retransmission logic etc) and transport **encryption**.
+Some of the main _features_ are:
 
-The Ouroboros daemons can be thought of as **software routers** that
-can be connected to each other. Each one has an address, and they
-forward packets among each other. The daemons also implement a
-Distributed Hash Table, so the network has its own internal
-name-to-address resolution.
+* Ouroboros is minimal: it only sends what it needs to send to operate.
+
+* Ouroboros adheres to the _end-to-end_ principle. Packet headers are
+  immutable between the program components (state machines) that
+  operate on their state. Only two protocol fields change on a
+  hop-by-hop (as viewed within a network layer) basis:
+  [TTL and ECN](/docs/concepts/protocols/).
+
+* Ouroboros can establish an encrypted flow in a _single RTT_ (not
+  including name-to-address resolution). The flow allocation API is a
+  2-way handshake (request-response) that agrees on endpoint IDs and
+  performs an ECDHE key exchange. The end-to-end protocol
+  [doesn't need a handshake](/docs/concepts/protocols/#operation-of-frcp).
+
+* The Ouroboros end-to-end protocol performs flow control, error
+  control and reliable transfer and is implemented as part of the
+  _application library_. Sequence numbers, acknowledgments, flow control
+  windows... The last thing the application does (or should do) is
+  encrypt everything before it hands it to the network layer for
+  delivery. With this functionality in the library, it's easy to force
+  encryption on _every_ flow that is created from your machine over
+  Ouroboros regardless of what the application programmer has
+  requested.
+
+* The flow allocation API works as an interface to the network. An
+  Ouroboros network layer is therefore "aware" of all traffic that it
+  is offered. This allows the layer to shape and police traffic, but
+  only based on quantity and QoS, not on the contents of the packets,
+  to ensure _net neutrality_.
+
+For a lot more depth, our article on the design of Ouroboros is
+accessible on [arXiv](https://arxiv.org/pdf/2001.09707.pdf).
 
 The best place to start understanding a bit what Ouroboros aims to do
 and how it differs from other packet networks is to first watch this
-presentation at [FOSDEM 2018](https://archive.fosdem.org/2018/schedule/event/ipc/), and have a
+presentation at [FOSDEM
+2018](https://archive.fosdem.org/2018/schedule/event/ipc/), and have a
 quick read of the [flow allocation](/docs/concepts/fa/) and [data
 path](/docs/concepts/datapath/) sections.
 
 {{< youtube 6fH23l45984 >}}
-
-For more depth, our article on the design of Ouroboros is accessible on [arXiv](https://arxiv.org/pdf/2001.09707.pdf).