Permissionless P2P with The Waku Network by Sasha | Devcon SEA

[Music] hello oh it works um nice to meet you my name is Sasha today um we will have a little presentation about waku uh it will be two presenters me and Ian uh we will explain you um overall problematics of peer-to-peer networks um we will go through um uh common parts of peer-to-peer networks challenges that are faced usually and uh uh how they usually are dealt with and the common tradeoffs uh then we will explain a bit about waku which is a functionable peer-to-peer network uh that has uh some answers to some of the problems that will be mentioned and we will show you some examples and uh we'll try to do a bit of programming so uh yeah uh how are you guys familiar raise your hand if you are really familiar with peer-to-peer networks you build one way yourself uh you know ins and outs of Le P2P or Dev P2P or you build your stack so maybe you can uh uh enjoy this talk I hope as well but uh otherwise it's more of an intermediate level so um yeah uh let's start so uh why do we even care about uh peer-to-peer networks so first of all is um that due to architectural uh decision of going with peerto peer uh we guarantee some uh potential decentralization and sensorship resistance that comes out of it and uh why do we even want it is that because we are in crypto space right I think this is like something that does not need a lot of answers but then [Music] um usually this uh solution is made uh to introduce some set some degree of privacy and that data ownership it's to provide this service to the users of our applications networks whatever uh other properties that peer-to-peer networks guarantee that usually they are full tolerant or uh resilient and this comes out of the fact that uh we don't have single point usually there and uh we um uh can survive as a as a as a set of nodes if one two or even half of the nodes are offline or down uh and then uh potentially we can get some scalability out of this decision uh this is questionable actually because p-to-p networks are known to be uh difficult to make right uh but U hypothetically we can reach a high degree of scalability naturally um what challenges there are so um first one is that we need to build one and maintain ourself uh this is challenging because uh the peer-to-peer networks has a lot of complexity in it like some set of protocols being implemented so we need to make sure that all the peers understand each other and then if we let's say release a new uh version of our software we need to make sure that it somehow like gets propagated or something this is quite challenging uh as well as there is a lot of devops involved like whenever we um whenever we upgrade something uh something might be down then it impact some some other people so uh it's difficult to to to do right um reliability is also a big challenge in peer-to-peer networks um why uh because uh it also depends on the degree of noes amount of notes in the network the less there are there more reliabilities so like if there is one note it's quite reliable if there are more then um it comes challenging um to make sure that all the protocols function correctly and the notes propagate the messages in the right way then uh Network discover is a huge bottleneck there um all projects made uh different decisions there but more or L there are some patterns that everyone follows um and security and traffic management like depending on the architecture of the peer-to-peer Network we go with uh we incur different uh pattern of how uh data will be propagated so let's say for the case for vaku that later will be explained by my colleague um wo goes with gossip sub architecture and it in course some particular way of how message is going to be exchanged in the network uh other people might go with a mixet or something else so depends and uh for the security uh there are more parts than just you know encryption any that other people cannot read your data there is also a security of over Network how like identity Seft like let's say if someone can pretend to be someone else in the peer-to-peer Network it's quite challenging and has to be addressed on the software level somehow uh so we can use different uh um algorithms here uh the other problem there is that um how to make the network not to go down because of like some some someone malicious there let's say if uh we have a peer that produces 90% of the traffic overall right uh we don't want single uh node to consume all the resources of the network yeah this is a security question as well um uh so um how to build the peer-to-peer Network so these days there are couple Solutions usually everyone goes with CT do it yourself diyi um and many projects just go there try to figure it out they figure it out somehow because all of us are quite good Engineers I I I hope and uh uh all of them just answered the questions uh sold it and uh release they use just not Network stack whatever is available in the language of their choice and um that's it uh but other projects has figured out that it can be scaled somehow so uh Dev uh def P2P and Le P2P got born so they uh they appeared approximately the same time def P2P is very dedicated for ethereum stack and it's like something that all ethereum nodes implement but there is so l2p which was um more of a generic stack like it can be used by any project it does not have any dependency on any blockchain whatsoever and it's very modular uh for waku it is the case that we built on top of l2p and we extend it with uh our protocols we we continue building from there um so shared Parts uh it also somehow related to the challenges that I mentioned and uh usually we care about peer Discovery in the peer-to-peer net right this is obvious unless we know our peers we cannot form a network and there are multiple choices that uh projects go with uh some of them are DNS Discovery we call some particular we get retrieve some DNS records from there we understand like this is a set of noes that we can use and we go go on with them uh some might some choices might be like an exchange further exchange like we ask the nodes if they know other nodes right so very natural way of uh of discovering a network same as humans Behavior Uh then uh informational exchange so um a format uh usually the networks try to converge into one format so hence there is some specification for a package of data that is going to be populated throughout the network uh then uh something specific to the networking in the in the internet is that some peers might be hard to re reach uh so hence we need to uh use some ho punching techniques uh which means that if I cannot dial you directly maybe we can bypass it somehow like you dial me instead or uh let's say uh if uh it is not possible it's approximately I think 30% of the of the users overall which is the case for uh some protocols we may do relaying we so which means that I am going to ask some other peer to relay you some some data that I want you to see and you do the same so we like bypass this uh this this W in between us um then the other uh shared Parts is that all the networks try to somehow secure themsel from dos so and some dos protection come comes in play and spam protection how it should how it can be addressed by different meanings usually it might be like some tokens token exchange there might be some uh common shared uh uh record of uh peers that are like reliable whatever they can be used can be trusted so different ways um but one of the most difficult Parts here is that it's hard to make it uh in a privacy preserving way so that we don't uh release some Identity or we don't even know who is pure actually is uh and vaku has found some answer in partnership with other projects in the space um other shared Parts is at transport transport so uh this one is very important because uh if our nodes in the network uh Implement more transports such as websockets websocket secures uh TCP UDP uh web RTC web transport the more they transport they Implement uh the more clients they can reach uh like let's say if uh we have a websocket implemented we can be sure that our node can function not only between like some uh some Ser servers right but also with browsers so hence we uh can serve more users um and much more so there is a bandwidth management like how to make sure that our nodes are very ecological in the resources that they have uh the reputation like we want to make sure that the peers which we are talking at hog right now uh are more or less fine or not uh encryption this is a huge question as well like we don't want the whole network know what we are talking about what we exchange right and and routing uh more or less um so hence there are some tradeoffs that we make uh while building the networks and one of them is that do we want to have a one huge Network or we want to have like uh some Sub sub networks that somehow talk to each other later on I don't know um if we do some sharding how many of them we want like one two two groups three groups depending on the content content exchanged maybe right so this is a conscious choice that we as uh Developers have to make uh here then uh a message size right a data data packet the bigger it is the slower propagation of it will be through the network regardless of the architectural choice of it right so we want to be cautious of it and we want to make the best choice for our particular particular need uh and then rate limiting right we don't want uh anyone spam the network consume all the resources so which technology we use are we fine with having let's say common Ledger of trusted nodes or we want to be more open like publicly available Network that anyone can join uh so in that case what do we do uh how do we address it I don't know it depends uh incentivization right so some of the projects public networks have no incentivization but they still function well uh and why it happens is that because people share a common cause they want to be part of this network because it let's say gives some privacy it gives uh underprivileged people AR to internet without them uh fearing for any consequences or something or just buying drugs whoever whatever um and Discovery protocols like there could be a different way of how we can discover so we do some tradeos here as well some can be slower some can be faster uh and uh what waku does so here I going to pass it down to Ian and he will tell you thank you thanks hello everyone um okay and in this part of the talk we are going to to overview the the actual implementation of the the waku protocols as my colleague mentioned is um um an opinionated implementation of the uh of our view or how we consider is um good to to solve the the well-known problems uh such as the discovery the the problem to of a nut um or a firewall the problem of routing uh this is covered by all of the the protocols that are shown in this list and aside from that uh we introduced a new um new one which is the aren uh red limiting one and we are going we are going to to cover in a few seconds okay uh regarding Discovery uh we have three main uh Discovery protocols one is uh perer exchange uh this is uh pretty centralized and is not ideal but is um is useful in in certain conditions and what what it does sorry what I'm explaining is not shown in in the screen but uh what peer exchange protocol does is it asks to other peer to uh share the the peers that it knows and it's just a request response uh protocol where the the other peer response about the information of each peers and then we have the DNS Discovery uh which is um very interesting protocol that uh is powered by DNS and then we have the Discovery V5 which we consider uh to be more uh decentralized and more uh convin for the web 3 um scenario and it's um it's based its implementation is based on cadmia and well as you know it's uh DHT and uh what it does it retrieves a random set of um en enrs and um yeah this is um very intensively used in in woku okay then regarding um uh another family of protocols that we have in waku is the request response protocols uh which are um you will see in in this talk that we have two main families of of notes we have what we call a full node um which is basically a note that um is part of the of the overlay of the of the network and and produces the uh routing of the data and then we have the The Edge nodes and for these Edge nodes such as um a mobile phone or a browser is um it cannot participate in the routing uh um protocol because is um data consuming and for that reason we we created this uh request response uh protocols for for helping in order to help these Edge nodes in in different ways for example in regarding sorry for the typo regarding the store note it's main purpose is to um allow um nodes uh to come when a node come back to to participate in the network to get back the the late latest state of of the the messages then we have the sink and the main purpose of this protocol is to make sure that all the St nodes have the latest State and the same state of of messages uh then we have light push the purpose of this protocol is for Edge clients to to be able to participate in the network to publish messages and filter in the other way around okay if we go further to the routing protocol sorry anyway okay uh okay regarding the routing protocol is um we we call it relay and it's a kind of opinionated version of of Gossip sa uh which is uh uh great and it's very interesting and we're going to to cover very briefly how gossip Works in in this talk um okay uh okay okay this is a uh very simplified schema of um uh prity interconnected Network and the dots uh just represent nodes and as you can see all of the nodes they are continuously exchanging uh control messages like for example uh the the messages that I saw the messages I'm I'm interested in and I the the control messages um names are I I want or I I need no and and then we have the the waku messages that these are the the actual messages that transport uh data in in the in the in the network something important to to bear in mind is that um we can have for example 100 connections to a uh to 100 notes but one single note will and spread um data Wu messages to up to six eight notes maximum and every note will pick up the best from each neighbors will pick up the best notes regarding the according to to certain parameters such as latency and number of messages per per second uh how responsive an is and and so on and okay uh and how does it work um every note has uh a um her bit that happens every second and on every second every note measures or um gives um a certain score to to all of its uh nebs and according to this score if the score is too low then it ignores the the the the note it doesn't mean it completely disconnects to the note it keeps um uh gossiping say asking what messages do you have what what what I have Etc but it doesn't uh participate or interact share sharing um um important data no it only establishes a mesh with um amplification factor of um of value between four or eight this is how we we are configuring at at the moment and and yeah and in this slide um it's just um a simple example of how a single Noe um establishes um at certain point time uh what what is the about his its nebs uh what is the the P score and for for example if note a receives a message then uh given that the relay the S the overlay uh network is uh established with b and d it will only deploy or sorry uh spread the the message to to b and d and not not others and something important to bear in mind is that this can change every every second it's not a fixed uh overlay network but it's something that is alive okay and uh okay uh then we have the red limit nullifier uh this is a very interesting uh topic and very interesting technology because it it allows um to protect the network against spam in a in a private way so that the the uh the note can prove that it belongs to to the network without actually disclosing uh its information or it's very very cool how how it's um implemented and it's based on cnar technology and a smart contract currently in sepolia where the the membership set is configured I think uh we are about to release um version two of rln and uh and yeah it's um basically to this is a quite complex um topic and it's be beyond my knowledge but just to to get an idea the main purpose of it is to protect the network against spam in a private way uh okay um regarding the the waku message the um as you remember this is the the one that is being uh sent across the the overlay Network um basically it contains it contains a bit more Fields than uh shown in in the left but basically we have a payload uh which for which we don't impose any um additional encryption we leave the encryption to the app um developers and regarding encryption important something to to notice that uh there is pointto point encryption um inherited by the lip P2P um which is made um following the noise protocol and we have the the content topic uh which is a field um useful from the for example in the filter protocol um an H note uh subscribes to a certain content topic and from all the information that is shared across the network this uh the messages the The Edge note is interested in is going to be sent to to them okay and regarding this point okay so um to build on top of waku uh I just going to introduce you a bit to cdks that we have and languages we support uh so this uh QR code leads you to documentation website there is a lot of information uh links to our communities and such if you have any questions about anything like vaku related uh code is failing uh behaves unexpectedly reach out to us uh everything is there but we do support JavaScript and typescript right now and Nim is uh and second language that uh it's more of first language but still uh it's the language of our choice and we have an implementation of waku in Nim language and it's compilable to C and you have uh the C artifact that you can consume later on we're also working on uh better uh go uh bindings and cdk and uh rust and python uh they are work in progress but can be used to some cases right now um so for GS waku we have like a couple of packages main one is waku SDK just uh install it use it it going to work I hope so then uh we have a a wrapping for react also uh deals with react life cycle methods and stuff that busts a lot of uh creates a lot of unexpected uh Behavior Uh then we have a create up that can boost up your application quite easily might be useful as well so the main users right now are status status is uh uh a messaging application which uh is dedicated for onet to one chat as well as communities uh and and uh uh it uses Vu underneath it has its own uh set of nodes that are operating uh there are a bit different guarantees than uh defaults that we provide propose uh projects to use such as uh a bit extended uh store retention right because such applications want to retain uh data longer then a second project that uses waku is run this is privacy oriented defi project and uh vaku is used for broadcasting fees in the network so that it's uh um not known where it originates from uh then the graph also uses vaku for uh information exchange between some of their nodes um yeah so um and use cases uh there can be anything such as defi as I already mentioned Community run UPS as well uh some social interactions uh wallet to wallet communication gaming you name it so uh we saw interesting applications even with uh ge location position such as uh uh users GE location gets mapped to a particular Nam space in vaku network and then you can talk to the room in which you are located quite interesting approach to create a layer on top of reality um so today we're going to show you some of the examples uh this link will lead you to a repository with uh our examples that where we experiment where we play around and uh as well as do something for users I will show you um an application named body book uh we created it for as a PC just to show people around here at Dev and uh uh there will be more examples and we can try to do some programming if you are interested otherwise I will just walk you through some simple onepage JavaScript application with uh request response protocols uh that are used uh do you have any questions at this point maybe we can do a quick Q&A before we go into some code presentation oh yeah there is a question sorry m something specific for Native mobile SDK so do we have a mobile or C or or Swift uh new plans I mean not now we have it in Plants yes uh JavaScript version can be used in react native we did some bindings um we didn't prove it working reliably so this is also work in progress we had some go uh vaku being adapted for running is also in react native or uh other stuff but uh also status is using um vaku as well but uh they did little bit more work than just you know installing it so it is work in progress yes so please is there a public network uh that the the waku nodes run on or are you expected to run your own nodes for the applications that you run yeah so the main difference between waku and let's say lip2p as I mentioned lip2p is a stack that we are using and anyone can let's say me you we together want to build a network we create an application out of Lip lip right uh what waku does differently is that it provides a set of protocols like solutions to some problems that we observe and we want users to uh have dealt with as well as we have a running Network which is called the waku network tww and uh I will show you how to join it let's say from JavaScript cdk in a couple of lines of code and you can hook in your own nodes to each or use it as a signaling note let's say to create your own sub Network or something like that yes any more okay um so I going to go to my laptop and uh let's see what we can do with the code today so this one is uh for uh example with rust it uses n version of uh um of of vaku uh some bindings and uh you can scan it and see how it is implemented later on Ian will go and present himself the code and walk you through it um so uh body book uh if you scan uh this will lead you to the source code of the simple onepage application otherwise you can visit body book. fun and uh what it does is that once you open it you can create um a book and then later on at the conference or somewhere you can come to people and ask them to sign uh your book like collect signatures these signatures will be created from a wallet right so let's say a metamask wallet or something and the interesting point about this application is that the signatures will be exchanged through waku and they won't be committed to the to the blockchain hence there will be like an easy propagation of uh this information and it will be stored in the in the store protocols that Ian mentioned about so here we have like a couple of U you know just Just Books whatever and there are some signatures attached um yeah so if you create it it's going to appear here and uh yeah so this is very simplistic application but still uh very use case very interesting use case Okay so uh then uh uh you can run a note this is another application example of how waku can be used you can be uh just a node operator so uh contributing to the network let's say if you have a spare Raspberry Pi for gigs of RAM or something just uh opening uh a Docker and doing one line can already contribute to the network quite a bit uh though I'm line it's not one line it's uh more of of one line to run in your um terminal and uh now if you open this link it will show you a basic JavaScript application it will lead you to this to the code which I will go show now um I hope you see it well yeah is it readable should I increase it a bit okay A bit um this is just single one file application which consumes JavaScript cdk and uh uh uh you have to create an instance of a node first right so hence uh this create light node function is used uh it it accepts like different parameters there you can pass particular coordinates of the network that you want to use if uh not default network is in use so by default Network I inan here tww and if we want to use a default set of configuration which just pass default bootstrap other thing that uh vaku has in it is um uh the message the the data get right it it gets propagated through the network and there are some properties uh of this uh data packet that help uh to do routing and uh one of them is content topic and uh content topic should be perceived as the Nam space under which uh data should be exchanged ched from the perspective of an application so let's say if I mean an application like tegram right uh a Content topic can be uh one chat one group in which the messages are getting exchanged so hence uh I am as a user have a set of chats and only from them I want to receive messages if they are coming from different chats I don't want to receive them that's the simple idea here so uh and as anything uh uh in the uh computer science we want to create a reader and writer we have uh a blop of uh bytes being exchanged in the network and these two lines are doing exactly this they create decoder and encoder and they are configured to uh be uh using one particular uh content topic later on we have to start the node like just to initiate the processes part of API and uh the second one does uh an important part is that with the block execution of application until we receive some peers uh this is just uh one way to do it uh another way might be to uh not to do it and uh rely on you know lazy uh connect connection that will be managed by uh GS waku in that case um so uh then here I are going to show two protocols through uh two um lightweight protocols that we have for Edge nodes as I one mentioned one of them is filter and another one is light push they come complimentary and uh for filter uh the main use case is that you want to receive only those messages that you are interested in without uh consuming a lot of um bandwidths Etc uh and the filter exactly does the same we uh send a request to a service node and we ask it to later return a messages to us uh the whole uh uh interaction happens over web socket as of now in future we might go into uh having a web transport which is work in progress right now as well as web RTC might be in use uh for some cases but regardless of it we rely on the service node to return us messages uh in that case um we can do a lot of H ristics as I mentioned peer-to-peer networks are not ideal uh some of this problematic parts are uh having uh unreliable nodes one node can pretend to be reliable by advertising itself uh with some protocols that we are interested in but it might not do what we want what we do in that case we Implement some heris insight such as if I sent a message and I didn't receive it back from that note it's probably not reliable I'm going to drop it so this is a part of overall umbrella term reliability which we were working for the past six months so um yeah this is a simple callback from JavaScript perspective nothing fancy s to Pi uh data in side we just uh oh yeah wait on white push so here just one for Loop send in 10 messages from from our site and the sent is exactly sent it's just one request over existing uh transport in our case again it's websockets it just creates a Bop of uh of bytes and and sense it yeah so let's see inter connection uh okay so I'm going to open Local Host I have it open and yeah there are two tabs uh here we want to reconnect here we want to reconnect as well um we are waiting for Pierce no Pierce available something happened good here we subscribed and here we subscribed so now we are sending some messages in the loop and we are receiving some messages as we see uh one of the properties of the network is that um howu functions is that we going going receive our own messages uh and uh this can be quite useful for some of the applications um yeah so this does it thing so it works uh one of the interesting things is that um there are a lot of logs uh error logs they expected as for they cannot be uh ignored uh are there any questions uh right now yeah please um light node instance can you repeat to yes yeah the light node instance it's not a P2P instant no actually it is so uh but it depends right uh there's some trade-offs that we have have to make in the browser one of them is that uh set of available transports uh for for the browser tab right browser is very restricted environment there are a lot of things that we cannot do such as we cannot do a TCP uh connection directly or UDP connection directly we have to do either HTTP or uh a websocket connection that's it web RTC as well but there are limits right so um and also resources uh browser is very limited in how much much computation we can do like heavy computation right uh the browser tab can become suspended uh quite easily by operational system everything stops working in there right uh and uh it cannot be a fully functional uh part of the network hence we call it an edge node meaning that the traffic kind of ends there right it does not participate as a full node it's not full but it is peer-to-peer in the meaning that the the browser tab is independent in how it discovers the network it uses uh almost everything but uh Discovery defies that Ian mentioned um it discovers the network through DNS and per exchange and as uh for our case right now we have 24 peers so right now we have 24 web socket connections to 24 full nodes that we can use interchangeably or in rotation or if we observe that some does not work we can use others and if others does not work we can do something else and so the per exchange is an abent pure Discovery meaning that it happens always in the background so and uh we can see that we have quite a few nodes collected right now right now 25 but the longer the browser tab will be executing will be open the more peers we're going to uh discover and use eventually so from that regard it is peer to-peer and it owns its own stack as to like uh encryption uh yeah so so this provides like a websocket server so all these nodes provide a separate websocket server for these Edge noes yeah exactly this is very interesting because we can uh reason about it as to having a server W application we don't have kind a server but we still can have a connection in between them right it's back endless yes and I mean one thing from the previous uh uh slide I have was the the syncing right so how how does the syncing works because you said you only send messages to like four or five uh peers at a time so how does it know like the me yeah so uh how does the node knows where to send the messages yes was it the question yes so um uh Gossip sub is not a directed uh uh way of routing the traffic and we rely here on eventual consistency let's name it like that we um we know that the node will relay messages to its peers in our case it's four 5 8 something like that right and we know that uh all the peers kind of connected to each other right we uh have it as a a graph um so if someone originates with a message on one end uh by the rules of Gossip sub it's going to propagate till the other end but it can take a lot of time as well as little to time right we don't know where the note is placed in the network work um and I don't mean geographical position but like logical from the the vaku standpoint um yeah so in our simulations we had simulations like up to 10,000 noes and we had the numbers as to uh in average uh from 200 to 500 milliseconds was the message propagation in current tww uh which supports rln as for the meaning to uh shield from the do we have like uh 1,000 the nodes and um the message propagates quite fast yeah and so if the node is offline and comes in right does it get the older messages that were broadcast yeah uh so um this is why we actually came up with store protocol right in peer-to-peer networks we kind of think about the transport right this is uh these are nodes they talk to each other a store everything else it's like application logic uh we agree with that right at each application that uses let's say vaku stack uh or the network uh needs to implement its own like uh stuff on top a store including but we still understand there is a need to have a short lift uh like while I'm offline let's say for 1 hour right I still want to get back these messages so uh store is for full nodes and it's uh going uh once let say your full node goes offline uh and goes online back it's just going to ask the pece around for the missing messages through the store protocol and it's going to do the S thank you any more questions no um let's see something with rust been done and uh if you want we can do some programming or something Co okay thanks Sasha um uh okay in this uh part of the session we're going is it visible we're going to to cover um the a few examples regarding the uh wagas bindings uh by the way credits to to Richard for the great job in this repo and uh this is the the uh in in there well in um QR shared earlier on by by Sasha uh you you will get um uh a branch to do this uh where this is implemented and let me let's uh first of all uh overview the the repo and what we have in there basically we have wuis bindings and the examples and in wuis uh this is the the one that um implements the the nwagu uh this is the the N implementation and from from here we've created or we are working on the creation of um C library that exposes uh all the functionality that that is available from from aaku no the discovery the creation of a note connection to another Pier um H punching um yeah ET all the all the lip2p protocols that we've uh mentioned uh earlier on are covered by the N implementation and in this C library what we are doing is we are exposing these uh features uh through ffi to any any other languages uh at the moment as Sasha mentioned we are covering uh goang rust uh python uh C++ and no GS and okay let's go let's carry on in this particular case um uh then we have the waku bindings crate and what it does is um a li crate uh which is just um a wrap a wer around the gues and in there we have the the implementation of the of the bindings stuff and all the the complexity is uh tackled within this this module and and yeah you will see that uh we we apply a technique called trampoline and that helps us to uh to interact with with rust sorry with the lip guacu library from from rust and then we have the in in this particular case we have a few consumers and this is the just a simple application um well it it uses Tokyo as a sync um framework and what what it does it basically at first it creates a a waku node with uh certain parameters then it establishes the DNS Discovery um URL uh this is for ring the B strap notes in order for the not to start participating in in the network it needs um an initial help and for that reason we we have this um and from there uh many other notes can be infer and then we start the this Discovery V5 uh protocol which is in charge of um discovering other nodes in um in a decentralized way okay this is part of the just of the example of of this application um U maybe the the example is not super idiomatic in terms of rust at the moment but it's just uh a proof of concept uh to to see how uh waku note can be integrated in in Rust and in this particular case the main purpose of the application or what the the Wu note is used in this case is just for for sharing the the game State across users across the the players um okay and given that we have uh a user interface and and something important to to bear in mind is that the the incoming messages by the note these messages are being handled by by the LI Li waku which is implemented in Nim and something important to mention is that this um guacu note is running in a separate uh thread and we need to and the liwu establishes a a communication U with this threat this this is needed because the name run time uh should run separately from any other run time such as the the rust golang uh noes Etc uh in order to uh to to make it work properly uh because um as we are using nowadays Nim we are using it with a garbage collector and it's need it needs to to run on its own thread and something I wanted to mention is that um all the incoming messages sorry for they come in in this closure in here um as we as the example is implemented now it starts the waku node and then we pass a uh we subscribe the node to a certain topic just the game topic and it we pass a closure which is in charge of um getting the incoming messages and with this uh what we are doing is we are um notifying the the main threat about the incoming message so that the game State can be um updated when when you and now let let's do a a quick a small demo uh in this uh in this case uh just we have two inst instances of the TIC Taco application uh on the left um each of them is running a a waku node then we say this is going to play as X and this is going to play as O then they can they can play and well it's a very simple example in this case player x one and okay uh something else I wanted to to share is in this in this presentation sorry feel free to to clone this [Music] example uh because we are going to to play a little bit with it it's just um you will find it in the in the same wakas bindings ripo and it's it's a bit uh more simpler and what it does it uh creates um it's more or less the same but um more simplified it creates a w um waku note we are passing uh sharts uh this this is uh the the chart thing is uh something that is uh needed to split traffic in in a certain way um it's um it can be understood as a way of um channels or communication channels in in Gossip sa uh then we are establishing um maximum of 1 Megabyte uh L level uh content topics uh sorry no uh this is the P subtopic we set the keep alive to true and as we show uh saw earlier on uh we enabled the DNS Discovery and dis B5 okay and in this case uh after that after creating the note uh we just started and then we establish uh we subscribe to to the waku to the to the topic and that's it and in this example it just uh creates a note start it subscribe to the topic and just wait um until a contrl c is pressed and if we if we run it we will see that uh yeah these logs are coming from the implementation of name guo and yeah okay and as you can see the note is starting to receive um Ray messages because it's subscribed to and yeah and that's it and we are receiving messages from from the network [Music] um they I believe they come from estos because I I connected to to the estos um Network and well um just uh that's that's it I don't know if there there there are questions or comments or would you like to to see something else or how how is the DHD look for the Network like what flavor of DHD how is the the DHD look up um being done or you mean um yeah we have a discovery with five client and it it performs um a a request to to the to to to the network and it's uh but so what like how does it decide where to Route the message just just on the peer scoring or um you mean the yeah exactly the the the messages are being routed by a healthy mesh if the um if there are uh peers that are misbehaving or are are spamming the the network then they they are blocked and they don't participate in the okay um in that case uh if no more question think ah yes uh yeah thank thank you for the question uh good question indeed um the as s mentioned um the gossip sa itself it doesn't guarantee the um um a certain message to to reach uh a certain point and for that reason we are working on uh on implementing uh what we call reliability protocols and uh somehow we had um an additional layer of redundancy um and one there is um [Music] um uh sorry I forgot the precise name but one uh previous um uh implementation of or one enhancement is to um um consider that one message is has been received properly if it has been received U by a store note so we uh somehow we use the the store node as a leverage to to reinforce the the transmission of of a of a message but but yeah inde this this is a um a very big problem that that we need to um overcome [Music] and uh and yeah we are working on on it and thank you thank you um any other question um okay in that case thank you so much for the time and and see you see you around