LSPS: Add optional client_info field for client and node identification#69
Open
kaloudis wants to merge 1 commit intolightning:masterfrom
Open
LSPS: Add optional client_info field for client and node identification#69kaloudis wants to merge 1 commit intolightning:masterfrom
kaloudis wants to merge 1 commit intolightning:masterfrom
Conversation
28 tasks
Contributor
|
Hmm, to be honest I'm not super convinced we should do this, as it definitely has drawbacks w.r.t. privacy and introduces the risk of being abused as a form of 'version negotiation' field, i.e., services might use this to opt into a proprietary superset of the spec, leading to even more fragmentation across the ecosystem.
Do you believe this really won't happen once this is introduced? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
client_infoobject to LSPS0 Common Schemas (bLIP 50) for identifying client applications and node implementationsclient_infofromlsps1.create_order(bLIP 51) andlsps2.get_info(bLIP 52)app,app_version,node,node_versionMotivation
LSPs currently have no standardized way to know which client applications or node implementations are using their services. Some implementations work around this by overloading the
tokenfield, but this conflicts with its intended purpose (discount codes, API keys). A dedicatedclient_infoobject cleanly separates client identification from authentication/authorization, enabling better debugging and analytics without sacrificing thetokenfield.Design Decisions
"0.13.0-beta1"is valid)