X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;f=README.md;h=fd264c8c2d928459f3c98abd948372ff6f83880d;hb=494219e3889200e8f2cce70d8194dc85fe432f9a;hp=24a76c2276dab03433a68f3d689c634d167c425f;hpb=24fd566567320b4d78fa868cce873bd733e30ce5;p=rust-lightning

diff --git a/README.md b/README.md
index 24a76c22..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,37 +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. (This is partially complete, but the events stuff needs to also
-   exist in Channel, which has a few inline TODOs to set up timers).
-
- * 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 (and some concept of available value in wallet).
-
- * 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.
-
- * 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.