-The goal is to provide a full-featured but also incredibly flexible lightning
-implementation, allowing the user to decide how they wish to use it. With that
-in mind, everything should be exposed via simple, composable APIs. The user
-should be able to decide whether they wish to use their own threading/execution
-models, allowing usage inside of existing library architectures, or allow us to
-handle that for them. Same goes with network connections - if the user wishes
-to use their own networking stack, they should be able to do so! This all means
-that we should provide simple external interfaces which allow the user to drive
-all execution, while implementing sample execution drivers that create a
-full-featured lightning daemon by default.
+A sample node which fetches blockchain data and manages on-chain funds via the
+Bitcoin Core RPC/REST interface is available
+[here](https://github.com/lightningdevkit/ldk-sample/). The individual pieces of
+that demo are composable, so you can pick the off-the-shelf parts you want
+and replace the rest.
+
+In general, `rust-lightning` does not provide (but LDK has implementations of):
+* on-disk storage - you can store the channel state any way you want - whether
+ Google Drive/iCloud, a local disk, any key-value store/database/a remote
+ server, or any combination of them - we provide a clean API that provides
+ objects which can be serialized into simple binary blobs, and stored in any
+ way you wish.
+* blockchain data - we provide a simple `block_connected`/`block_disconnected`
+ API which you provide block headers and transaction information to. We also
+ provide an API for getting information about transactions we wish to be
+ informed of, which is compatible with Electrum server requests/neutrino
+ filtering/etc.
+* UTXO management - RL/LDK owns on-chain funds as long as they are claimable as
+ part of a Lightning output which can be contested - once a channel is closed
+ and all on-chain outputs are spendable only by the user, we provide users
+ notifications that a UTXO is "theirs" again and it is up to them to spend it
+ as they wish. Additionally, channel funding is accomplished with a generic API
+ which notifies users of the output which needs to appear on-chain, which they
+ can then create a transaction for. Once a transaction is created, we handle
+ the rest. This is a large part of our API's goals - making it easier to
+ integrate Lightning into existing on-chain wallets which have their own
+ on-chain logic - without needing to move funds in and out of a separate
+ Lightning wallet with on-chain transactions and a separate private key system.
+* networking - to enable a user to run a full Lightning node on an embedded
+ machine, we don't specify exactly how to connect to another node at all! We
+ provide a default implementation which uses TCP sockets, but, e.g., if you
+ wanted to run your full Lightning node on a hardware wallet, you could, by
+ piping the Lightning network messages over USB/serial and then sending them in
+ a TCP socket from another machine.
+* private keys - again we have "default implementations", but users can choose to
+ provide private keys to RL/LDK in any way they wish following a simple API. We
+ even support a generic API for signing transactions, allowing users to run
+ RL/LDK without any private keys in memory/putting private keys only on
+ hardware wallets.
+
+LDK's customizability was presented about at Advancing Bitcoin in February 2020:
+https://vimeo.com/showcase/8372504/video/412818125
+
+Design Goal
+-----------
+The goal is to provide a fully-featured and incredibly flexible Lightning
+implementation, allowing users to decide how they wish to use it. With that
+in mind, everything should be exposed via simple, composable APIs. More
+information about `rust-lightning`'s flexibility is provided in the `About`
+section above.