DEV Community: Yash Kumar Saini

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

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

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

TL;DR

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

What I Built

Reachable: Security and Performance

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

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

Opportunity-Radar: Scraping and UI

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

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

The Personal Stack: Obsidian and Portfolio

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

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

Pull Requests

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

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

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

Issues & Discussions

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

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

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

Tech Stack

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

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

What's Next

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

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

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

GitHub · X · LinkedIn · Portfolio

Generated by DevNotion

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

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

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

The setting

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

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

Signing authenticates the record, not the routing table

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

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

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

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

Building the attack to measure it

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

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

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

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

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

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

The root cause

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

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

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

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

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

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

The details are where the real engineering is:

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

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

What I learned

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

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

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

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

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

Project Overview

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

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

Bug Fix or Performance Improvement

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

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

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

Two things are attacker-controlled and unbounded:

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

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

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

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

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

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

Code

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

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

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

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

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

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

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

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

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

My Improvements

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

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

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

Reproduce it:

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

Best Use of Sentry

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

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

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

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

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

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

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

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

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

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

Best Use of Google AI

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

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

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

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

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

The setting

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

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

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

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

The first sign

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

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

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

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

The investigation

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

So from the outside:

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

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

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

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

The root cause

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

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

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

The fix

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

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

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

The canary that would have caught it

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

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

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

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

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

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

What I learned

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

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

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

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

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

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

TL;DR

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

What I Built

GitBanner: The Aesthetic CLI

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

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

Obsidian & Personal Knowledge

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

Kad-Monitor: The Final Chapter

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

P2P & Backend Hardening

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

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

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

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

Issues & Discussions

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

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

Tech Stack & Workflow

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

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

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

What's Next

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

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

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

GitHub · X · LinkedIn · Portfolio

Generated by DevNotion

Gravy Theory: three chickens, one base

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

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

What I Built

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

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

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

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

Seven sections, each answering one question:


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

The constraint

One HTML file. Zero image requests.

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

index.html    ~147 KB    everything

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

Demo

Cook the base →

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

yashksaini-coder / comfort-food-challenge

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

Gravy Theory — three chickens, one base

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

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

→ Live demo

The constraint

One HTML file. Zero image requests.

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

index.html    ~146 KB    everything

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

What's in it

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

…

View on GitHub

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

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

Journey

The thing that took three attempts

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

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

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

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

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

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

Four filters, all of them static

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

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

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

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

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

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

Two CSS traps I fell into twice each

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

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

Making the colour actually interpolate

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

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

The part I'm most proud of

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

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

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

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

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

The bug that embarrassed me most

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

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

What's next

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

Watch the oil separate →

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

Dev log #16 Typographic Hierarchy and the Great Obsidian Purge

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

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

TL;DR

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

What I Built

Portfolio Redesign: The Typography Pivot

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

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

The Obsidian Purge

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

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

Neovim Tinkering (As Always)

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

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

Pull Requests

I had two main PRs on the go this week:

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

Issues & Discussions

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

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

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

Tech Stack

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

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

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

What's Next

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

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

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

GitHub · X · LinkedIn · Portfolio

Generated by DevNotion

Dev log #15 Refining the Craft: A week of Neovim UI hacking and portfolio architecture

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

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

TL;DR

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

What I Built

nvim (The Editor Overhaul)

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

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

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

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

portfolio (Restructuring the Narrative)

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

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

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

Pull Requests

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

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

Tech Stack & Stats

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

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

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

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

What's Next

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

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

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

GitHub · X · LinkedIn · Portfolio

Generated by DevNotion

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

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

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

TL;DR

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

The Fight for a More Secure DHT

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

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

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

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

The Tax of Asynchronous Testing

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

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

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

Maintenance and Tooling

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

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

Tech Stack & Vibe

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

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

What's Next

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

Catch you in the next update. Keep shipping.

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

GitHub · X · LinkedIn · Portfolio

Generated by DevNotion

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

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

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

TL;DR

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

WHAT I BUILT

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

py-libp2p

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

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

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

nvim

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

ISSUES & DISCUSSIONS

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

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

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

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

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

TECH STACK

This week was a deep dive into Python and Lua.

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

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

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

WHAT'S NEXT

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

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

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

GitHub · X · LinkedIn · Portfolio

Generated by DevNotion

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

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

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

TL;DR

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

WHAT I BUILT

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

Portfolio & Personal Branding

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

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

The Maintenance Grind

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

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

PULL REQUESTS

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

Deep Diving into WebRTC (py-libp2p)

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

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

Documentation DX

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

CODE REVIEWS

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

TECH STACK

This week was a polyglot's dream.

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

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

WHAT'S NEXT

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

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

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

GitHub · X · LinkedIn · Portfolio

Generated by DevNotion

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

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

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

A quick honest note before we start

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

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

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

The problem: why a Python libp2p wants WebRTC at all

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

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

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

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

What actually landed

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

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

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

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

Architecture in one picture

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

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

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

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

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

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

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

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

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

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

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

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

Reason 1: SCTP has a 16 KiB message ceiling

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

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

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

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

Here's the on-wire shape:

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

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

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

The sender side of a stream then becomes:

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

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

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

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

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

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

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

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

Deep dive #2 — the certificate pin that actually pins

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

Setting the scene

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

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

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

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

The naïve pin

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

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

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

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

The fix

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

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

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

The canary

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

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

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

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

Deep dive #3 — bridging two runtimes without blowing up

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

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

The bridge is a small class:

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

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

The heart of it is run_coro:

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

    future = asyncio.run_coroutine_threadsafe(coro, loop)

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

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

Two subtle things worth pausing on:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So we put all of it in one function:

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

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

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

The maintainer's response, verbatim, was:

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

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

Testing: 153 tests, but only one of them mattered

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

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

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

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

The loopback test's docstring calls this out explicitly:

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

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

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

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

What the review looked like from the inside

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

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

The maintainer's approving comment, in full:

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

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

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

Where it goes next

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

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

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

The one takeaway I want you to leave with

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

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

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

Try it, and honest expectations

You can install and inspect it today:

pip install 'libp2p[webrtc]'

Then in code:

from libp2p import new_host

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

Realistic expectations:

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

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

References

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

DEV Community: Yash Kumar Saini

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

TL;DR

What I Built

Reachable: Security and Performance

Opportunity-Radar: Scraping and UI

The Personal Stack: Obsidian and Portfolio

Pull Requests

Issues & Discussions

Tech Stack

What's Next

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

The setting

Signing authenticates the record, not the routing table

Building the attack to measure it

The root cause

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

What I learned

Links

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

Project Overview

Bug Fix or Performance Improvement

Code

My Improvements

Best Use of Sentry

Best Use of Google AI

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

The setting

The first sign

The investigation

The root cause

The fix

The canary that would have caught it

What I learned

Links

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

TL;DR

What I Built

GitBanner: The Aesthetic CLI

Obsidian & Personal Knowledge

Kad-Monitor: The Final Chapter

P2P & Backend Hardening

Issues & Discussions

Tech Stack & Workflow

What's Next

Gravy Theory: three chickens, one base

What I Built

The constraint

Demo

yashksaini-coder / comfort-food-challenge

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

Gravy Theory — three chickens, one base

The constraint

What's in it

Journey

The thing that took three attempts

Four filters, all of them static

Two CSS traps I fell into twice each

Making the colour actually interpolate

The part I'm most proud of

The bug that embarrassed me most

What's next

Dev log #16 Typographic Hierarchy and the Great Obsidian Purge

TL;DR

What I Built

Portfolio Redesign: The Typography Pivot

The Obsidian Purge

Neovim Tinkering (As Always)

Pull Requests

Issues & Discussions

Tech Stack

What's Next

Dev log #15 Refining the Craft: A week of Neovim UI hacking and portfolio architecture

TL;DR

What I Built

nvim (The Editor Overhaul)

portfolio (Restructuring the Narrative)

Pull Requests

Tech Stack & Stats

What's Next

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