Project structure / Naming conventions

[tnull]

For now I created the following submodules in the crate:

• transport for LSPS0
• channel_request for LSPS1
• jit_channel for LSPS3 (possibly LSPS2 soon)

I however wonder if we should follow the namespacing introduced in the LSPSs and structure the crate along the lines of
crate::lsps0::.. etc.

A question arising from this would then how to deal with datatypes shared between LSPSs...

[tnull]

It seems current sentiment in the spec group is is to not have LSPS4 rename to LSPS2v2. It's probably therefore best to rename and restructure this crate along the lines of the LSPS numbers, i.e., have the modules named:
lsps0, lsps1, lsps2, etc.

Moreover, we should really rename the crate as a whole. Given we might want to upstream it eventually, we could consider already renaming it to lightning-liquidity-management or lightning-liquidity-tools.

I'd likely want to do this once #20 lands, and before we cut an intial alpha release.
(cc @johncantrell97)

[johncantrell97]

sounds good, can do the renaming and restructuring post merge. I agree the name of the crate is horrible. I think those suggestions are already much better but might be too broad?

I could imagine there being other liquidity management tools (swaps, liquidity ads, etc.) that might not belong in this crate? I guess they could end up in here?

[tnull]

I could imagine there being other liquidity management tools (swaps, liquidity ads, etc.) that might not belong in this crate? I guess they could end up in here?

Yeah, that's a good point. Given that we call the main object LiquidityManager, we might actually consider whether it could support these other Liquidity things if they were added eventually?

[jkczyz]

Moreover, we should really rename the crate as a whole. Given we might want to upstream it eventually, we could consider already renaming it to lightning-liquidity-management or lightning-liquidity-tools.

I'd opt for something short like lightning-liquidity. If you use a longer name, someone can come around later and take the shorter one and get more eyeballs / feel more canonical.

[tnull]

Alright. After discussion out-of-band, current sentiment seems to be to a) rename the crate to lightning-liquidity, b) rename the modules to use the lspsX format, and c) to further modularize and expose the codebase so that, for example, third parties can opt to just reuse our message types/serialization, or, just a specific LSPS implementation, preferably in a non LDK-dependant manner. To this end we'll need to make sure that not too many LDK types leak into the 'inner' part of the codebase.

As there seems to be consensus on this, I'm closing this and will reopen issues to track these action items individually.