Timeline OS: Building on the Solid Web
Why I'm betting on Tim Berners-Lee's vision for data ownership, and the lessons learned trying to build with it.
Timeline OS: Building on the Solid Web
We trade personal data for services. Big tech companies gather detailed profiles of our habits, preferences, and relationships. The centralized model creates data silos that are targets for hackers and opaque to the users whose information they hold.
Timeline OS is my response to this problem, a personal operating system for managing the stream of data that defines our lives. At its foundation is Solid, Tim Berners-Lee's vision for a decentralized web where you own your data.
The problem: walled gardens everywhere

Your data is scattered and trapped in silos. Each app (Facebook, LinkedIn, Google, your bank) creates its own separate, inaccessible database. You have limited control and portability. Vendor lock-in is the norm.
Between 2009 and 2019 alone, data breaches resulted in the theft or loss of over 230 million healthcare records in the United States. Centralized data is a prime target for attacks.
The solution: personal data pods

Solid proposes a different model, Personal Data Pods. Your data lives in a secure online vault that you control. Apps connect to your data. They don't own it. You grant and revoke permissions as you see fit.
The benefit is data interoperability. Because your data is stored according to open standards, you can switch between compatible apps without losing your information:
"If a user decides they no longer prefer their current messaging application, they can switch to another one without losing any contacts, message history, or existing conversations."
Lessons from the frontier
I've spent considerable time building on Solid, and the tools are still under construction.
The ecosystem of libraries, documentation, and servers needed to support the vision is a work in progress. API documentation where key functions are labeled "subject to change, even in a non-major release." Libraries that are buggy. On one occasion during development, a major section of the API reference disappeared for hours.
For most organizations building today, Solid isn't a practical option yet.
The control paradox
A foundational principle of Solid is that the user has ultimate control. They decide who can access their data. This sounds ideal, but when applied to complex procedures like healthcare, it creates a paradox.
To allow a doctor to edit a patient's medical records, the patient must first possess the permission to edit those records themselves. In healthcare, a patient should not be able to alter their own medical history. That could have dangerous consequences. The current Solid specification struggles to accommodate these rules.
The enterprise gap
For an enterprise, the blocker is Identity and Access Management, not the vision. IAM inside a company isn't "can this person log in." It's audit trails that satisfy a regulator, role-based access a hospital or a bank can defend, and integration with the identity systems already running the building. Solid's model (every user owns their pod and grants access peer to peer) has no clean answer yet for "the compliance officer needs read access to these 4,000 employees' records, logged, revocable, and provable in an audit two years from now."
One of Solid's founding motivations was that centralized data silos are fat targets for ransomware. But a federation of millions of individually-governed pods trades one big target for a sprawl of small ones, each with its own access rules and its own ways to be misconfigured. You don't remove the security problem. You redistribute it.
The momentum reflects this. Since October 2024 the has stewarded the Solid specification, while , the commercial steward, has shifted its framing toward consumer data wallets. The center of gravity is moving toward the individual, which is exactly where the IAM problem is smallest.
Why I'm still building
I still believe Solid is the future. My dissertation on enterprise Solid development put it this way:
"Solid will remain as a passion project at the brink of breaking into the mainstream."
Beyond folders and files
My research led to three findings about how to design personal information systems:
1. Usage-based organization beats hierarchies
In 1990, Yukio Noguchi introduced a paper filing system with no categories. Documents go in envelopes, and each time you use one, it goes back to the left side of the shelf. Frequently used documents naturally migrate left. Unused ones accumulate on the right for easy archiving.
Timeline OS takes the same approach, temporal flow over rigid folders.
2. Navigation vs. search: different memory systems

Despite the power of modern search, people prefer finding files by navigating folders. Studies show 56-68% of file retrievals are done by clicking through folders, while only 4-15% use search (sources in Why Your Brain Prefers Folders).
fMRI studies explain why. Navigating a file hierarchy activates the posterior regions of the brain, the same structures we use for real-world spatial navigation. It's largely autonomous, running in the background. Using search activates the left-lateralized frontal regions, associated with language and working memory.
So when you're trying to write a report, using search forces your brain to compete for the same linguistic resources needed for your primary task. Navigation doesn't interfere, because it uses different cognitive pathways.
"Navigating through our folder structures uses the same brain area as navigation through the real world." — Yael Benn et al., 2015
Good systems should support both. Timeline OS provides a visual timeline you can navigate and a command prompt you can query, matching how your brain actually works.
3. Your body as interface
In my Bachelor's thesis (2009), I introduced the "Resting Hand Gesture" for multi-touch interfaces. Placing your hand flat on a surface triggers context-sensitive menus at your fingertips.
That principle guides Timeline OS, technology that adapts to human behavior, not the other way around.
The vision
Timeline OS organizes your life along the three axes people actually use to find their way back to their own data, , rather than the single hierarchy a filesystem forces on you:
- Temporal: when did it happen? Every item carries a timestamp for free.
- Thematic: what is it about? Tags and types that filter without refiling.
- Social: who was involved? The axis most tools quietly ignore.
Those three came out of research, not a UI decision, and they get their own post: Three Ways Back to Your Own Life. Each person's data lives in a personal pod (nodes in a fungal network, the rhizomorphs this whole project is named after) that can publish, connect, and be queried, always on your terms.
What's next
The system is being built one project at a time, each a self-contained tool that also acts as a "mod" in the larger whole:
- eidotter: the shared design system that gives every project the same DOS terminal look and, eventually, the same pod plumbing.
- Pomodoke Calendar: scheduling, the time axis made concrete.
- Tracker: habit tracking with retro themes; a steady feed of dated, personal events.
- DOSBTS: diabetes data as a dedicated instrument you own, not a service you rent.
None of them need Solid to be finished to be useful today, which is the point. Each works on its own now, and each is built to connect to your pod the day the plumbing is ready. Solid stays, as my dissertation put it, "a passion project at the brink of breaking into the mainstream." So I'm building the things that will be waiting for it when it arrives.