configurable max htlc in-flight limit (ldk #850) - ux implications for rgb dex swaps

[moakilodash]

hi @zoedberg

i ran into some ux friction points i'd love your guidance on.

with ldk's default max_inbound_htlc_value_in_flight_percent_of_channel sitting at 10% of channel capacity (made configurable via ChannelHandshakeConfig after rust-lightning - issue #850), users on a dex like kaleidoswap effectively can only swap up to ~10% of their channel in a single payment regardless of their actual balance.

right now the experience for a user hitting this ceiling is confusing, and at the end of it they either have to split their order or open a much larger channel just to accommodate a trade.

a few things i'd like your take on:

• is there a plan to expose ChannelHandshakeConfig::max_inbound_htlc_value_in_flight_percent_of_channel as a configurable option in rln, or will it stay at the ldk?

• if keeping it fixed, what are the concerns behind not raising it? (even to something like 20%) for rgb asset channels used primarily for swaps and not routing, the privacy trade-offs of a low in-flight cap feel less relevant. what are the concerns as for the limit here?

thanks!

[zoedberg]

Hi!

I think we can make this configurable by adding a parameter to the /openchannel API.
That said, it’s important to keep in mind the trade-off involved:

• higher cap: better UX for large single-shot swaps
• lower cap: reduced worst-case exposure when funds are tied up in inbound HTLCs, especially if the node is often offline

Since RLN targets advanced users, it makes sense for us to expose this parameter and allow node operators to tune it based on their risk tolerance and use case.

On your side, I’d recommend making this as a user-configurable option as well, together with a clear explanation of the trade-offs so users can make an informed decision.