We are ready to start and now let me welcome Jaldano, who we talk about
serdities and to an encryption, permissions and jazz.
Let's welcome him with a round of applause.
Thank you very much.
So thank you for the interview, my name is Geo, I'm a software engineer, I've got
a garden computing.
As you mentioned today we will talk a bit about serdities and to an encryption and
our jazz does permissions.
Before we start, I would like again to take a moment to recognize or acknowledge one of
maybe one of the main reasons we are all here today.
How many of you have read this paper?
Of course.
Well, if you haven't, I highly suggest that you do, that this is a literally gold mine.
To me, what I found especially interesting about it, aside from all the technicalities which
are of course interesting was a simple but I think very powerful idea.
What is your up, work offline, sick magically, when connected and you, in all of these,
rating control of your data?
And yes, I know it's 26, like we have 5G everywhere, but also, I don't know if you heard
last year, guess where I live?
So, yeah, if you don't know, we had a power outage in Southern Europe that lasted for a couple
of days and everything went nuts.
So let's talk about the real problem here.
Imagine we have two people, let's call them Bob and Linda.
They want to work on something together.
Both of them are offline because reasons.
Now Bob starts saying, the gut is blue.
A few moments later, Linda comes in and says, the gut is yellow.
So, now, what color is the gut?
No, it's yellow.
No, look aside, the thing is that with additional approaches, like Nico was mentioning,
there's not really any rule to define the behavior.
The most common one is, let's say, our last, right, right, right, our wind's approach.
Basically, your state, well, this is also the most common for complex data types.
Basically, your state, it's effectively whatever comes last to your server.
So in that case, Linda State will have one other, other, other Bob.
The thing is that in this case, the state was whatever the server came last.
So if Linda and Bob took each other directly, each one will have had the state of the other.
If that was just the basic rule.
And yeah, and you have to let us, because you seem to don't know which, which, where is the truth at the end.
Another solution could be starting to do a lot of computer solution.
You know, you are where you get these models or pop-ups saying, oh, this is the red, it's those are your red, it's, and the user picks what should be the, the final state or correct state.
They don't, on the side of this is that, I think, can never hear anyone saying, I love the solving merge conflicts.
So I don't, I don't know if any of you do does, but never heard of one of anyone.
And then, let's not approach could be in the traditional term resource logging.
So one person, like, only a single person can edit or touch our source or modify it at any given time.
But that could, it's collaboration.
So that was one of the main things I liked about the paper, which was allowing people to work on data also while offline,
red and in control over the data.
And plus, like, I don't really understand how people can really collaborate or, like, communicate and get a lot of,
if they're both offline, I cannot communicate.
So yeah, in this case, the cut is basically that collaboration is over, we don't have anything.
So, and this is where serity is coming.
Now, how many of you knows what a serity is?
Okay, let's say, half of us, that's good.
Okay, a serity, so serity stands for conflict-free, replicated data type.
And there are data structures that are mathematically designed to merge without conflicts.
And the key inside here is mathematical.
In a sense, that it's not on a best step, best effort, Bayesian, or it's not a restricts.
They are mathematically ensured to be, to merge conflict-free.
Let's look at, over-singplified, practical example.
This is kind of web-coded, a web-coded serity.
And it's a counter.
As you can see, when we construct these data structure,
we initialize with our node ID, so it's ourselves with our own counter zero.
And then we can increment by adding whatever number we want to our own state.
Then we can merge with other people's state.
So in that sense, then we keep track of others, other changes over other peers that we sync with.
And at the end, the final value, it's always going to be the sum of all peers' counters.
And these ensures that eventually, when everyone sync their data with each other,
the final state will converge to the same one for everyone.
Quoting the log of first paper, we are not trying to resolve conflicts with these approaches.
We are designing them away, and the main point here is eventual consistency.
So in our case, with a well-designed serity, let's say one that mixes colors.
All changes are persisted, they're preserved, and they're merged sensibly, according to our own logic.
Everyone is happy, cut this green, and everyone lost their work.
I mean, this conception here is that when I talk to people about managing all sorts of things kind of conflicts or the work of everyone is preserved,
they tend to think about it as a, like if everyone works is preserved in the history of the change.
There are some implementation, some libraries that also retain the history of changes, so you can do time travel or get edits over time.
But that's not an intrinsic property of serity, like what they do is literally only having a consistent final state, which is mathematically probable.
And there is also, for me, at least, a useful mental model to think about them, which is, I think about serity as local state with superpowers.
If you're familiar with React or, I guess, any other front and library really, you know, you state.
So basically, you have these local state that you can update and react then for you updates the UI.
When I think about serity, since serity is, I think about the same thing, so updating local state, which then triggers the renders.
But at the same time, syncing them to their devices, so that the same state changes happen for every one of the same time or when the sync.
So it's local first, in the most pure way, let's say, like it's, you write on to local state and you get instant feedback.
In jets, we do this by swapping out, you state, we use co-state and co-stents for co-value or collaborative values, which is our own primitive for synced serity, let's say.
And with this, we get magical synced state across multiple clients.
And these, basically, changes the work texture, because in addition to client server architecture, we have our server, old-ingled the logic called the business logic called the validations.
And clients are just teen view layers that just present data.
These, as a few disadvantages, like, first of all, you need to go over the network to do any update, and that creates lower UI, and it's a bit frustrating.
Like, we know how you guys can feel bad when the network is low.
And second, they are not available offline, like your server is down, there is no way you can make those requests.
Most importantly, because your server holds the logic, so it's not on your client.
With local first, on the other hand, we shift all the logic and permissions to the clients.
They hold authority to the state, they hold all the logic, and they do the violations, they do everything themselves.
And the middle part, the middle part is just optionally a sync and storage layer, so that can persist data long term for cashing or for whatever reason.
But it's not alternative, so the state's authorities are still all the clients.
And yeah, with this inversion, the good thing is that servers or your infrastructure becomes a commodity.
And in fact, if the sync server is that dumb, you don't really need to have one.
You can just technically sync between clients, between each other, without needing to rely on a central authority.
Or someone that sings data for you.
And this, as Nico mentioned before, gives us an amazing benefit.
First of all, users control their data.
They are authorities over their data, and they own it.
And most importantly, for me at least, as a frontend person, maybe, is that operations are easy.
You're effectively updating local state.
So every variety, every state changes is done because it's on local disk, it's on local, it's on memory.
And then there is something else sinking to somewhere else.
But the thing happens locally, and it's faster.
And then, yeah.
No, that's not true. No, they're all fine first by default.
So that's not what they're going to get with local first, most of the times.
There is an issue though, which is kind of the elephant in the room when talking about local first applications.
Other stop users from doing nested things, like they own the data.
Other, we prevent people from reading data that shouldn't read or writing or modifying data that shouldn't be able to.
In traditional context, you know, the server is the gatekeeper.
So they said they did it there, it does the validation, you on the server, you can perform checks.
But the thing is that we just wanted to limit servers. We took them off the equation.
So how do we, how do we enforce this? How do we make sure that no one does bad things?
There are few approaches, which are maybe two naive.
We can just check on the clients.
So we can implement our apps to check local state and see.
And so your code can check if you should show the users the actual state.
But I mean, clients can be modified.
So everyone can open your dev tools, change your code, and then access to data or modify it.
But if I think that they, the shouldn't.
Second approach is having the SERP server.
So we're seeing infrastructure by the data changes before forwarding updates to the clients.
The issue here is that we need smart server again at this point, because we need to copy the logic of the clients on the server,
or on the sync servers to check which data can be seen to which client.
And it also so we need to copy validation logic, permission checks.
So we are just reinventing a traditional backend.
Third approach is just don't sync everything.
So I have only the sync server getting all the data, but then just check for permissions at the very end.
But again, still we need custom logic and we lose the magic of strategies.
Other ways of this, jets does these.
We are trying to tackle this problem with we do with cryptography.
Sorry, give me a second.
So we use cryptographic primitives to enforce permissions in a three distributed way.
Now, jets is not exactly.
I mean, it is to some extent, but it's not exactly a full CRDT.
But we have some similar properties and we decided to have other trade-offs.
So let's see how it works.
We have linda.
If we have performing rolling ashes over their updates.
And then at the end sign a lot of the stage, ush with the skin author.
We can verify effectively that she was the one making those edits.
Now, Bob can do the same.
And this way we have a verifiable and independent verifiable list of transaction in jets and a final state.
Now, in order to give people write permissions, we can store the information inside a group in jets.
Which is just another covalu or another come up.
So this way we know in the group, we chooseer can modify things inside this state.
On the other hand, everything we need to give reduxes to people is instead of ushing those edits in plain text.
We can just encrypt them and do rolling ashes over those encrypted changes.
And store the keys and give the keys to user that needs to read data.
Where do we store the keys? Again, same covalu.
So same group which has which have keys.
At this point doing permission changes just means changing those keys in that group.
And revealing the keys to the right people.
So this is actually a very simplified version of how jets works.
There are some more things under the hood.
If they are interested, please contact us.
We'll have to give you more insights.
But the nice thing I think is that in this model, the things are very completely oblivious to your approach.
Because it only needs to pass data round to pass difts around within each client.
And in fact, it only needs to pass down encrypted difts.
So it's a completely transparent component from your infrastructure.
And so for instance, if you use jets cloud to do all of your things server,
you don't have to trust us with your data.
And nor your user need to trust you if you want to self-host the things server.
So user effectively have control over their data.
Now, that's another point.
Yeah, it's so client, but yeah, I need to send the emails.
How do we do that?
Well, that's the only problem here is that what if you have some business logic that you don't want to expose to clients,
but you want to all of them in a trusted environment?
Again, quoting the log of the paper, there is no cloud for us, at least in jets, is just another client.
And this is an experience, a bit, a confusion point when it'll come back again first,
which is that we are so used to traditional client server model,
then whenever we think about something not running on our client, we assume it's a server.
In fact, while most apps can just work like this and be fine,
workers and server workers are just other clients.
So, just to give a quick example, this is how we do permissions in jets,
or like we do the fine scheme as in jets.
We can see how we can define an ownership for our cat, for in this case, Linda,
and our Bob can update the cat, given she had permission from, given to him from Linda.
And yeah, that's it.
Thank you very much.
And I think right.
Yes, we will now take questions.
If there are in the room or in the chat, no, in the chat.
So, please raise your hand if you want the mic.
Yeah, you.
Thank you.
It's really cool.
I was wondering about the role of these servers that basically act as some sort of,
you know, middleman sometimes, if you want to.
Okay.
So, how do you decide which, like, what servers actually store?
Are these servers completely public?
Can anyone, because they only received encrypted things?
Yeah.
Or do they have a white list of allowed agents or something like that?
So, in our own implementation, like, we have a set of
sync servers around the world, as a different, different
edges that couldn't communicate with each other.
And they're public.
So, in our sense, anyone can read them right from those, from those
sync servers.
The thing is that you can only write your data and read the data you have access to.
Even if, you know, everyone is running to the same database.
There is no issue, because you can only get the data you will.
You can technically maybe get encrypted data, but you will not able to access.
You will not be able to access it.
Of course, then, if you want to self-host it, you can do additional checks.
You know, to allow your clients to think to that, to your sync server.
Because you don't want to people to free boot your sync server.
In theory, they can be open.
Thank you.
Are there a question in the room?
We have two.
Here.
Is there an easy way to compact the logs of operations?
So, we don't do it yet.
We are exploring ideas on how to do it.
I cannot answer you.
I don't give you the solution, because we don't get yet there yet.
But in theory, what we want to do is compacting those stages.
Because one issue of this approach is that then there is a big chance to grow a lot of our time.
So, yeah, that's very exciting that I do.
Thanks.
That was a really great introduction.
Thank you very much.
I just started the day.
I apologize to you, but this is actually a comment.
Which is, I just wanted to clarify that we didn't write.
There is no cloud.
It's just somebody else's computer.
I believe it was Chris Waterston, who created the bumper sticker.
Okay.
So, just making sure credit goes where it's due.
Okay.
So, I'm talking to that wherever you are.
Sorry about that.
No, it's a quite alright.
But I just want to make sure we give appropriate credit.
Okay.
Thank you.
Thank you for the talk.
How is the time synchronized?
Because those hashes are depend on time, on time.
And it must be synchronized on clients.
So, is it solved or is it depends on synchronization?
Yeah, that's one of the trade-offs we made.
Right now, jazz is based on work clock.
So, it's not really synchronized.
Sorry?
On the other side?
Yeah, yeah, exactly.
It's on the clock on the device of the user.
So, we made this trade-off.
It's not ideal.
There are maybe a better solution.
We'll be exploring them in the future.
We already have started doing some work.
But yeah, for now it's work clock on the client.
And looking at the user layer.
So, specifically, there was a user preference.
Right?
Of like, how is this disagreement reconciled?
In this case, there was a choice of color combination.
Right?
And I'm curious about what frameworks there are.
Because what I'm seeing from the user is that there are sometimes disagreements.
Essentially, like, okay, that as an organization, for example,
we now need to reconcile.
I'm curious about frameworks for that.
So, in jazz, if you feel good about jazz,
we don't, like, in jazz, especially, we decided,
we found out that last variety of wins is what we,
what users need, 95% of the time.
So, what we do is just keep the, like, last,
the last that it wins over the others.
But, we also keep the wall history of edits.
So, in our case, you can implement your own logic on top of this story,
rather than accepting our default view.
Other frameworks do things a bit differently.
I don't know the world context to be honest here.
But, yeah, like, in jazz, you can, no, it's not easy right now.
Like, the framework doesn't really support it out of the box.
But, you could do that.
You can do, you can implement your own resolution logic.
Great. I think we ran out of time.
We had a very good question.
Thank you. Y'all, I know for this amazing time.
Thank you very much.
Thank you.