Skip to content

cargo: make vss-server/impls easier to consume as a library - #116

Open
phlip9 wants to merge 6 commits into
lightningdevkit:mainfrom
phlip9:phlip9/relax-deps
Open

phlip9 wants to merge 6 commits into
lightningdevkit:mainfrom
phlip9:phlip9/relax-deps

Conversation

@phlip9

@phlip9 phlip9 commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

server+impls: make postgres native TLS optional

The native-tls crate adds a ton of build headache that I'd like to
avoid if I'm not actually using it. This diff makes it possible to
disable it.

cargo: relax direct dependency version requirements

Make it easier to consume VSS crates as a library. I've limited direct
crate dep semver versions to the first MSRV+semver compatible crate that
compiles and passes all tests.

  • tokio-v1.30 is the first version that supports OnceCell::const_new
    without the parking_lot crate enabled

@ldk-reviews-bot

ldk-reviews-bot commented Sep 10, 2026 •

Copy link
Copy Markdown

👋 Thanks for assigning @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.

@phlip9

phlip9 commented Sep 10, 2026

Copy link
Copy Markdown
Contributor Author

Looks like vss-server also needs something like lightningdevkit/ldk-node#1092 to fix MSRV CI checks

@tnull
tnull self-requested a review September 11, 2026 21:13

@tnull tnull left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not opposed to the change, but could expand a bit on a) what headache you're referring to exactly and b) what's your use case for using the crates independently from the vss-server binary?

Changes themselves LGTM I think.

Comment thread impls/src/postgres_store.rs
@phlip9

phlip9 commented Sep 22, 2026

Copy link
Copy Markdown
Contributor Author

Sure, let me expand on this a bit:

a) We try really hard to use only one TLS stack (rustls) as much as we can. This is for hardening (avoid exposing more non-memory safe code to the open internet), build convenience (it's slightly annoying to configure openssl+pkgconfig in nix builds and dev machines), dependency minimization, reduced binary bloat, and reduced CI build time. So pulling in openssl and the native-tls crate is something I would like to avoid.

b) We're now running an internal VSS (inside our VPC with mTLS auth). It was actually really nice just pulling in the VssService hyper service from server/src/vss_service.rs and serving it on top of all our existing Rust tooling. This integrates cleanly into our e2e tests, gets all our logs+traces+metrics tooling, mTLS config, instrumented allocator, etc ~ for free. It's not that we can't do this as a separate "opaque" service behind nginx, but then it's definitely harder to test.

@tnull

tnull commented Sep 22, 2026

Copy link
Copy Markdown
Contributor

Sure, let me expand on this a bit:

a) We try really hard to use only one TLS stack (rustls) as much as we can. This is for hardening (avoid exposing more non-memory safe code to the open internet), build convenience (it's slightly annoying to configure openssl+pkgconfig in nix builds and dev machines), dependency minimization, reduced binary bloat, and reduced CI build time. So pulling in openssl and the native-tls crate is something I would like to avoid.

b) We're now running an internal VSS (inside our VPC with mTLS auth). It was actually really nice just pulling in the VssService hyper service from server/src/vss_service.rs and serving it on top of all our existing Rust tooling. This integrates cleanly into our e2e tests, gets all our logs+traces+metrics tooling, mTLS config, instrumented allocator, etc ~ for free. It's not that we can't do this as a separate "opaque" service behind nginx, but then it's definitely harder to test.

Okay, makes sense (though I'm not sure where I stand on the rustls vs openssl arguments, but that is for an orthogonal discussion, trade-offs everywhere).

So, happy to have this land from my side, but @tankyleo still needs to review.

@phlip9

phlip9 commented Sep 22, 2026

Copy link
Copy Markdown
Contributor Author

Pushed a separate PR to fix MSRV CI issues: #117

Comment thread impls/Cargo.toml
Comment thread server/Cargo.toml
Comment thread impls/src/lib.rs Outdated
Comment thread impls/Cargo.toml
Comment thread server/Cargo.toml

@tankyleo tankyleo left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Some buggy github stuff ignore this]

Make it easier to consume VSS crates as a library. I've limited direct
crate dep semver versions to the first MSRV+semver compatible crate that
compiles and passes all tests.

* tokio-v1.30 is the first version that supports `OnceCell::const_new`
  without the `parking_lot` crate enabled
The `native-tls` crate adds a ton of build headache that I'd like to
avoid if I'm not actually using it. This diff makes it possible to
disable it.
Ensure that crates continue to build if we resolve dependencies to the
minimal version specified in the Cargo.toml (vs the versions locked in
the Cargo.lock).
Comment thread impls/Cargo.toml
tokio = { version = "1.30", default-features = false, features = ["rt", "macros"] }
native-tls = { version = "0.2.4", default-features = false }
postgres-native-tls = { version = "0.5", default-features = false, features = ["runtime"] }
log = { version = "0.4.8", default-features = false }

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: looks like we can still pull this down to 0.4.6 ? Same for server/Cargo.toml.

Comment thread docs/getting-started.md
include `sub` and `exp` claims, and omit `aud`; `sub` becomes the VSS storage user token. VSS only
verifies tokens, you must run the service that issues them.

### Optional Features

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's put this section right after prerequisites above, with a H2 header instead of H3

rustup default ${{ env.TOOLCHAIN }}
rustup component add rustfmt
- name: Run rustfmt checks
run: cargo fmt --check

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we've got this check already in ping-tests.yml I know it's hidden away in there.

Let's drop the fmt command in ping-tests.yml, and use fmt --all --check here

Comment on lines +60 to +61
cargo check --workspace
cargo check --workspace --no-default-features

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like we can do a single

cargo hack check --workspace --each-feature --locked

here to test all feature combinations ?

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.

4 participants