Nextgraph

Oh, I will try not to do hums.

No, don't think about it, it's all good.

Just be yourself.

Also, gotta say, your audio sounds really good.

And your voice is sounding fresh.

Okay, thanks.

Same for you.

I can hear you well and always a

pleasure to have you.

Hello and welcome to the second episode of

the SolarCast podcast.

And today we have Nico with us from

NextGraph.

We will be covering tons of different topics,

from how NextGraph works, to why it was

started, and some exciting new announcements that have

been made recently, as well as the status

of funding for open source in Europe right

now.

So, with no further ado, let's dive in.

Awesome!

So glad to have you here, Nico, and

right after FOSDEM.

This is going to be the second episode

of SolarCast.

And you are actually one of the first

people who even heard about it ever, because

we started talking about doing this recording like

a year ago.

Exactly.

Hello, Zenna.

I'm very happy to be here with you

today.

Finally!

After an intense FOSDEM, that's for sure, and

the previous one was also intense.

It's always intense, right?

You couldn't join us, but you were missed,

for sure.

And I hope you saw some recordings.

But it was, yes, next time.

Next FOSDEM, we'll be together in Brussels again.

And also this FOSDEM, you were organizing like

a whole section, weren't you?

Yes, indeed.

There was this dev room.

This was the first time that we did

a local first dev room.

It was needed, right?

It was overdue.

And it went very well.

We had a full day, packed with amazing

talks.

I think we might expect to have it

next year, as a repeat.

I really hope so!

My FOMO was so intense, it was off

the charts.

I understand you, really.

I would like to miss it.

You have the videos.

At least you can go watch the videos

whenever you have time.

Everything is there.

And that goes for everyone else who might

be listening as well.

That said, was there like...

Actually, I think I know the answer to

this.

Because before we dive into the regular questions

of the interview, y'all made a pretty

big announcement this FOSDEM.

Or maybe specifically, NLNet made a big announcement,

and you are part of it.

Exactly.

It's a joint announcement.

And it was big, and it was at

the same time.

So this FOSDEM was intense for me.

We announced that there is a consortium that

was created and that has been selected by

the European Commission for three years of funding

with the goal of building a suite of

apps based on XRF.

And we can dive into that a bit

later if you want.

But the suite of apps is productivity tools.

It borders to social networks also.

So we expect a lot from that.

It was just announced a few days ago.

Yeah, that is incredible.

And from having seen a bit of behind

the scenes, wow, you deserve this.

The amount of effort you've put in to

make this happen is incredible and admirable.

So cheers to you.

Thank you.

Thank you so much.

So going forward, what do you see with

this new consortium and this new suite of

apps that are going to be built on

NextGraph?

What do you see as the next steps?

How do you think you're going to be

engaging with the surrounding communities?

Yes, it's going to be first a lot

of work.

These 12 partners working together, they all bring

their own technology.

We're going to make it happen.

The work is concentrated on the first two

years.

So you can expect something to test in

about a year or maybe a bit before.

And we have CryptoPad also in the consortium.

So we're going to work on compatibility with

the suite of apps of CryptoPad.

So then the sky is open, I would

say.

We're still looking at other suites that already

exist, like NextCloud or La Suite Numérique from

the French government or others that would like

to have interoperability with us.

And we would like to benefit from the

features that we can offer them.

So why not that?

In terms of community, there are also some

independent app makers that are looking into NextGraph

for using it as a base for their

work.

So we hope, yes, we have expectations.

I hope it will turn out to be

good.

It will definitely.

I'm so excited to see more and hear

about what's coming forward with that.

I can't wait.

It's really been a journey for the whole

peer-to-peer kind of webs.

Well, that's how I refer to it in

my head.

Easier than saying offline first, local first, peer

-to-peer networks.

But the maturity is really starting to come.

But one thing that you mentioned just now

was interoperability.

And just because this has become like kind

of like the tagline for digital sovereignty in

Europe, I'm kind of wondering like what does

interoperability mean for you in practice as someone

who's like developing protocol?

Sure, that's a very good question.

And the word is used interoperability.

It's used everywhere, right?

Everybody is interoperable.

Basically, not saying it is like a mistake.

But then how do you do it?

And what it really means, it's another question.

And then we have problems of interoperability on

the definition of the term interoperability.

I know.

It's a tough subject.

So what it means, at least for the

end user, I guess, is that if the

end user is using an app and then

wants to switch to another app, if the

user has the files, he can do that.

They can do that, right?

If she's using one website and then wants

to switch to another one, the same.

We have basic interoperability with the web.

We have these links, right?

We can connect.

We can say, now I redirect users to

another page that exists for 30 years.

That's the very lowest standard of interoperability.

But then the apps that we use, they

need to save the data somewhere.

And this data has a format.

And this format is decided by the programmers

of the app makers, of the ones who

wrote the program, the software.

And this is where there is this problem

of interoperability, because is that format understood by

other apps or not?

So we have import, export, and this is

becoming soon a nightmare.

So I have done this work here, but

I need to export it in another one

and import it, and it doesn't work, or

there are differences.

These programs don't really understand the same formats

the same way.

So at the level of the data, I

like to use a specific format, which is

called RDF.

It is a simple format that describes...

Yes, it is not known.

I see your interest.

It is not so well known.

There is another one which is called JSON,

which is more known, right?

But the JSON is simple.

It is playing well with the...

The structure is very good.

It is very simple to use.

But it does not really describe the schema.

So we have JSON schema, for example, but

this is still very open in there, right?

Anybody can do anything.

And it is not meant for having a

way to share this schema globally with others.

It is more like, OK, I can define

my own schema, and then what?

So RDF has been thought from the beginning

in how we connect data across databases.

A database is like where I store my

data normally as a program.

It could be in a file if it

is just local, but when we have a

server and that we want to have collaboration

with different users, we put the data in

the database.

And it is the same.

Let's see it as a file for those

who don't know.

But then the data, in which format is

it in there?

And how do I exchange or link the

data across these databases, across these servers?

And this is why RDF exists.

And it was invented in cooperation with Tim

Berners-Lee, the inventor of the web.

So he did the web like 30 years

ago, and then he said that was cool,

everybody is using it, but it is a

web of web pages, right?

Of these HTML web pages.

Now I want to do the web of

the data.

So it's at a lower level.

It's how I link the data itself.

And then that's it.

That's the standard.

So it's a simple standard.

It doesn't have a lot.

And you can link the data across all

the planet databases.

This is fascinating.

And I love hearing such a concrete answer

to this question, because usually this question is

so confuddled in so many different ways.

We can come back to the same question,

because you mentioned protocols and I did not

address that.

So we can also go back to that

after if you want to.

Because there is also the problem of interoperability

at the level of the network, which is

another problem.

I was talking about the data now.

There is another one at the network and

the protocol level.

So the web, I was talking about the

web, is based on this protocol that is

called HTTP.

Everybody knows it, even those who don't know

exactly how it works.

And this was created by the same person,

Tim Berners-Lee.

So it's a very simple sync protocol that

can take or put some data on the

server.

Or I want to read.

So I take the data, it's called GET.

Or I want to modify this data and

it's put or patch or post.

But there are two ways of using this

protocol.

Most of the people use the GET.

They want to receive the information, to read

it, to browse the web.

And then we have...

So this protocol is based on TCPIP.

This is less known, but it is a

lower level protocol that makes the internet.

So the internet is using this protocol.

So all these computers, these servers, these devices

of the user are using this protocol to

exchange information.

There is only one protocol in the world

for that.

And all the internet is based on that.

At the genesis of the internet, there were

many competing protocols.

But eventually, it all boiled down to one

because we wanted interoperability.

And one of them won, let's say.

So then on top of TCPIP, HTTP was

able to exist.

And it's the same.

HTTP became the standard at the higher level

of this protocol for getting or putting data

to the server.

And now we see that this paradigm of

the web and the HTTP protocol put and

get is changing, is evolving to some more

decentralized protocols.

So this is what you're working also, Zina.

I know you're very into that.

And you call it peer-for-peer, or

it could be peer-to-peer.

There is a slight difference between the two

terms that you can explain maybe later.

And then it's more decentralized.

And we don't use HTTP.

We use new protocols.

But most of the time, they are based

on TCPIP under the hood.

So these many protocols on the peer-to

-peer level, I find it as a bit

counterproductive because I would imagine one protocol that

would fit all the needs, that would be

a convergence of all this research that happened

along the years, all these small protocols that

aren't used so much yet, but that will

be used at some point in the future

because we want this peer-to-peer change

to happen.

So I'm actually really curious.

I wish it could happen.

Yeah, because we've had this conversation, you and

I, before.

And we're not going to delve into all

of that now, even though it's a very

interesting conversation, I think.

But the conversation is the question of multiplicity

versus the one.

And if we recap just in short, I

was saying that in a distributed web where

things are peer-to-peer, there will be

multiplicity because that aligns with the organizing forms

and the architectural forms of these kind of

webs and networks.

And you were saying what you said just

now, which is this whole of like, there

will be one protocol that will eventually become

the protocol that we will use, but it

will be an updated version compared to what

is existing now, which is like HTTPS and

stuff like that.

Did I recap that correctly?

Yes, it's good that you mentioned this previous

discussion we had.

And yes, for me, I'm still saying the

same.

And for now, we are not there.

For now, we still have a diversity of

protocols.

And it has, of course, a benefit because

everybody can experiment and add features that are

specific to what they need.

But then there is this question that you

raised of interoperability.

And if we want the devices and the

networks to talk to each other, I believe

that somehow we need to speak the same

language or the same protocol.

Then there is also the option of making

bridges.

Like if we do have separate networks and

separate systems that don't talk the same protocol,

then we can make bridges between them.

It's already existing for some of the protocols.

But I found that this bridges solution is

a bit brittle because we don't have parity

of features on those protocols.

So it's always going to be a subset

of the features that are bridged.

And it can be, for the end user,

I mean, a bit confusing.

So as we've seen, these HTTP protocols take

over the whole web.

We might see one protocol, and it doesn't

have to be mine.

I would prefer to just work with all

the people doing protocols today and come back

to the drawing table and say, let's make

the best of all these protocols.

And then let's design it together and then

let's implement it together.

We can even split the work because we

are many.

So then it's going to go very fast,

the implementation.

And then it's the best, right?

So we all put our brains in it.

So it's the best of all of it.

So I'm wishing for that.

And in the meanwhile, I have my protocol.

Something like that.

I fully get that.

And thank you for touching back in on

this, because it was something I was thinking

about ahead of the podcast.

I was like, should we bring this conversation

back?

It's really interesting, and I find it very

fascinating.

Also, because it touches on that correlation between

technical work and organizational work and how they

kind of shape each other.

That's called sociomateriality, which is a completely other

topic that we won't go into now.

Hashtag academics.

Yeah, somebody needs to interview you at some

point.

No, definitely not.

But I thought it was interesting because something

that you mentioned here, it comes back to

this whole question of like, is it a

feature or is it a bug?

Exactly.

Because in a lot of these networks, like

ActivityPub, which is the protocol for Mastodon, or

also in Scuttlebutt, we had the same situation

where we had the Scuttlebutt protocol, but someone

built the chess app and someone else built,

of course, just regular social networking.

And then you mentioned this aspect of the

parity of features and how that can become

confusing for end users.

So I was wondering, you mentioned that that

was going to be a challenge for networks

to be able to communicate together because one

network might be using a certain data set

that the other network doesn't use for different

purposes.

But I'm wondering, because that is already happening

in a sense.

Like a lot of these networks have multiple

apps being built on top of them.

Like communicating between a LEMME instance and a

PixelFed instance, for example, can sometimes be a

little bit like wonk.

How do you see that happening now that

you're going to be building multiple apps running

over NextGraph?

Good, very good question.

So, yes, this ecosystem of apps built on

NextGraph or built on this ideal protocol is

needed, is wanted, is desired.

And it's going to happen.

We have a plan for 16 apps in

ELFA.

That's the name of the project, the consortium

for encrypted local-first applications.

That's a name that says what it does.

And then we want even interoperability with other

apps.

We have also third-party apps, app makers

that are already building apps, like three of

them at least, in the pipeline, a video

editor.

We have a text editor with comments and

social interaction.

The video editor is Miru.

And then we have a Lilo startup that

is working on the web of trust and

social networks and personal network manager.

It means I import all my contacts into

this app and then I can contact the

people but also share these contacts with others.

But anyway, what I mean, what I wanted

to say about the diverse ecosystem is that

if the protocol is at the lowest level

possible, then there is, the sky is open.

Then everything can happen on top of this

protocol.

So we don't want to pack the protocol

with a lot of features, like ActivityPub has

a bit of this problem because it's a

higher level protocol.

It's more about what the format of the

data, about what you can do, what the

interactions the users can do on this protocol.

While NextGraph protocol, it's a lower level.

It's about syncing data.

That's all it does.

So we are in the local first paradigm.

So it is different than a web API.

We have here a sync engine and a

sync protocol.

So the devices of the users are connected

through this protocol and they sync the data.

And that's what's happening.

And it's end-to-end encrypted.

So there are some servers in between that

are just there to help, to help for

the communication.

But they don't see the data because it's

end-to-end encrypted.

And we call them brokers and they do

store and forward.

It's like in WhatsApp.

When you send a message in WhatsApp, there

is a server, the server of Meta, but

it doesn't see the data, the message.

And as soon as the message is transferred

to the other devices, WhatsApp deletes the data

that it had stored on the server.

We don't delete it because it helps for

synchronization with new users that join a group,

for example, or new devices that you would

add for yourself.

But the user can decide at some point

to remove data from the broker also.

As long as it's end-to-end encrypted,

it's okay.

So that's the general architecture.

And it syncs data.

So you have documents that are synced.

In the documents, what you put is up

to the app developer.

The app developer can create all kinds of

formats for the data, different types of interactions,

of use cases, of flows, of how to

use the app.

That doesn't matter because we just use these

documents as a database, as a global database,

as I said before.

And it handles permissions, but that's it.

And the format, we can support RDF, JSON,

and Markdown also for the text, the rich

text editing.

So that's the basic we give.

We give a little bit more in the

protocol, but I don't want to touch it

now.

And we think that this is really the

base that an app developer needs.

Yeah.

Can I make a sneaky, cheeky request?

Yeah.

One app that's missing on the market, a

huge gap in the open source market, is

voice chatting apps.

Like, Discord has a stranglehold on the market,

and Mumble used to be the other option,

basically.

Now Discord is starting to use these identity

verification methods that are quite intrusive.

Yes.

So, yeah.

A sneaky, cheeky little sign.

Okay, I will keep it in the back

of my mind.

In fact, it's very true in the news.

In the last days, everybody was talking about

this problem of Discord that open source people,

at least, or privacy-concerned people, want to

leave Discord, where it's massively used so far,

even in the open source communities.

And it was a wrong idea because it's

not open source, it's not an open platform.

So, why are we...

What are we doing there in the first

place?

But, anyway, it's going to change, but people

are confused because there's no alternative.

Right?

There's not a very good open source alternative.

There is one that is trying, but it's

missing this key feature of the audio, as

you said, this audio chat or...

So, let's do it.

Yes, let's do it.

I hope that somebody will do it soon.

On any protocol, I would say, and then

I can port it to NexGraph or something

like that.

But if they want to do it on

NexGraph, they are welcome to do it, of

course.

If you're listening to this, you can reach

out to NexGraph or any other protocol and

build a voice chatting app for open source

and people will love you.

Exactly.

You will have a lot of adoption in

the coming days or weeks.

You have to do it quick.

Actually, we've been having this issue for years

because we used voice chatting in Scuttlebutt as

well.

Now it's becoming...

I feel so old when I say these

things, but seven years ago...

No, but it wasn't seven years ago.

Maybe four years ago.

We were using voice chat a lot, but

then something happened with Mumble and then it

just kind of fell off.

But no one wanted to move to Discord,

of course.

I tried it, Mumble.

It's nice, right?

It's like a native app that you had

to install and it was working great.

I don't know why it didn't pick up.

I don't know.

There are some questions to ask here.

What's better in Discord than Mumble, by example?

Why?

Exactly.

Good question.

For the eve online player season.

But now we've gotten plentifully distracted by super

interesting conversation, which is always a pleasure.

And part of that conversation has also dived

into some of those questions that we're going

to be exploring in this podcast episode.

So one thing that I'm very curious about

right now.

And I think I don't know if people

have heard this story, but you yourself are

a very fascinating person.

Thank you.

You too.

See that.

With so many cool life stories.

But I'm curious, like what's when Next Graph

was initiated?

What was it that like made you want

to build Next Graph?

And why did you find it so important?

Yes.

Okay.

So I will make it short.

This idea is 20 years old.

Even more, I think.

It was the first idea was the tools

I'm using today, so 20 years ago, are

not good enough.

It's all brittle.

It's all okay.

They are open source.

Imagine 20 years ago how it was, but

the situation improved a little bit, but it's

still not as good as I want it.

Right?

Tell me.

Good enough for what?

All the tools.

Like I'm using a computer and I have

these problems all the time.

Right?

Of incompatibility of apps, of I need to

use a server.

I need to install a server.

If I want to self-host an open

source project, I need to install maybe 20,

25, 30 different servers, services, right, on the

server that I rent.

I need to sysadmin this server.

I need to make the security good for

it and all these apps to work together,

which is a nightmare.

We have Framasoft in France, right, tried to

do that.

They called the project to degooglize the internet

10 years ago and it didn't really pick

up.

They did some good things, but it was

brittle also because you had these different apps

and they were not working well together.

We have newer attempts at that that are

the same, right.

I take these different softwares and I try

to make them work together, but it doesn't

really fit.

So there is this first problem, right, and

then I want to own my data.

I want to everything I do, even if

it's on the web, even if it's sharing

with others, I want to have a copy

locally.

I want to be the owner of my

own data and if something happens, I can

do, I can use another software and I

can switch to another.

Yes, if the software is not good enough,

I can change it, but also if I

want to just use another one, I should

be able to do that.

So that was the first principles I wanted

to address.

It's called malleable software.

There is a term for that and it

does not exist.

We are still struggling to create malleable software.

So that's our very first