Mono Repo VS Multi Repo

[holzeis]

Thinking about how we want to setup the project integrated with the ldk stuff we need to decide if we want to go again for a mono or a multi repo approach.

The following diagram tries to depict my view on the target architecture. Please comment if you see it differently.

I am in favor of going for a mono repo like it has been done in ItchySats. We will be faster that way! I propose the following structure (aligned with the ItchySats naming for the sake of the argument)

• taker-frontend: everything flutter related, android, windows, etc. (no rust source code)
• taker: Basically the rust api for the taker-frontend, builds on top of the daemon. flutter bridge code will be generated from here into the taker-frontend.
• daemon: contains the common protocol, wallet, oracle, etc. implementation (based on the ldk sample)
• maker: starts the maker ldk node (daemon) and exposes additional http endpoints to fetch offers, trigger settlements, etc.
• ldk-bdk: We keep this in a folder within the 10101 repo until it gets stable enough to extract it.

I would keep the rust-lightning enhancement in a separate repo though. That will be easier to get up to date with the upstream if we want to do so.

[holzeis]

@klochowicz is in favor of keeping the ldk-bdk in a separate repository which is fine with me (still having concerns though). See corresponding discussion here get10101/bdk-ldk#1 (comment)

[bonomat]

I am in favor of going for a mono repo like it has been done in ItchySats. We will be faster that way! I propose the following structure (aligned with the ItchySats naming for the sake of the argument)

I agree with this. It makes development much faster. On our ldk-sample fork we initially decided to keep things separated (ldk-sample and rust-lightning) but realized that this is too cumbersome to iterate and hence decided for going for path dependencies. Since Lucas and me use the same folder structure this worked just fine, still, you need to pull two projects and it is not ideal. In our case though, we expect to eventually pull upstream patches down, hence, it makes sense to keep rust-lightning in a separate repository.

On the argument of keeping ldk-bdk outside so that we can easier push things upstream: this project does not seem to me like a library which is or will be kept up2date. It's more an example someone hacked together. I think we will benefit more from it if we move it where it is being used, i.e. within 10101.

[klochowicz]

in the spirit of being a good open-source citizen, I intend to contribute back to the community with updated versions of ldk-bdk and the ldk-bdk-sample. I don't think folding it into our project is fair in any way to the original author and it doesn't give us benefits either (again, this code doesn't change, and if it does, it's easier to test the changes in the sample project anyway without spinning the whole app). So, in terms of dev convenience, as the dev who's working on that very part of code, I say that the convenient part is to keep it as is.

[bonomat]

That's a good point and I agree with this.
For the time being and in the spirit of moving fast I would not concentrate on contributing things back but making things work.

There is one issue: the project you started using does not have a license, which means, we cannot even use it without being afraid of him starting to sue us.

See here: https://opensource.guide/legal/

Making your GitHub project public is not the same as licensing your project. Public projects are covered by GitHub’s Terms of Service, which allows others to view and fork your project, but your work otherwise comes with no permissions.

If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it’s public, unless you explicitly give them the right to do so.

[klochowicz]

I only read the licence info in Cargo.toml, which mentions license = "MIT OR Apache-2.0", so I assumed it was OK - I have indeed overlooked that. I have opened an issue in the upstream repository to see whether we can rectify this.

[bonomat]

Thanks for looking into it. I think this should be enough for moving forward.

[holzeis]

Conclusion of this discussion

• We go with a mono repo approach as this will save us time.
• Taker and maker will share a core library within the mono repo.
• bdk-ldk will be managed as a dependency.

Closing this discussion! Feel free to reopen if you disagree with the conclusion.