Bridges to Nowhere
Resurrecting the White House Feeds with RSS-Bridge
Not long ago, the White House website provided a simple, powerful, and standard public service: RSS feeds for its "Presidential Actions." For anyone who wanted to systematically track Executive Orders, Proclamations, or Memoranda, these feeds delivered structured, machine-readable data directly to your feed reader of choice, creating a reliable, real-time record of executive action.
Sometime recently, that service disappeared. The official /feed/ URLs now lead to a "404 Page Not Found" error:
This is more than a technical inconvenience. It is a quiet but meaningful degradation of public infrastructure. The burden of tracking government action has been shifted from an efficient, automated "push" system to a manual, laborious "pull" system. Citizens, journalists, and legal professionals are now expected to repeatedly visit the website and visually scan for changes—a process that is inefficient, prone to error, and fundamentally less transparent.
This represents a deliberate shift from structured data to unstructured presentation. An RSS feed is more than a list of links; it is a promise of machine-readability, a channel for automated monitoring. By removing it, the administration trades genuine transparency for digital aesthetics, replacing an open data stream with a static webpage. The public record may still exist, but the ability to easily and systematically engage with it has been degraded.
Rebuilding the Bridge
When an official channel is dismantled, the open-source community often provides the tools to rebuild it. In this case, the foundation for a solution is RSS-Bridge, a powerful, self-hosted framework that generates feeds for websites that lack them.
The true strength of RSS-Bridge is its extensibility. The platform allows anyone to write a small, specific PHP script—a "bridge"—that tells the system how to parse a particular website. I developed a suite of these custom bridges to target the White House pages, restoring the original functionality by turning the unstructured HTML back into structured data feeds.
Use the Bridges
The goal of this work is to share the solution. To that end, the bridges are available for public use. You can generate feeds from my public instance at https://rssbridge.sij.law, view the live output in my FreshRSS reader at https://rss.sij.law, or grab the code from GitHub to run it yourself. The code is open source and available on my fork of the project (look for the WhiteHouse*.php files), pending its inclusion in the main repository.
The Enduring Need for Watchtowers
The removal of a simple RSS feed is symptomatic of a larger trend toward a less open, less verifiable digital commons. When official sources of information become less reliable, the need for independent, citizen-run "watchtowers" grows. This problem of disappearing infrastructure is a close cousin to the issue of link rot I explored in a previous post, "Toward Enduring Web Citations." Tools like RSS-Bridge and ArchiveBox provide a powerful counternarrative, equipping us to build more resilient and trustworthy methods for accessing public information. We cannot afford to be passive consumers of data that can be altered or removed on a whim; we must build and maintain our own bridges.
On Compelled Silence and Compelled Lies
If a canary song is heard, but no one verifies the source, are we safe or already compromised?
Someone on We2.ee asked me about the “warrant canary” I recently introduced there. What it’s good for, how it holds up legally, if canaries are more than just digital virtue signaling. It’s a sharp question, and one I wanted to explore thoroughly. So let’s dive into what warrant canaries are, their uncertain legal terrain, and why—and how—I chose to implement one anyway.
From Mineshafts to Mainframes
The term “warrant canary” originates in a familiar but grim coal mining practice. For generations, miners would carry caged canaries—small, famously sensitive songbirds—down into the shafts with them. The bird’s well-being was a constant, living indicator of air quality. As long as the canary sang, the air was safe. If it fell silent, it served as an urgent warning to GTFO before invisible toxic gases overwhelmed the miners, too.
A warrant canary is an attempt to apply this idiomatic concept in an entirely different context where the invisible threat isn’t carbon monoxide but a secret government order accompanied by a gag clause. The canary’s ‘song’, here, is a regularly published statement from a service provider asserting that no such orders have been received. Its sudden absence is the signal. But this elegant concept raises some thorny questions: can we trust a canary that continues to sing? And if it falls silent, what does that actually tell us?
A Clever Feint on Shaky Legal Ground
The entire legal theory of a warrant canary hinges on a frankly audacious distinction that has never been definitively tested in court. It operates in the grey area between the government's power to compel silence (via a gag order) and the First Amendment's protection against compelled speech.
Laws like the USA PATRIOT Act and the Foreign Intelligence Surveillance Act (FISA) grant government agencies the power to issue secret orders for data, like National Security Letters (NSLs). These often come with gag orders, making it a crime for the recipient to disclose the order's existence. That is compelled silence.
However, forcing a provider to continue publishing a statement they know to be false (e.g., "we have not received any NSLs") would be compelling them to lie. This is a form of compelled speech that would face much stricter constitutional scrutiny. The warrant canary is designed to exploit this gap. Rather than lie, the provider simply stops speaking.
But let's be clear: this is a high-stakes legal gamble.
A prosecutor would almost certainly argue that the sudden, deliberate silence is a form of communication intended to circumvent the gag order. And given this administration’s relentless assault on civil liberties, paired with a Supreme Court that has shown willingness to reconsider long-standing precedents, it is far from certain that a court would favor the canary's subtle logic over a government demand for total secrecy.
A provider who lets their canary expire isn't just signaling to their users; they are potentially volunteering to be the test case in a novel, expensive, and foundational legal battle they are not guaranteed to win.
Warrant Canaries in the Wild
With legal precarity as backdrop, three prominent cases demonstrate the challenges, the triumphs, and why precise design is everything when navigating such hostile territory.
Apple: The Canary, the Standoff, and the Long Game
The most famous and fiercely debated warrant canary incident is Apple's. To understand it, you have to remember the context: it was November 2013, the ink barely dry on the Snowden/PRISM revelations. Public trust in tech companies' ability to protect user data from government overreach was at an all-time low. In its very first transparency report, Apple made a bold claim:
“Apple has never received an order under Section 215 of the USA Patriot Act. We would expect to challenge such an order if served on us.”
For privacy advocates, this was a masterstroke. The implication was that if this sentence ever vanished, users should assume Apple had been served such an order and was legally gagged from saying so.
Then, in the very next report and all that would follow, the sentence was gone. Rampant speculation ensued. Had the canary worked, signaling a secret order? Or was it just a lawyerly rewording in response to new DOJ reporting guidelines? The ambiguity was the message, and no one outside Apple knows for sure.
Of course, Apple’s canary saga doesn't exist in a vacuum. It must be viewed as part of a bigger pivot toward user privacy under Tim Cook, memorialized in his 2014 statement of privacy as a fundamental human right. Just two years later, Apple’s commitment to user privacy faced an arguably much more meaningful test, in its famous 2015–2016 standoff with the FBI. The Bureau demanded Apple create a backdoor into the San Bernardino shooter's iPhone; Apple refused. Apple aced the test, moving the conversation from the fine print of a transparency report to the front page of every major newspaper.
RiseUp: Silence in Seattle Cements Concept
If the Apple story is about interpreting ambiguous signals from a corporate giant, the experience of the activist-focused tech collective RiseUp is about a canary serving its exact, intended purpose under immense pressure. In late 2016, the collective failed to update the warrant canary on their website.
The silence did not go unnoticed. For a user base of activists and organizers deeply attuned to such signals, the lapse was an immediate red flag. Commentators like William Gillis at the Center for Stateless Society quickly documented the "dead canary," correctly interpreting it as a near-certain sign that RiseUp had been served a secret government order with a gag clause. The system, at least as an alarm, had worked.
Months later, in February 2017, the collective was finally able to publish a statement explaining the situation. They had received two sealed FBI warrants, both accompanied by gag orders, related to an international DDoS extortion ring and a ransomware operation—criminal activities that violated their terms of service. Faced with the choice of perjuring themselves by issuing a false canary or facing contempt of court charges and likely incarceration, they chose the correct (and only legally viable) option: they said nothing and let the canary expire.
In their own words:
"The canary was so broad that any attempt to issue a new one would be a violation of a gag order... This is not desirable, because if any one of a number of minor things happen, it signals to users that a major thing has happened."
As a result, RiseUp changed their canary, making it narrower and more specific.
Cloudflare: Questions of Scale and the Plausibility of Perfection
The lessons from Apple's ambiguity and RiseUp's high-stakes test culminate in the Cloudflare approach: a masterclass in surgical precision. As one of the core infrastructure providers of the modern web, the promises they make carry enormous weight. Their canary isn't a single sentence in a report, but a specific list of substantive actions they have never taken.
Since at least 2019, their transparency reports have consistently included the following six attestations:
1. Cloudflare has never turned over our encryption or authentication keys or our customers' encryption or authentication keys to anyone.
2. Cloudflare has never installed any law enforcement software or equipment anywhere on our network.
3. Cloudflare has never provided any law enforcement organization a feed of our customers' content transiting our network.
4. Cloudflare has never modified customer content at the request of law enforcement or another party.
5. Cloudflare has never modified the intended destination of DNS responses at the request of law enforcement or another third party.
6. Cloudflare has never weakened, compromised, or subverted any of its encryption at the request of law enforcement or another third party.Given this clarity, it was interesting to see the community concern that erupted on platforms like Hacker News in 2023 and early 2024. Vigilant users noticed that the date stamp on their transparency report page appeared to be stale, leading to speculation that one of these six promises had been broken. The situation highlighted the hair-trigger sensitivity of the community, and even prompted a response from Cloudflare's CEO, Matthew Prince, who noted the delay was likely an oversight.
This confusion appears to stem from a stale date on a webpage, not a change in the canary's substance. My own research confirms the six attestations above have remained consistent through every semi-annual report. As of this writing, their canary page is fully up-to-date and those same six attestations remain intact.
Far from being a failure, I see the Cloudflare case as a textbook example of a canary working as intended, albeit in a roundabout way. The precision of their statements leaves little room for misinterpretation, and the community's swift reaction to a perceived lapse—even one that turned out to be a clerical error—proves that people are watching. That vigilance is a non-negotiable component of any successful canary system.
And yet, one must acknowledge the extraordinary nature of Cloudflare's position. Given that they route roughly 20% of the entire web, the claim to have a perfect record against immense, constant state-level pressure is, to say the least, a remarkable one. This doesn't invalidate their canary; rather, it underscores why the community's vigilance is so important. For those who wish to monitor for themselves, Cloudflare helpfully provides an RSS feed for its transparency reports.
Words Are Very Necessary
So, after wading through the legal ambiguities and the real-world case studies, the question remains: is running a warrant canary a worthwhile endeavor, or just digital virtue signaling?
For me, it’s a yes—but only if it is a direct and thoughtful response to the lessons learned from those who came before:
- The attestations must be precise. As RiseUp learned, a broad canary is brittle. The We2.ee canary makes only four, narrowly-scoped promises focused on the most fundamental compromises: secret court orders, physical seizure, compelled surveillance modifications, and gag orders that would force a lie by omission.
- The proof must be verifiable and decentralized. As Apple’s ambiguity taught us, a canary needs a strong, public proof of life. Each We2.ee canary is time-stamped with a current news headline and a Monero block hash, then cryptographically signed with my PGP key.
- The process must be deliberate. A fully automated canary is worthless—a sophisticated adversary who compromises a server could simply let it keep running. My canary.py script gathers data but requires my manual review and GPG passphrase to sign and post the final message.
Of course, even this design has weaknesses. A missing canary is still ambiguous—it could mean a gagged order, but it could also mean I’m on vacation. It’s vulnerable if an adversary compromises not just the server, but my private PGP keys. As the Cloudflare case proves, it only works if people are actually watching.
are we safe or already compromised?
How to Verify the Canary
Step 1: Import My Public Key (One-time setup)
My public PGP key is the ultimate source of truth for my online identity. You can import it from the OpenPGP.org keyserver:
# Import the key from a public server
gpg --keyserver keys.openpgp.org --recv-keys '323A8A2C47B376224B3613B7535B265AEDBE5B44'
# Verify the fingerprint of the imported key
gpg --fingerprint [email protected]
# This should display: 323A 8A2C 47B3 7622 4B36 13B7 535B 265A EDBE 5B44
Step 2: Verify the Canary Message (Weekly check)
With my key imported, you can download the latest canary statement from the sw1tch repository and verify its cryptographic signature.
# Download the latest canary
curl -s https://sij.ai/sij/sw1tch/raw/branch/main/canary.txt > canary.txt
# Verify its signature
gpg --verify canary.txt
A successful check will show a Good signature from my key.
The Bottom Line
This all leads to a simple protocol: if the weekly canary in the #announcements:we2.ee room is more than three days late without a prior announcement, ping me. If there’s still radio silence, you should assume the canary's purpose has been triggered and act accordingly.
Ultimately, running a canary for We2.ee is not about digital virtue signaling. It is about transforming an abstract commitment to user privacy into a concrete, weekly, verifiable action. It is not a solution to state surveillance, but it is an alarm bell—and in a world of compelled silence, a reliable alarm bell is a powerful tool.
The free open source code for sw1tch, including the canary.py module, is available on my personal code hub.
Toward Enduring Web Citations
An attempt to solve the twin problems of impermanence and imprecision.
n. A citation that combines a textual reference with a durable hyperlink to that exact passage in a preserved copy of the source.
v. (–cited, –citing) To create a citation by joining a selected text passage to a permanent, pinpoint hyperlink of its archived source.
Before going into the mechanics, see it in action:
Here’s the deepcite I created there—try the link for yourself:
The Twin Flaws of a Standard Hyperlink
The architecture of the web is fundamentally at odds with the demands of lasting citation. Any link we use as a reference is undermined by two distinct problems: one of permanence, the other of precision.
The permanence problem—link rot—is well-known. A normal hyperlink is a fragile, hopeful pointer to a resource you don't control. Pages change, URL schemes evolve, and critical information simply disappears. The Internet Archive has been fighting this battle for decades.
The precision problem is more subtle, a chronic friction we’ve just grudgingly accepted. A link to a 10,000-word article isn’t a citation; it’s a research assignment you’ve hoisted upon your reader. In effect they are asked to (a) take you at your word, (b) try to guess the right keywords for a ⌘ F search with whatever contextual clues you’ve provided, or (c) just resign themselves to reading the document in full.
The web has an emerging tool for the precision problem in the text fragment URL. By appending #:~:text=... to the end of a link, you can direct nearly every modern web browser to scroll to and highlight a specific passage on that page. At first blush, this recent W3C standard seems incredibly useful. Provide a colleague the precise pincite to one consequential fact you spot on line 2416 of a dense environmental report. Or point your future self back to a key insight toward the end of an obscure scientific study that took you multiple reads to appreciate its significance. This looks promising...
But on its own, this technology only exacerbates the permanence problem. It creates a citation so specific that a single punctuation fix on the live page will break it—a phenomenon one might aptly call “fragment rot.”
A truly useful web citation needs to solve both problems at once: it must point precisely to the relevant portion of a cited source, and it must do it enduringly. For that to happen, the source itself must be frozen in time, exactly as it appeared when the citation was made.
Calling All Archivists
Inspired by my earlier work on a similar script for DEVONthink (which also has significant new features and improvements as I'll detail in a follow up post), I saw the potential a text fragment tool could have. I enlisted my trusty AI coding assistant, and within five minutes, I had a working proof of concept. But my initial success was short-lived. I experienced fragment rot firsthand after just a few uses, and then again a few days later. The theoretical risk I’d anticipated was a practical, frequent reality.
This technical frustration soon collided with a much larger concern. Immediately after the presidential inauguration on January 20, 2025, information began disappearing from federal government websites—first sporadically, very soon systematically. Databases and other resources conservationists have long relied on from agencies like the EPA and NOAA, among others, abruptly went dark.
As a public interest environmental lawyer, my work is built on this data. My cases under the Endangered Species Act (ESA), Clean Water Act (CWA), and National Environmental Policy Act (NEPA—RIP) depend on a stable, verifiable administrative record. This wasn’t just another vaguely-menacing news item portending yet more symbolic violence on the Rule of Law. It represented (and still represents) a clear, concrete, and immediate threat to my clients' interests and to the science-based, mission-driven advocacy my colleagues and I have built our careers on.
I had already explored the world of self-hosting enough to have come across ArchiveBox, an open-source tool that creates high-fidelity, personal archives of web content. Its recent beta API made it the perfect engine. But ArchiveBox alone wasn’t sufficient. The URL for each archived snapshot includes a timestamp with microsecond accuracy, making it impossible to predict from the client-side. I needed a custom bridge to sit between my browser and my archive.
The Web Deepcite Tool
My solution is composed of two parts that work together: a script that runs in your browser, and an optional backend you can host yourself.
1. Browser Deepciter (client)
The heart of the system is a single JavaScript file. I run it in Orion Browser using its excellent Programmable Button functionality with a keyboard shortcut, but it works just as well as a standard bookmarklet in any other modern browser.
When you select text on a page and run the script as-is, it assembles and stores in your system clipboard a deepcite formatted in rich text looking like this:
note: the cite is hyperlinked with text fragments to the original:
https://example.com/#:~:text=This%20domain%20is ...When you configure the script by pointing PROXY_BASE_URL to your self-hosted backend, and specifying URL_PREFIX to match your backend’s configuration, it creates a deepcite that looks the same, except that the citation's hyperlink points to the archived webpage.
2. Self-Hosted Backend (server)
The backend pairs a standard ArchiveBox instance with a FastAPI server that I wrote to act as a smart proxy with basic URL shortening / analytics functionality built in. When you create a deepcite, the backend tells ArchiveBox to save a 100% self-contained archive of the page using Singlefile.
When the link is visited, the proxy serves that file after injecting a minimalist banner at the top to indicate:
- archival date;
- any delay between when the citation was made and when the page was archived (this can happen if ArchiveBox had a long job queue or was unresponsive);
- link to archived PDF of page;
- link to original / live page; and
- QR code for archival URL.
Try First On My Demo Server
Setting up a self-hosted server can be a project. To help decide if this is a workflow you'd find useful, you can point the client script to my public demo instance. To do this, configure the variable at the top of the JavaScript file:
PROXY_BASE_URL = 'https://cit.is'Getting Your Own Setup Running
If you're as excited about this as I am, and want your very own permanent private archival deepciter, head over to my open source code repository to get started:
The README.md file in that repository provides the canonical step-by-step instructions. The setup process should be familiar to anyone who has dabbled in self-hosting. You will use a standard .env file to configure the ArchiveBox Docker container, and a config.yaml file to tell the proxy script where to find your ArchiveBox instance and how to behave. Once configured, you run the services with docker compose and the proxy script via Python.
Next Steps
This toolkit is already a core part of my own workflow, but I am considering several future improvements and welcome feedback. I'm currently mulling adding the Internet Archive as an alternative to Archivebox, finding a creative way to bypass the need for a server script (perhaps by combining Internet Archive with an API call to a link shortening service), integrating deepcite functionality directly into ArchiveBox (i.e. by forking that project), and building browser extensions for a more polished UX than bookmarklets.
The web's citation problems aren't going away—if anything, the recent wave of government data disappearing has made clear how fragile our digital references really are. Deepcite won't solve every corner case, and setting up your own archive does require some technical effort. But for researchers, writers, and lawyers who depend on precise, durable evidence, the investment in a system you control is, I believe, a necessary one.
UPDATES
2025.06.20
I've added support for using SingleFile directly and bypassing ArchiveBox. In my testing so far SingleFile is faster, more reliable, simpler, and uses a lot less space. I.e., a win/win/win/win. SingleFile is therefore now the default mode.
2025.06.22
I'm excited to share that I'm busy building this out as a subscription service at cit.is. Stay tuned for announcements about a public beta soon. Meantime, please note I'm moving the demo deepcites from https://sij.law/cite/ to https://cit.is/ .
One Script to Secure Your Shit, Two More to Tell You About It
`vpn`, `vitals`, and `vitals monitor` keep my connections locked and my servers visible. Purpose-built and a bit hacky—here’s how they work and why I rely on them.
I self-host this blog, earth.law (Mastodon), lone.earth (Peertube), sij.ai (Forgejo), we2.ee (Matrix), and a mess of other communications, data gathering & forensics, and personal cloud infra and microservices. Unencrypted traffic or blind spots? Not happening. These three scripts—vpn, vitals, vitals monitor—secure my setup and keep me in the loop. They’re rough-edged but deliberate, living in my system PATH alongside the dozens more at sij.ai/sij/pathScripts. Let’s dig in.
vpn: exit node control with privacy in mind
vpn manages Mullvad VPN exit nodes through Tailscale, encrypting traffic and keeping logs. It's at sij.ai/sij/pathScripts with docs.
What It Does
- Commands:
start,stop,new,shh(random from privacy-strong countries),to <country>,status. - Logs switches to
/var/log/vpn_rotation.txt. shhpicks from a list—Finland, Germany, Iceland, etc.—where privacy laws mean something, more critical than ever for dissidents and discontents in the US of A.. under the current administration.
Examples
vitals: server health in JSON
vitals dumps server Tailscale and AdGuard network diagnostics to JSON for downstream use. It’s also at sij.ai/sij/pathScripts along with more documentation.
What It Does
- Grabs local IP and uptime.
- Hits Mullvad’s API for WAN IP, VPN status.
- Checks Tailscale nodes and AdGuard via custom filtering rules.
Example
Setup
Add an AdGuard DNS rewrite — check.adguard.test pointed to the server's Tailscale IP (100.x.x.x).
vitals monitor: track server vitals in macOS menu bar
A SwiftBar plugin for macOS built on vitals and vpn, pinging my local machine and two servers every 15 seconds and parking the results up top in hyper-minimalist fashion. Find it at sij.ai/sij/SwiftBar.
What It Does
- Runs
vitalson localhost and up to two servers (defined in~/.servers.yaml) - Menu bar Braille readout: one row per server, left dot for Mullvad VPN, right for AdGuard DNS, ●: on, ○: off.
- Flag emoji: localhost's exit node country—jurisdiction in one glyph.
- Dropdown: WAN IP, Mullvad hostname, DNS, uptime. IP's clickable to rotate VPN.
Example
Menu bar shows ⠝ 🇩🇪:
- Localhost: ●● - Mullvad (VPN) on, AdGuard (DNS) on
- Server 1: ○● - Mullvad (VPN) off, AdGuard (DNS) on
- Server 2: ●○ - Mullvad (VPN) on, AdGuard (DNS) off
- 🇩🇪 means the localhost's internet traffic goes is routed through a Mullvad exit node in Germany.
Dropdown might look like:
sij-mbp16
🇸🇪 89.37.63.18
⋈ AdGuard Home
⧖ up 6 hours, 58 minutes
---
sij-vm
🇩🇰 45.129.56.152
⋈ AdGuard Home
⧖ up 5 days, 15 hours, 31 minutes
---
sij-fin
🇫🇮 65.21.99.202
⋈ Standard DNS
⧖ up 1 week, 21 hours, 17 minutesThe line with the flag emoji and public IP under each server is clickable—SwiftBar hides a | bash=/tmp/swiftbar_vpn_123.sh tag linked to temp scripts that'll run a server’s vpn shh .
So, say I spot ⠙ mid-work—my NAS's VPN connection has dropped. Click the dropdown IP and it’s back on a trusted Finnish node—no terminal dance, no fuss.
Setup
Install SwiftBar, populate ~/.servers.yaml (see repo example). SSH needs to work—keys or passwords.
Why I Run Them
These are hacky fixes that stuck and earned a place in my system PATH. vpn owns my traffic—2025’s political climate keeps it non-negotiable when handling anything confidential. vitals cuts through bullshit with raw data. vitals monitor brings it to the top of my screen—suitably minimalist for macOS, sufficiently cryptic to shrug off prying eyes, just enough to know what's up. Light, PATH-ready, no GUI bloat.
Get Them
Grab vpn and vitals at sij.ai/sij/pathScripts, vitals monitor at sij.ai/sij/SwiftBar. They evolve there—check for updates. Tinker, break, fix—and ping me at @sij:we2.ee with rants or results.
Getting Clever with Caddy and Conduwuit / Matrix
A deep dive into We2.ee's Caddy configuration, handling Matrix federation, offering profile and room redirection shortlinks, and combining multiple services on a single domain.
My post earlier this evening discussed generally how Caddy has made self-hosting multiple web services a breeze. Here I want to build on that and look specifically at the Caddy configuration I use for We2.ee, the public Matrix homeserver I run and have posted about already.
The complete Caddyfile entry is available here. Let's look closer at a few key sections. First, you'll see a series of redirection handlers like this:
handle /about {
redir https://sij.law/we2ee/ permanent
}This one simply redirects we2.ee/about to sij.law/we2ee . This allows me to create authoritative "About" URL on the we2.ee domain but host the actual page here on my blog – saving me having to host a whole separate CMS just for We2.ee, and potentially lending credibility to We2.ee through my professional online presence here.
Next, you'll see some more redirection handlers that rely on regular expressions ("regex"):
# Handle Matrix-style room redirects
@matrix_local_room {
path_regexp ^/@@([^:]+)$
}
redir @matrix_local_room https://matrix.to/#/%23{re.1}:we2.ee permanent
# Handle Matrix-style room redirects with custom domains
@matrix_remote_room {
path_regexp ^/@@([^:]+):([^/]+)$
}
redir @matrix_remote_room https://matrix.to/#/%23{re.1}:{re.2} permanent
# Handle Matrix-style user redirects
@matrix_local_user {
path_regexp ^/@([^:]+)$
}
redir @matrix_local_user https://matrix.to/#/@{re.1}:we2.ee permanent
# Handle Matrix-style user redirects with custom domains
@matrix_remote_user {
path_regexp ^/@([^:]+):([^/]+)$
}
redir @matrix_remote_user https://matrix.to/#/@{re.1}:{re.2} permanentThese are particularly efficient—they allow for much shorter links for Matrix rooms and user profiles that redirect to the Matrix.to service. For example:
- we2.ee/@sij redirects to
matrix.to/#/@sij:we2.ee(saving 12 characters) - we2.ee/@sangye:matrix.org redirects to
matrix.to/#/@sangye:matrix.org(saving 5 characters) - we2.ee/@@pub redirects to
matrix.to/#/#pub:we2.ee(saving 11 characters) - we2.ee/@@matrix:matrix.org redirects to
matrix.to/#/#matrix:matrix.org(saving 4 characters)
Next you'll see the handlers for the actual underlying services, Conduwuit and Element:
# Handle Conduwuit homeserver
handle /_matrix/* {
reverse_proxy localhost:8448
}
# Handle federation
handle /.well-known/matrix/server {
header Access-Control-Allow-Origin "*"
header Content-Type "application/json"
respond `{"m.server": "we2.ee"}`
}
# Handle client discovery
handle /.well-known/matrix/client {
header Access-Control-Allow-Origin "*"
header Content-Type "application/json"
respond `{
"m.homeserver": {"base_url": "https://we2.ee"},
"org.matrix.msc3575.proxy": {"url": "https://we2.ee"}
}`
}
# Handle MSC1929 Admin Contact Information
handle /.well-known/matrix/support {
header Access-Control-Allow-Origin "*"
header Content-Type "application/json"
respond `{
"contacts": [
{
"matrix_id": "@sij:we2.ee",
"email_address": "[email protected]",
"role": "m.role.admin"
}
],
"support_page": "https://we2.ee/about"
}`
}
# Handle Element webUI
handle {
reverse_proxy localhost:8637
}This part of the Caddy configuration block:
- serves up the actual Matrix homeserver (powered by conduwuit) at We2.ee
- provides the necessary endpoints for federation
- provides the MSC1929 endpoint for handling abuse reports, etc.
- serves up an Element web interface for accessing the Matrix homeserver directly at We2.ee
I hope some of this is useful for folks running their own Matrix homeservers or anyone interested in seeing how Caddy configurations can be structured for more complex setups.
Simplifying Web Services with Caddy
Running multiple web services doesn't have to be complicated. Here's how Caddy makes it simple by handling reverse proxying and HTTPS certificates automatically, plus a script I use to set up new services with a single command.
After my recent posts about We2.ee, Lone.Earth, Earth.Law and that pump calculator project, several folks asked about managing multiple websites without it becoming a huge time sink. The secret isn't complicated—it's a neat tool called Caddy that handles most of the tedious parts automatically.
Understanding Reverse Proxies
Traditionally, web servers were designed with a simple model: one server running a single service on ports 80 (HTTP) and—more recently as infosec awareness increased—443 (HTTPS). This made sense when most organizations ran just one website or application per server. The web server would directly handle incoming requests and serve the content.
But this model doesn't work well for self-hosting. Most of us want to run multiple services on a single machine - maybe a blog like this, a chat service like We2.ee, and a few microservices like that pump calculator. We can't dedicate an entire server to each service—that would be wasteful and expensive—and we can't run them all on ports 80/443 (only one service can use a port at a time).
This is where reverse proxies come in. They act as a traffic director for your web server. Instead of services competing for ports 80 and 443, each service runs on its own port, and the reverse proxy directs traffic for
- A blog to port 2368
- A Mastodon instance to port 3000
- An uptime tracking service to port 3001
- A code hub to port 3003
- An encrypted chat service to port 8448
- DNS-over-HTTPS filter and resolver on 8502
- A Peertube instance to port 9000
- An LLM API to port 11434
- ... etc.
When someone visits any of your websites, the reverse proxy looks at which domain they're trying to reach and routes them to the right service. That's really all there is to it—it's just routing traffic based on the requested domain.
Why Caddy Makes Life Easier
Caddy is a reverse proxy that manages this well and also happens to take care of one of the biggest headaches in web hosting: HTTPS certificates. Here's what my actual Caddy config looks like for this blog:
sij.law {
reverse_proxy localhost:2368
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
This simple config tells Caddy to:
- Send all traffic for sij.law to the blog running on port 2368
- Automatically get HTTPS certificates from Let's Encrypt
- Renew those certificates before they expire
- Handle all the TLS/SSL security settings
If you've ever dealt with manual certificate management or complex web server configurations, you'll appreciate how much work these few lines are saving.
Making Domain Setup Even Easier
To streamline things further, I wrote a script that automates the whole domain setup process. When I was ready to launch that pump calculator I mentioned in my last post on the open web, I just ran:
cf pumpcalc.sij.ai --port 8901 --ip 100.64.64.11
One command and done—cf creates the DNS record on Cloudflare and points it to the IP of the server running Caddy, creates a Caddy configuration that reverse proxies pumpcalc.sij.ai to port 8901 on my testbench server (which has the Tailscale IP address 100.64.64.11), and handles the HTTPS certification.
If you want to try this script out yourself, see the more detailed documentation at sij.ai/sij/cf, and by all means have a look at the Python code and see how it works under the hood.
Getting Started
- Start by installing Caddy on your server
- Create a config for just one website
- Let Caddy handle your HTTPS certificates
- Add more sites when you're ready
Start small, get comfortable with how it works, and expand when you need to. Ready to dig deeper? The Caddy documentation is excellent, or feel free to reach out with questions.
Thinking Like a Developer, Pt. 1
When our backup pump failed on the homestead, I built a calculator to figure out what we really needed. It’s a small, open-source tool born from necessity and a few iterations with self-hosted AI.
I live on a homestead in southern Oregon, surrounded by the vastness of the Umpqua National Forest in every direction. It’s the kind of place where nature dictates the rhythm of life. We rely on a natural mountain spring for water most days, but when that fails (as nature sometimes does), we turn to a small stream or a mile-long ditch. According to local lore, some intrepid homesteader dug that ditch in the early 1900s to water a single cow.
These water sources connect to a network of pipes, backup pumps, and an unoptimized system that could generously be described as "inventive." When our pump failed recently, we faced an immediate and critical question: how powerful does a replacement pump need to be?
From Problem to Solution
To answer that question, I did what any coder-lawyer-homesteader would do—I wrote a script. Specifically, a pump power calculator that factors in pipe diameter, distance, flow rate, pipe material, and other inputs to calculate the horsepower needed for a given setup. It factors in key considerations like friction head loss, flow velocity, and static head, ultimately providing recommendations with a built-in safety margin. For example, in our setup, with a 4000-foot run of 1" pipe that rises up around 120 feet and delivers around 7.5 gallons per minute, it calculated we needed at least 0.75 HP—but 1 HP if we want a 30% safety margin.
You can try it out for yourself at pumpcalc.sij.ai or embedded at the bottom of this post, and if you’re curious about the code, it’s open source at sij.ai/sij/pumpcalc. I built the calculator in Python using FastAPI for the backend and Jinja2 for templating—simple, reliable tools that get the job done without unnecessary complexity.
This wasn’t a solo endeavor. I leaned on the open-source AI tool Ollama and specifically QwQ, a powerful 32 billion parameter research model that rivals leading commercial AI systems like ChatGPT o1 in reasoning capabilities. QwQ particularly excels at technical problem-solving and mathematical tasks, making it perfect for engineering calculations like this.
The Iterative Process of Coding
Developing this script wasn’t a one-and-done affair. It took five back-and-forth sessions with the AI to:
- Factor in relevant variables like pipe roughness and flow rate.
- Exclude unnecessary inputs that made the interface clunky.
- Add some polish, like the Gruvbox Dark color scheme that now graces the app.
Each iteration made the calculator more useful and user-friendly. By the end, I had something functional, simple, and—dare I say—elegant.
Why Share This?
I’m sharing this as the first in a series of "Thinking Like a Developer" stories, because I believe coding isn’t as mystifying as it might seem. If a lawyer on a homestead with a temperamental water system can write a pump calculator, anyone can. The key is thinking like a developer: break the problem into smaller, solvable pieces, and don’t be afraid to consult tools or collaborators along the way.
This approach to problem-solving—breaking down complex challenges and leveraging coding tools—mirrors how I approach legal technology challenges. I frequently rely on Python and AI libraries to streamline legal work, from document analysis to case law research. Whether it's calculating pump requirements or processing legal documents, the fundamental thinking process remains the same. Who knows? You might find your next project hidden in a problem you didn’t even know you wanted to solve.
The productivity software landscape in 2025 is dominated by a paradox. We have more tools than ever promising to revolutionize how we work, yet finding software that simply works well for critical tasks remains surprisingly difficult. The market is flooded with VC-backed "all-in-one" solutions that promise to be your second brain, your AI assistant, your project manager, and your content creator – all while syncing seamlessly to the cloud and integrating with every workflow imaginable.
These tools seduce us with impressive feature lists. AI integration! Real-time collaboration! Infinite workspaces! Knowledge graphs! The marketing is slick, the interfaces are polished, and the promises are grand. Who wouldn't want a single tool that does everything? The problem is that these solutions often fail precisely when we need them most – during crunch time on a legal brief, in the middle of a research deep-dive, or when racing against a deadline with spotty internet access.
This disconnect between marketing hype and daily reality calls for a fundamental reassessment of how we evaluate productivity software. Instead of asking "What can this tool do?", we need to ask harder questions: Will this tool reliably perform its core function when I'm under pressure? Do I actually own and control my data? Does it respect my operating system's conventions and capabilities? Does it solve real problems, or just create the illusion of productivity?
The answers to these questions often lead us away from the latest all-in-one wonders and toward more focused, thoughtfully designed tools that excel at specific tasks. This isn't about being a luddite or refusing innovation – it's about demanding software that genuinely serves our needs rather than VC growth metrics.
Let's explore what actually matters in productivity software, and why the boring fundamentals often beat exciting promises.
Core Principles for Evaluating Tools
Reliability as Non-Negotiable
Software reliability is like oxygen – you only notice it when it's gone. Nothing destroys trust faster than an app crashing while you're finalizing a court filing, losing your research notes before a deadline, or failing to sync just when you need to reference something on your phone. The psychological cost is real: once software has failed you at a critical moment, you'll forever question whether you can trust it again.
The hidden costs of unreliable software extend far beyond the immediate frustration. You start developing defensive workflows – keeping backup copies, taking extra screenshots, manually exporting more often than you should need to. Your cognitive load increases as you constantly wonder if your work is really saved. You spend time researching alternatives instead of focusing on your actual work. This accumulated friction and anxiety exact a toll on both productivity and peace of mind.
Sometimes, boring is better. OmniOutliner's interface might not win any design awards in 2025, but it has never once lost my work in a decade of writing legal briefs and academic papers. Things' feature set is intentionally constrained, but its rock-solid reliability means I never question whether my tasks are actually captured. These tools prove that reliability isn't just about not crashing – it's about consistently delivering on core promises.
Data Sovereignty
The foundation of any serious productivity tool should be local-first architecture. Your data – your thoughts, research, and work product – should exist first and foremost on your own devices. This isn't just philosophical; it's practical. Local-first means your tools work at full speed regardless of internet connectivity. It means your data isn't held hostage to someone else's servers or business model.
Sync should enhance your workflow, not be a requirement for it. Tools like DEVONthink and Anytype get this right: powerful local functionality with sync as an optional layer. Contrast this with Notion, where even viewing your own notes requires an internet connection. When sync is mandatory, you're not just trusting a company's current practices – you're betting on their long-term viability and ethical behavior.
The risks of closed ecosystems become apparent over time. Companies get acquired, pivot their business models, or shut down entirely. Proprietary formats and cloud-only storage create golden handcuffs – the more you invest in the system, the harder it becomes to leave. This is why robust export capabilities aren't a nice-to-have feature; they're a fundamental right. Your data should be portable, in standard formats, without requiring paid subscriptions or special tools.
Platform Integration
Real macOS optimization goes far beyond a native-looking interface. It's about respecting platform conventions and leveraging system capabilities. Things integrates with macOS Quick Entry and Shortcuts. DEVONthink leverages Spotlight and Services. Hook enables deep linking between native apps. These integrations create workflows that feel natural and efficient.
The proliferation of Electron-based apps has normalized subpar performance and platform-agnostic design. While cross-platform compatibility has its place, tools that fully embrace macOS capabilities offer a fundamentally better experience. Native apps launch faster, use less memory, and respond more smoothly. They support system-wide features like Services, Quick Look, and native window management without awkward workarounds.
System integration points matter because they reduce friction. Universal keyboard shortcuts that work as expected. Services menu integration for quick actions. Proper handling of macOS document states and window management. These details might seem minor in isolation, but they compound into a significantly better user experience.
The performance implications of platform optimization extend beyond raw speed. Native apps tend to be more energy-efficient, crucial for mobile work. They handle system transitions (sleep/wake, network changes) more gracefully. They scale better with larger datasets because they can leverage system capabilities more effectively. When you're dealing with thousands of notes or documents, these optimizations make a real difference in daily use.
The AI Integration Problem
The current wave of AI integration in productivity software often feels more like a game of follow-the-leader than thoughtful feature development. Nearly every app now advertises some form of AI capability, but peek under the hood and you'll find the same OpenAI API calls wrapped in increasingly thin veneers of differentiation.
The OpenAI API Trap
The privacy implications of casual AI integration are staggering. When your note-taking app proudly announces AI features, what they're often really saying is "we're going to send your personal notes, research, and thoughts to OpenAI's servers." For professionals dealing with confidential information – lawyers, researchers, healthcare providers – this creates serious ethical and legal concerns. Even for personal use, do you really want your private journals and notes being used to train third-party AI models?
The cost dependency is equally problematic. Apps that rely on OpenAI's API are essentially reselling compute time with a markup. As these features move from novelty to expected functionality, the costs compound. You're not just paying for your productivity app's subscription – you're indirectly funding their API usage. When OpenAI changes their pricing (which they have, repeatedly), your app's economics change too.
The quality of results from generic AI integration often disappoints. Cookie-cutter implementations of ChatGPT might be good at generating bland summaries or generic suggestions, but they lack the context and specificity that make AI truly useful for productivity work. It's the difference between having a general-purpose chatbot and having AI that actually understands your personal knowledge base and workflow.
Examples of Thoughtful AI Integration
DEVONthink's approach to AI stands in sharp contrast to the current trend. Long before the ChatGPT boom, they developed native machine learning capabilities that run locally on your device. Their AI focuses on specific, valuable tasks: classifying documents, finding relationships between files, suggesting locations for new content. It's AI that serves a purpose rather than chasing a trend.
Noted's integration of Whisper for local audio transcription is another example of AI done right. By running the model locally, they maintain privacy while delivering genuine utility – accurate transcription with timestamp linking that enhances the core note-taking experience. The key is that the AI serves the app's primary purpose rather than existing as a separate feature.
When AI Adds Value vs. Checkbox Features
The distinction between valuable AI integration and checkbox features comes down to three key questions:
- Does it enhance the core functionality of the app, or is it bolted on?
- Does it respect user privacy and data sovereignty?
- Does it solve a specific problem better than non-AI alternatives?
Valuable AI integration looks like DEVONthink's document classification – it makes the core experience better. It looks like Noted's transcription – it solves a specific problem elegantly. Checkbox features look like generic "AI assistants" that merely repackage ChatGPT, or "smart" features that add complexity without corresponding value.
The future of AI in productivity software isn't about having the most AI features – it's about having the right ones, implemented thoughtfully and ethically. As users, we should demand AI integration that respects our privacy, serves genuine needs, and enhances rather than complicates our workflows.
The Case for Specialized Tools
The allure of an all-in-one solution is understandable. The idea of having your entire productivity system in one place sounds efficient. But in practice, tools that try to do everything often end up doing nothing particularly well. The "everything app" becomes the "almost anything, sort of" app.
Why "Do Everything" Often Means "Do Nothing Well"
When apps try to be everything to everyone, they inevitably make compromises. Task management gets buried under a mountain of features. Note-taking becomes cluttered with unnecessary options. Document management becomes an afterthought. The interface grows increasingly complex as features compete for limited screen real estate. What starts as an attempt at simplification through consolidation often ends in cognitive overhead and decreased efficiency.
Success Stories of Focused Applications
Things: Task Management Done Right
Things succeeds precisely because it knows what it isn't. It's not a note-taking app. It's not a calendar. It's not trying to be your second brain. It is, simply and excellently, a task manager. Its design choices reflect this focus: quick entry that never gets in your way, keyboard shortcuts that become muscle memory, and an interface that clarifies rather than complicates. By embracing constraints, Things delivers an experience that feels both powerful and effortless.
DEVONthink: Document Management Mastery
DEVONthink exemplifies the power of doing one thing exceptionally well. It's a document management powerhouse that understands its role in your workflow. Its AI features serve document organization and discovery, not generic chat. Its search capabilities are tuned specifically for document management. Even its interface, while complex, is complex in service of its core purpose. Every feature exists to help you manage, find, and use your documents more effectively.
OmniOutliner: The Power of Purpose-Built Tools
OmniOutliner's focused approach to structured writing and outlining demonstrates why specialized tools endure. It doesn't try to be a full word processor or a note-taking app. Instead, it provides precisely the features needed for serious outlining work: robust keyboard controls, flexible organization, powerful styling options, and rock-solid stability. When you need to outline a legal brief or structure a complex document, its purposeful design proves invaluable.
Integration Between Specialized Tools
The real magic happens when specialized tools work together. Rather than forcing everything into one application, modern workflows can leverage the strengths of multiple focused tools through thoughtful integration.
The Power of Hooks and Automation
Tools like Hook demonstrate how specialized apps can form a cohesive system. By creating bidirectional links between items in different apps – a task in Things, a research document in DEVONthink, an outline in OmniOutliner – Hook lets each app excel at its core function while maintaining connections across your workflow. These connections don't require apps to build complex features outside their expertise; they just need to be good citizens in the larger ecosystem.
Building Workflows Across Apps
The most effective productivity systems often resemble a well-designed toolkit rather than a Swiss Army knife. A task in Things might link to research in DEVONthink, which informs an outline in OmniOutliner, which eventually becomes a draft in Ulysses. Each transition leverages apps' native capabilities – URL schemes, automation support, export options – to create workflows that are both powerful and reliable.
This approach to integration preserves what makes each tool special while creating a whole greater than the sum of its parts. Instead of compromising to fit everything into one app, we can build workflows that use the right tool for each job, connected thoughtfully where it matters.
The Real Cost of "Free" and Cheap Tools
If there's one constant in productivity software, it's that nothing is truly free. When a tool – especially a VC-backed one – offers extensive features at no cost, you're not the customer; you're the product. The real costs of "free" and cheap tools often emerge only after you've invested significant time and data into them.
Lock-in Strategies
The playbook is depressingly familiar: Offer a generous free tier to build dependency, create friction around data export, then gradually restrict features behind paywalls or premium tiers. Notion exemplifies this strategy – it's easy to pour your life into it, but extracting your data in a usable form becomes increasingly difficult as your usage grows. The more you invest in these systems, the higher your switching costs become.
What starts as "free" becomes expensive not in dollars, but in flexibility and control. Your workflows adapt to the tool's limitations. Your data structure conforms to its models. Your team processes build around its constraints. By the time the limitations become painful, extraction costs – in time, effort, and potential data loss – feel prohibitive.
Data Portability Concerns
True data portability goes beyond the ability to export to PDF or download a JSON dump. It means getting your data out in formats you can actually use elsewhere. Compare DEVONthink's extensive export options and standard file formats with Notion's limited export capabilities. One treats your data as yours; the other treats it as theirs.
The most insidious portability issues often surface only when you try to leave. Markdown files that aren't really markdown. Relationships between items that don't survive export. Metadata that vanishes during transfer. These aren't technical limitations – they're business decisions designed to increase retention through friction.
Subscription Models and Sustainability
Not all subscriptions are evil. Teams building quality software need sustainable revenue to continue development and support. The issue isn't paying for software – it's the value proposition and the terms of the relationship.
Setapp offers an interesting counter-model: access to high-quality apps like Ulysses, Hookmark, and many others for a single subscription. The key difference is that these are mature, focused tools with clear value propositions, not platforms trying to own your entire workflow.
The Value Proposition of Quality Software
Quality software justifies its cost through reliability, thoughtful design, and respect for your data and workflows. Things isn't cheap, but its reliability means never losing a task. DEVONthink's price reflects its power as a research tool. OmniOutliner's cost is trivial compared to the value it provides for serious writing and planning work.
The real value proposition extends beyond features:
- Time saved through reliability and efficiency
- Peace of mind from knowing your data is yours
- Professional support when you need it
- Sustainable development ensuring longevity
- Respect for platform conventions and capabilities
When evaluating software costs, the question shouldn't be "What's the cheapest option?" but rather "What's the true cost of depending on this tool?" Often, paying for quality software costs less in the long run than dealing with the hidden costs of "free" alternatives.
Building a Sustainable Productivity Stack
Building a productivity system that lasts requires thinking beyond feature lists and current trends. It demands careful consideration of your core workflows, the reliability of your tools, and the long-term viability of your choices.
Evaluating Core Needs
Start by identifying your non-negotiables. What tasks truly matter in your daily work? Where do current tools create friction? What data absolutely must remain under your control? This evaluation often reveals that you need fewer tools than you think, but those tools need to be more robust than you might have assumed.
A sustainable stack typically includes:
- A rock-solid task manager (like Things)
- A reliable document management system (like DEVONthink)
- Purpose-built tools for specific workflows (like OmniOutliner for structured writing)
- Thoughtful connections between these tools (via Hook or automation)
Investing in Reliability
Reliability isn't just about software not crashing – it's about consistency in your workflow. This means:
- Tools that work offline first
- Data that lives on your devices
- Sync that enhances rather than constrains
- Export options that respect your ownership
- Performance that scales with your needs
Planning for Longevity
Consider the long-term viability of your tools. Look for:
- Companies with sustainable business models
- Software with clear development roadmaps
- Tools that use standard formats where possible
- Apps that respect platform conventions
- Solutions that can grow with your needs
The Role of Community and Development Approach
A healthy community and transparent development process often indicate a tool's long-term prospects. But "community" doesn't always mean what you think. Obsidian's vast plugin ecosystem might seem attractive, but DEVONthink's years of focused development and professional support often provide more real-world value.
A Call for Better Standards
What Users Should Demand
We need to raise our standards for productivity software:
- True ownership of our data
- Local-first architecture with optional sync
- Clear data export paths
- Native performance and integration
- Sustainable business models that align with user interests
- Privacy-respecting features, especially around AI
- Transparent pricing without lock-in
What Developers Should Prioritize
Developers need to shift focus from feature bloat to fundamentals:
- Rock-solid reliability
- Thoughtful platform integration
- Standard formats and protocols
- Clear data portability
- Sustainable revenue models that don't compromise user interests
- Ethical AI implementation
- Performance at scale
The Future of Productivity Software
The future of productivity software isn't about finding the perfect all-in-one solution. It's about building sustainable systems from focused, reliable tools that respect our needs, our data, and our workflows.
We need to move beyond the cycle of VC-backed hype and return to fundamentals: tools that do one thing exceptionally well, respect their users, and stand the test of time. This might mean paying more upfront for quality software, but the alternative – entrusting our work and data to unsustainable "free" solutions – ultimately costs more.
The tools we use shape how we work, think, and create. It's time to demand better. Not more features, not more AI, not more promises – just better, more reliable, more respectful software that helps us do our best work.
Let's vote with our wallets and our attention for the kind of productivity software we actually need, not just what's currently trending on Product Hunt.