[00:00:00] Katherine Druckman: Hey everyone. Welcome back to Reality 2.0, I'm Katherine Druckman. Doc Searls is co-hosting with me as usual, and we have two guests today. One of them is a regular and he is Kyle Rankin, who you I'm sure you know by now. But Kyle Rankin is the newly installed president of Purism. If you don't know what purism is, you should definitely check that out.

But you probably do because you've listened to the show before. And we also have Holmes Wilson who is, among other things, the co-founder of Fight for the Future, which is a great organization. You should check out if you're not. And also the founder of Quiet and we will let him kind of fill those out a little bit, but, uh, before we get started, I wanted to remind everyone to check out our website at reality2cast.com.

That is the number two in the URL. And I think there is a chance we might have some pretty interesting supplementary information for this episode. So definitely check it out there. Um, so yeah, so Doc, I'm going to hand it over to you to, to give a more thorough introduction. Tell us a little bit more about what we're talking about today.

[00:01:06] Doc Searls: Well, I learned about Quiet and Holmes from, I think it was from something he posted in the, um, the BR a Berkman client list of announcements. Uh, and, uh, I've been, I'm an, I'm an alumnus fellow of the Berkman Klein center at Harvard. And I'm still run a project there, which is to say they have a server that they let me use.

But I'm on the announcements list and I saw what he was doing when he, when he announced that I thought, okay, we have to talk about this because it looks really interesting. So with that, I just, um, and then I got a little demo, uh, Holmes and I talked earlier this week. I was very intrigued by it, um, because I think we need it.

So, so Holmes, you want to explain a little bit about where Quiet's coming from and what it's about. 

[00:01:49] Holmes Wilson: Sure. Um, so Quiet is an attempt to build an alternative to slack or discord. Um, the team chat apps like slack or discord that does not depend on any central server. And instead of depending on central server infrastructure in quiet, the app on your device connects to that apps on the devices of the people in the community that you're in and syncs data over in this case messages over Tor using, um, using IPFS and an IPFS based CRDT, which is a technology for, um, for sinking state, between, uh, decentralized or in a decentralized context.

And the advantages of this are potentially, um, privacy and security, but also, uh, it's really good for software freedom because you aren't dependent on code, running on a cloud service that. But you either have to sort of bring your own server or essentially give that part of your software. Freedom to whoever is running that server.

The state that it's in is very early. No one should use it for anything that requires security at the moment. Um, and it has almost no features except being able to, um, being able to create basically a space where people can chat and I can talk a bit more about, about how to do that.

Isn't quiet and how it does that under the hood. Um, but our goal is to make something that has the features you'd expect from, um, something like slack or discord element, but that, yeah, it doesn't require you bring your own server or just someone else's.

[00:03:24] Doc Searls: CRDT is a for collaborative editing, right. Is, and you're using it for that. And is it, do you have, do you plan for collaborative editing to be part of that? We generally don't think of slack that way or discord that way as sort of like people takes turns chatting. So how does that work? 

[00:03:40] Holmes Wilson: Yeah. Yeah. Um, yeah, CRDT was kind of, it's a conflict for your datatype.

Um, I think that's right. I, it, and it, um, It was initially, uh, it was the first solution to the problem of how do you make something like Google docs, um, where, or, you know, ether pad, where everybody can edit a document together. And everyone versions of the document sort of sync with each other. It was the first solution to the problem of how to do that in a decentralized context, without a central server, mediating that, and, you know, telling everyone what the latest changes were and without the problem of the documents, at some point, for some reason, getting out of, out of sync and people having different states, a CRDT was the first solution to that problem in, in the academic literature.

I think the paper came out in 2011. I might be misremembering. Um, but, um, but yeah. Uh, so, so you often think of it, um, as something that's used for real time document. But actually, um, you know, the problem of sharing state is between between different apps is something that happens a lot in apps that we're familiar with.

So messaging apps do it. I mean, you know, if you think about, um, the big, so, you know, most of the teams I was on before slack existed use IRC and the tricky thing with IRC that slack did really well. And that, that was a relief when we started using slack, despite the software freedom sacrifice was that, um, you know, with IRC, you had to kind of jump through hoops to be able to see messages that were sent while you were offline.

Um, you know, I remember people setting up like, it'll be on a server and then being able to connect to it or, or using some type of. Yeah, you had to kind of do, do funny things to, to be able to, um, to, to see what was sent while you were gone, whereas slack, um, would let you go offline and you could come back online and your client, which has asked slack server for the latest messages that were sent while you were gone and slack would oblige and, you know, uh, in sync.

And so what's happening there as a, as a sinking of state between, um, between you and the server and also between all the peers in the server. And so effectively a sinking of state between, um, everybody in the, in the slack channel and, um, the community. And then the trick is if we want to create the thing is if we want to create something that feels as functional as slack, where you can see stuff that was sent while you're gone, um, and where everybody kind of sees the same conversation without having to, you know, do sort of special tricks, you need something like that.

You need something that can sync state reliably, and a CRDT is really good for.

[00:06:36] Katherine Druckman: I feel like I inevitably, I want to take the questions to somewhere. That's going to get us emails about being too political, but considering things that are going on in the news, let's just say, I'm wondering how you see, uh, this type of, um, application of your technology being used to protect people who might want to communicate about things that are very controversial.

[00:07:05] Holmes Wilson: Yeah. So, I mean, I think Tor is known for enabling things that are controversial. It's it's in a set of technologies that are very radically empowering. I think end to end encryption itself is one of those technologies, right? Where it sort of works. Whoever's using it in this very reliable way and has these properties that, um, are really desirable for privacy, but it.

And to an encryption, you know, Diffie-Hellman key exchange does not care who you are. It gives us security properties wherever you are. Um, I think that, um, I mean, we could talk more about it, but I think I, um, I've been in this space a while and I think that the basic, well, I think the basic, um, liberal values of, um, you know, liberal and this sort of traditional sense values of, uh, freedom of expression and, um, and freedom of association are extremely important to preserving democracy.

And I think that they're the extension of those values into this TechSpace as like software freedom and being able to read and understand and modify and distribute, um, the code that you're using, um, for the applications that are important in your life. I think that that's really, really important too.

And, and the expressive, um, Uh, freedom of software developers is also something really important for society. So I'm kind of, I don't know, I guess now I'd say like sort of old fashioned or traditional in that sense. Um, but in an unapologetic way. And, and ultimately I think that, um, you know, tools that are radically empowering are really good for society because sometimes majority's, you know, make that decisions.

I mean, I came up as an activist in the time of the Iraq war and we saw how that turned out, you know, and, and, um, and at the time I think, uh, it was very unpopular to be against the war. You know, it's the kind of thing that might damage your career or, you know, make you enemies with your neighbors. And, um, and, and I think.

I think, you know, in this moment, people sometimes think about controversial things as being sort of antisocial, but we have to remember that throughout history, controversy has been really important for keeping society, um, honest and for preventing some of like the worst, uh, you know, overreaches of power or the worst types of violence by, by, um, you know, majority's or the government.

And so the government, the governments should say. Um, and so, yeah, I think tech, like this is really great and this is why I'm doing it. You know, I, I, I, my, in my, my work has gone back and forth between tech and politics and I'm in like a tech side, but I used to sort of doing as co-founder of fight for the future, more straight up activism on issues like privacy, um, and, and, uh, freedom of expression online.

And. Yeah. So the I'm working on this for a reason, cause I believe in these things and cause I think, um, I think we need more radically empowering technologies and more software freedom and more autonomy. Um, and uh, and that, that will make the world better, you know? And, and, and then I think there's a family of potential uses for technology like tour.

Um, you know, in places where there are authoritarian governments that are trying to continue and where movements are trying to unseat those governments, you know, I think towards, or technologies, power to aid, those movements can be overstated. You know, there isn't any tool that's gonna, like you push a button and you get around the great firewall or you push a button and you know, you can be whatever kind of radical radical activists and the dictator can find you and hurt you like that.

Tech is never going to really, uh, be a. You know, a silver bullet or a kind of all-in-one solution. But I think that, um, you know, human rights organizations and, um, and democratic governments, in some cases, including the us and EU have funded radically empowering technologies over the years, because they do seem to sort of turn the dial and give, um, people in resistance movements, just a little bit more breathing room, just a little bit more of an adage.

And sometimes that's all you need to get momentum, um, around a movement that can be, that can ultimately unseat a dictator. Um, and I don't know that that would be one of my greatest aspirations for, for this tool someday, although it's nowhere near where it needs to be in order to enable that kind of work.

Now it's just not, um, solid or scrutinized enough. So that, 

[00:11:54] Katherine Druckman: that actually kind of reminds me of, uh, so I, I, uh, have a couple of questions just real quick. And along those lines actually about, you know, being ready yet. We've talked the last two episodes, I guess, about Mastodon and how it mastered on his, seen this massive influx of new users.

Um, and also people just sort of reviving their old accounts that they had parked and it's seen a ton of activity. And the first part of the question is, do you see this sort of being like that at some point or, or, being as significant as Mastodon? But also, you know, in terms of being ready yet, I wonder how you think about that kind of last mile.

When you're getting something like this ready and making it usable, not just for the Uber geeks of the world, but for every everybody and make it because there, there are some clunkiness, for example, to something like Mastodon and you know, those of us here on this call probably don't notice it. I don't really notice it, but I've seen people mention these things.

Well, you know, when you follow somebody on a different server, you have to go for this extra step and, you know, it's confusing or, or something like that. And there's always this one little thing that, that keeps it from really taking off in the way that something a little bit simpler to use does. And I'm just wondering kind of how you think about getting it to that point.

[00:13:10] Holmes Wilson: Yeah. Um, yeah, that's, that's usually important. So, you know, I think we've seen with, um, with, uh, signal, um, that you can, if you make something you can sort of make us something to a point where it's usable for some group of people, you can. Um, you know, keep at it over the years and, and, and sort of keep polishing it and it doesn't have to be perfect.

But then in these moments where people are either, um, really worried about their privacy or really unhappy with another tool they're using, that's functionally similar, you can get a big influx of users from that other platform. And, you know, I think, I think messaging apps are pretty great and this respect, they, they, they have a degree of openness, which is that they are not, their functionality is kind of.

Commodity or something, or kind of like interchangeable. Like if the tool lets you communicate with your friends, that lets you communicate with your friends, if you want to move, um, a circle of friends from one messaging option, other typically you just have to sort of send an invite link to the group, to the group and say, we're okay, let's try this other thing, everybody move over.

And if everybody in that moment has an okay enough time moving over that the new group reestablishes itself on the new platform, then, um, you know, you just, you just had a little mini Exodus and that can feed on itself. And in these moments of, you know, the most recent memorable one was, was signal when WhatsApp put out an update that.

Showed up sort of carry cause it is privacy policy warning and or privacy policy change. And, uh, that triggered a kind of, um, collective awareness moment in India where people were all of a sudden switching on mass to signal, um, and signal servers can just barely, you know, single ad to like, hold on for dear life for, for a few weeks just to, um, just to keep up or maybe, um, and, uh, like single had a few of those moments before that.

Um, you know, and, and VPNs have moments like that. Um, you know, VPN use after the Snowden revelations or something or tour has had moments like that, I believe. Um, definitely locally, at least. Um, I think my, essentially my master plan for marketing is to make sure that the app is not clunky is, is, is, has.

Little enough clunk that you can have, you could possibly have a group of people really using it daily and enjoy it and just enjoying it and to confirm that that's the case. And we're doing that by dogfooding internally and by testing with a small number of groups, and then to make sure that we're ready for an influx.

If, if, if, and when one happens, um, by user testing that like that process of going from WhatsApp to quiet, or going from discord to quiet and going from slack to quiet and to see how that goes and making sure that it's smooth and that, you know, 20 people or 50 people or a hundred people I'll have a good time and make the, make the move.

And then I think, you know, you Polish and keep putting your tool out there and wait for that moment where discord messes up or where slack messes up and does something terrible or where, you know, um, people people's threat model changes radically and all of a sudden your tool fits their threat model.

Pretty good. Um, And, and I think as far as, uh, how we reduce the clunk to that level where, you know, you can have an influx like that, and it isn't limited by the, you know, by the clunkiness of the tool. Um, I think peer to peer, a peer to peer design actually gives us an advantage over a federated design.

Um, there's, there's an ongoing conversation about this and it's gotten a little bit contentious at points, um, between folks like groups like, um, you know, groups working on federated tech, like matrix or Mastodon, perhaps, um, and groups working on centralized, but free and open source tech like signal, um, in Moxy, Marlin spike signal founder, um, has this post called the ecosystem is moving where he talks about, um, it talks about how.

Innovation in a federated context is difficult and how creating user good users, user experiences in a federated context is difficult because most people aren't are not going to run a server. I think, I mean, there are many people in the free software movement, I think have thought, or at least hoped that the way we would get past this transition to the cloud would be that everyone would bring their own server and become common to have a server running in your house the way you have a wifi router in your house.

But, um, you know, for a server to be good, it has to cost a hundred bucks or a couple of hundred bucks, or maybe more than that. And it's just another thing people have to buy and they have to wrap their heads around it and maintain it. And I think that's always given the cloud and advantage. Um, and then if you don't bring your own server, you have to trust someone else's, um, and find some, you know, find a friend who has a server and that could be okay.

But even just the, like the part in the sign-on process where you have to enter, not just your username and your password, but also the server name and. So that you have permission to use that server or something that gets a little weird and, um, you know, or maybe there's a default server, but you don't wanna use the default when you do, um, that creates, uh, and I think with, with peer to peer apps, potentially, um, you can create a better user experience because you, the app itself can bring with it, all of the, so to speak infrastructure.

It needs in order to create the experience that it needs to create without depending on this like third, third party or third thing, and where you don't have to specify that third thing, you open up the app. So right now, the way, the way sign on works in quiet is you open up the app. Um, you can either join a community that was created by somebody else or create your own.

To join a community created by somebody else. You paste in a code, which is an onion address, but without the onion suffix, but it's basically a tracking and address to create a community. You just say, I want to create a community. And then you invite others by giving them that code. They, they, they go through process.

They open the app to paste in the code, uh, and you're on a community together. And then everything's normal. Uh, it just sort of works. And yeah, there's some weird things when, you know, if you're offline and, uh, and no one is online or if you're online at no one else's online, your messages might not get delivered for a bit.

But we found that in using it internally, that isn't such a big deal, like, especially with like working with other people, you tend to work at the same time as other people cause that's convenient or at least as a few of your collaborators. And so the sinking of messages all sort of works out. But I guess I should just go back and say, um, there's this debate about Federation.

Versus centralization where the centralization folks say that Federation is kind of both, um, a UX problem and also potentially a security problem, because, you know, if the, you are probably not as capable of securing your own server as Google is, or as sitting on this. And, but then if you use, if you're going to use, um, a central server or a very popular server that is very secure, you are then exposed to the problem of, well, the power that, that server wields over you.

And also the additional complexity of the system had to build in, in order to accommodate multiple servers, which itself could be a distraction or a security issue. Whereas with a centralized server, you don't have to essentially a system. You don't have to worry about. I think peer-to-peer is actually has more of the advantages than that centralization has, where you have one way that you're doing things and it works.

And you don't have to sort of choose who you're relying on. Um, you're relying on the app itself, but it also has the de-centralization advantages. Obviously the Federation does, in fact, more of them, um, you know, the, the operating and your computer is the, is the code is, is the whole system. And you have control over it by virtue of running it on your computer and being able to fork it, being able to understand it and you know, all that stuff.

Um, so, so I think peer to peer apps, once we get the plumbing, right, put us in a better position to create great user experiences and minimize clunk than, um, the federated system like Macedonia that said it doesn't we just don't just get that for free it. I think it opens up some doors. Sort of smooth the path or it gives us a better path, but we still have to walk that path and, um, and do the work of polishing things, which, you know, ultimately I think comes down to being familiar, uh, UX models that people are used to so that, you know, the app is familiar more than anything wherever possible.

And, um, and testing. 

[00:22:26] Kyle Rankin: So I'm glad you brought up signal. Uh, because one of the questions I had sort of, I guess, can somewhat relate to that, which is around the notion of identity. So, you know, you're on a platform known for an anonymous station, right? And so there's, there's definitely a lot of benefits for, in an MD, but at the same time, I was wondering how you made.

Um, I guess identity in general, um, like for example, signals cases, they, they started with the design decision of everyone has a phone number and that's your identity. And then, so it's transferable and now that's somewhat controversial as you know, I'm sure. And then they had some sense of, well now can we do something that doesn't require a phone number as the root of identity, right.

And then as a sort of re-engineer that, um, and so I was wondering, I imagine that you've factored that into sort of your design decisions for identity and maybe how one transfers identity between devices or, you know, that might be running quiet or, um, or I recoverability, I lose a device and now I want to rejoin all of that, um, like recovery, but I'll, I'll, I'll start with that and then just sort of 

[00:23:30] Holmes Wilson: go from there.

Yeah. Okay. So, um, so let's see, I think I'll just sort of say the way we do it first and then sort of talk about the principles behind it. So the, the first thing is that, um, is that the. Type of product we're targeting is a different type of product. It's sort of a different class of product that signal or WhatsApp.

We're building a chat out for teams, something more analogous to discord or slack, where you have a bounded number of users that are part of a community. And they were led in by some, by some initial, you know, admin or community creator. Um, whereas signal and WhatsApp are open networks where everyone comes in, you know, as themselves.

And you need to be able to talk to everyone else in the world. Um, open networks like that are difficult to, uh, are, are more difficult to address with a peer to peer app in the current state of peer-to-peer. Then a bounded network of members of the team. So right off the bat, I'm building something that's an August to slacker Dysport or for that matter of Google docs or, you know, on a sauna instance or a discourse community or something that class of apps where you have a bounded number of people that are all like in a private space together, but they've all been led in by somebody that is much, much easier to address with peer to peer app.

Um, and then, then something like signal would be, and so we're doing it that way. 

So let's see. I, the, the way that we handle identity and quiet is when is that, um, there is, uh, right now, and this will evolve and get more complicated as we, as. Um, move forward because it's, it's a little too, there is some clunky right now.

There's some clunkiness and unfamiliarity right now. Um, in the way we do it, uh, that I think we can improve upon. So it'll get more complicated as we go forward, but the way we do it right now, as to say that there is one owner of a community and they are the one who gives the invite link, which is an onion address out to everybody.

And they must be online when someone accepts that invitation or uses that invite link, because it's just an onion address. And they're providing, they're hosting that on the end address on their device, on their one device that they've used to start the community. And what happens when someone joins is they, um, they connect to that device and send a certificate signing request that says who they are and, you know, and they're, they're, uh, they're canned from either public information.

Um, and then they get back a signed certificate from the owner that says, okay, cool. You're who, you know, this is a certificate that you can show to other people in the community that says you're a member of this community. And that says, uh, w what I have said, you can stay, you're famous. And, and we have one single owner and we use standard public key infrastructure.

You know, this is a, this is a problem. That's very standard. You know, it's how, sort of, how. The web works, uh, kind of, um, with SSL certificates and stuff. Um, you have two certificate authorities and intermediate CA's and, uh, and then, you know, the signed certificates that people use to, to, um, determine identity or assert identity, um, you have it in corporate networks.

So we're using standard PKI library, um, that, and an approach that gives us that now that's not a global identity, that's only relative to the community that you're in and the weaknesses that potentially the owner of the community is, is the, is the ruler in this case. And could, um, give sign a certificate for themselves that says that they're you.

Um, and so on top of that, we have to build in some protections that, um, well, so that we have to, we have to trust the community owner to some degree and the threat model of. Uh, can only protect against the malicious community owner to some degree, they can't do it maybe perfectly in the case of protecting against impersonation, but we can, um, sink the set of certificates, granted the same way that we sync all the messages.

And so, as soon as you connect to some other peers, you'll start to get, um, a list of all of the people in the community and what their certificates are, what their key information is. And then it definitely, once you start communicating with them, you'll have that. Um, and so really it's, it's a bit like single with, um, you know, trust them first use where you what's better than trust them for CS.

But once you are, at least once you were commuting communicating with somebody, abolitionists administrator can no longer impersonate them because you already have their key information. So anyway, that's, that's sort of, that's how, that's the basic outline of how we're doing it. And then, uh, Then in terms of how we do recovery.

Um, we haven't built that part yet with, like I said, the app has no features in terms of how we imagined doing it. Our first pass answers to do it the way that crypto wallets do it and give you a, give you a pass phrase you can write down for, for the administrator at least so that they can, um, they have like some rude CA key that they can keep offline and that they can use to re constitute the community.

And then for individuals, maybe we do the same thing and let you reconstitute your account that way. Um, or maybe we say. You know, you just asked for another invitation from the owner and, you know, if you lose your phone, you, you, you know, ask your CTO or your, um, you know, community monitor or something like that to let you back in.

Um, and yeah, and that actually gets a bit account recovery, potentially. It can be smoother in the context of a community that is bounded and where there is an owner, because the owner can use their discretion to let someone back in, or maybe restore access to someone's name, at least maybe not their messages.

Um, or maybe you just come in with a new name. Uh, so that's pretty much how we're doing it. And yeah, I'm curious what you think of that approach. There's definitely, you know, ways we could refine it, but that's kind of like the baseline, you know, mostly even fermentation and, um, you know, you can make it better by introducing maybe some centralization.

Maybe you can make it better by introducing some second factor. Then maybe there's some other UX things you can do to make it simpler. But 

[00:30:13] Kyle Rankin: no, I, I think that makes sense. And also it sort of maps to, because I think a lot of people, when they think about a peer-to-peer system, they're not in one, I think a lot of people are out of practice thinking about how peer to peer systems compare, contrast with like a centralized system and the powers or the issues that you were talking about now are the same.

If we were talking about, say a, uh, say a matrix server or a, even a Mastodon instance where you have a moderator or moderators or someone who owns that, who has those powers as well, you know, like they have the vacant, they have the ability to change someone's identity to, to impersonate that identity. Um, In the same, like for example, um, and you also sort of answered a question I was gonna follow up with about moderation, which it makes sense that whoever creates the room now basically is sort of like room moderator.

And then, um, as, as result has quote unquote godlike powers over that room. But that would make sense because they're, they're creating that. And I imagine at some point you might be able to delegate authority or something, a lot of chat rooms do that sort of thing. Yeah. Yeah. I think that makes sense of recovery makes sense.

Like I said, like, imagine it's this, it's all of these questions, like, as I'm thinking of them, I mean, maybe it's just me because I'm thinking of them and then think of, yeah, but this is the same issue you run into running a centralized system. It's just, you're offloading that consent. Like you're just that moderator who's running that system elsewhere has the same either authority or the same, you know, the same things can happen.

[00:31:45] Holmes Wilson: Yeah. Yeah. And w you know, the funny thing is that, um, one funny thing is the relationship between this and like the sort of cryptocurrency blockchain movement or. The relationship between an app like this and the cluster of free software projects that are descendant from Bitcoin. Um, and one interesting, well, the first interesting thing is when I set out to make something like this, I thought it would be cool to build it on a cryptocurrency stock.

So I was messing around with see cash and, you know, seeing if I could do messaging on, see cash, identity, antsy cash, and there's some things that are cool about that, but it, it just, isn't a stack that's really built for this. And you, you need to, you know, we needed something that was, that was closer in order to just make a chat out.

That felt like it felt good. Um, but the interesting thing, so the first interesting thing is that to build a very broad class of decentralized applications, you totally don't need cryptocurrency or blockchain. Like you, you can address a lot of different types of, of the needs of different types of applications without that, uh, There are some things that are hard to do without it.

And, um, and that are N where, uh, blockchain life system can be really cool and help address some of these things. So one cool thing that blockchain based systems can do that you can't do otherwise it's like, uh, or that we don't know how yet to do otherwise is, um, unique names in a decentralized network that herself they're self-certified are controlled by, by end users.

So like, if you, so we can have these like separate communities where I'm homes and like community homes and another community, but if we wanted to make it, so I have a username the way I do, I get hub that is global and works across all of my communities and where someone can just like type in homes, Worcester, anatomy, to any community and know that because they typed in that name correctly, they added the right person.

Um, and, and it's, and their connection with me is secure. You can't do that in a decentralized way, without something like. But if you have a blockchain, you can, um, and that's kind of cool. And another flight place where that comes up is message ordering. Um, it's you can kind of create a sort of loose relative order to messages, but you can never be totally sure who sent a message first in all cases without, um, that central authority or something like a blockchain.

Um, and so in, yeah, that's a funny place where you can get, you can, um, peer to peer apps or fall a little short of like what you can do with a centralized app in terms of the security properties you can provide, but where you can get closer to the. Security properties by doing something with, with, um, blockchain tech, if you want it to, although then it comes along with all the baggage of that.

Um, and you know, you, you just have to bring some money to the party and that's annoying. Um, you know, what works like, like most apps in normal reality, don't make you pay money to have a username. So, um, so yeah, there's that? And I think also, um, yeah, ultimately though there is this question of like, you do need somebody to have trust and so you have to choose what that is.

And the, if the root of trust is the community creator, um, that has certain benefits and drawbacks. If the root of trust is a blockchain that has certain benefits and drawbacks. And if the root of trust is a federated server or a centralized server that has benefits and drawbacks. Um, but I, I do think that the peer to peer.

The peer-to-peer blockchain. This version of this is, is actually pretty good. Um, for, for like situations where you have a team collaborating. 

[00:35:49] Kyle Rankin: Well, and another thing that blockchain brings with it is a sense of permanence right in, and that was something else I sort of wanted to ask you about is one value.

At least in some, uh, chat messaging systems is through morality or at least that's a feature that some tout, right. And so I was in, and then there's a couple of interesting use cases, especially when you're either combining anonymity or, or groups, uh, for instance, a recent discussion that ended up being on a social on social media, about a way of an implementation of when the signal does this.

But essentially I have a group. It has, it has. Conversations. I invite a new member to the group. Does that new members see past conversations or not? So I guess that's two questions. One is about general purpose, ephemerality and messages. And either I imagine some people want it to be permanent. Other people want them to disappear.

And then second that, that specific use case of having new people join the community. 

[00:36:46] Holmes Wilson: Yeah. Well, so I think there's a, there's a general thing, which is that, um, I think there's one thing here that we, that I know that I know in my bones and in my personal lived experience and that I know I have to do, which is that, that, um, there must be an option for ephemerality and like, you can not choose a stock for this.

That is not a femoral for, for messages and still purport to offer privacy. Like, uh, and this is part of the reason why I stopped missing artsy cash, just because everything there was. Permanent Pell, possibly encrypted forever. But, but everything you wrote was in this global shared state, and that didn't make any sense, um, for messaging, you, you must give people the, in this day and age with the threats that exist and what the current state of endpoint security, you must give people an option to delete their stuff, because that's the only way in practice that, that high-risk users can, can be private and even then it's hard.

Um, but, uh, but yeah, you have to give people a way to delete messages. And I think also if you are building a tool for, um, first sensitive uses, I think it's good if you make that the default and, and you, the stand, the best practice in, um, in our, in organizations that are subject to some kind of, or groups that are subject to some kind of threat of institutional doxing, like, you know, the threat where somebody hacks your email server and spills out all your internal communications selectively, perhaps onto the internet in order to make you look.

That's anyone subject to that kind of threat, uh, needs. And even if you don't know that you are, but you should probably do it anyway, you need to have some type of policy where Stephanie gets saved intentionally. And the default is that things get deleted after a certain amount of time. Um, and that's, that's something that we did internally at the, for the future.

Um, we were very, very, very glad that we did it when, um, when a, an attacker that citizen lab, um, called the citizens citizen lab identified as bell trucks, InfoSec, or something like that. Uh, tried to hack us with a fairly sophisticated phishing attempt in order to get access to our internal comms in order to give them to private investigators who were working for, um, probably funded sort of two steps removed by the lobbyists for the U S telecom industry.

This sounds kind of crazy, but, um, There's been a decent amount of, we were subject to aggressive phishing attempt and a sophisticated phishing attempt in the, at the height and one of our net neutrality campaigns. And in parallel to that, there has been a lot of reporting both about who did the, what service provider did that attack, what their business model was and what types of clients they worked for.

And also in parallel to that, there's been reporting on, um, dirty tricks campaigns by telecom companies during that fight, that included things like, um, buying large numbers of stolen identities and submitting them to the FCC as if they were valid comments, uh, posting that neutrality. There is this like, so there's constellation of, um, work that was happening, that it was very, very, um, dark side that ended up getting aimed at us.

And when that happened. And when we started to become, when we became aware that someone was trying to get access to our internal communications, we were really, really glad that we had a document retention policy that deleted all of our email after a certain number of months, and that wiped out our stock after a set number of months, everybody should be doing that.

And so I'm definitely gonna make a tool that does that. And we've put a lot of thought into how to do that. Um, and we don't have the exact design yet. Um, but that's, it's definitely one of the first features we'll implement is some type of time's deletion probably time deletion set by the community owner and globally, and then potentially like, um, with the ability to pin messages for posterity, if you need to do that and with the ability to shorten the deletion period, if you want to do that.

Um, so that's definitely something we're going to do. Um, and. Then then the next part of it is, so that's the, that's the piece that I know. And then there's another piece that I have no idea about, because it completely depends on what someone threat model is and what the use case is and what people want, what actual users that you have in that actual moment want, because there's a million ways you can do this and the sort of controversy or conversation that you alluded to about, you know, how signal does it is just a great example.

There's like, um, so there are questions. Yeah. Like, like, do you. Is your conduit is the conversation you want to invite someone into so that they can scroll back and see where the conversation has been up until that point and get context. Or do you want, when you invite someone in, do you want them to be totally unaware of the conversation that's been happening up to that point, to the point where like people could have been talking about them in the channel right up to the point that they joined, um, and know that they will not be able to see any of those things.

Um, that that's one question right now, we, we work like slack does where you can see conversations that have happened before you join it, because you're in a team you're welcomed to the team and you want to be able to kind of like follow it, um, where you wanna be able to like situate yourself in the team's conversations and catch up.

And that's an important thing. If users say that they want something different, we can, we can make it so that you, um, You know, so that the encryption is scratching or something, and you don't get access to, uh, conversations that happened before you arrived, but we'll, we'll wait and see on that. Um, and then in terms of how you do time deletion, um, there's funny questions there.

Like, so signal actually stigma does it in a way that I think most people, most people would be surprised to know how single does it. I think because the intuition you have is like, okay, I sent a message and the channel is set to just for messages to disappear in a week. And so they're going to disappear in a week and a week goes by, and I know that that's, that thing has been deleted and that's not actually how signal does it, um, so signal, first of all, the way it does multiple device support is you sent.

The message will get sent almost as if it was being sent to different users, each of a user's devices. And then there's a message queue for that device. And then the message will sit in that message queue until it gets delivered to that device. And then if the timestamp is such that the message is supposed to expire that device itself will delete it, but the devices themselves were in charge of deletion.

So when you send a message that has a disappearing time of a week in signal, uh, and someone in your community, you know, one of the people in the group has, um, one of the recipients has, you know, signaled desktop, but they haven't opened it in a year. That message is just going to sit in the queue on signal servers for that person's signal desktop instance for a long time, I think maybe forever.

And also this is basically. The other funny thing about this, this is based on me kind of weeding through the forums, the signal forums with a friend who was concerned about this. And I was trying to figure out what signal was doing it even just like communicating this to the user has never been worth.

It has always been complicated enough and not even really worth it enough for a signal, um, to really tackle. So like, uh, you, you have to kind of get in the weeds just to know how they're doing it. And then of course they could change it at any point. Um, and I'm sure they're refining it all the time. So, so that's an interesting question.

And another interesting question is like, does the timer, does deletion timer start when the message is sent and created? Cause that kind of seems like it's how it should work, but then when you think about it, if the deletion time is a minute. You wouldn't really be able to ever have an effective conversation that way, because you relying on someone being able to read all your messages to the minute of you sending them.

Um, so actually the way signal does it is the timer starts when the person reads it. I think when the person first like sees it, um, but then that has the unexpected result that you, you have messages sitting around on devices and servers for way longer than the expiration time, which isn't desirable in some time models.

Um, yeah. And then, you know, and then there's the other question which applies to signal at us and everything, which is how do you know that somebody deleted it? You know, of course a user can screenshot their app and keep everything squirreled away forever. They can, or user can have a cloud backup service that they're using.

That's, uh, always generating a new, you know, a new backup every, every so often. And it's helpfully sending a diff of everything to, you know, to iCloud or to back plays or something like that. Um, so you never really know, but, um, but, uh, I think. One of the things that I'm interested in is how we can make visible to the user or at least to an administrator, uh, when all of the clients in a group of have dutifully deleted their expiring messages and when they have not, or when they're not known to have, or, and of course you wouldn't even, someone could be lying to you because they could be, they could have screen capped it.

But like we, uh, even just in assertion, that's, you know where someone's saying, I have deleted this message, and you can assume that if they're not malicious and lying about it, that, uh, that the message has gone and where you can make, you know, have some idea of, of what type of, um, stuff is sticking around forever without you wanting it to that, that would be that I'm really interested in that in ways that.

And not a deletion system can be kind of giving you, uh, giving you a status report on how successfully or how many clients in which clients have deleted messages. And then you could potentially kick someone out who hadn't, um, who, who, whose client, you could kick out a person or a device that hadn't been seen online in a long time and, um, removed their access.

[00:46:54] Kyle Rankin: Yeah, that's sort of led to the follow-up. I was wondering, is it this sort of, there's a notion in peer to peer where there's social in, anything about who trusts and who, you know, how much trust. In, in traditional models, how much trust the client gets versus several, like you mentioned, in the case of signal and issue is we, you ask for a policy and then the signal client decides whether it's going to, when it's going to delete and that sort of thing.

And I'm wondering in peer to peer, there's some sort of, I guess, traditionally there's a sense that all the clients have more trust than they might traditionally have in, in sort of a centralized system, as a centralized system, often also centralizes trust where they trust themselves, but kind of don't trust the clients very much.

And I was wondering, um, in, in your model, like how much trust does say the, the creator of a room, or maybe, maybe this is plants in the future, but, um, how much trust do individual members do they share almost equivalent levels of trust or is it more, is there more trust in the originator of a room? Um, and how you've kind of approached that, 

[00:48:00] Holmes Wilson: um, I explained how the identity system works and there were, we're really leaning on the originator of the room, um, or the people they delegate, but, and then for naming in particular for the granting of a username of like a human readable username, that's unique too, I think is familiar, both familiar and important, I think to, um, to peer, to peer, peer, to peer apps, to at least attempt.

Um, although there's some discussion about that, maybe it's not, but I think it is for that. You need to lean really heavily on one person because otherwise there's no, well, there's no way that, that sort of sovereign to the group that you can get uniqueness without having something like a consensus algorithm or in a blockchain or, um, or a central single authority.

So in that case of naming, we really trust the admin, but then we. We as users learn about names, they remember them. And so they trust the admin wants. Um, and after that they, they sort of trust, uh, signatures in public keys. All right. 

And so, so then in terms of message privacy, um, right now we, we only have messages that are visible to the whole group. So we rely totally on tour and onion services to encrypt messages, but at some point we'll IDM some private channels. And in that case, you'll be able to send a message that is sinked to everybody, but encrypted just to the recipients.

And in that case, you'll do a key exchange with the other parties to that conversation. And so it's provided that you have, that you're not being met in the middle somehow that you will be able to. Yeah. And there's layers of protection against that. You would not be trusting the, in men with the privacy review messages, for example, you'd all be kind of on an equal playing field for that.

And then there's some stuff around message ordering where the CRDC has nice properties of, um, kind of tangling all the messages together into it or not. All of them chain tangling all the messages in a channel at least potentially across the whole community. But right now, just in a single channel into a sort of graph where each message is linked to the hash of the previous message.

And, um, and so, you know, if someone wants to completely. Mass with the message ordering there's limits on how they could do that. And everybody's kind of on equal footing. Indian men wouldn't have really special powers to mess with the message ordering. Um, and, um, and there, there are limits to that where there's some violations of message ordering that you can't guarantee it, you can't protect against and that system, but there are some that you can.

Um, and so, yeah, generally, um, we, I mean, I think, I think the way to purse this stuff is to start with the threat model and the, you know, our, our threat model is essentially that, um, you know, users should be able to, or the, the, the properties we want are that like a user can communicate privately with other users and that, um, a malicious user can undermine that.

And then. And malicious admin is limited in how they can undermine it as much as we can. 

[00:51:47] Doc Searls: So, uh, I'm going to ask you the question about how you grow. Um, there's, uh, have worked with a lot of startups that have also followed a lot of, uh, development program, uh, development projects like this one over many years and early on.

Um, I are, we, there was the group I was working with notice that there are three stages, basically for every company, for every development group, whatever those are new, hot and big. If they succeed, they go through these stages and they're like state changes there. What you're doing when you're new is very different than what you do when you're hot and you're dealing with that.

And then very different than, than when you're big and you've reached scale. Um, In fact, I think I talked to, um, Evan Williams about this, uh, at, when he was still at Twitter, because Twitter just started out as a side thing that they were doing for, with a little company they had called or, uh, Odo. And it was Twitter.

It was just a way that they message each other. Basically it is just short message thing and that it turned into something hot and then it turned out when they had to fail whale all the time. And then it turned to something big that Elon Musk just maybe bought. Right. So that's kind of an extreme case, but I think what you've got there, um, if, if it does succeed at scale, um, you've got, you've been talking.

I mean, I really liked the kind of heuristics you're going through that you're learning, you know, you're thinking out loud and I'm sure with your development team, you're going over this stuff all the time and you're using your tool for your own internal purposes. Right. So you're, so there's a learning that goes on there.

Um, So I'm wondering how you, how you thought about that. You know, does, does tour scale, did, will you have to move past tour? How do you change tour? If, when say if you succeed, the primary use of tour may be quiet and not, I'm just hiding, you know, where my browsing, you know, it's a community thing and lots of people are using it.

What how's that go? 

[00:53:49] Holmes Wilson: Yeah. Um, so the main, your main question is less about like, how do we grow and more about like, how do we, how do we, if we do grow, how do we ride that? 

[00:54:00] Doc Searls: Um, and it's, it's actually, you know, you've got, you've got something that's really potentially huge and, and you can. You know, naturally you tend one would tend to fantasize about this, but, and that's part of how we, how we anticipate things, you know, I mean, I've got something I've been working on for 10 years.

It's still new, you know, it's never, it's never gone to a hotter big, I hope it does eventually. It probably won't. I don't know, but, um, but I, I imagine how that may go, but that's just me, you know? So I'm just wondering how, you know, your, how your fantasies inform your work, I guess, is a way of looking at it and how you look for problems downstream.

That might be wow. That man may be insurmountable if we stay on this particular approach. 

[00:54:46] Holmes Wilson: Yeah. Um, yeah. Well, I'll start with tar. You mentioned that, um, well maybe I'll start with the fantasy. I think the first layer of fantasy is that, or the fantasy for me is symbol. That's one. It is. That, that we make this, we reduce clunk enough, um, that people can have fun using this every day that the general messaging app space is like moving forward.

Slow enough for us to catch up with like some core set of features that, that are good enough for, for many uses. Um, and that, at some point we start to have that cycle of influxes that signal has had do, do people do to discontent with existing platforms or worries about privacy or autonomy, and that's, that's sort of the baseline, the baseline fantasy.

And then we started, we started to grow and we start to become the thing people use. Um, the next one is, um, that we're able to find some way we're able to find something that people are willing to pay for. Um, So that we can split the cost of making this thing awesome with some of our users, um, and that we can do that in a way that's consistent with software freedom.

Um, we might, that might mean offering some centralized piece or some features that like, you know, additional emojis or something like that that are trivial to add, or that are in the open source version of the app and would be trivial to, for anyone to add. But that we just happened to not put in the official builds and where people are happy to pay us for the, for the laws or for the vibes to, um, to have access to those features or some combination of those two things, you know, and, and an example of a centralized thing will probably provide, is it need to provide is a push notification service for us.

Um, because if you want this to be efficient, if you want your team shout out to have push notifications on iPhones, you can't do that with peer-to-peer apps. Unfortunately, unless we, you know, let's, we're outside the apple headquarters with pitchforks and torches and managed to make serious changes there.

Um, so then the next level of fantasy is that we is that this stack is so good for, um, for built, for enabling the building of team collaboration apps that you can actually build an app like a Kanban board or a document editing, a collaborative document, editing tool, like Google docs or a password sharing app, like one password for teams.

It's easier to build those things inside something like quiet, honest, either in quiet or on a stack, like quiet than it is to build them using a traditional cloud stack and where people, this becomes. The there become the, it becomes a new movement of free software developers working on, um, on rebuilding the apps that we use along peer-to-peer private, autonomous lines, similar to how, you know, similar to the way the guru movement got started or the way Linux got started or the way, you know, no maps got built by community volunteers that said, okay, here's the moonshot.

We know where we're going. We're trying to rebuild the desktop to be, but, but to be usable and free more that I think the, the maybe second biggest fantasy I have is that is that I'm able to spark and quiet as able to spark a movement, a movement, a new phase of the free software movement, where, um, where people are singing a little bit, or there's a community of people focused on this thing that had been shot up rebuild all of the apps that we use to be.

To work just as good as they do in the cloud and, but run on our own devices without dependency on central infrastructure, at least for any, for any app where we know how to do that. And then the highest level of fantasy is to, is to break through some of the hard technical and research problems, um, that make, that would make it difficult or impossible to do that for a broad class of apps, for things like Facebook and Twitter or YouTube, or, um, their, their, their apps right now that, that the existing quiet stacker is totally inadequate for, uh, for building, um, or replacing or substituting.

And the fantasy is that we can punch through some of those, those tough research questions and find ways to make, um, apps that move very large amounts of data or that, um, or that, you know, move data in very complex ways and then open network things that would be hard to do. With our SAC now, but we, that we figure out how to do some of that stuff and are, um, are able to, you know, build features someday.

Like, you know, the feature slack has where different communities can message between each other, not just within each other. Um, that's something it'd be hard to do with our stack now, but we might feel it, figure that out someday. And once you figure that out, you can build Twitter, you can build Facebook, you can help, um, you know, Google calendar, G suite, everything.

You can sort of do everything once you have that. Um, and then, yeah, in terms of barriers to that, um, I think the biggest barriers are, um, you know, whether we can ride this, whether we can with the resources we have access to at any given point, make things good enough. Um, with this sort of, for some period of the project decentralization, it's going to be a ball and chain.

And for some period it could be winded. Um, but right now it's a ball and chain. Like it would've taken us wait less time to build, uh, you know, basic slack clone that does absolutely nothing, um, with the centralized stack than it did to do this in a peer to peer way. So there a lot of push through the pushing against the stock and against the constraints of the stock right now.

And I think the biggest question is for our survival is can we, can we like stand that? Can we survive with that and still make something that's useful enough to get traction and start growing. And then, then yeah, once, once we get through that end and it does work really well and you know, people just starting new communities and jumping ship from.

From existing centralized platforms or for a federated platforms perhaps into this, and that's going fine because it's a peer to peer app and it works no matter, you know, the cool thing is this scales no matter, uh, for, from our point of view, assuming tour continues to exist in and work this skills, um, quite a lot without us really having to worry about it.

Because as long as, you know, if we make a community of a hundred or a thousand people work, we can have as many of those communities as we need to. Um, cause they don't, they don't really create more of a burden for us or for the network. They're all isolated. So that's really cool. And then, yeah, the question is there's a question around tour.

Um, I think, you know, the. Um, and in, in many networks, uh, require anonymity sets, you, you can't have an enemy, an anonymity tool that only one person uses because, you know, if only one person uses the anonymity tool, they're not anonymous, no matter how fancy and amazing that tool is. Um, and, and that, if you think about what that means, that means that the more people are using tour, the more anonymous it is and the more anonymous it becomes potentially.

And, um, and so, uh, so a large influx of users is beneficial to tour. And I think from a tourist perspective would be a very good problem to have then, but there is some physical or financial perhaps limit to that. I don't think there's really a technical limit because I think probably everything Torah does is, you know, they go to the login scalable or whatever.

I think it's, it's just that the. You know, with their current system for attracting volunteer note operators be able to sustain how much growth could that sustain in this like good problem to have scenario where everybody, all of a sudden wants to use tour to build to a lapse. Um, I mean, that would be amazing from, for Tory institutionally.

I think that'd be amazing. And then the question is really can tour ride that ride, that wave of going from going from new to hot to big. Um, and certainly if we are making revenue from people using our thing, we would want to help tour with that. Um, um, you know, at a personal level, I'm a supporter of tour and we'll continue to be like a donors tour.

Um, but, uh, but yeah, I think, I think there is maybe some scenario to where we could, um, well there are. There are anonymity networks that seek to address that problem of scalability by baking, by using crypto to bacon, um, an incentive structure for node operators. So tore could do that potentially someday if they started to run into this problem.

Um, I don't think they have any plans to right now because I think their sort of social, um, model of sustainability and growth is working pretty good. Like people like torso there's community, they have a community that's doing this, so they don't need to. I mean, the incentive structure is you get to be awesome by running a tour node and you get some privacy benefits, I think about running your unrelated, um, or exit node, maybe.

So there's that. But yeah. And then there's the possibility that we could decide. We could ended up in a situation where a tour is a ceiling to our growth and where we have to drop it. And what that would look like is we will. Maybe need to change our threat model. We would need to change the, we need to accept some security properties that are different than tours.

Like, you know, if you, if you're okay with leaking your IP address to the other people in your community, um, then you don't have to use tour, but you do need something like a tracker to, if you don't use tour, you need a tracker to find when other peers are online and you need a central service or some type of service to help with, um, Nat traversal.

And so there's like another, there's another way you could have made this something like quiet without tour, um, that uses other methods for tackling peer discovery and Nat traversal. And we could start, we can move to something like that, or we can make our own, you know, incentivized, scalable, like, um, not skip the scalable in the sense of like, It contains the mechanism that attracts more infrastructure to it as it grows.

And as it needs to, um, we could make our, uh, make a system like that. Those, those would be the two, the two options. And I think, I think actually the, the one of, you know, build quiet with a tracker and a sun turn server, like the kinds of, um, help peers connect services that, that we're using right now. And we're using zoom or that, you know, every, every video calling up ever always has to use, because some percentage, I think it's like 18% of users in most real world scenarios are not able to connect to each other peer to peer.

You need some central service to actually like relay all of the data, not just help them bust through the firewall, but actually relay all the data. Um, you would, you could build something like quiet using a tracker and, uh, and one of these things. You can action help her services. And that would be your dependency on centralization, but that's not such a bad sacrifice, but that was a, that was a long and convoluted answer.

I hope it was clear. Um, yeah, those are the different options. 

[01:07:19] Katherine Druckman: Well, cool. Um, yeah, we've we, it's probably about time to wrap up. I know this has been a really good one because I've been "Quiet". Um, while I've enjoyed listening to, sorry, I couldn't help myself my dramatic pause. Um, but I did have a couple of wrap up questions and, and one of them, are you, are you looking for contributors or do you have any specific message for our listeners?

And then the second part of my wrap-up question is I just wondered if we could talk just a tiny bit about karaoke, because I feel like I would be remiss in not bringing that up, that little, uh, bio tidbit there. 

[01:07:58] Holmes Wilson: Yeah. Um, so, okay. Well the karaoke question is that I put in my bio that I love karaoke. Um, I have the word karaoke tattooed on my arm.

It's the only tattoo I have. Um, and I, one of my contributions to culture, uh, has been, or was making a. Uh, PR a live performance out of karaoke using Ableton live as, um, the T to make us. Karaoke mashup mega mix that is sung by the audience. And then I will perform that with a bunch of wireless mics that I'll start singing on, but then I'll give to everybody else and the Mike's have auto tune and effects and things like that.

And everybody's sings like ridiculous, you know, schlock from the nineties together, uh, potentially over music that does not belong to the song that they're singing and blast another song. And, um, I don't know. I, I love I called that performance karaoke crime, and there's a funny quote about it. Once I did a performance, this is really funny.

Once I did a performance that got written up by the New York times because of the band that I was opening for and they called me a boisterous one, man, Spitfire that inspired enthusiasm and sometimes revulsion. And that was like, yes, that is 

[01:09:11] Katherine Druckman: winning right there. 

[01:09:13] Holmes Wilson: Especially here to karaoke. That is, that is like the highest point you can get.

I think, as a karaoke practitioner, Yeah, but, um, but so that's me and karaoke. And then in terms of how people can contribute, um, the thing I need more than anything else, more than anything else in the world right now are, um, people who are in a position, people who, um, understand InfoSec and are in a position to recommend or recommend against, um, tools, uh, to, to friends or, um, or some organizations or community or some community like anyone who understands, uh, privacy and security and is often in a position of recommending or helping people find tools that fit their needs.

I, I need people like that to talk to, um, to tell me what, um, what I'm doing wrong, what I should be thinking about and to like work with, to refine the product, to get to the point where they can recommend. Um, as, as a solution for some, some users and some threat models, that's, that's the most, maybe the most important thing.

And then one notch down from that is I need people who are willing for some reason to try this out and in a regular way to actually try to use this as a communication tool regularly, like we are doing internally. Um, even though it has no features yet other we'll have them quickly and we'll add the ones.

If you do this, we will add the ones you need before we do anything else. Um, you will have, you will be a part of a small number of people who have total control over our priorities. And, um, and those are the two things I need InfoSec experts who can tell me what I'm doing right. And wrong and refine with, with me as, as we go.

And, um, people who were really who'd be down to use this for some reason. And, uh, Yeah. And then as far as contribution open-source contributions go like that would be amazing, but I could, we're currently set up as a team that's working full time in a more traditional traditional way. Um, and we, and so you, haven't just sort of, uh, just to set an X, just to be fair and setting expectation.

You might have to work with us on that to create a space and a role for you that that is that's comfortable and satisfying. And, but I'm willing to do that. It'd be amazing, um, to have to have contributions. I think at some point when we're a little farther along, it will be, become more open to contributions.

And one thing I'm really excited about is because our project does not have a central service dependency. We're not going to be like signaling. You know, there's just one signal. Um, this thing is built to be radically forcable and that's not to say that I want, you know, a million folks to exist or everything to be a fork, but, um, it would be best, you know, if people contribute to our project, but you will be able to contribute to our project, knowing that if we do something someday that you don't like, you can fork it and you don't have to spin up a million AWS instances to support your users.

So you will just be able to fork it and have a thing that you think is great. Um, I don't know if that helps, but yeah. 

[01:12:36] Katherine Druckman: Yep. It does. Well, that's great. Maybe, maybe we can, uh, create a little Reality 2.0 community with it. We'll see. We'll see if we're nerdy enough to figure it out. Yeah. 

[01:12:46] Holmes Wilson: Yeah. Interesting people I'd be really interested in, in this would be a cool challenge if someone's like messaging out, that's boring, but I really want, you know, a password sharing app or a Kanban board is private or, uh, you know, some other type of team collaboration tool.

It's private. I would be on, I would be into, I'd be really excited about talking with you about how to do that and help you, you know, use what pieces of our stack are useful to you. Or maybe even talk through how we could expose some of the stack or expose some or a stack to an out by a third party developers that you could like build the app in quiet.

And, um, you sort of use quiet as the backend for, uh, another type of application that's sharing state between members of a community. Then you wouldn't have to worry about like things like identity and the thinking and authentic cation or the peer to peer networking we would have without, but you could build a cool, like, you know, react app for team collaboration.

That that was like super private. That's also something I'm interested in. If, if you're, if you're into that, um, I want 

[01:13:49] Doc Searls: to say, I, I definitely want to do something in Bloomington, Indiana. We have several communities. We want to start there. We want to do something small experimental. It'd be great if we.

User tool when, you know, if you're ready for it. And we have a developer there, but he's a full stack guy and he's working with us. He's got 10 hours a week. He wants to give us, um, I think it would be, we should have a conversation about it. 

[01:14:13] Holmes Wilson: Yeah, we would love to, and we're, we're ready. We're ready. Now our mobile mobile apps aren't ready.

So for use case requires mobile apps. We aren't ready for you yet, but we would be in, I think three or four months. Um, we already have proof of concepts on mobile that work. We just sort of need to commit to finishing that cycle of work. Um, and yeah, and we can add features fairly rapidly now I think so if there's like small sort of things you need like reactions or images or people have been giving us feedback like that, and we're prioritizing some of that stuff just to get the ball rolling with people and create something that's minimally satisfying.

Um, so I think we're ready. Oh, yeah. Good question. Um, so right now it's, uh, right now we support windows Linux, and with Linux, we, we are at least our app images, so we've spread Linux, windows, and, um, and Mac, and we have proofs of concept for Android and iOS. Another interesting question we didn't get to talk about is the web platform and, uh, and how to make grabs on the web platform, but maybe that's for another.

Yeah, 

[01:15:25] Katherine Druckman: I, we, we do, we say this a lot, but this one we definitely need to follow up because, you know, we would really like to talk about this again. I think when, when things move even further along, so yeah, we should definitely regroup then.

Yeah. Thank you so much. Thank you both to both of you for, um, for joining us because it meant that I got to listen and enjoy. It was great. Not that I don't enjoy also asking questions, but it was 

[01:15:54] Holmes Wilson: awesome. I'm super grateful to all of you, and I'm really grateful to Kyle for all the questions that I think structured conversation, essentially in a really great way.

Um, and it was cool. 

[01:16:07] Kyle Rankin: I'm grateful to find out about it. I might become a alpha user myself here because I have some of the use cases you're 

[01:16:12] Holmes Wilson: interested in. So, oh, I'm so excited. You 

[01:16:17] Doc Searls: guys, you guys should take this and run with it. I think it'd be a lot of fun. Love to see where that goes. 

[01:16:24] Katherine Druckman: Yeah, me too. So what we're here for bringing the cool people together.

[01:16:30] Kyle Rankin: Awesome. 

[01:16:32] Doc Searls: I wanted to get you here Holmes. I think there's this a lot of promise. 

[01:16:38] Katherine Druckman: And thank you everyone who has listened through this whole thing, which I'm pretty sure is actually a sizeable number because this one's been really good. So with that, uh, we will, uh, we will talk to you next time. 

[01:16:51] Doc Searls: And in the meantime.