#The Web as home: who owns your home directory?

Earlier we saw the network becoming the operating system.

But where is the user's home directory, and who controls it?

Linked data gave us names and meanings that can cross application boundaries, but it did not give that data a home.

On a normal computer, the home-directory question has an obvious answer, at least in theory. Your documents, photos, music, projects, notes, saved games, half-written novels and badly named folders live somewhere that is more yours than the applications are.

You can install another text editor without rewriting every document. You can open an image in a different program. You can remove an application and, if the world is not too cursed, your files remain.

The Web did not follow that example.

Your mail lives in the mail application. Your photos live in the photo application. Your calendar lives in the calendar application. Each service brings its own account, storage, permissions, interface, business model and export button if you are lucky.

That is convenient for the maker of the application. Everything can be designed as one system. It is often convenient for the user too, until they want to replace one part of it.

Software moved into the network. The user's home did not come with it.

#A sideways look

One way to describe the modern Web is:

application -> account -> data

The application is the starting point. You choose an application, create an account inside it, and your data begins to accumulate there.

There is another way to organize the same elements:

identity -> data -> applications

The person is the starting point. The data lives near that person. Applications receive permission to read or change parts of it.

The elements have not changed. Only their order has.

In the first version, replacing an application means moving your life from one system to another.

In the second, replacing an application can be closer to changing tools on a workbench.

Sometimes moving the boundary changes the problem more than solving it ever could.

For this second shape to work, the important things cannot all be owned by the application.

Linked data helps different tools understand the same things. But by itself, it does not organize the world differently. Identity, storage and permission must also exist independently of the application.

#Connecting to Solid

https://solidproject.org/ There is a project called Solid that explores this kind of world. https://solidproject.org/

Solid separates identity and data from applications. A person has an identity on the Web. Their data can live in storage they choose, usually called a pod. Applications ask for permission to read or change parts of it.

The Solid protocols add shared infrastructure for identity, storage and permissions to the Web. They do not prescribe a calendar, notebook, shop or social network. Those belong higher up.

Solid servers and libraries provide a platform on top of those agreements. A notes application can write a note without also becoming an identity provider, storage service and permission system.

Linked data describes what the data means and how it relates to other things. Solid decides where that data lives, who controls it, and which applications may use it.

Solid adds to the Web rather than replacing it. It can be useful without becoming the answer to everything.

#Applications as visitors

Once data and identity live outside the application, the application no longer has to become a kingdom before it can be useful.

A calendar can concentrate on appointments. A contacts tool can concentrate on people. A notes editor can concentrate on writing notes. They can work with the same people, places and events without sharing a codebase, framework or owner.

An application can arrive, do useful work, and leave without taking the user's world with it.

A library lets another program reuse code. Shared data lets another application reuse what a person has already made. The first saves the programmer work. The second keeps the user's world from being trapped in the first application.

Reusable software is not only software that can be imported into another program. It can be software that can be replaced by another program without taking the user's world with it.

A better tool does not first have to persuade you to abandon everything you made with the old one. It can ask for access and try to be better.

Innovation can arrive from elsewhere because your world is not sealed inside the original application.

#Where the complexity goes

None of this removes complexity.

Permissions can be confusing. Applications may disagree about data. Vocabularies can drift. Two tools may change the same thing at the same time. Storage providers can fail, disappear or become less friendly than they were when you chose them.

Centralised services hide many of these problems by making one organization responsible for the whole system. That can be a good bargain. One account and one button are easier to explain than identity providers, storage providers and access rules.

Moving the boundary does not make the problems disappear. It makes them shared problems instead of private details hidden inside each application.

Those problems are the point. They show where the real work needs to be done. They are the price of giving independent tools room to exist.

Solid may fail for social reasons, business reasons, usability reasons, or because another system finds a better shape. Standards do not win merely by being sensible.

Final forms have not done very well in this book.

#Small tools, not kingdoms

Back in the knitted castle, the reusable thing turned out not to be only the code. It was the boundary around the code.

Solid moves that boundary around the whole application. The application itself can become one of the replaceable parts.

A private application asks:

How can we keep the user inside?

A personal Web asks:

How can this tool remain useful after the user replaces it?

The second question does not require Solid as its only answer. But Solid is a serious attempt to build the answer into the Web itself.