Next talk is Nikolai himself, so I'm taking off the MC and Lauren talking about next
graph and to encourage us to hear the tape.
Thank you.
So, another round of applause for Linux because we didn't have any program with the display.
Hello, everyone.
I'm Nikolai with Lauren.
We are working on the next graph since three years with the support of NNET and the NGI Fund
of the European Commission.
Let's talk a little bit.
Give you a story about data.
We'll make it very short.
We have a bit late.
Where is my data today?
There.
For most of us, right?
It means me or other accounts.
No access to road data.
It's there, but we can't have access to it.
And plain text in their cloud.
That's not something you want because cyber attacks, leaks, surveillance.
Open social alternatives.
First them.
Great.
But, marry other accounts.
In compatible APIs and data formats, nothing works well together.
And plain text in their servers.
This is a means.
There are friends, but still.
I want my data.
Sorry.
Sound.
I want all my data.
I want all my data in one place.
So I can have control over it.
Ownership, availability, security and privacy.
I can share and collaborate with who I want if I want it.
So I want end-to-end encryption.
And the server is just going to do store and forward of encrypted blocks of data.
It's not going to do much more.
And we call it the broker in the next graph.
And then once I do that, I have local first and I need the strategies.
Because the server doesn't do anything anymore.
It's not helping me with coordination, with total order, with transactions, anything.
How many servers?
You got it.
A federation.
Right?
Because we can't fit all the data of the world in one server.
And it's synchronizes with a pub sub.
There are many ways to do reliable broadcast, but we choose pub sub.
Or go see by example.
It replicates on all your devices, first of all.
Second, it's also stored in the brokers, the servers, but end-to-end encrypted.
So we have full decentralization.
You can have several brokers that are doing backups and emails of your data.
Fail saves.
So I want to completely decentralize the central place for all my data.
This is what I want.
And that's the graph.
Now I'm going to go on the stack.
We started very low on the network and now we go to the protocol.
So the protocol is specialized for end-to-end encryption of CRDTs.
There are a few people doing that, but they are all in the room today.
And so then it can sync any kind of CRDT.
So in the future, we will see more CRDTs.
We have found out some generic CRDTs that you know.
And then we will see specialize CRDTs, because we need to be close to the data model of the application,
like basically 2D, 3D, how do you manage conflicts in that?
So it could do it.
It's the protocol manager's access control with cryptographic capabilities.
So Brooklyn, before I explain what they do, I will not do it.
Because it's too complex and I also give more details of that later on in another talk this afternoon.
We used this, this is a scheme.
It's like you have a HTTP, you have FTP, and you have did.
And then you can put whatever you want in the scheme.
So there are decentralized identifiers.
So it did energy for an aircraft.
And then we put the public keys of the document.
They are stable and durable and portable IDs for your documents.
And for your identity.
We also do with the protocol upload and download the binary files with streaming, content addressing, and chunking, like a bit of rent.
But encrypted.
So we support the services for now of YGS that you heard about just before and auto merge.
That's what just before me and RDS.
Now RDS, you don't know what it is, right?
Who knows about RDS?
Oh.
So I should do a dev room about RDS next year.
So it's a graph, it's a graph data format for those who don't know.
YGS and auto merge are more like JSON like.
They also do rich text, a plain text.
In next graph, I call those discrete compared to the graph, which is like continuous.
You see the image.
And then we have Sparkle, Sparkle, which is the query language for like SQL.
It's similar.
And then it's a standout.
It's a data format that is very simple.
You have, you don't make tables with many rows.
You have only three columns.
It's a subject predicate object.
It brings interoperability by default.
Your apps can use the same format.
It's not like JSON or you can have different,
you need to define the schema here.
It's a flexible format and malleable software.
Means you can replace the software that you keep the data.
And you can compose the software and change it.
And you have a, it's not, it's not bound together, the two.
You can link other documents inside one document.
And it's a database with the query language.
So that's a base across all your documents.
And the documents that have been shared with you.
It has automatic joins.
This is like different from SQL.
When you need to think ahead about your foreign keys.
Here, all the data is joinable.
From the go, when this I said it, it's the global IDs.
This is very important.
Okay, this was key.
So pick up sync protocol.
See the diagnostic graph database.
An encryption address.
Next card brings all the data.
It's not only end to an encrypted, but encryption address.
The database on your disk.
There's the key.
Whenever up in the stack, we have a web SDK.
You can do apps with WSM RAM.
Native apps with storage still web technology.
But it's a web view.
And then you can do also pure rest, Python and TypeScript.
So for the native apps, it's all the platforms.
And for the languages, it's those.
For now, but we are also going to add more as we can as we do.
So the SDK, the APIs are two.
Two levels.
The raw APIs.
You just subscribe to the documents.
It's document-based.
Update the documents.
The CRDT binary blocks of WGS automatically.
The RDS triples.
But you also have a higher API that lowering will present now.
We're compatible with these three frameworks.
And then on top of that, you have a framework.
The framework is, so on top of the SDK, if you want to use common features that all apps need.
So we give you a history of your modification.
That's immutable.
You can audit every commit, every change of the data is signed.
So we have authenticity, it's immutable.
And we can even time travel.
We can come back in the past and see what was there.
Permissions, of course.
Search, local search.
Sparkle, local, sparkle, always.
Everything's local, local first.
And reactive queries, not.
We don't have a chat, but we are working on it.
Which is what everybody does now.
You make a query and the query stays alive.
And if you're underlying data changes, your results are going to change also.
After months.
That's great.
For the reactive programming, it's great.
Comments, chat, notifications, basic.
The store, the drive for all your documents.
The wallet where you have all your keys.
And you need to open this wallet locally.
Not talking to the server.
And the app store, because we want to make apps with next half.
And then we need to install those apps and other access to them.
This is the user who decides which apps.
So it's not ready.
Next up, ecosystem.
It's who's using it today.
We have a few docially.
I mean, he's here in the room.
We're working with hospitals, because the next half is resilient.
So if half of the hospital burns, the other half can see the work.
Miru, Miru is a video editor.
He's also in the room.
He's going to present a little bit later.
We have a personal network manager, which is bringing all your contacts from
LinkedIn, Gmail, blah, blah.
And then some services like activity pods that
is doing compatibility with activity pub.
And soon we have mail.
Now, one big thing, we just got a grant.
And we're going to do all these apps.
We have three years to do it.
This is going to be the workspace that everybody wants.
It's an integrated local first based on next graph.
And there will be sub-granting.
So if you want to apply for grants at NNNAT,
you can be helping us during this framework.
We have a stack.
We have a stack that starts with the network,
which is decentralized.
You can install itself host.
It can go on all kinds of things up to the cloud.
It's AWS.
It's not recommended, but if you need to,
you can it's encrypted.
So it's okay.
The best is to have it at home.
You have a small device at home.
That's the dream, right?
We're super decentralized.
So because we don't use DNS,
it's only on IP.
So don't worry about that.
Second level is a set protocol and engine.
So the SDK then the framework and then this ecosystem of apps.
Now, this is the properties that you get when you're using us.
I will let you read that later in the PDF.
We are in alpha.
You can start using it.
We have a startup using it already.
But performance, this is the next step.
Torrid plugins are going to be cool for those who want to make native apps.
This is what we do this year.
And now, Lauren, we'll take the mic.
Yeah, for the next.
All right.
Okay, come here.
So I developed the TypeScript SDK in ORM.
So an object relational mapping to map the different CRDTs,
bit RDF or automation, YJS,
to play in TypeScript objects.
So it's easier and you don't have the different APIs.
For example, this is my bed.
This is YJS.
And then comparison in the next graph with the ORM,
you just say data.key equals value.
No function calls.
This happens in the background.
And you get reactive life synchronization with your front.
And this is React, spelled, and view.
And I'm going to show you a demo.
So it's easier to read like that.
When you know it works.
Isn't it?
Right?
Yeah.
So you put it in your language.
Yes.
Okay.
Perfect.
So now.
So I have written an expense tracker example app.
You have implementations in the same window with
view.
React and spelled.
Right.
And here you can see two different windows.
Having two different running to different engines.
Or replicas can call them.
And I can add a new category here.
What is your app doing?
Sorry.
What is your app doing?
To the expense tracker.
Right.
And so I can.
Yeah.
I think the connection is not good.
So might have.
Okay.
Found out.
Sorry for that.
Here we go.
So add a new category.
For example, work related things.
You can see it pops up.
Here and in the different.
In the other tab and the other frameworks.
And I can expect add an expense.
Let's call out.
Pause.
Dan.
Take it.
Train.
Take it.
Not like that.
And add it to work.
And here you can see.
It's synchronized.
We see.
Great.
Hello, everyone.
My bad.
Chit, chit, chit.
You can start over with me.
The other one.
Want to be on your slides.
Starts with this slide.
This is the state show.
Start with different slide.
Here we go.
Okay.
So what's happening in the background?
The object changes.
Something like expense.
The title is called.
Within you.
Post them.
Trying to get here.
See it.
The engine.
The changes send to the engine.
From the orm to the.
Engine running in either.
Rust orn.
As binary.
Persist.
The CRDT.
And so you sit to other replicas.
To other devices.
There.
The engine receives the changes.
Decrips it.
Flies it to the local replica.
And up there.
It's the type of object.
And this makes the front end re-render automatically.
Okay.
So what happens.
So.
Here's an example of how this component looks like in a.
I'm compact format here.
The example for react.
You either call use discrete.
If you use.
And you're using json.
Supporting.
Rdf like auto much or y js.
You call it.
You get the duck.
Expenses.
Or if you're in.
Graph mode.
You just defined a schema.
I'm getting to this in the next slide.
You pass the schema and the scope.
This can be.
I have the whole.
All documents or subset of documents.
Or just one document.
And again, I have the expenses here.
And then I render all the expenses in an input.
And if I change, you can see that the component
will re-render.
So the thing is typing and RDF schema is a bit hard for RDF.
So what do we do?
In TypeScript, this expense and expense category looks
like this.
We have a graph and a sub to an ID.
The graph is the document ID.
It's an iri and the subject ID is an iri as well.
You have a type and then properties like title,
total price, payment status, different.
And you have objects with cardinality bigger than one.
So you have a set, an RDF, you don't have ordering.
So everything is usually a set.
And here's the sub object, the expense category, per expense.
Now this is auto-generated.
And this is what you actually define as a schema.
You have, again, type, title, different properties
of different data types, string, float, diger.
And here, again, you can see the sub schema,
which is our sub object, the expense category.
OK, to sum it up, what we do is we modify a series of T's.
In TypeScript, like any other object, you
don't have to deal with the specifics of the certain CRD
T's.
We have the ORM for RDF that's typed.
And we have support for auto-motion, yjs, as well, typing
there and schemas comes soon as well.
Right?
Type, say, 54 GF.
We have the reactivity in ReactView and Svelte currently.
And you have the live syncing with other users and devices.
And you want to show the Neti app, but we want it to show.
Do you have it here?
How much time do we have?
Two minutes.
OK.
Let's do it.
So that wasn't native apps.
All right.
Native.
So where do you see it?
This is what my example app looks like.
You can also find it on git.netxt.org.
Nope, that's a web browser.
So here you see the view from the native app.
I have an expense, plus the entrain ticket,
and two expense categories, groceries, and work,
and the properties that are into as well.
It is the same data.
It's the same data that synchronizes.
It displayed with a different software,
which is the same data.
And here it's native.
It's running in native application.
Maybe you zoom out and we see it.
But yeah, sure.
Right, what happens when you modify it?
It should synchronize.
Maybe it's logged out, like your web app was.
Ah, yeah.
No, no, it's still on.
It's we see it's connected.
OK, this is the demo effect.
What happened?
Where did you change?
The expense category.
Nope.
Do you want to go to wallet?
In the good wallet.
So find this one.
Maybe the connection.
This is syncing by the entrainet.
And you are in, you change it from here, from there.
You are in live mode.
Yeah.
OK.
You can close it, open it again.
OK.
And this is, oh, yeah.
We still are there.
Maybe you go directly to the queue.
Usually it works.
We have some connectivity issues.
Yeah.
It's well this morning, of course.
All right.
Thank you, Nico.
Lauren.
We have time for a couple of questions.
OK.
I'm going to try to do my questions.
OK.
Thanks a lot for working on this.
I've been reading of having something like this for more about five years now.
Something that I'm usually like working with is like,
versioning and branches.
So can I, if I build an application of this, can I say that I'm like working in a graph now for some time and then later merge that in?
Because it's a, sorry, it's CRDT.
And I can just like work on a branch and monitor that in later.
Yes.
Yes, you can.
We have branches.
Awesome.
Thank you.
Perfect.
You can.
So I want to ask you, where is the marketing happening?
Is this enough?
Where the merge happens?
Is it in a thing server?
Is it a thing server or the server does the,
No, no, it does nothing.
It's done in the client, in every client that you're seeing.
It's done in the client and it's done on every client.
We call them an application the same way.
It's deterministic.
That's, that's the reality thing.
So the server is basically just the pubs have,
Exactly.
It's still on for a while.
And cryptid things.
Thank you.
I was wondering since like RDF seems to be like a first pass citizen of this.
Does it have like a way to federate Sparkle queries across documents?
Like I don't probably want all my documents locally.
If I have all my data within the next graph.
But like how do I reconcile this with running Sparkle queries through those?
Yes.
In the future, you'll be able to decide exactly which document should be in which device
That you don't want to synchronize all of it in all the devices.
That's the first thing.
Once they are synchronized, you can make a query that encompasses all your documents.
You can make a query on all the database if you want to with Sparkle.
That's the scope he was referring to before.
Now the federated queries is that when you want to query or things that are somewhere else.
So it would be another user basically.
And this we will do it just.
It's quite easy to do it.
We'll find a priority for it.
We want it first to give you an SDK.
You could play it with it with reactants.
But it's there.
It's going to be.
Thanks for the great talk.
Can you hear me?
Is it?
Yes.
We are here.
You and this is for the remote speakers.
Good.
So it's a nice coincidence that you are using RDF.
Because SPDX is also based on RDF.
This is great.
One question.
What about gigabytes of RDF?
So if we have very large files and very large graphs.
How is this supposed to work with like a scale at a very large scale?
The question for everything is like the RDF.
But also the to merge the digest.
It's always a question.
And for the binary files, it's okay.
We have streaming.
For the RDF, I will add streaming.
It means that okay.
It's two gigabytes of RDF.
I will receive it.
And I will ingest it into the local spark engine, which is oxygraph,
by the way, because everything is in rest.
And it will come.
I can't tell you how long it will take for now.
And it will try.
Maybe a follow-up question.
Because in the graph, in this RDF graph, everything can be connected to everything.
That means that you cannot know in advance how much data do you need?
In order to be able to kind of, in a meaningful way, browse your current document.
So in the answer, do you really think that it can be like two gigabytes of data loaded into the local cache?
Because is this going to work actually?
Like in a responsive way for users?
So if the data is present locally, it's very good.
The graph has super good.
But if it needs to be fetched, or federated query.
First, then you have to wait to receive it.
We decrypt it.
We materialize the state.
And then it's available to you.
Thanks for the question.
If you run out of like the remote device, the space.
So you cannot think what is happening in that case.
The remote device?
You have to think all your updates to all the devices and remote device.
Yes, so that's what I said before.
We would have the mechanism to decide on which device to synchronize what?
I think we run out of time for the dictionary.
Right?
Yeah.
30 seconds.
One very short question.
Yes or no?
Question?
Would be great.