On this page On this page
episode 20 — Netstack.FM New Year Special, 2025 Wrap-Up.
This New Year special reflects on the first nineteen episodes of netstack.fm , highlighting key lessons about networking, Rust, open source, and the people behind the protocols and systems that power the internet. It also looks at the evolution of the Rama framework and sets the stage for continued learning, collaboration, and new conversations in the year ahead.
00:00 Intro00:54 Introduction and Year In Review03:28 Insights from Guests and the 2025 episodes22:21 Rama Testimonials27:28 Rama in 202631:07 Closing Message32:07 Outro
Music for this episode was composed by Dj Mailbox. Listen to his music at https://on.soundcloud.com/4MRyPSNj8FZoVGpytj
Elizabeth (Plabayo)
0:12 | 🔗
This is netstack.fm, your weekly podcast about networking, Rust, and everything in between. You are listening to episode 20, our end of year episode where Glen reflects on that journey so far through conversations with engineers, maintainers, and researchers working on modern networking systems. From Rust and Async Runtimes. to protocols and open source communities. We look at what we've learned and how it shapes what comes next, including our work on Rama. Welcome everybody for this Netstack.fm New Year's special. First of all I would like to thank all the guests that have participated in the last year. We had 19 episodes so far and they were really wonderful thanks to our guests and the subjects they helped to uncover. I would also like to thank the community both around Nestack.FM as well as Rama. Both communities grew a lot and there has been more and interaction as well as outreach and for that I am very grateful. Later in the episode we will also listen to some testimonials from a couple of users of the Rama framework. At that point we will also cover a bit about how Rama has evolved since start of this podcast. At that point I believe we were... A couple of months after 0.2 and well in the midst of work of working towers 0.3 I am happy to announce that the ending is nearly there and by the end of January 2026 we will actually release Rama 0.3 In the meanwhile, a couple of days ago we released the last alpha version of Rama 0.3, which is Rama 0.3 alpha 4. But all that and more we will cover later, near the ending of the episode. Before we go over some lessons that we learned in the past year with the 19 episodes of Netstack.FM that we covered so far, I would like to also present some numbers. In the top 5 episodes of this year was first of all number 1 Tokio with Carl Lerche that has the most views and after that came Datastar and Hypermedia which was episode 4. On number 3 we had Hyper with Sean McArthur and episode 4 and 5 are the Google episodes which we had around zero copy and Fuchsia's Netsetak 3. We also have listeners all around the world. But the top 10 countries are in the first and second place by a big majority, United States and Germany. After that come India, Australia, Sweden, United Kingdom, France, Canada, Switzerland and Japan. listeners are represented by many more countries around this wonderful globe. So why are we doing this episode? Over the last episodes of Netstack.FM we've talked with people who built or studied core parts of the internet. Such as HTTP, URLs, asynchronous times, browsers, proxies, network stacks, tooling, etc. Today is a reflection of what we've learned so far and what we can do about it as a global community. We learned that networking is more than just protocols. It's also how we use them and put systems together. protocols, they define the possibilities, but the systems define the outcomes. And these systems need to continue to evolve. And what many of our guests agree with is that one of the hidden superpowers of Rust is that it helps us to continuously refactor and evolve our code bases. Async Rust is also a huge win, but we are still awaiting on some parts. We learned in episode 5 with Carl Lerche that Tokio succeeded by rejecting the callback abased async and it was the right solution at the right time. In that episode he explained the history of Tokio, its present and the future. There is no built-in async runtime in Rust or in the standard library. Of course some people they consider Tokio to be very much that and for example frameworks such as Rama have official support only for Tokio as it's one and only asynchronous time. Others are more pragmatic. For example, in episode 2 we talked with Sean McArthur, who is very well known as the author and maintainer of Hyper. And it might come as no surprise, but he got a lot of love from many of our different guests in the last 19 episodes which we produced so far. For example, in episode 15... We talked with Edward and Noah from Cloudflare about Pingora and their other rust work. They do not use Hyper directly, but they have for example the h2 fork and they also contributed upstream patches in the name of security. But even so, most of the H2 crate was already fine as is, as Sean also blogged and whereas many H2 implementations in the wild were vulnerable to the rapid reset attacks, was dubbed CVE-2023-44487, h2 itself was unaffected. This is a great testimony not only to the great craftsmanship of Sean and his fellow contributors, but also to the Rust language which empowers all. with its philosophies and rich type systems. In episode 9 for example we talk with Lucio Franco about GRPC and the many tonic rates which he maintains within the Hyperium space. He and many more had nothing but good to say We would like to make a great shout out to Sean. as he is a true driving force within the Rust HTTP space for his work and his well-known crates such as Hyper, HTTP, H2, H3 requests and more. Keep it up Sean and a Happy New Year! In the last episodes we also learned that optimization is about memory but a lot less than you think. For example, I come from C and C++ and within that space and while working on game engines, games, trading systems and more, there was always lot of attention and detail to the memory management. To my surprise, this was not much of a concern of many of our guests that shared their stories with us. For example, Noah, For example in episode 15 we learned from Noah that if you use a memory allocator such as jmelc you already get a huge boost without having to do anything especially when building proxies and similar kind of web services due to how it deals with memory fragmentation and memory use. which among many other things prevent the expensive syscalls that otherwise drag you down. And for those who don't know In a past where the animals could still talk, jmalloc was in fact the default memory allocator of Rust. Only later, still before the 1.0 days if I recall correctly, was it swapped out with the default system allocators. can see that there's not all that much attention to memory management besides the obvious things most people would pay attention to anyway. For example, buffers, parsing or storing resource data once and sharing it across pipelines. And a good example of this is for example, zero copy, which in episode 10 Joshua from Google shared a lot about and many of us are inspired by that and in fact that also one of his missions as he told himself to now spread forward the zero copy philosophy which he hopes will live and spread far beyond the zero copy crate itself We also learned that protocols are social contracts, not just specs. Protocols, they unlock possibilities and they provide a canvas. But they are also in between the lines and words, a set of social For example, from the great Larry Massenter, we learned in episode 17 a whole lot about early history of the web and how it evolved. We also learned that the difference between the URI and URL is mostly just a naming decision, which surprised me very much. And even the greatest philosophers, according to him, will continue to sleep over the inability to define what a URI really is, regardless how you name it. We also learned from him that the implementation and critical evaluation of when to use a protocol is just as important, if not more, than the spec itself. Key insights we take away from that are HTTP won because it was open, flexible and forgiving, in contrast to for example Gopher, which was not open. gRPC succeeded because of tooling and consistency. The generation of clients based on strong typed and well-defined APIs was built in from the start. This results in a consistent and pleasant experience across languages with performance in mind from start to finish. It's a strong contrast with the efforts such as OpenAPI, what used to be called Swagger, where such things are a mere afterthought, with all the unfortunate side effects that come with such a thing. Something we also take away is the wonderful network and cooperation that happens within network. From multiple guests, not the least from Max Inden, who taught us many great things about Firefox and how they are building a rock solid Quic stack at Mozilla. He had great things to say about the IETF meetings which are open to all and allow you to make a real difference by helping to define the specifications of tomorrow. In episode 14 we had the great honor to talk with Tertz and Arya from NLNet Labs about the foundational BGP and DNSSEC technologies they are building in an open and collaborative way. and how despite this open nature they managed to keep it sustainable by finding commercial partners who have shared interest in making their missions happen and have the funds and means to contribute financially in meaningful ways. and while we talk to all our guests individually, many of them work together on one or multiple projects. A Prime example of this is Dirk Jan Ochtman. In episode 7 we talk to him about RustTLS Hickory DNS and ACME. But honestly if you start to pay attention to networking space in Rust you will see him in many different repositories and spaces as a contributor in one way or another. He is a truly active individual who just as NLNetLabs has found a way to do open source work in a sustainable and comfortable manner. For others, reaching this kind of sustainability and as a result unlocking the potential of doing it full time can take many more years. In episode 6 we talked with Daniel Stenberg about his personal journey and the history and evolution of curl. In it we learned a lot, including the fact that it took close to two decades before he could work on Curl full-time in a sustainable manner without having to do it after hours. It was also one of the things that we wanted to achieve with this podcast to highlight the humans, individuals, teams and organizations behind the protocols, implementations and applications. These are the hackers we owe a lot to. . As said before implementations matter just as much, if not more so, than the specifications of the protocols and conventions. From Martin we learned in episode 16 all about Sound.io and what it unlocked. He is a key driver in this space with Sans IO implementations for HTTP, which is the ureq Crate as well as WebRTC, which is the str0m crate Joseph Dye from PingProxies had in episode 13 also many great things to say about this. If you do this well, take these lessons to heart and build technology from the ground up as a small team of craftspeople, you can get greatness and you will unlock your wildest dreams. The great folks at Oxide Computer are a true testimony to this. Ryan Goodfellow was our guest in episode 12 to talk to us about this and more. A key insight from the oxide episode was that building up availability is very important and the better insights you get at runtime the easier it is to tackle edge case issues in production. In fact, they also have their own podcast, Oxide and Friends, and one of their own observations was that this year they talked a lot about debugging systems in the wild. It might be a sign of their maturity, but the fact that they can solve them so well also shows the great tooling and foundational technology they have built from the ground up. Metrics, logs and traces all are different answers for different or shared failure modes. Retrofitting observalability is nearly impossible. Great tooling to present and consume this data can help a lot as well. Metoro is a great example of this, which we learned all about in episode 3. In this episode Chris explained to us about the insights and utility one can have when combining the power of open telemetry, the insights that EBPF can unlock and how useful this combination is when having the ability to present it as nicely as Metoro does Lastly, in the previous episode, episode 19, Firezone and learned about the modern VPN systems they are building, powered by Rust. This and all our other episodes, one release per week, since the date we started, are highly recommended to listen to. We heard from some people who discovered the show quite late, that it is high quality binge material. That said, similar to how you see a clear difference between the first three Star Wars movies and the three movies afterwards, you will also notice that our editing and other production work on the episodes greatly improved starting from episode 6 and beyond. At least our episode numbers were chronological since the start. Some protocols are also mostly forgotten by most until one individual gives it a spotlight it deserves. SSE or Server-side events is a very small protocol built on the fact that HTTP response payloads can be streamed ever since the original HTTP versions. In HTTP 1 it was until the connection was closed as in those days, to surprise of many perhaps, It would be just a single request and response pair pair connection. With HTTP 1.1, came many improvements, one of them is the concept of keep-alive connections, allowing us to reuse connections for many different requests and responses. Streaming responses are supported here by the use of chunked encoding, which prefixes lengths to the next chunk of data it streams. Starting from H2, thanks to the benefit of historical lessons behind us, we solved it in much cleaner manner. H2 and beyond works with data frames. And these frames allow us to stream by default, without the need of awkward chunked encoding or relying on the connection to be closed. In fact, starting from H2, we are working with hundreds of different independent streams over the same connection, and this is also what powers gRPC. We cover that greatly in episode 9 with Lucio Franco. SSE is a combination of a small web API combined with a protocol that defines how to format the streaming data in terms of data events. In episode 4, Delaney Gillian from the Datastar Federation helped us to understand what Datastar is and how it fits in the hypermedia traditional web. It also teaches us that all implementations are not equal and that there are benefits in bringing your own JS client for SSE endpoint consumption. One can only hope that browser implementers pick up these insights so that the datastar JavaScript library can be even smaller than it already is today. beauty is found in simplicity. DataStar built on the principles of SSE and HTTP combined with the modern semantic HTML of today and the powerful CSS features now widely available in most browsers shows how delightful it can be to build web services with a modular framework like Rama. It is a choice we make every day when designing web services, proxies and clients. Now sometimes and also perhaps because our website is ramaproxy.org, folks think Rama is just for building proxies. And I understand why. I mean the website doesn't help. But it's a website we like and we want to stick with it. And in fact Rama's origin is also in building proxies. We were building proxies and similar technologies for over a decade already in many different languages and built on many different foundational technologies. And what I always tell people is that a proxy is basically just a server and a client combined together. But it goes further than that. Because a proxy's job is also to be pretty invisible. Not always because the user doesn't know that the proxy is there. In fact, most of time they know very well that they go via a proxy. But the job of a proxy is to do a very specific job or set of tasks. and it shouldn't do anything beyond that scope. For example, in case it needs to monitor and inspect web traffic, you don't expect it to modify unrelated headers or break things by dropping data or modifying something in unexpected ways. If, for example, the only job of the proxy is to inject a specific header to make sure that the upstream service can work with the incoming request, then you wouldn't expect it to change the entire cookie header for example. And to do this you need a network stack about which you control every little part. At the very least it needs to do the out of the box need to have the ability to control it in such a way that it works for you and not the other way around. As such, along the way while building Rama, we discovered that if you make a framework in a modular way that Rama is, and you can build with it proxies with all the middleware you want in such a fashion that you can route the traffic and shape it how you want, Then you can just as well build web services with it. You can also build clients with it. and you can do all kind of stuff. In fact that's the goal. The goal is there to empower you so that you can build any kind of network service within any kind of protocol. It's a very big goal and there is many decades of work ahead of us. But at this point we are almost there where we have the foundations to continue to build everything else. So knowing all this and knowing what we learned about all the 19 episodes behind us, where does Rama fit into all of this? Well, we didn't start more than 3 years ago with Rama because we just wanted a new framework. It appeared because these patterns kept repeating. We want explicit layers instead of hidden stacks. We want async without pretending abstraction is free, or always has to be. Neither do we want async where we always have to handwrite our own futures, like it used to be in Rust right now, especially since the Impletrate return types, there are much better ways, even if not perfect yet. We want observability as a first-class concern and built-in right from the start. It has to trickle down through every part of the system. We want protocol pragmatism. Where protocols are just layers. Where protocols can work together and be combined in any way you wish. For example Socks 5 over TLS. It is possible, why not? But most tools will not allow you for it. In Rama you can. One of our community members recently made a joke, but it speaks truth. Rama turns engineers into lego players. The building blocks are there. Go build with them and bring your own or modified blocks where you need them. Now, Rama doesn't solve everything, and it shouldn't. It focuses on where leverage exists today. And if we can learn one thing from the great Daniel Stenberg himself, it is that good libraries will continue to evolve, grow and expand even multiple decades into the journey. By building on great foundations and with Rust as our programming language, we have the right tool for the exact job. These and Rama itself are here to empower you to unlock your true potential, so that you can stop reinventing the wheel and instead deliver your unique business values. also received some great Rama testimonials over the last couple of months. Most want to privately share this as they do not want to disclose the specific information about companies they work for or projects they are building internally. However, we did have a couple of people who did want to step forward and some did it already in a very public way. For example Irfan, he wrote a great blog post about frontend to low level networking where he shared his journey contributing to open source. We are glad to see how Rama has helped him to get into the deep layers of networking to the point where he was able to build service with Rama and even more contribute to our framework and add external capabilities to our Rama CLI tool. we will link in the show notes to the blog article he wrote. But here is already also a little audio message which he wanted to share with you all. Irfan (Community Member)
23:25 | 🔗
Hello everyone, my name is Irfan and I'm a software developer here at Montreal, Quebec, Canada. ⁓ So I've been a front end developer for the last eight plus years. So recently I started doing some back end development and also this year I started contributing to open source. So that's where Rama comes in. As a newcomer in this space, Rama gave me like kind of like the most amazing experience. Shout out to Glenn, the maintainer, where he helped me with mentorship, amazing experience with mentorship and co-review. ⁓ It just made my learning in unfamiliar territory a very smooth experience. When I first go into Rama documentation, it just feels so easy to understand, yet it's kind of complex in nature, you know? Because this space, networking and low-level stuff is very new to me. ⁓ and also learning Rust, et cetera, that really puts me on, like, can make it very uncomfortable, but then reading about Doc and the open source maintainer giving me some mentorship and community is very nice, and that made me really, really comfortable. ⁓ So I made my couple of contributions for the last couple of months. ⁓ with the Stunnel features and the routers and etc. It's a very, very cool learning experience. And Rama just made it very ⁓ easy to start and easy to contribute. And what I really like about Rama is when I go into the website and I saw the read the documentation, even though I'm unfamiliar, but yet I still understand, starting to understand. It's easy to understand, easy to learn, yet it's... I know that it's very powerful and very complex in nature because it's a big code and it's like, there's so much more stuff you can do, ⁓ build on top of Rama and you can just give you that flexibility of things that you can do, you know? So, ⁓ I really liked that and how I'm using it is just, I'm just currently learning. I'm learning Rust and I'm learning low level networking, backend systems, et cetera, et cetera. So. This is a very, very, very good experience for me and ⁓ hopefully next year I can continue to contribute and learn more. I have no doubt this community is gonna thrive and keep growing as the years to come because of the amazing people that maintain this project. ⁓ So yeah, I think that's about it for me. So I hope you guys have a happy new year. Thank you Irfan for sharing this audio message. Now, he is not alone in this. We had many contributors in Rama who came to Rama because they wanted to learn. And we are glad that we can offer this space and opportunities of mentoring. It's a win-win for all of us. Another member of our community told us that he was able to build 4G proxies with Rama in a production setup with little to no effort. In the last two years we also helped to onboard several companies and organizations to onboard them on Rama and have them get started with building their first projects with Rama. Not because they needed this help, but because they saw the mutual benefits in doing so. We offer service contracts to help you build, maintain, educate and more. also a pragmatic way for these organizations to keep Rama, its projects and development sustainable. You can find more about our service contracts on our website. Now what's coming for Rama? .To start we released the last alpha version of 0.30, which is named 0.30 alpha 4. This was the last alpha release and we are now in the last Miles towards the 0.3 release, which is planned for the end of January 2026. Starting from that release we also plan to release more frequently and in smaller chunks. A lot has happened since 0.2 release and all companies, organizations and individuals that we know of that work with Rama and some of them also work with us, for now they've been using Rama from the main tipkit branch. Now this works especially when they have us helping them maintain some of their code bases, but it will be nice when starting from early next years these teams and individuals can instead start using Rama from an actual version number. which will be starting from 03.0. End of January would also like to take the opportunity to thank Brecht Stamper who has stepped up big time to help maintain Rama and has helped driven forward several new features such as ACME and certain TLS capabilities. But he was also the key figure in helping drive forward the big redesigns and refactors around rama service trait and state management Gone is the context type. The context type was there to combine static states with dynamic state as well as some other utilities. However, after a lot of usage by ourselves and other partners, it turned out not to be the right tool for the job. It was leaking everywhere and it had very little benefit outside a very specific use case. This and a lot more has led to new Rama service design. State injection and its dynamic but simple extension system are now easier to use than ever before, while unlocking many new possibilities. We are working very hard to make Rama 0.3 happen, which will be the foundation for the versions to come. And starting in 2026, we will start to speak on conferences and meetups about Rama. The first one will be FOSDEM in Brussels, Belgium. there will speak at the Rust track on the 1st of February about rethinking network services, freedom and modularity with Rama. Other conferences are yet to announce their speakers, but with some luck you might also hear more about Rama on conferences such as the first ever Tokio conference as well as the Rust NL weeks. We are also looking into several meetups, but these are yet to be decided upon. If you organize a meetup, especially in Belgium, feel free to reach out to us. Now that the foundations of Rama are becoming more stable and we are in the phase of expanding our feature sets such as the gRPC and Quic support and of course everything else that is unlocked by this, we are also going to work hard on education and documentation. You can expect throughout 2026 that we start to blog more about Rama, start to make tutorials both in text and video formats about Rama and the network knowledge that comes with it. From Fabian Sanglar in episode 18 we learned that well-drawn diagrams play an essential role in conveying knowledge. We will do our best to apply that lesson in our new educational material. The goal is that you can lock your true potential and own the network stack on which you are building. Rama is not just a framework, it is a paradigm shift to think differently, go forward and build together with us. After all these episodes and our work on Rama, a modeler service framework for Rust that helps you build proxies, servers and clients with full control over your network stack, one thing is clear. The future of network isn't about just one new protocol or just another framework. It's about better mental models, explicit systems, honest abstractions, tools that respect reality and collaboration and respect. netstack.fm exists to explore that space and its global community, slowly, openly and in collaboration with the experts that make progress happen. As such, this episode is not a conclusion, it is a checkpoint. We wish you all a happy new year and best wishes to you and your loved ones. We hope to see you back in 2026 in the next episode of Nestec.fm and invite you all to join our Rama community. Take care! Elizabeth (Plabayo)
32:07 | 🔗
Netstack.fm is brought to you by Plabayo building secure, open, and resilient infrastructure with Rust protocols, and purpose. This show is also made possible by Rama, the open source networking framework. Plabayo offers service contracts and welcome sponsorships to keep building and supporting its ecosystem. The theme music of this podcast was composed by DJ Mailbox. If you enjoyed this episode, don't forget to subscribe on your favorite podcast platform and leave a five-star review. It really helps others discover the show. Thanks for tuning in. We'll see you next time for the next handshake.