This repository was archived by the owner on Jan 6, 2025. It is now read-only.
LSPS2: Further client-side simplifications #100
Merged
Conversation
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
.. and expose it via the corresponding event. This allows the client to track which previously-made request an event corresponds to.
.. and expose it via the corresponding event. This allows the client to track which previously-made request an event corresponds to. It also allows to drop our requirements and additional bookkeeping around `user_channel_id`.
.. since it's aruably not needed now that we more and more decouple the fee-request and buy-request stages.
.. as it's implied and we won't support LSP-trusts-client anytime soon.
johncantrell97
approved these changes
Feb 5, 2024
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
We previously simplified the client-side flow and reduced the amount of superfluous tracking in #88. However, this also removed an easy way for the client to clearly associate events with the previously made requests.
In this PR we go a step further and:
a) Return the
request_idfromrequest_opening_params, re-introducing the means to associate requests/events, without the need for additional tracking ofuser_channel_ids or similar.b) Return the
request_idfromselect_opening_paramsand use it to track the requests everywhere, allowing us to dropuser_channel_identirely. This doesn't only mean we don't have to keep track of it separately, but also that we don't have to expose an API that might be misused, requiring us to check and document the uniqueness properties of the identifiers.c) Since we now ended up with essentially a single client side state, we drop the
InboundChannelStatetracking entirely.d) We commit to not support 'LSP-trusts-client' mode any time soon and just remove it from the API.