Rust library for connecting to the IPFS HTTP API using Hyper/Actix

You can use actix-web as a backend instead of hyper

ipfs-api

Components

Name Documentation Crate
ipfs-api-prelude
ipfs-api-backend-actix
ipfs-api-backend-hyper
ipfs-api (deprecated)

Rust library for connecting to the IPFS HTTP API using Hyper/Actix.

Usage

Using Hyper

To use the Hyper backend, declare:

You can specify either with-hyper-rustls or with-hyper-tls (mutually exclusive) feature for TLS support.

Using Actix

To use the Actix backend, declare:

Builder Pattern

With either the Hyper or Actix backend, you can specify the with-builder feature to enable a builder pattern to use when building requests.

Usage (DEPRECATED)

Feature Flags (DEPRECATED)

You can use actix-web as a backend instead of hyper.

You also have the option of using rustls instead of native tls:

To enable the builder pattern (default) use the with-builder feature:

Examples

Writing a file to IPFS

With Hyper
With Actix

Reading a file from IPFS

With Hyper
With Actix

Additional Examples

There are also a bunch of examples included in the project, which I used for testing

For a list of examples, run:

You can run any of the examples with cargo:

License

Licensed under either of

  • Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
  • MIT license (LICENSE-MIT or #404)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Issues

Collection of the latest Issues

nathan-at-least

nathan-at-least

good first issue
1

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.

nathan-at-least

nathan-at-least

0

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.

nathan-at-least

nathan-at-least

0

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.)

sergiupopescu199

sergiupopescu199

0

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

matthiasbeyer

matthiasbeyer

enhancement
2

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?

ec1oud

ec1oud

1

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.

jcaesar

jcaesar

2

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?)

raffomania

raffomania

5

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.

mikeal

mikeal

1

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.

abusch

abusch

1

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.

icefoxen

icefoxen

2

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.

Information - Updated May 14, 2022

Stars: 150
Forks: 51
Issues: 16

Rust bindings for libinjection

Add libinjection to dependencies of Cargo

Rust bindings for libinjection

CDRS is looking for maintainers

CDRS is Apache Cassandra driver written in pure Rust

CDRS is looking for maintainers

Rust bindings for the C++ api of PyTorch

LIghtweight wrapper for pytorch eg libtorch in rust

Rust bindings for the C++ api of PyTorch

Rust leveldb bindings

Almost-complete bindings for leveldb for Rust

Rust leveldb bindings

rust-analyzer is a modular compiler frontend for the Rust language

It also contains some tips &amp; tricks to help you be more productive when using rust-analyzer

rust-analyzer is a modular compiler frontend for the Rust language

Rust-Lightning is a Bitcoin Lightning library written in Rust

lightning, does not handle networking, persistence, or any other I/O

Rust-Lightning is a Bitcoin Lightning library written in Rust

Rust FUSE - Filesystem in Userspace

Rust library crate for easy implementation of Crate documentation

Rust FUSE - Filesystem in Userspace

Rust crate to implement a counterpart to the PBRT book's (3rd edition) C++ code:

Some images of the test scenes are shown below, but you can find more

Rust crate to implement a counterpart to the PBRT book's (3rd edition) C++ code:

Rust Persian Calendar

1** provides functionality for conversion among Persian (Solar Hijri) and Gregorian calendars

Rust Persian Calendar

Rust DjangoHashers

A Rust port of the password primitives used in alternatice implementation: the package library that requires OpenSSL

Rust DjangoHashers

The arkworks ecosystem consist of Rust libraries for designing and working with zero knowledge succinct...

This library is released under the MIT License and the Apache v2 License (see License)

The arkworks ecosystem consist of Rust libraries for designing and working with zero knowledge succinct...
Facebook Instagram Twitter GitHub Dribbble
Privacy