Here it is. Hello, everyone. I'm Niko and I'm going to present you
NextGraph 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 NextGraph?
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 work in 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, NextGraph is Local-First.
You will hear about local-first more and more.
You just heard about it five minutes ago.
It's a hot topic, but what is it?
Maybe you remember that we used to have offline-only software.
No internet or at best you would exchange files by email.
And now everything is in the cloud.
As you 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, they synchronize 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.so, 2 very good websites.
I don't have time to explain it now.
But basically, they 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 diffs and it just works.
So the difference with other sync protocols is that NextGraph is end-to-end 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 end-to-end.
Our protocol has been designed from the beginning to securely transport any kind of CRDT.
And it could transport, by example, EtherSync
It just presented.
From now, we support the CRDT of Automerge.
That's why I'm saying it because it's based on Automerge also what you did.
YJS, RDF and soon Loro.
And soon we could add more also.
The RDF CRDT has been developed in-house because there wasn't any available.
The three other libs, are the most known CRDTs.
It's about JSON, rich text, markdown and plain text.
And with that, you can do already a lot of things.
By the way, if you're app, if you have an app,
And if you're already using one of those, you can port it to NextGraph and you will immediately benefit from encrypted sync.
We also have immutable binary files because it's useful, right?
Attachments, 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 are the best fit for their data model.
And this is why it might become interesting, it's because we have a framework.
Any app can become collaborative, local-first and end-to-end encrypted at low cost.
We're providing convenient APIs for web-app developers who are using reactive 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, NodeJS and Rust, because NextGraph is 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 ( a web-app).
So that end-users can manage their wallet, install and launch other apps; store access and search
their data locally and while keeping it encrypted at rest.
They can grant and revoke access, of their 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 scrapping, online harassment and pervasive surveillance, more private social networks are needed.
Meaning social profiles and posts should be protected by permissions and encryption.
And your family vacation pictures should probably not end up in your public profile anyway.
NextGraph can help with making secure, encrypted and local-first social apps.
Generally, with our SDK, the developer only deals with local data and subscribes to the data for updates and it synchronizes in the background.
No more remote API calls, fetch or post (like on slide).
It's not a client server anymore, which makes it more decentralized than a web service or even than a federated system.
Don't get me wrong, the Fediverse is great and we are happy it's here, but we want to overcome its limitations.
Like, for example, the VPS, you need to run, the sysadmin you need to trust, who will install, manage and upgrade many web apps,
often incompatible one with another.
The domain names 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 FOSS services can be complicated and not risk-free neither.
This is a picture of a French Data Centre that burned down a few years ago.
We want to be more decentralized and resilient than that.
We want to have zero "single point of failure", so we got rid of domain 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 talk to a broker and the brokers talk to each other.
The brokers ran 24-7, and only "store and forward" 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. This is the 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 DIDs as identifiers for both users and data.
Each document has its own DID, and regardless of where the data is stored, the DID is stable and remains always the same.
I can share the DID 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, it 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 thought 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 a web application for end users.
Thanks to our collaboration to with ActivityPods project (present in the room),
we are compatible with ActivityPub and Solid, and by the way, they are presenting tomorrow in the Bird of a Feather, track A on Social Web at 12 o'clock tomorrow.
Now that I mentioned Solid, in fact, RDF, Link Data, Semantic Web, (all 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.
RDF is used by Wikipedia, many industries, in academia, as knowledge bases, for social graphs, any graph.
We know that all popular social networks are internally based on Graphs. also Netflix. Like Meta and all of that.
With NextGraph, every document can be linked to any other document or to a social account/profile.
But in fact RDF can store any data. You can use it as a DataBase.
that can be queried easily without worrying about JOINS and Foreign keys.
I am skipping the slide about SPARQL and about more features, because I am running out of time.
We believe our framework is a good foundation for implementing any social or content-oriented app
with local-first, E2EE, privacy, and decentralization at heart,
including for data or productivity tools, and anything you want, really. To make apps!
With the current enshittification of platforms, and Big Tech dominance that feels like never-ending, it is about time to regain control on our digital lives.
To achieve that, we believe that more cooperation with you, with other FOSS projects, and integration of the many existing solutions is the key, towards massive adoption.
We propose NextGraph as an open ecosystem and stack, based on standards, for everybody to enjoy and build upon.
If you feel it’s cool, join the adventure. Contact us or talk to me today. And stay tuned for the beta release! Thank you!
And I have hex stickers, if you want.