Curio Log

When UI localization is only half the battle

2026-06-16T16:03:34+08:00

In the recent Hestia survey, many users asked me to add Chinese localization to Hestia. That's no problem with the current technology, so why not? I thought the hardest part was wiring all the hardcoded strings, and that everything would be downhill from there. Turns out I was so wrong...

I first translate it from English to Indonesian, my native language. Then I approach the Chinese localization using both as references, tackling it from two angles simultaneously. It resulted in a decent localization that is neither stiff nor feels out of place.

Then a revelation came to me when I tried using it. All the menus, buttons, and settings are now in pinyin, except the content itself:

Most mods are in English, so even with a Chinese interface, they would still be staring at walls of English text. This only solves half the problem!

Some online games I played over a decade ago had a translation button in their chat window, it was helpful. I figured Hestia needed the same button. The problem now is, who will translate it? I explored some options, but they were either too expensive or had unacceptable translation quality.

I decided to build myself one with Rust + Actix and deploy it on my own server. An LLM now handles the translation, and with the right instructions, it can produce contextual translations. It's still taking 15-60s to complete a single translation, but once done, it's aggressively cached on Redis for speed and on MySQL for persistence.

The tricky part was in preventing abuse. The service must be publicly available, without any authentication or an API key, because Hestia's users will access the translation service from their own PCs. So I had to hardcode it to process only GameBanana mods along with a strict rate limiter.

While translation quality isn't the best, it's actually solid enough. Now, even I can read what mod does, regardless of what language it's written in.

Rust as a web app? Introducing an experimental Altcha server

2026-06-09T00:10:08+08:00

With Bun transitioning from Zig to Rust, why aren't we just using Rust directly on the web?

And so I did.

Currently in experimental phase, I deployed an Altcha challenge/verify server built on Rust & Actix. It runs as a multi-instance binary backed by an Nginx reverse proxy, with each instance binding to its own internal port, and all communicate via Redis. I could freely set how many instances were running from a few commands, which I later simplified into a script. Nginx load-balances everything and adds several layers of abuse protection, including an additional rate limiter built into the server itself.

API Endpoints

All API endpoints are currently public. If you try this, expect rough edges. Treat it as a proof of concept for Rust on the web behind Nginx. Reach out to me for issues or suggestions!

1. Configuration

Returns the server configuration, including all supported algorithms.

GET https://cerberus.hnawc.com/config

_Response:

{
  "algorithms": [
    "ARGON2ID",
    "SCRYPT",
    "PBKDF2/SHA-256",
    "PBKDF2/SHA-384",
    "PBKDF2/SHA-512"
  ],
  "maxDifficulty": 0,
  "pow": "v2",
  "server": "cerberus.hnawc.com"
}

2. Challenge

Returns a signed proof-of-work challenge. The client's widget uses this to generate a solution.

GET https://cerberus.hnawc.com/challenge

_{Query Parameter:}
algo OR algorithm
Possible values are ARGON2ID, SCRYPT, PBKDF2/SHA-256, PBKDF2/SHA-384, and PBKDF2/SHA-512 with all case-insensitive and support common shorthand. The default algorithm is Argon2id as it is the current strongest one to fight bots, but that may change in the future as technology develops.

GET https://cerberus.hnawc.com/challenge?algo=argon2id
GET https://cerberus.hnawc.com/challenge?algo=scrypt
GET https://cerberus.hnawc.com/challenge?algo=PBKDF2/SHA-256
GET https://cerberus.hnawc.com/challenge?algo=SHA-384
GET https://cerberus.hnawc.com/challenge?algo=sha512

_Response:

{
  "parameters": {
    "algorithm": "ARGON2ID",
    "cost": 1,
    "expiresAt": 1781181120,
    "keyLength": 32,
    "keyPrefix": "476d20ac5f2a5361870125da64c75f65",
    "keySignature": "22f9787b3db56caa4cca8f2ac19d2bce09ef2942caa78c0272e766cbee0db046",
    "memoryCost": 131072,
    "nonce": "f45992822a154214d5e53193451aac07",
    "parallelism": 1,
    "salt": "58beee892019246b9c7d45d3f6b2520c"
  },
  "signature": "420c55a9918a77df2b133e5b12cacf2ec4075ceb74cfe691784302e9587188fc"
}

3. Verify

Submits a completed proof-of-work solution. The client's widget generates this after the challenge is solved.

POST https://cerberus.hnawc.com/verify

_Example:

curl -X POST https://cerberus.hnawc.com/verify \
  -H "Content-Type: application/json" \
  -d '
{
  "challenge": {
    "parameters": {
      "algorithm": "ARGON2ID",
      "cost": 1,
      "expiresAt": 1781181935,
      "keyLength": 32,
      "keyPrefix": "8f58a823e137a04ebde45c7ec0a98bb1",
      "keySignature": "e32d295c093e2174d4ffd617de6d865f445b1bda95b89d2326aefc941504c048",
      "memoryCost": 131072,
      "nonce": "c7085f021f0b05342619c0be1d530dfa",
      "parallelism": 1,
      "salt": "16d9426feb30b0c969c2f8a7210dfefa"
    },
    "signature": "e22e447110e4f8e1ee43ef36a86eb5c640afec149454a991475fadedd49a7d2f"
  },
  "solution": {
    "counter": 12,
    "derivedKey": "8f58a823e137a04ebde45c7ec0a98bb1f5c1f8c5d8ed79017dce5b8a945faebc",
    "time": 2167.6
  }
}
'

_{Response (success):}

{"success": true}

_{Response (failure):}

{"success": false, "error": "expired"}

_{Possible error messages:}

malformed_json = Payload body couldn't be parsed.
expired = The challenge's expiresAt is in the past.
replay = Identical solved nonce exists, indicating a replay-attack.
invalid_payload = Solution doesn't validate or payload was tampered.

How to Use

Use the new Altcha Widget v3 that supports POW v2 to enable Argon2id algorithm.

_Example:

<head>
  <!-- Loads Altcha -->
  <script async defer src="https://cdn.jsdelivr.net/npm/altcha@3.0.11/dist/main/altcha.min.js" type="module"></script>
</head>
<body>
  <!-- Render widget & fetch the challenge -->
  <altcha-widget challenge="https://cerberus.hnawc.com/challenge" workers="1"></altcha-widget>

  <!-- Loads Argon2id to solve the challenge -->
  <script>
  window.addEventListener('load', async () => {
    const blob = await fetch('https://cdn.jsdelivr.net/npm/altcha@3.0.11/dist/workers/argon2id.js').then(r => r.blob());
    $altcha.algorithms.set('ARGON2ID', () => new Worker(URL.createObjectURL(blob)));
  });
  </script>
</body>

_Demo:

^{Link: https://cerberus.hnawc.com/demo}

Once solved and the user submits the form, the payload is ready to be verified to /verify via a POST request from your end. If {"success": true}, process the form.

_{Practical Usage:}
Altcha invisibly protects my own contact page. It auto-loads the challenge, silently solves it, then immediately submits to /verify and fetches my email address. Altcha Widget v3's auto=onload and display="invisible" make this frictionless setup possible without needing user interaction.

Inside the survey: Anonymous & Autonomous

2026-06-07T17:58:20+08:00

With the release of Hestia version 1.5.0, the feedback survey for version 1.4.1 has officially come to a close. It was exciting to read everyone's feedback and respond to it.

Survey results
• Current Version: https://hestia-survey.hnawc.com/ongoing
• Previous Version: https://hestia-survey.hnawc.com/previous
• Version specific: 1.4.1

Whether you're curious about the backend or not, I insist on sharing how it works. The survey form is hardcoded into the app with minimal payload and transmitted anonymously to a Cloudflare worker instance, which in turn verifies integrity and rate limit before writing into the D1 database. The summary table is automatically generated in Google Sheets, which I scripted to periodically fetch new data from the database and notify me of any new submissions. That way, I stay on top of everything without needing AI to take part in this automation.

p.s. Among many incoming bug reports, feature requests, and words of support, there were also some jokes thrown in:

Reading a file in chunks? Swallow it whole!

2026-05-30T14:48:32+08:00

Recently, I had to render multiple high-resolution images on a Rust + Egui stack for Hestia. The bottleneck was obviously the process being choked by decoding and rendering, but let's shift our focus elsewhere: reading the image files.

For nearly 2 decades, I have been reading files by chunking them into smaller buffers. Nothing is wrong with that, really...

use std::fs::File;
use std::io::{self, Read};

fn main() {
    // Open the file
    let mut file = File::open("image.png").unwrap();

    // Collect all bytes into 'image'
    let mut image = Vec::new();

    // Prepare chunk size of 4kb
    let mut buffer = [0; 4096];

    // Loop-read operation
    loop {
        let b = file.read(&mut buffer).unwrap();
        if b == 0 {
          break; 
        }
        image.extend_from_slice(&buffer[..b]);
    }
}

In this scenario, I needed to squeeze performance wherever possible. This led me to memory mapping, which is also available in Rust under the memmap2 crate.

use std::fs::File;
use memmap2::MmapOptions;

fn main() {
    // Open the file
    let file = File::open("image.png").unwrap();

    // Map the file into memory & assign to 'image'
    let image = unsafe{ 
        MmapOptions::new().map(&file).unwrap()
    };
}

The block is wrapped in unsafe because it contradicts Rust's memory-safe philosophy, and it won't compile unless we explicitly mark it as unsafe.

Adopting this technique has significantly improved speed. Under the hood, it doesn't actually read the whole file yet, it only registers the file's location in memory and loads chunks of the file when needed, and the OS can efficiently unload it if memory is tight. And the whole thing is done with zero-copy, avoiding wasted operations and unnecessary memory overhead. Beautiful.

It seems I was still living in 2004...

2026-05-30T10:27:56+08:00

I was writing a small tool in Rust to scan folders recursively on my PC and generate a hash for each file, but it was too slow. Wondering if it was due to the PC limitations, I naturally went to Task Manager.

Processes list via System Informer

That was not the actual image (I didn't take a screenshot at the time), but you get the gist... The CPU was practically idle, and this tool didn't even reach over 10% cpu usage.

Did I mention that the tool is small? Very small, it only does a WalkDir function, generates a hash, and stores it in memory.

Suddenly, an idea struck me: what if I fire up multiple scanners concurrently and merge the results? After a little research, apparently it was a thing! By using both Tokio for concurrent tasks and Rayon for multi-core processing, I was able to achieve near-100% CPU usage and significantly improve the scanning speed.

Turns out I have only been using a single core, like a primitive person time-traveled from the Pentium III era in early 2000. Coming from web development, I never had to deal with such low-level stuff, and it felt great to be in control. After all, I paid for the whole PC, so it's only natural I use the whole CPU, right?