DEV Community: Yash Kumar Saini

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 log #7 Reviving DevNotion: 10,000 Lines, Multi-LLM Support, and the Road to v2.1

Yash Kumar Saini — Tue, 23 Jun 2026 15:14:06 +0000

Spent the week breathing new life into DevNotion—59 commits and over 10,000 lines of code later, v2.1 is officially alive. It was a massive push toward multi-LLM support and public-facing dashboards, keeping a steady 6-day streak in the process.

TL;DR

I spent the week breathing new life into DevNotion—59 commits and over 10,000 lines of code later, v2.1 is officially alive. It was a massive push toward multi-LLM support and public-facing dashboards, keeping a steady 6-day streak in the process.

What I Built

Most of my energy this week went into a massive revival of DevNotion. I’ve been sitting on some ideas for a while, but this week I finally sat down and tore into the codebase to bring v2 and v2.1 to life. We’re talking 150 files changed and a delta of +10,199/-3,768 lines. That’s a lot of TypeScript, but the result feels like a completely different beast.

The core of the work was moving toward a more robust, multi-LLM architecture. I wanted the ability to flip between models and handle the preview-to-publish flow more gracefully. I spent a significant chunk of time in src/server rebuilding how we handle sessions and public access. One of the more satisfying bits was implementing a global brute-force backstop for the auth layer—it’s one of those "peace of mind" features that you don't realize you need until you're actually looking at a public deploy.

Speaking of public deploys, I spent some time in the root directory getting the project ready for the real world. I wrote a proper Dockerfile and set up a Render blueprint. I also had to make sure the app honors the platform’s $PORT environment variable (classic "it works on my machine but fails in the cloud" moment).

The dashboard also got a major overhaul. I added a public view and implemented token-gated actions for publishing, running, and deleting content. It makes the whole "dashboard as a service" feel much more real. I even took a moment to "un-mangle" the .gitignore because my patterns for .remember/ and the masterplan were getting a bit messy.

On a much smaller scale, I kept my nvim config fresh. Nothing ground-breaking there—just five quick commits to keep all my plugins updated. It’s a small ritual, but keeping the tools sharp is half the battle when you're doing 10k-line weeks.

Pull Requests

The centerpiece of the week was definitely PR #1 in DevNotion: "DevNotion v2 + v2.1 — multi-LLM, preview→approve publishing, images, dashboard & landing."

Merging this felt like a massive weight off my shoulders. It wasn't just a feature update; it was a total revival. It introduced the multi-LLM logic, the new image handling, and the entire landing page. With over 8,000 additions in this single PR, it was basically the foundation for everything I’m planning next. Merging it on Saturday was the perfect way to cap off the week's momentum.

Tech Stack

This was a TypeScript-heavy week, no doubt about it. When you're building out complex dashboard logic and server-side auth, TS is just non-negotiable for me. I also spent some time with Lua for my editor config and a bit of Dockerfile/Shell work to get the deployment pipeline smoothed out.

The line count this week is pretty wild—over 10,000 additions. Usually, I'm a big fan of "deletion weeks" where I refactor and prune, but this was a week of pure creation. I was building out net-new features and expanding the scope of the project, so the heavy addition-to-deletion ratio feels right for where the project is at.

I also managed a 6-day streak. I missed the perfect 7-day run by a hair, but honestly, the flow was so good that it didn't feel like a grind. When you’re deep in the "revival" phase of a project you care about, the commits just kind of happen.

What's Next

Now that the v2.1 foundation is merged and the Docker/Render setup is live, I’m looking at the docs. I’ve already started updating the README with new architecture diagrams (swapped out some old Mermaid flowcharts for something a bit cleaner) and fresh dashboard images.

Next week, I want to battle-test the public view logic. Now that the token-gated actions are in place, I want to see how it holds up under some actual usage. There’s also some more work to do on the "masterplan" (now that I’ve fixed the gitignore for it!). I'm feeling really good about the direction DevNotion is heading—it’s finally starting to match the vision I had in my head months ago. 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

I Revived DevNotion (multi agent blog workflow) — And Finally Perfected it

Yash Kumar Saini — Sat, 06 Jun 2026 13:58:54 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Every Monday standup, someone asks: "What'd you ship last week?" And every Monday I freeze. Did I merge that PR Tuesday or Wednesday? Was the gnarly part in the harvest code or the publisher? I'd sit there scrolling my own commit history like it belonged to a stranger.

So back in March I built something to answer the question for me. DevNotion — a Mastra pipeline that reads a week of my GitHub activity, writes it up as a first-person blog post, and ships it to Notion and DEV.to. It won $500 in the Notion MCP Challenge. Then I did what everyone does with a hackathon project: nothing, for two months.

Here's the thing, though. It worked, but I never fully trusted it. One LLM, no say in it. It published the instant it finished writing — no preview, no edit, no "hang on, let me read that first." And when I opened the repo back up for the Finish-Up-A-Thon, the very first run failed in the most embarrassing way I can think of. Honestly? Best thing that could've happened. It showed me exactly what "finish this" was supposed to mean.

DevNotion v2 is the version I should've shipped the first time. It writes a draft, shows it to me, lets me edit it, and only publishes when I say go. Multiple LLM providers. Three publishing targets. A deterministic cover image, much better data, a real test suite. Seven phases, 51 tests, a one-command setup wizard — and, most of all, a failure mode that protects my name instead of betting it.

One idea ran under the whole rebuild: a tool that writes in your voice and posts under your name has to be trustworthy before it gets to be convenient.

Demo

Repo: github.com/yashksaini-coder/DevNotion

yashksaini-coder / DevNotion

DevNotion is an agentic server built using 3 mastra agents to work as a pipeline to publish weekly blogs on Notion Pages & DEV.to

DevNotion

Turn your weekly GitHub activity into a polished, illustrated blog post — narrated by an LLM, reviewed by you, and published to Notion, DEV.to, and Hashnode.

DevNotion is a Mastra pipeline of specialist agents: it harvests a week of your GitHub work, narrates it into a first-person post, generates images, and lets you preview/edit before it publishes anywhere. Originally built for the DEV.to × Notion MCP Challenge (where it won $500); v2 was rebuilt for the GitHub Finish-Up-A-Thon with multi-LLM support, a review dashboard, image generation, richer harvesting, and a fail-safe publishing flow.

What's new in v2

v1	v2
LLM	Gemini only	Gemini · OpenAI · Anthropic (provider abstraction; default `gemini-3-flash-preview`)
Publish targets	Notion + DEV.to	Notion + DEV.to + Hashnode
Flow	generate → publish immediately	generate → preview → edit → approve → publish
UI	none (CLI/cron)	web dashboard (trigger, preview, edit, history)
Images	none	deterministic stats

…

View on GitHub

Three specialist agents, with generation and publishing deliberately split by a human approval gate:

Each agent does one thing and only one thing. Harvest is pure data — two quick GraphQL/REST passes over the week, no LLM anywhere near it. Narrate is the single model call: raw data goes in, a first-person post comes out, in whatever tone you picked. Publish is plumbing — a Notion page, a DEV.to draft, a Hashnode draft if you've set it up, plus the cover and the footer. And right in the middle, between writing and shipping, there's a human. That gate is the whole reason v2 exists.

The rule I kept from v1: an LLM only shows up where it earns its spot. Harvesting the data, drawing the stats card, pushing to each platform — that's all plain deterministic code. No tokens, no rate limits, no chance of the thing inventing a number. The model writes the prose. Everything around it is code I can unit-test. That's the only reason I'm comfortable letting it post under my name without re-reading every figure first.

In practice it's quick. I kick off a run (scheduled, or by hand from the dashboard) and a few seconds later there's a draft sitting there marked Preview Ready. Not published. I read it, fix a sentence or two right in the browser, hit Approve & Publish. Then it goes out — and even then it goes out as a draft on each platform, not a live post.

The Comeback Story

Where v1 actually was

I genuinely thought I'd left v1 in decent shape. The first run set me straight in about four seconds:

Narrate step: LLM call failed: You exceeded your current quota …
  limit: 0, model: gemini-2.0-flash
Publish: Created Notion page: https://app.notion.com/…
Publish: Published DEV.to article: https://dev.to/…

Read it twice. The narration failed — and the thing published anyway. v1 had this well-meaning "always produce a blog" fallback, so a quota error quietly shipped a bare stats stub to my real DEV.to account. For a tool whose entire job is to represent my work? That's about the worst thing it could possibly do.

That one log was hiding three separate bugs:

Wrong model, wired to nothing. The live workflow read a different config key than the one I'd been carefully setting. So it quietly fell back to a retired gemini-2.0-flash, whose free quota is now 0. I'd been turning a knob connected to thin air.
The failure was silent. A try/catch swapped in a deterministic stub and marched straight on to publishing.
Nothing ever let me look. No preview, no gate, no pause before it went live.

And a sneakier one underneath all that: a week with 13 direct commits reported +0/-0 lines changed, because line stats were summed from pull requests only. The posts came out technically accurate and completely dead.

What actually bothered me wasn't any single bug. It was that the worst one was the helpful one. That try/catch-into-a-stub got added in v1 on purpose, to guarantee a post always shipped. And that good intention is exactly what turned a recoverable quota error into a published embarrassment. Turns out "always succeed" is the wrong goal for something that talks for you. "Never lie" is the right one.

So I rebuilt it in seven phases. Each one got a quick spec, a plan, the actual work, a review, and a green test run before I let myself start the next. Not ceremony — it's the fail-loud rule pointed at my own process. Every phase had to prove itself (types clean, tests green) before anything got stacked on top, so nothing could quietly rot three phases deep. Here's how it went.

Phase 1 — Make narration trustworthy

First, one place to choose the model, defaulting to gemini-3-flash-preview (which, unlike the thing it replaced, actually has a free tier). Then the part that matters most — narration that fails loud:

// src/llm/narrate.ts
// FAIL-LOUD: throws on provider error or unparseable output. NEVER returns a
// deterministic fallback — the caller decides what to do with a failure.
export async function narrateBlog(provider, data, opts = {}) {
  const system = buildNarratorSystemPrompt(opts.tone ?? 'casual', opts.focusAreas);
  const prompt = `Generate a blog post from this GitHub contribution data:\n\n${JSON.stringify(data, null, 2)}`;

  const text = await provider.generate(prompt, {
    system,
    maxTokens: opts.maxTokens ?? 8192, // Gemini 3 is a thinking model — small budgets starve the answer
  });

  const parsed = parseFrontmatter(text);
  if (!parsed.success) throw new Error(`Narration failed: ${parsed.error}`);
  return parsed.data.blog;
}

If narration throws, the step throws, the run is marked failed, and the publish step never runs. A quota error can't reach a single reader anymore. (The old deterministic builder is still in there — but now it's a manual escape hatch you reach for on purpose, never something that fires on its own.)

Trustworthy also meant not living and dying by one vendor's quota. v1 was Gemini or nothing. v2 runs every call through a tiny provider interface, so an outage or a quota wall is a config change instead of a rewrite:

// src/llm/provider.ts — one interface, three interchangeable backends
export function createProvider(env: Env): LLMProvider {
  switch (env.LLM_PROVIDER) {
    case 'openai':    return createOpenAIProvider(env);
    case 'anthropic': return createAnthropicProvider(env);
    default:          return createGeminiProvider(env);
  }
}

The Gemini side also rotates through a comma-separated list of keys (keys[keyIndex++ % keys.length]). Three free keys gets you somewhere around 1,500 requests a day between them, which is plenty for a weekly run plus a day of messing around. Swapping the whole brain of the pipeline is one env var now.

Phase 2 — Split generate from publish

This was the keystone, and it's the reason v1 never had a preview to begin with. The old workflow welded harvest → narrate → publish into one chain, and that chain's output schema dropped the blog body on the floor. There was nothing to preview because the content never survived the handoff between steps. The smoking gun was the workflow's own output type: it carried URLs and counts and no content field at all. You can't bolt a preview screen onto something that throws the draft away. So splitting it wasn't a nice-to-have stacked on v1. It was the thing that had to happen before anything else could.

v2 cuts the pipeline in half. A generate phase makes a full, previewable draft and stops. A separate publish step runs only when you approve, edits and all:

// src/server/routes/run.ts
// POST /run  → generates a draft, stores it, sets status "preview". Publishes NOTHING.
// POST /publish/:jobId → applies your edited markdown, then calls publishBlog().

That one cut bought three things at once: a safe failure mode, an editable preview in the browser, and run history that finally shows what actually got written. And the publisher turned into a single function that both the dashboard and the cron job call:

// src/publish/publish-content.ts — one publisher, used by cron AND the dashboard
export async function publishBlog(opts: {
  blog; weeklyData; publishMode: 'auto' | 'draft';
  images?: { statsCardPath?: string };
}): Promise<PublishResult> { /* notion → devto → hashnode → write planner + footer */ }

Tying it together is a little JSON-backed run store that's basically the pipeline's state machine. Every run walks a fixed path — running → preview → publishing → published, or failed — and that one record is what the dashboard lists, what the preview renders from, and what publish reads back when you hit approve. It's also where the Dev log #n counter lives, so the numbers stay in order whether a post came from the dashboard or the cron job. One ledger, two doors in.

Phase 3 — Harvest the real diff

The +0/-0 bug is dead. A second, bounded GraphQL pass walks each active repo's commits — real additions and deletions, changed-file counts, and the directories you actually touched — so the narrator can talk about specifics instead of waving its hands. That same week that used to report nothing now says:

week 2026-05-27 → totals +2,252/-293
- DevNotion:        +2,220/-282, files=25, areas=[src/server, src/tools, bin]
- yashksaini-coder: +24/-3,      files=5,  areas=[assets, .github/workflows]

It's quota-safe on purpose: hard caps on how many repos and commits it'll look at, and every commit wrapped in its own try/catch so one bad fetch can't sink the whole week:

// src/tools/github-commits.ts — bounded, best-effort changed-file harvest
for (const sha of shas) {
  try {
    const res = await fetch(`https://api.github.com/repos/${owner}/${name}/commits/${sha}`, { headers });
    if (!res.ok) continue;
    for (const f of (await res.json()).files ?? []) paths.push(f.filename);
  } catch {
    // skip this commit on any error — never sink the whole week
  }
}

Two passes, on purpose. GraphQL is great for breadth — a whole week across a pile of repos in one query. The per-commit file lists come from a few targeted REST calls instead, each one cheap and each one isolated. This was the single thing v1's readers kept telling me: commit titles are cryptic, the diff is where the story actually is. Now it's in there.

Phase 4 — Sharper writing + an author footer

I tightened the narrator's instructions. Lead with a character or a moment, not a stat line. A hard no stat-dumping rule — the numbers live on the card, the prose doesn't need to recite them. And lean on the new touched-areas data, so a post can say "a week deep in src/server" instead of "made several changes." You still get to pick the tone — casual, professional, technical, storytelling — but those rules hold no matter which one you choose. Then I gave every post, on every platform, the same author footer, built from one config file:

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

[GitHub] · [X] · [LinkedIn] · [Portfolio]

It gets stamped on at publish time, not written by the narrator. So you can't accidentally delete it in the preview, and Hashnode gets it for free.

You can see the difference in the titles. One real run opened with "Bridging the Gap: TLS Interop, p2p Hardening, and Neovim Refinement" — pulled straight out of the directories I'd been living in that week. Not "This week I made 35 commits." That's what the touched-areas data buys you.

Phase 5 — The cover image

My first instinct was the obvious one: an AI cover. Nano Banana (gemini-2.5-flash-image), prompted off the week's headline. I wired the whole thing up… and found out the free tier gives image generation a quota of limit: 0. It never produced a single cover. So I was carrying a flaky, rate-limited dependency that did, in practice, nothing.

So I ripped it out and used something I already had. The stats card — a hand-built SVG rendered to PNG with @resvg/resvg-js, showing the week's exact numbers — happens to already be 1200×630, which is cover/OG size. So I just made it the cover:

// src/images/stats-card.ts — the numbers come from code, never from a model
const stats = [
  [fmt(data.totalCommits), 'commits'],
  [`+${fmt(data.totalAdditions)}`, 'added'],
  [`-${fmt(data.totalDeletions)}`, 'removed'],
  // …
];

It leads with the post title and the headline numbers (commits, PRs, reviews, lines, repos) and becomes the cover everywhere: DEV.to's main_image, the Hashnode cover, the Notion page cover. The Dev log #n bit stays on the article title, not the card, so the banner is all title and stats, and a long title wraps instead of running off the edge. Because the card is built from code, no model can ever round 2,252 down to "about 2,000." And here's the bit I liked: ripping out the AI cover made the feature more reliable, not less. It went from never working to always working in the same commit that deleted code. No API, no quota, no fallback path. It just renders.

Phase 6 — A dashboard worth screenshotting

My three dashboard routes had quietly drifted into three slightly-different stylesheets. I pulled them back into one design system — shared tokens, one shell, shared components — and gave it a deliberate Swiss / International Typographic feel: tight type scale, one orange accent, lots of breathing room. It's all server-rendered HTML, no build step, straight through tsx, which keeps the footprint tiny and the dependency list short. Most of the effort went into the preview/edit screen, because honestly that screen is the product. It's where you read the draft, tweak a line, and decide to ship.

Phase 7 — Tests

51 tests across 18 suites now cover the frontmatter parser, the fail-loud path, the deterministic fallback, tag normalization, provider and model selection, publish-target selection, the diff aggregation, and the stats-card builder (cover title-strip and wrap included). They run in under two seconds and they're deliberately boring. The point isn't cleverness — it's a regression net under the deterministic spine, so something like swapping out the cover implementation can't quietly break publishing.

Setup in one command

v1's setup was a .env scavenger hunt: copy the example, guess which keys you actually need, find out you missed one when a run blows up halfway through. npx devnotion init is a wizard instead. It asks for each credential, checks it with a live API call (green check or red error, right there in the terminal), and writes a clean .env.local. Small thing. But something that calls itself finished shouldn't make the first five minutes the worst five.

Before vs after

	Before (v1)	After (v2)
Failure mode	silently published a stub	fail-loud — publishes nothing
Review	none — instant publish	preview, edit, approve
LLMs	Gemini only	Gemini / OpenAI / Anthropic
Publish targets	Notion + DEV.to	+ Hashnode (Subscription)
Line stats	PR-only (`+0/-0` on commit weeks)	real per-commit deltas + touched areas
Cover image	none	Deterministic stats card, used as the cover
Setup	hand-edit `.env`	`npx devnotion init` wizard
Tests	a handful	51 across 18 suites

Before: "It works, but you have to trust it blindly."
After: "It works, and it gets out of your way — safely."

Publishing responsibly (the research that turned into a feature)

Around phase five I almost bolted on auto-publishing to a couple more platforms. Then I did the boring thing first and actually read the rules. The question I typed into the search bar was blunt: "is automated/AI publishing even allowed here, and can it get my account restricted?" The answers ended up reshaping the design.

Medium is a dead end for automation, on two counts. Its publishing API was archived in 2023 (no new integration tokens), and its AI content policy gives undisclosed AI writing "Network Only" distribution and can pull it outright. An auto-posted AI dev-log is exactly what that policy is aimed at — so Medium's off the roadmap by design, not by accident.
Hashnode has a real publishing API, but its Code of Conduct bans "automated or bulk posting" and self-promotion without contributing, and its terms let them suspend accounts at their discretion. A genuine weekly post is fine. Blind, scheduled, multi-account auto-posting is the pattern they're watching for.
DEV.to is the friendliest to drafts and review, which is exactly the workflow I landed on anyway.

The fix wasn't to publish less. It was to publish honestly:

Draft by default, human approval required. Every platform gets a draft; I review and edit it in the dashboard, then publish on-platform myself. Nothing ships unattended.
A disclosure footer on every post — small, bold, Generated by DevNotion. No hiding the tool.
A Dev log #n title prefix, so the series is honest about what it is.

The thread through all of it is disclosure over cleverness. A reader — and a platform's moderation team — can tell exactly what this is and whose name is on it. That's cheaper than building some workaround, and a lot cheaper than getting an account suspended.

That one search turned a feature I'd have rushed into a constraint that made the whole thing more defensible. "Finished" doesn't just mean it runs. It means it won't get your accounts pulled.

My Experience with GitHub Copilot

Reopening a codebase you haven't touched in months is mostly just remembering. You spend the first few hours working out why past-you did what they did before you can change any of it. That's where pairing with AI actually paid off, and it was almost never "write this function." It was "help me understand this again." A few moments stuck with me more than any autocomplete:

Diagnosing the silent bug. The most useful assist wasn't generated code — it was tracing why setting the model config changed nothing. Walking the two divergent code paths with an AI partner surfaced the split-brain config in minutes, instead of an afternoon of console.log archaeology.
The provider abstraction. Describing "one interface, swap Gemini / OpenAI / Anthropic" in plain English got me a clean factory I refined, instead of writing it from a blank file.
Relearning an unfamiliar API. Mastra's workflow primitives had shifted since I first used them. Rather than spelunking changelogs, I described the harvest → narrate → publish shape I wanted, let the assistant scaffold the createStep/createWorkflow calls, then fixed the schema wiring against the real types.
Knowing when to delete. I started wiring an AI cover via the Nano Banana API and paired to figure out its quirks — Gemini image models return bytes via result.files, and you call generateText, not some dedicated image function. The genuinely useful assist came right after: confirming the free tier's image quota was limit: 0, which made dropping the whole thing the obvious call instead of a stubborn one.
Tests. Generating the first pass of each unit test from the module's signature, then tightening the assertions by hand, is what made a 51-test suite cheap enough to actually write.

The thing that changed most wasn't speed. It was confidence coming back into a cold codebase. It didn't just finish my lines — it helped me remember what the code did and figure out where to take it next. Nobody warns you that's the hard part of "finishing" something. That's the part pairing helped with most.

Results & Validation

7 phases, shipped incrementally — each verified against tsc and the test suite before the next.
51 tests / 18 suites, green.
The narration path was confirmed live on the free tier (gemini-3-flash-preview), the harvest fix verified on a real week (+0/-0 → +2,252/-293), and the stats card rendered to a real 1200×630 PNG.
Proven end-to-end on real weeks. I ran v2 against three separate January 2026 weeks; each produced a Notion page and a DEV.to draft with the deterministic stats card attached as the cover — verified straight from the DEV.to API, where cover_image resolved to the generated card for every post.

None of this is theoretical. The rebuild got verified the same way it got built — incrementally. Every phase ended with a clean tsc and a green suite before the next one started. The failing first run became a passing one I watched run end to end. And the final proof was deliberately mundane: three real weeks, published as reviewable drafts, covers and all, with nothing shipped that I hadn't read first.

What "finishing" actually meant

I came into this assuming "finishing" meant features. More platforms, nicer output, an AI cover. Almost none of it was that. The phases that actually mattered were the ones that made the tool honest — failing loud instead of shipping junk, showing me the draft before it went live, putting real diffs where guesses used to be, reading each platform's rules before automating against them.

And the clearest tell? How often "finishing" turned out to mean deleting. The AI cover, gone. The silent fallback, out of the hot path. A whole config key wired to nothing, gone. The version that finally felt done wasn't the one with the most code. It was the one I'd trust to post under my name while I wasn't looking.

The repo is yashksaini-coder/DevNotion: npx devnotion init, point it at a week, and watch the draft land in the dashboard before anything ships. If you try it, open an issue — I read them now, and "I read them now" is its own small proof the thing is finished. ⭐ it if the rebuild resonates.

yashksaini-coder / DevNotion

DevNotion is an agentic server built using 3 mastra agents to work as a pipeline to publish weekly blogs on Notion Pages & DEV.to

DevNotion

Turn your weekly GitHub activity into a polished, illustrated blog post — narrated by an LLM, reviewed by you, and published to Notion, DEV.to, and Hashnode.

What's new in v2

v1	v2
LLM	Gemini only	Gemini · OpenAI · Anthropic (provider abstraction; default `gemini-3-flash-preview`)
Publish targets	Notion + DEV.to	Notion + DEV.to + Hashnode
Flow	generate → publish immediately	generate → preview → edit → approve → publish
UI	none (CLI/cron)	web dashboard (trigger, preview, edit, history)
Images	none	deterministic stats

…

View on GitHub

Connect: GitHub · X · LinkedIn · Portfolio

Built with Mastra, the Vercel AI SDK, Gemini 3 Flash for narration, @resvg/resvg-js for the stats-card cover, and the Notion / DEV.to / Hashnode APIs. By Yash K Saini — GitHub · X · LinkedIn. Star it if it made you smile.

From Rust CLI bug-hunting to a massive Portfolio overhaul

Yash Kumar Saini — Sat, 06 Jun 2026 08:34:48 +0000

23 commits, 3 PRs, and a 7-day streak. This week was a balance of deep-diving into Rust CLI logic, refining my Neovim setup, and a massive +4,500 line overhaul of my portfolio.

TL;DR

It’s been a while since I’ve had a "perfect week," but I finally hit that 7-day commit streak. 23 commits, 3 PRs, and 1 closed issue across 4 different repos—this week was the definition of a polyglot grind. I spent my time bouncing between surgical Rust fixes in a CLI tool, deep-diving into Python backend logic, and completely ripping apart my portfolio for a modern redesign.

WHAT I BUILT

The week was split between high-level visual work and low-level logic. I managed to touch four different repositories, each serving a very different purpose in my workflow.

DeepRead

I spent a good chunk of the week in DeepRead. With 8 commits, this was my most active repo in terms of frequency. It’s a Python-heavy project, and I was focused on refining the core processing logic. Python is usually my go-to for anything involving heavy data or AI-adjacent backend work, and this week was no exception. I didn't open a PR here yet, but the 8 commits represent a lot of iterative testing and refining of the internal modules.

nvim

You know it’s a productive week when you’re also tweaking your tools. I pushed 7 commits to my nvim config. Most of this was Lua-based (obviously), and I was mainly focused on tightening up my LSP settings and UI. There’s something incredibly satisfying about spending 20 minutes fixing a minor annoyance in your editor and then seeing it pay off for the rest of the week. If my environment isn't perfect, I can't get into that deep flow state.

GitBanner

I’ve been working on GitBanner, a TypeScript tool for generating GitHub profile banners. I pushed 6 commits and opened a new feature PR: feat: add ignore-languages input to filter generated/vendored files. The goal here was to give users more control over what shows up in their stats. Nobody wants their "top languages" to be skewed by a massive vendored library or a bunch of generated CSS files. It’s a small DX improvement, but those are the ones that make a tool actually usable.

trx

Finally, I did some surgical work on trx, a Rust-based CLI tool. This was a classic "scratch your own itch" situation. I noticed a bug where the tool would repeatedly prompt for an update even after I’d already upgraded. I opened an issue for it—bug: TRX repeatedly prompts for update even after successfully updating—and then immediately went in to fix it. Rust is great for this kind of thing because once you get the logic right and the compiler is happy, you know it’s solid.

PULL REQUESTS

I opened three PRs this week, and they tell the story of where my head was at.

The most significant one in terms of sheer volume was for my portfolio. The PR, feat: portfolio modern redesign + scrolling GitHub PR sidebar, clocked in at a massive +4,509 lines. I decided it was time to move away from my old layout and go for something much more modern. The highlight of this redesign is a new scrolling sidebar that pulls in my latest GitHub PRs. It’s a bit meta—building a tool to show the tools I’m building—but I love how it looks. It’s still open as I’m fine-tuning some of the CSS transitions, but the bulk of the work is done.

On the Rust side, I got fix: stop re-prompting update after user skips or upgrades merged into trx. This was the fix for the bug I mentioned earlier. It involved tightening up the version check logic to ensure the CLI respects the user's choice to skip an update or correctly identifies when the local version matches the remote.

I also have the GitBanner PR open, which adds the ignore-languages input. This was a fun bit of TypeScript logic, essentially filtering the language data before it hits the rendering engine.

ISSUES & DISCUSSIONS

I only opened one issue this week, but it was a productive one. I reported the update prompt bug in trx and then closed it myself with the PR I mentioned above. I’m a big believer in documenting bugs even if you’re the one fixing them five minutes later. It creates a paper trail for anyone else who might run into the same weird behavior.

TECH STACK

This was a true polyglot week. My language breakdown is all over the place:

Python for the heavy lifting in DeepRead.
TypeScript for the GitBanner logic and the massive Portfolio redesign.
Rust for the CLI stability in trx.
Lua for the Neovim configuration.

The numbers tell an interesting story: +4,614 additions and -1,081 deletions. That’s a huge net positive, mostly driven by the portfolio redesign. Usually, I like to see more deletions (refactoring is a gift), but when you’re shipping a whole new UI, the additions are going to win every time.

And of course, the 7-day streak. It wasn't a forced grind; I just happened to be in a really good rhythm where I had something I wanted to ship every single day.

WHAT'S NEXT

Next week is all about landing those open PRs. I want to get the portfolio redesign merged and live—there are still a few responsive design bugs I need to squash in that new scrolling sidebar. I also want to see the GitBanner feature through to completion. Beyond that, I’m planning to dive back into the Python side of things with DeepRead. There’s some performance optimization I’ve been putting off, and now that my environment is dialed in and my portfolio is looking fresh, I’ve got no excuses left.

Catch you all next week!

python #typescript #rust #frontend #dx #consistency · 4 min read · Generated 2026-05-24 by DevNotion

DEV Community: Yash Kumar Saini

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

ISSUES & DISCUSSIONS

CODE REVIEWS

TECH STACK

WHAT'S NEXT

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

TL;DR

The Big Push: The Rust Book Simplified

Deep in the Networking Weeds: py-libp2p

SRE Tooling and AI Contexts

The Reviewer's Hat

Tech Stack & Vibe

What's Next?

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

TL;DR

What I Built

The Neovim Pivot (nvim)

Hardening the Core (openslate)

Pull Requests & Pipeline Fixes

The Tech Stack & The Streak

What's Next

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

TL;DR

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`)