DEV Community: Althaaf Mohamed

When your server has the right file, but the browser still won't show it

Althaaf Mohamed — Tue, 28 Jul 2026 14:52:14 +0000

The bug: a feature that worked everywhere except where it mattered

A new feature went into a web app's main file. Deployed, confirmed present on the actual server via a direct file check. Refreshed the browser — repeatedly, in incognito, on a different device. Nothing.

The file was correct. The server had the file. The feature simply wasn't there.

First instinct: it's caching

Hard refresh. Cleared browser cache entirely. Tried an incognito window — guaranteed no cache at all. Still nothing.

Checked whether the server itself might be caching an old version somewhere between disk and browser (a CDN, a reverse proxy). Fetched the file directly with a command-line tool, bypassing the browser completely: the new code was right there, in the actual response.

So the correct file was genuinely being served. And still, the feature didn't run.

Second instinct: something's silently failing inside the code

Added visible, unmissable debug messages directly inside the new function — the kind that pop up on screen, impossible to miss if the code runs at all.

Nothing appeared. Not even the most basic possible message, placed as the literal first line of the function.

Yet other code in that same file — code that had been working for weeks — was demonstrably still running correctly, fetching live data successfully.

The real diagnostic question

At this point, two things were true simultaneously: the file on the server was correct, and the code in that file wasn't executing. That's a genuinely strange combination — normally, if a browser has the right file, the code in it runs.

Unless the browser wasn't loading that file at all.

The actual root cause

Web servers have a long-standing default behavior: when someone visits a bare address with no specific filename, the server looks for a file conventionally named index.html and serves that automatically. It's such an old, ingrained convention that it's easy to forget it exists at all once a project has moved past its earliest setup.

This particular project had, at some earlier point, needed exactly this fixed — the bare domain was serving a different, separate file than the one everyone had been actively editing since. The fix at the time was to make a copy. That copy was never revisited. Every edit since then went only into the "real" file — the one being tested was always the untouched, months-old copy sitting quietly under the conventional default name.

The actual lesson

The instinct to suspect caching first is usually right — it's the most common cause of "I changed it and nothing happened." But caching has a specific signature: the server itself returns the new content correctly when checked directly, while the browser stubbornly shows the old thing.

Here, the server was also consistently serving something old — just a genuinely different file than the one being edited, not a stale copy of the same one. That distinction is the actual tell: if a direct server check confirms new content, but the live URL still shows old behavior, it's worth checking whether that URL is even resolving to the file you think it is, rather than assuming it must be some deeper, more exotic caching layer.

Sometimes the boring, first-year-of-web-development default is exactly what's happening — precisely because it's old and easy to forget.

Code: https://github.com/AlthaafM/Quantum-Lattice

When three different bug fixes all fail identically, stop fixing and start diffing

Althaaf Mohamed — Tue, 21 Jul 2026 09:46:27 +0000

The bug: a JSON error with no obvious cause

Adding a biometric authentication plugin to a Tauri desktop app, the build started failing with this:

failed to parse JSON: expected value at line 1 column 1: expected value at line 1 column 1

No file path. No line number in our own code. Just a generic parse failure, somewhere inside Tauri's own build process.

First instinct: check the obvious file

The error mentioned "capabilities" — Tauri's permission system — so the first suspect was the capability file itself. Opened it, read it carefully, looked completely valid. Removed the biometry-specific permissions entirely, leaving just the two that had worked before. Same error.

Second instinct: it's the plugin's fault

Tried a different version of the plugin. Same error. Tried pulling the plugin directly from its GitHub source instead of the published package, in case the published version was missing a file. Same error, byte for byte.

Three genuinely different attempts, identical failure. Worth sitting with that for a moment: when multiple different versions of the same dependency all fail identically, the dependency itself becomes a much less likely suspect than something upstream of it.

The actual test that mattered

Rather than keep guessing at the plugin, the real diagnostic question became: does a completely fresh, untouched Tauri project — zero modifications — also fail this same way, on this same machine?

It didn't. A brand-new scaffold built and ran fine immediately.

That single test eliminated an entire category of hypotheses at once. Not the Rust toolchain. Not the Tauri version. Not the operating system. Something specific to this project, that a fresh one didn't have.

Finding the actual difference

With a genuinely working reference project sitting right there, the fastest path forward was direct comparison rather than more guessing. Cargo.toml: identical in structure. tauri.conf.json: identical. The capabilities file: nearly identical, except the broken project was missing one line the working one still had — a schema reference we'd removed earlier while chasing a different, unrelated hypothesis.

Copying the working project's capability file over, byte for byte, fixed it immediately.

What actually happened

The most likely explanation: repeated automated rewrites of that config file (through a terminal, across several rounds of troubleshooting) introduced a subtle encoding artifact — invisible on screen, but different from a byte-for-byte perspective. Not something a visual read-through would ever catch.

The actual lesson

"I read the file and it looks fine" is a weaker claim than it feels like in the moment. Text that displays correctly and text that is byte-for-byte correct are different things, and most tools happily show you the first while hiding the second.

When a config-driven failure resists every content-level fix, the more productive question isn't "what's wrong with what I wrote" — it's "is there a known-good reference I can diff against directly, rather than re-reading my own version one more time." A fresh scaffold, a fresh clone, a fresh anything genuinely different from what's already been touched repeatedly, is worth more than another careful read-through.

Code: https://github.com/AlthaafM/Quantum-Lattice

How do you estimate hashrate you can never directly measure?

Althaaf Mohamed — Sun, 19 Jul 2026 15:31:22 +0000

The problem: you can't directly measure someone else's hashrate

Building a mining pool dashboard, one question comes up immediately: how fast is each contributor's machine actually going? Seems simple, until you realize the pool never actually sees the raw hashing loop running — it only ever sees the occasional successful share submission. Everything in between is invisible.

So the real question becomes: can you estimate hashrate from something you can observe, without ever measuring it directly?

The insight: difficulty tells you the odds

A share is accepted when a hash meets a target difficulty — a certain number of leading zero bits. At difficulty D, the probability any single hash attempt succeeds is 1 in 2^D. That means, on average, finding one share takes 2^D attempts.

That's the whole insight. If you know how many shares someone found, and how much time passed, you can work backward to an estimate of their actual hash rate:

estimated_hashrate = (shares_found * 2^difficulty) / elapsed_seconds

No cooperation needed from the miner, no telemetry, nothing extra to build into the client. Just difficulty, share count, and a clock — all data the pool already has.

Why this is an estimate, not a measurement

Worth being honest about the real limitation here: proof-of-work is genuinely random. Finding a share in half the "expected" time isn't unusual, and neither is taking twice as long. With a small number of shares, the estimate can swing noticeably even though the underlying hardware speed hasn't changed at all.

This showed up immediately in testing — a contributor with a real, measured 4.5 MH/s (from their own miner's direct count of nonces tried) saw the dashboard estimate their hashrate at roughly a third of that, purely from a stretch of below-average luck early on. The estimate wasn't wrong — it's honestly reporting what the observed data implies — it just needs more samples to converge toward the true value. This is the same reason real, established pools show hashrate as a rolling average over a window of time rather than an instantaneous number: smoothing out exactly this kind of natural statistical noise.

What this means for choosing a difficulty setting

This estimation math also directly informs a separate, practical decision: how much easier should the pool's share-difficulty be than the real network target? Too close to the real difficulty, and shares arrive so rarely that the estimate above never has enough samples to mean anything. Too far below it, and the pool gets flooded with submissions for no real benefit.

The setting that worked well here: roughly 16 bits easier than the real network difficulty, aiming for a share every 20-30 seconds for a typical modern CPU — frequent enough for a meaningful, quickly-converging estimate, without excessive request volume.

A real, honest gap worth naming

Right now, difficulty is one fixed value applied to every connected contributor. A high-end machine and a modest laptop both get the same target — meaning the powerful machine floods the pool with shares while the modest one waits a while between each. The correct, standard fix is per-contributor variable difficulty: adjusting each miner's individual target based on their own observed submission rate, so everyone gets a similarly steady rhythm regardless of hardware. Real, valuable improvement, genuinely on the roadmap, not built yet.

Code: https://github.com/AlthaafM/Quantum-Lattice
Live dashboard: https://ql-pool.futuristicai.co.za

Quantum-Lattice mining pool is now live — tested, proportional payouts

Althaaf Mohamed — Sun, 19 Jul 2026 08:08:46 +0000

Why a pool needs its own identity, not each miner's

Quantum-Lattice just shipped a mining pool, and the core design decision worth writing about is one that isn't obvious until you actually try to build it: a pool can't simply "collect" rewards on behalf of whoever finds them.

The proof-of-work hash includes the miner's own public key as an input:

sha3_256(version, previous_block_hash, merkle_root, block_height, miner_pubkey, nonce)

That means a winning nonce is cryptographically tied to whichever address was hashed with it. If each connected contributor searched using their own address, a share that happened to also satisfy the real network difficulty would be a valid block — but only under that specific miner's identity. The pool could never swap in its own address afterward and resubmit; changing the address changes the hash entirely.

The actual fix

The pool builds one template using its own address, and hands that exact template out to everyone connected. Every contributor searches for a nonce against a header that already has the pool's identity baked in — their own wallet address is only ever used separately, for bookkeeping, never inside the actual hash.

Concretely:

Pool fetches a real template from the node (block height, previous hash, merkle root, real difficulty)
Pool constructs a candidate header using its own address as the "miner" field
Pool hands this out to connected miners, at a deliberately easier, pool-set difficulty
A miner finds a nonce meeting the easier target, submits {their own address (for credit), nonce}
Pool checks: does this nonce, on the header with the pool's own address, also satisfy the real difficulty?
If yes — genuine block, submitted under the pool's identity, real reward earned
Pool signs and sends individual payouts to every contributor, proportional to shares submitted since the last win

A real bug this design surfaced

The first version of the payout logic assumed the pool had just earned a full 48 QL block reward, and split that fixed amount. During testing — funding the pool with a smaller, deliberate test amount to verify the split logic without waiting on real network odds — it tried to sign a payout for more than the pool's actual balance.

The fix: query the pool's real, current balance from the node immediately before calculating any payout, rather than assuming a fixed reward amount. Obvious in hindsight, but a good reminder that "we know what triggered this" doesn't mean "we know how much is actually available" — those are separate facts, and only one of them is safe to assume.

Testing it properly before shipping

Two independent machines contributed real, different amounts of work. The pool was funded with a small, real amount specifically to test the payout mechanism without waiting on genuine 38-bit network odds. The trigger produced two separate signed transactions, correctly proportional to each machine's actual share count, and both wallets showed the correct, confirmed balance increase shortly after.

That's the difference between "the logic looks right" and "the logic is right" — worth the extra step before anything goes live.

What's next

Difficulty is currently one fixed value for every connected contributor. A meaningfully better version adjusts difficulty per miner, based on their individual submission rate — so a high-end machine and a modest laptop both get a similarly steady rhythm of shares, rather than one flooding the pool and the other waiting a long time between confirmations. Real, valuable improvement, not yet built.

Code: https://github.com/AlthaafM/Quantum-Lattice
Try it: https://quantum-lattice.futuristicai.co.za

A silent bug: how a missing timeout froze our sync loop forever

Althaaf Mohamed — Sat, 18 Jul 2026 11:51:19 +0000

The setup

We recently added continuous peer syncing to Quantum-Lattice's node — instead of checking for missed blocks only once at startup, nodes now re-check periodically in the background, so they recover automatically after any brief network interruption.

Testing it live went well at first: a test node correctly caught up on a real gap, pulling and applying dozens of missing blocks over a genuine internet connection. Then... nothing. No errors. No crash. Just silence, for 15 minutes straight, while the real chain kept advancing without it.

The investigation

The node was still alive — CPU usage was normal, no panic in the logs. That ruled out a crash. The periodic task was clearly supposed to run every 60 seconds indefinitely:

\rust tokio::spawn(async move { loop { catch_up(...).await; tokio::time::sleep(Duration::from_secs(60)).await; } }); \\

Nothing about that loop looks wrong on its own. The bug wasn't in the loop — it was in what the loop was waiting on.

The actual bug

Inside catch_up(), the function that opens a connection to a peer and asks "what's your current height?" had no timeout at all:

\rust let mut stream = TcpStream::connect(peer).await.ok()?; \\

If that connection attempt ever hangs — doesn't cleanly succeed, doesn't cleanly fail, just sits there — the .await never resolves. The loop isn't broken; it's just permanently parked on one single call that will never return. It worked once because that first connection happened to succeed quickly. Some time later, one connection attempt didn't, and the entire background task quietly stopped forever.

The fix

Wrap the connection attempt (and the subsequent read) in an explicit timeout:

\rust let mut stream = tokio::time::timeout( Duration::from_secs(10), TcpStream::connect(peer), ).await.ok()?.ok()?; \\

Now a hung attempt fails cleanly after 10 seconds instead of blocking forever, the loop proceeds to its next sleep-and-retry cycle, and a temporary network hiccup becomes a temporary hiccup — not a permanent, silent failure.

The lesson

Every .await in a loop meant to run forever is a place where "forever" can quietly mean "until this one specific call never returns." We'd already added timeouts to every inbound connection this node handles — but the outbound calls this same node makes to check on its peers had been overlooked entirely. Worth explicitly auditing every unattended, long-running loop for exactly this: not "can this fail?" but "can this specific await simply never resolve at all?"

Confirmed fixed with a real, live re-test — the same node now recovers correctly and repeatedly, watched over several consecutive cycles rather than assumed from a single pass.

Code: https://github.com/AlthaafM/Quantum-Lattice

Quantum-Lattice's first independent node: what it actually took

Althaaf Mohamed — Fri, 17 Jul 2026 20:15:47 +0000

A real external node, not just a design goal

Today, Quantum-Lattice got its first genuinely independent, externally-operated full node — someone running their own copy of the chain, verifying it themselves, entirely separate from our own infrastructure. Worth sharing what that actually involves, since "just clone the repo and run it" undersells a real technical detail worth understanding.

The genesis problem

When a brand-new node starts with no existing chain data, it generates its own genesis block locally. That's normal — every node needs a genesis to start from. The problem: genesis includes real, specific values (in our case, two treasury vault public keys), and every subsequent block links back to it by hash. A node that generates its own fresh genesis is, cryptographically, starting an entirely separate, incompatible chain — not "behind" the real network, just fundamentally different from it.

This means peer-to-peer catch-up syncing — the normal mechanism for "ask a peer what I'm missing and pull it" — can't bridge that gap. No amount of requesting blocks from a peer fixes a mismatched genesis.

The fix: seed once, sync forever after

The practical solution is straightforward once you see the problem clearly: give a new node a real, already-synced copy of the chain database to start from. Once it shares the genuine genesis and history, ongoing P2P sync works exactly as designed — we tested this directly today, watching a fresh node correctly request and apply 43 real, missing blocks from a peer, complete with correctly recalculated difficulty retargeting at each step, purely over a real internet connection.

Worth knowing if you're building something similar

If you're designing a P2P system with any kind of genesis or bootstrap state, it's worth deciding early whether brand-new participants will generate their own bootstrap state (fine for fully independent instances) or need a shared, distributed starting point (necessary if they're meant to join your specific network). We hadn't fully separated these two cases early on — worth building in from the start if you're doing this yourself.

Genuinely one of the more interesting problems this project has hit so far — not a bug, just a real consequence of how trustless verification actually has to work.

Code: https://github.com/AlthaafM/Quantum-Lattice
Explorer: https://quantum-lattice.futuristicai.co.za
Discussion and questions welcome in our Telegram: https://t.me/+QfarLtaccHM0NzFk

Quantum-Lattice update: real multi-threaded mining, and 130+ wallets since launch

Althaaf Mohamed — Thu, 16 Jul 2026 09:25:26 +0000

What's changed since launch

A couple of genuine updates worth sharing, both driven by real user feedback rather than planned in advance.

Multi-threaded mining is now live

Someone running a high-core-count machine (a Threadripper) flagged that the mining client was only using a single CPU core, regardless of how many were actually available. A real, honest limitation — now fixed.

Both the Linux and Windows mining clients automatically detect and use every available CPU core by default now, with an optional argument to override the count if you'd rather limit it. Confirmed working on real multi-core hardware — batch sizes now scale correctly with thread count instead of staying fixed regardless of the machine running it.

Real, sustained growth

Over 130 real wallets created since launch, up from 35 just a couple of days in — genuinely encouraging, continuing growth rather than a single launch-day spike. Steady mining activity, and some genuinely good technical conversations happening on Bitcointalk and Reddit.

Where to find it

🌐 Explorer: https://quantum-lattice.futuristicai.co.za
👛 Wallet: https://qlwallet.futuristicai.co.za
💻 Code: https://github.com/AlthaafM/Quantum-Lattice

Why Post-Quantum Signatures Matter, and How Quantum-Lattice Implements Them

Althaaf Mohamed — Mon, 13 Jul 2026 19:13:59 +0000

The Problem Most Blockchains Are Ignoring

Every major blockchain today — Bitcoin, Ethereum, and nearly everything built on top of them — signs transactions using elliptic-curve cryptography (ECDSA or similar schemes). This has worked well for over a decade, and against classical computers, it still holds up fine.

The problem is Shor's algorithm — a quantum algorithm that, given a sufficiently powerful quantum computer, can efficiently solve the exact mathematical problem elliptic-curve cryptography relies on. Once that hardware exists at scale, ECDSA-based signatures stop being secure, full stop.

Here's the part that makes this an active concern today, not a someday problem: an adversary doesn't need a quantum computer right now to start the attack. Public keys and signatures on every blockchain are, by design, public and permanent. Someone can record that data today, store it, and simply wait — decrypting it retroactively once the hardware exists. This is known as "harvest now, decrypt later," and it means the security of transactions happening on ECDSA-based chains right now is already partly dependent on how long quantum hardware takes to mature.

ML-DSA-65: What Quantum-Lattice Actually Uses

Quantum-Lattice signs every single transaction using ML-DSA-65 — Module-Lattice-Based Digital Signature Algorithm, standardized by NIST as FIPS 204 in 2024, after nearly a decade of public cryptanalysis and competition among candidate algorithms.

Instead of relying on the elliptic-curve discrete logarithm problem (the thing Shor's algorithm breaks), ML-DSA is built on the hardness of certain lattice problems — specifically, problems believed to be hard for both classical and quantum computers. The "65" refers to NIST's security category 3, a substantial security margin appropriate for long-lived infrastructure like a blockchain.

The Real Trade-off: Size

Post-quantum security isn't free. ML-DSA-65 public keys are 1,952 bytes, and signatures run 3,309 bytes — dramatically larger than ECDSA's roughly 33-byte public keys and ~72-byte signatures.

This is a genuine, honest trade-off worth naming rather than glossing over: every Quantum-Lattice transaction carries real extra weight compared to a legacy chain. We consider that weight the actual cost of the security margin — not overhead to be hidden, but the visible price of resistance to an attack ECDSA simply cannot resist at all.

Proof, Not Just Claims

Rather than asking anyone to just trust that this is implemented correctly, Quantum-Lattice publishes real, independently reproducible cryptographic test vectors on its live explorer — a fixed seed, its derived public key, a signed message, and the resulting signature, alongside SHA3-256 and proof-of-work hash examples using the network's actual construction. Anyone can run the same computation themselves and verify the output matches exactly.

The full source code is open and Apache 2.0 licensed on GitHub, so the actual implementation — not just the description of it — is available for anyone to read.

Where This Leaves Us

Quantum-Lattice is a real, working network today — live mining, a functioning non-custodial wallet, and a public explorer showing real chain activity. It's early-stage, and we've been upfront about that from day one. But the cryptography underneath it isn't speculative — it's the actual finalized NIST standard, implemented, tested, and open for anyone to verify.

🌐 Explorer: https://quantum-lattice.futuristicai.co.za
👛 Wallet: https://qlwallet.futuristicai.co.za
💻 Code: https://github.com/AlthaafM/Quantum-Lattice