WEBVTT 00:00.000 --> 00:10.560 Hello, and welcome to this talk. 00:10.560 --> 00:13.160 This is how to level up the Fedivers. 00:13.160 --> 00:15.760 Who here came and saw our talk last year, right? 00:15.760 --> 00:16.960 The solid few. 00:16.960 --> 00:20.240 So if you know, if you know the reality of the situation, 00:20.240 --> 00:21.320 I'm Christine Lemmer, Robert. 00:21.320 --> 00:22.640 This is Jessica Talon. 00:22.640 --> 00:23.840 It's difficult to get in a word, 00:23.840 --> 00:26.880 adjoised with Jessica, and I'm the shy one. 00:26.880 --> 00:32.880 But anyway, but she's kindly let me speak a bit in this time. 00:32.880 --> 00:35.760 So, you know, but who are we? 00:35.760 --> 00:37.040 What are we doing here, right? 00:37.040 --> 00:40.120 Well, you know, you might have heard of this thing called Activity Pub. 00:40.120 --> 00:41.840 Has anybody heard of Activity Pub? 00:41.840 --> 00:45.080 Yeah, okay, all right, a little bit of knowledge. 00:45.080 --> 00:49.080 So, you know, some decentralized social-weddes thing, basically. 00:49.080 --> 00:51.320 And, well, would you know, would you look at this? 00:51.320 --> 00:53.320 It's got, who are the editors, Christine Lemmer, 00:53.320 --> 00:54.440 Weber, and Jessica Talon? 00:54.440 --> 00:56.360 That's us, we're here, we're so okay. 00:56.360 --> 00:58.400 So, that's, that's us from the stage. 00:58.400 --> 01:01.440 We know a thing or two, we've got to, we've got some ideas, right? 01:01.440 --> 01:02.640 We've been doing this for a while. 01:02.640 --> 01:05.160 And actually, we work at this organization called The Sprayatly Institute. 01:05.160 --> 01:08.800 We're doing research in next generation decentralized networking tech. 01:08.800 --> 01:13.800 And, and we're here to talk about how this relates to the Fedivers. 01:13.800 --> 01:15.480 But we do a whole lot of different things. 01:15.480 --> 01:18.280 So, actually, because we love cutesy characters, 01:18.280 --> 01:21.160 we have a bunch of different characters that represent our cutesy stuff. 01:21.160 --> 01:24.600 As in terms of the very serious tech that we actually do work on, 01:24.720 --> 01:26.000 we're not going to talk about all of this, 01:26.000 --> 01:28.120 not all the super-applies to the Fedivers, 01:28.120 --> 01:30.280 but quite a bit of it does, actually. 01:30.280 --> 01:37.120 And, and, and, and, and so, the big, the biggest thing that we want to talk about here 01:37.120 --> 01:39.440 is that from our perspective, the Fedivers has not done. 01:39.440 --> 01:43.200 There, it's, we've have a lot of adoption, it's great. 01:43.200 --> 01:45.400 There's a lot of things that do go really well, 01:45.400 --> 01:47.040 but there's some things that are really missing, right? 01:47.040 --> 01:50.280 So, one of the biggest complaints is people are afraid to adopt the server, 01:50.280 --> 01:53.400 because a server can go down and they lose access to their content, 01:53.400 --> 01:56.160 so it's a graph to their identity, right? 01:56.160 --> 01:58.640 And, so we want portable content and identity. 01:58.640 --> 02:02.040 We have some stuff Jessica is going to talk about the importance of client the server. 02:02.040 --> 02:05.800 We're going to talk about a better security model. 02:05.800 --> 02:10.000 Self-hosting is clearly hard, and this back is not quite as peer-to-peer. 02:10.000 --> 02:13.800 And, also, if I boost your post, it might take down your instance. 02:13.800 --> 02:15.480 So, then that shouldn't happen. 02:15.480 --> 02:22.640 So, um, now you may be aware that I wrote this blog post and a follow-up 02:22.640 --> 02:29.960 that got quite a bit of attention, kind of critiquing AT Prodo and in kind of in-depth. 02:29.960 --> 02:34.960 And, I think, I think if you didn't read it, you might just think that I'm, 02:34.960 --> 02:38.800 it was either Pro One Camp or against another, but in reality, actually, 02:38.800 --> 02:43.440 it's just that I think there are certain ideas that are really important and useful 02:43.440 --> 02:45.080 from various pieces of tech. 02:45.080 --> 02:49.080 And now I'm going to throw myself under the bus by saying that actually, 02:49.080 --> 02:52.280 I go off a proposal for a blue sky at one point. 02:52.400 --> 02:55.680 And actually, I think this right up is not what happened with blue sky, 02:55.680 --> 03:00.320 but I actually think it has a lot of the ideas that are articulated in this from a thing 03:00.320 --> 03:03.760 in 2020 or a lot of the ideas that we're going to hear us talking about today. 03:03.760 --> 03:10.480 These ideas don't aren't new, and the idea of combining the ideas from different types 03:10.480 --> 03:12.280 of approaches is also not new. 03:12.280 --> 03:15.160 And, in fact, actually, you can go even further back to that. 03:15.160 --> 03:20.440 Before activity, Pub was actually successfully ratified as a W3C standard. 03:20.760 --> 03:25.400 I co-authored this paper activity Pub from decentralized to distributed social networks, 03:25.400 --> 03:26.960 and that was in 2017. 03:26.960 --> 03:30.640 So these ideas of being able to bring the Fediverts in some of this direction, 03:30.640 --> 03:34.160 the idea that the Fediverts just as in terms of the way that the document was written 03:34.160 --> 03:39.840 is not the complete and final story, and that there are ways that are specification and compatible 03:39.840 --> 03:45.080 that we can improve things is really at the heart of what we're talking about today. 03:45.080 --> 03:49.080 So the first thing I want to talk about is content addressing is a freaking great idea. 03:49.080 --> 03:52.080 So I don't know if you're familiar with content addressing, 03:52.080 --> 03:53.840 but you're certainly familiar with links like this. 03:53.840 --> 03:55.360 There's this lovely cat picture, right? 03:55.360 --> 03:59.720 It's at example.org slash cat.jpg, but example.org goes down, 03:59.720 --> 04:01.800 and you can't access this picture anymore, right? 04:01.800 --> 04:04.880 So this is a problem with HTTP based links. 04:04.880 --> 04:08.000 And it turns out there's more than one type of link. 04:08.000 --> 04:09.160 You know, HTTP is one of them. 04:09.160 --> 04:10.400 Here's another type. 04:10.400 --> 04:13.400 So this is a URN for a hash, right? 04:13.400 --> 04:17.800 And technically, anything that actually matches this hash, 04:17.840 --> 04:25.840 so this is a hash to the cat picture, is the actual version of this cat picture, right? 04:25.840 --> 04:28.440 And but you're like, okay, well, great. 04:28.440 --> 04:31.080 So this means that if example.org goes down, 04:31.080 --> 04:35.480 then I can still get the cat picture, but how do I know where I should get it from, right? 04:35.480 --> 04:41.080 So there's something called magnet links, which actually combine these ideas and several others. 04:41.080 --> 04:46.440 So for example, right here, you see it has the hash version of the hash to the cat.jpg, 04:46.440 --> 04:50.840 but as the exact topic, but it also says, as an acceptable source, 04:50.840 --> 04:54.200 you can get it from at this link. 04:54.200 --> 04:57.800 And so that actually composes those ideas together. 04:57.800 --> 05:02.480 And it turns out that this can, this is specification compatible with activity pub. 05:02.480 --> 05:07.680 And very early on in Spratley's history, I wrote this little demo that actually showed 05:07.680 --> 05:12.800 an activity pub compatible implementation that uses constant addressing, right? 05:12.800 --> 05:19.920 That says, you know, here is a way to be able to distribute objects that are referred to by their content. 05:19.920 --> 05:27.360 In a way that is compatible with activity pub, you thought to make sure that activity pub could actually contain more than just HTTP URIs in it. 05:27.360 --> 05:31.920 And it's a demo, but it works. 05:31.920 --> 05:36.400 And there's ways, that is really washed out looking on the screen. 05:36.400 --> 05:42.480 But this is the mascot for our character, Port Bella, which represents a project where we have 05:42.480 --> 05:52.880 encrypted content address storage, so hosting providers can actually host things without even knowing the exact details of the content that they're hosting and that you can be able to retrieve them. 05:52.880 --> 05:56.080 And this is the one thing that I'm going to say that the blue sky got right. 05:56.080 --> 06:02.800 I have a lot of criticisms that their current infrastructure is not actually fully decentralized, 06:02.800 --> 06:05.600 but this idea is correct, right? 06:05.600 --> 06:12.400 It doesn't originate with blue sky and hp, but the decision to be able to make this a key part of the system is actually 06:12.400 --> 06:17.360 one that I think the Fedivers should adopt and I've been arguing so for it since about 2017. 06:18.560 --> 06:23.680 And it turns out if you have content addressing and you have the ability to have updates to it, 06:23.680 --> 06:28.000 you can think of how Git is immutable, but you can actually have updates to a Git repository, right? 06:29.200 --> 06:32.880 There is a similar idea that as in terms of mutable content addressing, 06:32.880 --> 06:36.640 this is actually sufficient to be able to have decentralized identity and activity pub. 06:36.640 --> 06:41.840 Because if you have an activity pub profile that has an inbox, you can point the inbox at a new location 06:41.920 --> 06:44.160 as you end up moving between different servers. 06:46.480 --> 06:47.840 But I'm going to hand it over to Jessica. 06:49.600 --> 06:50.000 Hello. 06:51.600 --> 07:00.400 So the first thing I'm going to talk about is this paper that we worked on at Spritely. 07:01.040 --> 07:05.040 And it's a humane approach to secure decentralized naming. 07:06.000 --> 07:11.920 Naming on distributed social networks is important where there are a lot of people and people have 07:11.920 --> 07:22.240 names and we want to be able to have contacts and and build a network and everything. 07:22.960 --> 07:27.520 I'm not going to go through this entire paper, but it's on our website if you want to. 07:28.480 --> 07:34.880 Oops. This is, yeah. And this is Brooks. This is another one of our map scouts. 07:34.880 --> 07:37.680 And this is an implementation of the pet name system. 07:39.120 --> 07:42.800 And I'm going to go into what pet names actually are in a second. 07:45.040 --> 07:51.280 But first let's just look at how naming works on the teddyverse at the moment. 07:51.280 --> 07:58.400 So this is mastered on and you can see we were starting to type a post and it's 07:58.400 --> 08:04.400 hopefully trying to fulfill some of these names. So we can order to complete this. 08:06.240 --> 08:12.640 But if you think about it, this is this is very fishable. Someone could easily create a profile 08:12.640 --> 08:18.640 and set their display name and picture and try and fish you with this system. 08:18.640 --> 08:26.640 And so that's, that's not ideal. And if you think to what Chrissy was talking about with 08:26.640 --> 08:36.240 distributed identity, well, I might be able to remember Cweberatsocial.co-op, but my memory is not 08:36.240 --> 08:43.280 good enough to remember this, as certainly not for a lot of people. And so what do we do about that? 08:43.280 --> 08:51.200 And turns out pet names can help with this too. There's something called Zuko's Triangle, 08:51.200 --> 08:57.600 which says you can pick two of the following. So names can either be globally unique, 08:58.880 --> 09:03.840 decentralized or human meaningful. And it turns out in a, well, we want decentralized, 09:03.840 --> 09:09.120 because we're building the decentralized social networks. We want them to be globally unique, 09:09.120 --> 09:14.560 like Chrissy was saying. But we're also people and we want them to be meaningful to ourselves. 09:14.560 --> 09:19.360 So how do we solve this? And it turns out pet names are the solution to this. 09:20.960 --> 09:26.240 Now, pet name might not be something you're familiar with, but you might actually be more familiar 09:26.240 --> 09:34.560 with it than you think. This is a picture and you can see it looks like your phone dialer. And indeed, 09:34.640 --> 09:40.320 you have a sort of pet name system in your pocket already in your contacts list. 09:41.200 --> 09:45.360 You probably don't remember all of the phone numbers in that contact list, but you're assigning 09:45.360 --> 09:51.360 names. And those names are not just generic names in a lot of cases. They're human meaningful, 09:51.360 --> 09:58.400 them mum, for example. And my mum is not the same as any of your mum's. And so these can be 09:58.480 --> 10:05.920 highly personal and highly meaningful to you. And these are names you give, you give contacts 10:05.920 --> 10:13.120 yourself. And these are actual pet names in the pet name system. There are two other types of names too. 10:15.120 --> 10:20.240 And when you're searching for a name, as you can see here, we're searching for Ben, 10:20.240 --> 10:26.240 and you can see some pet names. But under here, you can see network contacts. And this is another 10:26.400 --> 10:32.880 type of name. This is what's called an edge name. And you can see here that Alicia is sharing 10:32.880 --> 10:40.160 a name to us for a contact. And this name is Ben Bitbiddle. And that's the name she's given. 10:40.160 --> 10:49.680 And you can rely on your network of people to provide names and help you corroborate who people are 10:50.640 --> 10:55.760 and give you a better idea. And so you can sort of rely on that trusted network of people 10:55.760 --> 11:04.800 or directory's even. And this is a mock-up of a chat application, but this could easily apply to 11:06.400 --> 11:13.680 mastered or some other social network sort of setting. And this has two kinds of names. You can see 11:13.680 --> 11:19.600 a star light here. And that's a pet name. It's got a solid border around it. And you can also see 11:19.920 --> 11:24.480 Carol here with a question mark. And this dotted line around it. And this is what's called 11:24.480 --> 11:29.360 a self-propos name. And this is a name you give yourself. Think of it like an IRC handle or something 11:29.360 --> 11:37.840 like that. You display name on master. And this is a name you give yourself and people can see. 11:37.840 --> 11:45.680 So with all of these three types of names together, you can solve distributed naming. 11:46.640 --> 11:52.080 By keeping the human meaningfulness, but also apply it to distributed identities. 11:54.320 --> 12:02.160 And this is not just something that applies in chat settings and things. This is a mock-up of how 12:02.160 --> 12:10.160 it could apply to master it on. So this can certainly apply to social applications like 12:10.160 --> 12:17.760 Nفسed Honor or any other activity probe implementation. Another thing I want to talk about 12:17.760 --> 12:23.280 is the client to server specification. And I think there was a talk this morning that I didn't 12:23.280 --> 12:30.640 end up making so I'll have to catch up on that. But this is a very important part of the spec. 12:32.640 --> 12:37.840 So if you look at the specification, you see, okay, there's a server to server spec. And this is 12:37.840 --> 12:42.000 what most people know. And if you're implementing activity probe, it's probably what you're 12:42.000 --> 12:49.680 looking at in the spec. And you know, that's great. But if you actually keep scrolling, 12:49.680 --> 12:56.000 there is another protocol in the specification called the client to server specification. And it's 12:56.000 --> 13:02.800 there for a really good reason. And people need to pay attention to it and think about implementing it. 13:03.200 --> 13:16.880 And if we look here, this is peer trooper. And on this, you could post a video and then you can 13:16.880 --> 13:26.240 see it in master it on, you can see it. You can even post a comment and let me hold that 13:26.320 --> 13:31.120 fatter rates back to peer trooper. And this is a great success of case, right? This is what we 13:31.120 --> 13:40.240 know activity probe to be. And it's great and wonderful. And it's a really good success case. 13:40.240 --> 13:47.600 But this idea of let's build a video, social network application. And let's build one for my 13:47.600 --> 13:57.360 crow blogging or one for blogging or one for like lemme for Reddit style content. That's the wrong 13:57.360 --> 14:07.280 model in my opinion, at least. We really should be building, we should really be building generic 14:07.280 --> 14:15.120 applications. And this is a pub straight. It was developed by Christine in the standardization 14:15.120 --> 14:22.240 process of activity pub. And we can see here, it supports micro blogging and here's some 14:23.680 --> 14:32.960 micro blogs posted by Christine. And that's great. And then we can also see you can post images, 14:33.920 --> 14:44.880 wonderful. And you can also post videos and you can post any number of content. And I think this is 14:44.960 --> 14:51.120 is the direction that we should have been going. And if you look at the history of activity 14:51.120 --> 14:58.320 activity probe and what came before it, there was Evans, Pompeo and a few. If you're a Pompeo user, 14:58.320 --> 15:08.800 anyone remember, open farm game? We're watering your tomatoes. And you could post any number of 15:08.800 --> 15:18.320 content. And you can also, you know, you can have generic servers where you set up a profile 15:18.320 --> 15:27.200 and then very flexible clients. And in Pompeo, it would display what it could have a fallback 15:27.200 --> 15:33.120 of display what it could. But you can also have very specific clients too. And one of the great 15:33.120 --> 15:40.400 things about the client to server protocol is that it supports this wide range of content. 15:40.400 --> 15:45.120 So if you wanted to build a very specific client for posting YouTube, you could use that with the 15:45.120 --> 15:52.400 generic server, but you could also use a more broad generic one with the same server. And that would 15:52.400 --> 16:00.160 allow you to have a single account on the Fediverse and have a single set of followers and people 16:00.160 --> 16:07.360 could follow you. And you could be interacting on lemme or peer tube and posting lots of diverse 16:07.360 --> 16:13.120 amounts of content. And I think that's a better model than having many accounts over different 16:13.120 --> 16:17.280 instances. And if you're setting these up yourself, add meaning, many different instances. 16:19.600 --> 16:24.720 And now I'm going to talk about the active model. And what is the active model? Well, it's actually 16:24.800 --> 16:33.040 a, it's a programming paradigm, similar to our object orientation or imperative or whatever. 16:33.040 --> 16:38.080 And I'm not in the wrong room. I'm still talking about the social network. And if you look in the 16:39.280 --> 16:47.040 activity per spec, you'll see we mention the active model a bunch. And why do we do that? It turns out 16:47.120 --> 16:58.160 the active model is actually really good at implementing this decentralized applications. And 16:58.160 --> 17:05.360 it's the foundation also of activity, but obviously we're working in often Django or Rails or whatever 17:05.360 --> 17:12.240 and these object orientated languages. And so here's another character and a family of characters 17:12.320 --> 17:20.000 and sprightly. And this is Goblins. And this is an activity, sorry, an active model framework 17:20.720 --> 17:29.680 written in scheme that we've worked on for a long time. And this is another character called Mandy. 17:29.680 --> 17:38.880 And this is activity pub on Giles. On the Goblins' active model framework. And currently it's 17:38.960 --> 17:44.320 just a prototype. Don't go running it unless you just want to play with it. Don't use it in 17:44.320 --> 17:50.800 production. It's what I'm trying to say. It's not very featureful, but it's showing this idea of 17:50.800 --> 17:58.880 message passing between activities and really adopting it in its sort of native environment. 17:58.880 --> 18:04.080 And I think that can be really powerful too. I'm going to hand back to Christine. 18:04.960 --> 18:10.480 So part of the reason we bring this up is a few years ago, who's seen this document? The 18:10.480 --> 18:14.400 okay pub networks of consent. Okay, a few people have seen it. So every now and then some sort of 18:14.400 --> 18:18.480 crisis happens on the pediverse and people are like, oh crap, how do we solve this? And people are like, 18:18.480 --> 18:23.680 oh, Christine actually was writing about this a few years ago. And so this is a document talking 18:23.680 --> 18:30.240 about security model aspects and also some social aspects of a system that's trying to be very 18:30.320 --> 18:37.520 consent respecting of people on the system. It uses this model of security called object capability, 18:37.520 --> 18:42.560 security. You can actually think of capability security as actually being a consent granting 18:42.560 --> 18:51.280 mechanism, where which is accountable, revocable, and is very intentionally granted and is limited. 18:52.400 --> 18:57.200 And one of the big challenges we had when I wrote this is that people were like, it's really 18:57.280 --> 19:01.200 hard for me to think about this and kind of like a Jango Rails type perspective. 19:01.200 --> 19:06.240 So this is kind of, and in many ways actually this kind of informed some of the future work 19:06.240 --> 19:11.440 to happen on spritly of trying to actually push the frontier of some actor model type programming 19:11.440 --> 19:14.880 so that you know, you could see, well, what ends up happening when you start thinking in terms 19:14.880 --> 19:24.880 of kind of actor model development. But I guess we had one more thing, which is who's ever had 19:25.040 --> 19:28.560 a post-boosted by me or somebody else's topic that kind of took down your own instance. 19:29.280 --> 19:36.800 Okay, a couple of people, I'm sorry, and the happens to my girlfriend all the time. 19:38.720 --> 19:46.400 But actually this is partly a consequence of something that we kind of knew about 19:48.000 --> 19:52.480 and is actually mentioned in the spec, but it's not a normative requirement. So at the end of the 19:52.480 --> 19:57.760 spec, it basically talks about how do you authenticate messages, right? And how do you do authentication 19:57.760 --> 20:05.040 and authorization? This thing of Ocap Pub is about, if you want to get into maybe this is a 20:05.040 --> 20:08.400 little bit too computer sciencey for some people, but this is more about the authorization, 20:08.400 --> 20:12.720 how you can do things thing. And then this one's about the side of authentication as in terms of 20:12.720 --> 20:19.200 how do you know that somebody is actually said the things that they did, right? So the reason that if I 20:19.200 --> 20:23.040 boost my girlfriend's post, that it takes down her server and all of her friends, 20:24.400 --> 20:32.160 is that what happens right now to be able to verify that she said the thing is since we don't 20:32.160 --> 20:36.240 have reliable signatures. And to Amazon's credit actually, Amazon did implement JSON all the 20:36.240 --> 20:41.600 signatures, but very few other things did, because it turns out they're difficult to 20:41.600 --> 20:46.240 canonicalize for a technical reason that's kind of more out of scope of this particular talk. 20:46.240 --> 20:51.600 But if we did have a signature solution, and I believe we could build one, including one that 20:51.600 --> 20:54.720 addresses the things that ended up being challenging with JSON all these signatures, 20:55.920 --> 21:02.240 what we would be able to do is to be able to distribute messages. And if I distribute my girlfriend 21:02.240 --> 21:07.040 VV's message, and then you receive it, you don't have to dial back to her server to make sure that 21:07.040 --> 21:12.080 it's actually there. You can actually, if you've already retrieved VV's profile at one time, 21:12.080 --> 21:16.480 and you know, you can see that it's signed with her key, you can say, okay, I'm pretty confident 21:16.480 --> 21:21.680 actually that VV sent this, and so unless it's within that time period, she had to revoke 21:21.680 --> 21:25.840 that key or something like that, you would be very certain, right? You'd actually be quite certain 21:25.840 --> 21:30.880 that she had said this thing, and we wouldn't have this thing where boosting posts actually 21:30.880 --> 21:37.280 can actually have a performance hit, which is kind of anti-social when you're what you're 21:37.280 --> 21:42.320 trying to do is actually to show how much you like something. So let's get to the wrap-up, 21:44.160 --> 21:51.920 we've set a lot of things. Part of the thing here is that we've, since despite these institutes 21:51.920 --> 21:57.520 started actually, one of the reasons we're giving this talk today is that it kind of looked like 21:57.520 --> 22:00.720 we ran off, and we did all these things over here, and people were like, aren't you the activity 22:00.720 --> 22:07.440 put people, you're supposed to be working on stuff relevant to us, and we are, but I think 22:07.440 --> 22:11.440 in some ways it wasn't quite obvious, because we have some other layers of our protocol that 22:11.440 --> 22:16.880 we've also been very focused on, but the goal here is to actually talk about how this stuff is 22:16.880 --> 22:26.800 very local and relevant. Yeah, and I just want to say that there are plenty of parts of the 22:26.800 --> 22:32.880 talk that may be sound a bit out there if you're just writing an activity pump implementation 22:32.880 --> 22:39.280 today with Rails or whatever, but there's a lot of this talk that you could do today. This is not 22:40.080 --> 22:46.400 requesting changes to the activity pump spec. This is not necessarily rewriting your entire app. 22:46.400 --> 22:52.240 This is things like adopting the client server API, which actually if you look at it, 22:52.240 --> 22:57.600 it looks very similar to the server to server API. It really isn't going to be that crazy to 22:57.600 --> 23:03.680 it implement, and they decentralize naming. That doesn't require a spec change. That is perfectly 23:03.680 --> 23:11.600 compatible with the spec. And even some of the other stuff in here, we've been working on, you know, 23:11.600 --> 23:17.600 where Sprite Lease Research Institute, we've done a lot of work on this, we've published 23:17.600 --> 23:25.280 the Pat Names paper, and we're working on Goblins, and lots of Porto Baller for the technology 23:25.280 --> 23:31.520 behind a lot of this. So if you want to, you can come, this paper is published on our website, 23:31.520 --> 23:37.440 but I do want you to take away, you can do this today, and a lot of it. There's a lot of low hanging 23:37.440 --> 23:43.280 fruit. And on that note, if you haven't checked out the Sprite Lease Research Institute, we've got a lot 23:43.280 --> 23:47.520 of cool stuff. You should check it out. We even published video games, so you can test out the 23:47.520 --> 23:51.440 weird low-level tech that we're talking about. You want to experience time-traveled debugging 23:51.440 --> 23:55.120 live while playing a video game. You can do it on the Sprite Lease. We have a whole arcade page. 23:56.320 --> 24:01.920 But, you know, are we a decentralized networking research organization, or are we a queer 24:01.920 --> 24:08.240 indie game development organization? Why not both? So anyway, and you can also donate to help 24:08.240 --> 24:12.240 move along the work that we're doing, and also kind of help us, we would like to bring it 24:12.240 --> 24:18.160 spend more of the time focusing on bringing things back to the Fediver's type space. And so yeah, 24:18.160 --> 24:22.000 the, that's it. I'm going to stop. Thanks. 24:24.000 --> 24:28.800 So Jessica, may I give you this one? Can we give me the hand light? 24:31.280 --> 24:37.760 Try, just test it. Test test? Good. All right, let's see. Do we have any questions for Jessica and 24:37.840 --> 24:40.800 Christine? One way up there, of course. 24:49.840 --> 24:54.160 So first of all, I think FedNames are really cool. We create a video. 24:55.520 --> 25:05.360 But I want to ask if there's any way of reducing the friction for adding and following people. 25:05.440 --> 25:13.200 So for example, on the centralizing networks, it's very easy at Joe or whatever. But like, 25:13.200 --> 25:18.720 if you want to follow me on, I don't know, first of all, or whatever, then I need to put the 25:18.720 --> 25:25.920 full URL and that confuse this people. So is there any pen name like feature for this sort of 25:25.920 --> 25:33.920 interaction? This is a good question, which is that it's already pretty difficult to be able to follow 25:33.920 --> 25:37.200 people on the FedNames, basically, if you, here's somebody's handler or whatever. 25:38.240 --> 25:45.280 So there is, part of the challenge here is actually the challenge of the fact that we're doing 25:45.280 --> 25:50.240 things inside of browsers. And the fact that, you know, what you really would want to be able to do 25:50.240 --> 25:57.040 is to recognize that you're accessing some sort of link that expresses an intent that it's relevant 25:57.040 --> 26:02.080 to, you know, your FedNames type works that you could. So there have been some other work on things 26:02.080 --> 26:07.440 like Web Intense and stuff like that that would be really helpful. I am not up this bit on 26:08.480 --> 26:13.840 where that current work is, but I think that I think that, you know, a lot of what we're talking 26:13.840 --> 26:21.280 about here is kind of like, in, like, kind of in band of the stuff that you're doing inside of the 26:21.280 --> 26:26.160 FedNivers, but there are ways to be able to simplify it, but it gets a little bit into kind of like 26:26.160 --> 26:29.440 the, like, how would you actually implement Web Intense and stuff like that in a way that 26:29.440 --> 26:35.840 browsers would actually cooperate with. And that's a little bit out of scope for me to get into 26:35.840 --> 26:40.960 right here. And also, I'm not quite as up to state on the latest efforts in that space. 26:45.840 --> 26:53.360 How does the OCAP Pub plan compare to existing FedNivers enhancement proposals about decentralization 26:53.360 --> 27:04.640 and core block checks? So the OCAP Pub right up is, it is, I think the big challenge with the 27:04.640 --> 27:11.280 OCAP Pub work is actually how likely is it that the FedNivers will actually be interested in 27:11.280 --> 27:16.960 at this point, right? And as I actually think it's very interesting, I think it's Benjamin Goring 27:16.960 --> 27:21.760 has done some work towards actually trying to implement the stuff, but the big challenges, 27:22.720 --> 27:27.440 a lot of assumptions kind of have, when I wrote that up, I was kind of writing it up in a panic 27:27.440 --> 27:31.680 as in terms of, like, I was worried about some things that ended up becoming kind of very focused 27:31.680 --> 27:40.400 on kind of domain-oriented things, getting embedded in there. And the OCAP Pub is not as focused 27:40.400 --> 27:49.200 on portable objects that's kind of more of the content addressing side of things. And I know there 27:49.200 --> 27:52.880 have been attempts to do things that are not as content addressing oriented in the FEPs, 27:52.880 --> 27:57.600 I'm not as up to date on them, but I do think that content addressing is the right way to do it 27:57.600 --> 28:04.640 personally. In terms of OCAP Pub, part of the reason I was writing it up then was, you know, 28:04.640 --> 28:09.600 kind of a concern that if I didn't get it written, we might kind of miss the opportunity 28:09.600 --> 28:14.240 and that the FedNivers may also fly. I'm not sure if that's actually already passed. It could be 28:14.240 --> 28:20.880 that the authorization side of things is actually the hardest nut to crack. You might notice that we 28:20.880 --> 28:26.160 spent the least amount of time kind of talking about OCAP Pub in here. That's partly because I don't, 28:26.160 --> 28:29.520 I don't know how much interest there was. When I originally started writing up OCAP Pub and 28:29.520 --> 28:33.920 talking about it with FedNivers implementers, a lot of the response that I got was this sounds really 28:33.920 --> 28:39.200 good, but it sounds a little bit too off-track for the direction that things are kind of going 28:39.200 --> 28:44.080 in the type of frameworks that we're currently using. So I would like to see it advanced further, 28:44.080 --> 28:49.920 but it actually requires us being able to kind of, it would require, it would require some more 28:49.920 --> 28:54.080 dedicated research time and effort, and we've kind of only barely dipped into that, just to 28:54.080 --> 29:00.160 have a little bit of time to be able to work on Mandy and show off how it could apply. But we 29:00.720 --> 29:05.200 it is something that let me put it this way. If you think that the kind of networks of consent 29:05.200 --> 29:09.600 model actually sounds really appealing, we could really use to help actually as in terms of being 29:09.600 --> 29:15.120 able to get some enough resources to be able to provide dedicated time on that. By the way, 29:15.120 --> 29:21.600 spray lead on institute slash donate. Always could use help there. Any other questions or do we 29:21.600 --> 29:30.240 have time for any? Okay, go ahead. Thanks. Do you have other thoughts on the ecosystem behind 29:30.240 --> 29:34.800 these ideas that you've outlined? So I was starting to write a service one to two implement this, 29:34.800 --> 29:39.680 but kind of didn't find any libraries for implementing the low-level stuff that I needed. 29:40.240 --> 29:46.640 What do you think is missing most there? That's a big question. It's about, we'll go ahead, just 29:46.640 --> 29:53.200 it. We're trying to work on some of the libraries and things to do with it. So obviously, 29:53.200 --> 29:59.440 we work in schemes. So maybe it's an applicable, I don't know. But hopefully these will come 30:00.080 --> 30:05.760 in time. Goblins is awesome and you should be using it. I will say that. 30:06.560 --> 30:09.360 Okay, I think that's it. All right, thanks everybody.