Skip to content

Commit 4905df8

Browse files
authored
Merge pull request #1628 from tnull/2022-07-readme-remove-slack
Remove Slack link and other updates to `README`
2 parents 018a783 + cf7655a commit 4905df8

File tree

1 file changed

+52
-54
lines changed

1 file changed

+52
-54
lines changed

README.md

Lines changed: 52 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -5,74 +5,73 @@ Rust-Lightning
55
[![Documentation](https://img.shields.io/static/v1?logo=read-the-docs&label=docs.rs&message=lightning&color=informational)](https://docs.rs/lightning/)
66
[![Safety Dance](https://img.shields.io/badge/unsafe-forbidden-success.svg)](https://github.com/rust-secure-code/safety-dance/)
77

8-
Rust-Lightning is a Bitcoin Lightning library written in Rust. The main crate,
8+
`rust-lightning` is a Bitcoin Lightning library written in Rust. The main crate,
99
`lightning`, does not handle networking, persistence, or any other I/O. Thus,
1010
it is runtime-agnostic, but users must implement basic networking logic, chain
1111
interactions, and disk storage. More information is available in the `About`
1212
section.
1313

14-
The `lightning-net-tokio` crate implements Lightning networking using the
15-
[Tokio](https://github.com/tokio-rs/tokio) async runtime.
16-
17-
The `lightning-persister` crate implements persistence for channel data that
18-
is crucial to avoiding loss of channel funds. Sample modules for persistence of
19-
other Rust-Lightning data is coming soon.
20-
2114
Status
2215
------
23-
24-
The project implements all of the BOLT specifications in the 1.0 spec. The
16+
The project implements all of the [BOLT
17+
specifications](https://github.com/lightning/bolts). The
2518
implementation has pretty good test coverage that is expected to continue to
2619
improve. It is also anticipated that as developers begin using the API, the
2720
lessons from that will result in changes to the API, so any developer using this
2821
API at this stage should be prepared to embrace that. The current state is
29-
sufficient for a developer or project to experiment with it. Recent increased
30-
contribution rate to the project is expected to lead to a high quality, stable,
31-
production-worthy implementation in 2021.
22+
sufficient for a developer or project to experiment with it.
3223

33-
Communications for Rust-Lightning and Lightning Development Kit happens through our LDK
34-
[slack](https://join.slack.com/t/lightningdevkit/shared_invite/zt-tte36cb7-r5f41MDn3ObFtDu~N9dCrQ) & [discord](https://discord.gg/5AcknnMfBw) channels.
24+
Communications for `rust-lightning` and Lightning Development Kit happen through
25+
our LDK [Discord](https://discord.gg/5AcknnMfBw) channels.
3526

3627
Crates
3728
-----------
38-
1. [lightning](./lightning)
39-
The Core of the LDK library, implements the lightning protocol, channel state machine,
40-
and on-chain logic. Supports no-std and exposes on relatively low-level interfaces.
29+
1. [lightning](./lightning)
30+
The core of the LDK library, implements the Lightning protocol, channel state machine,
31+
and on-chain logic. Supports `no-std` and exposes only relatively low-level interfaces.
4132
2. [lightning-background-processor](./lightning-background-processor)
4233
Utilities to perform required background tasks for Rust Lightning.
4334
3. [lightning-block-sync](./lightning-block-sync)
4435
Utilities to fetch the chain data from a block source and feed them into Rust Lightning.
4536
4. [lightning-invoice](./lightning-invoice)
46-
Data structures to parse and serialize BOLT11 lightning invoices.
37+
Data structures to parse and serialize
38+
[BOLT #11](https://github.com/lightning/bolts/blob/master/11-payment-encoding.md)
39+
Lightning invoices.
4740
5. [lightning-net-tokio](./lightning-net-tokio)
48-
Implementation of the rust-lightning network stack using Tokio.
49-
For Rust-Lightning clients which wish to make direct connections to Lightning P2P nodes,
50-
this is a simple alternative to implementing the required network stack, especially for those already using Tokio.
41+
Implementation of the `rust-lightning` network stack using the
42+
[Tokio](https://github.com/tokio-rs/tokio) `async` runtime. For `rust-lightning`
43+
clients which wish to make direct connections to Lightning P2P nodes, this is
44+
a simple alternative to implementing the required network stack, especially
45+
for those already using Tokio.
5146
6. [lightning-persister](./lightning-persister)
52-
Utilities to manage Rust-Lightning channel data persistence and retrieval.
47+
Implements utilities to manage `rust-lightning` channel data persistence and retrieval.
48+
Persisting channel data is crucial to avoiding loss of channel funds.
5349
7. [lightning-rapid-gossip-sync](./lightning-rapid-gossip-sync)
5450
Client for rapid gossip graph syncing, aimed primarily at mobile clients.
5551

5652
About
5753
-----------
58-
LDK/Rust-Lightning is a generic library which allows you to build a lightning
59-
node without needing to worry about getting all of the lightning state machine,
54+
LDK/`rust-lightning` is a generic library which allows you to build a Lightning
55+
node without needing to worry about getting all of the Lightning state machine,
6056
routing, and on-chain punishment code (and other chain interactions) exactly
61-
correct. Note that Rust-Lightning isn't, in itself, a node. There are various
57+
correct. Note that `rust-lightning` isn't, in itself, a node. There are various
6258
working/in progress demos which could be used as a node today, but if you "just"
63-
want a generic lightning node, you're almost certainly better off with
64-
`c-lightning`/`lnd` - if, on the other hand, you want to integrate lightning
65-
with custom features such as your own chain sync, your own key management, your
66-
own data storage/backup logic, etc., LDK is likely your only option. Some
67-
Rust-Lightning utilities such as those in `chan_utils` are also suitable for use
68-
in non-LN Bitcoin applications such as DLCs and bulletin boards.
69-
70-
We are currently working on a demo node which fetches blockchain data and
71-
on-chain funds via Bitcoin Core RPC/REST. The individual pieces of that demo
72-
are/will be composable, so you can pick the off-the-shelf parts you want and
73-
replace the rest.
74-
75-
In general, Rust-Lightning does not provide (but LDK has implementations of):
59+
want a generic Lightning node, you're almost certainly better off with [Core
60+
Lightning](https://github.com/ElementsProject/lightning) or
61+
[LND](https://github.com/lightningnetwork/lnd). If, on the other hand, you want
62+
to integrate Lightning with custom features such as your own chain sync, your
63+
own key management, your own data storage/backup logic, etc., LDK is likely your
64+
only option. Some `rust-lightning` utilities such as those in
65+
[`chan_utils`](./lightning/src/ln/chan_utils.rs) are also suitable for use in
66+
non-LN Bitcoin applications such as Discreet Log Contracts (DLCs) and bulletin boards.
67+
68+
A sample node which fetches blockchain data and manages on-chain funds via the
69+
Bitcoin Core RPC/REST interface is available
70+
[here](https://github.com/lightningdevkit/ldk-sample/). The individual pieces of
71+
that demo are composable, so you can pick the off-the-shelf parts you want
72+
and replace the rest.
73+
74+
In general, `rust-lightning` does not provide (but LDK has implementations of):
7675
* on-disk storage - you can store the channel state any way you want - whether
7776
Google Drive/iCloud, a local disk, any key-value store/database/a remote
7877
server, or any combination of them - we provide a clean API that provides
@@ -84,21 +83,21 @@ In general, Rust-Lightning does not provide (but LDK has implementations of):
8483
informed of, which is compatible with Electrum server requests/neutrino
8584
filtering/etc.
8685
* UTXO management - RL/LDK owns on-chain funds as long as they are claimable as
87-
a part of a lightning output which can be contested - once a channel is closed
86+
part of a Lightning output which can be contested - once a channel is closed
8887
and all on-chain outputs are spendable only by the user, we provide users
8988
notifications that a UTXO is "theirs" again and it is up to them to spend it
9089
as they wish. Additionally, channel funding is accomplished with a generic API
9190
which notifies users of the output which needs to appear on-chain, which they
9291
can then create a transaction for. Once a transaction is created, we handle
9392
the rest. This is a large part of our API's goals - making it easier to
94-
integrate lightning into existing on-chain wallets which have their own
93+
integrate Lightning into existing on-chain wallets which have their own
9594
on-chain logic - without needing to move funds in and out of a separate
96-
lightning wallet with on-chain transactions and a separate private key system.
97-
* networking - to enable a user to run a full lightning node on an embedded
95+
Lightning wallet with on-chain transactions and a separate private key system.
96+
* networking - to enable a user to run a full Lightning node on an embedded
9897
machine, we don't specify exactly how to connect to another node at all! We
9998
provide a default implementation which uses TCP sockets, but, e.g., if you
100-
wanted to run your full lightning node on a hardware wallet, you could, by
101-
piping the lightning network messages over USB/serial and then sending them in
99+
wanted to run your full Lightning node on a hardware wallet, you could, by
100+
piping the Lightning network messages over USB/serial and then sending them in
102101
a TCP socket from another machine.
103102
* private keys - again we have "default implementations", but users can chose to
104103
provide private keys to RL/LDK in any way they wish following a simple API. We
@@ -111,25 +110,24 @@ https://vimeo.com/showcase/8372504/video/412818125
111110

112111
Design Goal
113112
-----------
114-
115-
The goal is to provide a full-featured but also incredibly flexible lightning
113+
The goal is to provide a full-featured but also incredibly flexible Lightning
116114
implementation, allowing the user to decide how they wish to use it. With that
117115
in mind, everything should be exposed via simple, composable APIs. More
118-
information about Rust-Lightning's flexibility is provided in the `About`
116+
information about `rust-lightning`'s flexibility is provided in the `About`
119117
section above.
120118

121119
For security reasons, do not add new dependencies. Really do not add new
122120
non-optional/non-test/non-library dependencies. Really really do not add
123121
dependencies with dependencies. Do convince Andrew to cut down dependency usage
124-
in rust-bitcoin.
122+
in `rust-bitcoin`.
125123

126124
Rust-Lightning vs. LDK (Lightning Development Kit)
127125
-------------
128-
Rust-Lightning refers to the core `lightning` crate within this repo, whereas
129-
LDK encompasses Rust-Lightning and all of its sample modules and crates (e.g.
126+
`rust-lightning` refers to the core `lightning` crate within this repo, whereas
127+
LDK encompasses `rust-lightning` and all of its sample modules and crates (e.g.
130128
the `lightning-persister` crate), language bindings, sample node
131-
implementation(s), and other tools built around using Rust-Lightning for
132-
lightning integration or building a lightning node.
129+
implementation(s), and other tools built around using `rust-lightning` for
130+
Lightning integration or building a Lightning node.
133131

134132
Tagline
135133
-------
@@ -144,7 +142,7 @@ Contributors are warmly welcome, see [CONTRIBUTING.md](CONTRIBUTING.md).
144142
Project Architecture
145143
---------------------
146144

147-
For a Rust-Lightning high-level API introduction, see [ARCH.md](ARCH.md).
145+
For a `rust-lightning` high-level API introduction, see [ARCH.md](ARCH.md).
148146

149147
License is either Apache-2.0 or MIT, at the option of the user (ie dual-license
150148
Apache-2.0 and MIT).

0 commit comments

Comments
 (0)