Anna (00:05):
Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. This week, we talk messaging with the team behind Waku from Status. Guests Oskar and Sanaz share with me the history of the Status project, Whisper and its limitations, Waku and Waku 2, and how this privacy-preserving peer-to-peer messaging protocol for resource restricted devices incorporates zero knowledge proofs. But before we start in, I want to remind you to check out the ZK Jobs board. If you're thinking of switching paths or jumping into the zk space, this could be a great place to find your next opportunity. To the job seekers, I've added the link to the ZK jobs board in the shownotes. I also want to thank this week’s sponsor Least Authority! Least Authority has a long history of working with privacy enhancing technologies, including Zero Knowledge Proofs. With current projects like the MoonMath Manual – a beginner’s guide to zk-SNARKS - and the soon to be released whitepaper on ZKAPs - Zero Knowledge Access Passes, Least Authority is contributing to the advancement of learning and development in the field. The company also carries out security audits, including reviews of circuits and cryptographic code. They are committed to helping teams improve the security of their protocols and products, along with publishing their security research on these topics for the broader community to benefit from. To stay up to date, visit leastauthority.com, sign up for their newsletter, follow them on Twitter @LeastAuthority.

Anna (00:46):
Also be sure to check out the new Community Matters page on their website to read about how they promote the use of secure systems and privacy-enhancing technologies in various communities. Now here is my interview with the Oscar and Sanaz from Status.

Anna (02:00):
So this week I'm catching up with Sanaz and Oskar from Status. Welcome to the show guys.

Oskar (02:10):
Thanks so much for having us.

Sanaz (02:11):
Yeah, thank you. So good to be here.

Anna (02:15):
So I think you two are the first people that I've had on the show from the Status project. And so for that reason, I think it's probably a good idea to actually talk a little bit about what Status is and maybe a little bit of the history of this project.

Oskar (02:30):
Yeah. So Status started off as a mobile app, with the goal of being a window onto Ethereum. And what that means is it's kind of a chat, wallet and dApp browser in one. And I guess one way of thinking about it is it's a bit like a WeChat, but for this Web3 Ethereum world, where the idea is that you want to be able to communicate with people and coordinate with them and transact and interact with these dApps and everything else that's provided in this ecosystem. And as part of that, a big portion of that, is also having it be a peer-to-peer, private, secure, and censorship-resistant. So there's a pretty big focus on making the chat part of it private and secure, and being able to withstand various types of censorship attacks and so on. So sort of running on public infrastructure.

Anna (03:22):
Would you put it in the category of MetaMask, Brave or, you mentioned WeChat, and so maybe more in the chat app world. Do you see any connection to MetaMask and to Brave, those are also browsers, they're also interacting with Web3.

Oskar (03:39):
Yeah. So I think it's somewhat similar. I guess what we're trying to do with Status is it's more of a, the chat component is a big part of it as well, because with Meta Mask as well you have a wallet, but with Status, you also have the ability to have that functionality, when it comes to chats and group chats and so on. And it's also pushed towards having it being used for communities. And because if you have sort of a native interoperability with all these other types of infrastructure, it makes it easier to do certain things and so on. And I should also mention that this is also where Status started, but then it evolved from there. So back in the day with Ethereum, you had Ethereum for consensus and compute, and then you had Swarm for storage and Whisper for messaging. And the initial idea was to create an app that exposes this and allows people to build things and interact with it. But since then we started delving deeper in terms of protocol and research design, because we realized that underlying protocols didn't provide everything we needed. And especially when it comes to something like Whisper, because Status was the only app that used Whisper in production, and that turned out to have a lot of issues in practice. So we started off by solving them and then we have started investing more in infrastructure layer. And that's also related to products like Nimbus, which is also about serving Ethereum light clients. So being able to run that on a mobile phone, which is non-trivial.

Anna (05:04):
So recently we had Martin from Gnosis on, who also told a similar story. And actually I know the projects... Status, as I understood, it was a 2017 launch project. I remember it from that era. And that the original proposal was somewhat ambitious, given the tooling at the time. And therefore what you're saying is you had to go back and build a lot of that infrastructure to actually be able to accomplish these things.

Oskar (05:34):
Correct. And a big part of it is also having to have users to be stakeholders and this thing of turning the model of Facebook, Google, which had model inside out, and which fits very nicely with the peer-to-peer decentralized landscape that we are living in.

Anna (05:47):
Cool. I want to understand a little bit about both of you, as well. At what point did you join the project, Sanaz, if you want to say, when did you join Status?

Sanaz (05:58):
It was September, 2020. I had an interview with the Vac team. And so I got the offer and then I joined the team.

Anna (06:09):
Nice. And what about you, Oskar? When did you join the team?

Oskar (06:13):
So I joined about four years ago, almost. And I started off working on the app, doing [unintelligible] programming and so on, and then I turned into head of engineering for a while. And then I started focusing more on protocol effort, which then turned into Vac, as a separate R&D unit, essentially.

Anna (06:30):
Very cool. Are you now heading up Vac? Is that your full-time gig or are you still working overall?

Oskar (06:37):
Correct, but there's a lot of overlap when it comes to other Status project zone, because we have got the Status app and desktop app as well. Various partnerships, we have the Nimbus app, we were on libp2p implementation. There's also just a lot of collaboration across those teams.

Anna (06:51):
Cool. And, Sanaz, what are you working on now?

Sanaz (06:55):
In general, my role is a protocol engineering. I mean, I'm a protocol engineer in Status. And so what I'm working, I'm basically focused on the privacy and security aspect of the product, I mean the protocol stack. And what I'm currently working... I mean, previously I was working on the Rate Limiting Nullifiers in a relay protocol to protect the system against spammers. And currently we're working on some sort of consistency model across our store nodes, because we are working in a peer-to-peer environment. We don't really have a central entity to store the messages that are transmitted in a network. So we rely on some resourceful nodes to store the message history for the other light nodes. And then there was a problem or a question: how can we synchronize these store nodes and to provide a view consistency and data availability in a distributed manner. And this is currently the main research field that I'm working with.

Anna (08:00):
I feel like in this episode, we'll be talking, at least partially, about this concept of messaging. Am I right? I feel like this is kind of at the heart of the project. I mean, Status, as I always understood it, was a messaging app. That was the original thinking around it. But let's take a few steps back and go through the evolution of some of these things. So you mentioned Whisper, Oskar, you mentioned this a little bit earlier on. Let's start there. What exactly is Whisper?

Oskar (08:32):
So Whisper is a privacy preserving peer-to-peer messaging protocol, essentially. And it was initially part of sort of this Holy Trinity with Ethereum, Swarm and Whisper, where Swarm[Whisper] was the messaging part. So you have this computer and you have the brain and you have just disk and then you need some way of communicating, and not everything needs to be on-chain. So that was the idea. And then it was also originally meant to be, to have this concept of total darkness and be extremely private and so on. And that's why it was used in the Status app, because we value privacy and we want people to be able to have that.

Anna (09:07):
So that's what it was originally. So conceptually, that's what you just described. It was one of these pillars. But what was it in practice at the time and what did you need to do to it? Because it sounds like you needed to evolve it somehow.

Oskar (09:21):
Initially, we took it as granted, and we didn't really think about it as something to analyze. So like this could be a problem or something, but then we'd realize quite quickly that it has a bunch of fundamental issues, especially when it comes to running Whisper on a mobile phone. And some of these are fundamental when it comes to scalability and bandwidth usage, but also other problems. So Whisper, and we'll get into that later, but it's using proof of work for spam protection and that doesn't really work on mobile phones, because you have heterogeneous nodes in the network. So on a mobile phone is not very powerful. So if you have to generate some proof of work, that drains your battery, and then an attacker can just spin up. And actually people did this, they spin up some VPS and just attack the whole network and spam it. So it doesn't really work as a spam prevention mechanism. It also had other issues. And some of these were conceptually, there was an idea of where to take them, but they weren't fleshed out in practice. So, for example, when it comes to historical messages, because on a mobile phone, you're mostly off-line. So a big part of it is when you come online, you have to be able to fetch historical messages. And you also can't really maintain, there's sort of theoretical, platonic ideal of Whisper is that every node is sending, forwarding messages to all of the nodes.

Anna (10:34):
Okay. Is that the Gossip model?

Oskar (10:37):
Yeah, but it doesn't have, it doesn't really do routing. Which is part of how it got it's theoretical privacy guarantees. But yeah, essentially. But that means that every node gets all other messages. So unlike other types of Gossip protocols, where you do some de-duplication and maybe you only set a subset and so on, it's a bit different. So because we were, I think the only, well, one of the few, if not the only, products to use Whisper in production, we found out about a lot of these issues and that led us to do some tweaks to it and so on to get things like implementing a mail service so we could get historical messages and so on. Also some light connection strategies. So you can actually use it from a mobile phone and a lot of these kinds of things.

Anna (11:21):
What was phase two of this project? Was Waku? Was that the thing that you did right? You took Whisper and transformed it?

Oskar (11:29):
Correct. So what we did is, essentially we did some scalability studies and we realized quite quickly that it's not going to hold up, even for a current user base. And you would run into issues very quickly, both when it comes to running on a mobile phone, but also even if you have a better data panel, whatever. So with that in mind, we cleared up the specification and also made sure we included all the compromises and all kinds of things that we had to get used in the protocol when it comes to the light client support and historical messages. And also rate-limiting, because we ended up having to lower proof of work so low that it wasn't useful on the mobile phones. So we since did all these things to make it useful on mobile phone. And then we made a specification out of it, and we analyzed it a bit in terms of being more realistic about the guarantees it provides and something that can actually be used from a mobile phone.

Anna (12:26):
Did you have to throw out the proof of work thing completely?

Oskar (12:28):
Essentially.

Anna (12:28):
Okay. So what actually replaces it then?

Oskar (12:32):
So that's the thing, theoretically proof of work should work for spam prevention, but it doesn't in practice, because it drains your battery. So we ended up lowering it to such an amount that it was barely useful at all. So what we did, as sort of a stop gap in initial version, is to have a rate limiting, which is not ideal, but it can deal with a script kiddie attacks. So it's a low level of defense, but it's what was needed to actually make it work on a mobile phone.

Anna (13:00):
What is that like, remember I'm not a computer scientist, so when you say rate limiting instead of proof of work, what does that actually... That's just the amount of messages possible or..?

Oskar (13:09):
Sometimes the script kiddie attacks, what would happen is that someone would spin up a server and send a bunch of messages, but with rate limiting we could essentially detect that and say, "Well, one node should not be able to publish this many messages in this short amount of time", but it's also very easy to circumvent. So it's not a very strong guarantee, but it's sort of a deal with real world attacks.

Anna (13:28):
I want to also talk about, cause you mentioned that this first initial Whisper model had this "total darkness", I think that's what you called it, right? It had full privacy, in its theoretical sense. As you move away from it, as you started to do more of the Waku modeling, did some of the total darkness disappear? Did it become partial darkness? What happened to privacy?

Oskar (13:51):
So I think the total darkness thing, it's not a rigorous concept. And I think it became more of a, almost like a marketing thing. And there was a period of Status, where it became this thing, where we have just total darkness and that's it, but it wasn't actually something real or substantiated. And I think that's also the case for Whisper that there's no rigorous privacy guarantees you actually get from it, in that sense, so it's more of a theoretical thingy. It's kind of a local optimum and more thing thing that doesn't work in practice essentially. And this also touches on something called... So there's something called the Anonymity Trilemma, which is that you can only [have] strong anonymity, high bandwidth and low latency. You've got to pick two, essentially. And a problem is that it sacrifices so much in bandwidth, especially when it comes to you get these false positives with the way the Bloom filters work and so on, that means it explodes in usage and it's not actually usable for any reasonable scale, at least in its initial design.

Anna (14:51):
With the rate-limiting model, where did that come from? Was that something that you developed? Or were you using existing thinking when implementing that?

Oskar (15:00):
So what exists V1 that was so very basic rate-limiting, in the sense like DevOps. Then after that, with V2, there is, first of all, there's this Peer Scoring from Gossipsub, but then this more novel form of rate limiting that we'll talk more about in detail later that essentially came from a discussion with Barry Whitehat at Devcon a few years ago. And that's the one that's based on Semaphore and this is a Privacy preserving rate-limiting with zero knowledge proofs and zk chain.

Anna (15:27):
Very cool. So you made this move from Whisper to Waku. Was there any other features of Waku that we haven't touched on yet? That was kind of novel or new?

Oskar (15:36):
So after we did the initial fork into Waku V1 and solved the most immediate problems, it was still a very small change that we had made. So for Waku V2, which is what we started a year ago, we essentialy wanted to make it more robust and resilient and so on. So one of those, the major thing is that we moved to libp2p, which enables us to have running browsers and get more transports and all these things. Another big thing that we're doing here is also that we moved to, instead of using it as non-existent routing that existed in Whisper, we are basing it on Gossipsub instead, which is also what's used for Eth2 and IPFS and other products.

Anna (16:16):
Did these replace Whisper? Or are those equivalents, libp2p, Gossipsub and Whisper, are they all the same thing? Or is it more like Whisper is the meta concept and you're going to implement versions of these other things inside it?

Oskar (16:31):
So Whisper is running on top of devp2p and that was also the case for Waku, the first version of Waku. And then when it comes to Waku V2, what we want to do with Waku V2 is that we want to make it, so it works for generalized messaging, so human to human, a machine to machine, peer to peer, obviously, also be privacy preserving, but also make sure it's modular by design, because different targets have different requirements when it comes to these trade-offs. So a big part is running in resource-restricted environments. So that's things like mobile phones and browsers and these types of things. So a big part of Waku V2 was taking this thing apart and then reassembling it into smaller modules that allowed people to pick and choose, to get their desired mix of privacy and being able to run under various restrictions, essentially.

Anna (17:25):
Cool. Okay. So you made these changes, but what kind of security trade-offs or problems came up with this new model that you still had to work around?

Sanaz (17:36):
Well, the protocol stack consists of several protocols and what I'm going to emphasize on is the relay protocol, which is basically a thin layer on top of the Gossipsub, libp2p Gossipsub. And the issue is that in this network, every node can publish arbitrarily many messages, there is no limit. And so it exposes us to the problem of spamming. I mean, there can be a lot of messages that are published in a short amount of time and can congest the system. And so, previously in Whisper, we had the proof of work to slow down the messaging rate, but in our case, because this proof of work was not efficient, it involves a lot of computational overhead, then we were thinking about an alternative and we brought the idea of RLN, the rate limiting nullifiers, and the Semaphore in it And the idea is that we are going to limit the number of messages that each publisher can publish in the network, but both in a verifiable manner and also in a way that the anonymity of the sender will be respected, because we really care about that aspect. The overall idea is that you're going to use a combination of zero knowledge proof to prove the identity of the sender and at the same time to use the secret sharing, to enforce users to reveal part of their secret values when they send a message so that if they violate the message, they have to disclose or they put themselves at the risk of disclosing their secrets key, and then being slashed. I mean, I can obviously get in more details, but this is just the overall idea.

Anna (19:22):
But I'm curious here, going back to what you had said about replacing some of the underlying stuff with libp2p, Gossipsub, is the libp2p where the rate limiting actually lives? Or is that a separate entity or those two separate ideas?

Sanaz (19:37):
Those are separate entities. I mean, in libp2p they're using Peer Scoring method to protect against spammers. And each peer monitors all the peers to which it's directly connected and adjusts their messaging cutoff. Let's say, if it sees misbehavior of another peer that is, again, directly connected, it may decide to route or not to route their messages. It's all based on the past activities. And this is the measure that is implemented in libp2p, but we are not relying on that part. And this rate limiting nullifier is another technique on top of that.

Anna (20:16):
Oh, cool. Does the fact that you're using libp2p that does have routing and this Peer Scoring, does that actually undermine privacy? Does that change the privacy model? Is anyone able to track that somehow?

Oskar (20:30):
So, yeah, it's a good question. So with the Pub/Sub and Gossipsub, which is one of the protocols that exist in libp2p, the relay protocol is a thin layer on top of it, you can have this, it's called a strict no sign policy, which means that you don't actually see, so someone's sending a message, you don't see a signature from it and so on. So in that sense, it doesn't degrade privacy because it gives you that option. And that also relates to something like Peer Scoring, because you're only scoring peers that are immediately connected to you, but you don't actually know that's where the message is coming from, which is also something that makes RLN more useful. It's also worth pointing out that libp2p is more like a framework and all these protocols are different layers. So you can think of that could be, to a sense, like libp2p extensions, where these many small protocols that are being used on top of libp2p. And that also means that you can more easily plug in things so you can have different transport, so you can run in browsers and all kinds of environments.

Anna (21:30):
Very cool. And then you mentioned that you're also using secret sharing. Where does that live in that stack? Is that within libp2p? Is that something next to it? Maybe help me place that.

Sanaz (21:45):
It's completely related to this rate limiting nullifier technique, as a whole, but there are two things that each publisher needs to prove, as I told you, one is the identity, that the publisher belongs to a group and has enough credentials to publish message in the system. And the other thing is that, because we wanted this spam protection to be [an] economic incentive, the users that want to send a message in the network, they lock some funds in a smart contract. And then we want to force them to reveal a part of their secret value, but it's a random share of their secret value. The rate right now is like one message, let's say, per second. And if the publisher tries to send more than one message per second, it has to reveal two shares of its secret. And then having two shares of its secret will enable us to reconstruct the entire secret. This is a secret sharing part. And when we reconstruct the secret, then we can, let's say, anyone who can reconstruct the secret. I mean, by having two shares of that, the person can go to the contract, slash this spammer, the guy who has violated the right and then withdraw the money. And the secret sharing part, this has to also be done in a verifiable manner. So we need to also prove that the sender has included a correct share in its message. And indeed what I can say is that this entire zero knowledge proof circuit will consist of this identity, the membership, as well as the correct secret share construction.

Anna (23:25):
Very cool. I actually want to dig into the zk proof really soon, but I have one more, at least, one more question on what you just described. The locked funds, who's doing that? Is that the node operators? Is that those who are passing messages? Or is that actually the original message senders from the start?

Sanaz (23:44):
It's the message sender. We have a notion of group and the group state is stored in a smart contract. And every node who wants to be part of this network to publish messages, it has to first register, to do the smart contract, lock some funds in the contract. And then after that point, it is able to send messages and also provide valid proof of membership, because her public is already published on the contract.

Anna (24:13):
Got it. So I used probably the wrong term. I just said node, but maybe what is the name of the agent that's actually doing the message passing? What do you call that?

Sanaz (24:22):
Well, it's distributed, it's peer-to-peer. I mean, it's like you have a network of nodes, all of them are connected. And then, let's say, if you want to send a message to another peer, you send it to the entire network and the recipient will get it. I mean, ultimately.

Anna (24:37):
So I was right in saying the word "node". That is actually the in-between agents that you're sending it to. This is probably a really dumb question, but are these Ethereum nodes, like full nodes? Or is there an extra level of nodes that just live in the Status network?

Oskar (24:53):
So these notes are separate, I mean, it's essentially Waku nodes, but obviously you can run, if you want to, run with Nimbus, for example, you can run Ethereum and Waku node at the same time. And I guess also, so what we're trying to do to with Waku is we're trying to have these adaptive nodes with [the] idea that you don't just have full nodes and light nodes, but it's more of a continuum, based on capabilities. And the reason for this is because, instead of having this thing where you have Infura and then [unintelligible], and then AWS, and then people just connecting through that, people who run infrastructure should be able to contribute what they can, which is also a big part of obviously with Ethereum, the tech stack of Ethereum, Eth2, where you should be able to run on commodity hardware. And the same thing is true here, where you might have a dedicated hardware, or you might just have a laptop and that [is] sometimes offline. And it also touches on some of the consistency things we were talking about before, where you should be able to contribute to the network with just your laptop or your mobile phone. And maybe it's different if you are on a limited data plan or 5G, like with battery and so on. So trying to accommodate for that as well. It's interesting as well to compare this type of spam prevention mechanism with more traditional methods, because in most traditional we take it for granted, when we're talking about most popular messengers where you use a phone number to register, where you have some email address, whatever. And usually that's a private piece of information that's very easy to link to other actions. Part of the reason why that's used is also because it's costly to get the new cell phone number. So if you just have a cell phone number that you can identify, connect to all actions, it's very easy to say, "Well, this person is spamming" and cut them off. So this presents a problem when it comes to open peer-to-peer networks, because you need some mechanism to replace that and make it costly, while at the same time maintaining privacy.

Anna (26:43):
Got it. So let's dig in to the ZKP and how it lives and what it looks like and what it exactly does. Sanaz, I know you just mentioned, the circuit itself holds the zk proof ID. You mentioned it held other elements of this. Let's go through it. Let's understand the SNARK and what it's doing exactly in this.

Sanaz (27:04):
We're using this RLN repository that gives us the circuit for the zero knowledge proof and the proof generation and the verification functionality. Indeed, what we are using is that we are passing the secret key of the user. And by "we" I mean "I", as a user, I pass my secret key to the circuit. I've also feed in epoch that I'm going to send the message for. And the proof generation unit will give me the proof that will prove that I'm the member of the group. And it also creates the secret share of my secret key and the proof that this secret construction is done correctly. It's a very high level idea. I might not be completely precise about that. And then I can use that proof, attach it to my message and then send it already to the network. And then everyone else can use this verify function to verify whether my proof is generated correctly. And then either route my message or drop it, because the proof is invalid. And in the case that I attempt, I mean, as a spammer, if I want to try to send more than one message per epoch, and if my messages are different, the routing peers will catch this misbehavior and then they can extract the secret key of me, as a spammer. And then they can go to the contract and withdraw the money and then slash me and drop my public key from the state of the group.

Anna (28:35):
Cool. So I feel like I heard just before something about a user limit or limit on the number. There was some number that was given as a top limit. And I'm curious about what is that exactly? What is this limit? And did the older version already also have that limit?

Sanaz (28:52):
I mean, right now, I don't have anything in mind that can pose any limit on the number of users. Of course, when we consider a larger group, then we end up with a larger size Merkle tree. And the larger size Merkle tree means that you'll end up having more constraints in our circuit. And then this will increase the proof time. We might have limitations on that side, but right now we're considering 2 to the power of 32. And as far as I know, the proof time, considering this size of group, is something like a half a second, to the best of my knowledge. So of course we can consider listing smaller groups, and then we can optimize the running time. I mean, the proof generation. There would be such trade-off in that respect, but even with 2 to the power of 32, I think it's going to accommodate around half a billion users. We already have half a second proof generation. We'd have half a billion users, which I think it's good enough, but we are definitely working on it to optimize, consider smaller size groups. I mean, in order to lower the number of constraints in our circuit.

Anna (29:59):
What are the other kind of trade-offs? I'm just curious if there's anything else that came up as you moved towards the zk concept. Is there anything else that you're now needing to fix for, in other parts of the construction?

Sanaz (30:16):
No, not exactly related to the zero knowledge proof part, but in order to prove the membership in a zero knowledge manner, we need to hold the state of the group as a Merkle tree. It was originally outsourced to the smart contract, but then there was a lot of gas consumption, you want to hold it in a smart contract for every user, any update on the group has to be handled through the contract and it was not very efficient. And then we decided to move the storage of a smart contract to the users. I mean, it's completely distributed, the Merkle tree is not distributed, but each user will hold it locally and then keep itself updated with the latest state of the group. And the state of the group right now is just like a set of public keys that are stored under contract. And every node has to listen to the contract and see if there's any update, and then they can reflect that updates on their own Merkle tree. There is a concern regarding the size of Merkle tree that has to be stored locally and we are thinking towards some hybrid structure where we will designate a set of full nodes, some of them that are more resourceful to hold the Merkle tree and then synchronize the state collaboratively. And then we will set some light nodes that will fetch the latest state from those full nodes, just in order to account for the resource restricted devices. And this was one of the major problems that we encountered. I mean, throughout this whole rate limiting nullifier and enabling this zero knowledge proof part.

Oskar (31:58):
I would add another thing to that as well. I think, it's kind of a novel mechanism and I think the user experience is also fairly important. So we'll see exactly what the best way of exposing that is. And to some extent, it's also like an app concern, because essentially what you're creating is this this garden, where you sort of pay your entrance fee. And then after that, you can message at a certain rate and be a nice citizen, which is great, but it's maybe not necessarily what all applications need, because it also means that you need to have funds to get started and, and all these types of things. So there might be some hybrids there, which plays into the idea of modularity as well, where, because it's Gossip and Sub/Pub-based, you have these topics. So you come out and you have some topics that are slightly more secure, and then it becomes the application level concern in terms of how much they want this stronger form of spam protection and so on.

Anna (32:48):
Yeah. I want to hear a little bit about the actual SNARK that you're using and how maybe the trusted setup plays into the way that you're thinking about building the system.

Sanaz (32:58):
Well, we are using groth16, and, as far as I know, the library that the RLN repository is using is Belmont. And for the trusted setup, it's going to go through this MPC ceremony. I mean, considering that one of the participants is honest, then we can rely on the output of the parameters that they generated, as a result of that MPC.

Anna (33:23):
Are you going to be using the Perpetual Powers of Tau that Wei Jie has put together? Or are you going to be running your own?

Oskar (33:30):
Correct. So because it's based on Semaphore and that's a part of the Perpetual Powers of Tau, we're using that. So we are able to piggyback on that community effort.

Anna (33:39):
Oh, amazing. Do you even have to do your own phase 2, or can you just use the Semaphore phase 2?

Oskar (33:45):
There's a phase 2 as well, but I think, that trusted setup, if I recall correctly has not as strong security requirements, sincerely. I think the worst case scenario, when I talked to Barry last time about it, is that you would be able to spam the system, that's the worst case scenario. And in that case, you could upgrade the system and so on. So it's slightly different from something like private transactions where the consequences are much worse.

Anna (34:11):
Going back to Status as the product, this messaging product that would be sending things around. What we're been talking about is this lower level, like deep in the weeds underlying protocol that would allow for some of these messages to be sent around. Does Waku V2, does that solve for everything it needed? Do you see this as something that could be incorporated into the initial product, the overall Sstatus product, to work? I'm curious if this solves everything or if it's just dealing with a piece?

Oskar (34:44):
Definitely. So, right now Waku V1 is what's running in the Status app. And Waku V2 is, essentially, overall, like we have this component we talked about, RLN, but a lot of the other components are ready and we are in the process of integrating it into the Status app. And we also have this collaboration with the WalletConnect, so WalletConnect 2 will be running on Waku V2. So a subset of things are essentially production-ready. We are doing some stability tweaks and so on, but we're dogfooding it as well. So right now we're using command line chat client and having a bridge to Discord, it's essentially a minimal subset is production-ready and then we'll add more and more modules. So RLN is one to increase guarantees and so on. I guess, going back to your question on how it fits into Status, this is like one part of it when it comes to the chat protocol, but then there's also other things on top of it. So we have this Signal-based Double Ratchet protocol for perfect forward secrecy and these types of things, which is just a conversational security layer and that's something that already exists. And it's not a focus research right now, because we're focusing on Waku V2 and data consistency and spam and so on, but that's something that you could potentially look at down the line when it comes to getting scalable group chat and so on. Then there's a lot of other things that maybe the Waku team isn't focused on completely, which are more sort of application level. And these are things like this effort around community management and access management and so on, because a lot of these topics, they are free for all. So you can just send stuff on it and then it appears in the Status app and that makes the moderation difficult. And here we distinguished spam from moderation, where spam is the network level thing. And then moderation is actually, if people send scam messages and these type of things. So there's an effort that's been going on within the Status core team to create this moderation features and these types of things. So you can create your own little community and these types of things.

Anna (36:40):
Very cool. I want to check a little acronym, cause you mentioned it a few times, RLN. What does that actually stand for, RLN?

Sanaz (36:49):
Rate Limiting Nullifier.

Anna (36:51):
Okay. Rate Limiting Nullifier. And that is the zk-based spam protection that you, that's your short form for that.

Sanaz (36:59):
Yes.

Anna (36:59):
At this state, how private is it? We had talked a bit earlier in the episode about the 100% darkness. How far along towards that has all of these innovations actually brought us? Is it a private system? Or would you say there's still some trade-offs we have to keep in mind?

Oskar (37:19):
So I would say the notion of total darkness, it's not a well-defined thing. It's not something anyone in the privacy research community would use. I guess it's very much a process and I think the biggest thing is really that it's pseudonymous. So having an open network where you don't actually tie it to any real world identifiers is huge, I think, because that allows, that gives people the tools to stay private in lots of ways. Another big aspect of this is what your exact requirements are, because you have to sacrifice something in order to get metadata protection guarantees, and usually in the form of something like bandwidth. So if you're running a full node, there's this notion called Key Anonymity, where essentially if you're sharing the same topic and you're not signing the message or something like that, then you're essentially hiding in that crowd. So you unlimited set is a message on that topic. Obviously this depends on your threat model and so on. And when it comes to being transparent around privacy guarantees and so on that was also a big thing, we didn't want it to just be a marketing claim where we said, "Oh, it's private" or whatever, we want to be really rigorous about it. And I think to get the absolute strongest privacy guarantees, when it comes to, I don't know, NSA-level adversaries, these types of things, you would probably need something more like a mixed net, things like a Nim product are working on and so on. And that's something we explored in the beginning, but we also want to be realistic and how it's something that you can deploy today. And also have it work in a Pub/Sub setting, to have this topic concept, because that's very vital in many applications, such as Status app. And I also want to mention that a big part of a privacy anonymity is also having a large set of users. So enabling a protocol to be used in many environments is also stuff, increasing privacy in that regard. But then it's also very much a process and we're still researching more details and how to improve things when it comes to unlinkability and these sort of things.

Sanaz (39:10):
In our messaging system we're trying to avoid to have any personally identifiable information in the messages. Let's say, one of the things that Oskar also mentioned was that we have the no sign policy, none of the messages should be signed and a signature shouldn't be visible to the other parties because... I mean, there are ways to sign it, it's not like it would be completely avoided, but there is a thing that on the vocal messages we shouldn't put any signature that is visible to the routing peers and the reason for that is that, I mean, signature, because it is tied to a verification key, it somehow allows to link all the messages that are issued by the same sender, by the same signer. So it breaks the anonymity because it provides linkability across all the messages that are published by the same publisher. So we are really concerned about this level of privacy. And as I told you, removing personally identifiable information. And so, let's say, there's no sign policy, it's one way to achieve that. And also I believe that using this Gossipsub protocol where you send them, I should say, pops up kind of paradigm, when you send a message and it will reach to the entire network, all the people that are subscribed to the topic, it provides a good level of anonymity, because literally no one knows who is communicating with whom, you just send a message and anyone is listening and someone can pick it and look at the message and someone can drop it. And you really don't know who does that or who does drop the message. So it also provides a good level of anonymity. We are also working on the anonymity and darkness in other layers of our protocol, let's say, in the store protocol. And also we have a filter protocol. Let's say, filter protocol is for nodes that don't want to really engage in the relay, but at the same time they want to get a subset of messages in the system. And in between there is a full node, there is a light node. The light node queries that the full node to filter the incoming messages and sends it back to the light node. And so this request to the filter node exposes or reveals some information about the courier. And so we need to take care of that part, but the fact is that we are very much explicit and transparent on our specs about what kind of security issues will happen, if you use this protocol. We're completely transparent about that. And of course we are working on the measures to provide anonymity, like using, let's say [unintelligible] transfer or stuff like this. These are the future research directions, but yes, we are certainly seriously concerned about users anonymity in our protocol stack.

Oskar (41:55):
To add to that, we are coming to this from having to be able to run on a mobile phone and I think a lot of theoretical construct and so on, they are great in theory and so on, but there's no such thing as a free lunch. And when you actually want to run it in a mobile browser or something, you need to have this way to get access to the full network. And to actually design that from the ground up. And we think of it as kind of a service network, where you have these nodes that provide various services. And then the idea is that you don't want it to be a single point of failure, a single gateway, but it's kind of thing where you can choose multiple entry points and then have them help you. And then if you have stronger requirements, then you can own your node completely. Another thing also is that we tried to make it easy for application developers, because applications developers, they don't know too much about, they have some cool dApp and they wanna do some cool stuff, but they don't know much about privacy or metadata protection or peer-to-peer or these types of things. So we also try to guide them in the right direction and have some recommendations for how to use the protocol. So for example, we, by default, share things on a single topic, because that increases the anonymity set, and which also plays into the role of modularity, but at the same time providing same defaults.

Anna (43:08):
Cool. Well, listen, I want to say thank you to both of you for coming on the show and explore, going through a bit of the history of Status, exploring the Waku V1, V2, bringing us up to date with where we're at. And I actually think you make a good point about the transparency about privacy guarantees. I like the fact that there's something modular here or something optional. But also I think that's something that everyone working in privacy always has to come up against, which is there are trade-offs for sure. And also there's privacy at different places. And you may have to make trade-offs in one place, in order to achieve the more important privacy for the end user, the one that they care about. But yeah, thanks so much for explaining all of this to me.

Sanaz (43:53):
Thanks for having us.

Oskar (43:55):
Thanks so much for having us. It was great.

Anna (43:57):
And I want to say thank you to the podcast producer, Andrey, thank you to the podcast editor Henrik, and to our listeners.

Anna (44:03):
Thanks for listening.