DAPPCON 2024: Waku - A Decentralised Communications Infrastructure For Your Dapps - Kumaraguru

Transcript

hey everyone this is Guru I'm one of the co-contributors of the waku project and I do develop relations for waku so starting with a problem statement we two Communications do not preserve your privacy out of the box so uh this is something that exists in all forms of web to communication whether you use sockets or anything that involves HTTP end points so your interactions online can be e dropped by multiple centralized applications and your social graph and your private metadata can be exploited by these centralized Gatekeepers so your messages that you send on web to are mostly linked with your IP addresses and your IP addresses can reveal a lot more information than

you actually think so basically it can reveal the sender and the receiver and also information like location the sender and receiver and along with this a lot of private metadata which can be for application specific processing and this information can facilitate large scale censorship or surveillance attacks around the world it can also hinder freedom of speech and this is not a problem that exists just with chat but pretty much with all the web 2 applications that can be in gaming marketplaces or location sharing apps or anything that involves machine to machine or machine to Human communication so to solve this uh we've

been building waku waku is a family of robust censorship resistant communication protocols designed to enable privacy Focus messaging for your web3 apps so we've stick on to six main ethos the first one being censorship resistance and privacy and we also have modularity by Design which means that you can use vaku with any blockchain of your choice or it's not even a blockchain vaku is something that can complement a block chain vaku is also adaptive we have different implementations for uh different resource restricted environments and it's securely scalable meaning that we don't compromise on the level of decentralization for scaling and most importantly I think personally

my favorite of all the all these ethos is Dos protection a lot of web3 networks that exist right now are not dos protected and even if they are DOs protected or rate limited they use centralized methods to do it but at vaku we've uh We've integrated rln rate limiting nullifiers which makes sure that we have a privacy first approach for uh rate limiting we'll be talking about it in detail in the upcoming slides but moving ahead uh these are some of the misconceptions that we usually have vaku is not a blockchain vaku is not just a chat messaging protocol but vaku is a generalized communication protocol that you can use for sending any kind of data between notes it's more on the network

level built on top of UDP and TCP so you can pretty much send any kind of data less than uh 1 MB and you can use vaku in multiple use cases revolving around gaming marketplaces State channels and again anything revolving around Communications which can be machine to machine machine to human or human to machine so talking about the history of vaku it all started in 2013 when the ethereum white paper was released we had the Holy Trinity of decentralized web which was ethereum for consensus swarm for storage and Whisper for communications but over the years uh as a developer Community uh We've forgot to you know focus more on other things like

swam and Whisper and there's this misconception that blockchains are web three and there peer-to-peer Technologies and a lot of other Technologies which also contribute to the web3 vision or the ethereum vision until 2020 uh there were there was not much of uh you know teams working on whisper as a protocol for R&D but in 2020 waku V1 replaced whisper in the status app vaku is an iteration of whisper we had a lot of architectural changes happen uh you know in the course of time and in 2020 status is a messaging app which migrated from whisper to waku today we are trying to evolve as the standard for web3 communications we trying to be as unopinionated as possible and we are

trying to build for the uh open-source communities around in web3 so we also had a mention in vitalic blog uh in December last year vitalic mentioned that vaku whisper still exists as vaku and it contributes to the deeper vision of peer-to-peer communication which can complement something like ethereum so this was one of the diagrams uh framed by Gavin Woods where ethereum smart contract ta are for consensus swamp for uh you know content address storage and Whisper for dynamic Communications so Dynamic Communications U should be gas free and that's the same

Etho that we trying to stick at uh waku as well vaku does not have any consensus as a network so it's open for anyone to push and uh subscribe to messages from a particular name space so going ahead vaku in shell has two main components the first one is the vaku protocols which which are a family of protocols and the vaku network which is an opinionated Network that we've built at waku so talking about the distinction of notes at waku we have two types of notes light notes for resource restricted environments like your mobile phones mobile apps or browser apps and we also have relay notes which are uh which

usually run in resource Rich environments like clusters or VPS servers So based on the category of the node we have different protocols to catter each of these categories the first one being light protocols which can work in resource restricted environments and relay protocols for uh the resource switch environments respectively so this is a diagram which can visualize uh the adaptability uh you know vaku can work in something as resource rich like a cluster we PS or Home Server with uh you know relay protocols and with lighter protocols you can use it on phones and browsers in less band withd environments so today I'll be uh

covering mostly the light protocols uh we have detailed documentation about relay protocols in our developer documentation and we also have rfc's and research articles for each of these protocols but light Protocols are the ones that are mostly used in consumer apps or in hackathons so talking about right protocols we have light push filter and store and each of these protocols have a different purpose but if you want to send a message data into a Content topic you'll be using light push for this light push basically pushes a blob of data into a Content topic and we use filter for retrieving or subscribing messages from a Content topic and content topics are

nothing but name spaces that exist within the vaku network and store is a complimentary protocol that we have for providing temporary storage for your messages that you send on the network and also uh to talk a bit more on stor we don't uh have any guarantees or Assurance with store protocol as of enough because vaku focuses more on the transport side of things but for long-term storage we definitely recommend you to use something like uh ipfs filecoin or codex uh for long-term storage and it's important to have Perpetual storage because uh at vaku store protocol uh the content of the store protocol usually gets cleared out

every 30 days so it's more for temporary storage and going ahead looking at the content topic architecture the whole vaku network is divided into content topics we have different name spaces like over here we have topic a topic B and topic C which are three different content topics and there can be multiple notes listening to different content topics and sending messages to different content topics and all these content topics are public by Nature just like ethereum so anyone can send a message into any content topic And subscribe messages from any content topic so for any kind of Access Control it should be cryptographic you can use something like lid protocol or uh something like threshold for doing this before you send

data into the content topic so it's important to set up encoders and decoders to make sure that no one else uses the same content topic as you do uh we also have U for just for simple use cases we have encoders and decoders within our SDK but for more deeper and wider use cases we definitely recommend you to check out other access controls but the way in which we declare a Content topic is based on this particular template it starts with the application name followed by the version of the application followed by the content topic name or the category finally ending with the encoding type an example for this would be super crypto which could be a name for your

application version could be one and notification can be uh the category of messages that you you know communicate with this content topic and you can also have Proto as the encoding uh so we use Proto buff for uh encoding and decoding in our uh documentation So based on the encoding standard that you use you can change it accordingly we also have a a structure for each and every data packet that sends that is getting sent into the waku network so we have different terminologies right now some people call these data packets as messages uh mostly developers refer this to be messages but uh Semite technical people misunderstand messages to be just chat messages so

messages here means that anything that uh you know gets sent from one note to the other is you know that's what we call messages over here and the maximum limit as I mentioned before is like 1,000 KB so we have the content topic as the first attribute that goes in uh the content topic is used for Content based filtering and you should be filling the content topic into which you want to push the message followed by payload which basically contains the message data and we also have a meta attribute for application specific processing followed by time stamp which has the time of the message when it was sent and finally we have an ephemeral property

which is a which can be a Boolean property here if you can vaku is not ephemeral by default which means that the messages that you send into the network are evaporable uh so it's not getting stored in the network so if you want to use St protocol you should be setting Emeral to true so that the message stays on the network for uh 30 days anyone can contribute to the vaku network by running your own node and we have a Docker compost command uh if you're interested to try running a vaku node there's no incentivization for running a vaku node yet uh incentivization is currently work in progress so yeah this is the simplest way to run a waku

node and we also have technical uh you know research specifications in this RFC uh it's available on V RFC do.de which is our request for comments uh in a collection of all the rfc's that we've have we've had for the protocol so another important thing that we consider at waku is uh vendor lock in so there are a lot of web3 protocols or products which still have vendor lock in which mean that once you start using the protocol you cannot uh you know migrate it to a different one or you you cannot self host it in a later stage so uh making sure that vaku doesn't have a vendor lock in is was very important in

a lot of decision making so vaku is privacy first by Design and we have two ways of using vaku the first one is running your own Fleet of vaku notes or running your own network or the second way is using the vaku network which is a network that we've Federated for developers or for projects to readily use vaku without having to do much of federation things so when you run your own custom Network it's still privacy by Design and even in the vaku network it's privacy by Design we don't have any architectural changes and all of the code for running a node is available on GitHub it's open source and both running a custom Network and the waku network

can provide you modularity and adaptiveness the one uh differences or the one advantages that you have with the vaku network is it's batteries ready which means you don't have to Federate you can just use the vaku network along with the SDK to send and receive messages without much setup and it's also rate Limited by default uh not by default but you you can choose to opt out of it I I believe but then uh rate limiting is a very novel feature that we've introduced with the waku network so no one can send like thousand messages to thousand messages in a minute to put waku Network down so rate limiting exists in waku and we also have node operator incentivization work in

progress with the waku network uh with the custom Network you don't have to have a incentivization for your node operators a lot of partners that are using waku right now have an in-house Fleet of vaku nodes running and they don't have any kind of incentivization for it obviously but if you use the waku network you can expect incentivization to be there for node operators uh down the road but we are actively researching on it it's work in progress also the one closest uh technology that can be compared with uh vaku in the web3 spaces Li P2P at least for me personally because we have communication protocols like XMP and a

lot of other protocols which are actually built on top of vaku so XMP uses vaku notes uh behind the hood so I think the one lowlevel protocol that exists in their web three space is going to be lip2p and the relationship between vaku and lip2p is uh both of them use gossip sub and vaku is built on top of of lip2 it's a service network built on top of lipy TP and gossip sub is the mechanism in which ethereum notes talk to each other so vaku enables Discovery in a decentralized and privacy preserving Manner and by default lipy top does not preserve your privacy your IP addresses are getting exposed when you use lip2p so these are some of the

modifications that we've architecturally implemented in vaku and uh with light clients uh lipy has JS vaku which is the typescript implementation of lipy and uh in vaku we have Js vaku which is pretty much solving the same problems and uh we also have protocol Ming working you know compatibility to work offline and Native roaming and all of these features in both uh lip2p and vaku but apart from these features vaku also provides you some uh upper hands like vaku is a service network it's also a turnkey solution and we we Implement economic spam protection or dos protection like I mentioned before so these are the

advantages of using waku directly rather than using something like lip P2P which complicates a lot of your development process talking about Rin uh rln stands for rate limiting nullifiers uh it's a technology that was uh collaboratively built with privacy scaling Explorations in the ethereum foundation so we had a lot of researchers from vak which is our Research Unit work with PSC team for shipping out this and vaku is one of the first few projects who is trying to implement rln on a production level so we have two segments in uh decentralized rate limiting process the first one is a

membership contract which has a membership set deployed on the smart contracts uh you can deploy this membership contract on any blockchain of your choice but right now it's available on testnet and yeah this membership contract interacts with the zero knowledge proof that is attached with every message that you send into waku so this is how we Implement rln so every time you try to spam the network or uh every time you cross your uh rate limiting the network basically doxes you so you get punished if you you know cross your rate limits that's how the whole concept of rlin is implemented in vaku I also have a quick simulation of how

fast a vaku message can be sent it starts from Singapore goes to India now to San Francisco and to New York and finally back to Frankfurt all this happens in like 20 milliseconds and it's simulated with a real time uh size of 2 KB data with realtime machines so this is how performant and competitive we are trying to be when compared to web 2 communication product protocols and we also have a couple of resources the first one that I want to highlight is the developer documentation it's available at docs. vacu.org and we also have a list of ideas that can be built on top of vaku uh they Community

curated ideas and you can find them out at ideas. wu. and finally you can find all the presentations videos from all the presentations that we've done in the last couple of months and we had like around 90 projects submitted at different hackathons for our bounties so all these projects are visible at awesome vaku n GitHub so these are the three main resources that can be useful in exploring more about waku I also want to highlight a few of the projects that use waku some of the projects from hackathons that we around the world so the first one is block iot uh the project implements an iot system that can communicate using vaku

protocols so if you want to make a home automation system but you don't want a centralized entity to know about uh you know your electricity usage or any kind of metric you can use Baku for this and you can also connect different iot devices for this so this was one of the most exciting projects we've had and we also had Becca Mouse which was one of my personal favorites it was from eth roome last year and it basically implements a privacy preserving wallet to wallet location sharing so right now with uh the location sharing options available in iOS or Android the location is obviously shared with the centralized entities uh like apple location services

or Google location services so this particular application enables you to share the locations peer-to-peer with the wallet of your choice so it it was really sleek and the application was uh pretty much production ready so this was one of my favorites and we also had a couple of games uh built on top of vaku we had a multiplayer trump card game built with waku where you can collect cards and also battle with other people so you can also build fun things with waku and uh one of the recent Bus Around the AI a convergence of AI and blockchain is data privacy right now when you use uh centralized llm

platforms uh all the LM platforms collect your data and they need to do it because they use it for uh recursive training in a later point of time but um there is it makes no sense for them to collect your identity coupled with the data so that's where vaku can be a middleware making sure that uh the prompts that you send to any llm platform get decoupled from the identity so right now the platforms can find out what you're searching for on uh you know these platform forms and they can advertise you based on what you're searching for and we also had a recent Buzz that most of the data from chat GPT was traded with another centralized entity for uh you know just in the name

of uh machine learning which doesn't make sense because people obviously search a lot of critical things in these llm platforms without understanding this uh big risk so this is where vaku can come as a middleware and you send your prompt to vaku and there's a fil node running on the other side which basically you know takes in the prompt and processes The Prompt so waku can be a good fit in compute marketplaces in llm platforms and you know in the whole sector of machine learning yep so if you want to learn more about waku if you want to see some cod Snippets you can find them at docs.

wu. we also have some example apps set up for you to try out it's available at examples. wu. and please feel free to join our Discord where we uh post our announcements every week we also make sure to be as open as possible we have around 17 co-contributors working for the waku team and uh we post out our weekly updates over here and also on our Twitter so make sure to follow us over there and we also have a nextjs boiler plate for anyone who's trying to build on top of vaku I know there's a lot of uh PR Pro privacy hackathons coming up in the next couple of weeks there's e Berlin followed by epr so all of these hackathons have privacy as the core

angle so if you want to experiment with waku uh make sure to check out the next JS boiler plate which has less than 100 lines of code but has a complete implementation of vaku I can also run through the code real quick and show you how uh the code should actually look like so we are also actively working on refactoring our SDK so we'll be having a new SDK in a couple of months or a couple of weeks depending on the uh development that we've having but uh yeah right now we have an SDK available for Javas script and uh it's very simple you'll just have to install vaku directly from our documentation and then

once you do that you can uh import the dependencies which are listed here create light node for uh creating a light node instance and wait for remote PE is for peer Discovery and we also have encoders and decoders within our SDK where we have create encoder for the encoder and create decoder for creating a decoder and as I mentioned before we use protobuf as the encryption and decryption standard for most of our documentation at least so we also installed the particular package protop of JS for JavaScript and after that it's pretty much simple you just declare a Content topic the content topic should follow the naming convention that we

discussed before and after that you create a message object over here I have a chat message object which has a time stamp and a data so this is how you template a data object that gets sent into waku and once that is done uh you can have a function for sending data which will be coming back again after we set up the node but before that we have a use effect hook which uh sets up a node by using the create light node command and in the create light node command you can pass this specific uh thing called default bootstrap you can set it to true if you want to use our default bootstrap notes we set up a

bootstrap notes to make it easier for developers to build at hackathons or just to experiment with waku so you can set it to true if you're trying to experiment or you can also set it set a particular set of fleets as the bootstrap noes uh you know alternatively but going ahead uh you just U you know start the node by node. start and that should get your node started and after the node is created that's when you have uh pure Discovery so for this we have a function called wait for remote pure this function basically waits for other uh peers to connect to your vaku node so the way it works is light nodes get connected to another relay node and these relay node

carry out most of the you know resource consumption or resource operations that require a lot of resources so once uh you know the remote peers are connected you can go ahead and create your encoders and decoders for this you can just uh you know Define an encoder using the create encoder function inside the create encoder function you can have the content topic into which uh the message should be pushed and you can also set the Emeral to be true or false over here so if you need to store the message just set it to true and after that you can set encoders and then similarly for decoders you just uh use the create

decoder function uh to pass in the content topic and then your decoder should be set up successfully and you also need a call back for uh retrieving all the messages from your filter so uh it's pretty much simple you you have all the code Snippets available on documentation you can uh you know get the payloads in different formats and you can find more in-depth explanation about this in do in the docs and the way in which uh the filter notes work is based on subscription waku follows a pubsub architecture which means that uh you subscribe to a particular content topic and you keep receiving messages from the content

topic so that's pretty much it you've uh I think the only part that we missed is sending the data so for sending data you just have to uh you know create the message object just like we mentioned before and then serialize the message using you know the encoder that we just created and finally you can use light push. send function for you know pushing the message into the content topic you'll just have to pass in the encoder and the payload into this function and it gets your message into the content topic so if the fimal is false the message is getting transmitted are real time which means that you cannot um you know expect

the message to be saved in the network for a particular amount of time so yeah that's all about sending receiving and storing messages with waku and this boiler plate is available on uh GitHub in the link that I shared before and it also has a you know very simple UI that explains you step by step about the processes that are happening behind sending and receiving a message and this can be the most minimal example that you can try and we also have other applications like guacu which was developed by one of our core contributors in vaku team this is basically an application where you can uh you know host question and answers so you can just share the link with other

people and they'll be able to submit ask questions through this link and it it will pop up for me over here and I also believe uh polling is available or it's going to be available really soon with Kaku so we are trying to build all these experimental stuff we have a couple of open bounties for developers to you know earn a couple of maybe a th000 or 2,000 bucks for doing all these examples so you can find more about waku bounties at bounties vacu.org we just trying to you know Implement vaku in more of non- chat use cases because there are quite a lot of chat applications that use waku so we are trying to explore non- chat use cases but when we talk about the

Enterprise Integrations with waku waku is being used by projects like X SMTP also the graph the graph uses waku in a very novel way in which they try to decentralize the indexers by pop sub communication so graph and we also have rail gun which is a a privacy focused layer to on top of ethereum so rail gun also got a mention from V in the last couple of weeks so uh they've been buzzing in the web3 space for quite a while and they are using waku as well so there are a couple of projects that use vaku in the production but we also acknowledge that there are a lot of issues with the SDK because of the rapid changes that we are doing and a lot of

features getting delivered so feel free to join the waku Discord and if you have any questions or if you have any if you need any support the co- contributors are always available to help so that's all from me for today but if there are any more questions I'll be happy to take a few questions uh hi thank you very much for the for the talk could you elaborate on the sensorship resistance uh for example I saw that you had to connect to bootstrap nodes at the beginning and the network packets could still be monitored and bled by ANP is there some workarounds around it yeah so censorship resistance over here is in a way that we

don't we don't need the identity for a message to be published or subscribed so let's say there are two actors in the note Bob and Alice so if Bob sends a message into a namespace or a Content topic uh Bob will be sending it inside the namespace and he doesn't necessarily have to you know provide any wallet address or any kind of uh identity to support this uh message so the IP address is also so not included as a part of the message and the other end where Alice or other subscribers are subscribing to the particular name space will not know the message is from Alice is from Bob so that's how we decouple the identity of the sender and receiver

by using name spaces and with lip P2P it's uh you can definitely find out the IP address of the peer who you are connected to but with vaku that's where we are having a novelty where you can't find the IP address of of the connected Pier uh you talked about uh chat applications but uh for example let's say you wanted to build something like forast or decentralized Twitter um could you describe how that would work like is I understand there's a storage solution for it or yeah so for foraster uh I assume there is a need for storage definitely because uh

once it's something like Snapchat once once you send a message and once it's uh delivered to the other Pier uh the message is not on not stored on any uh any specific database or any specific storage that's how vaku naturally is uh for proof of concept for something like farcaster you can definitely use store protocol but we also uh want to be transpar that store is currently centralized but uh we also have you know other Solutions like CeX which is a Content address storage like ipfs or even ipfs uh they can be the right fits for these use cases so you store these messages on ipfs or if a user wants to send a image over vaku which exceeds 1

MB they can store it on ipfs and the CID gets transmitted on waku it's not the whole uh you know file getting transmitted on waku so this is how we are trying to solve messaging use cases and status has been already doing it for the last couple of years but for farcaster definitely like uh they can readily Implement vaku uh and it can solve a lot of privacy issues that exist in social media applications in web too thanks for the talk with respect to rln is the rate limit configurable and if it is how is it configur who gets to set the the rate limit right so right now rln is still experimental in our

stack uh but we've been uh getting a lot of good feedback from different teams who are trying to dock food it but uh for the network we have a rate limit for the at least the waku network we have a rate limit of one message per second which is just for you know the uh current uh timing but then um Rin is rlin depends on the you know reputation system that you create for a particular Identity or a particular pure that way uh you don't essentially get to spam the network with like thousand messages a second and you get blacklisted in your IP or your identity gets doxed once you cross the limit so Arlin uh you know there's a smart contract deployed on the

blockchain which basically has the membership set of all the you know Pier or all the membership contracts memberships generated from the contract so this is the only segment where vaku has a blockchain part of it apart from this waku is more of a privacy Tech protocol than a web3 prot protocol but uh yeah right now uh for the waku network we have one message per second as the limit which is totally customizable depending on the shared resource that you have in your uh you know set of bootstrap fleets yeah so feel free to reach out to

me if you have uh yeah I can take a few more questions um thank you so much for the for the presentation first I have a question around you mentioned that the graph is using waku uh is it using it like uh Kafka cluster like following like a pobub architecture um if it's using it like that those are many many calls and you will definitely hit the rate limit uh how are they handling that yeah so right enough all the Integrations that we have currently don't Implement rln rln is something that we've implemented only in the vak network but the way graph uses this uh graph has a separate team called graph Ops within their organization I

believe and graph Ops has graph cast which is one of their uh you know exactly where vaku is being used and also I believe subgraph radio so that's where vaku is being implemented so right now they have uh you know they've just statically uh declared the rate limits for the time being they don't implement rln or any of the uh decentralized rate limiting U as of enough so they have like a def you know static uh number defined to the number of messages per second which is not the right way to do it but uh the graph team is also helping out with us in do fooding rln but uh it'll be in production only after like

uh it's you know battle tested for quite some time but yeah that's how graph is using it and I have one follow up question um and in such Enterprise scenarios uh there's a lot of data privacy issues and regulation that companies has to follow um when using wacko the the data is just decentralized the data is anonymized and there are no regulations there how does it work yeah it's very tricky uh to be solving this particular problem in this space because there are a lot of you know Bad actors as well like waku can also be used for a lot of dark F use cases or a lot of use cases that cannot

stick to the ethical values I would say but in terms of privacy it solves a lot of bigger issues like uh people who try to use Messenger on a web to platform they are more vulnerable to be you know every time you send a message on a web2 platform uh the general web3 public who is not much technical would not know that their message is passing through a lot of servers a lot of http eight ways and it can be intercepted anywhere at any point of time even if they are encrypted so that is the biggest problem that waku is trying to solve I'm trying to be more permissionless and more trustless so there are a lot of Bad actors definitely but we are uh trying to address all these problems on a long

run yeah thank you thank you thanks for talk uh one question um as I understand the um relay nodes are acting as a storage for the messages itself so the name spaces storing the name spaces with a payload so how do you guys uh or how it's in a scenario when a certain set of nodes keep that keep these uh or this node uh name space they are detached from the network netor in a case of a

censorship for example what does it mean to the network in a whole I mean is this namespace completely lost uh is the data completely lost or is it somehow replicated between the nodes yeah so Nam spaces are primarily used for Content routing so they are like an address uh through which uh the messages go through and like on on a storage perspective right now the store notes uh you know the content topics one store the messages if the feral is said to true but on a long run if vaku is used with something like let's say ipfs

that's where uh you can make it completely ephemeral where you don't lose the messages and there's also another problem that we are trying to solve at vaku that uh the message delivery is also not guaranteed right now like you don't know if a message reached to a particular node uh if you send it with vaku but there are many projects that Implement novel mechanisms like pinging uh or sharing a secret to make sure that um a message was delivered so these are all in proof of concept stage uh you know different Enterprises are using uh different ways to solve this problem but uh when we talk about name spaces and the EV operability of EV operability of storage I think it's mostly like like name

spaces are just for Content routing rather than content storage but for solving this issue I think something like ipfs or codex is going to be the answer so we are actively working with these storage protocols to understand uh the requirements we've been uh doing a bunch of things with ipfs but it's pretty hard to implement storage with ipfs without having to depend on a https Gateway so you know if you want to run a ipfs node locally and if you want to pin the file uh it's pretty hard but if you want to do it with a you know Gateway service which depends on https endpoints it's possible but we don't want to you know depend on HTTP endpoint for that so that's the only blocker that we have right now with

storage yeah cool then I think uh I'll wrap up the workshop with this but if you have any more questions feel free to reach out to me I'll be happy to take take it oneon-one yeah thank you