DEV Community: Danish ali siddiqui

The same Rust gave two different answers, and neither matched JavaScript

Danish ali siddiqui — Tue, 18 Aug 2026 08:45:11 +0000

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

Demo Video

The setup

I was porting TinyColor, a fifteen-year-old JavaScript colour library, to Rust. The rule I set myself was that the original test suite had to pass unmodified. Not a translation of it. The actual file, byte for byte, sha256-pinned, loading my Rust instead of the JavaScript.

That works because upstream's test file loads the library on exactly one line:

const tinycolor = require("./tinycolor.js");

So I compiled the Rust to WebAssembly, put a shim at that path, and let the suite run. Forty-four of forty-five tests passed on the first try.

The forty-fifth is what this post is about.

One bit

readability("#000", "#111")

expected  1.1121078324840545
got       1.1121078324840543

Two doubles that differ in the last place. That's the smallest possible disagreement between two f64 values, and there's no smaller one to find.

It's also an unusual thing for a test to catch, because most test suites don't compare floats exactly. They use an epsilon. TinyColor's suite asserts the literal value to sixteen decimal places, which struck me as fragile when I first read it and turned out to be the reason I found any of this.

readability is a WCAG contrast ratio, and it's built on relative luminance:

function getLuminance() {
  var rgb = this.toRgb();
  var R = rgb.r / 255 <= 0.03928
    ? rgb.r / 255 / 12.92
    : Math.pow((rgb.r / 255 + 0.055) / 1.055, 2.4);
  // same for G and B
  return 0.2126 * R + 0.7152 * G + 0.0722 * B;
}

One Math.pow per channel. That's the whole surface area.

What I assumed, and why I was wrong

My first theory was rounding. My port has a whole module reproducing JavaScript's numeric quirks, because they bite constantly: Math.round(-1.5) is -1 in JS and -2 in Rust, parseFloat("50%") is 50 rather than an error. I'd already been caught by both. So a rounding difference in luminance felt like more of the same, and I went looking for one.

There wasn't one. The arithmetic was identical. I printed intermediate values at full precision and they matched all the way to the pow call.

Then I ran the same code natively instead of through WebAssembly, mostly out of frustration.

native Rust        1.1121078324840545   ← matches JavaScript
the same Rust,
compiled to WASM   1.1121078324840543   ← doesn't

Same source file. Same input. Different answer.

That reframed the whole thing. I'd been looking for a bug in my code, and my code was fine. The disagreement was underneath it.

Math.pow is not one function

Math.pow isn't defined to be bit-exact. IEEE 754 mandates correct rounding for add, subtract, multiply, divide and square root. Transcendental functions like pow are explicitly left alone, because a correctly-rounded pow is expensive and nobody wanted to require it.

So every implementation makes its own accuracy-versus-speed trade, and they disagree in the last bit or two:

V8 uses its own port of fdlibm
Rust on macOS calls the system libm, which is Apple's
Rust on wasm32 has no system libm, so it links a MUSL-derived implementation

Three different pows. I was comparing two of them against a third.

Since getLuminance only ever sees integer channel values, I could check the whole input space rather than guess. All 256 of them, against V8:

implementation	matches V8 exactly
Rust std `powf` (macOS libm)	207 / 256
Rust std `powf` (wasm32, MUSL)	225 / 256
V8 (fdlibm)	the reference

Neither one matches. Not "close enough" — they each disagree with V8 on a few dozen of the 256 possible inputs, and they disagree on different ones.

That was the moment the bug stopped being annoying and got interesting. There was no libm I could pick that would be right. Switching to the MUSL version would have fixed 18 more cases and broken others.

The fix was in the question, not the answer

I'd been asking "which pow do I use." Wrong question.

Look again at what feeds it:

var rgb = this.toRgb();   // r, g, b are ROUNDED here
Math.pow((rgb.r / 255 + 0.055) / 1.055, 2.4);

toRgb() rounds. So rgb.r is always an integer from 0 to 255. pow never sees anything else. Ever.

That isn't a function call with a continuous domain. It's a lookup with 256 possible inputs, and I'd been treating it as maths because it was written as maths.

So I generated the table. Ran V8 once over all 256 channel values, captured the exact f64 bit patterns, and emitted them as Rust:

pub static SRGB_LINEAR: [u64; 256] = [
    0x0000000000000000, // 0 -> 0
    0x3f33e45677c176f7, // 1 -> 0.0003035269835488375
    0x3f43e45677c176f7, // 2 -> 0.000607053967097675
    // ... 253 more
];

pub fn srgb_linear(channel: f64) -> Option<f64> {
    if channel.fract() != 0.0 || !(0.0..=255.0).contains(&channel) {
        return None;   // outside the domain: fall back to computing it
    }
    Some(f64::from_bits(SRGB_LINEAR[channel as usize]))
}

Bit patterns rather than decimal literals, so nothing depends on how a float parser rounds the text.

The test passed. And so did the other 44, on both build targets, which is the part that matters: the port stopped being sensitive to what it was compiled for.

It's also faster than calling pow, though that was luck rather than design.

The thing I keep thinking about

The test that caught this looked like bad practice. Asserting a float to sixteen decimal places is exactly what you're told not to do, and if TinyColor had used an epsilon like a sensible person, my port would have shipped with a silent cross-platform inconsistency that no test anywhere would have found.

I'd have had a colour library that computed contrast ratios differently depending on whether you ran it natively or in a browser. It would never have shown up as a bug. Just two systems quietly disagreeing about whether some text passes WCAG AA.

I'm not going to argue everyone should assert exact floats. But the strict version of that test found something a tolerant version couldn't, and I've stopped assuming an epsilon is always the grown-up choice.

The other lesson is cheaper: check the domain before optimising the function. I spent a couple of hours on which pow implementation to trust, and the answer was that the question didn't apply, because the input space was 256 values and had been the whole time.

The port, and a decision log with 22 of these written up: github.com/BigAchiever/tinycolor-rs

analogous(-1): how a default hid a heap-exhaustion bug for fifteen years

Danish ali siddiqui — Mon, 17 Aug 2026 18:07:37 +0000

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

Project Overview

TinyColor is a colour library for JavaScript. Parse a colour in basically any format, convert it, lighten it, generate a palette from it. It's fifteen years old, has 5.2k stars, and ships on npm as tinycolor2 underneath a lot of design tooling.

I found this while porting it to Rust. I'd built a differential fuzzer for the port: run the original on V8 and my version side by side, same inputs, compare the outputs bit for bit. Thirty-one million comparisons, zero disagreements in the colour maths.

It found nothing here though. Not because the code is fine, but because for these inputs the original doesn't return a wrong answer. It doesn't return at all, and you can't diff against a process that's died.

Bug Fix or Performance Improvement

analogous(results) and monochromatic(results) loop forever on a negative or fractional count, and take the heap with them.

Both decrement a counter and test it for truthiness:

// analogous
for (hsl.h = (hsl.h - (part * results >> 1) + 720) % 360; --results; ) { ... }

// monochromatic
while (results--) { ... }

A counter that never lands exactly on 0 never stops. From 1.5 the sequence goes 0.5, -0.5, -1.5, -2.5…. From -1 it goes -2, -3, -4…. Every pass pushes another colour object onto an array nobody will ever read.

$ node --max-old-space-size=256 -e "require('tinycolor2')('red').analogous(-1)"

<--- Last few GCs --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

$ echo $?
134

Six cases, all exit 134: both functions at -1, 1.5 and 0.5.

Here's the part that makes it worth guarding rather than shrugging at. polyad() is the third combination function, sitting in the same file, taking the same shape of argument. It already validates:

if (isNaN(number) || number <= 0) {
  throw new Error("Argument to polyad must be a positive number");
}

So the hazard is recognised in one of the three and not the other two. Any caller passing a user-supplied palette size into analogous() or monochromatic() has an unauthenticated way to kill the process. A number field in a colour picker. A value out of a config file. No exotic input needed, just a minus sign.

Code

Issue: bgrins/TinyColor#280
Pull request: (link)

 function analogous(color, results, slices) {
   results = results || 6;
   slices = slices || 30;

+  if (isNaN(results) || results <= 0) {
+    throw new Error("Argument to analogous must be a positive number");
+  }
+
   var hsl = tinycolor(color).toHsl();
   var part = 360 / slices;
   var ret = [tinycolor(color)];

   for (hsl.h = (hsl.h - ((part * results) >> 1) + 720) % 360; --results; ) {
     hsl.h = (hsl.h + part) % 360;
     ret.push(tinycolor(hsl));
   }
   return ret;
 }

 function monochromatic(color, results) {
   results = results || 6;
+
+  if (isNaN(results) || results <= 0) {
+    throw new Error("Argument to monochromatic must be a positive number");
+  }
+
   var hsv = tinycolor(color).toHsv();

Tests mirroring the ones polyad already has:

assertThrows(() => { tinycolor("red").analogous(-1); });
assertThrows(() => { tinycolor("red").analogous(1.5); });
assertThrows(() => { tinycolor("red").monochromatic(-1); });
assertThrows(() => { tinycolor("red").monochromatic(0.5); });

My Improvements

Why nobody hit this in fifteen years

This is the bit I found genuinely interesting, and it's why I nearly dismissed my own bug report.

My first three probes came back clean. analogous(0) returns six colours. analogous(null) returns six. analogous(NaN) returns six. I assumed I'd fat-fingered the argument and moved on, and only came back to it an hour later because the shape of "some counts are fine" bothered me.

The answer is on the first line of the function:

results = results || 6;

That's a default, not a guard. But it happens to catch almost everything a developer would think to try:

you pass	truthy?	loop actually gets	outcome
`0`	no	`6`	fine
`null`	no	`6`	fine
`undefined`	no	`6`	fine
`NaN`	no	`6`	fine
`false`	no	`6`	fine
`-1`	yes	`-1`	heap death
`1.5`	yes	`1.5`	heap death
`0.5`	yes	`0.5`	heap death

Every falsy value gets swapped for 6 before the loop ever sees it. The default is accidentally guarding the entire class of input you'd reach for first.

So the function is safe for every value you'd casually try and unsafe for the ones you wouldn't. That's a nasty shape for a bug: it hides from exactly the person looking for it.

Checking the blast radius

analogous takes a second argument, slices, guarded the same lazy way with slices || 30. I assumed it had the same hole and it doesn't. slices only feeds part = 360 / slices, so a bad value gives you a wrong hue or a NaN channel, but the loop is driven entirely by results. slices at -1, 1.5 and NaN all return six colours and terminate.

Worth checking rather than assuming, and it let me narrow the report instead of overclaiming.

Guard, or coerce?

Two ways to fix it:

Guard and throw, the way polyad() does.
Coerce with results = Math.max(1, Math.floor(results)).

Coercion is friendlier to anyone currently passing 1.5 and getting something back. But it silently changes their result and buries the mistake, and I don't think a colour library should be quietly reinterpreting your arguments. The guard also matches what the same file already does for the same input, so a maintainer can merge it without deciding a new policy. Consistency inside a codebase beats my personal taste in error handling.

Verifying before filing

I checked against current main, not just the copy I'd vendored: byte-identical, both loops still there, all six cases still exit 134. Then I read a hundred existing issues looking for a duplicate. Closest are #116 and #204, neither of which is this.

The PR is open rather than merged, and I'll be straight about why: TinyColor hasn't merged anything since February 2023.

What my port does instead

It returns a finite list. analogous(-1) gives one entry, 1.5 gives two.

That's the single deliberate behavioural divergence in an otherwise bit-exact port, documented as D-022 in the decision log. Reproducing the original faithfully would've meant shipping a denial of service on purpose. And there's nothing to reproduce anyway: the original doesn't return something wrong here, it stops existing.

The port, the decision log, and the fuzzer that sent me looking: github.com/BigAchiever/tinycolor-rs

How do you form a group nobody can admit they're in?

Danish ali siddiqui — Sun, 16 Aug 2026 21:37:08 +0000

Arun invoiced a design agency ₹1,20,000 in January. It's August.

He is in a 4,000-member designers' Discord. He could post the agency's name right now and warn everyone. He won't, and you already know why: the freelancer who publicly names a client stops getting briefs. He'd pay for it alone, and everyone else would benefit.

Here's the part that makes it a systems problem rather than a sad story. Three other people in that same Discord are owed money by that same agency. None of them knows. Each one is running the same arithmetic Arun is, arriving at the same answer, and saying nothing.

Four people who together have real leverage. Individually, none of them can afford the first move.

I built an agent for this over a hackathon weekend. The interesting part wasn't the AI. It was that every obvious solution destroys the thing you're trying to protect.

The obvious version, and why it dies

"Just make a private channel for victims of bad clients."

To join, you say who burned you. Now the group knows. One screenshot and Arun is on a list.

"Okay, collect reports centrally and only reveal at a threshold."

Better. This is roughly how Callisto Vault handles assault reports, and it's a good pattern. But it reveals the group to its own members at the threshold. Four people now know each other's names and amounts. Four times the leak surface, arriving exactly when things get tense.

The requirement I ended up with was stricter than I expected:

Nobody is exposed. Not to the channel, not to the accused, and not to each other — not even after it works.

Which sounds impossible, because how do four people coordinate if they can't know who they are?

They don't. The agent knows. Nobody else does.

The public board that can't name the client

Here's what actually appears in the Discord:

PICKET · matter #1
> "invoiced in January, still chasing in August"
₹50k–2L · 180d+ overdue

🟩⬜⬜⬜  1/4 joined
[ JOIN ]

One sentence Arun wrote himself. An amount band, not his figure. A counter. The agency's name is nowhere on it, in any state, ever.

That's the whole trick, and it's easy to misread as "we're being cautious". It isn't caution. The accused agency might be in that Discord. The board has to be safe to read for the very person it's about.

So the board can't tell you who it is. Which raises the obvious problem: how does a real fellow-victim recognise it?

They don't recognise it. They guess. And then they prove it.

You tap JOIN, and the agent DMs you the intake steps: email us, and name the client yourself.

That's the admission test. Not a password, not an invite code. It's the one thing only someone in the same situation would know. Get it right and your pip fills. Get it wrong and your claim is held, sealed, and nobody is told anything. Crucially you don't learn whether you guessed right, so nobody can use the system to fish for the name.

The column I refused to write

When you tap JOIN, the bot knows your Discord identity. When you email, it knows your address. Storing discord_id → claimant_id would be one line and would make a dozen features easier.

That line is the entire attack surface. One leaked table and every claimant is public.

So the bot never says who tapped, and the join reply is written to be impossible to personalise:

def render_join_instruction(v: MatterPublic, intake_address: str) -> str:
    # Deliberately does NOT name who tapped: a Discord button tap is invisible
    # to other members, and naming the tapper here would be the exact
    # first-mover exposure this system exists to prevent.

There's a side effect I like: you can tap JOIN twice and the bot won't remember you. It looks like a bug. It's the guarantee, visible. To recognise you, it would have to have stored the link it promised not to store.

Negotiating for people you never introduce

At four matching claims, one email goes to the agency: four documented claims, the combined total, the age of the oldest. No names.

The agency offers 60%. And this is where the design either holds or collapses.

The tempting move is a group thread: "they've offered 60%, what do we all think?" Convenient, and it hands everyone's identity to everyone else at the worst possible moment.

Instead each claimant gets their own sealed email:

For your claim it means: ₹72,000 (60% of your ₹1,20,000)

Their slice. Their decision. Three accept, one refuses. Three claims settle, one stays open independently. Nobody was outvoted, because there was never a vote. The client is told "3 of 4 accepted", not which three.

They still don't know each other. That's not a limitation of the build. That's the product.

Two problems I didn't see coming

Who decides admission? Matching "that media agency in Andheri, the blueprint one" to Blueprint Media Pvt. Ltd. is exactly what an LLM is good at. So my first version asked the model: does this claim belong? That makes a hallucination-prone component the doorman for a group of people trying to stay hidden.

The fix is one word. The model is never asked "should this be let in?", only "which of these existing things does it look like, if any?" Admission is then if key != matter.canonical_key. I tested it with "Blueprint Constructions". Same first word, different company. Returns None. Not because the prompt asks nicely, but because the comparison happens in Python.

Same rule everywhere: the model can read a messy claim, read the attached invoice, classify a reply. It cannot let anyone in, move any state, or put a number in an outgoing email. When the client writes "sixty percent", the 60 is only used because code checks that number literally appears in their own sentence.

Why should the agency believe any of this? Their reasonable reply to "four people are owed money" is: prove it isn't one person with four inboxes and a good afternoon.

I reached for a hash chain first. It proves nothing. I control the whole thing and can rebuild it in a second with any timestamps I want. It's a diary that catches you erasing a page, written by the person holding the pen.

What saved it was already there: the comms gateway stamps every event with a monotonic sequence number that I don't issue and can't move. So every ledger row stores the seq that caused it, and a verifier re-fetches them:

[3] independence: last claim admitted at seq 21392,
    first client REPLY at seq 21420
    -> claims PRECEDE the client's first reply ✓

The four claims existed before the agency was ever contacted, and that ordering is enforced by infrastructure I don't own. They don't have to trust me. They have to trust that I can't rewrite someone else's log.

If your system makes a claim about time or order, anchor it to a counter you don't control.

Three things that bit me

A card body that vanished. Posting a Discord card with a body rendered the title and button and silently dropped the body. Because edits are text-only, the board looked correct from its second update onward — so the bug only appeared on a tile's very first render. Which is the exact frame a demo video opens on.

A poller that ate its own history. My event cursor defaulted to 0. Delete the local DB, restart, and the agent replays every event the project has ever seen, reopening closed cases and re-posting their public messages. If your poller has a cursor, decide what a missing cursor means, and make it mean "now".

Being right and not recognising it. I added a vision model that reads the attached invoice and rejects a claim if the document disagrees. Then a test claim said ₹95,000 while its invoice said ₹1,20,000, and my system refused it. I debugged the "bug" for a minute before realising it was working.

The thing worth taking

The hard constraint turned out to be generative rather than limiting. Nobody may be exposed to anybody forced the amount bands, the name-it-yourself admission test, the column I didn't write, and the sealed per-person negotiation. Every one of those is a better design than what I'd have built without the constraint.

If you're building something where people have to cooperate but can't afford to be seen cooperating — whistleblowing, wage disputes, deposit disputes, bad-landlord registries, the shape is reusable: a public counter, a private admission test only a real participant can pass, and an agent that acts on the group's behalf without ever assembling it.

Code: github.com/BigAchiever/Picket

What would you have done differently? I'm most unsure about the guess-and-prove admission test — it works, but it assumes enough density that guessing is worth someone's time.

GitHub doesn't retry webhooks. So I gave my tunnel a database.

Danish ali siddiqui — Sun, 09 Aug 2026 19:42:34 +0000

Built solo over a weekend for the WeMakeDevs × Zerops challenge. There's a live gateway you can poke at, and a section near the end about what it can't do.

I was testing a GitHub integration with a tunnel open to my laptop. I shut the lid to go get coffee. When I came back, the push event was gone.

Not delayed. Not sitting in a queue somewhere. Gone.

I figured I'd misconfigured something. I hadn't. From GitHub's own docs:

"GitHub does not automatically redeliver failed deliveries."
— docs.github.com

One failed delivery and it's your problem, unless you open the UI and redeliver by hand.

I checked other providers, expecting GitHub to be unusual. It isn't:

Provider	What happens when your tunnel is down
GitHub	No automatic retries at all
Stripe (test mode)	3 attempts over a few hours
Shopify	8 attempts over 4 hours, then deletes your webhook subscription

Read the last one again. Shopify doesn't just give up on the event. It unsubscribes your app.

The part nobody tells you about tunnels

Here's what I hadn't thought about properly. A tunnel turns your laptop into production infrastructure for somebody else's system.

Senders don't wait for you. A customer checks out at 2am. CI finishes after you've left for lunch. Your wifi drops for thirty seconds on a train.

When that happens the sender gets a 502. It burns one of the three or four attempts it was ever going to make, and then the event is gone.

Someone is about to say "ngrok already has replay." It does, and it's good. But ngrok can only replay a request it already saw, which means you were connected when it arrived. The ones that hurt are the ones that arrive when you aren't.

That's structural, not a missing feature:

A tunnel is a pipe, not a mailbox. If nothing is listening at your end, the request has nowhere to go.

So I built the mailbox. It's called Doorbell, and it's a tunnel with a database in the path.

You can break it right now

You have to take my word for everything else in this post. This part you can check yourself.

I'm running a public gateway — the always-on server that holds tunnels open. It has a tunnel named shop with nothing connected to it, which is the same state as your laptop with the lid shut.

On a phone? Just open the live page and watch the held right now counter. At a keyboard, send it a webhook:

curl -i -X POST https://gw-2ad0-3000.prg1.zerops.app/t/shop/hook -d '{"n":1}'

HTTP/2 202

202 Accepted, where you'd expect a 502.

There is no laptop on the other end. Your request is now a row in Postgres, and it gets delivered the moment someone connects. Reload that live page and the counter is one higher. That's yours.

Now try a name nobody reserved:

curl -i -X POST https://gw-2ad0-3000.prg1.zerops.app/t/zzrandom99/hook -d '{"n":1}'

HTTP/2 404

That 404 matters as much as the 202. Only reserved names get held. If any name worked, anyone could fill my database by inventing URLs, and "we store everything" would just mean "free disk for strangers."

And here's what you get back when you reconnect:

$ doorbell -name demo 3000
  https://gw-2ad0-3000.prg1.zerops.app/t/demo/
  → forwarding to 127.0.0.1:3000

  ▲ requests held while you were away are arriving now
  ✓ 11:11:23 POST   /hooks/github    200  held 4s
  ✓ 11:11:23 POST   /hooks/github    200  held 2s
  ✓ 11:11:24 POST   /hooks/github    200  held <1s

Oldest first, each showing how long it waited.

Before you get excited: is this for you?

One thing you should know 30 seconds in rather than 10 minutes in.

A held webhook will fail a signature check. GitHub and Stripe sign each delivery so your app can prove it really came from them. Doorbell strips anything that looks like a signing header before writing the row, so the signature is gone by the time the request reaches you.

That's a deliberate trade. I'd rather hand you a request whose signature no longer verifies than keep someone's live signing secret sitting in my database. Held requests carry an X-Doorbell-Replay header, so you can skip verification when you see it.

If your handler verifies signatures and you can't branch on that header, this tool will annoy you. Better you know now.

Two more things, and then the good part:

You run this yourself. The gateway above is mine, for trying it. For real use you deploy your own from one YAML file, and nobody else's servers sit in the path of your traffic.
It's a development tunnel. Don't put it in front of production traffic.

What `202` actually means

This is where a lot of "reliable webhook" tooling quietly lies to you.

202 Accepted does not mean your app handled it. It means: I have taken responsibility for this request. The row is on disk before the sender gets any answer at all.

Two things make that promise real.

Ordering. Each tunnel's queue drains oldest first, one at a time. That's the only order your handler can make sense of. If the delete arrives before the create, your code does the wrong thing.

No duplicates. If you reconnect twice quickly, two drains could race for the same stored request and send the same webhook twice. A duplicate payment notification is somebody's real problem.

So the database decides, not the application. Claiming a request and marking it taken happen in a single SQL statement, so only one drain can ever win it. There's a test that runs eight of them at once to prove it:

if won != 1 {
    t.Fatalf("%d of %d claimers won the same row; every extra winner is a webhook delivered twice", won, racers)
}

The whole thing rests on one function

When you run doorbell 3000, the CLI opens a single outbound connection to the gateway and holds it open. Nothing listens on your machine. Nothing gets opened on your router.

It's like calling a support line. They can't call you. But while you're on the line, they can talk to you.

Each incoming request becomes its own stream on that one connection, using yamux to run many conversations down a single socket. The proxying itself is just Go's standard library, with one substitution:

Transport: &http.Transport{
    // The whole trick: instead of dialling a network address, open a
    // new multiplexed stream on the socket the laptop already holds open.
    DialContext: func(_ context.Context, _, _ string) (net.Conn, error) {
        return session.Open()
    },
},

Swap dial an address for open a stream and you're done. Chunked bodies, keep-alive and WebSocket upgrades all still work, because httputil.ReverseProxy is doing the actual HTTP.

The bug I shipped, and how I found it

Doorbell has a dashboard. It shows the request and response bodies it captured, and it can re-send any stored request to whoever's laptop is connected. Both were behind a token. Good.

The problem: that same token also guarded the port the CLI dials to open a tunnel. One check was answering two completely different questions. May you open a tunnel? and may you read everyone's payloads? ran through the same line of code.

So anyone I let tunnel through my gateway could also read every captured body on it, and re-send any of them.

The file's own doc comment said the opposite:

"Tunnels themselves are not gated by this — only the surfaces that expose captured request and response bodies."

The comment described the intent. The code did something else. Nobody catches that in review, because both call sites look correct on their own.

The fix was to split them:

// tokenOK gates the control port: may this client open a tunnel at all?
func (g *gateway) tokenOK(presented string) bool {
    if g.cfg.clientToken == "" {
        return true
    }
    return subtle.ConstantTimeCompare(...) == 1
}

// adminTokenOK gates the dashboard. Kept separate on purpose.
func (g *gateway) adminTokenOK(presented string) bool {
    return subtle.ConstantTimeCompare(...) == 1
}

Then I nearly made it worse.

The dashboard also accepts ?token= in the URL, and that path called tokenOK too. Look at what tokenOK does when no client token is set: it returns true for anything. My public gateway has no client token, on purpose, so anyone can tunnel. Which means ?token=literally-anything would have opened the dashboard to the first person who tried it.

I caught it before shipping. There's now a test whose only job is to fail if it comes back:

func TestGuessedQueryTokenCannotUnlockTheDashboard(t *testing.T) {
    g := gatewayWithTokens("", "operator-secret")
    if got, _ := reachedOperator(g, req("/dashboard?token=anything")); got {
        t.Fatal("?token=anything unlocked the dashboard on a public gateway")
    }
}

Two privileges, two tokens. Opening a tunnel is a small thing to be allowed to do. Reading what went through it isn't.

Why this can't run on most of the internet

Holding that connection open gives you two requirements you can't negotiate away:

A raw TCP port on the gateway. Plain TCP, not HTTP, because the client speaks its own protocol on it.
A process that never sleeps. It sits there holding the socket for hours.

Those two rule out every serverless platform, by definition. A function stops existing the moment it returns a response, so nobody is left holding the line. And a platform that handles HTTP for you can't give you a port that isn't HTTP.

I'll be straight with you, because a Fly.io user is already typing: Fly.io gives you a raw TCP port too. So does Railway. Zerops isn't magic here.

But the port was never the hard part. The hard part is the database. It's storing captured webhook bodies, so it must never face the internet, and I didn't want to spend a hackathon weekend wiring up a private network by hand to make that true.

Paste one YAML file into Zerops and about ninety seconds later you have a gateway, a Postgres, a Valkey and a private network between them, in your own account. (Valkey is a Redis fork. It tracks which gateway container currently owns which tunnel, so this still works when there's more than one.)

One assumption sat underneath all of it: that a raw TCP port on Zerops is genuinely reachable from the public internet. The docs said ports 10–65435 were available. But documented isn't measured, and if that line was wrong the whole project was dead. So before writing any of the gateway, I deployed a thirty-line echo server on port 7000 and dialled it from my laptop. It answered. That throwaway test is still sitting in my account next to the real project.

One honest note: that YAML can't open the raw port for you. Zerops' import format has no field for it, so it's still one click in the dashboard afterwards.

What still doesn't work

The signature thing above is the big one. Two more:

The CLI needs IPv6 to reach my public gateway. Webhooks don't — every curl in this post runs over ordinary IPv4, because that's HTTP going through Zerops' shared load balancer. A raw TCP port can't use that path, and Zerops won't publish raw ports on a shared IPv4. That leaves IPv6 or a paid dedicated IPv4.

Custom domains are written and unit-tested but have never run end to end. Proving that needs a real domain and a wildcard certificate, which I didn't have.

Things you're about to ask

How long are requests held? Until you reconnect. The cap is 200 per tunnel and 1 MB per body. Past 200 the oldest undelivered ones get dropped, because without a cap the table becomes a way to fill someone's disk.

Is the ordering per tunnel or global? Per tunnel. Each queue drains on its own.

Doesn't that eight-way race contradict the ordering? No. That's the test, hammering one row on purpose to prove only one claimer wins. The real drain loop is sequential.

What if two people connect with the same tunnel name? A reservation belongs to whoever made it. The second one gets the name "shop" is reserved by someone else.

Try it

The two curls at the top take about thirty seconds and need nothing installed. For your own tunnel:

go install github.com/BigAchiever/doorbell/cmd/doorbell@latest
doorbell -name pick-a-name 3000

🎥 4-minute demo
🌐 Live gateway
💻 Source (MIT)

CI fails the build if the Postgres and Valkey test suites skip, because a green run that quietly tested nothing is worse than a red one. That's the check I'm proudest of.

If you break it, I'd genuinely like to know how.

WhatsApp Knowledge Miner: Transforming Group Chats into a Searchable Knowledge Base

Danish ali siddiqui — Sun, 07 Sep 2025 10:12:36 +0000

In today's fast-paced digital communication landscape, WhatsApp has become a central hub for group discussions, brainstorming sessions, and knowledge sharing. However, the transient nature of these conversations often leads to valuable insights being lost amidst the chat clutter. Enter the WhatsApp Knowledge Miner, a tool designed to extract, organize, and transform your WhatsApp group chats into a structured, searchable knowledge base.

Project Overview

The WhatsApp Knowledge Miner is an open-source application that bridges the gap between unstructured WhatsApp group chats and structured knowledge management. By leveraging the WhatsApp Business API and advanced natural language processing (NLP) techniques, the application captures messages, analyzes their content, and converts them into question-answer pairs that can be easily searched and referenced.

🧩 Core Components
1. WhatsApp Bridge

The WhatsApp Bridge serves as the interface between your WhatsApp account and the application. It connects to your WhatsApp account and securely stores messages in a local SQLite database.

Setup:

cd whatsapp-bridge
go run main.go

Upon running, scan the QR code displayed to log in (similar to WhatsApp Web). The application will then begin capturing messages from your WhatsApp groups.
**

Message Capture and Storage**

Captured messages are stored in a local SQLite database, ensuring that all data remains secure and accessible. This local storage approach facilitates easy retrieval and analysis of messages without relying on external servers.

*3. Message Processing Server
*
The message processing server analyzes the captured messages to identify key information, such as questions and answers. Using NLP techniques, it extracts relevant content and organizes it into structured data.

*4. Streamlit Web Interface
*
The Streamlit web interface provides a user-friendly platform to interact with the processed data. Users can search for specific questions and view the corresponding answers, making it easy to access valuable information from past discussions.

🔧 Technical Highlights

Go (Golang): Used for building the WhatsApp Bridge, ensuring efficient and concurrent message capturing.

SQLite: Provides a lightweight and reliable local database for storing messages.

Natural Language Processing: Employed to analyze and extract meaningful information from unstructured messages.

Streamlit: Facilitates the creation of an interactive web interface for users to search and view Q&A pairs.

🧪 Installation and Usage

Clone the Repository:

git clone https://github.com/BigAchiever/whatsapp-knowledge-miner.git
cd whatsapp-knowledge-miner

Set Up the WhatsApp Bridge:

cd whatsapp-bridge
go run main.go

Scan the QR code to log in to your WhatsApp account.

Run the Message Processing Server:

Navigate to the whatsapp-mcp-server directory and start the server to begin processing captured messages.

Launch the Streamlit Web Interface:

In the streamlit-app directory, run the following command to start the web interface:

streamlit run app.py

Access the interface through your web browser to search and view Q&A pairs.

🌟 Key Features

Seamless Integration: Effortlessly connects to your WhatsApp account to capture messages.

Automated Q&A Extraction: Utilizes NLP to automatically generate question-answer pairs from conversations.

Local Data Storage: Ensures data privacy by storing messages in a local SQLite database.

Interactive Search Interface: Provides a user-friendly web interface for searching and viewing Q&A pairs.

Open Source: Freely available for modification and enhancement.

💡 Use Cases

Team Collaboration: Easily reference past discussions and decisions made in group chats.

Knowledge Management: Organize and access valuable information shared within WhatsApp groups.

Educational Purposes: Create a repository of questions and answers for study groups or tutoring sessions.

Customer Support: Analyze customer inquiries and responses to improve support services.

🔗 Explore the Project

To delve deeper into the WhatsApp Knowledge Miner, explore the Github Repository
. Here, you'll find comprehensive documentation, installation instructions, and the complete source code.
For more checkout my LinkedIn

🧠 Conclusion

The WhatsApp Knowledge Miner exemplifies the power of combining messaging platforms with advanced data processing techniques. By transforming unstructured group chats into a searchable knowledge base, it enhances collaboration, preserves valuable information, and streamlines access to past discussions. Whether for personal use, team collaboration, or educational purposes, this tool offers a practical solution to manage and utilize the wealth of information shared within WhatsApp groups.

DEV Community: Danish ali siddiqui

The same Rust gave two different answers, and neither matched JavaScript

Demo Video

The setup

One bit

What I assumed, and why I was wrong

Math.pow is not one function

The fix was in the question, not the answer

The thing I keep thinking about

analogous(-1): how a default hid a heap-exhaustion bug for fifteen years

Project Overview

Bug Fix or Performance Improvement

Code

My Improvements

Why nobody hit this in fifteen years

Checking the blast radius

Guard, or coerce?

Verifying before filing

What my port does instead

How do you form a group nobody can admit they're in?

The obvious version, and why it dies

The public board that can't name the client

The column I refused to write

Negotiating for people you never introduce

Two problems I didn't see coming

Three things that bit me

The thing worth taking

GitHub doesn't retry webhooks. So I gave my tunnel a database.

The part nobody tells you about tunnels

You can break it right now

Before you get excited: is this for you?

What 202 actually means

The whole thing rests on one function

The bug I shipped, and how I found it

Why this can't run on most of the internet

What still doesn't work

Things you're about to ask

Try it

WhatsApp Knowledge Miner: Transforming Group Chats into a Searchable Knowledge Base

Project Overview

🔧 Technical Highlights

🧪 Installation and Usage

🌟 Key Features

💡 Use Cases

🔗 Explore the Project

🧠 Conclusion

What `202` actually means