Skip to content

필사 모드: Decentralized & P2P Content Protocols in 2026 — IPFS Helia / libp2p / BitTorrent v2 / WebTorrent / Hyperdrive / Iroh / Filecoin / Arweave / Storacha Deep Dive

English
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — "decentralized" is a word that hides too much

In 2026, when people say "decentralized content," everyone hears something different. One person pictures an IPFS CID. Another pictures a torrent magnet link. A third pictures Arweave's "permanent storage" promise. A fourth pictures Filecoin's storage market. And someone, somewhere, is still pulling up an old Jack Dorsey Web5 slide — even though that project has barely moved since 2024.

This piece puts all of those terms on a single map. Which protocols are alive, which ones died (Beaker Browser, RIP 2022), which ones rebranded (web3.storage to Storacha, 2024), and which ones are still quietly shipping (Iroh, Helia, Boxo).

Let me front-load the core message:

- **IPFS is the protocol; Helia is its modern JS implementation.** They are not the same thing.

- **libp2p** split out of IPFS into its own networking stack that now powers far more than IPFS.

- **BitTorrent v2 (BEP 52)** is a 2018 spec that is still, in 2026, in the slow-adoption phase.

- **WebTorrent** is the only really practical option for torrenting inside a browser tab.

- **Hyperdrive / Hypercore** outlived the Beaker browser as libraries.

- **Iroh** is a Rust reimagination of IPFS — smaller, faster, mobile-friendly.

- **Filecoin / Arweave / Storj / Sia / Akord** all survive with very different economic models.

- **Storacha (formerly web3.storage)** and **NFT.Storage** are Protocol Labs descendants offering hosted IPFS pinning.

- **Web5 is mostly stalled.**

Let's walk through them.

1. The 2026 P2P Content Map — Four Big Buckets

The easiest mental model is four buckets.

+----------------------------------------------------------+

| 2026 P2P Content Map |

+----------------------------------------------------------+

| 1. IPFS family (content-addressed, CID) |

| - IPFS Helia (JS) |

| - Kubo (Go) |

| - Boxo (modular library) |

| - Iroh (Rust reimagination) |

| - libp2p (networking stack) |

| |

| 2. Hyper family (append-only logs) |

| - Hypercore |

| - Hyperdrive |

| - Beaker Browser (RIP 2022) |

| - Dat to Hyper rebrand |

| |

| 3. BitTorrent family |

| - BitTorrent v1 (1990s) |

| - BitTorrent v2 / BEP 52 (2018, slow uptake) |

| - WebTorrent (browser JS) |

| |

| 4. Crypto storage (economic incentives) |

| - Filecoin (verifiable storage market) |

| - Arweave (permanent storage) |

| - Storj DCS (S3-compatible) |

| - Sia / Akord |

| - Banyan Storage (on Filecoin) |

+----------------------------------------------------------+

These four are complementary. **IPFS is for addressing and discovery, BitTorrent for bulk distribution, Hyper for append-only data streams, crypto storage for durability and incentives.** Different problems.

A few neighbors that sit slightly off the main map:

- **ActivityPub** — the federated social protocol Mastodon uses. Not strictly P2P, but lives under the same "decentralized" umbrella.

- **WebRTC data channels** — direct browser-to-browser links. WebTorrent's transport.

- **Tahoe-LAFS** — an old (2008-) encrypted distributed store, still alive.

2. IPFS — Protocol Labs, still evolving

**IPFS (InterPlanetary File System)** was started in 2014 by Juan Benet at **Protocol Labs**. The protocol is **content-addressed**: files are identified not by location (URL) but by the hash of their contents (CID).

Why that matters:

- Same file, same CID — caching and dedupe come for free.

- Same CID, same content from any host — if one provider disappears and the same CID still exists somewhere on the network, the data is recoverable.

- Tamper-evident — change one byte, the CID changes too.

IPFS implementations in 2026

For years the two major implementations were **Kubo** (Go, formerly go-ipfs) and **js-ipfs**. Then 2023 changed the JS side.

- **Kubo** is alive, actively developed, and remains the server/CLI standard.

- **js-ipfs is effectively EOL** — replaced by **Helia** starting August 2023.

- **Boxo** is the modular Go library spun out of Kubo's internals.

- **Iroh** is the Rust "lite IPFS" being built by the **Number 0** team.

The trend is clear: the IPFS world is moving **from a single monolithic daemon to libraries you embed**.

IPFS is not a blockchain

A persistent confusion worth squashing: **IPFS is not a blockchain.** There is no consensus algorithm and no token in the base IPFS protocol. IPFS is a **DHT-based content lookup system**.

**Filecoin** came out of the same company (Protocol Labs) and is the blockchain piece. IPFS is the address scheme; Filecoin is the market that pays storage providers to keep those addresses around.

3. Helia (August 2023) — The Modern JS Client Replacing js-ipfs

**Helia** is the JavaScript IPFS rewrite that Protocol Labs and the IPFS Foundation released in August 2023. It is closer to a from-scratch reimplementation than an incremental js-ipfs upgrade.

Why rewrite? Since js-ipfs started (2016), the JS ecosystem changed too much. ES modules, TypeScript-first, Web Streams, and above all, **front-end environments where bundle size matters**. The old js-ipfs codebase was large, heavy, and tightly coupled.

Helia's design principles:

- **Modular** — pick what you need; never import the entire full-node.

- **Modern JS** — ESM, TypeScript first, async iterators.

- **Block-first API** — blocks are the primary citizens; the file abstraction (UnixFS) is a separate optional package.

- **Pluggable transport** — choose your libp2p transport (WebRTC, WebTransport, WebSocket).

A minimal Helia sketch:

const helia = await createHelia()

const fs = unixfs(helia)

// Upload

const encoder = new TextEncoder()

const cid = await fs.addBytes(encoder.encode('Hello Helia 2026'))

console.log('CID:', cid.toString())

// Read back

const decoder = new TextDecoder()

let content = ''

for await (const chunk of fs.cat(cid)) {

content += decoder.decode(chunk)

}

console.log(content)

When does Helia fit?

- **Running an IPFS node directly in the browser** — without depending on a gateway like ipfs.io.

- **Lightweight IPFS in Node.js** — when running Kubo as a daemon feels excessive.

- **Mobile PWAs, Electron, Tauri** — environments where bundle size is critical.

4. Boxo — Modular IPFS Library (Go)

**Boxo** is the **Go library collection** spun out of Kubo in 2023. The name is meant to evoke "a collection of boxes."

If Helia is the JS-side "modular IPFS," **Boxo is the Go-side equivalent.** Kubo is the full-node daemon; Boxo is the toolbox of components that Kubo uses internally, repackaged so other projects can use them too.

Components include:

- **bitswap** — block exchange protocol.

- **gateway** — HTTP gateway implementation (`/ipfs/CID`).

- **blockstore** — block storage abstractions.

- **routing** — DHT, delegated routing.

- **path resolution** — IPLD path traversal.

When do you reach for Boxo? **When you want pieces of IPFS embedded in your service, not a full node.** Examples:

- Adding content addressing to an internal CDN.

- Running just an HTTP gateway, not a full node.

- Building a custom IPFS-like application (a data marketplace, say).

The Boxo split is the clearest signal of the IPFS world's drift **from monolith daemon to embeddable library**.

5. libp2p — The Networking Stack That Outgrew IPFS

**libp2p** was originally part of IPFS. Everything P2P networking needs — peer discovery, transports, multiplexing, encryption — bundled into a library IPFS used internally. It was good enough that **people wanted it outside IPFS** too, so it became its own project.

In 2026, libp2p is an essentially independent P2P networking standard. It is used by **Ethereum 2.0 consensus clients (Lighthouse, Lodestar, Nimbus)**, **Polkadot/Substrate**, **Filecoin**, **Eth2 P2P gossip**, and **Iroh**.

libp2p modularity

libp2p's core idea is "transports and protocols are swappable":

- **Transports** — TCP, QUIC, WebSocket, WebTransport, WebRTC, Bluetooth.

- **Security** — Noise, TLS 1.3.

- **Muxers** — yamux, mplex.

- **Discovery** — mDNS, DHT, rendezvous, bootstrap.

- **Pubsub** — gossipsub (what Eth2 uses), floodsub.

JS sketch — roughly what Helia configures under the hood:

const node = await createLibp2p({

transports: [webSockets(), webRTC()],

connectionEncryption: [noise()],

streamMuxers: [yamux()]

})

await node.start()

console.log('peer id:', node.peerId.toString())

Learn libp2p once and you understand the internals of **most modern P2P systems**, not just IPFS. It is basically a standard.

6. BitTorrent v2 (BEP 52) — A 2018 Spec Still Slow to Adopt in 2026

**BitTorrent v2** is the major upgrade specified in 2018 as **BEP 52**. The headline changes:

- **SHA-256 hashing** (v1 uses SHA-1).

- **Per-file Merkle trees** — each file has its own Merkle root.

- **Cross-torrent dedupe** — the same file across torrents downloads only once.

- **Hybrid torrents** — support both v1 and v2 simultaneously.

Technically v2 is unambiguously better. But in 2026 adoption is still **slow**. Why?

- **Too much legacy** — decades of v1 torrents are baked into trackers and index sites.

- **Clients lagged** — qBittorrent, Transmission, etc. added support gradually, with v1 fallbacks common.

- **Users don't feel a "benefit"** — v1 still works.

State of the world in 2026:

- **qBittorrent / Deluge / Transmission** support v2 and hybrid mode.

- **uTorrent** caught up on the mainline.

- **WebTorrent** support is partial.

- **Tracker side** — v2 indexing grew, but v1 dominates.

Who should care:

- **Torrent client developers** — the v2 Merkle verification is a great case study in data integrity.

- **Operators distributing large files (Linux ISOs, public datasets)** — v2 is where you eventually want to be.

7. WebTorrent — Browser-Native Torrents in JavaScript

**WebTorrent**, built by **Feross Aboukhadijeh**, is a pure-JS, browser-native BitTorrent client. There is a desktop app too, but the magic is being able to **download torrents inside a browser tab with no plugin**.

How? WebRTC

Traditional BitTorrent uses TCP/UDP. Browsers cannot use either directly. **WebTorrent uses WebRTC data channels as its transport**, which makes browser-to-browser P2P possible.

Trade-offs:

- **Cannot speak to classic torrent peers directly** — you need other WebRTC-capable peers (hybrid clients) on the swarm.

- **Needs a WebRTC signaling server** to bootstrap the first connection.

A tiny browser snippet:

const client = new WebTorrent()

const magnetURI = 'magnet:?xt=urn:btih:...'

client.add(magnetURI, function (torrent) {

torrent.files.forEach(function (file) {

// stream directly into a video element

file.appendTo('#player')

})

})

Why WebTorrent survived:

- It is **the de facto option for browser P2P video streaming** — Twitter/X experimented with it, and ActivityPub video platforms like PeerTube use it heavily.

- **Feross keeps maintaining it.** That solo-maintainer stability has held up for years.

In 2026 WebTorrent is, in practice, the default library for **WebRTC-based P2P video and live streaming**.

8. Hyperdrive + Hypercore — Append-Only Logs as a Filesystem

**Hypercore** is a P2P protocol for **append-only logs** (logs you can only append to). **Hyperdrive** is the filesystem abstraction built on top.

Core ideas:

- All data is stored as a **log**: never mutated, only extended with new entries.

- Each log is identified by a **public key**. The key holder is the writer.

- Anyone with the key can read and replicate.

How is this different from IPFS? **IPFS is for addressing already-finished data; Hypercore is for replicating data that grows over time.** Different problem.

Hypercore fits when:

- **Real-time collaborative documents** — one side writes, others follow.

- **Append-only datasets** — logs, audit trails, trading data.

- **Versioning** — every change lives in the log naturally.

JS sketch:

const core = new Hypercore('./my-storage')

await core.ready()

await core.append('first entry')

await core.append('second entry')

console.log('blocks:', core.length)

const first = await core.get(0)

console.log(first.toString())

9. Beaker Browser (RIP 2022) → Dat → Hyper Rebrand

**Beaker Browser** existed from 2016 to 2022 as a "P2P web browser." It looked like an ordinary browser but could **host and visit P2P sites over `dat://`**. Create a folder, hit "publish," and you had a P2P site.

In 2022 Beaker officially stopped development. But the underlying **Dat protocol** did not die — it **rebranded to Hyper** and lives on as a library ecosystem.

- **Dat protocol then Hyper (Hypercore, Hyperdrive, etc.)**

- **Beaker Browser is RIP**, but the **Hyper ecosystem remains a small but alive community**.

- **Holepunch** (the parent of the Pear Runtime) builds P2P app runtimes (Keet, Pear) on top of Hyper.

The Beaker-died-but-libraries-survive pattern is a recurring one in P2P history. Compare:

- ZeroNet — mostly stalled; only libraries remain.

- Maelstrom (BitTorrent Inc.'s browser) — died early.

- Beaker — RIP 2022.

From the browser vendor side, P2P integration is so deep — across security and UX — that staying in library form is the realistic equilibrium.

10. Iroh (Number 0) — A Rust Reimagination of IPFS

**Iroh** is the **Number 0** team's **Rust-based IPFS reimagination**. Started around 2022, moved fast through 2024-25.

Core message: **"Keep the good ideas of IPFS, drop the baggage of the legacy implementations."**

What distinguishes Iroh:

- **Rust** — memory safety, fast binaries, friendly to embedded and mobile.

- **Small bundle** — full Kubo is tens of MB; Iroh is far lighter.

- **QUIC-first transport** — unlike libp2p's older TCP-first assumptions.

- **Focus on the connection itself** — getting two devices talking directly is the primary goal.

- **Holepunching emphasis** — a lot of engineering goes into traversing NAT.

Iroh describes itself as **"a library for moving files P2P, quickly."** It follows IPFS ideas but does not try to implement every feature of the IPFS reference stack.

A Rust sketch:

use iroh::Iroh;

#[tokio::main]

async fn main() -> anyhow::Result<()> {

let iroh = Iroh::memory().await?;

let blob = iroh.blobs().add_bytes(b"Hello Iroh 2026".to_vec()).await?;

println!("hash: {}", blob.hash);

Ok(())

}

When to choose Iroh:

- **Mobile or embedded** apps that need P2P file transfer.

- **Desktop apps where bundle size matters** (Electron, Tauri).

- **Rust backends** that want native P2P.

When to choose IPFS Kubo:

- **Full IPFS node functionality** is needed (public gateway, pinning, IPNS, MFS, etc.).

- **Compatibility with existing IPFS tooling and services** matters.

11. Banyan / Filecoin / Storj DCS / Arweave / Sia / Akord — Five Flavors of Crypto Storage

This section is about the **economic model** of where data lives. P2P protocols define how to address data, not who keeps the disks spinning — that is a separate market.

Filecoin

**Filecoin** (Protocol Labs) is the storage-market blockchain. The mechanism:

- Storage providers (SPs) advertise disk capacity.

- Clients make deals: "store this for N months."

- SPs periodically prove they still hold the data via **PoSt (Proof-of-Spacetime)** and **PoRep (Proof-of-Replication)**.

- Payments are in FIL.

The big change from 2024-25 was **FVM (Filecoin Virtual Machine)** — EVM-compatible smart contracts on Filecoin.

Banyan Storage

**Banyan Storage** sits on top of Filecoin as **end-to-end-encrypted cloud-storage UX**. Regular users do not see Filecoin at all; they get something Dropbox-like. The backend is Filecoin and IPFS.

Storj DCS (Decentralized Cloud Storage)

**Storj** is a P2P distributed store with an **S3-compatible API** front and center. Key tricks:

- Files are **erasure-coded into about 80 pieces** spread worldwide.

- Reconstruction needs only a subset.

- Pay in STORJ tokens or with a credit card.

The positioning is more "S3 replacement" than "Web3 storage." It is engineered for migration ease.

Arweave

**Arweave** is different. The keyword is **permanent storage**: pay once, "200 years" promised.

- Data lives on a modified blockchain called the **blockweave**.

- Miners must include proofs of past blocks as well as new ones (Proof of Access).

- Payment is one-shot: tokens for permanence.

Common uses: NFT metadata, academic material, content that cannot afford to disappear.

Sia / Akord

- **Sia** — an old (2014-) decentralized store. Its own token (SC). Direct host-renter contracts.

- **Akord** — a friendly UI on top of Arweave. Aimed at things like permanent family-photo backups.

Veera Network

Newer, eyeing P2P CDN and content delivery. Not yet mainstream.

One-liner matrix

| Solution | One-liner |

| --- | --- |

| Filecoin | Storage-market blockchain paired with IPFS |

| Banyan | User-friendly cloud UX on top of Filecoin |

| Storj | S3-compatible distributed storage |

| Arweave | Blockweave with "permanent storage" pricing |

| Sia | Older P2P storage with host-renter contracts |

| Akord | UI layer over Arweave |

12. Pintswap / Pollen — The Next Wave

**Pintswap** is a P2P token swap protocol. No central matching engine; OTC trades happen peer-to-peer over libp2p, with only the settlement signed on-chain.

**Pollen Network** is a P2P CDN vision — pooling spare bandwidth from user devices to serve content.

Neither is mainstream in 2026, but both illustrate **the pattern of P2P infrastructure slipping into the lower layers of dApps**.

13. web3.storage to Storacha (Rebrand, 2024)

From 2020 to 2022, **web3.storage** and **NFT.Storage** were Protocol Labs-run services that **let you throw a file at them and they would store it on IPFS plus Filecoin**, mostly free or cheap. Everything from NFT metadata to academic datasets ended up using them.

In 2024 web3.storage **rebranded to Storacha**, with operational responsibility splitting off. Key changes:

- **Name** — web3.storage to Storacha.

- **UCAN (User Controlled Authorization Networks)** for permissioning, in place of tokens.

- **w3up CLI** — a new client.

CLI in practice:

install

npm install -g @web3-storage/w3cli

log in (email)

w3 login your@email.com

create a space

w3 space create my-space

upload

w3 up ./my-file.png

Operationally, this is still one of the most approachable ways to host IPFS content.

14. NFT.Storage — Protocol Labs

**NFT.Storage** is the sister project focused on **NFT metadata**. Token IDs, images, attributes JSON — all parked on IPFS, originally free.

In 2024 NFT.Storage split into **NFT.Storage Classic** (free, minimal support) and **NFT.Storage v2** (commercial). Free-tier policy changes put a small crack in the "free permanent NFT metadata" promise, and some collections moved to Arweave as a result.

The lesson: **never trust a free IPFS pinning service to be permanent.** Someone always pays the bill.

15. Web5 (TBD55, Jack Dorsey) — Stalled

**Web5** is the vision Jack Dorsey's **Block** (formerly Square) and its **TBD** group (sometimes called TBD55) announced in 2022. The slogan: "Web2 usability plus Web3 decentralization, without tokens."

Design pillars:

- **DIDs (Decentralized Identifiers)** — users own their identity.

- **VCs (Verifiable Credentials)** — W3C standard.

- **DWNs (Decentralized Web Nodes)** — user-controlled data nodes.

The ambition was huge. Through 2024-25 the pace **fell off sharply**. As of 2026:

- Very few major dApps adopted Web5.

- The DWN spec is alive but commercial momentum is thin.

- "Token-less Web3" failed to differentiate from existing non-token decentralization efforts like Solid and plain IPFS.

It is a useful case study in **strong slogan, weak building momentum**.

16. Korea and Japan IPFS Usage Notes

P2P protocols are global, but regional examples ground the picture.

Korea

- **NFT metadata and digital asset preservation** — Klip and a number of Korean NFT projects use the IPFS plus Arweave combination.

- **Public data and digital archive experiments** — some libraries and the National Archives have evaluated IPFS as a content-integrity supplement.

- **ICON / Kakao Klaytn ecosystem** — some Korean web3 teams have published library work and tested their own distributed storage variants.

- **Domestic dApp community** — Helia and Storacha as backends for NFT marketplaces.

Japan

- **Sony Music and Japanese label NFT projects** — multiple cases storing metadata on IPFS.

- **Japanese web3 services and NFT marketplaces** — token exchanges and NFT platforms routinely dual-host on IPFS plus Arweave.

- **Publishing and archives** — some manga and literature archive efforts use IPFS as a backup.

- **Decentralized identity experiments** — proof-of-concepts inside Japan's Digital Agency.

Common thread: **"NFT metadata plus permanent storage"** is the scenario where IPFS and Arweave most often appear side by side.

17. Who Should Learn P2P Content?

| Role | What to study |

| --- | --- |

| dApp / NFT developer | IPFS (Helia), Storacha, NFT.Storage, Arweave |

| Distributed systems engineer | libp2p, IPFS Kubo, Iroh internals |

| Mobile / Tauri developer | Iroh, WebRTC, WebTorrent |

| Data archivist | Arweave, Filecoin, Banyan |

| Academic / research | IPFS, Arweave, Tahoe-LAFS |

| Censorship-resistance / human rights tools | IPFS, BitTorrent v2, WebTorrent, libp2p |

| Media / CDN | WebTorrent, Pollen, Filecoin |

Four reasons to learn it

1. **Permanent storage** — content that survives the company that uploaded it. NFTs, academia, journalism.

2. **Censorship resistance** — when single-host dependency is a problem. (And the responsibility, including for bad content, distributes too.)

3. **CDN cost reduction** — P2P can dramatically cut egress for large content.

4. **The systems-design fun** — libp2p, Iroh, Hypercore are excellent material in their own right.

When you should not use P2P

- **Internal web apps** — use S3 or Cloud Storage.

- **Fast MVP** — standard cloud is much quicker.

- **Compliance-heavy industries** — data-location tracking becomes harder.

**P2P is not a default; it is a tool for specific problems.** Do not try to put it everywhere.

18. A 5-Minute Decision Tree for 2026

| Question | Answer |

| --- | --- |

| Just want to drop a small file on IPFS | Storacha (formerly web3.storage) |

| Hosting NFT metadata | Storacha plus Arweave dual hosting |

| Real permanent storage (decades) | Arweave |

| Drop-in replacement for S3 | Storj DCS |

| IPFS node directly in the browser | Helia |

| Browser torrents or P2P video | WebTorrent |

| P2P file transfer on mobile | Iroh |

| Append-only collaborative data | Hypercore / Hyperdrive |

| P2P in a Rust backend | Iroh or libp2p (Rust) |

| Censorship-resistant video platform | PeerTube (ActivityPub plus WebTorrent) |

| P2P token swaps | Pintswap |

Epilogue — What Survived and Why

Twelve years on from IPFS's 2014 launch, the P2P content space has seen one full cycle of hype and consolidation. The pattern of what survived is fairly clear.

**Survivors share:**

- **A clear, single mission** — IPFS (addressing), Arweave (permanence), WebTorrent (browser).

- **A library form factor** — pieces other systems can embed, not just standalone full apps.

- **A persistent maintainer** — Feross, Protocol Labs, Number 0, Holepunch; people and teams who keep showing up.

**Those that died or stalled share:**

- **Outsized ambition** — Web5, Beaker Browser.

- **Single-company dependence** — when the sponsor cools off, so does the project.

- **No crisp value answer** — they could not explain why you should use them instead of standard cloud.

The right 2026 stance is not "all-in decentralized" but **"selectively P2P."** IPFS for NFT metadata, Arweave for permanence, WebTorrent for browser video, and S3 for everything else. That mix is the pragmatic one.

References

- IPFS — https://ipfs.tech/

- IPFS Docs — https://docs.ipfs.tech/

- Helia — https://helia.io/

- Helia GitHub — https://github.com/ipfs/helia

- Boxo (Go IPFS modular library) — https://github.com/ipfs/boxo

- Kubo (Go IPFS implementation) — https://github.com/ipfs/kubo

- libp2p — https://libp2p.io/

- libp2p Specs — https://github.com/libp2p/specs

- BitTorrent v2 spec (BEP 52) — https://www.bittorrent.org/beps/bep_0052.html

- BitTorrent v1 spec (BEP 3) — https://www.bittorrent.org/beps/bep_0003.html

- WebTorrent — https://webtorrent.io/

- WebTorrent GitHub — https://github.com/webtorrent/webtorrent

- Hypercore — https://hypercore-protocol.org/

- Hypercore GitHub — https://github.com/holepunchto/hypercore

- Holepunch (Pear runtime) — https://holepunch.to/

- Beaker Browser (sunset announcement) — https://beakerbrowser.com/

- Dat Project — https://dat-ecosystem.org/

- Iroh (Number 0) — https://iroh.computer/

- Iroh GitHub — https://github.com/n0-computer/iroh

- Filecoin — https://filecoin.io/

- Filecoin FVM — https://fvm.filecoin.io/

- Banyan Storage — https://banyan.computer/

- Storj DCS — https://www.storj.io/

- Arweave — https://www.arweave.org/

- Sia — https://sia.tech/

- Akord — https://akord.com/

- Pintswap — https://pintswap.com/

- Storacha (web3.storage rebrand) — https://storacha.network/

- web3.storage docs — https://web3.storage/docs/

- NFT.Storage — https://nft.storage/

- Web5 / TBD — https://developer.tbd.website/

- ActivityPub spec — https://www.w3.org/TR/activitypub/

- WebRTC — https://webrtc.org/

- Tahoe-LAFS — https://www.tahoe-lafs.org/

- PeerTube — https://joinpeertube.org/

- IPLD — https://ipld.io/

- Multiformats — https://multiformats.io/

- UCAN — https://ucan.xyz/

현재 단락 (1/346)

In 2026, when people say "decentralized content," everyone hears something different. One person pic...

작성 글자: 0원문 글자: 21,461작성 단락: 0/346