We should look to create a dedicated section on testing.

Currently, it's difficult to write tests for things like opening channels as it requires a second node.

Some things we might include in this section:

• Testing overview, tradeoffs, recommended testing tools
• Testing recipes, common patterns for testing with LDK
• Testing environments, mocking functions, mocking modules

• Make all the overall steps Headers rather than checkboxes
• Make all the information visually hierarchical -- all information/code samples that fall within the header should be indented hierarchically
• Make key-value information more visually keyed-/value'd. i.e. "Dependencies: ChannelManager" becomes "Dependencies: ChannelManager
• All code things that are currently formatted like: "channel manager," "peer manager" should become ChannelManager, PeerManager (i.e. code format all the things)
• Parts of the code samples that are formatted like "<insert X code here>" should be in comments, and prefixed by TODO so syntax highlighting highlights them
• Don't combine multiple examples into the same code sample, split them
• Reorder the information in each step of Setup to be: 1. description, 2. code example, 3. dependencies, 4. references.
• 80col all code examples and comments therein

Once the Vuepress version (currently on the develop branch) is live, we can apply for Algolia Docsearch, which will be a major enhancement of the search. The current search just covers the headline content, Algolia does fulltext search.

We currently say "LDK/Rust-Lightning is a generic library which allows you to build a lightning node without needing to..." under Getting Started. I think we should do one of the following:

1. Only refer to it as LDK on the website
2. Explain what LDK is and what rust-lightning is then use them consistently on the website

If we merge a PR for lightningdevkit.org, it should automatically deploy

This is an issue is to help us track, improve and implement further visual aspects of the website. Most of what we need is there, but it's important to get the base/template as solid as possible as it will be used by the BDK project. We are looking to make updates in the following areas.

• The title fonts seem to be randomly missing pixels, a rendering issue?
• Remove the expanding sidebar as it's difficult to tell what is part of the current article and what links out to other pages. (Discussion needed)
• Support for a blog page
• #58
• #60

+ any other relevant notes about Electrum

Our documentation about a specific feature (e.g zero-conf chan) might be an advanced, subsection of the "Opening a channel" one, thus making it hard to find the information.

Once the website is more stuffed, it could be cool to add a topic index, like https://bitcoinops.org/en/topics/

The LDK project start to be spread across different repositories. Also the type of helpful contributions start to expand (technical writing, infrastructure deployment, product management).

I think we should consider adding a Community section on the website telling about the project history, the modules, their milestones and where to engage with other community participants.

As a reference : https://docs.btcpayserver.org/Contribute/

https://lightningdevkit.org/tutorials/build_a_node_in_rust/#10-sync-channelmonitors-and-channelmanager-to-chain-tip

Add a note to make sure channel monitors are in sync first before doing it for channel manager and chain monitor.

Can also add an extra step around populating the filter when instantiating a chain monitor

• ChannelMonitor::load_outputs_to_watch

Create a table showing the different trade-offs LDK-based implementations have made e.g (Sensei, lnrod, lnq). Based on block sourcing, networking, entropy, pathfinding etc

https://twitter.com/vindard/status/1379789255296303112

Look to integrate rust lightning docs directly into the site instead of linking out to the external site at http://docs.rs/lightning.

Might be possible to do with Algolia search directly.

Alternatively, we can build the rust-lighting docs ourselves and embed them into the site with some custom CSS.

We need to change include the Features section on the landing page. Still need to identify what we want on there.

@ConorOkus proposed a grid layout with each feature linking out to its own page in the docs. Similar to the Why Next.js section in their docs. Open for discussion.

Addition of a beginner-friendly contribution section for anyone looking to contribute to the technical documentation of the site. With some reference from here

I could set it up

Toggling between the different programming language tabs is a bit janky at the moment and makes pages jump around quite a bit.

LDK Java Sample - https://github.com/getlipa/ldk-sample-java

LDK Kotlin Sample - https://github.com/BlueWallet/HelloLightning

BDK/LDK Sample - https://github.com/johncantrell97/bdk-ldk

I'm not sure that what's currently in these sections makes sense. Seems like Overview should be more of an overview of LDK or maybe an index of the docs? Maybe take inspiration from Firebase Overview section or Stripe Overview.

And seems like Getting Started is more of an Architecture section, so should be renamed. If Overview becomes an index/entrypoint to the docs, then maybe Getting Started is unnecessary.

In any case, these two sections need some rethinking.

In some cases users will need to access the channelmanager in the event handler, making the current order confusing.

See getlipa/ldk-sample-java#1 (comment)

Update this section to make it clear the channel monitor will forward requests through to the chain monitors.

Users should make sure the channel monitors are all the same best hash before they start using the chain monitor.

For some/many users, a unified API would be preferable. Abstraction layer might be convenient?

Based on Val's write up - https://docs.google.com/document/d/1AMulTFMqjNFIDegHz1turh4X2SIUVt20uW90ntESSN4/

@ConorOkus Can you provide some more details on what should be in the footer? For now I haven't done much there, because I found it not necessary to repeat the links from the top navbar.

Basically I need to finish #27

https://github.com/lightningdevkit/lightningdevkit.org/blob/5fb28f93e6396b8580c0a5ecf2e1f1280217cb75/docs/mobile.md

We say "We are currently working on a demo node which fetches blockchain data and on-chain funds via Bitcoin Core RPC/REST."

I believe this text is out of date. I think it was written when we didn't yet have a completed sample, but now we have one. Of course we'll always be "currently working" on all aspects of the software, but I think we shouldn't suggest the sample isn't yet complete or ready to use.

Jeff: "when I made the diagram, using the name NetGraphMsgHandler seemed a bit too low-level. It is a struct that implements the RoutingMessageHandler trait, so "Routing" seemed like a better name to use there"

We currently make it clear that multiple types of events need to be handled, but the user has to do some external digging to the site to find examples of how to do this here.

In general, I think we should break up our guides/tutorials into separate pages to allow more room to add these code examples directly into the docs e.g Initialize the ChannelManagerPersister would have its own page with example code for each type of event handling.

This will be largely influenced by what goes in the, what questions do you have about the Lightning Development Kit? discussion.

https://squarecrypto.slack.com/archives/GQR9UAARY/p1635476156009000?thread_ts=1635474564.006400&cid=GQR9UAARY

(a) use optimal mobile OS APIs to background sync
(b) when app is brought to foreground, prioritize LN network graph data sync
(c) then download remaining block data

Because LN payments can be sent without having the blockchain sync'd (step c). So b should be prioritized over c since that data is required for sending, then by allowing users to send after b but before c there is less latency for the user (ideally none if step a works well and/or step b is fast).

shutdown_script is used for our funds when negotiating a channel close and destination_script is used if LDK needs to sweep funds when the counterparty goes to the chain because if we don't they can take them after a delay.

They're stored as a part of the channel, and fetched when channel opens and stored for the duration and only used on close

• remove "Using LDK" section from main "Build a Node" guide
• add separate guide with:

• opening a channel (public + private)
• [force]closing a channel
• sending a payment to an invoice
• list [usable] channels
• list peers
• get node pubkey
• get invoice
• connect peer

Should be the same format as "Build a Node" guide w/ Rust code samples taken from the sample + modified to suit the docs, but should also the existing docs Java samples, especially Matt's "Opening a Channel" Java sample.

• Highlight the fact we expect users to implement their own KeysInterface but use InMemorySigner for channel-specific parts.
• Some recommendations for transferring state to a separate node/wallet implementation given, spending logic requires a lot of custom logic
• LDK will always require the user to provide the initial randomness from which things like this can be derived for the default KeysManager
• What gets persisted so that channel keys can be recovered on restart?
• What is needed to rederive keys
  • channel_keys_id for the Signer?
  • seed for KeysManager

My understanding is that TxFilter is in the LDK not the app code. We should have @jkczyz or someone confirm and update the visual.

https://ldk-docs-preview.netlify.app/architecture/

"Blockchain Data" has both Java and Rust code samples. "Build a Node" should do similarly.

Remove the blue/purple as it's similar to what Square Crypto and Lightning Labs use.
Let's experiment with the green the current site is using or some other alternative.

Rather than just a big code block with comments, this section should be broken up into steps with headers, explanations, and code samples -- along the lines of the Build a Node guide.

The LDK guide should explain what you should do if someone instructs an LDK node to stop in an orderly manner.

Raised in slack - https://lightningdevkit.slack.com/archives/CSYT185MY/p1643372662877939

The syntax highlighting of <code> elements within a div.custom-block tip has white text with a light background, and can't be read without manually highlighting with the mouse cursor. I suggest a darker color for syntax highlights when they are contained in a tip block in light mode. Replicated in Brave and Firefox on macOS.

When a script is registered to be watched we should mention the need to perform a rescan from some birth height to ensure it has not already been spent.

It is a unique feature in the space, so we should promote it and also pay extra attention to explaining it well since it will be new to folks.

Add a Payment Retries section to Sending Payments.

Includes new InvoicePayer API that retires payments as paths fail.

Released v0.0.103.0
Pull Request

This one is up to me to get it started, detailing how to build a lightclient with LDK and what options you're offered.

https://github.com/lsilva01/ldk_notes/blob/main/1_connect_to_bitcoin_core.md

it points to my twitter account instead of an invite link for discord

Diagrams from @jkczyz, @arik-so, and @ariard need to be added IIUC.