Let's welcome the next speaker, it's Fintan, who's going to talk about radical, local
first code collaboration.
Let's welcome him.
Even better.
Yeah, it's my first time to pause them.
Thanks for sticking around this schedule.
It's so stacked, like it's crazy.
Thanks Nico for organizing everyone else.
Yeah, it's amazing.
I'm Fintan, I work on radical as a maintainer.
I'm like here about local first digital sovereignty, functional programming, and also
like during handstands and calisthenics.
I've been working on radical for six years, just over six years now.
So I'll take you through some of this.
But first, I'd like to say happy Saint Bridges Day, because I'm Irish.
Yeah, a great day for fertility, first day of spring, up women.
So before I get into radical, I have to say that I got into open source software
by working on open source projects on GitHub.
GitHub is the home for open source.
Bush lately, it feels like it's a shaky ground or a shaky foundation that we're building on,
because Microsoft acquired it.
Microsoft is a UF owned entity, and that has implications.
I'm lucky enough to be based in London now, Bush.
In Ireland, and I've never been bound off GitHub, but all there has been due to their
geolocation.
Not only that, the CEO of GitHub stepped down recently, and GitHub is under the arm of the
AI division in GitHub, or in Microsoft.
And they've trained their co-pilot AI on our free and open source software.
So what can we do about it?
Well, GitHub is already decentralized.
This is amazing.
And Bush, radical, does is adds a decentralized network layer on top of that, as well as
bundling the more code collaboration or like the social artifacts inside of GitHub and
disperses this through the decentralized network.
So my colleague Lawrence is in the decentralized internet and privacy room.
He would have talked by now on the whole decentralized element of radical.
So watch the recording of that, but I'll get into more of the code collaboration and local
first end of things.
You might remember this phase from earlier.
Briefly Alex worked on radical.
I was sorry to see him go, but it's okay.
He's better off there.
But he pioneered what we call collaborative objects or cobs.
And these are local first CRDTs that were bundling in GitHub.
So how radical is kind of laid out is we use or abuse Git name spaces.
Every peer has their own name space.
So the simplified version here is got Alice, Bob, and Eve.
And they have their own set of references.
And references just point to commits.
And so in this case, we can jump to the idea of them having a reference to a particular issue.
If we then combine those references, we can create the commit graph.
And we get this graph of an issue where we can start off with a title in the description.
Alice might make one comment, Bob might make another comment in parallel.
Eve labels the issue and so on and so forth until it gets closed.
So the commits contain operations and operations have actions in them.
But then what we need then is to be able to walk this graph.
We do it in a like topological sort with some type breaking and produce some more consumable JSON.
So this is what our like CLIs or web interfaces use to present issues or patches.
One problem with that evaluation function is that one way to do it is through native rust through our library.
And in other ways through the CLIs or through like user owned binaries.
So this gives access to like file system, IO, anything can be like executed.
So this is one problem I'd like you to keep in consideration for a later slide.
Another problem is that all the existing hubs are mostly defined by us at the moment.
So we have issues, we have patches, we have this idea of an identity for repository that's also a Cobb.
And we have the job Cobb which is for like CI, CD kind of stuff.
But as far as we know the others is the empty session.
So in the future we'd like to make this a bit easier.
I might just do a quick show of my terminal to give you an idea of what that looks like.
So here I'm in the heartwood repository with this is where we write the radical protocol.
And if I run rad issue, I can list out the issues.
And if I do rad issue show.
We can see the text, the author, some labels, it's status.
We've got the same for patches.
Something interesting about patches in radical is that they're immutable.
So each revision is a mutable change based on the last one, which is a nice feature because we can interchange revisions easily.
And rollbacked or like choose ones like previous ones that might have been a better implementation, but someone experimented with the revision.
Let me go back.
So something I've been thinking about for the future is maybe using WebAssembly for these Cobbs.
The idea is kind of like a plug-in system.
So WebAssembly kind of gives you the a little bit more security.
One idea in WebAssembly is like this idea of fuel.
So the executable drains from the fuel reserves for each operation.
So it can't run forever in a recursive loop ruining your system somehow.
And another aspect is that it can't access IO.
I think there are some like proposals for interfaces, what their capability based.
So and then also these like binary executables could also be distributed through Git as well.
Maybe hide in them inside Blobs and this makes them distributed through the network as well.
That's more of an idea right now.
We have an experimented with it.
But if anyone is more familiar with like WebAssembly, please come talk to us.
But that's it.
That's kind of the run through of local first experience,
but if you go to Radical, ICLE.xYZ, there's links to our Zulu,
where we chat about the protocol itself.
And yeah, come chat to us, come try out Radical.
Let us know what's not working, what's working, and everything in between.
Thank you.
We're going to take questions.
There is five minutes of a question for Fintan.
Yes.
So how is replication of potentially unwanted artifacts from third party?
It's from third party peers.
Like say spam issues or other content.
Sure, yeah.
That's a good question.
Get that a lot.
So part of it is just a kind of policy system.
So when you notice a node that you don't like,
you can rad block to add it to a block list and your node will start filtering out.
It's pretty rudimentary right now,
but we want to go that up into our richer ecosystem where people can build maybe more automated tools for detecting that.
I'm just doing it for you or even exchange in block lists.
Can you like retroactively get rid of stuff that's been like added that you don't want?
There are ways to like, yeah, it comes to delish prides of cobs, but it's a little bit hard because it's a get graph.
So those objects lie around and you'd have to do some more manual forensics for the giant being.
Yeah, thanks.
Good question.
What were chances?
Yeah.
Thank you.
So the question is about accessibility.
Because I found this is pretty super cool.
I really would like to be able to embark on it.
Yeah.
But I am a little bit worried about the accessibility considerations.
So to give just one example, the script that you used to install.
I was reading it during the talk.
Yeah.
Well, you used colors to mark errors.
And the second example is like, you used zoolip to communicate.
I'm not sure it's the most accessible way to communicate actually.
So do you consider moving while taking accessibility considerations into account at all the levels of the project,
including the communication means?
And for instance, I assume that metrics would be more like it's a higher chance to be accessible right?
Right.
My nature.
Yeah.
I love that question.
Thanks.
And I appreciate that.
Like, I, so to speak blind to these problems.
Because I don't have accessibility issues.
And we're a very small team.
So it's something that I'd love to see.
But I don't know where to start with that.
And I didn't even realize that through the paths accessibility issues.
Yeah.
If you want to chat about it more, I'd love to hear your thoughts.
Yeah.
Thanks for watching.
And I mean, everything was on the slides.
But the slides are not on the page of the conference.
I'm kind of stuck.
Yeah.
Thank you.
First of all, great talk.
Thank you.
And just a comment, but hopefully not an annoying one.
And it's that I do have a assembly like a lot for my job.
So you certainly pick my interest.
If you want to talk about assembly sometime and need advice or anything.
Yeah.
Please.
We should be to chat.
It's, it's called that you're using it.
Yeah.
Do you ever get examples of source code getting lost?
Because the page will go offline?
No.
Yes.
Yeah.
And we have the benefit of people hosting like super seed.
So replicating the whole network.
Which is a fantastic size of 50 gigabytes or so right now.
Yeah.
Next question.
Yeah.
Two actually.
The one is,
What is the scale?
What is the amount of issues that you have imported into radical from an existing project?
If that is something that has happened?
Sure.
And the other one is, if you say, have a, let's say, a primary or,
Let's say, a official repository somewhere,
Yeah.
Can you decide who gets to send you stuff?
Yes.
I'm going to cheat and tell you to watch my colleagues talk recording.
Because he's actually got some graphs for numbers.
And then the second question is, again, yeah, there's like the policy system.
So we actually host our own nodes.
That is locked down to repositories that we care about only.
And don't let the rest of the network come in.
Yeah.
Thanks.
Thank you.