From Zero to Hero with Solid
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | 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. | |
| Identifiers | 10.5446/61658 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023256 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Communications protocolMobile appSoftware developerOpen setWeb browserExtension (kinesiology)Linked dataTurtle graphicsData storage deviceService (economics)Solid geometryFocus (optics)AuthenticationInternet service providerIdentity managementDemonGamma functionPresentation of a groupSolid geometryInternet service providerIdentity managementTask (computing)Virtual machineData storage deviceType theoryPasswordMobile appData exchangeSoftware developer1 (number)Social classCommunications protocolWeb 2.0Content (media)EmailWebsiteUniform resource locatorRandomizationService (economics)ImplementationFocus (optics)Semantic WebOntologyProjective planeDifferent (Kate Ryan album)Cartesian coordinate systemShared memoryContext awarenessOpen setBitBoolean algebraCategory of beingLoginTurtle graphicsMachine visionObject (grammar)Data storage deviceComputer architectureFile formatIterationComputer animation
07:42
Binary fileComputer-generated imageryVideoconferencingTask (computing)Solid geometryFocus (optics)Server (computing)Web pageData structureData structureCartesian coordinate systemAuthenticationMultiplication signElectronic mailing listServer (computing)Black boxSolid geometryWeb 2.0Mobile appData storage deviceFile formatTask (computing)Web pageUniform resource locatorPoint (geometry)RootDirectory serviceMereologyComputer fileFile systemLink (knot theory)Integrated development environmentComputer animation
11:14
Data storage deviceWeb pageTotal S.A.CASE <Informatik>Solid geometryElectronic mailing listWeb pageTask (computing)LoginBitComputer animation
12:42
Web pageTerm (mathematics)Data structureData typePrice indexTask (computing)Client (computing)Standard deviationSolid geometryServer (computing)Source codeBlock (periodic table)Data storage deviceVideoconferencingSubject indexingPoint (geometry)Cartesian coordinate systemWeb pageMultiplication signDebuggerSolid geometryMobile appExistenceCodeTask (computing)Type theorySubject indexingCache (computing)CASE <Informatik>WebsiteInformationNP-hardData managementIdentity managementDifferent (Kate Ryan album)Server (computing)Focus (optics)Proper mapProjective planeAuthenticationFrame problemStandard deviation1 (number)View (database)BlogGoodness of fitDatabaseComputer animation
17:57
3 (number)Decision tree learningMaxima and minimaTorusFiber (mathematics)ProteinSolid geometryPoint cloudoutputMobile appWeb browserThread (computing)Internet forumAuthenticationSynchronizationMobile WebType theoryRevision controlExecution unitSource codeGroup actionWeb pageInformationWebsiteComputer configurationProxy serverLink (knot theory)File viewerPersonal digital assistantElectronic mailing listPoint (geometry)Mobile appMultiplication signOperator (mathematics)Descriptive statisticsMathematicsCartesian coordinate systemSolid geometryRevision controlWebsiteToken ringData storage deviceLink (knot theory)Type theoryServer (computing)InternetworkingTimestampSource code1 (number)Uniform resource locatorThread (computing)Search engine (computing)ExistenceAuthenticationSynchronizationBitDebuggerRight angleInternet forumConnected spaceDisk read-and-write headWeb browserStability theoryPoint cloudComputer animation
25:33
Mobile appProcess (computing)Computer virusVideo gameBlock (periodic table)InformationPower (physics)Mobile appDifferent (Kate Ryan album)Axiom of choiceLatent heatBuildingServer (computing)Mechanism designCASE <Informatik>Type theoryCartesian coordinate systemSubject indexingDependent and independent variablesPoint (geometry)BitMereologyPrice indexView (database)Operator (mathematics)Point cloudInternet service providerSolid geometryGame controllerArithmetic meanSynchronizationImplementationAsynchronous Transfer ModeQuery languageUniform resource locatorClient (computing)Presentation of a groupInteractive televisionComputer animation
32:54
Mobile appInternet service providerData miningVector potentialPoint (geometry)Information privacyProjective planeCommunications protocolPower (physics)Axiom of choiceData storage deviceEncryptionMobile appInformationCodeCartesian coordinate systemSolid geometryEscape characterServer (computing)Internet forumSoftware frameworkDifferent (Kate Ryan album)WebsiteComputer configurationMaterialization (paranormal)Cloud computingSoftware developerBuildingMehrplatzsystemOpen sourcePoint cloudReading (process)MereologyFAQCausalityTheoryMatrix (mathematics)Physical systemComputer animation
40:15
Mobile appComputer animationProgram flowchart
Transcript: English(auto-generated)
00:05
And let's welcome the next show, From Zero to Hero with Solid. Thanks Noel for presenting. Okay, thank you. My name is Noel, I'm from Barcelona. I'm currently working at Moodle four days a week.
00:23
But I'm also in the site making solid apps, site projects. And that's mostly what I will talk about today. I usually work in the open. This means that I journal about my development. So you can follow my work in my website and here you have all the socials and everything. So if you are more interested in something I say, you probably can find more detail in my website.
00:44
So before we start, how many people know what solid is or heard about it? Well, maybe half the room. Okay, that's nice. So for those of you who don't know, before I say what solid is, I have to go back to the creation of the web. So when the web was created, these technologies were invented like web browser, HTTP, HTML.
01:05
I'm sure most of us are familiar with these ones. But later on there was something called the semantic web. And how many people know what the semantic web is or are familiar with that? Okay, almost the same as solid, so yeah. Basically the semantic web is an idea that in websites, other than human readable content and linked documents,
01:27
users can also have linked data, which is machine readable data, not only human readable. And like this, some technologies were introduced like the resource definition framework, JSON-LD, Tardel, etc.
01:40
We will see more about this later. And finally, the solid protocol. It's the next iteration of this idea and it brings decentralized storage to the web. The web I see it and the way they say it, Web 3.0 by the creators of the web. But it doesn't have to be confused with Web 3, which is blockchain.
02:02
As you will see, solid doesn't have anything to do with blockchain. It's something completely different. And the basic idea of solid is that users have a pod and applications and services store the data in the user pod. So for example, if you have here on the left, we have the traditional architecture.
02:22
Each application you use stores the data in a backend. And that's how most applications work nowadays, right? The idea of solid is that you can use different applications, but these applications can store data in the same pod. So it's the user, the one deciding where the data goes.
02:40
And it's important for privacy, but also for interoperability and a better user experience. Because this way they can share data between different apps seamlessly, right? That's the basic idea. And if you are more interested in the idea of solid in general, more division, you can watch a talk from 2019 that was given here at FOSDEM.
03:02
And you can see more about that. This talk will be a bit more technical. So when you saw the title of this talk, maybe this is what comes to mind. But before we begin, I want to clarify that there are different types of heroes, right? So what type of heroes do I mean? So there are many ways to use solid, just like there are many ways to make websites.
03:23
In this talk, we will focus on making solid apps. So I will not talk about hosting pods or making solid services. Mostly I will talk about making solid apps. And this is because this is what I have been doing for the last four years as site projects. So I have not worked either in any enterprise-level application or anything.
03:43
But I don't want to discourage you from learning from this. Because my goal with these apps is to make them usable for people. It's not only some site project, some random site project to try technology. My end goal is to actually make useful apps. And also, it will be broad strokes, because I cannot get into many of the details.
04:03
But we will get into some of the ways. So the first app I developed was in 2018. It's called Solid Focus. And basically it's a task manager, right? So the first application you do, it's always like a to-do app. So this is what I decided to do with Solid to learn about it.
04:23
So the only thing we care about is that you have tasks, and you can mark them as done or not done. That's the basic, right? And when you open the application for the first time, this is what you see. So normally, people is used to register an account with an email and a password or something like this.
04:43
In Solid, it's different, because what you have to do when you open an account is to give the solid pod. And you are telling the app where it should get the data, right? In this case, I also added a login offline button, because I know many people are not familiar with Solid. And if they only want to try the app, they can do it like this, without a pod.
05:02
I also think it's very aligned with the vision of Solid, that users decide where to store data. So they can decide to store it in their local device without hitting the network, right? So this is how it works. And when you are making a Solid app, there are actually three actors you are interested in.
05:20
One of them is your application, another one is your pod. Well, the user's pod, where the data will be stored. But there is also the identity provider. And actually, when users are authenticating, you are communicating with the identity provider. It will give you a token, and it's this token, the one you use to do the data exchange in the pod.
05:43
This is the basic architecture of how it works. But in general, you don't have to care too much about this, because you just use a library, you give it the URL, and then it gives you the token, and you can make authenticated requests. But I think it is important to at least know that before you get into it.
06:01
So once you have the token, then you want to create data, right? So usually when you think about a task manager, this is the type of data you will see, right? You have an ID, a description, an add-on. It's a Boolean. But when you are working with solid, this is how you would do it. Now, before people want to leave the room, one of my goals with this talk is to actually convince you why this is better.
06:26
And in the end, when you get used to it, it's not so different, actually. So hopefully I will do it. So we have a context. This indicates the vocabulary of this piece of data. That's important because if different applications are using the same data,
06:41
they need to share an ontology or they need to be using something that is the same so that the data can be shared or understood by different implementations. The ID, it's a URL. This is also important because it's where the data is actually stored. We will see more about this later. And then there is the type. So if you think about object-oriented programming,
07:03
this would be like the class of the object. And then you have other properties, which can be just literals, or they can be linked to other objects or other properties. So the one before was JSON-LD, which is maybe more familiar for most people because it's JSON.
07:21
But when you are working with solid most of the time, you will be seeing RDF. And this is a format called turtle. And actually it's not so different from the first JSON I showed you. It's only that if you are not familiar, at first it may be striking. But eventually it's quite similar to use and it's not so different. So this is why I think it's not so bad in the end.
07:43
I have been talking about the solid pod, like it's only a black box. But the thing is that inside of the solid pod, you actually have containers. You can think of these as folders in a file system. Inside of these folders or these containers, you have the documents and you can also have binary.
08:01
Like for example, you can have a video, an image, a JSON file, whatever. But this is something that will be not structured using this vocabulary data, right? So it's important that what is useful for your app and what you want to be interoperable is structured using RDF. And inside of the documents, you have resources, okay?
08:22
So what I mentioned before that the IDE says where the data is stored. If we look at the IDE of a task in this example, we can see that the root of the URL is the solid pod. So this tells you where the user is storing its data, right? The directory tells you the container where the task is stored.
08:43
The URL is the document and the complete URL, including the hash, is the RDF resource. So this is nice because whenever you see a piece of data in solid, you immediately know its structure and what it is stored. This is useful as well if you export data and all of this. So now we have the authentication token, we have the data, and we know where to put it.
09:05
So now this is the easy part because this is built using web technologies. You only have to do a post request. So you do a post request to the URL with the document and you create the document. And the body of the request will be the data in Tardel format. It can also be in other formats if you want, but most of the time you will be using Tardel.
09:24
It's the most common, right? If you want to get the data, you do a get request to the document. If you want to delete the data, you do a delete request. If you want to get a list of all the tasks, you do a get to the container and you will get the list.
09:41
And so on and so forth. The basic idea is that it works like the web because it's built from those technologies, right? And actually the good news is that that's it. This is how you make solid apps. And now in this talk I will go into more things, but these are the basics. If you understand this, you can already do a lot of things with solid.
10:03
And I think that's nice because it's building up on existing technologies. So it's always important in that regard. Here you have some links if you want to get into the weeds with some things. And here you have my journal when I explain how I learned solid. This is the first time I saw solid, so it may be more interesting to some of you.
10:24
Some takeaways, we learned the solid basics. And something that maybe wasn't obvious is that there is no server. You make the application and the application works in the front-end. Because the data will be stored in the solid pod, right? So this is nice because you don't have to manage any servers.
10:42
And you are only building front-end applications, which is static assets. And these static assets, they can be downloaded in a zip file and put into a computer or whatever. It's only JavaScript and HTML. But we also have some challenges. For example, the onboarding UX is not great. We have some issues with the page speed.
11:02
And also, I didn't get into some of the things important for interoperability. So the next application I worked on, it's called Media Kraken. In this case, it's a media tracker. So the point is that you store all the movies that you have watched and all the movies you want to watch. And you can keep track of them. The use case is this and it's quite simple, right?
11:23
You can see how you can filter the movies, etc. So in this case, this is how the login looks like. In philosophy, it's very similar to the other one. But it improves a little bit because at least I explain what is solid. I help users a little bit if they don't understand what to do.
11:41
But also, once you are inside of the application, you can export the data. And it will be exported as a JSON-LD. Later on, when you log in with your solid account, you can import it. So in this way, I added one way for people who started using it offline to upgrade to using solid. And I think this is also important so that they can make it more easy.
12:06
The other issue about the page speed, also maybe this wasn't obvious. But when you do a request to the movies container that I mentioned, you can get all the tasks in the previous example. You get a list of movies, right? But then you only get the idea of the movie.
12:22
You don't get all the metadata, like the name and the image and everything. So if you want to get the movies, then you need to make another request for each of them. So in the end, this is not great. You are doing N plus one requests, right? In case you are wondering, why would you get all the movies? Why don't you get just the ten first movies and you do pagination, right?
12:42
The point is that I want my application to be snappy and that you can filter things quickly and it works. If you have to do HTTP requests every time you do any interaction, it will be very slow, not just the page reload. So that's why I wanted to have all the movies in the front end.
13:00
And then what happens doing this is that the first time you open the app, you see this. And depending how many movies you have, you will be seeing this for a long time, which is not great, right? So what I did is that there is a movie cache of the data using IndexDB. And this way, the next time I open the application, I can look at the last modified date of each one of the documents and only request the new ones.
13:25
This is a big improvement compared with Solid Focus. This makes it more usable. Still, if you have many movies, for example, I have more than 2,000, the first time you open it in a new device, it's not great. It can still be improved by a little bit, right?
13:42
And finally, the thing I mentioned about interoperability. I don't have time to get into this a lot, but I wrote a blog post called Interoperable Serendipity. And I think this is actually the most important point of Solid. In the end, if you are using Solid and you are making apps, but they are not interoperable, you will end up in the same scenario we have now.
14:04
The power of Solid is that you use different applications and they use your data. So I think this is important to have into account. So for example, which vocabulary would you use? There are some websites where you can see the vocabularies that are already used, and you can see which ones are the most popular.
14:22
So they are the most likely to be more useful. You can also create your own vocabulary. If you are doing a new use case, there's nothing wrong with creating your own vocabulary, and then other people will be able to use it to make other apps, right? And finally, at the beginning, I wasn't sure about this,
14:41
but now that I've learned more, I think mixing and matching vocabularies is actually okay. So you shouldn't be taken aback by doing this, right? And then we have solved which vocabulary to use. The other thing is, where do you store data? For example, if I am storing movies in slash movies,
15:01
maybe another app can do it in slash films, so they will not work correctly together, right? So the point is that when you log in and you get the identity of the user, you will get a document describing all its information, all the public information. And if you are making the request with an authentication token, you also get the private information.
15:21
And some of this information is something called a type index, and this type index tells you these users have tasks in this container, movies in this container, et cetera, right? So once you do that, then you can already use the proper container without hard coding anything in your application. If you are the first one adding movies or whatever to a pod,
15:43
then you can just create the type index if it doesn't exist. I have to mention that right now it's a draft, but you can still use it, and I have been using it for years, because it's a client-to-client standard. This means that the clients, so the applications,
16:00
are the only ones that need to know about this type index. From the point of view of the pod, it's just a simple document, right? So this is something you can use today. There is also something else called the solid application interoperability spec, but this one is a client-to-server standard. So until servers start implementing this, this will not work. Just to clarify in case it's not clear, server is the pod, right?
16:26
Okay, so the final thing about this app is that if you have all the data in your pod, you will not have all the movies in existence in your pod. So how do you make this work to have a good user experience so that people can search and get the movie they want, right?
16:43
In this case, something that I think is very important to do with solid apps is to rely on public information. So in this case, I am using a website called the movie database, which gives you a database and a free API to query that. Depending what type of data you are working on,
17:01
you can search different APIs. But this is the basic idea. And if you want to learn more about how I built this app, you can check it out here. And some takeaways, type indexes are nice. I encourage you to use them. And also caching is nice. It improves the performance a lot.
17:20
So this is something to keep in mind. Things we still have to improve on boarding UX and page speed. They are still not great, right? The next application I built is called Humai. I don't want to scare you with the time frame in this. The thing is that, as I mentioned, this is a project and I don't only work on solid.
17:42
I also experiment with different technologies. And for this one in particular, I started doing some animation things and all that. So it was entirely solid, what made this take so long. But in any case, Humai is a recipes manager. So the point is that you have a collection of recipes and you can search them and browse them.
18:02
So InSpirit is quite similar to MediaKraken, but instead of movies with recipes, right? This is the basic idea of the app. So the onboarding UX, at first sight, it may seem very similar to the other ones, but I think it's a lot better. Why? Because this button here says, create your first recipe.
18:21
It doesn't say, use browser storage. And this is important because for people who don't understand how things work, maybe they are scared. Like, what is browser storage? But if they just say, create first recipe, they can just go ahead and do it without worrying about solid or any technical aspects. Then, when they start using the application,
18:42
they can see the status of their data in here. And what I'm trying to convey to users is the concept of a cloud. So I still mention solid when they have to log in and create the account and everything, but I think this way they understand that they have a cloud where the data is stored,
19:00
which is using solid, but they also have the local data. And I think this type of concept is something maybe they are already familiar with. And this got me to the realization that the application is offline first. So that is quite nice. But there are some issues or some challenges when you are doing an offline first solid app. For example, when you authenticate with a solid pod,
19:25
you shouldn't store the authentication token in the front end. And if you want to see the details why, you can read this forum thread. And also, every time you open the app, you have to redirect to do the authentication. This is also something that could be improved in the future, but that's how it currently works.
19:41
So the way I have solved this for now is that I have some settings, and depending on the device you are using, you can reconnect automatically or not. For example, in my desktop device, I have this with everything automatic because I have a stable internet connection. But in my mobile phone, I don't reconnect automatically.
20:00
I only synchronize manually whenever I want to. This is the basic idea. And the second thing, this will get a bit into the woods as well, but imagine you have this delicious ramen recipe in your pod, right? And you have it in two devices. You have it safely stored in your solid pod, and you have a copy in your mobile phone
20:20
and another copy in your desktop, right? You change the title of the recipe in your mobile phone, but it's not connected to the internet, so the changes stay local for now. Then you change the description in your desktop device. This one is connected to the internet. So you will synchronize with the pod, and you will push the changes.
20:41
But now we have an issue. When the phone finally synchronizes, you will see that it has been updated because you look at the timestamp of the last update, but you don't know what has changed. So now you have to decide if you discard the local data or you discard the remote data. So this is not ideal. The way I solve this is using something called CRDTs.
21:04
You can also read more about the details here. And in this case, I had to create a vocab for this. And that's fine, and I'm mixing both the recipes vocabulary and the CRDT vocabulary. So let's go through that again. You do the same thing. You modify the name in the mobile device,
21:20
but this time you also store the operation in the data. So not only the change, but also what happened and what time, right? Then you do the same in the desktop. You synchronize, and you push the changes. And then when you synchronize with the mobile phone, you will see that what changed remotely was only the description.
21:41
So in this way, you can pull the changes, and then you push your change without any conflicts. And this is the basic idea. And when you do all this, then you have everything synchronized. If your head is spinning right now, don't worry, because this is a bit esoteric. But not all solid applications have to do this. It's just this is the way I found
22:02
to make my user experience how I wanted it to be. But you don't need to do this if you are getting started or want to see how solid works, right? So something else, and I think this is one of the most interesting things about this app, is that before I was saying that for movies, for example, you search an API, right?
22:21
But if you have to search an API with all the recipes in the world, it doesn't exist. How does people search recipes? Or at least how do I search recipes? I go to a search engine, and I search for the recipe. So the point is that the data itself is the web. It's websites that are already there, right? So the point is that for recipes,
22:42
when you make a search, most search engines show you the results, and they know that they are recipes. This is not just a website for them. They know these are recipes. And if you look under the hood, you inspect the source of these websites. You will see that in the header, they have some data called application LDJson,
23:00
and the nice thing is that this is actually semantic data. So this is what I mentioned way at the beginning, and many websites are already using this, websites that don't even know that solid exists or anything. So this is very nice because this is one way to leverage the data that already exists in the wild, and I think this is a nice way to showcase
23:20
what the future could look like, if solid was more used and data were more interconnected, right? So yeah, you just import, you just put the URL of the website, and you import the data. Unfortunately, because the application lives in the front end, there are course issues, so you cannot make HTTP requests, and the way I've solved it for now is to use a proxy.
23:42
But depending on the application you do, this will not be an issue, because you can also use the server where you are hosting the app or something. And finally, the last thing to mention is that in this app, I also implemented the ability to share things. So by default, when you create data in a solid pod,
24:02
you should create it private, right? But you can also change the permissions and make it public, and this way you can share this link with other people. Then if you share this, you can give the link to someone who doesn't even have a solid account or doesn't even know what solid is, and they will be able to see the data
24:22
using the URL of your document. And something interesting to realize here is that this is not only a URL of my application. Like with my app, you can share recipes. No, you are sharing the document URL in the solid pod. What this means is that visitors don't need a solid account because it's public,
24:42
but also that any of you here in this room and anybody can make an application that already uses this URL, because you only have to read the solid document that is following the solid protocol, right? So in this way, you can already see how doing data in this way is useful in the end.
25:03
And you can learn more here if you want, more of the details. You can also read more about how I implemented this application. And if you are curious why it took me three years, this is where you can see why. And some takeaways is that offline fares is really nice. I think I'm probably going to do it for most of my apps,
25:22
at least the ones that follow this schema. Sharing is caring. What I mean with this is that hopefully sharing these recipes or using this type of feature inside of a solid app will show people why solid is useful. And maybe without even knowing what solid is, they can realize the power of this.
25:42
Like, look, someone shared with me this URL and then I use the same URL in another app and I can get the data. I think there are very different interactions that we can see here. And finally, keep it simple. This is something I always try to remind myself. I don't always make it, but I think it's important to keep it in mind. Especially with solid,
26:00
because things can get out of hand. But as I said at the beginning, the basic things, GET, POST, RDF, those are the basics. And if you have that in mind, I think you can go a long way with solid. And I still have some challenges. I cannot give you a solution because this is where I am right now.
26:21
So the onboarding, I think it has improved a lot. But still, when people want to connect to the cloud and they see solid, they don't know what that is. So this is one of the challenges. And also, the course issue, if I want to make front-end applications, this is very difficult to get around. So this is some of the challenges I also haven't solved yet.
26:41
And that's it. You can follow my work and use the apps. And if you have any questions, let me know.
27:02
Thank you. It was a wonderful presentation. I'm wondering, when do you think it will be ready to be used in a more mature application? Because just for example, one thing is that you are taking full control of the pod, meaning that I would never share with you
27:20
my credentials of the pod so that you would have access to everything. And if you have any thoughts about the timeline for that? Yeah, so I cannot speak about the timeline because I'm not part of the specification process. So the answer to this would be when the specification includes some mechanisms to do that. And they already have it in mind
27:41
and they aren't working on it. But I cannot give you any answers about the timeline because I'm not involved in that process. What I can tell you is that I know what people who use solid that have this type of concerns, they just have different pods. I have a pod for my private or sensitive information and I have another pod for my public information.
28:03
And this is also nice because you can use the same app with different pods. Like if you are using something for your professional life and then your personal life, you can have it in different pods and that's okay. So yeah, that's my opinion on the topic for now.
28:20
It's something still being worked on. Any more questions? Thank you. Yeah, thank you. Well, it's a bit of a related question, but it's more specific to the type indices.
28:43
So I didn't know about that. I've never used them. So you're saying that they're part of the spec or soon to be part of? The point about type indexes is that they are a different spec made by people who are working on solid. But it's a client spec, which means that from the point of view of the pods,
29:02
it's just a document. So maybe you can call it more a convention than anything else. And the point is that if people start using this convention, then it will become more interoperable in the wild. But it's a convention, you could say, because the pods don't need to implement anything for this to work.
29:20
Yeah, thank you. And so my question was, and this is where it relates to the previous question, so I find it very interesting, but isn't it a bit risky to basically grant the apps to go and mess with the global type indices? It means you can maybe mess up the type indices of someone else or, I mean, shouldn't it be the responsibility of the pod provider
29:42
to build up that type index? Eventually, when it gets into the spec, yes. For example, the solid application interoperability spec, which is also a draft, it does this type of thing in the side of the pods. So yeah, the thing about solid, as I said at the beginning, is that there are many ways to do things
30:00
because the building blocks are basic, but you can combine them in many ways, you know? And the point is that right now, and that's what I'm thinking about when I do this, if you have to build a solid application today, the type index is your best choice because the solid application interoperability requires implementation in the server
30:21
and it's not happening yet. So you cannot rely on that. So type indexes are the best thing we have. You can also choose not to use type indexes, but then it will be even less interoperable. And to me, it's very important that an app is interoperable. Thank you. Yeah, you're welcome. Yes, hello.
30:42
Yes, here. Okay. Yeah, so with MediaKraken, we saw that it can be complicated to fetch a lot of movie and also it's the same if you want to fetch from different pods, it can be very complex. I wanted to know what's your feeling about speed and all that on solid.
31:02
Do you think solid is doomed to be used with really low data app or do you think it's possible to have big data with solid? I think it depends a lot on the use case of the app. For example, for my apps, even if I had perfect querying APIs, I think I would still use this because I found the offline-first approach
31:21
and I like it a lot, you know? But eventually, there is something called Spark UL, which means you can run queries on linked data. These type of things could get into the specification. But again, all of this depends on the specification. And I really don't know when it will happen or if. I mean, I know that people working on the spec,
31:42
they are aware of these issues and they are working on this. But I don't know the timeline, really. I just can say that for my apps at least, this use case, that's what I do, offline-first. And even if I had good querying endpoints, probably I wouldn't use them. But I don't know.
32:00
I guess it depends on the implementation. Yeah, thanks. Yeah. Hi. If you have that offline-first mode with the CRDT, is there a way to do it or there is, but have you looked into doing it in such a way that someone doesn't need to bring their own pod, that they can use their own devices
32:21
and have their devices sync between each other directly? Technically, it would be very easy and very possible because you just have the operations and you just have to do it. Personally, I have not done it in my apps because I'm interested in having easy experiences for users
32:41
and what I am going to tell them if they have to synchronize two devices. Maybe I can use WebRTC or something like this. Yes, but I think they are still devices. I think what they like is the idea of having a cloud and everything is safe in the cloud. And this is also what I personally would do. I don't know if I would want to have only things in devices.
33:04
But to answer your question, yes, it would be very easy to do. I just haven't done it, but it would be very easy. And by the way, well, all of this is open source, so you are welcome to fork it or ask me about the code or anything. I would be happy to help you if you want.
33:26
Rich, I'll get my exercise. RDF and linked data exist for so long
33:42
and we don't see a lot of open source projects unleashing the potential of such a system. Why do you think it's not more mainstream? And do you think there is enough learning material that are easy to understand for developers?
34:02
I cannot answer for everybody because I don't know. But my personal opinion is that in theory RDF is awesome. I like it a lot and this is why I'm working on this. But in practice, the developer experience is not great. And people, when they see Tartel and RDF and all these things,
34:20
they don't like it. So my opinion is that it's because of lack of learning materials and the developer experience to get started. But I don't know. I think if you learn the building blocks, because I learned about RDF four years ago when I learned about solids. I didn't even know about the semantic web.
34:40
But I learned the basic things like the specs I linked at the beginning, RDF and all of this. And I think once you understand those basic things, it's very easy to work with, I think. But I don't know. It depends on that. And there are not a lot of learning materials that I know of. And there is not one framework you can use that is super easy,
35:02
has a very nice developer experience. So I think it's still a thing of tooling and documentation at this point. But this is my personal opinion. I cannot speak for what people, I don't know. Yeah. Can you just tell me about when you stored the pod on a... I just did a quick read of the actual FAQs on the solid website.
35:24
And it seems to be a lot of the details of how the pod providers store the data up to the providers so that options such as encryption is left to them. So that seems to move a lot of the privacy concerns. We have existing cloud services to the pod providers unless you self-help on a server that you encrypt yourself and such.
35:44
So do you have any thoughts on that, on how that works with the provider escape at that moment? So the point is... So the biggest issue today for someone to start using solid is which pod provider to use, basically.
36:02
If I have to recommend a friend of mine to use solid, I don't even know what I would recommend them. But I like the point that users choose. And if you are super worried about privacy and you want everything super encrypted and everything, then you choose a pod provider that encrypts everything.
36:21
But if you don't care so much, then you don't have to. You just self-host something in your home. So I don't know. I think this is part of the flexibility of solid. So it's nice that it's the choice of the user. But I don't have many thoughts about that. Personally I self-host and I don't mind about encryption.
36:43
I'd like to ask you how to find vocabularies because I know there are a lot of vocabularies, but it's quite a cause. They are very difficult to find and to understand. So at first I also worried a lot about this,
37:01
but now it's like the least of my problems because really you just search. If there is one that already exists, like in this website I shared, there is a website with a lot of vocabularies. Just search one. And if you don't find one that works for you, you create your own. And it's not so difficult.
37:20
I think at first I understand how it's confusing, but once you decide that you can make your own vocabulary, it's not so difficult. Also I recommend a lot this talk I linked called Bag of Chips. This is the one that changed my mind about this, that it's fine to mix vocabularies and make your own.
37:41
So I recommend watching that. Given that you've got different pod providers and you can never be sure what the infrastructure that you're working with is going to be like, it could be a very slow pod provider or whatever, do you have to design your apps quite defensively
38:01
because you can never be sure that actually the pod provider is actually going to be able to service the HTTP request that you want to make? My answer to that is that no, because you just follow the solid protocol and that's it. I mean, if the pod provider is slow, users will be unhappy and they will use another pod provider.
38:22
So I don't worry about that. I just code to the solid spec, and I don't mind about that. The only thing is things that are not in the spec yet, and they are drafts, and different pod providers implement differently, but hopefully when the spec is more stable, this will not be an issue.
38:41
Hi, thanks for the great presentation. All your examples were single user applications. How would you apply the philosophy of solid to, let's say, for example, forum software? Would you either store all posts from all users in their own pods and somehow get access to all those pods, or would you just not use it for that
39:02
and just use it, for example, for public information on the user? Yeah, so I haven't done anything about that, so I'm only going to say what I think about it. But basically, my intuition tells me that it would be something very similar to activity path, which is the protocol that powers Mastodon and the Fediverse.
39:20
And underneath it, it also uses linked data. So I think it would be very similar to that, the way it works, and I don't know exactly how it works. I have not coded activity applications, but I think the information is duplicated in the server for something. I guess it would be something like that. I don't know, but I think my answer
39:41
to thinking about social applications with solid is look at activity path, because it's the same idea, I think, or similar at least. Just as an FYI, there's also an active discussion going on in the matrix room associated with this dev room, so you might want to look there.
40:01
I will take a look and answer. Well, also, you guys might want to check it out. Well, so that's it, I guess. Thank you, everybody. Okay.