[00:57.230 --> 00:59.510]  Let me introduce our next speaker.
[01:03.180 --> 01:07.580]  The pandemic plaguing us makes planning problematic.
[01:08.240 --> 01:17.700]  Most online collaboration tools have security weak points, be it application vulnerabilities or willingness to give data at the drop of a law enforcement officer's hat.
[01:18.620 --> 01:20.220]  There is a better way, though.
[01:21.220 --> 01:22.560]  Peer-to-peer collaboration tools.
[01:23.100 --> 01:24.620]  Please welcome Holmes Wilson.
[01:32.170 --> 01:32.770]  Hi.
[01:33.430 --> 01:34.830]  My name is Holmes Wilson.
[01:35.150 --> 01:52.770]  I'm a co-founder and now a board member of the tech policy activism organization, Fight for the Future, which has made a really significant impact over the years on tech policy issues like online privacy, Internet censorship, the right to encrypt, net neutrality,
[01:52.870 --> 01:54.330]  and limiting biometric surveillance.
[01:55.310 --> 01:59.210]  So this talk relates to three problems I think about way too much.
[02:00.210 --> 02:03.030]  The first is the problem of holding big tech companies accountable.
[02:04.210 --> 02:09.550]  The second is Russia's horrific invasion of Ukraine and the problem of fighting authoritarianism.
[02:10.290 --> 02:16.690]  And the third is the pandemic and how we can do sensitive work together securely online.
[02:18.350 --> 02:26.430]  Today I'll suggest a shift in our thinking about software that we can make right now which I think can help with each of these problems.
[02:27.090 --> 02:35.810]  Holding big tech companies accountable, helping activists fight authoritarianism, and improving security for remote teams doing sensitive work online.
[02:37.230 --> 02:38.530]  But first I have a rant.
[02:39.130 --> 02:42.310]  A rant that will hopefully turn into something more constructive than a rant.
[02:43.610 --> 02:45.650]  My friends think the Internet sucks.
[02:45.930 --> 02:47.250]  And this is bumming me out.
[02:47.970 --> 02:53.250]  So two years ago at HOPE 2020, I attempted to answer this question of why.
[02:53.510 --> 02:56.090]  Why do most of my friends think the Internet sucks?
[02:56.750 --> 03:00.290]  And also a related question of what can I do to change it?
[03:00.350 --> 03:01.530]  Because it's bumming me out.
[03:03.170 --> 03:06.870]  And I think the answer to the first question was that the Internet had changed.
[03:06.870 --> 03:25.350]  changed from being a tool for tearing down unaccountable power with movements like Occupy and the Arab Spring, to being an unaccountable power itself in its own right dominated by unaccountable tech companies run by cringey celebrity billionaires.
[03:27.890 --> 03:35.450]  So when the Internet looked like it was a tool for challenging unaccountable power, people felt like it was on their side and they liked it.
[03:35.450 --> 03:46.350]  But when big tech made the Internet start seeming like a new unaccountable power in its own right, people, like the majority of my friends, began to fear and mistrust and hate it.
[03:47.550 --> 03:49.170]  So how did this happen?
[03:49.690 --> 03:54.350]  I think it had something to do with the cloud because both things seemed to happen around the same time.
[03:55.230 --> 04:04.630]  With the cloud, software most people used every day largely stopped working on its own and started being tethered to infrastructure controlled by someone else.
[04:05.150 --> 04:06.650]  And we all know this story well.
[04:07.290 --> 04:09.130]  Microsoft Word gave way to Google Docs.
[04:09.350 --> 04:10.490]  Email gave way to Gmail.
[04:11.630 --> 04:18.890]  Conversations that used to happen on USENET, mailing lists, and forums began happening on massive centrally controlled platforms like Facebook and Twitter.
[04:19.710 --> 04:35.470]  And even when apps didn't need infrastructure and could easily run without servers, Apple artificially inserted themselves and their own infrastructure as a gatekeeper with an app store to grab the power and profits that came from controlling what software users could run.
[04:37.370 --> 04:42.230]  On an iPhone, even the simplest game can't run without permission from big tech.
[04:42.230 --> 04:47.630]  We can't hold big tech accountable because we depend on their infrastructure way too much.
[04:49.330 --> 04:54.570]  The medium that gave us the rise of Occupy Wall Street started to look more like regular Wall Street.
[04:55.310 --> 04:58.150]  And after a while, people noticed and they thought that it sucked.
[04:59.650 --> 05:01.110]  That's, I think, part of the reason.
[05:03.190 --> 05:04.730]  But there's something more to the story.
[05:04.970 --> 05:07.250]  And to me, it makes the whole thing even sadder.
[05:07.250 --> 05:13.790]  Because we actually had, and we still have, a great mechanism for holding big tech companies accountable.
[05:15.010 --> 05:19.790]  But the tethering of our software to servers undermined that mechanism terribly.
[05:20.350 --> 05:24.370]  The mechanism I'm talking about is free software, sometimes called open source software.
[05:25.110 --> 05:29.130]  And free software is a mechanism for holding software accountable that works by guaranteeing four freedoms.
[05:30.090 --> 05:37.350]  The freedom to run software as we wish, the freedom to study and change it, the freedom to redistribute copies, and the freedom to distribute modified versions.
[05:37.990 --> 05:42.390]  I actually worked at the Free Software Foundation in 2009 and 2010.
[05:42.610 --> 05:52.290]  And I was only there for a brief time, but I still think free software is probably the clearest framework for thinking about the intersection of politics and software.
[05:52.770 --> 05:54.370]  Particularly power and software.
[05:55.230 --> 05:59.590]  And this articulation saved the Internet multiple times.
[06:00.310 --> 06:06.970]  In the darkest days of the Microsoft desktop monopoly, when a lot of computing looked like this, free software web browsers helped us escape.
[06:07.810 --> 06:14.790]  And then again, when media monopolies tried to keep popular culture off the Internet, free software file sharing apps helped us escape.
[06:16.490 --> 06:23.050]  When Apple nearly seized control of the future of computing with the iPhone, free software operating systems helped us escape.
[06:25.310 --> 06:31.550]  And when you escaped to free software, you could feel it was on your side, in a way that doesn't happen that much with software these days.
[06:32.190 --> 06:37.710]  Free software killer apps like Firefox and VLC and BitTorrent worked for you in a way that was really palpable.
[06:38.590 --> 06:40.130]  You want to turn off all ads in your browser?
[06:40.530 --> 06:40.970]  Cool.
[06:41.190 --> 06:41.470]  Done.
[06:41.730 --> 06:42.290]  Said Firefox.
[06:43.490 --> 06:47.170]  You think DRM and video codecs are kind of stupid and videos should just work?
[06:47.610 --> 06:48.050]  Cool.
[06:48.270 --> 06:48.810]  So do we.
[06:48.990 --> 06:49.530]  Said VLC.
[06:50.110 --> 06:54.630]  You think copyright should recognize the public's interest in building free online libraries?
[06:55.970 --> 06:57.270]  BitTorrent said do your thing.
[06:57.910 --> 06:59.290]  And largely we did.
[07:01.690 --> 07:05.570]  And, you know, you want to run BitTorrent on your phone, which is still banned on iOS?
[07:06.310 --> 07:07.570]  Android said why, of course.
[07:08.550 --> 07:09.490]  And why wouldn't it?
[07:10.110 --> 07:14.270]  When big tech made power plays against us, free software refused to participate.
[07:15.130 --> 07:16.330]  And how could it participate?
[07:16.530 --> 07:22.290]  Because if it did, someone would fork it, take the code, put out a new version, and release something else.
[07:22.510 --> 07:27.270]  Which rarely happened because the threat of a fork made all of that...
[07:27.770 --> 07:30.250]  all those worst power plays that big tech could play.
[07:30.470 --> 07:31.770]  Both taboo and pointless.
[07:32.750 --> 07:35.510]  A lot of people think of free software as an ethical choice.
[07:35.710 --> 07:36.910]  Like something like being vegan.
[07:37.990 --> 07:39.850]  But actually, I think it's more like...
[07:39.850 --> 07:41.490]  Yeah, we got the vegetarian haggis here.
[07:42.130 --> 07:43.810]  Actually, I think it's more like a union.
[07:44.970 --> 07:47.950]  Because good unions can give all workers more leverage.
[07:48.230 --> 07:49.830]  Not just workers in unions.
[07:50.470 --> 07:52.830]  By posing a credible threat of successful revolt.
[07:53.490 --> 07:55.170]  And by altering societal norms.
[07:56.710 --> 07:59.270]  Unions have this slogan I love, which is...
[07:59.270 --> 08:00.530]  The folks that brought you the weekend.
[08:01.210 --> 08:03.130]  Like, unions made weekends normal.
[08:03.790 --> 08:06.810]  And in the same way, the threat posed by free software alternatives...
[08:07.690 --> 08:12.250]  And the way these alternatives raised our expectations of how software should behave...
[08:12.250 --> 08:15.310]  held big tech accountable time and time again over the history of the Internet.
[08:16.030 --> 08:17.730]  This is part of our history as a movement.
[08:19.150 --> 08:22.390]  This is the track that we want the Internet to be on as it grows.
[08:22.930 --> 08:25.110]  To be able to hold big tech companies accountable.
[08:25.530 --> 08:28.610]  And have an Internet that people really feel is on their side.
[08:30.930 --> 08:35.590]  So, why isn't this accountability mechanism of free software working in the age of the cloud?
[08:36.250 --> 08:37.850]  I think there's a simple answer.
[08:38.150 --> 08:39.890]  And the answer is dependence on servers.
[08:40.950 --> 08:45.290]  For starters, server dependence fundamentally undermines free software's core freedoms.
[08:46.550 --> 08:48.050]  The freedom to run software?
[08:49.250 --> 08:50.490]  Only if you've got a server.
[08:51.410 --> 08:53.370]  The freedom to study and change it?
[08:54.290 --> 08:55.730]  Not on someone else's server.
[08:56.190 --> 08:57.570]  Not legally, anyway.
[08:59.290 --> 09:02.010]  The freedom to redistribute or distribute changes?
[09:03.110 --> 09:08.530]  You can redistribute the code, says free software, but the data and relationships all live on the server.
[09:09.950 --> 09:14.070]  The Free Software Foundation spotted this threat of server dependence as the cloud took off.
[09:14.830 --> 09:18.590]  Calling out a thing it called service as a software substitute.
[09:19.110 --> 09:21.590]  An awkward riff on software as a service, the business model of the cloud.
[09:22.970 --> 09:28.070]  Two perfect examples of service as a software substitute were Google Docs and Gmail.
[09:28.370 --> 09:32.130]  Because they replaced things that people had always done locally on their own computers.
[09:32.930 --> 09:34.970]  Like email clients and word processors.
[09:36.830 --> 09:42.310]  But the Free Software Foundation never said that server dependence was always bad.
[09:43.170 --> 09:51.030]  After all, the movement had always run some software on servers for things like email lists and code repos and bug trackers.
[09:52.510 --> 09:59.170]  And requiring developers to change that when the technical path to doing so was still so untested was a bridge too far.
[09:59.350 --> 10:00.870]  Even for the Free Software Foundation.
[10:02.510 --> 10:06.990]  In 2010, when I was a campaigner there, I thought this was an inconsistency and a mistake.
[10:06.990 --> 10:09.750]  And I think the past decade has showed I was probably right.
[10:11.150 --> 10:17.030]  One great example of how server dependence weakened free software is a website we all know and love.
[10:17.290 --> 10:18.450]  Or maybe we don't love it.
[10:19.470 --> 10:21.530]  The front page of the Internet, Reddit.
[10:23.050 --> 10:27.490]  At the Free Software Foundation, we had to boycott a lot of popular services when campaigning.
[10:27.830 --> 10:29.090]  But we had a green light to use Reddit.
[10:29.270 --> 10:30.350]  Because Reddit was free software.
[10:30.990 --> 10:42.690]  That meant that in theory, if Reddit did something its users didn't like, users could fork its code, start their own Reddit, and even if it never came to that, use the threat of being able to do so to hold Reddit accountable.
[10:43.290 --> 10:44.110]  In theory.
[10:45.010 --> 10:50.590]  However, in practice, forking Reddit would leave you with nothing more than an empty website.
[10:50.950 --> 10:57.170]  Because all of the data and relationships that made Reddit what it was lived on company-run servers.
[10:57.750 --> 11:08.410]  And meanwhile, the work of scaling Reddit to hundreds of millions of users had made its codebase so complex and so difficult to maintain, even for Reddit itself, that it had become less and less useful to anyone else.
[11:08.990 --> 11:15.630]  This is exactly what Reddit said in 2017 when they announced that they would no longer be releasing Reddit's codebase as free software.
[11:16.090 --> 11:18.270]  And few cared, because Reddit was right.
[11:18.610 --> 11:26.670]  When software depended on servers, free software's four freedoms, and the power to fork only got you a complex, hard-to-maintain, empty website.
[11:28.170 --> 11:41.010]  Reddit shows that if we care about holding popular services accountable, we really, really need to leave the server behind, even when that seems hard or impossible, and even for things that we've always traditionally done using servers.
[11:43.230 --> 11:53.270]  To see more evidence that servers are a problem for free software holding big tech accountable, we can compare areas of software that are dependent on servers to areas of software that are not.
[11:54.530 --> 11:57.310]  My favorite place to start is developer tools, because it's both.
[11:57.850 --> 12:01.710]  Developer tools give us the closest thing we're going to get to a real pure experiment.
[12:02.450 --> 12:10.090]  On one side, we have tools that run on devices developers control, like IDEs, libraries, languages, desktop operating systems, and server operating systems.
[12:10.930 --> 12:15.990]  Here, free software is extremely strong, and developers have a huge amount of power to hold big tech accountable.
[12:18.130 --> 12:23.270]  Free software is such an integral part of every developer's day, that it's hard to even imagine a world without it.
[12:24.090 --> 12:27.130]  No one's going to sign a license agreement to use some library they just found.
[12:29.430 --> 12:35.950]  According to the latest Stack Overflow survey, 40% of professional developers use free software operating systems.
[12:37.450 --> 12:51.350]  And when big tech offers free software languages and developer tools, like Go, or Kubernetes, or Flutter, or React, or Jest, PyTorch, these rarely, if ever, raise the accountability problems that big tech is famous for.
[12:52.750 --> 12:57.970]  Tech CEOs are not getting dragged in front of Congress, dragged over the coals, over React and Go.
[12:58.550 --> 12:59.850]  Though that would be kind of weird.
[13:00.750 --> 13:14.110]  On the other side, when we look at developer tools that require or benefit from central servers, like GitHub, Cloudflare, Amazon Web Services, or App Stores, free software is much weaker.
[13:14.710 --> 13:16.510]  And the picture changes completely.
[13:17.270 --> 13:22.590]  For one thing, when developer tools depend on servers, big tech can kick developers off these tools.
[13:23.110 --> 13:24.790]  And what can a developer do about that?
[13:25.630 --> 13:27.330]  Servers are a censorship problem.
[13:27.330 --> 13:44.890]  The mere fact that there is a free App Store called FDroid, or a free GitHub alternative called GitLab, both good things, does not solve a developer's problem when they are kicked off App Stores or GitHub because those services have a critical mass of data and users that make them especially useful.
[13:45.370 --> 13:49.890]  And as we saw with the example of Reddit, developers can't just fork those just because you can fork the code.
[13:52.170 --> 13:53.550]  Servers are a lock-in problem.
[13:55.110 --> 14:08.770]  There are tons of free software replacements for popular server-based tools, and many are quite good, but most teams don't use them because most people don't want to be the one who is the single point of failure if something breaks, for dozens or hundreds or maybe millions of people.
[14:10.930 --> 14:15.910]  Open source volunteers especially don't want to be the single point of failure.
[14:16.730 --> 14:22.850]  As a volunteer, do you want to be on pager duty and get that call in the middle of the night with that special ringtone when the server breaks?
[14:23.770 --> 14:30.010]  Do you want to take your laptop to a party, to every party you go to in case something breaks, and never leave cell phone range?
[14:31.810 --> 14:36.430]  Signal creator Moxie Marlinspike talks about this being his life for years.
[14:37.730 --> 14:40.830]  Nobody wants that life as a volunteer, or few people do, I should say.
[14:42.130 --> 14:43.510]  Servers are a volunteer problem.
[14:44.350 --> 14:55.010]  And yes, the classic open source business model is to provide a hosted version supported by a paid team so you don't have to rely on volunteers to do DevOps, but Gmail is free and Instagram is free.
[14:55.610 --> 15:01.830]  And Wall Street and Big Tech can subsidize these products for a decade or more until they can profit from dominance.
[15:02.130 --> 15:09.630]  So if you're up against a free product from Big Tech and you have server bills, servers are a competitiveness problem.
[15:11.150 --> 15:14.550]  Again, with developers, we have the same market and the same customer.
[15:15.150 --> 15:15.590]  Developers.
[15:15.890 --> 15:22.570]  Our customer is highly technical and empowered, and fully capable of running their own server, far more than the typical person is.
[15:23.170 --> 15:30.570]  And yet, as soon as servers are in the mix, Big Tech's power shoots up, and the ability to hold Big Tech accountable falls off a cliff.
[15:32.850 --> 15:34.310]  Servers are a problem.
[15:36.170 --> 15:47.230]  Moving beyond developer tools to other areas of software, we see that in areas without server dependence, we have some strong free software alternatives, and we do not see Big Tech at its worst.
[15:47.850 --> 15:56.410]  We have web browsers, media players, document readers, desktop operating systems and mobile operating systems, minus the server dependent bits in the app stores.
[15:57.370 --> 16:05.670]  These aren't perfect utopias, but despite dominance by Big Tech, we don't see high prices, almost any advertising, or massive data collection.
[16:07.070 --> 16:18.090]  Conversely, in areas of software that depend on free servers, on servers, such as social media, search, e-commerce, or collaboration tools, we see Big Tech at its worst.
[16:18.630 --> 16:26.050]  We see high prices, the most heavy-handed and problematic forms of advertising, and few privacy protections.
[16:28.410 --> 16:30.050]  Servers are just a problem.
[16:30.930 --> 16:35.510]  Because our inability to hold Big Tech accountable stems from a simple relationship.
[16:36.310 --> 16:38.350]  Server dependence weakens free software.
[16:38.710 --> 16:41.910]  And the longer we go without realizing it, the longer we'll be stuck without a solution.
[16:43.370 --> 16:44.830]  So how do we replace servers?
[16:46.230 --> 16:53.930]  If you're a professional developer, you're probably thinking, wait a second, there were huge advantages when we switched to developing things on servers.
[16:53.930 --> 16:55.890]  And decentralized systems are really tricky.
[16:56.510 --> 16:58.370]  And I want to validate that completely.
[16:59.190 --> 17:03.090]  Yes, cloud made building software easier in so many ways.
[17:03.810 --> 17:08.850]  Yes, handling complex data across many users without a server can be very daunting.
[17:09.210 --> 17:15.170]  So to validate your doubts, and just bring everybody up to speed on this, I'm going to show a huge list of reasons why it's true.
[17:18.310 --> 17:19.490]  I'm not even going to read all of them.
[17:19.570 --> 17:20.010]  There's so many.
[17:20.870 --> 17:22.590]  And this list is non-exhaustive.
[17:22.790 --> 17:24.590]  I'll just say, yes, it's daunting.
[17:25.570 --> 17:27.530]  But building the world we want takes work.
[17:27.910 --> 17:32.450]  So if the evidence says that servers are a problem, we have to roll up our sleeves and do that work.
[17:34.570 --> 17:36.030]  But how do we replace servers?
[17:36.530 --> 17:37.930]  So I have a trick.
[17:38.310 --> 17:50.190]  And the trick is to find broad categories of software where the difficulty of eliminating the server is unusually low and the benefits of eliminating the server are unusually high.
[17:51.010 --> 17:54.250]  And then you can attack those categories once you find them.
[17:55.150 --> 17:58.350]  I believe team collaboration is one such category.
[17:58.950 --> 18:09.170]  Apps like Slack, Discord, Google Docs, GitHub, Trello, Basecamp, Figma, Miro, Asana, and so on.
[18:10.130 --> 18:32.770]  The benefits of eliminating servers for these apps is unusually high because these apps are so central to our creative and professional lives and because the privacy and security properties of these apps can be so essential, especially for remote teams doing sensitive work in a pandemic and for activists resisting authoritarianism.
[18:34.770 --> 18:52.090]  The difficulty of eliminating the server here is relatively low because these apps sync limited-sized state and they do it in private networks, which progress in both Tor and peer-to-peer stacks has made a lot less difficult than it used to be.
[18:53.830 --> 18:55.210]  Okay, so how do I know this?
[18:56.450 --> 18:59.090]  Because my collaborators and I went and did it.
[18:59.670 --> 19:08.070]  We built a thing that I think proves that open societies can bring privacy and accountability to the broad category of team collaboration tools.
[19:09.530 --> 19:19.090]  We built a Slack alternative that does not use servers and it's missing a ton of features and it's not audited yet, so please don't use it for anything critical.
[19:19.830 --> 19:32.190]  But it's exciting that this is even possible because if it's possible for us to build a Slack alternative, it's possible to build alternatives that are not dependent on servers to a broad range of collaboration tools.
[19:34.010 --> 19:37.650]  It's called Quiet and I'm going to show it to you now.
[19:39.050 --> 19:41.890]  All right, this is the terrifying part.
[19:43.890 --> 19:45.350]  So I'm over here.
[19:52.670 --> 19:53.270]  And...
[19:53.270 --> 19:53.910]  Cool.
[19:54.570 --> 19:55.170]  Whoops.
[19:57.450 --> 20:03.130]  All right, so here I have three apps running in my computer, three instances of Quiet.
[20:03.470 --> 20:05.170]  They're all connected out through Tor.
[20:08.970 --> 20:09.830]  I can say hi.
[20:13.850 --> 20:15.950]  And the message is sent to everyone else.
[20:16.210 --> 20:16.290]  Oops.
[20:16.490 --> 20:17.170]  I'm in the wrong channel here.
[20:17.510 --> 20:18.510]  You can see the message is sent.
[20:18.650 --> 20:20.130]  I can say hi back from Bob.
[20:23.040 --> 20:24.040]  And the message appears.
[20:24.320 --> 20:25.840]  All the clients sync state with each other.
[20:27.480 --> 20:28.560]  Now, let's see.
[20:28.640 --> 20:30.540]  I can send a GIF.
[20:34.410 --> 20:37.590]  I think it's this one.
[20:38.590 --> 20:38.790]  Yep.
[20:40.250 --> 20:41.670]  All right, so I'll send that GIF.
[20:43.370 --> 20:46.350]  And it appears on everyone's clients.
[20:47.370 --> 20:51.170]  And, yeah, some people who work on this app with me are here today.
[20:51.910 --> 20:52.510]  Let's see.
[20:53.230 --> 20:55.550]  Victor actually worked on some of the file sending stuff.
[20:55.550 --> 20:57.150]  So, yeah.
[20:57.410 --> 20:57.970]  How's it going?
[20:59.250 --> 21:02.070]  I think other people are online in this chat.
[21:02.730 --> 21:02.950]  Oh, yeah.
[21:03.110 --> 21:03.470]  There's Victor.
[21:04.030 --> 21:04.210]  Cool.
[21:04.870 --> 21:05.350]  Amelia.
[21:05.890 --> 21:06.890]  Where is Amelia?
[21:07.210 --> 21:07.750]  There's Amelia.
[21:09.810 --> 21:11.370]  Does everything look good out there?
[21:11.690 --> 21:12.990]  Like, pretty.
[21:13.170 --> 21:14.230]  How's the talk going so far?
[21:15.350 --> 21:16.130]  Okay, great.
[21:18.250 --> 21:19.210]  So, cool.
[21:19.410 --> 21:19.530]  Yeah.
[21:19.910 --> 21:27.530]  And now I'm going to do something that is really hard to do in any centralized, or impossible to do in most centralized messaging apps, especially the free ones.
[21:28.190 --> 21:29.410]  And that is...
[21:29.410 --> 21:31.270]  I'm going to send a very large file.
[21:33.830 --> 21:34.630]  Let's see.
[21:34.810 --> 21:40.570]  I'm going to send this three gigabyte Ubuntu ISO to everybody.
[21:40.570 --> 21:44.790]  I hope this works.
[21:51.050 --> 21:52.310]  Oh, no, it didn't.
[21:52.710 --> 21:54.810]  Well, demo effect.
[21:56.270 --> 21:57.930]  But the principle here...
[21:57.930 --> 21:58.730]  Well, maybe it will.
[21:59.030 --> 21:59.890]  Maybe it just threw an error.
[22:00.430 --> 22:11.390]  Anyway, the principle here is that when apps depend on a server, they have to limit file size because the server is a shared resource.
[22:11.390 --> 22:17.710]  But when users bring their own infrastructure to the party, you don't really have to limit people in that way.
[22:17.910 --> 22:22.950]  So, it's a cool illustration of how freedom... of how servers enhance software freedom in this particular case.
[22:25.030 --> 22:25.550]  But, yeah.
[22:26.190 --> 22:33.050]  What I think it's doing now is it's hashing the file, and then once it hashes the file, it will send a link to everybody, and they will have the option of downloading it.
[22:35.050 --> 22:35.410]  So...
[22:36.030 --> 22:36.470]  Let's see.
[22:36.530 --> 22:36.770]  Oh, yeah.
[22:36.930 --> 22:38.710]  And I'll show you what it's like to invite someone.
[22:38.710 --> 22:42.170]  The inviting process is actually quite a bit like...
[22:43.530 --> 22:44.750]  It's quite a bit like Slack.
[22:47.350 --> 22:47.750]  So...
[22:48.610 --> 22:49.650]  I think it's this one.
[22:51.490 --> 22:51.890]  Yeah.
[22:52.430 --> 22:52.710]  Okay.
[22:52.810 --> 22:55.070]  So, I have a new user here that we want to invite.
[22:55.230 --> 22:57.050]  They've just spun up an instance of quiet.
[22:57.210 --> 22:58.390]  This could be you joining right now.
[22:58.390 --> 23:09.410]  I will get them an invite link, copy it to my clipboard, paste it in here, and continue.
[23:10.350 --> 23:11.570]  And I'll choose a username.
[23:13.030 --> 23:13.750]  Charles.
[23:16.350 --> 23:18.150]  And this often takes a bit.
[23:18.150 --> 23:26.790]  And I'm not sure if it will work right now, just because of, like, timing and network issues and stuff.
[23:27.310 --> 23:27.830]  But...
[23:29.170 --> 23:33.310]  This client is making a connection over Tor to the owner's device over here.
[23:33.790 --> 23:36.730]  And we'll go through an onboarding process and should be able to join.
[23:42.190 --> 23:46.010]  One issue is that if Tor times out the first time, it has to try again a couple times.
[23:47.130 --> 23:52.090]  But, as we can see, the people who are in the channel are still mostly connected to each other.
[23:53.450 --> 23:54.550]  This should still be working.
[23:55.730 --> 23:55.870]  Yep.
[23:56.590 --> 23:56.950]  And...
[23:57.710 --> 23:59.630]  This guy's dead because I sent this giant file.
[24:00.170 --> 24:00.430]  All right.
[24:00.430 --> 24:02.110]  So, I'm gonna go back to my talk.
[24:03.470 --> 24:04.770]  That's the demo.
[24:06.750 --> 24:07.310]  And...
[24:08.190 --> 24:08.890]  Let's see.
[24:11.430 --> 24:11.990]  So...
[24:12.730 --> 24:13.750]  I'm in here.
[24:14.590 --> 24:15.450]  And here.
[24:23.220 --> 24:23.780]  Cool.
[24:26.750 --> 24:28.010]  So, here's how it works.
[24:29.050 --> 24:32.890]  I said syncing limited amounts of state and private networks was getting easier to do.
[24:33.110 --> 24:34.530]  So, now I'll explain why.
[24:35.750 --> 24:43.950]  First, the invitation code I sent in my demo to invite a new user is an Onion address that points to an onboarding API running on the owner's device.
[24:45.190 --> 24:50.590]  An Onion address is an address within the Tor network that is unguessable, lasts forever or as long as we need it.
[24:51.750 --> 24:55.310]  And all data exchanged with an Onion address is end-to-end encrypted by Tor.
[24:56.810 --> 25:01.310]  Onboarding in Quiet is complicated under the hood, so I'll skip that, but you can ask questions about it.
[25:02.050 --> 25:15.350]  But when onboarding is complete, we have a closed network of users, all of whom are members of the same community, who know each other's Onion addresses and public keys, who can therefore all connect to each other over Tor, each with a signed certificate from the owner,
[25:15.710 --> 25:19.310]  with their user name, a public key, and that's it.
[25:19.410 --> 25:20.730]  That's our closed private network.
[25:21.730 --> 25:23.310]  Everyone is connected privately over Tor.
[25:23.310 --> 25:25.930]  So, now, how do we sync state?
[25:27.170 --> 25:39.530]  To sync state, we use a CRDT called OrbitDB, which is built on a peer-to-peer protocol called IPFS, which we force to use Tor and only connect to the Onion addresses of other community members in our closed network.
[25:40.750 --> 25:44.090]  CRDT stands for Conflict-Free Replicated Data Type.
[25:44.470 --> 25:53.690]  CRDTs can merge state changes between a network of nodes with eventual consistency, meaning that no matter what changes on any node, all nodes will eventually sync to the same state.
[25:55.130 --> 26:01.830]  OrbitDB is fairly unusual among CRDTs in that it comes with all of the necessary peer-to-peer parts built in for sharing data.
[26:04.010 --> 26:15.150]  When someone sends a message, OrbitDB adds that message to its local state, calculates a hash of its new state, broadcasts this hash to other members using a gossip protocol that's part of IPFS.
[26:16.350 --> 26:28.390]  And, um, a gossip protocol is often called an epidemic protocol, which, uh, because it spreads peers... the way it works is it spreads data from peers to their neighbors to their neighbors and so on until everybody gets the data.
[26:30.330 --> 26:32.090]  Here's a really simple visualization of that.
[26:32.310 --> 26:37.790]  This person sends a hash, they send it to their neighbors, they send it to their neighbors until everyone has it.
[26:38.570 --> 26:45.070]  On the receiving side, whenever OrbitDB sees a hash it has not seen yet, it knows there is data it has not yet synced.
[26:45.490 --> 26:56.210]  So, it uses this hash like a link to fetch, uh, that data using IPFS, and then when it gets that, any data it links to, and so on, until it has synced everything there is to sync.
[26:56.410 --> 26:57.970]  This is a little bit like how Git works.
[26:59.830 --> 27:05.850]  For sending files, Quiet also uses IPFS, and IPFS splits files into blocks.
[27:06.010 --> 27:08.310]  This is the, this is what we used when we sent that GIF.
[27:09.210 --> 27:13.770]  Um, it splits files into blocks and fetches blocks from peers that have them, like BitTorrent does.
[27:14.450 --> 27:18.610]  And, of course, we need to introduce some limit on the number of messages, and especially files.
[27:18.930 --> 27:26.690]  Otherwise, our state will grow and grow until it's too big to fit on a single device, and then we violated the constraint of syncing limited amounts of state.
[27:27.750 --> 27:33.710]  One really great way to limit state and privacy tools is to do time deletion, because then it's a feature and not a bug.
[27:34.190 --> 27:39.590]  Time deletion protects you in the case of a device being compromised or seized, and it also limits our state size.
[27:42.250 --> 27:53.810]  Quiet uses Electron and React on desktop, React Native on mobile, and underneath all that, on all platforms, we use Redux and Node.js with OrbitDB and the JavaScript implementation of IPFS.
[27:54.610 --> 27:56.610]  And then underneath all that, there's the Tor binary.
[27:57.630 --> 28:03.330]  So, you know, you could probably imagine a lot of the friction here is just getting all these pieces to work together.
[28:04.630 --> 28:08.770]  But that's the part that can get easier and easier as the tools and libraries improve.
[28:09.370 --> 28:16.550]  And I think that with enough investment in libraries and tooling, we can get to a point where you could build something like this in a weekend hackathon.
[28:19.790 --> 28:26.310]  So, one question is, okay, this works for a chat of a few people, but would it work for a team of 100 or a conference like HOPE?
[28:27.310 --> 28:31.810]  The front end is still a little slow, so we ran some performance tests on our underlying stack.
[28:33.630 --> 28:37.410]  This was a test we ran of messages per second.
[28:37.630 --> 28:44.770]  We sent 100 messages in five separate tests at 1, 5, 10, 20, and 50 messages per second.
[28:45.050 --> 28:46.590]  The results are actually pretty random.
[28:46.930 --> 28:49.410]  It's some interaction between Tor and OrbitDB.
[28:49.590 --> 28:58.670]  But the meaningful thing here is that the average is that when we sent these 100 messages, average latency is well under two seconds, even at five messages per second.
[29:01.630 --> 29:05.550]  And then the max stays reasonable under four seconds.
[29:07.770 --> 29:11.030]  And then another question would be, is it still fast when a lot of users join?
[29:11.350 --> 29:14.370]  Here we ran a test with 100 users, and there was a problem.
[29:15.650 --> 29:21.350]  You can see delivery time of messages spike in the upper 20% of users, up to unacceptable numbers.
[29:21.350 --> 29:22.590]  This is the max, not the average.
[29:22.710 --> 29:23.350]  The average is much better.
[29:24.870 --> 29:27.450]  We don't think this is really a scalability problem inherently.
[29:27.630 --> 29:32.270]  We think it's more just a bug with how we're using IPFS, because it doesn't seem to vary that much with the size of the community.
[29:33.450 --> 29:34.970]  But it did mess up our test a little bit.
[29:36.030 --> 29:41.490]  And then the last thing is, we tried to simulate just this question of, well, okay, is Tor the bottleneck here?
[29:41.490 --> 29:49.470]  And we did that by connecting five users in a chain to simulate number of hops out in a larger gossip network.
[29:50.490 --> 29:53.570]  And messages still arrive pretty fast in this case.
[29:53.790 --> 30:03.770]  You can see four hops out is that top line, and we're still under two seconds for the most part, except for that one spike.
[30:05.510 --> 30:11.850]  So this simulates at least the level of data moving across peers in the Tor network.
[30:11.950 --> 30:15.490]  This simulates a group of, I think, around 1,000 users, if my math is right.
[30:16.790 --> 30:17.810]  So what about mobile?
[30:18.310 --> 30:20.150]  We haven't done performance tests on mobile yet.
[30:20.370 --> 30:21.610]  We have a proof of concept.
[30:21.610 --> 30:23.150]  It works in our pockets.
[30:23.150 --> 30:23.750]  We've tried it.
[30:24.590 --> 30:30.130]  But the main issue with mobile is that push notifications will still require a server in some way.
[30:32.530 --> 30:37.050]  So we have a stack that lets us pretty much eliminate servers.
[30:37.790 --> 30:44.330]  But how meaningful are its security and privacy properties to activists and others doing sensitive work?
[30:45.310 --> 30:52.270]  Before we built Quiet, we conducted 18 user interviews with activists, journalists, and security experts that advised both activists and journalists.
[30:53.170 --> 31:02.790]  The most important security requirements that this re-identified were usability, end-to-end encryption, timed deletion, and resistance to account credential phishing.
[31:03.390 --> 31:10.010]  Neither users nor security experts mention specific properties of encryption like forward or backward secrecy as requirements.
[31:11.170 --> 31:14.030]  We believe that Quiet's design meets these requirements.
[31:14.570 --> 31:16.490]  Messages are end-to-end encrypted by Tor.
[31:17.110 --> 31:18.770]  Metadata is protected by Tor.
[31:18.770 --> 31:20.870]  There are no passwords to phish.
[31:21.570 --> 31:26.610]  Timed deletion is not implemented yet, but it's planned and possible.
[31:27.430 --> 31:31.410]  And users do not reveal email addresses, phone numbers, or even IP addresses.
[31:32.910 --> 31:39.370]  The fact that Signal reveals phone numbers was the main complaint about Signal from the experts and users we interviewed.
[31:41.310 --> 31:51.570]  Of course, we have not solved any of the threats of supply chain attacks, attacks on update servers, endpoint attacks, timing attacks on Tor, censorship of Tor, and so on and so on.
[31:51.710 --> 31:55.950]  All of these were main threats, but they're similar or bigger problems in the centralized world.
[31:57.530 --> 32:01.810]  So now I'm going to do a quick rapid-fire run of related work.
[32:02.350 --> 32:04.090]  I wonder if I can get a time check.
[32:04.550 --> 32:04.870]  Oh, cool.
[32:05.050 --> 32:05.770]  So we have some time.
[32:06.030 --> 32:06.530]  All right.
[32:08.450 --> 32:13.470]  So first, it's useful to draw the contrast with Signal and Matrix.
[32:14.130 --> 32:20.450]  Signal reduces the server's power by using encryption, limited data retention, and locally stored contacts.
[32:20.730 --> 32:25.350]  But servers and Signal are still very powerful, and they're very much a point of failure.
[32:25.350 --> 32:33.570]  And while phone numbers do decentralize the social graph, they're a huge gift to anyone who's able to seize an activist's phone, right?
[32:33.710 --> 32:37.250]  Because then they have access to all their contacts, everyone they've communicated with in Signal.
[32:38.910 --> 32:48.810]  Matrix also uses encryption, and it uses federation, which means anyone can run a server, servers are interconnected, and it can work great for organizations that run their own servers.
[32:49.790 --> 32:58.970]  But the thing with federation is that we have an example of federation in email, and Gmail shows how federation can still give big tech tons of power over most users.
[32:59.530 --> 33:04.050]  And federated systems leak metadata even worse in some cases than centralized ones.
[33:05.090 --> 33:10.970]  So next are some projects that use Tor to protect metadata and reduce server dependence.
[33:11.870 --> 33:18.630]  Ricochet Refresh uses Tor Onion addresses to connect users one-to-one, and does not do group messaging, as far as I know yet.
[33:19.790 --> 33:29.890]  Kutch works like Ricochet Refresh, but for group messaging it uses ephemeral servers that are untrusted, ephemeral, and easy to run, and learn almost nothing about users.
[33:30.590 --> 33:31.490]  But it still needs servers.
[33:32.810 --> 33:40.530]  Federation is the Worst of All Worlds is a must-read on the issues of federation by security expert and Kutch creator, Sarah Jamie Lewis.
[33:42.630 --> 33:44.470]  Briar is a project that is awesome.
[33:44.730 --> 33:51.450]  It uses CRDT syncing, well, not exactly CRDT, but something like a CRDT over Tor, like Quiet.
[33:51.950 --> 33:59.270]  But in Briar you can join a group with someone without ever letting them connect to you directly, not even over Tor.
[33:59.910 --> 34:01.590]  That's something you can't do in Quiet.
[34:01.830 --> 34:06.230]  And the difference between these two approaches contains some really interesting usability trade-offs.
[34:06.810 --> 34:12.770]  It also means Briar works for users who want to stay off the Internet completely, connecting over Bluetooth or a local network only.
[34:14.990 --> 34:20.570]  Session attempts metadata protection without Tor by using Onion routing servers paid in its own cryptocurrency.
[34:21.270 --> 34:24.930]  Because they're paid, these servers can also store messages for offline users.
[34:26.350 --> 34:30.690]  Okay, next comes some approaches that do not attempt to protect metadata, but are still worthy of a mention.
[34:32.030 --> 34:36.850]  Birdie, like Briar, allows for chat over Bluetooth and local networks as well as over the regular Internet.
[34:37.510 --> 34:39.650]  And like Quiet, it uses IPFS and OrbitDB.
[34:40.550 --> 34:45.430]  Cabal is functionally very similar to Quiet and uses HyperCore, which is analogous to IPFS.
[34:46.670 --> 34:49.430]  Pinecone is an effort by Matrix to go full peer-to-peer.
[34:49.610 --> 34:51.530]  And this would be a game-changer if it happened.
[34:52.270 --> 34:58.190]  But Pinecone is still really minimal and doesn't address things like offline message delivery or metadata protection.
[34:59.690 --> 35:03.550]  Pinecone is almost like a faster Tor but without any metadata protection.
[35:04.010 --> 35:06.050]  It's just an overlay network for connecting nodes on the Internet.
[35:07.530 --> 35:14.430]  Ether with an A is a peer-to-peer Reddit that attempts to tackle spam and let communities elect moderators using a bespoke peer-to-peer stack.
[35:15.230 --> 35:23.930]  Secure Scuttlebutt is a peer-to-peer protocol for syncing individual status updates like in a social network that uses volunteer-run servers for peer discovery and offline storage.
[35:25.290 --> 35:32.510]  Radical is a peer-to-peer replacement for GitHub using volunteer always on nodes inspired by Secure Scuttlebutt and a syncing algorithm based on Git.
[35:33.510 --> 35:39.050]  So next are some just general important parts of the movement for server independence that I'll run through really quickly.
[35:40.030 --> 35:48.710]  This essay, Local First Software, Your Own Data in Spite of the Cloud, is a slightly less radical call to action than the one I just gave, because they're not talking about eliminating servers completely.
[35:50.490 --> 35:55.390]  Martin Kleppman is one of the authors of this essay and has co-authored a paper on seemingly every major theme in this space.
[35:56.410 --> 35:57.530]  Automerge is his project.
[35:58.990 --> 36:06.270]  Mixnats are probably the future of anonymity since they're resistant to the traffic analysis attacks that work on Tor, but they struggle to be fast enough for things like chat.
[36:07.470 --> 36:10.490]  Loopix is the mixnet paper to read if you're interested.
[36:10.490 --> 36:16.290]  And Nym tries to be faster and more scalable than Loopix by compensating nodes in cryptocurrency and making other improvements.
[36:17.550 --> 36:24.250]  Rollercoaster is the paper I found when Googling whether someone had tackled this question of group messaging and group interaction in a mixnet.
[36:24.450 --> 36:26.470]  And it's co-authored by Martin Kleppman.
[36:26.630 --> 36:28.690]  So he has papers on everything in the space.
[36:30.270 --> 36:35.590]  This library, Local First Auth, explores all the minutia of access control in a decentralized network.
[36:36.730 --> 36:39.850]  Braid is an effort to make state syncing an Internet standard.
[36:40.490 --> 36:44.630]  And the Braid meetings end up being a cool cluster of CRDT and peer-to-peer research folk.
[36:45.250 --> 36:48.310]  RedWord is a stack built on Braid that has its own demo chat app.
[36:49.790 --> 36:57.530]  And Conix is a paper on how to give people secure global usernames without a blockchain that can't be impersonated or taken away.
[36:57.790 --> 37:04.090]  This is, I think, the one thing it's probably worth using servers for, and where we're probably going to remain server-dependent for a while.
[37:05.510 --> 37:11.250]  So to give this a little more structure, here's a subjective attempt I made to categorize these projects on a scale of server-dependence.
[37:11.590 --> 37:14.530]  And there's some really difficult comparisons here.
[37:14.650 --> 37:16.650]  And the scale, obviously, is totally subjective.
[37:17.030 --> 37:19.490]  But, you know, this is...
[37:19.490 --> 37:21.430]  I think it's still helpful and meaningful.
[37:22.990 --> 37:26.370]  One question is whether using Tor counts as using a server.
[37:26.630 --> 37:30.530]  And I think it doesn't because of Tor's robustness and Tor's scalability.
[37:31.710 --> 37:34.590]  I'm sorry, robustness, scalability, and neutrality, too.
[37:36.530 --> 37:36.930]  Okay.
[37:37.210 --> 37:45.430]  So, in conclusion, I think there are moments in the history of the free software movement where a clear common goal emerges.
[37:46.470 --> 37:53.930]  The parallel pushes in the 1980s by the GNU project and Linus Torvalds to build a complete free software operating system was one such moment.
[37:54.550 --> 37:59.470]  And the push in the late 1990s for a modern free software desktop was another.
[38:00.590 --> 38:03.110]  I believe we're staring at yet another such moment.
[38:03.470 --> 38:13.370]  One where we can rebuild collaboration tools without servers so that free software can once again hold big tech accountable as it always has.
[38:13.790 --> 38:23.050]  And give activists fighting authoritarianism and anyone doing sensitive work remotely in the pandemic meaningful privacy and security features that they currently lack.
[38:25.930 --> 38:26.950]  So, this is us.
[38:27.110 --> 38:27.850]  We really need your help.
[38:28.070 --> 38:33.230]  And the number one thing this movement needs is real groups of people ready to try out these tools.
[38:33.790 --> 38:34.910]  How am I doing for time?
[38:38.420 --> 38:38.780]  Okay.
[38:39.200 --> 38:39.440]  Yeah.
[38:40.080 --> 38:45.120]  We need people to try out our tools because projects like ours, the first way they fail is they don't find a niche.
[38:45.580 --> 38:53.640]  And the thing that would change everything for our development process would be to have three or five groups of people using Quiet every day, as we do, telling us what they need so that we can build it.
[38:54.300 --> 38:58.580]  If we could just find one group of people like that today, that would be a huge deal for us.
[38:59.020 --> 39:03.420]  So, if that's you or you can think of someone who it might be, that would be super helpful.
[39:03.600 --> 39:05.320]  And please approach me online or after the talk.
[39:05.760 --> 39:19.720]  Ideally, you'd have some reason to care about privacy and security, but also either be able to understand and evaluate really unaudited software like Quiet and understand the risks about that or your privacy and security needs would be very far from anything serious or critical.
[39:21.300 --> 39:29.600]  If you're interested in making technical progress on these tools, the Quiet team and I can help get you oriented on the different efforts in this space to help see where you can best plug in.
[39:30.420 --> 39:38.620]  Also, just quickly, some acknowledgements and gratitude to Guillaume Marceau, Lisa La Rochelle, and Ying Chang for their feedback on this talk, as well as everybody on the Quiet team.
[39:40.140 --> 39:40.540]  Cool.
[39:40.740 --> 39:42.100]  I think we can move to questions now.
[39:52.650 --> 39:53.270]  Thank you.
[39:53.510 --> 39:56.770]  And if anyone has any questions, please line up here behind the mic.
[39:57.630 --> 39:59.610]  Quick question from online.
[39:59.990 --> 40:01.330]  Are the slides going to be online?
[40:03.230 --> 40:03.750]  Yes.
[40:03.990 --> 40:05.830]  I can post them to Twitter later today.
[40:06.070 --> 40:08.650]  And so you can get the references to those other projects.
[40:13.470 --> 40:14.870]  Hey, thanks for the talk.
[40:15.030 --> 40:15.330]  Really great.
[40:16.190 --> 40:38.590]  I'm curious to hear some on how you envision moderation will work in these decentralized spaces, both for, like, content that might be, you know, crafted to push people out of them or, you know, combatting against, like, civil attacks or any sort of identity flooding.
[40:39.270 --> 40:44.010]  You know, if you send out an invite and then 500 people jump in and then your community is in.
[40:44.150 --> 40:50.850]  So I'm just curious, like, the ideas around how to manage that when there's no central authority dealing with it.
[40:50.850 --> 40:51.870]  Yeah.
[40:52.210 --> 41:05.030]  Well, you know, in my talk I said the trick that makes collaboration tools a good place to start is that they're limited-sized state in closed networks, right?
[41:05.210 --> 41:12.670]  And that closed networks thing is important not just for the technical layer, but also for the social layer, for dealing with social problems like moderation.
[41:12.870 --> 41:15.670]  And I suppose civil resistance becomes a technical problem, too.
[41:16.250 --> 41:22.490]  So if we're thinking about open networks that anyone can join, that's a much harder problem.
[41:22.970 --> 41:25.110]  And it's one we don't have to solve just yet.
[41:25.370 --> 41:39.650]  But if we're thinking about closed networks, where there is someone who has the power to let people in selectively, to kick people out, and also to appoint moderators, you know, we can do the whole... we can do everything that a moderation stack can do within this framework.
[41:39.650 --> 41:48.070]  I mean, we haven't done it yet, but you can shadow ban people, you can hide posts, you can post a code of conduct, you can appoint moderators to enforce a code of conduct.
[41:48.870 --> 41:55.510]  You could even potentially let users fork the community if they think the moderators are not adequately enforcing the code of conduct.
[41:55.710 --> 41:58.210]  You can do content warnings, the whole thing.
[41:58.850 --> 42:04.610]  The one question you had about what if a flood of people comes in from an invite link, you can have a feature for that.
[42:04.610 --> 42:07.310]  I mean, the invite link is not itself giving people access.
[42:07.490 --> 42:12.290]  The invite link is just a connection to the owner's onboarding API.
[42:12.610 --> 42:15.130]  They don't have access to the internal network at that point.
[42:15.170 --> 42:20.370]  So the onboarding API can do what it wants to say, okay, only 10 people from this invite link.
[42:20.370 --> 42:24.010]  Or it could also roll back all those invites if it wanted to later.
[42:25.250 --> 42:36.070]  The one thing I think I should say, just to fully answer your question, is systems like these cannot stop a bunch of people coming together consensually, happily, to do something that is bad for the rest of society.
[42:36.350 --> 42:40.830]  And for that, I think you need richer social norms and potentially, in the worst case, law enforcement.
[42:41.830 --> 42:42.390]  Thank you.
[42:44.430 --> 42:46.450]  I have another question from online.
[42:46.630 --> 42:47.950]  This question is from Greylight.
[42:47.950 --> 43:01.290]  Did the delay in deploying IPv6 and the, quote, original sin of NAT contribute to the centralization of servers, or would the business interests of big tech have done this just as quickly regardless?
[43:03.650 --> 43:06.270]  Well, if you think of that slide, that's a super good question.
[43:07.090 --> 43:22.530]  If you think of that slide, of all of the reasons why servers are helpful, I mean, only a few of those are related to the problems of not being able to connect two peers directly because of the delayed IPv6 or because of NATs.
[43:22.650 --> 43:26.730]  So just, the question is referring to the problem of, like, you have two peers on the Internet, how do you connect them?
[43:27.010 --> 43:29.050]  And that turns out to not be a trivial problem.
[43:29.610 --> 43:31.550]  Tor actually makes it a pretty trivial problem.
[43:31.670 --> 43:33.890]  If you're both connected to Tor, you're going to connect.
[43:34.010 --> 43:35.050]  And that's why I really like Tor.
[43:35.310 --> 43:38.470]  So Tor sort of gives you that perfect Internet where two peers can always connect.
[43:38.610 --> 43:40.510]  It kind of, like, refers to the Internet's original sin.
[43:41.650 --> 43:44.650]  But there are a lot of problems that just being able to connect doesn't solve.
[43:44.790 --> 43:46.190]  Like, what if someone's offline?
[43:46.350 --> 43:49.170]  And how do you... where does your message to them go when they're offline?
[43:49.410 --> 43:52.470]  And do you have to wait until you're contemporaneously online to deliver that?
[43:52.490 --> 43:54.550]  Or is there someone who can hold on to it for you?
[43:54.870 --> 43:57.410]  So peer-to-peer networks do need to solve those problems.
[43:58.650 --> 44:08.890]  And I think those problems are tricky enough that big tech probably would have risen up in the state it's in, even if we had been able to connect directly to each other's computers.
[44:13.260 --> 44:18.360]  In my experience working with activist spaces, everybody is really into the idea of privacy.
[44:18.700 --> 44:20.220]  And they're like, yeah, encryption, let's do it.
[44:20.460 --> 44:25.080]  And then the amount of technical support that these, you know, non-tech-savvy folks need is just wild.
[44:25.540 --> 44:31.100]  What barriers to entry do you see or anticipate with QUIET in particular?
[44:31.100 --> 44:37.700]  Well, I mean, we're targeting ease of use that's at the level of Signal or Slack or Discord.
[44:38.340 --> 44:41.720]  The one catch with the current system is around invitation.
[44:42.060 --> 44:47.800]  There can be situations where just if the owner isn't online, that can be a little confusing.
[44:47.800 --> 44:49.640]  But we can address stuff like that.
[44:51.720 --> 45:02.040]  And there is sometimes a user experience issue of, like, if no one's online and a message is sent, you might get sort of new, old messages, like things you hadn't seen before that are syncing.
[45:02.360 --> 45:06.180]  But that's a user experience problem, and it doesn't come up that much.
[45:06.660 --> 45:08.140]  So I think the biggest thing is features.
[45:08.340 --> 45:09.460]  Like, we don't have reactions.
[45:09.460 --> 45:11.120]  We don't have, like, app mentions.
[45:11.320 --> 45:13.340]  We don't have all the, like, granular notification controls.
[45:13.480 --> 45:20.860]  These apps are really full-featured, and there's kind of one direction of getting the stack to be pretty reliable, which we've made a lot of progress on.
[45:20.940 --> 45:25.360]  But there's the other direction of making it work as good as Slack and Discord do.
[45:26.580 --> 45:28.720]  And I think once you get there, you're in the running.
[45:29.200 --> 45:31.140]  You know, I was at Fight for the Future.
[45:31.140 --> 45:32.120]  We use Slack internally.
[45:32.180 --> 45:33.220]  Now they use Matrix internally.
[45:33.660 --> 45:37.160]  There was some grumbling when people adopted Matrix, but it went pretty well.
[45:37.320 --> 45:38.940]  And I've tested quiet with the team there.
[45:39.100 --> 45:41.700]  And, like, you know, it doesn't do anything.
[45:41.860 --> 45:43.360]  All the things they need yet is the problem.
[45:44.440 --> 45:46.020]  But there isn't, like, an intrinsic problem.
[45:46.100 --> 45:50.560]  And I think, actually, peer-to-peer apps can be more accessible than federated ones because you don't need someone to run the server.
[45:50.860 --> 45:54.300]  And you don't have to think about, like, oh, I'm Holmes at, like, my home server.
[45:54.500 --> 46:00.060]  Or there's things about the onboarding experience with federated systems that are just a little bit not what people expect.
[46:00.520 --> 46:05.600]  With peer-to-peer apps, or this one anyway, it's just pick a user name or enter the link, pick a user name, and you're in.
[46:05.820 --> 46:06.120]  And that's it.
[46:07.180 --> 46:07.420]  Awesome.
[46:07.600 --> 46:07.880]  Thank you.
[46:08.200 --> 46:08.280]  Yeah.
[46:12.740 --> 46:28.240]  So I had a question about if there's a user that is offline or has very limited, or offline a lot or has limited connectivity, how effective is this at message queuing?
[46:28.240 --> 46:34.220]  Like, say there's a user that's like, oh, I know I'm going to be offline, but I want to be able to back-read when I can get Internet again.
[46:34.740 --> 46:37.220]  Is there a mechanism that would allow them to do that?
[46:37.240 --> 46:41.060]  Or do they just have to get back online before those messages get dropped by their peers?
[46:43.800 --> 46:45.080]  Let me understand the question.
[46:45.280 --> 46:47.660]  I'll just maybe say something to help understand it better.
[46:48.240 --> 46:49.740]  Nothing ever gets dropped.
[46:50.800 --> 46:54.480]  Well, time deletion would drop things eventually.
[46:56.240 --> 47:02.320]  Doing time deletion at like a five minutes or one hour scale would not work so great in the system, because you would lose things.
[47:02.320 --> 47:10.560]  But doing time deletion at like a two weeks or month scale would work fine, presuming you have connectivity in that period.
[47:12.540 --> 47:21.060]  I think, yeah, if you had very short time deletion scales, then offlineness would lead to you missing messages.
[47:21.060 --> 47:23.020]  But I think that's the user's intent in that case.
[47:23.880 --> 47:24.320]  Okay.
[47:24.400 --> 47:31.580]  I was just wondering, is there a default time deletion span in the system?
[47:31.580 --> 47:34.180]  Or what is it currently working with?
[47:34.260 --> 47:35.500]  We haven't implemented it yet.
[47:35.520 --> 47:36.680]  It's planned but not implemented.
[47:37.000 --> 47:46.580]  And I think that, you know, like if a good floor would be something like three months or six months, and then users could ratchet it up from there.
[47:46.840 --> 47:47.280]  Okay.
[47:47.740 --> 47:48.060]  Thank you.
[47:48.540 --> 47:48.640]  Yeah.
[47:50.460 --> 47:53.260]  One question from online from user LEGO KTM.
[47:53.460 --> 47:57.460]  You did call out GitHub as a problematic proprietary server.
[47:57.640 --> 47:59.460]  Why is the quiet code developed there?
[48:00.340 --> 48:01.200]  That's a good question.
[48:01.200 --> 48:05.140]  I think the issue isn't so much...
[48:05.140 --> 48:05.820]  It's like...
[48:06.400 --> 48:12.200]  It's that thing I said about, is free software an ethical choice like being vegan?
[48:12.200 --> 48:16.500]  Or is it a movement to try to build power?
[48:17.320 --> 48:18.640]  And I think...
[48:19.940 --> 48:25.660]  I think if it's a movement to try to build power, you can think about it a little bit differently than, okay, we have to boycott everything.
[48:27.520 --> 48:41.680]  I think at some point, we'll want to run our own infrastructure so that we can be sure that our users are getting updates from us and not from, you know, the U.S. government subverting Microsoft to send an update through GitHub to our users.
[48:41.680 --> 48:46.760]  So there will be a real practical security reason for using it at some point.
[48:46.900 --> 48:51.820]  And at that point, we'll embrace running our own infrastructure the way Tor Project and others have.
[48:52.220 --> 48:56.700]  But at this stage, we've got a huge mountain to climb just getting this stuff working.
[48:56.700 --> 48:58.320]  And so I'm choosing my battles.
[49:01.970 --> 49:08.550]  As you've described quiet, there's just one major, like, master that allows for invite, right?
[49:09.250 --> 49:10.230]  One major what?
[49:10.410 --> 49:11.870]  Master for allowing invite?
[49:12.070 --> 49:16.570]  Like, if the boss node is offline, then invite doesn't work?
[49:16.730 --> 49:17.950]  That's currently correct.
[49:17.950 --> 49:31.410]  Although we can use a tool in the Tor ecosystem called Onion Balance to share that responsibility partially across either everybody in the community or some set of moderators and admins.
[49:31.570 --> 49:31.850]  Okay.
[49:31.930 --> 49:32.410]  If we want to.
[49:32.590 --> 49:33.870]  Right now, it's just one.
[49:34.370 --> 49:34.650]  Okay.
[49:34.770 --> 49:41.170]  But the plan is to move to a, like, multi-master system so that you don't have to have the person who started the group online always?
[49:41.170 --> 49:42.070]  Yes.
[49:42.370 --> 49:54.310]  And the one caveat is that if you want to do unique usernames, a good starting point is to still rely on the owner to be the sole giver of unique usernames.
[49:54.650 --> 49:59.390]  You could have a consensus algorithm, but that gets dicey.
[49:59.390 --> 50:08.650]  So probably what we would do in adding Onion Balance so that anyone can join, even when the owner is offline, is let people join as a guest first.
[50:08.910 --> 50:11.870]  And then they would be sort of in the CRDT as a guest.
[50:11.970 --> 50:17.610]  And then when the owner came through, the owner could see their certificate signing request, sign it, send that to the CRDT.
[50:17.710 --> 50:24.070]  Even if they weren't both online at the same time, they could be sort of blessed as a full user and have a real username.
[50:24.330 --> 50:26.190]  Something like a Nick serve in an IRC or something.
[50:27.130 --> 50:27.950]  Sounds good, yeah.
[50:28.110 --> 50:34.730]  My experience with Slack, Matrix, et cetera, is that rarely is the person who started the group online when everyone else is.
[50:34.970 --> 50:39.270]  So that restriction seems like it is a major usability issue.
[50:39.450 --> 50:39.890]  It is.
[50:39.970 --> 50:40.810]  It's super annoying.
[50:41.070 --> 50:45.070]  But yeah, there is a path to resolving it, but it introduces some complexity, so we've deferred it.
[50:45.410 --> 50:48.790]  Another path to solving it is to try to keep phones online as much as you can.
[50:51.270 --> 51:04.030]  If the owner is running on a desktop and on an Android device and both are able to give out certificates, you get decent coverage from that.
[51:04.370 --> 51:06.430]  But yeah, not great.
[51:07.010 --> 51:07.610]  Thank you.
[51:10.330 --> 51:11.550]  Thank you again for the talk.
[51:13.670 --> 51:19.550]  Just so everyone knows, we do want to hear about any experiences you've had at HOPE, your opinion of how this has gone this year, positive or negative.
[51:19.890 --> 51:24.850]  When the event is over, please feel free to send us email at feedback at hope.net.
[51:25.810 --> 51:27.810]  Feedback at hope.net.
[51:28.210 --> 51:28.790]  Thank you.
[51:28.790 --> 51:29.710]  Thanks, everybody.
[51:30.530 --> 51:30.770]  Thank you.