Hansen IT Solutions

A phone stops being a phone the moment you pull the SIM

Every homelabber has one: a phone in a drawer, three Android versions behind, battery at 84% health, “worth maybe fifty bucks.” The usual fates are eBay, the e-waste bin, or a guilt-inducing death in a kitchen junk drawer. There’s a better one. Pull the SIM, put it on Wi-Fi, and that drawer phone becomes the cheapest decent pocket computer you own — a screen, a battery, speakers, a camera and a Wi-Fi radio, free of carrier obligations and mostly free of the attention economy if you set it up right.

The insight that unlocked this for me came from a piece over at XDA, where Yash Patel walked through the six apps that turned his ageing Pixel 6a into a daily productivity device. What struck me wasn’t the apps themselves — it was the pattern behind them. Nearly all of them are open source, offline-first, and account-free. That’s not a coincidence. A phone you’ve retired from daily-driver duty is the one place you can finally insist on software that doesn’t want anything from you.

Strip it before you build it

The setup is subtraction, in this order:

• Factory reset. Start clean. You’re not migrating a life to this device, you’re commissioning a tool.
• Sign in with as little as possible. Skip every account the setup wizard will let you skip. The goal is a device that loses nothing meaningful if it’s stolen from the kitchen bench.
• Airplane mode, then Wi-Fi on. The cellular radio is the single biggest battery drain on an idle phone. Off means a device that sips power on standby for days.
• Remove the leftovers. The carrier and OEM clutter you never chose doesn’t need to live out its retirement on the device either:

adb shell pm uninstall -k --user 0 com.google.android.apps.youtube.music

The --user 0 flag uninstalls for the current user profile only — no root needed, and a factory reset undoes it all if you change your mind. Work down the app list in Settings and reclaim the storage.

One honest caveat: a lithium battery on a permanent charger is a swelling risk, not a set-and-forget appliance. Keep the device somewhere visible and ventilated, out of sunlight and definitely not under a pillow. If the case starts lifting, that’s the whole project over — recycle it. An old phone is free, but it isn’t worth a fire.

The toolkit: offline-first, self-hostable, no accounts

Here’s the stack I’d put on it, and why each piece earns its slot on a homelab device rather than a phone you merely tolerate.

LocalSend — the LAN is the transfer layer

LocalSend moves files between the phone and anything else on your network — laptop, desktop, another phone — over your own Wi-Fi, no cloud hop, no cable, no account. It’s open source and cross-platform, which matters more than it sounds: the moment “get this off my phone” becomes “upload it and download it,” you’ve introduced a third party into moving a screenshot twenty feet. On a network you already run, that’s just silly.

Joplin — notes that sync to a server you own

Joplin is the note app for people who run their own infrastructure, because its sync target is a decision, not a mandate: WebDAV, Nextcloud, Joplin Server, or a file drop target you choose. Point it at the box in the cupboard and your notes travel between pocket terminal and desktop through your own network, with end-to-end encryption available when you want it. A capture device with a sync story you control is a genuinely different product from one that syncs to someone’s business model.

Karakeep — a capture inbox you can self-host

The habit the XDA piece nails is capture: interesting link, share sheet, done. Karakeep is an open-source bookmark manager that can run on your own hardware, ingests links, images and notes, and tags them with AI assist so your future self can actually find them again. This is the exact pattern behind every “read it later” graveyard you’ve ever abandoned, except the pile lives on your disk, in your backups, under your retention policy. My own link-scanning workflow is basically this idea with more cron jobs attached — a capture inbox you own is the front door to a lot of interesting automation.

Timety — time tracking that never phones home

Focus timers and habit trackers are the app store’s creepiest genre: intimate behavioural data, monetised aggressively. Timety does focus sessions, habits and time analytics offline-first with no account at all. The data that describes how you spend your attention stays on a device with no SIM and no cloud — which is precisely the arrangement that makes me willing to track it in the first place.

Breezy Weather and Firefox — the quality-of-life pair

Breezy Weather is the weather app for people who dislike being the product: open source, customisable widgets, and your choice of forecast provider. Firefox rounds it out because it’s the one mainstream Android browser that still takes real extensions, and on a device this stripped down, a browser with uBlock Origin is a different machine — pages load like it’s five years newer than it is.

What it’s actually for

Be honest about the role. This isn’t a second phone; it’s a terminal. Mine lives on the desk as the capture-and-glance device: notes go to Joplin, links go to Karakeep, files move via LocalSend, and the weather and dashboard widgets do the ambient information thing. Bedside is the other obvious posting — a device with no notifications worth reading is the first alarm clock in a decade that doesn’t beg for attention at 11pm.

And that’s the comparison that makes the project worth an afternoon: a cheap Android tablet with a worse screen, worse radios and ads in the launcher costs actual money. The drawer phone costs a factory reset and six app installs. In a homelab, the best node is always the one you already own.

Know its limits

Two rules keep this sane. First, it is not critical infrastructure — nothing should break when (not if) the battery dies or Android 15’s last security patch ages out. It’s a convenience layer, so treat outages as cosmetic. Second, keep it account-light on purpose. A SIM-less device can’t receive SMS, which makes it the wrong home for anything that needs text-message recovery codes — but that’s not a bug in the plan, it is the plan. The moment a device accumulates logins, it stops being a toy terminal and starts being an incident waiting for a payload.

Retire the SIM, not the phone. The hardware was never the problem — it was everything the phone was required to be. Take that away and what’s left is a very good small computer that already lives in your pocket’s shape.

The ad blocker’s blind spot

Every home lab eventually grows a DNS blocker — Pi-hole, AdGuard Home, whatever keeps the trackers out. And every one of those setups has the same quiet failure: the TV. YouTube serves its ads from the same infrastructure that serves the video itself, so there is no domain to sink. Block the ad hosts and you block the show. The result is that the biggest screen in the house runs the most aggressive ad load in the house, and your careful network-level filtering does nothing about it.

That gap finally has a decent answer. João Carrasqueira’s writeup over at XDA pushed iSponsorBlockTV onto my radar: a small open-source container that mutes YouTube’s ads, presses skip when the button appears, and cuts sponsored segments out of videos — on every TV in the house, without touching the TV or swapping the app for anything.

The trick is that it isn’t a blocker at all

Once you see how it works, it’s one of those designs that seems obvious in hindsight. The YouTube TV app already has a remote-control protocol — it’s how your phone links to a TV and controls playback. iSponsorBlockTV speaks that same protocol. You pair it with your TV using the same “link with TV code” flow you’d use for a phone, and from then on it sits on your LAN watching the playback state like a very fast, very literal-minded family member:

• An ad starts — it mutes the TV instantly, then presses “Skip” the moment the button becomes available. Unskippable ads still play, but they play silently, which turns a shout into a shrug.
• A sponsored segment, intro, outro, or “smash that like button” reminder arrives — it consults the SponsorBlock database and jumps the playhead past it, per the categories you enable.

No modification to the TV, no sideloading, no third-party YouTube client that breaks every time Google changes something. The app stays stock and updated. The container just acts like a polite second remote. Because it pairs per-device, you can add every TV in the house — and apparently even the Nintendo Switch’s YouTube app, which is the kind of detail that tells you the pairing protocol is the real interface here, not some hack on a specific app version.

Deployment, the short version

This is a ten-minute job on an existing Docker host, which is exactly why it belongs in the home lab rather than on some appliance:

# grab the compose file from the official wiki, then:
docker compose up -d

# interactive setup inside the container:
docker compose exec isponsorblocktv iSponsorBlockTV setup
#  → choose segment categories and skip behaviour
#  → add each TV using the code from
#    YouTube → Settings → Link with TV code

If you’re a Proxmox household, the community scripts will drop it into an LXC instead, and the setup flow inside the container shell is the same. Resource cost is effectively nothing — this is a watch-and-wait service, not a transcoder — so it earns its keep on even a low-power always-on box.

The configuration decisions worth actually thinking about:

• Which segment categories to skip. Sponsors, intros, and interaction reminders are easy wins. “Filler” is where taste lives — some creators’ filler is the reason you watched.
• Minimum segment length. Skipping every sub-two-second pause makes playback feel epileptic. Set a floor.
• Mute-only versus skip for ads. Muting is the killer feature; the auto-skip just saves the button press.
• Channel whitelist. Yes, it needs a YouTube API key — annoying, but it’s the honest way to let the creators you actually value keep their sponsor reads.

The honest boundaries

Three things this tool does not do. It doesn’t block ads — it suppresses them after they start, so YouTube still counts the impression and the ad still technically plays (muted). It doesn’t help where the SponsorBlock database has no coverage; long-tail videos get no segment skipping, because that data is crowd-sourced. And it only works for devices that speak the TV-app pairing protocol — this is a living-room fix, not network policy.

It’s also worth being an adult about the economics. Muted and skipped ads pay creators less. The sponsor segments cut by SponsorBlock are the ones funding the video you’re enjoying. My position: mute YouTube’s own ad firehose without guilt, but whitelist — or better, directly support — the handful of channels you’d genuinely miss. If YouTube is the main screen in your house and this whole paragraph stings a bit, the grown-up answer is a Premium family plan; the container is the workaround, not the principle.

Worth the container slot?

Yes, and it’s not close. The TV is the most-watched, worst-behaved app most households own, and nothing in the standard self-hosting stack — Pi-hole, AdGuard Home, reverse proxies, the whole rack — laid a glove on it. iSponsorBlockTV gets halfway there for the cost of one tiny always-on container and a TV pairing code. It went from “article I read” to permanent resident on my box the same afternoon, which is the highest praise a homelab service can earn.

Small business footnote: this is a home comfort, not a client-site tool. Don’t deploy it on networks you manage for other people without asking — filtering someone else’s ads is a decision they get to make, not you.

Five challengers, one crown, and a category error

An XDA writer spent time with five open-source Obsidian alternatives — Logseq, Joplin, TriliumNext, SiYuan, and AppFlowy — and walked away with a clear winner: AppFlowy, won on polish, built-in databases, Kanban boards, and AI features that arrive without a plugin spree. It’s a fair verdict, and I don’t argue with the testing. I argue with the framing — because I don’t think the shootout proves AppFlowy is the best Obsidian alternative. It proves the tester was shopping for Notion.

You don’t switch apps; you hire them for a job

People leave Obsidian for roughly three reasons, and they’re completely different jobs:

• Plugin fatigue. You’ve spent twenty hours assembling a workspace out of community plugins and you’re tired of maintaining a cathedral.
• A Notion-shaped hole. You want databases, boards, and timelines — a project workspace — and you’re tired of building them out of plugins.
• Sync sovereignty. You want your notes on hardware you own, with no vendor in the loop, and Obsidian’s sync options feel like someone else’s product decision.

AppFlowy won the test because the test was job #2. It’s a genuinely good Notion-alike: block editor, nested pages, grid/Kanban/timeline views, charts, slash commands, AI assistance, Google Drive embeds. If your complaint about Obsidian was “I’m using it to run projects and it fights me,” AppFlowy is the correct answer and the polish gap the writer found in TriliumNext and SiYuan is real.

But if your complaint was job #1 or job #3, the winner’s podium looks nothing like that.

The field, matched to the job it’s actually good at

• Joplin is the sync-sovereignty answer that bores people into overlooking it. Markdown notes, end-to-end encrypted sync, and — the part a homelab owner cares about — it syncs over plain WebDAV, which means the Nextcloud you already run is your note backend. Nothing new to host.
• Logseq is an outliner with a journal-first habit loop. The “learning curve” the review hit isn’t a defect; it’s a different paradigm wearing Obsidian’s clothes. Hire it for thinking in outlines and backlinks, not for documents.
• TriliumNext is the team-wiki engine: deep hierarchy, scriptable, self-hostable server. Overwhelming UI, yes — because it’s aimed at people building a knowledge base, not a journal.
• SiYuan brings block references and real databases in one package, with a self-hosted server option. Strong feature set, rougher edges, especially on macOS.
• AppFlowy is the workspace: the most Notion-shaped of the five, and — the detail that matters here — its cloud has a self-hostable server, so a small team can run the whole thing on one Docker host.

The open-source nuance everyone skips

AppFlowy being open source is a real advantage over Notion — you can inspect it, fork it, and run the server yourself, which for a 3–10 person business that doesn’t want a vendor reading its ops notes is a legitimate appliance: one box, no per-seat SaaS, data at rest on your iron. That’s the deployment where I’d actually recommend it without hedging.

But “open source” is not “files you own.” Obsidian’s data model is a folder of plain Markdown — exit cost zero, toolchain grep, git, and everything else forever. AppFlowy’s data model is an app-shaped store that its server understands. You’re not locked in the way Notion locks you in, but you’re also not one tar command away from your own notes. If the job is notes, the folder still wins. If the job is running projects with other people, built-in databases beat a folder, and AppFlowy has earned its win.

The test to run before you switch anything

Write down the job in one sentence before you migrate a single note. Most “Obsidian fatigue” I see — including the plugin sprawl the original article opens with — is really a plugin cathedral problem, and the cure is deleting plugins, not changing apps. Deleting is reversible, free, and takes an evening.

But if the sentence you wrote down starts with “I need to track…” and ends with a board, a timeline, or a team — that’s not fatigue. That’s a hiring mistake: you’ve been employing a note app to do a workspace’s job. Then AppFlowy isn’t the alternative that won a shootout; it’s the tool you should have hired in the first place. And running its server next to your other self-hosted services is exactly where a setup like that belongs.

Wrong question, common answer

Every battery-powered ESP32 thread eventually gets the same reply: “just use a bigger battery.” It’s the wrong lever. Whether a sensor lasts six weeks or sixteen months on one charge is decided almost entirely in firmware and board choice — the battery is the last variable you touch, not the first. A recent roundup of ESP32 builds that run a year on batteries got me doing the arithmetic behind my own shelf sensors, and the numbers are more instructive than the project list.

The one number that rules them all

Take a standard 18650 cell at roughly 3,000 mAh. A year is 8,760 hours. Divide and your entire power budget is about 340 µA of average draw. Not peak — average, sleep included, always. Every design decision from here is just negotiating against that number.

Now the uncomfortable part: a typical dev board can’t meet it. The bare ESP32-C3 module sips a couple of dozen microamps in deep sleep, but the devkit wrapped around it adds a power LED, a USB-to-serial chip, and a cheap LDO with sloppy quiescent current. Perfectly good boards sleep at 1–2 mA because of that overhead — which is a dead cell in about two months while your firmware is doing absolutely nothing. Your code can be flawless and the board still loses.

So rule one: for battery builds, use a bare module or a battery-oriented board, or get out the soldering iron and lift the LED and regulator. Rule two is where the real leverage lives:

Your radio-time is your battery bill

Deep sleep is nearly free. Awake time is expensive, and radio time is the most expensive of all. Compare two honest duty cycles:

• The event-driven doorbell. Button wired to an RTC GPIO, ESP-NOW instead of Wi-Fi: wake, send one packet, sleep — under 100 ms per ring. Ten rings a day is one second of radio time daily. Averaged out, that’s under 2 µA. The battery’s own self-discharge dwarfs your firmware. This build runs until the cell ages out.
• The naïve temperature sensor. Publish over Wi-Fi every five minutes, and every cycle pays the full association tax: join, DHCP, MQTT connect, publish, tear-down — call it four seconds awake at ~120 mA. That’s a ~1.6 mA average, and the same cell dies in under three months despite “sleeping” 98% of the time.

Same battery, same chip, roughly a 40× difference in life, and not one milliamp of it was decided by hardware. The fixes are boring and effective: sample cheaply and batch readings in RTC memory (which survives deep sleep), keep the Wi-Fi connection parameters warm instead of renegotiating every wake, transmit a UDP burst every fifteen minutes instead of MQTT every five — or get the radio off Wi-Fi entirely.

Pick the protocol like it costs money, because it does

This is the part listicles gloss over. There’s a ladder, and each rung buys you an order of magnitude:

• Wi-Fi — most flexible, most expensive. Justified only when the device must speak to infrastructure directly and rarely.
• ESP-NOW — connectionless peer-to-peer between Espressif chips. Send-and-sleep in under 100 ms. Costs you one always-powered gateway board near your router; every battery node after that is nearly free to run. This is the right default inside a house.
• LoRa — when the distance is real: paddocks, sheds, the letterbox three houses of signal away. Low bitrate, but a soil sensor reporting twice a day will comfortably run a year on one cell.

The minimum viable firmware is smaller than you’d think:

// event node: wake on reed switch, report, die quietly
RTC_DATA_ATTR int opens = 0;                 // survives deep sleep
esp_sleep_enable_ext0_wakeup(REED_PIN, 0);   // magnet away = low
send_espnow_broadcast(opens);                // <100 ms of radio
esp_deep_sleep_start();

What a year-on-battery build actually looks like

The patterns that earn their keep, all of which appear in the roundup that started this:

• Door/mailbox sensors — magnetic reed switch on an RTC GPIO, event-driven wake, report to Home Assistant, sleep. No cable run to a letterbox ever again.
• Batching temperature nodes — sample locally, transmit on a schedule. RTC memory means you never rebuild state after a wake.
• E-paper dashboards — e-paper only draws power while refreshing, so a forecast card updated three times a day is nearly free. The moment you want hourly updates or colour, the budget changes species.
• Soil sensors — two readings a day, a MOSFET cutting power to the sensor between them (sensors that “idle” at a milliamp are silent budget killers), LoRa backhaul.

Know when not to bother

Engineering hours aren’t free either. If there’s an outlet within cable reach, USB power is cheaper than a power-budget optimisation campaign. The year-on-battery discipline pays off precisely where wiring can’t go: letterboxes, door frames, ceilings, garden beds, the wall you don’t own. Those are the builds worth doing the duty-cycle arithmetic for.

And do the arithmetic before the build, not after — a five-minute estimate of average draw against 340 µA tells you whether the project is a battery project or a USB project. That check has saved me more abandoned builds than any component purchase ever has. Most “it died after a month” ESP32 posts weren’t hardware failures; they were firmware that never met its own power budget.

Every board drags a toolchain behind it

Every ESP32 I’ve owned has eventually demanded a toolchain. esptool and its Python venv, PlatformIO and its bottomless cache, the Arduino IDE and its driver roulette, udev rules on Linux — and the worst case of all: the board that needs rescuing while you’re sitting at a machine with none of it installed. Half the friction of working with microcontrollers isn’t the hardware. It’s the software you’re expected to keep around for the ten minutes a month you actually need it.

ESPConnect collapses that pile into a browser tab. It’s an open-source control center for ESP32-class boards that runs entirely inside a Chromium browser — no installer, no account, no backend — using Web Serial to talk straight to the chip over USB. It grew out of Jason2866’s WebSerial ESPTool, which proved you could flash an ESP32 from a page; ESPConnect turns that trick into a whole maintenance workshop.

What you get without installing anything

Point a Chromium browser at version 89 or newer (Chrome, Edge, Brave, Arc) at the app, plug the board in with a data-capable USB cable, click Connect, and grant the browser permission to the serial port. After the handshake, a drawer of tools unlocks:

• Device Info — chip family, revision, MAC, flash size, crystal. More useful than it sounds once your parts drawer fills with anonymous DevKit clones.
• Partitions — a graphical map plus a table of every entry with offsets, sizes, and unused flash, so you can sanity-check a layout before you flash over it.
• File system — browse, upload, back up, restore, and format SPIFFS, LittleFS, or FAT partitions, with inline preview for text, JSON, images, and audio, plus usage gauges.
• Apps — your OTA slots: which one is active, what’s staged next, build metadata and sizes.
• Flash — flash any .bin with common offset presets and an optional full chip erase.
• Console — a real serial monitor: stream output, send commands, Ctrl+C, change baud rate, reset the board.
• Integrity — MD5 over any offset and length, for verifying what’s actually on the chip.

That list reads like a desktop IDE’s debug menu. It’s a web page. Nothing to install is not a gimmick here — it’s the entire value proposition.

The feature that matters: back up before you break it

Flashing gets the screenshots, but backups are why I bookmarked this thing. ESPConnect can image individual partitions, the partition table, only the used regions of flash, or arbitrary address ranges you specify — and then MD5-check any of it against what’s on the device. That enables the workflow every firmware tinkerer learns the hard way:

• Image the used flash of a working device before you touch anything.
• Verify the MD5 so you know the backup isn’t a beautiful copy of nothing.
• Experiment. Break it. You will.
• Restore, and you’re back to known-good in minutes instead of spending an evening with a serial recovery guide.

It’s also the right move the day you buy a cheap pre-flashed board — a display module, a smart-home sensor — and want to replace its firmware with your own. Image the vendor’s flash first, and your curiosity stops being a one-way door.

Where it earns its keep day to day

Most ESP32 projects end up headless, with their configuration living in a file on the flash — config.json, calibration values, thresholds. The normal edit loop is miserable: change one number, rebuild, reflash the whole firmware, hope you didn’t typo. With ESPConnect you browse the file system, pull the file down, edit it, push it back — and the app stages edits locally, so you commit with Save to Flash only when you’re satisfied. Fixing a threshold on a shelf sensor stops being a compile job.

The OTA slot view deserves a mention too. If your devices update themselves, “did the update actually take?” is a question you’ll ask eventually, and the Apps tab answers it directly — which slot is live, what’s waiting in the other one — without breaking out a serial capture rig.

No backend is a feature — and a reason to self-host

Everything happens in the browser: no backend, no account, no telemetry, and your firmware images and backups stay on your machine unless you move them. For a tool that sees the entire contents of your flash, that’s the correct architecture.

Now sit with the flip side: you’re flashing firmware from a web page. That means trusting whatever is served at that URL, for eternity. The project is MIT-licensed and publishes two builds — a stable one cut from tagged releases, and a preview built from main — and the sane default is stable for anything that touches real devices. But if this becomes part of your maintenance routine, stop depending on someone else’s GitHub Pages hosting and run it yourself:

docker build -t espconnect .
docker run --rm -p 8080:80 espconnect

Now the toolbox lives on your LAN, next to the boards it manages. A hosting hiccup — or a lapsed domain — can’t quietly turn your flashing tool into someone else’s payload loader. It’s the same instinct as self-hosting anything a small business actually depends on: pin your tools where you can see them.

The honest limits

• Chromium only. Web Serial is the engine, so Firefox and Safari users are out. Fine for a bench machine you control; a limitation everywhere else.
• ESP8266 is a guest, not a citizen. It connects, but partition tables, file systems, and the advanced features are ESP32-only. Don’t retire your ESP8266 workflow for this.
• The NVS inspector is experimental. Reading namespaces, keys, and decoded values from the non-volatile storage partition is genuinely neat for debugging — but it’s read-only, partly reverse-engineered, and the project itself says not to treat its output as authoritative.
• Physics still applies. If your board lacks auto-reset wiring, you’ll still do the manual dance: hold BOOT, tap RESET, keep holding while you click Connect, release when the ESP-ROM banner appears.
• One port, one owner. Close the Arduino IDE or PlatformIO before connecting; only one application can hold the serial bridge.

And keep esptool installed anyway. If a board won’t handshake — drop to 115200 baud and replug the cable before you panic — the old-school command line is still the tool of last resort. A browser tab that works 95% of the time doesn’t replace the tool that works the other 5%.

Verdict

An ESP32 is the cheapest pair of remote hands a home lab can buy. ESPConnect is the maintenance hatch for those hands: the first time you image a working device in under two minutes before a risky flash, or fix a config file on a headless sensor without opening an IDE, it earns its bookmark. Use the stable build, self-host it once headless boards become infrastructure rather than toys — and let it build the backup habit you always meant to have. The tool makes the habit nearly free, which is exactly the point.

The problem with giving strangers your real address

Every vendor trial, every forum, every “enter your email to download the datasheet” form is a small gamble. Plus-addressing (gary+vendor@example.com) is the usual compromise, and it works — until the day one of those vendors strips the tag and sells the address anyway. Now your real domain is on a marketing list that outlives the vendor. The other option, a public temp-mail service, is worse: the inbox is shared with everyone else using it, the domains are on every blocklist in existence, and the mails sit in someone else’s logs until their retention policy says otherwise.

There’s a third option that homelab people keep sleeping on: run the disposable address service yourself, on a domain you control and don’t otherwise care about. OpenTrashmail caught my eye because it’s the rare mail-adjacent project that doesn’t demand a week of your life. It ships its own mail server — a Python SMTP daemon — plus a web UI, and it stores everything as flat files. No Postfix, no Dovecot, no database. That’s the right amount of mail server for a job that’s supposed to be disposable.

What it actually does

OpenTrashmail is a catch-all inbox for a domain you point at it. You set an MX record, expose port 25, and from that moment every address on the domain works — vendorx@burn.example.com, random-nouns@burn.example.com, anything. Nothing to pre-create. Mails land in a web UI with attachments, dark mode, per-address RSS, and delete buttons.

The parts that matter more than they first appear:

• JSON API and RSS for every address. You can script “give me the newest message at this address” — which turns throwaway email from a manual chore into plumbing.
• Webhooks, global or per-address, signed with HMAC-SHA256. A mail arrives, your automation hears about it.
• 100% file-based storage. The data directory is one bind mount. Backing up a burner-mail service is rsync, not database dumps.
• Retention is built in (DELETE_OLDER_THAN_DAYS), so the whole thing can be self-cleaning.

Why this beats the temp-mail sites

Public temp-mail domains get blocked because they’re public. Your domain gets blocklisted the same way only if you publish it — so don’t. Use it exclusively for your own sign-ups, never paste its addresses into forums, and pick a domain that isn’t your main one. The trade is: a little DNS discipline in exchange for addresses that (a) actually pass sign-up forms, (b) aren’t readable by every other temp-mail user, and (c) can be burned per-vendor because there’s an infinite supply.

The privacy argument is the one I care about most. A throwaway address that routes through someone else’s server isn’t throwaway — it’s theirs. Mine rides a mail daemon whose logs I own, on a box in my rack, and when I nuke the data directory nobody keeps a copy.

Setup: one record, one container

DNS first. Point an MX at a host that runs the container:

mail.burn.example.com.  IN A    203.0.113.10
burn.example.com.       IN MX 10 mail.burn.example.com.

Then the container. This is close to what I’d run in production — daemonised, persisted, domain-restricted, with cleanup:

docker run -d --restart=unless-stopped --name opentrashmail \
  -e DOMAINS="burn.example.com" \
  -e SMTP_HOSTNAME="mail.burn.example.com" \
  -e DISCARD_UNKNOWN=true \
  -e DELETE_OLDER_THAN_DAYS=90 \
  -e PASSWORD="something-long" \
  -p 80:80 -p 25:25 \
  -v /srv/opentrashmail/data:/var/www/opentrashmail/data \
  hascheksolutions/opentrashmail:1

If you want subdomain-tagged addresses per vendor family — shopping@retail.burn.example.com — a wildcard MX plus DOMAINS="*.burn.example.com" gets you there. Cute, optional.

The two settings that keep you off blocklists

Here’s where I’d slow down, because this is the part that separates “fun weekend service” from “career-limiting DNS incident”.

Set DISCARD_UNKNOWN=true. With it off, the server accepts mail for any domain, which to the outside world looks exactly like an open relay — the kind of thing that gets your IP onto blacklists your real mail will then suffer for. With it on, the server rejects foreign recipients during the SMTP dialog like a well-behaved MTA.

Host the web UI somewhere else. The project’s own advice is right: put the UI on a different domain than the one receiving mail, guard it with PASSWORD or ALLOWED_IPS (or hide it behind your reverse proxy with auth), and set SMTP_HOSTNAME to match your MX with a matching PTR record. Add STARTTLS with a Let’s Encrypt cert — a mail host that offers no TLS in 2026 looks sketchy to senders and spam filters alike. None of this is hard; it’s just ten minutes of care that most “quick SMTP in Docker” tutorials skip.

The trick that makes it more than a toy

The moment this stopped being a novelty for me was the JSON API. Disposable addresses plus a scriptable inbox equals automated email round-trips: sign up for a service from a script, poll /json/<address> for the confirmation link, done. The project docs even pitch it for capturing 2FA mail programmatically — I’d keep that inside the lab boundary only, because anything that auto-reads auth mail from a shared-ish surface deserves a long think first. But for test environments and CI that need to verify “the mail actually sent”, it’s excellent glue. Webhooks push the same idea further: a signed POST per message, straight into n8n, a Discord channel, or a small receiver script.

There’s also a quiet honeypot mode: set an ADMIN catch-all address and every message to every address is visible from one login. For a lab network where everything is yours anyway, that’s a feature; for anything multi-user, it’s a footgun. Know which one you’re running.

The small business angle

If you run IT for a small outfit, this pattern earns its keep without touching customer data: procurement portals, vendor trials, webinar registrations, “create an account to see the price” — all of it can go to per-vendor burner addresses on your domain. When the marketing spam starts, you know exactly who leaked, and you delete the address instead of unsubscribing from eleven lists. Combined with the retention setting, the data you’re keeping is close to none — and as I keep saying about breaches, mail you no longer have cannot be dumped.

Verdict

OpenTrashmail nails a narrow brief: disposable inbound mail with zero ceremony. It will not replace your mail server, and you shouldn’t ask it to. But as a purpose-built burner domain that you own end to end — scriptable, self-cleaning, one container — it’s earned a slot on my “runs forever, never think about it” list. Give it a spare domain, harden those two settings, and stop handing your real address to strangers.

The screen nobody fights over

Every home lab eventually has a drawer of shame: the $25 monitor that came free with something, the first-gen Pi you swapped out two upgrades ago, an HDMI cable of unknown provenance. The individual parts are worthless; the combination is the most-watched screen in the house — if you put them together as a family dashboard. A writer at XDA did exactly that this week, wiring a forgotten monitor and a Raspberry Pi 4 into a shared screen for chores, meals, calendars, and photos. It’s the right idea, and it deserves a harder look than the parts list — because the hardware is the easy 10% of the project.

Why family dashboards die

Not from hardware failure. From update friction. A dashboard is a promise that the screen will keep telling the truth — today’s calendar, this week’s chores, tonight’s dinner. The moment changing any of that requires SSH, the countdown starts. Within a month, the dashboard is a photo frame; within three, it’s a black rectangle the family has learned to ignore.

So my rule: if updating the screen needs a terminal, it’s already dead. Design for that from the first boot and the project survives. Ignore it and you’ve built a very expensive clock.

This is also why “just build it as a web page and open a tab” fails. A tab is not an appliance: it closes, it updates, it logs out. The dashboard has to be the only thing the machine knows how to do.

The build is two decisions, not twenty

• Screen: the worst HDMI monitor you own. Not-touch is fine. Big text fixes more UX problems than touch does, and the remote control is everyone’s phone anyway.
• Brain: whatever Pi is in the drawer. A Pi 4 with 1GB ran the XDA build at ~50% memory — no mini PC needed. A lightweight OS (DietPi is a good default; it idles under a few hundred MB) leaves the whole machine for one Chromium window.

Do not buy a touchscreen for version one. Buy it for version three, after the family has told you what they actually reach for. My experience with kiosk builds is that the features you’re sure they’ll want get ignored and the boring ones — the clock, the calendar, tonight’s meal — carry the whole device.

Kiosk mode, and the Wayland trap

The dashboard tool I’d point at here is Home Screens: custom pages, a proper web portal for layout, and — crucially — a separate portal just for content edits. But the software is only half the kiosk. The other half is making the OS boot into a fullscreen browser and nothing else.

On a Pi, that means an autostart entry or a small systemd service that launches Chromium fullscreen, incognito, pointing at the dashboard URL. Something like:

[Unit]
Description=Dashboard kiosk
After=network-online.target

[Service]
User=kiosk
Environment=DISPLAY=:0 WAYLAND_DISPLAY=wayland-0
ExecStart=/usr/bin/chromium-browser --kiosk --incognito \
  --noerrdialogs --disable-infobars \
  http://localhost:3000
Restart=always
RestartSec=5

[Install]
WantedBy=graphical.target

Two lessons that will save you an evening. First, the XDA author’s build crashed on boot — UI up for two seconds, dead, restart, repeat — because the kiosk was launched into a session layer (Wayland) it wasn’t configured for. If you see a crash loop, suspect the session before the app: launch the browser the way the project’s own installer does, into the session the project documents. Second, Restart=always with a short backoff is not optional. A kiosk that shows a black screen after a browser crash until someone reboots it has failed the appliance test.

Two doors into the dashboard

Home Screens’ smartest design decision is that it has two doors. The builder portal (port 3000) is for the person who makes pages. The content portal (the same URL plus /remote) is for everyone else: chores, meal plans, users, photos, screen brightness, sleep and wake — all editable from a phone, none of it able to break the layout.

That separation of powers is what keeps the screen alive. The family gets a door with no sharp edges; you keep the dangerous one. It also gives you the feature nobody knows they need until it works: alerts on the big screen. A persistent or timed message when someone forgets a chore is nag-as-a-service — off your back, onto the furniture.

Feed it things that update themselves

A dashboard’s content pipeline splits into two kinds, and they age very differently:

• Self-updating: calendar (iCal links), weather, photo carousel via an API. These never rot.
• Hand-fed: chores, meals, lists. These rot in days unless the editing door is genuinely easy.

Maximise the first, make the second a one-tap phone job, and skip anything in between. A card that needs a weekly manual export will be the first thing the family notices is wrong.

Run it like a service, because it is one

This machine has the most public SLO in your house. Everyone can see when it’s down. So give it the boring production treatment:

• Auto-restart everything — the browser session at minimum, and a read-only-ish SD card setup so a power cut at 6am can’t corrupt it.
• Boot to dashboard after power loss — no login, no desktop, straight to the kiosk.
• Sleep on a schedule — dim or blank overnight via the content portal or DPMS; a 24/7 bright panel in a hallway is how projects get unplugged.
• One-line health check — if you already monitor services (and if you’re reading this blog, you do), curl -f http://pi:3000 from your uptime monitor tells you the dashboard is serving, which is 90% of “the screen is fine.”

The small-business version is the same build

Swap the family content for ops content and this is a reception screen or a warehouse status board: today’s schedule, a Grafana or Glance page, the on-call rotation, the shipment board. The rules carry over unchanged — worst screen you have, kiosk boots to one URL, auto-restart, and a content door a non-technical person can use without calling you. Every client site has a wall; most of them are showing a screensaver because nobody treated the wall screen as a service.

The best screen is the one already paid for

The economics of a junk-drawer dashboard are unbeatable: zero dollars, one evening, and the family’s shared context stops living in four different apps. The XDA piece is a good build log — read it for the DietPi and kiosk details. But the parts list isn’t the lesson. The lesson is that the screen survives on maintenance design: two doors, self-updating feeds, restart-on-failure, and a phone-sized path from “tonight’s dinner changed” to the wall. Build those in, and the cheapest screen in the house becomes the one nobody can live without.

Agent skills — the markdown instruction files that teach a coding agent how you want things done — have quietly become real infrastructure. Claude Code keeps them in ~/.claude/skills/, Cursor in ~/.cursor/skills/, Codex in ~/.codex/skills/, Amp in ~/.config/amp/skills/, and there’s now a cross-tool convention forming around ~/.agents/skills/. Use more than one agent, as most of us now do, and your hard-won procedures are smeared across five hidden directories in two different file formats, with no way to find the one you wrote last March.

Chops is a free, open-source macOS app by Shpigford that treats this as what it actually is: a dotfile management problem. One window, every tool’s skills and agents, and an editor. It’s a small app doing an unglamorous job, which is exactly why it works.

What it does

• Discovery across tools — scans the skills and agents directories for Claude Code, Cursor, Codex, Windsurf, Copilot, Aider, and Amp, plus any custom paths you point it at.
• A real editor — monospaced, Cmd+S to save, frontmatter parsed and displayed, so you’re editing the file where it lives instead of round-tripping through a terminal.
• Full-text search — across names, descriptions, and body content. Six months in, this is the feature you’ll open the app for.
• Collections — group skills into logical sets without moving or rewriting the source files. Non-destructive by design.
• Per-tool boilerplate — creating a new skill generates the correct skeleton for whichever agent it targets, frontmatter included.
• File watching — FSEvents-based, so edits made outside the app show up instantly.
• Registries and remotes — browse and install from the skills.sh registry, and connect to remote servers running OpenClaw or Hermes to discover and install skills living on other machines.

The feature that matters most is the symlink

Buried in the README is the detail that makes Chops more than a file browser: skills are identified by their resolved symlink path. Symlink the same file into multiple tools’ directories and Chops shows it once, badged for each tool it serves. That’s not a dedup gimmick — it’s the correct architecture for this problem, and it’s the part you should steal even if you never install the app:

git clone git@github.com:you/agent-skills.git ~/agent-skills
for tool in claude codex cursor; do
  mkdir -p ~/.${tool}/skills
  ln -s ~/agent-skills/release-checklist ~/.${tool}/skills/release-checklist
done

One canonical copy in a git repository, one symlink per tool. Edit the skill once, every agent sees the update, and your procedures get a changelog for free. The honest caveat: agents don’t all accept identical skill formats — Cursor uses .mdc files, others use markdown with frontmatter — so some skills will need thin per-tool wrappers. That’s still vastly better than five divergent copies edited by hand.

An ops-flavoured review

What I like: it reads files where they are instead of importing them into its own database-shaped world, the collections never touch source, and the search is fast. What you should know before granting it access: Chops deliberately ships with the macOS sandbox disabled, because reading dotfiles across your home directory is the entire job. Defensible, but understand you’re handing an app unsandboxed filesystem access — fetch it from the GitHub releases page, not from a mirror. And it’s a young project with no automated test suite; validate what you care about manually, the way the README says the author does.

If you’re on Linux, there’s no app for you here. But the durable lesson isn’t the app, it’s the map: skills are plain files in known directories, they dedupe cleanly through symlinks, and they belong in git. A ten-line shell script gets you the same architecture Chops renders in SwiftUI.

Version your procedures like code

A skill is an instruction sheet an agent will follow with real tools on real systems. You wouldn’t ship an unreviewed deploy script to production, so don’t ship an unreviewed skill to the agent that can run your deploy script. Put them in a repo, review them in pull requests, and let Chops — or your symlinks — handle distribution across whichever agents you’re running this month.

The people getting real leverage from agents aren’t the ones with the best prompts. They’re the ones whose accumulated procedures survive every tool switch. Skills on disk, in git, deduplicated: that’s how that happens.

Obsidian vaults accumulate plugins the way home labs accumulate Raspberry Pis. One comes from a Reddit thread, another from a YouTube tutorial, and eighteen months later you have a dozen community plugins installed and no idea which of them still have maintainers — or what any of them can actually reach inside your vault.

Since May, Obsidian has been quietly fixing the information half of that problem. Every plugin version that lands in the community directory now gets an automated scan, and the results are published as a safety scorecard on the Obsidian Community site — the same catalog as the in-app browser, but with the receipts attached. A piece over on XDA, “Obsidian launched safety scorecards for every plugin, and checking mine changed what I keep installed”, is what finally pushed me to run the audit on my own vaults. Here’s the short version of what the scorecards say, and how to act on them without losing an evening to tab-hopping.

What the scorecard actually measures

Each plugin page on the Community site has a Scorecard tab, and the sidebar boils it down to two bars:

• Health — is anyone still looking after this? It pulls recent commit activity and install counts. A plugin with a commit five days ago and 97,000 installs is alive; a plugin whose last release predates your current laptop is a maintenance risk regardless of how well it scans.
• Review — does the code scan clean? Dependency vulnerabilities, suspicious patterns like base64 blobs, and — the part I care about most — whether the published build can be reproduced byte-for-byte from the public source repository.

Below the bars sit Disclosures: what the plugin can reach. This is where you learn that your drawing plugin reads the system clipboard and can see every file path in the vault. Usually that’s not malice — some feature needs it — but it’s a fair bet nobody ever asked you about it. Every scorecard also carries a work-in-progress banner, which is honest: treat the whole thing as evidence, not a verdict.

Read it like a pipeline, not a rating

If you run CI for a living, none of this is conceptually new. Health is your bus-factor signal. Review is dependency scanning plus build provenance — the same “can I rebuild what I shipped?” question that SLSA-style attestations ask. Disclosures are permissions, the blast radius. Read a plugin page the way you’d read a green check on a pull request: it means the checks ran, not that the code loves you.

Two specifics worth internalizing before you panic:

• “Malware scan not available” is not a red flag. It shows up on big, boring plugins like Dataview and Templater too. It means there is no result to display — absence of evidence, not evidence of absence.
• A reproducible build is the strongest signal on the page. If Obsidian could rebuild the plugin from source and get a file identical to the one you installed, then what’s sitting in your vault is code anyone can read. That beats every heuristic.

The audit, in twenty minutes

1. Open Settings → Community plugins and write down everything installed — including the disabled ones. The disabled ones are where the deletions come from.
2. Look each plugin up on the Community site and check three things: the Review bar, the Disclosures, and the last commit date.
3. Apply three rules:
   • Reproducible build plus live maintenance → keep, carry on.
   • Health and Review disagree → investigate or drop. A healthy-looking plugin that fails review, or whose description still references a model from three years ago, is a fossil with good PR.
   • Disabled for more than a few months → uninstall. Reinstalling takes thirty seconds. This boring rule improves your vault’s security more than any scanner ever will.

The October 30 cutoff the app never mentions

There’s a deadline attached to all this that Obsidian doesn’t surface in the app at all: scorecard results on existing plugins are informational-only until October 30, 2026. After that, a plugin whose latest release fails review — actual errors, not a mere “caution” rating — gets pulled from the directory and can no longer be installed from the app.

If one of your workhorses is on the wrong side of that line, you have three moves, in order of preference: check the plugin’s repository, since most failures will be build issues a maintainer is already patching; back up the plugin folder from .obsidian/plugins/ so a reinstall stays possible even if it’s delisted; or go find the replacement now, on your own schedule, rather than mid-project.

Why this matters more for work vaults

A personal vault leaking clipboard contents is annoying. A small-business vault holding client notes, meeting records, and the odd pasted credential is a different asset class entirely. Plugins are third-party code with filesystem access to all of it, and “it was fine when I installed it in 2023” is not a control — that’s a hope with a version number. Moving from one-time hand review of the first submission to automated scans of every version is the biggest security improvement the Obsidian ecosystem has made. But scorecards only work if somebody reads them.

Twenty minutes, once a quarter, with a delete-first bias. That’s the entire practice.

The build stops at the bare MDF

Every DIY arcade cabinet follows the same arc. Week one you’re flashing a RetroPie image, arguing with controller mappings, and feeling like a genius. Week three the controls work, the emulator frontend is configured, and the cabinet sits in the corner as a sheet of bare MDF with a screen bolted into it. Six months later it’s still sitting there, because the remaining work — the finish — is a completely different skill from everything you’ve done so far.

I’ve watched this pattern repeat across homelab projects of every flavour: the functional 90% ships in a weekend, and the cosmetic 10% dies in committee. With arcade cabinets the gap is worse, because a half-finished cab doesn’t just look unfinished — it looks like furniture that’s been in an accident. The wrap kit that kicked off this thinking is Arcade Revival’s full cabinet wrap, and it’s a good excuse to talk about the finishing decision every cabinet builder eventually faces.

Why paint is where arcade builds go to die

Painting an arcade cabinet properly is real work. MDF drinks paint, so you need to seal the edges, sand, prime, sand again, and only then think about colour. That’s before the dust control, the cure time between coats, and the near-certainty that the first side you do teaches you everything you’ll wish you’d known for the second side. A gloss black arcade side panel is one of the least forgiving surfaces in hobby woodworking — every sanding scratch and dust fleck reads like a headline.

None of this is hard in the way that debugging a kernel panic is hard. It’s just slow, physical, and unforgiving of impatience, which is exactly the combination that people who are good at software tend to underestimate.

The three realistic finishes

For a home-built upright, your actual options narrow to three:

• Paint. Cheapest per litre, most expensive in evenings. Fine if you enjoy finishing work; miserable if you don’t. Custom colour, but any artwork means stencils, decals, or artistic talent you may not have budgeted for.
• Printed side art. The classic route — big printed panels applied over a painted base. You still paint, but the art carries the visual load. Works well, but it’s two projects stitched together.
• A full wrap. Pre-cut adhesive vinyl covering every exterior panel, printed with the complete artwork. You skip the paint entirely and the artwork arrives as geometry rather than as a separate problem.

The interesting shift is that wraps have quietly become a DIY product rather than a signwriter’s trade. That’s down to the vinyl itself.

Air-release vinyl changes the maths

The old objection to wrapping anything yourself was bubbles. Traditional sign vinyl grabs immediately, and one trapped pocket of air means lifting the panel, stretching the film, and starting over with a heat gun and a vocabulary you didn’t plan on using. Modern cast vinyls with air-release adhesive channels — 3M’s 40C series is what Arcade Revival prints on — are a different material. The adhesive face is micro-channelled, so air migrates out along the channels as you squeegee the film down, and the initial grab is mild enough that you can peel a panel back up and reseat it when your alignment drifts.

For a cabinet, that repositionability matters more than the bubble resistance. Aligning a full-height side panel to a cabinet you built in your garage — with the tolerances of a cabinet you built in your garage — is the part that would scare me off, and forgiving adhesive is what makes it survivable.

The practical kit is refreshingly short:

• a fresh blade in a utility knife (dull blades drag and stretch the film — replace them mid-job if needed)
• the squeegee that ships in the box
• a clean cloth and some isopropyl for degreasing the panels first

No heat gun, no solvents, no spray equipment. If you’ve ever applied a phone screen protector badly and sworn off the entire category, the difference here is scale and time: a cabinet panel goes down over minutes, with room to correct, not seconds.

The panels that actually make it look real

A full wrap kit covers the sides, the front kick panel, the control panel strip, the control panel overlay, the screen bezel, and a translucent marquee. In my view the two that matter are the control panel overlay and the marquee, and they matter for different reasons.

The control panel overlay is the surface players actually touch. Bare MDF there announces “prototype” the instant someone rests their wrists on it, and it will slowly dissolve into grease. An overlay turns the most-abused surface into the most durable one.

The marquee is the soul of the machine. A translucent marquee print, backlit, is the moment a box of MDF becomes an arcade cabinet — it’s the light you see across the room. If you’re triaging a budget, those two panels are where I’d spend first, and a wrap kit that includes both plus the sides is effectively the whole decision made for you.

Two honest catches

Fit is cabinet-specific. These kits are printed for a specific cabinet profile — in this case Arcade Revival’s own uprights, with panels following the machine’s lines. If you’re building your own cab from plans, check the panel dimensions against yours before ordering, or accept that you’ll be trimming. Trimming vinyl is fine; discovering a four-centimetre shortfall on a side panel is not.

Fan art is fan art. The kit’s own disclaimer is worth reading: it’s an unofficial, unlicensed design inspired by classic games, not an endorsed product. That’s the honest way to sell this stuff, and it’s the same position most of the retro-cabinet artwork ecosystem operates in. Just go in knowing it’s a themed tribute, not licensed merchandise.

One more from the pragmatic column: kits like this generally don’t replace panels you wreck during installation. Dry-fit every panel before you commit. The repositionable adhesive makes alignment forgiving, but “forgiving” and “unlimited” are different words.

Build the guts, buy the skin

The broader lesson applies well past arcade cabinets. Every big project contains a subsystem that is someone else’s core competency, and finishing is almost always it for those of us who live in terminals. You wouldn’t mill your own screws. The version of you that’s good at firmware, emulation configuration, and wiring a control panel should not also be the version of you learning to spray a flawless gloss finish on a two-metre sheet of MDF.

Spend your evenings on the parts only you care about — the input lag tuning, the frontend theme, the coin-door wiring that makes guests smile — and buy the finish from people who print it for a living on a machine the size of your car. The cabinet gets finished, the room gets a centrepiece, and you get your weekends back. That’s a trade I’d take every time.