After a torrent has finished downloading, make possible to (automatically) import its file/folder to a local IPFS node

[hollownights]

Following the idea of making Frostwire more IPFS-friendly, I propose that it should be possible to import a downloaded file or folder directly from Frostwire to the users’ local IPFS node, pinning it to the node, and even better if this can be set up to be done automatically. Such a behavior, combined with IPFS URLs used as webseeds (#996), would make for a more decentralized and resilient web with better interoperability between a decentralized web protocol (IPFS) and a decentralized but “files-only protocol” like BitTorrent.

Relevant links:

https://docs.ipfs.tech/basics/desktop-app/

https://docs.ipfs.tech/reference/kubo/cli/

https://docs.ipfs.tech/reference/kubo/rpc/

P.S.: I am not a developer, so I’m here as a user to propose such a feature, discuss it and test if it gets implemented.

[hollownights]

Here is a real situation when being able to easily import a downloaded file or folder from a BitTorrent client into a local IPFS node without duplicating the files or the need to use command line would be of great help: importing big dumps of files from a library repository. Below, two different posts from two different projects that describe this exact situation.

IPFS Free Library

Help seed Z-Library on IPFS

[gubatron]

I've played with IPFS in the past, I like your idea for integration and I think it woulnd't be that hard if the local IPFS has an HTTP RPC interface where we can tell it:

"Hey, add the file at this to your index and do your thing..."

We could have a new Settings > IPFS screen where you could:

• Enable/Disable the integration
• Specify the IP:PORT where the local IPFS server should be notified about a new file

Does that sound logical?

I'll install IPFS on my workstation to have a better sense and get back to you.

Thanks @hollownights for this idea, it's awesome. We're all for decentralization and content resilience to fight censorship and level the playing field for the have nots.

[hollownights]

@gubatron Hi!

it woulnd't be that hard if the local IPFS has an HTTP RPC interface

That's the good part: IPFS Desktop has an HTTP RPC interface, no other software needed! I've tried playing with it a bit, but I am just too bad with command line and couldn't do much with it.

"Hey, add the file at this to your index and do your thing..."

We could have a new Settings > IPFS screen where you could:

* Enable/Disable the integration

* Specify the IP:PORT where the local IPFS server should be notified about a new file

Does that sound logical?

Totally logical and, in fact, that's what I had in mind. I've been doing the rounds through BitTorrent clients to see if anyone would like to implement this feature, and that's pretty much what I proposed for Transmission:

Plus, I do think this should be a native setting within Transmission with a checkbox for "on/off" and fields to inform the port used for the local API or the location to an executable.

I'll install IPFS on my workstation to have a better sense and get back to you.

Thanks @hollownights for this idea, it's awesome. We're all for decentralization and content resilience to fight censorship and level the playing field for the have nots.

I'm glad you liked the idea and it would be awesome if Frostwire was the first BitTorrent client to implement such a feature. It's been a while since the last "breakthrough" on BitTorrent (I have WebTorrent in mind when I say this) and bridging the gap between BitTorrent and IPFS could be huge.

[gubatron]

As for IPFS webseeds, to FrostWire IPFS files served by HTTP gateways look no different than regular webseeds.
This is up to the users creating torrents if they should add webseeds.

My only question is "Does IPFS have IPFS hash ids for entire folders?", most torrent files refer to entire folder structures, very few torrents are about a single file, which could be the only webseed integration we could guarantee since the pointed IPFS webseed URL would work for only a single file at the time.

That aside, this is how I think torrent creation would be like.

Perhaps in the Torrent Creation dialog we could have something to automate this process by doing the following:

If the IPFS integration is off or if it's on but we can't reach the local ipfs server do nothing.

Tell the IPFS local server to announce the file pointed by the torrent, once it responds (whether it has indexed that file in the past or it just did it) with the IPFS hash, we can use this hash to create a few different webseeds using well known IPFS gateways.

If IPFS works like we think, when a user requests this torrent, their torrent client will try to fetch the file from the IPFS gateways (along with the bittorrent mechanisms), and the gateways should query the file using that ID, and our localnode should talk to IPFS about the file and share it.

[gubatron]

This would indeed help with network uptime and cross network content seeding.

[gubatron]

even better would be to make sure every FrostWire instance is an IPFS node too.

[gubatron]

every file you seed, is also announced and seeded on IPFS, perhaps even indexed for distributed search

[gubatron]

We have a migration to bittorrent2 next on our list, this is a very important ticket.
But IPFS integration sounds very interesting.

[gubatron]

This could be a way for us to integrate an IPFS node if it's lighter than the official golang implementation
https://github.com/ipfs-rust/ipfs-embed/

[hollownights]

As for IPFS webseeds, to FrostWire IPFS files served by HTTP gateways look no different than regular webseeds.
This is up to the users creating torrents if they should add webseeds.

Yes, I know. With #996 I'm not talking about changing how torrents are created, but really just better handling an IPFS public gateway URL as to not overload the gateway and to actually make use of the IPFS network by getting the files through a local IPFS node. The only situation I have envisioned that would impact torrent creation is the one I've proposed for PeerTube.

My only question is "Does IPFS have IPFS hash ids for entire folders?"

It does, but I have not tested what is the response for a folder and how the client behaves when faced with it. I only tried it single-file torrents like these ones: https://bin.infini.fr/?9cdb2d48dcd2aa83#8PUoWjief34tCVyqFi6giSzRhfmn5MQodG4vpYciwzjE

every file you seed, is also announced and seeded on IPFS, perhaps even indexed for distributed search

The way IPFS works, which is much more like how a web server works, I think it is more logical when the opposite is done: first a file is imported to IPFS, then it is added as a webseed in a torrent. In fact, that's what I proposed for PeerTube (see the link above).

[gubatron]

Yes, I know. With #996

oh there's another Issue :), sounds like you want FrostWire to have a webserver to serve files if the seeds in a torrent look like an IPFS URL, interesting. Not sure if this would be doable for things like, what if we can't serve on port 80, or on whatever port the seed URL says.

It does

That's great news!

[hollownights]

sounds like you want FrostWire to have a webserver to serve files

I think you got so excited with such a feature that you are taking it a little too far already haha. No, it isn't a webserver and it really is as "dumb" as it reads: did Frostwire find a IPFS-like URL being used as webseed? If yes, rewrite the URL to try and get the file through IPFS.