Copy of my message to the common group:

I think I have to multiply entities 🙁

The problem is that in rust world you have to maintain small libraries (called “crates”) to have a modular design.

But rust crate not necessarily equals to a git repo. Today at LNP/BP Association we have >50 of rust crates to maintain, and it will be a crazy overload to have each one as a standalone repo. So for me, until now, Git repo was a unit of code access rights (the needs of the level of peer review) and logical architecture - while rust crates was a way of actual code modularization. This was solved through rust “cargo workspaces”, which allow to maintain multiple crates inside a single repo in an efficient manner.

Unfortunatelly, I came to a situation, when some rust logically-related crates (like lightning_encoding and lnp2p) stored in the same repo ( lnp-core ), become too distant in their rust dependency hierarchy, having crates from other repos inbetween themselves - which resulted in inabulity to have a single Cargo.lock file per repo. Thus, they have to be split into separate repositories for now - and we have to multiply the number of git repositories, which is very unfortunatelly.

Another dimension to that problem is the fact that GitHub org can have only up to 6 pinned repos, grabbing attention of independent contributors. In LNP-BP GitHub org we have more than 6 already, especially if I will split lnp-core repo into multiple ones. We had to separate before other GitHub orgs from LNP-BP (for RGB, networking, storm etc); now it seems the time has come for LNP (lightning-related repos).

So from today I will create a LNP-WG GitHub org and move all lightning-related crates to it, there splitting lnp-core into two repos, one for lightning_encoding and the other one for the rest of lnp-core. LNP Node will also be relocated to LNP-WG.

I would like to propose to move also this repo to https://github.com/LNP-WG. What do you think?

This removes the requirement to use std and alloc and provides them as features. However this is mainly intended as a way to add those features in a single breaking release and avoid breaking later.

The support still has a few issues:

• P2PAddress is not enabled without std, this is related to IP addresses being in std. See also https://github.com/rust-lang/rfcs/pull/2832
• ~~This introduces incompatibility hazard: one crate could turn on std while another turns on serde - the error types will fail to compile. This could be fixed by the upcoming weak dependency features but MSRV issues. :(~~ Fixed in followup commit Thankfully the incompatibility is trivial to fix but not sure if it's still a good idea. At least we have a warning about it.
• bitcoin integration is annoying because of that crates poor no_std implementation.

I'm making this a PR and will keep it open for a bit in case people have ideas how to do this better.

Closes #6

After better analysis it was determined that these features don't help with forward compatibility and only slightly improve convenience. The noise is probably not worth it.

bitcoin_* were somewhat more interesting because the bitcoin crate has sad no_std support but there's hope it'll be improved and even if not adding features is better than removing. (The features weren't released yet.)

Closes #10

https://github.com/rust-bitcoin/rust-bitcoin/pull/878#issuecomment-1079909613

There are probably other interesting constants. Note: we should focus on the interoperability constants - shared by multiple applications/crates, not protocol-only constants.