 the technical introductory of technical kind of like advanced talk on GossipServe. There's been a lot of interest in GossipServe. They have around 130 people outside there for this particular talk, right? I don't think everybody will fit in this group if they happen to show up. But yeah, we have a really little time and a lot of ground to cover, so I'm gonna get started. I'm Rahul Pradhani, I'm the techie for the B2B project from Modular Labs. And this is what we're gonna be talking about. In this defined GossipServe. So, GossipServe is a scalable and extensible peer-to-peer gossip protocol. And our agenda for today is, first of all, I wanna make sure that we all have kind of like a common base night to talk about these technical concepts. So, I'm gonna do a very quick introduction to peer-to-peer bops up. Who here is familiar with these concepts? Maybe a five and above in a scale of 10. Fantastic, okay. So, I'm gonna move through this pretty quickly. Then we're gonna talk about what is GossipServe. So, we're gonna talk about how GossipServe operates and what's up next. Because as you'll see, GossipServe is a stepping stone in a rule that includes a normal functionality that's coming in the future. So, oh my God, this is gonna suck a little bit. All right, so let's move on. What is bops up? Bops up is a message oriented communication pattern. This is in stock contrast with stream orientation. So, here we're not interested with bops up. We're normally interested in sending transactional messages and small units that are actually messages and not streams over the wire between a bunch of peers that are not necessarily talking to each other. So, the interaction model of bops up is M to M. This means that N peers are publishing messages about a particular subject and a lot of other peers in the network are interested in consuming messages from that particular subject. This is as I said, in contrast to RBC, I reply with Westworld patterns, which are mostly one to one. Now, bops up communication is asynchronous and decoupled in nature. This means that whatever I send a message as a producer, I have no guarantee, first of all, when who is actually gonna receive that message? Because peers don't have a complete view of the network and a complete view of the subscription state. And it's also asynchronous because there is no time dependency. I have received no explicit confirmation from any peer that they've actually received my message. Processes act as publishers and consumers of messages. And in a peer-to-peer network, this is important because a process can act as both things. And they congregate around topics of interest. Now, bops up is quite popular in enterprise software and if you've heard of products and projects like Apache Ante-MQ or Kafka-Rabbit-MQ, then that's it. But in those contexts, it's usually centralized around brokers in private networks and it's definitely not. These approaches are not suitable for public message partners. So what does decentralized peer-to-peer help? First of all, it's broker-less. It means that we have no central authorities to keep track of subscribers, publishers' topics, it's self-recognating. Whenever we deal with peer-to-peer networks, we have to monitor it, right? And peer-to-peer networks can rotate in presence very rapidly, so there is no global knowledge. There is no single peer that is an authority that has a complete view of the network. And the network behavior actually emerges from small, tiny, local decisions that peers are taking along the way, right? So peer-to-peer Popsil is usually constructed as an overlay network with peers collaborating to ensure message-deliverability, right? And when we say overlay, there's usually an underlay, right? So it's an underlay network that actually makes sure that messages and traffic gets relevant. And usually, algorithms will assume that the underlay is one kind of network. So this means that I can always find a path from A to B and if I can, that's a pathology. So just to set a baseline for terminology, a topic is a subject around which peers congregate and they commit to receive messages. Subscription is the act of expressing interest on a particular topic. Publishing is the act of creating a message and pushing it out to the network. Forwarding is the act of propagating a message to other peers in the topic. And hand-mealed discovery is something I'll talk about in a second. So the disciple properties in peer-to-peer Popsil are reliability, resilience, efficient dissemination, altruism-free routing. This means that only those peers that are actually participating in a particular topic will actually contribute to forwarding that topic and we're not burdening the rest of the peers of the network that are not invested in a particular topic and disseminating that. It has to be scalable across various axes. So we're talking about number of nodes, number of topics, messages, subscriptions, subscribers. All of these are different axes for scalability. It has to be a low overhead for maintenance. As I say, we are relying on peers making local decisions so that messages are clearly routed in the network. And ideally, we'll have the protocol that is simple and easy to understand. So we'll see if we've actually managed to do this for GossipServe. So what is GossipServe? The key elements of GossipServe is that, first of all, it's a scalable and extensible PubServe culture. So GossipServe in itself is not necessarily intended to be a final usage of a peer-to-peer protocol or for peer-to-peer PubServe protocol. It is a protocol on top of which we can overlay different routers to take different decisions. And GossipServe actually provides the primitives to make sure that, first of all, messages are delivered. And second, there's enough gossip metadata circulating on the network so that different and alternative decisions can be taken along the way. It was envisioned and specified initially by a developer called Viso. He's in the LVTB core team. And as I said, it provides a base layer and primitives to build adaptive, self-optimizing routing algorithms capable of repair and rearrangement in the network in the process of churn. So the key aspect of GossipServe is that it combines stable, reciprocal messages with gossip about message flow metadata. We'll dig into this in a second. And it succeeds a protocol that we had in the LVTB step, which is called FlotServe. And it's basically the dumbest protocol in terms of you're to be a PubServe. You disseminate a message to every peer that you connected to that. And you know it's interesting what you're telling me, right? Which is great because it's robust, it's resilient. And it can take minimal latency parts because you just push the message out. And those peers that are closely connected to you and have a fast link with you could receive it first. But it also creates a lot of right amplification. And it basically clubs up the bandwidth because you're creating a lot of duplication in the network. As I said, GossipServe is the stepping stone towards the grand vision of MSR, which is I'll introduce it a bit later, but basically concoct ideas from Plum Tree, Hyper-V, or Go-Best. Warning, the stickiness of GossipServe is currently off. And this is very important for people to understand. It is a protocol that we're going to continue iterating on over and over again. And as I said, it's a stepping stone towards this more stable and featureately protocol called EBSA. There are three implementations. There is the reference implementation in Go that the Libby2B core team produced. There is a implementation by the Sigma Prime guys who are just here. Raise your hands, please. Get some credit. Fantastic. It's currently sitting in a fork. And I don't know if the chain-save guys are here. I don't think they are, but they also contributed and they created a GossipServe a protocol to change this. Cool. So how does it work? I'm going to go through different layers of the protocol to kind of like do a whole thing. So the first thing that you need to understand is that GossipServe is actually a hybrid of two different networks that are on the same protocol, that are on the same boundary. So there is a full message network formed by reservable links through which messages are forwarded. And this is, the word reservable is very important because this is supposed to be a stable mesh where peers are actually exchanging messages with one another. So if I'm pure A and I'm interacting with pure B in a topic, these two peers will actually be exchanging messages with one another consistently. And then there is a metadata-only network that carries GossipS, about which peers, what peers are actually seeing. So as I said, the full message network, we call it Mesh, is a sparsely connected network of reservable links between peers that are actively consuming and interested and therefore forwarding a particular topic. The construction of the mesh is actually randomized and is self-stabilizing because it has a number of stabilizing parameters. So peers are configured, the mesh is configured with a target degree, which by default is 6. There is a high and low watermark, which by default is 4 and 12. And peers will strive to maintain the connectedness for a particular topic at an optimal level of 6, taking compensating action whenever it goes above the low watermark or above the high watermark. This is a way to keep that leeway to avoid drastic down-cutting and up-regulating. So the stable mesh is complemented by a metadata-only network, which is a densely connected network that augments the mesh with Gossip propagation about which messages are actually available. So this enables writing decisions to be made. If I have, the easy way to put this is in a particular topic, if I have 50 peers that are interested, that are consuming, so 15 neighbors of mine, are interested in a particular topic, only allowed to keep 6, in theory, based on the stable mesh, the remaining nine will turn into gossip peers. So I will not exchange messages with them, but I will collaborate with them, telling them what messages I've seen without actually pushing messages to them. We'll go through this in a second. So how does topic membership work? As I said, a peer can be subscribed and be emitting messages on various topics at once. So peers can participate in many topics, either as subscribers, publishers, and both. And peers keep a view of all neighbor subscriptions whether they overlap with ours or not. So if I'm subscribed to topic A, and another peer is subscribed to topic C, but I'm not interested in C, I will still note that the other peer is subscribed to topic C. As subscribers, as I said, only engage in message propagation and gossip for virtual topics. So I will only actually participate, and this is one of the key properties, if you remember, that are desirable in Pub-Sub systems, in peer-to-peer Pub-Sub systems, which is only those peers that are invested in a topic should be making effort towards disseminating that topic, so that the gossip does satisfy them. So we have a concept that's called subscription evening, which is basically on every new connection, peers will exchange the topics that they subscribe to, and as the application that is using the Libby-to-peer stack joins four-leaves topics, they will send updates to all of the peers. So as I'm participating, as I become a participant in a new topic, I will send an update to all of the peers. Now, we don't want to be very chatty, so we've introduced the concept of piggybacking. So this means that we will try to coalesce updates, metadata updates to peers on top of messages that we anyway need to send them, such as graphs and proofs and so on, as you see. And this kind of weakening enables us to create about metadata flows and to do also a terminal topic sending, which is also called final, I'll explain this in a second. So with regards to topic membership, there is two key concepts to understand here. There is the concept of grafting and proof. I said that the stable mesh is actually a self-regulating mesh, and these two messages are key to regulating that mesh. So graph control messages, graph control message, proposes a two-way full message stable link with a peer. So it basically, when one peer sends a graph to another peer, it's basically telling it, hey, I want to be part of your reciprocal mesh for this topic, right? This means that I'm going to send you messages and you promise to send you messages as well, right? Now, the other peer can reject that because they're already beyond their target degree, right? And if they're rejected, they send back a clue. However, the other peer knows that I'm interested in that topic, right? Because we can do subscription to that topic. Therefore, even though I'm not part of the stable mesh, that will send me metadata, right? So this is where the aspects, these two networks started making sense, right? Now, a prune control message dissolves a two-way message, a two-way stable mesh, stable between two peers. And this could be, in this could be sent and respond to a graph that we want to reject or if I'm down-regulating my degree, right? Now, one key, another key aspect to try to understand is that by itself, BOSP sub sub right now does not include a mechanism for peer discovery, right? So if we want to, whenever we want to subscribe to a topic, we need to find a set of peers that are already subscribed to that topic. This specification is called ambient peer discovery, right? We rely on the peer discovery mechanism which is present in the audience, right? This is going to change as we go forward. Where there's currently a PR to add active peer discovery so that whenever you, the application subscribes to a topic, there will be a, a pop-up will actually do a lookup of peers in that topic for them, for the application. And we also plan on introducing something that we call collaborative peer exchange. Let's talk about message flow. When a peer wants to send a message as a message source, they just push the message to a wall stable, to all peers in the application, they're full of message flow, right? Super simple. Now, peers that receive that message are actually message routers. So whenever they receive that message, they will forward that message to all other peers that are part of that mesh, of that view of the network, right? And we follow here as to interbreak silence because we don't want to send the message back and forward, back and forward, back and forward, right? Now, we can also publish messages on topics that we don't subscribe to, right? And this is interesting for things like, for example, IPNAS, the Interplanetary Naming Service where we want to send updates from whatever name, the mapping of a name changes to a different app, for example, right? So you don't necessarily the peer that's watching, for example, the DNS server, a DNS name server somewhere, and then it's noticing this change, doesn't necessarily want to be subscribed to the Starbucks, right? So as the possibility of sending those messages and when we do that, we basically are, remember that we keep in track of what peers are actually subscribed to, the network, we're not forming stable meshes with them, but we keep in track of them. So if the local application tries to send that message, we will immediately find what we call a fan-up group from those peers that we know are already subscribed to them, right? And this is gonna be an ephemeral message. So once we found that group, we push out the message, those peers we know are already part of the mesh, therefore they will forward that message internally because the message has arrived inside the mesh for the topic. And after two minutes, we just dissolved that fan-up group because that was just an ephemeral set. So we don't want to keep it along for too long because that would be aggregating state that we don't. We also have the concept of topic validators and message validators, so we can, so when a peer, when an application sends a message, sorry, the application can configure, it can attach predicates, validation predicates to topics, right? And either to point out, for example, is using this for validating signatures in blocks that are getting propagated and so on, right? And transactions. So when a message is published locally or before forwarding a message, this predicate will be called. If it succeeds, then the message will continue dissemination. Otherwise, it will just be dropped. We have the concept of asynchronous validators for heavy logic and Goss himself can also be configured to sign outbound messages and to, and to strictly validate dynamic signatures as well. Now, how do we regulate the mesh? There's a concept called happy, which by default happens every second. This is a very popular concept in distributed systems. And this basically performs mesh and Goss at maintenance functions, right? There's three things that happen. We regulate the mesh degree for every topic. We emit Goss in and we slide the message. So this is kind of like how degree regulation works. As already explained, if we're below a certain threshold, we will try to add peers to the mesh for that particular topic. If we're above a certain threshold, then we will try, we will prune peers from that topic to try to keep the degree at a stable constant. To be able to do this, we keep a bunch of local states or topics that I subscribe to, topics that I recently sent a message to. This is the found out groups, peers that we currently connected to and what kind of links we maintain with them, whether it's a full link, message data link or if the found out peers, and what messages we've recently seen. Why is this important? This is this last bit. Because we send Gosset. So this is where the Gosset comes in. So every single peer that we know is interested in a particular topic that is not part of our stable mesh, we will collaborate in the network by Gosseting what messages we've seen in that particular topic. So we don't send a message to them, but what we do is with every tick and every heartbeat, we will, with the message, we keep in a message cache and we keep in kind of like a sliding window of the messages that we've seen in the last 30 seconds, two minutes, this is configurable. We will send them a list of all the messages of the messages that we've seen. And this usually happens as well. We try to piggyback this because we don't want to create excess overhead in the network, but sending this message around every time that we see a message. So we try to piggyback. If we have a message to send them anyway, then we try to piggyback these control messages. Now, if a peer spots a message that they haven't seen, they can ask for that message, they can pull that message by sending an I want control message. So in that I want control message, there will be listing the messages that they want us to push to them. Why is this important? This is important because it allows us to take round decisions. So imagine the case where you have a stable mesh, you're in a topic, you have a bunch of peers that are sending you messages, and another peer, which is gossiping with you, tells you about a message that you haven't seen yet. This means that your, that deliverability towards you is not 100%. Because in your mesh, you haven't received that message yet. So you can use that as a sign, as a hint to try to repair that pathology by pruning peers that you believe are unhealthy and grafting with peers, with the peer that sent the message who probably has a better route to the rest of the mesh. You have one meeting next. Okay, fantastic. I think I'm almost done. So this is kind of like a bit of a schematic view of what's on the wire. By the way, all of these images and so on, you can find them on the web, so don't worry. I'll just show you where they are. I just want to talk quickly about what's next. For a gossip sub, first of all, we want to formalize a gossip sub into an academic paper. We want to harden the reference implementation and go to the database to enable pluggable routers. This is, for us, very important for the vision of gossip sub itself. And formalizing a gossip sub into an academic paper is going to be also a robust step in allowing other downstream projects to actually build on top of that analyze it and to get all this work peer reviewed because it's essentially a new contribution to the state of the art. We want to integrate discovery mechanisms and there are various benchmarking efforts underway. Important aspect is said, gossip sub is not the final destination. And gossip sub is a step along the way. Really, the key aspect here is and where we want to get to is a protocol that we call MSU, MSU, which is a combination of geometry, high-par view for membership maintenance and vocals for the proximity awareness machine and so on. And this will allow us essentially to model the kind of behavior that I describe. So if we, so with MSU, we'll be able to build dynamic dissemination trees that are mutating and that are adapting to the conditions of the network by keeping track of the peers that are better connected to the network and as well those peers that happen to present pathologies with us. So whenever we find messages that we haven't seen that are gossip, that are incoming gossip from another peer, we can rebalance the tree and make sure that we always have a good connection to them. So this is what we also call the self-healing mesh. We want to introduce adaptive cache modules and things like collaborative and passive membership peers. So something that's key here is the ability to send advisories over the network of what peers are available in which time. So ideally, you want to use an ambient discovery mechanism like the DHT, for example, to find a seed, a limited number of peers that acts as a seed to bind to that topic and once you have those few peers which are probably overloaded because they are being advertised, right? You want to inquire them for other members that they know about in the mesh and you want to create gossip not just about the messages that are available but about what peers are present in that topic. So this is something that's going to be cool. That's going to be, that's coming down the pike. It also has notions of peers. Cool. So as I said, all of these time terms and these schematic views, which are pretty nice and very beautiful, they are available under the Docs website. So make sure that you check out the new snazzy docs for Gossips of which we just released one week ago. Just in time for that. In time for more to do this.