 So hi everyone. In this short demo talk we'll look at VACU, the communication layer for web free and how it uses Serenalge Proofs for its service network. We'll show a demo with VACU for we're using RLand for private economics plan protection and what this means for you as a user and node operator. Finally we'll look at how you can actively participate in and contribute to the network yourself as a node operator, developer or end user. Just as a warning I gave a talk yesterday that's going to be fairly similar to this one but this one is going to be slightly more high level and targeted towards DAP developers. So first briefly about VAC and me. I'm the director of research at VAC. We build public good protocols for the decentralized web with a focus on privacy and communication. We do applied research based on which we build protocols, libraries and publications and we also do custodians of protocols that reflect a set of principles. It has its origins in the status app and basically trying to improve on the online protocols and infrastructure and we build VACU among other things. So as a DAP developer you might have like a frontend and some smart contract and the frontend could be a website, something else like a binary but what about all the other interactions? So in the original web free vision you had the whole trinity with the fear for compute consensus, swung for storage and whisper for messaging. A lot of these centralized applications, DAPs, they make sacrifice in how they function from the way domains work to our websites are hosted and reliance on central services when it comes to communication. And we see this time and time again where centralized single points of failure systems, they work for a while but then eventually they fail. And often individual users, they might not care enough and it's tempting for platforms to take shortcuts and that's why it's important to be principled but at the same time be pragmatic in terms of trade-offs that you allow on top. And we'll touch more on this when it comes to design goals around modularity. So privacy is the power to selectively reveal yourself and its requirement for freedom and self-determination. And just like you need decentralization in order to get sense of persistence, you need privacy to enable freedom of expression. And to build applications that are decentralized and privacy-protecting, you need a base layer to infrastructure itself to have those properties. Synology proofs are a wonderful new tool and just like smart contracts enable program-owned money, Synology proofs allows us to express fundamentally new things. And in line with the great tradition of trust minimization, we can prove statements while revealing the absolute minimum information necessary. And this fits the definition of privacy, the power to selectively reveal yourself perfectly. I'm sure you don't need to tell anyone in this room but it's a truly revolutionary. Technology is advancing extremely fast and often it's our imagination that's the limit. So Breakthrough on Vacus, what is it? It's a set of modular protocols for peer-to-peer communication. It has a focus on privacy, security and being able to run anywhere. It's basically the spiritual successor to Whisper. And by modular, we mean that you can pick and choose protocols and how you use them depending on various constraints and trade-offs. For example, banner of uses versus privacy. It's assigned to work in resource-resistant environments like mobile phones and in web browsers. It's decentralized, sensor-persistent and blockchain agnostic. So here's an example of use cases for Vacu. So for example, status is using it for its chat functionality. WorldConnect is partly using it for session management. Railgun for its relay network. And you can use it for things like multi-seq coordination with GNOS is safe. There are currently three main implementations, JS Vacu for browsers. Go Vacu, which is optimized for usage on mobile and desktop. And it also has bindings for things like Kotlin and Swift. Vacu in NIM, which is the main service node and where all the resources are happening. And there's also an experimental version in Rust. Just briefly on some protocols that are used. So we specify how our message are formatted to facilitate things like encryptions and signatures, a relay for sending and receiving messages. And this is based on LP2P gussup. And then there are also protocols for more light usage, like filter, light push and store. These are used by nodes that are maybe not always online. Or they might have some connectivity or bandwidth restrictions. There's also RLN relay, which is used for peer-to-peer economics ban protection using CK Snarks, which I'll go into soon. And there are other products here as well. But these are the main ones of the interest right now. So one way of looking at Vacu is as an open service network. There are nodes with varying degrees, it comes to compabilities and requirements. For example, when it comes to things like bandwidth usage, storage, uptime, privacy requirements, latency requirements, and connectivity restrictions. We have this concept of adaptive nodes that run a variety of protocols. And node operators can choose which protocols they want to run. And naturally, there will be some nodes that do more consumption and other nodes that do more provisioning. And this gives a rise to the idea of a service network where services are provided for and consumed. This is one way of looking at the Vacu network. We have a bunch of nodes with different capabilities and they run different protocols. And for the Vacu network, there are a few problems that arise here. For example, when it comes to network spam and incentivizing service nodes. We want to address these while keeping privacy guarantees of the base layer. So the spam problem arises on the gossip player where anyone can overwhelm the network with messes. And the service incentivization is a problem where nodes don't directly benefit from provisioning of a certain service. This can happen if they're using the protocol directly themselves as part of normal operation or if they aren't socially inclined to provide a certain service. And this depends a lot on how individual platforms decide to use this network. In this talk, I'm only going to go into the first one, but I also gave a talk yesterday where I touched on the service incentivization a bit more. Since the peer-to-peer relay network is open to anyone, there's a problem with spam. And if we look at some existing solutions for dealing with spam in traditional messaging systems, a lot of entities like Google, Facebook, Twitter, Telegram, Discord, they use phone number verification. And while this is largely civil assistant, it's centralized and not private at all. Historically, whisper use-proof work, which isn't really good for heterogeneous networks. It's things like peer-scoring, but it's open to civil attacks and doesn't directly address spam protection in an anonymous peer-to-peer network. And the key idea here is to use RLN for private economic spam protection using CK Snarks. I'm not going to go into too much detail of RLN here. If you're interested, there's some write-ups on VAC.dev by Snouse who's been pushing all of this from our side. And Taylor is giving a talk, which goes into the RLN circuit in more detail in a few hours in this room. But I'll just talk briefly about what it is. So RLN stands for rate limiting nullifier. It's an anonymous rate limiting mechanism based on CK Snarks. By rate limiting, we mean that you can only send N messages in a given period. And by anonymity, we mean that you can't link messages to a publisher. We configure it as a voting booth where you're only allowed to vote once every election. It can be used for things like spam protection in peer-to-peer messaging systems and also rate limiting in general, such as for a decentralized capture. And there are basically three parts to it. So you read this somewhere and then you can signal and file in just a verification and slashing phase. You put some capital at risk and this can need to be economic or social. And if you double signal, you get slashed. So each user has a secret identity key and read this as a commitment of that in a contract and deposit some funds. And this makes them a member of that RLN group. And the key to withdraw that fund is the secret identity key. And if someone knows that secret, they can take their social funds. And for each epoch, the user sends a message by proving that it's a member of the RLN group and it reveals a secret of its secret identity key. The shares derived in such a way that two of such shares in the same epoch allows construction of the corresponding secret ID key. And the secret sharing has another element, which is an application defined identifier, which is the RLN identifier. And with that, you can sort of make the secret sharing unique for your application. So for example, if a user wants to use the same membership credentials for two different apps for messaging, then it can do so without being worried about getting slashed by combining two shares from two different applications. So here's a brief recorded video, see here, it's playing. So what this is showing is that on the right here you have JS Vacu running browser and you connect to your wallet and then sort of pulls down the state from the RLN contract, including the some number of members that are there. And then after that, you generate RLN credentials locally. So that's the secret key and then also the kind of the public key. And then you basically register that in the smart contract. It's going to take a while until it gets through. And then on the left here you see in Vacu, which is sort of this service node written in NIM, and that's going to listen for events from the contract. And there's also this example chat application that you see in the top left. It will take a bit of time to go through. And then basically the next step after you have registered is going to be the singling right. So this is using Vacu in the kind of light mode, using light push stuff to that. Here you can see on the bottom left you see that the new key's been added. So it's receiving the public keys from the smart contract. And basically opting is mochal tree because it needs that in order to do verification and slashing. Now the transaction has been included. See here? Yeah, that was a bit slow, one second. Right, so here you're actually sort of sending, so in this case it's just using this very light mode to connect to the Vacu network. And then you're sending a message. And once you send a message it's going to construct a proof as well as some additional metadata that's needed. And then it's going to sort of basically propagate that throughout the rest of the network. And all these nodes that are running all in really will sort of verify that. Verify that proof as well as make sure that the Seekie proof is valid, that it's not double signaling and it's in the right epoch and these sorts of things. So you can see here it's been received. Yeah, and it's going to keep relaying it to other nodes. I'm actually going to skip to the next one here just to show how spamming works. Right, so in this case we have, I think it's a unix, the epoch is basically like a unix time, like 10 seconds buffer. So that means that if you send more than two messages in a 10 second period, then that will sort of, it will be an invalid message basically. So now you're going to see in the bottom left that it's, yeah spam, so spam message has been found and it's going to drop the message full of variations. So it means it's not going to propagate it to other nodes basically. And slashing is not fully implemented yet in the, in the, sort of this client, but it's work in progress. Yeah, just some backup slides in case the demo didn't work here. Right, so now what, you can, you can build stuff with Vacu today regardless of what platform you're on, if it's a mobile browser on a server or whatever. You can take it to vacu.org, we'll talk to some people from the Vacu team here. I also didn't go into too much detail of this here, but if you want to play with this library we're building, you can also do this with Syracuse. And this basically enables you to use all the unfold applications outside of Vacu in different environments. So maybe it's not just a browser application, but you want to do something in Rust or with Python or whatever. So this can be pretty useful because as a CFFI API and what's an API as well. And you can also run a node and this helps the network and is a fun way to sort of get some more hands-on when it comes to peer-to-peer and CKinfra, even if you aren't super technical. Yeah, I'm going to check out Discord and say hi as a QR code here to the Vacu Discord. Here's some links. If you find anything that's exciting to work on, feel free to come up to talk to me. And we're also hiring.