WEBVTT 00:00.000 --> 00:09.720 All right, everyone, if you could help me in welcoming Andreas Andreas as a core maintainer 00:09.720 --> 00:13.760 of P2 Panda, he's going to be giving a presentation on walkway systems. 00:13.760 --> 00:18.520 These are infrastructure-independent P2P architectures that allow applications to switch seamlessly 00:18.520 --> 00:21.280 between internet, mesh, and other transport layers. 00:21.280 --> 00:23.280 So if you'll help me in welcoming Andreas, everyone. 00:23.280 --> 00:25.280 Thank you. 00:53.280 --> 01:14.800 Okay. 01:14.800 --> 01:15.640 I'll try that again. 01:15.640 --> 01:17.920 Hello, yeah. 01:17.920 --> 01:19.440 Yeah, so they walk away stacked. 01:19.440 --> 01:23.980 That was this term, which was brought up during the D 01:23.980 --> 01:27.640 Web seminar, which was an event I helped organizing 01:27.640 --> 01:31.920 in the internet archive in San Francisco last year. 01:31.920 --> 01:35.040 Yeah, about me, my name is Andreas. 01:35.040 --> 01:38.120 So ADZ on the internet, I'm a musician and a developer 01:38.120 --> 01:39.680 since a long time. 01:39.680 --> 01:42.280 And yeah, as we already heard, I'm also one of the maintainers 01:42.280 --> 01:44.000 of peer-to-panel, which we started 01:44.000 --> 01:46.560 like also roughly six years ago. 01:46.560 --> 01:46.920 Cool. 01:46.920 --> 01:50.560 So this is basically like a kind of like a mini-compressed 01:50.560 --> 01:52.560 version of this lecture I tried to give. 01:52.560 --> 01:56.440 Some concepts might be known to you, some others, not. 01:56.440 --> 01:59.160 And bear in mind, this is if you're a radical framework. 01:59.160 --> 02:04.840 I will, you know, it will be rough on some edges. 02:04.840 --> 02:07.560 So most of the time, we want to send a message to someone, right? 02:07.560 --> 02:10.760 So here we have Bobby, Bobby wants to send a message 02:10.760 --> 02:15.640 to Daphne, you know, we have the message here and Bobby. 02:15.640 --> 02:18.640 And Bobby probably wants to send it over, that's 02:18.640 --> 02:19.440 the internet. 02:19.440 --> 02:24.720 And, you know, they sent the message to a server or to another 02:24.720 --> 02:25.560 note. 02:25.560 --> 02:27.360 And then what we usually want to do is like, yeah, 02:27.360 --> 02:29.160 we want to process that message. 02:29.160 --> 02:30.680 You want to look at it. 02:30.680 --> 02:31.560 Does it look correct? 02:31.560 --> 02:33.480 Does it have the right shape? 02:33.480 --> 02:35.480 Then we want to store this message in a database. 02:35.480 --> 02:37.480 And then we want to do queries on that database 02:37.480 --> 02:42.080 so then finally render it into the UI. 02:42.080 --> 02:44.480 So now, of course, now we want to move this into a peer-to-peer 02:44.480 --> 02:46.680 space and there we don't have servers. 02:46.680 --> 02:50.240 And maybe we want to use other authentication strategies 02:50.240 --> 02:56.200 then then checking your email address if it's valid or something 02:56.200 --> 02:58.080 or your phone number. 02:58.080 --> 03:00.160 So what we use is public key cryptography. 03:00.160 --> 03:01.160 We sign the message. 03:01.160 --> 03:03.200 We attach the public key to the message. 03:03.200 --> 03:06.800 And now wherever that message arrives, we can now check that 03:06.800 --> 03:09.720 signature and we can say, OK, cool. 03:09.720 --> 03:12.120 This message actually has integrity. 03:12.120 --> 03:14.040 It's a guarantee we gained now. 03:14.040 --> 03:17.400 The integrity guarantee is no one has tampered with the contents 03:17.400 --> 03:19.920 of this message while it was underway. 03:19.920 --> 03:22.720 The other thing we also gained is provenance. 03:22.720 --> 03:28.320 We know where that message came from or authentication. 03:28.320 --> 03:30.840 These are guarantees we gained from this. 03:30.840 --> 03:33.720 And this is, I would say, some base guarantees 03:33.720 --> 03:36.560 we want for a walkway stack. 03:36.560 --> 03:39.520 Of course, we need other systems to map Bobby 03:39.520 --> 03:44.520 to actually that public key, but this is another problem. 03:44.520 --> 03:47.520 Yeah, and because I'm trying to paint the model here, 03:47.520 --> 03:49.600 let's try to make this even more abstract. 03:49.600 --> 03:55.920 So we can say somehow this message of Bobby needs to be sent. 03:55.920 --> 03:58.440 So it needs to be sent over something I would call the connectivity 03:58.440 --> 04:02.400 substrate, like the internet protocol or a USB stick, 04:02.400 --> 04:04.040 or we don't know, it doesn't matter. 04:04.040 --> 04:06.880 But it somehow needs to be sent. 04:06.880 --> 04:09.440 And this message, that's our data type, right? 04:09.440 --> 04:11.640 Like something we define. 04:11.640 --> 04:15.400 And then we can now even more simplify this into, 04:15.400 --> 04:18.280 let's call this bottom part the event delivery layer, 04:18.280 --> 04:20.840 because this is the thing which brings the message 04:20.840 --> 04:22.520 to somewhere. 04:22.520 --> 04:27.240 And then we want to process this on the event processing layer. 04:27.240 --> 04:28.600 This is another simplification. 04:28.600 --> 04:30.560 And then finally, we have the application on top of that. 04:33.280 --> 04:33.640 Cool. 04:33.640 --> 04:39.800 And now, some people happen to like local first links very much 04:39.800 --> 04:41.840 and in local first, we always want to do everything 04:41.840 --> 04:44.280 like right on the machine locally. 04:44.280 --> 04:47.720 That basically means that now everyone turns into a server. 04:47.720 --> 04:50.000 Every computer actually buys this, including. 04:50.000 --> 04:53.400 And we want to store the data there. 04:53.400 --> 04:57.480 And the problem, which we have to now, 04:57.480 --> 04:59.680 it's a think about this when everything is stored on your machine, 04:59.680 --> 05:05.360 like it's that you might be missing out on someone else's data. 05:05.360 --> 05:08.720 And that can especially happen when there is network partition 05:08.720 --> 05:10.520 or network fragmentation, literally things 05:10.520 --> 05:12.680 like there is no internet. 05:12.680 --> 05:17.360 And so now we end up with like an inconsistent state of the system 05:17.360 --> 05:20.960 because Stephanie didn't get the messages of Bobby. 05:20.960 --> 05:23.440 And then now we have a problem. 05:23.440 --> 05:25.120 This can be easily solved with something 05:25.120 --> 05:29.360 like people call a sync protocol or like a replication protocol, 05:29.360 --> 05:32.760 which is basically like two peers asking each other 05:32.760 --> 05:34.520 what they're missing of each other 05:34.520 --> 05:37.920 and then, you know, it's usually expressed as some sort of state vector. 05:37.920 --> 05:41.560 And this is enough information for the other peer 05:41.560 --> 05:44.360 to compute the difference between these two sets 05:44.360 --> 05:48.160 to then sense the missing messages to the other party. 05:48.160 --> 05:53.480 And what we gained from this now is like eventual consistency guarantees. 05:53.480 --> 05:56.480 Like these systems will now converge to the same state 05:56.480 --> 06:00.480 and that will make everyone in the local first world happy. 06:00.480 --> 06:03.880 And now if you look really close to what we've just done, 06:03.880 --> 06:05.880 it's actually already a CRDT. 06:05.880 --> 06:09.280 So CRDTs can be very complicated to understand 06:09.280 --> 06:13.080 but this what we just saw was already a CRDT. 06:13.080 --> 06:15.880 So we have a set of messages like all the chat messages 06:15.880 --> 06:17.280 which can be sent in this group, 06:17.280 --> 06:21.680 which were sent in that system and, you know, 06:21.680 --> 06:25.080 eventually everyone will see all the chat messages, right? 06:25.080 --> 06:27.680 And it also kind of doesn't matter 06:27.680 --> 06:29.680 in which order they arrived, 06:29.680 --> 06:32.880 they will be just sorted by timestamp afterwards anyway. 06:32.880 --> 06:36.680 And also it doesn't matter if they arrived multiple times 06:36.680 --> 06:40.280 because, you know, like we just ignored that. 06:40.280 --> 06:42.480 So here we have a very simple CRDT already. 06:42.480 --> 06:45.080 It's called a grow only set. 06:45.080 --> 06:47.280 And that's interesting, right? 06:47.280 --> 06:50.480 Because we're suddenly in like this world. 06:50.480 --> 06:52.080 We didn't even notice that we did it 06:52.080 --> 06:53.880 and I think many of you implemented these things 06:53.880 --> 06:58.080 and maybe accidentally already implemented the CRDT. 06:58.080 --> 07:00.480 Another terminology I introduced here is the replica. 07:00.480 --> 07:03.080 So now we have suddenly like replicas, 07:03.080 --> 07:08.080 which are basically like the local view on your state. 07:08.080 --> 07:10.680 And now we can talk about like, you know, 07:10.680 --> 07:14.880 peers having replicas of this data. 07:14.880 --> 07:17.080 There's different CRDTs. 07:17.080 --> 07:20.880 Very simple ones, but they're all really interesting. 07:20.880 --> 07:25.280 Like the grow only set, we looked at a last right wins map, 07:25.280 --> 07:27.680 kind of like a key value store where, you know, 07:27.680 --> 07:31.080 the next item will overwrite the other one. 07:31.080 --> 07:32.480 There is the append only look, 07:32.480 --> 07:35.480 which is something people also call a hash chain 07:35.480 --> 07:40.880 that's linked list where the next item points at the previous one. 07:40.880 --> 07:43.480 And then you can have that also expressed in a tree 07:43.480 --> 07:46.480 where multiple items can point at the previous one. 07:46.480 --> 07:49.280 And then you end up having a directed acically graph 07:49.280 --> 07:52.080 or a hash graph. 07:52.080 --> 07:56.280 These are all like nice, basic CRDTs. 07:56.280 --> 07:59.680 And there's proofs that there are actually functions also like CRDTs. 07:59.680 --> 08:01.280 We can, they can converge. 08:01.280 --> 08:05.480 And they have the same properties we want mathematically from them. 08:05.480 --> 08:08.080 So let's extend this model a little bit now more. 08:08.080 --> 08:13.080 So now our event delivery layer suddenly became, 08:13.080 --> 08:15.080 suddenly got a sync protocol. 08:15.080 --> 08:18.480 So now it's not only connectivity substrate, 08:18.480 --> 08:22.080 like the internet protocol, but now we also express the sync protocol on top of that. 08:22.080 --> 08:26.280 And we can kind of agree that might be on the event delivery layer, right? 08:26.280 --> 08:32.080 But then at the same time, the sync protocol is pretty closely tied to the data type. 08:32.080 --> 08:33.880 We are syncing with because, you know, 08:33.880 --> 08:35.880 you might want to sync a deck differently. 08:35.880 --> 08:38.680 And it depends only look differently than a set. 08:38.680 --> 08:40.680 There's different strategies there. 08:40.680 --> 08:42.680 I'm going to talk about later. 08:42.680 --> 08:45.680 But we have to pick some data type. 08:45.680 --> 08:48.480 And we call it, in the walkaway stack, 08:48.480 --> 08:52.480 I call it like a base convergent data type. 08:52.480 --> 08:55.880 It's basically, yeah, like this core data type. 08:55.880 --> 09:01.880 And it can be one of these, or maybe something else, a mercury or whatnot. 09:01.880 --> 09:05.680 Yeah, and this brings me now to even more simplification of this model, 09:05.680 --> 09:07.080 which looks like this. 09:07.080 --> 09:10.680 So we have an event delivery layer, as I mentioned, 09:10.680 --> 09:12.080 the base convergent data type. 09:12.080 --> 09:14.080 And then we do the event processing on top. 09:14.080 --> 09:18.280 And this is getting now quite interesting, if we start thinking about applications 09:18.280 --> 09:21.880 like with this sort of model. 09:21.880 --> 09:24.280 And let me walk you through it. 09:24.280 --> 09:26.480 So we start with the event delivery layer. 09:26.480 --> 09:28.880 You know, some concrete connectivity, 09:28.880 --> 09:29.680 stop substrates. 09:29.680 --> 09:31.080 We could pick here, it's like we just heard, 09:31.080 --> 09:35.080 I wrote, could use valid, could use the torrent network, 09:35.080 --> 09:42.480 it to be what, you know, you pick your favorite substrates to connect to peers 09:42.480 --> 09:44.680 and exchange messages. 09:44.680 --> 09:46.080 There's different sync protocols. 09:46.080 --> 09:48.880 I mentioned already, depending on your data type, 09:48.880 --> 09:50.480 there might be different efficiencies. 09:50.480 --> 09:52.880 You gain from them, for example, for sets. 09:52.880 --> 09:59.080 And maps, there's the range-based set reconciliation by Alirasha Maya. 09:59.080 --> 10:03.680 And the rebuilds is like something with bloom filters. 10:03.680 --> 10:08.480 And the block height comparison, that's a very simple strategy 10:08.480 --> 10:14.080 to compare the state of two append-only logs and then compute the diff. 10:14.080 --> 10:16.280 I'm going to talk about this a little bit more. 10:16.280 --> 10:19.680 But you see, like there's already kind of like a little zoo of things we can do. 10:19.680 --> 10:22.880 And maybe the thing I want to point out here is, 10:22.880 --> 10:25.680 it kind of is important what base data type you pick, 10:25.680 --> 10:29.280 because it kind of influences the replication protocol 10:29.280 --> 10:31.080 and therefore also your event delivery layer. 10:31.080 --> 10:35.280 So they're kind of somehow tied together. 10:35.480 --> 10:39.480 And then now we can also look at this base conversion data type. 10:39.480 --> 10:42.280 And, you know, some people are like, yeah, I mean, 10:42.280 --> 10:47.080 append-only logs are nice, but like, or sets, but I want a graph. 10:47.080 --> 10:50.080 And my answer to that is, yes, that's cool, 10:50.080 --> 10:52.480 because they're completely unrelated. 10:52.480 --> 10:56.880 Your base conversion data type is just a carrier of your data. 10:56.880 --> 10:59.880 And then you express other data types on top of that, right? 10:59.880 --> 11:02.680 It's a little bit like the IP packet or the data gram, right? 11:02.680 --> 11:05.080 It's just a carrier of something. 11:05.080 --> 11:06.280 And we can understand them, 11:06.280 --> 11:07.680 similar like here as well. 11:07.680 --> 11:10.080 It's kind of like a carrier of any information we want, 11:10.080 --> 11:14.280 including graphs or mercletaries or whatnot. 11:14.280 --> 11:19.880 So we can sync DAX over append-only logs. 11:19.880 --> 11:24.880 And you see this is basically like some sort of like enhancement of my message. 11:24.880 --> 11:29.080 So this base conversion data type now gives me the cryptographic integrity 11:29.080 --> 11:32.080 for hashing function, the provenance, 11:32.080 --> 11:34.480 through a digital signature algorithm. 11:34.480 --> 11:41.680 And it protects now my payload and what we gain is all of these get guarantees 11:41.680 --> 11:48.680 and then on top even eventually consistency for our like local first worlds. 11:48.680 --> 11:51.680 Okay, let's move up to the event processing layer. 11:51.680 --> 11:55.480 So now we are observing these messages coming in, right? 11:55.480 --> 11:59.080 And some people might call it eventsourcing. 11:59.080 --> 12:01.880 In any case, we usually want to observe these events 12:01.880 --> 12:05.280 and then we want to materialize state on top of that. 12:05.280 --> 12:08.080 We kind of like, you know, message comes in and says like, 12:08.080 --> 12:10.480 create this thing, then I'm creating this thing, 12:10.480 --> 12:15.080 I put it into a database and someone comes around the corner and says, 12:15.080 --> 12:18.280 I update that thing, then I change the value in that database. 12:18.280 --> 12:21.080 This is usually where my materialize state lives. 12:21.080 --> 12:24.680 And then I want to have queries on top of that for my application to, 12:24.680 --> 12:27.880 again, render it to the UI. 12:27.880 --> 12:31.080 And what is interesting with event processing is, 12:31.080 --> 12:36.080 and this is, I think what I'm very excited about is we can layer the concerns. 12:36.080 --> 12:41.680 And we can enhance our data types with certain processing methods, 12:41.680 --> 12:50.080 which enrich my data in a way so I can then get even more guarantees higher up the stack. 12:50.080 --> 12:52.080 Oh, God, I used the word stack too much. 12:52.080 --> 12:57.080 I don't want to sound like, oh, as I model or something where you have these layers. 12:57.480 --> 13:06.280 This is a much more pluralistic, much more, yeah, like, yeah, much more colorful worlds, I think. 13:06.280 --> 13:09.880 But in any case, some data types, you want to enhance the certain features here. 13:09.880 --> 13:13.480 We basically introduce something where I describe predecessors. 13:13.480 --> 13:21.880 So I point with like a vector clock, which is cryptographically secured to like past items. 13:21.880 --> 13:30.680 And now, suddenly, we composed on an appent or single writer appent on a locally composed multi-writer directed acyclic graph, right? 13:30.680 --> 13:36.080 And with this information, I can now express a processing pipeline, 13:36.080 --> 13:37.480 which, again, does the same thing. 13:37.480 --> 13:39.280 My message arrives in the system. 13:39.280 --> 13:40.280 I validate it. 13:40.280 --> 13:41.480 It does everything look fine. 13:41.480 --> 13:42.880 It's a signature correct. 13:42.880 --> 13:44.880 And then now I can do ordering. 13:44.880 --> 13:49.680 And, you know, like topological, like, basically like a topological sword, 13:49.680 --> 13:51.880 I can check out my dependencies met. 13:51.880 --> 13:55.080 If not, wait, if yes, forward it. 13:55.080 --> 13:59.880 And then I end up with a topologically sorted serialized sequence of my events. 13:59.880 --> 14:04.080 And then I get my partial ordering guarantee, which is also called causal ordering. 14:04.080 --> 14:07.880 And that's awesome, because literally every CRDT kind of needs that. 14:07.880 --> 14:13.280 And so once again, we are in a world where systems can converge. 14:13.280 --> 14:19.680 There can be fully decentralized, and we can still get the guarantees that we eventually 14:19.680 --> 14:21.280 will end up in the same state. 14:21.280 --> 14:27.880 And all of this through like some nice layering and kind of optional extension of my data types. 14:27.880 --> 14:30.880 Some needed, some other stones. 14:30.880 --> 14:35.680 And this may be an invitation to kind of think about it as like a general class of things 14:35.680 --> 14:38.080 we might be able to compose. 14:38.080 --> 14:40.680 And there's many problems we have in that space, many, many problems. 14:40.680 --> 14:46.480 It's not only ordering or signatures or integrity checks. 14:46.480 --> 14:52.280 It's things like access control, permission management, capabilities. 14:52.280 --> 14:56.480 We want to think about, of course, attacks on the system. 14:56.480 --> 14:59.680 So we need to worry about Byzantine fault tolerance. 14:59.680 --> 15:04.480 We need to think about garbage collection, so data shouldn't grow forever. 15:04.480 --> 15:06.880 But we at one point also want to get rid of it. 15:06.880 --> 15:10.080 These are like forms of coordination. 15:10.080 --> 15:13.680 And we do want to do key agreements. 15:13.680 --> 15:15.680 We want to agree on secret materials. 15:15.680 --> 15:21.680 So we can have a shared key and then encrypts data with it. 15:21.680 --> 15:22.680 And so on and so on. 15:22.680 --> 15:25.080 So there's a lot of things we can do on that layer. 15:25.080 --> 15:26.480 And this is, I think, which is interesting. 15:26.480 --> 15:29.680 It's completely detached from event delivery, right? 15:29.680 --> 15:34.280 This is like its own complete ecosystem, almost like a state machine. 15:34.280 --> 15:37.280 We can just describe it as such. 15:37.280 --> 15:40.880 And yeah, I think this is a little bit like a provocation. 15:40.880 --> 15:43.280 We're like existing CRDT frameworks. 15:43.280 --> 15:46.880 I think there's a future where I don't need to opt in 15:46.880 --> 15:50.080 into a whole ecosystem of like a super CRDT. 15:50.080 --> 15:52.280 But actually, I just want to text CRDT part. 15:52.280 --> 15:54.680 And everything else can be done by other frameworks. 15:54.680 --> 15:58.080 And maybe this even will be pluggable and interchangeable, 15:58.080 --> 16:00.080 depending on my needs. 16:00.080 --> 16:00.880 We're not there yet. 16:00.880 --> 16:01.880 This is just an idea. 16:01.880 --> 16:05.880 But I think it's for me it's personally quite exciting. 16:05.880 --> 16:08.880 Yeah, and then we'll finally at the definition of a walk away stack. 16:08.880 --> 16:12.280 So the walk away stack is basically like moving all of these application 16:12.280 --> 16:15.680 concerns up to the event processing layer. 16:15.680 --> 16:22.080 And then we can move away from the event delivery layer whenever we want. 16:22.080 --> 16:26.480 And this is really beautiful because now we are not dependent on the technical infrastructure 16:26.480 --> 16:31.680 that layer imposes on us and also maybe like the politics around this technical infrastructure. 16:32.080 --> 16:36.280 Including internet shutdowns and censorship and whatnot. 16:36.280 --> 16:41.480 And someone in the seminar called it power in balances as well. 16:41.480 --> 16:44.280 So you choose your own power in balances. 16:44.280 --> 16:49.280 Because we're always exposed to systems where there is some sort of like power dynamic going on. 16:49.280 --> 16:54.080 But maybe if our applications don't break when we move to another system, 16:54.080 --> 16:58.280 then we have something like walk away and choose our own power in balances. 16:58.280 --> 17:01.480 So this is a little bit the idea behind it. 17:02.480 --> 17:08.480 Cool. And now I talked a lot about direct connections, the internet and so on. 17:08.480 --> 17:14.480 But I'm also here in a room where there's a lot of people doing mesh networking. 17:14.480 --> 17:20.480 And now I want to combine these two worlds and see like okay I aren't they actually the same in some way. 17:20.480 --> 17:21.480 If we think about it. 17:21.480 --> 17:27.480 So in a mesh network usually let's I'm taking a very radical example. 17:27.480 --> 17:30.480 I have an antenna and this antenna is just broadcasting. 17:30.480 --> 17:34.480 Right. It's just like I send data. I just emit it. 17:34.480 --> 17:37.480 A little antenna sending data. 17:37.480 --> 17:40.480 Yeah. And you know it sends the data and it spreads. 17:40.480 --> 17:43.480 It's a little bit like you throw stone into the water, you know, 17:43.480 --> 17:47.480 and it's the ripples of the water just, you know, like move. 17:47.480 --> 17:52.480 And at one point that little wave will hit another antenna somewhere here. 17:53.480 --> 17:56.480 And message received. Right. 17:56.480 --> 18:01.480 We have a one directional communication happening here. 18:01.480 --> 18:04.480 And then we sent an answer and the answer comes back in the same way. 18:04.480 --> 18:13.480 And here we go. We have our same scenario again of some communication between two parties like Bobby and Duffney. 18:13.480 --> 18:19.480 Okay. So now how can we get eventually consistency guarantee? How can we make this local first? 18:19.480 --> 18:24.480 So as I just said, we want to converge to the same state. 18:24.480 --> 18:27.480 At one point every peer has to see every message. Right. 18:27.480 --> 18:30.480 This is the guarantee we want to achieve. 18:30.480 --> 18:33.480 How do we do this? We could literally just repeat the message all the time. 18:33.480 --> 18:37.480 Until maybe everyone has it. 18:37.480 --> 18:41.480 We don't know if they're going to have it. We don't have any form of acknowledgement. 18:41.480 --> 18:45.480 But I can just do like best effort. I just repeated it forever. 18:45.480 --> 18:49.480 And that works, of course, that's a fine synchronization protocol anyway. 18:49.480 --> 18:53.480 The problem is here maybe the more data you created in your application, 18:53.480 --> 18:57.480 the more crazy it gets because now if you repeat all of these things all the time. 18:57.480 --> 19:01.480 And there's an answer to that. You send a pent-only look. 19:01.480 --> 19:07.480 So an pent-only look is like a strictly ordered sequence of items. 19:07.480 --> 19:13.480 And I know my current state because I am at the sequence number three. 19:13.480 --> 19:18.480 Definitely is at sequence number one. Now I know that Stephanie is missing two items 19:18.480 --> 19:21.480 because we can literally just compare these two numbers. 19:21.480 --> 19:27.480 And this is something where we can simply just do by broadcasting our current highest of the lock. 19:27.480 --> 19:31.480 And definitely just broadcast, hey, I'm at like lock height one. 19:31.480 --> 19:34.480 And I receive this signal as Bobby. 19:34.480 --> 19:40.480 And this is enough information for me to compute the difference between this and just reply. 19:40.480 --> 19:44.480 And I do this until no one says anything anymore, basically. 19:44.480 --> 19:46.480 No one announced their lock height anymore. 19:46.480 --> 19:51.480 This is already, you know, now we're already in exactly the same space I just mentioned before. 19:51.480 --> 19:53.480 And with the help of a pent-only looks. 19:53.480 --> 19:56.480 There's other strategies as well, but this is like one example. 19:56.480 --> 20:01.480 And very concretely, this is done in the project called Tiny SSB. 20:01.480 --> 20:02.480 You can check it out. 20:02.480 --> 20:07.480 And Tiny SSB goes even that far to do like a packet ready over short wave, 20:07.480 --> 20:13.480 and with Skywave bouncing over the Atlantic Ocean with a pent-only looks. 20:13.480 --> 20:18.480 And there, of course, like we all have the problem now. 20:18.480 --> 20:21.480 As soon as we move this world into like, 20:21.480 --> 20:26.480 yeah, mesh networking, we might have too much data in our payloads. 20:26.480 --> 20:29.480 So we need to be smart with like what do we actually want to send. 20:29.480 --> 20:33.480 Tiny SSB also has some interesting ideas of like a form of compression, 20:33.480 --> 20:36.480 where we omit kind of like redundant data. 20:36.480 --> 20:41.480 We can actually also just compute ourselves because it's deterministic. 20:41.480 --> 20:44.480 The interesting project you should definitely check it out. 20:44.480 --> 20:49.480 Okay, so now the mesh networks learn something from local first. 20:49.480 --> 20:53.480 Now the other way around, how can we make like, 20:53.480 --> 20:58.480 internet or IP based like stacks more like feel more like mesh networks. 20:58.480 --> 21:02.480 So in, of course, on the internet, we always think about direct connections. 21:03.480 --> 21:07.480 But we can express basically broadcast overlays on top of that. 21:07.480 --> 21:10.480 We heard that already before something like I regoss it. 21:10.480 --> 21:15.480 And this is like a very interesting sort of provocation also to developers 21:15.480 --> 21:19.480 to think in these dimensions of like, okay, what if everything is broadcast, right? 21:19.480 --> 21:22.480 And the new, if we still maintain direct connections in our system. 21:22.480 --> 21:27.480 But the high level abstraction is broadcast. 21:27.480 --> 21:34.480 And yeah, exactly. 21:34.480 --> 21:36.480 So this is like my provocation. 21:36.480 --> 21:38.480 Is it the same, maybe not. 21:38.480 --> 21:45.480 But yeah, maybe we can actually express this in this high level sort of IPA API. 21:45.480 --> 21:52.480 So we just subscribe to it topic, organize ourselves around like an identifier. 21:52.480 --> 21:55.480 And then I just get a TX and RX like a way to send a message, 21:55.480 --> 21:57.480 a way to receive a message. 21:57.480 --> 22:01.480 And this is just like a sort of like almost like a broadcast interface. 22:01.480 --> 22:03.480 This is very simplifying obviously. 22:03.480 --> 22:07.480 We need to do so much more, what's in terms of privacy and security. 22:07.480 --> 22:13.480 But I think it's like a provocation in this direction to think about these systems more from this broadcast, 22:13.480 --> 22:16.480 even when we are on the internet. 22:16.480 --> 22:20.480 Another thought around walk away is something, 22:20.480 --> 22:23.480 some people call relays, some people call support notes, 22:23.480 --> 22:27.480 some people call store and forward. 22:27.480 --> 22:32.480 And this is like something we also want to have in these systems. 22:32.480 --> 22:36.480 And we can actually also leverage quite well from mesh networks. 22:36.480 --> 22:42.480 We want to relay data, of course, by intermediaries. 22:42.480 --> 22:44.480 You know, like you are in a protest situation. 22:44.480 --> 22:47.480 There is a building around in front of you. 22:47.480 --> 22:49.480 But there are some people on the other side of the building, 22:49.480 --> 22:51.480 how do you get around that building. 22:51.480 --> 22:55.480 So basically what you do is you relay from everyone's smartphone, 22:55.480 --> 22:57.480 basically from everyone's Bluetooth, 22:57.480 --> 23:02.480 energy, capability devices around the building until the message arrived. 23:02.480 --> 23:05.480 This is some sort of relaying problem. 23:05.480 --> 23:09.480 And this is awesome and we want to have it all the time. 23:09.480 --> 23:12.480 So basically what I do is like I have my message. 23:12.480 --> 23:15.480 I encrypt it in a ways because I don't, you know, 23:15.480 --> 23:18.480 I don't trust any intermediaries to intercept my message. 23:18.480 --> 23:20.480 So I need to encrypt it beforehand. 23:20.480 --> 23:26.480 It arrives on these relays and they are just forwarded until it finally arrives 23:26.480 --> 23:31.480 at the receiver, which is basically definitely again. 23:31.480 --> 23:35.480 And the property we want here is like this sort of, I mean, 23:35.480 --> 23:38.480 fairly dystopian scenario, but I think a very important one is 23:38.480 --> 23:45.480 relays can go down and we want still this network 23:45.480 --> 23:51.480 to somehow still be able to communicate even when things get really shaky. 23:51.480 --> 23:56.480 One idea we can maybe combine things with is like, 23:56.480 --> 23:59.480 of course, how do you agree on this symmetric key right in the beginning? 23:59.480 --> 24:01.480 I think like people from MeshTastik, 24:01.480 --> 24:03.480 they usually do some handshake in person. 24:03.480 --> 24:06.480 This is a sort of side channel where you agree on that key. 24:06.480 --> 24:10.480 And then afterwards you get into your like secret communication. 24:10.480 --> 24:13.480 We could also use the direct connections, actually, 24:13.480 --> 24:18.480 and we still have the internet to use the CRDT to coordinate key agreements. 24:18.480 --> 24:21.480 And then when we go out into the Mesh World, 24:21.480 --> 24:24.480 we could then use that key to continue talking. 24:24.480 --> 24:27.480 So this is like a very concrete example. 24:27.480 --> 24:31.480 I think call is also doing a lot of work here in this direction. 24:31.480 --> 24:35.480 And yeah, this is a little bit like a map I try to paint. 24:35.480 --> 24:40.480 You see this is a very theoretical approximation of a very vast space. 24:40.480 --> 24:44.480 There's a lot of stuff missing here, which doesn't fit on this slide. 24:44.480 --> 24:48.480 But I think we kind of have a lot of things already happening 24:48.480 --> 24:50.480 in all of these directions. 24:50.480 --> 24:54.480 But maybe there is much more space for like actually interoperability 24:54.480 --> 24:58.480 and collaboration across projects from this like MeshFear, 24:58.480 --> 25:00.480 the local first sphere. 25:00.480 --> 25:02.480 I think it's definitely possible. 25:02.480 --> 25:04.480 Cool. So thank you very much. 25:04.480 --> 25:06.480 I think this is it. 25:06.480 --> 25:14.480 Yeah, we have time for one or two questions. 25:14.480 --> 25:18.480 So is anyone have anything they want to ask? 25:18.480 --> 25:22.480 Well with that, let's give another applause then. 25:22.480 --> 25:24.480 Thank you very much. 25:24.480 --> 25:26.480 Thank you for showing us this. 25:26.480 --> 25:29.480 And if you do think of questions, 25:29.480 --> 25:32.480 feel free to find a mastering talk to him. 25:36.480 --> 25:38.480 Thank you very much.