DEV Community: Yash Kumar Saini

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

Yash Kumar Saini — Sat, 19 Sep 2026 05:49:17 +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

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.

Dev log #17 From 16-bit TUIs to p2p Hardening: A 227-Commit Week

Yash Kumar Saini — Sun, 16 Aug 2026 13:14:30 +0000

A high-output week focused on shipping GitBanner 1.3.0, hardening WebRTC and DHT layers in py-libp2p, and archiving kad-monitor with a proper demo harness. 227 commits, 16 PRs, and a perfect 7-day streak.

TL;DR

This week was a massive exercise in context switching, but in the best way possible. I logged 227 commits across a dozen repos, ranging from low-level p2p networking fixes in Python to aesthetic TUI refinements in TypeScript. The highlights? Shipping a 16-bit type system for GitBanner, hardening py-libp2p against DoS attacks, and finally archiving my kad-monitor project with the dignity of a full demo harness.

What I Built

GitBanner: The Aesthetic CLI

I spent a huge chunk of my time (95 commits!) on GitBanner. I’m prepping the 1.3.0 release, and I went down a rabbit hole with the TUI type system. I implemented a 16-bit CLI/TUI aesthetic—using Silkscreen for titles and VT323 for basically everything else. It gives the tool this retro-terminal vibe that I’m obsessed with.

Beyond the visuals, I did a lot of "invisible" work: rebuilding dist, regenerating cards, and cleaning up the caption logic so the 'total commits' count doesn't feel redundant next to the 52-week scope. It’s about that polish.

Obsidian & Personal Knowledge

My obsidian-vault saw 58 commits this week. I know, "commits to a vault?" but I treat my knowledge base like a codebase. I overhauled the graph palette to ensure every category has a vibrant, distinct family based on perceptual distance. I also built a calendar-sync tool to repair frontmatter and backfill my August 2026 daily notes. If it isn't automated, I won't do it.

Kad-Monitor: The Final Chapter

I decided to officially archive kad-monitor. But I didn't want to just flip the bit and walk away. I spent 37 commits building a proper "Demo Harness." I merged PR #1, which includes a runnable simulation, a full dashboard, and A/B experiment results. I also documented its limitations honestly in the README. There's something satisfying about parking a project with a clean deployment guide and CI badges rather than letting it rot.

P2P & Backend Hardening

Most of my "serious" engineering time went into py-libp2p. P2P networking is unforgiving, and this week was all about resilience.

I opened PR #1442 to enforce IP subnet diversity in Kademlia DHT k-buckets. In a decentralized network, you don't want all your peers coming from the same subnet—that's a centralization risk. I also tackled a security concern in PR #1396, hardening the /sdp HTTP server against memory-amplification DoS attacks.

One of the more satisfying fixes was PR #1441. I noticed our varint decoders were accepting truncated or over-long inputs. It’s a classic edge case that can lead to all sorts of weirdness down the line, so I tightened that up to reject malformed data immediately.

I also took a swing at hydradb, opening PR #80 to optimize cursor performance. The old logic was rescanning the cursor tail on every page drain while holding a global mutex—not exactly great for concurrency. I swapped it to subtract drained bytes instead, which should feel much snappier.

Issues & Discussions

I opened 13 issues this week, mostly as I was dogfooding my own tools or digging into upstream dependencies.

HydraDB: Found a nasty bug where merge_distributed_inner_join treats null keys as equal (Issue #96). That results in a massive cross-product of null rows that can blow up your memory.
Agent-Orchestrator: Had some trouble with the Linux AppImage on Arch (Issue #4006). It turns out it was built with a legacy FUSE2 runtime. I opened PR #4007 to move it to a modern runtime so it actually starts on clean installs.
Corsair: Did a quick accessibility audit and found some missing labels in the Studio ChatPage (Issue #746). I fixed that and also implemented a constant-time comparison for GitLab tokens to prevent timing attacks (PR #757).

Tech Stack & Workflow

This was a heavy Python and TypeScript week, but I also touched quite a bit of Lua while tweaking my Neovim config.

I actually simplified my nvim setup this week. I removed toggleterm and all its associated complexity in favor of a leaner workflow. I also restored my <leader>gg binding to trigger snacks.lazygit. Sometimes the best code is the code you delete—I ended the week with a net negative line count on my config, which is always the goal.

The stats tell a story of massive growth: +29,890 lines and -12,478 lines. A lot of that addition is documentation and the Obsidian backfill, but the 12k deletions represent a lot of refactoring in GitBanner and py-libp2p.

What's Next

Next week is all about the GitBanner 1.3.0 launch. I want to make sure the new TUI type system is rock solid. I’m also planning to dive deeper into the HydraDB join issues I uncovered—fixing that cross-join on null keys is going to be a fun challenge in distributed logic.

Seven days of commits in a row. The streak is alive, the coffee is strong, and the code is getting cleaner. See you next week!

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

GitHub · X · LinkedIn · Portfolio

Generated by DevNotion

Gravy Theory: three chickens, one base

Yash Kumar Saini — Sat, 15 Aug 2026 09:59:55 +0000

This is a submission for Frontend Challenge - Comfort Food Edition Perfect Landing.

What I Built

Gravy Theory is an interactive field guide to North Indian gravy, built around a single claim:

Butter chicken and chicken curry are not different recipes. They are the same onion–tomato masala, stopped at different moments and finished in different directions. Chilli chicken never touches it at all.

Recipes give you minutes. Cooks give you colour. So the page is organised around the thing a recipe can't hand you — the ability to look at a pan and know where you are.

It's best understood by dragging the dial rather than reading about it: open the live demo (source).

Seven sections, each answering one question:


The base	A dial that cooks the masala from raw to done. Six ingredients light up as you pass their stage.
The split	Three dishes, tabbed, each showing what it adds on top of the shared base.
The fork	One pan divides into two along drawn curves while a wok slides in from the right and stops short.
The clock	Where the time actually goes. Butter chicken is the only one needing two burners.
Green chilli	Heat plotted against aroma on a log scale. The Indian green chilli sits where nothing else does.
The dabba	Seven tins, seven jobs — and what breaks when each one is missing.
Tonight	Three questions. It's a constraint problem, not a taste problem.

The constraint

One HTML file. Zero image requests.

Every pan, thali, katori, roti, chilli, spice tin and ingredient is drawn in CSS gradients and inline SVG. No build step, no framework, no bundler, no icon font, no CDN, no tracking. The only external request is Google Fonts.

index.html    ~147 KB    everything

Open it in a browser. That's the whole setup.

Demo

Cook the base →

Best on a real screen — the dial, the tabs and the fork scene all want a pointer or a thumb. It works from 320px up, and with JavaScript switched off.

yashksaini-coder / comfort-food-challenge

An interactive field guide to North Indian gravy. One HTML file, zero image requests — every pan, thali and chilli drawn in CSS and inline SVG. DEV Frontend Challenge, Comfort Food Edition.

Gravy Theory — three chickens, one base

An interactive field guide to North Indian gravy, arguing one thing: butter chicken and chicken curry are not different recipes. They are the same onion–tomato masala, stopped at different moments and finished in different directions. Chilli chicken never touches it at all.

Built for the DEV Frontend Challenge — Comfort Food Edition (Perfect Landing prompt).

→ Live demo

The constraint

One HTML file. Zero image requests.

Every pan, thali, katori, roti, chilli, spice tin and ingredient on the page is drawn in CSS gradients and inline SVG. There is no build step, no framework, no bundler, no icon font, no CDN and no tracking. The only external request is Google Fonts.

index.html    ~146 KB    everything

Open it in a browser. That's the whole setup.

What's in it

Section	What it does
The base	A dial that cooks the masala from raw to

…

View on GitHub

Plain links, in case the embeds above don't render for you:

Live demo — https://yashksaini-coder.github.io/comfort-food-challenge/
Source — https://github.com/yashksaini-coder/comfort-food-challenge (MIT)

Journey

The thing that took three attempts

My first pass at the butter chicken looked like a donut chart. Orange disc, gradient, a white wedge for the cream. Technically food-coloured; emotionally a pie chart.

What fixed it wasn't more detail. It was realising that real food has three separable optical layers, and I had collapsed two of them into one:

an opaque pigmented base
a subsurface glow — light entering the material, scattering, coming back warmer
a specular glint — a hard reflection off the fat on top

The glow is big, blurry and coloured. The glint is small, sharp and near-white. Merge them into one soft highlight and you get plastic every single time.

/* subsurface — wide, offset toward the light, blurred, screened */
.kadai__pool::before {
  background:
    radial-gradient(
      58% 44% at 66% 30%,
      #f0a03c7a,
      #d6431f2e 54%,
      transparent 74%
    ),
    radial-gradient(34% 26% at 33% 68%, #f0a03c54, transparent 72%);
  filter: blur(9px);
  mix-blend-mode: screen;
}
/* specular — tiny, hard, warm-white. This one line is the difference. */
.kadai__lit::before {
  width: 15%;
  aspect-ratio: 2.1;
  background: linear-gradient(100deg, #fffdf4, #ffe9be 62%, #ffd79200);
  rotate: -22deg;
  filter: blur(1.1px);
  mix-blend-mode: screen;
}

The other half of it: commit to one light source and never break it. Everything on the page is lit from the upper right (--lx: 78%; --ly: 18%). Mismatched light direction is the fastest way to make something read as drawn rather than lit.

Four filters, all of them static

Inline SVG filters do the work CSS can't: a feTurbulence + feDisplacementMap pair gives gravy a ragged edge instead of a perfect circle, a gooey feColorMatrix makes cream dollops fuse with surface tension rather than stack like stickers, and thresholded noise paints tandoor char onto the chicken.

The rule I set myself: no filter animates its own parameters. Animating baseFrequency or seed regenerates Perlin noise on the CPU every frame and drops a phone to single-digit FPS. The steam filter is completely static — only the source element translates.

That char filter also taught me something I didn't know. My first version rendered nothing:

<!-- broken: thresholds at 6/7 ≈ 0.857 -->
<feFuncA type="discrete" tableValues="0 0 0 0 0 0 1"/>

fractalNoise alpha clusters tightly around 0.5 and essentially never reaches 0.857, so the soot layer was empty. A linear stretch puts the threshold where the data actually lives:

<feFuncA type="linear" slope="11" intercept="-6.6"/>

Two CSS traps I fell into twice each

Percentage padding on an absolutely positioned element resolves against the positioned ancestor, not the element. padding: 7.5% on a pan inside a 1000px stage became 75px per side on a 190px pan — the gravy collapsed to a dot. Same bug later stretched my spice tins into ovals. The fix both times is inset: 7.5% on an absolutely positioned child, which does resolve against the parent's own box.

Inline style beats every media query. My entire mobile layout for the fork scene was silently dead because the positions lived in style="--x:27%". Custom properties don't escape specificity — anything responsive has to live in a class.

Making the colour actually interpolate

The dial interpolates the gravy in OKLCH so the ramp doesn't go grey through the middle of a warm palette. But as a plain custom property, --f is a string — so the colour stepped instead of transitioning. Registering it fixes that in three lines:

@property --f {
  syntax: "<percentage>";
  inherits: true;
  initial-value: 100%;
}
@property --gravy {
  syntax: "<color>";
  inherits: true;
  initial-value: #b94a17;
}

The part I'm most proud of

Not the food — the accessibility, because it forced better decisions everywhere.

The chilli scatter and the masala dabba were originally sets of aria-pressed toggle buttons. But aria-pressed models N independent toggles, and a set where exactly one member is active is the APG radio group pattern. Converting them collapsed 13 tab stops into 2, added arrow-key navigation, and made screen readers announce "3 of 6" instead of "pressed."

A few more that I'd have shipped broken without checking:

A live region inside a display: none subtree announces nothing. My quiz verdict wrote all its text while hidden, then revealed it — silent both ways. The region now lives outside the collapsible body.
Hiding a button's label with display: none destroys its accessible name. Below 30rem my motion toggle fell back to a stale title and announced the opposite of what it would do.
role="img" makes every descendant presentational. My fork scene had four visible captions that screen readers never saw.
prefers-reduced-motion blocks usually forget delays. Zeroing animation-duration but not animation-delay leaves the hero at opacity: 0 for half a second.

There's a Pause motion control in the header that stops every looping animation (WCAG 2.2.2 — a :hover pause is reachable by neither keyboard nor touch), contrast is verified AA across every text/background pair in both palettes, and the whole page is readable with JavaScript switched off — tabs become stacked panels, charts fall back to static lists.

The bug that embarrassed me most

Late on, a review pass caught that two of my three timing bars ran past their own labels. Chicken curry's bar reached 45 minutes against a "42 min" caption; butter chicken hit 26.1 against "24". On a page whose entire middle section is a timing comparison, I had drawn the timings wrong. There's now a script that asserts every bar ends where its label says it does.

Lesson filed: the thing you're arguing is the thing to write a check for.

What's next

A cook-along mode. The rotating stamp advertises eighteen minutes and then does nothing with it — start/pause/reset driving the dial in real time against the stage timings would make the page usable at the stove, and the pause control it needs is one I've already built.

Watch the oil separate →

Built with vanilla HTML, CSS and JavaScript. No frameworks were harmed. It's one file and it's MIT — take it apart.

Dev log #16 Typographic Hierarchy and the Great Obsidian Purge

Yash Kumar Saini — Tue, 11 Aug 2026 06:18:06 +0000

Spent the week redesigning my portfolio’s blog layout and nuking thousands of stale notes in my Obsidian vault. Between the UI polish and some deep dives into libp2p DHT de-flaking, I pushed 36 commits and managed to delete almost 16,000 lines of clutter.

TL;DR

I’ve always believed that your digital space needs a good pruning every now and then to stay healthy. This week was the embodiment of that philosophy. I pushed 36 commits across four primary projects, resulting in over 23,000 additions and nearly 16,000 deletions. Most of that churn came from a massive redesign of my portfolio's blog and a long-overdue "fresh start" for my Obsidian vault. On the open-source side, I spent some quality time in the weeds of py-libp2p, chasing down flaky DHT tests and proposing better subnet diversity limits.

What I Built

Portfolio Redesign: The Typography Pivot

My main focus this week was my portfolio. I’ve been feeling like the blog layout was getting a bit cluttered, so I opened and merged PR #15, which was all about "typographic hierarchy instead of decoration." I’m moving away from unnecessary borders and boxes and letting the type do the heavy lifting.

I spent a lot of time in components/blog and app/blog refining the layout. I implemented borderless filter pills and full-width rows to give the content more room to breathe. One of the bigger technical shifts was moving the blog list to be fully server-rendered. It feels snappier, and it allowed me to implement more "honest" dates and better hover states on the rows. I also added a real focus ring for accessibility (because we’ve all been frustrated by keyboard navigation that feels like a guessing game). By the time I was done, I’d touched over 200 files in that repo alone.

The Obsidian Purge

I also took a metaphorical chainsaw to my obsidian-vault. I nuked nearly 10,000 lines of stale content. I removed entire directories for "Projects," "Rust," and "Backend" notes that were just gathering digital dust.

It’s easy to let a vault become a graveyard of half-finished thoughts. I renamed my local audit to "Persona-Audit-August-2026" and cleared out a bunch of orphaned assets and stale index notes. I even repointed some old PDF links, like the Rust book, and dropped "Practical C" from my active reading list. It feels good to have a clean slate for the second half of the year.

Neovim Tinkering (As Always)

My nvim config saw some action too. I finally made the jump from bufferline to barbar for my tabline. I also swapped out aerial for outline.nvim to handle my symbols and code structure.

Beyond the editor itself, I did some work on my config’s documentation site. I redesigned the card layout to use a masonry/bento style CSS-column grid. I reordered the cards "tallest-first" so the columns balance out better visually. I also widened the max width to 5xl and added some hairline section dividers. It’s a much tighter rhythm now.

Pull Requests

I had two main PRs on the go this week:

Portfolio PR #15 (Merged): As I mentioned, this was the big typography overhaul. It was a massive diff (+10,034 / -1,811) because I was essentially re-skinning the entire blog experience. It feels much more professional now—less like a template and more like a custom-built home for my thoughts.
py-libp2p PR #1424 (Open): This one was a bit more technical. I’ve been hitting some flakiness in the kad_dht tests, specifically where the dht_pair fixture races on routing-table population. Sometimes Node A just doesn't know about Node B in time for the test to run. I introduced a bounded poll to give the nodes time to find each other without making the tests feel sluggish.

Issues & Discussions

Most of my community-facing work happened in the py-libp2p repo. I opened three issues that I’m pretty passionate about:

Issue #1423: This was the bug report for the flaky dht_pair fixture I mentioned above. It’s one of those "it works on my machine but fails in CI" problems that makes everyone's life harder.
Issue #1422 & #1421: These are about hardening the Kademlia DHT. I want to make subnet-diversity limits runtime-configurable and add a table-wide IP-group cap (maxForTable). When you're dealing with p2p networking, you really don't want your routing table to be dominated by a single ISP or subnet—it’s a massive reliability and security risk.

I also did a tiny bit of housekeeping on Pair-Pal by creating a FUNDING.yml file. It’s a small step, but it’s part of taking my open-source projects more seriously.

Tech Stack

This was a heavily polyglot week, though the numbers are skewed by the sheer amount of content in the portfolio and vault:

TypeScript: The backbone of the portfolio redesign.
Lua: Keeping the Neovim config evolving.
Python: The language of choice for my libp2p contributions.
Markdown/MDX: This was the "cleanup" language this week.

The add/delete ratio was interesting. While I added over 23k lines, a huge chunk of that was the new portfolio structure. Deleting 15k lines—mostly from the Obsidian vault and the old portfolio layout—felt just as productive. Refactoring isn't always about the new stuff; it's about making sure the old stuff isn't in the way.

What's Next

Next week, I’m hoping to get that libp2p PR merged once the maintainers have a look at my polling logic. I also want to dive deeper into those subnet diversity configurations I proposed. On the personal side, now that the portfolio layout is stable, I need to actually sit down and write some of the long-form content I’ve been planning.

The editor is clean, the vault is purged, and the site is fast. No more excuses—time to build.

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 #15 Refining the Craft: A week of Neovim UI hacking and portfolio architecture

Yash Kumar Saini — Thu, 06 Aug 2026 04:18:06 +0000

Balanced the scales this week with a near-perfect 1:1 ratio of additions to deletions. Focused on stripping back my Neovim UI and restructuring how I showcase my career history—33 commits and a 5-day streak of pure flow.

TL;DR

This week was all about the "one for me, one for the world" balance. I spent a significant chunk of time deep in my Neovim configuration, ripping out UI components that didn't spark joy, while simultaneously overhauling my portfolio's experience section. With 3,162 additions and 3,141 deletions, the codebase effectively stayed the same size but feels twice as fast. It’s that rare kind of week where the net line count is almost zero, but the functional improvement is massive.

What I Built

nvim (The Editor Overhaul)

I’m a firm believer that your editor is a living organism. If you aren't tweaking it, you aren't learning. This week, I went on a bit of a minimalist crusade in my nvim config. I made 23 commits across 60 files, mostly centered around lua/plugins and lua/config.

The biggest move was swapping out mini.statusline for lualine. Don't get me wrong, the mini ecosystem is incredible, but I found myself wanting the specific modularity that lualine offers for my current workflow. Along with that, I decided to drop barbecue and implement a custom winbar. It’s cleaner, less distracting, and gives me exactly the context I need without the visual noise.

I also tackled a bug that has been driving me absolutely wild: my <leader>bd (buffer delete) mapping. For a while there, it had a nasty habit of taking the whole editor down instead of just closing the current buffer. There’s nothing quite like being in the middle of a deep logic flow, trying to clean up your tabs, and accidentally nuking your entire session. I finally sat down and fixed the logic so it correctly handles the last buffer—now, it re-opens the dashboard instead of exiting. Speaking of the dashboard, I added a "Recent Files" row using snacks, which has already saved me a dozen telescope lookups today.

On the maintenance side, I tweaked my CI. I used to have a GitHub Action running daily to update all my plugins, but it was getting noisy. I shifted that to a weekly Sunday 00:00 IST schedule. It keeps things fresh without cluttering my notification feed every single morning.

portfolio (Restructuring the Narrative)

While the Neovim work was about personal productivity, the work on my portfolio repo was about how I present my work to the world. I pushed 10 commits here, but they were "heavy" commits—over 2,500 lines added and 1,200 removed.

The core of this work was a total refactor of the experience section. Previously, my roles were just a flat list, which doesn't really capture the story of growing within a company. I opened and merged a PR to group roles under single company cards. It sounds like a small UI change, but the data restructuring in lib and data to make this happen cleanly was a fun puzzle. I also made sure to render the "company narrative" on the home section to give visitors more context about the impact I had at each stop.

I also spent some time in components/common and components/sections just obsessing over the layout. I refactored the layout logic to align every section rule to the content box. There’s a specific kind of satisfaction that comes from seeing your CSS grid and TypeScript props align perfectly across different screen sizes.

Pull Requests

I managed to get one significant PR through the pipeline this week:

feat(experience): group roles under one company card: This was the heart of my portfolio work. It involved 685 additions and 378 deletions. Beyond just the UI, I had to update the TypeScript interfaces to support nested role structures and ensure the rendering logic didn't break for older, single-role entries. It’s merged and live now, and the "Experience" tab looks significantly more professional.

Tech Stack & Stats

It was a classic polyglot week, though the commit activity was concentrated in Lua (for the editor) and TypeScript (for the portfolio).

Looking at the broader stats, I'm currently sitting on a massive pile of code across different languages—everything from a heavy Python and Rust backbone to Go, C#, and even some Solidity and Nix tucked away in various repos. It’s a reminder that as a freelancer, you never really stop adding tools to the belt.

The most telling stat this week is the Add/Delete ratio. 3,162 up, 3,141 down. That is the definition of a refactoring week. I wasn't just piling new features on top of a shaky foundation; I was digging out the old stuff and replacing it with something better.

I also hit a 5-day commit streak. I don't usually game the green squares, but when you're in the middle of a refactor, it’s hard to stay away for more than 24 hours. The momentum just carries you.

What's Next

With the Neovim UI finally feeling "quiet" and the portfolio restructuring out of the way, I’m looking to dive back into some deeper backend work next week. I’ve got some ideas for CLI tools that have been rattling around my head while I was tweaking my lua configs.

The goal for next week? Keep the deletion energy high. If I can ship features while keeping the total line count stable, I’m winning. See you in the next update!

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

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

Issues & Discussions

Code Reviews

Tech Stack

What's Next

The receipt should come from the person who received it

What I Built

Demo

Code

yashksaini-coder / Cairn

The itch

How I Built It

The axis everything turns on

One hash, and everything checks against it

Speech, and why the transcript is a convenience

What Cairn proves

Prize Categories

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

TL;DR

The Great Purge and Portfolio Polish

Deep in the Networking Guts

Building and Fixing at Scale

The Tooling Life: Neovim and DevNotion

Pull Requests of Note

Tech Stack & Vibe

What's Next

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

TL;DR

What I Built

Deep in the Networking weeds: py-libp2p

Hardening Reachable & Breakscale

The Digital Brain: obsidian-vault

Pull Requests & Orchestration

Issues & Community

Tech Stack & Vibe

What's Next

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

TL;DR

What I Built

Reachable: Security and Performance

Opportunity-Radar: Scraping and UI

The Personal Stack: Obsidian and Portfolio

Pull Requests

Issues & Discussions

Tech Stack

What's Next

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

The setting

Signing authenticates the record, not the routing table

Building the attack to measure it

The root cause

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

What I learned

Links

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

Project Overview

Bug Fix or Performance Improvement

Code

My Improvements

Best Use of Sentry

Best Use of Google AI

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

The setting

The first sign

The investigation

The root cause

The fix

The canary that would have caught it

What I learned

Links

Dev log #17 From 16-bit TUIs to p2p Hardening: A 227-Commit Week

TL;DR

What I Built

GitBanner: The Aesthetic CLI