Today, we’re announcing the next phase of that work: our technical team is joining Filecoin Foundation. The open source technology we’ve built will accelerate the development of Fil One, a new S3-compatible Filecoin storage product that provides a unified Filecoin client experience. Fil One, which launched this week, is part of a new generation of Filecoin products, alongside the permissionless IPFS pinning and payment smart contracts of Filecoin Onchain Cloud.

The Storacha developer upload and IPFS service, however, will be shutting down.

That doesn’t mean your NFTs or your IPFS links have to break. Thanks to content-addressing and IPFS, you can seamlessly move your data to new pinning services. But you will have to move it — by the end of May at the very latest.

This post explains what’s changing, when, and what you need to do.

What’s shutting down

The Storacha developer upload service — Console, SDKs, and CLI, including UCAN support — is closing soon, and we’ll be winding down our IPFS services.

Here are the dates:

• Effective immediately: No more sign-ups.
• April 15, 2026: We’ll be disabling uploads. The console, SDKs, and CLI will become read-only.
• May 1, 2026: Content will no longer be discoverable on the broader IPFS network, though our own w3s.link gateway will continue to provide access to your data.
• May 31, 2026: The Storacha gateways (w3s.link) will stop serving content. Uploaded data will no longer be accessible through Storacha.

If you’re still uploading, April 15 is your deadline for uploads. If you need to retrieve or migrate stored data, May 31 is the cutoff. That means you’ll need to download your data if you don’t have it locally, and find an alternate IPFS service if you don’t already have one.

No charges during the transition

Paying customers will not be charged from April 1. You have the full transition period to retrieve your data at no cost.

Migrating your data

If your data is already pinned or backed up elsewhere, you may not need to do anything.

If you do need to move data off Storacha, your content remains accessible via the Storacha gateways through May 31. If you’d like a hand, we’ll be posting more detailed migration guides with step-by-step documentation by April 15.

For help planning your migration now, reach out at support@storacha.network.

Where to go next

If you need ongoing IPFS or Filecoin storage, here are some great options:

• Fil One offers S3-compatible object storage on Filecoin; the Storacha team will be working on Fil One at Filecoin Foundation.
• Filecoin Onchain Cloud’s Filecoin Pin service provides permissionless, onchain IPFS pinning and payments, part of the new Filecoin Web3 core.

By April 15, the Storacha technical team will provide specific migration tools to help you migrate your data to these services, or to other IPFS pinning services.

Thank you

To everyone who stored data with us, hung out on Discord, came to our events, and built on top of our tools: thank you. We hope you continue to explore the world of decentralized storage, IPFS, and Filecoin with us.

— The Storacha Team support@storacha.network

Storacha is a decentralized storage platform built for real-world teams. It gives you the power of content-addressed storage with UCAN-based authorization, but without forcing you to become a cryptography expert.

If you are building an app with Storacha, you will eventually need a way to manage content, monitor uploads, and verify permissions. The Storacha Web Console provides exactly that: a simple, visual control center for your Spaces.

What the Console Is For

The Storacha Web Console is not a replacement for the Storacha client. It is a companion tool.

The Storacha client is used to build real applications and automate storage flows programmatically. The console is designed for human operators who need visibility, control, and verification.

You can think of it like this:

Storacha client is for building your app
Console is for managing and monitoring your Spaces

The console gives you a clear view of what is stored in your Space, who uploaded it, and whether each upload was authorized correctly.

How to Access the Console

The only official console entry point is:

console.storacha.network

When you open this link, you will be asked to authenticate using email.

Here is the exact flow:

1. Visit console.storacha.network
2. Enter your email address if you don’t have an account
3. Check your email for a verification message from Storacha
4. Click the link in the email to confirm your login

This email-based login is the preferred and primary method for accessing the Storacha Web Console.

What You See in the Console

Once you log in, you will land on the dashboard.

The console dashboard is designed to be clean and intuitive, showing:

• Your Spaces
• Upload history
• Recent activity
• Storage usage

This is your control center. It provides an immediate snapshot of what is happening in your Storacha environment.

Spaces: Your Storage Buckets

In Storacha, a Space is like a storage bucket.

It represents a secure container where content can be uploaded, stored, and managed.

In the console, you can:

• View all Spaces
• Select a Space to see its contents
• Inspect Space details such as DID and activity

A Space is identified by a DID (Decentralized Identifier), and this DID is used as the authority reference in UCAN permissions.

Uploading Files Through the Console

One of the most useful features of the console is that it lets you upload files directly.

This is useful for:

• Testing your Space
• Verifying that your Space is correctly configured
• Quickly uploading assets for demos

The upload flow is simple:

1. Select a Space
2. Click Upload
3. Choose a file
4. Confirm upload

When the upload completes, the console returns a CID (Content Identifier). This CID is the cryptographic fingerprint of the content stored in the Space.

Understanding the CID

The CID is the core concept behind content-addressed storage.

Instead of referring to files by name or location, you refer to them by their content fingerprint.

This has two major advantages:

1. Content integrity
   The CID guarantees that the content cannot be changed without changing the CID.
2. Content deduplication
   If the same file is uploaded multiple times, it will produce the same CID, meaning the system can store it efficiently.

The console makes it easy to copy the CID and use it in your applications or for verification.

Upload History and Authorization Context

Every upload in Storacha is content addressed and backed by verifiable authorization at upload time.

• When you inspect an upload in the console, you can view:
  • the root CID
  • a public gateway URL for the content
  • the underlying CAR shard identifiers
• This gives operators confidence that the data was stored correctly and can be retrieved deterministically.
• At the time of writing, full UCAN proof chain details such as delegations and abilities are handled programmatically via the Storacha client and are not yet exposed in the console UI.

This is important because Storacha is built on the idea of cryptographic authorization rather than assumptions or hidden permissions.

Why the Console Matters

The console is valuable for multiple reasons:

1. Quick validation

Before you build an app, you can test storage flows and verify that your Space is configured correctly.

2. Non-technical management

Not everyone on your team is a developer. The console allows product managers and operators to manage uploads without code.

3. Auditing

You can inspect upload history and verify proof chains, which is essential for security and compliance.

4. Debugging

If your SDK integration is failing, the console helps you confirm whether the issue is with your code or with the Space configuration.

Console vs SDK

Both tools are important, but they serve different purposes.

The console is best for:

• Manual uploads
• Testing
• Auditing
• Monitoring

The SDK is best for:

• automated uploads
• building apps
• custom logic
• generating delegations programmatically

In practice, you will use both. The console for management and the SDK for production workflows.

Final Thoughts

The Storacha Web Console is a powerful tool for managing uploads and verifying access. It provides a clear, visual way to inspect your Spaces, monitor activity, and validate your storage configuration.

If you are new to Storacha, the console is the easiest way to start exploring the platform without writing code.

And once you are ready to build, the SDK will allow you to automate everything you did in the console.

About Storacha

Storacha is building the foundation for a decentralized internet based on verifiable, self-sovereign data. Backed by a $6.5M Seed round led by Protocol Labs Venture Studio, Storacha enables portable, programmable private data at scale through DIDs and UCANs — a breakthrough in decentralized access control. Its infrastructure powers entirely new possibilities: from AI agents securely sharing data, to games and dApps exchanging off-chain assets without relying on servers or middlemen. Storacha’s vision is simple: your house, your key.

When building on decentralized platforms like Storacha, debugging requires a new perspective. The process shifts from checking server logs and network routes to verifying cryptographic proofs and authority chains. This guide provides a clear framework for understanding and resolving issues with the Storacha CLI, helping you confidently navigate this different paradigm.

For developers who want to inspect data or explore Storacha’s internal structures, the Storacha CLI debugger provides commands for extracting multihashes, parsing delegations, and examining archived CAR files. It’s a resource for hands-on exploration,be sure to check it out.

Why Debugging Storacha Feels Different

With traditional centralized storage, an error like `Permission Denied` usually means checking a API key. In Storacha’s decentralized model, the same error requires you to verify a chain of relationships:

1. Your Agent Identity (the decentralized identifier or DID currently active in your CLI).

2. Your Active Space (the specific namespace you are targeting).

3. The UCAN Delegation (the cryptographically signed token that proves your Agent has permission to perform an action in that Space).

Failures are rarely about network reach; they are about **proofs, capabilities, and context. Understanding this is 90% of the solution.

First Steps in Any Debugging Session

When a command fails, start by methodically checking your environment. These initial commands can identify the majority of common issues.

1. Confirm Your Identity and Context

Always know who and where your CLI is operating. Your Agent (identity) and active Space (context) form the foundation of all subsequent operations.

a) Check your current Agent identity (who you are)

$ storacha whoami
Agent DID: did:key:z6MkfrV…8h3

b) List all Spaces you have access to and see which is active

$ storacha space ls
NAME DID ACTIVE
web-assets did:key:z6MkixX… true
archive-data did:key:z6MkaB2… false

c) If the wrong Space is active, switch to the correct one

$ storacha space use archive-data

2. Inspect Your Authorizations (UCANs)

Permissions in Storacha are explicit and granular. Use this command to see what capabilities your current Agent possesses for the active Space.

List all active delegations (UCAN proofs) for your current context

$ storacha delegation ls
RECIPIENT ABILITIES EXPIRES
did:key:z6MkfrV… space/blob/add 2024–12–31
did:key:z6MkfrV… upload/add 2024–10–15 ⚠️ EXPIRED

What to look for:

• Missing Abilities: Do you see the necessary capability (e.g., `space/blob/add` for uploads)?
• Expired Proofs: Has the delegation for a critical ability expired?

Diagnostic Flowchart: Finding the Issue

Follow this logical path to isolate the root cause of most problems.

Common Debugging Scenarios and Fixes

Scenario 1: Proof Invalid on Upload

This is the most common authorization error. It means the UCAN proof your Agent is presenting does not validate for the requested operation.

The Fix:

1. Ensure you are in the correct Space (see First Steps above).

2. Check your delegations for the `upload/add` or `space/blob/add` ability.

3. If it’s missing or expired, a user with admin rights to the Space must grant you a new delegation.

Example: An admin creates a new delegation for a developer

# Generate Unix timestamp for Dec 31, 2024 23:59:59
EXPIRE_TS=$(date -d “2024–12–31 23:59:59” +%s)

# Create delegation
storacha delegation create did:key:z6Mk7b9… \
 - can 'space/blob/add' \
 - can 'upload/add' \
 - expiration $EXPIRE_TS \
 - name "Developer Delegation" \
 - type app \
 - output developer-delegation.car

he developer would then load this new CAR file (developer-delegation.car) to update their permissions. After this, uploads using the delegated capabilities should succeed.

Scenario 2: Upload Hangs or Times Out

When `storacha up` gets stuck, the issue is often at the network layer or related to the file itself.

Diagnostic Steps:

1. Enable verbose logging to see the internal process:

storacha up ./large-video.mp4 — verbose

2. Analyze the output. Where does it hang?

• Computing CID…: The CLI is hashing your file. For very large files, this takes time.
• Signing with UCAN proof…: Authorization is being prepared.
• Connecting to IPFS nodes…: This is the network transfer phase. A timeout here suggests a firewall or connectivity issue.

3. Test with a small file to isolate the problem:

$ echo “test” > small.txt
 $ storacha up small.txt

Scenario 3: Content Not Retrievable via Gateway

You get a CID back from an upload, but `storacha open <cid>` or a public gateway returns nothing.

Possible Causes and Checks:

* Incomplete Upload: The network may not have fully propagated the data. Wait a moment and try again.

* CID Mismatch: Double-check that the CID you are trying to open matches the one output by the `storacha up` command exactly.

* Gateway Health: Test if the gateway itself is operational.

$ curl -I https://storacha.link/ipfs/bafybeia4gshp24x5s5ngbofr2jlsnwq2jqvl4kxbqaeyfjnaxu4eh4bawi

Automating Checks with Scripts

1. Check Authentication & Context

Checking Agent and Space context…

storacha whoami > /dev/null && echo “ ✅ Agent authenticated.”
ACTIVE_SPACE=$(storacha space ls | grep “true” | awk ‘{print $1}’)
echo “ Active Space: $ACTIVE_SPACE”

2. Test a Small Upload

Testing upload functionality…

TEST_FILE=”/tmp/storacha_test_$(date +%s).txt”
echo “Test payload $(date)” > $TEST_FILE
if CID=$(storacha up $TEST_FILE 2>&1 | grep -o ‘bafy[^ ]*’); then
 echo “ ✅ Upload succeeded. CID: $CID”
 # 3. Test Retrieval
 if storacha open $CID > /dev/null 2>&1; then
 echo “ ✅ Content is accessible via gateway.”
 else
 echo “ ⚠️ Uploaded but not immediately retrievable.”
 fi
else
 echo “ ❌ Upload test failed.”
 exit 1
fi
echo "✅ All basic health checks passed."

This script can be run from a CI/CD pipeline or a scheduled cron job.

Best Practices and Pro Tips

1. Start a Debug Session Methodically: Always run `whoami` and `space ls` first. This eliminates guesswork.
2. Leverage Structured Output: Use the ` — json` flag with commands to parse outputs programmatically in scripts.
3. Keep Delegations Minimal: When creating UCANs, grant only the abilities needed (` — can`) and set reasonable expirations (` — expires`). This follows the principle of least privilege.
4. Maintain a Delegation Log: Keep a simple record (a text file or spreadsheet) of outstanding delegations, their purpose, and expiration dates to avoid surprises.

Where to Find Help

If you’ve worked through these steps and are still stuck, the decentralized community is your best resource.

1. Official Documentation: The [Storacha Docs](https://docs.storacha.network/) are the definitive source for CLI options and concepts.

2. Community Support: Ask specific questions in the [Storacha Discord](https://discord.gg/storacha). Providing your error output and the steps you’ve already tried will get you better help faster.

3. Code and Issues: Check the [Storacha CLI GitHub Repository](https://github.com/storacha-labs/cli) to see if your issue is a known bug or to report a new one.

Debugging with Storacha is a skill that reinforces a deeper understanding of decentralized systems. By learning to trace the flow of authority through identities, spaces, and cryptographic proofs, you gain not just the ability to fix problems, but to build more robust and intentional applications on the decentralized web.

About Storacha

Storacha is building the foundation for a decentralized internet based on verifiable, self-sovereign data. Backed by a $6.5M Seed round led by Protocol Labs Venture Studio, Storacha enables portable, programmable private data at scale through DIDs and UCANs — a breakthrough in decentralized access control. Its infrastructure powers entirely new possibilities: from AI agents securely sharing data, to games and dApps exchanging off-chain assets without relying on servers or middlemen. Storacha’s vision is simple: your house, your key.

Imagine this: you’re out to dinner when the baby sitter calls you. She just got home from an outing with your kids but can’t get into your house.

You realize you didn’t let the big company that manages your home access know that you’d like her to be able to get in.

You try to login on the company website but it’s down for maintenance. It’s pouring rain. You drive home, only to find the rain caused an internet outage.

Without the company, even you can’t get in. You curse this company. You think to yourself “I’d switch tomorrow, but there’s a catch.” The catch is you’d have to sell your house and buy a new one.

This bizarre, contrived nightmare is what would happen in a world where for some reason, we didn’t just control access to our homes ourselves with simple locks and keys.

And yet, it closely approximates the way permissioning works on today’s internet.

How did we get here?

The early internet was a decentralized hodge podge of websites where all data was public. At some point, the internet needed permissions.

Early builders adopted existing technologies companies used for internal networks, a centralized directory of permissions managed by the company.

They applied the same model to websites, with each website managing a list of users, identities, permissions. That’s the internet we have today.

Unfortunately, using a permissioning model designed for working at a closed company leads to an open internet that feels a bit like digital serfdom.

Today, our data is locked in silos we don’t control. We need to remember a million passwords just to access it. Sometimes we have to pay just to share it.

Meanwhile most of the actual sharing happens because the company we stored our data with decides to sell it.

It makes you wonder: did no one invent a digital equivalent of a good old fashion key?

Cryptographic keys are everywhere on the internet today, and they allow us to unlock things. But that’s really only one half of what a key does.

My car key unlocks my car, and only my car, but it also gives me the right to drive it. By possessing my car key, I can drive my car without having to prove myself to anyone (unless I get pulled over for speeding).

I can give someone my car key so they can drive my car to pick up groceries. A real world key isn’t just to unlock, it gives you a capability as well.

Fortunately, this kind of digital key, one that both unlocks and grants capabilities, has existed in research labs for decades.

Now, as the internet becomes increasingly unusable under the weight of centralized permissions, web3 builders are by necessity looking for better solutions more suited to decentralized blockchain ecosystems.

In doing so, we’re rediscovering capability research. Now Storacha is betting big on User Controlled Access Networks, or UCANs, a technology that realizes the potential of this research for today’s internet.

Setup a space here with 5GB free.

How Storacha Uses UCAN

Storacha helped co-create UCAN along with authors Brooklyn Zelenka, Irakli Gozalishvili, Daniel Holmgren, and Philipp Krüger.

What is UCAN? (User Controlled Access Network) is a decentralized authorization protocol that uses cryptographic keys to grant capabilities, not just unlock access. Unlike OAuth or traditional API keys that rely on centralized servers, UCANs are self-contained tokens that work offline and enable peer-to-peer permission delegation.

UCAN technology is infused into almost every layer of our storage product. With the flexible digital keys UCAN provides, Storacha can do things you simply can’t do easily with any other storage product.

Consider the following real world Storacha customers and partners:

• Starling Labs and the Shoah Project enable journalists around the world to capture images and stories and upload to Storacha, without Storacha ever knowing their individual identities.
• OpenSea allows their users to upload to their storage account, but limits their capabilities on how much each user can upload based on a payment plan. Storacha plays no role in OpenSea’s user management.
• LIT Protocol offers a decentralized platform for secure encryption and private key management. Storacha’s encrypted upload client (public launch out soon, but already available in our open source libraries) combines LIT’s technology with UCANs to unlock something truly special: encrypted private data you can share, without re-encrypting, and without relying on centralized service for access control.

UCAN technology isn’t just important for customers, it’s critical to building Storacha’s decentralized storage network.

While blockchains are great as public ledgers to store critical accounting of transactions in decentralized systems, they’re still a bottleneck to network speed, when often a transaction can simply occur between two parties without going back to a central chain.

UCAN technology enables multiple parties to work together on behalf of a user, without a coordinating authority, because every action taken can be provably tied back through a cryptographic chain of provenance to an end user’s original intent (as well as their capability to carry out that intent).

Read UCAN technical specs here.

Towards a More Open and Empowered Internet

UCAN technology reflects a broader movement, a return to the foundational ideals of the internet: openness, innovation, and user agency. Originally conceptualized by Brooklyn Zelenka and others, UCANs are now being implemented by teams like Storacha and Infura as real-world solutions to the challenges of access control in a decentralized world.

For a generation that grew up in the shadow of closed platforms and centralized control, this shift may seem radical. But just a decade ago, the internet was alive with independent creators, open standards, and emergent networks. And before that, it was a vast, chaotic playground for collective expression. The internet can be that again — and more.

Storacha is committed to building the infrastructure for that future. UCANs are a key building block in making decentralized, user-owned systems viable at scale. We’re just getting started — and we invite you to build with us.

Setup a space here with 5GB free.

FAQ

1. How does UCAN work? UCANs chain cryptographic capabilities from a root authority (the user) through delegated permissions, creating provable authorization without centralized validation.
2. What’s the difference between UCAN and OAuth? OAuth requires online server validation; UCAN tokens are self-contained and work offline. OAuth centralizes control with the service provider; UCANs give users direct control over permission delegation.

About Storacha

Storacha is building the foundation for a decentralized internet based on verifiable, self-sovereign data. Backed by a $6.5M Seed round led by Protocol Labs Venture Studio, Storacha enables portable, programmable private data at scale through DIDs and UCANs — a breakthrough in decentralized access control. Its infrastructure powers entirely new possibilities: from AI agents securely sharing data, to games and dApps exchanging off-chain assets without relying on servers or middlemen. Storacha’s vision is simple: your house, your key.

Key People: Brooklyn Zelenka: UCAN co-creator, Fission founder, Storacha team: Former IPFS/Filecoin core developers at Protocol Labs

Related Technologies:
1. DID (Decentralized Identifiers): W3C standard for self-sovereign identity
2. IPLD (InterPlanetary Linked Data): Content-addressed data structures, Filecoin: Decentralized storage blockchain backing Storacha

Storacha Forge is a decentralized backup service built for organizations drowning in huge datasets that need long-term retention but not constant access.

It runs on verifiable decentralized infrastructure, with predictable pricing, true data sovereignty, using the Filecoin Onchain Cloud as part of its onchain verification layer.

If you’re storing terrabytes or petabytes of compliance archives, digital assets, historical analytics, AI training data, blockchain state backups, digital media repositories, or research and compliance records, Storacha Forge gives you the warm storage tier enterprises have been missing.

Want to talk deployment? 👇

https://meetings-ap1.hubspot.com/storacha

Why This Is a Big Deal

For years, enterprises have had two terrible choices:

• Pay hot-storage prices for data you barely touch
• Or shove it into cold storage and wait hours to get it back
• Cloud providers pretend to offer a “middle tier,” but hidden retrieval fees, slow speeds, and vendor lock-in keep it way closer to cold storage.

Storacha Forge finally delivers the middle tier everyone expected.

• $5.99 per TiB per month
• Drops to $1 per TiB after 18 months with lifecycle management
• Plus decentralized, verifiable storage.

The Real Cost Problem

Cloud pricing pushes you into extremes:

• S3 Standard: around $23 per TiB monthly
• Glacier Deep Archive: $0.99 per TiB, up to 48 hours to retrieve, plus fees that can hit hundreds per TiB

But real enterprise data sits somewhere between “hot” and “frozen.”

Think:

• AI training datasets
• DePIN telemetry and sensor data
• Blockchain state and node backups
• Media and rights repositories
• Research, compliance, and financial archives

These workloads can’t wait half a day, but they don’t need instant speed either. At $5.99 per TiB, Storacha Forge delivers about 75% savings vs S3 Standard while staying far more accessible than cold storage. For petabyte-scale orgs, that’s a full reset of storage economics.

Why Decentralized Storage Actually Helps

This isn’t ideology. It’s just practical.

1/ Much Lower Egress Fees AWS egress can hit $90 per TiB. Storacha Forge egress is $10 per TiB, which is 80% to 90% cheaper. And your data isn’t trapped by any single provider’s decisions.

2/ Verifiable Storage Cryptographic proofs confirm your data is stored correctly, unchanged, and available.

Regulated industries love this.

3/ Protocol Governance Your storage terms follow protocol rules, not quarterly earnings surprises or sudden pricing pivots.

4/ Flexible Locations It supports data sovereignty across multiple regulatory environments without giving up accessibility or performance.

Who Gets the Most Out of Storacha Forge

• AI and Media teams managing training data, model checkpoints, and digital assets
• Financial and regulated industries keeping audit-ready records plus long-term archives
• DePIN and blockchain networks storing telemetry, state, and transaction data
• Research and academia generating massive datasets with declining access needs
• Public sector and government needing transparent pricing and strong data sovereignty
• SaaS and digital businesses dealing with fast-growing analytics, logs, and user backups

Simple, Transparent Pricing

• $5.99 per TiB per month for storage
• $10 per TiB egress
• Free onboarding for 18-month contracts
• $1 per TiB per month cold storage after 18 months

Bottom Line

Enterprise data never fit neatly into “hot” or “cold.”

Storacha Forge introduces a real infrequent-access tier for large datasets that stay important but aren’t touched constantly.

You get predictable costs, verifiable durability, decentralized infrastructure, clean billing, and clarity on where your data lives.

For storage architects, data engineers, and IT teams, Storacha Forge is a practical long-term solution for keeping semi-active data secure and accessible.

Get Started

Connect with our team through 👇

https://meetings-ap1.hubspot.com/storacha

About Storacha

Storacha is building the foundation for a decentralized internet based on verifiable, self-sovereign data.

Backed by a $6.5M Seed round led by Protocol Labs Venture Studio, Storacha enables portable, programmable private data at scale through DIDs and UCANs, a breakthrough in decentralized access control.

Its infrastructure powers entirely new possibilities: from AI agents securely sharing data, to games and dApps exchanging off-chain assets without relying on servers or middlemen. Storacha’s vision is simple: your house, your key.

Introducing an unstoppable partnership between Storacha & Presearch.

The modern internet has become synonymous with a few companies.

A few who decide what we discover. A few who control where we store data. A few holding the keys to how most people access and cultivate knowledge online.

This dominance has gone largely unquestioned for decades, and the status quo has come at the cost of privacy, control, and independence.

The antidote is to intentionally rebuild the tools that have become integral to the human experience online.

Storage should not be locked in proprietary silos. It should be distributed across verifiable, community-powered networks.

Search should not be controlled by one company. It should be operated by thousands of independent participants.

Those rebuilding with purpose share the same goal: putting people first. This is where projects like Storacha and Presearch are aligning their efforts to make that future a reality even faster.

Presearch is a search engine that enables people to access information without profiling, filtering, or surveillance.

You can search without having your habits manipulated for ad dollars, all through the power of a decentralized infrastructure.

Storacha decentralizes storage giving true data ownership while ensuring that once data is created, it remains fast, verifiable, and accessible without relying on a single provider.

Together, decentralized search and storage form the backbone of a free internet.

Why Is Centralization a Problem?

Centralization means essential online services are in the hands of a single company or a very small group.

When you search on Google, one corporation’s algorithm chooses which results appear first.

When you store files in iCloud, one company controls the servers, the rules, and even whether you keep access.

It leaves billions of people dependent on a few gatekeepers.

Leading to four reasons why centralization is a problem:

1. Censorship and Suppression

Content can be buried, deprioritized, or removed with little transparency. Expanded information, independent journalism, and non-mainstream topics are often pushed out of sight.

2. Surveillance Capitalism

Every search, click, and upload becomes a data point sold to advertisers and used to refine a profile of your behavior.

3. Fragility

When major cloud services go down, a majority of the internet shuts down. One decision or mistake by a centralized provider can erase entire communities.

4. Bias
Algorithms optimized for advertising and engagement skew the information landscape. The results you see are what is most profitable, not what is most accurate or useful.

Decentralizing essential tools on the web reverses this imbalance that has gone on long enough.

Power is distributed across networks of people all across the globe, removing single points of failure or manipulation.

Communities of people are the core of the infrastructure and principles of a shifted system.

The shift has already happened through projects like these that enhance the pillars of the internet: how we find information and how we store it.

Presearch: Decentralized Search Engine

Search is how most of the internet is navigated. It’s how we find information, evaluate opinions, and accumulate knowledge.

Today, that key navigation tool is owned by a few corporate entities fueled by surveillance and advertising

Presearch is the alternative search engine for people who don’t want their data in the hands of companies who will sell it to the highest bidder.

Searches are routed through a network of computers, owned by people just like you, which removes the link between the user and the query.

Presearch does not track user activity or build behavior profiles. Search results are not tied to your identity or location.

This means that your results are not filtered, and you break out of the echo chamber to discover more with less corporate limitations.

Storacha: Decentralized Storage

If search is how we find information, decentralized storage ensures it remains accessible.

Storacha is a next-generation hot storage network built on IPFS and Filecoin, designed for fast, verifiable data retrieval.

Decentralized nodes keep frequently used data fast, and every file is cryptographically provable, so you know it’s your authentic, non-tampered data.

You don’t have to trust a single company, the trust is mathematically written in code.

Ownership and permission is kept in your hands, not a corporation’s, through UCANs, or User Controlled Authorization Networks.

Through speed, transparency, and sovereignty, Storacha provides a decentralized alternative to the corporate chokehold on your files.

How Search and Storage Work Together

Search without storage is fragile. Storage without search is invisible. Together, decentralized search and decentralized storage create a complete ecosystem for knowledge.

Presearch makes sure information can be found and helps you uncover suppressed content, all while maintaining your privacy.

Storacha makes sure that information endures while you have ownership.

This pairing matters because the problems of centralization are not isolated. They reinforce each other.

When storage is centralized, content can be deleted. When search is centralized, even surviving content can be buried.

Only by addressing both can we build an internet that is resilient, fair, and open.

Why This Matters Now

The urgency of decentralization has grown in recent years. AI systems increasingly determine what we read, watch, and believe.

They inherit the same biases that legacy information systems have been plagued with. Governments are pressuring platforms to police content more aggressively.

Outages at major cloud providers highlight the fragility of depending on a few data centers.

If we continue to rely on centralized search and storage, these trends will only intensify. AI models will be trained on biased data.

Content will disappear without recourse. And the boundaries of discovery will be set not by what exists, but by what corporations allow.

Decentralization offers a way out. It ensures that discovery remains open and that knowledge remains permanent.

It restores agency to users and communities. It builds resilience into the very fabric of the web.

The internet’s future will not be secured by accepting the status quo. It requires a foundation that prioritizes privacy, permanence, and independence.

Decentralized search engines like Presearch and decentralized storage networks like Storacha represent two critical steps toward that foundation.

The choices we make today about how we search, store, and share information will shape not just the future of the internet, but the future of knowledge itself.

Choose the Internet That Serves You

When you choose decentralized tools, you’re saying the web should serve people and communities, not gatekeepers.

Start here:

• Search privately: presearch.com
• Store it fast & verifiably: storacha.network
• Learn more: Presearch: presearch.com/learn-more · Storacha Blog: storacha.network/blog

About Storacha

Storacha is building the foundation for a decentralized internet based on verifiable, self-sovereign data. Backed by a $6.5M Seed round led by Protocol Labs Venture Studio, Storacha enables portable, programmable private data at scale through DIDs and UCANs — a breakthrough in decentralized access control. Its infrastructure powers entirely new possibilities: from AI agents securely sharing data, to games and dApps exchanging off-chain assets without relying on servers or middlemen. Storacha’s vision is simple: your house, your key.

What if “add private storage” was just an iframe?

DMAIL wanted private, wallet-native storage without trashing UX, so Storacha shipped an iframe pattern that drops military-grade encrypted storage into any SSO in ~30 minutes. DMAIL’s the first case study; any app can copy-paste it.

Encryption Without the Headache

DMAIL’s users are already comfortable with decentralized systems, but that doesn’t mean they want to manage cryptographic keys. The challenge was building enterprise-grade encryption that felt as simple as dragging a file into a folder.

Here’s what Storacha built:

• Files encrypted before leaving the user’s device
• Zero-knowledge architecture (even Storacha can’t see their data)
• Seamless integration with their existing workspace
• Enterprise compliance without enterprise complexity
• The ability to share and revoke access instantly

The solution involved three key pieces: UCANs for authorization, client-side encryption for security, and an iframe integration that makes it feel native to their app.

How It Actually Works

In DMAIL’s workspace, users see various widgets for different services — crypto analytics, portfolio tracking, data platforms. When they click on the Storacha widget, the Storacha console opens as an embedded iframe. But the magic happens in the authentication handshake.

Instead of creating another login, Storacha built an SSO bridge. DMAIL sends the user’s credentials via postMessage, and Storacha grants access only if the credentials are valid and authorized by the DMAIL/provider auth service. The whole process takes about 3 seconds.

// DMAIL sends auth data to embedded Storacha console
parent.postMessage({
  type: 'AUTH_DATA',
  provider: 'dmail',
  email: user.email,
  userId: user.id,
  sessionToken: user.token
}, '<https://console.storacha.network>')

// Storacha validates SSO token and creates UCAN delegation
const userDID = await validateSSOToken(ssoData)
const delegation = await createSpaceDelegation({
  issuer: serviceDID,
  audience: userDID,
  capabilities: ['space/*']
})

Once authenticated, users can create “Private Spaces”- essentially encrypted folders where each space gets its own RSA key pair.

The Privacy and Encryption Architecture

The interesting part happens when someone uploads a file. Everything is private and encrypted on the client side using symmetric keys, but managing those keys securely required some creativity.

Here’s the flow:

Upload:

1. User drags a file into their private space
2. Browser generates a random 256-bit AES key
3. File gets encrypted using AES-256-CTR as it’s read, allowing massive files to be processed without loading entirely into memory using streaming encryption
4. The symmetric key gets sent to Storacha’s UCAN-KMS server
5. UCAN-KMS validates the user’s permissions and encrypts the symmetric key
6. Encrypted file + encrypted key metadata gets stored on IPFS

Download:

1. User (or someone they’ve shared space with) requests the file
2. Storacha validates their UCAN delegation to ensure they have access
3. UCAN-KMS decrypts the symmetric key
4. Browser receives the symmetric key and decrypts the file locally

The result is military-grade encryption that feels like using Dropbox, but with mathematical guarantees that only users can access the plaintext data.

UCANs: The Secret Sauce

The authorization system is built on User-Controlled Authorization Networks (UCANs) — think of them as decentralized permission slips that don’t require a centralized server to validate.

When Alice wants to share a file with Bob, she creates a UCAN that says “Bob can decrypt files in Alice’s Legal Documents space for the next 30 days.” Bob can use this UCAN to prove his access rights without Alice needing to be online or manage a sharing server.

The powerful part is granular permissions. Alice can give Bob access to decrypt files but not upload new ones. Or access to one space but not another. And she can revoke access instantly by marking the UCAN as revoked in the system.

She can also create delegation chains — Bob could re-delegate limited access to Carol, creating an auditable chain of permissions.

// Alice creates delegation for Bob
const delegation = await createDelegation({
  issuer: alice.did,
  audience: bob.did, 
  capabilities: ['space/content/decrypt'],
  with: 'did:key:alice-legal-docs-space',
  expiration: Math.floor(Date.now() / 1000) + (30 * 24 * 60 * 60) // 30 days
})

// Bob uses delegation to access files
const file = await decryptFile(cid, { 
  delegation,
  proofs: [delegation] 
})

The Architecture That Made It Possible

DMAIL’s integration revealed something important about building developer-friendly infrastructure. The key was making encryption invisible to the end user while keeping it auditable for developers.

The UCAN-KMS server acts as a bridge between UCAN delegations and enterprise Key Management Services. It validates UCAN tokens and performs cryptographic operations based on the proven capabilities, without ever seeing the plaintext data.

This means:

• Only users can see their files
• KMS never sees the UCAN tokens or user data
• Each space gets its own RSA key pair, cryptographically isolated from others
• All cryptographic operations are logged for audit compliance.
• Every operation requires valid UCAN proofs.

The modular design means DMAIL could swap between different KMS providers or even Lit Protocol without changing their client code. The CryptoAdapter interface makes it provider-agnostic.

Integration Patterns for Any Provider

The iframe integration pattern built for DMAIL works for any SSO provider. Whether you’re building a productivity app, a messaging platform, or a collaboration tool, you can embed private storage in about an hour.

Storacha provides a test environment at console.storacha.network/test-iframe where you can see exactly how it works. The integration requires:

1. Embed Storacha console as an iframe

const iframe = document.createElement('iframe')
iframe.src = '<https://console.storacha.network/iframe?sso=your-provider>'
iframe.style.width = '400px'
iframe.style.height = '600px'
iframe.title = 'Storacha Console'
iframe.referrerPolicy = 'origin'
iframe.sandbox = 'allow-scripts allow-same-origin allow-forms allow-popups allow-top-navigation-by-user-activation allow-downloads'
iframe.allow = 'payment'
document.body.appendChild(iframe)

2. Send user auth data via postMessage

let communicationPort = null

window.addEventListener('message', (event) => {
  if (event.origin !== '<https://console.storacha.network>') return
  
  if (event.data.type === 'CONSOLE_READY') {
    if (event.ports && event.ports.length > 0) {
      communicationPort = event.ports[0]
      communicationPort.onmessage = handlePortMessage
    }
  }
})

function handlePortMessage(event) {
  const { data } = event
  
  switch (data.type) {
    case 'LOGIN_REQUEST':
      const authData = {
        type: 'AUTH_DATA',
        authProvider: 'your-provider',
        email: 'user@example.com',
        externalUserId: 'user123',
        externalSessionToken: 'session-jwt-token'
      }
      communicationPort.postMessage(authData)
      break
  }
}

3. Handle the auth response and file operation callbacks.

function handlePortMessage(event) {
  const { data } = event
  
  switch (data.type) {
    case 'LOGIN_REQUEST':
      // Send auth data
      break
      
    case 'LOGIN_STATUS':
      console.log('Auth status:', data.status)
      break
      
    case 'LOGIN_COMPLETED':
      if (data.status === 'success') {
        handleAuthSuccess(data)
      } else {
        handleAuthError(data.error)
      }
      break
  }
}

That’s it. Your users get client-side encrypted private storage without you having to build a cryptography team.

Storacha handles everything — key management, encryption, UCAN delegations, file sharing, access revocation. The iframe is just the entry point for apps to start using encrypted and private decentralized data storage. Applications just need to pass user credentials and listen for authentication callbacks.

The Bigger Picture

What started as DMAIL needing secure file storage turned into a pattern for embedding private storage in any application. The combination of UCANs for authorization and client-side encryption for privacy creates something interesting: truly user-owned data that applications can’t access without explicit permission.

DMAIL’s users now have private storage that feels native to their workspace. But more importantly, they have granular control over who can access what, with the ability to revoke permissions instantly. All without managing a single cryptographic key.

The technical implementation is more sophisticated than what most companies would build in-house (streaming encryption, key management, delegation chains, audit logging), but the integration is simple enough that it will take just an hour to integrate into applications.

The iframe pattern means any SSO provider can offer their users encrypted private storage without hiring cryptographers, managing key infrastructure, or worrying about compliance audits. What would typically require months of cryptography work becomes an afternoon of iframe integration.

Want to see how this works in practice? Try out the Storacha in Dmail at https://mail.dmail.ai/workspace or test the iframe integration at console.storacha.network/test-iframe. If you build something with these patterns, the community would love to hear about it in our discord. Want to go further inside the Storacha ecosystem? Check out the curated list: awesome-storacha

Happy building!

About Storacha

Storacha is building the foundation for a decentralized internet based on verifiable, self-sovereign data. Backed by a $6.5M Seed round led by Protocol Labs Venture Studio, Storacha enables portable, programmable private data at scale through DIDs and UCANs — a breakthrough in decentralized access control. Its infrastructure powers entirely new possibilities: from AI agents securely sharing data, to games and dApps exchanging off-chain assets without relying on servers or middlemen. Storacha’s vision is simple: your house, your key.

This guest post comes from Nico Krause, a team member exploring innovative ways to bring secure, verifiable workflows to life using Storacha.

In this write-up, they share how building an OrbitDB Storacha bridge is used to provide effortless backups and one-command restores. Read the original post here.

Introduction

In today’s decentralized ecosystem, data ownership and resilience are more important than ever. Distributed applications rely on decentralized databases like OrbitDB for peer-to-peer state management, but there’s always one big question:

How do we back up and restore decentralized databases in a way that is verifiable, reliable, and developer-friendly?

Orbitdb Storacha Bridge library seamlessly connects OrbitDB with Storacha a decentralized hot storage layer built on Filecoin to provide effortless backups and one-command restores. With just a few lines of code, developers can preserve their database across a decentralized storage network, ensuring permanence, verifiability, and recoverability.

What is OrbitDB?

OrbitDB is a serverless, distributed, peer-to-peer database built on IPFS and libp2p. Unlike traditional databases, OrbitDB doesn’t require centralized servers. Instead, it uses Merkle-CRDTs to ensure conflict-free replication across peers.

Key features of OrbitDB:

• Decentralized: No single point of failure.
• Multiple data models: Key-value store, event log, documents, counters, etc.
• Content-addressed: Every database entry is represented by a CID (Content Identifier).
• Use cases: Ideal for dApps, blockchain metadata storage, local-first apps, and distributed systems.

OrbitDB ensures that applications can run independently of centralized infrastructure but without backups, even decentralized systems risk losing continuity.

OrbitDB at a Decade: A Turning Point

With OrbitDB turning 10 and version 3.0 unlocking stability, and with Helia/libp2p enabling browser-native nodes, we’re standing at the edge of a software architectural shift

What is Storacha?

Storacha is a decentralized hot storage network designed to complement Filecoin by offering CDN-like performance with IPFS compatibility. Think of it as the high-speed “edge layer” for decentralized data.

Storacha provides:

• Scalable, low-latency storage for real-world apps.
• Filecoin-backed permanence with redundancy.
• UCAN-based permissions (User-Controlled Authorization Networks) for secure access.
• Developer-first SDKs for JavaScript, Go, and CLI.
• High availability (99.9%) with data integrity validation.

For developers, Storacha feels like using a modern cloud storage service but without centralization risks.

The goal of the orbitdb-storacha-bridge is to show how decentralized storage can power real developer workflows. OrbitDB by itself is great for peer-to-peer apps, but:

• Backups can be tricky to manage.
• Developers want permanence and redundancy.
• Restores should be fast and identity-preserving.

Storacha provides the perfect fit:

• Speed: Hot storage means fast backup and retrieval.
• Redundancy: Filecoin ensures data permanence.
• Verifiability: CIDs + Merkle proofs validate integrity.
• Ease of use: Simple APIs make integration seamless.

In short, Storacha transforms OrbitDB from a purely peer-to-peer database into a resilient, production ready storage solution.

Architecture & Workflow

Let’s break down how the bridge works.

Backup Flow

1. Extract Database Blocks
   > OrbitDB consists of multiple blocks: log entries, manifest, identity, and access control.
   > The bridge decomposes the database into these components.
2. Upload to Storacha
   Each block is uploaded to Storacha, stored as content-addressed chunks (CIDs).
3. Discovery & Indexing
   Files are registered inside a Storacha “space” for easy listing and future restoration.

Restore Flow

1. CID Conversion
   1. Storacha provides Filecoin/IPFS CIDs (bafkre...).
   2. OrbitDB expects its own CID format (zdpu...).
   3. The bridge automatically translates between the two.
2. Reassembly
   1. The database is rehydrated from the recovered blocks.
   2. Identity and access control metadata are preserved.

Roadmap

1. Current Status
   The OrbitDB Storacha bridge library integrates into a local-first peer-to-peer todo app, enabling backup and restore when peers or relays become unreachable.
2. Next Step: CustomStores
   Implement Storacha as a custom storage backend within OrbitDB.
   This means backups become implicit: every update is pushed in parallel to Storacha, enabling fresh installs of OrbitDB to sync immediately even without peer availability.
3. Authentication Upgrade: UCAN Delegation
   Currently, the library uses Storacha Key + Proof credentials. Future contributions aim to introduce delegated UCAN-based authentication, simplifying onboarding and access flow.
4. Hybrid SSR + PWA Mode
   Build hybrid apps using SSR frameworks (Next.js, SvelteKit, etc.) that fallback to full client-side P2P operation if servers go down. Such resilience enables apps to keep operating and replicating critical data even in infrastructural failure scenarios.

Quickstart & Code Examples

Getting started is incredibly simple.

Install

npm install orbitdb-storacha-bridge

Backup a Database

import { backupDatabase } from "orbitdb-storacha-bridge";

const backup = await backupDatabase(orbitdb, dbAddress, {
  storachaKey: process.env.STORACHA_KEY,
  storachaProof: process.env.STORACHA_PROOF,
});

console.log(`✅ Backed up ${backup.blocksUploaded} blocks`);

Restore a Database

import { restoreDatabaseFromSpace } from "orbitdb-storacha-bridge";

const restore = await restoreDatabaseFromSpace(targetOrbitdb, {
  storachaKey: process.env.STORACHA_KEY,
  storachaProof: process.env.STORACHA_PROOF,
});

console.log(`✅ Restored ${restore.entriesRecovered} entries`);

That’s it backup and restore in three lines of code.

Resources

1. Source Code: NiKrause/orbitdb-storacha-bridge
2. Relevant Docs:
   > Storacha : docs.storacha.network
   > OrbitDB: api.orbitdb.org
3. For Demo & Tests refer Readme.md.

Conclusion

The orbitdb-storacha-bridge project highlights the future of decentralized applications: databases that are resilient, verifiable, and permanently backed up all without relying on centralized servers.

With just a few lines of code, developers can:

• Back up OrbitDB databases into Storacha.
• Restore them with integrity and identity preserved.
• Confidently build apps that won’t lose critical data.

If you’re building decentralized applications, this bridge is a must-try.

Glossary

1. Peer-to-Peer Database (P2P DB)
   A database that does not rely on a central server. Instead, every participant (peer) maintains a copy of the database and synchronizes directly with others. In OrbitDB, peers exchange changes over IPFS/libp2p, meaning the app can continue working even if some peers or servers go offline.
2. OrbitDB
   A distributed, peer-to-peer database built on top of IPFS. It supports multiple store types (key-value, log, documents, counters) and works in both Node.js and modern browsers.
3. IPFS (InterPlanetary File System)
   A decentralized protocol for storing and sharing files using content addressing (files are identified by their hash, called a CID). OrbitDB uses IPFS for storage and transport.
4. CID (Content Identifier)
   A unique, cryptographic hash that identifies content in IPFS. Instead of referring to “where” a file is stored (like a URL), a CID identifies “what” the file is.
5. Libp2p
   A modular peer-to-peer networking stack used by IPFS and OrbitDB. It enables peer discovery, transport (WebRTC, TCP, WebSockets), encryption, and messaging.
6. Helia
   The modern successor to js-libp2p, designed for IPFS in browsers. It enables lightweight peer-to-peer nodes to run client-side, letting users spin up IPFS + OrbitDB instances directly in their browser.
7. Manifest
   Metadata that defines how an OrbitDB database is created and identified. It includes the database type, access controller, and other configuration details.
8. Identity
   OrbitDB uses cryptographic identities (public/private key pairs) to sign and verify database entries. This ensures only authorized peers can write to a database.
9. Access Controller
   The component in OrbitDB that defines who can write (or replicate) to the database. Common controllers include IPFSAccessController or custom implementations.
10. Blocks
    The smallest unit of content in IPFS. Files and database entries are broken into blocks, each identified by its own CID. Storacha backs up OrbitDB by storing these blocks.
11. Storacha
    A decentralized, Filecoin-backed storage layer designed to be UCAN-native and backend-less. It provides primitives like spaces, proofs, and delegations for secure and composable storage.
12. UCAN (User Controlled Authorization Networks)
    A cryptographic, delegation-based authorization system. Instead of centralized API keys, UCANs allow users to delegate permissions securely and verifiably. Planned for future integration in OrbitDB–Storacha bridge.
13. CustomStores (OrbitDB)
    OrbitDB supports defining custom storage backends. In the future, Storacha could be plugged in directly as a CustomStore so backups happen implicitly with every write.
14. Hybrid Applications (SSR + P2P)
    Apps that combine server-side rendering (SSR) frameworks (like Next.js or SvelteKit) with local-first peer-to-peer replication. Even if the SSR server fails, the client-side app (as a PWA) continues to run and sync via OrbitDB + IPFS + Storacha.

At Storacha, we’re building the backbone for a decentralized future powered by fast, portable, and programmable data. Today, we’re thrilled to announce a strategic partnership with Parasail, a protocol that will help you earn a share of next generation infrastructure through real-world utility staking and curated deal access. This collaboration marks the beginning of a long-term alignment between two foundational pieces of the web3 infrastructure stack. While there’s no code-level integration today, we share a common vision for scalable, verifiable, and performant decentralized systems — and we’re just getting started.

About Parasail: Own a Share of the Next Generation Infrastructure

Parasail is building the trust engine for the next generation infrastructure. It connects strategic capital with real on-chain infrastructure, giving investors and contributors a way to earn from decentralized networks without operating hardware.

This means that protocols can finally rely on trustless accountability: staked guarantees that services like compute, bandwidth, or hardware performance will actually be delivered. It also paves a possible way to earn yield from decentralized infrastructures by allocating capital strategically, without needing scale or hardware ops.

Why This Partnership Makes Sense

While Storacha focuses on blazing-fast hot storage on IPFS and Filecoin, Parasail tackles the trust layer, ensuring those offering infrastructure services are held to their promises. Together, we represent two sides of the same coin:

• Storacha enables performant, programmable data access
• Parasail ensures those services are reliably delivered and earnings are utility based and real without operating hardware

This is a strategic alignment based on shared values, not a technical integration (yet). But it sets the stage for future collaboration across co-marketing, ecosystem education, and potential touchpoints in decentralized service provisioning.

Looking Ahead: Building the Future of Infra, Together

As we continue to grow the Storacha network, we’re proud to align with protocols like Parasail who share our commitment to high-integrity, high-performance decentralized infrastructure.

Here’s what to expect next:

• Co-branded content drops across X and Discord
• Ecosystem storytelling around programmable data + verifiable trust
• Continued exploration of how SLA-backed incentives can strengthen the storage stack

This is just the beginning. Storacha and Parasail are aligned on one simple truth: the decentralized web will not scale without performance and trust. Together, we are working to make both accessible.

About Storacha

Storacha is building the foundation for a decentralized internet based on verifiable, self-sovereign data. Storacha enables portable, programmable private data at scale through DIDs and UCANs — a breakthrough in decentralized access control. Its infrastructure powers entirely new possibilities: from AI agents securely sharing data, to games and dApps exchanging off-chain assets without relying on servers or middlemen. Storacha’s vision is simple: your house, your key.

About Parasail

Parasail creates simple, efficient ways for anyone to earn from next-generation infrastructure: from GPU networks and data centers to CDNs and power grids. Built fully on-chain and integrated with DeFi, Parasail maximizes both utility and liquidity.

This guest post comes from Akash, along with fellow builders Dhruv, Gulshan, and Devansh, a team exploring innovative ways to bring secure, verifiable workflows to life using Storacha. In this write-up, they share how they built a DocumentSigner tracking system powered by UCANs and IPNS, enabling tamper-proof, decentralized document verification. Read the original post here.

Introduction

In an era where decentralized technologies are gaining traction, the need for seamless, server-independent document workflows is rising. Enter DocumentSigner on Storacha a proof-of-concept system built atop Storacha, IPFS/IPNS, and UCANs that enables secure PDF signing and signer tracking without any backend infrastructure.

What is DocumentSigner?

DocumentSigner is a decentralized document signing application built using Storacha. It allows organizations, employees, contractors, or freelancers each identified by a DID to securely sign agreements. Permissions and access are granted via UCAN delegations, and the entire signing workflow is facilitated through decentralized storage and linking, eliminating reliance on centralized servers.

Architecture and Workflow

1. Upload & Initial Setup:
   > The PDF agreement is uploaded to Storacha as a directory, returning an IPFS CID.
   > A UCAN delegation is created for each signer with embedded metadata DID, signing window (notBefore, expiration), and the file’s CID.
2. IPNS for Tracking State
   > An IPNS key is generated (and stored in localStorage) to manage a mutable pointer to the current version of the document.
3. Signing Process
   > Signers use their UCAN to open, sign, and submit updates. After signing, a new directory (containing signed.pdf, original agreement.pdf, and delegations.json) is uploaded, yielding a new CID. > The IPNS name is then updated to point to this latest CID, effectively tracking document evolution.
4. State Resolution & Comparison
   > To check who has signed, the system resolves the IPNS name using https://name.web3.storage/name/<ipnsName> (preferred over cached resolution).
   > It fetches and parses embedded JSON from the PDFs (delegations.pdfand signed.pdf), allowing comparison of pending vs completed signatures all without a backend.

Why Storacha, UCANs and IPNS?

Storacha is used as the decentralized storage backbone for this DocumentSigner demo because it provides all the primitives required to make the signing flow completely backend-less:

• CID Generation : Every uploaded file gets a unique, immutable Content Identifier (CID) via IPFS.
• Space-based Uploads: Files are uploaded directly to a user’s storage space without relying on central servers.
• UCAN Embedding : UCAN (User Controlled Authorization Networks) tokens can be generated and embedded to delegate granular, time-bound permissions to specific signers.
• No Centralized Backend : All logic and data storage happen client-side or on decentralized infrastructure, removing the need for traditional servers.

This architecture is complemented by:

• IPFS (InterPlanetary File System): Content-addressed storage for PDFs, ensuring immutability and verifiability.
• IPNS (InterPlanetary Name System): Mutable pointers that can update to reference the latest signed document version while keeping a permanent reference name.
• UCANs : Decentralized authorization tokens defining who can sign, whatthey can sign, and when.
• DIDs (Decentralized Identifiers): Unique identities for organizations, employees, or contractors participating in the signing flow.
• w3name: Library for generating and updating IPNS names and keys directly in the browser.

Together, these technologies make it possible to:

• Store agreements securely on decentralized storage.
• Delegate signing permissions without a central authority.
• Track document signing status in real-time via IPNS updates.
• Maintain complete transparency and version history of signed documents.

This combination of Storacha, IPFS, IPNS, UCANs and DIDs demonstrates how modern Web3 tools can power practical, secure, and self-contained document workflows without a backend.

Resources

1. Source code: Github (Contributor: Gulshan)
2. Storacha UCANs: storacha/ucanto
3. Storacha Docs: docs.storacha.network
4. Implementation Blog: Tracking System
5. DocumentSigner Docs:
   📂 docusign/docs
   📄IPNS Management
   📄UCAN Generation
   📄Decode UCAN
   📄File Upload
   📄Signature
   📄Track