Here it is. Hello, everyone. I'm Nico and I'm going to present to
Next Graph today that I developed in the last two years with the support of
NLNet Foundation and the NGI Fund of the European Commission.
So what is Next Graph?
It's a protocol for encrypted sync of data.
And on top of that, it's a framework for developing collaborative applications.
It's a working progress. The protocol is ready and the framework is coming this year.
You will ask me maybe why another protocol, why another framework.
Like if they were not enough of them already, right?
First of all, Next Graph is local first.
So you will hear about local first more and more.
You just heard it about that five minutes ago.
It's a hot topic, but what is it?
Maybe you remember that we used to have offline on least software.
No internet or at best you would exchange files by email.
And now everything is in the cloud.
As you will know, the cloud does not work offline.
Today we are talking about local first apps, which can work online, but also offline.
And when connectivity is restored, the synchronized without conflict.
As a bonus, you also get real-time collaboration for free.
How can it merge without conflict?
This is because we use CRDTs.
You heard of it just before.
And if you don't know what it is, you go to CRDT.tech or Lofi.store, a very good website.
I don't have time to explain it now.
But basically, there are data types, meaning a special format or encoding of your data.
We encode each update separately.
And that helps us to merge automatically the concurrent edits.
That's the problem when you edit concurrently the same thing.
When we are back online, we sync the divs and it just works.
So the difference with other sync protocols is that next graph is Antoine encrypted, which you know what it means, right?
We believe that privacy is important.
I'm sure you agree.
Users should own their data and how to own your data.
The only way to enforce that is by encrypting everything Antoine.
Our protocol has been designed from the beginning to securely transport any kind of CRDT.
And it could transport, by example, aether, aether, aether, what was it?
It just presented.
From now, we support the CRDT of auto merge.
That's why I'm saying it because it's based on auto merge also what you did.
YGS, RDF and soon Noreau.
And soon we could unmore also.
The RDF CRDT has been developed in house because there wasn't any available.
The three other lives, they are the most known CRDTs.
It's about JSON, rich text, map down and plain text.
And with that, you can do already a lot of things.
By the way, if you're up, if you haven't up.
And if you're already using one of those, you can port it to next graph and you will immediately benefit from encrypted sync.
We also have immutable binary files because it's useful, right?
Attachments, the files, the images, the videos.
And we added the mechanism of blocks like in notion so that the users can combine within a single document.
Many CRDTs and types inside one document.
Also developers can choose which CRDTs the best fit for their data model.
And this is why it might become interesting, it's because we have framework.
Any app can become collaborative, local first and end when encrypted at low cost.
We're providing convenient APIs for web app developers who are using active stores like those,
where they can bind their data to some GUI components, right?
That's how it works.
We have the data and we bind.
We give you that a reactive store.
We have bindings for TypeScript, NodeGS and Rust, because in traffic it's coded in Rust and compiled to wasm.
And we will add later support for all this if we can.
Using our framework, we already developed an app.
For mobile desktop and web web app.
So that end users can manage their wallet, install and launch other apps, store access and search.
They are data locally and while keeping it encrypted at rest.
They can grant and revoke access, they are data to other apps.
They can grant access to their data to other apps and share documents in their social network.
Users can organize their documents into public protected and private stores and create new stores for teams and groups.
We believe that in the context of AI is crappy, online harassment and pervasive surveillance, more private social networks are needed.
Meaning social profiles and posts should probably be protected by permissions and encryption.
And your family vacation picture should probably not end up in your public profile anyway.
Next slide can help with making secure and cryptid and local first social apps.
Generally, with us SDK, the developer only did with local data and subscribed to the data for the dates and it synchronized in the background.
No more remote API calls, fetch or post like here.
It's not a client server anymore, which makes it more decentralized and web service or even an federated system.
Don't get me wrong, the Fediverse is great and we are happy to hear, but we want to overcome its limitations.
Like, for example, the VPS, you need to run, the CIS admin, you need to trust, who will install and manage and upgrade many web apps,
of any compatible one with another.
The domain name is that need to be paid every year and bring some portability issues when we move our data to another service providers.
We have problems with portability here.
So running first services can be complicated and not risk-free neither.
This is a picture of a French that has sent out that burned down a few years ago.
We want to be more decentralized and resilient than that.
We want to have more and zero single point of failure, so we got three of the main names.
I mean, they are not mandatory for the protocol to work, just IP is enough.
Does that mean that we are peer-to-peer?
Not really, not exactly because peer-to-peer has a major problem.
What to do when you want to sync your data and you can't find any other peer online at the exact same moment than you.
So, as a consequence, we still have a server, servers, but we call them brokers.
Our network is organized in a two-tier topology, which means the peers took to a broker and the brokers took to each other.
The workers ran 24-7, and only stolen for a while, encrypted blocks of data.
They are simple to set up and run.
They can run anywhere, as long as they have a public IP, and we want to see them running everywhere, especially at home and in your office.
Basically, what we call at the edge of the network, there is a level of decentralization that we want and data locality that we want.
I can control where my data is stored and I can easily add automated encrypted backups by configuring more brokers in my account.
Because we developed this new protocol that does not need domain names, we automatically came to use the IDs as identifiers for both the users and data.
Each document has its own ID, and regardless of where the data is stored, the ID is stable and remains always the same.
I can share the ID link with other users and collaborate with them on any document.
Those URIs represent permissions that we call cryptographic permissions because if you have the key, the link is the same.
You can read, you can subscribe, or you can maybe edit, but if you don't have it, you can do nothing.
Of course, we sort about backward compatibility to HTTP.
You can already run a web service in Node.js, by example, to serve your data if you need to, and there is also web application for end users.
Thanks to our collaboration to with activity pods project here in the room.
We are compatible with activity pod and solid, and by the way, they are presenting tomorrow in the birth of a physician, track A on social web at 12 o'clock tomorrow.
Now that I mentioned solid, in fact, RDF, link data, semantic web, source synonyms are the heart of our platform.
As I said earlier, we have developed a CRDT for RDF because we believe that link data is great for interoperability.