Background

The original repo from Richard Schneider published packages to nuget, making it a lot easier to use the code in your projects.

The problem

Since Richard is no longer around, the packages that were published to nuget.org under that account cannot be updated anymore.

The solution

There are two options:

• Contact nuget and see if ownership can be transferred (WIP)
• Publish under a new package name but keeping the same namespaces and assembly name for easy updating.

Problem

There's no APIs for interacting with the Filestore in any way.

• HTTP equivalent of ipfs filestore * is missing.
• The HTTP equivalent of ipfs add --nocopy is missing.
• The HTTP equivalent of ipfs add --fscache is missing.
   

Solution

Add the missing APIs.

• Our IFileSystemApi.AddAsync API methods use an AddFileOptions parameter to specify options, which should be where --nocopy and --fscache are implemented.
• Add a new IFilestoreApi to ICoreApi in the net-ipfs-core repo and implement in IpfsClient in the net-ipfs-http-client repo.

See also ipfs-shipyard/net-ipfs-http-client#37

Having a strong name avoids warnings from strong-named consumers of the main assembly.

• Refactor Core\ipfs.snk to a common location
• Enable strong name signing in Core.csproj

The problem

The project does not have an EditorConfig. There is no IDE guidance in terms of code style.

The solution

To keep things clean for all developers on this project, we need to set up the .editorconfig file so Visual Studio and Rider automatically follow the correct coding conventions.

Here's what I think we should do:

1. Merge https://github.com/richardschneider/peer-talk
2. Merge https://github.com/ipfs-shipyard/net-ipfs-http-client as well
3. Rename this into ipfs-net (maybe)

By default, Kubo will return "Self" as an IPNS key, using the identity of your own node. The problem is that turning a string into a MultiHash always tries to convert to Base58, which identity hashes are not.

To repro:

new MultiHash("k51qzi5uqu5dj38iif6tbbg7embsfa3l5yk4ld8e2c9n3obgk41n7ot7nepp6l");

Output:

...threw an exception of type 'System.InvalidOperationException'. "invalid character: l"
at SimpleBase.Base58Alphabet.get_Item(Char c)
at SimpleBase.Base58.Decode(String text)
at Ipfs.Base58.Decode(String s) in .\net-ipfs-core\src\Base58.cs:line 69
at Ipfs.Base58.FromBase58(String s) in .\net-ipfs-core\src\Base58.cs:line 84
at Ipfs.MultiHash..ctor(String s) in .\net-ipfs-core\src\MultiHash.cs:line 223

This is especially problematic because the default node will throw if you try to retrieve the ipns keys.

Overview

We're forking and maintaining the amazing work done by Richard Schneider, who appears to have permanently logged off since November 2019.

To support IPFS in the .NET ecosystem, I'll be maintaining this repo and the net-ipfs-http-client repo, approving PRs, and generally helping the community pick up where Richard left off.

First steps

The library is 3 years out of date at this point, so we (as maintainers) are prioritizing bringing it into 2022 before anything else:

• Consolidate TargetFrameworks to netstandard2.0 and updating tests to net6.0 LTS - #1
• Generally update and consolidate dependencies where possible - #5
• Move to GitHub Actions - #3
• Create issue and PR templates, making it easier to file issues
• Publish a Nuget package with the same namespaces, but under a different package name - #6

How to contribute

The codebase is old, and many things are broken in the latest IPFS release (0.0.13). It'll take some time before we can get updated code into your hands again.

If you'd like to help out:

• Feel free to migrate your tickets from Richard Schneider's repos.
• Open issues for any problems you can find with the latest v0.0.13 IPFS release!
• To coordinate work, please open an issue BEFORE opening a PR
• If you'd like to work on something, ask in a comment. A maintainer will assign you to work on the issue if appropriate.

Nullability is a newer feature of C# that helps reduce bugs in caller code as well as within the library code. It can also help avoid the need for excessive null checks and ArgumentNullException by letting compile-time assertions provide enough of a guarantee on correctness from the caller.

• Enable <Nullable>enable</Nullable> in a global property in Directory.Build.props at the repo root.
• Fix all warnings ("get clean")
• Change the nullable warning to an error ("stay clean")

The problem

The Core API does not have a way to interact with MFS.

The solution

Create a new interface and the types needed for interacting with MFS via the Core API. This includes all endpoints under /api/v0/files/.

Reference:

• https://docs.ipfs.tech/concepts/file-systems/#mutable-file-system-mfs
• https://docs.ipfs.tech/reference/kubo/rpc/#api-v0-files-ls

The problem

Since this project was last maintained, several APIs in Kubo have been marked deprecated, but were not marked [Obsolete] in our API.

The solution

Go through all deprecated rpc commands and mark the corresponding methods / classes as [Obsolete] in our codebase.

Background

We're forking and maintaining the amazing work done by Richard Schneider, who appears to have permanently logged off since November 2019.

To support IPFS in the .NET ecosystem, I'll be maintaining this repo and the net-ipfs-http-client repo, approving PRs, and generally helping the community pick up where Richard left off.

First steps

Before we can have PRs rolling in, one of the first things we need to do is consolidating our TargetFramework to netstandard2.0.

There's a few reasons for this:

• net45 has since reach end of life
• netstandard1.4 is starting to show its age (also just not recommended anymore)

Checklist

• All TargetFrameworks have been removed, except for netstandard2.0
• All compilation conditionals (#if NET45, etc) have been removed.
• Tests have been consolidated to a single .NET 6 project, referencing a single NS2.0 project

Steps to repro:

1. Run IpfsClient.Dag.PutAsync with an object that has a Cid
2. Inspect the returned dag entry in Kubo
3. Observe that the Cid is serialized into an inline string and not in a map with a "/" key -- so it looks like this: {"/":"Qmfoo"}.

This is required by ipld specs to form proper merkledag trees. It should be handle by the json serializer when performing dag operations.

Background

The ported library is currently using a combination of AppVeyor, Travic, Codacy, and a few more.

The problem

Rather than using 3 different DevOps services, we should stick to what GitHub offers out of the box

The solution

• Clean up and remove all devops related content in the repository

We also need GitHub Actions workflows that:

• Ensure the project builds successfully
• Runs Unit Tests

Greetings, I have been testing richard schneider's librarys as Id like to generate a CID that matches the IPFS clients CID without connecting to an IPFS node and storing the file (it will serve as a reference only),

I have tried net-ipfs-http-client with success but it does seem to connect to a remote HTTP api http://ipv4.fiddler:5001 if no URL is provided (I may be mistaken).

Below is my working code that uses the embedded daemon which works but as mentioned I do not want a IPFS daemon running on the same server that this C# code is running.

using Ipfs.CoreApi;
using Ipfs.Engine;

var ipfs = new IpfsEngine("this is not a secure pass phrase".ToCharArray());

for (int i = 0; i < 255; i++)
{
  var options = new AddFileOptions { OnlyHash = true };
  var fsn = await ipfs.FileSystem.AddTextAsync("hello world " + i.ToString(), options);
  Console.WriteLine((string)fsn.Id);
}

The code below shows I have had success generating a multihash but I cannot figure out how to wrap the file in UnixFS.
Ideally Id add an additional step and get the expected CID: Qmf412jQZiuVUtdgnB36FXFX7xg5V6KEbSJ4dpQuhkLyfD

byte[] prefix = { 0x12, 0x20 }; // 0x12 == sha256, 0x20 == size (always same size for sha256)
const string data = "hello world";

// multihash native calculation.
var BinData = Encoding.UTF8.GetBytes(data);
var sha256 = SHA256.Create();
var hash = sha256.ComputeHash(BinData);
var combined = prefix.Concat(hash).ToArray();
string result = Base58.Encode(combined);
Console.WriteLine("result: " + result);

Thanks

The larger repo after #16 will have package versions spread all over the various csproj files. Move to using a root-level Directory.Packages.props to make package upgrades much easier. See https://learn.microsoft.com/en-us/nuget/consume-packages/Central-Package-Management for documentation on central package management.

• Create Directory.Packages.props in repo root with ManagePackageVersionsCentrally set to true.
• For each PackageReference in each csproj, create a corresponding item in Directory.Packages.props at the latest of all version numbers across the projects. Remove the version number in the csproj.
• Ideally at this point upgrade all packages to latest from nuget.org.

Background

The library currently uses dependencies such as SimpleBase, BouncyCastle and a few custom implementations for various things.

The problem

The cs multiformats projects are now complete enough to cover all of our needs.

The solution

Remove dependencies on SimpleBase, BouncyCastle, gRPC, etc., and replace with cs-multibase, cs-multihash, cs-multiaddress, and cs-multicodec wherever possible.

After upgrading kubo to v. 0.18, I get this error when creating a new IPFS client.

Background

In order to make this project reasonably usable again, we need to be able to publish packages to nuget.

The problem

The package published by Richard Schneider cannot be updated. I went to extensive efforts to find out what happened to him. Using the last of his digital footprint, I check for obituaries, prison sentences, missing persons cases, and eventually talked to his old colleagues. It seems he decided to live off grid in late 2019, so there's no chance that Nuget will transfer package ownership for us.

The solution

We'll need to publish new packages.

So that we don't end up in the same situation as before, where we're unable to update packages because the maintainer disappeared, we need to either

• Publish under a "common" account where only a select people have access
• Publish under a personal account, but make sure all maintainers are listed as co-owners.

We'll also need to clean up all metadata in the project pointing to the previous author and his packages before publishing.