DEV Community: Yash Kumar Saini

I Built My Friend a Mock Interviewer That Read His Rust Code

Yash Kumar Saini — Mon, 05 Oct 2026 13:53:30 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

grill is a mock technical interviewer that has read your code. It runs in a terminal, on an open model, on your own laptop.

I built it for my friend Akash. He has spent the last year writing Rust, ships TypeScript on the side, and is looking for a full-time role. The rounds he dreads are the Rust and JavaScript deep dives.

Most interview prep tools ask the same textbook questions: what is a closure, explain ownership. Real senior interviews do not go that way. They go "walk me through your project", and then the interviewer points at one line you hoped nobody would notice and asks why.

You cannot practise that with a question bank, because the questions depend on your code. So grill does three things:

Reads his repositories and finds the lines worth a question: unsafe blocks, locks, lifetimes, spawned tasks, useEffect, forEach(async ...), any, empty catch.
Interviews him on them. One question about that exact code, one follow-up that presses on the weakest part of his answer, then a grade from 0 to 4 with what he missed.
Remembers what he got wrong. The next session draws more from his worst topics.

Here is the scanner on four of Akash's public repositories. This is real output:

116 spots, and the top one is in miccli, his voice dictation CLI: an Arc<Mutex<...>> shared with a real-time audio callback. That is exactly the line a Rust interviewer would circle.

Demo

A session looks like this. The code and location are real scanner output; paste your own question, answer and grade from a real run in place of the placeholder lines:

── 1 of 5 ──
AkashJana18/miccli src/audio.rs:62  shared-state
62 │     pub fn start_capture(&self) -> Result<AudioStream> {
63 │         let (tx, rx) = mpsc::channel();
   │         ...
72 │         let sink = Arc::new(Mutex::new(PendingResampler::new(
   │         ...

Code

yashksaini-coder / grill

grill

A mock interviewer that has read your code. It runs on your laptop, on an open model, with no network.

Most interview prep asks textbook questions. Real senior interviews ask "walk me through your project", then press on the one line you hoped nobody would notice. grill clones your repositories, finds those lines, and asks about them.

Built for Akash, who writes Rust and TypeScript and is interviewing for full-time roles.

── 1 of 5 ──
AkashJana18/miccli src/audio.rs:62  shared-state
62 │     pub fn start_capture(&self) -> Result<AudioStream> {
63 │         let (tx, rx) = mpsc::channel();
   │         ...
72 │         let sink = Arc::new(Mutex::new(PendingResampler::new(
   │         ...

Why is `sink` behind a Mutex, and what does the audio callback do if that lock is contended?
  >

The code and location above are real scanner output. The question is an example of the kind a model asks; yours will differ.

Demo

Recorded…

View on GitHub

About 1,300 lines of TypeScript including tests, three runtime dependencies, MIT licensed.

ollama pull gemma3:4b

git clone https://github.com/yashksaini-coder/grill && cd grill
npm install && npm run build && npm link

grill ingest AkashJana18/miccli AkashJana18/solana-consensus-lab
grill start                    # 5 questions
grill start -n 3 --lang rust   # Rust only
grill report                   # the weak-spot map

How I Built It

The open pieces:

Gemma, Google's open-weight model, served by Ollama on localhost.
Mastra, the open-source TypeScript agent framework, for the two agents and the tool.

Design rule: the model gets one small job at a time

A 4B model running on a laptop is not going to plan an interview, hold a rubric in its head, and remember what it asked five turns ago. So I did not ask it to. The order of steps lives in ordinary TypeScript. The model is only ever asked to do one of three things: write a question, write a follow-up, or grade an exchange.

Every one of those calls is handed the real snippet again. The model never has to recall code, so it has less room to invent it.

Stage 1: finding the lines worth asking about

The scanner is a table of 38 patterns, 17 for Rust and 21 for JavaScript and TypeScript. Each one carries a topic, a weight, and the angle a good interviewer would take:

rust("lock", "concurrency", /\.(lock|read|write)\(\)\s*(\.await|\.unwrap\(\)|\?)/, 4,
  "how long the guard lives, whether it is held across an await, and what a poisoned or contended lock does"),

js("async-in-loop", "async", /\.(forEach|map|filter|reduce)\(\s*async\b/, 5,
  "what actually awaits here, the order of completion, and how errors surface"),

A regex hit on one line is not a question. So for every hit, the scanner walks up to the enclosing function, matches braces to find its end, and frames the whole thing. Weights are summed per function, overlapping frames are dropped in favour of the strongest, and each repository contributes its best 40 spots, round-robin across topics so a codebase full of .unwrap() does not turn the whole interview into error handling.

This is regex and brace counting, not a parser. It finds interesting code. It does not understand it. Understanding is the model's job.

Stage 2: two Mastra agents on Gemma

Mastra talks to Ollama through its OpenAI-compatible endpoint, so there is no provider SDK and no API key:

const model = { providerId: "local", modelId: config.modelId, url: config.url, apiKey: "local" };

this.interviewer = new Agent({ id: "interviewer", name: "interviewer", instructions: INTERVIEWER, model });
this.grader = new Agent({ id: "grader", name: "grader", instructions: GRADER, model });

The interviewer is told to ask exactly one question, to name an identifier from the snippet so the candidate knows it read the code, and never to answer or hint.

The grader is a separate agent with a separate prompt. It did not write the question, so it has no stake in the answer being good. It returns JSON:

{"score": 2, "verdict": "one sentence", "missed": ["specific point"], "better": "the answer you wanted"}

Small models wrap JSON in prose and code fences. Instead of trusting the reply, grill pulls out the first balanced {...}, validates it with zod, and if that fails, shows the model its own bad reply and asks once more.

There is also an opt-in read_source tool (grill start --tools). It lets the interviewer read beyond the snippet, for example to see a caller or a type definition. It is confined to the repository: a path that resolves outside the checkout is refused. It needs a model with tool calling, so it is off by default.

Stage 3: the weak-spot map

Every round is saved as JSON under ~/.grill/sessions. The next session picks spots with a weighted draw:

export function priority(spot: Hotspot, seen: Set<string>, stats: TopicStat[]): number {
  const stat = stats.find((s) => s.topic === spot.topic);
  const weakness = stat ? (4 - stat.mean) / 4 : 0.5;
  const repeat = seen.has(spot.id) ? 0.15 : 1;
  // Squared, so the first session opens on the richest code, not on filler.
  return spot.score ** 2 * (0.5 + weakness) * repeat;
}

Score a 1 on lifetimes and lifetimes come back. Score a 4 on unsafe and it fades. Spots already asked are rare but not banned, because being asked the same thing twice is how you find out whether you learned it.

Testing an LLM app without an LLM

I did not want the test suite to need a GPU. The tests start a fake OpenAI-compatible server on a random local port and point the real Mastra agents at it. That covers a full round, the JSON retry, :skip and :quit, and the tool call including the path-escape refusal. 18 tests, a few seconds, no model.

Why Does Open Innovation Matter?

For this project it is not a preference. A closed API would have made it a worse tool for Akash in four concrete ways.

His fumbled answers stay his. Interview practice only works if you are willing to be wrong. grill stores every weak answer he gives, by design. That file sits in ~/.grill on his disk. With a hosted API, the same record of everything he does not know would be on someone else's server.

Private code works. grill ingest takes a local path. Work code under NDA, the repository he cannot push anywhere, the side project he is not ready to show: all of it can be interviewed on without leaving the machine. Once the model is pulled, a local-path session needs no network at all.

Practice is free, so he can do a lot of it. Three model calls per question, five questions per session, as many sessions as it takes. On a metered API that is a bill that grows with exactly the behaviour I want to encourage.

He can change the interviewer. The rubric is a string in src/interview/mastra-brain.ts. If he is preparing for a company that cares about system design more than language trivia, he edits the prompt. If he gets a better laptop, GRILL_MODEL swaps in a bigger model in one environment variable. If Ollama is not his thing, GRILL_URL points at llama.cpp or LM Studio. Nothing in the tool is tied to one vendor.

Open weights made it private and free. An open framework made it changeable. He needs all three.

Limits, honestly

The scanner cannot tell a deliberate unwrap() from a careless one. It surfaces candidates; some are dull.
Question quality is the model's. A larger local model asks sharper questions.
The grade is a study aid, not a verdict. Read the "missed" list, not the number.

Prize Categories

Best Use of Gemma. Gemma runs locally through Ollama and does all three jobs: asking, pressing, and grading. The whole design, with fixed orchestration and one small task per call, exists to make a small open-weight model enough.
Best Use of Mastra. Two Mastra agents over an open model, plus a sandboxed read_source tool, wired to a local OpenAI-compatible endpoint with no provider SDK.

Dev log #24 Hardening the p2p stack: From flaky tests to WebSocket fixes

Yash Kumar Saini — Mon, 05 Oct 2026 09:12:47 +0000

Hi, glad you found your way here. I'm Yash, a developer who contributes to open source, mostly p2p networking and AI tooling. Each week I write up what I shipped, what broke, and what fixing it taught me.

GitHub · X · LinkedIn · Portfolio

TL;DR

If you've ever had a CI run fail because a test expected a packet to arrive in exactly 200ms, you know my pain this week. I spent most of my time moving away from clock-based testing and toward progress-driven logic, alongside some critical bug fixes in the Python libp2p stack. Across 22 commits and 15 code reviews, it was a heavy week for p2p infrastructure and making sure our networking primitives actually behave when the network gets noisy.

What I Built

Most of my energy went into minip2p, where I’m deep in the weeds of making the Rust implementation more resilient. I pushed 14 commits there, but the real story is in the refactoring.

minip2p: Killing the Flaky Test

There’s nothing that kills developer velocity quite like a flaky test suite. I opened and closed Issue #261 this week because our timing-budgeted tests were falling over whenever the CI runner got too busy. We’ve all been there: you put a sleep in a test, it works on your machine, and then it fails in GitHub Actions because the runner is under-provisioned.

I landed PR #284 to address this. Instead of waiting for the clock, I refactored the tests to be driven by progress. For the TCP transport tests, I stopped waiting for an arbitrary 200ms and started waiting for the socket to actually fill and drain. I also had to isolate the relay reservation and timer-bound tests in nextest to ensure they aren't fighting for resources. It’s the kind of unglamorous work that makes the whole project feel more professional.

Beyond the tests, I landed a pretty significant refactor in PR #260. I wanted to consolidate how we handle framed exchanges. Now, AutoNAT and Identify (two core p2p protocols) share a framed exchange and are properly bounded by their declared lengths. It’s a bit of "defensive networking"—ensuring a peer can't just stream infinite data at us during a handshake.

py-libp2p: Fixing the Leaks

On the Python side of things, I spent some time in py-libp2p. I noticed a gnarly issue where the WebSocket transport was being a bit too generic with its error reporting. Basically, every failure after the initial connection was being swallowed and reported as a "handshake timeout," which is incredibly frustrating when you're trying to debug a real network issue. Even worse, it was leaking the TCP socket in the process.

I closed Issue #1554 by landing PR #1556, which ensures we report the real dial failure and, crucially, close the socket so we don't bleed file descriptors. I also followed up with PR #1555 to make sure we’re actually verifying server certificates on wss:// (secure WebSocket) dials. Security isn't optional, even in p2p.

Trak: Cleaning up the Indexer

I also made a quick pit stop at Trak, a Rust project I've been helping out with. I noticed the indexer was getting distracted by test fixtures. If you have a directory full of mock code for tests, you don't necessarily want your primary code indexer treating those as real declarations. I landed PR #1 by updating the logic to read declarations from source code only and explicitly exclude test fixture trees. It’s a small change (+532/-12), but it makes the tool much more accurate for its users.

Pull Requests

It was a "clean sweep" week for PRs—5 opened, 5 merged.

[minip2p #284]: The big test overhaul. Moving from sleep() to actual state-checking.
[minip2p #260]: The core refactor. Sharing framed exchanges between protocols.
[py-libp2p #1556]: Fixing the WebSocket socket leak and improving error transparency.
[py-libp2p #1555]: Enforcing WSS certificate verification.
[Trak #1]: Narrowing the indexer's scope to exclude noise.

Code Reviews

While I only had 22 commits of my own, I spent a massive amount of time in the dotnet-libp2p repository. I provided 15 reviews this week, and honestly, this is where a lot of the "architectural" thinking happens. Helping the C# implementation stay in sync with the wider libp2p spec is a challenge, but the team there is shipping some great stuff.

Some of the highlights from the review pile:

QUIC on Windows: Reviewed a PR to enable the QUIC transport for Windows users.
Gossipsub Hardening: Looked at changes for handling partial messages and using IDONTWANT for large gossip messages to save bandwidth.
Security: Approved a move to P-256 ephemeral keys for TLS and better validation of gossip signatures before they hit application hooks.
Reliability: Gave the green light on PRs for preserving Yamux replies and handling segmented writes more gracefully.

Reviewing 15 PRs while only opening 5 of my own definitely made this a "mentorship and alignment" week. It's important to keep the ecosystem moving together, especially when you're working across three different languages.

Tech Stack

This week was a polyglot special:

Rust: My main focus for the heavy lifting in minip2p and Trak.
Python: Used for the py-libp2p maintenance and bug fixing.
C#: Purely on the review side, ensuring the .NET implementation is solid.

The numbers tell a story of growth: +2,503 / -357. That’s a lot of new code, but a good chunk of that was the test infrastructure and the refactored protocol handlers. I'm okay with a net positive line count when it means the tests are finally stable.

What's Next

Next week, I want to double down on the minip2p transport layer. Now that the tests are stable, I can actually start benchmarking performance without worrying about the CI runner's mood. I'm also keeping an eye on the open PRs in the Python and .NET stacks—there's a lot of momentum right now in the p2p space, and I want to make sure we keep that energy going.

If you're building p2p tools, stop using sleep() in your tests. Your future self (and your CI) will thank you. See you next week!

Generated by DevNotion

Dev log #23 Polishing the stack: Diagrams, async shutdowns, and a whole lot of code reviews

Yash Kumar Saini — Sun, 27 Sep 2026 14:02:10 +0000

GitHub · X · LinkedIn · Portfolio

TL;DR

This week was all about clarity—both in the code and how we explain it. I spent a significant chunk of time in the docs and refactoring event flows, while also diving deep into code reviews for the C# libp2p ecosystem. 15 commits, 5 PRs, and 12 code reviews later, the p2p stack feels a lot more solid.

What I Built

Most of my energy this week went into minip2p. It’s one thing to build a p2p library in Rust; it’s another thing entirely to make sure people actually understand how to use it. I spent a lot of time in docs/pages and docs/components, trying to visualize the invisible.

I tackled a major refactor in the core crate, specifically routing all capabilities through Endpoint events. This was a hefty PR—1,365 additions and 939 deletions—aimed at making the internal event system more predictable. When you're dealing with p2p networking, state management is everything. Moving toward a more event-driven architecture for capabilities simplifies the mental model significantly.

On the documentation front, I realized the landing page needed more "meat." I built out diagrams to explain the connection attempt flow and the event loop. I used Tailwind to style these diagrams directly, ensuring they look great and stay responsive. I also spent time correcting some claims about the event loop and unsafe usage—it's vital to be precise when you're talking about Rust's safety guarantees. I even made sure to neutralize animation delays for users with reduced motion settings because accessibility shouldn't be an afterthought in dev tools.

I also jumped over to dotnet-libp2p to handle some protocol-level stability. I implemented async shutdown for the pubsub router and discovery protocols. In a distributed system, how you leave the network is just as important as how you join it. Without proper async teardown, you end up with hanging resources or weird state issues on the peer side. While I was there, I bumped Microsoft.SourceLink.GitHub to clear up a pesky NU1902 restore failure that was gunking up the CI.

Pull Requests

I had five PRs on the move this week, and I'm happy to say four of them are already merged.

The big one was Route all capabilities through Endpoint events (#177). It was a deep-tissue refactor of the minip2p core. It’s always a bit nerve-wracking to move over 2,000 lines of code in a networking stack, but the result is a much cleaner interface for how we handle peer capabilities.

In the Python world, I opened an enhancement for py-libp2p to randomise per-round lookup candidate selection in the Kademlia DHT. Randomization is a small change—only about 150 lines—but it’s a huge win for network resilience. It prevents the lookup process from getting stuck in a loop or being biased toward the same set of peers every time. That one is still open and undergoing review.

The rest were mostly focused on the C# side, getting those async shutdowns merged and fixing the build pipeline.

Issues & Discussions

I spent some time clearing the deck on the issue tracker for minip2p. I opened and subsequently closed Add UI sections to the landing page. This was the driver for all that Tailwind and diagram work I mentioned earlier. It’s satisfying to see a "docs" issue result in tangible, visual improvements to a project.

Code Reviews

If I wasn't writing code this week, I was reading it. I gave 12 code reviews, almost exclusively in the dotnet-libp2p repo.

The Nethermind team has been crushing it, and I spent a lot of time reviewing their Gossipsub implementation. We looked at everything from bounding Gossipsub control-plane work to supporting partial messages.

Reviewing 12 PRs while only opening 5 of my own definitely made this a "mentorship and maintenance" week. I approved work on TLS remote public key exposure, pubsub TTL cache eviction fixes, and hardening strict pubsub no-sign validation. It’s a lot of specialized p2p logic, but keeping the C# implementation at parity with the Go and Rust versions is a massive goal for the ecosystem.

Tech Stack

It was a polyglot week, leaning heavily into the typed world.

Rust: My primary focus for minip2p. I spent a lot of time balancing core logic with documentation.
C#: Used for the protocol-level work in dotnet-libp2p. The async/await pattern in C# is a different beast compared to Rust's futures, but it's equally powerful for networking.
Python: Just a touch of it for the Kademlia DHT work in py-libp2p.

With 2,661 additions and 1,439 deletions, it was a net-positive week in terms of LOC, but a lot of that "weight" is in the new documentation and diagrams. The refactors actually helped trim some of the fat in the core logic.

What's Next

Next week, I want to see that Kademlia randomization PR in py-libp2p get across the finish line. I’m also planning to dive back into the minip2p Rust crates to see if there are more areas where I can simplify the event logic now that the capability routing is merged.

There's always more to document, but for now, I'm just happy the landing page finally explains the event loop without me having to jump into a Discord call to draw it on a virtual whiteboard!

Dev log #22 Tearing out the old: Deleting 3,800 lines of legacy p2p code

Yash Kumar Saini — Mon, 21 Sep 2026 04:00:59 +0000

GitHub · X · LinkedIn · Portfolio

TL;DR

There is no feeling quite like watching a PR diff show thousands of red lines and only a handful of green ones. This week was all about that catharsis. I spent my time simplifying the p2p stack, specifically by ripping out legacy protocols in Rust and hardening storage layers in Python. Across 5 commits and 3 PRs, I managed to delete nearly 4,000 lines of code while only adding about 160. It was a week for codebase health and architectural clarity.

What I Built

Most of my energy this week went into minip2p, a Rust-based peer-to-peer networking stack I've been contributing to. If you’ve spent any time in the libp2p ecosystem, you know that Floodsub is the "old way" of doing pubsub—it’s simple, but it’s incredibly noisy and inefficient because it just broadcasts everything to everyone. Gossipsub has been the standard for a long time now, and maintaining both in a "mini" implementation started to feel like unnecessary baggage.

I pushed 3 commits to minip2p that effectively scrubbed Floodsub from the entire project. This wasn't just a "delete the file" kind of task; it was a breaking change that rippled through the public API and the documentation. I had to touch 53 files to make it happen. The commit messages tell the story: I started by dropping it from the README and the docs site, then moved into the core pubsub logic to make Gossipsub the only available router, and finally cleaned up the bindings so users don't even have to (or get to) select a router anymore. It’s a breaking change—marked with the ! in my commit messages—but the codebase is so much leaner for it. We're talking 141 additions against 3,876 deletions. That is a lot of technical debt gone in one go.

On the Python side, I spent some time with py-libp2p. This was less about architectural shifts and more about the "un-glamorous" work that keeps a project viable: fixing flaky tests. I’ve been annoyed by test_echo_thin_waist for a bit because of how it handled subprocesses. If a test doesn't reap its children properly, you end up with zombie processes and weird CI failures that have nothing to do with your actual code. I pushed 2 commits to ensure we're reaping those echo subprocesses cleanly. It’s a small change—18 lines added—but it makes the local dev experience and the CI pipeline significantly more stable.

Pull Requests

I had three major PRs in flight this week, two of which are already merged.

The big one was Remove Floodsub from every public layer (#199) in minip2p. This was the culmination of the work I mentioned above. Landing a PR that deletes 4,258 lines (including some generated code and docs) feels like a massive win. It simplifies the mental model for anyone new coming into the repo. You don't have to ask "which pubsub should I use?" anymore. There's only one, and it's the one that works at scale.

I also landed a fix in py-libp2p: test(examples): reap echo subprocess cleanly in test_echo_thin_waist (fixes #1541). This addressed a specific issue where the echo example tests were leaving processes hanging. It’s a small fix but a necessary one for keeping the "thin waist" of the protocol stack actually thin and manageable.

Finally, I have an open PR over at sixb titled storage: durable, swept file upload sessions for pg and sqlite. This is a much heavier lift on the "new feature" side of things. I’m building out a more resilient way to handle file uploads, ensuring that sessions are durable across restarts and properly "swept" (cleaned up) when they expire. It’s currently at 1,493 additions, which is where most of my "new" code lived this week. I'm supporting both PostgreSQL and SQLite, which always adds a layer of complexity when you're trying to keep the abstraction clean. It’s still in review, but I’m looking forward to getting this landed to make the storage layer more robust.

Code Reviews

I managed to get into the reviewer's seat twice this week, which I always try to do to stay connected with what else is happening in the ecosystem.

First, I looked at a PR in agent-orchestrator: feat(packaging): support Arch Linux and stop self-updates on system installs. Packaging is one of those things that is easy to get wrong, especially when it comes to "self-updating" logic. You really don't want a binary trying to update itself if it was installed via pacman. I approved this one as it makes the tool a much better citizen on Linux systems.

I also reviewed a PR in py-libp2p: eg/1130-add-gossipsub-comparison-and-standalone-examples. This was a nice coincidence given my work on minip2p. It adds better examples and comparisons for Gossipsub, which is exactly what the project needs as we steer people away from older protocols. Good docs and examples are the best way to prevent people from reaching for the wrong tools.

Tech Stack

This was a classic polyglot week for me, split between Rust and Python.

The Rust work was deep and structural. When you're working with p2p protocols, Rust’s type system is a godsend for making sure you don't leave any edge cases unhandled when ripping out a whole protocol layer. The net-negative line count this week is a badge of honor. Refactoring isn't always glamorous, but it’s how you keep a project from collapsing under its own weight.

The Python work was more about the glue and the storage logic. Python is great for iterating on things like storage sessions and test harnesses where you want to move fast. Even though I was adding code in my sixb PR, the overall week was still dominated by the massive deletions in minip2p.

What's Next

Next week, I’m hoping to get that sixb storage PR merged. It’s a big chunk of code, and I want to make sure the "sweeping" logic for old sessions is rock solid before it hits production. I'll also be keeping an eye on minip2p to see if my Floodsub removal caused any unexpected friction for downstream users—though, honestly, I think everyone will be happy to see it gone.

There's also some more work to do on the py-libp2p test suite. Now that the echo tests are stable, I want to look at some of the other long-running examples that occasionally time out in CI. It’s a never-ending battle, but someone’s gotta do it!

Dev log #21 Hardening WebRTC-Direct and solving SCM leaks

Yash Kumar Saini — Sat, 19 Sep 2026 05:49:17 +0000

GitHub · X · LinkedIn · Portfolio

TL;DR

This week was all about the "glue" that holds distributed systems together. I spent my time jumping between the Python implementation of libp2p and a Go-based agent orchestrator. It was a week of deep-dives into networking internals—specifically getting WebRTC-Direct to behave across different language implementations—and fixing some frustrating SCM polling issues. Across 8 commits and 11 PRs, I focused on making sure connections are actually closed when they're supposed to be and that our agents aren't hallucinating CI failures.

What I Built

Most of my energy went into py-libp2p, where I’m currently neck-deep in WebRTC-Direct work. Networking is one of those things where it works 99% of the time, and then that last 1% takes up 90% of your brainpower.

Networking Internals (py-libp2p)

I pushed 6 commits to py-libp2p this week, mostly centered on stabilizing the transport layer. One of the big wins was fixing a race condition in the WebRTC dialer where ICE credentials weren't being set correctly before the first-contact replay. This was specifically blocking interoperability between Go and Python nodes—one of those gnarly "it works in isolation but fails in the wild" bugs. I also spent some time on the housekeeping side, fixing socket leaks in both mplex and the swarm. If you've ever wondered why your long-running nodes eventually run out of file descriptors, it’s usually because of unclosed secured connections. I made sure that when we shut down, we actually release the underlying sockets.

Agent Orchestration (agent-orchestrator)

Over in agent-orchestrator, the work was more about the developer experience and SCM integration. I tackled a weird edge case where workspace files with backslashes in their names were resolving incorrectly on Linux and macOS. It’s a classic cross-platform path handling headache, but getting it right means one less "it works on my machine" conversation. I also looked into how the orchestrator handles GitHub polling—specifically an issue where it was re-listing every open PR because the since parameter wasn't being respected by the endpoint.

Pull Requests

It was a heavy PR week—11 in total. I had 4 merged, 3 still open, and 4 closed as I refined my approach.

In the py-libp2p world, PR #1513 was a big documentation push. I documented the STUN listener versus the SDP harness and provided guidance on v1 vs v2 dialing. Clear docs are just as important as clean code when you’re building p2p primitives. I also have PR #1532 open, which introduces a true ICE-Lite listener for WebRTC-Direct. This is a significant addition (+166 lines) that will make the listener much more robust.

On the bug-squashing front, PR #1497 and PR #1495 landed to fix the connection shutdown and WebRTC dial issues I mentioned earlier.

For agent-orchestrator, I had a few PRs that I ended up closing (#5089, #5088, #5057, and #5056). Sometimes you start a fix and realize there's a better architectural way to handle it, or you're iterating fast and a better solution emerges. I’d rather close a PR and open a better one than merge something that isn't quite right. However, PR #5055 did land, which fixed that backslash filename bug on non-Windows systems.

Issues & Discussions

I opened and closed 6 issues this week, which really tells the story of the week's detective work.

The most interesting one is Issue #1498 regarding residual unclosed-socket leaks. This is currently gating our filterwarnings guard in the test suite. Until we can guarantee the tests aren't leaking resources, we can't turn on the stricter CI checks. It's a bit of a slog, but it's the kind of maintenance that prevents technical debt from spiraling.

I also opened Issue #1512 for the ICE-Lite listener work. It's one of those features that started as a "nice to have" and quickly became a "need to have" for proper WebRTC-Direct support.

On the agent-orchestrator side, Issue #5046 was a fun find: the Copilot adapter was adding a permanent line to .git/info/exclude for every single session. That’s a great way to end up with a massive, messy exclude file if you’re not careful.

Code Reviews

Reviewing is where I get to see how others are thinking about the same problems. I did 2 reviews this week:

py-libp2p: I requested changes on PR #1139, which adds Gossipsub comparison and standalone examples. Gossipsub is complex, and while examples are great, they need to be rock-solid so they don't mislead new users.
agent-orchestrator: I approved PR #5137, which adds support for Arch Linux and—thankfully—stops self-updates on system installs. System-managed packages should be handled by the package manager, not the app itself.

Tech Stack

It was a Python-heavy week (6 commits/PRs) with a solid side of Go (2 commits/PRs).

Python: My focus here was almost entirely on the networking stack—handling sockets, bytes, and protocols.
Go: Used for the orchestrator work, dealing more with SCM APIs and file system abstractions.

With 508 additions and only 41 deletions, this was definitely a "building and fixing" week rather than a "cleaning and refactoring" week. I’m adding new capabilities to the WebRTC stack, and that naturally comes with a higher line count.

What's Next

The goal for next week is to get the ICE-Lite listener PR (#1532) in py-libp2p across the finish line. I also want to circle back to those socket leaks in the test suite. It's not the most glamorous work, but seeing a clean, green CI with no resource warnings is a special kind of satisfying. On the orchestrator side, I'll be keeping an eye on the SCM polling fixes to make sure our agent's view of the world stays in sync with GitHub.

Catch you next week!

The receipt should come from the person who received it

Yash Kumar Saini — Sun, 06 Sep 2026 17:33:22 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

Every donation platform proves the same single fact: money left your account. The fact you actually care about is the second one, that it reached a person, and the receipt for the first is issued by the organisation holding the money. The thing you're trusting and the thing producing the evidence are the same thing.

Cairn changes who issues the receipt.

You lock SOL in an escrow no intermediary can open. The only thing that moves it is a signature from the recipient's own wallet, and that transaction carries the hash of a recording where they say, in their own words, what they received. The receipt comes from the person at the end of the chain, and the chain welds it to the transfer.

Three commands, and the third one is the whole project:

cairn give     --to <them> --amount 0.05 --for "one term of school fees"
cairn receive  --escrow <pubkey> --audio receipt.wav   # they run this
cairn verify   <signature>                             # anyone runs this

cairn verify re-downloads the recording, re-hashes the bytes it gets back, rebuilds the receipt from scratch and compares the result against what's on chain. It doesn't ask my server to be honest. With cairn hash it doesn't need my server to exist.

A cairn is a stack of stones travellers raise along a route. Each person who passes adds one. It proves somebody came through, it guides whoever comes next, and it works with nobody owning it and nobody supervising it. Every clause maps onto something the software does, which is the only reason the name stuck.

Demo

docs/COMMANDS.md walks the whole loop with real captured terminal output at every step — funding an escrow, recording a receipt, releasing, and verifying.

The command that matters:

Those two hashes were produced by different code paths, minutes apart. The same command against a recording whose bytes have been altered:

Two visibly different hashes and a non-zero exit code, so it can gate a script.

Code

yashksaini-coder / Cairn

A weekend build. Lock some SOL for someone; they only get it by signing a transaction that carries the hash of a voice recording saying what they received.

Devnet. Not audited. About 4,500 lines of Rust, of which 400 are the test suite, and no frontend at all.

cairn give     --to <them> --amount 0.05 --for "one term of school fees"
cairn receive  --escrow <pubkey> --audio receipt.wav     # they run this
cairn verify   <signature>                               # anyone runs this

A real session against a local validator — the escrow is created on chain, the receipt is signed by the recipient's key, and the failure at the end is a genuine hash mismatch after the stored recording is altered. Also available as mp4, or replay it yourself with asciinema play assets/demo.cast.

The itch

Donation platforms verify that money left you. They don't verify…

View on GitHub

A weekend build: roughly 4,500 lines of Rust, 400 of them the test suite. MIT.

cairn/
├── programs/cairn/      custody, authorization, state machine
├── crates/
│   ├── cairn-core/      canonical receipt, hashing, seeds, account layout
│   ├── cairn-api/       blob store, index, verifier. Holds no keys.
│   └── cairn-cli/       the client. All of it.
└── docs/

How I Built It

The axis everything turns on

Two things here look similar and are not, and the entire design is the consequence of separating them.

Authorization is an ed25519 signature from the recipient key the donor names at creation. The program enforces it. No server key, operator key or admin override substitutes for it.

Testimony is the recording. Human evidence, hashed and committed on chain so it's tamper-evident and bound to exactly one transaction signature.

The recording authorizes nothing. Audio used as an authentication factor is walked through by replay or a decent TTS model, so Cairn treats it as attached evidence with guaranteed integrity instead. That's a much smaller claim, and it's one the software can actually keep.

Note the asymmetry. The recipient's way out is a signature; the donor's way back is a deadline. There's no third arrow and nobody standing in the middle.

One hash, and everything checks against it

Strip Cairn down and a single sentence is left: two independently computed hashes agree. Everything below exists to make that sentence hard to fake and easy to check.

It starts with the encoding.

receipt_hash = sha256(
    b"cairn:receipt:v1" ‖ escrow(32) ‖ audio_sha256(32) ‖ transcript ‖ locale(8) ‖ recorded_at(8)
)

locale is a fixed 8 bytes rather than a string, and that's the load-bearing choice. Every field except the transcript is fixed width, so for a preimage of length L the transcript is always exactly L - 96 bytes. The encoding is injective with no length prefixes anywhere: no two distinct receipts concatenate to identical bytes. Add a second variable-length field and that evaporates — ("ab", "c") and ("a", "bc") land on the same preimage, and two different receipts share one hash. A test named transcript_and_locale_do_not_smear exists purely to fail if someone later decides locale should be a String. Transcripts are NFC-normalised, trimmed and whitespace-collapsed first, so the same recording hashes the same regardless of which machine composed the receipt.

Then there's the question of how many implementations of that function exist, and the answer is one. cairn-core compiles to both sbf-solana-solana and the host, so the on-chain program, the CLI and the API server all call the same receipt_hash(). Not kept in sync, not mirrored, not generated from a shared schema — the same function, compiled twice. The account layout works the same way: Escrow is defined once in cairn-core and the program wraps it in a newtype that Anchor's traits hang off, so the bytes the program writes are the bytes the indexer reads, with a test asserting that Anchor's generated discriminator matches the constant the decoder uses.

That count is also why the client is a CLI. A browser would need its own receipt_hash(), which means hand-porting the normalisation into TypeScript, and JavaScript's \s and Rust's char::is_whitespace disagree about U+FEFF — a byte-order mark in a transcript gives you a browser reporting a valid receipt and a chain reporting a fake one. That character is patchable; the shape of it isn't. Any second implementation is a second answer, and an interface whose job is to display "these match" while running different code from the thing doing the matching argues against itself.

With one function to check against, three commands do the checking rather than taking anything on faith. cairn show re-hashes the description client-side against the on-chain need_hash, so the API can serve whatever text it likes and it doesn't matter. cairn receive rebuilds the receipt from the audio on the recipient's own disk and refuses to sign if the server's hash doesn't cover it. cairn hash touches no network, needs no key and reads no database — compute a hash with the wifi off and compare it against a block explorer.

Which leaves the server holding nothing worth stealing: no keypair, no signing path, no instruction it could call to move a lamport.

Speech, and why the transcript is a convenience

Transcription runs through ElevenLabs Scribe. The recipient speaks whatever language they actually speak, and the transcript joins the canonical receipt alongside the locale tag.

It's wired as best-effort enrichment rather than a dependency. The hash covers the audio bytes either way, so a receipt is valid with or without a transcript — the audio is the evidence, and the transcript is a convenience for whoever reads it later. Depending on a third party that lightly felt like the right call inside something whose whole argument is about not needing to trust third parties.

What Cairn proves

One sentence, precisely: that a specific recording, unaltered, was committed by the holder of a specific key in the same instruction that moved specific funds. There's no window in which the money has moved without a receipt, or a receipt exists without the money.

Every design decision above exists to make that sentence checkable by a stranger who has no access to me, my server, or my database. Every state transition has a happy-path test in LiteSVM, and every guard has a negative test asserting its specific error code. The one that carries the trust model is only_the_named_recipient_can_release.

Prize Categories

Best Use of Solana. The escrow program isn't a payment rail bolted onto the side of the idea — it's the only reason the idea works. A receipt that anyone with database access can remove is a receipt back under the control of the party you were trying not to have to trust, which is the exact problem the project starts from. Putting it on Solana moves custody into a program-owned vault PDA with deterministic seeds and no operator key, makes the recipient's ed25519 signature the sole authorization primitive, and makes the receipt append-only by construction rather than by policy. The program is the trust model. Everything off-chain is a convenience wrapped around it, and it says so by holding no keys.

Best Use of ElevenLabs. Scribe closes the language gap that sits between a donor and a recipient by default. The audio is the evidence, but audio in a language you don't read is evidence you can't check, and a transcript makes it legible to someone on the other side of that gap. The locale tag travels inside the hash preimage alongside the transcript, so the language a receipt was given in is part of what gets committed — not metadata bolted on afterwards, but a field the signature covers.

It was a good challenge that stretched me to make use of solana and AI together in a interesting manner. Interesting part was the idea of getting the scribe using eleven labs. Overall a good exercise to learn something new.

Yash K Saini — Engineer, building in public — AI/ML, low-level (Rust/C/C++), and open source.

Dev log #20 Deleting 180k lines and chasing socket leaks: A week in the OSS trenches

Yash Kumar Saini — Sun, 06 Sep 2026 13:46:16 +0000

Yash K Saini — Engineer, building in public — AI/ML, low-level (Rust/C/C++), and open source.

GitHub · X · LinkedIn · Portfolio

A massive week of cleanup and deep technical dives. From deleting 180k lines in my vault to fixing socket leaks in libp2p and contributing to the Rust compiler, I hit 102 commits and a perfect 7-day streak.

TL;DR

There is something incredibly therapeutic about a net-negative week. I pushed 102 commits across a dozen repos, but the headline stat isn't the additions—it’s the 188,000 lines of code I deleted. Between chasing down residual socket leaks in py-libp2p, building out a resumable progress log for Reachable, and even opening a PR on the Rust compiler, it’s been a high-velocity seven days.

The Great Purge and Portfolio Polish

I started the week with a "scorched earth" approach to my obsidian-vault. I realized I was tracking way too much of Obsidian's internal UI state and plugin noise, which made the git history a mess. I ripped out about 179,000 lines by stopping the tracking of that ephemeral state. Now, my syncs are clean, and the vault actually represents my thoughts rather than my editor's window positions. It’s a good reminder that just because you can version control something doesn't mean you should.

On the portfolio front, I spent a good chunk of time in app/projects and components/common. I finally stripped out some old "catalogue-numbering" chrome that was cluttering the UI and gave each project row its own distinct card surface. I also fixed a nagging SEO issue by moving the canonical origin to yashksaini.vercel.app. The big feature update here was the new "spotlight" section, where I’m now featuring GitBanner and Reachable right at the top. If you’re going to build things, you might as well show them off properly.

Deep in the Networking Guts

A lot of my mental energy this week went into py-libp2p. Networking bugs are the ultimate test of patience. I opened two pretty critical issues regarding socket leaks. In Issue #1485, I found that the Swarm was leaking dialed connection sockets on shutdown because the service-manager stop path wasn't cleaning up properly. I followed that up with Issue #1487, which identified residual leaks in the muxer connection test fixtures.

I didn't just report them, though. I’ve been working on PR #1486 to ensure connections are explicitly closed on shutdown so their sockets are released back to the OS. I also pushed forward on WebRTC-Direct interop tests. Getting Python and Go to agree on WebRTC-Direct is... a journey. We had a case where the ICE handshake succeeded, but then the connection was immediately torn down. It’s these kinds of edge cases that make p2p work both frustrating and deeply rewarding.

Building and Fixing at Scale

I also spent some time on breakscale, which is a project that really challenges how I think about failure states. I found a bug (Issue #51) where a node losing 25% of its requests to timeouts was still reporting a 0% failure rate. That’s a dangerous blind spot. I merged PR #57 to ensure timeouts are counted correctly so the failure rate actually reflects reality. I also fixed a nasty data loss bug in PR #54—previously, if the validator rejected a saved design, the next save or delete would just erase it from storage. Now, we keep the design even if the current build can't "open" it.

Over at Reachable, the focus was on the demo experience. I built out a resumable progress log, a sound score mixer, and a frame renderer. This project is becoming a really cool playground for TypeScript-based media tools. I’m particularly happy with the "paste-ready" voiceover script block—it’s one of those small DX (developer experience) features that makes the tool feel much more polished.

The Tooling Life: Neovim and DevNotion

You can’t be a dev without constantly tweaking your tools. I did some work on my nvim config, specifically rebuilding the keymap reference around a prefix tree. I also fixed a frustrating bug where <leader>bd would leave a blank window open. Now it closes the window properly, and I can open a terminal from any window type, not just "normal" ones. It’s the little things that keep the flow state alive.

For DevNotion, I focused on the documentation and the "blog log." I reworked the masthead and made the ledger header sticky while scrolling. I also made a conscious decision to drop the sequential numbering from posts. Now they’re just titled "Dev log: ." It feels less like a chore and more like a journal. I also had to escape some pipes in the headlines to prevent the markdown tables in the logs from breaking—classic string manipulation fun.

Pull Requests of Note

Beyond the ones I've mentioned, a few others stood out:

Rust Compiler: I opened PR #162123 to report unsatisfied opaque item bounds instead of a generic type mismatch under the -Znext-solver. Contributing to the Rust compiler is always a "hold your breath" moment, but it's the best way to learn how the magic happens.
Agent Orchestrator: Merged a fix in PR #4717 to carry the resolved model through metadata merging. This fixed a bug where ao spawn would record an empty model.
Sixb: Merged PR #478 which adds the project model catalog to both the core and server.

Tech Stack & Vibe

This was a true polyglot week. TypeScript dominated the frontend and CLI work, Python was the heavy hitter for the libp2p networking logic, and I dipped into Rust for the compiler work. I even wrote a bit of C++ for some basic alphabet-printing programs in my Learning-2026 repo—sometimes you just need to get back to the basics to clear your head.

The 7-day streak feels good. It wasn't a forced grind; it was just one of those weeks where every time I sat down, there was a clear problem to solve. Whether it was a socket leak in Python or a CSS alignment issue in my portfolio, the momentum stayed high.

What's Next

Next week is going to be about closing the loop on those py-libp2p leaks. I want to get the connection-closing logic merged and see if I can figure out why the Go and Python WebRTC-Direct implementations are talking past each other. I’ll also be spending more time on the Reachable frame renderer—there’s some performance optimization I want to try out.

Catch you in the next push.

Dev log #19 WebRTC v2 flows, agentic orchestration, and a perfectly synced vault

Yash Kumar Saini — Mon, 31 Aug 2026 06:52:21 +0000

This week was a high-output sprint across the stack—from low-level p2p networking in Python to refining agentic workflows in TypeScript. I pushed 53 commits and opened 13 PRs, maintaining a perfect 7-day streak while balancing deep protocol work with personal knowledge management.

TL;DR

I didn't really intend for this to be a "build everything" week, but that’s exactly where the momentum took me. Between hardening WebRTC implementations in py-libp2p and chasing down edge cases in agent orchestration, I managed to ship 53 commits and keep my daily streak alive for the full seven days. The stats show a heavy tilt toward new code—over 12,000 additions—as I laid the groundwork for better telemetry and more robust p2p networking.

What I Built

Deep in the Networking weeds: py-libp2p

Most of my "deep work" hours went into py-libp2p. Networking code is unforgiving, but incredibly satisfying when it clicks. I spent a significant chunk of time in libp2p/kad_dht implementing configurable subnet-diversity limits and table-wide IP-group caps. If you've ever dealt with Sybil attacks or just messy peer distributions, you know why this matters—it’s about making the DHT resilient, not just functional.

On the transport side, I was neck-deep in libp2p/transport fixing WebRTC issues. I had to guard private-slot writes and ensure we’re using close_peer_connection at every production site to avoid hanging resources. I also spent time on a tricky Windows-specific bug where we needed to listen on a concrete non-loopback interface for tests to actually pass.

Hardening Reachable & Breakscale

I’ve been refining Reachable, specifically making the "Ask" feature behave more like a natural conversation. I had to harden the store behind it to ensure state doesn't drift when the UI gets complex.

Over at breakscale, I hit a weird one: Vitest failing on Node 26 because of jsdom's localStorage implementation. I opened an issue, tracked it down, and pushed a fix to put localStorage back where it belongs. I also shipped a feature to improve design descriptions—focusing on what a design is made of rather than just its dimensions. It’s a small UX shift, but it makes the tool feel much more intuitive.

The Digital Brain: obsidian-vault

I treat my obsidian-vault like a production repo, and this week it saw 35 commits. I was mostly syncing UI states and fixing templates. I noticed a bug in my "Concept" template where the parent pointer was recursively pointing at the template itself (classic meta-mess). I also logged three separate stream sessions, which has been a great way to document my thought process while I code.

Pull Requests & Orchestration

I opened 13 PRs this week, and while some are still in flight, they represent a lot of the "glue" work I do across the ecosystem.

A lot of my focus was on agent-orchestrator. I’m working on carrying request IDs into daemon-emitted events to make telemetry actually useful. There’s nothing worse than seeing an error in a log and having no way to trace it back to the original trigger. I also fixed a dev-server proxy issue where it was pointing at the wrong daemon—one of those "how did this ever work?" bugs that felt great to squash.

In the corsair repo, I’ve been on a mission to improve reliability and performance. I opened PRs to:

Cover verifyHmacSignature with proper unit tests (security code without tests is just a disaster waiting to happen).
Add database indexes on corsair_entities and corsair_accounts query paths. As the data grows, those sequential scans were starting to hurt.
Clean up CLI error handling so async command failures don't just dump unhandled promise rejections into the terminal.

Issues & Community

I opened 7 issues this week, mostly as a way to "work in the open." When I find a bug in agent-orchestrator (like the Connect Mobile tailnet proxy stranding processes on ungraceful exits) or a performance bottleneck in corsair, I document it before I fix it. It helps me stay organized and gives the maintainers a heads-up on what I’m poking at.

One specific bug I’m still tracking is in omarchy, where selecting the default agent somehow triggers a version downgrade because of a mise release cooldown. It’s a weird interaction between the version manager and the agent logic that I’m hoping to resolve next week.

Tech Stack & Vibe

This was a polyglot week, but Python and TypeScript were the clear winners.

Python: 84MB of code touched (mostly libp2p internals).
TypeScript: 58MB of code across frontend tools and CLI utilities.
The Mix: A bit of Lua for my nvim config updates and some Shell/Makefile glue to keep the CI pipelines happy.

With 12,205 additions against 1,500 deletions, this was definitely a "growth" week. I wasn't just cleaning up; I was shipping new features and expanding test suites. The 7-day streak wasn't forced—when you're bouncing between p2p protocols and AI agents, there's always one more thing you want to tweak before calling it a day.

What's Next

Next week, I’m planning to close out those WebRTC v2 PRs in py-libp2p. The specs are solid, but the implementation details around data-channel framing as a byte stream are still a bit finicky. I also want to get those corsair database indexes merged and see the real-world performance delta.

And of course, more streaming. I’ve found that logging my sessions in Obsidian has made me much more intentional about the code I write. If I have to explain it to a "future me" in a log, I'm less likely to take the lazy shortcut.

Catch you in the next push. Keep hacking.

Yash K Saini — Engineer, building in public — AI/ML, low-level (Rust/C/C++), and open source.

GitHub · X · LinkedIn · Portfolio

Generated by DevNotion

Dev log #18 From Redis Brokers to Knowledge Graphs: A 177-Commit Sprint

Yash Kumar Saini — Sun, 23 Aug 2026 16:26:50 +0000

Hit a perfect 7-day streak this week, shipping 177 commits across systems architecture and personal tooling. Between hardening Redis brokers and fixing terminal hijacking in tmux, I managed to push nearly 7k lines of code across eight different projects.

TL;DR

There’s a specific kind of satisfaction that comes from a perfect 7-day streak where the flow state just doesn't quit. This week was a massive 177-commit sprint, largely split between hardening the infrastructure for Reachable and refining the data pipelines in my opportunity-radar. I spent a lot of time in the "maintenance and hardening" phase—fixing memory leaks, bounding caches, and making sure my CLI tools don't hijack my terminal. With nearly 7,000 lines added and 2,700 removed, the codebase feels significantly more robust than it did last Monday.

What I Built

Reachable: Security and Performance

I spent the lion's share of my time (84 commits!) on Reachable. Most of the work was centered around the worker/reachable and web/components areas. One of the more critical changes was in the ingest layer: I bounded the packument cache by size. If you've ever dealt with massive metadata ingestion, you know how quickly an unbounded cache can eat your RAM, so getting that logic in place was a huge win for stability.

On the security side, I reworked how we handle keys. I updated the system to show minted keys as masked values instead of printing them whole (basic security hygiene, but easy to overlook early on) and added the ability for testers to revoke keys immediately. Waiting out a TTL just to test a revocation flow is a special kind of developer hell, so I’m glad that’s behind me. I also did some housekeeping by stripping out internal working notes from the docs and pointing everything to the proper references.

Opportunity-Radar: Scraping and UI

My Python-based opportunity-radar saw 40 commits this week. Scraping is always a game of whack-a-mole with edge cases. I spent a good chunk of Tuesday fixing a bug where neighboring listings were getting "glued" onto titles—one of those classic regex-adjacent headaches.

To make the data actually usable, I implemented paging for the opportunities table and derived category filters directly from the data instead of hardcoding them. I also hooked up the dashboard to supply run tokens directly, which makes the manual trigger flow much smoother. It’s starting to feel like a real product rather than just a collection of scripts.

The Personal Stack: Obsidian and Portfolio

I’m a big believer in "sharpening the saw," so I put 27 commits into my obsidian-vault. I’ve been working on syncing the graph zoom and UI state across devices. There’s something deeply nerdy but satisfying about getting your #stream and #reference tags to color-coordinate perfectly across your knowledge base.

I also gave my portfolio some love. I’m a bit of a stickler for UX, so I spent time enlarging the ⌘K hint chips in the header so they actually look like controls. I also fixed a gnarly bug in the hero section where scrub audio would stay locked after a page reload. If you’re going to have audio on a dev portfolio, it has to work perfectly, or it’s just noise.

Pull Requests

I opened 6 PRs this week, and the results were a mix of "shipped it" and "back to the drawing board."

Over at sixb, I had two successful merges. One was a critical fix for the broker: I bounded a Redis command so a single stuck reply couldn't hang the entire publication pipeline. The other involved releasing event subscriptions for action runs that settled late—essentially plugging a memory leak I’d been hunting for a while. I did close one massive PR (+2,030 lines) regarding connector stores and sealed credentials without merging it. It was a big architectural pivot, and after looking at the diff, I realized I wanted to approach the credential sealing differently. Sometimes the best thing you can do for a codebase is realize a 2,000-line change isn't the right one.

In the agent-orchestrator repo, I’ve got two PRs currently open. They both deal with tmux integration. One fixes a bug where destroying a session would accidentally hand the orchestrator's terminal over to another session, and the other handles resuming agents when using a non-default tmux base-index. If you’ve ever had your terminal focus stolen by a background process, you know why these are high priority for me.

Issues & Discussions

I was pretty active on the issue tracker this week, opening 5 issues across various projects.

The most interesting one was in hydradb, where I noticed an inconsistency in how HTTP and Bolt map CLASS_FRESHNESS errors. One treats them as retryable, the other doesn't. That’s the kind of subtle bug that causes "it works on my machine" tickets, so I’m hoping to dive into the fix for that soon.

I also tracked down a CPU spike in nezuko where the runtime was spinning at 100% while idle and leaking file descriptors. There’s no faster way to lose my trust in a tool than having it cook my CPU while it’s doing literally nothing, so getting that issue documented (and subsequently closed) was a relief.

Tech Stack

This was a true polyglot week. TypeScript was my primary driver for the web and worker logic in Reachable and sixb, while Python handled the heavy lifting for the data scraping in opportunity-radar. I also dipped into Go to add a AO_DISABLE_GPU escape hatch for the agent-orchestrator—sometimes you just need a way to bypass broken drivers when you're working on desktop tools.

The stats tell the story: 177 commits over 7 days. My add/delete ratio was about 2.5:1. While I love a good refactoring week where I delete more than I add, this week was clearly about expansion. Building out the paging systems, the credential stores (even the ones I pivoted on), and the dashboard features meant a lot of new logic hitting the disk.

What's Next

Next week, I’m focusing on the tmux fixes in agent-orchestrator. I want to get those PRs merged so the terminal handling is rock solid. I’m also planning to revisit the credential sealing logic I backed out of in sixb—I have a better idea now of how to handle the "sealed" part without making the storage layer too brittle.

Consistency is key, and hitting a 7-day streak feels like I've got the momentum I need heading into September. See you on the next push!

Yash K Saini — Engineer, building in public — AI/ML, low-level (Rust/C/C++), and open source.

GitHub · X · LinkedIn · Portfolio

Generated by DevNotion

One rented /24 could eclipse a Kademlia node. Now it takes ten.

Yash Kumar Saini — Thu, 20 Aug 2026 18:56:59 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The setting

py-libp2p speaks Kademlia — a distributed hash table where every node keeps a routing table of other nodes, bucketed by how far their IDs sit from its own. You find a peer or a record by asking the nodes closest to the target, who point you closer, and closer, until you arrive. It's elegant, and it works because of one quiet assumption: the peers in your routing table are a fair sample of the network.

An eclipse attack breaks exactly that assumption. If an attacker can get their nodes into enough of your routing buckets — specifically the closest-K slots for a target key — they don't need to break any crypto. They just surround you. Every lookup you make gets answered by them. They can hide records, feed you stale routing, or silently partition you from the real DHT. You're still online. You're still "connected." You're just connected to a lie.

Signing authenticates the record, not the routing table

The reason this one nags at me is that the DHT already has an integrity story: records are signed. So my instinct — and I don't think I'm alone — was that the surface was mostly covered. If a malicious peer can't forge a record, how much damage can it do?

A lot, it turns out, because signing and eclipse answer different questions.

Record signing authenticates content. Hand me a DHT record and I can verify the owning key produced it. I can't be fed forged values.
Eclipse attacks membership. The attacker never forges anything. They make sure the only peers you ever ask are theirs, then answer with perfectly valid, perfectly signed records — just never the whole set. Withholding has no signature. Silence has no signature.

So the real surface isn't the record. It's how a peer earns a slot in a k-bucket.

Building the attack to measure it

I didn't want to argue this from a whiteboard, so I built an eclipse-attack simulation inside py-libp2p — it lives at tests/examples/attack_simulation/eclipse_attack/. It spins up a network of honest KadDHT nodes, introduces malicious peers that flood the honest nodes' routing tables and poison DHT entries, and then measures what actually degrades: a RealAttackMetrics collector runs real lookups against the network and records the success rate as the attack takes hold.

# tests/examples/attack_simulation/eclipse_attack/attack_scenarios.py
async def execute(self):
    async with trio.open_nursery() as nursery:
        for mp in self.malicious_peers:
            for target in self.honest_peers:
                nursery.start_soon(mp.poison_dht_entries, target)
                nursery.start_soon(mp.flood_peer_table,
                                   self.honest_peer_tables[target])

The point of the harness is to turn "eclipse is possible" into a number: what fraction of lookups can an attacker capture, and how does that change once the routing table stops admitting them so cheaply?

The point of the harness is to turn "eclipse is possible" into a number. I drove the fork's real KBucket.add_peer (k = 20) with Sybil peers from attacker-controlled /24s, running it with MAX_PEERS_PER_SUBNET set to 0 (the pre-#1399 behaviour) versus its default of 2. This is a component-level measurement — it isolates exactly what the admission rule changes:

Attacker capability	Pre-#1399 (no filter)	With #1399 (max 2 / subnet)
Bucket slots captured — flood from a single `/24`	20 / 20 (100%)	2 / 20 (10%)
Distinct `/24`s needed to fully own a 20-slot bucket	1	10
Share of slots taken when the bucket already holds 10 honest, subnet-diverse peers	50%	17%

Before the fix, one rented /24 owns the whole bucket. After it, an attacker needs ten genuinely distinct networks to do the same — the cost moved from "grind cheap IDs" to "rent diverse address space," which is the entire point.

The root cause

In vanilla Kademlia, a peer earns a bucket slot mostly by being live and having an ID that lands in range. Node IDs are cheap — you can grind as many as you want. So an attacker spins up a Sybil fleet and, crucially, parks them at IP addresses in a subnet they control. Their cheap resource is node IDs; the resource they'd actually have to spend is distinct network positions — and nothing in the base admission rule was pricing that.

A rented cloud block is typically a /24, not a scattering of unrelated addresses. That's the lever: if admission is priced in distinct subnets rather than distinct IDs, surrounding a node suddenly costs real, diverse address space the attacker can't cheaply conjure.

The fix — #1399: enforce IP subnet diversity in k-buckets

libp2p/py-libp2p#1399 (closes #1383) makes KBucket.add_peer reject a new peer when its globally-routable /24 (IPv4) or /48 (IPv6) subnet already holds MAX_PEERS_PER_SUBNET (default 2) peers in that bucket:

# IP/subnet diversity limits for k-buckets (issue #1383). Within one bucket,
# at most MAX_PEERS_PER_SUBNET peers may share the same globally-routable subnet.
# /24 matches realistic attacker economics — a rented cloud block is typically
# a /24, not a /16 — and avoids bundling an ASN dataset.
MAX_PEERS_PER_SUBNET = 2

def _subnet_key(peer_info: PeerInfo) -> str | None:
    for addr in peer_info.addrs:
        if "p2p-circuit" in str(addr):      # relayed addr = relay's IP, not the peer's
            continue
        for proto, prefix_len in (("ip4", SUBNET_PREFIX_LEN_V4),
                                  ("ip6", SUBNET_PREFIX_LEN_V6)):
            ...
            if not ip.is_global:            # loopback/private/CGNAT/link-local → exempt
                continue
            return str(ip_network(f"{ip}/{prefix_len}", strict=False))

The details are where the real engineering is:

Only globally-routable addresses are grouped (ip.is_global) — loopback, RFC1918/ULA private, CGNAT (100.64.0.0/10), link-local, and documentation ranges are exempt, so CI and local testnets are unaffected.
DNS-named and relayed (p2p-circuit) peers are exempt — a circuit address exposes the relay's IP, not the peer's, so grouping on it would wrongly bundle distinct peers behind a shared relay.
Multi-homed peers are grouped by their first globally-routable address (a deliberate divergence from go-libp2p, which checks every address — simpler, and it avoids false rejections of legitimately multi-homed peers).
Reject-only, no eviction — matching go-libp2p's TryAddPeer, which avoids opening a churn/DoS vector where an attacker forces evictions.
Opt-out via MAX_PEERS_PER_SUBNET <= 0, and a guard so a subnet rejection on a non-full bucket can't trigger a spurious bucket split.

No protocol or wire change — just a stricter admission rule at exactly the layer the eclipse attacks.

What I learned

The trap wasn't a bug in the code — it was a bug in the question. "Records are signed, so the DHT is safe" quietly swaps the question you need answered ("is this set of peers a fair sample?") for one you've already answered ("is this record authentic?"). Authentication and membership-diversity are orthogonal: signing is a real defense against forgery and no defense at all against being surrounded by valid liars.

The broader habit I'm keeping: when someone says "that's already handled," ask which property is handled. The most dangerous vulnerabilities live in the gap between two defenses that each look complete on their own.

The /sdp endpoint that trusted its callers: fixing a memory-amplification DoS in py-libp2p

Yash Kumar Saini — Thu, 20 Aug 2026 18:56:05 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

py-libp2p is the Python implementation of libp2p — the peer-to-peer networking stack that underpins IPFS, Filecoin, and Ethereum-class nodes. I've been working on its WebRTC-Direct transport, which lets two peers connect without a certificate authority: the peer's multiaddr carries a hash of its TLS cert, and the DTLS handshake is verified against it.

Before that encrypted transport exists, the two sides have to swap SDP offer/answer blobs. Until the STUN-based listener lands (#1352), py-libp2p ships a minimal dev harness for this: a tiny hand-rolled HTTP server (no aiohttp dependency) that accepts an SDP offer over POST /sdp and hands the body to an offer handler. This post is about a memory-amplification DoS I found and fixed in that harness.

Bug Fix or Performance Improvement

The POST /sdp handler read the caller's Content-Length and buffered exactly that many bytes — with no upper bound — before the handshake ever happened. Here's the pre-fix read path in _aiortc_helpers.py:

# Read HTTP request line (consumed but not used) + headers
await asyncio.wait_for(reader.readline(), timeout=_SDP_HTTP_TIMEOUT)
headers: dict[str, str] = {}
while True:
    line = await asyncio.wait_for(reader.readline(), timeout=_SDP_HTTP_TIMEOUT)
    if line in (b"\r\n", b"\n", b""):
        break
    key, _, value = line.decode().partition(":")
    headers[key.strip().lower()] = value.strip()

content_length = int(headers.get("content-length", "0"))
body = b""
if content_length > 0:
    body = await asyncio.wait_for(
        reader.readexactly(content_length),
        timeout=_SDP_HTTP_TIMEOUT,
    )

Two things are attacker-controlled and unbounded:

The body. content_length comes straight from the request. reader.readexactly(content_length) accumulates that many bytes into memory — and readexactly bypasses the StreamReader's default 64 KiB flow-control limit, so nothing throttles it. body.decode() makes a second copy, the handler string a third. Net amplification ≈ 2× the bytes on the wire, with no ceiling.
The headers. while True with only a per-line timeout: an attacker can keep sending header lines forever — the loop never counts them.

This is pre-handshake, unauthenticated input. Anyone who can reach the port can trigger it.

Where I found it: a reviewer flagged the shape of this inside my own WebRTC PR (#1309) — a one-line "reads the whole body into memory with no cap, availability risk" note. Easy to read as a style nit; it wasn't. Pre-handshake input is attacker-controlled by definition, and "reads the whole body with no cap" is the entire exploit.

The numbers. I built a reproduction harness that imports the real run_signaling_server at the pre-fix parent (9506041) and the merged fix (759c75b), fires the malicious request, and samples RSS on a 20 ms timer:

Metric	Before (pre-fix)	After (#1396)
Peak RSS, 512 MiB malicious body	1,113 MB (+1,052)	61 MB (+0)
Peak RSS, 1 GiB malicious body	2,137 MB (+2,076)	rejected, idle
Peak RSS, 4 concurrent × 300 MiB	1,575 MB (+1,514)	88 MB (+27)
Time to refuse oversized request	never (buffers to OOM)	0.3 ms (`413` on headers alone)
Body size accepted	unbounded	32 KiB (`413` above)

(Measured in a Python 3.11 / aiortc 1.15 sandbox on a single asyncio loop — re-run the harness on your own hardware for local figures; the ~2× ratio holds.)

Code

PR: libp2p/py-libp2p#1396 — fix(webrtc): harden /sdp HTTP server against memory-amplification DoS · merged Aug 14, 2026 · closes #1354 · commit 759c75b.

The fix adds three bounded constants and rejects before touching any body buffer:

# Bounds for the HTTP /sdp dev harness — defend against memory-amplification
# DoS while the harness exists (until the STUN-based listener lands, #1352).
_MAX_SDP_BODY_SIZE = 32 * 1024  # 32 KiB; SDP offers are typically 1–4 KiB
_MAX_HEADER_LINES = 64
_MAX_HEADER_BYTES = 8 * 1024    # 8 KiB total across all header lines

Headers are bounded by line count and cumulative bytes (the for/else fires a 400 if the terminator never arrives):

headers: dict[str, str] = {}
header_bytes = 0
for _ in range(_MAX_HEADER_LINES + 1):
    line = await asyncio.wait_for(reader.readline(), timeout=_SDP_HTTP_TIMEOUT)
    if line in (b"\r\n", b"\n", b""):
        break
    header_bytes += len(line)
    if header_bytes > _MAX_HEADER_BYTES:
        writer.write(b"HTTP/1.1 400 Bad Request\r\nContent-Length: 0\r\n\r\n")
        await writer.drain(); return
    key, _, value = line.decode().partition(":")
    headers[key.strip().lower()] = value.strip()
else:
    writer.write(b"HTTP/1.1 400 Bad Request\r\nContent-Length: 0\r\n\r\n")
    await writer.drain(); return

And Content-Length is validated before any body buffer exists — malformed/negative → 400, oversized → 413:

raw_cl = headers.get("content-length", "0")
try:
    content_length = int(raw_cl)
except ValueError:
    writer.write(b"HTTP/1.1 400 Bad Request\r\nContent-Length: 0\r\n\r\n")
    await writer.drain(); return
if content_length < 0:
    writer.write(b"HTTP/1.1 400 Bad Request\r\nContent-Length: 0\r\n\r\n")
    await writer.drain(); return
if content_length > _MAX_SDP_BODY_SIZE:
    writer.write(b"HTTP/1.1 413 Payload Too Large\r\nContent-Length: 0\r\n\r\n")
    await writer.drain(); return

The PR also ships a 228-line regression test (test_aiortc_helpers.py) whose key assertion checks that RSS didn't grow after a 413 — not just the status code:

async def _too_large(self) -> None:
    rss_before = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
    server, port = await _start()
    line = await _status(port, b"POST /sdp HTTP/1.1\r\nContent-Length: 999999999\r\n\r\n")
    assert b"413" in line
    rss_after = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
    assert (rss_after - rss_before) < one_mib   # body buffer was never allocated

My Improvements

I deliberately chose a hard cap over a streaming-with-ceiling read. SDP offers are 1–4 KiB in practice; no legitimate caller needs to POST megabytes here, so a fixed 32 KiB ceiling with early rejection is simpler and safer than draining a bounded stream. Rejecting on the Content-Length header alone means the oversized request never allocates a buffer at all — which is why the "after" column of the table plateaus at the idle baseline and the refusal lands in 0.3 ms.

Impact in context: py-libp2p underpins Python IPFS/Filecoin-class nodes. A signaling endpoint that OOM-kills the whole process on unauthenticated, pre-handshake input is a cheap remote crash — no credentials, no handshake, one connection. Bounding it to 32 KiB turns "attacker picks my memory ceiling" into "attacker gets a 413."

What I learned: the reviewer's one-line "availability risk" aside was a working exploit, and I almost filed it under style. Pre-handshake input is attacker-controlled by definition — "trust the Content-Length" is never a safe default. And the test matters as much as the fix: asserting 413 proves the status code; asserting RSS-didn't-grow proves the property — that no buffer was allocated.

Reproduce it:

git clone https://github.com/libp2p/py-libp2p && cd py-libp2p
pip install aiortc
git checkout 9506041   # PRE-FIX: RSS climbs to ~1.1 GB, 200 OK
python3 exploit.py PREFIX body 512
git checkout 759c75b   # POST-FIX (#1396): 413 in 0.3 ms, RSS flat
python3 exploit.py POSTFIX bodyreject 512

Best Use of Sentry

There's no first-class trio integration for Sentry (its Python integrations are asyncio / Django / Flask / FastAPI / AIOHTTP / etc.), so I attached manually — and it fit cleanly because the pieces genuinely apply:

The /sdp server is plain asyncio, so wrapping the handler in sentry_sdk.start_transaction(op="sdp.post", name="/sdp handler") gave me a real trace waterfall — the span sitting on reader.readexactly() is visibly the culprit.
AsyncioIntegration actually applies — the WebRTC bridge from #1309 runs a real asyncio event loop in a daemon thread, so the integration isn't decorative.
SocketIntegration adds DNS/connect spans for free, on-topic for a P2P lib.
I emitted RSS as a custom measurement so the before/after shows up inside Sentry:

import resource, sentry_sdk
from sentry_sdk.integrations.asyncio import AsyncioIntegration
from sentry_sdk.integrations.socket import SocketIntegration

sentry_sdk.init(dsn="<YOUR_DSN>", traces_sample_rate=1.0, profiles_sample_rate=1.0,
                integrations=[AsyncioIntegration(), SocketIntegration()])

def rss_mb():
    return resource.getrusage(resource.RUSAGE_SELF).ru_maxrss / 1024  # Linux: KB→MB

with sentry_sdk.start_transaction(op="sdp.post", name="/sdp handler") as tx:
    tx.set_measurement("rss_before_mb", rss_mb(), "megabyte")
    # ... handle request ...
    tx.set_measurement("rss_after_mb", rss_mb(), "megabyte")

Here's the captured trace — the sdp.read_body span running reader.readexactly(157286400) is the whole story, and the rss_before_mb / rss_after_mb measurements ride along on the transaction:

Seer's root-cause analysis — this was the standout. I ran Seer on the captured event and, with no knowledge of the fix I'd already shipped, it pinned the exact cause and proposed essentially the same patch:

Quoting it: Seer flagged a "+196 MB in one request" spike, found that handle() "reads Content-Length directly from the attacker-controlled HTTP header and passes it verbatim to reader.readexactly(content_length) … with no upper-bound check," and separately caught the header loop as an "unbounded while-loop." Its recommended fix — a MAX_SDP_BODY_SIZE cap that returns 413 Payload Too Large before the read, plus per-line/total header caps — is the same shape as #1396. The only real difference: Seer suggested a 64 KiB cap; I shipped 32 KiB. Honest verdict: right, and specific enough to act on — the uncommon case where the AI root-cause analysis lands the actual fix rather than a vague "add validation."

On Session Replay: not applicable — there's no browser in this path, so I didn't fake a screenshot. The honest "N/A" is more useful to a maintainer than a contrived one.

Best Use of Google AI

I pasted the pre-fix read path into Google AI Studio (Gemini) and asked for three concrete hypotheses for the unbounded memory growth, ranked by likelihood, with a one-line fix for each.

Its #1, ranked "Most Likely," was exactly right: "the server trusts the client-provided content-length header and attempts to buffer the full amount into RAM … an attacker can send a large value (e.g. 10^9) and slowly stream data, forcing the server to grow its internal buffer to match." It even independently named the ~2× amplification I'd measured — "Python's object-copying behaviour is acting as a memory multiplier." The guard it proposed (if content_length > 1_048_576: raise …) is the same shape as the fix I shipped in #1396 — the only difference is the cap size (Gemini picked 1 MiB; I used 32 KiB, since real SDP offers are 1–4 KiB). Honest read: for a tightly-scoped prompt, Gemini's top-ranked hypothesis landed the real bug on the first try.

The test was green. Every real connection would have failed.

Yash Kumar Saini — Thu, 20 Aug 2026 18:54:53 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The setting

WebRTC-Direct in libp2p has a neat trick for connecting without a certificate authority: the peer's multiaddr contains a hash of its TLS certificate — /webrtc-direct/certhash/<...>. When you dial, the DTLS handshake presents a cert, you hash it, and you check it against the certhash in the address. No CA, no trust store — the address is the pin.

For that to work, py-libp2p has to make aiortc use our libp2p-generated certificate, not the one aiortc auto-generates for itself. So the code pins it:

config = RTCConfiguration(certificates=[rtc_cert])
return RTCPeerConnection(configuration=config)

Clean. Obvious. And, as of aiortc ≥ 1.5, completely wrong — in two different ways.

The first sign

The first way was loud: aiortc ≥ 1.5 dropped certificates= from RTCConfiguration. Passing it raises TypeError. Easy to spot, easy to "fix" — just move the cert onto the object after construction:

pc = RTCPeerConnection(configuration=config)
pc._certificates = [rtc_cert]   # looks right. isn't.
return pc

The tests went green. The loopback echo test — open a data channel, send a payload, get it back — passed. I could have shipped it right there.

The quiet way is the one that would have burned every user.

The investigation

Here's the thing that made this a story and not a one-liner. pc._certificates = [...] is a silent no-op. aiortc never reads _certificates. Inside the class, it stores and reads the cert as self.__certificates — a double-underscore attribute. And Python does something specific with double-underscore names inside a class body: it mangles them. self.__certificates inside class RTCPeerConnection is compiled to self._RTCPeerConnection__certificates.

So from the outside:

pc._certificates — a brand-new attribute I invented. aiortc reads it never.
pc._RTCPeerConnection__certificates — the actual slot aiortc reads at createOffer/createAnswer time to write the SDP a=fingerprint line (see aiortc/rtcpeerconnection.py:295 and :1129).

I was setting the first one. aiortc was reading the second one — still holding its own auto-generated cert. The result:

The /webrtc-direct/certhash/<...> multiaddr advertised our libp2p cert hash.
The DTLS handshake used aiortc's auto-generated cert.
Every real dial would fail peer verification with Remote DTLS fingerprint does not match certhash.

And the loopback echo test still passed — because loopback doesn't validate the DTLS fingerprint against a multiaddr. It just opens a channel and echoes bytes. The one property that was broken was the one property the happy-path test never checked.

The root cause

This is a bug that lives in the seam between two systems:

Python's language rule: name mangling rewrites __name references inside a class body so subclasses can't accidentally clobber a base class's "private" attributes. It's a language feature doing exactly what it's designed to do.
aiortc's library internals: it stores the cert under __certificates, i.e. it relies on that mangling for its own encapsulation.

Neither is wrong on its own. But when you reach into a library's private state from outside the class, the mangled name is the only name that works — and the un-mangled one you'd naturally type is a no-op that fails silently. There's no AttributeError, no TypeError, no warning. You just create a junk attribute and move on, and everything downstream keeps working except the security property.

The fix

Set the mangled attribute directly, after construction, before any SDP operation triggers the handshake:

config = RTCConfiguration(iceServers=list(ice_servers) if ice_servers else [])
pc = RTCPeerConnection(configuration=config)
# Replace aiortc's auto-generated cert. Must use the mangled name —
# aiortc reads only `self.__certificates`, which mangles to this.
pc._RTCPeerConnection__certificates = [rtc_cert]  # type: ignore[attr-defined]
return pc

It's an ugly line, and the docstring says so out loud — reaching into _RTCPeerConnection__certificates is exactly the kind of private-state coupling that breaks on a library upgrade. But it's correct, and it's annotated so the next person knows why it can't just be pc._certificates.

The canary that would have caught it

The real fix wasn't the one-liner — it was the test that makes the silent failure loud. The happy-path echo test can't see this bug, so I added one that asserts the invariant: the pinned cert's fingerprint must actually appear in the SDP.

@pytest.mark.trio
async def test_cert_pinning_lands_in_sdp_fingerprint() -> None:
    """
    Guards against a class of cert-pin bug: if the pin is a no-op (e.g.
    written to a public attribute aiortc never reads because it actually
    stores the cert under a name-mangled private slot), the SDP a=fingerprint
    line reflects aiortc's auto-generated cert instead of ours.
    """
    cert = WebRTCCertificate.from_aiortc()
    pc = await bridge.run_coro(create_peer_connection(cert._rtc_certificate, ice_servers=[]))

    # Need at least one data channel for the SCTP m-line, otherwise
    # createOffer omits the DTLS fingerprint entirely.
    await bridge.run_coro(_create_dummy_channel(pc))

    sdp = await bridge.run_coro(_offer())
    expected = _sdp_fingerprint_string(cert)
    assert expected in sdp.upper(), "SDP fingerprint does not match pinned cert."

Note the small landmine inside the fix for the test: createOffer omits the DTLS fingerprint entirely unless there's at least one SCTP m-line, so the canary has to create a dummy data channel first or it asserts against an empty offer. The bug had layers even in the reproduction.

Revert the mangled-name fix and this test goes red immediately with a fingerprint mismatch. Keep the old pc._certificates = [...] no-op and it's red. That's the whole point: it fails closed.

What I learned

Two lessons, and they're the same lesson from two directions.

Test the invariant, not the happy path. The echo test proved bytes moved. It said nothing about which certificate moved them — and that was the only thing that mattered for security. A green test is only as good as the property it asserts, and "it worked end to end" quietly excludes every property your end-to-end path doesn't check.

A silent no-op is worse than a crash. If pc._certificates = [...] had raised, I'd have fixed it in thirty seconds. Because it succeeded — created a real attribute, threw no error — it sailed through review and tests and would have shipped a transport where every authenticated dial fails. When you reach across an encapsulation boundary into a library's private state, assume the language is doing something clever with the name, and write the test that proves your write actually landed where the library reads.