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

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!

Start by reviewing ChannelHandshakeConfig in LDK and the configuration surface in rln, then read the linked rust-lightning issue #850. Done means documenting whether rln should expose the max in-flight HTLC percentage and explaining the implications for RGB asset channels and DEX swaps.