| title | description |
|---|---|
Publish using the command line |
Learn how to publish content with IPFS by pinning a file to a pinning service using the command line. |
:::warning Some steps of this guide are currently outdated due to changes with web3.storage. :::
Similar to the Publish a file with IPFS quickstart, this guide will teach you about pinning services and how to use them to publish content-addressed data with IPFS. However, instead of using the Web3 UI used in the related guide , you will upload the file to web3.storage using the w3 command line interface. By the end of this guide, you should have a better understanding of how content addressing and CIDs work from a high level, as well as how to use the w3 command line interface to publish data to IPFS.
:::callout The web3.storage pinning service was chosen purely for demonstration purposes, and is one of many pinning services you can choose from. While each pinning services has different SDKs and APIs, their fundamental role is the same - to store files and make them available to the IPFS network. In fact, one of the main benefits of IPFS is that files can be pinned to multiple pinning services, thereby reducing vendor lock-in. :::
Pinning refers to the process of ensuring that a particular piece of content is retrievable with IPFS. In other words, pinning is equivalent to storing a file on a computer or server that is connected to the internet, thereby making it available to the rest of the IPFS network.
Pinning can be done at various levels, from individual files to entire directories that are addressed by a CID. You can also pin CIDs to multiple IPFS nodes to increase the redundancy and resilience of the file on the network.
Pinning services are similar to hosting services, in that they run an IPFS node for you and ensure that your files are available to the IPFS network.
:::callout Data pinned to the IPFS network is public by default and retrievable by anyone. Avoid publishing private data or adequately encrypt it before publishing. :::
- A unix-like terminal.
- Node.js installed in the terminal environment.
- The following image, downloaded and saved on your computer:
-
Install the w3 command line interface.
npm install -g @web3-storage/w3cli
-
Authorize the w3 tool to act on behalf of the account associated with your email address
<[email protected]>:w3 login <[email protected]>
-
Create a space for your files.
w3 space create Pictures
-
Upload your file.
w3 up welcome-to-IPFS.jpg
Congratulations, you have successfully pinned a file to IPFS using the w3 cli! 🎉
Let's unpack what just happened, by looking at CIDs.
In IPFS, every file and directory is identified with a Content Identifier (CID). The CID serves as the permanent address of the file and can be used by anyone to find it on the IPFS network.
When a file is first added to an IPFS node (like the image used in this guide), it's first transformed into a content-addressable representation in which the file is split into smaller chunks (if above ~1MB) which are linked together and hashed to produce the CID.
In this guide, the CID for the uploaded image is:
bafybeicn7i3soqdgr7dwnrwytgq4zxy7a5jpkizrvhm5mv6bgjd32wm3q4
You can now share the CID with anyone and they can fetch the file using IPFS.
To dive deeper into the anatomy of the CID, check out the CID inspector.
:::callout The transformation into a content-addressable representation is a local operation that doesn't require any network connectivity. With web3.storage, this transformation happens client-side (in the browser). :::
Now that your file is pinned to a pinning service, you will fetch it using an IPFS gateway. An IPFS Gateway is an HTTP interface that serves as a bridge to the IPFS network. In other words, it allows you to fetch CIDs from IPFS using HTTP.
Pinning services typically offer an IPFS gateway as a way to easily retrieve your CIDs. For example, Web3.storage operates the w3s.link gateway, from which you can retrieve the uploaded CID.
To retrieve the CID, open the following URL: bafybeicn7i3soqdgr7dwnrwytgq4zxy7a5jpkizrvhm5mv6bgjd32wm3q4.ipfs.w3s.link
:::callout
When pinning a file to IPFS, the filename is not stored by default. To ensure the filename is retained, it's common to wrap the file in a directory. In such instances, both the file and the directory will have unique CIDs. Web3.storage wraps files in a directory by default, which is why you see a directory listing with the file welcome-to-IPFS.jpg followed by a shorthand CID: bafk…beom of the file.
:::
In this quickstart guide, you learned about pinning services, and how to use them to publish content-addressed data with IPFS. You also learned how CIDs address files and directories in IPFS by uploading a file to a pinning service called web3.storage.
Pinning services provide a convenient alternative to running IPFS nodes and infrastructure. However, the two are not mutually exclusive; you can combine a pinning service with an IPFS node on your computer to increase the resilience of your CIDs.
Possible next steps include:
- Check out the lifecycle of data in IPFS to learn more about how publishing by pinning fits into the full lifecycle of data in IPFS.
- Try fetching the pinned file by following the retrieval quickstart.
- If you prefer to upload a file programmatically with JavaScript or Go, check out the Web3.storage docs.
- Alternatively, try out Filebase, a pinning service that offers an AWS S3-compatible API for pinning, so you can use any S3-compatible SDK, e.g. aws-sdk, and many more.
- You can also try out Functionland Fula network, a pinning service that provides a true globally distributed and individually-owned nodes Fula Network. The SDK supports mobile-native applications and offers built-in encryption. As an example, you can checkout the FxFotos app, which is designed as an alternative to Media Sync applications GitHub Repo and live on Google Play