Your documents aren’t really yours: The case for decentralized document management

Centralized platforms put your data at risk. Decentralized document management with IPFS is the fix.

It’s Monday morning and like many of my colleagues, I open my inbox and get a report from a business partner as an attachment. And like every morning, I find myself thinking:

Why don’t they use our Teams workspace?

It raises the question: How do we exchange documents across institutional boundaries? In practice, it usually comes down to two options: sending email attachments or using centralized platforms like SharePoint, Google Docs, and similar tools. Later in the article we’ll see that email is actually not such a bad choice, so let’s first analyze the implications of using a centralized platform for the collaboration. It implies that in a network of participants (e.g. from different organizations), there is one participant that hosts the platform. For now, it is not relevant, whether the platform is cloud-hosted or on-premise and if it is open source or not – the relevant implication is that one participant has ownership of the platform and therefore the data.

Problems of centralization

When using centralized platforms, three problems arise:

• Integrity: It is hard to reliably trace if and how documents were changed. Of course most document exchange platforms have audit logs and show changes, but these are not immune against internal or external attacks on the platform. One option is to trace the fingerprints (hashes) of documents by all participants, but this is rarely done in practice. Therefore users from all organizations have to trust that the documents are not changed and in environments with low trust levels, this discourages the usage of such platforms.
• Availability: Even if data is not manipulated and integrity is maintained, participants have to trust that it remains available. Yet this cannot always be guaranteed – outages occur or because of political reasons. One known case is the removal of access rights to the Microsoft platform of the chief prosecutor of the International Criminal Court. The same risk applies to any centralized platform whose operator can simply revoke access or block a participant.
• Ownership and control: Especially in political or business contexts, owning the data creates an imbalance: if one party hosts and controls the data, collaboration with others is no longer truly on equal footing. An alternative is to have an intermediary participant which stands next to or above the network of organizations which collaborate. However this intermediary has to be neutral and adds to the complexity of collaboration which adds friction and inefficiency.

Note that these architectural aspects are mostly non-functional and a business user might not care where the document is uploaded as long as it can be accessed by the relevant contributors in the specific business context. Nevertheless they create risks for the digital sovereignty of each organization and we assume that many business users consciously or unconsciously are aware of them. We believe that this is one of the reasons that email is still very popular. Beyond its simplicity, users know that the document ends up in both the sent and inbox folders of all participants in the conversation. A downtime or manipulation of an email server does not have any impact on the rest of the network. It is a truly decentralized system, though it comes with other drawbacks – to keep documents in sync, plenty of emails are sent with document versions and every participant has to consolidate attachments manually.

Read more: 5 forces driving DevOps and AI in 2026

The proposal: Sovereignty through decentralization

To address these issues, storage and control need to be decentralized across the participants in a network instead of relying on a single host. It is worth distinguishing distribution from decentralization here: what matters is not that data is stored in several locations under a single admin account, but that each participant has full control over its own copy of the data.

The technical foundation for this is content‑based addressing using the InterPlanetary File System (IPFS) within a private network of participants. In IPFS, files are not identified by where they are stored, but by cryptographic hashes of their content. If even a single bit changes, the identifier changes. This provides integrity and tamper‑resistance at the protocol level. Thanks to content‑based routing using a distributed hash table, it doesn’t matter which server physically stores the data; the network finds the content by its hash, much like BitTorrent.

Each organization explicitly decides, via “pinning,” which data it wants to keep locally and persistently. To restrict the network to a specific consortium and maintain data governance, you can use private swarms and cluster keys. This way, you keep the benefits of decentralization while blocking unauthorized access from the outside. Every member runs its own node, redundancy avoids single points of failure, and collaboration returns to a level playing field.

A decentralized IPFS network for document management has two main challenges:

If all collaborators want to agree which documents should remain pinned in the network, typically a pinning service is used. Pinning itself, though, reintroduces a centralized component in the architecture. To resolve this, an IPFS-cluster component can be used, which is a decentralized orchestration component for IPFS pins. It can execute configurable policies which pins should remain on which nodes and can therefore make a centralized pinning service obsolete.

When working with different versions of documents, each document has a new IPFS identifier, because the hash of the document changes. This makes it difficult to link documents to each other (e.g. for the version history). This can be solved using the IPFS cluster metadata services, which maintain metadata fields even if the document identifier changes.

Using TruSpace: A practical implementation

To validate the idea of decentralized document management, we implemented a practical open source implementation of these concepts: TruSpace, an AI‑assisted helper for document collaboration built on a private IPFS backbone. Documents and their edit history are stored as content‑addressed IPFS objects, distributed across the participants’ nodes. Every change creates a new hash, which means that if any document were manipulated it would actually result in a different document because of the new hash. Meta-data is used to link various objects together in a user-friendly interface: documents, their location in workspaces, tags, chats, permissions. In addition, the documents are analyzed with an AI using pre-configured prompts, e.g. for executive summaries or inconsistencies in the document. The results of the AI analysis are IPFS objects as well and distributed in the network. In order to prevent dependencies to centralized LLM providers, the analysis is run locally using ollama and an open source LLM of the user’s choice.

The implementation is available on GitHub and OpenCode and can be tested in a sandbox environment on truspace.dev.

Summary and outlook

Digital sovereignty means retaining full control over the integrity, availability, and ownership of your data. Moving away from email‑based or centralized platforms toward a decentralized, content‑addressed network combined with local AI gives organizations exactly this autonomy across institutional boundaries. Tools like TruSpace make this approach practical, secure, and efficient. On Monday morning, my inbox should contain nothing but links to my TruSpace node — no attachments, sovereign data control.

That said, purely decentralized approaches still come with challenges. Decentralized architectures often require rethinking UX and have a larger installation and maintenance effort than a single centralized installation. Future development will likely focus on using such decentralized networks more as a data integration layer. In other words: building bridges to other open source systems like NextCloud or Paperless NGX, combining IPFS‑level sovereignty with the familiar user experience of existing tools.

More from We Love Open Source

• Want to get into AI? Start with this.
• 5 forces driving DevOps and AI in 2026
• Deep dive into the Model Context Protocol
• Open source won, so why are we still fighting?
• How AI Is changing government technology collaboration forever