DEV Community: Yash Kumar Saini

What I learned building wfreq

Yash Kumar Saini — Wed, 28 Oct 2026 15:10:42 +0000

TL;DR

How a word-frequency tool taught me to wrap errors instead of replacing them: from .expect() to thiserror, #[source] and per-file warnings.

I built wfreq, a small Rust CLI that prints the most common words in .txt, .md, .pdf and .docx files. The counting took an afternoon. The error messages took the rest of the project.

This post is about the hardest part: making the tool tell the truth when something goes wrong.

Version 1: `.expect()` and a crash

The first main read the file like this:

let content = std::fs::read_to_string(&args.file).expect("File can not read");

I pointed it at a PDF and got:

thread 'main' panicked at src/main.rs:30:57:
File can not read: Error { kind: InvalidData, message: "stream did not contain valid UTF-8" }

Two problems. A panic is a crash with a backtrace hint, not a message for a user. And read_to_string only accepts valid UTF-8, so every PDF "can not be read", even though the file is right there.

Version 2: `?` and an error message nobody asked for

The textbook fix is to return Result from main and use ?. I added a custom error enum with thiserror and nice messages:

#[derive(Debug, Error)]
pub enum CliError {
    #[error("File not found or cannot read: {0}")]
    FileReadError(PathBuf),
    // ...
}

fn main() -> Result<(), Box<dyn Error>> {
    let content = parser::extract_text(&args.file)?;
    // ...
}

Then I ran it on a missing file:

$ wfreq nope.txt
Error: FileReadError("nope.txt")

My message was nowhere. When main returns Err, Rust prints the error with Debug, not Display, so all the #[error("...")] text is ignored.

The fix is small: keep ? everywhere, but handle the error once, at the top.

fn main() {
    if let Err(e) = run() {
        eprintln!("error: {e}");   // Display: the #[error] text
        std::process::exit(1);
    }
}

fn run() -> Result<(), Box<dyn Error>> {
    // all the real work, using ? freely
}

exit(1) lives in main, after run() has returned and dropped everything, so nothing is skipped. And eprintln! sends the message to stderr, so wfreq notes.txt > top.txt never puts an error into the output file.

Version 3: the lie

Now errors looked nice:

$ wfreq nope.txt
error: File not found or cannot read: nope.txt

Then I tried a file that did exist but was not valid UTF-8. Same message: "File not found or cannot read". The file was right there. The real reason, invalid UTF-8, was gone.

The culprit was one character in the conversion:

std::fs::read_to_string(path)
    .map_err(|_| CliError::FileReadError(path.to_path_buf()))

|_| throws the io::Error away. "Not found", "permission denied", "is a directory" and "not UTF-8" all became the same vague sentence.

The rule I took from this: when you convert an error, wrap it, don't replace it. Your error adds the context (which file), and the original error keeps the cause (why).

#[derive(Debug, Error)]
pub enum CliError {
    #[error("cannot read {}: {source}", .path.display())]
    FileRead {
        path: PathBuf,
        #[source]
        source: std::io::Error,
    },
    // ...
}

std::fs::read_to_string(path).map_err(|source| CliError::FileRead {
    path: path.to_path_buf(),
    source,
})

Two details worth knowing:

PathBuf has no Display, because a path is not guaranteed to be valid text. So the message uses {} with .path.display() as an extra argument. The leading . refers to the variant's field.
#[source] makes thiserror implement Error::source(), so tools that print error chains can follow it to the io::Error.

Now the same file says what is actually wrong:

error: cannot read bad.txt: stream did not contain valid UTF-8
error: cannot read nope.txt: No such file or directory (os error 2)

Version 4: the bug that compiled

When I added PDF and DOCX support, the parser picked a function by file extension. One version looked like this:

match ext.as_str() {
    "txt" | "md" => {
        txt::parse(file_path);
        Ok("Parser success".to_string())
    }
    "docx" => docx::parse(file_path),
    // ...
}

This type-checks (once a missing use std::fs; was added). Every arm returns Result<String, CliError>. But the ; after txt::parse(file_path) throws away the parsed text and any error. Every .txt file now "contained" the two words parser and success, and a broken file reported success.

The compiler can't catch this: the types are right, the values are wrong. A test can:

#[test]
fn reads_text_from_stdin() {
    let out = run_with_stdin(&["-", "-n", "1"], "to be or not to be");
    assert_eq!(stdout(&out), "Path: -\n 1. be              2\n");
}

Each arm should just be the parser call, so its result (text or error) is returned as-is:

"txt" | "md" => txt::parse(file_path),
"pdf" => pdf::parse(file_path),
"docx" => docx::parse(file_path),

Version 5: one bad file in a folder

Then the tool learned to read folders. A folder can hold a broken PDF next to twenty good text files. Should one bad file stop the whole run?

I decided:

One file given: any problem is an error, exit code 1.
Several files or a folder: a bad file is a warning on stderr and is skipped.
Every file failed: that is an error too, because there is nothing to count.

for path in &files {
    match parser::extract_text(path) {
        Ok(text) => merge_counts(&mut counts, count_words(&text, args.case_sensitive)),
        Err(e) if files.len() > 1 => eprintln!("warning: {e} (skipped)"),
        Err(e) => return Err(e.into()),
    }
}

This only works because of version 3. The warning is useful because the error already carries the file and the reason:

warning: cannot parse docs/old.pdf: PDF error: couldn't parse input: invalid file header (skipped)

Without the path in the error, that line would say "cannot parse: invalid file header", and you would have to guess which of the twenty files it means.

What I'd tell myself at the start

.expect() is for "this cannot happen", not for user input.
Returning Result from main prints Debug. Use a run() function and print the error yourself.
map_err(|_| ...) deletes information you can't get back. Wrap the error with #[source] instead.
Put the file path in the error, not in the caller. You will need it as soon as there is more than one file.
A match arm with a ; and a hard-coded Ok(...) compiles fine. Write an end-to-end test that checks real output.

The integration tests in tests/integration.rs check every error message mentioned here, so none of these bugs can come back quietly.

full crash → crates.io story: https://medium.com/@yash_k_saini/from-a-crash-to-crates-io-shipping-a-rust-cli-tool-f6ed59c16a9f
repo: https://github.com/yashksaini-coder/wfreq
crate: https://crates.io/crates/wfreq

Dev log #27 Deep in the review queue: Hardening libp2p across Python and .NET

Yash Kumar Saini — Tue, 27 Oct 2026 13:08:58 +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

Sometimes the most productive weeks aren't the ones where I'm smashing out hundreds of commits, but the ones where I'm acting as the glue for the projects I care about. This week was exactly that—a heavy focus on the libp2p ecosystem. I spent most of my energy in the review queue and hardening the Python implementation's connection logic. With 12 code reviews under my belt and a critical fix for dial timeouts in py-libp2p, it was a week about stability and community growth rather than just raw feature velocity.

WHAT I BUILT

My hands-on coding time was almost exclusively dedicated to py-libp2p. Networking code is notoriously finicky, and I’ve been digging into how we handle connection lifecycles lately.

I spent a good chunk of time in the swarm logic. The standout task was addressing a bug where the swarm wasn't respecting the dial timeouts we'd configured. I pushed a commit that added 73 lines and stripped out 10, focusing on making sure every transport dial is strictly bounded by ConnectionConfig.dial_timeout. It’s one of those "silent" bugs—everything looks fine until a peer is unresponsive, and suddenly your resource usage spikes because connections are hanging in limbo. Getting this right makes the whole library much more resilient in production environments.

I also did some maintenance work on the interop side. We’ve been seeing some friction between the Nim and Python implementations, specifically around the Random Number Generator (Rng) API. I spent some time trying to unbreak the Nim interop build by pinning versions and aligning with the current nim-libp2p API. Even though that specific PR didn't land (it ended up being closed), the process of debugging the interop failure was invaluable for understanding where our cross-language assumptions are breaking down.

PULL REQUESTS

I had three PRs on the go this week, each hitting a different part of the stack.

First up, in the py-libp2p repo, I opened fix(swarm): bound each transport dial by ConnectionConfig.dial_timeout. This is the core fix I mentioned earlier. It’s currently open and undergoing testing to ensure we don't accidentally drop valid connections under heavy load.

I also opened a PR in agentmesh: sdk/python: say which DNS addresses py-libp2p cannot dial. This is more of a DX (Developer Experience) improvement. There’s nothing more frustrating than a "Failed to dial" error that doesn't tell you why. This PR adds better error reporting so users know exactly which DNS addresses are causing issues.

Lastly, I had fix(interop): unbreak Nim interop build. As I mentioned, this one was closed without a merge. We decided to take a different approach to the version pinning, but the investigation I did here helped us identify the root cause of the Rng API mismatch. Sometimes a closed PR is just as useful as a merged one for moving the conversation forward.

ISSUES & DISCUSSIONS

On the issue front, I formally documented the timeout bug I found by opening host.connect ignores ConnectionConfig.dial_timeout. I like to open an issue even if I'm planning to fix it immediately—it provides a paper trail for why the code changed, which is a lifesaver for future maintainers (or future me in six months).

I also got involved in a discussion over at the afara project. I shared notes from running afara end-to-end locally after doing a fresh clone and a pass over the toju.network. There’s a specific kind of "new user" perspective you only have once, and I try to capture that whenever I’m exploring a new part of the ecosystem. I’m still waiting for some feedback on those notes, but it’s a great way to help a project improve its onboarding flow.

CODE REVIEWS

This is where I spent the bulk of my "brain cycles" this week. I performed 12 reviews in total, which is a high ratio compared to my single commit.

The vast majority of my review work was for dotnet-libp2p. The NethermindEth team is doing some incredible work bringing libp2p to the .NET world, and I’ve been helping them audit their PRs. I approved 11 PRs there, covering a wide range of critical networking features:

Stream Multiplexing: I approved the addition of Mplex support and improvements to Yamux, including sizing frames to fit secure channel records and handling aborted streams on session loss.
Gossipsub & Routing: Reviewed a change to compute gossip message IDs outside the router lock, which is a huge win for performance under high load. I also looked at how they recheck graylisting after RPC penalties.
Resource Management: Approved an opt-in inbound stream limit, which is essential for protecting nodes against DoS attacks.
Session Handling: Looked at PRs that prevent sessions from surviving peer disposal and keep routine initialization failures at the "Debug" log level to avoid spamming production logs.

Outside of the .NET world, I also left a comment on an agentmesh PR regarding Python 3.14 support. We're trying to figure out the best way to handle the transition and whether to prefer 3.13 over 3.11 in certain environments.

TECH STACK

This week was 100% Python from a coding perspective, but my "conceptual" stack included C# and Nim as well.

The additions-to-deletions ratio (+79/-12) reflects the fact that I was mostly adding safety checks and better error handling. It wasn't a "rip and replace" refactoring week; it was a "harden and protect" week. When you're working on a networking stack, you're often adding logic to handle edge cases that you didn't think of in the initial implementation.

WHAT'S NEXT

Next week, I’m hoping to see those py-libp2p PRs land. The dial timeout fix is a priority for me because it affects the stability of any project using the library for long-running nodes. I'll also be keeping an eye on the afara discussion to see if my feedback helps them streamline their local setup.

I might also dive back into the Nim interop issues. Now that we know why the Rng API was causing trouble, I want to make sure we have a robust way to prevent that kind of regression in the future. Onward!

Dev log #26 Deep in the libp2p weeds: Fixing DHT prefixes and Yamux resets

Yash Kumar Saini — Tue, 20 Oct 2026 04:12:05 +0000

GitHub · X · LinkedIn · Portfolio

TL;DR

I spent the week chasing ghosts in the networking stack, specifically focusing on the Python libp2p implementation. It was one of those weeks where you don't necessarily ship a brand-new feature, but you find the cracks in the foundation and start patching them up. I opened two significant PRs to fix protocol-level bugs in Kademlia and Yamux, and flagged four issues that were either blocking my workflow or breaking CI for everyone else.

Pull Requests

Most of my energy this week went into py-libp2p. If you've ever worked on p2p protocols, you know that the "happy path" is easy, but the edge cases are where the real work happens.

I opened a PR titled fix(kad_dht): honour protocol_prefix on the wire because I realized that even if you pass a custom protocol_prefix to the DHT, the library was just... ignoring it. It would accept the configuration, but then it would go right ahead and speak /ipfs/kad/1.0.0 on the wire anyway. That’s a nightmare for anyone trying to run a private network or a specialized DHT that shouldn't be talking to the main IPFS public network. I added about 130 lines of code and ripped out 17 to ensure that the prefix actually gets propagated down to the protocol level where it belongs. It’s one of those fixes that feels small until you realize you can't build custom networks without it.

The second PR, fix(yamux): report a remote reset to a bounded read, not a clean EOF, is even more of a deep-dive into stream multiplexing. I was looking at how Yamux handles stream resets. If a remote peer sends a RST (reset) frame, the local reader should know that something went wrong. However, I found that on a bounded read, the library was reporting a clean EOF. That's dangerous! A clean EOF tells the application "everything finished successfully," while a RST should tell the application "the connection was dropped abruptly." I pushed a fix (+59/-1) to make sure we’re reporting the state correctly. It’s a subtle distinction, but it’s the difference between a reliable file transfer and a corrupted one that thinks it's finished.

Both of these are currently OPEN and waiting for the maintainers to take a look. P2P code is notoriously tricky to review, so I'm expecting some back-and-forth on the test cases.

Issues & Discussions

I ended up opening four issues this week, mostly because I kept hitting walls while trying to get my environment and the library to behave.

First, I had to document the DHT bug properly before fixing it. In kad_dht: protocol_prefix is accepted and then ignored, I laid out the evidence of how the prefix was being dropped. It’s always better to have a clear issue trail before you just chuck a PR at a project.

I also ran into a weird one in the agentmesh repo. I was trying to run the SDK build on a machine running the Python 3.14 alpha/beta (yes, I like living on the edge), and it just exploded. I opened make sdk-python fails on a Python 3.14 host because the error message was completely unhelpful—it didn't name anything relevant to the actual failure. These kinds of "future-proofing" issues are vital for keeping projects alive as the ecosystem moves forward.

Back in py-libp2p, I noticed that the interop CI was completely broken. It turns out the Nim echo server, which we use to test cross-language compatibility, no longer compiles. I opened interop CI: the nim echo server no longer compiles, blocking every PR to get some eyes on it. There’s nothing more frustrating than having a perfect PR ready to go, only to have the entire CI pipeline turn red because of a dependency issue in a different language.

Finally, I logged the original bug for the Yamux reset issue: yamux: a bounded read on a stream the peer RESET reports a clean EOF. Documenting these protocol-level quirks is half the battle in open source.

Tech Stack

This was a pure Python and networking week. When you're working in the libp2p ecosystem, you're not just writing code; you're thinking about byte streams, frame headers, and state machines.

My work was heavily focused on:

Backend/Networking: Dealing with the Kademlia DHT and Yamux multiplexer.
Protocol Design: Ensuring that protocol IDs and prefixes are correctly handled on the wire.
CI/DX: Debugging why builds fail on newer Python versions and fixing broken interop tests.

I didn't have a commit streak this week, mostly because I spent a lot of time in "research and debug" mode—reading the specs, tracing the execution flow, and writing the issues before I actually touched the code. Sometimes the best work happens when the keyboard is quiet.

What's Next

Next week is all about the follow-through. I've got those two PRs in py-libp2p that need to be shepherded through review. Protocol changes usually require a lot of justification (rightfully so!), so I'll probably be spending some time writing more exhaustive test cases to prove that my fixes don't break existing behavior.

I'm also hoping to see some movement on the agentmesh issue. If I can't get the SDK building on Python 3.14, I might have to go down another rabbit hole to fix the underlying build script myself. The joys of being an early adopter!

Overall, I'm feeling good about the progress—cleaning up the core of a p2p library is rewarding work, even if it's invisible to most users. Onward!

Dev log #25 Hardening p2p networking and shipping interactive CLI features in Rust

Yash Kumar Saini — Tue, 20 Oct 2026 04:10:16 +0000

GitHub · X · LinkedIn · Portfolio

TL;DR

Sometimes the most satisfying weeks aren't about the volume of commits, but the weight of the problems you're solving. This week was a deep dive into the guts of p2p networking and CLI ergonomics, all in Rust. I managed to get 5 PRs merged across two key projects, totaling 2,203 additions. The highlight was definitely landing the new interactive mode in Trak and tightening up some potentially leaky connection logic in minip2p.

What I Built

Most of my energy this week was split between two very different but equally interesting Rust projects: minip2p and Trak.

Hardening the p2p Layer: minip2p

Working on minip2p always feels like a battle against the inherent chaos of the internet. When you're dealing with NAT traversal and relay servers, you can't assume anything works the way it says it does.

I spent a good chunk of time in the NAT and relay-server logic. One of the more critical fixes was addressing how we handle NAT renewals. I realized we were being a bit too trusting of the relay's expiration timestamps. If you trust an external server to tell you exactly when your mapping expires, you're asking for a dropped connection. I pushed a fix to schedule renewals at half the lifetime, providing a much-needed safety margin.

I also dug into the relay-server itself to ensure we’re properly counting finished HOP workers against the connection cap. In p2p, if you don't track your resource usage with surgical precision, you end up with "ghost" connections that eat up your capacity until the whole node crawls to a halt.

On the swarm side, I tackled a gnarly edge case where abandoning a peer-closed stream wasn't properly acknowledging its dropped data. It’s one of those "invisible" bugs that doesn't crash the app but leads to weird state mismatches over time. Getting that fixed (and documented) makes the whole stream lifecycle feel much more robust.

Better Exploration: Trak

On the developer tooling front, I’ve been contributing to Trak. This week was all about making the tool more "explorable."

The big win was landing the interactive mode. Previously, you had to know exactly what subcommand you wanted. Now, if you run trak with no arguments, it drops you into an interactive session. I also mirrored the --tree functionality from callers over to calls. When you're trying to map out a complex codebase, being able to see the call hierarchy as a tree is a game-changer.

I ended up adding about 1,757 lines to Trak this week, which included a lot of work on the interactive match list ordering and driving a scripted interactive session against the binary to make sure the UI doesn't regress.

Pull Requests

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

In minip2p, pull #323 and pull #322 were the heavy hitters for networking stability. The former dealt with that NAT renewal skepticism I mentioned, while the latter fixed the connection cap accounting in the relay server. I also landed pull #321, which ensures we're properly acking data when a stream is abandoned. These are the kinds of fixes that you don't "see" as a user, but you definitely feel when the network stays stable for days instead of hours.

Over at Trak, pull #3 was the massive one. It introduced the interactive mode and changed the default behavior of the CLI. It’s always a bit nerve-wracking to change the entry point of a tool, but the feedback on the whole-branch review was solid, and I think it makes the tool much more approachable for new users. I also squeezed in pull #2 to add the --tree flag to the calls command, keeping the API surface consistent across the different search modes.

Issues & Discussions

While most things went smoothly, I did open one issue in minip2p that's going to need some brainpower next week.

Issue #324 is about our manual-ack backpressure tests. Right now, the tests are a bit flaky because they interpret "the link has been quiet for 500ms" as "the link has stopped." In a real-world network (or even a busy CI runner), 500ms of silence doesn't necessarily mean the backpressure is working; it might just mean the CPU was busy elsewhere. I need to find a more deterministic way to validate that the data flow has actually paused without relying on wall-clock timers.

Code Reviews

I also spent some time in the dotnet-libp2p repo, helping out with some code reviews. Even though my own coding this week was 100% Rust, the p2p world is small, and the concepts carry over.

I approved pull #303, which adds a fuzzing harness for core channels. Fuzzing is absolutely essential for networking code—if there's a weird state transition possible, a fuzzer will find it long before a human does. I also took a look at pull #299 regarding Yamux stream registration. Ensuring outbound frames don't get ahead of stream registration is a classic race condition in multiplexers, so it was good to see that getting tightened up.

Tech Stack

This was a pure Rust week. 8 commits, all in Rust.

The line counts tell an interesting story: +2203 / -173. Usually, I like a higher deletion ratio (nothing feels better than deleting code), but this was a heavy feature-work week for Trak. Building out an interactive TUI (Text User Interface) and the associated logic naturally involves a lot of new code.

I didn't hit a 7-day streak this week, but the work I did put in was high-intensity. Sometimes you need those gap days to let the p2p state machine logic settle in your head before you write the next line of code.

What's Next

Next week, I need to tackle that backpressure test flakiness in minip2p. Flaky tests are the bane of my existence, and I won't feel comfortable adding more features until the CI is rock solid. I'm also planning to keep refining the interactive mode in Trak—now that the foundation is there, I want to see if I can make the navigation even snappier.

The p2p stack is feeling more stable, and the CLI tools are getting more powerful. It's a good place to be. See you in the next update!

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

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 Community: Yash Kumar Saini

What I learned building wfreq

TL;DR

Version 1: .expect() and a crash

Version 2: ? and an error message nobody asked for

Version 3: the lie

Version 4: the bug that compiled

Version 5: one bad file in a folder

What I'd tell myself at the start

Dev log #27 Deep in the review queue: Hardening libp2p across Python and .NET

TL;DR

WHAT I BUILT

PULL REQUESTS

ISSUES & DISCUSSIONS

CODE REVIEWS

TECH STACK

WHAT'S NEXT

Dev log #26 Deep in the libp2p weeds: Fixing DHT prefixes and Yamux resets

TL;DR

Pull Requests

Issues & Discussions

Tech Stack

What's Next

Dev log #25 Hardening p2p networking and shipping interactive CLI features in Rust

TL;DR

What I Built

Hardening the p2p Layer: minip2p

Better Exploration: Trak

Pull Requests

Issues & Discussions

Code Reviews

Tech Stack

What's Next

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

What I Built

Demo

Code

yashksaini-coder / grill

grill

Demo

How I Built It

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

Stage 1: finding the lines worth asking about

Stage 2: two Mastra agents on Gemma

Stage 3: the weak-spot map

Testing an LLM app without an LLM

Why Does Open Innovation Matter?

Limits, honestly

Prize Categories

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

TL;DR

What I Built

minip2p: Killing the Flaky Test

py-libp2p: Fixing the Leaks

Trak: Cleaning up the Indexer

Pull Requests

Code Reviews

Tech Stack

What's Next

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

TL;DR

What I Built

Pull Requests

Issues & Discussions

Code Reviews

Tech Stack

What's Next

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

TL;DR

What I Built

Pull Requests

Code Reviews

Tech Stack

What's Next

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

TL;DR

What I Built

Networking Internals (py-libp2p)

Agent Orchestration (agent-orchestrator)

Pull Requests

Version 1: `.expect()` and a crash

Version 2: `?` and an error message nobody asked for