Skip to content

wasm: Route clock reads through a time module - #1122

Open
benthecarman wants to merge 4 commits into
lightningdevkit:mainfrom
benthecarman:wasm-time
Open

benthecarman wants to merge 4 commits into
lightningdevkit:mainfrom
benthecarman:wasm-time

Conversation

@benthecarman

Copy link
Copy Markdown
Contributor

First step toward wasm32 support: stop reading the system clock directly, since SystemTime::now() panics on wasm32-unknown-unknown.

  • Add ldk_node::time. All clock reads go through it, and hosts without a
    system clock can install a TimeProvider.
  • Use LDK and BDK's explicit-time APIs instead of the ones that read the clock
    internally.
  • Move LDK's std features behind a default ldk-std feature, and
    lightning-net-tokio behind a default net-tokio feature. Both are temporary
    scaffolding for the port.
  • Add a CI job that bans direct clock reads and checks that LDK's std/time
    features are off when default features are disabled.

Native behavior should be unchanged.

benthecarman and others added 4 commits October 1, 2026 14:45
Keep node wall and monotonic clock reads behind one provider in the time
module. Use native clocks by default and let embedding hosts supply a
clock before first use. Require a provider on bare WASM and prevent
replacement so monotonic measurements share one origin.

Drop chrono's clock feature, as UTC timestamps now come from the
provider.

Ban direct platform clock reads with clippy and run the check in a
dedicated CI job across the native and UniFFI feature sets, so new code
stays wasm32-safe while the rest of the port lands.

AI assistance: Claude Opus 5.5 and OpenAI Codex.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Supply node time to BDK scans, liquidity, invoice timestamps, gossip
snapshots, and UniFFI expiry checks through existing explicit-time APIs.
Preserve freshness and expiry validation, and report a pre-epoch clock
as an LSPS2 invoice creation error.

Disable transaction-sync's optional timing logs, which duplicate the
node's own sync duration logs, so it no longer reads the clock itself.

Ban the dependency APIs that read the platform clock internally, so
call sites keep using the explicit-time variants.

AI assistance: Claude Opus 5.5 and OpenAI Codex.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LDK's std feature reads the system clock internally (channel manager,
gossip, offers, payment retries, liquidity), which wasm32 can't do.
Move it and liquidity's time feature behind a default ldk-std feature,
so code can switch to LDK's explicit-time APIs when it is disabled.

The chain sources and filesystem storage pull in LDK crates that
require std, so they enable ldk-std. Native builds resolve the same LDK
features as before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
lightning-net-tokio enables LDK's default features, which turns std
back on even when ldk-std is disabled. Move it behind a default
net-tokio feature so builds without ldk-std are free of LDK's internal
clock reads.

Without net-tokio, a placeholder socket type stands in for the
transport. It has no values, so no connection can be created with it:
connecting to peers fails and listening addresses are rejected at build
time. This leaves the seam for a wasm32 transport later.

Restore the CI check that disabling default features leaves no LDK
clock features enabled, and lint a build without net-tokio so the
placeholder keeps compiling.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ldk-reviews-bot

ldk-reviews-bot commented Oct 1, 2026 •

Copy link
Copy Markdown

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@benthecarman benthecarman added this to the 0.9 milestone Oct 1, 2026
@ldk-reviews-bot
ldk-reviews-bot requested a review from tnull October 1, 2026 20:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants