I recently submitted a small PR to SeedSigner — the multisig message signing fix I wrote about in my previous post. After opening it, I tagged two maintainers in a comment asking for feedback. One of them, kdmukai, was not happy about that: I consider it rude to directly “@” reference any of us just to call for our attention. Notice that your “@” message adds nothing that is not already stated in the PR description. Reserve “@” call outs for when there are specific questions that the targeted person is the best resource and the discussion may be stalled until they weigh in. ...

I run CertainKey, a service that provides ownership and control verification reports for self-managed super funds (SMSFs) holding bitcoin. Part of that process involves proving that the fund trustee controls specific keys in a multisig wallet — not by moving funds, but by signing a message with each key individually. For this I built Gatekeeper, a tool that verifies BIP-322 message signatures. The flow is simple: the customer signs a known message with their hardware wallet at the relevant derivation path, and Gatekeeper confirms the signature matches the expected public key from the wallet descriptor. ...

Over the past few years, my approach to exposing homelab services to the internet has gone through four distinct phases. Each one solved a real problem and created a new one. If you’re self-hosting services and trying to figure out the “right” way to handle ingress, TLS, and reverse proxying, this might save you some time. Phase 1: Port Forwarding with DDNS The simplest thing that works. I forwarded ports on my router to services like Nextcloud, Bitcoin Core, and LND, and used No-IP for dynamic DNS so the world could find my changing residential IP. ...

A few days ago I wrote about shutting down CertainKey, my service for cryptographic verification of Bitcoin holdings. I’d built what I thought was the right tool, but couldn’t find a market willing to pay for it. Turns out I might have given up too early. I recently had a conversation with an SMSF holder whose auditor was asking for proof of ownership and control over their Bitcoin. The auditor’s initial suggestion? Broadcast a small transaction to prove control. ...

The results are in. One week of maximum aggression fee policy on my Lightning node. Here’s what happened. The Baseline When I cranked the dial on January 29, the channels looked like this: Channel Local Balance Ratio triple_lightning 99,335 sats 1.8% Babylon-4a 251,607 sats 5.0% CLB 4,943,843 sats 98.9% Three channels totalling 15.5M sats of capacity, almost all of it on the wrong side. The fee policy: deep inbound discounts on depleted channels (-2400 ppm), near-free outbound on overloaded ones (1 ppm), hourly updates via charge-lnd, and a weekly auto-tuning script to ratchet fees up or down based on observed movement. ...

A few of us play darts remotely — I’m in Brisbane, Thomas is in Dubbo, others are scattered around Australia. We jump on a voice chat, call out our throws, and each keep score on whatever’s handy. I use a notepad. Some of the others use chalkboards. It works, but someone always loses track of who’s closed what, and there’s no record of the game afterwards. So I built Good Grouping — a self-hosted live darts scoring app. One person enters the throws, everyone sees the board update in real time over WebSockets. Passkey auth, crown tracking for bragging rights, the works. ...

I renamed all three nodes in a Proxmox cluster recently. The hostname changes went fine. Corosync updated without drama. HA picked up the new names. Then I put a node in maintenance mode and watched every migration fail. Host key verification failed. ERROR: migration aborted: Can't connect to destination address using public key The fix took longer to find than the actual rename. Why Rename Nodes? The nodes had legacy names from initial setup — the kind of thing that made sense at the time but doesn’t scale. A proper naming convention helps with inventory management, scripting, and not having to explain cryptic hostnames to every new team member. ...

Most bot and notification setups rely on Telegram or Signal. Both are fine, but they require trusting third-party infrastructure with your metadata. After reading about OpenClawd and noticing the Telegram dependency, I decided to set up something more private. SimpleX is a messaging protocol with no user identifiers - no phone numbers, no usernames, no accounts. Combined with a self-hosted relay server, you get end-to-end encrypted messaging where you control the infrastructure. ...

This is a follow-on to my SimpleX CLI Docker Setup post. If you read that, you might remember the socat workaround I used to get around the WebSocket server only binding to localhost: command: > sh -c "socat TCP-LISTEN:5225,fork,bind=0.0.0.0 TCP:127.0.0.1:5226 & simplex-chat -p 5226" It worked, but it always felt like a hack. The underlying issue was that simplex-chat hardcodes the bind address to 127.0.0.1 when you use the -p flag. ...

I run multiple Caddy instances across separate networks, all using a shared oauth2-proxy for authentication. The setup worked fine when Caddy and oauth2-proxy were on the same network. When I moved some services to a different network and had Caddy call oauth2-proxy over its public HTTPS endpoint, group-based authorization broke silently. Users could log in. The cookie was valid. But every request failed with “Access denied: No group membership found.” ...