optional configurability of ChannelHandshakeLimits force_announced_channel_preference

[xsats]

Permit initialisation of UserConfig ChannelManager with force_announced_channel_preference option disabled, to allow the wallet to create either public/private channel irregardless of anouncedChannels default.

I agree with the discussion in #54 surrounding public channels on mobile (i.e. for non-routing mobile nodes there's likely no strong advantages) but I think it could still be advantageous to expose this option and permit a react-native-ldk app to override the forced-private setting on behalf of a user, if doing so could benefit them e.g. via additional liquidity, advantageous public routes and/or even the lure of offering up some of their ln float to earn some routing sats (admittedly in suboptimal routing node conditions).

[xsats]

In addition to the above, the availability of the force_announced_channel_preference is also useful for testing and exploring some different ldk-mobile-node use-cases.

[Jasonvdb]

Hey thanks for the contribution!
I'm happy to expose this and let the user decide and experiment here. But I don't think any sort of routing on mobile will be possible especially on iOS with the app's limitations. Perhaps with some hacking an android background process something can be done though.

I would also be worried about a mobile wallet that just flooded the network graph with channels that are not usable. Could make routing more unreliable for others. But yeah again nothing we could do to stop someone actually doing that if they really wanted to.

If you want to chat more about this with the LDK team we have a discord channel called react-native-ldk
https://discord.gg/aB5j4mZk . I think they could give better insight into this than me.

Add the kotlin side in I'll review 👍

[xsats]

Thanks for all your great work on this lib!

Yeah routing isn't a real focus just now but I still think this option is useful for hacking/testing and some possible unconventional applications of ldk on mobile. As you mentioned, this could allow apps/users to flood the LN with unusable channels via mobile, but that's nothing that can't already be done with ldk/LN alone. Also, I'd argue the onus is on the LN to be engineered to be resistant to low effort 'attacks' like this. Will leave that discussion for elsewhere in any case.

Thanks for the link. I've actually been lurking in the ldk discord for quite some time. Lot's of great discussion and incredible work by everyone.

AFAIK my latest commit should fix the typescript/kotlin types discrepancy I just introduced and make the force_announced_channel_preference option available and usable on both Android and iOS. Please let me know if I've missed something though.

[Jasonvdb]

Hey @xsats really sorry for not coming back to this earlier. I think at the time I was busy with a major refactor to LDK 114 which changed almost every line. I've since just exposed the entire LDK config so it can be customised as much as you want from the JS side when starting up LDK. https://github.com/synonymdev/react-native-ldk/blob/master/lib/src/utils/types.ts#L353