Go ahead and introduce you to Nico.
Nico is the founder of NextCraft.org and an engineer specializing in encryption and local
first software.
He's going to be taking us on a technical dive into NextCraft, which is a local first platform
and STK built in Russ that enables secure decentralized app development without reliance
on DNS or central servers.
So with that, I believe you're set up.
Yeah, I'm on that.
Yep.
All right.
So with that, I'm going to hand over Nico.
Let's welcome Nico, everyone.
Hello, everybody.
So I'm Nico, author of NextCraft.
For those who are switching rooms and that work in the local first room before,
you will have a repeat of 10 minutes and then inside the line.
Okay.
So then, I was saying, and then the next 10 minutes will be deep dive into encryption
and yeah, encryption, the sync protocol that I think you will like.
So I started NextCraft three years ago.
We have the support of FNLNet and GI funds and the European Commission.
We'll tell you a small story about data.
It starts with, where is my data today?
I'm not asking you, but in general, all the others.
It's here.
And that's a problem.
For this reason, we have tons of accounts.
No access to the raw data that we don't have access.
It's there and maybe they give us an API, maybe not.
And we have everything is in plaintext in their cloud.
So, we have open source alternatives.
Great.
Now, same.
Billions of accounts.
In compatible APIs and data formats, nothing works together well.
And the same plaintext in their servers.
So it's cool.
Season means right.
We might trust them, but still, if there is a leak.
I don't want them to have my data.
I want my data.
I want all of my data and I want all my data in one place.
It's so I can control it.
And I have ownership.
A sense of ownership.
A availability.
If there is no internet, I still have it.
Security and privacy are just mentioned.
And I can share and collaborate if I want to.
And not to share it with the NSA, by example.
I want a several place for all my data with an encryption
that we solved the previous problems.
Once it is and when encrypted, the server is useless.
Almost.
Right?
It's just doing store and forward of encrypted blocks of data.
Why do I still have a server?
Some people like Iro or others, they do peer-to-peer.
I have my device connected to another device directly.
And we'll change like that.
We don't do that because we showed that it's hard to find
some other device connected at the exact same moment.
So that's we can change.
It's better to pass with a relay that we call the broker.
And that is in between to help with the transfer of the
encrypted data.
Store and forward.
And okay, local first and CRDT.
So there is the devroom of local first.
Maybe some of you were there.
Local first.
It means that you have the data on your device,
primarily on your device.
And if you don't have internet, it still works.
That's the idea.
CRDT is who knows?
CRDT is.
Oh, it's cool.
So I have not to explain it.
I don't have the time anyway.
But it's this data types.
It's a format that avoids conflicts.
If I change the data and you change it,
but we are not connected.
We are not online at this time.
There is no coordination.
Then we are back online.
We bring the data together.
And there is no conflict.
It's not good.
There is no mesh conflict.
There is no need to do something.
It just works.
There is math behind it.
It's not just just.
But it works.
Then it works good for things.
Some domains.
It works for others.
We don't know yet.
But if you want to know more about CRDT,
you go to those websites that have a lot of resources.
Now, I will show you a bit.
What I was saying before,
Antoine encryption.
What does it mean?
I have the brokers that are the servers that are in red
because they have only encrypted data.
They can't see anything.
So once it's like that,
only the devices are in green and they can decrypt.
Encrypt decrypt.
And then because it's CRDT,
we say the materialize the state.
Because the CRDT, it's a bit like a log.
You have a log of operations.
That's I add this, remove that,
add this character, move it there, whatever.
So we need to process all these operations.
And reconstruct the final document.
The current state of the document.
So we call that materialization of the state.
So if you don't store that locally,
you have to rematerialize every time.
Which is costly.
So look at first, we also store it locally.
And with next half, we store it.
Encrypted at rest.
So that's not the same as the Antoine encryption.
So we re-encrypt at rest.
It's just symmetric encryption.
But that's important, I think, too,
because devices, you never know what happens with them.
So I was coming back to my story of the data.
I want this central place with all my data.
How many servers?
We need it for that.
I say a federation.
We have your server, their servers,
and they talk to each other.
We have a pub sub in X-half.
And we imagine one day that you'll have all the brokers in black.
And all the end user devices in orange.
The colors might change.
But I want a central place.
How many server federation synced in a pub sub?
I said it.
Now, the replication of all the data in all my devices.
This is important.
I can choose also if I want it on this device or all the devices.
This is not ready, but it will be one day.
The data replicates on all my devices.
This is the first thing.
Then there's collaboration between different users.
And the documents.
And the data is also replicated on the brokers.
And if you are not connected with the pub sub,
the brokers remembers what are the documents that you are interested in.
So even if you are not online,
it will continue to gather the blocks and bits of data,
the new things, the dates.
And once you connect, you get all the new things at once.
So that's also cool.
Now, full decentralization, right?
When you are in such a paradigm, so we have a full decentralization,
because also we don't depend on DNS.
Everything is IP based.
We want the devices, the brokers, to be hosted at home.
For example, in a small box,
you don't want to have to set up a DNS just for that.
Though, where are we?
I want to completely decentralize central place for all my data.
And that's next graph.
Why do I central of all my data is there?
Now, I'm going to go on the stack and step by step above on the stack.
The protocol above that is specialized for synchronizing CRDTs.
And to end and cryptate CRDTs.
And in the second part, I will explain how.
I can't sync any kind of CRDTs.
So we have several CRDTs.
And anyone, any CRDT could do, could work on this protocol.
We already have three.
You will see that later.
Then we use for access control permissions.
We use capabilities.
Not are in fact cryptographic, similar, like signatures,
or if you want certificates.
And if you don't have this key, this private key,
or symmetric key, depends for writing.
It's asymmetric.
And for reading, it's symmetric key.
OK.
So if you don't have it, you can't open the documents at all.
Right?
So that's a capability.
It's not ACL.
Then we have, I was there already.
We used this.
It's a scheme.
Like you have HTTP, FTP.
You have DID, column.
And then you can do what you want.
With sub name for your own.
It's called a method.
And G for next graph.
And then there, we put what we want.
We put public keys to identify users and documents.
Each document gets a deal.
And that's it's very stable.
Never changes.
That the document moved from one block after another.
From an account to another.
You share it.
It's the same did.
It's never going to change.
So it's not a content addressing, by example.
Because that changes every time you change the document.
That's very important to have a stable ID.
And not connected to domain either.
So we know the problems associated with domains for identifying resources.
Right?
I'm sure you know.
So then we have in the protocol.
I upload and download of binary files.
This is basic.
We have to have it.
We're streaming content addressing this time.
Because this is immutable.
So it's okay.
And then a chunking.
We like a bit around.
Now what are the strategies that we support for documents?
It's document based.
YGS, auto merge.
And the third one are the F that you never heard of.
I'm sure.
So YGS is known.
Auto merge also.
They do JSON like data.
It's maps and arrays.
And RDF is a graph format.
So I like graphs.
And that's maybe why I call it next graph.
And I find it cool to store data.
And also to link data between documents between users.
So your database that is local to your devices is in fact connected to other databases.
Because we have identifiers that are globally unique.
Where are we on that next slide?
RDF, right?
It's called Sparkle is the query language.
It's similar to SQL.
Data log also is very similar.
If you heard of that log.
And then we call it link data.
It's a standout.
And you need the records.
Like in SQL it's okay.
You have a row with the columns.
Here you can only have three columns.
Always.
That's why we call them triples.
And that's small.
The smallest unit of data that you can store.
I'm not going to dig into it now.
And then it brings interoperability.
Because you can have schemas that are adopted by.
We call them ontologies that describe this through RDF, the format.
We can have interoperability between different apps.
And the user remains in control.
Because the data is the user owns the data and can change the apps.
It's not happy with the app.
It changes.
That's valuable software.
You can compose apps.
But your data remains the same.
Now this is an example.
Very schematic of RDF.
When you connect data items.
We key data.
My example is based on RDF.
They extract the data from Wikipedia.
And you can query it in Sparkle.
We have also all the social networks.
It's the graph.
Database for sure.
So that you can query it.
But they have bigger databases.
For us it's different.
It's decentralized.
Now the linking between the documentation and the data base.
Local database.
That has automatic joins.
You don't need to think about the primary.
Forenkeys and to join your tables.
Because all these three pairs are joinable by default.
That's cool.
Clearly this I said.
And team honestly.
Okay.
Hello.
So next graph.
Engine is sync protocol.
CRDT.
Agnostic.
Graph database and encryption address.
Now the SDK.
We can do apps with next graph.
Of course.
Web.
Web apps.
It's rust compiled.
In native.
It's rust compiled to binary code.
And but we still web view.
We like to do everything in web technology.
For now.
But the future is open.
We could do TTTK or what we want.
But the engine is all in rust.
And then we have bindings for Python and type script.
When you do native apps.
So it's then with same tutorial.
This is not as we have all this platform supported.
And this language is.
So.
The SDK is composed of two APIs.
Two level of APIs.
You have the the raw APIs lower.
It's a you subscribe to a document.
Or two several documents.
You receive the dates.
You send the dates.
And these updates are of the form of a CRDT of dates.
It's a binary blob.
Most of the time for YGS and auto merge.
You don't really know what's inside.
And.
For our DF it's going to be trippers.
But trippers also you might not really know what it means.
But for in some cases you need that.
If you're going to use post mirror.
For example, you want native APIs.
But on top of that, we made an OEM.
So that you can manipulate the data.
Like type script object.
There are types of boxes.
You know, and you can just do.
Object dot title.
Equal.
And it's reactive.
We have signals.
And selective to react as well.
And view for now.
The font and frameworks.
But we could add more like a.
Solid.
Solid GSM things like that.
It's.
Wouldn't be difficult now that we did all of the work for the others.
The main ones.
Those.
So on top of that, we have a framework.
It's a bit different than the SDK.
The framework gives you features.
Functionalities.
That the other apps that developers want.
Right.
They want to develop again and again.
And that they just want to use.
So history.
We have that already.
It's the.
It's the log of of all the operations that are signed.
So we have a authenticity of all the commis.
Like a bit like a block chain.
You know, say that it.
You have a proof.
And you have no detail.
And you can't change it.
It's immutable.
That's immutable.
All the history you can't change it.
And the dates of the past are linked to the present.
So it's.
Well, it's the history.
And you can time travel.
You can go back in time.
Commission.
Okay.
I talked about it.
I'm not going to dive in so much into it.
Then we have search locally.
Local search.
Always everything local.
Sparkle the query engine local.
And the reactive queries.
The IBM.
We don't have it yet.
It's the when you start a query.
You get some results.
And the data changes afterwards.
And then your results change.
Consequently.
And that's super cool.
Especially when you are doing everything reactive and local first and everything.
But we are working on it.
We'll have it in around six months from now.
Then we have.
We want to add.
This is not ready.
Comments chat and notification.
But this is basic, right?
And the store.
We have it the wallet.
We have it.
We wouldn't work without it.
The wallet.
It's not like.
It's not a cryptocurrency.
It's just a small file where you have some keys stored there and is protected by a password.
You know.
And it's local.
We never have to connect to anything to use this wallet.
And the app store is because we want you to make apps.
And then we will be able to install.
Right?
Through the.
The system.
So.
Where I mean this is also for after.
So I'm basic assets transaction is good to say that we don't have it.
That's everything.
Even.
A bunch of consistent.
For now.
This is a principle of realities.
But we want to add it because when you do e-commerce.
When you do.
You want to vote double spend.
When.
It's needed.
Right?
So we will add it with pixels.
Basically.
And the coordination.
Then you need internet.
But.
Yes.
A trade of.
It's good to.
Bring it into the framework for those.
We need it.
Some apps that have been done with this ecosystem.
Do clearly mean me who you can check it.
On my website.
Different types of apps services.
You can do services.
And then.
A nice announcement that we are going to do a suite of apps that is.
Supposed to replace.
Google.
Workspace or something like that.
Local first.
And when I crypt it.
And based on the next half.
And we have.
Yeah, a good team.
A good consortium.
And they will be also subgranting for those who want to contribute.
And help us.
Through an internet.
If you know in a net.
You know what I mean.
Then I recap.
The stack.
The open platform with the brokers.
That can be hosted anywhere.
Then on top the photo and the engine.
And there is the framework and the ecosystem.
And those are the properties of this whole ecosystem and the framework.
I'm not going to dig into that.
You understood me.
What is not done.
What we will do this year.
We are still in alpha.
It's about performances.
About the toy plugin.
Because for now.
There is only available on the web.
To make web apps.
But it's the same code.
You code your app once.
The same API.
And then it just works in toy too.
We do it.
I use it.
But I didn't make it so easy for you to do the same.
You would have to fork or an extra thought.
I will do that.
And then the app store.
And improve the framework.
And implement the core protocol.
Because we don't have it implemented.
Which is the one that talks between the brokers.
For now.
I'm just using one broker.
And everybody forgives me.
But it's because I don't have so much time.
I don't have so much time to do everything all at once.
Now those are sparkling.
How much am I?
I moved time.
8 minutes.
8 minutes is good.
So here we have this.
You can read like me.
I can not talk anymore.
So we have this store.
The concept of a store is.
It's a bunch of documents together.
So I have the private one, which is only for me.
It synchronizes between my devices.
But that's where it stops.
Then I have protected one where I can share with other users.
I decided which one was permissions.
And then the public one is for everyone.
You don't need to have an account or anything to access.
Then you can create more of those for groups.
When you put your friends in it and everything.
OK.
This is already said.
Now let's go to the meet of the thing.
Because there is five minutes for questions after.
Right?
It's after the six minutes.
Seven minutes.
I think it's OK.
I will stop very soon if you have questions.
Let me know.
So I can stop.
So what is that?
That's how it works internally.
See, that's the part you will like the most.
So we have a plain text.
It's here.
Whatever graph.
The date.
The data.
We trunk it.
In the maximum one megabyte.
Then each chunk is.
We make a hash of the plain text.
And it's a keyed hash.
Because you will understand that this is convergent and encryption.
Which is a subject subject to the confirmation of file attack.
So we don't want people to try to understand.
If you have a file on your.
This car.
So we.
And the keying is a one big complex but it works.
Then we have the hash of the plain text.
That becomes the encryption key.
The symmetric encryption key.
So we encrypt this chunk with the key.
And that becomes the cipher text.
Right?
And then we hash the cipher text.
And that becomes the ID of this block of this chunk.
The same.
So we have a.
A pair of information, which is the block ID.
And the same symmetric key.
The symmetric key is here.
The block ID is there.
And with that, I can retrieve the data from the broker by example.
I identify the data.
The block.
And then I can decrease.
Right?
So we call that a reference.
Now, when you have many chunks.
You put all of that into a.
That I just so before I.
I'll explain you.
So I don't need to do it.
Right?
Then it's good because I didn't plan to do it.
Anyway.
So.
There's something going on with the slides.
Anyway, this slide is good.
So I will explain that.
Now what we have that when we have this.
This blocks.
And this was just one operation.
Let's say a big one.
Ah, now it's coming back.
Okay.
So we have.
Ah, yeah.
There is this slide in the middle.
And then there is the other one.
No.
It's going back.
Anyway.
A bit annoying.
So we have.
I will explain it anyway.
We have a.
So then once we have all this operation one after another.
Here we are.
So this is one of them.
I say root commit is the first when you create the document.
You have the root commit.
It's encrypted with the mechanism of you before.
All of them.
And then.
We have the first operation that add some text.
One character or one sentence to the text.
In a text editor.
Let's say.
So we do the same.
We encrypted everything.
We get a key and an ID.
But what we do is that we link this new.
That are commit with the past with the previous one.
Always.
So you can see this is the past.
And we are.
The timeline is doing like that.
I should not pass the line.
And then you have.
So what happens?
See how it is.
You can have concurrent modifications.
So this is what happened there.
In three and four.
They didn't have internet.
Maybe one of the two didn't have internet.
So there is.
They're all based on two.
And they don't know that they mutually.
They made some modifications.
So we have this fork.
Temporary fork in the dagger.
And the next time that they have internet.
They will exchange those commits.
Through the service.
Through the pub sub.
And they will realize that there was this fork.
And you know what?
We don't even have a measure operation.
There's a measure commit or something like that.
They just stay like that.
We say we have two heads at that moment.
Two current heads.
And then we.
At the next operation.
If someone writes something new.
We will.
The next one.
The number five.
We'll be a merge.
In fact, a merge.
A operation.
But it also has some real data in it.
Right?
It says the whatever this person is used.
It's Alice.
That she did.
And it also makes the merge.
And with interference with the ideas.
The previous ones.
So when you come and want to open the document.
The only thing that you need.
Let's say you didn't have access to the document.
It just arrived to you.
It was given access to.
The only thing you need is the key and the idea of the number five.
That is there in red.
If I give you that.
Then you can open them.
You know.
One of the other like that.
And I would stop here because I think I'm very close to the end.
And then a question or two.
That's it.
Thank you.
All right.
We have time for more two quick questions.
Okay.
I see a hand right here.
How does that client authenticate with a broker?
How does a broker know when a client is allowed to talk to?
Signs.
A challenge.
We see the private key.
Simple.
Okay.
Like the same private key used for encrypting the files?
No.
We have different ones for this because only the broker needs to know that one.
Your register to this broker is giving you service, right?
So your register always your friend or it's yours or you pay for it.
Something like that.
That's it.
Yeah.
One question regarding this large RDF structure with the distributed graph.
How does that relate to the capabilities?
Can you let's say make accessible only a part of the big graph?
Provide capabilities for only a part but still have them connected to perhaps inaccessible?
I see people with disabilities with people moving.
They shouldn't move when the questions.
Okay.
Now I was wondering about the relationship between the capabilities on one side.
And this possibility to build one big RDF.
Yes.
Thank you.
Okay.
And then how these two relates?
Can you let's say give access, give capabilities to parts of the graph?
Exactly.
So each the graph is made of documents that contain a bit of it.
But then you have a bigger graph.
The composition of all of them, the union.
So each document has permissions.
I can share only one part of the graph for all of it.
And so is a bit of a question?
Yes.
All right.
And sorry.
We have to call it there.
But if you'd like to ask more questions, we can we find you.
Where do I find me?
Yeah.
We're going to find you if they want to talk about it.
All right.
So reach out through here.
And yeah.
On that note, let's give another round of applause everyone.
Thank you, Nico.
We appreciate it.
All right.
Thank you.