Skip to content

Conversation

johncantrell97
Copy link

Makes this LnurlAuth implementation usable for other purposes outside of vss. Perhaps it should be extracted to it's own crate instead.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Sep 11, 2025

👋 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.

@tnull tnull requested review from tnull and removed request for valentinewallace September 12, 2025 07:34
Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

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

Hmm, if we do this, we'd also need a way to expose the VssClient/LnUrlAuthProvider from LDK Node. Tbh. the only way I think we should do this is by doing a larger refactor upstream the VssStore implementation to lightning-persister (which we intended to do since the start, but never did), and have LDK Node simply take it as any other KVStore implementation (mod maybe keeping some convenience methods on the builder). Then users can build/configure the VssStore indpendently to their liking and just hand it into LDK node.

}

async fn get_jwt_token(&self, force_refresh: bool) -> Result<String, VssHeaderProviderError> {
pub async fn get_jwt_token(&self, force_refresh: bool) -> Result<String, VssHeaderProviderError> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Wouldn't you already get an exposed variant of this as part of the VssHeaderProvider::get_headers impl below?

If we make this public, this needs docs.

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.

3 participants