Solid: taking back the Web through decentralization
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Verborgh, Ruben
Solid is a new ecosystem for the Web, in which people store their own data instead of having to upload it to applications. This changes how we will build apps: we no longer have to harvest people's data, but ask permission to access people's data space. Solid was created by the inventor of the World Wide Web, Sir Tim Berners-Lee. Its mission is to reshape the web as we know it. Solid will foster a new breed of applications with capabilities above and beyond anything that exists today. Within the Solid ecosystem, people decide where they store their data. Photos they take, comments they write, contacts in their address book, calendar events, how many miles they run each day from their fitness tracker… these are all stored in their Solid pod. This Solid pod can be in their house or workplace, or with an online provider of their choice. Since they own their data, they are free to move it at any time, without interruption of service. People can give apps permission to read or write to parts of their Solid pod. So whenever they’re opening up a new app, they don’t have to fill out their details ever again. Things saved through one app are available in another: syncing is never needed, because data stays with people. This approach protects people's privacy and is also great for developers: we can build apps without harvesting massive amounts of data first.
 2019 marks the 30th birthday of the World Wide Web. In those 30 years, the world has changed a lot, not in the least because of the web. The web has changed the way in which we communicate, in which we find information about things, in which we learn things, also the way in which businesses done all over the globe. And to me, the most important thing of the web is that it is something for everyone. When Tim Berners-Lee created the web, his idea was that it should work for anyone regardless of where you come from, where you're now, where you're going. This independence of anything was the most important thing. It was about connecting people, about sharing information. And fortunately, as you know, the web is under threat these days from different angles. One of the most important problems is that we have lost control of our personal data in our online and offline lives. And actually, this is something that worries me. I guess a lot of you as well. Maybe that's why you're here. It also worries Tim Berners-Lee himself, because this is not why he created the web. Fortunately, there is a plan, an idea of how to solve things. And that plan is a project, a mission called SOLID. So I'm here to talk about SOLID today. And with SOLID, we aim to reshape the relationship that people have with their data and the applications that they use. And fundamentally, SOLID is about choice. We want to get back to that web where we can choose whatever we want to do independently of the large platforms that are there. So today, let's talk about universality and innovation, main drivers behind the original vision of the web. And then have a look at the web of the future, what a new relation between apps, data, and people should look like. And finally, let's of course also talk about development, how will the developer experience change if we make all of these things happen? First of all, of course, let's talk about the web, let's talk about the role of centralization in the history of the web, and let's talk about a main problem that we have today, which are of course the walled gardens. So 30 years is a long time, maybe too long for many of us to remember the world before the web. But what happened before the web was it was very hard to exchange information because there was high heterogeneity around the world. And there was different hardware that people use, different software was very hard to communicate. It was also very hard to innovate because if you wanted to build software for which machines would you build, for which platforms would you build, right? Those were hard questions these days. So the main thing that the web changed was universality. The web strived to be universal because it was independent of many things. And anyone in this room and everywhere else can use the web regardless of the hardware you're using. You can use it from a laptop, from a mobile device. You can also use it with whatever operating system you want, with whatever browser, the choice is yours. And this was a real revolution that the web has brought. This is very great for innovation because instead of wondering which system to pick, you just build for the web and it works everywhere. At least that's a philosophy. And how this works is through standards that provide the needed interoperability. The web, because of these things, brings freedom of expression to everyone across the world. And the principle there is that anyone can say anything about anything. And it has given a voice to many people who didn't have such a voice before. And the good thing is we all have our own spaces on the web. Everyone can create a website, you can say it's your opinion and I don't have to agree with it, you're free to do so and no one controls that. And if you want to discuss the opinion of someone else, well, we can link to them. We don't have to copy them, we can just point to it even though we might agree or disagree with them. The other side of freedom of expression is that of course people started doing that. They started exercising their rights. They started writing their own blogs and websites, sharing things from wherever they wanted to share them. So that was a very good time of birth creativity. And unfortunately that time seems to be a bit behind us given what's currently happening, but I'll talk more about that in a bit. Why I have seen because of that revolution is lots of social platforms, if you still remember, what is it, 15 years ago, things like delicious, for sharing bookmarks, flicker, for sharing pictures and so on. So there were platforms that were enabling the independence that people had and they were enabling them in sharing content because they made it so much easier. The other side of it is that the web also made innovation easy because anyone can build anything for any reason. It's like the developers equivalent of freedom of speech. And this is called permissionless innovation because you can develop whatever you want. You don't depend on hardware, software, you just build for the web. So you don't need anyone's permission to join the web and launch a new idea. And if you say, well, of course, think again because in app stores that's not the case. You depend on a centralized party to have your app approved. So the web is completely different in that regard. Permissionless innovation has been responsible for crazy ideas, things that 15, 20 years ago seemed like pure sense fiction, but nowadays are pretty normal. I took an Uber to get here. Of course I did. What else would I have done? And this shows the power of universality and permissionless innovation. Now of course this has some assumptions about whether or not there are central parties. So let's talk about history of centralization and decentralization. When the web started, decentralization was actually the default assumption. Many things were decentralized back then, the internet, email, and so on. So that's not new about the web. What was new about the web is universality, the fact that the decentralization system would work with many platforms. And the first threat to this universality started with a browser war. If you still remember around, well, the end of the 90s, the 2000s, if you didn't have internet explorer, well, you're out of luck and that's the one browser you need. But this means that you were obliged to start buying certain kind of computers that would be capable of running this software otherwise you would be excluded from the web. And this also means as a developer you depended on Microsoft for your speed of innovation. So even things like obliging people to use a certain browser can have a very big impact on the ecosystem. So this universality is important. So how did the browser wars end? Well, they never really ended. They just got replaced by another war because at some point it didn't matter anymore which browser you were using. What mattered was the first page that you used to get on the web. And that means that, well, if you're not on Google as a company, you're out of luck. So this means that we see that ranking in search engine is certainly a target, not great content. And this again provides a danger. It also means that if you as a developer want to innovate, well, you better make sure that whatever you do ranks highly on Google if not there's no point. So again, that's another way of how innovation is impacted by centralization. And how did this war end? Well, it didn't really. It just got replaced by yet another battle. And these are of course the platform wars that are still ongoing today. You're not on Facebook while you're out of luck. There's a couple of things you cannot use because you only have the sign in with Facebook button. And what we saw is that clicks suddenly became much more important than having high quality content. So this has totally shaped the way that we use the web. And for developers, it means that, well, you either compete with Facebook if you also try to harvest lots of data, or you depend on Facebook because you need people to log in with Facebook on your website, otherwise they will not join. So this coples your innovation to their innovation. And this is not great for universality, privacy, or innovation. So let's do a bit on this last topic of the walled gardens that are created by such social media. And by the way, I don't seem to pick on any platform in particular. I'm here to sketch what's happening to the web with a couple of examples. So what happened today is that our data has become centralized and only a handful of platforms on the web. What used to be on people's personal blogs a couple of years ago is now on Facebook, is now on Twitter. And of course, those platforms, they must be credited for providing a great user experience, but at the same time, we have lost control of all the data that we put on them. This has far reaching consequences for privacy. I don't have to tell you that. In fact, you've been told it so many times that you probably don't really care too much anymore. However, it also endangers the web's universality. And this is bad for all developers who want to build things on the web. The sign-in buttons are a threat to the web, but what's also a threat to the web is the apps. Like, hey, it works better with a native app. But this is madness if you think about it. I mean, the great thing about the web was that finally we could use one piece of software to browse all information of the world. Now that we have had this for 30 years, what do we do? We start using specific apps again to browse information. So this is kind of a big step backwards if you think about it. This creates the wild gardens because what those social networks and other networks on the web do is they harvest data. Their main business model is getting as much data as possible. And this creates a situation where, for instance, I cannot share a photo on Facebook with my colleagues on LinkedIn. I have to either move the data or move the people. And this creates those gardens where you have to really climb across them in order to be able to share content. This is not the web. The web could just link to things and there were no barriers before. Of course, the main problem here is that this massive centralization, it hurts diversity in the web. It hurts innovation. It also hurts the choice that people have. And let's be honest, if you have a budget on time to build one API integration, will you choose Facebook.com or will you choose a very specific provider with lots of privacy? I mean, there's a market reality. We have to follow what is happening, obviously. So this means that developers start depending on such centralized platforms for data and identity. And if you don't want to depend on them, well, you have to become one of them, basically. If you can't beat them, join them. That's a sad reality. So people lose control of their data and it's very hard to switch to other apps because if you switch to another app, well, too bad because your data is left behind. So this means that even if you have great ideas for innovation, people are locked in. So you cannot convince them as easily to move around. And this brings us back to the irony of permissionless innovation because you can ask, like, hey, how did this happen? Didn't we have this great idea that we could build whatever we want? Well, unfortunately, permissionless innovation is so permissive that it even allows platforms that go against this idea. And I think it was very beautifully phrased in the Guardian where they said that the Facebook founder has no intention of allowing anyone to build anything of his platform that does not have his express approval. And profited mightily from the web's openness, he has kicked away the letter that elevated him to his current eminence. I think it's really, really beautiful metaphor because if you see the web as a native platform, you see all those letters that people are getting because of the web, and then you build a platform, climb on top, and you just kick it away because it's not needed anymore. And that's kind of what happened, unfortunately. However, let's not keep on talking too much about the past and all the problems. They're there. Let's not keep on talking about them. Let's have a look at a different way to do things that might prevent what's happening today. So I'll talk about Solat, and the most important thing there is choice. We want to give people back the choice that has always been theirs on the web. So the Solat ecosystem enables people to pick the applications, the websites, and so on that they want to use, while at the same time giving them the opportunity to store their data wherever they want, and that's the new thing. So this means that people can control their data, and they can share it with the apps and the people that they choose. How does this work concretely? Well, this is a view that we're all very familiar with today. It's a social media post, and how this would work today is that all of the pieces of data that built this view, they're stored in a single centralized space. What we're saying here is that you will get the choice to store your data wherever you want. So concretely, if this is my social media post, well, this profile picture there is mine. So I store it in my data space in my data pod. My name, of course, mine is also stored there. The text itself is also stored in my data space. If you place a comment on my message, well, this comment is yours. Your data space, the picture is yours, your data space. If someone else replies to your comments, well, it goes in their data space. I think you get the picture. Even a piece of data, as small as a like, if you say, I like this, well, this like is yours and it can be stored on your data space. So you can choose for whatever piece of data you create where it is stored. And this creates a very different world. So first, I briefly look at what we have today. In essence, the problem that we have is that data and applications are coupled together. So when we say Facebook, when we say LinkedIn, we mean my Facebook and my LinkedIn because it's the data that they have about me in an application. This has a couple of problems. As I said before, it's very hard to share data across things. Another terrible problem is synchronization. If, for instance, I indicate on Facebook I'm going to this event, well, then Doodle won't know about it or Mike Heller won't know about it. So because data is closely tied to the application, so you have this constant synchronization problem and you can share across boundaries. So that's what happens with data silos. But what if we push the data out of those silos? The applications on this side don't contain any data because the data is in people's personal data pots. And this completely changes the picture because I can pick any application. I can, for instance, start with a social feed. I can post a picture and the picture is stored in my personal pot. And then when I open a photo gallery application, well, I can view the same picture. So there's no need to synchronize because data never leaves my space. There's only one copy of it, really. And this switching between apps is really important. Now, this is great for privacy, obviously, because I can control what apps get to see my data. It sounds so very great for a choice because now I can pick any app I want. If I don't like an app, I can move, if I don't like my data provider, I can move. So that's a story for people. There's also a very intriguing story for developers. Because this is what you have today. We have a single market for centralized apps where the competition is based on data ownership. Here on this side, whoever has most data will win. It doesn't matter how good you are, just get the most data you can. And this is really bad because if someone has a creative idea, they have trouble entering the market. Suppose you invent something really simple. It's called a slider of disagreement. It's a feature that we all want. We want to indicate on the social feeds to see more or less content we disagree with, right? Filter bubbles and stuff. It's a feature everyone wants if you build it while tough luck. You will never get an option because you cannot enter the market since you don't have the data. This is what happens when you have a competition based on data ownership. Very bad for innovation. Indeed, if you think about it, can you name me any feature that Facebook or Twitter or LinkedIn have built in the past five years that really have drastically changed your life? You probably can't. They don't have to innovate to have the data already. If you want to innovate too bad, you don't have the data. This changes when we move data out of apps and to your people. Because then you get a separate competition between data storage and applications. This is not a competition where the winner takes everything. This is a competition where multiple things can coexist. Here I can pick my app independently of my storage provider. The app that I like might be different from the app that you like. You pick whatever you like, I pick what I like, and it still works. Also storage-wise, we might have choices. I might want to store my data in the cloud. You might want to store it in your basement on your own server. All of those things become possible. This will also change the way we think about markets. Because right now you cannot choose. You cannot go to Facebook and say, hey, I will pay you 10 bucks a month if you don't mind my data. Well, you cannot do that. Here I expect there will be lots of choice. Just to give you an example of how interesting it will be, I expect that there will be free providers of data storage, but there will probably be minor data that will be the terms and conditions. I expect there will be paying solutions, and they will not mind my data. I even expect there will be solutions that will pay me to put my data there, but then, of course, they will definitely mind my data. This just shows how much choice there can be, such an ecosystem with two markets, and the kind of innovations that you can have there. This is a theory on how it works on a higher level. Let's have a concrete look at what is there in a solid ecosystem. Solid is a project started by Tim Berners-Lee, and it's much bigger than that. It's in fact the whole community of people working on these things and sharing these values. There's not a company, an organization, it's not just software either. It's an ecosystem, it's a movement, it's a community. An ecosystem in the sense that solid, one of the main tasks we have, is defining standards for interoperability. We try to define as few standards as we can. What we mostly do is reusing existing web standards, existing W3C standards to enable these kind of things. It's not a new web, it's the existing web with a couple of existing standards that we bring together. Solid is also a movement in the sense that we want to shift the way that apps are being built. Nowadays, as a developer, you depend on data to succeed. If people join your application, you need to first ask them lots of questions to get the data, and one of your biggest tasks is collecting data. What if it weren't? What if you build apps in such a way that you don't keep the data, that you access people's data that they provide to you? They can skip all those data harvesting tasks and focus on what you're really good at. Finally, solid is also a community, so there's different people in there, there's different companies, organizations trying to make solid into something great. Because solid is based on standards, anyone can build or host software for solid. This means that you can have a server at home or possibly also a server at your workplace. There's open source software for that, so nothing stops you from doing that. You can run servers, you can use one of the three community servers, all of those things are possible. A lot of choice there. The solid server, what is it exactly? It acts as a data plot, personal storage of any kind of data, it stores it and it will guard your data. In fact, a solid server is just a regular web server with support for access control and support for link data. I will explain link data in just a minute. The solid server is completely application agnostic, so you can build any kind of application with it, you're not restricted to specific domains. All the application specific logic resides inside of the client applications. In a way, a solid server is just like your website. This is not a new or revolutionary, it's just like the old days where you would start your own website, except it's not composed of web pages, it's composed of elementary pieces of data. That's the only difference, but conceptually it's like just getting your own website. What kind of data is inside of a solid plot? Anything you can imagine. It's your personal data store, whatever you want to store there. I'm thinking specifically of profile data, pictures, comments, likes, anything you do online or offline, you can store there. It's your space, it's safe, so put there whatever you want. What are clients then? Well, solid clients are browser apps or perhaps native apps that read from your pod or write data to your pod. So what can we have? Well, the idea is that you give apps specific permission. So you say, look, this app is, for instance, photo apps, you can only see my photos, don't touch any of my other personal data. Friends can give you permission to access things. So if one of my friends says, well, hey, these are pictures I want you to see, then I can use any of my apps to have a look at their pics. And what those apps do is they deliver a unified experience. So you can browse your friends' pictures along with yours. Like, if they use totally different applications to create pictures, it doesn't matter. You use your apps and you have a seamless experience of everything in your network. If you think about it, this is kind of how computers in general work. Like, you know, people make files, they send them around, and then I use whatever program I have to open those files. Well, it's very similar, except it's for the web. So what kind of apps can we build? Well, this is where your creativity comes in. Everything you can envision, you can build with SOLID, just like you can build anything for the web. Permissionless innovation, right? So calendars, social feeds, photo sharing apps, perhaps even assistance to organize conferences like this one, all of those things are possible. You name it, if you can build it, well, you can build it with SOLID. So that's about the ecosystem. Let's also talk about the community of people making things happen and what is the current state of all of these things. Well, so the SOLID server is there, there's several apps, and I would say at the moment, don't let the general public look at it. It's very relevant to the edges, but as a developer, you can already go there and start building things. So there's a SOLID server, and you can store your data online for free. We've got a couple of places such as those two where you can store your data, but if you don't want to, you can just start your own. It doesn't really matter. For instance, I have my own server, application-wise, we have a data browser, we have contacts apps, photos apps, and so on. So all of the things you would expect. Now, the difference is that these apps don't work with one single backend. They work with the whole web. So for instance, a contacts application doesn't just read your address book, it can read all of the contacts that you have access to. And of course, we also have a couple of software libraries that make it easy for developers to build on top of SOLIDs, and for instance, authentication is there, data processing, so all the low-level stuff you need to get started. Now SOLID is currently transitioning. It used to be a research project under MIT Wings. Now it's becoming much bigger, and there's also a startup within the ecosystem that tries to kickstart it. So it started growing at MIT as a research prototype, but through this, and I'm a researcher myself. In research, once you prove it works, you have to move on. So there's no time for building things like a user experience, production grade software, and so on. So this is why it's a good idea that it's taken to the next level. And one of those startups is called Interrupt, and it's a startup that Tim Berners-Lee himself is backing. And the idea of Interrupt is to accelerate development. So we want to open up the ecosystem for all. We want to maintain a couple of common building blocks as open source. We want to create tooling for developers, and we want to offer services and apps. Now it's very important to understand that these things are different, because I've heard some people being very concerned about this. Oh wait, so you have this ecosystem, and now there's a startup, and you're going to take our data again, or no, this is not how it works. We just have to be very pragmatic. If we want an ecosystem such as this one taking off, we have to show that there's business in there. We have to do that. And I own an academic myself. I don't care too much about business. But if you don't do that, it doesn't work. You need a couple of companies to drive the ecosystem, to make sure that commercial things are being built as well. And I think that by showing, yes, there is economic value in such a way of thinking as well, that we can unlock the potential of the whole ecosystem. And also as I said before, someone has to think about user experience, about maintaining production, great software, and so on. And so interrupt is now taking on that role for the ecosystem. However, very importantly, interrupt as the only company with Insolid is never going to work. Like we need competition to grow there. Because remember when I was talking about the two markets, the whole idea is based on competition. So if there's only one player, it doesn't really work. So what interrupt hopes to do is to show, look, this is how you can do nice things with Insolid. But the whole goal of this is that there becomes competition to the ecosystem, that there's different companies with different views trying to build this for everyone. While it is a time I look like, while a couple of years ago, 2014, was the start of the project at MIT, then a couple of months ago, we had a launch of interrupts, which give quite some attention to the Solid ecosystem. Just last week, we released a developer toolkit and a common UX experience. So if you want to start building on Solid, it's now a lot easier. And we hope that in some months, we'll have an MVP of the ecosystem that not just works for developers, but also works for regular people so we can send anyone there to try and have fun with it. And maybe as of today, if you like what I'm talking about, you can also become involved and this is a new step for the Solid project. We'll see. Which brings me to the next part, how does development on top of Solid work? Well, there's two things we need to talk about on the one hand, the way APIs and clients work is obviously going to change substantially. And then we also need to look at, given these change circumstances, how we should start developing web apps. So what you have currently is, if you look at what developers do, they're building apps that are specific to a certain backend. So if I'm building an app called X, well, I will build them backend and a front end and they will work together, but X will not work with any other backend and the backend itself will probably not work with any other application. So this is how we build things today. It's all reinventing the wheel basically. And this is easy because we exactly know what the backend is going to send to us because we wrote the backend ourselves or someone in our team did. What you get if people start keeping their own data is that different apps are going to access different data pods. So this app will need data from different sources, but they are the same source that the other app will work from. So this is more ecosystem thinking than the other side. So we need to start agreeing on things. We need to make things work together, like see the bigger picture. And indeed, if you look at the current approach of building APIs, well, that doesn't really work well with decentralization because what you see is the clients will have a big chunk of logic and all that logic will be very specific for an application, will be very specific for a certain backend. So all of the requests in there make a lot of assumptions on how things work, how the backend works, and so on and so forth. And this is not sustainable because first of all, with Solet, with this way of thinking, there will be multiple servers. So this privilege connection you don't have. And also, who says that those servers will behave exactly as you expect? So this way of building what we currently do is not possible. We have to transition into something else. I think this is what it will look like. So basically, the application-specific logic will become quite a bit smaller. And in this logic, we will not start doing HTTP requests directly because we don't know where to send those requests and we don't know what those requests should look like. So what I think is that we'll see clients that have a query engine inside of them. Inside your application logic, you only write queries. So you don't tell where they should be found. You just tell what it is that you want to see. It's up to this library to then translate this into concrete HTTP requests, but you don't have to care about this. And this also means that the ecosystem is at liberty to change interfaces, to have caching and so on. A lot of details that the application developer shouldn't really have to care about. Of course, this means that we'll need quite a complex query library to deal with this. But the good thing is that this library will be reused across multiple clients, so we only have to write it once, basically. Now, since there will be lots of data on different places, interoperability is going to be crucial. And in fact, you'll notice that there's quite a lot of initiatives that look a bit like solid, and that's true. SID by itself is not extremely new, it's actually just a very logical way of doing things. In fact, the way that we're currently approaching apps is the crazy way of doing things. Like, who said that in order to use an app, we have to push our data there? There's quite some initiatives with the same goal, like keep your data, reuse apps. However, from what I see is that solid is the only one actually strongly focusing on interoperability. I see many others focusing on identity, security, blockchain, even, all of those things are happening. But to us, the real problem is interoperability. How are we going to ensure that each app works with each data pod that you can find online? So here are some challenges that we have to counter. Because if we need, if we all store our own data wherever we want, how can we connect it to other people's data? And how can apps share data without having to agree on everything first? Like, do apps need to know exactly how to model a person, a contact, a photo, a like, a comment, or is it possible that we are thinking differently about that? And finally, how do we integrate data from multiple data pods? Because at every point in time, applications will need to start harvesting data from different places. Well, those challenges in SOLID we solve them through linked data and the RDF form. So let me explain how that works. Linked data is nothing special. It actually uses the cornerstones of the web, which are URLs and links. For instance, this piece of data, which looks a lot like JSON, is me liking this edition of FOSDEM. But how did I do that? Because if you go to this home page, you'll see that there's no like button, but I still liked it anyway. Now, the good thing is, this is my piece of data. So I created it. I store it in my personal data space. But how can I still like something else? Well, I simply link to it. So this is URL for me. This is URL for FOSDEM. And this is me saying, hey, I like this thing out there on the web. And this is a real like. Like, I created it. It's as good as anything else, except I'm in control and I can store it wherever I want. So this is how we connect information from different places on the web together. And even though they're stored in different places, we can still talk about them. The other thing is about interoperability. And there's a lot of things to be said about it. But what we're focusing on nowadays is recognizing ships. And if you have an application that wants to work with social feeds, well, all you have to do is recognize this particular ship. It's a like given by a certain person for a certain object at a certain time. That's all there is to it. And what we are doing with this is layered compatibility. Because this like could, for instance, have much more attributes or could have comments attached to it and so on. Or could maybe even have a picture attached to it. It doesn't matter. Your app only has to recognize one specific ship. So this means that if you are building applications for a solid, you don't have to know. You know everything in a solid ecosystem. If you only care about likes, you don't have to know about pictures. You don't have to know about calendars. You don't have to know about anything you don't want to know about. So solid is not one big specification of how everything should look like. It is small specifications that you can mix and match in whatever way you want. So if you just want to do likes, well, recognizing this shape is sufficient. Final question, if data comes from many different places, how do you combine it? Well, that's a nice thing, you can just concatenate data from different sources. So this is my like. This is not a person's like. They're stored in different places, but they are interoperable because we're all using your rice and we're using the same ships. So these things show why link data is a good way of approaching a decentralized environment of different data stores. Which brings me to the final point is, as developers, how will we build apps on top of that? And what we've realized is that the developer experience is going to be the most crucial factor to have success for solid but in fact for anything. And what we've also learned is that we should really pay attention to front-end developers because they're the ones building the apps that people see. And together with UX designers, they bring solid to people. So as a solid community, we shouldn't, in my opinion, try to focus too much and to end up saying, well, we'll build the back-ends, we'll build the specs, we'll build the applications. I don't think that's really our job because frankly, I'm more on the back-end myself. I don't know what the user wants. So the idea is that we want to enable developers to build things on top of solid instead of doing it ourselves. But of course, by enabling developers to build nice things, we also enable ourselves. So that's a very strong argument for investing in developer experience because this is the way that we can make an ecosystem spread. If we give developers the seats to start building themselves, it will be so much faster and better if we just give them applications as an example and then say, well, if you want to build something, just build something. Now, making sure that they have a great experience while building decentralized apps is very important. That said, building decentralized apps is a bit more complex than centralized apps because you don't control the back-end, you don't control the data model. So we need to think about a very good experience there. For me, I think it's very important to make sure that the simple things are simple but that the complex things are manageable because honestly, link data has a reputation for being complex. But there's a very nice quote, I think, that hits to the core of this. People think RDF is a pain because it is complicated. However, the truth is much worse. RDF is painfully simplistic but it allows you to work with real-world data and problems that are horribly complicated. So indeed, decentralized environments are complex. Data is everywhere, different shapes, different formats. It's much easier to be in a centralized space. So we should remind ourselves that, yes, we're tackling a complex problem. However, if we succeed in making the simple things simple, then we're quite good. Now the link data developer experience that I've seen over the past couple of years was following the way of JSON APIs. And what is that way? Well, simple. You gather some input from the user, then you send a specific API call to your back-end, you parse the JSON response, you traverse the JSON tree structure, and then finally you obey the DOM. This is very classical old-school JSON. And if we make that the RDF equivalent, well, we gather data into a query, we send the query to the server, we get RDF back, we parse it, we traverse the graph, and then we obey the DOM. However, this is horribly complicated, and this is not what the cool kids are doing nowadays. And what are the cool kids doing? Well, they're doing things like React, Vue.js, Angular, and so on. So if you want any chance of succeeding, we of course have to be there. We have to think of what the link data experience would look like in these frameworks. And here's an example of what link data looks like in React. For instance, I can say, welcome, dear user, and give their first name. I can show their profile picture by just adding the simple components. I can give them a link to their inbox, to their homepage. I can give them a list of their friends. So this whole five-step process, forget about it. Just declaratively say what it is that you want, display it to the user, and that's it. Now, you might notice those tiny expressions in there. I call them microquery expressions, and they're very crucial to make things happen. There's quite some magic behind them, because they look very simple. They look like just JSON objects, but actually every one of those expressions, every single one is going to the web to get data. So how does it work? Well, it's a language called LDFlex. And LDFlex tries to expose link data without the complexities of RDF, and RDF is the underlying model of link data. So we can say things like, give me the user's name, give me the user's friends, give me the first name of the user's friends, give me the first name of the friends of the user, and go to a random thing out of the web and find their blog. So these are just data expressions for getting things online. So at this point, you could say, like, who, you just invented yet another query language. Congrats, why couldn't you reuse? Well, actually, it's not just a query language. LDFlex is a domain-specific language for JavaScript. This means that every expression is actually just a JavaScript expression. So data.user.friend.firstname is plain JavaScript. And now here's the trick. It feels like a local object. It feels like traversing a JSON graph in memory. However, underneath, it uses proxy, which can do basically magic to any property. So what's actually happening is that this expression will behave like a web query. If you put a weight keyword in front of it, what will happen is that the LDFlex software will go on the web, will go find a list of your friends from your data pods, will then go to your friends' data pods and get their names. So a very simple forward expression like this one actually hides a query on the web. And this is how we can make the simple things really simple. And I think that small inventors like this one are crucial to provide a nice developer experience to SOLID. So we've talked about universality and innovation, why it is so important that we go back to the core values of the web. We've talked about a new way to think about apps, data, and people. We want to build apps in such a way that the data is controlled by the people, not by the app. Now we talked about decentralized development, how it's significantly more complex, but it can be managed with the right developer experience. So given all of this, what would I expect the future to look like? He built it and that became the future. However, Tim himself actually prefers this slight alteration of the quote. The best way to invent the future is to predict it. Think about it for a second. We can say what we want the future to look like. And I want the future to look like this. I don't want apps to own our data. I want to re-control our own data that we can choose apps that we want. This is what we with SOLID want the world to look like. This is what we predict. And the next step is to invent those things that we feel are necessary to make it happen. So they include standards, they include software implementations, they also include developer experience so all of you can help us invent that future. But truly thought, I don't think that our main problems are technology. In fact, there's many more to tackle. SOLID will need a very diverse community in order to be successful. And I say diversity, I'm talking in the first place about different people coming from different places, with different backgrounds, with different views on a problem. That's important. I'm also talking about the very specific skill set and a very diverse skill set. As Timmer is Lisa himself, we should assemble the brightest minds from business, technology, government, civil society, the arts, and academia to tackle the threats to the web's future. Because this is not just something only for developers, even though we play an important part in that. I think if he succeeds, this is something that's going to be very important to everyone. Thank you.
 2019 marks the 30th birthday of the World Wide Web.  In those 30 years, the world has changed a lot, not in the least because of the web.  The web has changed the way in which we communicate, in which we find information about things,  in which we learn things, also the way in which businesses done all over the globe.  And to me, the most important thing of the web is that it is something for everyone.  When Tim Berners-Lee created the web, his idea was that it should work for anyone regardless  of where you come from, where you're now, where you're going.  This independence of anything was the most important thing.  It was about connecting people, about sharing information.  And fortunately, as you know, the web is under threat these days from different angles.  One of the most important problems is that we have lost control of our personal data  in our online and offline lives.  And actually, this is something that worries me.  I guess a lot of you as well.  Maybe that's why you're here.  It also worries Tim Berners-Lee himself, because this is not why he created the web.  Fortunately, there is a plan, an idea of how to solve things.  And that plan is a project, a mission called SOLID.  So I'm here to talk about SOLID today.  And with SOLID, we aim to reshape the relationship that people have with their data and the applications  that they use.  And fundamentally, SOLID is about choice.  We want to get back to that web where we can choose whatever we want to do independently  of the large platforms that are there.  So today, let's talk about universality and innovation, main drivers behind the original  vision of the web.  And then have a look at the web of the future, what a new relation between apps, data, and  people should look like.  And finally, let's of course also talk about development, how will the developer experience  change if we make all of these things happen?  First of all, of course, let's talk about the web, let's talk about the role of centralization  in the history of the web, and let's talk about a main problem that we have today, which  are of course the walled gardens.  So 30 years is a long time, maybe too long for many of us to remember the world before  the web.  But what happened before the web was it was very hard to exchange information because  there was high heterogeneity around the world.  And there was different hardware that people use, different software was very hard to communicate.  It was also very hard to innovate because if you wanted to build software for which machines  would you build, for which platforms would you build, right?  Those were hard questions these days.  So the main thing that the web changed was universality.  The web strived to be universal because it was independent of many things.  And anyone in this room and everywhere else can use the web regardless of the hardware  you're using.  You can use it from a laptop, from a mobile device.  You can also use it with whatever operating system you want, with whatever browser, the  choice is yours.  And this was a real revolution that the web has brought.  This is very great for innovation because instead of wondering which system to pick,  you just build for the web and it works everywhere.  At least that's a philosophy.  And how this works is through standards that provide the needed interoperability.  The web, because of these things, brings freedom of expression to everyone across the world.  And the principle there is that anyone can say anything about anything.  And it has given a voice to many people who didn't have such a voice before.  And the good thing is we all have our own spaces on the web.  Everyone can create a website, you can say it's your opinion and I don't have to agree  with it, you're free to do so and no one controls that.  And if you want to discuss the opinion of someone else, well, we can link to them.  We don't have to copy them, we can just point to it even though we might agree or disagree  with them.  The other side of freedom of expression is that of course people started doing that.  They started exercising their rights.  They started writing their own blogs and websites, sharing things from wherever they wanted to  share them.  So that was a very good time of birth creativity.  And unfortunately that time seems to be a bit behind us given what's currently happening,  but I'll talk more about that in a bit.  Why I have seen because of that revolution is lots of social platforms, if you still  remember, what is it, 15 years ago, things like delicious, for sharing bookmarks, flicker,  for sharing pictures and so on.  So there were platforms that were enabling the independence that people had and they  were enabling them in sharing content because they made it so much easier.  The other side of it is that the web also made innovation easy because anyone can build  anything for any reason.  It's like the developers equivalent of freedom of speech.  And this is called permissionless innovation because you can develop whatever you want.  You don't depend on hardware, software, you just build for the web.  So you don't need anyone's permission to join the web and launch a new idea.  And if you say, well, of course, think again because in app stores that's not the case.  You depend on a centralized party to have your app approved.  So the web is completely different in that regard.  Permissionless innovation has been responsible for crazy ideas, things that 15, 20 years  ago seemed like pure sense fiction, but nowadays are pretty normal.  I took an Uber to get here.  Of course I did.  What else would I have done?  And this shows the power of universality and permissionless innovation.  Now of course this has some assumptions about whether or not there are central parties.  So let's talk about history of centralization and decentralization.  When the web started, decentralization was actually the default assumption.  Many things were decentralized back then, the internet, email, and so on.  So that's not new about the web.  What was new about the web is universality, the fact that the decentralization system  would work with many platforms.  And the first threat to this universality started with a browser war.  If you still remember around, well, the end of the 90s, the 2000s, if you didn't have  internet explorer, well, you're out of luck and that's the one browser you need.  But this means that you were obliged to start buying certain kind of computers that would  be capable of running this software otherwise you would be excluded from the web.  And this also means as a developer you depended on Microsoft for your speed of innovation.  So even things like obliging people to use a certain browser can have a very big impact  on the ecosystem.  So this universality is important.  So how did the browser wars end?  Well, they never really ended.  They just got replaced by another war because at some point it didn't matter anymore which  browser you were using.  What mattered was the first page that you used to get on the web.  And that means that, well, if you're not on Google as a company, you're out of luck.  So this means that we see that ranking in search engine is certainly a target, not great  content.  And this again provides a danger.  It also means that if you as a developer want to innovate, well, you better make sure  that whatever you do ranks highly on Google if not there's no point.  So again, that's another way of how innovation is impacted by centralization.  And how did this war end?  Well, it didn't really.  It just got replaced by yet another battle.  And these are of course the platform wars that are still ongoing today.  You're not on Facebook while you're out of luck.  There's a couple of things you cannot use because you only have the sign in with Facebook  button.  And what we saw is that clicks suddenly became much more important than having high quality  content.  So this has totally shaped the way that we use the web.  And for developers, it means that, well, you either compete with Facebook if you also  try to harvest lots of data, or you depend on Facebook because you need people to log  in with Facebook on your website, otherwise they will not join.  So this coples your innovation to their innovation.  And this is not great for universality, privacy, or innovation.  So let's do a bit on this last topic of the walled gardens that are created by such social  media.  And by the way, I don't seem to pick on any platform in particular.  I'm here to sketch what's happening to the web with a couple of examples.  So what happened today is that our data has become centralized and only a handful of platforms  on the web.  What used to be on people's personal blogs a couple of years ago is now on Facebook,  is now on Twitter.  And of course, those platforms, they must be credited for providing a great user experience,  but at the same time, we have lost control of all the data that we put on them.  This has far reaching consequences for privacy.  I don't have to tell you that.  In fact, you've been told it so many times that you probably don't really care too much  anymore.  However, it also endangers the web's universality.  And this is bad for all developers who want to build things on the web.  The sign-in buttons are a threat to the web, but what's also a threat to the web is the  apps.  Like, hey, it works better with a native app.  But this is madness if you think about it.  I mean, the great thing about the web was that finally we could use one piece of software  to browse all information of the world.  Now that we have had this for 30 years, what do we do?  We start using specific apps again to browse information.  So this is kind of a big step backwards if you think about it.  This creates the wild gardens because what those social networks and other networks on  the web do is they harvest data.  Their main business model is getting as much data as possible.  And this creates a situation where, for instance, I cannot share a photo on Facebook with my  colleagues on LinkedIn.  I have to either move the data or move the people.  And this creates those gardens where you have to really climb across them in order to be  able to share content.  This is not the web.  The web could just link to things and there were no barriers before.  Of course, the main problem here is that this massive centralization, it hurts diversity  in the web.  It hurts innovation.  It also hurts the choice that people have.  And let's be honest, if you have a budget on time to build one API integration, will  you choose Facebook.com or will you choose a very specific provider with lots of privacy?  I mean, there's a market reality.  We have to follow what is happening, obviously.  So this means that developers start depending on such centralized platforms for data and  identity.  And if you don't want to depend on them, well, you have to become one of them, basically.  If you can't beat them, join them.  That's a sad reality.  So people lose control of their data and it's very hard to switch to other apps because  if you switch to another app, well, too bad because your data is left behind.  So this means that even if you have great ideas for innovation, people are locked in.  So you cannot convince them as easily to move around.  And this brings us back to the irony of permissionless innovation because you can ask, like, hey,  how did this happen?  Didn't we have this great idea that we could build whatever we want?  Well, unfortunately, permissionless innovation is so permissive that it even allows platforms  that go against this idea.  And I think it was very beautifully phrased in the Guardian where they said that the Facebook  founder has no intention of allowing anyone to build anything of his platform that does  not have his express approval.  And profited mightily from the web's openness, he has kicked away the letter that elevated  him to his current eminence.  I think it's really, really beautiful metaphor because if you see the web as a native platform,  you see all those letters that people are getting because of the web, and then you build  a platform, climb on top, and you just kick it away because it's not needed anymore.  And that's kind of what happened, unfortunately.  However, let's not keep on talking too much about the past and all the problems.  They're there.  Let's not keep on talking about them.  Let's have a look at a different way to do things that might prevent what's happening  today.  So I'll talk about Solat, and the most important thing there is choice.  We want to give people back the choice that has always been theirs on the web.  So the Solat ecosystem enables people to pick the applications, the websites, and so on  that they want to use, while at the same time giving them the opportunity to store their  data wherever they want, and that's the new thing.  So this means that people can control their data, and they can share it with the apps  and the people that they choose.  How does this work concretely?  Well, this is a view that we're all very familiar with today.  It's a social media post, and how this would work today is that all of the pieces of data  that built this view, they're stored in a single centralized space.  What we're saying here is that you will get the choice to store your data wherever you  want.  So concretely, if this is my social media post, well, this profile picture there is mine.  So I store it in my data space in my data pod.  My name, of course, mine is also stored there.  The text itself is also stored in my data space.  If you place a comment on my message, well, this comment is yours.  Your data space, the picture is yours, your data space.  If someone else replies to your comments, well, it goes in their data space.  I think you get the picture.  Even a piece of data, as small as a like, if you say, I like this, well, this like is  yours and it can be stored on your data space.  So you can choose for whatever piece of data you create where it is stored.  And this creates a very different world.  So first, I briefly look at what we have today.  In essence, the problem that we have is that data and applications are coupled together.  So when we say Facebook, when we say LinkedIn, we mean my Facebook and my LinkedIn because  it's the data that they have about me in an application.  This has a couple of problems.  As I said before, it's very hard to share data across things.  Another terrible problem is synchronization.  If, for instance, I indicate on Facebook I'm going to this event, well, then Doodle won't  know about it or Mike Heller won't know about it.  So because data is closely tied to the application, so you have this constant synchronization  problem and you can share across boundaries.  So that's what happens with data silos.  But what if we push the data out of those silos?  The applications on this side don't contain any data because the data is in people's personal  data pots.  And this completely changes the picture because I can pick any application.  I can, for instance, start with a social feed.  I can post a picture and the picture is stored in my personal pot.  And then when I open a photo gallery application, well, I can view the same picture.  So there's no need to synchronize because data never leaves my space.  There's only one copy of it, really.  And this switching between apps is really important.  Now, this is great for privacy, obviously, because I can control what apps get to see  my data.  It sounds so very great for a choice because now I can pick any app I want.  If I don't like an app, I can move, if I don't like my data provider, I can move.  So that's a story for people.  There's also a very intriguing story for developers.  Because this is what you have today.  We have a single market for centralized apps where the competition is based on data ownership.  Here on this side, whoever has most data will win.  It doesn't matter how good you are, just get the most data you can.  And this is really bad because if someone has a creative idea, they have trouble entering  the market.  Suppose you invent something really simple.  It's called a slider of disagreement.  It's a feature that we all want.  We want to indicate on the social feeds to see more or less content we disagree with,  right?  Filter bubbles and stuff.  It's a feature everyone wants if you build it while tough luck.  You will never get an option because you cannot enter the market since you don't have the  data.  This is what happens when you have a competition based on data ownership.  Very bad for innovation.  Indeed, if you think about it, can you name me any feature that Facebook or Twitter or  LinkedIn have built in the past five years that really have drastically changed your  life?  You probably can't.  They don't have to innovate to have the data already.  If you want to innovate too bad, you don't have the data.  This changes when we move data out of apps and to your people.  Because then you get a separate competition between data storage and applications.  This is not a competition where the winner takes everything.  This is a competition where multiple things can coexist.  Here I can pick my app independently of my storage provider.  The app that I like might be different from the app that you like.  You pick whatever you like, I pick what I like, and it still works.  Also storage-wise, we might have choices.  I might want to store my data in the cloud.  You might want to store it in your basement on your own server.  All of those things become possible.  This will also change the way we think about markets.  Because right now you cannot choose.  You cannot go to Facebook and say, hey, I will pay you 10 bucks a month if you don't  mind my data.  Well, you cannot do that.  Here I expect there will be lots of choice.  Just to give you an example of how interesting it will be, I expect that there will be free  providers of data storage, but there will probably be minor data that will be the terms  and conditions.  I expect there will be paying solutions, and they will not mind my data.  I even expect there will be solutions that will pay me to put my data there, but then,  of course, they will definitely mind my data.  This just shows how much choice there can be, such an ecosystem with two markets, and  the kind of innovations that you can have there.  This is a theory on how it works on a higher level.  Let's have a concrete look at what is there in a solid ecosystem.  Solid is a project started by Tim Berners-Lee, and it's much bigger than that.  It's in fact the whole community of people working on these things and sharing these  values.  There's not a company, an organization, it's not just software either.  It's an ecosystem, it's a movement, it's a community.  An ecosystem in the sense that solid, one of the main tasks we have, is defining standards  for interoperability.  We try to define as few standards as we can.  What we mostly do is reusing existing web standards, existing W3C standards to enable  these kind of things.  It's not a new web, it's the existing web with a couple of existing standards that  we bring together.  Solid is also a movement in the sense that we want to shift the way that apps are being  built.  Nowadays, as a developer, you depend on data to succeed.  If people join your application, you need to first ask them lots of questions to get  the data, and one of your biggest tasks is collecting data.  What if it weren't?  What if you build apps in such a way that you don't keep the data, that you access people's  data that they provide to you?  They can skip all those data harvesting tasks and focus on what you're really good at.  Finally, solid is also a community, so there's different people in there, there's different  companies, organizations trying to make solid into something great.  Because solid is based on standards, anyone can build or host software for solid.  This means that you can have a server at home or possibly also a server at your workplace.  There's open source software for that, so nothing stops you from doing that.  You can run servers, you can use one of the three community servers, all of those things  are possible.  A lot of choice there.  The solid server, what is it exactly?  It acts as a data plot, personal storage of any kind of data, it stores it and it will  guard your data.  In fact, a solid server is just a regular web server with support for access control  and support for link data.  I will explain link data in just a minute.  The solid server is completely application agnostic, so you can build any kind of application  with it, you're not restricted to specific domains.  All the application specific logic resides inside of the client applications.  In a way, a solid server is just like your website.  This is not a new or revolutionary, it's just like the old days where you would start your  own website, except it's not composed of web pages, it's composed of elementary pieces  of data.  That's the only difference, but conceptually it's like just getting your own website.  What kind of data is inside of a solid plot?  Anything you can imagine.  It's your personal data store, whatever you want to store there.  I'm thinking specifically of profile data, pictures, comments, likes, anything you do  online or offline, you can store there.  It's your space, it's safe, so put there whatever you want.  What are clients then?  Well, solid clients are browser apps or perhaps native apps that read from your pod or write  data to your pod.  So what can we have?  Well, the idea is that you give apps specific permission.  So you say, look, this app is, for instance, photo apps, you can only see my photos, don't  touch any of my other personal data.  Friends can give you permission to access things.  So if one of my friends says, well, hey, these are pictures I want you to see, then I can  use any of my apps to have a look at their pics.  And what those apps do is they deliver a unified experience.  So you can browse your friends' pictures along with yours.  Like, if they use totally different applications to create pictures, it doesn't matter.  You use your apps and you have a seamless experience of everything in your network.  If you think about it, this is kind of how computers in general work.  Like, you know, people make files, they send them around, and then I use whatever program  I have to open those files.  Well, it's very similar, except it's for the web.  So what kind of apps can we build?  Well, this is where your creativity comes in.  Everything you can envision, you can build with SOLID, just like you can build anything  for the web.  Permissionless innovation, right?  So calendars, social feeds, photo sharing apps, perhaps even assistance to organize conferences  like this one, all of those things are possible.  You name it, if you can build it, well, you can build it with SOLID.  So that's about the ecosystem.  Let's also talk about the community of people making things happen and what is the current  state of all of these things.  Well, so the SOLID server is there, there's several apps, and I would say at the moment,  don't let the general public look at it.  It's very relevant to the edges, but as a developer, you can already go there and start  building things.  So there's a SOLID server, and you can store your data online for free.  We've got a couple of places such as those two where you can store your data, but if  you don't want to, you can just start your own.  It doesn't really matter.  For instance, I have my own server, application-wise, we have a data browser, we have contacts  apps, photos apps, and so on.  So all of the things you would expect.  Now, the difference is that these apps don't work with one single backend.  They work with the whole web.  So for instance, a contacts application doesn't just read your address book, it can read all  of the contacts that you have access to.  And of course, we also have a couple of software libraries that make it easy for developers  to build on top of SOLIDs, and for instance, authentication is there, data processing,  so all the low-level stuff you need to get started.  Now SOLID is currently transitioning.  It used to be a research project under MIT Wings.  Now it's becoming much bigger, and there's also a startup within the ecosystem that tries  to kickstart it.  So it started growing at MIT as a research prototype, but through this, and I'm a researcher  myself.  In research, once you prove it works, you have to move on.  So there's no time for building things like a user experience, production grade software,  and so on.  So this is why it's a good idea that it's taken to the next level.  And one of those startups is called Interrupt, and it's a startup that Tim Berners-Lee himself  is backing.  And the idea of Interrupt is to accelerate development.  So we want to open up the ecosystem for all.  We want to maintain a couple of common building blocks as open source.  We want to create tooling for developers, and we want to offer services and apps.  Now it's very important to understand that these things are different, because I've  heard some people being very concerned about this.  Oh wait, so you have this ecosystem, and now there's a startup, and you're going to take  our data again, or no, this is not how it works.  We just have to be very pragmatic.  If we want an ecosystem such as this one taking off, we have to show that there's business  in there.  We have to do that.  And I own an academic myself.  I don't care too much about business.  But if you don't do that, it doesn't work.  You need a couple of companies to drive the ecosystem, to make sure that commercial things  are being built as well.  And I think that by showing, yes, there is economic value in such a way of thinking as  well, that we can unlock the potential of the whole ecosystem.  And also as I said before, someone has to think about user experience, about maintaining  production, great software, and so on.  And so interrupt is now taking on that role for the ecosystem.  However, very importantly, interrupt as the only company with Insolid is never going to  work.  Like we need competition to grow there.  Because remember when I was talking about the two markets, the whole idea is based on  competition.  So if there's only one player, it doesn't really work.  So what interrupt hopes to do is to show, look, this is how you can do nice things with  Insolid.  But the whole goal of this is that there becomes competition to the ecosystem, that there's  different companies with different views trying to build this for everyone.  While it is a time I look like, while a couple of years ago, 2014, was the start of the project  at MIT, then a couple of months ago, we had a launch of interrupts, which give quite some  attention to the Solid ecosystem.  Just last week, we released a developer toolkit and a common UX experience.  So if you want to start building on Solid, it's now a lot easier.  And we hope that in some months, we'll have an MVP of the ecosystem that not just works  for developers, but also works for regular people so we can send anyone there to try  and have fun with it.  And maybe as of today, if you like what I'm talking about, you can also become involved  and this is a new step for the Solid project.  We'll see.  Which brings me to the next part, how does development on top of Solid work?  Well, there's two things we need to talk about on the one hand, the way APIs and clients  work is obviously going to change substantially.  And then we also need to look at, given these change circumstances, how we should start developing  web apps.  So what you have currently is, if you look at what developers do, they're building apps  that are specific to a certain backend.  So if I'm building an app called X, well, I will build them backend and a front end  and they will work together, but X will not work with any other backend and the backend  itself will probably not work with any other application.  So this is how we build things today.  It's all reinventing the wheel basically.  And this is easy because we exactly know what the backend is going to send to us because  we wrote the backend ourselves or someone in our team did.  What you get if people start keeping their own data is that different apps are going  to access different data pods.  So this app will need data from different sources, but they are the same source that  the other app will work from.  So this is more ecosystem thinking than the other side.  So we need to start agreeing on things.  We need to make things work together, like see the bigger picture.  And indeed, if you look at the current approach of building APIs, well, that doesn't really  work well with decentralization because what you see is the clients will have a big chunk  of logic and all that logic will be very specific for an application, will be very specific  for a certain backend.  So all of the requests in there make a lot of assumptions on how things work, how the  backend works, and so on and so forth.  And this is not sustainable because first of all, with Solet, with this way of thinking,  there will be multiple servers.  So this privilege connection you don't have.  And also, who says that those servers will behave exactly as you expect?  So this way of building what we currently do is not possible.  We have to transition into something else.  I think this is what it will look like.  So basically, the application-specific logic will become quite a bit smaller.  And in this logic, we will not start doing HTTP requests directly because we don't know  where to send those requests and we don't know what those requests should look like.  So what I think is that we'll see clients that have a query engine inside of them.  Inside your application logic, you only write queries.  So you don't tell where they should be found.  You just tell what it is that you want to see.  It's up to this library to then translate this into concrete HTTP requests, but you  don't have to care about this.  And this also means that the ecosystem is at liberty to change interfaces, to have caching  and so on.  A lot of details that the application developer shouldn't really have to care about.  Of course, this means that we'll need quite a complex query library to deal with this.  But the good thing is that this library will be reused across multiple clients, so we only  have to write it once, basically.  Now, since there will be lots of data on different places, interoperability is going to be crucial.  And in fact, you'll notice that there's quite a lot of initiatives that look a bit like  solid, and that's true.  SID by itself is not extremely new, it's actually just a very logical way of doing things.  In fact, the way that we're currently approaching apps is the crazy way of doing things.  Like, who said that in order to use an app, we have to push our data there?  There's quite some initiatives with the same goal, like keep your data, reuse apps.  However, from what I see is that solid is the only one actually strongly focusing on interoperability.  I see many others focusing on identity, security, blockchain, even, all of those things are  happening.  But to us, the real problem is interoperability.  How are we going to ensure that each app works with each data pod that you can find online?  So here are some challenges that we have to counter.  Because if we need, if we all store our own data wherever we want, how can we connect it  to other people's data?  And how can apps share data without having to agree on everything first?  Like, do apps need to know exactly how to model a person, a contact, a photo, a like,  a comment, or is it possible that we are thinking differently about that?  And finally, how do we integrate data from multiple data pods?  Because at every point in time, applications will need to start harvesting data from different  places.  Well, those challenges in SOLID we solve them through linked data and the RDF form.  So let me explain how that works.  Linked data is nothing special.  It actually uses the cornerstones of the web, which are URLs and links.  For instance, this piece of data, which looks a lot like JSON, is me liking this edition  of FOSDEM.  But how did I do that?  Because if you go to this home page, you'll see that there's no like button, but I still  liked it anyway.  Now, the good thing is, this is my piece of data.  So I created it.  I store it in my personal data space.  But how can I still like something else?  Well, I simply link to it.  So this is URL for me.  This is URL for FOSDEM.  And this is me saying, hey, I like this thing out there on the web.  And this is a real like.  Like, I created it.  It's as good as anything else, except I'm in control and I can store it wherever I want.  So this is how we connect information from different places on the web together.  And even though they're stored in different places, we can still talk about them.  The other thing is about interoperability.  And there's a lot of things to be said about it.  But what we're focusing on nowadays is recognizing ships.  And if you have an application that wants to work with social feeds, well, all you have  to do is recognize this particular ship.  It's a like given by a certain person for a certain object at a certain time.  That's all there is to it.  And what we are doing with this is layered compatibility.  Because this like could, for instance, have much more attributes or could have comments  attached to it and so on.  Or could maybe even have a picture attached to it.  It doesn't matter.  Your app only has to recognize one specific ship.  So this means that if you are building applications for a solid, you don't have to know.  You know everything in a solid ecosystem.  If you only care about likes, you don't have to know about pictures.  You don't have to know about calendars.  You don't have to know about anything you don't want to know about.  So solid is not one big specification of how everything should look like.  It is small specifications that you can mix and match in whatever way you want.  So if you just want to do likes, well, recognizing this shape is sufficient.  Final question, if data comes from many different places, how do you combine it?  Well, that's a nice thing, you can just concatenate data from different sources.  So this is my like.  This is not a person's like.  They're stored in different places, but they are interoperable because we're all using  your rice and we're using the same ships.  So these things show why link data is a good way of approaching a decentralized environment  of different data stores.  Which brings me to the final point is, as developers, how will we build apps on top  of that?  And what we've realized is that the developer experience is going to be the most crucial  factor to have success for solid but in fact for anything.  And what we've also learned is that we should really pay attention to front-end developers  because they're the ones building the apps that people see.  And together with UX designers, they bring solid to people.  So as a solid community, we shouldn't, in my opinion, try to focus too much and to end  up saying, well, we'll build the back-ends, we'll build the specs, we'll build the applications.  I don't think that's really our job because frankly, I'm more on the back-end myself.  I don't know what the user wants.  So the idea is that we want to enable developers to build things on top of solid instead of  doing it ourselves.  But of course, by enabling developers to build nice things, we also enable ourselves.  So that's a very strong argument for investing in developer experience because this is the  way that we can make an ecosystem spread.  If we give developers the seats to start building themselves, it will be so much faster and  better if we just give them applications as an example and then say, well, if you want  to build something, just build something.  Now, making sure that they have a great experience while building decentralized apps is very important.  That said, building decentralized apps is a bit more complex than centralized apps because  you don't control the back-end, you don't control the data model.  So we need to think about a very good experience there.  For me, I think it's very important to make sure that the simple things are simple but  that the complex things are manageable because honestly, link data has a reputation for being  complex.  But there's a very nice quote, I think, that hits to the core of this.  People think RDF is a pain because it is complicated.  However, the truth is much worse.  RDF is painfully simplistic but it allows you to work with real-world data and problems  that are horribly complicated.  So indeed, decentralized environments are complex.  Data is everywhere, different shapes, different formats.  It's much easier to be in a centralized space.  So we should remind ourselves that, yes, we're tackling a complex problem.  However, if we succeed in making the simple things simple, then we're quite good.  Now the link data developer experience that I've seen over the past couple of years was  following the way of JSON APIs.  And what is that way?  Well, simple.  You gather some input from the user, then you send a specific API call to your back-end,  you parse the JSON response, you traverse the JSON tree structure, and then finally  you obey the DOM.  This is very classical old-school JSON.  And if we make that the RDF equivalent, well, we gather data into a query, we send the query  to the server, we get RDF back, we parse it, we traverse the graph, and then we obey the  DOM.  However, this is horribly complicated, and this is not what the cool kids are doing nowadays.  And what are the cool kids doing?  Well, they're doing things like React, Vue.js, Angular, and so on.  So if you want any chance of succeeding, we of course have to be there.  We have to think of what the link data experience would look like in these frameworks.  And here's an example of what link data looks like in React.  For instance, I can say, welcome, dear user, and give their first name.  I can show their profile picture by just adding the simple components.  I can give them a link to their inbox, to their homepage.  I can give them a list of their friends.  So this whole five-step process, forget about it.  Just declaratively say what it is that you want, display it to the user, and that's it.  Now, you might notice those tiny expressions in there.  I call them microquery expressions, and they're very crucial to make things happen.  There's quite some magic behind them, because they look very simple.  They look like just JSON objects, but actually every one of those expressions, every single  one is going to the web to get data.  So how does it work?  Well, it's a language called LDFlex.  And LDFlex tries to expose link data without the complexities of RDF, and RDF is the underlying  model of link data.  So we can say things like, give me the user's name, give me the user's friends, give me  the first name of the user's friends, give me the first name of the friends of the user,  and go to a random thing out of the web and find their blog.  So these are just data expressions for getting things online.  So at this point, you could say, like, who, you just invented yet another query language.  Congrats, why couldn't you reuse?  Well, actually, it's not just a query language.  LDFlex is a domain-specific language for JavaScript.  This means that every expression is actually just a JavaScript expression.  So data.user.friend.firstname is plain JavaScript.  And now here's the trick.  It feels like a local object.  It feels like traversing a JSON graph in memory.  However, underneath, it uses proxy, which can do basically magic to any property.  So what's actually happening is that this expression will behave like a web query.  If you put a weight keyword in front of it, what will happen is that the LDFlex software  will go on the web, will go find a list of your friends from your data pods, will then  go to your friends' data pods and get their names.  So a very simple forward expression like this one actually hides a query on the web.  And this is how we can make the simple things really simple.  And I think that small inventors like this one are crucial to provide a nice developer  experience to SOLID.  So we've talked about universality and innovation, why it is so important that we go back to  the core values of the web.  We've talked about a new way to think about apps, data, and people.  We want to build apps in such a way that the data is controlled by the people, not by the  app.  Now we talked about decentralized development, how it's significantly more complex, but  it can be managed with the right developer experience.  So given all of this, what would I expect the future to look like?  He built it and that became the future.  However, Tim himself actually prefers this slight alteration of the quote.  The best way to invent the future is to predict it.  Think about it for a second.  We can say what we want the future to look like.  And I want the future to look like this.  I don't want apps to own our data.  I want to re-control our own data that we can choose apps that we want.  This is what we with SOLID want the world to look like.  This is what we predict.  And the next step is to invent those things that we feel are necessary to make it happen.  So they include standards, they include software implementations, they also include developer  experience so all of you can help us invent that future.  But truly thought, I don't think that our main problems are technology.  In fact, there's many more to tackle.  SOLID will need a very diverse community in order to be successful.  And I say diversity, I'm talking in the first place about different people coming from different  places, with different backgrounds, with different views on a problem.  That's important.  I'm also talking about the very specific skill set and a very diverse skill set.  As Timmer is Lisa himself, we should assemble the brightest minds from business, technology,  government, civil society, the arts, and academia to tackle the threats to the web's future.  Because this is not just something only for developers, even though we play an important  part in that.  I think if he succeeds, this is something that's going to be very important to everyone.  Thank you.
Solid__taking_back_the_Web_through_decentralization_App_development_0_155.png Solid__taking_back_the_Web_through_decentralization_App_development_156_215.png Solid__taking_back_the_Web_through_decentralization_App_development_216_1427.png Solid__taking_back_the_Web_through_decentralization_App_development_1428_2795.png Solid__taking_back_the_Web_through_decentralization_App_development_2796_2951.png Solid__taking_back_the_Web_through_decentralization_App_development_2952_2999.png Solid__taking_back_the_Web_through_decentralization_App_development_3000_3467.png Solid__taking_back_the_Web_through_decentralization_App_development_3468_5663.png Solid__taking_back_the_Web_through_decentralization_App_development_5664_6539.png Solid__taking_back_the_Web_through_decentralization_App_development_6540_7031.png Solid__taking_back_the_Web_through_decentralization_App_development_7032_8603.png Solid__taking_back_the_Web_through_decentralization_App_development_8604_9083.png Solid__taking_back_the_Web_through_decentralization_App_development_9084_9323.png Solid__taking_back_the_Web_through_decentralization_App_development_9324_11999.png Solid__taking_back_the_Web_through_decentralization_App_development_12000_12107.png Solid__taking_back_the_Web_through_decentralization_App_development_12108_12983.png Solid__taking_back_the_Web_through_decentralization_App_development_12984_13391.png Solid__taking_back_the_Web_through_decentralization_App_development_13392_13439.png Solid__taking_back_the_Web_through_decentralization_App_development_13440_13559.png Solid__taking_back_the_Web_through_decentralization_App_development_13560_15935.png Solid__taking_back_the_Web_through_decentralization_App_development_15936_16139.png Solid__taking_back_the_Web_through_decentralization_App_development_16140_17243.png Solid__taking_back_the_Web_through_decentralization_App_development_17244_18587.png Solid__taking_back_the_Web_through_decentralization_App_development_18588_18911.png Solid__taking_back_the_Web_through_decentralization_App_development_18912_19727.png Solid__taking_back_the_Web_through_decentralization_App_development_19728_21263.png Solid__taking_back_the_Web_through_decentralization_App_development_21264_23831.png Solid__taking_back_the_Web_through_decentralization_App_development_23832_27647.png Solid__taking_back_the_Web_through_decentralization_App_development_27648_27851.png Solid__taking_back_the_Web_through_decentralization_App_development_27852_29951.png Solid__taking_back_the_Web_through_decentralization_App_development_29952_30131.png Solid__taking_back_the_Web_through_decentralization_App_development_30132_30323.png Solid__taking_back_the_Web_through_decentralization_App_development_30324_30527.png Solid__taking_back_the_Web_through_decentralization_App_development_30528_31811.png Solid__taking_back_the_Web_through_decentralization_App_development_31812_32291.png Solid__taking_back_the_Web_through_decentralization_App_development_32292_32387.png Solid__taking_back_the_Web_through_decentralization_App_development_32388_33947.png Solid__taking_back_the_Web_through_decentralization_App_development_33948_34511.png Solid__taking_back_the_Web_through_decentralization_App_development_34512_34727.png Solid__taking_back_the_Web_through_decentralization_App_development_34728_35087.png Solid__taking_back_the_Web_through_decentralization_App_development_35088_39611.png Solid__taking_back_the_Web_through_decentralization_App_development_39612_39815.png Solid__taking_back_the_Web_through_decentralization_App_development_39816_41255.png Solid__taking_back_the_Web_through_decentralization_App_development_41256_42575.png Solid__taking_back_the_Web_through_decentralization_App_development_42576_45203.png Solid__taking_back_the_Web_through_decentralization_App_development_45204_47699.png Solid__taking_back_the_Web_through_decentralization_App_development_47700_50999.png Solid__taking_back_the_Web_through_decentralization_App_development_51000_51599.png Solid__taking_back_the_Web_through_decentralization_App_development_51600_51791.png Solid__taking_back_the_Web_through_decentralization_App_development_51792_51887.png Solid__taking_back_the_Web_through_decentralization_App_development_51888_51947.png Solid__taking_back_the_Web_through_decentralization_App_development_51948_52019.png Solid__taking_back_the_Web_through_decentralization_App_development_52020_54047.png Solid__taking_back_the_Web_through_decentralization_App_development_54048_55319.png Solid__taking_back_the_Web_through_decentralization_App_development_55320_55571.png Solid__taking_back_the_Web_through_decentralization_App_development_55572_56291.png Solid__taking_back_the_Web_through_decentralization_App_development_56292_56723.png Solid__taking_back_the_Web_through_decentralization_App_development_56724_57947.png Solid__taking_back_the_Web_through_decentralization_App_development_57948_57995.png Solid__taking_back_the_Web_through_decentralization_App_development_57996_58283.png Solid__taking_back_the_Web_through_decentralization_App_development_58284_58883.png Solid__taking_back_the_Web_through_decentralization_App_development_58884_60491.png Solid__taking_back_the_Web_through_decentralization_App_development_60492_61343.png Solid__taking_back_the_Web_through_decentralization_App_development_61344_64055.png Solid__taking_back_the_Web_through_decentralization_App_development_64056_64115.png Solid__taking_back_the_Web_through_decentralization_App_development_64116_64259.png Solid__taking_back_the_Web_through_decentralization_App_development_64260_64379.png