👋 📌 We're moving to the IPFS Shipyard

[Arlodotexe]

Quick links to the new repos:

• ipfs-shipyard/net-ipfs-http-client
• ipfs-shipyard/net-ipfs-core

---

Sadly, Richard Schneider appears to have permanently logged off in November 2019. These are still some of the best IPFS libraries available but have long since fallen into disrepair.

As a long-time .NET developer and IPFS enthusiast, I've volunteered to lead the maintainence efforts on ipfs-shipyard/net-ipfs-http-client and ipfs-shipyard/net-ipfs-core, which are imports of Richard's repos as they are now.

I'll be updating the library to work with the latest go-ipfs release (current v0.13.0), adding new features (like passing your own HttpClientHandler), cleaning up the codebase, approving PRs, and generally helping the community pick up where Richard left off.

Due to the insane complexity of the project, we've opted not to bring over richardschneider/net-ipfs-engine. If anyone is feeling up to the challenge, we should talk.

That's all. See you in the shipyard! 🚢

[Pandapip1]

I would definitely like to see net-ipfs-engine and peer-talk updated!

richardschneider/peer-talk#59 is the primary reason that net-ipfs-engine currently does not work. If that's fixed, there shouldn't need to be too many changes afterward to get it fully working.

[tsuckow]

net-ipfs-engine isn't the worst of it. peer-talk was/is in dire need of love. I did a lot of work several months ago to make DHT work in peer talk and be able to download an image in a test project

tsuckow/net-ipfs-engine
tsuckow/peer-talk

The test project that downloads a jpeg
tsuckow/CSharpIPFSTestApp

Richard 🫡 did some amazing code, but had an interesting style that should be refactored.

Edit: Facepalm, I just noticed you linked to my issue

[Arlodotexe]

@tsuckow @Pandapip1 I see you've done some work on getting Noise implemented, managed to get Peer Discovery working and fixed a couple things (including mplex).

I presume our goal is to maintain compatibility with Kubo. There's a long list of changes to Kubo, Boxo and libp2p since the last engine update, and I'm not sure how aligned it currently is. Mplex was removed in the latest 0.25.0, just as one example.

Looking around, we might consider joining efforts with NethermindEth/dotnet-libp2p instead. This library is in active maintenance and seems further along than peer-talk.

Regarding the net-ipfs-core and net-ipfs-http-client libraries in the shipyard, I've been maintaining these only enough to keep them usable with the latest version of Kubo. There are still questions surrounding whether or not we should split net-ipfs-http-client into two (one for the Kubo RPC API v0, one for the HTTP Gateway). The API surface for net-ipfs-engine (and consequently net-ipfs-core and net-ipfs-http-client) currently differs from Kubo in some places, and this is a good time to reconcile that.

We'll need more planning and coordination to bring the ipfs ecosystem in dotnet fully up to speed, and we'll need a place we can organize and plan.

We don't have a channel in the official IPFS Discord server (I tried when I first got set up in the IPFS Shipyard), but we do have an officially sanctioned #ipfs-shipyard channel in the UWP Community Discord server. This community has a small army of devs and app testers, as well as official presence from various teams inside Microsoft and Uno Platform (helpful for bringing this to mobile down the road).

This requires careful thought to do it well. Let's gather here for initial planning and coordination, and we'll go from there.