!!!
This document has moved.
You'll now find information like this in the ipld/ipld meta-repo, and published to the web at https://ipld.io/ .
All documentation, fixtures, specifications, and web content is now gathered into that repo. Please update your links, and direct new contributions there.
!!!
IPLD is a project with the long term aim of increasing the amount of technology which develops based on decentralized, "local-first" principles.
This is a very holistic goal: we want to increase the amount of such technology by making it easier to write such technology; by making such technology easier to use and consistently more reliably than its centralized counterparts; by making it clear that such technology can provide features and possibilities that centralized software simply can't. We want to make all of these things true in a harmonious self-reinforcing cycle of ecosystemic growth, where continuing development of decentralized local-first technologies makes more development of even more decentralized local-first technologies more appealing.
A Theory of Change is an understanding that some of our goals are very long term. We can't work on all of them directly: in many cases we have to plan for more reachable intermediate goals, identify ways to know we've reached those, and plan actions that lead to those intermediate goals; in other cases, it means we aren't pursuing goals directly at all, but just trying to support the right conditions for our desired outcomes to be able to emerge.
IPLD is the “data” layer of our vision for a Decentralized Web. However, since IPLD doesn’t really concern itself with how blocks are stored or how they are distributed, the work we’re doing can be leveraged by many projects and use cases beyond just “Decentralization.”
As an example, git is a decentralized technology built on decentralized primitives, yet most people interact with aspects of git through centralized services (GitHub, GitLab, etc). These services solve acute coordination problems while git itself delivers an unmatched user experience because it’s built on primitives that don’t assume a central authority.
IPLD brings a superset of the capabilities of git’s internals to the developer community. We don’t yet know how those will be leveraged, but it’s a fair bet that many of them especially in the near future, will use centralization or federation in order to solve some acute problems their applications face.
There’s both a gradual story to technical progress and a more radical one. The radical one is that certain core innovations spark fundamental changes in the computing ecosystem. Another says that adoption of technological changes are more gradual and that something that is too big of a change cannot be adopted quickly.
IPLD comes from the perspective of radical change (Let’s Re-Decentralize the Web!) but it’s a simple enough primitive that you can also see the case for it being adopted as part of a more gradual shift in computing, where centralized, federated and edge services adopt it to solve problems it’s uniquely well suited to. This increases general familiarity with the project and its primitives and lays the groundwork for continued gradual change towards fully distributed systems.
The great thing about IPLD is that we don’t have to pick one of these theories; IPLD is well suited to both and as long as we don’t assume our community will come from a specific perspective we can just release good code, plant a lot of seeds in different developer communities, and see which ones sprout and grow.
One concrete example we use to state our objectives in the IPLD project is this:
Imagine you want to write the next "git" (or imagine git hadn't been made yet, and you're about to do it). Some decentralized project: you know you need content-address data primitives, but haven't written it yet.
The goal of IPLD is to make that take one order of magnitude less time than it otherwise would have.
(Thereafter, we also hope IPLD made that project enduringly easier to debug, easier to build compatibility stories with other projects, easier to actually ship the content around, easier to build long term migration strategies for as the project evolves, and so on. But in general: all these things should be easier to do with IPLD in contrast to if you tried to do all these things alone.)