Skip to content

Conversation

@TheBlueMatt
Copy link

JWT-based authentication is currently largely the default due to
its integration in `ldk-node` indirectly via LNURL-auth. This is
great, but massively over-engineered (and requiring yet another
service devs have to set up and maintain) for just authenticating
to a storage service (and maybe an LSP).

Here we add a much simpler authentication scheme, based simply on
proof-of-knowledge of a private key. This allows for a simple VSS
install without requiring any additional services. It relies on
some higher-level authentication to limit new account registration,
but that can be accomplished through more traditional anti-DoS
systems like Apple DeviceCheck.

JWT-based authentication is currently largely the default due to
its integration in `ldk-node` indirectly via LNURL-auth. This is
great, but massively over-engineered (and requiring yet another
service devs have to set up and maintain) for just authenticating
to a storage service (and maybe an LSP).

In the next commit, we'll add an option for a much simpler
authentication scheme, based simply on proof-of-knowledge of a
private key and the service using the signing pubkey to identify
where to store data.

This then leaves authentication of installs to a higher-level (e.g.
a web proxy that validates Apple DeviceCheck attestations before
passing requests through to VSS).
JWT-based authentication is currently largely the default due to
its integration in `ldk-node` indirectly via LNURL-auth. This is
great, but massively over-engineered (and requiring yet another
service devs have to set up and maintain) for just authenticating
to a storage service (and maybe an LSP).

Here we add a much simpler authentication scheme, based simply on
proof-of-knowledge of a private key. This allows for a simple VSS
install without requiring any additional services. It relies on
some higher-level authentication to limit new account registration,
but that can be accomplished through more traditional anti-DoS
systems like Apple DeviceCheck.
@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Dec 29, 2025

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

@tnull tnull requested review from tankyleo and removed request for valentinewallace December 30, 2025 08:23
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.

Here we add a much simpler authentication scheme, based simply on
proof-of-knowledge of a private key.

I'm a bit skeptical of this approach right now. Generally there is no harm in supporting different authentication schemes, but we so far failed to establish a single standard authentication mechanism.

For that reason I'm afraid that adding more different authentication schemes could result in an even more complicated/confusion support matrix for users.

Any thoughts on that? Wouldn't it be preferable to commit to one scheme for now to finally establish a standard? Could you expand on why you couldn't just use the existing JWT auth for your usecase?

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