Reference IpfsCore as a submodule

[erikmav]

As a smaller version of the work attempted for ipfs-shipyard/net-ipfs-core#16 instead of pulling in all of the C# repos to one place, just combine this repo and net-ipfs-core into a single repo. This repo's code and Core need to almost always be in sync, and we need to either combine or add Core as a submodule in this repo to make it easier to develop across both.

Also use central package versioning in the combined repo to avoid having to maintain dependent package lists in 4 csproj files.

[Arlodotexe]

When we migrated from Richard's repositories, we kept these separate because other people may still implement the Core API without knowing or caring about the HTTP client.

net-ipfs-http-client is currently the only library (that I know of) which implements the net-ipfs-core. This is "fine", our only good and up-to-date option is to bootstrap Kubo, which works with the HTTP API.

But in the future, I expect to see these implementations for net-ipfs-core:

• .NET bindings for gomobile-ipfs that works on (at least) Droid / iOS
• .NET bindings for ipfs-wasm, whenever that project is ready.
• Anything created by the IPFS community. Could create a libp2p-sharp and try from scratch, or try reviving Richard's net-ipfs-engine.

I need those first 2 for my own projects, but seeing ipfs-wasm come to .NET would be a near-perfect option. Full managed access to IPFS and libp2p, no bootstrapping or API overhead. The same code running everywhere, and someone to maintain it.

So while combining the repos seems like a good idea now, it would make it harder to grow the IPFS ecosystem for .NET in the long run. The need for dual-PRs will slow as we get things tidied up and brought into 2023

[Arlodotexe]

That said, unlike in the net-ipfs-core library, we aren't closing this off yet.

It's a very good point that we could just use a submodule. Tooling on submodules has come a long way in recent years, it would make development much easier.

Let's consider the implications before moving forward, though.

• What kind of problems could we run into if we did this?
• Or, are there any good reasons to keep using the nuget package over the submodule?

My time is short today, so I'll come back to this later. Things to think about.

[Arlodotexe]

We have CI in both repos, the effort needed to update the NuGet package is negligible.

Additionally, avoiding submodules means we must use a published version of the NuGet for net-ipfs-core, which we should expect as a requirement since using net-ipfs-http-client will be pulling in a published version of net-ipfs-core, and it must be on NuGet.