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