rust-libp2p-server as kubo alternative

[ottpeter]

Hi,

Is it planned that the development of rust-libp2p-server will be continued, until it is a viable alternative of kubo? rust-ipfs (https://github.com/rs-ipfs/rust-ipfs) is not maintained anymore, so there is not really an alternative for kubo, meaning, IPFS is centralized around kubo.

[ottpeter]

Max wrote me in an e-mail that rust-ipfs is continued here: https://github.com/dariusc93/rust-ipfs

[mxinden]

//CC @dariusc93

[dariusc93]

I do maintain the fork of rust-ipfs, which is up-to-date with rust-libp2p. While I cant really say its on-par with kubo, there is a lot of functionality in place to make it viable to use in individual projects (eg upnp, bitswap, dht, pubsub, dag and unixfs operations) while other parts are still a WIP (ipns publisher and resolver, which sits under a experimental feature, autorelay, connection management, etc), while allowing custom behaviours (though interaction might be limited at this time unless done via channels). I will say that rpc api is not really a priority for me with this project since it is designed to be embedded and direct, but I do have plans to build something to make it near compatible with the rpc api (with the aim of replacing the deprecated ipfs-http that was in the original project)

[ottpeter]

Thanks for all this info!
This seems a little bit of a problem, though. So, if there is a backup application, or any similar application, it won't be able to easily back up data if it is data created with software other then kubo? Is it a custom to use the same store? The folder structure kubo is creating looks like this:

├── api
├── blocks
├── config
├── datastore
├── datastore_spec
├── gateway
├── keystore
├── repo.lock
└── version

Would it be able to access the files that were created with rust-ipfs?

[ottpeter]

Probably best thing would be if backend side of IPFS-Backup would be in Rust. Then it would use rust-ipfs for IPFS, it wouldn't assume that there is a Kubo node on the server, would need to communicate with a React front end, and would need to call Filecoin smart contracts. Currently it is written in Express. Do you think that it is a good idea to switch to Rust, are there enough libraries to handle IPFS + Filecoin + REST API?

[thomaseizinger]

This seems a little bit of a problem, though. So, if there is a backup application, or any similar application, it won't be able to easily back up data if it is data created with software other then kubo?

Not meaning to step on your toes or anything, but if you code against an API that is only available in Kubo, then you've written yourself a Kubo backup application. I don't quite understand why you'd expect that to work with any other implementation of IPFS?

Probably best thing would be if backend side of IPFS-Backup would be in Rust. Then it would use rust-ipfs for IPFS, it wouldn't assume that there is a Kubo node on the server, would need to communicate with a React front end, and would need to call Filecoin smart contracts. Currently it is written in Express. Do you think that it is a good idea to switch to Rust, are there enough libraries to handle IPFS + Filecoin + REST API?

I don't have a lot of insight into how your project works but maybe some of your users would like to run Kubo themselves and only have your app integrate with it? One issue with an embedded IPFS implementation is that your app also needs to run continuously otherwise state changes are not going to applied. Thus, it may make sense to have a separate daemon. I don't know about the state of @dariusc93 rust-ipfs project but you could always write yourself a separate daemon that has exactly the API you need.

It is not uncommon for projects to support several backends. Your users would just have to specify, which one they want to use.

but I do have plans to build something to make it near compatible with the rpc api (with the aim of replacing the deprecated ipfs-http that was in the original project)

Perhaps you can collaborate with @dariusc93 on this :)

[kehiy]

hi @ottpeter
IPFS also has other implementations like Helia and ...

[ottpeter]

Hi @kehiy ,
Currently I'm using kubo-rpc-client to connect to IPFS, when developing IPFS-Backup. Here is an example line: https://github.com/ottpeter/IPFS-Backup/blob/master/backend/utils/backupUtils.js#L59
I would like to experiment with swapping kubo with a Rust-based IPFS daemon, and have IPFS-Backup continue working. If that can't be easily done, that would mean that applications similar to IPFS-Backup, are forced to use kubo. That's not really good, because that means that kubo is a single-point-of-failure.

[kehiy]

so, you can check this:
https://github.com/n0-computer/iroh

Also consider this you can use other clients, and I think the kubo-rpc-client should work with other implementations if they follow the IPFS protocol.

implementations:
https://docs.ipfs.tech/concepts/ipfs-implementations/

[ottpeter]

Thanks!
I don't think that this will be that easy. I thought this would be simpler. I think Iroh won't have the same API. I will try it when I install the new server.

[kehiy]

you're welcome.
check all implementations, I believe you can find lots of implementations that you can use instead of Kubo.

[thomaseizinger]

I think Iroh won't have the same API.

That is kind of expected. The important bit is that implementations are compatible on the network layer, i.e. libp2p. Which APIs are being offered greatly depends on the scope of your IPFS implementation. Kubo chose to offer an RPC API. Other implementations may offer other APIs or could also be designed to be directly embedded in your app and not as a separate daemon!