When I was working at CERN, in 1989, it was the time when computers were becoming essential in the workplace, helping people better document the projects they were working on. Importantly, it was also the time these computers were increasingly starting to be connected to the––then twenty-year-old––internet. Despite the fact that computers were connected to it, people were not using the internet to manage their projects, and their computers were doing nothing to help with collaboration. Overall, the net was not a very accessible space then, being mostly used by academics and scientists.
Working with various different experimental groups at CERN, I was becoming increasingly frustrated by the different and incompatible computer systems people were using, and the resulting inefficiencies. So, I thought, “What if there was a way to use the internet to create one big, virtual documentation system?” I imagined and proposed a system to connect together all these systems into something like one big, hypertext book. One big web.
When I thought about the system I wanted to build, I wanted an instrument for collaboration, for remote creativity, for learning, and for connecting. I wanted to connect people to one another, anywhere in the world, and help them share their ideas.
Each of the people working on a project with me should be able to plug into the project on the web, learn all they need to know, add the work they do into the warp and the weft of it, and then leave knowing that everyone else could see and use what they had contributed. The people should be in a sort of equilibrium with the project web, in that whenever they knew something it didn’t know, they could tell the web immediately and intuitively, and others could learn of the update immediately.
On a larger scale, if there was someone on one side of the world with 50 percent of a solution to a big problem, and on the other side of the world someone with the other 50 percent of the solution, then the web should be the medium through which their knowledge would be combined, and the problem solved.
I was lucky that the internet already existed as an open, permission-less space. It was because of this openness that I was able to build the web on top of it. I didn’t have to ask anyone’s permission to use it. And I knew that the web, too, had to be open and permission-less, in turn.
The first web server went live in 1991. And from then, the web grew exponentially. The first code I wrote for the web was for the NeXT computer, which was my main development system. The program, WorldWideWeb.app, was what we now call a web browser, but it was also an editor. Not just for reading, but also for writing. That was because, for me, the read-write nature of the web was very important. But the web took off very much more as a read-only medium rather than the two-way space I had hoped for.
Why was that? Well, the original code allowed you to edit web pages and save them to your local files on your desktop. In my case, my desktop computer was also a web server. So, anything I edited on my local files was automatically on the web. But for most people out there, it was not easy for them to set up a web server themselves, and often their desktop computer would be behind a firewall of some sort, and their website would not in fact be visible to people outside the company.
Another thing: I didn’t write the code to allow you to save back files into the web itself, mainly because you can’t just let anyone write to your web server. You have to have a system of users and passwords and sets of users who have access and restrictions for those who don’t. So, for one reason or another, the web took off as a medium with a few publishers and a lot of readers––and not the collaborative mind meld I had hoped for!
Real collaboration on the web currently happens at places like Google Docs, GitHub, Jira, and, to a certain extent, on Facebook. These platforms have set up their own sets of users, ways to manage those users, and ways to let you control who gets to access what.
Reflecting back, what do I wish I could have added to the web back then? Well, let’s start with common standards for single sign-on. You can’t share documents, media, or files across platforms unless you have a global concept of identity. With single sign-on, instead of having to choose whether to log on with Facebook or Google or Twitter, you would log on with your ubiquitous sign-on to access anything on the web.
Then let’s imagine that given interoperability between different sign-in systems, you had standards for groups, so Facebook groups and LinkedIn groups were all compatible, allowing you to share anything with any person and in any group. In 2021, perhaps some of the most powerful collaborative tools are currently in fact the calendar systems. These do break down the barriers between the social networks. When you fire up your calendar program on your laptop or on your phone, it pulls in calendar data from several different places: your personal calendar, your home calendar, and your work calendar for various organizations. You might also have public calendars for public holidays, and maybe for the times when your favorite band or sports team is playing. These come to you through different forms of authentication and group membership, and then, crucially, they are all merged into one view, so that, if someone asks you whether you can do dinner, you can see all the reasons across your life for saying no. And when you add or change things, the people who have been given access to your calendar will get to see those updates. This is all quite important––I have known people who have attributed the survival of their relationship to good shared calendars!
I want that power of integration across all social boundaries, with access control and delegation of responsibility not just for calendars, but for everything. This means building new protocols and new interoperable standards for many application areas, like contacts, social media, health, and fitness. And I want all those domains to link together seamlessly in a way that they don’t when they are handled by a hundred different apps on phones or computers. These differences between the power of the web I would like to see and the frustrating situation we have now form a large but tractable design challenge. And we are working on this now.
The project––the movement––is called Solid. Solid began in 2015 at MIT and is a better way to connect people and data. It is an open-source, web-based protocol for organizing data, applications, and identities on the web. Solid uses existing web standards, like HTTP, web sockets, and linked data. The Solid spec is a universal API between servers and stores, built on existing web standards, and separates the apps from the data. Whichever app a user runs, it stores the data in the user’s personal online data store—or “pod.” A pod is like a personal web server for a user’s data: a personal data cloud, like a USB key in the sky. With Solid, a user can share anything with anyone, or no one, and each user has a choice of apps to use with the same data. Users are in control of their data and decide which entities and apps can access their data. Developers also benefit from being able to tap into a rich tapestry of data and can focus on the functionality of their app without having to create a specific back-end for each app. Organizations establish a new type of relationship with their users—built on trust and mutual benefit.
Solid flips the current dysfunctional world of data silos upside down and puts the user on top. In fact, it flips the web right side up! It puts users back in control, in a way they were when everyone could have their own website and blog. The same sense of sovereign identity, of a contributor among peers, a sense of agency as an individual.
Importantly, Solid is also about trust, and getting people to feel safe in the online world. For me, what the web needs now is Solid.
Three years ago, I started a company to bring commercial force to the uptake of Solid and empower people with their data, called Inrupt. Inrupt is working with businesses and governments across continents. For example, the government of Flanders is providing every citizen with a Solid pod. They are creating, with our help, a data utility company, like an ISP or an electric company, but for Solid pods. Other countries are looking at giving citizens pods for things like tracking skills and jobs, health, fitness, and so on. Companies are working with us to allow their customers control of their data and how it is used across various sectors of the retail industry. Tech companies are joining the movement to play their role and new business models in the new Solid ecosystem. Open-source developers have found the Solid project and have played with apps to see what is possible, and are working to imagine a new experience to design a new world, leaving behind the preconceptions of what social networks have to be like.
As I have said before, the future of the web is so much bigger than the past. And just because it exists in the way it does today does not mean it needs to stay this way. When we see the issues with the web and the internet today, we can and need to fix them. The internet has gone through many phases and changes in its fifty-year history. Let’s introduce Solid as essential in web 3.0, and use it as a platform, an enabling platform as I have always wanted, for people to be able communicate across boundaries of all sorts, and for that communication to be creative, collaborative, and––I would add, in 2021––compassionate.
What is the future of the internet? Thirty years after the creation of the first web page, what have we learned about the impact of the internet on communication, connection, and democracy? Join the Knight Foundation for Lessons from the First Internet Ages, a virtual symposium that will explore and evaluate what key figures in the development […]