Welcome now the next speaker, the duo.
We have Andreas and Tobias and they're going to talk about, was a local first Linux desktop
with Modal Reflection and peer-to-pondal.
Welcome!
Hi everyone, I'm Tobias and this Andreas and we're from Modal.
Shout out to all the other Modal people here in the room.
Really cool that everyone's here.
Great energy.
Today we're here to talk about local first on the desktop and also the broader Linux mobile
desktop complex.
Yeah, I'm going to start that on kind of a broader context.
I think this picture is maybe good for setting the stage.
Because I think for many of us we've been in this movement for a long time and I think over the last year
people outside of our specific circles have really realized all of our infrastructure fully dependent
on the US, what the fuck are we going to do?
And I think from a meta perspective this could have been like, wow, this is the moment
or everyone realizes what needs to happen.
We're just going to switch over, everyone's going to use three software now.
Except most of the things that people actually need, we don't actually have.
We don't have a daily travel phone operating system.
We don't really have the level of security like on the Linux desktop that like iOS or Graphene have.
A lot of the collaborative tools that people need in the real world like relax and so on.
We don't have like a good alternative.
Anything that's like the bi-sync is like a question mark.
And it's all a bunch of stuff like this where we are like 80% of the solution that works as long as you're really technical.
And for anyone else it's like,
and our takeaway sort of as a collective and like I guess some of the people around are in our circles
is that we really need to be much more focused on strategic.
We need to like actually think about how we can solve these problems in a way that scales to people who don't come the fossil.
And also I think we need to sort of take an account the fact that the world is not where it was five years ago or 10 years ago
when most of the tech that we have now was built and planned.
I was like, yeah, these platforms are just kind of sort of neutral and like it would be nice if we had free software.
But like, you know, whatever.
It's also fine if only some of us can use it.
That's not where we're going and we need to be much more realistic about the kind of risks that we're facing.
And that is sort of the background where model comes from.
It's a new collective from I guess mostly the Berlin community around Gnom and post market and Peter Pandan some other things.
It comes sort of like out of our local events there.
And it sort of the idea is that we're organizing differently.
We're organizing around goals rather than like these specific technologies.
But we're also doing it in this focused way to like actually achieve them on a semi useful timescale.
And for us that starts maybe like by taking another step back.
I like sort of looking at like what we're actually trying to do.
Because software freedom is useful and good and we still need it.
It's sort of one of the one of the driving principles of everything always.
But it's not the only thing.
And I think in the Gnom community people have long realized this that's why like the design first is always like a big thing there.
And I think that always needs to be part of it because otherwise people who are not at fuzz them don't want to use stuff.
But also I think we need to be much more aggressive about security.
We need to like actually think about the kind of threats that not only like are real now but are going to be really in the future.
We need to think about post internet. We need to think about all of the like.
Current and future risks that that sort of exist nowadays that people didn't think about before.
And for us this friends say it's into a few semi concrete medium term goals.
One of them is the security saying like actually getting the Linux desktop to be as secure as graphene.
That's like a big topic 100 different small things need to be done there.
But that's like sort of a driving force for us.
We need a daily drive mobile phone that you can actually use to deploy in the field instead of Android.
We need to look for sync. I don't think I need to say more for this room.
We need robust like foundations for like the system itself.
Like you don't want people in the field to like do the NF upgrade and then everything breaks.
You need image space. Like there's no question there.
You'd hardware to like be sort of I don't know.
Usable as long as the hardware itself is usable because we don't know like what those supply chains are going to be doing in the future.
And you know that in irrespective of the other good things right like you can just keep stuff for longer and like fewer emissions and so on.
You really need to keep that hardware.
And then we need an Apple ecosystem of apps that actually work with all of this stuff that are local first and so on.
And in order to get there we do all kinds of things. We do developments design organizing.
We write grants to all of the above.
But also policy stuff I think is really important because for example bootloader unlocking does not really like a good technical solution.
There you need the policy solution.
And sort of our provocative goal in the long term as we would like a free software iPhone so to speak.
Like an actual computing platform that is nice to use for everyone.
And that gives everyone the rights that currently like only free software people or yeah technical people like enjoy.
And for that we have a specific stock.
I guess like there is sort of the standard Linux desktop stock.
Linux system D for all the security stuff.
Free desktop, wallet, and pipe wire.
You know, desktop stock.
GTK and a wide app because that's the stuff that sort of works best of mobile.
Peter Panda for Logan networking.
A photographer's networking.
And then flatback for app delivery.
And basically what we do is we just work upstream on these various projects to push forward our evil agenda of everything being good and cool.
But I think one specific goal obviously for this room is that we meet networking to be way more resilient because that's like one of the sort of if we're talking about various risks.
That's one of the most immediate risks.
The network sort of can go away at any moment.
And so that is I think like one important goal for us.
And that's why looking for a sync is sort of at the core of of this broader vision.
And for that, I'll let Andreas talk about Peter Panda.
Hi.
Yeah, my name is Andreas. I'm part of the Peter Panda gang.
We are free people right now.
This is like Sam, Cliff and me.
We are based in Berlin in London.
And funded for open source grants since the last six years.
Sometimes we do also consultancy contracts.
Yeah.
And that Peter Panda is basically like a collection of what we call building blocks.
And of course, the goal is to make like app development very easy.
So people should focus on building the application.
I think we all want that.
For us, it's quite important that these building blocks are very modular.
And agnostic to your data types, agnostic to the transports underneath.
Basically to avoid something like the framework lock in.
So we want this to be hackable.
People should plug in the things together.
How they want.
And they should view their locked in into like certain technologies here.
Some highlights, maybe of some things we've been working on is like confidential discovery and sync.
This is also inspired by the Willow project.
I think there's similar things going on there.
We have a key agreement scheme for groups, which is full offline first.
And it even supports double-ratcheting.
Maybe it's the first implementation out there in Rust.
We have CRDTs to organize groups, which is interesting for multi-device.
We have forms of garbage collection, different forms of coordination strategies to prune your data.
Because you don't want to keep it around forever.
And we focus also.
This is like one of a high-level goal and introspection.
So like every system should be observable.
You should really understand what's going on.
This helps for debugging a lot.
And as I mentioned before, all of this is independent of peer-to-pandler.
Basically, these are fully generic implementations.
You can combine them with any stacks, any peer-to-peer protocol whatsoever.
So this is all of these are very concrete modules.
You can just pull into your project.
Another thing which is interesting about Pietopanda is that we don't really distinct between federation and decentralization.
Like Pietopanda and its cores, like pure peer-to-peer decentralized.
But it's also sometimes okay to have a note running somewhere in multiple clients, talk to it.
That can be a note running on a server and then you have lightweight clients in the browser.
You know, basically using the note as a proxy.
Or having the note on system level and the multiple applications talking to it on the same machine.
And then there's hybrids of these.
And we think it's kind of up to the users or the communities, like based on the trade-offs of these two worlds.
And to decide which one is best for them.
Here, Tupanda is basically, we call that post-internet.
So we also not only think about offline first, what happens if the internet is gone.
We also think about what happens if there is no internet at all for political reasons for catastrophic reasons.
So all our data types and designs are also prepared for basically like a broadcast only world.
That means packet radio, Laura, Bluetooth, low energy.
I mean, it's still established connections with Bluetooth for energy.
But you get the idea we're basically like prepared for these scenarios.
On our underlying principle, which inspires this reference model, we call the walkaway stack.
And by that, we basically mean the events delivery part, like how your events arrive to your stack.
We don't really care.
We have some solutions here.
We have things.
But we want you to be able to swap that out in application should continue to run.
It shouldn't be bothered about how these events arrive.
Laura, packet radio, over the internet, over tour.
And for this advice, it's very important because we don't know if the infrastructure is going to have in the future will be will stay.
And we also don't know what power dynamics will play there.
So walkaway basically means choose your own power and balances by choosing your own infrastructure.
And you can see that being reflected in the creator-panda stack.
So we have really a whole bunch of modules.
Like down here, we have our event delivery layer, let's say.
And very different sorts of connectivity substrates.
You can plug in, also I mentioned, like, Laura and based.
And up here, we've entered the event processing world.
It's basically what the application wants to do.
And there we have different modules, which might be interesting for you.
Key agreements to agree on a symmetric key.
Maybe then you start to encrypt that towards relay.
That relay has then zero metadata because we agreed on the key beforehand for this key agreement scheme.
Things like that.
And then, at the very end, you have your database.
And all the things you want to do.
And we don't really have an opinion on how you want to do that.
I think already, like, just the talks I heard before, all technologies, which could probably put there on top.
And of course, it's a little bit cumbersome.
You kind of need to be a peer-to-peer expert to know what you're really doing.
With all of these modules, so currently, this is our work right now.
We're working towards what we call peer-to-panda node and peer-to-panda client.
These are more opinionated, high-level APIs, where you get very easy interfaces.
Publish, subscribe, pattern, to deal with the whole stack.
This is kind of, like, there we're leaving the modules on.
There you get your whole all-in-one solution.
And then, next to all of the development work, we also do research.
You can follow that research on our blog, where we publish all our findings.
And we also part of different events.
We organized, like, last year, I was one of the organizers of the DWAP seminar in San Francisco and the Internet archive.
And I also organized, like, a little lecture series.
I'm going to talk about it.
Free your clock.
About this walk-away stack, I just mentioned, and some more philosophical thoughts about it.
And then, yeah, we do collaborations with other teams.
This is really great for us, because they're building the applications.
They're giving us feedback on our APIs.
They find the bugs.
Yeah, this collaboration, now specifically, we're going to talk about it.
It's the one with the GNOME community, and, yeah, this is them.
Very concrete leading to the reflection project we will talk about.
All right.
Yeah.
So, reflection is sort of the end product of, I guess, a two-year, like, collaboration between the GNOME community,
P2Panda and, like, the various other people around model.
And, sort of, the basic insight was that, like, we need an app that people can actually use day-to-day.
And that's why we started, like, a text editor.
That's the one thing we do all day is, like, take notes.
So, like, sort of collaborative note-taking seems like a good, concrete case.
And also, it seems like a good thing to, like, actually test all of the UI patterns.
And, sort of, things that we're going to need across any local first app,
because it's, like, a pretty, pretty generic thing that you can use for all kinds of stuff.
And it started as, like, just sort of, a hack fest, where we, like, experimented a bit.
And then, eventually, like, as part of an anomaly grant, Julian, who's there in the back,
expanded it to a slightly more real app.
And then, over the past six months, we've worked on this as part of a prototype fund grant
to, like, get to a first release.
And, yeah, that's sort of where we're now.
Current state is, it is a fully native GTK app.
You can install on your Linux machine, or hopefully soon in my class.
We have some builds, but nothing published yet.
And it works for all of the basics.
It's a pretty simple, like, app, right?
Like, it's a text view that sings.
But behind that, of course, is a gigantic amount of technology that needs to all work together
in just the right way.
And we're really happy that, like, we got those, those basics to work,
and that we can now build on it.
And we still have a few more months of funding under prototype fund.
And as part of that, we're going to focus on both stabilizing that,
and, like, doing some user testing, and, like, sort of seeing where this project
needs to go in the medium term.
But also, we're really interested in ecosystem side.
So, like, one of the next things is G object binding.
So, like, the app is written in Rust, because P-dependence written in Rust.
But if you want to use it in a Python app or in a JavaScript app,
you're going to need G object bindings.
And so, that's going to be one of the next focuses.
So, any GNOME app developer can just use this sort of for free.
And then we're also going to work on developer documentation to make that easier.
And also, if you're interested in this, maybe Bookmark March 236,
we're going to have a series of online events for developers
where people can ask questions, and we work through the problems
and questions people have.
Because it is really important to us for this to, like, be, sort of,
the beginning of an ecosystem rather than, like, this one app.
Like, it is more about those ecosystem effects to us.
And also, as part of this project,
we've done quite a bit of user interface research,
because a lot of the questions around local first
are also not solved from a user interface,
one of you, not just, like, from a science point of view.
And to us, like, sort of, the idea of, like,
solving these, sort of, as UX patterns,
was also really important.
And so, in addition to the stuff that we built,
we also did quite a bit of exploration around stuff
that we might want to do in the future.
For example, Peter Pond already has, like,
most of the technical side of access controls
and permission management.
And we also explored, like, how this would be integrated in reflection.
And then, sort of, as an extension,
how this would be done in any, like,
local first GDK app.
Another one is revision control, often, like,
whatever, if you go offline for a longer time,
maybe you don't want to, like, just randomly merge everything
back when everything together when you're back.
Maybe you want to, like, sort of, consciously branch off.
And there are a lot of, like, UI questions around how
would you do this for plain text?
It was one question for more complex things.
It's quite another question.
And that's also something that we started exploring
and would be really interesting to look into more.
Another one is zones.
This is one that we're hearing a lot from the people
who actually are using the app.
Like, having to have every single document
beats on network, which is currently the case,
has some downsides.
You always have to have it open.
And one of the ideas is that you just have
these shared folders that, like, sync all together,
rather than just, like, per document.
And so, yeah, we did a lot of exploration around that.
And the important thing for us is that we saw
these problems in a way that, like, sort of,
can ideally be inherited by the rest of the ecosystem.
Maybe, eventually, as part of, like, some kind of widget library,
where you just, like, get this little popover for free.
And one concrete example for this is that last year
at Guadak, Yakum and I were designing a new app
that is currently still working progress,
but Georgia is working on it here.
It's, like, a presentation app.
And they were like, but what if we had collaboration?
And there was, like, sort of, copied the UI
for the collaboration thing in from reflection.
It just made sense.
And sort of, I think it's a good example
that, like, most of these apps are quite similar in this sense.
And we hope to, sort of, yeah, make this possible for more people
essentially without having to know about the local first that much.
And then, sort of, like, I guess the next step
is to bring it even more into the system
and for that, I'm giving it back to the Andreas.
Yeah, exactly.
So, looking at all of these patterns
reemerging, of course, we can ask ourselves,
I think, we all do, like, okay, is there, like, some patterns
we might just apply on a host level.
So, host basically being a host environment,
which, like, hosts multiple apps.
And, of course, the operating system
would be a good choice for that.
And, yeah, so we've been, like, brainstorming a little bit.
This is already, like, a process of, like, the last two years.
Like, how would that play out?
Like, obviously, one thing you may be want to do
is, like, organize your context
on some way on operating system level.
Like, you know, you have free of public keys every year.
Or, yeah, hash is already IDs.
What if there is, like, a contact book application.
And, you request access to that application.
You add, like, some application can be written
and anything.
It doesn't even need to be peer-to-pender.
Just request access to it.
And, then, the user can give scope access, like, say,
okay, I only want to share, like, these five contacts
with this application.
And, then, the application retrieves it.
And, that's what everybody needs to do with this material.
So, this is, like, one very concrete solution
for, like, something we can sort on the host level.
We, of course, want this to be, like, as private as possible.
We don't want, like, unnecessarily, like,
link, you know, people to, like, imutable data records.
And, then, that across all applications.
So, this is a tricky challenge.
Obviously, pad name systems will be play a big part in this.
And, something we call, or, like, which came up in the peer-to-peer
browser group last week, like, something, like, maybe lazy identities.
So, you don't want your data to be linked across all everything.
So, you only want to reveal it, maybe, on demand
when it is actually necessary to have it, for example,
for access control.
So, here, again, like, some beautiful wire frames of tovy.
Like, this is now just, like, jam on, like, what this could look like.
Maybe interesting to highlight is, like, yeah, you can add the context of how you met that person that might be interesting to,
to keep around, like, you see the devices, like, which are connected to that identity
because I think multi devices still have a big issue.
And, and something we need to think about, and then, like,
the documents, like, you share with that user.
Think, obviously, something we all need, at least if you are
application once, eventually, consistency guarantees.
So, that would be great to have on the host level as well.
Of course, the application doesn't even need to, like, think about this anymore.
It just, like, subscribes to a topic or something.
And, like, it receives, like, the events it needs to have.
I don't, I don't think, I think, probably your all agree.
We will not agree on a super sync protocol, which everyone will be happy with right now.
I don't think we are there yet as a community.
But maybe we can slowly agree on, like, interfaces.
How they might look like, because they might look the same.
So, this is going in a little bit in the direction, also,
what the people from Delta Chat have been doing, like, the web XDC,
where they try to simplify the interface so much, and then, basically,
it doesn't really matter anymore once again, where the events come from,
the event delivery layer is abstracted away, and that can be very different
implementations.
And, we try to get in that direction as well and think how we can maybe,
at least express an API here.
This is, like, just research.
Another thing are, like, support nodes.
Some people call them relay.
Some people call them always online nodes, like,
there's definitely terminology around.
This is also awesome to do on an operating system level, right?
Like, you can actually, like, share it across apps.
You don't want to leak any data.
It should be, like, fully encrypted.
And, that phone, that device doesn't even need to be a server.
It can just be your post-market OS device.
With a solar panel attached, and that could be already like your support node.
Of course, we want this to be multi-transport.
Yeah.
And, this is now part of a grant.
We receive from an LNet, this sort of research and development.
We're going to start around May.
And, as I already mentioned, these are many open questions.
And, yeah, we very much invite you to join us here.
We also have this event happening now in a couple of weeks.
And, this is one of the ongoing events series of the model collective,
where we specifically are going to talk about identity systems, like,
Kate, DM, and Eileen Wagner will be invited.
And, yeah, we also going to talk about the Worker Wasteck.
And, also, all the other usual topics.
If you're interested in post-market, or, yeah, a curl, stuff,
or a system-d or a GNOME design, you're also welcome.
Yeah, it's always a fun time.
Yeah, thank you very much.
Thank you.
Thank you very much, Les.
And, Tobias, we'll take questions in the room.
Do we have questions on the Internet?
Please raise your hands.
All of you.
Now, so I know how many questions we have.
Two.
Okay.
You can still think about it.
Hi.
Sorry.
Oh, okay.
Yes.
Oh, yes.
Oh, okay.
I understand.
Thank you.
So, I maintain an app called Multiplex.
That you just can use to like, stream, like, see, watch Torx together.
Very sources.
And, like, I had to get a, like, WebRTC base, like,
like, is he side channels?
You can, like, synchronize, like, playback positions.
Membership and so on.
And, and, and, I'd be curious to see, like,
Cundee, I used, like, bit Torrent, and, like,
what do you see, like, two different protocols.
And, like, this is a chance of peer-to-peer, like,
could do this, that could, for example, stream the actual video,
as well, like, this is a way, or a story to do that.
Yeah. I think that's not a peer-to-peer,
but, actually, like, lower level, like, on the transport,
because they really don't want to have any overhead,
when you do streaming.
But, I would look at IRO, and, and,
there's currently an experimental repository called IRO live,
which actually does all of that on top of the quick stack.
And, I mean, get upon the has.
I also built in, so you would basically talk the exact same APIs.
Where peer-to-peer would help you, is, like,
all the data you may be want to organize around your session,
like, you know, who is online, what are we watching currently
together, all of these sorts of things.
But, like, the actual streaming I would do on the quick stack,
maybe with IRO. Yeah.
Thank you.
Hi, thank you.
You're not here.
I wanted to ask you.
So, of course, this project is a very opinionated,
and tightly linked to the economic system,
and especially GTK.
So, I'm wondering, as right now,
the app is usable strictly on Linux,
and you're planning on MacOS.
I was wondering about interface plans that you have,
especially, I don't know, Android,
IOS, to broaden the applicability,
and use a job reflection beyond the Linux,
and specifically, you know, my ecosystem.
I mean, like, GTK works on Android now,
I hear.
No, I mean, like, obviously, having this
app specifically work on more platforms is cool,
but like, there's no reason why you couldn't build
a native client for other platforms,
that called reflection or not, like, that's totally possible.
And in fact, there is already an experiment
to sort of make it work on the web.
We have some experiments running it on the web browser,
and also, I mean, I think what would be nice
to agree on, like, a common way to do text editing,
of course, I think the people from team type
are thinking in that direction.
So, yeah, if there's, like, a common protocol
on how to describe, like, text CRDTs,
then it would be fairly easy
for them to have different ways to speak
to reflection on different platforms.
Yeah.
Yes.
Question here.
Do you think that just matter?
Yes.
I have a question.
So, you're doing, like, a great deal of design
and UX in your work.
And I was one, and at the same time,
you're trying to do new products, new solutions.
I was wondering, couldn't be interesting
in that such people, like you, that do great design,
actually work on solutions that are already
heavily used to make them better,
instead of trying to make new products,
which are going to then fragment more
the open source ecosystem.
What are the existing things?
Well, they might not fit everything you want to do,
but I'm from CRYPAT, for example.
We could do much better in design,
but we don't necessarily always have the scale
and the help of the people that have the scales.
And when people kind of say,
oh, it doesn't look good enough,
then then go to solution that do way less than what we do.
But then are looking nice, which is great.
It's cool that there are new solutions.
But why don't they come to help?
Why don't more people come to help on design
to make our solution better?
Speaking from myself, I don't want to name myself.
Sorry.
No, sorry.
Speaking of a solution designer,
if you use GTK, then I'm all yours.
If not, let's imagine.
Hello, answer.
Is there any doubt about questions?
Well, I'd like to answer.
We have one minute.
Is the last question?
I was wondering to what extent this stack is also
allowed could work on a mesh, right?
Not just peer to peer, but peer to peer to peer to peer.
Like sending messages across multiple hubs.
Is that possible?
Yes.
So this is what I hinted on the post-internet sort of as light.
And I'm going to give a lecture as a talk on that in at
3.30 in the decentralized internet and privacy room.
I think it's about exactly that topic.
And basically showcasing how these things are maybe the same
depending on how we look at it.
Really exciting.
We're staying here, aren't we?
Yeah.
Thanks again.
Thank you very much.
Thanks a lot.