Willow

Oh shit.

Oops.

Okay.

Wow.

Okay.

Let's get going.

Um, I'm going to go on my snack.

I got so excited.

I'm going to go on my snack.

I got so excited.

Okay.

Oh shit.

Oops.

Okay.

Wow.

Okay.

Let's get going.

Um, I'm going to go on my snack.

I got so excited.

Okay.

And a little bit.

Yeah.

You're going to ask me to introduce myself and my project.

I think that I'm going to be awkward, right?

But it'd be so fun.

I didn't mean to be thinking.

It's been recording for like, two years.

I'm going to be like,

I didn't mean to be thinking.

I didn't mean to be thinking.

It's been recording for like,

fifty minutes though.

Yeah.

I know.

I know what you've been doing.

Okay.

Are you concerned?

Mmm.

Wait.

I know you've been preparing me and teasing me into it.

I've done a marvelous job.

But I have been aware of it.

Okay.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

Yeah.

And the music you just heard was a creation by our guest today, which is Aliyosha from the Willow Project.

Throughout the episode, you might hear a few more tunes gathered here and there.

And if you want to hear more, just check out their website, worm-blossom.org, which they

host together with Sammy.

Today, we will be hearing a bit of a more, I guess, Aliyosha called it theoretical computer

science.

Take on these kind of protocols and specifically a walkthrough of Willow and what makes Willow

particularly secure compared to most other protocols in the scene.

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

Thank you so much for joining me here today, Aliyosha.

We have been chatting away for a solid 20 minutes already.

And now it's time for the official podcast.

So you and I have known each other for quite a few years now.

True.

And it started in the, I want to say infamous, but it's not very infamous.

It's more like famous, but it's also not famous.

It should be infamous.

And what we're talking about is of course, it's got a lot.

For those who have no clue what's got a lot is, do you want to give a quick debrief on

the sailor's network?

Oh, no.

You get an unusual debrief on that if I'm the one to do it.

I'm sure I can give it a try.

So in a year that might have been 2015 or something, a person in New Zealand named Dominic

Tar decided that the world needs better technology for certain things, including social networking.

I mean, actually you wanted to build a package manager, which is something I can deeply relate

to, but it got derailed a bit.

So secure scatterbout is this protocol by which people or rather their computers can

exchange information in a way that is not dependent on their always being a direct

internet connection available.

So Dominic basically lived on a sailboat and didn't have internet for very long periods

of time, but that shouldn't stop him from just writing down stuff like in a diary and

maybe later just synchronizing it with other peers.

That's what scatterbout is essentially.

You write a kind of diary of entries and you tell your computer who your friends are and

then the data is automatically exchanged between you whenever there's connectivity and crucially

that connectivity doesn't need to be direct.

So if I wanted to see Dominic's post, I wouldn't need to connect to Dominic directly, but rather

I would just need to find anyone else who already had Dominic's post and then I would

be able to receive them and also verify that they had not been altered, that they really

were what Dominic had intended.

But why not just use internet though?

Why it works over the internet potentially.

What's the difference?

Why don't you just like Facebook message someone or something?

Right.

Right.

So it might come as a bit of surprise, but I'm not terribly fond of Facebook and neither

was Dominic Tarr.

So hi, come on.

Because you actually gone quite far with that.

Do you have a smartphone?

I do.

You do.

Yes.

I've never seen you use one.

That's correct because you've never seen me being controlled whether I have a ticket

in public transport in Berlin.

That's why I have a smartphone.

Oh, so it's kind of forced into the system aspect.

Yep.

Yeah.

Makes sense.

But yeah, it touches on the whole bigger picture of things though.

And while we met on Scolobot, you are currently working on a project called Willow, which

is the next generation of these kind of networks that would work even if you're out

sailing on a sailboat and you don't have access to internet but want to communicate with your

friends.

So first of all, if we skip the whole Y of like, okay, Facebook is horrible.

Surveyor of the state, society, you know, of these things.

I knew this wasn't Blizzard and I wouldn't have to say it.

Yeah, they are.

But if we then dive instead straight into Y Willow, because that's not as implicit.

Fair.

Why did you start Willow when Scolobot was around?

So first of all, it's difficult for me to answer that because I never sat down and said,

these are the three reasons that make me want to do this thing, right?

Instead, it's a whole set of feelings and drives that lead into putting the time into

this.

But as far as I have managed to identify, like career and concepts in what is driving me,

I would say the two primary ones are the fragility of the default way of going about it and a

sort of carelessness toward users, where tools can be turned against the users.

And the fragility aspect of it, that's what we just, you know, move to the sidelines as

being implicit in Facebook's bed for multiple reasons.

But I mean-

So when you say fragility, if I'm translating it into my own terms, just to understand, does

that mean like security risks?

And like, or what do you mean with fragility?

Not necessarily security, but just we are dependent on certain information technology,

right?

We treat it as infrastructure and we treat it as being there and working and stuff starts

breaking in the real world once computers start breaking, which is very wild if you consider

the role that computer plays 40 years ago.

And this fragility, like one of the most basic aspects of course is just when Dominic

on his boat doesn't have an internet connection, he cannot send stuff to the Facebook server.

So that's not going to work.

So in that sense, it's very fragile, it depends on always available internet connection, right?

But then also, it's fragile at really every single part and every single link of the chain

that leads from a sending message to be receiving message, right?

It goes through a single server that server might be hacked, there might be government

regulation that forces it to shut it down.

And the idea of these local first peer-to-peer projects that kind of unifies the whole space,

I think, is to combat that fragility and to replace it with a project that actually

more inspired by nature, I would say, where there's a lot of like optimistically trying

things out in many directions at the same time, right?

Which can be as simple as optimistically replicating the data across many machines instead of just

a single direct path, right?

It's very natural for computer scientists to say, let's find the one shortest path and

send data that way because that's the most efficient.

It's also the most fragile thing you could possibly do.

All the peer-to-peer projects or most of them are going away that tries to avoid this

fragility, right?

And in the infamous, hopefully, Scuttlebutt, especially in the early days, there was the

saying of no global singletons and rejecting every entity, every concept of which there

would be only one and on which you would be dependent, which is not...

What's like...

Okay, so I know singletons is like...

Because we talked about this in previous podcasts, in example, a singleton, like in one way one

could say a centralized server, but in another way one could also say DHT, right?

Like a distributed hash table.

Exactly, or a blockchain, right?

So there is kind of shades where the peer-to-peer projects position themselves along this axis

of how thoroughly do you avoid global singletons.

You can...

I mean, you can go pretty far.

You can say there's only one internet.

You shouldn't use the internet.

You should use any kind of available network.

That's a rather extreme way of taking things, but it's also kind of sensible, I would say,

it makes sense to not hard code dependence on the internet and to your protocol.

Yeah.

Right, and like...

And this is why we're those, right?

Well, that's one side of it, but really if all I cared about was not having global singletons,

then I was to be unscattered but, because scattered but is probably the most pure experiment

in this regard that actually gained traction.

But then the other aspect that I mentioned beyond just fragility would be, well, essentially,

the ability to webinise the network, the system, the tools against its users.

And this is what you mentioned with Care for People.

Yes.

Yeah.

So rather than being enabling webinisation of the network against its users, you're trying

to take an approach of Care for People.

But what does that mean in practice when you're building a protocol?

Because it's not like, is it more heart emojis?

Maybe you should about that as a strategy.

You know, there's at least five differently coloured heart emojis, right?

And so you've just encode everything using different colours of the heart emerging.

We might be onto something.

It's not exactly human readable, but as a human, whatever you look at, you get a good vibe.

But we are actually slightly onto something, because if one looks at your website, like

Willow, and you're also a personal website, is it worm.blossom?

Worm-blossom.org.

Worm-blossom.org.

And where you have this expression, which is also very much thanks to your co-creator,

Sammy.

And she is a fantastic cartoon artist.

And so it's a little protocol.

Comic artist.

Oh, comic artist.

Sammy would yell at me if I didn't jump in here right now.

What's the name?

You'd have to ask Sammy that.

But let's just call her an illustrator.

Okay, illustrator.

Well, she's a fantastic illustrator, and like the whole Willow protocol is very well documented,

one of the best of its kind.

Which is something we could talk about, and we will talk about pretty soon.

But is this also part of the care you're talking about?

No, and yes.

Okay.

I don't know.

Feelings are mushy things.

Okay, okay, this was actually before.

I slightly interrupted you by raising my hand.

And that was because you keep coming back to your feelings.

And me as knowing you, you have a lot of feelings, of course, as anyone does.

But your feelings are often seemingly, intuitively connected to deeper thought.

Because something that the listener might not know,

you are not pure developer TM.

You're actually like a mathematician, right?

Well, technically no, but...

And a musician.

Well, technically no, but...

Yeah.

Actually, no, I shouldn't do that.

Yes, I said identify as a musician.

Yeah.

And screw labels.

So yes, I'm a musician, damn it.

Yes, you are.

But no, I like the proper training.

Like, I don't know enough analysis, and not enough topology to call myself a mathematician.

I'm sorry.

Yes, the maths computer scientist I've taken a fairly theory heavy

and maths laden route.

Let's phrase it like that.

Let's phrase it like that then.

But when you talk about feelings,

are those feelings maybe also connected to,

okay, I'm trying to remember the terminology we just used,

but like these theory-laden perspectives that you also hold?

That's a good question.

Like, I've...

I've always been very guided, both in which things I'm exploring

and in which shape that exploration takes,

by a sense of aesthetics almost.

Like, seeing solutions that are not beautiful

makes me want to replace them.

Which is both a strength and a curse in some sense.

It's a strength because it leaves me dissatisfied with things that

many other people who don't then develop their own protocols from scratch

will just accept.

And I do think the problems are real that we can identify there.

So it's good to have a sort of innate motivation to try to improve on things.

Right, so that's how I would say it's a strength.

And I guess it's a weakness in two senses.

One, purely in the conventional academic slash mathematical sense.

That's not a valid argument.

Right, so communicating stuff needs a different kind of work.

And two also, sometimes reality is just messy,

and I need to stop myself from considering messiness as unappealing or unaesthetic.

But I think this is also...

Okay, this is a weird maybe relation to Mink,

but there's this anime called Orb.

You've never heard of it.

No, it's a quite nice anime I would say.

But the topic of the anime is about mathematicians who started

looking at, is it called the heuristic bottle?

The basically that the sun is in the center and the earth is rotating around the sun,

which was like a thing only have herrhetics would say back in the day.

Oh, is it a place of Poland?

Good question.

I don't actually know where geographically it is, but one of the perspectives that I

keeps coming back to is that these mathematicians that were looking at

what convinced them was the truth, even though they had enjoyed getting killed for it,

because they were saying something that was going against the word of God, so to speak.

They kept coming back to the sense of beauty and cleanness,

and that's something that me, I've never been able to relate to,

because I'm not a mathematician, and I haven't dove deep into that space.

But I'm also understanding that as an artist, I'm not like someone who speaks the language of math,

so to speak.

There is a sense of an a beauty that isn't necessarily a rejection of messiness,

but it can also be the beauty of nature.

In many ways.

I mean, I do know that being guided by a sense of beauty is fairly common amongst mathematicians.

Like, I'm not the weird one out there, at least not amongst mathematicians.

There is a beautiful piece of writing called Lockhart's Lament, which does a good job of conveying

the beauty in mathematics to non-mathematicians.

So I'll ask you to put a link to that into the description.

Also, how did we get here?

It feels like a vast change of it.

The starting point of this was how you're weaving in illustrations and weaving in your own music is

available on word.org, or word slash blossom.org.

And you're taking this approach to your work that is rooted in care for people.

And care for people is multifaceted.

Yeah, and accordingly, I can take my answer to very many different directions.

Let's start with the answer that doesn't lead us immediately back to where we actually started

from, but let's go somewhere completely different.

Not completely different.

So the comics and the music and the playful updates are a form of self-defense.

Because working on this stuff is difficult and it takes discipline and it takes a lot of time

that you cannot put into other things.

And especially if you are on a deadline due to grant work, for example, and you need to just

deliver this feature because food costs money in our society.

I had that that takes us tall and like we've reached multiple times points or at the very least

I have reached points where it became very difficult for me to actually do the work

despite having obligations that we should do the work.

So at some point, Sam and I sat together virtually in a call and talked about what we might do

to help us with that and to bring more joy into the process.

And this started with me suggesting let's do a dev diary, which is actually a tradition

we took from Scuttlebutt, where people would just post regular updates on which work they

have been doing.

And so we never developed this concept of let's just do weekly updates about everything we've done.

And it's funny. So I proposed that and Sammy was not amused. She didn't like the idea at all

because it was adding more work, which was not the work we were supposed to be doing.

There were other factors involved.

But let's leave it at that.

And so she took one day or two days of mulling it over and then she came back to me and said,

okay, we can do this, but then we have to do it right, which means making it exuberant and

actually expressing stuff beyond just the updates.

And then it was clear from the very start that she would be drawing effectively a webcomic.

And then that I would be doing background music for it.

So that's where that started. And then we ended this period of just being highly

motivated. And we used our own build framework for generating the website and we built that

we kept building on it. And that led into a very virtuous cycle where I at least suddenly wanted

to get work done so that I could post about it because it felt good. And also just having

the weekly update to work to work across the week.

It gave you a bunch of mini deadlines, which are great for motivation.

So that's how that came about. And then people seemed to like it,

which was also like when we realized, oh, there's people reading this. This is weird.

And there's people interacting with us because of this. Like we have a community, it's on Discord.

For now, it's obviously going to migrate to a Willow alternative. But no, people are showing

up there. And then we did this experiment of posting a little help wanted snippets where we'll say,

hey, here's an easy task that we could do. But also someone else could do it. And people started

doing these. So yeah, the whole site just like this website. It's been a good thing.

And it's still fun to do. And we're still dreaming up stuff we want to do with it. And then need to

balance that with the reality of putting too much time to the website is also maybe a bit

of an unwise decision. But yeah, so that's a huge tangent on why there's drawings and music

on our weekly devlog website. But now to come back to the other aspect of care for users. I mean,

it's parents. Basically, we have a responsibility. We design protocols that we want to be used by

non-technical people. We don't want people to use an application because it's built on top of

Willow. We want people to use an application because it's a good application. And ideally,

that application is built on Willow. And thus, the users inherit certain benefits. They're not

necessarily aware of. And hopefully they will never need to be aware of them even. It should be

invisible and getting off point. Well, actually, that's a great timing of you getting off point.

And because I'm a little bit curious here, because you mentioned that the user would inherit some

specific benefits without necessarily having to be aware of what specific benefits they're getting

from using an application that's running over Willow. But I'm curious here, like,

when we started this conversation, they were comparing with Scuttlebutt. But not everyone

was Scuttlebutt. So just to start off, what are the benefits of having an application over Willow?

What are the different qualities that come with that?

How does it differ from making a regular web application? You know what I mean?

I mean, regular web applications are fine except they're fragile. I think the more interesting

part is once you leave all that fragile stuff behind and move into the peer-to-peer world,

and then the community over the past decade or so, decades, technically has done a very good job

of building anti-fredgile stuff or, you know, some communities. Are you referring to work by

Taylorview, like anti-fredgility stuff? Not consciously, so. Oh, cool. Okay. I am roughly aware of that work.

But no, I just meant it's not fragile. It's an intuitive term. Yeah. Yeah. Which

holds high to tangent, loading very specific meaning, like technical meaning in a specific context,

one to very intuitive terms. It's a great cause for miscommunication. Yeah, that's very true.

So. We're staying focused. We can do this. I'm going to stay focused now. You don't have to stay focused.

So no. What? No. Why didn't you say so from the very start? So this morning, breakfast.

What did you have in a breakfast? Serious. What are we doing? Yes. What time?

How did they differ from other cereals? So why you should use Willow? Why Willow is better than

everyone else? No. Here we go. We actually had a conversation about this just last night because

we were out at a bar. Indeed. Our listeners don't need to know that. I mean, just organically replay

that full conversation. But I don't know. Okay. Since I was a slash sarcasm,

friend one who didn't pick that up. I'm not Gosh's voice.

Well, I thought we were just going to edit that out. But thank you very much. No, no, no. This is

staying. 100%. Yeah. Maybe we can just edit that into two parts like comedy episode.

Okay. Insert Jingle from Aliyasha. Oh, no, you meant editing. Darn it.

So welcome back. Now we're staying focused. We sidetracked. Now we're going to sidetrack into

two other topics. But before we sidetrack into two other topics, we're going to continue on the

thread of the qualities that are inherent of a protocol such as willow and maybe specifically

willow. Let's start with like what's protocols like willow, which are usually like routing agnostic,

which is a term, but basically that you could use it over sneaker net, like put stuff on USB or

that you could put it on a route, your data, the image network or Bluetooth and bounce it between

phones or the regular internet. And now we have the peer-to-peer quality. And then we also have

the local first quality. And like willow is from my perspective, a very classic example of like

a peer-for-peer application or a protocol. Yeah. But here's what we're trying to provide beyond that.

We are trying very hard to enable features such as strong deletion, deletion of metadata,

user agency over which stuff propagates where and how to get rid of it later.

So number one, on a regular application, I can just delete my data. Why does that matter?

You can delete your data. Wow. Why have we thought of that yet?

No. So here's the thing. There's several facets to the question of deletion in distributed systems.

So once you put something on the internet, anyone might have it, right? Like it might be downloaded

by somebody else. And if you then delete it on your machine locally, that doesn't really help

because it's still on different machines. And you can ask other people nicely to also delete

their copies of the data. And if all of them comply, then yay, you deleted the thing truly.

However, if somebody took a screenshot and printed it out, then no computer protocol is going to be

able to break into their home and destroy that printout. So there are certain limits to which

forms of deletion you can achieve. But in this peer-to-peer space where one of the core tenants

is essentially that data stored redundantly on multiple machines. And you don't really know

in advance which machines those might be. There is a very tempting way of going about deletion,

which is just to give up on it. You might say, well, in no chance, you can't force people to

delete it. It's open source. They might just modify that client and not delete stuff.

So why even bother? That's one approach. And a surprisingly large number of protocols takes

that approach and makes choices in their data models. So kind of that choices, that's it at the very

heart of how you insert data into these systems that rely on deletion, not really being a priority.

Right? Scatterbut is... Well, it should be infamous for many reasons. One of them is that

its core data structure, essentially whenever you post new data, the new data contains the

reference to prior data. And Scatterbut says you have to kind of check the validity of that

reference. And that also includes changing the validity of, well, the thing you're referencing,

that references thing before it as well. So you have to check that step as well. And you kind of

have to step through the full chain and verify everything, which means you can't delete anything.

Everything has to be always available in order to perform this sort of verification.

So Scatterbut is inherently unable to delete stuff up to certain caveats.

So basically, on regular internet, it's difficult to get something deleted because

whomever could download it. On Scatterbut it was essentially an inbuilt function of the protocol

to make sure that things did not get deleted. Yes. And in Scatterbut, like the data structure

is called an append-only log. And more recently, there's been a lot of protocols exploring stuff

like Merkeljags, which is roughly put a generalization of this, where instead of having only one preceding

thing, you need to validate, you kind of multiple things you need to validate.

That's very rightly speaking, what a Merkadag is. And yeah, all of these are very

anti-deletion in some sense. And I'm not buying the argument that says, well,

don't expect things to go away if you've put them on the internet. Like, just don't

put things on the internet then. But I do want to put things on the internet. And I get it can't be

that black and white. So at the very least, the protocol should be able to, like, I should be able

to signal intent, I would like this to be deleted. Because sure, there might be malicious peers

who will not respect this intent. But you know, most human beings are kind of okay. And also,

most human beings don't modify this software. And they run their computer. So

I actually think the prior is more important. But any of yeah. Anyway, so if most people

do honor deletion requests, so if I post something and then I later delete that,

then the malicious user has to obtain the data kind of in the window where it was not yet deleted,

right? And that window relative to the duration of the universe, that window is going to shrink

and shrink and shrink and shrink. Right? Like, even if it's been online for two weeks before I

deleted it for two years, like in 50 years time for the vast majority, it should have been deleted.

And this becomes especially important because like one of the use cases that we saw in Scuttlebutt

was a lot of the networks where Scuttlebutt suddenly saw uprights and downloads was like,

for example, Myanmar when the word broke out. And that kind of I remember was quite worrying at the

time because a lot of the qualities of Scuttlebutt is definitely not made for safe communication

because if someone eventually found out that, whoa, their communication has been compromised when

they were trying to have safe communication with their peers in Myanmar and they just could not

delete anything and became a huge security risk. Yeah, I know at least one person who,

when that happened, suddenly had to spend all their time making sure that people did not use

Scuttlebutt over there. Yeah, so being able to solve this is quite like, deeply critical.

But then Willow enables the vision?

It's by signaling. It enables the vision in the way that you just described.

Yes, but it also attempts to do that fairly thoroughly. So here is another problem with

distributed systems where, or with our particular brand of distributed systems, where essentially

data might take a long time to get somewhere and might take different paths and you don't know

when which updates will arrive somewhere. So if I first say, let's use the default example from

our own website, we write some data and we give it kind of the name, I hate my boss.

Or Trump. Sure, let's stay with our boss. So I don't actually hate my boss.

So it's easy for me to do use that example. You post a poop emoji kind of to the, and you name

that thing, I hate my boss. And later you, for mysterious reasons, regret posting that.

And you might want to get rid of that. Well, you can delete the poop emoji by saying,

please delete the data that I named, I hate my boss. There's a certain problem with propagating

a marker saying, please delete the data, I named, I hate my boss across the network.

Again, it doesn't quite suffice to convince your boss that you never hated them in the first place.

If on their machine, they get a request, please delete, I hate my boss. And the boss is like,

what? Yeah, like even if they never got the poop emoji, they still got the metadata that something

happens somewhere. Right. And that's, for example, something that I, I don't know many other projects

that try to solve that, but we found a quite elegant solution there.

But Willow has this hierarchical approach to effectively naming the data you put in there.

You can just think of it as like a path in a file system. Whenever I want to insert data into Willow,

I essentially select a folder inside Willow and that folder might live in a different folder or

directory. Right. Until there's actually the data file. And what we can do is essentially,

we have something that looks like deleting a folder high up in the hierarchy. So if I

post, I hate my boss inside something code, well, posts, for example, then I could just say,

please delete the posts on the directory. And then that is the request that gets circulated around

that kind of stays around. Right. So everyone knows I had a post directory launch,

once, which makes sense of kind of the education we're using to communicate as a post directory.

But there's no trace of me having posted. I hate my boss inside the directory.

So that was one of the first things that you said differentiated Willow from other somewhere,

like peer for peer protocols. I can just also give you the next thing that's on my mind as you

say that, because it fits well with what I just have been described, which is that we give these

hierarchical names to data. So essentially whenever you publish something, it's like placing it in a,

like, at a certain place in a file system. But that's surprisingly rather atypical.

It's atypical, because many systems are built on a different kind of addressing called content

addressing, where you don't assign a name that has meaning to certain data. But instead what you do

is you take the data, you put it into a magic concept called a cryptographic secure hash function.

And what this hash function spits out is a random looking string of garbage that uniquely

identifies the data and that random looking string has been, has been computed from the data you

put into that. So if, you know, if some monkey sits at a typewriter and writes the works of Shakespeare,

and at a different typewriter, a different monkey happens to also write the exact works of Shakespeare,

and both monkeys independently put their output through the same hash function. The shorter

random looking identifier, which is a lot shorter than the actual works of Shakespeare is going to

look, there's going to be identical for both of them. And then systems use that to request data,

for example. The same technology is also used in the append only lots of scuttlebutt or the

generalization to mercury's, because when I spoke earlier of new things, reference old things,

what that actually means is new things contain this, contain the digest of the case of scuttlebutt,

the previous, the previous message. Yeah. And well, that's a certain problem, because

suppose I was able to delete an old thing, but somebody has the new things that's

still pointing to the old thing by manner of just including the digest of the old thing.

Now I can confirm the guess as to what the old thing has been. Like, if I'm like, my boss might

think, well, they probably posted a poop emoji. So they take a poop emoji and they feed it into

the hash function, and they get a digest. And if that digest kind of matches the thing,

like the old thing, of which the new thing includes the insecure digest, then they can confirm that

guess. And it's got what you can never get rid of that, because you needed to keep this

this chain. So basically content addressing has immediate consequences for deletion. And

there's, there's multiple ways of looking at it. So one of them is to treat this as a feature and say,

it's censorship resistant, and you never get link rot. Right. So link rot is the concept that

when you have a hyperlink on the web, so one website points to different websites. Quite often,

the other website doesn't exist any longer and you just get, sorry, I couldn't find this. And

with these, these let's call them cipherlinks, because it's kind of a cute name,

with these cipherlinks that there isn't really a thing, because anyone who still has that old

website knows its hash and can just feed it back. So you can't really delete stuff, because it

doesn't even matter whether something has been created or are not. Like, it doesn't matter if I

posted the poop emoji, if anyone who might not have been me posted the poop emoji,

but would have the same hash. Right. So then that thing would be retrievable by that hash.

Like there's no direct connection to me as an entity with intent in this kind of system.

And I'm not quite sure why I'm going with this. You were going into the direction of like how

will it visit differently? And you know that that's where you want me to go, because I'm using

too much time, I wasn't going there at all.

Well, then I carried you right and I would not know.

Then I tried reading my own mind for another second.

Oh, yes. I know where I was going. Linkrod.

Yeah, you must go.

So yes. So this kind of content addressing, it can be said to solve linkrod, because it doesn't

matter whether the server where the data originally lived goes offline, because that never mattered

in the first place. All that mattered was that somebody figured out that a particular piece of

data maps to a particular digest. And from that moment on that, that connection has been made,

and anyone who ever had the data can now answer the request for the digest.

And it's not dependent on a single server, which can eliminate the main cause of linkrod.

But the problem here is, of course, you also can't deliberately induce linkrod.

Like sometimes you just want your website to not be on the web anymore.

So building the web on this technology, which many projects have enthusiastically tried to do

in the name of censorship, resistance, and well, anti-fragility actually.

That has deep flaws, because it robs humans of the agency to retract something.

And one of the core ideas behind WOODO is that we believe that there is a different way.

So if we have kind of the classic way the web does it, which is links just point to a location.

And by removing the data from that location, you can delete stuff, but also

locations just rot away because you need to pay for them on the web,

and servers run on electricity, and servers grow old.

So you kind of get linkrod back into the system, and then there's the opposite approach of

making links really, really unrotable to the point where you can't get rid of them, even if you

wanted to. And what WOODO does instead is something different. It allows people to assign meaningful

names to the data. So I as a user can say, I want this poop emoji to be addressed not as

the secure head, the secure digest of the poop emoji. And neither I want to say, well,

you need to retrieve the poop emoji from this particular server. But rather, I just say, well,

this poop emoji, it's going to be a reachable under the name I hate my boss, as posted by me,

where me in the sense is an entity participating in the network, which,

practically speaking, just means some public key of a group of graphically secure

signature scheme. The standard form of identity in distributed networks,

like the public and private key. Yeah, pretty much. Instead of a login with the password.

Right. Yeah, I think going to the details of that would actually take us off too much on the

attention. So we will. Yeah, let's just assume that we know what a public key and a secret key

in a signature scheme. I didn't. So this is kind of important. It's not that there's like on the

whole world, everybody now associates, I hate my boss with a poop emoji, rather that's tied to me.

But if somebody asks, well, which data did Ayasha assigned to, I hate my boss, then they would be

getting back a poop emoji. Yeah. And the way this word is really works, it's really just I

create a record saying the name I hate my boss now maps to a poop emoji, signed Ayasha.

Yeah. Where instead of signing Ayasha, I actually use my secret key to generate a secure signature

that anyone who knows my public key can verify as actually belonging to that, like having been

produced by the person having the secret key for that public key, poor, this is.

But no one else would be able to reproduce that like signature.

Exactly. Only I am able to produce the signature. And therefore, by trying to guess if you had

posted poop emoji, even by trying to guess that you posted poop emoji or thinking that they have

the answer, they wouldn't be able to replicate the exact same post because they don't have your

private key. Yeah. So nobody can pretend that I posted a poop emoji, except for me myself.

And then it's not really pretending. And so the cool thing about this is this does not rot

on its own. Right. The signature is going to stay valid until the end of time. At least that's

what cryptographers pretend. And that's great. And we're going to make that a sound too. Right. So

if as long as the cryptographic primitive stays secure, the thing is just as durable as a content

addressing thing, you're right. It's just like, if I die, then in 40 years, there's still going to be

kind of my signature on I hate my boss being mapped to a poopy. How did we end?

I don't think I've said poop emoji this often my entire life. In total. Good thing it's just a

private conversation between my good friends and myself. Yeah, it's not a dependable log.

So suppose I'm deeply unhappy with that. And I want to change that poop emoji to a unicorn emoji.

Then I can. I just have to issue the new record saying, I am holder of the secret

fee for the following public key. Short-hand for that. I am Yasha. Now associate the

friend about a boss with a unicorn emoji with an irony emoji. Let's just pretend there's an

irony mode just probably an iron ingot and then something. Yeah. So I can just do that. And

all I really need then is to attach to these two signed records one saying, I have my boss poopy

emoji and one saying, I have my boss irony emoji. All I need is a way for telling which of them

is newer than the other. And then kind of everyone who gets the newer one can throw away the old one.

And this way we still get the ability to override stuff to mutate data and also effectively to

deletion willows just a special case of overwriting some stuff. And so you get the

intentional parts where you deliberately want to remove data from the web. But you get rid of the

passive link rod that is inserted into the web depending on your point of view,

either by virtue of being dependent on locations or by virtue of being dependent on capital flowing

into a system. Yeah. And that's one of the big hypotheses that we're exploring that this actually

works and that it creates value. So this whole concept, like where did it start? Where does it come

from? We all designed it on our own. No, it is for Asian whatsoever. We're really young.

Yeah. Willow, and in particular the ideas that I just talked about, is based on a prior project

called Earth Star. And Earth Star in turn grew out of Scuttlebutt actually in a sense,

because there was a user on Scuttlebutt called Cinnamon who is no longer with us sadly. But Cinnamon

at the time saw problems with Scuttlebutt that not many other people were talking about at the time,

many of which I've talked about by now, like the the paragraphs of being unable to delete things

and kind of how structurally they anchored in the usage of the abandoned only log. And

Cinnamon eventually realized that Scuttlebutt cannot or should not be the future and started

their own protocol, which was called Earth Star. And Earth Star was based on this idea of these

signed bindings of mapping human legible names deliberately to data rather than just using content

addressing. And then Sammy joined that effort actually way before me. And the way I then later

joined, I caught COVID and took some aspirin and then felt very sassy. And for some reason

decided to write a little document how I would do Earth Star from Scuttlebutt if I could,

but I would never do that obviously. I gave it the worst possible name so that nobody could

ever take it seriously, which was soil sun as opposed to Earth Star. So soil sun, which nobody

should name their protocol soil sun. I had a good, all right? And especially when it's okay.

No. It's very fertile. Indeed. And Sammy for some reason took it seriously. And Sammy for some

reason wanted to implement it and acquired funding and gave it a good name. So Willow actually comes

from the aspirin that I took. Oh, I didn't know this part of the story. That's beautiful. Now you

know. Oh my god. Yeah. But there is also a certain part that you brought in and I can assume

what did you call it? Soil. Soil sun. Yeah. Soil sun. The tagline was a minimalistic reimagining

of Earth Star. Did you bring in something that you're quite well known in our circles for is like

rich base sub reconciliation? I did not. Well, depending on how you would like to treat causality,

I did not bring in orange base set reconciliation when with the soil sun draft, the soil sun draft

just started out as we me removing a bunch of stuff. And then as it turned into Willow,

later adding back other kinds of stuff, no way to set reconciliation. Yeah. There's there's a good

story there actually. So back in the day, it's it's 2019, I think. I have been active on scutter

but at one point, the strange thing happened where like a real the real world professor joined the

network. Yeah, this person joined the network showed off some work of this and was really cool.

And you know, you you stalk these people on social media and turns out they chaired the

computer networking group at the University of Basel that professor is called Christian

Tuden or CFT was a scutter part and stuff escalated. We ended up writing a paper. So a CFT and Eric

Lavera, who later also did a post after a position in Basel and me and Dominic Tar himself wrote this

indeed. We wrote those paper on Sophia's cut about and actually got it published and that was

quite fun. And you know, at one point, Eric and I got invited to Basel University and we spent

two days, I think, there just working on this paper and I running out our thoughts. And through

that, I got to know Christian Julian, who in 2019 then invited me to do a semester in his group as an

intern, essentially. And during that semester, I set out thinking a lot about the pendant only logs.

But what actually happened very much inspired by postings of Cinnamon on Scutterbutt about kind

of the dangers with a pendant only logs. And not only the dangers, but also this inherent limitation

of one thing has to come after the other, which is not great if you want to use multiple devices

because you know, you might just post stuff on one device and on the other concurrently before they

have talked to each other. You might want to pick, you probably want to be able to do that, but then

the append only log does weird things and is unhappy and your data becomes corrupted and everyone has

to reject it and to sadness. So Cinnamon and I were both exploring on Scutterbutt, notions of how to

avoid that. And at the time, I was very fascinated with category theory of all things, which is this

arcane branch of mathematics. And very central to that branch of mathematics is the notion of

everything of every concept having a kind of dual concept that you get for free, kind of you can look

at everything from two different viewpoints. But they're essentially the same, but kind of different.

And I was wondering what is the dual to the log or rather sequence, because there's certain

context and computer science where kind of the operation of saying first this, then that exists,

and then the dual notion for that is either that or the other. The important part being that either

that or the other, the order doesn't matter. Right, you always choose one of them, it doesn't matter

whether you placed one first or the other first. You can still choose the same thing and

irrespective of how they were placed, I'm rambling, as opposed to sequencing stuff,

we're saying first this, then that there's clearly a notion of one comes before the other.

So I was wondering a lot about how does the the logliness of secure Scutterbutt, which is all about

sequencing stuff in order. Well, if the dual to that is not caring about the order and just

having a collection of stuff, which we call a set in mathematics, how does that relate to each other?

And then is there a nice way for efficiently reconciling the difference between two sets?

Because we never set the C explicitly, but the main reason why Scutterbutt uses this highly

restrictive and kind of yucky append-only log is because it makes for extremely efficient and

simple data synchronization. I just like, if you and I meet and both of us are interested in the

data that Dominic has published, then I just say, well, I have the first 200 things Dominic has

published. And you say, oh, cool, but I already have 212 things. So what you then do is you just

send the newest 12 things to me and that's it. So all we really needed to exchange in order to

get communication going were two numbers, right? Who has how much stuff? That's extremely cool and

simple and doesn't work at all for unordered collections, so for sets. So I ended up spending

most of my time in Basa trying to figure out how to do that, like how to reconcile sets.

And so I read a bunch of papers. I found this one paper that had a solution, but which was ugly.

We talked about it now. I'm driven by things not being pretty enough. And that paper,

what it did essentially was it forced a certain structure on the things in the set. So rather

than saying I inserted things in this order in the sets in the set, and now that's the structure

that wouldn't work, because if you insert things in different order, you still end up with the same

set. If you insert the same things, right, if I first insert Apple and then banana or if I first

insert banana and then Apple, I still get the set containing banana and apple.

And so you can't really do it based on the ordering, but what you can do is you can just say, well,

for any possible combination of fruits, I'm just going to define kind of a rigid structure of them,

which could be added simple. It's kind of just sort them alphabetically, for example. For various

reasons, that's not efficient to just sort them in the list, but you need to arrange them in a tree,

which is a particular kind of data structure we don't really need to get into. But what they did is

they built a tree whose shape depended uniquely on the contents. Then they put

Merkle labels on that, which we probably don't need to go into. But if you know what a Merkle tree is,

that's the core idea of theirs. They just do a special unique Merkle tree for every set, and then

you just kind of compare the first part of each tree, the root node, do they have the same Merkle

label? If so, then you know the trees are identical. If not, then you kind of compare the

left and the right child. Rocky speaking, that's the ideal here. The paper being

called, I don't actually know the name. I will put the link somewhere.

And you've written a paper on this? No, that's the thing that I found ugly.

Oh, but you've written a paper on rangeface, so very conservation.

Yes. So which was my take on how to do things instead, where the important part is effectively,

you do a very similar technique of kind of saying I compare kind of the highest point on the tree,

and if they are equal, then I know that everything is equal. And if they are not,

kind of look at the next lower layer in the tree and start comparing points in that layer and so on.

But the core difference in my work was that I didn't mandate a particular shape of tree,

but rather I would say you can use any kind of tree that stores the same sort of data.

And you can see the main work somehow, and I probably shouldn't explain the details

right now that would take a while. But if you are curious about it, then go read the paper.

No, don't read the papers. That paper, that paper was written so that it would make it past

reviewers. I mean, yeah, actually you'd read the paper.

So think about it. What do you, where would you send people?

I shouldn't be stumped by this.

I'm deeply saddened that I am stumped by this.

So before I wrote the paper, I actually just put a little write up on GitHub that does a lot of

hand waving, but probably is a way better entry point than the paper itself.

So I can link to that.

And I can look for some other resources.

And right now we are at time because I'm trying to keep these compact enough that they're

in listenable. And so is there any final note you'd like to pitch in before we close this

beautiful introduction chapter?

Thank you.

So