XY is an alpha-stage Python charting library aimed at a specific gap: datasets too large for Plotly or Bokeh but where you still want to pan, zoom, hover and click. The claim that drew me in was that its cost is bounded by screen size rather than data size.

That’s a testable claim, so I tested it. This post walks through what the design does, what the measurements showed, and where I think it does and doesn’t belong.

Who this is written for: you can read Python, you know what an array is, and you’ve made a plot with Matplotlib at some point. Everything else is explained.

Where the numbers come from. Every figure carries its source:

• [M] — measured on an Apple Silicon laptop

• [C] — derived from constants in python/xy/config.py

• [R] — reported by the project’s CI benchmarks in spec/benchmarks/results.md

The last section covers how to reproduce all of them.

The problem you haven’t run into yet

Most plots are a few hundred points. It feels instant, so you never think about what the library is doing underneath.

Now imagine a file with ten million rows — every flight that took off last year, or every star in a sky survey — and the instruction “plot it.”

The obvious code:

python

import matplotlib.pyplot as plt
plt.scatter(x, y)
plt.savefig("out.png")

That took about 860 ms and 580 MB of memory [M]. In Plotly, asking for an interactive chart you can pan and zoom takes 54 seconds and 1.5 GB [R]. In Plotly’s default non-GPU mode, which builds one SVG element per point, it never finishes at all — that path stops being usable somewhere above a million points [R].

Now look at your screen. A typical plot area is around 1200 × 800 pixels: 960,000 pixels total [M]. Ten million things drawn onto fewer than a million dots means 10.4 points share each pixel [M] on average. Nine out of ten are painted over before you ever see them.

The machine did enormous work to produce an image carrying no more information than a much cheaper image would have.

That observation is the foundation of XY’s design.

The core idea

Traditional charting libraries have a cost that scales with how much data you have. Ten times the data, roughly ten times the work.

XY is built so cost scales with how many pixels are on screen.

Your screen doesn’t grow when your dataset does, so past a certain size, plotting more data costs almost nothing extra. The payloads I measured:

Two things there need explaining, and the explanation turned out to be the most interesting part of the exercise.

First, a 10× jump from one million to ten million changes the payload by 0.7% [M]. Second — and this reads like a typo the first time — plotting more data sent less.

Nothing shrank. Those rows are two different formats either side of a switch.

One number, two formats

XY picks a representation based on how many points are visible. The switch is a constant in python/xy/config.py:

python

SCATTER_DENSITY_THRESHOLD = 200_000
DENSITY_GRID = (512, 384)
DENSITY_SAMPLE_TARGET = 8_192

Below the threshold: direct mode

Every point ships individually as two 32-bit floats — an x and a y — so 8 bytes per point. 100,000 points is 100,000 × 8 = 800,000 bytes = 781.25 KB [C], which is the 782 KB measured above. Cost grows linearly and without limit; ten million points would be 78 MB.

In exchange, every point is really there. You can hover it, click it, colour it individually.

Above the threshold: density mode

XY stops sending points and sends a picture of where they were:

count grid      512 × 384 cells × 1 byte  = 196,608 B = 192 KB
sample overlay  8,192 points × 2 × f32    =  65,536 B =  64 KB
                                            ─────────────────
                                                        256 KB  [C]
+ chart specification metadata                           ~3 KB
                                            ─────────────────
                                                        259 KB

Measured: 258–260 KB [M]. The derivation agrees to within 3 KB.

Now notice what’s missing from that calculation: N never appears. The grid is 512 × 384 whether it holds a thousand points or a billion. The sample overlay is 8,192 points regardless. No term in the formula can be influenced by your data size.

That’s the difference between “flat in practice” and “flat by construction.” The payload isn’t flat because someone optimized carefully — it’s flat because the format has no room to be anything else.

The gap that reveals the priorities

Density mode costs 256 KB. Direct mode costs 8 bytes per point. Set them equal:

256 KB ÷ 8 bytes = 32,768 points  [C]

Above 32,768 points, direct mode is already the more expensive way to send a chart. But XY doesn’t switch there — it switches at 200,000, shipping up to 6.1× more data than it strictly needs to [C] in between.

That gap is deliberate. The LOD specification states the rule directly:

Invariant L2 (exact under budget): if visible ≤ budget, the user sees real marks with real channels — never a sample, never an aggregate.

— spec/design/lod-architecture.md

Under the budget you get exact hover, exact selection, and a real colour per mark. A density grid provides none of those. Bandwidth is the cheaper thing to spend, so XY spends it.

The payload curve is a step function: linear, then a cliff, then horizontal forever.

What makes it possible

The step function is the visible behaviour. Five design decisions underpin it.

Numbers travel as bytes, not text

When Plotly sends data to the browser, it converts it to JSON:

json

{"x": [1.0, 2.0, 3.0]}

A double-precision float is 8 bytes in memory. As JSON text, a realistic coordinate like -73.98452301 runs a dozen characters; with separators the average worked out to 19.9 bytes per number [M] — 5.0× the 4 bytes [M] the same value occupies as a 32-bit float.

Size is only half of it. The browser must then parse every one of those strings back into a number, character by character. For twenty million numbers, that’s hundreds of megabytes of text and a parse that blocks the page.

XY moves data as raw binary float buffers. The design dossier states it as an invariant:

No JSON numbers on the wire; data moves as raw f32 buffers (§29).

The bytes leaving your NumPy array are byte-for-byte the bytes the graphics card reads. The only copies are memcpycopies — blind block moves — never parse-a-number copies.

Transferable idea: text is a fine container for configuration and a poor one for data.

Computation runs where the data already is

Plotly computes in JavaScript, in the browser, on the same thread that handles your clicks. That’s why pages freeze.

XY computes in Rust — a compiled language in C’s performance class — running inside your Python process. The data never leaves the machine to be processed; the browser receives a finished, small result.

(The project’s CI, on slower hardware, records 2 ms at 100,000 points [R].)

Transferable idea: move the computation to the data, not the data to the computation. It’s why databases push filters down to storage.

The graphics card draws the marks

Plotly’s default scatter creates one SVG element per point — a real object in the page’s document tree, like a <div>, carrying hundreds of bytes of structure and style. Browsers degrade badly past ten to a hundred thousand of them, which is why that path takes 44 seconds at one million points and 113 seconds at three million [R].

XY draws through WebGL2, the browser’s interface to your GPU (js/src/50_chartview.ts). GPUs exist to run the same small operation on millions of items at once. XY uses instanced rendering: upload one marker shape, then issue a single command meaning “draw this 500,000 times, at these positions.”

The HTML document is still used — for axis labels, legend and tooltips. Small things, few of them.

Worth knowing: the GPU holds only a cache. Canonical data stays CPU-side in 64-bit precision, and every GPU buffer is droppable and rebuildable. Hover, selection, export and zoom all need the real values, and data that exists only in video memory can’t serve them.

Level of detail

The same idea games use: a distant mountain isn’t rendered rock by rock.

XY defines four tiers and picks one per chart, re-picking as you zoom (spec/design/lod-architecture.md):

Tier 0 — Direct. Draw every point, exactly. No approximation.

Tier 1 — Decimation, for lines. A stock price with 100 million samples on a 1,200-pixel-wide chart gives each pixel column ~83,000 samples. But a pixel column can only show a vertical segment, so what matters is the first, last, minimum and maximum value in that column. Keep four, discard the rest.

This is the M4 algorithm (Jugel et al., VLDB 2014), and its property is unusual: the reduced line rasterizes to an image identical to the full-data line. Not similar — identical.

That’s testable, so the harness tests it. Rasterizing a 2,000,000-point signal with sharp spikes at 1200px wide, both fully and M4-reduced, then comparing every pixel column:

points in:            2,000,000
points kept:              4,777   (419× reduction)   [M]
M4 max deviation:           0.0                      [M]
naive subsampling,
same budget:              302.16                     [M]

Zero. Uniform subsampling to the identical budget misses spikes by 302 units. Same number of points kept; one method is exact and the other isn’t.

Tier 2 — Density surfaces, for scatter. Scatter points have no order, so dropping some would genuinely distort the picture. Instead XY bins them into the fixed grid described above.

Tier 3 — Out-of-core tiles. Beyond RAM, canonical data stays on disk and only the tiles the current view needs are read — the way map applications load tiles as you pan.

A floating-point trap worth remembering

This one will show up in your own code someday.

GPUs prefer 32-bit floats over 64-bit — half the memory, faster to process. So the obvious optimization is storing coordinates as float32.

A float32 has a 24-bit mantissa: about 7 significant decimal digits total (not 7 after the decimal point).

Now consider time. Computers commonly store timestamps as milliseconds since 1 January 1970 — currently around 1,700,000,000,000, thirteen digits. Seven digits of precision for a thirteen-digit number leaves the last six as noise.

Measured precisely:

gap between neighbouring float32 values near 1.7e12:
    131,072 ms  =  2 minutes 11 seconds          [M]

a day of per-second readings (86,400 samples):
    660 distinct x-positions survive              [M]

A day of data becomes 660 columns. No exception, no warning — just a chart that’s quietly wrong.

The fix is a change of coordinates, not more bits. Keep full precision in Python; compute a per-column offset; subtract it before the cast:

raw:        1_700_000_000_000, 1_700_000_001_000, 1_700_000_002_000
offset:     1_700_000_001_000
relative:              -1_000,                 0,             1_000

Those small numbers fit a float32 with room to spare. The offset stays in Python as a 64-bit value and is added back during rendering. Round-tripping the same timestamps this way gave a maximum error of 0 ms at 4 bytes per value [M] — same storage, exact results. When you zoom far enough that precision tightens again, XY re-centres the offset.

The technique isn’t XY’s invention. deck.gl adopted it and then removed their far more complex emulated-64-bit code, reporting that the offset approach “rivals 64-bit precision at 32-bit speeds.” Cesium uses the same idea under the name RTC.

Transferable idea: when an optimization looks free, find out what it costs. And when precision fails, ask whether you can move the origin before asking for more bits.

Summarising without distorting

Here’s a question that sounds simple and isn’t.

You’re plotting a million flights, coloured by airline — red for one, blue for another. Zoomed out, XY is in density mode, and one cell now covers 500 flights of mixed colour.

What colour is that cell?

Each obvious answer distorts something:

• Colour by count alone — the airline information is gone entirely.

• Majority wins — a cell holding 251 red and 249 blue renders as pure red. Minorities vanish.

• Brightest or maximum — one outlier speaks for 500 points.

XY’s rule, from spec/design/lod-architecture.md:

the density surface wears the data’s own colors, and it composites like the data’s own points

Each cell shows the alpha-weighted mean of its points’ actual colours, averaged in linear light, and its transparency is set to what that many overlapping semi-transparent marks would physically produce — 1 − (1 − a)ᵏ for k points.

The consequence: the zoomed-out surface and the zoomed-in points are the same image at two magnifications. Zoom in and the surface dissolves into individual marks with the same hue and brightness. Nothing jumps.

The “linear light” detail is doing real work. Screen colours are stored in sRGB, a non-linear encoding matched to human perception. Averaging red and blue as raw bytes gives a dark purple of 128; converting to linear light, averaging, then converting back gives 188 [M] — which is what overlapping red and blue light actually produces. Both values verified exactly.

Where a channel has no honest aggregate — marker size has no meaningful average — XY drops it and renders a visible “aggregated” badge, so a summary can’t be mistaken for raw data.

The project’s own competitive research is candid that most of XY’s parts exist elsewhere: GPU rendering, binary transport, density aggregation and tile pyramids are all prior art. What it identifies as new is the combination together with these truthfulness rules.

Points that remember where they came from

If XY sends a grid instead of points, how do you click a flight and see its callsign?

The design is indices, not payloads. Hover and selection return row positions into your original data:

python

import xy, pandas as pd

flights = pd.read_parquet("flights.parquet")   # 10M rows, 40 columns

def on_select(sel):
    picked = flights.iloc[sel.index]           # full records, all 40 columns
    print(picked.groupby("airline").size())

xy.scatter_chart(
    xy.scatter(x="lon", y="lat", color="airline", size="altitude", data=flights),
    on_select=on_select,
)

Verified: box-selecting a region returned 3,163 indices where a NumPy mask predicted 3,163 — exact match [M].

The reason for the design is arithmetic. Attaching a 40-byte callsign to each of ten million points would add 400 MB to the wire and dismantle everything above. Row position costs nothing — it already exists implicitly in array order.

The GPU knows geometry. Python knows everything. Array position links them.

One consequence to plan around: in density mode there are no individual points to hover, so you get a cell summary plus a drill to the top rows in that cell. Zoom past the budget and exact per-point hover returns.

Where XY fits

Large scientific and engineering data. Sensor logs, particle physics, sky surveys, genomics — millions of rows you need to look at, not just compute on.

Time series and monitoring. Offset encoding keeps timestamps exact, M4 keeps long histories cheap, and appends cost only the size of the append rather than a full re-send, so live dashboards stay responsive.

Work that needs points back, not just pixels. Select a region, get the records. The main alternative for very large scatter plots, datashader, returns a finished image — there’s nothing to click.

Ordinary small charts. XY isn’t only a big-data tool: 0.4 ms to build a 100,000-point chart [M] against 159 ms for Plotly to serialize the same chart to HTML [M]. Small-data startup is a tracked benchmark category with an explicit goal of beating Plotly, Bokeh and Altair on first paint [R].

Where XY is the wrong tool

Games and general graphics. XY uses the GPU, but nothing about it generalises. It’s event-driven: it draws when something changes, then goes idle. Games do the opposite — simulate and draw every frame, continuously. XY’s central optimization is that panning updates a few GPU variables and never touches data buffers, which is precisely wrong for a world that changes each tick. The mark types are also a fixed set of about twenty; the plugin documentation is explicit that a plugin returns “ordinary XY marks — not shaders, not draw calls.” That restriction is what lets plugins inherit hover, selection and export for free, but custom geometry needs a different tool. Use PixiJS or Three.js on the web, Godot or Unity natively.

Native mobile apps. The Rust engine runs inside a Python process. Phones don’t have one. A browser-embeddable bundle exists and would work in a WebView, and a browser-free Rust rasterizer can produce PNGs server-side, but iOS and Android aren’t supported targets.

Charts XY doesn’t have yet. Plotly ships around forty trace types; XY has scatter, line, area, bar, histogram, box, violin, hexbin, heatmap, contour, error bars and a handful more. Absent: treemap, sunburst, Sankey, radar, gauge, waterfall, funnel — and candlestick/OHLC, which was prototyped on a branch whose pull request was closed unmerged.

For candlesticks today, TradingView’s Lightweight Charts is the strongest free option — candlesticks, time axis, crosshairs, price scales and volume panes in about 35 KB, purpose-built for finance rather than bolted on. It’s JavaScript;lightweight-charts-python wraps it. For a static image in a report, mplfinance is simplest.

There’s an elegant footnote there. Candlestick reduction is first/max/min/last per pixel column — exactly the M4 algorithm XY already ships for lines. And for candles that reduction isn’t even an approximation: merging sixty one-minute candles into one hourly candle is just a coarser candle, lossless in the chart’s own language. The architecture suits OHLC unusually well; the mark simply hasn’t been built.

The ordering looks deliberate rather than accidental. The shared primitives — rectangles, filled polygons, grid textures — came first, because once those exist each new chart type is largely wiring. Breadth is cheap after depth.

Anything small and routine. With 5,000 points, XY offers nothing Matplotlib doesn’t, and Matplotlib is twenty years mature, installed everywhere, and thoroughly documented by strangers who hit your problem first.

XY is in alpha. Its design dossier maintains a public list of unresolved issues: the tier decision doesn’t yet account for GPU fill rate, logarithmic axes skip the tile pyramid and take a full rescan, brightness can shift when zooming certain coloured surfaces. Documented openly — but this is a project under active construction, not a settled dependency.

Reproducing these numbers

Everything marked [M] comes from scripts/validate_article_claims.py in the repository. It checks each claim against the value asserted here and prints PASS or FAIL, exiting non-zero on failure so it can run in CI:

bash

python3 scripts/validate_article_claims.py --sizes 1e5,1e6,1e7

The checks come in three tiers. Tier A is arithmetic and needs only NumPy — the float32 timestamp collapse, the offset-encoding round trip, the linear-light colour figures, the M4 pixel comparison, and the payload derivation read fromconfig.py. Tier B exercises the engine and needs the native Rust core (cargo build --release). Tier C runs Matplotlib and Plotly for comparison and skips gracefully if they aren’t installed.

Two habits came out of building it that I’d carry to any measurement work.

Pin the value, not just the trend. An early version of the payload check verified only that the payload didn’t grow with N. It passed — while the figure it was being compared against was three times too large, because that figure came from a benchmark table predating a compression change. A test that checks a trend without pinning the value will certify a wrong number without complaint. The check now asserts flatness and an absolute band, independently.

Benchmark numbers carry a date. spec/benchmarks/results.md labels its retained tables with the run that produced them and marks superseded figures explicitly. Reading that metadata is part of reading the number.

Two figures here are marked [R] and weren’t re-measured locally: Plotly’s 54 seconds and 1.5 GB at ten million points, and the SVG-path collapse timings. They’re consistent with the smaller measurements I did take, but they’re labelled as reported rather than measured because that’s what they are.

That labelling habit is one the project itself follows — its design dossier flags its own “Plotly uses 40–100 bytes per point” figure as an estimate pending measurement rather than publishing it as fact.

What I’d carry away

Four ideas here outlive this particular library.

Bound the work by the output, not the input. The screen holds a million pixels. That’s the real budget. Any system with a fixed-size output has a similar bound available, and most don’t take it.

Text is a poor container for numbers. 19.9 bytes versus 4, plus a parse on the receiving end. Binary formats aren’t premature optimization at scale; they’re the difference between working and not.

Move computation to the data. Rust inside the Python process rather than JavaScript in the browser. The fastest network request is the one never made.

The naive optimization is often silently wrong. “Use float32, it’s smaller” turns a day of per-second data into 660 columns with no error raised. The fix wasn’t more precision — it was moving the origin so the numbers got small.

And one worth stealing from how the project documents itself: XY publishes a list of its own unsolved problems, marks unverified claims as estimates, and credits the prior work each idea came from. That practice is rarer, and more useful, than any technique above.

Sources

• spec/design-dossier.md — architecture, invariants, competitive research

• spec/design/lod-architecture.md — tier ladder, aggregation truthfulness rules

• spec/benchmarks/results.md — CI benchmark methodology and results

• python/xy/config.py — tuning constants used in the payload derivations

• scripts/validate_article_claims.py — the verification harness

• Jugel et al., M4: A Visualization-Oriented Time Series Data Aggregation, VLDB 2014

This article explores that evolution in depth: how HTTP/1.1, 2, and 3 differ, what they mean for back-end and front-end developers, and how platforms like Nginx, Vercel, and Cloudflare bring it all together.

Settle in — this article is not a quick read, but it gathers the detail that turns “black-box performance” into predictable engineering.

When your React or React Native app loads, hundreds of packets race across networks governed by invisible rules — HTTP versions. Each upgrade — from HTTP/1.1 to HTTP/2 to HTTP/3 — reshaped how browsers, servers, and frameworks communicate.
Understanding these layers helps developers build faster, safer, and more resilient applications.

Why Protocol Versions Still Matter

Modern frameworks (Next.js, Remix, Astro, Expo) handle a lot for you, but protocol behavior still affects:

• Latency on first load and during navigations

• Tail performance (p95/p99) under packet loss or mobile transitions

• Concurrency of module, font, image, API, and streaming fetches

• Security posture (TLS 1.3, replay risks, Zero‑Trust hops)

• Observability and capacity planning

Layer Refresher (Mental Model)

• Application Layer: Defines HTTP request/response meaning (methods, headers, bodies) and stays stateless per request.

• Transport Layer: Moves bytes reliably (TCP) or via independent encrypted streams (QUIC over UDP).

• Encryption: TLS 1.2/1.3 secures data above TCP; QUIC bakes TLS 1.3 directly into transport.

• Multiplexing: Multiple logical streams share one connection (HTTP/2 on TCP; HTTP/3 on QUIC without cross-stream blocking).

Analogy:
HTTP defines the message.
TCP insists every letter arrive strictly in order.
QUIC lets each envelope arrive independently—no one waits for the slowest.

HTTP/1.1 — in a modern web environment

HTTP/1.1 powered the early web. It introduced

• persistent connections

• Chunked transfer encoding

• Basic caching semantics enhancements

but every request still traveled over a single, ordered TCP stream.

When packet #5 was delayed, packets #6–#100 waited behind it.
This created one of the web’s earliest bottlenecks: Head-of-Line Blocking (HOLB).

Deep Dive: HTTP is Stateless, but HOLB Isn’t

A common question is:

“If HTTP is stateless, why does one delayed packet stall everything?”

Here’s the distinction:

• HTTP lives at the application layer — defining what data is exchanged (GET, POST, headers, body). It’s statelessbecause each request carries all needed context and doesn’t depend on earlier ones.

• HOLB lives at the transport layer (TCP) — which guarantees ordered delivery of packets. If a packet is lost, the entire stream waits until it’s retransmitted.

The transport layer decides how data travels — handling delivery, ordering, and error correction between endpoints.

So while HTTP doesn’t maintain conversation state, the underlying TCP connection does maintain ordering state. That’s what causes global delays.

HTTP/2 — Multiplexing and Compression, But Transport HOLB Remains

HTTP/2 reimagined how data flows over the same TCP base, bringing four key upgrades:

1. Binary framing — Requests/responses are split into structured frames for faster parsing.

2. Multiplexing — Multiple requests share one connection via independent streams.

3. HPACK header compression — Repeated headers like cookies are encoded as dictionary references.

4. Server Push(Deprecated in Practice) — Servers can pre-send assets they expect the client would need.

What Improved:

• Eliminated application-layer HOLB (no strict request sequencing).

• Fewer TLS handshakes; better use of a single congestion window.

• Significant header byte reduction for chatty APIs or GraphQL endpoints.

What Didn’t:

• Transport-level HOLB remains. One lost TCP packet still stalls delivery of frames for all streams sharing that TCP connection until retransmission completes.

Why Server Push Fell Away:

• Complexity in correctness (over-pushing/waste).

• Hard to cache predictably.

• Browsers (e.g., Chrome, Firefox) disabled or deprecated it. Use instead: rel=preload, rel=preconnect, HTTP 103 Early Hints.

🔐 TLS 1.3, ALPN, and Edge Termination

Modern HTTP effectively means HTTPS.

TLS 1.3:

• Fewer round trips (1-RTT; 0-RTT possible on resumption).

• Forward secrecy enforced.

• Cleaner cipher suite landscape.

ALPN (Application-Layer Protocol Negotiation):

• Client offers: h2, h3, http/1.1.

• Server picks the highest mutually supported (e.g., h2 or h3).

TLS Termination at the Edge

On platforms like Vercel, Cloudflare, and Netlify, TLS usually terminates at their edge:

• Browser ↔ Edge: Encrypted (TLS 1.3).

• Edge ↔ Your Backend: Often re-encrypted with HTTPS, sometimes proxied via HTTP for internal performance.

• Frameworks such as Express or Django must use trust proxy headers (X-Forwarded-Proto, Host, For) to interpret the original connection as secure.

Vercel note:
Serverless functions on Vercel run within the same TLS-terminated environment. You don’t manage certificates — the edge fabric handles TLS 1.3 automatically.

For self-hosting, Nginx or Caddy can terminate TLS and optionally re-encrypt upstream traffic using HTTPS or mTLS — aligning with Zero-Trust principles (“verify and encrypt every hop”).

HTTP/3 — QUIC: Stream Independence & Mobility

QUIC(RFC 9000) stands for Quick UDP Internet Connections — a transport protocol that blends reliability, encryption, and parallelism on top of UDP.

Key Concepts

• 0-RTT (Zero Round-Trip Time): Clients reuse keys from previous sessions to send data immediately without a handshake. Great for mobile users reconnecting frequently.

• Stream Independence: Each stream has its own packet numbering and flow control. Packet loss affects only that stream — others continue unaffected.

• Connection Migration: Sessions are tied to a connection ID rather than an IP address. If a device switches from Wi-Fi to 4G, the same connection continues.

• Built-in TLS 1.3: Encryption is mandatory and integrated into the transport layer.

• Header Compression: QPACK (not HPACK). Designed to avoid introducing head-of-line blocking during header table synchronization in a loss scenario.

Performance Gains:

• Improved tail latency on lossy, mobile, or high-jitter networks.

• Faster recovery from packet loss; unaffected streams continue.

• Reduced handshake overhead (esp. with resumption).

Adoption:

• Major CDNs and browsers widely support HTTP/3.

• gRPC over HTTP/3, and is supported by some of the languages

  • Go / Rust: Strong HTTP/3 + QUIC libraries.

  • Node.js: Experimental / progressing; see Node.js issue #57281.

  • Python: User-space libs (aioquic) or via edge proxies (Caddy, Cloudflare) rather than stdlib.

  • Java / .NET: HTTP/3 adoption moving through library layers (Netty, Jetty, Kestrel updates).,

Practical Impact by Role

Frontend / Web App Engineers

• Don’t over-bundle solely to reduce request count (HTTP/2+ handles concurrency). Still bundle for code splitting strategy and caching boundaries.

• Use rel=preload (critical CSS, fonts), rel=preconnect (third-party origins), and rel=dns-prefetch.

• Prefer Early Hints (103) when supported to prime fetches earlier.

• Eliminate bloat: large cookies and verbose headers consume compression tables.

• Measure p95 Resource Timing vs just “Time to First Byte.”

React Native / Mobile Clients

• HTTP/3 improves resilience when radios churn (Wi‑Fi ↔ 4G).

• Use keep-alive pools carefully; minimize forced connection churn.

• Monitor tail API latencies under network transitions (simulate with network link conditioners).

Backend / API Engineers

• Reduce header entropy (avoid ever-growing dynamic data in headers) to maximize HPACK/QPACK efficiency.

• Validate proxies preserve :authority and correct scheme for downstream auth logic.

• Tune HTTP/2 max concurrent streams and flow windows if using high-volume streaming (gRPC).

Infra / Platform

• Roll out HTTP/3 via CDN toggle first—low risk.

• Track metrics: loss %, retransmissions, handshake times, p95 vs p99 request latency segments.

• Consider mTLS for internal re-encryption; align with Zero-Trust.

• Use Alt-Svc headers to advertise HTTP/3 (Alt-Svc: h3=”:443”; ma=86400).

How to Inspect Which Protocol You’re Using

Browser DevTools:

1. Open Network panel > right-click column header > enable “Protocol”.

2. Reload — look for h2, h3, or http/1.1

# Force HTTP/2
curl -I --http2 https://example.com

# Attempt HTTP/3 (curl must be built with nghttp3/quiche)
curl -I --http3 https://example.com

# Detailed HTTP/2 framing
nghttp -ans https://example.com

# QUIC packet-level trace (advanced)
sudo qlogctl … (platform-specific) 

Minimal Nginx Config Examples

HTTP/2 Enablement (production-stable):

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/ssl/fullchain.pem;
    ssl_certificate_key /etc/ssl/privkey.pem;

    location / {
        root /var/www/html;
        index index.html;
    }
}

HTTP/3 (QUIC) Example (requires nginx-quic or alternative like Caddy):

server {
    listen 443 ssl http2;
    listen 443 quic reuseport;

    server_name example.com;

    ssl_certificate     /etc/ssl/fullchain.pem;
    ssl_certificate_key /etc/ssl/privkey.pem;

    add_header Alt-Svc ‘h3=”:443”; ma=86400’;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Note: Mainline Nginx may not yet include native QUIC in all distributions—verify your build.

Closing Thought

Every upgrade of HTTP rewired how the web feels.
HTTP/2 gave us speed through multiplexing.
HTTP/3 gave us resilience through QUIC.
TLS 1.3 and Zero-Trust made every hop secure by design.

We don’t code the protocol —
But it decides how fast, safe, and seamless our code feels to the world.

If you want to learn above detail, as part of mentoring conversation reach back to us at prabodh

Want to understand the mathematical foundations of one of the most important cryptographic systems in the digital world? read through this article …

Introduction

This article explores RSA cryptography from a mathematical perspective, designed to bridge the gap between pure mathematics and its real-world applications in computer science. Through clear explanations and practical examples, we'll discover how elegant

mathematical concepts like prime numbers, modular arithmetic, and Fermat's Little Theorem come together to create one of the most important encryption systems in the digital world.

RSA was developed by Ron Rivest, Adi Shamir, and Leonard Adleman at the Massachusetts Institute of Technology (MIT) in 1977. This asymmetric cryptosystem revolutionized secure communication by using the mathematical difficulty of factoring large composite numbers as its foundation.

Foundation Concepts: Prime Numbers and Coprimality

Before diving into RSA, let's establish the fundamental mathematical building blocks.

Prime Numbers

A prime number is a natural number greater than 1 that has exactly two distinct positive divisors: 1 and itself.

Examples:

1. 5 is prime because its only factors are 1 and 5

2. 17 is prime because it cannot be divided evenly by any number except 1 and 17

Note: The number 1 is not considered prime because it has only one factor (itself).

Coprime Numbers

Two integers a and b are coprime (or relatively prime) if their greatest common divisor equals 1:

gcd(a, b) = 1

This means they share no common positive factors other than 1.

Examples:

1. (8, 15) are coprime because:
     Factors of 8:  {1, 2, 4, 8}
     Factors of 15: {1, 3, 5, 15}
     Common factors: {1} only

2. (8, 12) are NOT coprime because they share factors 2 and 4 besides 1

Division and Modular Arithmetic

Understanding Division with Remainders

When we divide one integer by another, we can express the relationship using the division algorithm:

Where:

• B is the dividend (number being divided)

• A is the divisor

• q is the quotient (how many times A goes into B)

• r is the remainder (what's left over)

Important constraint: 0 ≤ r < A (the remainder is always less than the divisor)

Examples:

1. A = 4, B= 12 : We get 12 = 3 × 4 + 0, so q= 3, r = 0
2. A = 4, B= 13 : We get 13 = 3 × 4 + 1, so q= 3, r = 1

Modular Arithmetic

Modular arithmetic is the mathematics of remainders. When we divide B by A, we write: B mod A = r

By the division algorithm, there exist integers q and r such that:

Key Properties:

• The remainder ‘r’ is unique when 0 ≤ r < |A|

• We use the notation B ≡ C (mod A) meaning B and C are congruent modulo A

• This means B and C leave the same remainder when divided by A

• Congruence modulo A is an equivalence relation (reflexive, symmetric, transitive)

The Circular Nature of Modular Arithmetic

Modular arithmetic behaves like circular (clock) arithmetic: residues 0 to A− 1 sit on a cycle and operations wrap around when they reach A.

Figure 1: Modular arithmetic cycle for x mod 4, showing how numbers with the same remainder are grouped together

For example, if we consider x mod 4 where x > 0, we see a natural cycle:

• 1 mod 4 = 1, 5 mod 4 = 1, 9 mod 4 = 1, 13 mod 4 = 1

• 2 mod 4 = 2, 6 mod 4 = 2, 10 mod 4 = 2, 14 mod 4 = 2

• 3 mod 4 = 3, 7 mod 4 = 3, 11 mod 4 = 3, 15 mod 4 = 3

• 4 mod 4 = 0, 8 mod 4 = 0, 12 mod 4 = 0, 16 mod 4 = 0

Figure 2: Concentric circle representation showing how 8 mod 4 = 0, demonstrating the cyclical nature of modular arithmetic

These visual representations help us understand that modular arithmetic creates natural groupings or "equivalence classes" of numbers that share the same remainder.

Cryptography Fundamentals

Cryptography is the science of protecting information by transforming it so that only authorized parties can access it.

Key Terms:

• Plaintext: The original, readable message

• Ciphertext: The encrypted, protected message

• Encryption: The process of converting plaintext to ciphertext

• Decryption: The process of recovering plaintext from ciphertext

Building Up to RSA: Simple Cipher Examples

Additive Cipher (Caesar Cipher)

The Caesar cipher shifts each letter by a fixed number of positions in the alphabet using modular arithmetic.

Encryption Formula:

C = (P − 65 + k) mod 26 + 65

Where:

• P = ASCII value of plaintext letter

• C = ASCII value of ciphertext letter

• k = shift key (0− 25)

Decryption Using Additive Inverse

To decrypt, we need the additive inverse of the key k in mod 26 arithmetic.

By definition, the additive inverse of k is the number -k such that:

k + (-k) ≡ 0 (mod 26)

Practically, this means:

additive inverse of k mod 26 = (−k) mod 26

General formal for finding additive inverse of k mod n is
(−k) mod n = ( n − (k mod n) ) mod n;

(-k) mod 26 = (26 - (17 mod 26 ) mod 26;
(-k) mod 26 = (26 - 17) mod 26 = 9 mod 26;

∴ additive inverse of 17 mod 26 is 9 mod 26

Decryption Formula:
P = ( (C - 65) + 9 ) mod 26 + 65; 

getting the plain text from above cipher values is left as an exercise to the reader.

The Concept of Modular Inverses

The "walk forward until you return home" principle applies to different types of operations:

Multiplicative Inverse

The multiplicative inverse of modulo n is a number a^-1 such that:

a × a−1 ≡ 1 (mod n)

Example: In mod 7 , we have 3 × 5 = 15 ≡ 1 (mod 7), so 5 is the multiplicative inverse of 3.

Exponential Inverse

In RSA, we use the fact that raising to some power e can be "undone" by raising to another power d, provided:

e × d ≡ 1 (mod φ(n))

Fermat's Little Theorem: The Foundation for RSA

Fermat's Little Theorem states that if p is prime and a is not divisible by p, then:

a^p−1 ≡ 1 (mod p)

Euler's Theorem (generalization): If gcd(a, n) = 1, then:

aφ(n) ≡ 1 (mod n)

Where φ(n) is Euler's totient function, counting how many numbers ≤ n are coprime to n.

Key Formulas:

• For prime p: φ(p) = p− 1

• For product of two primes: φ(pq) = (p− 1)(q− 1)

• The generalised formula for the total of Euler’s totient function for any positive integer is:

  Where p1, p2, …,pk are the distinct prime factors of

Example: For n = 10 = 2 × 5 :

The numbers 1, 3, 7, 9 are exactly the four integers between 1 and 10 that are coprime to 10.

RSA Cryptosystem: A Complete Walkthrough

Now let's see how all these mathematical concepts come together in RSA:

The security of RSA relies on the difficulty of factoring n back into its prime components p and q.

Why This Matters: φ(n) counts how many numbers from 1 to n are coprime with n. This creates the mathematical space where our encryption/decryption exponents will operate.

RSA String Encryption Demo, Pick two distinct primes from this set:
11 13 17 19 23 29 31 37 41 43 47 53

Step-by-Step RSA Implementation, Let's work through RSA using p = 13 and  q = 17:

Step 1: Build modulus n = p × q;  n = p × q = 13 × 17 = 221
Step 2: Euler's Totient φ(n) = (p-1)(q-1)
        φ(n) = (13-1)(17-1) = 12 × 16 = 192
Step 3: Choose public exponent e with gcd(e, φ(n)) = 1
        Count of valid public exponents e in [2, φ(n)-1]:  
        φ(n)=(p−1)(q−1)=12⋅16=192; 
        φ( φ(n) ) = φ(192) = 64; 
        Some valid e values: 5 7 11 13 17 19 23 25 29 31 35 37

        Selected: e = 5
Step 4: Compute private exponent d = e⁻¹ (mod φ(n))
        d is the modular inverse of e modulo φ(n)

        e × d ≡ 1 (mod φ(n)) → 5 × 77 ≡ 1 (mod 192)
        Therefore: d = 77

Public Key  : (e = 5, n = 221)
Private Key : (d = 77, n = 221)

Encryption and Decryption Demo

Now let's encrypt the message "HELLO":

Demo: Encrypt/Decrypt a string message

Mathematical Verification

Encryption Formula:

C = P^e mod n = P⁵ mod 221

• H (72): 72⁵ mod 221 = 89 ✓

• E (69): 69⁵ mod 221 = 205✓

• L (76): 76⁵ mod 221 = 111✓

• O (79): 79⁵ mod 221 = 27 ✓

Decryption Formula:

P= C^d mod n = C⁷⁷ mod 221

• 89⁷⁷ mod 221 = 72 (H) ✓

• 205⁷⁷ mod 221 = 69 (E) ✓

• 111⁷⁷ mod 221 = 76 (L) ✓

• 27⁷⁷ mod 221 = 79 (O) ✓

Why RSA Decryption Works

The mathematical elegance of RSA lies in Euler's theorem. Since we choose e and d such that:

e × d ≡ 1 (mod φ(n))

This means e × d= 1 + k × φ(n) for some integer k.

Therefore: (P^e)^d = P^ed = P^1+kφ(n) = P × (P^φ(n))k

By Euler's theorem, if gcd(P , n) = 1, then P φ(n) ≡ 1 (mod n).

Thus:

P × (1)k ≡ P (mod n)

This guarantees that encryption followed by decryption recovers the original message.

Additional Mathematical Insights

φ(n) = 192 factors into: 2⁶ × 3¹
φ(φ(n)) = φ(192) = 64 = 192 × ∏(1 - 1/p) over its prime factors p

The factorization reveals that there are 64 valid choices for the public exponent e.

RSA Security, The Hard Problem

RSA's security relies on the integer factorization problem: given a large composite number n = p × q , it is computationally infeasible to find p and q when they are large primes (typically hundreds of digits long).

Why this matters:

• Anyone can see the public key (n, e)

• To decrypt without the private key d, one would need to factor n to find p and q

• With p and q, one could compute φ(n) and then find d

• Current factoring algorithms cannot handle sufficiently large n in reasonable time

From Toy Example to Real World

In this demonstration, n = 221 can be factored easily. But with real RSA:

• Key sizes are typically 2048 bits or larger

• Prime numbers p and q are hundreds of digits long

• Factoring such large n is computationally infeasible with current technology

RSA’s effective security is much less than its key size for example, 1024 ≈ 80 bits, 2048 bits RSA ≈ 112 bits, 3072 bits RSA ≈ 128 bits, and so on. Due to the mathematical structure and patterns within RSA keys, as well as the efficiency of integer factorization algorithms. we shall discuss on that in another article, that also covers Attack Algorithms, Symmetric Ciphers like AES and more.

Conclusion

RSA cryptography demonstrates the beautiful intersection of pure mathematics and practical computer science. Starting from elementary concepts like prime numbers and modular arithmetic, we've built up to understanding one of the most important cryptographic systems in use today.

Key insights:

• Mathematical Foundation: Prime numbers and modular arithmetic provide the building blocks

• Elegant Design: Fermat's Little Theorem and Euler's theorem enable the encryption/decryption process

• Practical Security: The difficulty of factoring large numbers protects real-world communications

• Asymmetric Nature: Public and private keys enable secure communication without prior key sharing

This mathematical exploration illustrates how abstract mathematical concepts can have profound practical applications, protecting everything from online banking to private messaging in our digital world. The elegant interplay between number theory and

cryptographic security continues to be one of the most beautiful examples of applied mathematics in computer science.

If you want to understand more about practical applications using openssl or libsodium you can reach out to us at Prabodh.

References and Further Reading

Introduction to Modern Cryptography by Katz and Lindell

A Course in Number Theory and Cryptography by Neal Koblitz

Khan Academy's course on modular arithmetic

The original RSA paper: "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems" (1978)

What Is Yoodli?

At its core, Yoodli is a personal AI speech coach that delivers private, real-time feedback on your communication. Whether you’re preparing for a keynote, a sales pitch, or a tough feedback session, it gives you the kind of insights usually reserved for professional coaches—only here, it’s always available and tailored to you.

Yoodli's Core Modes of Practice

Yoodli offers multiple ways to practice and grow, depending on your needs:

• Pitch/Presentation Mode – Record your talk, review detailed feedback, and even practice with AI-generated follow-up questions.

• Interview Mode – Choose a job role, set your interviewer’s demeanor, and experience dynamic Q&A practice.

• Roleplay Mode – Rehearse crucial conversations—like asking for a raise or handling conflict—with AI stepping into the other role.

• Video Call Coaching – Yoodli can join live Zoom, Teams, or Google Meet calls, offering subtle nudges such as “slow down” or “avoid filler words.” While it takes some getting used to during deep discussions, it can dramatically improve live performance.

• Desktop App Feedback – On Windows or macOS, record conversations and receive instant, private coaching.

What Makes Yoodli Stand Out?

Real-Time, Judgment-Free Feedback

Think of Yoodli as a smart mirror for communication. It transcribes your speech and provides instant analytics on filler words, pacing, clarity, and tone—without criticism, just data-driven guidance.

Focused on Both Content and Delivery

Most tools flag tone or speed, but Yoodli goes further—helping you refine what you say and how you say it. From rephrasing unclear ideas to sharpening delivery, it covers the full spectrum of effective communication.

Realistic Roleplay Scenarios

Instead of rehearsing alone, you engage with an AI that reacts, questions, and even challenges you—simulating real dialogue in a risk-free environment.

Personalized Progress Tracking

Over time, Yoodli tracks your growth: filler word reduction, pacing improvements, clarity gains, and confidence trends. You don’t just feel progress—you see it.

Sample Scenarios Where Yoodli Shines

• Public Speaking: Record a TED-style talk and refine both substance and style.

• Crucial Conversations: Practice negotiating a raise, addressing conflict, or giving feedback in a safe environment.

• Sales & Business: Sharpen your pitch and delivery before you walk into the real deal.

✨ Takeaway

We’re entering an era where AI isn’t just crunching numbers—it’s helping us become better humans in conversation. With the right feedback loop, practice isn’t just for musicians or athletes. You can practice your words, your tone, your confidence—and show up as the best version of yourself.

At Prabodh, we don’t just design engaging workshops—we strive to make you more successful by discovering and sharing the tools that give you an edge.

👉 Curious to see how Yoodli works? Try it out here and start transforming the way you communicate.

When React introduced Hooks in 2019, it changed the way we thought about building components. Suddenly, we could manage state and side effects in functional components without juggling class lifecycle methods. Hooks like useState and useEffect became the bread and butter of modern React development.

But as applications grow, developers are bumping into the limits of Hooks: unnecessary re-renders, complicated dependency arrays, and performance bottlenecks in fine-grained updates.

This is where Signals come in. Signals don’t replace Hooks—they complement them—and offer a fresh approach to reactivity that’s already gaining traction in frameworks like SolidJS, Angular, and even experiments in React’s ecosystem.

A Quick Recap: React Hooks

Here’s the classic way we handle state with Hooks:

import { useState } from "react";

function Counter() {

  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count is {count}
    </button>
  );
}

This works beautifully. But if this count state was passed deep into multiple child components, React would need to re-render all of them whenever count changes—even if they don’t directly use it.

What Are Signals?

A Signal is a special kind of state container.
Think of it like a box that holds a value, and whenever the value changes, only the places that use it update—no unnecessary re-renders.

Here’s the same counter implemented with Signals (example using @preact/signals-react):

import { signal } from "@preact/signals-react";

const count = signal(0);
function Counter() {

  return (
    <button onClick={() => count.value++}>
      Count is {count.value}
    </button>
  );
}

Notice a few things:

• No useState.

• No re-rendering the entire component tree.

• Only the parts of the UI that directly read count.value update.

Why Signals Complement Hooks

Instead of replacing Hooks, Signals solve some of their shortcomings:

1. Fine-grained reactivity

• Hooks: Changing state re-renders the whole component.

• Signals: Only the elements that read the signal update.

2. No dependency arrays

• With useEffect, we manually track dependencies:

useEffect(() => {
  fetchData(query);
}, [query]);

• With Signals, the system knows what depends on what, so no arrays are needed.

3. Global state without Context

• Instead of setting up a React Context and a provider, a signal can be imported and shared anywhere:

export const user = signal(null);

Any component reading user.value will automatically update when it changes.

Signals + Hooks in Practice

The sweet spot is using both together.

For example, keep Hooks for local component state, and Signals for global/shared reactive data:

import { signal } from "@preact/signals-react";
import { useState } from "react";

const theme = signal("light");
function Toolbar() {
  const [open, setOpen] = useState(false);

  return (
    <div>
      <button onClick={() => setOpen(!open)}>Menu</button>
      <button onClick={() => theme.value = theme.value === "light" ? "dark" : "light"}>
        Toggle Theme
      </button>

      <p>Theme is: {theme.value}</p>
    </div>

  );

}

• open (local UI toggle) works great with useState.

• theme (shared across the app) is better suited for a Signal.

The Road Ahead

React’s own team is experimenting with concepts like React Forget (a compiler that could make Hooks behave more like Signals under the hood). Meanwhile, libraries like @preact/signals-react are giving us a glimpse of the future.

If Hooks gave us a declarative way to manage state, Signals give us a more efficient and predictable reactivity model. Together, they create a developer experience that’s both powerful and ergonomic.

✨ Closing Thoughts

Hooks aren’t going anywhere. They’re still the foundation of React apps. But Signals add a new layer:

• Fewer re-renders

• Cleaner reactive code

• A simpler way to manage shared state

Think of Hooks as the engine, and Signals as a turbocharger.

The next time you find yourself struggling with complex useEffect dependencies or heavy global state management, give Signals a try—you may find they make your React codebase feel lighter and faster.