WEBVTT 00:00.000 --> 00:11.000 Okay, can you hear me? 00:11.000 --> 00:13.000 Okay, great. 00:13.000 --> 00:15.000 I'm Morgan. 00:15.000 --> 00:19.000 I've ever had presentation or introduction. 00:19.000 --> 00:20.000 Good morning. 00:20.000 --> 00:23.000 afternoon, whatever the hell it is. 00:23.000 --> 00:25.000 I made this mistake in the past. 00:25.000 --> 00:28.000 Let's kill this guy so we don't have that all overlay. 00:28.000 --> 00:29.000 Perfect. 00:29.000 --> 00:31.000 So, I'm Morgan. 00:31.000 --> 00:38.000 I am the developer of Gosling and Refrersh working for an organization called Blueprint for Free Speech. 00:38.000 --> 00:43.000 We are a nonprofit kind of focused on journalists and mobile protections. 00:43.000 --> 00:45.000 And I'm not doing that. 00:45.000 --> 00:51.000 I am also the browser team late at the Tor project where we are eye over the team of eight engineers developing 00:51.000 --> 00:55.000 Tor browser, Tor browser for Android and mobile browser. 00:55.000 --> 00:58.000 But today, I'm here talking about Gosling. 00:58.000 --> 01:01.000 So, what is Gosling and what does it do? 01:01.000 --> 01:06.000 Gosling is a rust library for developing peer-to-peer applications that has all of these 01:06.000 --> 01:07.000 lovely properties. 01:07.000 --> 01:12.000 And then encryption for secrecy, anonymity, whole-punching, financial circumvention, client 01:12.000 --> 01:17.000 authentication, metadata resistance, and optional applications specific authorization extension. 01:17.000 --> 01:20.000 So, I'm going to go over all that stuff. 01:20.000 --> 01:23.000 So, it's built on Tor and unanswered services. 01:23.000 --> 01:26.000 Jeremy talked about unanswered services a little bit beforehand. 01:26.000 --> 01:28.000 This is a kind of a short talk. 01:28.000 --> 01:32.000 So, I'm not going to go into the details of how Tor and unanswered services were 01:32.000 --> 01:33.000 specifically. 01:33.000 --> 01:35.000 I kind of assume this crowd probably knows it already. 01:35.000 --> 01:40.000 But the main high-level idea that we need to understand is that the Tor network allows 01:40.000 --> 01:43.000 you to connect it up to endpoints anonymously. 01:43.000 --> 01:49.000 And then unanswered services are kind of the reverse of that where people can host services anonymously. 01:50.000 --> 01:53.000 And they're only accessible for the Tor network. 01:53.000 --> 01:55.000 So, how does Gosling work? 01:55.000 --> 02:01.000 So, Gosling is a library is kind of like live P2P in the sense that you use it to build peer-to-peer applications. 02:01.000 --> 02:06.000 Every user has an ID, an unanswered service ID, which turned it over earlier. 02:06.000 --> 02:10.000 This ID serves two purposes within Gosling. 02:10.000 --> 02:11.000 So, one, it's a destination. 02:11.000 --> 02:16.000 And then point, it's an unanswered service that you connect to and you host. 02:16.000 --> 02:21.000 And finally, it's also an identifier that's used for authenticating clients that connect to 02:21.000 --> 02:22.000 an unanswered service. 02:22.000 --> 02:27.000 So, in a Gosling peer-to-peer network application, every peer-to-peer hosted an unanswered service. 02:27.000 --> 02:31.000 And if you want to connect the peers, you connect it to their unanswered service. 02:31.000 --> 02:38.000 So, we get an encryption with forward secrecy by default because we're going through Tor. 02:38.000 --> 02:42.000 You get anonymity for free because again, you're going through Tor. 02:42.000 --> 02:48.000 There is no way to leak your actual IP address by using Gosling. 02:48.000 --> 02:53.000 Presuming you don't do something silly, like as part of the optional application extension. 02:53.000 --> 02:55.000 Say, hello, my IP addresses. 02:55.000 --> 02:56.000 One, I just hear a point, whatever. 02:56.000 --> 02:59.000 If you don't do that, then you can't leak your IP address. 02:59.000 --> 03:00.000 But that's on you. 03:00.000 --> 03:04.000 There's no central register, no signups, no need to associate. 03:04.000 --> 03:10.000 You're earning a service ID or your peer ID or you want to call it with actual identifying information. 03:10.000 --> 03:15.000 Again, because you're using Tor, you get a whole bunching for free. 03:15.000 --> 03:20.000 You only need to make an outbound connection from your computer to the Tor network. 03:20.000 --> 03:24.000 And you get, since it's your convention, again, with Tor. 03:24.000 --> 03:27.000 So, there's, again, no authority or gatekeeping. 03:27.000 --> 03:29.000 Nothing stops anybody from hosting an unanswered service. 03:29.000 --> 03:34.000 If you can connect to the Tor network, you can create very easily a new unanswered society. 03:34.000 --> 03:38.000 If you want to get rid of that and make start over, you can do that. 03:38.000 --> 03:43.000 It is very straightforward, and there's no overhead and really doing this. 03:43.000 --> 03:48.000 So, you might be thinking to yourself, okay, that's really cool. 03:48.000 --> 03:51.000 So, you host unanswered services on Tor. 03:51.000 --> 03:53.000 Good job. 03:53.000 --> 03:56.000 This is where we actually get to value out of this. 03:56.000 --> 03:57.000 Client authentication. 03:57.000 --> 04:01.000 So, in the Tor network, unanswered services are self-authenticating. 04:01.000 --> 04:05.000 If you can connect to an unanswered service, you, as a client, understand. 04:05.000 --> 04:08.000 This is actually the endpoint that I am trying to get to you. 04:08.000 --> 04:11.000 There is no possibility for a man, man, man. 04:11.000 --> 04:12.000 Excuse me. 04:12.000 --> 04:14.000 A machine in the middle of the hack. 04:14.000 --> 04:18.000 There is no possibility of somebody else having like, 04:18.000 --> 04:23.000 swap the entity or redirected the DNS request or whatever. 04:23.000 --> 04:29.000 You can, as a client, have certainly that if you connect to an unanswered service and the connection exists and it succeeds, 04:29.000 --> 04:32.000 you know you're going to the endpoint that you think you're going to. 04:33.000 --> 04:38.000 The problem is this is supposed to be an authenticated peer-to-peer system. 04:38.000 --> 04:46.000 So, how does an unanswered service verify that a client coming in is who they say they are? 04:46.000 --> 04:53.000 So, clients using Gosling basically make a claim that they are the owner of some's unanswered society. 04:53.000 --> 04:56.000 I mentioned earlier that unanswered service had these sort of two parts. 04:56.000 --> 05:00.000 So, what you connect to and also who they are an identifier, 05:00.000 --> 05:02.000 a unique identifier per client. 05:02.000 --> 05:06.000 So, an unanswered service ID is actually a public key. 05:06.000 --> 05:09.000 That's specifically it's an ED25519 public key. 05:09.000 --> 05:11.000 Again, it's certainly mentioned in the previous talk. 05:11.000 --> 05:16.000 If a user connects to your service and they claim that they are the owner of an unanswered society, 05:16.000 --> 05:21.000 what they're actually claiming is that they own the private key that was used to generate that public key. 05:21.000 --> 05:28.000 So, to verify that a Gosling client which connects to a peer connects to a peer's uninservice, 05:28.000 --> 05:33.000 we basically ask them to sign a particularly crafted message proving that, 05:33.000 --> 05:40.000 okay, you claim that you're, you know, ABC once you see that onion, prove it with photography. 05:40.000 --> 05:47.000 So, that's the sort of client verification side of connecting to a verified host. 05:47.000 --> 05:51.000 In addition, we also have optional application-specific extensions. 05:51.000 --> 05:57.000 So, a lot of this is inspired from Ricochet Refresh, which I kind of mentioned earlier, 05:57.000 --> 06:05.000 and part of that protocol involves, basically presenting a message saying, hey, you know, 06:05.000 --> 06:08.000 I'm so, and so, I would like to add you as a contact. 06:08.000 --> 06:13.000 And so, when designing Gosling, we were like, okay, but we kind of need that sort of idea, 06:13.000 --> 06:17.000 we don't want, like, hard to code it to make it only work in the asymmetric context, 06:17.000 --> 06:21.000 but also work in any kind of peer-to-peer application context. 06:21.000 --> 06:27.000 So, there's a little part piece of the protocol that allows you to send arbitrary messages along with the protocol 06:27.000 --> 06:30.000 that allow you to build these application-specific extensions. 06:30.000 --> 06:34.000 So, you can add in functionality like peer block lists, or allow lists, 06:34.000 --> 06:38.000 invite codes, proof of work, or state schemes, or whatever. 06:38.000 --> 06:41.000 And finally, you get metadata resistance. 06:41.000 --> 06:46.000 You get part of this, almost of this, just from uninservices. 06:46.000 --> 06:50.000 So, all the communication contents are end-in-accripted, 06:50.000 --> 06:52.000 and stay entirely in tour network. 06:52.000 --> 06:55.000 Clientities are not exposed at all. 06:55.000 --> 06:59.000 And there's no way to know which peers have connected to other peers, 06:59.000 --> 07:02.000 because all this sort of information is only known to the peers involved. 07:02.000 --> 07:04.000 So, it sounds great. 07:04.000 --> 07:06.000 What's the problem here? 07:07.000 --> 07:11.000 So, one problem with uninservices is that, 07:11.000 --> 07:16.000 if you know the uninservicity, or the endpoint of an uninservist, 07:16.000 --> 07:18.000 you can tell a bit's online. 07:18.000 --> 07:21.000 So, you might think to yourself, well, that's true of any kind of thing. 07:21.000 --> 07:24.000 You know, if I know CNN's URL, I can tell CNN's online, 07:24.000 --> 07:26.000 if I've internet, I just connect to it. 07:26.000 --> 07:30.000 So, the problem with that is that applications, 07:30.000 --> 07:33.000 which use uninservices in this way, for instance, 07:33.000 --> 07:37.000 because they refresh, are not servers on internet somewhere. 07:37.000 --> 07:41.000 They are actual people who use actual computers and have actual lives 07:41.000 --> 07:44.000 that correlate with their uptime of miscomputers. 07:44.000 --> 07:47.000 So, one of the problems we wanted to solve was, 07:47.000 --> 07:51.000 we didn't want arbitrary people who just happens to know your username 07:51.000 --> 07:55.000 or your PDI in this context to be able to sell 07:55.000 --> 07:57.000 if we're using your computer or not. 07:57.000 --> 08:02.000 So, and then one other caveat here is, 08:02.000 --> 08:06.000 an uninservist client authorization doesn't solve this problem. 08:06.000 --> 08:11.000 So, this is a little tour feature that requires you to have a particular key 08:11.000 --> 08:14.000 in order to, additional authentication information 08:14.000 --> 08:16.000 needs to connect to an uninservist. 08:16.000 --> 08:18.000 But the problem is that even if you don't have the key, 08:18.000 --> 08:21.000 but you know the uninservist ID, you can still determine 08:21.000 --> 08:26.000 if the uninservist was online over a certain window time. 08:26.000 --> 08:28.000 So, it doesn't solve this problem, 08:28.000 --> 08:33.000 but it does decrease the time resolution of kind of knowing 08:33.000 --> 08:36.000 when people are online or offline. 08:36.000 --> 08:39.000 So, we kind of call this problem a cyber stalking, 08:39.000 --> 08:41.000 where, you know, if you know the service ID, 08:41.000 --> 08:44.000 you can kind of simply figure out their online or offline. 08:44.000 --> 08:48.000 At best, it's just a privacy violation. 08:48.000 --> 08:51.000 If you are a malicious third party, 08:51.000 --> 08:55.000 you can get a profile of somebody's online offline status. 08:55.000 --> 08:58.000 In a quite malicious third party, 08:58.000 --> 09:00.000 you can potentially discover your guard node. 09:00.000 --> 09:04.000 So, for example, you can enumerate listed guard nodes. 09:04.000 --> 09:07.000 If you have some sort of DDS botnetwork, 09:07.000 --> 09:10.000 you can just verify if somebody's online, 09:10.000 --> 09:12.000 DDS hardknock off a guard node, 09:12.000 --> 09:14.000 see if the user goes offline, 09:14.000 --> 09:16.000 it kind of steps through the guard nodes this way. 09:16.000 --> 09:21.000 A very malicious third party could use legal interventions 09:21.000 --> 09:24.000 or hacking or running malicious guard nodes to identify 09:24.000 --> 09:28.000 the actual IP address of an uninservice using this online offline profile. 09:28.000 --> 09:34.000 So, we wanted to avoid that in general case. 09:34.000 --> 09:38.000 One other little thing here is that if you are using 09:38.000 --> 09:41.000 one of these types of applications that use an uninservice 09:41.000 --> 09:44.000 as your endpoint that other peers connect to, 09:44.000 --> 09:47.000 but you don't broadcast your service ID, 09:47.000 --> 09:49.000 then you're fine. 09:49.000 --> 09:51.000 If you can trust the people you've shared it with, 09:51.000 --> 09:54.000 to not try to dox to you or discover where you are, 09:54.000 --> 09:56.000 or whatever, then you're fine. 09:56.000 --> 09:59.000 Uninservices are not generally enumerable. 09:59.000 --> 10:00.000 So, if you're running an uninservice, 10:00.000 --> 10:04.000 and you never tell anybody what the idea is, 10:04.000 --> 10:08.000 then nobody can tell that it's online or offline. 10:08.000 --> 10:10.000 All right. 10:10.000 --> 10:11.000 So, what we want. 10:11.000 --> 10:14.000 We want authenticated peers to be able to connect to each other 10:14.000 --> 10:15.000 and communicate. 10:15.000 --> 10:18.000 We want authenticated peers to not be able to determine 10:18.000 --> 10:21.000 people's online or offline status, 10:21.000 --> 10:23.000 but you also want authenticated peers to have a pathway 10:23.000 --> 10:25.000 to be coming authenticated. 10:25.000 --> 10:29.000 So, obviously, you can't do all these things at the same time. 10:29.000 --> 10:32.000 And a lot of these types of applications 10:32.000 --> 10:34.000 kind of require you to share your service ID 10:34.000 --> 10:36.000 for basic functionality. 10:36.000 --> 10:38.000 Like, if I want to chat with a friend, 10:38.000 --> 10:41.000 I have to tell them what my username is, right? 10:41.000 --> 10:45.000 So, the solution and Gosling is to split the responsibility 10:45.000 --> 10:47.000 across multiple uninservices. 10:47.000 --> 10:50.000 So, you just have one identity service, 10:50.000 --> 10:54.000 which is used as basically as an introduction point. 10:54.000 --> 10:58.000 And so, again, insert the instant messaging context. 10:58.000 --> 11:01.000 This is the ID that you would give people 11:01.000 --> 11:05.000 to invite them to chat with you. 11:05.000 --> 11:07.000 And so, they would connect to this uninservice 11:07.000 --> 11:10.000 and then the Gosling protocol will one verify 11:10.000 --> 11:12.000 if you'd actually want to be friends, 11:12.000 --> 11:13.000 want to be peers or whatever. 11:13.000 --> 11:16.000 And if they succeed this handshake, 11:16.000 --> 11:18.000 then they are given their own, 11:18.000 --> 11:19.000 especially unique uninservice. 11:19.000 --> 11:20.000 They are allowed to connect to you. 11:20.000 --> 11:23.000 And that's for the actual application logic happens. 11:23.000 --> 11:27.000 So, basically what this means is that 11:27.000 --> 11:30.000 to acquire new peers, they have to go through 11:30.000 --> 11:31.000 your identity service, 11:31.000 --> 11:34.000 but if you don't need any more peers, 11:34.000 --> 11:36.000 then you can just turn that identity service off 11:36.000 --> 11:39.000 and then all of your friends or contacts or peers 11:39.000 --> 11:40.000 or if you want to call them, 11:40.000 --> 11:42.000 each have different endpoints they connect to you. 11:42.000 --> 11:45.000 And if you ever want to revoke their access, 11:45.000 --> 11:48.000 then you can just stop running your uninservices. 11:48.000 --> 11:50.000 Oh, that's what I talked about, 11:50.000 --> 11:51.000 basically this now. 11:51.000 --> 11:54.000 So, the basic plan here is you can't, 11:54.000 --> 11:56.000 or basic ideas that you can't solve the problem 11:56.000 --> 11:57.000 in a general case, 11:57.000 --> 12:01.000 but you can give users control over their visibility 12:01.000 --> 12:03.000 and what they share and what sort of metadata 12:03.000 --> 12:06.000 they expose about themselves. 12:06.000 --> 12:09.000 I think I feel like I've blazed through this, 12:09.000 --> 12:10.000 but that's fine. 12:10.000 --> 12:12.000 I have a whole bunch of links to documentation. 12:12.000 --> 12:14.000 We have a design doc, a protocol spec. 12:14.000 --> 12:18.000 A usage guide, along with both a rust 12:18.000 --> 12:20.000 and a C++ sort of example, 12:20.000 --> 12:22.000 toyed chat application, which kind of lets you 12:22.000 --> 12:24.000 interact with and play with a protocol 12:24.000 --> 12:27.000 and sort of the stepwise command line away, 12:27.000 --> 12:30.000 and also create documentation because it's rust. 12:30.000 --> 12:34.000 There's a little screenshot of the example application 12:34.000 --> 12:35.000 you kind of see that where you kind of like 12:35.000 --> 12:37.000 store your identity service, 12:37.000 --> 12:39.000 stop it, start endpoints, end endpoint, 12:39.000 --> 12:40.000 send messages, that type of thing. 12:40.000 --> 12:42.000 List of peers I connect to you. 12:42.000 --> 12:45.000 This rust version, which just uses the trade directly, 12:45.000 --> 12:49.000 and a C++ version, which uses the CF5 version. 12:49.000 --> 12:54.000 Okay, a couple of shout outs from the organization I work for. 12:54.000 --> 12:55.000 Work for. 12:55.000 --> 12:58.000 We have this no slot project, which is a sort of project, 12:58.000 --> 13:02.000 which helps journalists and whistleblowers 13:02.000 --> 13:04.000 and organizations defend themselves against 13:04.000 --> 13:07.000 frivolous losses, which are kind of weaponized in Europe. 13:07.000 --> 13:10.000 This underdevelopment sterves project, which aims to sort of support 13:10.000 --> 13:12.000 whistleblowers. 13:12.000 --> 13:16.000 And of course, my two little tools or some of my tools I work on, 13:16.000 --> 13:19.000 Rick Shade refresh, which is kind of inspiration for this whole library 13:19.000 --> 13:23.000 and the idea of peer-to-peer earnings service applications 13:23.000 --> 13:25.000 and reducing this sort of exposed metadata. 13:25.000 --> 13:27.000 That's currently under active development, 13:27.000 --> 13:29.000 thanks to a grant from NL that. 13:29.000 --> 13:31.000 And then something which people might find useful, 13:31.000 --> 13:35.000 they don't find gosling useful, is a great call for interface. 13:35.000 --> 13:37.000 We look it up on crates.io. 13:37.000 --> 13:40.000 It basically encapsulates a lot of the nonsense 13:40.000 --> 13:43.000 of integrating legacy toward Yemen, 13:43.000 --> 13:46.000 as well as the new already implementation, 13:46.000 --> 13:49.000 and kind of wraps all of that stuff in a relatively simple 13:49.000 --> 13:53.000 and somewhat opinionated API service. 13:53.000 --> 13:55.000 So if you want to integrate towards your service 13:55.000 --> 13:58.000 into your application, or you want to programmatically 13:58.000 --> 14:01.000 start or stop running services or kind of things over toer, 14:01.000 --> 14:04.000 you should give this a great check out. 14:05.000 --> 14:07.000 And that's that. 14:07.000 --> 14:10.000 I have so much time for questions, I think. 14:10.000 --> 14:13.000 Thank you. 14:13.000 --> 14:19.000 There is indeed plenty of time for questions. 14:19.000 --> 14:21.000 So let's, let's get going. 14:21.000 --> 14:22.000 All right, Jeremy. 14:22.000 --> 14:24.000 Let's see your hand. 14:24.000 --> 14:27.000 Mmm, it's for a be a softball, Jeremy. 14:27.000 --> 14:30.000 Okay. 14:30.000 --> 14:39.000 So regarding the identity on your service that you described 14:39.000 --> 14:44.000 to mitigate the risk of checking what your uptime is. 14:44.000 --> 14:49.000 So there is an alternate way of gaining security with that. 14:49.000 --> 14:53.000 One of my Ricochet contacts does this thing where 14:53.000 --> 14:58.000 they only sign on once every like 24 hours 14:58.000 --> 15:01.000 for like only a couple minutes of the time. 15:01.000 --> 15:04.000 And they figure that if I want to send a message, 15:04.000 --> 15:07.000 I'll just have it cute in Ricochet refresh 15:07.000 --> 15:09.000 and they'll get it when they sign on. 15:09.000 --> 15:13.000 And so I'm curious, does, does the approach you describe 15:13.000 --> 15:16.000 of using a separate identity on your service? 15:16.000 --> 15:21.000 Does that sort of improve or foggingly to what my contact does? 15:21.000 --> 15:26.000 Like if you combine those two with that grant you additional 15:26.000 --> 15:29.000 security and some threat models? 15:29.000 --> 15:33.000 Potentially, I guess, if you don't 15:33.000 --> 15:37.000 rust your contacts, then that sort of extreme approach 15:37.000 --> 15:39.000 could be useful. 15:39.000 --> 15:41.000 So what I would imagine instead of what you're, 15:41.000 --> 15:44.000 so working on a new version, which includes this sort of 15:44.000 --> 15:46.000 visibility controls and visibility features 15:46.000 --> 15:49.000 around your online status in Ricochet refresh 15:49.000 --> 15:51.000 for the run version three now. 15:51.000 --> 15:54.000 What you would probably do is they would add you 15:54.000 --> 15:57.000 and whoever else they want to talk to on Ricochet 15:57.000 --> 16:00.000 and you would initially connect to their identity service. 16:00.000 --> 16:03.000 And once everybody is all friends and everybody else is list, 16:03.000 --> 16:06.000 they can just stop running their identity service. 16:06.000 --> 16:07.000 Right? 16:07.000 --> 16:10.000 And then the only person who would be able to 16:10.000 --> 16:12.000 know their uptime in this case would be you 16:12.000 --> 16:14.000 because you'd be able to connect to their one 16:14.000 --> 16:17.000 on your service endpoint that only you know and they know. 16:17.000 --> 16:21.000 And so at that point, presumably they trust you 16:21.000 --> 16:23.000 not to do all the various things I was talking about, 16:23.000 --> 16:25.000 then they can easily do that on. 16:25.000 --> 16:28.000 Alternatively, if they don't trust you either, 16:28.000 --> 16:31.000 they can also just turn off their endpoints and only 16:31.000 --> 16:34.000 connect to you whenever they come online. 16:34.000 --> 16:37.000 Or do the similar type of thing where 16:37.000 --> 16:39.000 they just like only come on once they see 16:39.000 --> 16:42.000 if they have a huge message for me for example. 16:42.000 --> 16:43.000 Cool. 16:43.000 --> 16:45.000 Is there any chance that Ricochet refresh might add 16:45.000 --> 16:49.000 a GUI option to automate that particular threat model? 16:49.000 --> 16:53.000 Maybe. 16:53.000 --> 16:57.000 At the moment, the current plan is to have a sort of kind of 16:57.000 --> 17:00.000 familiar setting to set your visibility. 17:00.000 --> 17:03.000 So by default, you'll be able to set yourself 17:03.000 --> 17:06.000 and totally online anybody can talk to me 17:06.000 --> 17:09.000 or a hidden mode where only your friends can see you 17:09.000 --> 17:12.000 or a completely sort of invisible mode where 17:12.000 --> 17:16.000 only time you ever connect to a contact is if you explicitly 17:16.000 --> 17:18.000 try to connect to them. 17:18.000 --> 17:20.000 And then of course an offline mode where nothing is 17:20.000 --> 17:22.000 online and you're not connecting anybody. 17:22.000 --> 17:24.000 So kind of. 17:24.000 --> 17:25.000 Okay. 17:25.000 --> 17:27.000 Makes sense, thanks. 17:27.000 --> 17:29.000 Well, wait for my question. 17:29.000 --> 17:31.000 Hello, yeah, I just have a question. 17:31.000 --> 17:32.000 Thanks for the talk. 17:32.000 --> 17:34.000 And for the great work that looks really interesting. 17:34.000 --> 17:37.000 I look forward to try the door interface. 17:37.000 --> 17:40.000 I mean, I can see how you abstracted away all the stuff you did 17:40.000 --> 17:42.000 before we could share. 17:42.000 --> 17:44.000 And you made it like libraries. 17:44.000 --> 17:46.000 But there's just, I think, one thing that is missing 17:46.000 --> 17:49.000 to make it like a really a completely alternative 17:49.000 --> 17:51.000 to like live peer-to-peer. 17:51.000 --> 17:55.000 It's being able to do a DHD, DHT distributed 17:55.000 --> 17:56.000 hash table. 17:56.000 --> 18:00.000 So is it something that you think about adding at some point? 18:00.000 --> 18:01.000 Or do you think it could be useful to have that in 18:01.000 --> 18:02.000 Gosling? 18:02.000 --> 18:06.000 What would you want the store and the distributed hash table? 18:06.000 --> 18:08.000 Well, it could be many things. 18:08.000 --> 18:12.000 I mean, usually when you build this decentralized peer-to-peer system, 18:12.000 --> 18:13.000 right? 18:13.000 --> 18:16.000 At some point, you want DHT, I guess, for a chat communication, 18:16.000 --> 18:18.000 you don't need it because you exchange your contact. 18:18.000 --> 18:21.000 But let's say you want the directory for something. 18:21.000 --> 18:23.000 Can be contact, you can be anything else. 18:23.000 --> 18:27.000 So at the moment, I have thought about this in the context 18:27.000 --> 18:28.000 of the sharing refresh. 18:28.000 --> 18:29.000 Where? 18:29.000 --> 18:31.000 So in the sharing refresh, we kind of have this very hard 18:31.000 --> 18:33.000 somewhat self-imposed constraint thing, 18:33.000 --> 18:37.000 exclusively peer-to-peer and not needing to run 18:37.000 --> 18:41.000 any extra infrastructure apart from the store network. 18:41.000 --> 18:44.000 In the context of a registry refresh, 18:44.000 --> 18:47.000 I have been thinking about, once this version is working, 18:47.000 --> 18:49.000 as a peer-to-peer, how can we add additional useful 18:49.000 --> 18:51.000 and useful functionality? 18:51.000 --> 18:57.000 Like, discord-like servers, for example, or whatever. 18:57.000 --> 19:02.000 I think that those types of things could be built on top, 19:02.000 --> 19:05.000 or adjacent to the peer-to-peer-to-peer part, 19:05.000 --> 19:07.000 but it's not really something I'm thinking about 19:07.000 --> 19:09.000 too actively right now. 19:09.000 --> 19:10.000 Okay, fix it up. 19:20.000 --> 19:22.000 Thank you for the talk. 19:22.000 --> 19:26.000 I guess my question, which may be you clarified, 19:26.000 --> 19:30.000 and I missed, but Gosling, is it based solely on 19:30.000 --> 19:33.000 already, or can I use it with C-tore? 19:33.000 --> 19:35.000 And if I can use it with C-tore, 19:35.000 --> 19:41.000 do you have, like, can I configure Gosling 19:41.000 --> 19:45.000 to use to work with Hoonix, basically, 19:45.000 --> 19:49.000 when the store binaries unlike some other box? 19:49.000 --> 19:53.000 Short answer, yes, longer answer. 19:53.000 --> 19:58.000 So Gosling is built, was originally built to work with C-tore. 19:58.000 --> 20:02.000 There is an experimental feature in the create itself 20:02.000 --> 20:05.000 that allows you to integrate the RD-client create, 20:05.000 --> 20:07.000 so it's completely in-proc. 20:07.000 --> 20:09.000 Outside of that, we recently received a patch 20:09.000 --> 20:12.000 from somebody on the internet to add support 20:12.000 --> 20:16.000 for configuring the C-tore demon using the 20:16.000 --> 20:19.000 standard environment variables that everybody expects 20:19.000 --> 20:21.000 and in terms of, like, the control port password 20:21.000 --> 20:25.000 or control port control file, or whatever, all that kind of stuff. 20:25.000 --> 20:28.000 So, if you go actually now and download 20:28.000 --> 20:31.000 the Riccii refresh alpha, it's an alpha, 20:31.000 --> 20:33.000 because I hold it whole new back ends. 20:33.000 --> 20:36.000 It is using the Tore interface create, which uses C-tore 20:36.000 --> 20:38.000 and it's kind of configuring this way. 20:38.000 --> 20:41.000 So, longer answer is yes. 20:41.000 --> 20:48.000 All right, we have time for one last question for me, move on. 20:48.000 --> 20:52.000 Who wants to hold the spatula? 20:53.000 --> 20:56.000 All right, well in that case, let's give it up one more time 20:56.000 --> 20:57.000 for Morgan, everyone. 20:57.000 --> 20:58.000 Thank you.