Let me tell you a story, who will talk about Willow, a family of...
Willow, a family of peer-to-peer storage protocols.
Let's welcome her with a round of applause.
Once upon a time, one unique time stamps was still small.
The ancients worked together to build a system which would let them share their knowledge from afar.
The system connected places of learning and all were hopeful that it would usher in a new golden age of art and science.
But the wicked hearts of men were drawn to the power of this system.
And slowly, piece by piece, they twisted the system to serve their bottomless grave.
Until it was theirs.
So listen well, system builder.
The systems you build today will be the weapons used against you tomorrow.
And now the title screen.
I'm not really sure why I wanted to include a title screen here, but after this, the video
game, illusions and... I should have taken that out. I'm Sammy Golo, a programmer, illustrator
and mum. I've been working on some peer-to-peer protocols, called Willow, together with
Aliosh and Maya, who sadly could not be here today. The story you just heard is one we're
waking up to. Centralized systems were designed with the best of intentions, but we're
weaponized anyway, and peer-to-peer systems will be exactly the same. If the next generation
of network succeed, there will be well-resourced people trying to turn them against us. But how
did they do this? I'm going to put the weaponization of networks into two broad categories,
the weaponization of data and weaponization of infrastructure. Data, particularly data connected
in the videos, is valuable and has a market, buyers who use that data to advertise to you,
who use that information to watch you, to condemn you and eventually to find you. That might sound
alarmous, but that is exactly what is happening in the United States as ice partners with
commercial data brokers. It was unthinkable not that long ago, and if it's happening today.
The infrastructure of the network themselves is also weaponized. If you force others to
traverse a network for basic functionality, you can listen to communications as a man in the middle.
By co-locating storage and functionality on certain points of networking, you can force new
terms and features on users who have no other choice. You can even make it so that people
need to buy new hardware to participate on the network. Our reliance on massive data centers
has even been weaponized to create a speculative AI bubble. How do you make the next generation
of protocols more difficult to weaponize? This is the lens through which I'd like to introduce
willow today. Willow is a family of peer-to-peer protocols which deal with accessing a modifying
share data, access control and data exchange. These take the forms of protocols and low-level
libraries. We want to provide plumbing, not products. I'm going to be talking about the why
of Willow mostly, rather than what or how. That's because if you'd like to learn about the
features of Willow or how it does what it does, we've got a website which can tell you that with
specifications, diagrams, comics and lots more besides. There are QR codes as you've seen along
the bottom of the slides, linking to different concepts where you can learn more.
So, data has value. Other ways that we can make it more difficult to gather.
Newtability is the ability to change a mapping of one value to another. Willow is a system of
mapping data to names. The deliberate act of naming makes it possible for us to assign new
values to names and to forget the old values entirely. People make mistakes and change their minds.
We want to system which gives users agency of their digital past.
Neutability also makes external moderation possible. For getting data makes it harder to
hoard and sell and analyse. And that's important because data has value. If the vast majority
of peers coordinate deletion, it decreases the window in which malicious data order can
in-depth data before it disappears. Even metadata has value. People have been drone-bombed
for being associated with metadata. So it's just not enough to be able to reassign values to names.
Sometimes we want to forget the fact that any data was assigned to those names to begin with.
Willow's naming structure allows peers to forget this kind of metadata and data wholesale.
This is a mitigation, of course. We can't force malicious peers to forget. The same way
I can't force you to forget this presentation after seeing it. But malicious peers have a
much harder time when they're operating in a network of peers working together. That improvement
of the odds alone is worth it. There are systems which present the most recent version
as the true value, but still hold on to the data and metadata in the background.
Usually as a requirement of some data trucks they're using. This is Earth's mutability
and does not sufficiently protect people. Not only does it not protect people but it
has another cost. Those old values need to be stored somewhere and quite often they need to be processed
too. When you have authentic deletion, you don't have these costs and you make it cheaper to
participate in the system. Cheapness is an interesting quality. When the requirements for running
your own network a lower, it's harder for others to make you feel like there's no alternative.
How can we further pursue cheapness? Let's talk about CRDTs. There are very
fancy CRDTs out there which are able to intelligently merge fine-grained edits into a single coherent
edit. These kinds of fine-grained CRDTs are critical for applications where many people are editing
the same thing at the same time, like a word processor or task list. But these fancy CRDTs
also come with a cost, storage and computation. Participation requires carrying around a
history of changes, perfect for data hoarders and a duty to process them into a final state.
This puts a hard ceiling on how large and long-lived these spaces can be. Not cheap.
Do we always need the ability to reconcile fine-grained edits? Arguably no. Most of the
day, we're using applications where people author data alone and share it with others,
private messaging, chat rooms, web pages, microblobs, media libraries, archives, forums,
issue trackers. You could use a fancy CRDT for these, but you would be adding
significant cost without benefit. So what if in the name of cheapness, we said we're not going
to support collaborative word processors, but the majority of applications instead.
Willow using an extremely simple CRDT, last right wins between different devices owned
by the same user. It's dirt cheap. Cheapness is interesting, not because it lets you run a
community of millions on a single server, but because it lets you run a community of a
dozen on a potato. This is critical in a world where we need to get more out of the hardware
that we already have. I just mentioned different devices owned by the same user. This implies
there's some notion of identity in Willow. Earlier, I mentioned how data is weaponized and used
to advertise to watch and locate individuals. This is done by associating different data points
with one another through an abstract identity or digital double, uniting them or which can
then often be tied to a real person. There's also a growing mania for associating individuals
with a single digital identity. When digital identities become synonymous with the flesh and blood
beings, they're set to exclusively represent. We create the conditions for grievous fraud.
How can we introduce identity to Willow in such a way that we can minimize these dangers?
And at the same time, enjoy intuitive access control. Users of Willow can issue their own identities
which will randomize ideas. They can keep that identity themselves or share it with others.
They can ascribe as much or as little identifying data like a name or picture to that idea as they
want. They can reuse a single identity across many communities or issue themselves as many as they
wish. For whatever scenario they see fit. It's a start, but malicious actors can still
de-obfuscate the relation between different identities. We see this on the web where technologies
like cookies are used to connect to single use different identities from across many different
domains and communities. Your identity as a reader of anarchist theory may be connected to your
identity out of your work, for instance. This is possible because the web is different domains
are able to bleed into one another and share information. But what if we formalize a hard and
crossable threshold between the domains? Willow has namespaces, which actors completely independent
universes of data and in space for yourself and in space for your friend circle and in space for
a social network. What belongs in one the namespace cannot cross over into another and nobody can
learn what is within a given namespace without being given explicit consent to access at first.
But the barrier of explicit consent is still not enough. It is still possible to use a single
identity across many namespaces linking them. A malicious actor can learn a lot by simply knowing
which namespaces you belong to. To mitigate this, it must be impossible for someone to learn
about the namespaces someone else is interested in unless they already know about it themselves.
Willow uses a system called private interest overlapped, confidentially determined what data
any two peers are both interested without revealing any interest, which their partner does not
know about themselves. This works at quite a granular level so you can not only hide namespace
from other peers but also parts of the namespace they don't have access to and presumably
have no knowledge of. This makes it very hard for malicious peers to gather data and infer
connections between data and identities. Within dependent namespaces, private interest overlapped
and usability, communities can have private digital spaces with real moderation. This is especially
relevant to vulnerable communities who need to be able to communicate with each other without
being harassed and spied upon. But by retreating to our own enclaves, are we losing something?
There is something special about finding a new website or profile you've never seen before
and perhaps making new friendships through that. Inversely, there's also something special to
being able to publish something you made and have it reach far further than you never imagined
it could. Can we do something like that? One mitigating? It's accompanying risks? The risks
being harassment, drive-by exposure to things you don't want to see and being forced to
participate in the same space with entities you want nothing to do with? Quite often, you can
only do something after the fact. In social networks you can block. On the Fediverse, you can go
a little further and you federate. Both of these are opt-out approaches. But what if we invert that
and make a public network that you opt into? Where every person you read data from is someone
you've chosen to listen to and who is allowed you to listen? So in addition to the prior that
invite only namespace, will those access control system let-o-cap? Has communal namespaces
where anyone can claim their own little slice of the space, which they can write whatever they
want to, with a catch being that nobody has to listen. Other users must choose whether they're
interested in your day's first and must be given express permission to read them. Both
stars of namespace have explicit concerns at their heart. You can never read or write any data
without someone having given you express permission first. Perhaps that permission is someone
saying I allow it absolutely everyone to see this, but at least it's always explicit.
What I've been scurting around is who stores well-o-data and how is it exchanged? This thing
appeared to peer system, the data restored and used its own devices. Devices only store what
they've expressed an interest in, and they can express a lot of granularity in that request,
not just what you do, only blog posts, but also when, like, only data from the last week,
or how much, like, only the most recent 100 megabytes. Creating a correspondence between
the community which uses network and infrastructure which hosts it is a wonderful way to keep
outside interest from screen things up. But how does data move from peer to peer? Many protocols
seem a bi-directional connection can always be established, but establishing such a connection
is a privilege. Maybe you don't have access to such infrastructure, or maybe you can't trust
that infrastructure. Every connection leaves the trace, and perhaps that's something you can't
afford. Infrastructure is a process, not an end state. Connectivity is lost and found.
Servers go down for maintenance or permanently. Volunteers move on, channels are compromised,
there must be different means of moving data to suit the given moment. And that's why we've
decoupled our data model entirely from how the data is exchanged, and this allows us to design
different sync protocols for different situations. For the good times, when you can establish
bi-directional connections, we've sync protocols which are able to confidentially determine
common interest with private interest overlap, resist, man, and the middle attacks. Intelligently
determine the least amount of information to exchange via a range-based set reconciliation,
and even communicate memory constraints with each other so that constrained devices like
microcontrollers can participate. These protocols don't specify the transport used, so it could be
web sockets, Bluetooth, or anything else capable of establishing bi-directional communication.
In particular, these protocols are able to let you securely communicate with peers
you don't necessarily trust, which is vital when you need to take every opportunity you can get.
For everything else, that's the drop format. This protocol serializes WillowDasis to single
blob, which can then be sent over the infrastructure you trust or already have. Signal, email,
or maybe personally transported by USBQ. We want to contribute and you can live your protocols,
able to meet the many crises that we're meeting today. Users should be able to see the risks
they're taking on with open eyes and have the tools to remedy them. One of the crises we
slept walked into was caused by believing that the internet was a new world separate from ours.
But networks are not a femoral virtual world, but grossly physical, a sprawl of cables and
humming machinery forced to creep over the surface of the earth. These networks have real
physical demands and constraints, and the protocols of tomorrow will need to justify every last
bite of storage and memory. The systems we build today will be the weapons used against us
tomorrow. Reality is messy, and when we ignore that, we betray the users who depend on the systems
we design. So, let's make our systems as hard to wield against us as possible, and perhaps
then we can truly make the mouse. Thank you.
Thank you. Thank you, Simon. So great. Thank you. I said you got so many
questions. Just apologies for the ignorance because I haven't. I don't know much about
will I, but I was wondering if you could say perhaps if you're able to who maybe your biggest
consumer is or maybe who is somebody who maybe maybe using it quite frequently. We are
deep in the kit, I've got a mic at so far. We're deep in design and theory and implementation,
so we're mostly just still procuring funding and building things.
Hi. Just trying to understand your aim, so you're trying to provide a foundation like the
web has, so including the protocol and how should different node access and how to be stored
data. Yes, it's quite low. It's just kind of like protocols for how do you access
and modify that data, how do you control the access to it, and also providing different
means to exchange it with other people. But you could use existing protocols, transports,
protocols, the web. But I mean like, Internet could be your underlying protocol use we're
thinking but like we didn't have that. Yeah, no, it's definitely supposed to be like a
companion to like the web. I see you. Thank you.
It just looks really great. Thanks a lot. Do you already have applications for your protocol
or are you still trying to figure out how all these different pieces fit together?
We have rust implementations for the data model, and also for our capabilities system
meta-cap, and we hope to have persistent storage and the drop format implemented in the next
month or so. No, on the application layer currently you don't have.
Thank you for the fantastic presentation. I was really inspiring. And I'm just wondering,
first of all, you did you who did the drawings? Great. Fantastic. I figured as much. And just one
question. So I believe I understand that you start from one theoretical starting point, which is
the sentence you stated, that these will be the weapons tomorrow of tomorrow that we'll be used
again. And how far are you in solving this problem you would say from a theoretical standpoint?
We've been working on these protocols for, I would say, like four years or so, and working
closely with sort of the prominent thinkers in within that field as well. So I feel like our designs
are pretty solid at this point for the data model, like the specifications are final.
So, yes, I think this is what we're going to shoot our shot with really.
Thank you very much. Do you have more questions? Please do this.
We have a question from the internet.
Okay. Tristan, Tristan, Tristan merely asks, any thoughts about backups?
Backups. Yes, you could, you could use it because this is kind of like, um,
because we don't use CRDTs. For days, basically, everything's just kind of like bite strings.
This system is ideal for storing like very large blocks of data. So, yeah, backups.
Great. Let's do them.
I'm not in the scene of the interrupt. Sorry.
I wanted to ask about how to implement VLO protocol, but that question kind of was answered or asked already.
But I will wondering, so it seems like it's a different kind of network.
So the devices that implement VLO protocol and everything else would be different in the
internet. I mean, they're all connected in the internet, but it could be that some places,
some remotes, don't implement VLO and some will implement VLO. And the question is how you
distinguish between each other? Yeah. I mean, I think kind of one of the
core design principles that we have is sort of meeting people where they're already at with sort
of the hardware that they have or the infrastructure that they're already trust.
And so, yes, if they need, if they need to be on the web or they need to really not be on the web,
you know, we want this to be something that they can use and mix or not really. So, yeah,
these things can sit side by side or they can be separate or, um, okay.
That makes sense? Yeah. Great. Thank you.
Well, especially in the room. Okay. And now that I have your attention. So first, we're going to thank you again.
Thank you.