Can you push your content to the network and somehow provide incentives for the network to hold on to it with IPFS?

New to ipfs…Kindof amazed at what you guys are working on…

I know probably filecoin is supposed to be the incentivizing “layer”, but its not implemented yet publicly.

So are there any alternate ways of pushing content to the the network for storage?

I know of the pinning concept, but if the data is already available and stored on my harddrive, why would I want to use ipfs anyways? Maybe it will help me transfer data from one computer to another, but I already have a USB drive :slight_smile:

The goal is also to have content that works offline. For example, I like Stavros’ IPFessay, so if I want to use IPFessay to write when offline, I should pin IPFessay to my node. Sure, if I have it locally outside of the IPFS on my volume somewhere, I can always re-add it to my node, if I need it; but why have duplicates of files, one locally and one in the IPFS? That’s not necessary.

Because the philosophy behind the IPFS—at least the way I understand it—is to do as much as possible within the IPFS. Add data to the IPFS, and work with it from within the network. That’s what the ipfs files command and the mutable filesystem (MFS) is for. If you only use the default IPFS datastore, it’ll become a mess, if you have a lot of data on your node, added or pinned. But if you ipfs files cp your objects to the MFS, you have filenames, folders etc., and you can work from that. Sure, the IPFS is immutable, so it’s always read-only; for example, if you have a text file in your MFS, you can read & open it with ipfs files read TextFile.docx | open -f -a "Microsoft Word", and you can read the file in Word… you can even edit the file, but then you have to save it first outside of the IPFS, and then re-add it with ipfs add. That’s why it’s so important that developers implement IPFS support into their software, so they can read objects from the MFS, open them, and, after editing, save them not locally, but add the newly edited file directly to the IPFS (and the MFS) again.

In the end, if file managers also implement IPFS, then you will not notice an immediate difference between browsing through the IPFS (its MFS) and the local filesystem.

So, depending on preferences, future computer users will have a lot of their stuff in the IPFS by default. (Which is also, why built-in encryption is so important.) So in the future—at least I hope so—you’ll be able to share files via the IPFS directly from the Finder (macOS), Explorer (Windows) etc., with or without Filecoin.

Are there alternate ways of pushing content to the network? To my knowledge, no, not for permanent storage, unless you pay for it (future Filecoin or at 3rd-party services like Eternum) or persuade users to pin your file, or if you form an IPFS-based F2F network with software like Arbore. Temporary storage is possible, however, i.e. caching the file on gateway nodes. You can do that by downloading the file outside of the IPFS through an http gateway, e.g. curl -o downloadedFile<hash>, and then your IPFS object (your file) will be available from that node as well, but it’s gone when the node runs the garbage collection.


There is also the option of using ipfs-cluster to form groups of participating nodes who coordinate with each other to hold data they care about. For example, a network of research labs who all rely on each others’ data could use cluster to maintain redundant copies of all the data.

Among other things, using this approach to replication will

  • provide redundant useful copies of the data without requiring a single participant to foot the bill for storage
  • increase speed of retrieval because there are more sources providing the data
  • put copies of the data close to the people who are relying on it, making it easier to do things like bulk analysis

Those benefits of ipfs-cluster accure on top of all the benefits of using content-addressed protocols – citability, unambiguous identifiers to distinguish and/all versions of the data, cryptographic enforcement of data integrity, etc.


Hi Jay and Matt,

Thanks for pointing me to these resources… I am looking in these!