And let's welcome the next show from zero to here of the solid.
Thanks Noel for presenting.
Okay.
Thank you.
So, my name is Noel, I'm from Barcelona, I'm currently working at Moodle for days
a week, 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.
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,
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 is 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, 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, Tartel, etc.
We will see more about this later.
And finally, the solid protocol, it's the next iteration of this idea and it brings the
centralized 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.
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 a, here on the left, we have the traditional architecture.
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.
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 Fosnum 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.
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, 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 random site project to try technology.
My end goal is to actually make useful apps.
And also, it will be road strokes because I cannot get into many of the details, but
we will get into some of the widths.
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.
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.
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 of line 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.
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.
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.
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.
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, and a don.
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.
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, 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, this would be like the class of the object.
And then you have other properties, which can be just literals, or there can be links
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.
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.
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.
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.
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.
So what I mentioned before, that the ID says where the data is stored, if we look at the
ID 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.
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.
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 this request will be the data in turtle format.
It can also be in other formats if you want, but most of the time you will be using turtle.
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, and so on and so forth.
The basic idea is that it works like the web, because it's built from those technologies.
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, 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 width with some things, and here
you have my journal when I explained how I learned solid.
This is the first time I saw solid, so it may be more interesting to some of you.
Some takeaways.
We learned the solid basics, and something that maybe was unobvious is that there is
no server.
You make the application, and the application works in the frontend, because the data will
be stored in the solid pod, right?
So this is nice because you don't have to manage any servers, and you are only building
frontend 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, 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?
You can see how you can filter the movies, et cetera.
So in this case, this is how the login looks like.
In philosophy, it's very similar to the other one, but it improved a little bit because at
least I explained what is solid, and I helped users a little bit if they don't understand
what to do.
But also, once you are inside of the application, you can export the data, and it will be exported
as 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.
The other issue about the page speed, also maybe this was an obvious, but when you do
a great 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.
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 1 requests, right?
In case you are wondering, why would you get all the movies?
Like, why don't you get just the 10 first movies and you do pagination, right?
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.
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 make, I open the application, I can look at the last modified
date of each one of the documents.
And only request the new ones.
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?
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 are now.
The power of solid is that you use different applications and they use your data, right?
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 vocabulary that are already used and you
can see which ones are the most popular.
So they are the most likely to be more useful, right?
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, but now that I've learned more,
I think mixing and matching vocabularies is actually okay.
So you shouldn't be taking a back 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, 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.
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, 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, 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?
Okay, so 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?
In this case, something that I think it's very important to do with solid apps is to
reliance 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, 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.
Some takeaways, type indexes are nice, I encourage you to use them, and also that catching
is nice.
It improves the performance a lot, 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 Umai.
I don't want you 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,
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, Umai is a recipes manager, so the point is that you have a collection
of recipes, and you can search them and browse them.
So Inspirit is quite similar to Media Kraken, 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 free recipe.
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, you
know?
But if they just create a free recipe, they can just go ahead and do it without worrying
about solid or any technical aspects, right?
Then when they start using the application, 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,
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, you should then store the authentication
token in the frontend, and if you want to see the details why, you can read this for
a 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.
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.
I only synchronize manually whenever I want to, right?
This is the basic idea.
And the second thing, this will get a bit into the width 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 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 they change it and 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.
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.
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, 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.
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 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 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?
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, 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.
And the nice thing is that this is actually semantic data.
So this is what I mentioned while at the beginning.
And many websites are already using this website 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 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 leaves 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.
But depending 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.
So yeah, 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, 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 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, 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.
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 first is really nice.
I think I'm probably going to do it for most of my apps, 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.
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
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 the solution because this is where I am right now.
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.
And that's it.
You can follow my work and use the apps, and if you have any questions, let me know.
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 my credential of the pod so that you would have access to
everything.
And if you have any thoughts about a 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 and they are working on it.
But I cannot give you any answers about the timeline because I'm not involved in that
process.
What I want to tell you is that I know what people who use Solit that have these 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.
And this is also nice because you can use the same app with different pods.
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.
It's something still being worked on.
Yeah.
Any more questions?
Okay.
Thank you.
Yeah.
Thank you.
Well, it's a bit of a related question but it's more specific to the type indices.
So I didn't know about that.
I've never used them.
So you're saying that it's 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 Solit but it's a client spec which means that from the point of view of the pods
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.
Yeah.
But it's a convention, you could say, because the pods don't need to implement anything
for this to work.
Yeah.
Thank you.
And so my question was, and this is where it relates to the previous question, is, 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 with someone else or I mean, shouldn't it be
the responsibility of the pod provider to build up that type index?
Eventually, when it gets into the spec, yes, for example, the Solit application interoperability
spec, which is also a draft, it does this type of thing in the site of the pod.
So yeah, the thing about Solit, as I said at the beginning, is that there are many ways
to do things 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 Solit application today, the type index is your best choice because
the Solit application interoperability requires implementation in the server 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.
Yeah, you're welcome.
Yes, hello, yes, here.
Okay.
Yeah, so with Media Kraken, 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 pod, it can be very complex.
I wanted to know what you're feeling about like speed and all that on Solit or do you
think like Solit is doomed to be used with really low data app or do you think it's possible
to have big data with Solit?
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 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 these 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, 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 query endpoints, probably I wouldn't use them, but I don't know.
I guess it depends on the implementation.
Thanks.
Yeah.
Hi.
If you have that offline first mode with a 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 and have their devices sync between each other
directly?
Yeah.
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 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.
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.
Yeah.
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.
I'll get my exercise.
RDF and link data exist for so long 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?
Yeah.
So 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 am working on this.
But in practice, the developer experience is not great and people when they see Tartel
and RDF and all these things, they don't like it.
So my opinion is that it's because 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 SOLID, I didn't even know about the semantic web.
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 like not one framework you can use that it's super easy, 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 can't speak for what people, that's my, I don't know.
Yeah, can you just tell me about the, when you stored the pod on a, I'm just, I just
could do a quick read of the actual FAQs on the SOLID website.
And it does, it's easily a lot of the details of how the pod providers store the data up
to the provider so that options such as encryption is left to them.
So that seems to like move a lot of the privacy concerns.
We have existing cloud services to the pod providers, unless you self-help stun a server
that you encrypt yourself and such.
So do you have any like thoughts on that, on how that works with the provider escape
at that moment?
Yeah, so the point is, so the biggest issue today for someone to start using SOLID is
which pod provider to use.
Basically, 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.
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, 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.
I'd like to ask you how to find vocabularies, because I know there are a lot of vocabularies,
but it's quite a chaos.
They're very difficult to find and to understand what the words are.
So at first I also worried a lot about this, 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 search, if you don't find one that works for you, you
create your own and it's not so difficult.
I think it's, at first I understand how it's confusing, but once you decide that you can
make your own vocabularies, it's not so difficult.
Also I recommend a lot this talk I linked called a bag of chips.
This is the one that changed my mind about this, that it's fine to mix vocabularies and
make your own.
So I recommend watching that.
Yeah.
Hi there.
Given that you've got different pod providers and you can never be sure like 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 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?
Yeah.
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.
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.
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 and just use it, for example, for public information
on the user?
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
pub, which is the protocol that powers Mastodon and the Fediverse, and underneath 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
servers or something.
I guess it would be something like that.
I don't know, but I think my answer to thinking about social applications with solid is look
at activity pub, 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 death room.
So you might want to look there, there's also the data.
I will take a look and answer, but also you guys might want to check it out.
Yeah.
Well, so that's it, I guess.
Thank you, everybody.
Thank you.
Okay.
Come on.
Let me see.
Okay.