X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;f=README.md;h=f2a39670b552196b17fe6f5325b7ff5cf0bf8ce6;hb=675cf4ac1d02b2b558a0e041d6cd4bebac0e5108;hp=24a76c2276dab03433a68f3d689c634d167c425f;hpb=eb354a89db20081e64f66da982a79ced01487a5c;p=rust-lightning

diff --git a/README.md b/README.md
index 24a76c22..f2a39670 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,10 @@
 Rust-Lightning, not Rusty's 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.
+Documentation can be found at [docs.rs](https://docs.rs/lightning/)
+
+Currently somewhere near 20% 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 +22,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.