IPFS Getting Started Guide
Want to get started using IPFS, but not sure where to begin? This guide walks you through everything you need to know to use IPFS on Filebase.
The InterPlanetary File System, or IPFS, is a decentralized peer-to-peer protocol that enables nodes to store and transfer files between one another.
IPFS isn’t inherently a network itself, like other decentralized storage networks such as Sia. IPFS is a communication protocol that outlines the workflow and components that facilitate the IPFS network to exist. Software such as the IPFS Desktop client or IPFS CLI daemon provides IPFS nodes the ability to interact with other nodes running the same software, in return creating a network of peers that are storing and sharing files between themselves.
This section provides a brief overview of IPFS and how it works. For a detailed, technical explanation of IPFS, please review our IPFS Whitepaper:
IPFS is similar to HTTP, a protocol that is at the heart of how we use, create, and distribute content on the internet currently. IPFS is relatively new and has a wide range of different attributes and benefits in comparison to HTTP.
To bridge the gap between the two protocols, IPFS HTTP gateways combine the two protocols, allowing you to use and build with IPFS by accessing the IPFS network through HTTP requests.
Traditionally, when you access a webpage there are multiple protocols working together to deliver this website to you. First, the DNS protocol finds the IP address of the server that is tied to the domain name. Then, HTTP is used to request the website from the host server. This workflow is referred to as the client-server model.
While the client-server model is at the forefront of how we interact with and use the internet today, this model is centralized by design and therefore comes with risks such as unreliability, lack of resilience, and single points of failure. The client-server model puts all responsibility on the host server to ensure that the website is constantly available and accessible. If the host server is down due to an outage, disaster, or hardware failure, the website becomes unreachable and inaccessible.
Most notably, the HTTP protocol only sends your request for the website to the host server and doesn’t send your request to other servers that might be able to respond if the host server is down. This is a fundamental difference between HTTP and IPFS.
Another model for website and file hosting or storage is to use cloud providers, like AWS or Google Cloud. This is a common workflow for many applications, websites, and platforms where cloud providers create redundancy and high availability by deploying these assets over multiple servers through high-level abstractions such as CDNs or storage services. Typically, though, these servers are all located in one geographical location, most of the time within the same server rack or row. This means that while there might be more redundancy on the protocol layer, there isn’t redundancy for data center-wide outages, disasters, or human error like a cable being disconnected by accident.
The cloud provider solutions are proprietary to each cloud provider, meaning they are not standardized, open-source, or interoperable due to these solutions being deployed at the hardware or software layers instead of on the protocol layer. This creates a hard vendor lock-in that can trap customers into staying with one provider, even if it isn’t benefiting them as much as another provider could.
Another problem with big cloud providers is that since each cloud provider has such a large market concentration, outages or disasters often have a detrimental effect when something happens like a hardware failure, fire, or even a human error. Outages of this size often affect thousands of websites, services, and platforms, which can bring down even more services if they rely on any of the websites brought down in the outage.
IPFS is a peer-to-peer communication protocol, meaning instead of each client being connected to a host server like in the client-server model, each client (also referred to as a peer or node) is connected to every other peer to allow it to act as both the client and the server simultaneously. With this configuration, any peer can serve any requested file or website and be a productive member of the network to provide high availability, reliability, and resiliency to network outages or disruptions. With IPFS, peers are able to pool their resources such as storage space or internet bandwidth to ensure that files are always available, resilient to outages, and most importantly, decentralized.
IPFS is unique from other decentralized storage networks because it offers additional features and attributes such as content addressing, directed acyclic graphics (DAGs), and distributed hash tables (DHTs).
Data stored on IPFS is located through its content address rather than its physical location. When data is stored on IPFS, it is stored in a series of encrypted pieces, with each piece having its own unique content identifier or hash. This hash serves as an identifier and links the piece to all the other pieces of that data.
Identifying an object, such as an object or a node, by the value of its hash is referred to as content addressing. The hash identifier is known as the Content Identifier or CID. When objects are uploaded to an IPFS bucket on Filebase, the IPFS CID is listed in the object’s metadata for easy reference in any tool or application, or for use with an IPFS gateway.
Directed Acyclic Graphs are a hierarchical data structure. A graph is a way to display objects and the relationship between them. A directed graph is when a graph’s edges have direction, as depicted in the photo above. An acyclic graph is a graph where the edges have definitive ends and do not create a loop to other objects. Think of a family tree that shows ancestors and their relationship to one another. This is a good example of a Directed Acyclic Graph.
In this context, an object in a graph is referred to as a node and an edge refers to the relation between the objects in a graph.
IPFS uses Merkle DAGS, where each node has a unique identifier that is the result of hashing the node’s contents. Merkle DAGs are a form of self-verified data structures.
A distributed hash table (DHT) is a distributed system for mapping keys to their associated values. DHTs are databases of keys and values that are split across all the peers on a distributed network. To locate content, you ask a peer on the network, which will return a DHT that tells you which peers are storing which blocks of content that make up the data object you’re requesting.
Location addressing is used by client-server models and protocols like HTTP to address content based on its location on the internet, typically through IP addresses or file path locations. Location addresses have three parts, which are combined into a URL. These parts are:
- Scheme: This refers to the protocol being used to serve the address, which typically is HTTPS.
- Hostname: This refers to the domain name mapped to the IP address of the server, such as
google.com - Path: This refers to the location of the file on the server, such as /assets/images/image.png.
Altogether, a URL typically looks like this:
https://google.com/assets/images/image.pngLocation addressing can cause issues with serving content if the URL changes in any way, such as if the file name changes or the file path gets adjusted. Sometimes, the server may not even be hosting the requested file anymore, and you’re brought to a broken webpage or image.
This disadvantage is referred to as ‘link rot’. It is one of the main disadvantages of using HTTP/HTTPS. Small changes to webpages or URL structures can cause entire webpages to be renamed and accessed at a new URL, causing updates to be required in any configurations that use those static URLs so that they reflect the new location of the content.
IPFS uses content addressing, since a file can be hosted simultaneously across different IPFS peers, trying to identify it by one location can be counterintuitive.
Content addressing is when a file stored on a peer-to-peer network is addressed by the cryptographic hash of the file’s contents. In IPFS, this cryptographic hash is known as the content identifier or CID.
A CID is a string of numbers and letters unique to the cryptographic hash of the file or folder’s contents.
If a file is uploaded multiple times to IPFS, if the content of that file has not changed, it will return the same CID each time it has been uploaded.
Any change to the file’s contents at all will provide a different CID when uploaded. This assures that files uploaded to IPFS are immutable since any changes will produce a new, unique content identifier.
A single CID can represent either a single file or a folder of files, like a folder containing the files for a static website.
There are currently two different versions of IPFS CIDs - version 0 (0v) and version 1 (v1).
CIDv0 CIDs are the first format of IPFS CIDs that was part of the initial IPFS design. This version of the IPFS CID uses a base 58-encoded multi-hash to create the content identifier value. This method is simple but isn’t as versatile as the newest CID version, CIDv1. CIDv0 is still the default version for a wide variety of IPFS applications and operations, and it is recommended that you support CIDv0 in any development environment.
CIDv0 CIDs are 46 characters long and always start with the characters “Qm”.
CIDv1 aims to provide forward compatibility and support different formats that can be used with future versions of the IPFS CID. CIDv1 CIDs include:
- A multi-base prefix specifies the encoding method and format used for the rest of the CID.
- A CID version identifier specifies the version of the CID.
- A multi-codec identifier that indicates the format of the content that the CID aims to identify. This helps software and programs interpret the content once the content has been fetched from an IPFS node.
The first few bytes of a CIDv1 CID can be used to interpret the remainder of the CID and provide information about how to decode the content once it has been fetched from IPFS.
Currently, new projects are advised to use CIDv1 in their development since this allows the project to be future-proofed, and IPFS plans to set the default CID version to CIDv1 as the new default in the future. CIDv1 CIDs are also safe to use in browser contexts, such as through IPFS subdomain gateways.
When a CIDv0 is accessed with a traditional gateway, the domain will return an HTTP 301 redirect to a subdomain, converting the CIDv0 CID to CIDv1 CID.
For example, opening a CIDv0 resource using a traditional gateway at:
https://dweb.link/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnRreturns a redirect to a CIDv1 representation at:
https://bafkreidgvpkjawlxz6sffxzwgooowe5yt7i6wsyg236mfoks77nywkptdq.ipfs.dweb.link/Once a file or folder is uploaded to IPFS and a CID is returned, that CID can be used to access the stored data through an IPFS gateway. All data uploaded to IPFS is public by default since all you need to access it is associated CID. There are no permissions, user accounts, or other security settings tied to IPFS CIDs.
Applications that natively support IPFS content addressing can refer to content stored on IPFS in the format:
ipfs://{CID}/{optional path to resource}This format doesn’t work for applications or tools that rely on HTTP, such as Curl or Wget. For these tools, you need to use an IPFS gateway.
IPFS HTTP gateways use the HTTP protocol to serve content hosted on the IPFS network, bridging the gap between the two different protocols. This means you can access content on IPFS through its IPFS CID in situations such as code snippets or applications that support HTTP, which most do.
Gateways are used to provide workarounds for applications that don’t natively support IPFS and can also be used as a sharing link for the data. An IPFS gateway can be local, private, or public, and uses the IPFS CID to provide a URL link to the content for access to the stored content.
Simply put, a gateway is an IPFS peer that accepts HTTP requests for IPFS CIDs.
The IPFS HTTP gateway format follows the structure:
https://<gateway-url>/ipfs/<CID>Note: The Filebase Public IPFS Gateway has an effective rate limit of 200 RPM (requests per minute).
All content stored on IPFS through Filebase can be accessed through the Filebase gateway with faster response times than accessing the content through any other gateway. This is because the Filebase gateway peers with our IPFS nodes. The Filebase gateway also peers with the IPFS gateways of other pinning services.
Any gateway is capable of serving any IPFS CID, and accessing the same CID through multiple gateways will produce the same result.
For example, the following IPFS gateway URLs both lead to the same file:
https://ipfs.filebase.io/ipfs/bafkreidfu7ruyq7us3im2sfdm4poeod5xiqqyqieda2wl6ddvcys3t5aomhttps://ipfs.io/ipfs/bafkreidfu7ruyq7us3im2sfdm4poeod5xiqqyqieda2wl6ddvcys3t5aomGateways can also serve the CID of a folder instead of just a single file. In this scenario, it will return a file directory tree that contains the files located in the folder.
For example, the following IPFS gateway URL leads to a folder directory of files:
https://ipfs.filebase.io/ipfs/QmWTqpfKyPJcGuWWg73beJJiL6FrCB5yX8qfcCF4bHvaneGateways can also be used to serve static websites. The following URL leads to a static webpage, hosted on IPFS using a folder containing a static HTML file and image files:
https://ipfs.filebase.io/ipfs/QmYRpH3myNKG2XeaBmdidec3R5HcF9PYBHUVHfks5ysTpq/Public gateways allow anyone to use HTTP to retrieve CIDs from the IPFS network. Filebase offers a public IPFS gateway with the following address:
https://ipfs.filebase.io/ipfs/<CID>/There are two forms of private IPFS gateways: dedicated and self-hosted.
Dedicated gateways are offered by IPFS pinning services that allow you to access the CIDs pinned on IPFS through the pinning service through your own private dedicated gateway. Dedicated gateways are typically not limited to traditional rate limits that public gateways are.
Self-hosted gateways refer to an IPFS node that you host yourself, either in the cloud or on your local machine, that is configured to act as an IPFS gateway. Self-hosted gateways are not limited to rate limits either, but require an IPFS to be running and managed by you for functionality. Many users choose an IPFS pinning service that offers dedicated gateways so they can avoid hosting and maintaining IPFS nodes themselves.
When a request for a CID is initiated using an IPFS HTTP gateway, the following steps occur:
- 1.The gateway checks if the CID has been cached locally before it attempts to retrieve it from the IPFS network. The cache can either be the local HTTP cache, or the cache of the IPFS gateway node.
- 2.If the CID hasn’t been cached, the CID will need to be retrieved from the IPFS network.
- 3.The IPFS peer will first ask its direct peers if any of them are hosting the requested CID, then it will query the DHT to find peer IDs and network addresses of peers that are currently hosting or pinning the requested CID.
- 4.The IPFS gateway node will connect to one of the peers with the CID, fetch the CID’s content, then relay the response to the client that requested the CID.
Through content addressing and content identifiers, any IPFS peer can retrieve any given CID as long as the file is being served by at least one peer on the network. When you request a CID from an IPFS peer and that peer is not hosting the file, it will search the entire IPFS network for the peer that has the file. Once it finds the peer, it will fetch the file associated with the CID and return it back to you.
When files and data are stored on the IPFS network, nodes on the network cache the files that they download and keep those files available for other nodes on the network. Since storage on these nodes is finite, the cache for each node must be cleared periodically to make room for new files to be cached and made available. The process of clearing the cache for IPFS nodes is referred to as the IPFS garbage collection process.
To assure that at least one peer is hosting the file, IPFS offers a feature known as pinning. IPFS pinning refers to the process of specifying data to be retained and persist on one or more IPFS nodes for long-term storage. Pinning assures that data is accessible indefinitely, and will not be removed during the IPFS garbage collection process.
When files and data are stored on the IPFS network, nodes on the network cache the files that they download and keep those files available for other nodes on the network. Since storage on these nodes is finite, the cache for each node must be cleared periodically to make room for new files to be cached and made available. The process of clearing the cache for IPFS nodes is referred to as the IPFS garbage collection process.
Garbage collection is an automatic process that is used to manage resources, such as IPFS node disk space. The process is designed to remove cached data that it thinks is no longer needed, though if your IPFS CID refers to a file that is vital to your workflow or environment, having this file removed can be detrimental. So how do you prevent your file from being removed during this process?
To protect data from the garbage collection process, data must be pinned on the IPFS network. This ensures that data is retained indefinitely and is always accessible. Pinning is useful for a variety of workflows, such as accessing data files from around the world without managing sharing permissions. All data uploaded to IPFS is public by default since all you need to access it is the file’s CID. There are no permissions, user accounts, or other security settings tied to IPFS CIDs.
One of the most popular workflows utilizing IPFS pinning right now is NFT collections. These collections have a variety of files involved, including NFT image files and their associated metadata files. If these files aren’t pinned on IPFS and they get removed by the IPFS garbage collection process, this can result in an “NFT Rug Pull”, which means that the NFT ceases to exist, and is no longer accessible or transferable.
Filebase offers an IPFS pinning service, where all files uploaded to a Filebase IPFS bucket are automatically pinned on 3 different IPFS nodes within the Filebase infrastructure. This ensures 3x redundancy for all IPFS pinned files on the Filebase infrastructure for high availability, resiliency, and reliability.
Some pinning service providers don’t publish provider records to the IPFS DHT, or Distributed Hash Table. The DHT is responsible for keeping a distributed system that maps keys to values and maps the CID that a user requests with the peer that is hosting that content. The DHT is essentially a large table storing CIDs with their associated storage peer. Filebase publishes our provider records to the IPFS DHT for the best performance and CID retrieval time when requested.
- 1.To sign up for a Filebase account, navigate to https://filebase.com. To make a new account, click the ‘Try for Free’ button in the top right corner of the webpage.
2. Next, fill out the fields of the form, including an email address and password, and agree to the Filebase terms to create your account.
Note: Temporary email addresses cannot be used to create a Filebase account.
3. You will receive an email with confirmation instructions. Click the link included in the email to confirm your account and finish the registration process.
Click on the ‘Buckets’ option from the menu to open the Buckets dashboard.
Select your IPFS Bucket. Need to make an IPFS bucket? Check out how to here.After clicking on the bucket name, select 'Upload' in the top right corner. You will have three options:
- File: File is for uploading an individual file to IPFS. This can be an image, video, audio, text, or any other file type.
- Folder: Folder is for uploading a folder containing multiple files, such as an NFT collection, or the files for a static website.
- CID: CID stands for content identifier, and is for re-pinning an existing IPFS CID that you may have from another pinning provider or a local IPFS node.
To upload a single file, choose 'File', then when prompted select the file you want to upload to IPFS.
Once uploaded, confirm that that status reads 'pinned'. You will then be able to view and copy the IPFS CID from the 'CID' category, as seen below.
Files uploaded to an IPFS bucket on Filebase are automatically pinned to IPFS and stored with 3x replication across the Filebase infrastructure by default, at no extra cost to you. This means your data is accessible and reliable in the event of a disaster or outage, and won't be affected by the IPFS garbage collection process.
- 1.Start by clicking on the ‘Buckets’ option from the menu to open the Buckets dashboard.
2. Select your IPFS Bucket.
3. After clicking on the bucket name, you will see any previously uploaded files. To upload another file, select 'Upload', then select 'File' from the options.
4. Select the file you want to upload to the IPFS.
5. Once uploaded, you will be able to view and copy the IPFS CID from the 'CID' category, as seen below.
- 1.Start by clicking on the ‘Buckets’ option from the menu to open the Buckets dashboard.
2. Select your IPFS Bucket.
3. After clicking on the bucket name, you will see any previously uploaded files. To upload another file, select 'Upload', then select 'Folder' from the options.
4. Select the folder you'd like to upload to IPFS.
5. Once uploaded, the folder will look similar to IPFS individual files.
6. Copy the IPFS CID for your folder, then navigate to
https://ipfs.filebase.io/ipfs/[CID]. The contents of your folder will be listed.If you're using the S3-compatible API, the CID will be returned in the response of a PutObject call.
For example, if we run the following AWS CLI command:
aws --endpoint https://s3.filebase.com s3 cp test-images/7FIMFhlMf6A.jpg s3://ipfs-test --debugThe response is shown below. For convenience, we've highlighted the respective response header:
You can also call the HeadObject API to fetch the CID at any time as well:
aws --endpoint https://s3.filebase.com s3api head-object --bucket ipfs-test --key 7FIMFhlMf6A.jpgA CAR file is a type of compressed archive file that contains multiple files, similar to a ZIP file. CAR files are used by the FileCoin and IPFS networks, which utilize the metadata fields to include the IPFS CIDs of each file within the archive.
Filebase supports uploading CAR files to IPFS using the S3-compatible API through the PutObject or MultipartUpload methods.
When you upload a CAR file, you can pass an S3 metadata header of
x-amz-meta-import: car along with the request. Filebase will then import the file as a CAR, and return the resulting CID.Below is an example using the AWS CLI, which adds the
x-amz-meta prefix automatically:aws --endpoint https://s3.filebase.com s3 cp pictures.car s3://ipfs-test --debug --metadata 'import=car'With the specified –debug flag, the response headers are shown, which reveal the CID:
2022-06-14 19:51:41,400 - ThreadPoolExecutor-0_2 - botocore.parsers - DEBUG - Response headers: {'Date': 'Tue, 14 Jun 2022 23:51:41 GMT', 'Content-Type': 'application/xml', 'Transfer-Encoding': 'chunked', 'Connection': 'keep-alive', 'x-amz-meta-cid': 'bafybeieurpeyzighqrvwjqyj3szuvbqvrbijm7cdair5a422ipf2d5qnlq', 'ETag': 'W/"d8cad258a3d9bbe03a26a13a3ec43b21"', 'x-amz-request-id': '144e0415-8162-45cd-b071-e51dada956ae', 'x-amz-id-2': 'ZmlsZWJhc2UtNmQ3ZjQ5OGZmZC14ejk1Mg==', 'Server': 'Filebase'}1. Start by clicking on the ‘Buckets’ option from the menu to open the Buckets dashboard.
2. Once at the Buckets dashboard, create a new IPFS bucket by clicking the ‘Create Bucket’ option in the top right corner.
3. Enter a bucket name and choose the IPFS network.
Bucket names must be unique across all Filebase users, be between 3 and 63 characters long, and can contain only lowercase characters, numbers, and dashes.
4. Then select your new IPFS Bucket.
5. After clicking on the bucket name, select 'Upload' from the top right corner, then select 'CID'.
6. Then enter your IPFS CID and a custom human-readable name to associate with your CID.
7. Select 'Search and Pin' to pin your CID to IPFS through Filebase.
Note: The IPFS network is large and it may take some time for Filebase's IPFS nodes to locate and fetch the CID.
- 1.
- 2.From the left side-bar menu, select 'Settings'.
3. Select 'Add Service' under 'Pinning Services'.
4. Select 'Filebase' when prompted to select a pinning service provider.
5. Enter the following configuration information to add Filebase as your pinning service provider:
- Secret Access Token: Navigate to the Filebase Access Keys page, then view the IPFS PInning Service API Endpoint. Click the drop down menu for 'Choose Bucket to Generate Token', then choose the IPFS Filebase Bucket you want to use.Then copy the generated Secret Access Token:
6. Select 'Save'. Your Filebase pinning service configuration will now be listed under 'Pinning Services'.
7. Next, select 'Files' from the left side-bar menu, then select 'Import'.
8. Select 'From IPFS'.
9. Input your IPFS CID, appended with
/ipfs/ and provide a name to associate with your CID, then select 'Import'. This CID can be for an individual file or a folder.10. Once imported, your IPFS asset will be listed. Select the 3 dots from the right side menu to bring up options to interact with your IPFS asset.
11. Select 'Set pinning'.
12. Select the check box next to 'Filebase', then select 'Apply'.
13. The 'Pin Status' for this IPFS asset will now show an icon with a cloud and a thumbtack, indicating it has been pinned to the configured pinning service.
14. Navigate to the Filebase web console, then select the bucket you used to generate your Secret Access Token earlier, and you will see your pinned IPFS asset, which will show the status 'Pinning', meaning it is in the process of being pinned to IPFS through Filebase. Once finished, this will read 'Pinned'.
- 1.
- 2.Next, add Filebase as a pinning service with the following command:
ipfs pin remote service add Filebase https://api.filebase.io/v1/ipfs SECRET-ACCESS-TOKENIf you intend to use more than one bucket, you will need to repeat this command with the secret access token for each bucket. In this workflow, the nickname should be Filebase(Bucket-Name) in order to identify different buckets.
Replace the following value to match your configuration:
- SECRET-ACCESS-TOKEN: Navigate to the Filebase Access Keys page, then view the IPFS PInning Service API Endpoint. Click the drop down menu for 'Choose Bucket to Generate Token', then choose the IPFS Filebase Bucket you want to use.Then copy the generated Secret Access Token:
3. Use the following command to pin an existing IPFS CID to Filebase:
ipfs pin remote add --service=Filebase --name=ASSET-NAME IPFS-CIDReplace ASSET-NAME with your desired human-readable value to be associated with your pinned CID, and replace IPFS-CID with the CID of your IPFS asset. This can be either a file or a folder.
ipfs pin remote add --service=Filebase --name=my-nft-collection bafybeif5x2gihgepga2vtjlx3lfdwgxquo2sbv4a77rsedokf6poqrrcse4. Navigate to the Filebase web console, then select the bucket you used to generate your Secret Access Token earlier, and you will see your pinned IPFS asset, which will show the status 'Pinning', meaning it is in the process of being pinned to IPFS through Filebase. Once finished, this will read 'Pinned'.
Your terminal will also return the following output:
CID: bafybeif5x2gihgepga2vtjlx3lfdwgxquo2sbv4a77rsedokf6poqrrcse
Name: my-nft-collection
Status: pinned
The IPFS Pinning Service API is a standardized API for re-pinning existing IPFS CIDs. It is often referred to as "remote" pinning or the IPFS "PSA". The IPFS PSA is used by both the IPFS CLI and IPFS Desktop application.
The IPFS development team tracks the compliance of each provider that supports the IPFS PSA to validate each implementation. Filebase is fully compliant with the IPFS PSA requirements. The official compliance report can be seen here.
Filebase supports the IPFS Pinning Service API through our IPFS Re-Pinning service. This API can be used to view pinned objects, add a new object to be pinned, or remove a pinned object.
To interact with the Filebase IPFS Pinning Service API, use the following information below.
https://api.filebase.io/v1/ipfsTo authenticate with the IPFS Pinning Service API, a token is required to be sent with each request in the HTTP headers, using the following format:
Authorization: Bearer <access-token>
The
access-token can be generated by navigating to the Filebase Access Keys page, then viewing the IPFS PInning Service API Endpoint. Click the drop down menu for 'Choose Bucket to Generate Token', then choose the IPFS Filebase Bucket you want to use. Then copy the generated Secret Access Token:
Request Body Schema:
application/jsonTo interact with the IPFS Pinning Service API, you need to send a payload in the form of JSON to the API URL. The following is an example of a POST payload:
{
"cid": "bafybeihbfkn5afsjep2jd65gn5vedh7vpvp6i6avfu5za7fnnhsvfutzjy",
"name": "image3",
"meta": {
"key_name": "value_name"
}
}
For a full list of the API methods, please see the IPFS Pinning Service documentation page:
You can also retrieve the IPFS CID using different AWS S3 SDKs. The example below uses The JavaScript SDK:
const AWS = require('aws-sdk');
const fs = require('fs');
const s3 = new AWS.S3({
endpoint: 'https://s3.filebase.com',
region: 'us-east-1',
signatureVersion: 'v4',
});
fs.readFile('image.png', (err, data) => {
if (err) {
console.error(err);
return;
}
const params = {
Bucket: 'my-ipfs-bucket',
Key: 'test/image.png',
ContentType: 'image/png',
Body: data,
};
const request = s3.putObject(params);
request.on('httpHeaders', (statusCode, headers) => {
console.log(`CID: ${headers['x-amz-meta-cid']}`);
});
request.send();
});
const command = new PutObjectCommand({...});
command.middlewareStack.add(
(next) => async (args) => {
// Check if request is incoming as middleware works both ways
const response = await next(args);
if (!response.response.statusCode) return response;
// Get cid from headers
const cid = response.response.headers["x-amz-meta-cid"];
console.log(cid);
return response;
},
{
step: "build",
name: "addCidToOutput",
},
);
const res = await client.send(command);
With IPFS, file sharing is made extremely easy, since all files uploaded to IPFS are publicly accessible through their CID value. As long as the file is pinned through an IPFS pinning service like Filebase, it’ll be accessible for long-term file sharing.
Click on the ‘Buckets’ option from the menu to open the Buckets dashboard.
After clicking on the bucket name, select 'Upload' in the top right corner. You will have three options:
- File: File is for uploading an individual file to IPFS. This can be an image, video, audio, text, or any other file type.
- Folder: Folder is for uploading a folder containing multiple files, such as an NFT collection, or the files for a static website.
- CID: CID stands for content identifier, and is for re-pinning an existing IPFS CID that you may have from another pinning provider or a local IPFS node.
To upload a single file, choose 'File', then when prompted select the file you want to upload to IPFS.
Once uploaded, confirm that that status reads 'pinned'.
Click on the file name to view the file’s details.
From this screen, you’ll see two different URLs listed for your file: its Filebase Object URL and its IPFS Gateway URL.
The Object URL can only be used to share the file if the file is within a public bucket. Otherwise, this URL will return an ‘Access Denied’ error message.
The IPFS Gateway URL can be used to share the file using its IPFS CID and the Filebase Public IPFS Gateway. This URL can be accessed by anyone in the world, regardless if the bucket is public or private.
Learn how to use the following IPFS tools with Filebase:
Learn how to use IPFS in the following tutorial guides:
For all of our Web3 tutorials showcasing IPFS, please see our Web3 Tutorial section:
If you have any questions, please join our Discord server, or send us an email at [email protected]
Last modified 10d ago