1 00:00:00,000 --> 00:00:27,080 Today we are joined by Andreas from P2Panda. 2 00:00:27,080 --> 00:00:32,840 Pyrtupanda is a protocol or a network compatible with post-internet communication 3 00:00:32,840 --> 00:00:37,640 infrastructures such as pocket radio, Bluetooth or sneakernet, what it's also 4 00:00:37,640 --> 00:00:43,840 known as USB transfer. It's a bunch of different modules that can all be 5 00:00:43,840 --> 00:00:50,280 accessed via the out of the box API, primarily written in Rust. Pyrtupanda was 6 00:00:50,280 --> 00:00:56,520 initiated by Andreas and Sam and since then Glyph has also joined the team. 7 00:00:56,600 --> 00:01:02,200 Andreas specifically is a programmer and musician and the tunes from a guitar you 8 00:01:02,200 --> 00:01:08,120 might hear scattered throughout the episode is clippings from his post episode tunes. 9 00:01:09,320 --> 00:01:16,200 He is been quite active in the scene and has been involved in the shaping of terms such as 10 00:01:16,200 --> 00:01:22,360 the walkaway stack and is also an active part of Modal and if you're curious about Modal, 11 00:01:22,360 --> 00:01:37,480 you can listen to the episode with Tobias. Now with no further ado, let's dive in! 12 00:01:52,520 --> 00:02:10,040 Hello and welcome to today's episode of SolarCast! I'm here with ADZ or Andreas. 13 00:02:11,400 --> 00:02:18,280 Hi. Hello. Really nice to be here. So we've known each other for a long time now. So almost 14 00:02:18,280 --> 00:02:28,840 ten years since this got about days and but I actually don't know how you got involved in all 15 00:02:28,840 --> 00:02:38,120 of this and where it all started. Yeah, I think there is this talk we gave at CCC. I think it was 16 00:02:38,840 --> 00:02:46,920 2019 and that's a very weird time capsule to go into when one wants to understand how we ended 17 00:02:46,920 --> 00:02:54,360 up doing the thing we're doing but at this time we wanted to build a software to organize 18 00:02:54,360 --> 00:03:02,520 festivals on top of scuttlebutt and it was meant to be called Pier Topanda and the background 19 00:03:02,520 --> 00:03:09,880 of that is that I was involved in another collective. I mean we started I think 2013 I think 20 00:03:10,440 --> 00:03:21,400 publishing a magazine called Plats 3000 which was meant to be like a very open platform for people 21 00:03:21,400 --> 00:03:28,680 to publish whatever thoughts they had on music. So it was like a discussion thing for people 22 00:03:28,680 --> 00:03:34,920 interested in nerdy music and the idea was that anyone can publish anything so it wouldn't be 23 00:03:34,920 --> 00:03:43,480 curated and anyone can answer to anyone else's articles. So it was also a little bit like a forum 24 00:03:44,680 --> 00:03:49,880 and maybe the magazine didn't go that well but I think the community around it which came out 25 00:03:49,880 --> 00:03:56,920 of that was really beautiful. So we had a lot of great gatherings and release parties and a lot of 26 00:03:56,920 --> 00:04:04,040 fun printing these magazines with weird covers and yeah and then we started to organize festivals 27 00:04:04,040 --> 00:04:13,720 because we really like this mode of non-curated content and then why specifically non-curated content? 28 00:04:13,720 --> 00:04:21,320 Yeah this is this comes from a very special niche but like I have a background in experimental 29 00:04:21,880 --> 00:04:27,720 contemporary music which in Germany has this very strange thing of noya music 30 00:04:28,520 --> 00:04:38,680 and which is highly academic so we have like dumb studs and all of these like big festivals 31 00:04:38,680 --> 00:04:45,080 where noya music is performed and at this time I think we were very bored by the academic part 32 00:04:45,080 --> 00:04:51,080 of that and the highly institutionalized aspect of it and we kind of wanted to break that a little 33 00:04:51,080 --> 00:04:55,240 bit because there's been a couple of people who just couldn't identify with that. They liked 34 00:04:55,240 --> 00:05:01,480 experimental music but they didn't like the framework around it and so we were like yeah against 35 00:05:01,480 --> 00:05:08,520 curation against like people trying to organize things we wanted to organize ourselves to do our 36 00:05:08,520 --> 00:05:13,320 own thing outside of the institutions this sort of thing. I think it never really happened as an 37 00:05:13,320 --> 00:05:21,160 actual impact let's say on the actual music culture I think no one cared but we had a lot of fun 38 00:05:21,240 --> 00:05:30,600 like doing it for ourselves and this is where it came from I think from this anti-academic context 39 00:05:31,800 --> 00:05:37,880 yeah and anti-institution context and so yeah we started just this like scene and festivals 40 00:05:37,880 --> 00:05:44,200 and used software to to allow us to organize in a way where there wouldn't be a centralized 41 00:05:44,200 --> 00:05:53,560 coordinator required which has so many parallels to today's world of admins and moderators and 42 00:05:53,560 --> 00:06:00,040 so forth so on and but I remember that you've told me before about this piece that you also were 43 00:06:00,040 --> 00:06:06,360 part of making which was a self organizing orchestra where people could like interact and be 44 00:06:06,360 --> 00:06:13,080 part of creating the music together but in a self organizing manner and yeah there's just 45 00:06:13,080 --> 00:06:21,800 something very beautiful about that in complexity theory it's called stigma but hey we're not going 46 00:06:21,800 --> 00:06:27,960 to dive into that right now but I think it's really cool and really beautiful how you've been 47 00:06:27,960 --> 00:06:34,920 part of self organizing systems or designing self organizing systems first in music and then with 48 00:06:34,920 --> 00:06:42,040 festivals and zines and now with peer-to-pop yeah exactly so we yeah we were like yeah at this time 49 00:06:42,040 --> 00:06:46,440 trying to build it build the software I mean we build it a couple of times so there was the first 50 00:06:46,440 --> 00:06:55,400 iteration in 2016 I think which was called 2015 maybe which was called for unwotung 3000 51 00:06:56,360 --> 00:07:02,680 which was built on ruby on rails actually and then the second iteration within a rebuild in 52 00:07:02,680 --> 00:07:09,720 Node.js and they both were like various centralized stacks and at this time for us it wasn't so important 53 00:07:09,720 --> 00:07:14,600 that the technology is like decentralized we were more interested in the mode of organizing on top 54 00:07:14,600 --> 00:07:21,800 of that but the more we did yeah sorry what made that what created a shift there why did you start 55 00:07:21,800 --> 00:07:28,440 caring I think us yeah I think you know like we've been we've been musicians and and you know 56 00:07:28,440 --> 00:07:34,680 festival organizers and I was studying musicology at this time I mean not really but I was playing 57 00:07:34,760 --> 00:07:39,080 in a lot of bands and I was surrounded by people from the experimental music scene in Berlin 58 00:07:39,800 --> 00:07:47,320 and we didn't know so much about hacker culture or computers or you know different software projects 59 00:07:47,320 --> 00:07:53,960 like I was I was mainly like a self taught programmer for fun and for a little bit of money on the 60 00:07:53,960 --> 00:08:03,800 site and and people around me were like no programmers at all mostly and we we just used technology 61 00:08:03,880 --> 00:08:11,640 as a way of formulating these ideas we have of organizing like and as a as a as also like as a 62 00:08:11,640 --> 00:08:20,040 propagation of like you can change the interfaces you can actually control or change how you 63 00:08:21,160 --> 00:08:26,600 how you call it the circumstances you are you are inside of like the framework around you like 64 00:08:26,600 --> 00:08:32,280 this was a little bit this sort of experimentation we had and and of course this is not you know this 65 00:08:32,280 --> 00:08:41,240 was a very utopian sort of thinking and power dynamics happen all the time and things can't 66 00:08:41,240 --> 00:08:45,880 be changed sometimes as well because you don't have the power to do it and I think for us this 67 00:08:45,880 --> 00:08:52,120 was just the means of like discussing these things and highlighting them what we can do and 68 00:08:52,840 --> 00:08:59,960 how we shift power dynamics by doing it in other directions and in other in in in other yeah like 69 00:09:00,040 --> 00:09:06,120 dynamics and yeah we use the magazine as a as a platform to discuss these things and these dynamics 70 00:09:06,120 --> 00:09:11,880 and and then we basically just use software development to express new ideas which came out of the 71 00:09:11,880 --> 00:09:17,880 discussions so it was kind of like a loop like a feedback feedback loop making software discussing 72 00:09:17,880 --> 00:09:23,960 like making software making a festival discussing the outcomes making a new software and so on. 73 00:09:24,040 --> 00:09:35,400 iterative learning um yeah that sounds lovely um it's bringing to mind like so it sounds like 74 00:09:35,400 --> 00:09:41,560 throughout these iterations you move from simply organizing well not simply because organizing 75 00:09:41,560 --> 00:09:48,440 is a big thing in and of itself but from organizing festivals and organizing in a self organizing 76 00:09:49,240 --> 00:09:55,960 to building self organizing technology how do you think that transition happened? 77 00:09:55,960 --> 00:10:01,080 yeah I think there's been two things happening at the same time I think one was us maybe radicalizing 78 00:10:01,080 --> 00:10:07,640 ourselves through this process um of thinking about these things and yeah um discussing these things 79 00:10:07,640 --> 00:10:14,760 and um and I think we also had an urge to leave the music scene a little bit because we got 80 00:10:14,840 --> 00:10:21,800 also maybe slightly bored of of it um and found out that there is a complete there's there are 81 00:10:21,800 --> 00:10:31,080 other spaces where this is being discussed since many many years um um and um uh yeah of course 82 00:10:31,080 --> 00:10:35,640 also the hacker scene um like whatever that means but like you know in computer culture 83 00:10:35,640 --> 00:10:41,720 decentralization and self organization has always been a thing and um I didn't know that at this 84 00:10:41,720 --> 00:10:47,480 point it was like a new thing and um that's like what we've been doing before already exist in 85 00:10:47,480 --> 00:10:54,520 other spaces and it's much better understood and I think at the same time Sam um who is still 86 00:10:55,640 --> 00:11:02,600 part of peer-to-panda like me um he um he was also part of the of these festivals and blood 87 00:11:02,760 --> 00:11:12,920 3000 and he um he just went to a workshop of the that protocol uh in trust in Berlin uh the trust 88 00:11:12,920 --> 00:11:17,960 space um and he just came back and was like oh my god I've seen something super cool you should 89 00:11:17,960 --> 00:11:24,760 check it out it really fits like um our thinking yeah and uh and then we were like whoa what is the 90 00:11:24,840 --> 00:11:31,000 that protocol and we were reading the websites inside out and um and then that led us to a 91 00:11:31,000 --> 00:11:37,240 secure scuttlebot um so yeah this is basically where it all started this whole rabbit hole and 92 00:11:37,240 --> 00:11:42,120 it was just us being fascinated wow this is like everything we talk about is already reflected 93 00:11:42,120 --> 00:11:47,960 here as well um and you were talking about how it would be cool to like hear this back in 20 years 94 00:11:48,120 --> 00:11:58,680 and here we are we're talking about that moment what is it 10 years ago and then look at y'all now 95 00:12:01,480 --> 00:12:06,680 yeah it's crazy it's really a little bit strange yeah and I think the as I said this this talk 96 00:12:06,680 --> 00:12:13,320 at CCC I think you've been there as well I remember talking to you afterwards um uh the talk is 97 00:12:13,320 --> 00:12:17,880 really like a weird time capsule as well like if you look at it you're like okay oh my god what is 98 00:12:17,880 --> 00:12:24,040 purter panel it doesn't make any sense before I see today yeah but it does make a bit of sense 99 00:12:24,040 --> 00:12:29,160 because if we also look at like right now you have tool kitty that has been built on purter panda 100 00:12:29,880 --> 00:12:36,360 and that is a direct continuation and a heritage from from I can't pronounce the German I'm sorry 101 00:12:36,360 --> 00:12:46,920 so I'm not gonna even try to butcher it yeah exactly yeah this is finally like um full circle coming 102 00:12:46,920 --> 00:12:52,680 back and building the software we wanted to build in this time you know so I was so keen on trying 103 00:12:52,680 --> 00:13:01,800 out tool kitty like a year ago and it kept being on the precipice of done uh where are you now 104 00:13:01,880 --> 00:13:09,720 with the tool kitty yeah it's a little bit of a sad story because um tool kitty was funded by 105 00:13:09,720 --> 00:13:15,560 the British government and this kicked it off the whole project which was amazing yeah and we were 106 00:13:15,560 --> 00:13:23,000 very ambitious pushing for something at least like proof of concept E problem is that um yeah 107 00:13:23,000 --> 00:13:28,840 half the team is like peer to panda core developers so we had a lot of other things to do after the 108 00:13:28,840 --> 00:13:35,160 grant was over and the other half are people who are coming from the yeah like the art the 109 00:13:35,160 --> 00:13:42,280 cultural scene and they are very dependent on money of course um so for them uh yeah and for us 110 00:13:42,280 --> 00:13:47,320 I mean we also dependent on money everyone is but uh it's nothing we can just like continue 111 00:13:47,320 --> 00:13:53,160 without any funding so the project was just stalled at this point and we couldn't get back to it 112 00:13:53,160 --> 00:14:00,760 um so yeah I think we left it in a we left it in a good place but um I think it's definitely not 113 00:14:00,760 --> 00:14:07,160 there where you can like really use it um we would need to yeah we basically need to continue with 114 00:14:07,160 --> 00:14:14,280 more funding and we have a grant we're still waiting for the answer so fingers crossed um so 115 00:14:14,280 --> 00:14:20,600 it's not over we're like we are definitely applying as much as we can for tool kitty also it's 116 00:14:20,600 --> 00:14:27,320 our favorite project um yeah obviously because it's really like the the heart of peer to panda let's say 117 00:14:28,040 --> 00:14:33,240 um so and we have a really beautiful team around it like everyone involved in it is just super 118 00:14:33,240 --> 00:14:38,680 nice and uh yeah it's just super nice to work together on it also slightly different than all our 119 00:14:38,680 --> 00:14:45,880 other peer to panda projects because it's the least technical let's say um so it's a really nice 120 00:14:45,960 --> 00:14:52,680 community yeah so um let's let's let's hope it's not over for sure but it's just yeah it's always like 121 00:14:52,680 --> 00:14:57,080 and the priorities are shifted through where the grants come from and for what yeah of course 122 00:15:04,680 --> 00:15:10,440 so one thing I was thinking about was now that we're talking about what you've been developing 123 00:15:10,440 --> 00:15:17,880 and uh tool kitty a direction that I've seen y'all going in which has been really cool to see 124 00:15:17,880 --> 00:15:22,680 is kind of a little bit more hands off on the that development of the applications that are 125 00:15:22,680 --> 00:15:29,160 building on peer to panda and focusing more on the core protocol development so the point of 126 00:15:29,160 --> 00:15:34,360 the question is first off can we do a little bit of a shout out because I saw that not all applications 127 00:15:34,360 --> 00:15:39,640 that are being built on peer to panda have been mentioned on the website so for those who are 128 00:15:39,640 --> 00:15:44,920 curious on what's being built on peer to panda what are like the active ones bubbling we got 129 00:15:44,920 --> 00:15:54,360 reflection we have dashchat um which is uh yeah like an encrypted messenger which also runs 130 00:15:54,360 --> 00:16:03,720 yeah without the internet and um and then we have jade's project um lore rest um which is like 131 00:16:03,720 --> 00:16:11,400 something like a it's more like a federated setup of community notes where people host their 132 00:16:11,400 --> 00:16:16,840 websites or build like applications for the community so this is more like a neighborhood's network 133 00:16:17,240 --> 00:16:23,960 um and it's it's it's also a little bit more low level like infrastructure for communities to 134 00:16:23,960 --> 00:16:31,400 build applications on top for example by sharing uh carpooling um message or it's these sorts of 135 00:16:31,400 --> 00:16:40,040 things um yeah it's really cool also like aiming at running on top of Laura as well um so I think 136 00:16:40,040 --> 00:16:46,440 this also plays with this idea of like every community has their own like backbone infrastructure 137 00:16:46,440 --> 00:16:54,920 of antennas and and maybe Wi-Fi um and these these communities can then yeah sink with each other 138 00:16:54,920 --> 00:17:05,720 across villages or neighborhoods um uh so this is the lore rest project um and um yeah and then 139 00:17:05,720 --> 00:17:11,960 in in the gnome community we have a couple of people who are active as well uh like we have um 140 00:17:11,960 --> 00:17:20,280 era which is a new calendar um which is basically a new calendar for the for the gnome 141 00:17:20,440 --> 00:17:28,840 and um yeah there's some experimental peer-to-panda sink built in now um this is similar to 142 00:17:28,840 --> 00:17:35,480 reflection so you have like text document sink but then this is now the calendar sink um also 143 00:17:35,480 --> 00:17:42,920 recently met someone who is doing the same for evolution which is like the lower level stack to 144 00:17:43,880 --> 00:17:51,080 um yeah represent calendar data I think if I and it's not my world but I think something like that 145 00:17:51,080 --> 00:17:57,560 and with this it allows also the current gnome calendar um we think it's just gnome calendar 146 00:17:57,560 --> 00:18:03,800 it's just called so that would already be two calendars um with peer-to-panda sink so this is ongoing 147 00:18:04,600 --> 00:18:11,960 um uh yeah and wow now I need to think um I think there's more um 148 00:18:12,760 --> 00:18:21,480 yeah yeah and if you think of more it's all good we can get back to them I'll add as many links as 149 00:18:21,480 --> 00:18:28,760 you provide me in the description anyways you mentioned this project that was building on the 150 00:18:28,760 --> 00:18:36,280 sink module you didn't call it the sink module but anyways this kind of ties back into a shift 151 00:18:36,360 --> 00:18:43,400 that's happened in the scene where previously we were building these monolithic protocols that were 152 00:18:43,400 --> 00:18:52,840 one size fit all and if it doesn't then fuck it we can't do anything about it so I'm curious here 153 00:18:53,640 --> 00:19:00,440 on your website you have listed a lot of the different modules you have and I'm just gonna 154 00:19:00,440 --> 00:19:10,760 go through them uh and read them out and so you got here peer-to-panda net peer-to-panda 155 00:19:10,760 --> 00:19:18,440 discovery sink blobs core store stream spaces encryption authentication and I'm wondering 156 00:19:18,520 --> 00:19:28,440 here like how modular is peer-to-panda and how easy is it to engage with this and also um 157 00:19:30,280 --> 00:19:39,800 what would you say is the essence of peer-to-panda in this yeah yeah I think it's um also maybe back 158 00:19:39,800 --> 00:19:44,760 to like where why we started peer-to-panda like the protocol actually I think we were like 159 00:19:44,760 --> 00:19:50,840 trying to build an application the catalog you know the festival app and it was too hard to do on 160 00:19:50,840 --> 00:19:58,520 scuttlebot at this time and then we basically gave ourselves the question okay how what would be 161 00:19:58,520 --> 00:20:04,600 necessary to build an application um and I think that always informs like what we do with peer-to-panda 162 00:20:04,600 --> 00:20:10,040 we we ask ourselves what is required to actually build an application uh like what are the 163 00:20:10,360 --> 00:20:16,120 what are the facilities and application developer would would reach for um if if they would do that 164 00:20:16,120 --> 00:20:22,360 and um we're also constantly in contact with application developers who give us feedback on the 165 00:20:22,360 --> 00:20:29,240 things they need and this is how we prioritize our our features let's say um but roughly I would say 166 00:20:29,240 --> 00:20:38,920 is like there's a group of people and they want to exchange data so whatever data I publish 167 00:20:39,560 --> 00:20:45,080 will also be received by everyone else in that group so this is the this is the main guarantee 168 00:20:45,080 --> 00:20:50,760 and uh now it gets a little bit more complicated because these people in this in this group 169 00:20:51,560 --> 00:20:57,880 uh in this in this group are maybe not online at the same time um and maybe even worse they might 170 00:20:57,880 --> 00:21:03,480 not use the internet they might use something else um to talk to each other maybe bluetooth or 171 00:21:04,360 --> 00:21:14,280 yeah a usb stick or amateur amateur radio like ham radio um and or the internet is very flaky or 172 00:21:14,280 --> 00:21:23,320 you know or like very slow and so on so but peer-to-panda I mean it's aiming at solving that whatever 173 00:21:23,320 --> 00:21:29,160 you send into this group it will eventually arrive to all of these people despite all of these 174 00:21:29,160 --> 00:21:33,720 yeah connectivity issues or different sorts of ways to connect to each other so this is the 175 00:21:33,720 --> 00:21:38,920 first thing and I would say that's like sync um you know like we make sure that data syncs 176 00:21:39,720 --> 00:21:46,280 to all of these people independent of like how how how the connectivity is done and how how 177 00:21:46,280 --> 00:21:52,360 how much online you are um and then the next problem we are trying to solve is to do this 178 00:21:52,440 --> 00:21:59,080 confidentially so it's actually like secure to send that data and no one else can read it um 179 00:21:59,080 --> 00:22:04,440 so no one no one outside of that group will be able to read this data I think this is another big 180 00:22:04,440 --> 00:22:09,640 priority for us so so that whatever you're sending now into this group is like confidential for 181 00:22:09,640 --> 00:22:15,640 only people who are in the group and this is easy to do on the internet but very hard to do in 182 00:22:15,640 --> 00:22:22,360 mesh networks for example or um networks where you have intermediaries like maybe you and me are 183 00:22:22,360 --> 00:22:28,360 in a group but uh you are very far away and I need like five other people in between you and me 184 00:22:28,360 --> 00:22:34,600 to get that data across but still I want only you to read this data and not these people in between us 185 00:22:34,600 --> 00:22:41,560 and um so we are we can use other intermediaries to deliver that data but they should never be able 186 00:22:41,560 --> 00:22:47,640 to read this communication or tap into it or change it so this is the whole end-to-end encryption 187 00:22:47,640 --> 00:22:53,960 part of peer-to-panda is this also where I wrote it or is it more separate more like in offline 188 00:22:53,960 --> 00:23:01,080 scenarios yeah this is it's both I wrote gives us um transport encryption so you know they're 189 00:23:01,080 --> 00:23:08,520 using TLS on top of quick which allows us to to have a you know direct communication going on 190 00:23:08,600 --> 00:23:15,080 like a direct connection and this this one is confidential between you and me um but this implies 191 00:23:15,080 --> 00:23:21,640 that there is a connection right um and whenever we can't have that sort of like setting which is 192 00:23:21,640 --> 00:23:27,800 again as I said like in in like um more mesh network scenarios for example or like broadcast um 193 00:23:28,920 --> 00:23:35,960 broadcasts uh transports like like packet radio or Laura um or Bluetooth advertisements then we 194 00:23:36,040 --> 00:23:40,840 just can't assume that there is a connection we just scream into the void and hope that someone 195 00:23:40,840 --> 00:23:47,480 is listening um but at the same time whatever we scream or say should be confidential right you don't 196 00:23:47,480 --> 00:23:54,040 want anybody to listen to that either um so this is where we have to leave the iro world or the 197 00:23:54,040 --> 00:24:00,040 like the TLS world and and bring our own solution so what we have is like a key agreement scheme 198 00:24:00,680 --> 00:24:08,680 for groups which uh works yeah without any assumption of a connection or being online and so on 199 00:24:08,680 --> 00:24:15,160 is this peer to panda spaces exactly uh so i mean the key agreement itself is peer to panda encryption 200 00:24:16,200 --> 00:24:23,240 um but now you need to know to whom do i encrypt data and who is in the group this is what we call 201 00:24:23,240 --> 00:24:27,640 like uh uh yeah like a group management you know i need to add someone into the group i need to 202 00:24:27,640 --> 00:24:33,560 remove them and this is solved with peer to panda off and that's a CRDT we've built which allows 203 00:24:33,560 --> 00:24:39,560 you to add people into a group yeah remove them change their like privileges maybe like make them 204 00:24:39,560 --> 00:24:44,680 from admin to like someone who has only right access or only read access and then uh it gets even 205 00:24:44,680 --> 00:24:51,400 more complicated because you cannot only add people but also groups again so a group can be made 206 00:24:52,280 --> 00:24:59,560 out of groups so uh and that allows us to uh also like have things like multi-device settings where 207 00:24:59,560 --> 00:25:06,200 maybe you as sanner you are a group and you have multiple devices in your group you know you have a 208 00:25:06,200 --> 00:25:11,560 smartphone you have your laptop you have your desktop computer these are three members in your group 209 00:25:11,560 --> 00:25:17,880 you know and on my end i am uh Andrea so a dc and i have the same i have a smartphone in the laptop 210 00:25:17,960 --> 00:25:23,800 and so therefore i have two members in my group but now i'm adding you uh like your group to my 211 00:25:23,800 --> 00:25:29,640 document you know and this is like no indirectly or yeah like transitively all of your three devices 212 00:25:29,640 --> 00:25:35,560 will now also have access to that document um and i'm still encrypting to all your devices like to your 213 00:25:35,560 --> 00:25:39,880 smartphone individually to your laptop and to your desktop so it's like encrypted individually for 214 00:25:39,880 --> 00:25:44,520 these devices but yeah we now we have that awareness that you know this should be done like that 215 00:25:44,520 --> 00:25:50,680 this is this like nested nested group management thing and we built a CRDT for that it's yeah 216 00:25:50,680 --> 00:25:57,880 mostly work of sam as well as a pretty pretty crazy work um to make that happen and um the combination 217 00:25:57,880 --> 00:26:06,120 of this CRDT and the key agreement scheme is then what we call spaces so a space is a place where we 218 00:26:06,120 --> 00:26:13,560 can have um key agreement for confidential yeah message exchange encrypted confidential message 219 00:26:13,560 --> 00:26:21,320 exchange towards a group which was managed by that CRDT this is so cool to hear because like 220 00:26:21,320 --> 00:26:29,880 back in the day back in the day but back in the day this was one of the huge challenges for us to 221 00:26:29,880 --> 00:26:39,160 solve just making a group and now you all got groups within groups nested groups yeah and it's 222 00:26:39,240 --> 00:26:44,280 i think like and then maybe like the the last pillar of of peer-to-panel i already kind of 223 00:26:44,280 --> 00:26:51,720 mentioned but if i say like yeah you know deliver messages to a group um make that confidential then 224 00:26:51,720 --> 00:26:59,400 i would say the third thing is access control so who is allowed to do what um and this is something 225 00:26:59,400 --> 00:27:06,040 application developers always want um you know they they want a way to describe you are allowed 226 00:27:06,040 --> 00:27:11,480 to read this document but you're not allowed to change it um you know things like that um and 227 00:27:12,200 --> 00:27:18,120 and this is indirectly handled with this CRDT as well um i just mentioned so so but i think 228 00:27:18,600 --> 00:27:26,600 with this is we already kind of describe peer-to-panel and um and so we we don't dictate what sort 229 00:27:26,600 --> 00:27:32,280 of data you're sending we only try to make sure it is done in a secure way and in a robust way 230 00:27:32,360 --> 00:27:39,640 on top of any transport um and that's what you mentioned because uh i watched your talk 231 00:27:39,640 --> 00:27:45,080 at least as much as i could it kept cutting out uh but your talk it faws them and you were talking 232 00:27:45,080 --> 00:27:52,840 about base convergent data types and you were mentioning how you could sync DAGs over for example 233 00:27:52,840 --> 00:28:00,760 append only logs um so what you're talking about right now it sounds like is that it's agnostic 234 00:28:00,760 --> 00:28:07,560 what the data type is and it's more about what how you send it is that what you mean when you say 235 00:28:07,560 --> 00:28:15,720 base convergent data types right yeah no it's exactly that yeah it's so so yeah the base 236 00:28:15,720 --> 00:28:21,400 convergent data type that's i mean that's that's an attempt to find the definition for this 237 00:28:21,400 --> 00:28:28,520 for this thing um uh where you know a bunch of people were involved in trying to find out how to 238 00:28:28,680 --> 00:28:35,400 name these things but i think the underlying the underlying question here is um and i think this 239 00:28:35,400 --> 00:28:41,000 has been mentioned a couple of times also in the past it's like this sort of like universal sync idea 240 00:28:41,000 --> 00:28:54,200 like is there something like a sync approach where we can deliver data of any kind um and i think 241 00:28:54,280 --> 00:28:59,880 right now in our thinking we would say that's not possible that doesn't really exist like i think 242 00:29:00,440 --> 00:29:06,280 there's still some sync protocols which make more sense for certain kind of data i would say 243 00:29:06,280 --> 00:29:12,760 specifically files should be synced in other ways um you know the willow folks have another 244 00:29:12,760 --> 00:29:20,120 approach which i think also makes sense for for uh yeah for files or for like um um yeah 245 00:29:20,120 --> 00:29:27,640 certain CRDTs but like i think still there is this sort of um challenge to try to express um 246 00:29:28,440 --> 00:29:34,760 like a like a basic element which is um uh allowing you to sync 247 00:29:36,120 --> 00:29:41,960 yeah as much different types of applications as possible and this is a little bit the role of the 248 00:29:41,960 --> 00:29:46,760 base convergent data type and also like what we try to solve with peer to panel because we try to be 249 00:29:46,840 --> 00:29:51,960 like as flexible as possible um because we don't have we're building for certain kinds of 250 00:29:51,960 --> 00:29:57,400 applications with certain guarantees but still there's a wide range in that and um um 251 00:29:58,360 --> 00:30:03,480 and then another thing which is interesting about this you know this data type this core data type 252 00:30:03,480 --> 00:30:10,520 is that um um there is different ways to interpret it as well um so if you look at the classic 253 00:30:11,080 --> 00:30:17,960 internet stack then you know while we are talking right now and this this this audio stream 254 00:30:17,960 --> 00:30:24,120 across our computers there is like there is one core layer underneath all of this and this is the 255 00:30:24,120 --> 00:30:31,400 IP layer um and on the IP layer there's something which is called the datagram um and you know 256 00:30:31,400 --> 00:30:36,920 that's the that's the core unit of what is being sent over the internet and then we express protocols 257 00:30:37,000 --> 00:30:43,240 on top of that on top of ip we have udp and on top of udp we have quick on on top of quick we 258 00:30:43,240 --> 00:30:49,640 have tls and then on top of tls we have signal um and then on top of signal we probably have also 259 00:30:49,640 --> 00:30:55,320 custom audio protocol they've built um so you know this is the this is this whole like stacking of like 260 00:30:56,920 --> 00:31:03,800 protocols and now you would say oh no Andreas you sound like a OSI layer sort of person you know 261 00:31:03,800 --> 00:31:07,880 which never really worked um but this is not what i mean i just want to say there is like 262 00:31:07,880 --> 00:31:12,440 the separation of concerns where you know different parts of the system handling are different 263 00:31:12,440 --> 00:31:18,120 different things and uh the base conversion data type is the thing which handles 264 00:31:20,040 --> 00:31:26,600 just making sure that the data arrived um on top of different transport um similar like the 265 00:31:26,680 --> 00:31:33,560 ip packet was just made to make sure that data was routed to the right computer um so i would 266 00:31:33,560 --> 00:31:39,400 say like the the the the the base conversion data type is a is a data type which can be sent over 267 00:31:39,400 --> 00:31:46,040 any transport it uh is authenticated um so it has like you know we have some sort of like idea 268 00:31:46,040 --> 00:31:50,760 who send it it can't be tempered with when it is going through intermediaries so it's like 269 00:31:50,840 --> 00:31:57,720 has integrity and um it has this quality of converging this is what convergent part of it is 270 00:31:57,720 --> 00:32:03,240 which basically means when peers observe the same data flowing in over time then they will 271 00:32:03,240 --> 00:32:08,440 converge to the same state and that's the quality we always want to have in peer-to-peer systems 272 00:32:08,440 --> 00:32:15,080 of this kind um you know just to clarify here and this is going to sound like a stupid question 273 00:32:15,080 --> 00:32:21,320 but when you say base convergent data type you mean the concept that has these qualities 274 00:32:21,320 --> 00:32:27,560 and these it's an abstraction that a bunch of different things can fit into or is it a specific 275 00:32:27,560 --> 00:32:34,200 data type it's a concept it's an abstract thing yeah and um i i think like so far from conversations 276 00:32:34,200 --> 00:32:40,680 with people i think we can also name them concretely i think like a typical base conversion data type 277 00:32:41,240 --> 00:32:46,760 is a is a last-right-winds range that would be like for example what willow does you could have 278 00:32:47,560 --> 00:32:54,440 directed aciclet graph um this is you know what hyperhyperspace does for example um or like subduction 279 00:32:55,640 --> 00:33:00,920 and if you know from the auto-merge people then you can have a panda only locks this is like what 280 00:33:00,920 --> 00:33:07,640 peer-to-panda is doing or like tiny ssb and you or you can have grow only sets um which i don't 281 00:33:07,800 --> 00:33:13,400 know if anyone is doing maybe nostru actually nostru is a grow only set i would say you know and these 282 00:33:13,400 --> 00:33:18,920 are all like base convergent data types i would say these are all like these ip packets uh in a way 283 00:33:18,920 --> 00:33:25,560 all of these like core data types which can deliver so much more uh which can be expressed on top 284 00:33:25,560 --> 00:33:30,760 of that and i think what we are trying to do with this sort of like framing is just yeah try to push 285 00:33:30,760 --> 00:33:35,880 a little bit the discussion into uh into this thing of like not everything needs to be expressed in 286 00:33:35,880 --> 00:33:41,720 this one data type you can compose functionality on top of that rather than trying to make this data 287 00:33:41,720 --> 00:33:47,800 type super powerful i think there's been a fascination in the past for like trying to make exactly 288 00:33:47,800 --> 00:33:54,440 that data type like solve everything and um i think we realized it maybe doesn't need to it can be 289 00:33:54,440 --> 00:34:01,320 extended on top of that similar like how an ip packet was then extended with udp and or tcp and 290 00:34:01,960 --> 00:34:07,320 this is a little bit the like let's say the provocation in that direction and it's great that you 291 00:34:07,320 --> 00:34:15,480 mention this because a provocation doesn't happen in nowhere it happens in a collective space and 292 00:34:16,200 --> 00:34:22,120 what you're talking about now is terminology that's been built in many conversations among many 293 00:34:22,120 --> 00:34:28,840 different parts and before we dive into append only logs and grow only sets because i'm a little 294 00:34:28,920 --> 00:34:36,440 bit curious about that um i would actually like to dive into your history and your engagement with 295 00:34:36,440 --> 00:34:44,760 communities and a process of curating conversations you've been part of the Basel meetups you've been 296 00:34:44,760 --> 00:34:51,160 part of the dweb meetups you've been part of local meetups at offline space and you were part of 297 00:34:51,160 --> 00:34:58,440 starting offline space throughout this you've also often talked about the importance of terminology 298 00:34:58,520 --> 00:35:09,160 so first off um i would like to get your uh permission to throw out some terms and get your feedback 299 00:35:09,160 --> 00:35:20,600 on them and then uh we see where we go from that is that okay yeah sure okay i'll see yeah yeah 300 00:35:20,600 --> 00:35:31,320 all right that's a fun game so we've already covered based convergent data types 301 00:35:31,960 --> 00:35:40,440 and you mentioned stacks before so how about the walkaway stack what's your quick elevator pitch 302 00:35:40,440 --> 00:35:47,720 on defining the walkaway stack that's just um what i said before with data arrives for a group 303 00:35:47,800 --> 00:35:55,640 independent of what is the um transport or like the the connectivity substrate 304 00:35:55,640 --> 00:36:03,480 underneath exactly that's another term exactly and that was going to be my next turn so what is 305 00:36:03,480 --> 00:36:11,720 connectivity substrate yeah it's like what makes us connect you know like a cable or usb 306 00:36:11,720 --> 00:36:18,600 stick or uh radio waves or um yeah this weird thing we call internet um because this is 307 00:36:18,600 --> 00:36:24,440 somewhere where i start getting confused uh when you say event delivery layer what do you mean by that 308 00:36:25,800 --> 00:36:33,480 yeah so this is like trying to separate again um like problems and concerns into into two 309 00:36:33,480 --> 00:36:39,880 different areas we have to event delivery and the event processing um and event delivery is 310 00:36:40,520 --> 00:36:45,240 basically a problem space where we are concerned with how do we connect to each other 311 00:36:46,040 --> 00:36:52,280 or like even were even before like how do we find each other um how do we connect to each other how 312 00:36:52,280 --> 00:36:59,880 do we establish a connection um if there's no connection how do we deliver the data anyway exactly 313 00:36:59,880 --> 00:37:07,000 peer discovery these things um but also like hole punching um you know like signaling um then 314 00:37:07,080 --> 00:37:13,400 relay fallbacks everything like aerosols for us these days um you know all of these things um 315 00:37:14,200 --> 00:37:21,240 and then sync uh we know which is another massive space uh to explore i just mentioned like you know 316 00:37:21,240 --> 00:37:27,480 that all of these ideas on how sync protocols can go about and um how they can be optimized for 317 00:37:27,480 --> 00:37:33,560 certain data types and so on um so this is the big space of event delivery so just like 318 00:37:34,200 --> 00:37:43,000 somehow your data arrives um yeah you know from other people um and we call this event um just to 319 00:37:43,560 --> 00:37:52,520 yeah i think it comes from event sourcing and um a little bit but also like to maybe really stay 320 00:37:52,520 --> 00:37:58,680 as abstract as possible you could also call it a message or data you know data delivery or message 321 00:37:58,680 --> 00:38:05,480 delivery um okay so now you you got your message delivered it somehow arrives but now you 322 00:38:05,480 --> 00:38:11,640 want to make sense of that message um you want to you want to process it so you look at it and you 323 00:38:11,640 --> 00:38:17,720 start extracting information from it um and knowledge um for example that message contains that 324 00:38:17,720 --> 00:38:22,760 information that you've been added to a group you know this is something i need to process now i 325 00:38:22,760 --> 00:38:28,440 need to change my group state and my key agreement state i need to know um you know 326 00:38:28,840 --> 00:38:36,280 maybe rotate a key or um you know like um make you aware of that key um so this is all processing 327 00:38:37,160 --> 00:38:41,880 and this is usually where we are entering more application layer like things and application 328 00:38:41,880 --> 00:38:49,800 wants to do with that data it got through the event delivery and um and the processing part is 329 00:38:49,800 --> 00:38:54,360 quite interesting because this is where like yeah things get a little bit more let's say custom 330 00:38:54,360 --> 00:39:00,520 you know different applications might need different ways of processing things some some 331 00:39:00,520 --> 00:39:08,600 want to look um you know um process um uh peer-to-panda encryption stuff some others want to maybe 332 00:39:08,600 --> 00:39:13,880 do auto merge um you know because they're building a text editor and um there's like different ways 333 00:39:13,880 --> 00:39:19,480 of processing that information these these events and um so i think this is basically like the 334 00:39:19,560 --> 00:39:24,440 separation of these two worlds and i think by separating that it also allows us to 335 00:39:25,640 --> 00:39:32,920 write software in a way where it is actually like walkaway meaning if you have that processing part 336 00:39:32,920 --> 00:39:37,800 separated in a completely different space then where that data came from doesn't matter 337 00:39:38,760 --> 00:39:44,600 and therefore it can always be swapped out how the data comes to you um you know which is 338 00:39:44,600 --> 00:39:49,960 important for walkaway that's a quality we want to always have so if one day the internet goes 339 00:39:49,960 --> 00:39:57,560 down you can still use your application because it didn't matter where the data came from um and 340 00:39:57,560 --> 00:40:05,960 all what transport it arrived to you so it's more like uh it's it's almost like uh um yeah like uh 341 00:40:05,960 --> 00:40:13,160 like a check um like a self-check like uh uh yeah like a corrective we always have for ourselves 342 00:40:13,160 --> 00:40:18,120 so whenever we write it code we always make sure that this is never violated this sort of 343 00:40:18,120 --> 00:40:24,440 guarantee this sort of separation yeah that's really cool to hear and i think that would be 344 00:40:24,440 --> 00:40:33,160 interesting for other protocol developers to take note of as well um so and we could totally dive 345 00:40:33,160 --> 00:40:40,200 into that as a rabbit hole just like there's many other things we could also dive into like for 346 00:40:40,200 --> 00:40:45,240 example i've been thinking about this whole thing of the terminology and why it's important and 347 00:40:45,240 --> 00:40:53,160 we touched on that in past conversations briefly but yeah i'm not gonna get distracted and instead 348 00:40:53,160 --> 00:41:05,720 i'm gonna hold my tongue and bite it and circle back to um data types and uh you mentioned before 349 00:41:05,720 --> 00:41:14,440 that peer-to-panda uses append-only logs and just as recently as this last summer there was a 350 00:41:14,440 --> 00:41:23,320 really interesting discussion between or conversation uh that you moderated between uh aliyoshi and 351 00:41:23,320 --> 00:41:31,800 samti on data types and i'm curious to hear your thoughts on this and whenever the video comes 352 00:41:31,800 --> 00:41:38,760 online i'll link it in the description but i'm also curious to hear your thoughts on append-only 353 00:41:38,760 --> 00:41:45,640 logs and then i have a follow-up question from something uh power source asked me before this 354 00:41:45,640 --> 00:41:52,680 conversation actually wow cool okay wow there's a lot there yeah okay so first question 355 00:41:53,400 --> 00:42:01,160 how i what i think about the discussion between aliyoshi and samtiago um so hyperhyperspace the protocol 356 00:42:01,160 --> 00:42:09,080 of samti um actually uses uh DAX um i always thought it was append-only logs but it is uh like 357 00:42:09,800 --> 00:42:16,040 actual DAX i think he changed over time what is the the core data type there but um and that's 358 00:42:16,040 --> 00:42:23,320 directed acyclic graphs yeah exactly and exactly and aliyoshi is like you know a big fan of 359 00:42:24,280 --> 00:42:33,000 like last right wins wins key value ranges um and the big difference with these is 360 00:42:34,600 --> 00:42:40,840 you know you have to imagine whatever you put in a key value store whatever was there before is gone 361 00:42:40,840 --> 00:42:46,840 you kind of overwrite what was there before and that says some nice qualities because you know 362 00:42:46,840 --> 00:42:53,240 you can be sure it's deleted forever at least from your computer um it makes it very simple you 363 00:42:53,240 --> 00:42:57,560 don't have to mess with like more than just like put it in a slot and you know and then it's there 364 00:42:57,560 --> 00:43:05,000 and whatever whatever was there before is gone um while a DAX or an append-only log has this notion 365 00:43:05,000 --> 00:43:11,000 of a history so you append something to it and what was there before stays right you just append on 366 00:43:11,000 --> 00:43:19,720 top of it um and this has pros and cons um the thing is uh whenever you need history 367 00:43:20,680 --> 00:43:26,600 then obviously a DAX and an append-only log is so much better because um if you need that on top 368 00:43:26,600 --> 00:43:32,600 of a key value range then you're basically building a DAX on top of that so you would start like 369 00:43:32,600 --> 00:43:39,480 pushing a DAX into that key value store um you know it would sit if you would basically have 370 00:43:39,480 --> 00:43:46,840 the whole thing and then the whole blob would just be moved into one slot um and um uh you know 371 00:43:46,840 --> 00:43:53,320 that's not very nice um and why would we want to have history it really depends on the application 372 00:43:53,320 --> 00:43:59,080 but i think um yeah there can be reasons where you maybe need to like go back in time and and and do 373 00:43:59,080 --> 00:44:05,880 something again and that usually comes for example for certain moderation scenarios you know someone 374 00:44:05,880 --> 00:44:14,360 has been writing something and concurrently uh they've been removed from the group uh now you 375 00:44:14,360 --> 00:44:20,520 maybe want to go back into that data type and going back into the past and remove these edits um 376 00:44:21,560 --> 00:44:27,400 you know that will be harder to do if you don't have history um another thing where it's important 377 00:44:27,400 --> 00:44:34,360 is maybe um yeah bucentine fault tolerance so um we uh we need sometimes the past because we need 378 00:44:34,360 --> 00:44:40,520 to understand where did someone come from what rights did they have in that moment um in the past 379 00:44:40,520 --> 00:44:45,400 and was that violated somehow um these these things are important to understand 380 00:44:45,400 --> 00:44:52,680 to to build certain uh security measures and and and and like bucentine fault tolerance measures um 381 00:44:53,640 --> 00:45:01,240 so i think i think the the the willow folks they always call this like fancy CRDTs um or like yeah 382 00:45:01,240 --> 00:45:04,840 and i think they're not very big fans of that and i think they have a really good point of 383 00:45:05,560 --> 00:45:10,680 of um doing that because it's true that you can build a lot of things with very little 384 00:45:11,480 --> 00:45:19,720 um but i think there's also space for you know history um because there's a lot of peer-to-peer 385 00:45:19,720 --> 00:45:25,480 problems we can only solve with that um and um so yeah i think it's it's like it's like it's 386 00:45:25,480 --> 00:45:33,320 basically like a choice one needs to make when building an application and um and um um i think 387 00:45:33,400 --> 00:45:36,760 we're just similar maybe to the terminology question you try to avoid 388 00:45:38,760 --> 00:45:42,200 you know i think we should we should we we we we we start to just get better at like 389 00:45:42,200 --> 00:45:47,480 describing these pros and cons maybe and and the requirements our applications need 390 00:45:47,480 --> 00:45:51,640 and then maybe one day we can actually communicate that very well to application developers 391 00:45:52,280 --> 00:45:57,240 and maybe there's a culture of application developers emerging we start to uh you know 392 00:45:57,240 --> 00:46:02,840 communicate these things to each other in a way where you know it will not be a question anymore 393 00:46:02,840 --> 00:46:09,320 you just take that or that based on what you need to build um i think that's such a beautiful and 394 00:46:09,320 --> 00:46:16,680 succinct summary of the conversation and the conclusions one can draw from it and it makes me think 395 00:46:16,680 --> 00:46:26,280 of uh silo was was there uh d webcamp and uh they're trying to build this like atomic referencing 396 00:46:27,160 --> 00:46:35,800 where you can reference also like down to specific sentences or tables etc and they're trying to 397 00:46:35,800 --> 00:46:44,120 do it and appear to appear way right now is not completely but still um this kind of scenario is 398 00:46:44,120 --> 00:46:51,960 where DAGs would be super relevant uh especially with like the whole history and being able to see 399 00:46:52,040 --> 00:46:57,640 the modifications that have been made but at the same time privacy is not great in those kind of 400 00:46:57,640 --> 00:47:05,720 systems um like aliasha pointed out uh from willow uh you want to be able to delete things for privacy 401 00:47:05,720 --> 00:47:13,160 and especially like the metadata as me and aliasha talked about in uh the episode as well um 402 00:47:14,200 --> 00:47:21,400 so the question i got from power source is related here as power source was wondering 403 00:47:21,400 --> 00:47:28,200 how you deal with deletion in peer-to-panda and i know you have dash chat and i'm wondering 404 00:47:28,200 --> 00:47:35,640 a bit how do you relate to it what what um guidance and security advice do you give for people who 405 00:47:35,640 --> 00:47:43,560 are building communication means over peer-to-panda yeah so you know like i mean um there is i think 406 00:47:43,560 --> 00:47:48,680 there's a couple of like uh things around append only locks which are usually criticized the first one 407 00:47:48,680 --> 00:47:55,640 is um you know you can't delete it it's append only it just grows forever it starts wasting your 408 00:47:55,640 --> 00:48:03,160 your hard disk space and then your computer crashes um the other one is uh yeah it forks so suddenly 409 00:48:03,160 --> 00:48:08,600 you you you broke like your eventual consistency guarantee because there's two versions of the same 410 00:48:08,600 --> 00:48:14,280 lock and depending on with whom i think what they're gonna see different things um all of this we know 411 00:48:14,280 --> 00:48:22,200 from secure scuttlebot um um and the third one is like yeah and partial sync um all of these 412 00:48:22,200 --> 00:48:27,000 like i just want to have a part of the lock without breaking its whole integrity and so on and um 413 00:48:27,960 --> 00:48:33,560 peer-to-panda addresses all of these things so um obviously we just didn't take the scuttlebot model 414 00:48:33,560 --> 00:48:40,680 and um went for that without like learning from the from the you know the bad parts of it um 415 00:48:41,480 --> 00:48:49,960 so uh like in peer-to-panda you can prune a lock at any time so if your lock grows to a point 416 00:48:51,160 --> 00:48:57,400 where you don't need that information anymore you can just say please delete everything 417 00:48:58,440 --> 00:49:03,960 from here on um it's like it's like a it's like a flag you're raising and you just say whoever 418 00:49:03,960 --> 00:49:09,960 observes this lock now from sequence number 17 you can delete everything which was published before 419 00:49:10,840 --> 00:49:19,000 that point and so you could be really um like um uh like as a provocative example you could say 420 00:49:19,000 --> 00:49:26,280 prune your lock always at sequence num like as soon as it reached a length of one you know um like 421 00:49:26,280 --> 00:49:31,640 as soon as your lock has the length of one just delete everything and then you're basically back at 422 00:49:31,640 --> 00:49:39,240 willow now you are in in in a pentony lock which has no history um and that's possible to express 423 00:49:39,240 --> 00:49:45,000 with peer-to-panda we can say our lock never grows beyond one item um and when it does it just 424 00:49:45,000 --> 00:49:50,600 gets pruned um so now you're you're back in no history world and we can still do that on top of 425 00:49:50,600 --> 00:49:57,480 a pentony locks um i wonder what al-Yosha would think about this description i think he would say 426 00:49:57,480 --> 00:50:03,880 then yeah this is like it doesn't have ranges and whatnot i mean of course um there is like yeah 427 00:50:03,880 --> 00:50:07,240 there is like different things but i just want to say in terms of privacy we're back in the same 428 00:50:07,240 --> 00:50:15,560 guarantees actually um yeah and um um so this is one nice thing we can do and uh what we basically 429 00:50:15,560 --> 00:50:21,880 say is again is up to the application to decide when they want to prune um so this is one thing 430 00:50:21,880 --> 00:50:29,720 another thing is um we separate the actual payload from the lock integrity part so when someone 431 00:50:29,720 --> 00:50:38,200 sends a message uh that message is you know hello sennah and that message is protected by 432 00:50:38,200 --> 00:50:43,480 you know like the signature and you know like the backlink and all of the you know a pentony lock 433 00:50:43,480 --> 00:50:49,240 things but we can always delete this uh payload uh without breaking the lock integrity 434 00:50:49,880 --> 00:50:55,080 that's kind of like a you know soft delete where you just say okay whatever message was delivered 435 00:50:55,160 --> 00:51:00,520 let's just remove that message we also call this off chain uh like the data is not on the chain 436 00:51:00,520 --> 00:51:05,320 on the hash chain um it's it's it's like expressed outside of that and independent 437 00:51:05,320 --> 00:51:10,120 it's still protected the integrity but we can delete it without affecting that integrity 438 00:51:10,840 --> 00:51:17,000 and um so this is another nice thing uh developers can do um if they if they just want to want 439 00:51:17,000 --> 00:51:22,600 some content to be gone and uh you know the metadata is you know they're fine with the metadata 440 00:51:22,680 --> 00:51:29,960 being around um and um yeah and then i think the last thing the forking uh this is you know like 441 00:51:29,960 --> 00:51:36,840 that's that's another thing so our appendony locks day they are they can be forked um we don't 442 00:51:36,840 --> 00:51:43,160 recommend it i mean it's uh you know they're more efficient when they're not forked uh but if 443 00:51:43,160 --> 00:51:49,720 they are forked by accident um for example they will not break then basically have like mitigations 444 00:51:49,800 --> 00:51:56,840 to like to like detect that and and and be fine with that um and um and that also allows you 445 00:51:56,840 --> 00:52:03,400 actually to by detecting that that now allows you also to like look into business and fault tolerance 446 00:52:04,040 --> 00:52:10,040 uh systems because a fork can be now considered you know let malicious acting and we might want to 447 00:52:10,040 --> 00:52:15,640 record that event um this is like research some people in basal are doing uh we're not so 448 00:52:15,640 --> 00:52:19,400 interested in that but you know these are like suddenly features which arise from this sort of thing 449 00:52:19,400 --> 00:52:24,520 and then yeah and then the the other thing not everything is written in one lock so it's not like 450 00:52:24,520 --> 00:52:28,920 in scuttlebutt where like everything you would do is like written in one massive big lock so 451 00:52:28,920 --> 00:52:33,800 in peter pandan we can write as many locks as we want at the same time and usually 452 00:52:34,680 --> 00:52:40,200 they're very small so i think we rarely have seen applications having like locks longer than 453 00:52:40,200 --> 00:52:47,800 100 items um it's usually something between one and 10 or 15 um oh wow yeah so you know like i think 454 00:52:47,800 --> 00:52:52,520 just like long locks sort of thing is a quite um yeah it's a quite um thing of the past 455 00:52:53,240 --> 00:52:57,880 thing of the past yeah we don't really observe that so much anymore yeah that's great to hear 456 00:52:59,880 --> 00:53:05,480 that's what crash my computer and then you can and then you can also delete whole locks right so 457 00:53:05,480 --> 00:53:11,160 when you start now having many locks then you can have like yeah you can also just delete the whole 458 00:53:11,640 --> 00:53:18,440 and that's totally fine and also similar you can also express locks in in sorts of groups and then 459 00:53:18,440 --> 00:53:25,560 we can say delete everything in that group so then all the locks will be gone um which is you know 460 00:53:25,560 --> 00:53:35,880 like a nice thing as well now we're actually nearing time oh it went so fast um yeah i really did 461 00:53:36,120 --> 00:53:45,720 i still actually have a few questions so first up modal what's up what's the gas 462 00:53:49,320 --> 00:53:56,440 yeah um so yeah we just had an boiling the ocean event in Berlin that was really nice um so we 463 00:53:56,440 --> 00:54:02,520 have been been meeting great people and and hacking on reflection and other things that was 464 00:54:02,520 --> 00:54:08,120 really cool there was someone who brought like NFC to the table which was fun to like look into 465 00:54:10,280 --> 00:54:16,920 and um yeah um i think the next boiling the ocean is happening soon after the all systems go 466 00:54:16,920 --> 00:54:23,320 conference um i don't ask me about dates right now i think it's October um we'll link it in the 467 00:54:23,320 --> 00:54:29,880 description yeah and another big thing which happens um it's been brewing for a while but now 468 00:54:29,880 --> 00:54:36,520 finally it's official is that modal got a sovereign tech fund grant of half a million euros 469 00:54:39,880 --> 00:54:44,440 yeah this is pretty cool and there's a like amazing team like working on that like 470 00:54:45,320 --> 00:54:52,680 Adrian and Sebastian for example from modal and Kate is also involved in the administrative parts 471 00:54:52,680 --> 00:55:02,120 and and Katarina and um yeah this is a very big grant for flat pack and portals work um and that 472 00:55:02,120 --> 00:55:06,840 indirectly affects peer to panda like it's not really a peer to peer grant unfortunately 473 00:55:09,160 --> 00:55:15,480 but it is uh it is still cool because this all is like work towards you know this whole host 474 00:55:15,480 --> 00:55:21,880 environment question of like how can we bring peer to peer UX and UI patterns and components 475 00:55:21,880 --> 00:55:27,640 into the operating system yeah and portals will be a very big part of that so like how do you 476 00:55:27,640 --> 00:55:35,000 ask for access to uh share data with someone or you know um to your uh contacts and so on 477 00:55:35,000 --> 00:55:40,200 so indirectly there will be some work now being done with that at least in terms of like 478 00:55:40,200 --> 00:55:46,440 improving security improving the stack making it more modern and so on and speaking of grants 479 00:55:46,600 --> 00:55:49,160 yeah uh yeah one invention pillow 480 00:55:53,160 --> 00:56:04,760 exactly so pillow that's a peer to panda plus willow yeah yeah exactly and um let's see if 481 00:56:04,760 --> 00:56:14,360 you stick to the name um yeah um but uh exactly this is like a grant we got from an lnet 482 00:56:15,000 --> 00:56:23,720 and it allows the willow folks to work on their um yeah um protocol to put and get data into 483 00:56:23,720 --> 00:56:30,920 their stores and and to sync it's like the WTP protocol i think like i hope i hope i didn't say it wrong 484 00:56:31,720 --> 00:56:36,680 but yeah this this is money for them to like specify and and implement this protocol 485 00:56:37,240 --> 00:56:43,400 which is great for us because then peer to panda can use it to store our operations from our 486 00:56:43,400 --> 00:56:50,680 append only log into willow so talking about like uh yeah um different base conversion data types 487 00:56:50,680 --> 00:56:56,920 now we store one and another um which is also interesting i think and the cool thing here is 488 00:56:56,920 --> 00:57:02,600 what we get then from willow is um really need access control for their capability system 489 00:57:02,600 --> 00:57:09,960 metal cap and now these willow notes can sync with each other and um we can express like access 490 00:57:09,960 --> 00:57:17,160 control for that and um yeah and then we have we have a nice way to like query these ranges and 491 00:57:17,160 --> 00:57:25,720 can map that back to our data type and we use that for um for support notes which is something 492 00:57:25,720 --> 00:57:33,400 we call um highly available or more available um notes in the network so when everyone is offline 493 00:57:33,400 --> 00:57:38,600 and you still want to get that data from somewhere then you can talk to a support note and this is 494 00:57:38,600 --> 00:57:44,840 where you might get it from um and combined with our encryption scheme we can have that data fully 495 00:57:44,840 --> 00:57:50,760 encrypted on on a willow peer so they will they will not really know what they're storing this is 496 00:57:50,760 --> 00:57:58,120 yet again one of those things i wish we could dive more into but Andreas i'm sorry you're gonna have 497 00:57:58,120 --> 00:58:10,280 to come back another time yeah um so you also got another grant for more sneaker net stuff i heard 498 00:58:10,280 --> 00:58:17,160 of yeah exactly yeah this is coming from the breakout program uh from equality uh this 499 00:58:17,160 --> 00:58:26,280 Montreal based organization and uh there we are um um yeah working on something we currently 500 00:58:26,280 --> 00:58:31,560 call the like the multi-plexer which is not a good name but it's basically switching between 501 00:58:31,560 --> 00:58:37,480 different transports and different ways of event delivery um so you know you're building 502 00:58:37,480 --> 00:58:44,200 application and you can just switch from Bluetooth low energy to uh the internet or to um yeah 503 00:58:44,200 --> 00:58:50,760 Laura and yeah um switch between all of these different transports depending on what's available 504 00:58:50,840 --> 00:58:58,600 to you and uh what makes sense maybe also for certain kinds of data um and uh and as part of that 505 00:58:58,600 --> 00:59:04,360 we are also exploring building like alternative yeah alternative ways to exchange data and 506 00:59:04,360 --> 00:59:09,080 in peer-to-panda and currently it's open what that exactly is i think it's like as part of the grant 507 00:59:09,080 --> 00:59:15,240 we also conducting research and we're talking to people to see where the priorities are um but you 508 00:59:15,400 --> 00:59:22,600 know like overtour over i2p over delta chat um over Bluetooth low energy advertisements over 509 00:59:22,600 --> 00:59:32,120 reticulum mesh tasks take mesh core uh there's a lot of options you know to pick from uh yeah 510 00:59:32,120 --> 00:59:37,720 uh exactly uh you know over the over the bit torrent dhd and whatnot um so there is like 511 00:59:37,720 --> 00:59:43,480 there's like many many options and we basically just need to prioritize based on uh user feedback 512 00:59:43,480 --> 00:59:48,040 so on that note we're going to have to round it off and thank you so much for joining 513 00:59:48,040 --> 00:59:54,200 here today andres it was a pleasure having you yeah thank you that was fun yeah thank you 514 00:59:54,200 --> 01:00:01,960 looking forward to the future developments and whatever is coming out and uh speaking of 515 01:00:02,600 --> 01:00:09,800 uh spacious is another app yeah right spacious spacious not using peer-to-panda yet but they are 516 01:00:09,800 --> 01:00:14,920 interested in doing so yeah i thought they said i talked to Alex and they said they were using 517 01:00:14,920 --> 01:00:20,680 paper oh wow okay wow then they are further than effort okay well amazing okay cool yeah i think 518 01:00:20,680 --> 01:00:25,240 this is the thing right now there's so many people doing things with peer-to-panda right now and it's 519 01:00:25,240 --> 01:00:34,120 yeah it's hard for even you to talk yeah it's really nice well that's a good problem to be having 520 01:00:34,120 --> 01:00:41,240 congratulations and talk to you later yeah talk to you later bye bye 521 01:00:51,720 --> 01:00:56,280 SolarCast