_ Git - rust-lightning/blob - README.md

   1 Rust-Lightning, not Rusty's Lightning!
   2
   3 Currently somewhere near 5% towards usable, published to see if there is any
   4 real interest from folks in either contributing to or using a lightning rust
   5 library.
   6
   7 The goal is to provide a full-featured but also incredibly flexible lightning
   8 implementation, allowing the user to decide how they wish to use it. With that
   9 in mind, everything should be exposed via simple, composable APIs. The user
  10 should be able to decide whether they wish to use their own threading/execution
  11 models, allowing usage inside of existing library architectures, or allow us to
  12 handle that for them. Same goes with network connections - if the user wishes
  13 to use their own networking stack, they should be able to do so! This all means
  14 that we should provide simple external interfaces which allow the user to drive
  15 all execution, while implementing sample execution drivers that create a
  16 full-featured lightning daemon by default.
  17
  18 For security reasons, do not add new dependencies. Really do not add new
  19 non-optional/non-test/non-library dependencies. Really really do not add
  20 dependencies with dependencies. Do convince Andrew to cut down dependency usage
  21 in rust-bitcoin.
  22
  23 Assorted random TODOs:
  24
  25  * Create a general timer interface - this should be passed around in reference
  26    form to most objects to allow them to register functions which are called on
  27    a timer. By default we should provide an implementation of this which uses
  28    some newfangled rusty promise-y library, but should generally ensure a
  29    client can simply integrate this into whatever existing timer interface
  30    they use.
  31
  32  * Networking...having a simple bytes-in-bytes-out interface which does message
  33    handling and calls our encryption layer is probably the right approach. We
  34    should then also probably use the same promise-y library we use for timers
  35    to do socket selection and reading/writing.
  36
  37  * Figure out how to expose when-to-connect and who-to-connect-to.
  38
  39  * Implement when-to-connect and who-to-connect-to based on route/node rumoring
  40    and channelmanager state.
  41
  42  * Some kind of serialization format for on-disk storage of things like
  43    channels, channelmonitors, routing db, etc.
  44
  45  * BOLT 10/network bootstrapping implementation.
  46
  47  * Some kind of DoS thing including ban tracking and putting that info in
  48    HandleError (and also rename HandleError) to be propagated up...and then
  49    handled.
  50
  51  * All the random TODOs and unimplemented!()s across the codebase.
  52
  53  * BOLT 11 (invoice/address creation/generation) implementation
  54
  55  * Type-ify our somewhat random usage of Uint256/[u8; 32]. Use Sha256dHash
  56    where appropriate, create our own types for everything else.
  57
  58  * Some kind of logging subsystem/API.
  59
  60 Notes on coding style:
  61  * Use tabs. If you want to align lines, use spaces. Any desired alignment
  62    should display fine at any tab-length display setting.
  63
  64 License is AGPL, but with agreement that Matt can relicense under any other
  65 OSI-approved license at will (and likely will with sufficient motivation).