Rudy Faile

Author: Rudy

  • DEF CON 34

    DEF CON 34

    I just got back from my first DEF CON which was four days at the Las Vegas Convention Center August 6th-9th 2026, with a few folks from Automattic. This year’s theme was Agency, and no, not the AI kind everybody is obsessed with right now. Agency as in owning your data, controlling your digital life, and choosing tech that works for you instead of against you. That’s something I have been preaching for the last 11 years, so the whole con felt like walking into a room full of my people.

    Here is how it went, plus some context on the talks that stuck with me.

    Getting there

    I flew in Thursday, August 6th, wheels down around 8am, at the hotel by 8:30. I stayed at the Horseshoe (used to be Bally’s) because it was the cheapest room I could find, and the Las Vegas Monorail runs from there to the convention center. I grabbed a $40 four-day monorail pass, dropped my bags, and headed over. It is three stops down to the con, about 15 to 20 minutes, and best of all you skip Strip traffic completely.

    The monorail drops you on the far side of the convention center from the West Hall. So you get off the train and then walk all the way around the building to get in… and the place is enormous. The full LVCC campus is something like 4.6 million square feet, and while DEF CON only uses the West Hall, that slice alone is massive. It’s easily one of the largest structures I’ve ever been inside. If you go, wear real shoes.

    This isn’t even where the conference is. You walk all the way through and around this thing to the left side, over the freeway, then all the way down to the other end of the west hall.

    Thursday itself is quiet. No talks. You pick up your badge, get your bearings, and figure out where everything is. The best part was catching up with Automattic people and meeting coworkers in person for the first time: Thyago, Kolja, and Fio. It’s always nice to meet the faces to go with the Slack handles in distributed work. I will say though from a perspective of time to value it is probably a skippable day.

    Friday

    Day two is when it picks up. My colleagues got into the Social Engineering Village by showing up about an hour and a half before 8am. I showed up at 8 so I wasn’t even close to getting in. I was overwhelmed about what to attend at that point, thousands of people were moving in every direction, and I didn’t want to miss the first block so I headed into the nearest room which was a malware development via process injection workshop.

    Not my usual lane, but interesting to watch. It was run by Yoann “OtterHacker” Dequeker, a red team lead at Wavestone who has been running this workshop at DEF CON for years. The idea is to start with basic process injection and then layer on techniques (module stomping, DLL injection, threadless injection) that make the malware harder for an EDR to catch. The part I liked was getting the loader to lean on DLLs a process would legitimately load anyway, so the behavior looks normal to an EDR and thus undetected. None of this is new, but spins on tried and true vulnerabilities is always worth knowing.

    At 10 I caught Click Me: Turning URI Links into Bug Bounty RCEs by Tobias Diehl. This one was great. Bug hunters usually see an unprotected URL input and write it off as a low-severity web finding. He showed real Microsoft enterprise cases where a bug in a custom URI handler which is low sev on web allowed for much more access expansion on the same app on desktop, and from there escalate all the way to remote code execution. Same boring URL, completely different impact once a desktop app is in the picture. Cool.

    Then I stayed in my seat for Hacking IDE Extensions, a VS Code workshop by Nick Copi. IDE extensions are an underrated bug bounty target: they run with real privileges, they parse whatever files are sitting in your workspace, and more and more of them ship LLM-backed agentic features that will happily execute commands. You install a deliberately vulnerable mock AI assistant called “Nopilot” and chain it from “user opened a folder” all the way to code execution, bypassing workspace trust entirely. It comes out of yet another six figure IDE bounty practice, which tells you the target is real money. Nick is a full-time bug bounty hunter, and it is amazing how many people at this conference make a legitimate living doing this.

    Next I headed over to the Mobile Hacking Community to hear Ken Gannon, a multi-year Pwn2Own winner who popped the Samsung S24 and S25. For years he made a living writing Android exploits by hand. This year he says he has not written a single one. His AI tool, Djini, does the whole chain now: recon, exploitation, and even the bug bounty report. He was supposed to demo its new “Deep Scan” feature finding Pwn2Own-level bugs on its own but unfortunately the con had some wifi issues (🙂). Smart guy, and one of the better talks I saw.

    Expect technology disruptions

    Then back to the bounty side for “Hackbots” by Jason Haddix and Ryan Bonner. Same core idea as Djini, but from a web perspective. They walked through the architecture of AI pentest bots (single-purpose versus multi-stage, context engineering, tool integration) and then live-built one, showing where AI genuinely speeds up recon and where it falls flat if you are not careful.

    The talk that stuck with me most was Meet the HTTP Terminator by James “albinowax” Kettle on the main stage. Kettle is the Director of Research at PortSwigger aka the Burp Suite people, and he has dropped novel HTTP research at Black Hat ten years running. On paper the talk was about HTTP desync attacks, and yes, he did unveil a new class of vulnerability. But the part that was interesting to me was the methodology. He built an autonomous system that invents new attack techniques and hacks live targets at scale.

    Somewhere in there I bought some merch for the family and grabbed food before the 2pm block. Which brings me to the real final boss of DEF CON: the schedule. It is a minmax nightmare and virtually impossible to optimize. There are easily something like fifty talks, workshops, and village sessions running at the same time, and the venue is so big that even if you line up a 4pm and a 5pm perfectly, you can’t account for the 20 minute walk between them until you are already doing it and weaving through foot traffic the whole way. At some point you stop trying to optimize and just point and shoot – or at least that’s what I did.

    Saturday

    Day three I mostly camped in the Bug Bounty Village. Since I have taken over security operations at Automattic, I now own our HackerOne programs, so these are exactly the people I wanted to be around: the hackers collecting bounties and the folks who run the programs they collect from.

    The highlight was a panel, Bots, Bounties, and Bullshit: An Honest Panel on AI in Hacking, moderated by Ben Sadeghipour with a lineup that included Johann Rehberger and Ads Dawson. One of the guys couldn’t make it, and was replaced last minute by another guy, but I didn’t catch who switched – if someone reads this that knows, please let me know so I can fix. Good discussion overall about hackers and LLM-security researchers cutting through the AI hype to get specific about what actually helps with recon/review/reporting and what is just noise.

    Honestly, the whole thing felt like an Automattic grand meetup. These are my people. Walk up to a group mid-conversation and they open the circle to pull you in. Ask someone about their tech and they light up. People are genuinely excited to be here and learn and share.

    One thing the conference nailed: on the main floors there might be a dozen talks happening at once, so instead of drowning everyone in ambient noise, they handed out headphones with clean, per-talk audio. You could actually tune into a speaker without the roar of the hall behind them. It also doesn’t matter how far from the stage you are. Huge difference – would recommend all bigger cons do this.

    Sunday

    Sunday is where the agency theme really landed for me.

    I started in Track 1 for a talk on surveillance, then went to a hardware hacking session that was also about surveillance. There was a ton of it this year, and just as much energy going the other way, into tools built for counter-surveillance. Hackers hate surveillance. This is a community that looks at surveillance capitalism, dark patterns, and mass data collection and says: fk you.

    From there I caught Matteo Giordano’s Beyond the Ceremony: The 2026 Passkey Attack Surface. Passkeys get sold as basically unphishable, and for the core login ceremony that is mostly true. But “mostly” is where the interesting stuff lives, and the talk dug into the parts of the passkey story that are still very much attackable.

    Then I made it to the Packet Hacking Village where the vibes were… immaculate. Dark room, a DJ, terminal screens glowing everywhere. This is my kind of place.

    On top of the classic Wall of Sheep, they added a “Field of Sheep”. They LIDAR scanned the room and then used WiFi triangulation to plot everyone broadcasting a WiFi signal, laid out in space. It is a cool hacker art piece and a privacy wake-up call at the same time. If you think your phone is being quiet in your pocket, it is not. Very on-theme for a con about agency. Also a reminder – do not show up with non-burner devices broadcasting signals.

    I spent the rest of the day down in Hall 2. I wandered through the Quantum Computing Village, hit the Red Team Village, and then ended up in the Maritime Hacking Village helping a guy try to hack a diesel truck, which is exactly the kind of sentence that only makes sense at DEF CON. From there I went straight to the airport.

    Coming home

    I’ve been wanting to go to DEF CON for years, and I’m glad I finally had the opportunity, the con delivers. If I had one piece of criticism it would be that the con is just… too big. Something like 1/5th of the scale would be a lot more manageable. It’s hard not to feel like you’re missing everything no matter where you are and it’s impossible to optimize your time.

    The talks were great, the villages were cool, but the thing I keep coming back to is the theme. “Agency” is not marketing fluff. It is the belief that you should own your data and get to decide what happens to it, and that when the defaults or the meta or the man are all stacked against you, you build something better. It was really nice to spend four days surrounded by thousands of people who have made that their creed. Hack the planet.

  • The Machine Was Never the Future

    The Machine Was Never the Future

    In movies and popular culture, every vision of the future looks like I, Robot.

    1x’s Neo Gamma

    Robots walking around doing our chores. Giant mechanical suits that make humans stronger. Autonomous vehicles, machines building other machines, enormous steel contraptions terraforming planets. Everything has motors, hydraulics, processors, wires and some gigantic battery that will inevitably be dead when you need it.

    It looks futuristic, but I think it might actually be primitive.

    I was listening to Dr. Zach Bush on The Joe Rogan Experience recently, and he started talking about biology and electrical signals in living things. I have no idea if Zach Bush is an authority on this subject, and this post is not based on his work. The conversation just reminded me of something I have been thinking about for years.

    Humanity is spending an unbelievable amount of effort trying to make machines behave like living things when living things are already better at most of the difficult parts.

    We are trying to build robots but we should be trying to program life.

    The Spider Is Better Technology

    Consider the spider.

    A spider is born and, without anybody teaching it anything, it knows how to build a web, capture prey, eat, survive and reproduce.

    Obviously, a spider does more than one thing. It is not literally a tiny robot executing three lines of code. It senses its environment, chooses where to build, avoids predators, competes with other spiders and changes its behavior based on what is happening around it… but that actually makes it more impressive.

    A spider constructs its own body from locally available materials. It powers itself by eating. It manufactures silk inside its body. It builds structures. It repairs some damage. Then it creates more spiders without a factory, an assembly line or a global supply chain.

    Now imagine we wanted to build a robot that did the same job.

    We would need to mine and refine metals. Manufacture processors, cameras, motors, gears and batteries. Write the software. Assemble every unit in a factory. Ship them wherever they are needed. Charge them. Repair them. Replace broken parts. Install updates. Then eventually throw the whole thing away and manufacture another one…… quadrillions of times.

    Natures spider just makes more spiders. It will never stop doing this. Spiders hatch, they build webs, hunt insects, mate, and the cycle repeats: for the last 300 million years, until the end of time, this will happen.

    A robot is a product made by a manufacturing system.

    A living organism is the product, the manufacturing system, the repair system and the power-management system combined.

    That seems like a much more advanced form of technology.

    Biology Does Not Need a Factory

    To be clear, biology is not free.

    A spider still needs energy. It needs water, oxygen, food and an environment it can survive in. It can get sick. It can be eaten. It can freeze to death. A spider does have a battery, in a sense – the battery is the insect it ate.

    The difference is that the spider can and knows to find that energy in its environment, process it, use it to maintain itself and turn some of it into another spider. It doesn’t have to think about this, it will do this instinctively.

    Mechanical technology pushes all of that complexity outside the machine.

    The robot needs a power plant somewhere. It needs a battery factory somewhere. It needs replacement parts sitting in a warehouse somewhere. It needs a truck, boat or airplane to move those parts. It needs people and other machines maintaining the entire chain.

    Biology brings an enormous amount of that machinery inside the organism.

    The maintenance did not disappear. The organism internalized it.

    Nature Has Already Solved the Hard Part

    Nature did not sit down and intentionally design spiders to control the insect population. Evolution does not work like an engineer receiving a Jira ticket.

    But evolution still produced a self-building, self-maintaining and self-replicating system that performs useful work inside a larger ecosystem.

    That is the part worth studying.

    The spider itself is not necessarily the answer. The answer is whatever underlying process allows a tiny egg to become a functioning spider in the first place.

    Somewhere inside that system is a set of biological instructions and interactions that tells cells what to become, where to go, when to stop growing and how to work together.

    We usually reduce this idea to DNA, but DNA is not a simple architectural blueprint.

    A skin cell and a neuron generally contain the same genome, yet they look completely different and perform completely different jobs. Cells are responding to gene regulation, chemicals, mechanical forces, neighboring cells and electrical conditions across their membranes.

    The genome matters, obviously, but it is only part of the system.

    A living organism is less like a computer reading a static program and more like a distributed system in which every machine is communicating, changing roles and rebuilding the network while it is running, which is completely insane when you think about what this looks like in the context of how the internet works versus how tiny a spider is.

    This Is Not Entirely Science Fiction

    I am not a biologist, and I am definitely not claiming I discovered synthetic biology by staring at spiders in my backyard. There are entire fields working on different pieces of this problem already.

    In 2018, researchers published a paper in Science showing that they could engineer communication between cells and cause those cells to ⁠organize themselves into multicellular structures.

    That is important because the researchers did not individually grab every cell and place it in the correct position, rather, they changed the rules the cells used to communicate.

    The larger structure emerged from those local interactions and that is much closer to how biology builds something versus how a normal human factory builds something.

    Researchers have also created small biological constructs commonly called xenobots. They took cells from frog embryos, arranged them into new forms and produced living structures capable of movement and other basic behaviors. The initial work described a ⁠pipeline for creating reconfigurable living organisms.

    Later experiments demonstrated something even stranger. Some of these constructs could move around a dish, collect loose cells into piles and create new clusters that developed into additional moving constructs. The researchers described this as ⁠kinematic self-replication.

    These are not tiny intelligent animals. They are not crawling out of the lab and building cities. They are small, short-lived biological systems operating under extremely controlled conditions… but the basic result is still incredible: cells taken from an existing animal can be rearranged into a living system that does something those cells never normally do inside that animal.

    We seem to be barely touching the controls, but apparently there are controls.

    We Barely Understand the Smallest Systems

    The other side of this is that biology is unbelievably complicated.

    Researchers created a nearly minimal synthetic cell called JCVI-syn3A to study how few genes a cell needs to live and divide somewhat normally.

    Even that stripped-down cell has hundreds of genes. Researchers studying it still had to work backward to determine why some of those genes were necessary for the cell to divide correctly. Their results were published in Cell in a paper on the ⁠genetic requirements for division in a genomically minimal cell.

    So we can remove huge pieces of a genome, transplant synthetic genomes and edit individual genes, but even one of the simplest cells we can produce is still complicated enough to surprise us.

    That is a pretty big gap between where we are and where I am talking about going. Right now, we mostly modify living systems that already exist and see what happens. We are not sitting down with a blank screen and writing a spider, but I think we should be focusing on getting to that place.

    Living Materials Are Already Here

    One of the most interesting areas of this research is engineered living materials.

    Instead of manufacturing a material and accepting that it will immediately begin deteriorating, researchers are experimenting with materials that contain living cells or are produced by them.

    Researchers have used bacteria that produce cellulose to grow materials into different shapes, detect chemical signals and help ⁠regenerate damaged sections of the material.

    Another group engineered Bacillus subtilis into a living component of a silica material. The resulting material could be ⁠regenerated from a piece of the original material, and new functions could be added through additional engineered bacterial strains.

    That sounds a lot more like the future to me than another robot arm. A normal material is manufactured, used and eventually discarded, you know: “wear and tear”, a living material might be grown, repaired and regrown.

    We are obviously nowhere close to growing a skyscraper from a seed. These materials currently have enormous limitations involving strength, stability, environmental requirements and control, but the underlying idea is there: the material does not merely sit there, it participates in its own construction.

    Electrical Signals Might Be Part of the Programming

    The electrical part is also real, although it is easy to wander into nonsense when talking about “energy” and biology (one of my skepticisms of the Zac Bush episode on JRE) – it is not magic electricity or vibrations from the universe… though I will say we seem to have have a very primitive understanding of it today.

    Cells maintain electrical differences across their membranes by controlling charged ions. Those electrical conditions can influence how cells move, communicate, develop and organize.

    In 2025, researchers reported direct evidence that naturally occurring electric fields helped guide the collective movement of embryonic cells in a living animal. The work showed that ⁠endogenous electric fields can direct cell migration during development.

    Other researchers have used electrical stimulation to influence the shape and size of organ-like tissues grown in laboratories.

    DNA is therefore probably not the only lever we would need to control to truly program living form.

    We may need to understand the combination of genetics, chemicals, electrical signals, physical forces and communication between cells. That is a much harder problem than editing one gene. It is also potentially much more powerful.

    Give It a Job and Let It Reproduce

    The version of this idea I keep coming back to is an organism designed around a function:

    Not a humanoid robot. Not a conscious creature. Not something that needs to understand what it is doing. Give it one useful job and the ability to reproduce the system that performs that job.

    A spider doesn’t “think” about finding food, building a web, catching insects, eating them, and mating. It is programmed to do this. It will never do anything different. All the spiders it breeds will do this.

    Imagine something that detects a specific pollutant, consumes it and produces a harmless material in its place or a living material that grows into cracks in concrete and reinforces the structure or an organism that can survive in a hostile environment and slowly change that environment into something more useful… imagine deploying a small starter population instead of manufacturing and shipping ten million individual machines.

    The individual organism might be less capable than a robot… but the system could be vastly more capable because, once deployed, it grows autonomously and is hands off.

    Why in science fiction does terraforming have to involve enormous steel machines?

    Why does useful technology have to be assembled instead of grown?

    I am not saying every machine should become an animal. A living table saw sounds like terrible idea 😆.

    Mechanical systems are better when we need exact behavior, high strength, extreme temperatures, sterility or an immediate off switch.

    I am saying that machines are one category of technology, but we keep treating them like they are the final category.

    The Problem Is the Off Switch

    Of course, there are some enormous problems with all of this…..

    A broken robot stops.

    A broken biological system might mutate and reproduce.

    The same feature that makes living technology so powerful makes it dangerous. A machine must be deliberately copied. An organism is under constant pressure to survive, adapt and create more of itself.

    Researchers working on engineered microbes are already dealing with this problem. They have developed biological “kill switches” intended to destroy engineered organisms under certain conditions.

    A 2022 Nature Communications paper described ⁠CRISPR-based kill switches for engineered microbes, but the paper also explains the fundamental difficulty: a kill switch creates evolutionary pressure favoring any mutant that escapes it.

    That is the terrifying part.

    Machines are hard to reproduce but relatively easy to recall.

    Living systems may become easy to reproduce and impossible to recall.

    You could give an organism a synthetic dependency so it cannot survive without a nutrient humans provide. You could limit the number of times it can reproduce. You could add redundant self-destruction systems.

    But once something is alive and reproducing, evolution gets a vote. Obviously as someone born in the 80s, you know what the obvious callback here is right?

    A robot is a product. A reproducing organism is life. Life, uh, finds a way.

    The Future Might Not Look Futuristic

    I have no idea whether humanity will ever gain enough control over biology to build the kinds of systems I am describing. We may discover that biological systems are too complex, unpredictable and dangerous to engineer this way outside narrow, controlled applications.

    We may get living construction materials and pollutant-eating bacteria but never get anywhere close to custom-designed complex organisms. Maybe I am just looking at a spider from an engineering perspective and overthinking it, butI do think the basic idea is right.

    The machines in I, Robot look futuristic because they move like people and talk like people. Underneath, they are still manufactured objects filled with parts that wear down and batteries that die.

    A spider is grown from a microscopic package of biological information. It assembles itself, fuels itself, produces its own building material and creates more spiders.

    One of those technologies seems considerably more advanced than the other.

    Humanity transformed the world when we learned how to shape dead matter into tools.

    The next transformation may happen when we learn how to give living matter a purpose of our own choosing.

    The future may not be a machine that successfully imitates life.

    The future may be life itself, rewritten.

  • DIY Sauna Plans

    DIY Sauna Plans

    A lot of people that watched my DIY Backyard Sauna Sauna Series on YouTube asked me if they could purchase the plans. So I put two sets together that cover everything you need to make the exact same Sauna. Here they are:

    6′×8′ Outdoor Sauna — Framing Plans

    These are the plans I drew from building a 6′×8′ cedar sauna on my back deck. Every dimension, every cut, pulled from the as-built measurements, not generic templates.

    CLICK HERE TO BUY

    What’s in the 7-page PDF:

    • Cover sheet with key specs at a glance
    • Floor framing plan — sleeper layout @ 10″ O.C., cedar deck direction, with substitution notes for non-deck build
    • Back wall elevation — 96″×88″, with a California-corner detail (single corner stud + backing block) for less thermal bridging and more insulation cavity
    • Front wall elevation — door & window rough openings precisely dimensioned, with kings/jacks/headers/cripples all called out
    • Side wall elevation — slope-cut studs with exact cut lengths at every position (88″ back tapering to 79″ front)
    • Roof framing plan — rafters @ 16″ O.C. on edge + outer 2×4 wrap for the eave overhang
    • Materials & cut list — every 2×4, every fastener, with real prices from my build

    You can watch how I framed this sauna using these plans step by step in this video here.

    6′×8′ Outdoor Sauna Interior & Finish Plans

    Phase 2 of the build, picking up where the framing leaves off. These are the actual interior decisions from my own sauna: wall buildup, bench geometry, heater placement, vent positions, all drawn from the as-built measurements.

    CLICK HERE TO BUY

    What’s in the 8-page PDF:

    • Cover sheet with key materials at a glance
    • Wall buildup section detail — cedar T&G → 1×2 furring (3/4″ air gap) → foil vapor barrier → R-15 Rockwool → 2×4 stud → OSB → Tyvek → SmartSide
    • Interior plan view — bench positions, heater corner, vent placement, door swing
    • Back wall interior elevation — 17 cedar boards + top exhaust vent dimensioned
    • Front wall interior elevation — door + window mirrored from exterior, intake vent at heater wall
    • Side wall interior elevation — 16 + 1 angled cedar board, heater placement with clearances, thermometer position, electrical note
    • Bench detail — cross-section + plan: top bench (8’×20″×44″H) + bottom bench (8’×15″×26″H) offset forward, joists 12″ O.C., 4″ cedar slats with 1″ gaps
    • Materials & cut list — cedar counts per wall, insulation, vapor barrier, furring, vents, heater, bench lumber

    You can also buy both PDFs together: 15 pages of dimensioned drawings, materials lists, and build-tested decisions for a 6′×8′ outdoor cedar sauna. Framing through finish, drawn from an actual build on a backyard deck. Prices for lumber and hardware documented with real prices from my exact build.

    You can watch me assemble these plans in my DIY Backyard Sauna series here.

  • Building a Backyard Sauna — Part 5: Finishing the Sauna

    Building a Backyard Sauna — Part 5: Finishing the Sauna

    The final post in my DIY backyard sauna build series. If you missed earlier parts: Part 1 (site prep & framing), Part 2 (roof & weatherproofing), Part 3 (siding, window, ventilation), Part 4 (lighting, vapor barrier, cedar)

    This is the one. The finale. Months of weekends compressed into a single episode that takes the sauna from “almost there” to “finished, fired up, and family-tested.”

    It’s also the longest video in the series, because the last 20% of any build is somehow always the most work. Custom door, benches, exterior ventilation finished out, electrical run, heater installed, first sauna, and a full tour.

    Here’s how it came together.

    Exterior Ventilation Finished Out

    I’d already framed the ventilation openings earlier in the build, but this stage was finishing them out adjustable exhaust vent cover and the intake vent. The intake sits low below the heater and adjacent to it; the exhaust sits high on the opposite wall. That layout creates a slow convection loop that keeps fresh air moving through the room without dumping heat out.

    If your sauna gets stuffy, your ventilation isn’t right. Mine breathes well I can feel a gentle pull of air when the heater’s running, and when I pour water on the rocks the steam doesn’t linger, but moves over me and dissipates.

    Building the Custom Door from Scratch

    I saw people say this in other videos, and it’s true: building a door from scratch is not that easy.

    I started by carefully measuring the doorway on all four sides, then constructed and sanded the frame before squaring it up, gluing the corners, and test-fitting it in the rough opening to make sure it would swing cleanly without rubbing. Getting a door to sit flush is a fussy process: a sixteenth of an inch in the wrong direction and it won’t close right.

    Then I laid one side of the door with the same tongue and groove cedar that’s installed on the interior of the sauna, before flipping it and filling it with R15 Rockwool insulation. We don’t want any part of the sauna to be a weak spot for heat loss, so it’s important that the door has the same quality of insulation as the rest of the walls.

    After that I installed my second piece of custom tempered glass that I ordered from a local glass shop, then all I needed was a handle.

    The door took longer than any other single piece of this build, but it was worth it: a flimsy door would have undone everything else.

    Finishing the Remaining Cedar

    With the door in, I wrapped up the last of the interior cedar corners, the doorframe, and the trickier cuts around fixtures and ventilation. The hand-fitting for these last pieces takes more time than the long, easy runs do. Patience here pays off in how the finished room reads visually.

    Designing and Building the Benches

    Benches are where a lot of DIY saunas go sideways. Wrong height, wrong depth, wrong wood, and the room becomes uncomfortable to sit in.

    A few principles I followed:

    • Two tiers, with the top bench tall enough that your feet are well above floor level when seated. Heat rises, and the top bench is where you actually want to sit.
    • Bench depth wide enough to lie down comfortably. A bench you can only sit on is a bench you’ll only use for ten minutes at a time.
    • Soft cedar (Western Red or Aspen-style), not regular construction cedar. The wood touches your skin. It needs to be smooth and low-resin so it doesn’t get sticky or sappy at temperature.

    Top bench went in first, then the bottom bench. Testing by sitting in the unheated room felt good.

    Under-Bench Lighting

    This was the small touch that ended up making the biggest aesthetic difference. LED strip lighting tucked under the front edge of the top and bottom bench, washing soft light down toward the floor.

    It does two things: practical (you can see where you’re stepping in a dim room) and atmospheric (it’s the difference between a wood box and a space you actually want to spend time in). It also lights the space, and not the people, which is an important element.

    Running the Electrical

    I covered the wiring approach in earlier episodes 50 amp circuit from the main panel to an outdoor 50 amp disconnect, 6/3 wet-rated wire to the sauna control panel, then to the heater. This stage was finishing those connections, mounting the control panel, and wiring up the heater itself.

    If you’re not comfortable with this part of a build, hire it out. The electrical is the one place where “I’ll figure it out as I go” is genuinely dangerous.

    Heater Test and First Sauna

    Powered the heater up for the first time. Watched it climb. Threw water on the rocks for the first time and felt that wave of löyly hit the room.

    It worked.

    There’s a specific quality to the heat in a properly insulated, properly vented sauna with the right kind of stove that you don’t get in a prefab unit or a cheap kit. It’s softer, more even, and the steam has weight to it. That feeling is what I was chasing through this whole build, and it was there on the first burn.

    Heating Theory in Practice

    Sauna heat works on three fronts:

    1. Convection — hot air rising and circulating through the room.
    2. Radiation — direct radiant heat from the heater and stones.
    3. Steam (löyly) — water on hot rocks creating a brief, intense spike of humidity and perceived heat.

    A good sauna balances all three. Too much convection without radiation and steam, and you get a hot room that feels flat. Too much radiation, and you get scorched skin without the depth. Steam ties it all together.

    Painting and Final Trim

    A few exterior touches: paint where it needed paint, cedar trim to clean up the visible transitions. The kind of small finishing work that’s invisible if you do it right and impossible to ignore if you don’t.

    The First Family Sauna

    The whole point of this project was to have something the family could use together. The first sauna with everyone in it was the moment that made the months of weekends worth it.

    The room felt right. The light was warm. The kids loved it. We talked.

    This is what I built it for.

    Final Thoughts on the Heater

    After several weeks of regular use, a few notes on the heater I went with the Vevor 9kW 200V electric heater which is an absolute steal on Amazon at $200. Worth its own paragraph since the heater is one of the decisions DIY builders agonize over the most:

    Trumpkin and most other sources go back and forth on this, and the recurring theme is that heater quality matters a lot. They’ll typically point you toward Harvia or one of the other premium brands that run anywhere from about $1,000 up to $3,000 depending on size and features. My take is that once you’ve gone electric, you’ve already stepped away from the traditional wood-fired stove, and at the end of the day the thing is really just heating a pile of rocks. For my room I probably could’ve gotten away with a 6–8 kW unit, but I oversized to 9 kW and the whole space comes up to temp in about 20 minutes — maybe 30 if it’s really cold out. And even if a component does eventually fail, I could replace this heater ten times over before I’d hit the price of a single premium one. Three or four months in, no issues, no regrets. At 9 kW for what it costs, it’s a great buy.

    Sauna and Cold Plunge

    I didn’t cover the cold plunge in this build, but I’ve been pairing the sauna with a cold plunge after each session. The contrast is the point. Hot, then cold, then rest. Several rounds. The energy and clarity afterward is its own kind of medicine, and it’s something I wanted built into the daily rhythm of where we live.

    What This Build Taught Me

    A few things I keep coming back to:

    • Custom always takes longer than you expect. Especially the door. Especially the door.
    • Don’t cheap out on the parts that matter. Vapor barrier, high-temp silicone, tempered glass, the heater. These are the things that decide whether the sauna lasts 5 years or 30.
    • Ventilation and insulation are 80% of whether a sauna works. Pretty cedar on the inside doesn’t matter if the wall cavity rots out behind it.
    • A good resource is worth its weight in gold. Trumpkin’s Notes saved me from probably ten major mistakes.

    Thank You

    If you’ve followed this series from the start — thank you. Sharing this build was one of the most rewarding parts of the project, and the questions and feedback in the comments made me think harder about a lot of the decisions.

    If you’re starting your own build: take your time, do the boring steps right, and don’t underestimate the door.

  • DIY Backyard Sauna Build – Part 4: Lighting, Vapor Barrier & Interior Cedar

    DIY Backyard Sauna Build – Part 4: Lighting, Vapor Barrier & Interior Cedar

    Part 4 of my DIY backyard sauna build. If you’re just joining: Part 1 (site prep & framing), Part 2 (roof & weatherproofing), Part 3 (siding, window, ventilation).

    This is the episode where the inside of the sauna stops looking like a construction site and starts looking like a sauna. The sequence — lighting wiring, vapor barrier, furring strips, cedar. This has to happen in this order, because once the cedar goes up, anything you forgot is staying forgotten.

    It’s also one of the shorter episodes in the series, but the steps in it matter a lot for whether your sauna lasts 30 years or starts rotting from the inside out in 5.

    Running the Lighting Electrical

    Sauna lighting has to handle high temperatures and high humidity, which rules out a lot of standard fixtures. I went with a setup designed for sauna use, ran the wiring through the wall cavities before any insulation or vapor barrier went on, and left a little slack at each fixture location so I had room to work later.

    A few things I’d flag for anyone doing this themselves:

    • Run the wire before the vapor barrier. Once the vapor barrier is up, you don’t want to be poking holes in it.
    • Use temperature-rated wire. Standard wire jacketing can degrade in sauna conditions. Check the rating on whatever you’re running.
    • Plan your switch location outside the hot room. You don’t want a standard switch on the inside of a sauna.

    Ran a quick test once it was wired in to make sure everything worked before sealing it all up behind the wall.

    Vapor Barrier

    This is the part most non-sauna DIY guides skip or get wrong, and it’s arguably the most important step in the whole interior build.

    A sauna gets hot and humid in cycles: heat up, cool down, repeat. That moisture wants to migrate out through the walls. If it gets into the insulation and stays there, you get mold, rot, and a sauna that smells wrong forever.

    The fix is a foil-faced vapor barrier on the warm side of the insulation (the inside of the sauna). The foil reflects radiant heat back into the room and blocks moisture from getting into the wall cavity. Tape every seam with foil tape, not regular duct tape, which will fail.

    Two rules I followed:

    1. Continuous coverage. Walls and ceiling, every cavity, every seam taped.
    2. Seal around penetrations. Lighting wires, ventilation openings, anything that punctures the barrier needs to be sealed back up.

    This step is boring and slow. Do it right anyway.

    Installing the Furring Strips

    Furring strips go up over the vapor barrier, running perpendicular to the direction the cedar will run. Do not skip furring strips. It does very important things:

    1. Creates an air gap between the vapor barrier and the cedar paneling. This gap lets any incidental moisture dry out instead of sitting against the wood and also allows the cedar to dry on both sides.
    2. Gives you something to nail the cedar to without puncturing the vapor barrier in random places.
    3. My colleague Tyler who also built a sauna pointed out a third benefit I hadn’t fully understood. Without an air gap, the cedar is in direct contact with the framing, so the heat in the wood conducts straight through into the studs and gets pulled into the insulation. With the air gap, the cedar can’t dump its heat into the wall instead, it re-emits the heat as infrared radiation, which the foil-faced vapor barrier reflects back into the sauna. As a result: your cedar walls stay hot, but your insulation stays cool.

    I used 1×2 furring strips over each stud, fastening them with 3 inch construction screws since they would hold the whole weight of the cedar.

    Installing the Cedar

    This is the satisfying part. Tongue and groove cedar going up, board by board.

    A few things that helped:

    • Start with a level reference line. If your first board isn’t level, every board after it is fighting that mistake.
    • Hidden-nail through the tongue. No exposed fasteners on the face of the wood.
    • Acclimate the cedar. Let the wood sit in the build space for a few days before installing so it adjusts to ambient humidity. Cedar that’s installed too dry or too damp can move on you.
    • Stagger your seams. Same as flooring, staggered seams look way better than aligned seams.

    The cedar smell hit immediately. That alone made all the tedious work of the vapor barrier feel worth it.

    What’s Next

    Part 5 is the finale: exterior ventilation finished out, custom door built and installed, benches designed and built, electrical finished, heater installed, and the first sauna. It’s the longest episode in the series and easily the most satisfying to film.

  • DIY Backyard Sauna Build – Part 3: Ventilation, Siding & Glass

    DIY Backyard Sauna Build – Part 3: Ventilation, Siding & Glass

    Part 3 of my DIY backyard sauna build. If you’re just joining, start with Part 1 (site prep and framing) and Part 2 (roof, sheathing, and weatherproofing)

    With the structure framed, roofed, and wrapped, it was time to start turning the sauna from “box that looks like a shed” into something that actually functions as a sauna. Part 3 is where that shift starts — I got the exterior siding on, installed the custom glass window, worked through the ventilation system, and started prepping for the electrical.

    Ventilation ended up being the piece I researched the most, and honestly it’s the part of a sauna build I see people mess up the most online. So I’ll spend some time on it here.

    Cutting the Door Opening and Installing the Front Siding

    Before siding went on, I had to cut the rough opening for the door through the sheathing and house wrap. Pretty straightforward — measure twice, cut once, and keep the cut as clean as possible because the trim will cover small mistakes but not big ones.

    From there, the front siding went up. I worked off the top, keeping a consistent reveal between boards.

    Ventilation Theory (The Part Most DIY Saunas Get Wrong)

    A sauna isn’t just a hot box. For it to actually work — meaning the heat stays where bodies are, humidity moves correctly, and you don’t suffocate — you need air moving in a deliberate way.

    The short version of what I landed on:

    • Intake goes low, near the heater, so fresh air gets pulled up through the stones and into the room at temperature.
    • Exhaust goes on the opposite wall, ideally placed to encourage a slow convection loop rather than dumping hot air out the top.
    • You want air turnover without killing the heat — maybe 4–6 air changes per hour depending on the source.

    Like I mentioned in the videos, I based my setup largely on Trumpkin’s Notes on Building a Sauna, which is the most useful free resource I found on this topic. If you’re planning a build, read it before you frame anything.

    Exterior Trim and Caulking

    Trim went on after the siding — corners, around the window, around the door opening. Not complicated but the kind of detail work that either looks great or looks off, depending on how patient you are with it.

    Then came caulking every seam that would see weather. Use an exterior-grade product rated for the temperature swings in your area. Cheap caulk cracks in a year or two and then you’re chasing leaks.

    The Custom Glass Window

    This was the moment I was most nervous about in the whole build. I had a custom tempered glass panel made at a local glass shop based on the rough opening dimensions I’d framed in Part 1. Tempered is non-negotiable here — regular glass near sauna temperatures is dangerous.

    When it arrived, I dry-fit it first without any sealant just to make sure the opening was right. It was — barely. A snug fit on the right and left side and about a 2 inch gap on top that required additional framing to close that opening.

    Then I framed the opening with cedar stops, applied a bead of high-temp silicone (the red stuff — rated for 500°F+), set the glass, and locked it in with the interior stops. High-temp silicone is the right call here. Standard silicone will off-gas or degrade at sauna temperatures.

    Prepping for Electrical

    With the exterior buttoned up, I started prepping for the electrical run. I’ll cover the actual wiring in Part 4, but at this stage it was mostly about locating the control panel, thinking through the conduit path, and making sure everything I’d need was on hand before I opened anything up.

    What I’d Do Differently

    A couple of lessons from this stage:

    • Dry-fit the glass panel the moment it arrives. If something’s off, you want to know before you’ve committed to sealants and trim.
    • Don’t skimp on high-temp silicone. It’s $10 more than the regular tube and it’s the difference between a window that lasts and one that fails in a year.
    • Plan your ventilation before you frame, not after. I got lucky that my placements worked out, but if I were doing it again I’d mark the exact intake and exhaust locations during framing.

    What’s Next

    Part 4 is a short video covering the lighting electrical, vapor barrier, and installing the furring and the first part of the actual interior cedar. Part 5 is finishing the sauna, and using it!

  • DIY Backyard Sauna Build – Part 2: Roofing, Sheathing, and Insulation

    DIY Backyard Sauna Build – Part 2: Roofing, Sheathing, and Insulation

    Part 2 of my DIY backyard sauna build is here! In this episode I get the sheathing up, build and install the roof, wrap the whole structure in Tyvek, install hurricane ties, insulation, and flash the window and door openings.

    This was the stage where the sauna finally started to look like an actual building and where a few small mistakes (looking at you, drip edge) taught me some lessons I wish I’d learned before starting.

    Part 1 is here with parts 3, 4, and 5 coming in the next few days.

  • DIY Backyard Sauna Build – Part 1: Site Prep & Framing

    DIY Backyard Sauna Build – Part 1: Site Prep & Framing

    I spent the last several months designing and building a sauna from scratch in my backyard and finally started posting the build on YouTube. Part 1 is live! It covers the background, site prep, and framing.

    Key things covered:

    – Why I decided to build instead of buy

    – Site preparation

    – Base frame construction

    – Wall framing and layout

    Part two is also already live with the rest coming in the following days.

  • If Your Website Only Works in Chrome, It Doesn’t Work

    If Your Website Only Works in Chrome, It Doesn’t Work

    I posted that on X back in January of 2024.

    I believed it then. I believe it now. But I’m starting to wonder if the rest of the internet got the memo, because things have gotten significantly worse.

    I use Firefox. I’ve written about this before. I use it because it’s open source, because Mozilla isn’t Google, and because Google already has enough of my data without handing them my entire browsing history on top of it. I even wrote a Firefox extension to fix a hotkey change that Mozilla made in Firefox 88 that messed up my workflow. I’m committed to this browser. I don’t want to leave.

    But the web is making it really, really hard to stay.

    The Numbers Are Brutal

    Let’s just look at where we are. According to StatCounter, Chrome’s global market share was 65.87% in 2022. By 2025, it climbed to 68.35%. On desktop specifically, it’s sitting at 73.26% as of February 2026. Firefox? It went from 3.04% in 2022 to 2.37% in 2025 to 2.29% now. That’s not a decline. That’s a slow death.

    And here’s the thing that makes it even worse: Chrome isn’t the only browser running on Google’s engine. Edge, Brave, Opera, Vivaldi, Arc… they all run on Chromium. When you add them all up, roughly 70% of all browsers on the planet are running Google’s rendering engine. Firefox and its Gecko engine are basically the last ones standing that aren’t either Chromium or Apple’s WebKit.

    We have been here before. This is IE6 all over again. Except this time the dominant browser is actually good, which makes the problem harder to see and even harder to fight.

    Developers Don’t Test Anymore

    Here’s where it gets personal. I browse the web every single day in Firefox and I run into broken websites constantly. Not “oh this font looks a little different” broken. I mean login forms that won’t submit. Payment flows that hang. Entire web apps that just show a blank white page. Dropdown menus that don’t open. Modals that trap your focus and never let go.

    Mozilla’s own community forums are full of people reporting the same thing. Users on Mozilla Connect describe websites that load in seconds on Chrome but take over a minute in Firefox. E-commerce sites where the payment button literally does not work unless you switch browsers. I can’t even pay my internet bill in Firefox. I’m not kidding.

    The MDN Browser Compatibility Report found that only 44% of developers were satisfied with the state of cross-browser compatibility. One developer in that survey said it plainly: “Chrome and Firefox are starting to diverge, with Chrome adding features before they’re fully standardized. As the dominant browser, some pages are being written to only work in Chrome now.”

    Another one: “Many APIs are Chrome-only and will never show up in other browsers.”

    This is not a Firefox problem. This is a developer problem. The browsers themselves are actually converging on standards. The Interop 2024 project ended the year with 95% of web platform tests passing across Chrome, Edge, Firefox, and Safari. Firefox scored the highest at 98.8%. Let me say that again: Firefox has the best standards compliance of any major browser, and websites still break in it because developers simply do not test.

    Enter the Vibe Coders

    So that’s the baseline. Developers were already building Chrome-only websites before AI entered the picture. Now let’s talk about what happened when you gave millions of people the ability to generate entire web applications without understanding what they’re generating.

    The timeline is almost poetic. Anthropic released Claude to the public in July 2023. Claude 3 dropped in March 2024. ChatGPT had already been out since late 2022. By 2025, “vibe coding” had become an actual term. Andrej Karpathy coined it. The idea is simple: you describe what you want, the AI writes the code, you accept it and move on. You don’t really look at it. You just… vibe.

    And during this exact same window, Chrome’s market share went up. Firefox’s went down.

    Now, correlation isn’t causation. I’m not claiming AI killed Firefox. But I am saying that AI made an existing problem dramatically worse, and here’s why.

    As I mentioned above, developers were already bad at cross-browser testing. They at least had the knowledge to do it if they wanted to. Vibe coders don’t even have that. They’re accepting generated code without reviewing it. Researchers have called this the “verification gap,” where building has been democratized but testing has not. A study from December 2025 found 69 vulnerabilities across 15 vibe-coded test applications. AI co-authored code showed 2.74x higher security vulnerabilities and 75% more misconfigurations than human-written code. If these tools can’t even get security right, you think they’re generating proper cross-browser fallbacks?

    LLMs are trained on the internet, and the internet is overwhelmingly Chrome. When an AI generates CSS, it reaches for -webkit- prefixed properties because that’s what dominates the training data. When it generates JavaScript, it uses APIs that Chrome supports because those are the ones most represented in the corpus. It’s a feedback loop. Chrome dominates, so the training data skews Chrome, so the AI generates Chrome-first code, so more websites only work in Chrome, so Chrome dominates further.

    Even some of the vibe coding platforms themselves are part of the problem. Bolt, one of the popular ones, straight up tells you it “works best on Chrome and other Chromium-based desktop browsers.” The tools used to build the web are now themselves Chrome-only. Let that sink in.

    The IE6 Lesson Nobody Learned

    In the early 2000s, Internet Explorer had somewhere around 95% market share. Developers built “works best in IE” websites. ActiveX controls everywhere (lol remember that?). Proprietary extensions that only worked in Microsoft’s browser. The web became a monoculture, innovation stalled, and it took years to dig out of that hole. Firefox was literally born to solve that problem.

    We are doing the exact same thing again, except this time it’s Google instead of Microsoft, and this time we have AI accelerating the consolidation at a pace that makes the IE era look quaint.

    Google reportedly makes up 60-70% of W3C meeting attendees. They are not just building the dominant browser. They are driving the standards process itself. The fox is running the henhouse, and the hens are writing Chrome-only websites with AI tools that don’t know any better.

    I Might Have to Switch

    I never thought I’d write this. I have used Firefox for a long time. I believe in what it represents. An open, independent web where no single company controls how you experience the internet. I’ve written more than one browser extension for it, I’ve reported bugs, I’ve defended it in conversations more times than I can count.

    But I’m tired of being the person who has to keep a second browser around for when things don’t work. I’m tired of hitting a login page and wondering if the button is broken or if it’s just Firefox. I’m tired of doing a double-take every time a website looks weird, trying to figure out if it’s a bug or if the developer just never opened anything except Chrome.

    At some point, principle runs into practicality. And right now, using Firefox on the modern web feels like bringing a perfectly good car to a highway that was paved exclusively for trucks.

    What’s Actually at Stake

    If Firefox dies, and its market share trajectory suggests that’s not a hypothetical, we lose the last truly independent browser engine. Every browser will either be Chromium or WebKit. Google will effectively control how the web renders for everyone on the planet.

    A single Chromium vulnerability would affect the vast majority of browser users globally. A single change to how Chromium handles ads, tracking, or content would ripple across billions of screens. One company. One engine. One point of failure.

    The U.S. Department of Justice proposed in November 2024 that Google divest Chrome entirely. They valued it at around $20 billion. Whether that happens or not, the fact that it’s even being discussed should tell you something about how consolidated things have gotten.

    I don’t have a clean solution here. I can’t make developers test in Firefox. I can’t make AI tools generate cross-browser code. I can’t single-handedly prop up a browser engine’s market share.

    But I can say this: if you’re a developer, open Firefox. Load your site. Click around. Fill out a form. Try to pay for something. If it doesn’t work, fix it. It’s that simple.

    And if you’re building websites with AI and you’re not testing the output in multiple browsers, you’re not building websites. You’re building Chrome extensions with extra steps.

    If your website only works in Chrome, it doesn’t work.

  • I Built a Menu Bar App That Turns My Wife’s Texts Into Calendar Events

    I Built a Menu Bar App That Turns My Wife’s Texts Into Calendar Events

    My day is a wall of notifications.

    IRC, Slack, Discord, P2s, Adium jabber alerts, ntfy.sh pings, Telegram, WhatsApp, iMessage. I have thousands of streams of text coming at me every single day. It’s just ping ping ding ding ding from the moment I open my laptop until I close it.

    And somewhere in that noise, my wife texts me that the kids have a baseball game Tuesday at 5pm at Riverside Park.

    She’s incredibly organized. She texts me about dates, plans, appointments, school events, family stuff. All the time. And she’s great about it. The problem is me. I’m neck deep in a Kubernetes migration or chasing a kernel bug, and by the time I come up for air, that text is buried under 47 Slack threads and a Discord ping about someone’s homelab.

    So I built something to fix it.

    iMessageWatcher

    Screenshot of iMessageWatcher app showing a conversation about a kids' baseball game scheduled for February 24, 2026, with event details added to the calendar.

    iMessageWatcher is a macOS menu bar app that watches my iMessages specifically from my wife and uses a local LLM to figure out if a message contains an event, a date, a reminder, or something I need to act on. If it does, the app automatically creates a calendar event with the name, location, time, and all that. No input from me. No copy-pasting. No “I’ll add that later” (which means never).

    The whole thing runs locally. The LLM runs on my machine through Ollama. My wife’s messages never leave my device, never hit a cloud API, never get sent to OpenAI or anyone else. That was non-negotiable for me.

    How It Works

    The app sits in your menu bar and polls the iMessage database (~/Library/Messages/chat.db) every 60 seconds. It watches for new messages from whichever contact you configure (in my case, my wife’s number).

    Flowchart illustrating how iMessageWatcher processes text messages into calendar events on a device, showing steps from iMessage database to classification and extraction by Olama LLM, leading to integration with Calendar, Reminders, Due App, and ntfy.sh.

    When it finds new messages, it grabs the recent conversation context and sends it to a local Ollama instance running deepseek-r1 (or whatever model you prefer). The LLM gets a prompt that basically says: “Look at this conversation. Is there an event, appointment, or task mentioned? If so, extract the name, date, time, and location. Return JSON.”

    The app parses the response and creates the event in Apple Calendar. Done. My wife texts “Don’t forget about the kids’ baseball game Tuesday at 5pm, it’s at Riverside Park” and a few seconds later, “Kids’ Baseball Game” shows up on my calendar for Tuesday at 5:00 PM at Riverside Park. I don’t touch anything.

    It also works with Apple Reminders, the Due app (a personal favorite reminder app), and ntfy.sh for push notifications. You can toggle each one on or off depending on your setup.

    The Entire App Is 4 Files!!!1

    This is probably my favorite part. The whole thing is 4 files with no Xcode project and no external dependencies:

    Overview of the app structure, featuring four key files: main.swift as the entry point, AppDelegate.swift for application logic, Info.plist for metadata, and build.sh for compilation. Each file includes brief descriptions of its functionality.
    • main.swift : App entry point. 5 lines.
    • AppDelegate.swift : All the logic. Menu bar, SQLite scanning, LLM classification, EventKit integration, preferences window. Everything.
    • Info.plist : Bundle metadata and permission descriptions.
    • build.sh : Compiles the app, generates the icon programmatically, bundles everything into a proper .app.

    No CocoaPods. No Swift Package Manager. No Xcode project file. You clone the repo, run ./build.sh, and you have a working macOS app. The build script even generates the app icon using Core Graphics in an inline Swift script. I love that kind of simplicity.

    The compilation is just a single swiftc call:

    swiftc -O main.swift AppDelegate.swift \
      -framework Cocoa \
      -framework EventKit \
      -lsqlite3

    That’s it. Two Swift files, three frameworks, one binary.

    Why Local LLM

    I thought about this a lot. I could have used OpenAI’s API or Claude’s API and gotten better classification accuracy out of the box. But these are my wife’s text messages. They contain personal details about my kids, our schedules, where we’ll be and when. I’m not sending that to a third party.

    Ollama makes this easy. You install it, pull a model, and you have a local inference server running on localhost. The app just makes HTTP requests to http://localhost:11434. Everything stays on my machine.

    The classification accuracy with deepseek-r1 is honestly great for this use case. It’s not trying to write poetry. It’s looking at a text message and deciding “is this an event or not” and pulling out structured data. Local models handle that just fine.

    The SQLite Trick

    iMessage on macOS stores everything in a SQLite database at ~/Library/Messages/chat.db. The app reads it directly using the SQLite3 C API (no ORMs, no wrappers, just raw queries). It tracks which messages it’s already processed using ROWIDs so it never creates duplicate events.

    You do need Full Disk Access enabled for the app since chat.db is in a protected directory. The app checks for this on launch and walks you through enabling it if needed.

    What It Actually Catches

    Here’s the kind of stuff that used to slip through the cracks and doesn’t anymore:

    • “Soccer practice moved to Thursday at 4:30”
    • “Dentist appointment for the kids next Wednesday at 2”
    • “My mom is coming over Saturday around noon”
    • “Can you take and pick up the kids from school tomorrow?”
    • “I’m traveling for a work event the second week of April to Houston” (Yes it will do a multi day entry accurately”
    • “Don’t forget we have that dinner thing Friday at 7, it’s at that Italian place downtown”

    The LLM is good at parsing casual language. My wife doesn’t text in calendar-event format. She texts like a normal person. And the model handles it.

    Try It

    The repo is at github.com/rfaile313/iMessageWatcher. Clone it, run ./build.sh, configure your contact, and you’re done.

    You’ll need:

    • macOS 14+
    • Ollama installed and running
    • Full Disk Access for the app
    • Calendar and Reminders permissions

    It’s free, it’s open source, and your data never leaves your machine. If you’re someone who drowns in notifications and occasionally misses the important stuff from the people who matter most, this might help.

    It definitely helped me stop being the guy who forgets about Tuesday at 5pm.