X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;ds=sidebyside;f=README.md;h=fd264c8c2d928459f3c98abd948372ff6f83880d;hb=refs%2Fheads%2F2020-01-443-absurdism;hp=877ccc3bcf6150d506d3146144eda78711159b54;hpb=34138a02463b4510522c405790125019d60f3199;p=rust-lightning

diff --git a/README.md b/README.md
index 877ccc3b..fd264c8c 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,12 @@
+[![Safety Dance](https://img.shields.io/badge/unsafe-forbidden-success.svg)](https://github.com/rust-secure-code/safety-dance/)
+
 Rust-Lightning, not Rusty's Lightning!
+=====
+
+Documentation can be found at [docs.rs](https://docs.rs/lightning/)
 
-Currently somewhere near 5% towards usable, published to see if there is any
-real interest from folks in either contributing to or using a lightning rust
-library.
+Currently somewhere near 50% towards usable, published to see if there is any
+real interest from folks in using a lightning rust library.
 
 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
@@ -20,43 +24,6 @@ non-optional/non-test/non-library dependencies. Really really do not add
 dependencies with dependencies. Do convince Andrew to cut down dependency usage
 in rust-bitcoin.
 
-Assorted random TODOs:
-
- * Create a general timer interface - this should be passed around in reference
-   form to most objects to allow them to register functions which are called on
-   a timer. By default we should provide an implementation of this which uses
-   some newfangled rusty promise-y library, but should generally ensure a
-   client can simply integrate this into whatever existing timer interface
-   they use.
-
- * Networking...having a simple bytes-in-bytes-out interface which does message
-   handling and calls our encryption layer is probably the right approach. We
-   should then also probably use the same promise-y library we use for timers
-   to do socket selection and reading/writing.
-
- * Figure out how to expose when-to-connect and who-to-connect-to.
-
- * Implement when-to-connect and who-to-connect-to based on route/node rumoring
-   and channelmanager state.
-
- * Some kind of serialization format for on-disk storage of things like
-   channels, channelmonitors, routing db, etc.
-
- * BOLT 10/network bootstrapping implementation.
-
- * Some kind of DoS thing including ban tracking and putting that info in
-   HandleError (and also rename HandleError) to be propagated up...and then
-   handled.
-
- * All the random TODOs and unimplemented!()s across the codebase.
-
- * BOLT 11 (invoice/address creation/generation) implementation
-
- * Type-ify our somewhat random usage of Uint256/[u8; 32]. Use Sha256dHash
-   where appropriate, create our own types for everything else.
-
- * Some kind of logging subsystem/API.
-
 Notes on coding style:
  * Use tabs. If you want to align lines, use spaces. Any desired alignment
    should display fine at any tab-length display setting.