My entry into programming was at 16, when friend came over to my house and told me about one of our neighbours, who was building websites, and even selling them (can you believe that?!) to small businesses. We looked at the websites and thought: We can do that better.

The way I entered the field might be how I always act, or it defined how I approach this craft: I want to build solutions to problems. I was never the one who could dabble deep into programming languages and nerd out on syntax or object-oriented vs. functional etc. For me, the endgoal was always priority. With more time in the field, I also cared about HOW I build these solutions, and HOW the code and structure looks like.

A few years forward, and I found myself in the StartUp world in Berlin. I loved the pace, the atmosphere, and the building, pivoting, trying out new tools to solve problems faster and better. Working at a company didn't satisfy my lust for exploring, so I wanted to develop my ideas outside of work. The city always provided enough UX/UI people to partner and tinker with. None of the toy projects ever succeeded, but that was not the point, really.

Family Meets LLMs

Life changes, I have a family now, went through the first hard years of being a parent, and I slowly feel more free time to explore this lust of building and solving problems. Now, in this phase, the tech ecosystem throws new tools my way to help me exactly with that: LLMs.

Was it more or less "meh" in the beginning, since Claude Opus 4.5, I can really thrive.

The Pool Dashboard

For example, we have a local community pool where I live now, and there website is hard to read, and the schedule hard to decipher. I am part of a parent WhatsApp group and the complains were every week the same: "I stood in front of the pool and it was closed", "Can someone tell me if the pool is actually open?".

Well, on one of these afternoons, between doing the dishes, prepping the day for my Kids, I threw the problem into Claude, gave it the website with the hard-to-read schedule, and told it to build a very basic, bare bones dashboard with YES/NO if the pool is open. I didn't look at the website yet, I just wanted a prototype and a first idea if it works. 5 minutes later it found the API call to for the JSON the website is getting, and build a very basic HTML/CSS website. I fed it more features, saw more edge cases, adjusted the code, gave it more guidelines. And fast forward one hour later, instead of answering to the WhatsApp group "I think it is", I posted a link for the website. While Claude was working, I purchased the domain, set up a GitHub CI/CD pipeline, set up GitHub pages, and then merged it all together.

It was fun, exhilarting, and reminded me of the pure joy I felt when I was younger. Could I have done it myself? Oh absolutely. But not in 45mins while I had to do 5 different things. For these debugging sessions, I need a notebook, a quiet place to think and bounce back and forth until I have a working example. Fun if you have all the time in the world, not so fun if you have 2 kids in the background who have priority (at least, most of the time).

The NHL Playoff Dashboard

The list goes on. A few months later, friends of mine wanted to start a NHL Playoff Fantasy team. We picked the teams, our friend forwarded the free website he set it up. And it was - aweful. I thought: I can do it better! Span up Claude inside Zed, and with the help of GitHub repos for unofficial NHL API documentation, span up a fully functional, live score and live data NHL dashboard for the playoffs, with each of our teams and players. It took about a week to get right, but without the help of the LLM, I would have taken so much longer (and probably lost interest) in setting up all the edge cases, details, parse API responses which were not documented etc.

Building Tools for Every Day

With the time, the tools got better, and I can finally build tools I can - and want to - use every day. I always wanted a seamless writing experience in the browser without logins and complex UI. So I built WorkLedger. I am using it every day now for a week and it truly changed my workday. Afer using it even more than I expected, I build a backend-sync server, and could nerd out with a close to "zero-knowledge" sync I always wanted to try out. The sheer fun of using something every day, and it works magically behind the scenes.

After that, I was tired of keeping my Brag Document in a Google Doc, so I build a fully customizable work stream "collector" called Brag Frog, which syncs all my resources into one place, and I can prep meetings, add items to OKRs and let myself draft a self review every half year based on all the work I am doing from across 7 different platforms.

I can open source this work, it runs fairly cheap on a fly.io instance. The static websites either run on GitHub or Vercel. It is fast and easy to setup and ship.

What About Quality?

And for the quality? My god, you can really fine tune and throw stuff at Claude Opus 4.6. The Brag Fox project particual was a mess. I constantly added and refined features, and the code ended up like expected: Messy. But hey, I wrote down a plan, guidelines how a proper code structure should look like for this type of project. Added guidelines from DDD and let it work. It took 2h, and 25 different tasks, and it refactored the whole codebase.

Is it perfect? Hell no. But so wouldn't be my code for a side project I build. I would even say, it is way better than what I would have come up with. Why? Becasue I build it on the side. I can now focus on guidelines and best practices, let it run for hours, and the solution is so close to "very good", that I can manually go through each module and do adjustments if I feel like it. But often times: Really not needed.

Why it works so well for me

I am a very pragmatic person. I need to see and touch things to understand them. I can read tutorials or study codebases, but I need to get my hands dirty. Spinning something up, jumping between RFC docs and then building it out, seeing if it works, and then going back to higher-level thinking: That's the stuff I love. I can do that now every time I like. And even with problems at work: I can spin up example implementations, see if they make sense, and then either throw them out or iterate until they meet my quality standards. All the while learning a ton of new things along the way.

A bit more than a week ago, I came across the blog post Using an engineering notebook. I personally love notebooks and use... too many of them. My only issue has always been that when my brain is on fire, my handwriting is not neat enough, it's not structured enough, and it helps me to note things down, but it always feels like I could be faster by text-to-speech or keyboard typing.

Now there are moments of silence of course, when I can sit down with a cup of coffee and map out a feature or thought in my head. For that, I don't think any digital device will ever come close to simple pen and paper.

Nevertheless, the time was ripe to "Build it yourself". I am always inspired by Excalidraw. I can open it, don't need an account, draw to my heart's content, and then save the finished drawing as a PNG to my local hard drive and take it anywhere. I wanted to build something seamless like that for writing. Hence, WorkLedger was born.

The landing page gives you a nice feature overview.

Shout out to BlockNote for offering a superb text editing experience.

I thought to myself: Local first is great, I will never need sync. Until I left the house on a Friday to bring my kids to skating lessons, work still ruminating within me, and I thought: Let's get this down on "paper" so I don't forget my thoughts. I opened WorkLedger on my iPhone and saw - nothing. Obviously a new session means new data. Argh. I had to implement sync.

The birth of sync ID

I started using Mullvad VPN this past year and was utterly confused by their lack of... account? I couldn't find a deep dive into this, all I have as an explanation is this blog post from 2017.

I got inspired though: What if I had a button which can generate a sync ID, and with that, I can - sync? That's it. No password, no complicated setup. And I want to copy/paste this sync ID to my devices where I need it. And somehow, the server doesn't even know this id, but still can give me my associated entries.

The core trick: domain separation

The core question is: If the server never sees this magic id, how does it know which entries belong to me?

The answer is that one string becomes two different strings through a one-way process. Given a sync ID like wl-a1b2c3d4e5f6a7b8c9d0, I derive two separate values from it:

This is called domain separation. The prefixes auth and crypto ensure the two hashes are computationally unrelated — knowing one reveals nothing useful about the other.

The auth token goes to the server as an X-Auth-Token header. The server uses it to identify your account and look up your entries. But because it is a SHA-256 hash of a sync ID (not the sync ID itself), the server cannot reverse it. And because the crypto seed uses a different prefix, the server cannot derive the encryption key either.

This is how it looks in my crypto.ts file:

async function sha256Hex(input: string): Promise<string> {
  const encoded = new TextEncoder().encode(input);
  const hash = await crypto.subtle.digest("SHA-256", encoded);
  return Array.from(new Uint8Array(hash))
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
}

export async function computeAuthToken(syncId: string): Promise<string> {
  return sha256Hex("auth:" + syncId);
}

export async function computeCryptoSeed(syncId: string): Promise<string> {
  return sha256Hex("crypto:" + syncId);
}

The sha256Hex function uses the Web Crypto API, which is available in all modern browsers, so I don't even need to import any npm modules for it.

Generating the sync ID

The sync ID is generated client-side from 10 random bytes, giving 80 bits of entropy.

A byte can hold any value from 0 to 255 — that is 256 possibilities. Since each bit doubles the possibilities and 2⁸ = 256, one byte equals 8 bits of entropy. Ten random bytes means 10 × 8 = 80 bits.

For reference:

• A typical password might have 30-50 bits of entropy (guessable)
• 80 bits is in the "nation-state can't brute-force this" range
• 128 bits is the standard target for symmetric cryptography

export function generateSyncIdLocal(): string {
  const bytes = crypto.getRandomValues(new Uint8Array(10));
  const hex = Array.from(bytes)
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
  return `wl-${hex}`;
}

The result looks like wl-a1b2c3d4e5f6a7b8c9d0. The wl- prefix is cosmetic - it makes the string recognizable as a WorkLedger sync ID when you paste it between devices.

80 bits of randomness means there are roughly 1.2 × 10²⁴ possible sync IDs. For any realistic number of users — say, 10 million accounts — the probability of a collision is vanishingly small.

From crypto seed to encryption key

The crypto seed alone is not the encryption key. It goes through one more transformation: PBKDF2 key derivation with a server-provided salt.

When you create an account, the server generates 16 random bytes as your salt and sends it back. This salt is stored alongside your auth token in the server database. Every device that connects with the same sync ID gets the same salt, which means every device derives the same encryption key.

const PBKDF2_ITERATIONS = 100_000;

export async function deriveKey(syncId: string, saltBase64: string): Promise<CryptoKey> {
  const cryptoSeed = await computeCryptoSeed(syncId);
  const encoder = new TextEncoder();
  const salt = Uint8Array.from(atob(saltBase64), (c) => c.charCodeAt(0));

  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    encoder.encode(cryptoSeed),
    "PBKDF2",
    false,
    ["deriveKey"],
  );

  return crypto.subtle.deriveKey(
    { name: "PBKDF2", salt, iterations: PBKDF2_ITERATIONS, hash: "SHA-256" },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"],
  );
}

The output is an AES-256-GCM key - a symmetric key that both encrypts and decrypts. PBKDF2 with 100,000 iterations makes brute-force attacks against weak sync IDs expensive, though with 80 bits of entropy the sync ID itself is already computationally infeasible to guess.

The full derivation chain looks like this:

Encrypting entries

With the key derived, each notebook entry gets encrypted before it leaves the device. I split each entry into two parts: the content payload that gets encrypted, and minimal metadata that stays in plaintext.

export async function encryptEntry(key: CryptoKey, entry: { ... }): Promise<SyncEntry> {
  const payload = {
    dayKey: entry.dayKey,
    createdAt: entry.createdAt,
    updatedAt: entry.updatedAt,
    blocks: entry.blocks,
    isArchived: entry.isArchived,
    tags: entry.tags ?? [],
    isPinned: entry.isPinned ?? false,
    signifier: entry.signifier,
  };
  const plaintext = JSON.stringify(payload);
  const encryptedPayload = await encrypt(key, plaintext);

  return {
    id: entry.id,                    // plaintext — server needs for dedup
    updatedAt: entry.updatedAt,      // plaintext — server needs for conflict resolution
    isArchived: entry.isArchived,    // plaintext — server needs for filtering
    isDeleted: entry.isDeleted,      // plaintext — server needs for deletion markers
    encryptedPayload,                // opaque blob
  };
}

The content fields — your actual writing (blocks), your tags, your date organization (dayKey) — all go into the encrypted blob. The server gets only an opaque base64 string.

The metadata fields stay in plaintext because the server needs them for operational purposes: id for deduplication, updatedAt for last-write-wins conflict resolution, isDeleted for soft-delete markers.

The encryption itself uses AES-256-GCM with a random 12-byte initialization vector (IV) prepended to the ciphertext:

export async function encrypt(key: CryptoKey, plaintext: string): Promise<string> {
  const encoder = new TextEncoder();
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv },
    key,
    encoder.encode(plaintext),
  );

  const combined = new Uint8Array(iv.byteLength + ciphertext.byteLength);
  combined.set(iv, 0);
  combined.set(new Uint8Array(ciphertext), iv.byteLength);

  let binary = "";
  for (let i = 0; i < combined.length; i++) {
    binary += String.fromCharCode(combined[i]);
  }
  return btoa(binary);
}

The loop builds the binary string one character at a time instead of using String.fromCharCode(...combined) with a spread operator — spreading passes every byte as a separate function argument, which blows the call stack for entries larger than ~64KB.

AES-GCM is an authenticated encryption scheme. It provides not only confidentiality but also integrity — if anyone tampers with the ciphertext, decryption fails. This matters because the server could theoretically modify the encrypted blobs, and AES-GCM ensures you would detect it. Note that AES-GCM only authenticates the encrypted payload itself — the plaintext metadata fields (id, updatedAt, etc.) travel outside the encryption envelope and are not integrity-protected.

A fresh random IV for every encryption operation means that encrypting the same entry twice produces different ciphertext, preventing identical content from producing identical blobs across pushes.

The server: what it stores, what it cannot see

The workledger-sync server is a Rust service built with Axum and SQLite. Its database schema is minimal:

-- The sync_id column stores the auth token, NOT the raw sync ID.
CREATE TABLE accounts (
    sync_id       TEXT PRIMARY KEY,   -- auth token: SHA-256("auth:" + syncId)
    salt          BLOB NOT NULL,      -- 16 random bytes, returned to client
    created_at    INTEGER NOT NULL,
    last_seen_at  INTEGER NOT NULL,
    entry_count   INTEGER NOT NULL DEFAULT 0
);

CREATE TABLE entries (
    id                TEXT NOT NULL,
    sync_id           TEXT NOT NULL REFERENCES accounts(sync_id) ON DELETE CASCADE,
    updated_at        INTEGER NOT NULL,
    is_archived       INTEGER NOT NULL DEFAULT 0,
    is_deleted        INTEGER NOT NULL DEFAULT 0,
    encrypted_payload BLOB NOT NULL,
    integrity_hash    TEXT NOT NULL,
    server_seq        INTEGER NOT NULL,
    PRIMARY KEY (sync_id, id)
);

CREATE TABLE sync_cursors (
    sync_id   TEXT PRIMARY KEY REFERENCES accounts(sync_id) ON DELETE CASCADE,
    next_seq  INTEGER NOT NULL DEFAULT 1
);

Here is what the server knows and does not know:

Even the column named sync_id in the database is misleading — it stores the auth token, not the actual sync ID. The naming was an early decision and I have to change it to be more accurate.

Account creation flow

When a user taps "Generate Sync ID" in the app, the following sequence happens:

1. The client generates a sync ID locally: wl-a1b2c3d4e5f6a7b8c9d0
2. The client computes SHA-256("auth:" + syncId) to get the auth token
3. The client sends a POST /api/v1/accounts with the auth token in the request body
4. The server generates 16 random bytes as the salt, stores the auth token and salt, and returns the salt to the client
5. The client computes SHA-256("crypto:" + syncId) to get the crypto seed
6. The client runs PBKDF2 with the crypto seed and server salt to derive the AES-256-GCM key
7. Sync is ready

The server enforces rate limiting on account creation to prevent abuse. But there is no CAPTCHA, no email verification, no OAuth flow. The auth token is self-authenticating — if you can produce it, you are the account owner.

Multi-device sync

When device B enters the same sync ID, the flow is:

1. The client computes the auth token from the entered sync ID
2. The client calls GET /api/v1/accounts/validate with the auth token as an X-Auth-Token header
3. The server looks up the auth token, confirms the account exists, and returns the salt
4. The client derives the same encryption key (same sync ID + same salt = same key)
5. The client performs a full bidirectional sync via POST /api/v1/sync/full

The full sync sends all local entries (encrypted) to the server and receives all server entries back. Both sides merge using last-write-wins on the updatedAt timestamp.

This is the crucial property: because key derivation is deterministic, any device with the same sync ID and salt produces the same encryption key. The server does not coordinate key exchange. There is no key escrow. The key exists only in browser memory, derived fresh on each session.

Random questions

Going through this exercise, I had some random questions. So you might have them too:

Is SHA-256 deterministic?

Yes, absolutely. That is the entire reason this works.

SHA-256 is a deterministic hash function. The same input always produces the same output, on any device, in any browser, forever. There is no randomness involved in hashing.

So when Device B enters wl-a1b2c3d4e5f6a7b8c9d0:

Device A:  SHA-256("auth:" + "wl-a1b2c3d4e5f6a7b8c9d0")  →  7f3a8b...
Device B:  SHA-256("auth:" + "wl-a1b2c3d4e5f6a7b8c9d0")  →  7f3a8b...
                                                                ^^^^^^^^
                                                            identical every time

Same input, same output. Device B sends 7f3a8b... as the X-Auth-Token header, the server looks it up, finds the account, returns the salt. Then:

Device A:  SHA-256("crypto:" + "wl-a1b2c3d4e5f6a7b8c9d0")  →  e9c1f2...
Device B:  SHA-256("crypto:" + "wl-a1b2c3d4e5f6a7b8c9d0")  →  e9c1f2...
                                                                ^^^^^^^^
                                                            identical every time

Same crypto seed + same salt (from server) → PBKDF2 is also deterministic → same AES-256-GCM key on both devices.

The only randomness in the entire crypto pipeline is:

1. The sync ID generation (once, on Device A)
2. The salt generation (once, on the server)
3. The IV for each encryption call (random 12 bytes every time, which is why re-encrypting the same entry produces different ciphertext)

Everything else is deterministic by design — that is what makes multi-device work without any key exchange protocol.

And why can't the server use the salt and auth token to reverse the sync ID?

Because SHA-256 is a one-way function. It only works in one direction.

"auth:" + "wl-a1b2c3d4e5f6a7b8c9d0"  →  SHA-256  →  7f3a8b...

There is no SHA-256-reverse function. Given 7f3a8b..., there is no mathematical operation that produces the input. This is not encryption (which is reversible with a key) — it is hashing (which destroys information). The 256-bit output is a fixed-size digest of arbitrary-length input. Many possible inputs map to the same output, so the mapping is inherently irreversible.

The salt does not help either. The salt is used later in the pipeline, in a completely separate step:

syncId
  │
  ├── SHA-256("auth:" + syncId)   → auth token     ← server has this
  │
  └── SHA-256("crypto:" + syncId) → crypto seed    ← server does NOT have this
        │
        └── PBKDF2(cryptoSeed, salt, 100k) → key   ← salt is used HERE

The salt participates in PBKDF2 key derivation from the crypto seed, not from the auth token. The server has the auth token and the salt, but these two values never interact in the derivation chain. They are on separate branches. The salt is useless without the crypto seed, and the crypto seed is a different hash that the server never receives.

So the server would need to brute-force the sync ID: guess a value, hash it with "auth:" prefix, check if it matches the stored auth token. With 80 bits of entropy (10 random bytes), that is 2⁸⁰ ≈ 1.2 × 10²⁴ guesses. At a billion hashes per second, that takes about 38 million years.

Final thoughts

I am quite happy with how it turned out. In the beginning, everything really worked like magic. I could click on a "generate sync ID" button, it created one and started syncing immediately. I copy/pasted the same id to my other browser session, and less than a second later, I saw the same entries. This whole process made me really curious if I am ever able to implement a truly "zero-knowledge" sync someday.

And for the syncing itself: There were enough gotchas and race conditions, which I have to write another day about.

For quite a while now I have been blocking every* ad in my home on a router level (* some ads obviously slip through, and also YouTube ads cannot be blocked on a DNS level). I remember having a very low powered virtual server running for some Linux server experimentations at the time, and I wanted to make better use of it. I knew of Pi-hole but this seemed so much work to setup.

This is when I found AdGuard Home. The HowTo install is very simple and gives you a basic setup you can play around with. Why not execute 3-4 CLI commands to install the service and be done with it?

The code is available on GitHub, with a very active community around it. After installing it on your server, you have to make sure that your port 53 is open and not blocked by your firewall. When you ask a device to use a DNS server, it automatically asks on port 53 unless told otherwise.

Very helpful gotchas:

• When you first install AdGuard Home on your server and have strict firewall rules, you may find DNS queries are blocked.
• When you update your firewall rules and forget to leave port 53 open, your DNS will stop working.

You can obviously change that in the settings when setting up AdGuard Home. The challenge is just with your router. It might not let you change the port for your DNS address. I know mine doesn't (Bell Aliant).

AdGuard has a ton of options, the most important are the DNS blocklists. These are pre-integrated public lists which get updated frequently by different communities. You can find everything, from gambling to general ads, to social media and other NSFW websites.

You can add them to your filters, and activate or deactivate them as you see fit.

After you change the DNS IP address from the generic one to your own server instance where AdGuard home runs, every time you browse, the DNS query will go through AdGuard home and checks if that domain is blocked or not.

Firefox Extensions

I recommend installing Firefox for your online experience. After you've installed and made it your default, you can install three extensions which make the internet way more enjoyable.

After all the noisy ads and dangerous websites are blocked via AdGuard Home, we can go further fine-tune our online experience:

• Additional ad blocker for YouTube and Co.
• Remove paywalls
• Remove Cookie notices

The "Remove paywalls" is the most... let's say gray-zone extension. You should absolutely support newspapers and journalism. So if you can, don't replace your Newspaper subscription with this extension. But if you are on a tight budget - and no one can reasonably expect you pay for 10 newspaper subscriptions at the same time, use this extension to occasionally read an article you wouldn't otherwise be able to.

You manually have to download it from this repository and download the bypass_paywalls_clean-latest.xpi file. Then, you go to the Firefox settings, Extensions, click on the little gear symbol, and click "Install Add-on from File...".

Gotchas

With all of these extensions and setups in place, you will find that occasionally a link or a website breaks. I get school emails, and they wrap their links inside a tracker URL. I had to whitelist a few of these to participate in their communications. You can easily do this via the DNS whitelist setting in AdGuard Home. But you will find that sometimes you don't know if the website or link is broken, or your setup blocks it.

The other issue is that: What if my server is down? No request will get out of your home. And you might keep guessing: Is the Internet down or just my server?

Hardware excursion

For the very first time, I cleanly separated my work (MacBook Pro M3 Pro) and my private digital life (Framework AMD 13" with Arch + COSMIC). I deinstalled all work related apps and logins from my phone (iPhone 13 Pro Max). I use Firefox on all devices, Thunderbird on my Framework laptop (and use GMail via the browser on my work laptop). On my iPhone, I use the default Mail client. I also unplugged completely from Apple and hope to get a GrapheneOS native Android phone soon.

My (Firefox) extensions

• Hide shorts for Youtube Using YouTube Enhancer now for this.
• I still don't care about cookies
• Someone on lobste.rs pointed out Consent-O-Matic
• uBlock Origin
  • A commenter pointed out these are redundant if you use uBlock Origin (which has URL tracking protection and tracker blocking built-in):
  • SponsorBlock for YouTube - Skip Sponsorships
  • AdBlocker for YouTube
  • ClearURLs
  • Privacy Badger
• YouTube Enhancer
• Are.na
• Bitwarden Password Manager
• Bypass Paywalls Clean

Configuring uBlock Origin for maximum coverage

Open uBlock Origin settings (click the extension icon → three gear icon) and go to Filter lists. Make sure these are enabled:

Privacy section:

• EasyPrivacy (replaces Privacy Badger)
• AdGuard/uBO – URL Tracking Protection (replaces ClearURLs)

Ads section:

• EasyList

uBlock Origin's built-in filters (enabled by default) handle YouTube ads specifically—no extra configuration needed.

Click "Update now" at the top, then "Apply changes".

Web Services I use

• TickTick for ToDos
• YNAB for finances
• Excalidraw for diagrams
• YouTube for...so many things honestly. I disable my browser watch history so no video recommendations and rabbit holes for me, perfect!
• Miniflux - Self hosted for my own RSS needs
• WakingUp for meditation
• GitHub for my coding projects.

Go-to websites I often browse

0. isthelclcpoolopen.ca - A dashboard I created for our local community pool.
1. The Verge
2. Are.na
3. Popular Pinboard posts
4. Lobsters
5. HackerNews
6. NewsMinimalist
7. Letterbox

Flow

I often times open the browser mindlessly, click on the suggested shortcuts in Firefox of my last visited websites, and see what's new. Once a day or around 3 times a week, I check my RSS feed. I really enjoy going to the websites directly, and RSS seems to... clean and stripped down. But I also don't want to check 15 blogs manually every day, so it's good enough.

I save websites (articles really) to my Are.na account and promised myself to read it later. Which... I barely do. I started a TickTick list with an every day task to read at least 2 articles from my "Aha! Coding" channel. And I want to read more papers and watch tutorials this year. It's always a nice attempt, and once work is heating up, I read up on so many things I need at that moment, that I don't have much time or energy left to read "general purpose" content. But every time I come across a new problem, I find a saved article months later which would have helped me - at least partly - with that. So I want to make a new attempt of being religious about reading tech articles again.

HackerNews is still one of my most visited website. I barely read the comments anymore, maybe the first one. But it's a good hub to know what's generally going on in the wider industry. Same with Lobsters, but I enjoy going through the comments there, even of posts I am not interested in. Pinboard is another one where I go through the popular saved articles, but don't use the service myself anymore.

For meditation and introspection, I enjoy WakingUp. It's sometimes "too far out there", but it's less cluttered than the other suppose-to-be meditation apps. And I still need some prompts or guidance, especially during a hectic day with work, family, hobbies and friends.

For my ToDos: I actually managed to have 0 ToDo apps during most of 2025. They always stress me out seeing all the open things in my life I currently can't make progress on. Work is manged separete, and life is happening so much at the moment with kids and family, that the top 3-5 priority tasks are always obvious. But I also realized I am missing out on cleaning out my (digital) life and experimenting with project ideas or blog posts. It's good to have a place to store them again. I start to use TickTick. I wish OmniFocus, Things and TickTick would have a baby. But TickTick is the best multi-platform tool I found, and it's "good enough". I really miss going nerdy in OmniFocus, and I miss the sheer beauty and simplicity of Things. But oh well. Can't have it all it seems.

I mange my finances for the past 15 years with YNAB. It is slowly not the best tool anymore, and I want to try Monarch, but their Canadian bank account support doesn't seem to be working reliably. But hey, they actually have a dashboard for it!

Coding projects still live in GitHub, and it slowly time to self host my projects. I never really collaborate much on these projects, but just want to store them somewhere where I can run workers. I would miss the hosting static websites via GitHub pages, so I have to figure out how to do that.

A bigger part takes YouTube. I listen to DJ sets, follow a few channels and often times watch tutorials or talks on it. YouTube is I think the only service which I am very happy to pay money for. Now it's owned by Google and I am sure there are some shady things going on with pushing videos front and center. I disabled my watcb history, so I see a black blank page when I open the general website. I have three YouTube bookmarks:

• Subscription view
• "Watch it later" playlist
• My own "Music" playlist

So I never browse YouTube mindlessly, and get no video recommendations (disabled also via one of the YouTube extensions).

That's it - that's my setup. I use Firefox Sync to have my account stored not only on my laptop, and as soon I setup Firefox somehwere else, all my extensions and bookmarks are back. And I trust Mozilla with my data (I work there and can talk to the folks and they are all great :)).

I don't expect that I change this setup very much in 2027 - the web feels much slower to change, but I still want to have this noted down somewhere.

Be careful what you wish for. MobileMe ceased to exist. It was a horrible slog to use, and the best part of this service was my shiny @me.com E-Mail address which I still have. iCloud is now fast, and every service in Apple's ecosystem is bundled under one platform. Instead of being an open, configurable environment with APIs, we have another closed ecosystem with the only goal to keep you inside.

In a way that makes it intentionally hard to switch services or add other devices. I started a new job almost 2 years ago, and had to give up my company MacBook, and thought to myself: I need a backup machine. I ordered the Framework laptop and put Arch + COSMIC on it. I use Firefox and Thunderbird, but had no way of integrating iCloud Drive in a nice way into my backup setup.

Few months down the line, and COSMIC entered the beta version. It is stable and fast. I fell deeper in love with my Framework laptop, which released a 2.8k 120Hz screen (finally), which I could just order and install myself (in less than 5 minutes).

I also fell in love with tinkering again, and felt constrained by the whole Apple ecosystem. To a point where every device but the Apple TV seems like a drag to use these days. So, time to break up with Apple (again).

The problem with bundling

Here's what I realized: Apple bundles four things that should be separate.

One account suspension, one forgotten password, one "suspicious activity" flag — and all four collapse at once. Your email address, your photos, your passwords, your files. Gone.

I don't think Apple is going to lock me out. But I also don't want my digital life to depend on that assumption.

My existing setup

• I already owned a very small, dedicated server with OVH. But it was not very powerful (4GB of RAM, low storage, 100Mbit/s up/down, located in France — I live in Canada now, so slow pings). I configured NGINX, had domains pointed to the IP address, had existing SSL certificates with Let's Encrypt and other small services deployed on it.
• I have 3-4 domains registered with GoDaddy.
• I use it as my DNS server via AdGuard Home.

My goals

I wanted a more powerful server, more RAM, bandwidth and also a faster ping. I wanted a built-in VPN, so certain services are forced to use a VPN connection or break by default. I wanted to host my own photos, files, calendars and contacts. I want an easy enough backup solution which runs by itself to a second, remote location.

How I went about it

The thought of setting up a whole self-hosted infrastructure seemed more than daunting. So many services to run and maintain, different installation scripts, docs which are probably outdated or don't exactly fit my particular needs etc.

But hey, we have a shiny new toy at our disposal: LLMs. It seemed to be perfect for this use case.

In my experience and usage, LLMs are vaguely helpful here. They can nail a solution, or lead you off stray if you are not careful in your planning phase. I was overwhelmed with transitioning and keeping existing files, and which services to use for calendars, contacts, photos, file sync, DNS, media handling, and legal torrenting for larger files and backups.

The LLM output was helpful in a way, where I could ask:

"These x,y,z are my needs. Tell me for File sync every possible self-hosting solution, and create a table with pros and cons. I want to be totally device independent, and it needs good Android, iOS, Linux and macOS apps or integration".

This helped me get to know solutions I maybe wasn't aware of. I did this with every category to get a first overview what's out there.

Turns out, I knew every solution and was also aware of its pros and cons. But good to know anyway.

What I chose

For email, I went with Migadu. Small Swiss company, straightforward pricing. I own the domain, they handle the mail. If they disappear, I point my MX records elsewhere and keep my address. That's the key thing — the address is mine now.

How it went

The real power doing this with LLMs was the guided step-by-step procedure without having to have hundreds of tabs open. I purchased a new dedicated server with OVH (this time: Intel Xeon, 64GB RAM, 4TB hard drive, located in Canada), and while I waited for the setup to be complete, I logged into my old server and printed every config to the terminal (cat /path/to/config) and copy pasted the whole terminal output. I pasted it in Claude and said: "This is my setup, I want to re-create it on my new server."

It then just told me the sudo apt install commands and printed out the updated configs for each service, so I could just copy paste and move on. It even suggested to use a tmux session for the larger rsync operation from server A to B, so closing the ssh session wouldn't kill it. Obvious, but I am sure I would have closed it by accident, realized it, googled, had an "Aha, of course tmux" moment and looked for all the right commands on some random blog post.

I wish LLMs would credit all their sources more. I love these blog posts, and using them subconsciously through a LLM feels just wrong.

I really like that I can tell the LLM to guide me through it step by step, don't be overly expressive and basically just serve as a better helper so I don't have to type everything by hand.

Each service gets its own subdomain and NGINX acts as a reverse proxy. Setting this up was surprisingly straightforward once I understood the pattern.

The NGINX reverse proxy pattern

Here's what a typical service config looks like (this is for Vaultwarden):

server {
    listen 443 ssl http2;
    server_name vault.MY_DOMAIN.ca;

    ssl_certificate /etc/letsencrypt/live/MY_DOMAIN.ca/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/MY_DOMAIN.ca/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The service (in this case, Vaultwarden) runs on localhost:8080. NGINX listens on 443, terminates SSL, and forwards requests. Each service follows this same pattern, just different ports and subdomains.

DNS setup

For each service, I add an A record in GoDaddy:

All subdomains point to the same server IP. NGINX looks at the Host header and routes to the right service. One wildcard Let's Encrypt certificate covers them all.

Service highlights

Vaultwarden was probably the easiest. It's a single Docker container that implements the Bitwarden API. The official Bitwarden apps (iOS, Android, browser extensions) just work — you just point them to your own domain instead of vault.bitwarden.com.

Seafile handles file sync. It's fast enough that I can edit a file on my desktop and see it update on my phone within seconds. The mobile apps are decent, though not as polished as iCloud Drive. The Linux client (seaf-cli) works great as a daemon.

Immich is honestly mind-blowing for a self-hosted project. Face recognition, object detection, map view, all running on my own hardware. The mobile app has auto-upload and it just works. The only catch: the ML container uses about 8GB of RAM, but I have 64GB so who cares.

The VPN routing trick

I wanted Transmission to always go through Mullvad, but not everything else. Turns out you can do this with WireGuard and policy-based routing.

Transmission runs as a specific user (UID 103 on my system). I added a routing rule that sends all traffic from that UID through the WireGuard tunnel:

ip rule add uidrange 103-103 lookup 200 priority 99
ip route add default dev wg-mullvad table 200

Everything else goes direct. I broke my connection quite a few times before I had figured it out.

Backups

This is the part I'm most paranoid about, and I think rightly so.

3-2-1 rule: three copies, two media types, one offsite.

1. Live data on the server
2. Encrypted daily backup to a Hetzner Storage Box (offsite, in Germany) using restic
3. Weekly sync to an external drive at home

Daily backups run at 4am via systemd timer. Databases (Immich PostgreSQL, Seafile MariaDB) get dumped to SQL first so the snapshots are consistent.

How the automation works

The backup is triggered by a systemd timer that runs daily:

[Unit]
Description=Daily backup to Hetzner Storage Box
Documentation=https://restic.readthedocs.io/

[Timer]
OnCalendar=daily
OnCalendar=*-*-* 04:00:00
Persistent=true
RandomizedDelaySec=15min

[Install]
WantedBy=timers.target

The timer calls a service that runs the backup script:

[Unit]
Description=Backup to Hetzner Storage Box via Restic
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/maple-backup.sh
User=root
Environment="RESTIC_REPOSITORY=sftp:uxxxxxx@uxxxxxx.your-storagebox.de:23/maple-backups"
Environment="RESTIC_PASSWORD_FILE=/root/.restic-password"

The actual backup script dumps databases, then uses restic to create encrypted snapshots:

#!/bin/bash
set -euo pipefail

# Dump databases before backup
docker exec immich_postgres pg_dumpall -U postgres > /backup/immich-db.sql
docker exec seafile-mariadb mysqldump -u root -p"$DB_PASSWORD" --all-databases > /backup/seafile-db.sql

# Run restic backup
restic backup \
    /opt/docker/vaultwarden \
    /opt/docker/seafile \
    /opt/docker/immich \
    /backup \
    --exclude='*.tmp' \
    --exclude-caches

# Cleanup old snapshots (keep last 7 daily, 4 weekly, 6 monthly)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

echo "Backup completed at $(date)"

The Hetzner Storage Box is accessed via SFTP. Restic handles the encryption, deduplication, and compression. If the server dies, I can restore everything from the Storage Box to a new machine.

What it costs

Compare that to iCloud+ 2TB ($13) + 1Password ($5) + Spotify ($11) + VPN ($8) = ~$37/month.

So yes, I'm paying about $19/month more. But I have a dedicated server with 64GB of RAM and 4TB of storage. I can run side projects on it. Experiments. Whatever I want.

What I learned

The technical setup wasn't that hard. NGINX configs are basically copy-paste once you get the pattern. Docker Compose makes services reproducible. Systemd timers are rock solid.

The hard part was the mental shift. With Apple, everything just worked — until it didn't, and then you had no control. Now I have full control — but I'm also responsible when things break.

I check the backup logs every week. I monitor disk space. I keep the system updated. It's maybe 30 minutes of maintenance per month. Totally worth it for the peace of mind.

The biggest win? I own my identity now. My email address is on my domain. My files are on my server. My passwords are in my vault. If any single service disappears tomorrow, I can move. That's the freedom I was looking for.

Here they are:

Understand the problem/feature to evaluate the possible solutions

Can it be efficetively solved with existing things or require new code?

Aim for simplicity

Think about what is necessary and sufficient to solve the problem, make interfaces and interactions as simple as they can be, don’t write “clever” or confusing code unless absolutely necessary.

Aim for elegance

Code should be readable and look beautiful, APIs should be small and well defined.

Aim for efficiency where possible

Avoid too many layers of abstraction or algorithms or structures that don’t scale.

Think about clear separation of policy and mechanism

Aim for simple clean mechanisms that you can layer different policies on as needed.

Think about extensibility

What things would your solution preclude being done in the future, try to spot leaky abstractions.

Think about failure scenarios and how to test for them and recover or fail as gracefully as possible.

Use useful comments to help future maintainers

Including yourself!

TL;DR

When we talk about a web service, we, more often than not, mean deployed code which listens on a certain IP address and port and responds to HTTP messages. There are many steps involved for two parties to be able to communicate with each other. Application developers are mainly confronted with two pieces of this process: TCP and HTTP.

TCP is a protocol which two parties use to establish a connection. They follow a certain pattern (three-way-handshake) where they send and receive short messages to negotiate the connection details. After establishing this connection, you can receive and send HTTP messages to the other party. HTTP is a stateless protocol which demands a response for every request, and defines, besides other options, the size and format of the data it is sending.

There is a great advantage in knowing how exactly the communication with TCP works and how and where HTTP is added. Having this information can help you improve the performance of your server application and make it more secure. If, for some reason, you want to choose any other protocol than TCP or HTTP, you know where and how to replace it.

Rust and the OSI model

Web services are deployed on computers connected to the internet. These computers have IP addresses and open ports they listen to for new messages. Applications running on these machines are signaling interest on certain messages so they can process and answer these.

A message sent to a server has to go through multiple layers and geographically different locations for it to arrive. To get a better understanding of these different layers, the OSI model was created. It is a conceptual framework to standardize the communications.

As we can see in the following figure, a client can’t just send over data to a server. It needs to go through many different routers to find the right server. For it not to get lost, a user application and the kernel are adding several headers to it, so each layer of the communication process knows where to route it to.

A packet goes through these different layers, and almost all of them add an extra header on top so the next layer knows how to deal with the information. Your application adds a HTTP header on top of the data it wants to send, before the kernel adds the TCP, IP and Ethernet header.

The receiving server goes through the same process but in reverse. It has to dismantle each header until it can read the data inside of it.

The added header sizes are standardized, so the operating system and the kernel know how many bytes they have to strip out until they can read the data. We can use this information now to get a better grasp on our data we receive.

In the OSI overview figure earlier, we see that the ethernet and IP header are pretty non-negotiable. But everything else is more in our control. We can choose UDP for example instead of TCP and can use our own protocol instead of using HTTP. We can, for example, have security reasons to implement our own protocol (with an own header size), so intruders who are reading our messages can’t make sense of them.

Where does Rust come into play? A web service has to support the following mechanism for it to be able to create connection, receiving messages and sending responses:

• Opening a connection to another client
• Support the different layers (TCP and HTTP)
• Hold connections
• Parse receiving messages
• Send proper HTTP messages back

Many other programming languages include a rich standard library to create these HTTP servers. Rust is however a little bit different. Being a Systems Programming Language, Rust wants to be as small as possible and also functioning well on micro controllers for example who don’t always want to communicate via HTTP with their peers.

Therefore, Rust decided just to include a basic understanding of TCP in the standard library, and no build-in support for HTTP. The blue parts (TCP/IP) are included in the Rust standard library. If you want to create web server which supports HTTP, you have to create your own. Luckily, this is a common scenario, so the community already built some battle-tested web server implementations in the past. The crate hyper for example is widely used as a http server.

There are also crates for web frameworks, which include all the layers beneath them (HTTP, TCP etc.) and offer all the modern ergonomics like parsing URL query parameter, reading and returning JSON and so on.

This also gives you a greater choice: If you just want a minimal functioning application server without much bloat doing one thing, you can create the few functions you need by hand and have a lightweight solution afterwards.

If you are coming from Go, NodeJS or Java, this means a shift in perspective. You probably have to look for a library which supports your needs from the start instead of going a few more miles without thinking about help from the community.

In addition to HTTP, you also need to make sure the connection between client and server is secure. This is handled via TLS (Transport Layer Security), a successor of SSL. Rust also hasn’t built-in TLS support, but there exist a few packages which support you in enabling TLS in your application.

Opening a connection

We look at an example where a browser application is sending a HTTP request to our web service which is written in Rust. We will dive shortly into how exactly the bytes arrive at the kernel, and how our Rust application is getting the bytes delivered into the running application. Note that this is all abstracted away through libraries, but you can later on choose not to use such library and implement something via the Rust core library itself.

In addition, it is helpful to know or at least heart about it once how exactly the flow of bytes in a web service works, so you can spot bugs, bottlenecks and other misconfigurations later on in your running application.

When the client sends a HTTP request, the kernel is wrapping the data in a package with a HTTP and TCP header attached to it. It arrives on our server at the so called NIC (network interface card). The client first has to establish a TCP connection to our server. Once done, our kernel opened a socket to which is listening to this address for incoming messages.

If you want to dig deeper into the kernel side of networking, I highly recommend Beej's Guide to Network Programming.

When we run a web server in Rust, we also have a socket to the operating system side where we can listen to incoming messages. The kernel’s job is to copy the data from the incoming TCP message onto our internal socket and notifies us when new data arrived.

In detail, the kernel reads the incoming messages and figures out which TCP connection (IP address and port) it is associated with, looks up the corresponding socket and copies the data to a receive buffer.

It notifies the process which is listening to new data to this socket and copies the data to a new buffer once the process is signaling interest. It copies the data from the receive buffer into the read buffer so that your server application can get the bytes out of the kernel into your program.

We learned earlier that Rust supports TCP right out of the box. Therefore, we can create, open and listen to a TCP socket within Rust. Once we receive a message, we can also answer back on the same socket. We can basically send any text back to the socket, we just have to be aware that the other side can interpret what we are sending.

Let’s open a socket, so the kernel knows where to forward incoming requests to. Each socket has to know the protocol being used (TCP in our case), the IP address and the port. In Rust, the TcpListener is handling the job for us, and we can use bind to tell the kernel the address and port we are listening to.

use std::net::TcpListener;

fn main() {
    let listener = TcpListener::bind("127.0.0.1:8080").unwrap();
   	for stream in listener.incoming() {
        let stream = stream.unwrap();
        println!("stream accepted {:?}", stream);
}

If you use cargo run to start the server, open a browser and navigate to localhost:8080, you see that we print something like this:

stream accepted TcpStream { addr: 127.0.0.1:8080, peer: 127.0.0.1:56931, fd: 4 }

This is a step in the right direction. But why don’t we see any data or HTTP headers? It’s because we receive a stream and print it on the console. We actually have to read the content from the stream.

When reading from the stream like that, the baseline we expect is UTF8 encoded text. At this point, the kernel already stripped away the TCP header and all we have left is the data encapsulated in it. This can either be HTTP headers + data or some other headers attached to the data.

Parsing our stream content, we should see the headers and also the data in plain text, and it is on us to strip away the headers to get to the real data of the message. Headers however play an important role: They help us interpret the data we receive.

There are many different HTTP headers, and the server is in charge to interpret them in the right way and work with them.

When using a web framework later on, all the details are abstracted away. However it is vital to understand the flow how information arrives at your application so later on, you can choose asynchronous strategies, your own protocol and where to look for optimizations.

Adding HTTP

The TcpListener gave us a stream, which we need to read and interpret. We have to somehow take this stream and read what’s in it. For this, we need a few components. First, we need to create a new function which takes an incoming stream and writes the bytes back to a local buffer. From there we can parse the data accordingly and send back an answer.

We add a helper function which does exactly that for us.

fn handle_stream(mut stream: TcpStream) {
    let mut buffer = [0; 1024];
    stream.read(&mut buffer).unwrap();
    println!("Request: {}", String::from_utf8_lossy(&buffer[..]));
}

All we have to do is to call this function in our iterator.

use std::net::{TcpListener, TcpStream};
use std::io::prelude::*;

fn main() {
	let listener = TcpListener::bind("127.0.0.1:8080").unwrap();
	for stream in listener.incoming() {
	    let stream = stream.unwrap();
	    handle_stream(stream);
	}
}

After starting the application again with cargo run, you can open a new browser window and navigate to the website localhost:8080 and see what your application is printing onto the console.

It will vary with your browser of choice, but the current version of Safari will send multiple requests which look like the following:

GET / HTTP/1.1
Host: localhost:8080
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Accept-Language: en-us

It includes:

• GET: The HTTP method
• /: The Path on the server
• HTTP/1.1: The version of the HTTP protocol
• HOST: The host/domain of the server we want to request data from
• Accept-Language: Which human language we prefer and understand

Instead of just printing out the stream, we can start to look at the HTTP specification, store the content in an array and iterate over it line by line, and create a HTTP struct out of it. This work is not trivial since we need to check the length of the message from the HTTP header and build the full message ourselves.

Thankfully there are already crates published in the Rust ecosystem which help you with this task. So, deploying a http server in production is much less work than we do here by hand.

After you opened your browser and navigated to localhost:8080, you saw an error page. That’s because we don’t return an answer yet, which the HTTP protocol requests we do. To solve this problem, we can write onto the stream and send bytes back to the client.

fn handle_stream(mut stream: TcpStream) {
    let mut buffer = [0; 512];
    stream.read(&mut buffer).unwrap();
    println!("{}", String::from_utf8_lossy(&buffer[..]));

    let response = "HTTP/1.1 200 OK\r\n\r\n";
    stream.write(response.as_bytes()).unwrap();
    stream.flush().unwrap();
}

When you open your browser now and navigate to localhost:8080, you will get a blank page instead of an error. We successfully communicated via HTTP to another application in just a few lines of code.