Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: FileNation – A simple way to send files using IPFS (filenation.io)
98 points by alexsicart 11 months ago | hide | past | web | favorite | 20 comments

Hi! My name is Alex Sicart and I have been working on a new way to send files using IPFS, so that everyone can benefit from this technology. With FileNation you can already send files in a more secure and efficient way using IPFS, a P2P hypermedia protocol. IPFS can save millions in bandwidth, right now FileNation pins files for free.

1 - Go to https://filenation.io/

2 - Click on Upload Files button. Locate the file that you want to upload and click open.

3 - Click on “Send Files to” and add the recpient email address.

4 - Click on “Your Email” and add your email address.

5 - Click on “Send”.

6 - The file will be added to IPFS and sent to the sender's email, keep page still open until Eternum has finished pinning :)

Try it out and tell me how I can improve it to empower more people with this amazing P2P technology :)

This is pretty cool, good job! I have a few questions:

* How long are you pinning files for?

* Is there a maximum size up to which you'll pin files?

Also, a tip: You can speed up your service by exposing the bridge on your pinning node. That way, your files don't have to go from node to node, the end user can just fetch them from your node's local pin store.

EDIT: Quickly skimming your code, it seems like you aren't uploading the files anywhere or pinning at all? Unless I'm mistaken, you're running ipfs-js and instantiating a node in the user's browser, which means that the user will have to keep the browser open for the file to be available, no?

I believe they're using Eternum's API to pin the content. I didn't look at the code, but the download link I got in the email is from https://eternum.io

Yes right now we are using Eternum API for the MVP to pin the content, but the next feature will be pinning in our server. Uploading the file to IPFS (front-end), then from the emai-server, downloading the file from hash to our own server and then connecting it to gateway https://filenation/ipfs/{hash} (everything in the same server to save a lot in bandwidth)

Ah yes, true. I missed that in the code, my TypeScript isn't great. Doesn't the page still have to stay open until Eternum has finished pinning, though?

Yes, it should take some minutes! I'll add this to new features. Thanks! :)

When I upload files do I have to assist in the P2P transfer of other files or is this supported by your servers? Is there any client side encryption planned ala Mega?

In your experience, how's the speed with sending and receiving files this way? I have relatively little knowledge about IPFS right now, but the last time I tried to access a site that claimed to be hosted in IPFS (accessing it through a gateway), it was so slow that it failed to load.

That is a constant source of frustration for us as well. We've been having problems where nodes intermittently couldn't discover other nodes, so content that was in one IPFS node would be unavailable on another.

I've spoken to a few people from the IPFS team, but they couldn't figure out the cause. Hopefully the next version makes discovery more reliable and fixes this (the files are quite quick to download once peers discover each other).

Yeah, I have two IPFS nodes, and had to make sure their swarm was bootstrapped with the IP address of each other. And even then, I still sometimes have to `ipfs swarm connect [ip_address]` after a reboot to be able to discover the content they have pinned.

Once they're connected, however, I haven't had any performance issues unless I was using IPNS. Though I only use IPFS to host static sites ( https://ipfs.poeti.codes/ipns/dreams.poeti.codes/ )

So, in a private ipfs network (connect to other peers who have a shared secret key) https://github.com/ipfs/go-ipfs/blob/master/docs/experimenta.... All the IPFS nodes are connected by default? Each peer pin files from other peers?

No, if I understand correctly, he just bootstraps the nodes from each other, making sure they are initially strongly connected. I tried that too, but it didn't reliably help the problem.

Yep, precisely! And if I'm having peer discovery issues with just two nodes, I can't imagine what you guys are having to go through. :/

For the curious: you'd run `ipfs id` on the nodes to get their addresses. Then you'd run `ipfs config edit` on them and add the other node's address to the bootstrap section. https://github.com/ipfs/go-ipfs/blob/master/docs/config.md#b...

But yeah... They'd still mysteriously not connect to each other at times.

Yep :( It's pretty disheartening to work on a product for some time and have the underlying technology just not work up to your standard.

Hearth is basically hit and miss for that reason, sometimes files show up right away and it's amazing, sometimes they time out and it's useless. Very frustrating, and there's absolutely nothing we can do about it.

I haven't looked at IPFS in depth but could this be because both the nodes are behind a nat and they need a relay node?

No, at least one wasn't. Plus, this happened even when they were directly connected.

Shameless plug: this is pretty similar to my https://filemap.xyz/ in its purposes and in the usage of IPFS and eternum.io, but Filemap kinda uses geographical locations instead of emails to "send" the files.

Their blog has more information about how it works: https://medium.com/filenation

Currently the "About" link goes to Github, which I found odd...

How private are files "sent" using this method? Doesn't the pinning node broadcast its hashes to the network?

I suppose a quick lookup to keybase for a gpg key (as it already asks for email), and then encryption with:


Would be one approach. Or, as a link is sent "out of band", I suppose one could simply provide a symmetric key in the email. Not as secure - but might be sufficient.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact