RFC: Sample architecture and onboarding documentation #1
Conversation
This is a meaningful rewrite of the previous sample rust-lightning based node. Mainly, it switches the code architecture to a new threading model, where each major LN components gets its own and communicate with others through dedidcated channels. It also splits the command line in its own binary, move logging in its own file, and vets the whole with a configuration file. Documentation is work in progress and aims to expose Rust-Lightning architecture usage. This is still experimental software and shouldn't be used beyond a local regtest. You still have wide holes which would provoke certain loss of funds.
|
Could you update the description to summarize the architecture? |
src/init.rs
Outdated
| let persister = Arc::new(FilesystemPersister::new(data_path.clone() + "/monitors")); | ||
|
|
||
| //TODO: if doesn't exist take best chain from bitcoind | ||
| let starting_blockhash = if let Ok(mut blockhash_file) = OpenOptions::new().read(true).open(data_path.clone() + "/blockhash") { |
There was a problem hiding this comment.
Why? Can't we just use the ChannelManager's serialized version?
src/utils.rs
Outdated
| } | ||
|
|
||
| /// Basic JSON-RPC client storing server host and credentials | ||
| pub struct RpcClient { |
There was a problem hiding this comment.
I presume this can be dropped in favor of the one now on RL upstream?
src/init.rs
Outdated
| const FEE_PROPORTIONAL_MILLIONTHS: u32 = 10; | ||
| const ANNOUNCE_CHANNELS: bool = false; | ||
|
|
||
| #[tokio::main] |
There was a problem hiding this comment.
You may want to specify a threaded executor :)
src/init.rs
Outdated
| let handles = setup_rpc_server(outbound_rpc_server_connector, ldk_port).await; | ||
| join_handles.push(handles); | ||
|
|
||
| loop { |
There was a problem hiding this comment.
Can't you just wait on all the join handles to finish?
src/sampled.rs
Outdated
| "invoice" => { | ||
| let amount = u64::from_str_radix(v_obj.get("amt").unwrap().as_str().unwrap(), 10).unwrap(); | ||
| let payment_preimage = [1; 32]; | ||
| //thread_rng().fill_bytes(&mut payment_preimage); |
ariard
force-pushed
the
draft-sample
branch
2 times, most recently
from
a0fae31 to
797028f
Compare
ARCH.md
Outdated
|
|
||
| # Why the sharing messages approach over the sharing memory one ? | ||
|
|
||
| Long-term, it might be interesting to provide a multi-process LDK sample, better fitted for |
There was a problem hiding this comment.
Note that a big part of the motivation for this in Core is that its written in a memory-unsafe language. Without unsafe code, there's little reason to do this (absent compiler and other similar bugs). Cross-host, not just cross-process, stuff is cooler, though.
There was a problem hiding this comment.
Come on, playing with the security capabilities or privileges framework of your system is cool too. Or even control groups for intensive process like routing or throwing a load balancer between p2p stack and channel processing. For high-availability, high-security node, multi-process is way better :p
There was a problem hiding this comment.
Lol, I mean I guess if you want capabilities enforcement that's cool. I still prefer multi-host, but whatever :)
…portable Make ldk sample importable
Ready for at least a high-level conceptual review.
For now, the sample is mostly a code skeleton with some commands functional (
connect/open/...). Don't intend to use it beyond your local regtest.