My current goal is to learn how to create and consume linked DAG nodes with serde. An example that spells this out would go a long way, because mapping between the general IPFS HTTP RPC documentation, the IPLD guides, and the ipfs_api crate docs is cumbersome.

The docs for [IpfsClient::dag_put aren't clear about which IPLD format multicodec is used.

For comparison, the js-ipfs API docs for ipfs.dag.put present an option for selecting the IPLD format.

Imagine a developer needs both a JS client and a rust ipfs_api client to interoperate. To do this, at minimum the ipfs_api needs to document which format is used, then the more flexible JS api would need to be modified to match. OTOH, if IpfsClient::dag_put allowed selection of the format, then either implementation could change to interoperate with the other.

As a rust dev new to IPFS, it's not clear to me from the IpfsClient::dag_put docs how to publish linked nodes.

Improve the doc example to show putting two nodes, where the parent node links to a child node with a CID.

This might live in ipfs-api-examples/examples/dag.rs, or directly in the dag_put doc comment if it's concise enough.

(This came from #76 but I thought it would help to have a separate specific ticket.)

I'm unable to successfully call IpfsClient::object_new.

With the following code:

-I get the following output:

Hi I wanted to know if this library support also the ipfs cluster

Hi, maybe I am misunderstanding something, so I am not sure whether there's an obvious reason why not, ... so why doesn't this crate use the cid crate for the content ids and instead uses String in its API?

The IPLD data model is a superset of JSON: it should be OK to store binary data. So on the command line, ipfs dag put --input-enc cbor actually works. It's another option that this Rust implementation could perhaps support. Do you think it's doable? It looks like there's a pervasive assumption that the data is json.

The http API is asymmetric though: there's no way to read back cbor AFAICT ( ipfs/go-ipfs#4313 ), so until that is done, perhaps there's no point.

I tried to force a byte array into a string, and ran into the problem that Rust expects every string to be valid UTF-8. If I use serde_json::json!(unsafe { String::from_utf8_unchecked(buf) }), it fails at runtime. So it seems the json API is hopeless for dealing with binary data in DAG nodes.

The reason I want to do that is to directly store a contiguous array of numbers into a byte array, to avoid cbor overhead. An array of numbers in CBOR has a one-byte prefix in front of each number to declare the type. If you already know what the type is, that's a waste of space, and prevents passing the array unconverted to other software (for example to draw a line graph). So I'd rather that the dag node uses cbor to annotate the expected data type, and then the actual array of numbers should just be a binary array. It's fine to construct CBOR that way, but getting it into and out of dag nodes is problematic so far.

The title actually says it all, but: Various getters return asynchronous streams (async_ftp::FtpSream::retr in my case, but so does e.g. cat — seems unfair to return something the library itself doesn't accept), and those cannot be easily passed to functions like add. Buffering in memory or temporary files may be expensive or even infeasible, depending on the size.

So it would be nice if some form of async stream could be passed to add and friends.

(This requires changes to rust-multipart-rfc7578, I think. I hope not to hyper, too?)

When using add, AFAIK the data I pass in has to be moved into the method because the argument requires a 'static lifetime. This makes the following impossible:

What I want to do:

1. directly pipe stdout into ipfs, without waiting
2. then wait for the first command to finish and check if it returned status 0
3. then return the ipfs hash

please correct me if I'm wrong, but with a 'static lifetime I think there's no way to do this.

Hiya :)

In the IPFS org we’ve created a new group for maintainers of client libraries. This will make it easier for us to loop you into issues that may cause problems or necessitate changes in your client library.

If you could let us know the github usernames of all the active maintainers we can add them to the group and note them in the clients table.

Also, we have a great IPFS weekly newsletter. A few days before each edition goes out a new pull request is created in the repo. If you have any announcements related to your client library feed free to log a new issue in the repo or just comment on an upcoming newsletter pull request.

Hi! We are considering renaming the IPFS Client libraries, please read more at https://github.com/ipfs/ipfs/issues/374 and comment if you are onboard.

Hi,

while contributing to the shiplift crate, I ran into the problem of converting a Stream<Item = Chunk> into an AsyncReader so I could use the Framed / Decoder stuff from tokio-codec. After banging my head on it for a few days, I found your StreamReader implementation which works great, but I'd like to avoid copying/pasting it...

Given that it's not specific to ipfs, would you consider extracting it to its own crate, or ideally submitting it to the tokio project?

I'm happy to do some of the work if that helps.

Just a thought that I had while fixing a bug I'd made...

We have the request::ApiRequest type which specifies some data for the request type. It should be possible to make an associated type request::ApiRequest::Response to link the response type to a particular request type. Then the type of client::IpfsClient::request<Req, Res>() -> AsyncResponse<Res> could just become client::IpfsClient::request<Req>() -> AsyncResponse<Req::Response>.

That wouldn't have prevented the bug that I'd made, I would have just put the typo in a different spot, so I'm not sure if this will actually help rather than just bikeshedding. But maybe it could make life a little simpler?

...actually, now that I think about it, we might be able to make the ApiRequest::path() method be an associated const now. Though that might be more restrictive than we want? I dunno.