Bringing peer-to-peer networks to ALL the peers by Franck Royer | Devcon SEA

[Music] all right thank you very much hi everyone let's get started so bringing PP networks to all the peers what are we talking about so we are trying to create a peer-to-peer model for unuser devices to be included in this model and by and user devices I mean desktop app mobile app web app in the browser and here more specifically we are talking about leave P2P goip sub based networks so for those who don't know gosip sub is what is used on the ethereum network for the Bon chain as a network layer so the current status quo across most peer-to-peer network is that we use R apis we three apis um and other web getaways to allow users in the browser mobile and desktop to access a p to-peer network usually anyone could run such API if they have the resources but when building applications with web apps or mobile apps um usually the users or developer will select one API maybe or maybe a couple so this does create some problems and and we're aware of that you know in the eum system and initiative like like client try to solve this problem around trust data access and propagation privacy and and censorship of this API I'll go in more detail at the end for that so the first problem we had to want started to use goip sub on again laptop um potential mobile and browser is that it has very unstable connections so if you want to compare that to e node for example when you're staking usually you run your node on maybe r byi or dap node or some on VPS U where connection is quite stable but on a laptop you're are going to change Wi-Fi we going to go offline the back online and go doesn't have any mechanism to help you with this specific scenario so there's no acknowledgement um to know whether your online is a bit hard can be have some time out from TCP and you can miss messages when you're on when you're offline right because once message goes through the network is gone so solution we we develop is uses um goip sub and this5 for desktop as well as a smart contract and zero knowledge based rate limit to ensure that you don't have too much bandwidth too much traffic going on the network so you can support it Network on household bandwidth and we have a number of L P2P request response protocol to enable uh browser and mobile to query for for more peers uh because this V5 can consume a bit too much um bandwidth and and resources and I was able to push messages and get messages from the ghub network so you still have a light weight to get U messages but it's much still it's more much more decentralized than the rest API finally in ter of Shing know if we start to put 10,000 or of thousand of users on the ghost sub Network um unlikely to work so we do separate I would say the global Network into smaller go of network via sharding so if you have a quick look at how it could work um so we have service nodes VPS that run in the cloud they allow a mobile phone to go and query for messages they missed um mobile phone could subscribe to desktop node and say hey can you please for messages that I'm interested in um desktop node goes offline and then back online can also quate messages to a service node in the cloud and fin your browser can push messages to service no via web soet that we then get uh pushed on the G sub layer which we call ho in our case all right so we we did have to um add resonancy right because has some inbit bit in Rundy we had to add that when for pushing messages we uh push to a couple of uh of Nod and we also had to add and to and relability protocol so that in a context of a chat application you know whether or you have some idea whether your recipient other participants in the group have seen your message and the result is that now you have some uh Rony and you can check message presence using um various nodes to access network instead of trusting one single rest API you do have some improved privacy because instead of having all your traffic going through one RPI you can select various peers and decide what traffic you uh you ask from them or you push to them and in term of censorship as well it means that you not R you do not rely on a single DNS single domain name for example and single rest API uh which could be censored or blocked but instead you apply a peer to peer Discovery strategy allowing you to access the network via different PE that's it for me five minute presentation I think question for time for questions thank you very much uh so we're going to have a bits of time to to ask some questions are there any questions please raise your hand um I think you mentioned status as one of the users is are there any other apps using this uh stack or approach you highlighted yeah of course so yes so the status chat app um use that and they have a mobile app and laptop and desktop app we have red gun red gun is a private defi um systems where they have a z SM contract and you can do defy without revealing your address and they do use waku on their mobile web and desktop app where the wallet has waku running um inside with the l2p and um I can send messages can send basically the transaction the proof that they have a note to broadcaster which are not in the cloud which then take the transaction from the wallet and push it on chain okay thanks and we also have other project uh I mean regun and U status are the most advanced one the most mat ones I think there's another question in the middle no okay now go ahead uh hi so my question was first is why rest and second is why not grpc or RPC why we not using grpc yeah grpc or RPC so in in the case of so in of lower lower protocol stack right um we using TCP and web socket I'm guessing you're talking just above why not using grpc instead of lip2p I guess yes so lip2p does come with a number of useful tools so when we start to buid and starting to use goip sub for example um it means that we start to we are introducing one technology stack into into the system right so we use thep GOP sub and when we want to look at request respon protocol we could indeed start to use grpc or rest API but this mean introducing new technology stack into the system which means that having a heterogenous technology stack means you know you may have more problem and um so it's just easier to continue using lip2p and Define this request respon protocol on top of lip2p and lip comes with with good things such as um you know the noise handshakes right so you have a point to point encryption with d2p out of the box um so you can just use that out of the box good question so we have time for one last question over here could you share a few more words about the sharding idea is it um if I have an application that grows massively would it start sharding itself automatically or work awesome awesome question so the idea with charting first is that you you know let's say you have a billion user right um all the messages they they generate would be too big to go through one household bandwidth right so the idea is to SP networks that you only look at messag you interesting in the that's a writing layer we have a Content topic which is metadata like just a string that you can attach to messages which allow you to further filter messages you looking at so on mobile you are going to only look at specific content topic which will be a subset of messages on The Shard so now you have several options you can either um come in and your application use one content topic and you're going to just be part of one chard um and if you grow up then you may want to look at seeing if you can use more shards or you can start in and have actually a big application from the get-go and just try to split over traffic from the get-go in terms of you can start with one Shard two shards or three shards instead of of growing to more shards it's just a consensus between operators so you can say okay we need two more sh on our Network and you can just tell your operators can we please support charge 10 and 11 now and they can start to support it and you can start to diverge traffic for it so it's bit of manual process and we haven't gone through this uh course pen yet but is um it's many operator consensus here thank you very much much that was the last question so give some Applause to Frank