Add support for the simple "sigs-based auth" VSS scheme #755
Conversation
TheBlueMatt
commented
Jan 15, 2026
TheBlueMatt
commented
At lightningdevkit/vss-server#79 we added a new, trivial, VSS authentication scheme that ensures client isolation without much else. This is great for testing, and we expect some to do new-account-rate-limiting via other means, so might well become a common default. Here we add support to it in ldk-node.
When we added the trivial sigs-based authentication scheme in VSS, we made it the default if no other authentication scheme was configured and default features are enabled. This broke our integration tests as we were expecting no authentication to be required in such a case. Here we fix this by switching to the new sigs-based auth scheme, removing `store_id`s to demonstrate client isolation while we're at it.
|
I've assigned @tnull as a reviewer! |
|
Depends on lightningdevkit/vss-client#54 |
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
Generally looks good, some comments. Mind adding an intermittent commit that bumps the dependency to your branch of vss-client so we can see if CI passes?
| .build_with_vss_store( | ||
| config_a.node_entropy, | ||
| vss_base_url.clone(), | ||
| "node_1_store".to_string(), |
There was a problem hiding this comment.
Why are we changing the store_id here and below?
There was a problem hiding this comment.
To demonstrate/test client isolation in VSS by default.
|
|
||
| let rand_suffix: String = | ||
| (0..7).map(|_| rng().sample(rand::distr::Alphanumeric) as char).collect(); | ||
| let store_id = format!("v0_compat_test_{}", rand_suffix); |
There was a problem hiding this comment.
No, please leave this in place, otherwise running this test repeatedly against the same backend won't start from scratch every time.
There was a problem hiding this comment.
Oops, sorry, missed that they're using a static seed. I randomized the seed.
There's not really any reason to force devs to select a `store_id` in the default `build_with_vss_store` anymore - we use a key derived from the node entropy to key the storage on the service side which should prevent anything else from accessing the same data unless its very deliberate. Thus, we simply drop the `store_id` parameter to `build_with_vss_store`.
|
Oops, fixed an issue but also pushed a new commit to drop the |
3 participants
