Transcript
dohmen-veltens-solid
00:00:00: Lucas Dohmen: Welcome listeners to a new episode of the CaSE podcast, a new conversation about software engineering. Today we want to talk about Solid and for that I invited Angelo Veltens. Hi, Angelo.
00:00:23: Angelo Veltens: Hi.
00:00:23: Lucas Dohmen: Angelo is an IT consultant at codecentric and he’s a member of the Solid community and currently works with Tim Berners-Lee on SolidOS. So he’s a very good person to ask everything about Solid. If you don’t know anything about Solid, we try to give you a good overview, but before we get into Solid, Solid claims that it tries to give you control back over your data. So do you have an example for us where we don’t have control over our data right now?
00:00:49: Angelo Veltens: Yeah, actually, I have several examples. So if I’m using the web today I often come to, or sooner or later I come to the point where we think okay, this should just work better. I don’t feel in control. Back in the days Apple started with a slogan: There’s an app for that. And it’s true. We go to the App Store and there’s an app for that, there’s actually a multitude of apps for everything we could imagine to do in our daily routine. So I could just say I choose the best app, the app that I like best. And the world could be a happy place, but in reality, this clashes often with the complexity of my life. There’s an app for everything, but there’s not an app for everything. So I am forced to use multiple apps to go through my day. There’s not one app for everything. And that’s fine because we don’t want to have one app for everything. This would bring other problems with us, but to have multiple apps brings the problem that I’m not feeling in control in the end. Because one this is, okay, who do I need to trust? Where do I put my data? So as one thing, one aspect of control, but the other aspect is, okay, this is my data. I want to use it. And if it’s siloed into an app and I want to go, the next step would be to use another app. I have to get the data from one app to the other, and that’s a problem of interoperability, that I can make use of my data in the end. Let’s say shopping lists. Perhaps I have an app for recipes. I want to go shopping. I have to put the ingredients from the recipe into the shopping list, and that could be a problem already. I have to copy/paste it over. And it’s often tedious manual work to copy over from one app to the other. And yeah, what Solid tries to achieve is to give me control over my data and make it interoperable to move data from one app to the next, or even better to not store it and couple it to the app.
00:03:03: Lucas Dohmen: So if I imagine the whole shopping thing today, right? Like I would maybe have an app with recipes and then I have another app that is my shopping list and maybe they have an integration with each other. So I can maybe say push them to my shopping list, but that’s not what you mean, right?
00:03:22: Angelo Veltens: This is a shortsighted solution for that. But the problem starts very soon because from the multitude of apps I talked about earlier, I don’t have that much of a selection now, I have to choose specific apps that have that integration. And both apps have to work officially together. And this often brings me down to one or two apps if I’m lucky. If there’s an app at all, I mostly don’t have that one app that works with exactly the one other app I want to use. So the freedom of choice is limited.
00:03:56: Lucas Dohmen: Yeah, true. And also if I maybe have my recipes from multiple sources, each of them needs to be integrated with my shopping list or maybe online ordering, food ordering system or something like that.
00:04:08: Angelo Veltens: Exactly. And I’m always forced to use a specific app. Even if, let’s say I don’t want to go shopping on my own, perhaps I want to share the shopping lists with my family. So what do we need to do? We have to agree on one single app for that. And we might have different desires and wishes what the app should do and how it should work, but we cannot choose freely. We have to find consensus on that nowadays.
00:04:34: Lucas Dohmen: True. So that maybe even leads to having multiple apps for the same purpose. Most people probably have more than one chat app right now, I would assume. Because to interact with other people that have different apps, you need a multitude of chat apps.
00:04:51: Angelo Veltens: Yeah. That’s a really good example. And that leads to other problems. This is often something I face in my life. Even with my wife, for example, I’m using multiple chat apps because we have multiple. And sometimes I write over the one, sometimes the other, or in the other app is a group of somebody else. And so when I want to find out, okay, I sent you that recipe. So where did I send it to you? Or where did you send it to me? Was it only one app, was it on Signal, was it on WhatsApp, or did you write it on a Trello board? I don’t remember where I put it and it’s really hard to stay in control of my data if it’s spread across multiple apps and I don’t really have access when I need it.
00:05:34: Lucas Dohmen: And even if you have an Android or iOS application, it’s not possible to search through all apps, right? They are all their own silos of data that you cannot search through. Unless it’s like a built-in application, then you probably have some search integration, but most of the apps don’t, right? But to look at a different example, one thing that I face from time to time as a consultant like you is, I want to share data with a customer. And maybe they are using Google Drive and maybe we are using Dropbox. And now we are in trouble, because we cannot share data with each other.
00:06:13: Angelo Veltens: I know this problem very well, but even worse is a calendar problem. So the customer uses Microsoft Teams for example, and we’re using Google Calendar. So we end up using multiple calendars in the end that are not synchronized. And of course there are always core problems with appointment conflicts and so on because we don’t have a single place where we could look.
00:06:36: Lucas Dohmen: Interesting. So one thing that I noticed about is that there are existing open standards for some of the things that we talked about. So what do you think is the problem? Why did we get into those silos to begin with?
00:06:51: Angelo Veltens: I think, for example the calendar, now we have standards for that, you could say it’s a solved problem. We have iCal and so on, but come back from a time where we didn’t have cloud and software-as-a-service solutions. And it’s good to synchronize or to port my calendar data from one desktop calendar to another desktop calendar or to my phone calendar. But what we actually want today is to be connected via cloud services, via the web. We want to collaborate together. And centralized web services are a great solution to achieve that. We have to pay for that by losing our interoperability. We have one central service that works perfectly and we can collaborate nicely as long as we don’t use another service, a different service. And what we are missing is, okay, we need some standards, but we also want to stick to the cloud and to cloud services and the web. I want to collaborate on the web. And this is where Solid comes into play. So we can have all the fancy web collaboration and social stuff together with open standards.
00:07:59: Lucas Dohmen: Okay. But before we dive into Solid, I just want to look at two other problems before we look at one of the possible solutions. And I think that the problems we described so far are very known to most people, if they are computer experts or not. They have faced those problems before. But there are also problems that maybe some of the more computer- focused people, those listening to the podcast maybe, have also faced. Like for example, I have some app that has some data from me in it, and I want to write a script to extend it. And maybe build something upon it because I just need this one feature, apart from that it’s perfect. But I just want that one thing. Is that also something that could be addressed with something like Solid?
00:08:46: Angelo Veltens: Totally. I mean, if you’re lucky you have a good API you could use, but then again you have to integrate against each and every API you want to use and all. And it’s really hard to combine data from different APIs in the end, and that’s often what you want to do. And it’s a lot of work. So even I, I really like coding even as a hobby, but I don’t have the time to do all that. I mean, we need to do better than one-to-one integrations with dedicated web services. We need standards. We need interoperability.
00:09:18: Lucas Dohmen: Yeah, definitely. Especially if I want to share my solution with other people that maybe use a different storage solution or whatever they use. That’s not nice. Okay. So let’s look a bit at Solid. So before we dive into the different approaches that Solid offers, what is Solid?
00:09:39: Angelo Veltens: So Solid is kind of a paradigm shift for the web. So today we usually have apps coupled to the data as described with the examples, and Solid decouples it. So think of something like Google Drive or Dropbox for your data. So you have apps and all the apps could store the data instead of their own database or backend system, they could just store it to a so-called Solid Pod. Solid Pod is a website that follows the Solid standards and allows you to store data on it in a way that other apps can access it and make use of it.
00:10:20: Lucas Dohmen: Okay. But that sounds a bit like I need to be like an operator, right? Like I need to maybe run my own server. Is this the case, or can it also work differently?
00:10:31: Angelo Veltens: You may run your own server, but you don’t have to. So this is another part where Solid brings you a lot of freedom of choice. And the paradigm shift is that we really have a way to decouple the app provider from the storage provider. So in the app we have different markets for both. So the app developer could focus on building the best app they could imagine while not having to care for things like authentication, user management, and storage. While the Pod provider can focus on providing secure storage and caring for the data and caring for access management, security, and so on. And you could host your own Solid Pod, but you could also pay someone to provide you with a Pod or some services, perhaps your insurance brings a Pod with their insurance account. A good thing with Solid is also you don’t have one Pod, you can have several Pods and all the Pods can have different standards for security and availability and so on.
00:11:38: Lucas Dohmen: So I don’t have exactly one Pod, but I could have one where I store my insurance information and one where I store my personal photos, for example. Right?
00:11:50: Angelo Veltens: Yeah, exactly. And for example, let’s say the podcast you are recording. It’s public anyway, you could easily put it on a Google-provided Solid Pod. If they one day decide to provide one. So it’s not a big deal for privacy or so. But perhaps your holiday photos, you are more concerned with and you don’t want to trust anybody, but set up a Raspberry Pi in your home and host a Solid Pod there to surf your photos. So you could share it with your family, but you don’t have to trust any cloud provider that may make use of the photos you don’t want them to. Then there are, for example, medical data, which I personally, I wouldn’t even put this on a server in my home because I don’t think that I’m enough of a security expert to make sure it never gets into the wrong hands. So I probably want to pay someone or trust my health insurer to store that data. And that’s possible with Solid. And we can have multiple Pods with different requirements and different offerings from different providers or even some clubs or non-commercial NGOs could provide Pods or the state could provide Pods, depending on the use case you can have different Pods.
00:13:06: Lucas Dohmen: So if I imagined that I now have like my photo Pod and my insurance Pod do I still have one identity that spans both Pods? Or am I like two people with two Pods? How does that work?
00:13:18: Angelo Veltens: That’s also a very important feature of Solid. As I said, it splits data from apps, but it also splits identity from data and from apps. So you could have one identity and use it as a single sign-on to all your apps and to all your Pods. But you also could have multiple identities. That’s also something where you have the freedom of choice. You could have multiple identities that are linked to each other, so people can see, these are the same, just different roles and different… perhaps you have a company Pod and the company identity and the private identity, but you choose to interlink them. So it’s obvious that it’s the same person, but in different contexts. But you could also have a completely anonymous identity which you do not interlink. And you have a different Pod, and it’s not connected to the rest of your digital life.
00:14:09: Lucas Dohmen: Okay. So if I imagine now that I have now my Pods, right? And now I want to solve the problem that we had in the beginning. I have some recipes and I want to maybe store the ingredients in my Pod so I can buy them. How would that work in this decoupled fashion?
00:14:28: Angelo Veltens: So let’s say all the apps exist already. So we have apps built on Solid that store the data and Solid Pods. So I would have a recipe app. And I would, for example, go to some website that has a recipe and click a button to save the recipe to my Pod. Now, even today a fun thing to know, there’s schema.org, perhaps for search engine optimization it’s often used, but actually this is linked data that could be used by Solid. And I’m currently writing a browser plugin that could use this JSON-LD data. It’s built on websites to store on the Pod, so I could store the recipe on a Pod and then use my favorite Solid recipe app to list them, to search them, to show them while I’m cooking and so on. And I could switch to any other recipe app any day, if I think another one is better, because my data is in the Pod and not coupled to the app. I can switch apps, and the new app accesses the same data on my same Pod. So if I go now to my shopping list app, which is also a Solid app, then this app will also connect to my Pod and see, or be able to see, the recipes and the ingredient list of these recipes and could provide a feature to say, Hey, you have this recipe here, which of these ingredients should I put on your shopping list? This is the way it could work. Because the data is stored in the Pod and not coupled to the app. All the apps could access the same data and make use of it.
00:15:56: Lucas Dohmen: So if I look at it from the perspective of the companies building those solutions, it’s pretty obvious I could get some money from hosting the Pod for you. Like I take five euros and you get, I don’t know, so many megabytes of data. How would that work with applications? Can they also be paid or is this something that is always free?
00:16:17: Angelo Veltens: No, of course you can have a paid application. I mean, you don’t have to open-source everything, you can just have as today, have a web service and a premium feature. You just don’t have to do the user management yourself. It’s quite good actually, because you don’t have to encourage people to create an account. You can just talk to the existing Solid users and say, Hey, you have a Solid account, just sign in here, try the free part of the app. And if you like it go to a premium account, pay it, you could even solve the payment and subscription stuff via Solid and something like verified credentials are also stored to the pod. And we say, okay, you’re a premium user now. And you can use the premium features you’re not able to access otherwise.
00:17:08: Lucas Dohmen: So it could even be an advantage for me as a business because I need to solve less problems and still can charge money for the service that I offer.
00:17:18: Angelo Veltens: Yes. I think that this is also good for the companies because they don’t have to focus on basic stuff like user management or even a chat. Today, every app needs a chat, it needs to code a chat. And it’s a waste of time in the end. You want to focus on your core domain and your core features because those are the things people are willing to pay money for. So why not choose existing chats? Perhaps you could have a web component, for example for chat, and do the web component in the rest of my service and the chat I store to the Solid Pod. I could even use an existing chat, for example, today we have a Miro board together and we were chatting, we continue the same chat we had earlier on another service on the mirror board for example.
00:18:12: Lucas Dohmen: So it reduces feature creep. And so would you say that the applications are more narrowly focused because they solve less problems than like a traditional app?
00:18:22: Angelo Veltens: Good question. Yeah, you could build very narrowly focused apps, of course, but I think you could also build larger applications as well. If you use chat data from the Pod, perhaps you want to have a better and more fancy chat UI or something like that. So you code it yourself, if you like, but you don’t have to, you don’t have to use your time for that. Nowadays, if I’m a startup, I need to focus on my core domain and build something really creative that isn’t there before. But if I don’t provide the essential parts the users expect me to provide, I’m dead in the beginning. I don’t have a better example right now, but okay, if I don’t have a chat and people expect an app like that to have a chat and I don’t provide it, then I have a problem. So I need to provide it, although it doesn’t have to earn money.
00:19:16: Lucas Dohmen: True. So you wrote the Angelo recipe application, and I already have a Pod and I want to start using it. I can use my identity to log into your service and start with that? And how much control do I have, how much of my data can you see?
00:19:34: Angelo Veltens: This is handled by access control lists, it’s a set of standards that does multiple things. It standardizes the API, much like for example, w3 standardized API to store objects. You have a Solid API to store data on your pod. This is one part. And the other standards, for example, care about authorization and authentication. And you could give granular access to which part of the Pod should be accessed by which people, if you could share with persons, so with me personally, for example, but you also could restrict which apps can access which part of the Pods. So you could say Angelo’s recipe app can access all my recipes, but not my photos. Or you could even go so far as to say, okay, this recipe app may only access recipes that are vegetarian or so. If it’s useful for you, for some reason. You can have very granular access, but it depends on how the data is organized in the Pod and you have to set the access rights or you have to use an app that sets up the access rights.
00:20:49: Lucas Dohmen: So you could imagine that you have like a guilty pleasure thing that you don’t want to share with the recipe app… Okay, cool. So this is the topic of decoupling, right? So the next feature…
00:21:00: Angelo Veltens: Although may I add one thing about the recipe, because this is often overlooked? I could have, looking at the recipes, but what is perhaps even more important is I could have multiple apps doing different things with those recipes. For example I have one app that just gives me the recipe and has me cooking. But I could have another app that perhaps calculates the calories of these recipes. Does something completely different that’s not related to the process of cooking itself, but perhaps wants to give me statistics over what I’m cooking. How many recipes do I have that have too much fat in it or something like that.
00:21:37: Lucas Dohmen: That’s important to know, but I think that also brings us to the topic of interoperability, right? Because we sometimes need to say this is the recipe and my recipe app and my calculation of calories app. They need to understand the same format, right? So I guess that’s a pretty hard problem?
00:21:58: Angelo Veltens: This is at least not an easy problem. But this is, I think, the problem we need to solve if we want to achieve what I told earlier in the examples of what we talked about, so we need interoperability, and it’s a hard problem, but it’s not an unsolvable problem. It’s just the problem we needed to take more attention to it because we came to a point, okay, where this didn’t matter a lot, we just wanted innovation and new services. And I use one service and don’t care as long as the service is fine. But now I think we came to a point where we need to collaborate more between. So how is Solid’s approach to interoperability? Solid as I said builds upon existing web standards and also on the idea of the semantic web or at least semantic web standards and technologies like linked data and RDF. And this doesn’t solve interoperability per se, but it at least gets around the standard problems, like, okay, I have a JSON structure and the other app has another JSON structure and they just don’t fit together. The good thing about using linked data is that I can quite easily, or I get around all the syntactical and structural problems, I can just merge linked data from two different sources to a combined dataset. And therefore build a personal knowledge graph of all the data from all the apps. This doesn’t mean the data is per se interoperable for all the apps, it could still have two recipe apps using different semantics for recipes, and this won’t fit together, but at least the application doesn’t crash, I can put all the data together to a knowledge graph and take a look at the data. So this is one part. So the semantic part of course needs more attention on the semantic level. So I need to make sure that the recipe apps use the same vocabulary, the same terms to describe recipes. And this is just a thing we need to do in the end. But there are existing standards. Like I mentioned, schema.org, for example, is a good example. We already have this. All the recipe sites, the sites out there on the web are already using schema.org to describe recipes. Why are they doing that? Why don’t they invent their own standards for it? Of course, because they want to be interoperable because they want to be found on the web by Google, for example, and other search engines. This is how Google places the boxes in the search results and shows you the relevant information. If I don’t provide this then I won’t be on the list. And it’s the same with Solid. We can reuse the same approach there. And if I’m building the third recipe app on the Solid ecosystem, and I’m not reusing the data that is already there from the other two, then people probably won’t use me. So it’s in my own interest to reuse the data that’s already there. And it also makes my life easy. Why should I invent a new standard? In the app world we are facing today, okay, I’m bringing my own database anyway and I can reinvent the wheel. I don’t have any advantage by being interoperable to other apps but perhaps someday in the future we are able to add a feature to export data, and then it will become relevant. But in Solid it’s relevant right from the start. I can use the data right from the start if I’m willing to, and I should do it. The good thing is I can use the parts of the data that are already there, but I can add more data to it. That’s one advantage of using linked data. It basically works by having so-called triples, statements about subjects. And I can add more statements, more facts about the same subject without destroying what’s already there. And so I could have a recipe and perhaps one app doesn’t support the calories feature, but if I have an app and want to add the calories to the recipe, I can just edit the data without breaking the other app. And can add more and use what’s already there without reinventing…
00:26:19: Lucas Dohmen: It seems to me that this is a pretty logical thing, if I want to bring more people to my app then I need to look into the existing standards because then I can convince more people to switch to my app because they don’t need to convert all the data. But on the other hand, if I imagine, let’s stick with our recipe example, and let’s say that someone from the US maybe wrote the first big recipe app, and they didn’t pay attention that maybe people in other countries use different measurements than the US and the data formats allow us to switch to different data formats, then I would be in a problem right? Then I would need to invent something new, maybe?
00:27:02: Angelo Veltens: It depends on how the American app expresses their units, for example. I think schema.org for example solved this, you can have in your recipes, in the amount you can have a value and a unit code, for example, with it and the other app could just use other unit codes or even translate from one unit to another. So this shouldn’t be a problem. But of course there might be things that are not defined yet where there isn’t a vocabulary yet you could use, one app would start with something and the other app would find, okay, this doesn’t really work for us, we need to do things differently. But I think this is a normal standardization process and, you know, it’s not engraved in stone. You could do data migrations, for example, if things don’t turn out, and the good thing is you have one place to do the data migration. It uses Pod. And we already did things like this with apps, with example apps we coded in the Solid community. It’s doable and it’s not that big of a deal to migrate data.
00:28:07: Lucas Dohmen: But from a user’s perspective, if I migrate my data from the old recipe format to the new recipe format then would the old apps not work anymore? Because the old data would be gone.
00:28:20: Angelo Veltens: That might, of course, if it’s not updated, it might be the case. That’s true. So you could update to the new app, perhaps the old one is not maintained anymore, but at least you don’t lose your data. You could also choose to not migrate the data. Solid won’t solve every problem in the world. So we probably get some new problems with this approach, some different problems. But the important thing for me is in the first place to have the foundation to be in control of our data and then make decisions like, okay, do I want to migrate my data? Do I want to stick with the old app? Or do I want to stick with the new app? For example, today, often I don’t have this choice. Just the old app is not supported anymore and I just lose all my data. So bam. So we are getting better with it. It won’t solve everything. And there are still problems that need proper thinking. And I can’t answer everything, how do we migrate this and how do we solve this case. But at least Solid gives us a standard and way to think and talk about new approaches in how we want to use our data in our apps.
00:29:33: Lucas Dohmen: Totally agree. I would not assume that it solves all the problems. Okay. So we talked about decoupling and interoperability. The last aspect you told me about was linking. Can you say something about that?
00:29:46: Angelo Veltens: Yes. So this is also about linked data. So as I told, what we are doing by putting all the data into Pods by using linked data standard we are creating a knowledge graph of my data. But we also talked about having multiple Pods and the linking aspect is very important because if I have multiple Pods, how do I get, for example, a list of all my holiday photos if some are on my Raspberry Pi at home, and some are on my Google Drive Pod and some are somewhere else. So this is where the linking part of linked data comes into play, where I have URIs for all the data and all the entities that are identified by URIs which I could resolve. So I can follow links, basically, like the web itself. I can follow one link from one HTML page to the next one and so on. And this is the way the data is linked with Solid, and the way apps could follow their nose from one piece of data, from the recipe to the ingredient, to whatever. And it doesn’t matter in which Pod or in which Pods all the data that is relevant to the use case I’m currently facing, it just doesn’t matter because it can follow the links.
00:30:58: Lucas Dohmen: Understood. So I think we have a good overview now. I said in the beginning you are working on the SolidOS part of the system. What is SolidOS when we now look at Solid as an ecosystem?
00:31:10: Angelo Veltens: So imagine you have a computer, you have a hard drive so you can store your data, basically your Solid Pod, but it’s quite useless if you don’t have any apps. So at least what any new computer should bring with it is an operating system with some basic features. So I could boot it up and take a look at my files. Perhaps create a new file. Perhaps do some calculations with a calculator and so on. And that’s where the name SolidOS comes from, because we think of SolidOS as an app that brings this basic operating system, like functionality, to your Solid Pod. So this is usually installed to your Pods. So even if you just have a Pod and didn’t use any apps yet, you have some core functionality, you could use SolidOS to access the data in your Pod, browse the files and browse the data, create a node, for example. Or even create a chat, a meeting, and some basic stuff where you think, okay, this is basic functionality I would expect from anything I want to do on the web. And this is what SolidOS does. So your pod isn’t useless when you start. And you can then make your first steps with Solid and start discovering third-party apps that could be hosted anywhere on the web. You know, it could be provided by anybody who wants to code an app and host it somewhere on GitHub pages or on a server or a commercial service. And I can use these specialized services to add more data to my Pod but I always have SolidOS to take a look at the raw data, for example, and do some basic stuff.
00:32:45: Lucas Dohmen: So if I imagined that I want to get started now with it. So what do I need as a starter kit, I need a SolidOS and I need a Solid Pod, or how does that work?
00:32:57: Angelo Veltens: Yeah. You probably would go to solidcommunity.net right now. This is a community server where you can get a Pod. It’s nothing commercial or professionally provided, so don’t expect anything to be available perhaps without downtime or so, but it’s quite cool and quite good to start and do first steps with Solid. So you could go there, create an account, and then you have a Pod and you already have SolidOS installed on it. If you open it in the browser, you can use SolidOS to browse through some photos that come with your profile. For example. You get a profile, the identity we mentioned earlier. And in Solid it’s called a WebID. Basically a URI that identifies you as a person. And if you resolve that URI, you could see a social-network-like profile, or you could edit a profile picture, your name, and you could also add friends. If you have other people that are using Solid, you can add them to your friend list there. And then you have a Pod and could, for example, use SolidOS to create some files on it, but you probably want to try some apps as well, there are some cool community-developed apps, like for example Media Kraken, where you can store your favorite movies on your Pod. And then check it as soon as you watched it or if you liked it, something like that. There’s a list of Solid apps on the Solid website, solidproject.org. There, you can see how you can get a Pod. You can see a list of apps you could try. And you can also learn about Solid from a development perspective, how to write my own Solid app and how to perhaps host my own Solid server and so on.
00:34:40: Lucas Dohmen: So solidcommunity.net is a combination of a Solid Pod and also SolidOS, it’s one package?
00:34:46: Angelo Veltens: Yes. SolidOS in the end, it’s just a web app so to say, and as a web app, it’s hosted on your Pod. Every Solid server is also a web server where I can just host a webpage, for example, and SolidOS in this regard is a webpage or web app that is hosted on this Solid pod per default. So you go to solidcommunity.net to register a Pod, for example. It’s just one Pod provider, there are others. So if you want to get an overview, you go to solidproject.org, which is the official website of the Solid project. And there you can get a list of Pod providers and choose one of them.
00:35:26: Lucas Dohmen: So one thing that I wanted to talk to you about is do you also see potential downsides, things that might be worse than the current solutions in Solid, dangers that you might see that we need to pay attention to when moving forward with Solid?
00:35:42: Angelo Veltens: So as I said, Solid is not a silver bullet that will solve all our problems, but it is a foundation that enables us to solve problems we currently face in the web and with the app ecosystem. This doesn’t mean necessarily that it solves it automatically, but it gives us the tools at hand. But with every tool there comes responsibility and dangers. So although Solid is meant to be decentralized, for example, it enables us to spread data around and get multiple identities and so on… But if you aren’t careful, then we could end up with something like a Google Pod where everybody has a Pod at Google and in the end Google would have even more data from us than it has now. Google Mail, Gmail, is a good example for that. Email is decentralized and I could get an email basically everywhere, but a lot of people just use Gmail. And if we end up like this with Solid, it also brings dangers of course. So it’s very important that we discuss Solid and the approaches of Solid not only from a purely technical perspective and how the technology works and how we develop things. But I think we need to discuss as a society, where do we want to go with the digitization. I think we need interoperability and we need to… I am a big fan of digitization. I don’t say we should do anything with paper to protect our privacy. That, couldn’t be the goal, but if we go the way to do everything digitally, we need to choose wisely how we do it.
00:37:33: Lucas Dohmen: So if people are interested now in this whole project they could of course get started with installing it, but do you have other calls to action for people that are interested in it as a project or even just as you Angelo?
00:37:48: Angelo Veltens: I of course would like to see more people being involved in the Solid community and be part of the movement. What I want you to do at least after listening to this episode, I hope you at least are aware of how limited we are currently with our apps and services. And perhaps you can think of the possibilities that separating apps from data could bring to your daily life. And then perhaps you get the idea of Solid and the vision I have with it. And then learn more about Solid, get a Pod, play around with it. Perhaps write an app, if you are are developer. But even if not, join the community, we need great people who improve UX for example. SolidOS is a nice tool that can do a lot of things, but the UX is really crap, so help needed there! But as I said, Solid approaches problems we need to solve as a society and not only as developers. We need to decide how we want to control our data in the future and how we want to enable people to use that data and really get into control of it. All members of society are welcome to join the Solid community and discuss those topics … for me, it’s the next step in the digitization. And it’s very important that we involve many people with it.
00:39:10: Lucas Dohmen: So it’s also very welcome to ask critical questions?
00:39:13: Angelo Veltens: Of course, yes.
00:39:15: Lucas Dohmen: Awesome. Then thank you so much for this great overview of Solid and all the problems it tries to solve. And to all our listeners: Have a nice day and see you in the next episode. Bye.
00:39:43: Angelo Veltens: Bye, thank you.