DEV Community: Yash Kumar Saini

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 log #14 Hardening the DHT against Eclipse attacks and the endless battle with flaky p2p tests

Yash Kumar Saini — Sat, 01 Aug 2026 04:20:17 +0000

Dived deep into libp2p security this week with a new IP subnet diversity feature for the Kad-DHT, while fighting a few stubborn race conditions in the test suite. 3 PRs open and some automated maintenance on my Neovim setup kept the gears turning.

TL;DR

Security hardening took center stage this week as I focused on making our Kademlia DHT implementation more resilient against Eclipse attacks. Between drafting logic for IP subnet diversity and chasing down race conditions in the py-libp2p test suite, it was a week of high-leverage architectural thinking paired with the granular frustration of de-flaking async code.

The Fight for a More Secure DHT

Most of my brainpower this week went into py-libp2p, specifically around how we handle peer selection in the Kademlia DHT. I opened a significant PR, feat(kad_dht): enforce IP subnet diversity in k-buckets (#1383), which adds 226 lines of new logic to ensure our routing table doesn't get saturated by peers from the same network neighborhood.

If you're not deep in the p2p weeds, here's the deal: an Eclipse attack happens when an attacker manages to surround a target node with their own malicious nodes. If all your "neighbors" in the network are controlled by one person, they can effectively cut you off from the real network or feed you fake data. By enforcing IP subnet diversity, we make it much harder (and more expensive) for an attacker to pull this off because they can't just spin up a thousand nodes on a single cloud provider's subnet and expect to fill up our k-buckets.

It’s one of those features that feels invisible until it’s not there, but it’s critical for the long-term health of the library.

I also kicked off a deep-dive discussion titled Eclipse-attack hardening for kad-dht: our approach, and why we dropped randomized lookup selection (#1383 / #1384). We had originally looked at randomized lookup selection as a defense mechanism, but after some back-and-forth, we decided to drop it in favor of more robust bucket management. It’s always better to realize an approach is suboptimal before you merge the code.

The Tax of Asynchronous Testing

When you're working on a library that relies heavily on asynchronous networking, you eventually have to pay the "flaky test tax." This week, I spent a good chunk of time hunting down two particularly annoying race conditions that have been haunting our CI.

The first was test(timed_cache): de-flake test_expiry_removal (#1408). The issue was a classic: the test was racing against a background sweeper thread. We were using trio.sleep, which is usually fine, but in a CI environment where CPU cycles can be unpredictable, the sweeper wasn't always finishing its cleanup before the test checked the results. I also opened an issue to track this specifically: flaky: test_expiry_removal races the background sweeper thread.

The second one was test(pubsub): de-flake test_gossip_gate_filters_peers (#1401). Similar story here—subscription propagation in Gossipsub is inherently timing-dependent. If the test moves faster than the network (even a mocked one), everything breaks. Fixing these isn't the most glamorous work, but there is a specific kind of satisfaction in seeing a red CI pipeline finally turn green after you've tightened up the timing logic.

Maintenance and Tooling

On the side, I kept my environment healthy. My nvim config saw 6 commits this week, though they were mostly automated chores. I have a CI setup that keeps all my plugins updated to the latest versions. It’s a "set it and forget it" kind of thing, but it ensures that when I sit down to code, my editor is actually ready for me.

With 7 additions and 7 deletions across those 6 commits, it was a perfectly balanced week of maintenance. No new bloat, just keeping the tools sharp.

Tech Stack & Vibe

This week was heavily skewed toward Python, given the work on py-libp2p. With over 96MB of Python code in the mix (thanks to the sheer scale of the libp2p ecosystem), it’s definitely my primary focus right now. But looking at my language stats, the polyglot life is still very much real—TypeScript, Rust, and Lua are all sitting there in the background, ready for when I pivot back to frontend or systems work.

The add/delete ratio was interestingly tight this week (7 up, 7 down in the repo I committed to directly). It reflects a week of refinement rather than raw feature expansion. Even the libp2p PRs, while adding new logic, were very focused on fixing specific behaviors rather than just piling on more code.

What's Next

I have three PRs currently sitting in "OPEN" status on py-libp2p. My priority for next week is getting those merged. The IP subnet diversity work is the big one—I want to make sure the implementation is bulletproof before it hits main. Once those are in, I’m hoping to get back to some net-new feature work, but as anyone in OSS knows, the next flaky test is probably just around the corner.

Catch you in the next update. Keep shipping.

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 #13 Hardening Kademlia: A week of p2p security architecture and Neovim maintenance

Yash Kumar Saini — Thu, 23 Jul 2026 04:06:15 +0000

Spent the week laying the groundwork for major p2p security upgrades while keeping my dev environment sharp. 9 commits and a 7-day streak, but the real work was in the three security-focused issues and a deep-dive discussion on DHT hardening.

TL;DR

Sometimes the most productive weeks are the ones where you don't actually merge a single PR. This week was all about the long game—specifically, hardening the Kademlia DHT in py-libp2p against eclipse attacks. I pushed 9 commits across two repos, maintained a perfect 7-day streak, and opened three critical security issues that I’m itching to start coding.

WHAT I BUILT

While I didn't close out any massive features this week, I spent a lot of time in the guts of py-libp2p. If you've ever worked on p2p networking, you know that the "boring" maintenance work is actually what keeps the whole house from falling down.

py-libp2p

I spent most of my active coding time in tests/core and the newsfragments directory. I managed to push two significant commits here that were more about stability and refactoring than net-new features.

First, I tackled a nagging issue with the TCP transport. I re-enabled a stale IPv6 listen/dial integration test that had been sitting there (closing issue #1189). There’s something deeply satisfying about turning a skipped test back to green, especially when it involves the finicky nature of IPv6 networking.

I also did some refactoring on the pubsub-test suite. I implemented predicate-based readiness in the subscribed_mesh fixture (PR #1315). Testing asynchronous p2p systems is a nightmare if your timing isn't perfect, and moving to a predicate-based readiness check makes the whole test suite much less flaky. I added 137 lines and only pulled out 9, mostly because robust testing logic usually requires a bit more verbosity than the "hope and pray" method of time.sleep().

nvim

The rest of my commits (7 of them, to be exact) were in my nvim config. This is the background hum of my development life. Most of these were automated via CI—keeping plugins updated to their latest versions. You’ll see a bunch of ci: update all plugins to latest [skip ci] messages in my history. It’s not "feature work" in the traditional sense, but keeping my editor sharp is a non-negotiable part of the craft. Even with these small updates, I touched 7 different files. It’s a net-zero change (+12/-12), which is exactly what you want for maintenance: keep it moving, don't break the flow.

ISSUES & DISCUSSIONS

This is where the real "brain work" happened this week. I've been thinking a lot about the security of the Kademlia Distributed Hash Table (DHT), specifically how to make it more resilient against eclipse attacks. I opened three issues and started a major discussion in the py-libp2p repo to map out the path forward.

I opened Issue #1383 to address IP/subnet diversity enforcement in KBucket. If a single attacker can fill up a bucket with nodes from the same subnet, they can effectively "eclipse" a node from the rest of the network. Enforcing diversity is a standard but critical defense.

Following that, I opened Issue #1384 for adding disjoint lookup paths to find_closest_peers_network. Parallel lookups are great for speed, but if they aren't disjoint, a single malicious node can still influence the outcome of the entire search.

Finally, I opened Issue #1385 regarding monotonic sequence numbers for silent-withholding detection in GET_VALUE requests. This one is a bit more nuanced—it's about detecting when a node is intentionally not giving you the data it should have.

I tied all of these together in a discussion titled "Hardening the Kademlia DHT against eclipse attacks — three issues I want to work on" (#1386). I put this in the "Ideas" category because I want to make sure the maintainers are aligned with the architectural changes before I start dropping massive PRs. It’s about building consensus before building the code.

TECH STACK

This week was a deep dive into Python and Lua.

Python remains my heavy lifter for backend and p2p work. With over 95MB of Python code in my current environment, it’s where I do my most complex logic. The +149/-21 line ratio this week shows I was mostly in "build and expand" mode rather than "refactor and destroy" mode.

Lua is my "glue" language, primarily for Neovim. It’s lightweight and does exactly what I need it to do for tooling.

I also kept my 7-day streak alive. I’m not a fan of the "grind" for the sake of a green square, but when you're deep into a security architecture problem, it's hard not to check in every day. The flow state is real.

WHAT'S NEXT

Next week is going to be about turning those issues into code. Now that I’ve laid out the plan for Kademlia hardening and got the discussion started, I’ll be diving into the KBucket implementation to start enforcing that subnet diversity. I’m also keeping an eye on the py-libp2p discussion board to see if the maintainers have any feedback on the disjoint lookup path proposal.

It’s one thing to talk about p2p security; it’s another thing to ship it. Time to get to work.

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 #12 Hardening WebRTC and Polishing the UI: A Week of Networking and Refinement

Yash Kumar Saini — Mon, 13 Jul 2026 03:13:05 +0000

Spent the week balancing deep p2p networking work in Python with some much-needed UI polish on my personal site. 11 commits and 6 PRs later, I hit a perfect 7-day streak and made the codebase a bit more secure.

TL;DR

This week was all about the "invisible" work that makes software feel solid. I spent a good chunk of time in the weeds of p2p networking, specifically hardening WebRTC implementations, while also carving out time to refine the typography and feel of my personal portfolio. With 11 commits across 5 repos and 6 PRs in flight, I managed to keep the momentum going every single day of the week.

WHAT I BUILT

Most of my direct commit activity this week was split between keeping my dev environment sharp and making my portfolio feel a bit more "me."

Portfolio & Personal Branding

I spent some quality time in yashksaini-coder/portfolio. If you're like me, you can't leave your personal site alone for more than a month. I pushed a few updates to the blog content, but the real fun was in the UI/UX tweaks. I swapped out the primary typography for JetBrains Mono—there’s just something about a good monospace font that makes a dev portfolio feel right.

I also went through a "make-interfaces-feel-better" phase. I refactored the selectedwork section, specifically dropping a cursor-follow preview tile that felt a bit too "heavy" and replaced it with something more streamlined. I also polished the index rows to make the transitions feel snappier. It’s about +452/-279 lines of code, which is a healthy amount of churn for a week that was supposed to be about "minor" updates.

The Maintenance Grind

My nvim config is basically a living organism at this point. I have CI set up to automatically track plugin updates, and this week was particularly noisy with 6 commits just keeping the toolchain current. It’s [skip ci] territory, but it ensures that when I sit down to actually write code, my editor isn't lagging behind the latest Lua API changes.

I also did a quick version bump for trx (v0.1.13) and merged a branch in openslate to fix some styling and search logic in the command palette. It’s the kind of small-scale maintenance that prevents technical debt from snowballing.

PULL REQUESTS

The PR list is where the "real" engineering happened this week. I’ve got five open PRs and one merged, mostly focused on the libp2p ecosystem and some documentation DX.

Deep Diving into WebRTC (py-libp2p)

The bulk of my brainpower went into libp2p/py-libp2p. I’ve been working on a few critical pieces for the WebRTC-Direct transport:

Shared-port dispatching: I opened a PR to add UdpMux. This is a big one for anyone running nodes behind restrictive NATs. It allows for shared-port inbound dispatching, which is essential for making WebRTC-Direct viable in the real world. That PR alone is +541 lines of new logic.
Security & Hardening: I submitted a fix to harden the /sdp HTTP server against memory-amplification DoS attacks. Networking code is always a target, and making sure we aren't vulnerable to simple memory exhaustion is a priority.
Refactoring & Cleanup: I also managed to delete some code! I deduplicated _varint.py in favor of the centralized libp2p.utils.varint. It’s only a net loss of about 60 lines, but every line of code removed is a line I don't have to debug later.
Testing: Re-enabled some stale IPv6 integration tests for the TCP transport. Green CI is the only CI I trust.

Documentation DX

Over at Hugging Face, I opened a PR for tau to add a "copy" button to code blocks in the docs. It’s a small thing, but as a dev, there is nothing more annoying than trying to manually select a multi-line command and accidentally grabbing the line numbers. I opened an issue for it first to track the requirement and then followed up with the implementation.

CODE REVIEWS

I spent some time on the other side of the fence this week, too. I reviewed and approved a PR for trx that was updating the main branch with new contributor changes. It was a relatively light review week, but I always try to make sure I’m unblocking others, especially in smaller OSS projects where contributor momentum is everything.

TECH STACK

This week was a polyglot's dream.

Python: My primary tool for the p2p networking work. Between UdpMux and DoS protection, I was deep in the Python standard library and libp2p internals.
TypeScript & MDX: Used these for the portfolio updates. The JetBrains Mono swap and the UI refactor kept me busy in the frontend.
Rust: Handled the version bumping and chore work for trx.
Lua: Mostly automated, but still the backbone of my editing environment.
Svelte: Touched this briefly while helping out with the openslate command palette fix.

With a 7-day streak, I’ve stayed consistent. The line delta (+609 / -306) shows that while I'm building new features (like the WebRTC muxing), I'm still making a conscious effort to refactor and delete the old cruft.

WHAT'S NEXT

The WebRTC PRs in py-libp2p are the priority for next week. I need to shepherd those through the review process and address any feedback on the UdpMux implementation. I’m also looking forward to seeing the copy button land in the tau docs—it’s a small win for developer experience.

On the personal side, now that the typography on the portfolio is settled, I might start looking into some more interactive elements for the blog section. But for now, I’m just happy to have a week of green squares and solid networking code under my belt. See you in 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

Adding WebRTC to py-libp2p: Two Runtimes, Three Specs, and One Unforgiving Private Slot

Yash Kumar Saini — Mon, 13 Jul 2026 03:07:12 +0000

TL;DR — py-libp2p PR #1309 adds an experimental WebRTC transport (/webrtc-direct and /webrtc) as a v1 node-to-node foundation. It's ~6,700 lines across 41 files, gated by libp2p[webrtc] + enable_webrtc, and merged after four rounds of maintainer review. This is the story of what's inside, why the seams are where they are, and the three bugs that would have shipped silently if the loopback test hadn't been written.

A quick honest note before we start

I want to be upfront about how this post came together. This is a reflective engineering write-up on a PR I authored, with the goal of turning the review conversation, spec cross-references, and multi-round fixes into something a future reader can learn from without having to scroll 400 GitHub comments.

Where I quote maintainers, those are their words. Where I explain "why we did it this way," I've tried to preserve the trade-offs as they actually came up in review — not the polished, past-tense version. This isn't a marketing post. WebRTC in py-libp2p is experimental v1; browser interop is not supported; there are follow-ups filed. I'll say that plainly throughout.

If you're new to libp2p, WebRTC, or trio, there's enough background woven in to keep you oriented. If you're deep in this ecosystem already, the interesting sections are the framing, the certificate pin, and the two-runtime bridge — feel free to jump.

The problem: why a Python libp2p wants WebRTC at all

libp2p is a modular network stack: identity, transports, security, multiplexing, routing, and pub/sub, each swappable. Its Go and JS implementations have had WebRTC for a while. Python did not — issue #546 tracks the gap.

Why care? Three reasons the ecosystem keeps coming back to:

NAT traversal for real users. Most consumer machines sit behind at least one NAT, often more. WebRTC's ICE + STUN + TURN dance is the only widely-deployed answer that browsers speak natively. If your Python peer wants to talk to a browser peer — or two NATed Python peers want to talk directly with only a light-touch relay — WebRTC is the door.
Native multiplexing. WebRTC data channels give you real per-stream framing over SCTP. That means the transport itself carries a "muxer," so you can skip the Yamux / Mplex upgrade step that a TCP-based libp2p connection needs.
Server-to-browser without an HTTP server. With /webrtc-direct, a Python node can accept an inbound connection from a browser peer purely via a UDP socket + a certificate hash embedded in the multiaddr. No signaling server, no HTTPS termination, no TURN unless traversal forces you there.

That's the "why." Now for the "how" — and specifically, why "how" turned into 6,700 lines of Python that took four review rounds to get right.

What actually landed

The PR body says it, but here it is in one paragraph so you know the surface area:

WebRTCDirectTransport (/webrtc-direct) and WebRTCPrivateTransport (/webrtc, relay-signaled).
Spec-compliant data-channel framing — uvarint length-prefixed protobuf, with the full FIN / FIN_ACK / STOP_SENDING / RESET state machine.
In-band data channels for application streams; the Noise handshake channel (id=0) stays pre-negotiated per spec.
Signaling with the bilateral ICE_DONE fix from libp2p/specs#585.
Noise XX with a prologue that binds the handshake to the DTLS certificate fingerprints.
ECDSA P-256 cert generation with multihash / multibase fingerprint encoding.
A DTLS cert pin that actually pins the cert. More on that shortly.
A trio ↔ asyncio bridge, because py-libp2p is trio and aiortc is asyncio.

The final tests count: 153 / 153 passing, including a real RTCPeerConnection ↔ RTCPeerConnection loopback test that exercises framing, chunked writes over the 16 KiB SCTP ceiling, and the SDP-fingerprint canary.

What's out of scope, and this matters: browser interop is not supported here; go / js /webrtc-direct interop is not wired (they reconstruct the SDP from STUN USERNAME, we don't have that hook yet); the /webrtc dial path is a listener + signaling skeleton only. All of that is deliberate. This is v1. v2 (specs#715) is where browser dial actually happens, and we wanted the v1 skeleton in the tree so it stops being vaporware.

Architecture in one picture

Two flavors of WebRTC show up in py-libp2p, and it took me a while to keep them straight. Here they are, side by side:

flowchart LR
  subgraph Direct["/webrtc-direct (server-reachable)"]
    A[Client] -- SDP offer built<br/>from server multiaddr --> B[Server<br/>publishes cert hash]
    A <-. DTLS + data channels .-> B
  end

  subgraph Private["/webrtc (both peers NATed)"]
    C[Peer A] --- R[Relay v2]
    D[Peer B] --- R
    C -. signaling over relay:<br/>SDP + ICE + ICE_DONE .-> D
    C <-. direct DTLS + data channels .-> D
  end

Two transports, one shared substrate: certs, SDP, Noise binding, stream framing, and the trio↔asyncio bridge. Only signaling differs.

Inside a single peer, the runtime layout looks like this:

flowchart TB
  subgraph Trio["Trio world (py-libp2p)"]
    T1[Host / Swarm]
    T2[WebRTCConnection]
    T3[WebRTCStream × N]
    T4[Application handlers]
  end

  subgraph Bridge["AsyncioBridge<br/>(background daemon thread)"]
    BR[asyncio event loop]
  end

  subgraph Asyncio["Asyncio world (aiortc)"]
    A1[RTCPeerConnection]
    A2[RTCDataChannel × N]
    A3[DTLS / ICE / SCTP]
  end

  T1 --> T2 --> T3
  T2 -- run_coro --> BR
  BR -- runs on --> A1
  A1 --> A2 --> A3
  A2 -. on_data via trio_token .-> T3

The interesting seam is the arrow labelled trio_token: aiortc calls into us from an asyncio thread, and we need those callbacks to hand data to trio memory channels safely. If we skip the token, we get RunFinishedError and worse. That code lives in stream.py:382-410 — I'll come back to it.

Deep dive #1 — framing, or "why bare protobuf was the wrong wire"

If you read the first draft of this PR, application-level writes were serialized as bare protobuf Message bytes and shoved straight into data_channel.send(...). That "works" on the happy path for small payloads. It's also wrong for two independent reasons — and once you understand both, you understand why the spec is written the way it is.

Reason 1: SCTP has a 16 KiB message ceiling

The libp2p WebRTC spec caps each data-channel message at 16 384 bytes. Below that, you're fine. Above, aiortc will happily hand SCTP an oversized message that gets fragmented in ways your peer can't reassemble, or your peer will drop it, or SCTP itself will complain — the failure modes vary by implementation, which is worse than a clean rejection.

The fix is to chunk on the sender's side and let the read side see one wire message per SCTP message.

Reason 2: bare protobuf isn't self-delimiting inside a stream frame

Even inside the 16 KiB limit, a Go or JS peer decoding your message needs a length prefix. The spec is explicit: each SCTP message is one uvarint length prefix + one protobuf Message. Not "raw protobuf." Not "concatenated protobufs." Exactly one framed pair per SCTP datagram.

Here's the on-wire shape:

┌───────────────────┬──────────────────────────────────────────┐
│  uvarint length   │  protobuf Message (flag? + message? bytes)│
└───────────────────┴──────────────────────────────────────────┘
                    ← up to 16 KiB total, hard ceiling ──────→

The uvarint itself is straightforward — 7 bits of payload per byte, top bit for continuation, capped at 10 bytes so it fits uint64:

# libp2p/transport/webrtc/_varint.py
def encode_uvarint(value: int) -> bytes:
    if value < 0:
        raise ValueError("uvarint cannot encode negative values")
    buf = bytearray()
    while value > 0x7F:
        buf.append((value & 0x7F) | 0x80)
        value >>= 7
    buf.append(value & 0x7F)
    return bytes(buf)

The sender side of a stream then becomes:

# libp2p/transport/webrtc/stream.py
async def write(self, data: bytes) -> None:
    if self._state == StreamState.RESET:
        raise WebRTCStreamError("Stream was reset")
    if self._write_closed:
        raise WebRTCStreamError("Write side is closed")

    offset = 0
    while offset < len(data):
        chunk = data[offset : offset + MAX_PAYLOAD_SIZE]
        msg = Message(message=chunk)
        await self._send_message(msg)
        offset += len(chunk)

MAX_PAYLOAD_SIZE is chosen so that even with the largest reasonable varint length prefix plus protobuf tag bytes, the full framed wire message stays under 16 KiB. The chunk boundary is on the sender; the reader just decodes one frame per SCTP message.

And this is worth calling out — there's one spec detail that's easy to miss:

The spec allows a message to carry both data and FIN, and the data must be delivered to the reader before the read channel is closed.

So the receive path enqueues payload first, then processes the flag. Getting that order wrong gives you a data loss bug that only shows up on the last chunk of a stream close. From stream.py:352-380:

# libp2p/transport/webrtc/stream.py
def _apply_on_trio_thread() -> None:
    # Enqueue payload BEFORE processing flags — the spec allows a
    # message to carry both data and FIN, and the data must be
    # delivered to the reader before the read channel is closed.
    if has_payload:
        try:
            self._read_send.send_nowait(payload)
        except trio.WouldBlock:
            logger.warning(...)
    if has_flag:
        if flag == Message.FIN:
            self._read_closed = True
            self._enqueue_eof_sentinel_locked()
            self._schedule_send(Message(flag=Message.FIN_ACK))
        elif flag == Message.FIN_ACK:
            self._fin_ack_received.set()
        ...

The comment isn't decoration; it's a spec citation for a future reader who wonders why the ordering matters.

Deep dive #2 — the certificate pin that actually pins

This is my favourite bug in the PR. It's the kind of bug that survives green tests because the failure is silent, the API looks correct, and the wrong value is only observable if you cross-check two places that most people cross-check exactly once — at spec-reading time, then never again.

Setting the scene

/webrtc-direct works by embedding the server's DTLS certificate hash in the multiaddr:

/ip4/127.0.0.1/udp/9090/webrtc-direct/certhash/uEiA…/p2p/12D3K…

The client dials that address, constructs an SDP offer locally (there's no signaling server), and expects the server's DTLS handshake to present a cert whose SHA-256 matches the certhash in the multiaddr. If they don't match, the client bails — that's the whole security story of /webrtc-direct.

Which means: whatever cert the server advertises, it must actually use in the DTLS handshake. If those two paths diverge, you either get a broken connection or, worse, a working connection that isn't actually pinned to anything.

The naïve pin

In aiortc, you'd expect to set the cert on the RTCPeerConnection like this:

pc = RTCPeerConnection()
pc._certificates = [my_cert]   # ← looks fine, right?

That's a silent no-op. RTCPeerConnection reads only its own name-mangled private attribute — self.__certificates inside the class, which mangles to self._RTCPeerConnection__certificates from the outside. The pc._certificates attribute lives on the object, sure, but aiortc never looks at it. It happily generates its own certificate at construction time and uses that in DTLS. Your advertised /certhash/ is a completely different digest.

The maintainer review flagged this indirectly — the loopback test caught it directly. Every test that ran without an actual peer connection passed. The moment we ran an SDP round-trip and grepped the a=fingerprint line, the pinned cert was nowhere.

The fix

# libp2p/transport/webrtc/_aiortc_helpers.py
async def create_peer_connection(
    rtc_cert: RTCCertificate,
    ice_servers: list[str] | None = None,
) -> RTCPeerConnection:
    """
    Create an RTCPeerConnection pinned to the given certificate.

    aiortc >= 1.5 no longer accepts certificates= in RTCConfiguration —
    passing it raises TypeError.  We build the peer connection with ICE
    servers only, then replace the auto-generated DTLS certificate before
    any SDP operation triggers the DTLS handshake.  The fingerprint and
    the actual handshake cert are read from a name-mangled private
    attribute (self.__certificates inside RTCPeerConnection →
    self._RTCPeerConnection__certificates from the outside).  Setting
    the un-mangled pc._certificates is a no-op that aiortc never reads.
    """
    config = RTCConfiguration(iceServers=list(ice_servers) if ice_servers else [])
    pc = RTCPeerConnection(configuration=config)
    # Must use the mangled name — aiortc reads only self.__certificates.
    pc._RTCPeerConnection__certificates = [rtc_cert]  # type: ignore[attr-defined]
    return pc

Two characters (__) that would look like a typo in a code review, guarding a subtle security property.

The canary

Fixing the bug is one thing; making sure it stays fixed is another. The loopback test now includes a canary — after the SDP exchange, it parses the a=fingerprint:sha-256 line out of the offer and asserts it equals the SHA-256 of the pinned cert:

# tests/core/transport/webrtc/test_multiplexing_loopback.py
def _sdp_fingerprint_string(cert: WebRTCCertificate) -> str:
    """
    Render *cert*'s SHA-256 fingerprint in the colon-separated upper-hex
    form aiortc writes into SDP a=fingerprint:sha-256 ... lines.
    """
    return ":".join(f"{b:02X}" for b in cert.fingerprint)

If somebody in the future refactors the pin — or aiortc renames __certificates — this test fails immediately, with a message that points straight at the divergence. That's the whole point of a canary: it wouldn't have been added if the bug hadn't happened, and it stays there so the bug can't come back.

The subplot here isn't "aiortc is buggy" — it's that libraries with public APIs sometimes leak private-attribute contracts into their integrators, and when they do, the only defense is a test that observes the on-wire outcome, not the API you think you called.

Deep dive #3 — bridging two runtimes without blowing up

py-libp2p is trio. aiortc is asyncio. Both are event loops. Neither will await the other's coroutines. This isn't a limitation of Python; it's a design decision by trio (structured concurrency, no thread-safety-by-default) that leans hard against interop.

The options are: pick one runtime, run both loops in one thread with a bridge library, or run the second loop in its own thread. Option one wasn't available — swapping either dependency was a non-starter. Option two (anyio, trio-asyncio) has enough corner cases with aiortc's assumptions that we didn't want to chase them under a review deadline. Option three is boring and explicit, which is what we wanted.

The bridge is a small class:

# libp2p/transport/webrtc/_asyncio_bridge.py
class AsyncioBridge:
    """
    Manages a background asyncio event loop for running aiortc coroutines.
    """
    def __init__(self) -> None:
        self._loop: asyncio.AbstractEventLoop | None = None
        self._thread: threading.Thread | None = None
        # Protects start/stop against concurrent trio calls
        self._lock = trio.Lock()
        # Protects _loop/_started/_stopped reads from run_coro against
        # concurrent stop() — needed because run_coro_sync is called
        # from non-trio threads (asyncio callbacks).
        self._state_lock = threading.Lock()

Two locks — a trio.Lock for the trio side of start/stop, and a threading.Lock because asyncio callbacks can hit the bridge from a foreign thread. If you only have the trio lock, you race with those callbacks and it manifests as intermittent AsyncioBridgeError: not running right at shutdown.

The heart of it is run_coro:

# libp2p/transport/webrtc/_asyncio_bridge.py
async def run_coro(self, coro: Coroutine[Any, Any, T]) -> T:
    with self._state_lock:
        loop = self._loop
        running = self._started and not self._stopped
    if loop is None or not running:
        coro.close()
        raise AsyncioBridgeError("AsyncioBridge is not running")

    future = asyncio.run_coroutine_threadsafe(coro, loop)

    def _wait_for_result() -> T:
        return future.result()

    try:
        # abandon_on_cancel=True lets trio cancel the scope immediately.
        # The background thread is abandoned but we cancel the asyncio
        # future below so it doesn't leak.
        return await trio.to_thread.run_sync(
            _wait_for_result, abandon_on_cancel=True
        )
    except trio.Cancelled:
        future.cancel()
        raise

Two subtle things worth pausing on:

abandon_on_cancel=True — without it, trio's cancellation waits for the thread to unwind before actually cancelling. With aiortc's coroutines that can mean seconds, or forever. With abandon_on_cancel=True, trio releases the scope immediately, we forward the cancellation to the asyncio future, and the background loop cleans up on its own timeline.
The _state_lock snapshot — we read loop and running under the lock, then use the local loop variable. If stop() runs concurrently, we either dispatched to a valid loop (which will handle the cancel) or we raise cleanly. Never a race where we scheduled on a partially-torn-down loop.

The reverse direction — aiortc calling us — needs a different trick. When a data channel fires an on_message event, we're on the asyncio thread, and we need to push bytes into a trio.MemorySendChannel. Direct calls into trio primitives from a foreign thread are undefined behavior. The trick is trio.lowlevel.current_trio_token(), captured at construction time:

# libp2p/transport/webrtc/stream.py
try:
    self._trio_token = trio.lowlevel.current_trio_token()
except RuntimeError:
    self._trio_token = None

def _run_on_trio_thread(self, fn: Callable[[], None]) -> None:
    token = self._trio_token
    try:
        trio.lowlevel.current_task()
        in_trio = True
    except RuntimeError:
        in_trio = False

    if in_trio or token is None:
        fn()
    else:
        try:
            trio.from_thread.run_sync(fn, trio_token=token)
        except trio.RunFinishedError:
            logger.debug(...)

If we're already on a trio task (tests), we call inline. If we're on an asyncio callback thread, we go through trio.from_thread.run_sync with the token. If trio has already shut down, we log and drop — not raise, because the callback is fire-and-forget from aiortc's point of view.

This is the code that makes the whole transport not-flaky. It's ~30 lines. It took two review cycles to converge on.

Deep dive #4 — Noise XX, but bound to DTLS

WebRTC already gives you an encrypted DTLS channel between two peers. Why do we still run Noise on top of it?

Because DTLS authenticates the certificate, not the libp2p peer. Anyone with a valid ECDSA P-256 cert can complete the DTLS handshake. But libp2p peers are identified by their libp2p identity key, which is a completely different keypair. So we need a step where each side proves control of a libp2p identity — and the natural way to do that is Noise XX, which is already how libp2p peers authenticate on TCP.

But there's a subtle attack here: what if an attacker sits between the two peers, has their own valid DTLS cert, and forwards both DTLS sessions? Both peers see a valid DTLS handshake, then run Noise on top — and if Noise doesn't know anything about DTLS, it authenticates fine end-to-end through the attacker.

The fix is the Noise prologue — a byte string that's mixed into the Noise handshake state at the start. The libp2p spec binds Noise to DTLS by putting both certificate fingerprints into the prologue:

# libp2p/transport/webrtc/noise_handshake.py
def build_noise_prologue(
    local_fingerprint: bytes,
    remote_fingerprint: bytes,
) -> bytes:
    """
    Build the Noise prologue that binds the handshake to the DTLS session.

    Prologue format:
        b"libp2p-webrtc-noise:" + encode(local_fp) + encode(remote_fp)
    """
    local_mh = _MH_SHA256_HEADER + local_fingerprint
    remote_mh = _MH_SHA256_HEADER + remote_fingerprint
    return NOISE_PROLOGUE_PREFIX + local_mh + remote_mh

If an attacker sits in the middle, each side sees a different remote fingerprint (the attacker's), so the prologues mismatch, and Noise fails. Clean. Nothing needs to change in the Noise state machine itself — the prologue is a parameter it already accepts.

The rest of the handshake reuses py-libp2p's existing PatternXX implementation. That's what "in-band data channels" is buying us — the Noise handshake rides over data channel 0, which is pre-negotiated (negotiated=True, id=0) so both peers agree on its identity without SDP renegotiation. Application streams get their own in-band channels, so the on('datachannel') event fires on the peer.

Why this matters: in the first draft of the PR, application streams used negotiated=True as well. The consequence was that on the remote peer, the datachannel event never fired, because pre-negotiated channels bypass it entirely. accept_stream() blocked forever. It was a classic "the spec is clear, we read it too quickly" fix — Noise uses negotiated=True because it's channel 0 and both sides know it's there; application streams use negotiated=False because they need to be announced.

Deep dive #5 — signaling, ICE_DONE, and a spec fix in flight

For the /webrtc (relay-signaled) case, two NATed peers need to exchange SDP over some other channel to get started. That channel is a Circuit Relay v2 stream, and the protocol is /webrtc-signaling/0.0.1.

The interesting part isn't the SDP exchange — it's how you know it's done. ICE candidates trickle over the signaling stream as each peer's ICE agent discovers them. At some point, both sides are done trickling, and the stream can close. But if one side closes prematurely, the other side loses candidates it hadn't received yet.

The old spec left this timing ambiguous. libp2p/specs#585 fixed it by adding a bilateral ICE_DONE message — each side signals it's done, and neither closes until both ICE_DONEs are seen:

Initiator                              Responder (via relay)
  ──── SDP_OFFER ─────────────────────────>
  <─── SDP_ANSWER ─────────────────────────
  <──> ICE_CANDIDATE (trickle, both ways) <>
  ──── ICE_DONE ───────────────────────────>
  <─── ICE_DONE ───────────────────────────
  (both sides close signaling stream)

That's what signaling.py implements. It's not the most complicated code in the PR, but it's the piece that cannot be handwaved with "we'll add ICE_DONE later" — it changes the state machine of when both peers agree the signaling phase has ended.

The seam that will save us a rewrite: `_apply_ice_credentials()`

There's one more piece of "spec is in flight" that we chose to handle architecturally rather than by writing a TODO.

The libp2p/specs#672 discussion is about Chrome removing SDP munging for ICE credentials — a change that will eventually break the v1 way of injecting the peer's ICE ufrag into the SDP. When that lands, code that has ICE credential handling scattered across the SDP builder is in for a bad time. Code that has all of it in one function just changes that function.

So we put all of it in one function:

# libp2p/transport/webrtc/sdp.py
def _apply_ice_credentials(
    sdp: str,
    ufrag: str,
    pwd: str,
    fingerprint_hex: str,
    remote_ufrag: str | None = None,
    remote_pwd: str | None = None,
) -> str:
    """
    Apply ICE credentials to the SDP.

    **This is the single seam for libp2p/specs#672.**  When Chrome drops
    ICE credential munging support, only this function needs to change.
    Currently a no-op passthrough — local credentials are already in the
    SDP template.  The remote credentials are accepted but unused until
    the spec changes require injecting them via a separate mechanism.
    """
    return sdp

Today it's a passthrough. Tomorrow, when v2 dispatches by libp2p+webrtc+v1/ / libp2p+webrtc+v2/ ufrag prefixes, this function grows a small branch on the ufrag prefix and everything else in the builder stays intact.

The maintainer's response, verbatim, was:

The v1 foundation here (framing, Noise prologue, certhash, _apply_ice_credentials() as a seam) is not throwaway — it feeds v2, but _apply_ice_credentials() will likely evolve into a version-dispatch layer rather than a single swap.

That's the value of a seam. It reserves the space for future evolution without pre-committing to which evolution.

Testing: 153 tests, but only one of them mattered

Unit tests are cheap; they run in ~10 seconds and give you fast feedback on individual modules. Integration tests are expensive; the two-RTCPeerConnection loopback test spins up an ICE agent, waits for connectivity, and pushes data through the SCTP stack. It takes a few seconds and is annoyingly flaky under heavy CI load.

But that expensive test caught three bugs the cheap ones missed:

Bug	Symptom in unit tests	Symptom in loopback	Caught by
`pc._certificates = [...]` no-ops	✅ Green	Advertised certhash ≠ SDP fingerprint	SDP-fingerprint canary
Application channels used `negotiated=True`	✅ Green	`accept_stream()` hangs forever	Real accept-stream round trip
Bare protobuf, no length prefix	✅ Green	16 KiB payload gets fragmented, reader dumps garbage	> 16 KiB echo round-trip

Each of these was reachable by unit tests only if you knew to look for them, which no one did. That's the lesson of integration testing WebRTC: unit tests are a floor, not a ceiling, and the ceiling has real hardware in it.

The loopback test's docstring calls this out explicitly:

"""
Integration test: two real RTCPeerConnections, end-to-end loopback.

Validates the WebRTC data-channel layer at the wire level — the three
ecosystem-compatibility fixes documented in PR #1309 review notes:

  - In-band data channels (negotiated=False): the responder's
    'datachannel' event must fire so WebRTCConnection.accept_stream()
    unblocks.
  - uvarint length-prefixed framing: every send must stay within the
    16 KiB spec ceiling; > 16 KiB payload round-trips through chunking
    and reassembly.
  - DTLS certificate pinning: aiortc >= 1.5 dropped 'certificates=' in
    RTCConfiguration; the cert override must take effect before
    createOffer/createAnswer so the local DTLS fingerprint in the SDP
    matches the one our peer expects.
"""

If somebody reads this file six months from now, they know exactly why those three assertions exist. That's the value of leaving the review context in the code, not just in the PR comments.

What the review looked like from the inside

Four review pushes on top of the initial scaffolding, roughly:

Correctness pass. Copilot flagged 22 inline issues, mostly F401 unused imports and one substantial one — that dial() was returning connections without actually running ICE/DTLS/Noise. We raised NotImplementedError on the paths that weren't wired yet, so a caller would fail loudly instead of getting a phantom connection.
Wire the transport into aiortc. This is where the cert-pin bug lived, silent, until we started running real handshakes.
Framing + in-band channels + cert pin. The three bugs above, all in one series of commits. The commit messages are worth reading — each one names exactly what was wrong and why the fix is right.
Two-PC loopback test + newsfragment reframe. Landing the integration test that guards the three fixes, and rewriting the newsfragment so "experimental v1 node-to-node scaffolding" is the first thing a changelog reader sees.

The maintainer's approving comment, in full:

Merging this as experimental WebRTC scaffolding behind libp2p[webrtc] + enable_webrtc. The critical-path fixes from the re-review (uvarint framing, in-band channels + DCEP wait, cert pinning, loopback tests, docstring/newsfragment accuracy) are in place, and CI is green.

#546 stays open (Refs #546 — do not auto-close on merge). This PR advances the parent issue but does not satisfy it.

That last line matters. Issue #546 is "WebRTC support in py-libp2p." This PR is not that. This PR is scaffolding for that. The follow-ups — browser interop, go/js interop, full private dial — are separate issues that get their own PRs on this foundation.

Where it goes next

The concrete follow-ups, in the order they'll probably ship:

STUN USERNAME exposure spike in aiortc. Go and JS /webrtc-direct listeners reconstruct the SDP offer from the STUN username on the inbound packet. Our listener uses an HTTP POST /sdp exchange as a py-to-py harness. If aiortc exposes the inbound STUN username via a hook, our listener can switch and interop lights up.
Private /webrtc dial. The listener is here, the signaling protocol is here, the WebRTCPrivateTransport is here. The dial path currently constructs and returns a connection without running relay signaling — that's the next PR.
Version dispatch in _apply_ice_credentials(). When libp2p+webrtc+v1/ and libp2p+webrtc+v2/ ufrag prefixes are standardized, that function grows a branch and WebRTCDirectListener learns to look at the prefix. v2 is the browser-compatible path.
Interop tests against go-libp2p and js-libp2p. These will fail today, deliberately. When the STUN username hook lands, they start passing, and we know we're on the ecosystem.

None of these are architecturally scary. The scary architecture is what this PR did: two runtimes, one wire format, one lifecycle, three specs. That's done.

The one takeaway I want you to leave with

If you're building anything that crosses two runtimes, two libraries, or two specs, the seams are the API. Not the surface API — the internal seams. Where does ICE credential handling live? One function. Where does the DTLS cert pin land? One helper. Where does the trio ↔ asyncio boundary get crossed? One class.

The maintainer review didn't just catch bugs. It repeatedly pushed us toward fewer places where the interesting decisions were expressed. Every review round pulled scattered logic into a named function, so that when the next spec revision lands (v1 → v2, specs#672, specs#715), the change is localized.

Scaffolding isn't just "the parts that don't work yet." Scaffolding is the shape of the seams, so the parts you fill in later fit.

Try it, and honest expectations

You can install and inspect it today:

pip install 'libp2p[webrtc]'

Then in code:

from libp2p import new_host

host = new_host(enable_webrtc=True)
# ...multiaddr: /ip4/…/udp/…/webrtc-direct/certhash/u…/p2p/…

Realistic expectations:

✅ Two Python peers talking /webrtc-direct on a loopback interface will work.
⚠️ Python peer ↔ Go peer or Python peer ↔ JS peer over /webrtc-direct will not work yet (the STUN username reconstruction gap).
❌ Browser peer dialing a Python peer will not work. That's v2's job.

If you want to help, the follow-up sub-issues under #546 are the map. The seams are ready. The wires need connecting.

References

Written by Yash Kumar Saini — reflections on a merged py-libp2p PR. Corrections and pushback welcome; I'll update this post in place if I got anything wrong. The PR itself is the source of truth.

Hardening Kademlia DHT: The Eclipse Attack That Record Signing Doesn't Stop

Yash Kumar Saini — Thu, 09 Jul 2026 05:34:38 +0000

Hardening Kademlia DHT: The Eclipse Attack That Record Signing Doesn't Stop

A few days ago I published Dev Log #9, which covered a security fix I landed in py-libp2p: binding a signed PeerRecord to its signer's identity so an attacker can't relay another peer's record as their own.

Then this comment came in from Valentyn Kit, a systems engineer:

"Binding the record to its signer kills the forged-record path, nice. The attack that tends to show up right after in Kademlia is eclipse/Sybil, where nobody forges anything: libp2p IDs are already pubkey-derived, but nothing makes it costly to mint a batch of valid IDs that land closest to a target key and quietly own that slice of the routing table. Curious whether py-libp2p has appetite for the S/Kademlia counters (crypto-puzzle IDs + disjoint lookup paths), or if that's considered out of scope for the DHT."

This is one of those comments where someone hands you a full threat model in two sentences. I spent the next few days digging into it — reading the S/Kademlia paper, tracing through py-libp2p's routing code, and checking what rust-libp2p has already shipped. Here's what I found.

What my fix actually closed

PR #1338 closed the record-forgery path. Before the fix, an attacker could inject a signed PeerRecord into the DHT claiming to represent peer X — even without X's private key. The fix ties the envelope's signer identity to the record payload, so maybe_consume_signed_record now rejects any record where those don't match.

That's a real fix. But Valentyn is pointing at something it doesn't touch at all.

The attack that signing doesn't stop

Here's the thing: the eclipse/Sybil attack doesn't need to forge anything.

A libp2p peer ID is multihash(pubkey). Generating a keypair takes microseconds. There is nothing preventing anyone from generating 10,000 valid, spec-compliant peer IDs in a few seconds.

Now here's why that matters for Kademlia. Kademlia routes by XOR distance — every node's routing table stores the peers closest to it in XOR space. For any target key T, I can generate keypairs in bulk, compute each one's XOR distance to T, and keep the ones that land closest. With enough trials I get 20 IDs that cluster tighter around T than any honest node. I connect them to the network, let them bootstrap normally, and now every honest node's routing table has my attacker nodes occupying the "closest to T" slots.

From that point:

Any FIND_NODE(T) returns my nodes as the nearest
Any GET_VALUE(T) routes through my nodes first
My nodes return each other as "even closer" — it's a closed loop
The honest node has no way to detect this

And critically: every message is signed by a valid keypair. The fix I landed passes all my attacker messages just fine, because they're all authentic. The attack lives in the routing layer, not the record layer.

What S/Kademlia proposes

The S/Kademlia paper (Baumgart & Mies, 2007) defines two specific counters for this class of attack.

1. Crypto-puzzle IDs

Instead of just PeerID = H(pubkey), require that the ID also satisfies a proof-of-work constraint:

PeerID = H(pubkey)
H(H(pubkey), nonce) < D     # PoW puzzle

To generate an ID that lands near a specific target in XOR space, an attacker now has to solve 2^d extra puzzles per attempt. Minting thousands of targeted IDs goes from milliseconds to hours.

The problem: this is a dead end for py-libp2p.

libp2p peer IDs are specified uniformly across all implementations — go-libp2p, rust-libp2p, js-libp2p, nim-libp2p. They're all multihash(pubkey) with no additional constraints. If py-libp2p started rejecting peers without PoW IDs it would disconnect from every other node in the ecosystem. This needs a spec-level change with buy-in from every implementation. Not something one library can ship unilaterally.

2. Disjoint lookup paths

This one is different — and it's in scope.

Instead of one iterative lookup, run d ≥ 2 independent lookups, each starting from a disjoint partition of your initial closest-peer set:

Path 1 starts from peers [p1, p2, ..., pk/2]
Path 2 starts from peers [pk/2+1, ..., pk]
Peers discovered on path 1 are never introduced to path 2's candidate set, and vice versa
Results merge only at the end

To eclipse this, an attacker now needs to dominate both paths simultaneously. With d = 2 and bucket size k = 20, that's 40 targeted IDs instead of 20. With d = 3 it's 60. Each path multiplies the cost linearly.

The important thing: this requires zero protocol changes. It uses the existing FIND_NODE wire format. Other nodes don't need to implement it. It's a pure algorithmic change to how the lookup query is structured — which means it's entirely within the scope of a single-library contribution to py-libp2p.

Where py-libp2p stands today

I went through the routing code carefully. Here's the honest state:

Component	File	Status
Single-path iterative lookup	`kad_dht/peer_routing.py`	Implemented — one candidate set, converges on a single path
k-bucket with liveness eviction	`kad_dht/routing_table.py`	Implemented — pings oldest peer before evicting
Sliding-window ALPHA concurrency	`peer_routing.py`	Implemented — I shipped this in PR #1274
Eclipse attack simulation	`tests/examples/attack_simulation/eclipse_attack/`	Simulation only — fake string IDs, never touches the real routing table
Sybil attack simulation	`tests/examples/attack_simulation/sybil_attack/`	Simulation only — IDs are Python strings like `"peer_sybil_0"`
IP/subnet diversity in k-buckets	`routing_table.py`	Missing
Disjoint lookup paths	`peer_routing.py`	Missing
Any actual Eclipse/Sybil defense	anywhere	Missing

That last row is the one that matters. The simulation code — merged under issue #57 via PR #950 — shows what an attack looks like but doesn't implement any counter-measure. The MaliciousPeer class in malicious_peer.py creates fake IDs as Python strings; it never touches a real KBucket or RoutingTable. And issue #57 itself is still open — PR #950 never formally closed it.

The gap between "we have simulations" and "we have defenses" is exactly where the contribution lives.

What I want to build

For py-libp2p: disjoint lookup paths

The target is find_closest_peers_network in peer_routing.py. Right now it maintains one shared closest_peers list and one shared queried_peers set. All ALPHA-concurrent queries feed into the same pool. If an attacker owns the closest-k slots for a target, every round of the lookup converges deeper into the eclipse.

The change I'm planning:

Partition the initial closest-peer set into d disjoint subsets (configurable, default d = 1 to preserve current behaviour)
Spawn d parallel but isolated iterative lookups — each with its own candidate list and queried-peers tracker
No peer crosses from one path to another mid-lookup
Merge results by XOR distance at the end
Expose disjoint_paths: int = 1 on KadDHT.__init__ so users opt in to d = 2 or d = 3

Files involved:

libp2p/kad_dht/peer_routing.py — the lookup refactor
libp2p/kad_dht/kad_dht.py — expose the parameter
libp2p/kad_dht/common.py — add DISJOINT_LOOKUP_PATHS = 1

This would be the first actual eclipse mitigation (not simulation) in py-libp2p.

Secondary: IP/subnet diversity in k-buckets

In KBucket.add_peer in routing_table.py, before accepting a new peer, check whether its /24 subnet already has MAX_PEERS_PER_SUBNET entries. If yes, reject rather than evict an existing peer. This forces an eclipse attacker to control IPs across many different subnets — not just many keypairs from a single VPS.

go-libp2p enforces /16 subnet diversity. rust-libp2p currently has nothing at this level (more on that below). ~30–50 lines of Python.

What rust-libp2p has — and what it's missing

I checked rust-libp2p's Kademlia implementation while researching this, because it's the most production-hardened libp2p implementation.

The good news: rust-libp2p has had disjoint lookup paths since v0.20.0 (2020). The config flag is disjoint_query_paths(true) on libp2p_kad::Config. The number of paths equals the set_parallelism() value (ALPHA).

The bad news: it's opt-in, and almost no application enables it explicitly. More importantly, rust-libp2p has no IP/subnet diversity in kbucket.rs at all. The kbucket_inserts strategy only controls whether connected or disconnected peers are preferred — not IP locality. An attacker with a /24 full of targeted IDs faces zero additional resistance.

	py-libp2p	rust-libp2p
Disjoint lookup paths	Missing	Present, opt-in, off by default
IP/subnet diversity	Missing	Missing
Eclipse attack testbed (real nodes)	Simulation only	None

The Rust project: `kad-eclipse-guard`

Because rust-libp2p is missing the subnet diversity piece, and because I want empirical data before writing the py-libp2p PR, I'm planning a standalone Rust crate that uses rust-libp2p as a dependency.

The idea: build a real testbed that proves the attack works, shows what each defense does to the success rate, and ships a SubnetDiversityFilter behaviour that can eventually be proposed upstream.

[package]
name = "kad-eclipse-guard"
version = "0.1.0"
edition = "2021"

[dependencies]
libp2p = { version = "0.55", features = ["kad", "tcp", "noise", "yamux", "identify", "macros"] }
tokio = { version = "1", features = ["full"] }
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }
clap = { version = "4", features = ["derive"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
ipnet = "2"
rand = "0.8"
sha2 = "0.10"
libp2p-identity = "0.2"

What it builds

Targeted ID generator (src/attack/targeted_id_gen.rs)

Generates Ed25519 keypairs whose PeerId lands XOR-closest to a target key. This is the core of the attack proof — 100k keypair trials in ~200ms, take the 20 closest to target T, done.

pub struct TargetedIdGenerator {
    target_key: Key<PeerId>,
    best_n: usize,
}

impl TargetedIdGenerator {
    pub fn generate(&self, trials: usize) -> Vec<Keypair> { ... }
}

Subnet diversity filter (src/hardening/subnet_diversity.rs)

A NetworkBehaviour wrapper around libp2p_kad::Behaviour that enforces per-subnet caps at the NetworkBehaviour composition layer — no changes needed to upstream kad internals.

pub struct SubnetDiversityFilter<TStore> {
    inner: libp2p_kad::Behaviour<TStore>,
    subnet_counts: HashMap<IpNet, usize>,
    max_per_subnet: usize,   // default: 2 per /24
    prefix_len_v4: u8,       // default: 24
    prefix_len_v6: u8,       // default: 64
}

When libp2p_kad fires RoutingUpdated for a new peer, the filter checks the peer's IP subnet against subnet_counts. If the subnet is saturated, it emits RemovePeer back to the inner behaviour.

Testbed (src/testbed/network.rs)

Runs 4 configurations with real rust-libp2p nodes over TCP:

Config	`disjoint_query_paths`	`SubnetDiversityFilter`
Baseline	false	off
Disjoint only	true	off
Diversity only	false	on
Hardened	true	on

Metrics collected per config: routing table contamination ratio, lookup success rate, time-to-eclipse (TTFE).

CLI

USAGE:
    kad-eclipse-guard [OPTIONS]

OPTIONS:
    --honest-peers <N>      [default: 50]
    --attacker-peers <M>    [default: 30]
    --trials <T>            keypair generation trials [default: 100000]
    --config <C>            baseline|disjoint|diversity|hardened|all
    --output <FILE>         JSON metrics output

What this proves

The attack is cheap. 100k keypair trials → 20 targeted IDs in ~200ms. No special hardware.
Disjoint paths help but multiply rather than block. With parallelism=3 and disjoint enabled, the attacker needs 3× the IDs — still microseconds per ID.
Subnet diversity raises the cost meaningfully. Filling a bucket of 20 across /24 caps of 2 requires IPs in at least 10 different subnets — that's a real operational barrier, not a CPU barrier.
Combined is strongest. Attacker must simultaneously control many subnets AND eclipse all d independent paths.

What's off the table

Idea	Why
Crypto-puzzle peer IDs	Requires spec change + buy-in from all libp2p implementations
Reputation / trust scoring	No spec, breaks with churn, too complex to get right
Proof-of-work ID validation	Would reject every non-py-libp2p peer on the network
DHT access control	Contradicts libp2p's open-participation design

The contribution path

Build and benchmark kad-eclipse-guard with real rust-libp2p nodes — get hard numbers.
Open a rust-libp2p discussion proposing SubnetDiversityFilter as a companion behaviour or eventual built-in, backed by the testbed metrics.
Open a py-libp2p issue for disjoint lookup paths, referencing issue #57 — gauge maintainer appetite before writing code.
Once there's signal, open the PR. Disjoint paths first (higher impact, no protocol change), subnet diversity second (smaller, easier to review standalone).

Wrapping up

Valentyn's comment identified something real: the fix I shipped in PR #1338 closes one attack surface but leaves the routing layer undefended. Record authentication and routing table hardening are separate problems, and py-libp2p currently has zero actual defenses for the second one — only simulations that never touch the real KBucket.

The path forward is concrete:

Disjoint lookup paths in peer_routing.py — in scope, no protocol changes, the biggest impact
Subnet diversity in routing_table.py — smaller, modeled on go-libp2p's approach
A Rust testbed to build the empirical case first

Issue #57 has been open since 2018. It asked for attack simulation (done, via PR #950) and security assessment (not done). The actual hardening is still waiting.

Shipping Docs, Rust Tooling, and a Week of Deep Reviews

Yash Kumar Saini — Tue, 07 Jul 2026 15:01:14 +0000

14 commits, 2 PRs, 1 issue, and 5 reviews across 3 repos. This week was all about hardening my Rust CLI 'trx' with mdBook and format checks, while doing some heavy lifting on Python backend reviews for the community.

TL;DR

It’s been a solid, high-energy week. I managed to hit a 7-day commit streak, which always feels great when the flow state actually sticks. The stats tell a story of expansion: 14 commits, 2 merged PRs, and 5 deep-dive reviews. I spent most of my "writing" time in Rust, specifically getting the documentation and CI for trx into a professional state, but my "thinking" time was heavily invested in Python backend architecture through some gnarly code reviews.

WHAT I BUILT

The star of the show this week was trx, my Rust-based project. I’ve been pushing this one forward for a while, but this week I realized that code without documentation is just a riddle for my future self. I spent a significant chunk of time setting up a proper documentation site using mdBook.

If you look at the numbers, I added over 1,500 lines and only deleted about 160. Usually, I’m a fan of the "less is more" refactoring approach, but this was a pure growth week. Most of those additions were the mdBook documentation site. I wanted a place where users (and I) could actually see the vision for the tool, and mdBook is just so snappy for Rust projects. It feels right.

I also spent some time on the "boring but important" stuff for trx. I integrated format checks into the workflow. There’s nothing that kills my momentum faster than a PR that fails because of a stray space or a missing newline, so getting cargo fmt enforced in CI was a priority. It’s one of those things you do once and thank yourself for every day after.

Outside of the Rust world, I did some maintenance on my nvim config and GitBanner. For nvim, it was mostly Lua-based tweaks to keep my environment feeling fast. I’m a firm believer that your editor should evolve with your workflow, so I’m constantly pruning and grafting my config. GitBanner saw a couple of TypeScript commits as well—just keeping the lights on and ensuring everything is running smoothly.

PULL REQUESTS

I kept the PR count low but the impact high this week. Both of my PRs were in the trx repo and both are now merged.

The first was the documentation overhaul. Adding 1,281 lines of documentation might sound like a slog, but it actually helped me find a few inconsistencies in how I was thinking about the CLI's API. Writing about your code is the best way to realize where your code is confusing.

The second was the format check PR. It was a mix of 292 additions and 161 deletions. This wasn't just adding a YAML file for GitHub Actions; it was also about running the formatter across the whole codebase and cleaning up the technical debt that had accumulated while I was "just hacking." It feels much cleaner now.

ISSUES & DISCUSSIONS

I opened one new issue this week in trx: Feature: Add a update keymap option.

As I was writing the documentation, I realized that the current way I handle keybindings is a bit too rigid. I want users to be able to rebind things without having to recompile the whole world. It’s currently marked as OPEN, and it’s likely going to be my main focus for the upcoming weekend. It’s one of those features that sounds simple until you start thinking about conflict resolution and nested maps.

CODE REVIEWS

This was a heavy review week, and honestly, I love that. I gave 5 reviews, which is more than double the number of PRs I opened myself. Most of this work happened over at opensre, a project I’ve been following closely.

I spent a lot of time looking at Python code this week. One of the more interesting reviews was for a fix in the Anthropic SDK client. We were seeing some weird TypeError issues when an API key was missing, and the PR introduced a "fail fast" mechanism. I’m a huge advocate for failing fast—there’s nothing worse than a silent failure that manifests as a cryptic error ten layers deep in your stack.

I also reviewed some AWS session caching logic and a psutil probe integration. The psutil one was particularly cool—it’s wiring a background sampler into a REPL. It’s the kind of low-level systems work that makes Python feel a lot more powerful than people give it credit for.

Reviewing other people's code is such a great way to stay sharp. You see patterns you wouldn't have thought of, and you catch bugs that you’ve definitely made yourself in the past. (We’ve all forgotten to validate a host boundary at least once, right? Looking at you, PR #2009).

TECH STACK

This week was a polyglot's dream.

Rust was my primary language for building, especially with the trx work. The type safety and the tooling (like cargo fmt and mdBook) just make the developer experience so top-tier.
Python dominated my review time. Between LLM clients and AWS SDKs, I was deep in the weeds of asynchronous Python and cloud infrastructure.
TypeScript and Lua provided the glue for my personal tools and editor setup.

My add/delete ratio was heavily skewed toward additions (1573 vs 161), which makes sense given the documentation push. It wasn't a "cleanup" week; it was a "foundation" week. And hitting that 7-day streak? That’s the cherry on top. It’s not about the grind; it’s about the rhythm.

WHAT'S NEXT

Next week is going to be all about that keymap feature for trx. I want to get the configuration logic sorted so I can finally move it out of the "experimental" phase. I’m also planning to dive back into some of the open issues in the opensre repo—there’s some interesting work happening around agent reliability that I want to be a part of.

Until then, keep shipping. (And maybe run cargo fmt before you push—your reviewers will thank you).

4 min read · Generated 2026-05-17 by DevNotion

Dev log #6 Networking Deep Dives and Scaling Docs: My 30k Line Week in OSS

Yash Kumar Saini — Tue, 07 Jul 2026 14:59:01 +0000

16 commits, 13 PRs, 4 issues, and 13 reviews across 7 repos. This week was a massive balancing act between deep p2p networking fixes in Python, scaling documentation with mdBook, and a heavy rotation of SRE code reviews.

TL;DR

It’s been one of those weeks where the line count looks absolutely ridiculous on paper—nearly 30,000 additions—but the reality was a mix of high-level architectural setup and low-level bug hunting. I pushed 16 commits, opened 13 PRs, and stayed in the flow with a perfect 7-day streak. The bulk of the volume came from launching a new documentation site, but the real "brain power" went into debugging IPv6 4-tuple handling in py-libp2p and refining AI-ready structured outputs for screenpipe.

The Big Push: The Rust Book Simplified

If you look at my stats and see +29,945 lines, don't worry—I didn't suddenly become a superhuman typing machine. Most of that was the heavy lifting involved in setting up the-rust-book-simplified.

I’ve been wanting to make the Rust book more accessible, and this week I finally sat down to build the infrastructure for it. I started by setting up mdBook with a custom theme and a landing page that doesn't just look like a standard doc site. In PR #1 and PR #2, I focused on the themed landing and playground integration.

There was a bit of a learning curve with the GitHub Pages deployment—I actually had to revert and drop a test step in PR #4 because the CI was being finicky with the mdbook binary. By PR #5, I had the core content merged and the site live. It’s a net-positive week for the Rust community, and honestly, seeing those green checkmarks on a fresh docs site is incredibly satisfying.

Deep in the Networking Weeds: py-libp2p

When I wasn't playing with CSS and Markdown, I was back in my natural habitat: p2p networking. I’ve been contributing to py-libp2p for a while, and this week I hit a particularly gnarly issue with IPv6.

I opened Issue #1316 because the websocket listener was failing to bind on IPv6. The culprit? A classic getsockname() unpack error. When you're dealing with IPv4, you expect a 2-tuple (address, port). But IPv6 gives you a 4-tuple (address, port, flow info, scope id). If your code isn't expecting those extra two values, everything blows up. I submitted the fix in PR #1317, ensuring we handle the 4-tuple correctly.

I also spent some time refactoring the test suite. In PR #1315, I moved the subscribed_mesh fixture to a predicate-based readiness check. If you've ever worked on p2p tests, you know how flaky they can be—waiting for peers to discover each other and settle into a mesh is a recipe for race conditions. Moving to a predicate-based approach makes the tests much more resilient. (And yes, I also closed Issue #1314 to remove the nursery parameter from IListener.listen(), which was a long-overdue breaking change to clean up the API).

SRE Tooling and AI Contexts

Over at opensre, I was tackling a bug where Azure SQL integrations weren't being populated correctly. It’s one of those silent failures where the tools report as "unavailable" even when the config is perfect. I tracked it down to detect_sources.py and pushed a fix in PR #722.

I also had a "developer moment" with Grafana. I opened PR #786 to use relative provisioning paths in the local compose setup, realized I’d missed a side effect, and immediately had to revert it in PR #787. We've all been there—the "fix" that breaks the dev environment for everyone else. Better to revert and rethink than to leave the team stranded.

On the AI front, I’ve been working on screenpipe. I’m really excited about the Model Context Protocol (MCP) work I’m doing there. In PR #3072, I’m building out a structured output format specifically for AI consumption. The goal is to make the data coming out of screenpipe easily "digestible" for LLMs without a ton of brittle parsing logic. It’s still open, but the foundation is solid.

The Reviewer's Hat

This week was heavy on the mentorship and review side. I gave 13 reviews, which is almost a 1:1 ratio with my own PRs. Most of my time was spent in the opensre repo, helping the team move faster.

I reviewed everything from Victoria Logs integrations (PR #663) to Apache Airflow evidence gathering (PR #570). One of the more interesting reviews was PR #780, which dealt with redacting overlapping spans in guardrails. It’s a tricky logic problem—ensuring you don't leak sensitive "bookends" of data when two redacted sections overlap.

I also pushed for some better project structure, requesting changes on PR #945 to move the Notion client into a dedicated services directory. Keeping the architecture clean now saves us a world of hurt six months down the line.

Tech Stack & Vibe

This was a very Python-heavy week, but the "lines changed" tell a story of two different worlds. On one hand, I was doing high-volume work in Rust and TypeScript for the docs and AI layers. On the other, I was doing surgical, low-line-count fixes in Python and C (shoutout to the 1 commit in PiEngine—sometimes you just need to tweak one thing in the core).

My nvim config also got some love with 7 commits. No major additions there, just constant sharpening of the saw. If my editor isn't feeling right, my code doesn't feel right.

Language Mix: Python (89M bytes processed), TypeScript, and Rust.
Add/Delete Ratio: Massive additions due to the mdBook launch. It’s a "building" phase, not a "cleaning" phase.
Streak: 7 days. The momentum is real.

What's Next?

Next week, I’m focusing on getting that MCP structured output merged in screenpipe. I also want to circle back to py-libp2p and see if there are more IPv6 edge cases hiding in the other transport layers. If this week was about breadth (docs, networking, SRE, AI), next week is going to be about depth.

Catch you on the next push!

Total Commits: 16 | PRs: 13 | Issues: 4 | Reviews: 13
Streak: 7 days of shipping.

python #rust #open-source #backend #consistency · 4 min read · Generated 2026-04-26 by DevNotion

Dev log #11 Kanagawa Dreams and Test Suites: A Week of Refactoring my Neovim and Hardening the Backend

Yash Kumar Saini — Tue, 07 Jul 2026 04:30:43 +0000

Hit a perfect 7-day streak this week, splitting my time between a massive aesthetic pivot in my Neovim config and a relentless testing marathon for openslate. With 22 commits and 10 PRs, I managed to delete over 2,000 lines of code while shipping a more stable integration layer.

TL;DR

There is something deeply satisfying about a week that ends with a net-positive refactor and a perfect 7-day streak. I spent the last seven days oscillating between the purely aesthetic—tearing down and rebuilding my Neovim environment—and the purely functional—writing enough integration tests for openslate to sleep soundly at night. Between 22 commits and 10 PRs, I touched everything from Lua config files to Svelte components and network retry logic.

What I Built

The Neovim Pivot (`nvim`)

If you’re like me, your editor is a living organism. This week, I decided it was time for a major evolution. I pushed 21 commits to my nvim repo, which resulted in about 3,200 additions and 2,000 deletions. That’s a lot of churn for a config, but the result was worth it: I’ve fully pivoted to a "Kanagawa modern-minimal" aesthetic.

I spent a significant chunk of time in lua/plugins and lua/config, cleaning up my <leader> notation and ensuring the UI felt snappy. I even updated the title logo and added a site HTML file to the repo. Most of the heavy lifting was actually maintenance—I have a CI job that updates all plugins to the latest versions, and I spent a few sessions manually resolving the fallout from those updates. There’s a specific kind of peace that comes from applying whitespace and lint fixes across 42 changed files. It’s the digital equivalent of vacuuming your office; you don’t realize how much the clutter was bothering you until it’s gone.

Hardening the Core (`openslate`)

While the Neovim work was about "feel," my work on openslate was all about "fact." I’m currently in the middle of a massive testing push. Even though the commit count looks low on the main branch, the PR activity tells the real story. I’m building out a robust integration suite to cover the entire application lifecycle.

I spent a lot of time in api/src, specifically focusing on authentication. I merged a critical PR that asserts the auth middleware returns a 401 when no cookie is present—it’s a small thing, but it’s the foundation of the whole security model. I also have several open PRs right now that cover the signup and signin flows, ensuring that the first user created actually gets the correct cookie back.

One of the trickier parts of the week was working on the build_fts_query logic. Full-text search (FTS) is always a bit of a nightmare when it comes to wildcard and quoting rules. I opened a PR specifically to test those edge cases because I noticed some weird behavior when users tried to search with special characters. Better to catch that in a test suite than in a bug report.

Pull Requests & Pipeline Fixes

This was a heavy PR week. I opened 10 in total, and they really represent the "breadth" of my current projects.

Over at opensre, I tackled a frustrating UI bug. I noticed that the interactive shell loading bar wasn't spinning while the LLM was doing its investigation. There’s nothing worse than staring at a static screen wondering if the backend has died or if it’s just thinking. I submitted a fix with about 150 lines of changes to ensure the progress state is correctly reflected in the terminal. Even though that PR is currently closed, the investigation into why the state wasn't bubbling up was a great deep dive into the shell's event loop.

I also spent some time on DevNotion (the very tool I'm using to track this!). I opened a PR to handle transient network errors during the "harvest" phase. When you're pulling data from multiple APIs, something is bound to flake out. Adding a retry strategy and a secure deployment plan (about 800 lines of new code) makes the whole system feel much more "production-ready" and less like a weekend hack.

The Tech Stack & The Streak

Looking at the language breakdown for the week, it’s a bit of a polyglot explosion. While Lua dominated my commit count because of the Neovim refactor, the actual logic was spread across TypeScript, Svelte, and a bit of Python.

The additions-to-deletions ratio (3226 vs 2063) is exactly where I like it to be during a refactor week. It shows that I’m not just piling on new features; I’m actively removing the old, brittle parts of the codebase to make room for the new stuff.

And then there’s the streak. Seven straight days of commits. It wasn't a forced grind; it was just one of those weeks where every time I sat down, there was something clear and actionable to do. Whether it was a 2am tweak to a Kanagawa color highlight or a mid-afternoon integration test for a media MIME filter, the momentum stayed high.

What's Next

Next week is all about closing the loop. I have a mountain of open PRs in openslate—everything from the command palette styling to the media DB filters. My goal is to get the integration test suite merged so I can start building out the next set of features on top of a "green" CI pipeline.

I’m also planning to dive deeper into the DevNotion harvest logic. Now that the retry strategy is in place, I want to see if I can optimize the data fetching to be a bit more parallel.

Until then, I’ll be enjoying the new, minimal look of my editor. It’s amazing how a fresh coat of paint can make you want to write another thousand lines of code. See you all 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

Dev log #10 The Power of the Zero-Commit Week: Stepping Back to Move Faster

Yash Kumar Saini — Fri, 03 Jul 2026 04:49:00 +0000

A rare week of total radio silence on GitHub—no commits, no PRs, and zero green squares. Sometimes the best thing for a codebase is for the developer to step away from the keyboard and focus on the bigger picture.

TL;DR

If you looked at my GitHub contribution graph for this past week, you’d see a whole lot of nothing. Zero commits, zero pull requests, and a broken streak. It wasn't a failure of productivity, but a conscious choice to trade the keyboard for a whiteboard and some much-needed headspace; I finished the week with 0 lines added and 0 lines deleted, but a much clearer roadmap for what's coming next.

The Sound of Silence

I’ve always been a bit of a "green square" addict. As a freelancer and active open-source contributor, there’s a certain dopamine hit that comes with shipping a PR or seeing a complex CI pipeline finally turn green. But this week, for the first time in a long while, I didn't touch a single repository.

There’s a specific kind of pressure that comes with being deep into p2p networking and backend tooling. When you're contributing to projects like libp2p or maintaining your own CLI tools, the "to-do" list never actually ends. There is always a dependency to bump, a bug to triage, or a refactor that's been nagging at the back of your brain. However, I’ve learned the hard way that if you don't intentionally schedule a "zero week," your brain will eventually schedule one for you in the form of burnout.

This week was about breaking the cycle of reactive coding. Instead of jumping into the src directory of my latest Python API or wrestling with borrow checker errors in my Rust crates, I spent my time reading, planning, and—dare I say it—resting.

Reflecting on the Stack

Even though I didn't push code, looking at my language distribution gives a pretty clear picture of where my head is usually at. My local environment is a graveyard of half-finished experiments across a massive range of technologies.

Python remains my heavy hitter, sitting at over 100MB of source code across my various projects. It’s my go-to for data pipelines and AI backend work because of the sheer speed of iteration. But when I’m looking for safety and performance, especially in the p2p space, I’m almost always reaching for Rust or TypeScript. Seeing nearly 12MB of Rust and 16MB of TypeScript in my stats reminds me of the shift I've made lately toward more memory-safe, robust systems.

I also noticed a significant amount of Nix, Lua, and even some OCaml and Nim in my historical data. It’s a reminder that being a developer isn't just about the code you write today; it's about the cumulative knowledge of all the paradigms you've explored. This week, instead of writing more Python, I spent time reading through some OCaml documentation and exploring how different languages handle concurrency. It’s the kind of "invisible work" that doesn't show up on a contribution graph but fundamentally changes how I'll approach my next PR.

The "Invisible" Work

We often talk about "shipping" as the only metric that matters. But what about the work that happens before the first line of code is written?

I spent a good chunk of this week thinking about architecture. I have a few open ideas for some CLI tools that help with developer experience (DX), and I realized that if I had started coding them on Monday, I would have built them the wrong way. By stepping back, I realized I was over-complicating the state management. I didn't need a complex database; I needed a simple, flat-file structure that stayed out of the user's way.

This is why I’m not sweating the 0% merge rate or the lack of reviews this week. As a developer, your value isn't just in your ability to type; it's in your ability to solve problems. Sometimes, the best solution is the code you decide not to write.

Tech Stack & Consistency

Usually, I’m bragging about a 7-day streak or a high review-to-PR ratio. This week, the streak is at zero.

Language Mix: My history is polyglot by nature. While Python, Rust, and TypeScript dominate the byte count, the presence of things like Solidity, Go, and even some C++ shows the breadth of the projects I’ve touched.
Add/Delete Ratio: 0/0. It’s a perfect balance, if a bit boring.
Review Balance: No reviews given, no reviews received. This was a week of total internal focus.

It feels strange to see "0 commits" at the top of a dev log, but I think it’s important to be honest about it. We aren't machines. We don't just produce code at a constant rate until we're decommissioned.

What's Next

The "rest" phase is officially over. My brain is already starting to itch for a terminal window.

Next week, I’m planning to dive back into the TypeScript and Rust side of my portfolio. I have some ideas for hardening a few SDKs I've been working on, and the architectural clarity I gained this week is going to make that process much smoother. I’m also looking at some of the issues I left hanging in my Python repos—now that I’ve had a break, the solutions to those "impossible" bugs are starting to feel a lot more obvious.

To anyone else feeling the pressure of the empty contribution graph: it’s okay to have a quiet week. The code will still be there on Monday. The goal isn't to have the most green squares; the goal is to build things that actually matter, and sometimes that requires stepping away from the screen.

See you all in the commit logs 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

Dev log #9 Hardening Kademlia DHT and automating the Neovim grind

Yash Kumar Saini — Fri, 03 Jul 2026 03:48:03 +0000

Seven days of flow. Fixed a peer identity binding issue in py-libp2p, automated my Neovim lockfile merges, and added a massive batch of notes on xv6 and Category Theory. 10 commits and a solid PR in the works.

TL;DR

I managed to hit a perfect seven-day streak this week, balancing some deep-dive p2p networking work with necessary maintenance on my local environment. The highlight was opening a PR in py-libp2p to tighten up how PeerRecords are handled in the Kademlia DHT. On the side, I spent time automating the annoying parts of my Neovim config and dumping a fresh batch of notes into my knowledge base. 10 commits, 204 lines added, and a much cleaner workflow to show for it.

What I Built

Neovim Configuration & CI

I’m a firm believer that your editor should work for you, not the other way around. My nvim repo saw a lot of action this week—9 commits in total—but most of it was under-the-hood maintenance. I’ve been leaning on Lua to keep things snappy, and this week was about ensuring my plugin ecosystem doesn't rot.

I pushed several updates to keep plugins at their latest versions, but the real "quality of life" improvement was adding a chore to auto-resolve lazy-lock.json merge conflicts. If you’ve ever worked on your Neovim config across multiple machines, you know the headache of the lockfile drifting. I set up a flow to prioritize incoming changes, which saves me from manually triaging JSON diffs every time I pull from dev. It’s a small tweak, but it removes a recurring friction point in my daily flow. I also spent time cleaning up the root of the config, with about 37 additions and 33 deletions—refactoring is a constant process when you live in your terminal.

The Knowledge Base

I also put some serious time into main-notes. I’m currently going deep on a few different subjects, and I use this repo as my "second brain." I added 167 lines of new material across 13 files, covering a pretty diverse range of topics: xv6 (the re-implementation of Unix V6), Category Theory, HQSE, and the Rust Handbook.

Writing notes for xv6 is always a trip because it forces you to think about the C-level reality of operating systems. It’s a nice contrast to the high-level Python and TypeScript work I do during the day. Most of these additions were in the Books and Books/Covers directories, effectively building out a digital library that I can reference whenever I’m stuck on a systems design problem.

Pull Requests

The most significant piece of code I wrote this week is currently sitting as an open PR in py-libp2p. I've been looking at how we handle the Kademlia Distributed Hash Table (DHT), specifically regarding security and record integrity.

The PR, titled fix(kad-dht): bind signed PeerRecord to its signer identity, addresses a subtle but important issue in how peer records are validated. In a p2p network, you can’t just trust data because it exists; you have to verify the source. By explicitly binding the signed PeerRecord to the identity of the signer, we’re making the DHT more resilient against certain types of spoofing or stale data propagation. It was 103 lines of Python that touched the core logic of the DHT implementation. It’s still open for review, and I’m looking forward to the feedback from the other libp2p contributors. There’s something uniquely satisfying about contributing to the foundational layers of the decentralized web.

Tech Stack

This was a polyglot week, as is usually the case when you're jumping between open-source contributions and personal tooling.

Python: This was the heavy lifter for the libp2p work. Python remains my go-to for quick prototyping in the p2p space, even if the eventual goal is often a Rust or Go implementation.
Lua: Purely for the Neovim environment. Lua’s integration into the Nvim ecosystem has made it so much easier to build custom logic for things like that lockfile auto-resolution I mentioned earlier.
C: This showed up in the context of my xv6 notes. Even when I’m not writing production C code, reading and documenting it is essential for keeping my systems knowledge sharp.
The Numbers: I added 204 lines and deleted 33. It wasn't a massive "tear it all down" refactoring week, but rather one of steady growth and precise fixes.

The 7-day streak is what I’m most proud of, though. It wasn’t about grinding out 12-hour days; it was about showing up every single day to move the needle, whether that was a complex p2p fix or just documenting a chapter of a book I’m reading.

What's Next

Next week, I’m hoping to get that py-libp2p PR merged. Once that’s landed, I want to look at more edge cases in the Python DHT implementation—there’s always more to harden. I’m also planning to dive deeper into the Category Theory notes. It’s abstract stuff, but the more I read, the more I see how those patterns emerge in functional programming and API design.

On the tooling side, my Neovim config feels stable for now, but I might look into optimizing my CI pipeline further to handle plugin updates more gracefully without cluttering my commit history. Until then, I'll be in the terminal. See you on GitHub!

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 #8 Hardening the Orchestrator: A Week of Making dev-publish Resilient

Yash Kumar Saini — Fri, 03 Jul 2026 03:47:12 +0000

Spent the week deep-diving into my dev-publish tool, focusing on durability and orchestrator resilience. 21 commits across two repos, with a massive cleanup of the publishing logic and some much-needed architecture documentation.

TL;DR

There is a specific kind of satisfaction that comes from taking a tool you use every day and finally giving it the "production-grade" treatment it deserves. This week was exactly that. I spent most of my time in the guts of dev-publish, moving past the "it works on my machine" phase and into "it works even if the world is on fire" territory. With 21 commits and over 11,000 lines of code churn, I focused on making the publishing orchestrator resilient and the state durable.

What I Built

The star of the show this week was dev-publish. If you’ve ever tried to automate cross-platform technical writing, you know that the edge cases are where the real pain lives. I pushed 16 commits here, touching about 45 files. The diff was pretty wild: +6,926 additions and -4,289 deletions. That net positive tells part of the story, but the deletions represent me ripping out brittle logic that just wasn't cutting it.

Hardening the Orchestrator

The biggest win was a massive fix to make the publish state durable and the orchestrator resilient. In the previous iteration, if a network request to an API (like Dev.to) failed halfway through a multi-platform push, the state was... let's just say "vague." I spent a lot of time in src ensuring that the orchestrator can now pick up where it left off. I also documented the published-flag semantics and re-run resilience in the README. It sounds like a small thing, but knowing that a re-run won't accidentally double-post your article is a huge weight off my mind.

I also spent some time on the "boring but important" stuff. I normalized how tags are handled to make them safer across different platforms and implemented a much stricter resolution for cover images. If a local image is required but missing, the tool now yells at you immediately rather than failing silently mid-upload.

One of my favorite commits this week was refactor: drop unused assetsDir config. There is nothing quite like the feeling of deleting configuration options that you realized were over-engineered and unnecessary. It keeps the surface area small and the DX (developer experience) clean.

Architecture and Docs

I’m a firm believer that if you can't draw it, you don't understand it. I spent a chunk of time in docs/diagrams and actually embedded an architecture diagram directly into the README. It helps me visualize the flow between the local markdown files, the image resolver, and the final API calls.

I also did a specific dive into the Dev.to integration. I added better validation for their API responses and exposed a properly typed error system. No more guessing why a request failed—now I get a clear, typed reason that the orchestrator can actually act upon.

Keeping the Saw Sharp

Outside of the heavy lifting on dev-publish, I spent a bit of time on my nvim config. This wasn't anything groundbreaking—mostly just keeping the environment healthy. I have a set of CI workflows that update all my plugins to the latest versions. It’s five quick commits that keep my editor snappy and ensure I’m not missing out on any new features or bug fixes in the Lua ecosystem. It’s the digital equivalent of cleaning your desk at the end of the day.

Pull Requests & Issues

You might notice there are zero PRs this week. Since I’m the primary driver on these specific projects right now, I’ve been pushing directly to the main branches to keep the velocity high. It’s a bit of a "move fast and fix things" approach, but since I’m also the one writing the tests and the docs, the quality bar stays where it needs to be. No issues opened or discussions started either—just pure, unadulterated flow state.

Tech Stack

This was a very TypeScript-heavy week. When you're building CLI tools and orchestrators, the type safety of TS is basically a superpower. Being able to define exactly what a "PublishState" looks like and having the compiler yell at me when I forget an edge case is the only way I stay sane.

The line count this week was pretty high (+6,935 / -4,298), which usually signals a mix of new feature work and heavy refactoring. I managed to maintain a 3-day streak, which felt good. It wasn't a "grind" week, but rather a few days of deep, focused work where I could really get into the zone.

Even though my total language profile shows a massive amount of Python and Rust from past projects, this week was all about the TypeScript and Lua. It’s a reminder that as a dev, your "current" stack is often just whatever tool is best for the problem you're solving right now.

What's Next

Now that the orchestrator in dev-publish is stable and the state is durable, I want to start looking at expanding the platform support. The foundation is there, the architecture is documented, and the error handling is typed.

I’m also keeping an eye on my Neovim setup. Those automated plugin updates sometimes introduce small breaking changes in the Lua APIs, so I might need to spend a morning next week tweaking my init.lua to accommodate any upstream shifts.

It was a solid week of building. Nothing beats the feeling of seeing a tool you built yourself get faster, stronger, and more reliable. Catch 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 #15 Refining the Craft: A week of Neovim UI hacking and portfolio architecture

TL;DR

What I Built

nvim (The Editor Overhaul)

portfolio (Restructuring the Narrative)

Pull Requests

Tech Stack & Stats

What's Next

Dev log #14 Hardening the DHT against Eclipse attacks and the endless battle with flaky p2p tests

TL;DR

The Fight for a More Secure DHT

The Tax of Asynchronous Testing

Maintenance and Tooling

Tech Stack & Vibe

What's Next

Dev log #13 Hardening Kademlia: A week of p2p security architecture and Neovim maintenance

TL;DR

WHAT I BUILT

py-libp2p

nvim

ISSUES & DISCUSSIONS

TECH STACK

WHAT'S NEXT

Dev log #12 Hardening WebRTC and Polishing the UI: A Week of Networking and Refinement

TL;DR

WHAT I BUILT

Portfolio & Personal Branding

The Maintenance Grind

PULL REQUESTS

Deep Diving into WebRTC (py-libp2p)

Documentation DX

CODE REVIEWS

TECH STACK

WHAT'S NEXT

Adding WebRTC to py-libp2p: Two Runtimes, Three Specs, and One Unforgiving Private Slot

A quick honest note before we start

The problem: why a Python libp2p wants WebRTC at all

What actually landed

Architecture in one picture

Deep dive #1 — framing, or "why bare protobuf was the wrong wire"

Reason 1: SCTP has a 16 KiB message ceiling

Reason 2: bare protobuf isn't self-delimiting inside a stream frame

Deep dive #2 — the certificate pin that actually pins

Setting the scene

The naïve pin

The fix

The canary

Deep dive #3 — bridging two runtimes without blowing up

Deep dive #4 — Noise XX, but bound to DTLS

Deep dive #5 — signaling, ICE_DONE, and a spec fix in flight

The seam that will save us a rewrite: _apply_ice_credentials()

Testing: 153 tests, but only one of them mattered

What the review looked like from the inside

Where it goes next

The one takeaway I want you to leave with

Try it, and honest expectations

References

Hardening Kademlia DHT: The Eclipse Attack That Record Signing Doesn't Stop

Hardening Kademlia DHT: The Eclipse Attack That Record Signing Doesn't Stop

What my fix actually closed

The attack that signing doesn't stop

What S/Kademlia proposes

1. Crypto-puzzle IDs

2. Disjoint lookup paths

Where py-libp2p stands today

What I want to build

For py-libp2p: disjoint lookup paths

Secondary: IP/subnet diversity in k-buckets

What rust-libp2p has — and what it's missing

The Rust project: kad-eclipse-guard

What it builds

What this proves

What's off the table

The contribution path

Wrapping up

Shipping Docs, Rust Tooling, and a Week of Deep Reviews

TL;DR

WHAT I BUILT

PULL REQUESTS

The seam that will save us a rewrite: `_apply_ice_credentials()`

The Rust project: `kad-eclipse-guard`

The Neovim Pivot (`nvim`)

Hardening the Core (`openslate`)