Skip to content

Commit cab9c30

Browse files
authored
Merge branch 'main' into main
2 parents f72ccc6 + 80963ff commit cab9c30

20 files changed

+357
-129
lines changed

.github/styles/pln-ignore.txt

Lines changed: 12 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,8 @@ bool(ean)
2222
boolean
2323
boxo
2424
browserify
25+
caddy
26+
Caddyfile
2527
callout
2628
callouts
2729
cas
@@ -114,6 +116,7 @@ keepalive
114116
keypair
115117
keystores
116118
kubo
119+
Kubo's
117120
kubuxu
118121
laika
119122
lan
@@ -130,6 +133,9 @@ mainnet
130133
markdown(lint)
131134
markdownlint
132135
merkle
136+
merklizing
137+
merkleizing
138+
merkleization
133139
metadata('s)
134140
metamask
135141
minimalistic
@@ -142,6 +148,8 @@ multiaddrs
142148
multibase
143149
multicast
144150
multicodec
151+
multicodecs
152+
multicodec(s)
145153
multiformats
146154
multihash
147155
multihashes
@@ -213,14 +221,17 @@ Someguy
213221
subcommand
214222
substring
215223
sys
224+
systemd
216225
sztandera
217226
testground
218227
testnet
219228
toolkits
220229
trustlessly
221-
uncensorable
230+
trustlessness
231+
uncensorable
222232
undialable
223233
uniswap
234+
unixfs
224235
unreachability
225236
untrusted
226237
upgradeability

.github/workflows/markdownlint-action.yml

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,8 +7,7 @@ jobs:
77
runs-on: ubuntu-latest
88
steps:
99
- name: markdownlint-cli
10-
uses: nosborn/github-action-markdown-cli@v3.3.0
10+
uses: nosborn/github-action-markdown-cli@v3.4.0
1111
with:
1212
files: .
1313
config_file: .markdownlint.jsonc
14-

.markdownlint.jsonc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -175,7 +175,7 @@
175175

176176
"MD033": {
177177
// Allowed elements
178-
"allowed_elements": []
178+
"allowed_elements": [""]
179179
},
180180

181181
// MD034/no-bare-urls - Bare URL used
@@ -302,4 +302,4 @@
302302
"//"
303303
]
304304
}
305-
}
305+
}

docs/.vuepress/config.js

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -208,6 +208,7 @@ module.exports = {
208208
'/how-to/configure-node',
209209
'/how-to/modify-bootstrap-list',
210210
'/how-to/nat-configuration',
211+
'/how-to/kubo-rpc-tls-auth',
211212
'/how-to/ipfs-updater',
212213
[
213214
'https://github.com/ipfs-examples/js-ipfs-examples/tree/master/examples/custom-ipfs-repo',
@@ -255,12 +256,12 @@ module.exports = {
255256
]
256257
},
257258
{
258-
title: 'IPFS in the browser',
259+
title: 'IPFS on the web',
259260
sidebarDepth: 1,
260261
collapsable: true,
261262
children: [
263+
'/how-to/ipfs-in-web-apps',
262264
'/how-to/address-ipfs-on-web',
263-
'/how-to/browser-tools-frameworks'
264265
]
265266
},
266267
{
@@ -277,7 +278,7 @@ module.exports = {
277278
collapsable: true,
278279
children: [
279280
'/how-to/gateway-best-practices',
280-
'/how-to/gateway-troubleshooting'
281+
'/how-to/gateway-troubleshooting',
281282
]
282283
},
283284
{

docs/.vuepress/redirects

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -40,6 +40,7 @@
4040
/guides/guides/addressing/ /how-to/address-ipfs-on-web
4141
/guides/guides/install/ /install
4242
/how-to/host-single-page-site /how-to/websites-on-ipfs/single-page-website
43+
/how-to/browser-tools-frameworks /how-to/ipfs-on-the-web
4344
/how-to/troubleshoot-file-transfers /how-to/troubleshooting
4445
/how-to/run-ipfs-inside-docker /install/run-ipfs-inside-docker
4546
/install/command-line-quick-start/ /how-to/command-line-quick-start
129 KB
Loading

docs/concepts/lifecycle.md

Lines changed: 15 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -5,25 +5,30 @@ description: Learn about the lifecycle of data in IPFS.
55

66
# The lifecycle of data in IPFS
77

8-
- [1. Content-addressable representation](#1-content-addressable-representation)
9-
- [2. Pinning](#2-pinning)
10-
- [3. Retrieval](#3-retrieval)
11-
- [4. Deleting](#4-deleting)
8+
- [1. Content-addressing](#1-content-addressing)
9+
- [2. Providing](#2-providing)
10+
- [3. Retrieving](#3-retrieving)
1211
- [Learn more](#learn-more)
1312

14-
## 1. Content-addressable representation
13+
## 1. Content-addressing / Merkleizing
1514

16-
The file is transformed into a content-addressable representation using a CID. The basic idea is that this representation makes files and directories **content-addressable** via CIDs by chunking files into smaller blocks, calculating their hashes, and constructing a [Merkle DAG](./merkle-dag.md).
15+
The first stage in the lifecycle of data in IPFS is to address it by CID. This is a local operation that takes arbitrary data and encodes it so it can be addressed by a CID.
1716

18-
## 2. Pinning
17+
The exact process depends on the type of data. For files and directories, this is done by constructing a [UnixFS](./file-systems.md#unix-file-system-unixfs) [Merkle DAG](./merkle-dag.md). For other data types, such as dag-cbor, this is done by encoding the data with [dag-cbor](https://ipld.io/docs/codecs/known/dag-cbor/) which is hashed to produce a CID.
18+
19+
For example, merkleizing a static web application into a UnixFS DAG looks like this, where the whole application is addressed by the CID in the top block (`bafy...jomu`):
20+
21+
![UnixFS Dag](./images/unixfs-dag-diagram.png)
22+
23+
## 2. Providing
1924

2025
In this stage, the blocks of the CID are saved on an IPFS node (or pinning service) and made retrievable to the network. Simply saving the CID on the node does not mean the CID is retrievable, so pinning must be used. Pinning allows the node to advertise that it has the CID, and provide it to the network.
2126

2227
- **Advertising:** In this step, a CID is made discoverable to the IPFS network by advertising a record linking the CID and the server's IP address to the [DHT](./dht.md). Advertising is a continuous process that repeats typically every 12 hours. The term **publishing** is also commonly used to refer to this step.
2328

2429
- **Providing:** The content-addressable representation of the CID is persisted on one of web3.storage's IPFS nodes (servers running an IPFS node) and made publicly available to the IPFS network.
2530

26-
## 3. Retrieval
31+
## 3. Retrieving
2732

2833
In this stage, an IPFS node fetches the blocks of the CID and constructs the Merkle DAG. This usually involves several steps:
2934

@@ -35,13 +40,13 @@ In this stage, an IPFS node fetches the blocks of the CID and constructs the Mer
3540

3641
- **Local access:** Once all blocks are present, the Merkle DAG can be constructed, making the file or directory underlying the CID successfully replicated and accessible.
3742

38-
## 4. Deleting
43+
<!-- ## 4. Deleting
3944
4045
At this point, the blocks associated with a CID are deleted from a node. **Deletion is always a local operation**. If a CID has been replicated to other nodes, it will continue to be available on the IPFS network.
4146
4247
:::callout
4348
Once the CID is replicated by another node, it is typically advertised to DHT by default, even if it isn't explicitly pinned.
44-
:::
49+
::: -->
4550

4651
## Learn more
4752

docs/how-to/browser-tools-frameworks.md

Lines changed: 0 additions & 32 deletions
This file was deleted.

docs/how-to/ipfs-in-web-apps.md

Lines changed: 127 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,127 @@
1+
---
2+
title: IPFS in web applications
3+
description: How to develop applications that use IPFS on the Web including addressing by CID, merkleizing, retrieval, providing, and CAR files with Helia.
4+
---
5+
6+
# IPFS in web applications and resource-constrained environments
7+
8+
In this guide you will learn how to use IPFS using JavaScript/TypeScript in web applications, including addressing data with CIDs, retrieval by CID, working with CAR files, and the nuances of providing.
9+
10+
For this, you will use [Helia](https://github.com/ipfs/helia), the most actively maintained implementation of IPFS in TypeScript for use on the web.
11+
12+
> **Note:** this guide is focused solely on using IPFS for data within a web application. It does _not_ cover using IPFS for static website distribution with IPFS Gateways.
13+
14+
## Challenges with IPFS on the web
15+
16+
IPFS allows you to fetch data by CID from multiple providers without being reliant on a single authoritative server.
17+
18+
However, making all of this work on the web is tricky due to networking constraints. Browsers impose many restrictions on web apps, for example, opening TCP/UDP connections is not possible. Instead, web apps are constrained to HTTP, WebSockets, WebRTC, and most recently WebTransport.
19+
20+
There are good reasons for this like security and resource management, but ultimately, it means that using IPFS on the web is different to native binaries.
21+
22+
## Key IPFS operations: Addressing, Retrieving, and Providing
23+
24+
As a developer, IPFS exposes three main operations for interacting with the network:
25+
26+
- **Addressing data with CIDs** (also known as **merkleizing**): taking arbitrary data and encoding so its addressable by CID. For example, given a directory of files, merkleizing it so it can be addressed and retrieved by CID.
27+
- **Retrieving data by CID**: given a CID, IPFS finds providers (peers who share the block), connects to them, fetches the blocks, and verifies that the retrieved data is what the CID represents.
28+
- **Providing data by CID**: making data addressed by a CID retrievable by other peers, either by running a node or with a pinning service.
29+
30+
## Addressing data by CID
31+
32+
As mentioned above, the first step in the [lifecycle of data in IPFS](../concepts/lifecycle.md) is to address it by CID.
33+
34+
When addressing data by [CIDs](../concepts/glossary.md#cid) you will need to choose:
35+
36+
- [hash function](../concepts/glossary.md#hash). For use in browsers, the default and recommended hash function is `sha2-256` which is also the default for [Helia](https://github.com/ipfs/helia).
37+
- [multicodec](../concepts/glossary.md#multicodec), which is the format of the data you are addressing and is used to help decode data. CIDs support a wide range of multicodecs, but for most intents and purposes, you will likely either want use:
38+
- [UnixFS](../concepts/file-systems.md#unix-file-system-unixfs) for files and directories.
39+
- [dag-cbor](../concepts/glossary.md#dag-cbor) for json-like structured data with binary encoding. DAG-CBOR is an extension of CBOR that adds a "link" type for CIDs, allowing for the creation of interlinked CBOR objects (which can be used to form larger linked data structures).
40+
41+
### CID Determinism
42+
43+
One important thing to note is that **the same data can result in different CIDs** depending on a number of factors, including the hash function, and the multicodec you use. **This is especially true for files**, where the same file, hash function and multicodec can still result in different CIDs depending on the different options that UnixFS supports.
44+
45+
See the [forum discussion on CID profiles](https://discuss.ipfs.tech/t/should-we-profile-cids/18507) and the [DASL](https://dasl.ing/) initiative for more for more information on the nature of this problem and how the community is addressing it.
46+
47+
For a visual demonstration of this, try the [DAG Builder](https://dag.ipfs.tech/), which visualises how files are addressed by CID with UnixFS and demonstrates how the same file can result in different CIDs, depending on the different options that UnixFS supports.
48+
49+
### Example: Addressing an object by CID with dag-cbor
50+
51+
For example, to address an object by CID with the `dag-cbor` multicodec and `sha2-256` hash function, you can use the following code using [Helia](https://github.com/ipfs/helia):
52+
53+
<iframe height="300" style="width: 100%;" scrolling="no" title="Addressing an object by CID with Helia and dag-cbor" src="https://codepen.io/2color/embed/xbKpJKx?default-tab=js%2Cresult" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
54+
See the Pen <a href="https://codepen.io/2color/pen/xbKpJKx">
55+
Addressing an object by CID with Helia and dag-cbor</a> by Daniel Norman (<a href="https://codepen.io/2color">@2color</a>)
56+
</iframe>
57+
58+
### Example: Addressing a file by CID with UnixFS
59+
60+
<iframe height="500" style="width: 100%;" scrolling="no" title="Addressing an image by CID with Helia and UnixFS" src="https://codepen.io/2color/embed/zxONqPj?default-tab=js%2Cresult" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
61+
See the Pen <a href="https://codepen.io/2color/pen/zxONqPj">
62+
Addressing an image by CID with Helia and UnixFS</a> by Daniel Norman (<a href="https://codepen.io/2color">@2color</a>)
63+
</iframe>
64+
65+
## Retrieval
66+
67+
From a high level, there are several ways to retrieve data with IPFS in web applications:
68+
69+
- Using the [Verified Fetch](https://www.npmjs.com/package/@helia/verified-fetch) library, which was modelled after the [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) and returns [Response](https://developer.mozilla.org/en-US/docs/Web/API/Response) objects, with the main difference being that it allows you to fetch data by CID, abstracting away the details of content routing, transports and retrieval. For more examples and background see the [release blog post](https://blog.ipfs.tech/verified-fetch/).
70+
- Using the [Helia](https://github.com/ipfs/helia/) library, which is the foundation for the `@helia/verified-fetch` library, and provides a more comprehensive and modular API for interacting with the IPFS network, beyond just retrieval.
71+
- Using public recursive gateways, e.g. `ipfs.io` with HTTP. This is not recommended for most use cases, because it forgoes the verifiability and trustlessness enabled by content addressing. Granted, it might be the easiest way to retrieve data in a web application, but is also the most fraught with security and centralization concerns.
72+
73+
### Example: Image retrieval with Verified Fetch
74+
75+
<iframe height="500" style="width: 100%;" scrolling="no" title="Fetch an image on IPFS Mainnet @helia/verified-fetch" src="https://codepen.io/2color/embed/QWXKZGx?default-tab=js%2Cresult" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
76+
See the Pen <a href="https://codepen.io/2color/pen/QWXKZGx">
77+
Fetch an image on IPFS Mainnet @helia/verified-fetch</a> by Daniel Norman
78+
</iframe>
79+
80+
## Providing data
81+
82+
For data to be retrievable by other peers on [IPFS Mainnet](../concepts/glossary.md#ipfs-mainnet) it will need to be uploaded to a pinning service or an IPFS node.
83+
84+
When possible, it's best to rely on client-side merkleization to address data by CID and then upload it to a pinning service or a node. [CAR files](#car-files) are a great way to do this, though they are not supported by all pinning services.
85+
86+
### You probably don't want to provide data from a browser
87+
88+
Browsers make for lousy servers. It's difficult to make a Web page a server, i.e. allow network incoming connections from other computers. WebRTC is the only exception, however, it has many caveats, and doesn't work in all networks.
89+
90+
For this reason, you should never count on providing data from a browser to work.
91+
92+
Instead, you should provide data from a long-running server that runs reliably and has a public IP. That can be a Kubo node that you run, or a [pinning service](../concepts/persistence.md#pinning-services).
93+
94+
### CAR files
95+
96+
The Content Archive format is a way of packaging up content addressed data into archive files that can be easily stored and transferred over the network. You can think of them like TAR files that are designed for storing collections of content addressed data.
97+
98+
**So why would you want to use CAR files?**
99+
100+
One of the main reasons is related to [CID determinism](#cid-determinism). As mentioned above, the same data can result in different CIDs, which can make it difficult to verify data without its content addressed representation. By packaging up the data into a CAR file, you can upload the CAR to multiple pinning services and nodes knowing they are providing the same CIDs
101+
102+
CAR files are a great way to store content-addressed data in a way that is easy to transport and store, and Helia (and other implementations) allow you to both export and import any data you've addressed by CID into a CAR file.
103+
104+
<iframe height="300" style="width: 100%;" scrolling="no" title="CAR export with Helia and dag-cbor" src="https://codepen.io/2color/embed/EaYoegX?default-tab=js%2Cresult" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
105+
See the Pen <a href="https://codepen.io/2color/pen/EaYoegX">
106+
CAR export with Helia and dag-cbor</a> by Daniel Norman (<a href="https://codepen.io/2color">@2color</a>)
107+
</iframe>
108+
109+
At the time of writing, not all pinning services support CAR files, but it is a feature that is being added to more and more services. Therefore, it is a good idea to check the documentation for the pinning service you are using to see if it supports CAR files.
110+
111+
## Conclusion
112+
113+
This guide has covered the essential aspects of using IPFS in web applications:
114+
115+
- The main operations: addressing/merkleizing data with CIDs, retrieving data, and providing data.
116+
- The challenges and limitations of using IPFS in browser environments.
117+
- Practical examples using modern tools like [Helia](https://github.com/ipfs/helia) and [Verified Fetch](https://www.npmjs.com/package/@helia/verified-fetch).
118+
- Best practices for handling data persistence through pinning services and CAR files.
119+
120+
When building web applications with IPFS, remember these key takeaways:
121+
122+
1. Use client-side merkleization (addressing) when adding new data to IPFS, but rely on pinning services or IPFS nodes for providing data.
123+
1. Be mindful of CID determinism when working with files and structured data.
124+
1. Consider using CAR files where possible for storage and transport of content-addressed data.
125+
1. Use Verified Fetch for simple retrieval or Helia for more complex IPFS interactions.
126+
127+
By following these guidelines, you can reap the benefits of IPFS while working within the constraints of the web.

0 commit comments

Comments
 (0)