Java-ipfs-http-client - is this project supported anymore?

I recently started to use java-ipfs-http-client

I was creating some basic unit tests in Java to test functionalities.

It seems like basic functionality like:


is throwing exceptions due to unsupported Codecs.

I left a ticket here:

To me it seems like the project is inactive. I can help support this project if some people help me out at the beginning.

My questions are:

(i) can someone help me with my immediate issue above

(ii) is there anyone who can help me get started supporting java-ipfs-http-client ?

(iii) is java-ipfs-http-client out of date and inactive?

Java is an important language so I think that we should maintain java-ipfs-http-client to promote IPFS.

Thank you

I cloned java-cid and changed pom to:


Then I ran:

mvn package

Then I added the following to my pom.xml:


I basically overode the version of cid dragged in via java-ipfs-http-client and its java-multiaddr

Now it works.

This has wasted some time.

Who can release a new release of java-cid with the master code and then update the poms of:


and other dependencies?

Basically the production releases are broken.

The master of java-cid fixes the issue but a new release is required to absorb the fix.

Who can do another release - big please :wink:

Or can someone give me permissions or show me how to do the release.

Thank you

Hi @javaspeak,
I am interested to contribute to the java client. More specifically I am looking to implement IPFS for Android. Both client and provider sides.
So there will be an Android app that people can install and contribute to file hosting. In the same time make it easier for app developers to utilize IPFS in their apps. It enables many interesting projects I believe.

I took a look at API today and its very basic and have few bugs. I do not recommend it for production use.

I had an idea to integrate IPFS into Java app but with code like that its not going to happen. Project seems dead, people complaining about quality on forums. JS-IPFS is viable alternative.

Sorry Yasharpm,

I did not notice the email notification for your message among all my spam email - hence the 5 day delay.

Before writing / maintaining / rewriting the http client API we need to do the following:

(i) Find the people of all the dependent projects and make sure that all projects are dead.

(ii) Contact all people from forked projects and see if they are active or not.

(iii) Look at the existing code and see which code we would like to use and what needs improvement or replacement.

Despite what hsn10 wrote, I did get the code working. Once I republished a dependent maven project locally with the head / master code, all my unit tests passed for the functionality I need IPFS for. I therefore do not find the code that bad as my tests passed. My tests were the benchmark test of whether I should implement the http client for IPFS in java myself or use the one of ipfs-http-client. Writing the http client for the API will take time so it is a balance of time.

I urge you ( yasharpm ) to first write the tests for the functionality you want to use of IPFS and then test whether you get the expected results.

I am no expert of IPFS - I am possibly using it in ways that have never been explored before - however I have not had enough time yet to explore the internals fully. I found the code for the cid bit to be a confusing. There was some bitwise code there that I would need to better understand before I can write a better implementation.

Therefore in order to JUSTIFY a rewrite of the http client we would need some of us to be good bitwise devs with time on our hands.

Also I noticed in the code that there is support for different CID formats - infact that was why the release code is not working because a dependent project had a new codec added to the master head but that code was never released and the poms of the dependent projects not updated.

In order to rewrite that part of the code I would need to access docs of the different codecs. We would need to research if there are docs available telling us what all the codecs are and what the format of each codec is. If you have time you can research this.

If you do decide to write some unit tests to test the code, I can also send you my tests.

Thank you

Hi hsn10,

When you wrote: “JS-IPFS” is a viable alternative - how can it be a viable alternative if we want to write our app in Java? Do you have a way you will use JS-IPFS from Java?

I thought the only way we can write an app that talks to IPFS from Java is to:

(i) Use an http client to the API - either use an existing one or implement our own one.

(ii) Install IPFS locally and access it executing command line commands. I am not sure if there is a project that has created a wrapper for command line IPFS commands. It would use Java classes like Runtime to execute the underlying commands. The wrapper could also parse the output. This is a bit of a messy solution but possible.

Did you check if someone has implemented a http client for the IPFS API in Kotlin to use in your Android app?

To me I see Java as a very used language - it seems MORE than strange to me that the projects seem not maintained and that the last changes on master / head of a dependent project which actually allow IPFS to work were NEVER released. It is almost like there is some big bad Wolf out there that wants to stop all but the most persistent people from using IPFS with Java in cool ways. :smile:

In my tests the only thing that I found not that cool was that when I was publishing a resource using IPNS the request takes a long time to get a response. In fact I had to increase the timeout. There was a method for changing the timeout without creating a new connection object but the code did nothing when I looked at it ( a bug ). It seems to me there is no callback in the API - it would be nice if we make the call to publish an IPNS resource and in the call we pass a callback URL - however it seems the API does not support this.

I know very little about the IPFS. But I’d love the idea that users can have their files hosted and shared for free!
I guess implementing an IPFS Java node is too big of a task! That would be even more amazing to exist.
May I ask, what is the idea that you are using the IPFS for?

I use nodejs to run js-ipfs based storage driver and then have microservice api exported for java.

@yasharpm I wanted to add some nuance to your enthusiasm about “files hosted and shared for free”. While technically true, you can host and share them for free, that sentiment seems to be leading people to believe that files are automatically replicated across the IPFS network and persisted in perpetuity at zero cost.

It would be nice if IPFS could come up with a better story to explain what it is. People get hooked with punchy lines like “hosted and shared for free” and then are inevitably let down by the detailed explanation of what exactly that means. There’s nothing incorrect in all of it but it’s like having to explain the punchline of a joke. Once you’re at that point you might understand the joke but you’re not going to be laughing and it’s not going to make you laugh.

I’ve also looked into Java support and posted a couple of questions to this forum about it but never receive any replies. My very cursory look at the java libraries are that they look like a direct port from the go code and are very idiosyncratic. There is a Kotlin implementation of libp2p the page is very confusing about where the project is at. It says “this is have work in progress!” but then lists out a roadmap for minimal phase v0.x with everything checked off but they seem to release often with one last week a 0.8.7

Textile has grpc-ipfs-lite and there’s some other stuff scattered here and there.

Peergos is written in Java so it might be worth taking a look at what they have.