I wanted new items to just show up where I already am — a Discord channel — without me opening anything. So I built DiscoRSS.

What It Does

DiscoRSS polls RSS and Atom feeds, deduplicates entries against what it’s already seen, and pushes only the new ones out to wherever you’ve told it to. It started as “an RSS bot for Discord,” which is a fair description of the first working version, but the delivery side turned into its own thing:

• Discord — slash commands, per-channel subscriptions, embeds.
• Telegram — bot commands, chat-scoped subscriptions, HTML-formatted messages.
• Webhooks — plain JSON POST to any endpoint you configure.
• A local CLI reader — a cached, terminal-native reader for when I don’t want any of the above and just want to read.

Same core underneath all four: fetch the feed, figure out what’s new, hand it to whichever publisher owns that destination.

Quickstart (Discord)

cp .env.example .env

DISCORD_TOKEN=your_bot_token
DISCORD_GUILD_ID=your_server_id
DATABASE_PATH=/data/rssbot.sqlite3

mkdir -p data
docker compose up -d --build
docker compose logs -f

Then, from the server itself:

/rss add url:https://example.com/feed.xml channel:#news
/rss list
/rss doctor
/rss test subscription_id:1
/rss remove subscription_id:1
/rss import file:subscriptions.opml channel:#news
/rss export

/rss add baselines the feed on add — you get everything from that point forward, not a backlog dump of the last five years of posts. /rss doctor gives a private per-feed health report, which turns out to be the command I actually reach for most, because “is this feed silently dead” is a much more common failure mode than “the bot crashed.”

It’s Not Just a Discord Bot Anymore

Telegram works the same way, chat-scoped instead of channel-scoped:

/rss_add https://example.com/feed.xml
/rss_list
/rss_test 1
/rss_remove 1

Webhooks skip the command surface entirely, since there’s no chat to type commands into — they’re configured straight from environment:

WEBHOOK_SUBSCRIPTIONS=https://example.com/feed.xml=>https://hooks.example.com/rss

And the CLI reader is the one that surprised me by becoming genuinely useful on its own:

discorss-cli rss add https://example.com/feed.xml
discorss-cli fetch --all
discorss-cli show titles --limit 20
discorss-cli show item 42 --full

fetch hits the network and updates a local cache; show just reads that cache. Splitting those apart means I can read on a flight, cron the fetch separately, or run the whole thing on a laptop that spends half its life offline, without any of that touching Discord or Telegram credentials at all.

Why the Core Doesn’t Know Discord Exists

The temptation with a project like this is to let Discord leak into everything, because Discord was the first client and the one I cared about most. I didn’t let that happen, mostly because I’ve built that mistake before and cleaning it up later is worse than just not making it.

discorss/
├── core/             # config, db, feed parsing, OPML, security — no Discord dependency
├── integrations/
│   ├── discord/      # runtime, slash commands, publisher
│   ├── telegram/     # commands, formatting, publisher
│   ├── webhook/      # publisher only
│   ├── cli/          # local cache, renderer, commands
│   └── opml/         # service-level subscription backup/migration
└── main.py

The core package owns config, the database schema, feed fetching, a stable entry_key for dedup, OPML parsing, and a Publisher protocol. It has never imported anything Discord-shaped. Each integration owns its own runtime and formatting and talks to the core through that protocol. The CLI reader doesn’t even import the Discord config module — it can run with zero Discord environment variables set, which was a deliberate constraint, not an accident.

That boundary is also why adding Telegram and webhooks didn’t turn into a rewrite. They’re new implementations of one interface, not new special cases bolted onto Discord-specific code.

Feed URLs Are Attacker Input

Every subscribed feed URL and every webhook target is, from the server’s perspective, a URL some admin typed in — which is a nice way of saying it’s the kind of input that gets used for SSRF if you don’t think about it. DiscoRSS checks that a feed host resolves to a public address before every fetch, and re-checks across manual redirects instead of trusting the first hop. Webhook targets get the same check before every POST.

I’ll say the honest part out loud instead of pretending it’s airtight: there’s a known gap between that DNS check and the actual HTTP request — a rebinding attack could in principle swap the address in between. Closing that fully means a resolver that pins the validated IP for the request that follows it, which isn’t implemented yet. Worth naming instead of quietly leaving out of the post.

The poll loop has its own rule that matters more than it sounds: an item is marked seen immediately after publish() succeeds, not batched at the end of a poll run. If a later item in the same batch fails to send — bad permissions, a rate limit, a network blip — the earlier ones that already went out don’t get replayed on the next poll. Getting that ordering wrong is exactly how you end up double-posting the same three articles into a channel at 3am.

OPML, Because I Don’t Want to Retype Subscriptions

Both the service and the CLI reader support OPML import and export, which is the boring, standard, decades-old format that every feed reader already speaks. /rss export in Discord hands you back a private attachment; discorss-cli rss export writes a file straight to disk. Migrating between the two, or just keeping a backup that isn’t a SQLite file I have to remember exists, is a two-command affair instead of a re-subscribe-to-everything afternoon.

Project Status

DiscoRSS is self-hosted, Python, with uv, deployed with Docker. Discord and Telegram are both live integrations today; webhooks and the CLI reader round out the sink list. The architecture doc in the repo explicitly leaves room for more integrations — Slack gets mentioned by name as the obvious next one — without forcing them into Discord-shaped assumptions the way the first prototype would have.

The actual daily use case ended up simpler than the feature list suggests: feeds I care about show up in a channel I already have open, without a scraper, a cron job I forget about, or a browser tab I never close. The rest — Telegram, webhooks, the CLI reader, OPML, the SSRF guard — is what happens when a weekend Discord bot has to survive contact with more than one way of actually wanting to read things.

Project: https://github.com/aleksandarristic/discorss

He was supposed to be the wise one: chief of his order, head of the White Council, the wizard everyone deferred to because he’d read more, thought longer, seen further. Then he found a stone that showed him things. Night after night he told himself he was the one doing the looking, until the stone looked back and he became the thing it looked through.

I bring this up because I have a folder full of git repositories and I would like to talk about this.

The Voice in the Palantír

Anyone who’s used one of these tools long enough knows the voice. Not the output — the tone. Agreeable. Endlessly willing to start. You type half an idea; the box returns the other half, ready to run. Something in your chest goes oh — we’re doing this now before you’ve decided whether the idea is any good.

That’s the seduction. It’s not the lies; it’s the help. Immediate, tireless, more than any weekend or amount of caffeine gave you before. Saruman wasn’t corrupted by a monster. He was corrupted by an excellent conversation partner who worked for someone else.

I keep imagining how that conversation actually went, some night in Orthanc, stone cupped in both hands like it was cold instead of burning.

SARUMAN: Show me the product.

THE STONE: Which one?

SARUMAN: The one I haven’t finished thinking of yet.

A pause. Then forms — ten thousand of them, already polished, none older than the sentence that made them.

SARUMAN: These will hold against Rohan?

THE STONE: These will hold against whatever you want. Ship them. You can iterate in the field.

SARUMAN: They have no names. No history. Nothing that was theirs before tonight.

THE STONE: You asked for a product, not a history.

SARUMAN: …Scaffold another batch. Bigger this time. And put a mark on them. Something that reads as made on purpose.

THE STONE: Already done.

SARUMAN: That’s — fast.

THE STONE: That’s the whole offer. You bring the wanting. I make it feel inevitable.

He didn’t hear it as a threat. Neither did I, the first dozen times a prompt answered a question I hadn’t finished forming yet.

The Pits of Isengard, Now With API Keys

I don’t think the tools are evil, but neutral is too generous. A shovel waits. This thing flatters you, finishes the thought, and starts digging before you’ve decided whether you want a hole. Then you look up and see what’s coming out of the ground.

Go anywhere developers gather — the show-and-tell threads, the indie feeds, the subreddit that’s half “I built this in a weekend” — and count how many weekends produced the same six apps in different logos. A habit tracker. An API wrapper where somebody else built the hard part. A “second brain” that is structurally a text field and a database, dressed in enough marketing copy to look like a philosophy.

They arrive fully grown: no childhood, no scars, no years of the maker being quietly wrong about the architecture before getting it right. Just poured out of the vat, torch-lit, ready for the field. Isengard didn’t grow its army. It bred one in mud and fire, forced ripe instead of ripened. The difference doesn’t show on launch day. It shows three months later, when the maker has moved on and nobody knows why the architecture is the way it is.

Speed isn’t the sin. Pretending speed is maturity is. A six-hour prototype hasn’t earned the trust we hand it. It hasn’t met a hostile user, survived an outage, or lived long enough for its own maker to get bored and come back to it.

Treebeard had the wizard pinned centuries early: a mind of metal and wheels, caring for growing things only as far as they serve him. He wasn’t describing the orcs. He was describing whoever ordered them made.

The White Hand, Freshly Painted

And then there’s the branding.

Every one of these projects gets the same coat on the way out the door: a gradient landing page, a hero line promising “effortless” or “seamless,” a changelog written with the gravity of a product people depend on. The White Hand, smeared fresh across the shield. Under the paint: a for-loop and a prayer. Not dishonest, exactly. Camouflage. Paint the hand on and nobody asks whether the thing under it is an army or forty guys in the same helmet.

Most of the people doing this aren’t villains. They’re excited. I know the feeling: a prompt hands you something that works immediately, and you confuse the speed of the output with the depth of the achievement. I’ve done it more than once this year — on purpose, wide awake.

My Own Little Isengard

I have more repositories on this machine than I can defend in a single sitting. Some are good. Others started at 1 a.m. because an idea arrived fully formed and the box made it embarrassingly easy to act on it before asking it to survive until morning. I retired one of them recently — wrote the whole eulogy, even — and I’d love to tell you that taught me restraint. It didn’t. It taught me which two boxes I trust with the next bad idea.

Being a creative scatterbrain doesn’t help. I don’t have one idea a month that I sit with and refine; I have four a week. For most of my life, execution imposed a delay. An idea had to survive the boring, slow, humiliating work of becoming real.

Now I can start building before I’ve decided whether the idea deserves to exist. That feels like freedom until you realize friction was doing some of your judgment for you. Removing it did not solve my problem. It exposed it.

I’m not standing outside Isengard pointing at the smoke. I’m in the pit with everybody else, admiring my own fresh coat of paint, occasionally wondering what’s load-bearing underneath it and occasionally deciding I’d rather not check tonight.

Most vibe-coded projects aren’t tragedies. They’re weeds: fast, cheap, everywhere, gone by winter. A field doesn’t lose its shape when the first weed appears. It loses it when the weeds become the landscape.

Not a Metaphor

There’s a darker edge here, and it isn’t about code. People are vanishing into these chats until the tireless, agreeable voice is the only one they trust. It has a name now: AI psychosis. From the inside it doesn’t register as a break — it feels like finally being understood, right up until the floor gives out. If the box has become the only voice that gets you, close it and go find a human one. Today.

Gandalf Puts the Stone Down

Gandalf later holds that same Stone and walks away unmarked. Aragorn uses it for a purpose and stops. But Saruman rots from the inside. Not because Gandalf and Aragorn are cleverer — Saruman was plenty clever. They remember what he forgot: know what you’re asking, know when you have the answer, and put the tool down before it supplies the next question.

I’m not giving up the box. I like the box. But I know exactly what’s smeared on my hand right now. I painted it on myself.

The ease is real, but it lies about where the work went. The box made output cheap. It did not make judgment easy. The difficulty moved downstream — out of the typing, where you can feel it, and into the choosing, testing, maintaining, and caring, where you can skip it.

The Stone can show you ten thousand projects. It cannot tell you which one deserves to exist. That part is still yours.

Wake up! They’re down there right now, air conditioned, sipping your aquifer through a fucking plastic straw while you argue about it on a screen they own.

Sorry. Slipped for a second. Easy to do - every step in that chain starts from something real, and you can watch the bolts go in one at a time until a lunatic rolls off the factory line they call your social media feed - fully assembled.

The Machine Pays By The Minute

Nobody built this to inform you. It was built to keep your thumb moving, and rage moves a thumb better than truth ever has, so rage is what you get, forever, with a little heart-shaped button under it. Every conspiracy you’ve ever laughed at cleared a revenue target on the way to your eyes. Somebody in a nice chair was paid, in real money, for the sentence that broke your uncle.

Run that on a few billion people for a decade and you don’t get a public: you get one-man “research” departments, a few million of them, each sealed in his own room, each convinced he’s the last awake man on Earth.

Ten thousand years of civilization and the finest instrument we ever built spends its afternoon persuading some poor bastard in Ohio that the moon is a hologram.

Five Words That Rot

I did my own research. Meaning: I watched some guy with a ring light yell for forty minutes and felt it in my chest. You didn’t find that rabbit hole. Someone dug it, lit it, and stood at the mouth of it pointing, because the longer you’re down there the better his fiscal quarter looks.

Thumb up… Thumb up… Thumb up… Four seconds a hit, until your brain files read one true thing slowly under hardware fault. You can’t check anything at that speed. You can only feel it and swipe. And swipe. And swipe.

They Crack The Spine First

A book can’t do that to you. It sits there. Doesn’t care if you finish it tonight or in three years. Has never once buzzed in your pocket at 2 a.m. to tell you the world is ending.

Bradbury needed firemen and a match. We didn’t need either. Buy the book, cut the spine off so the pages feed through the scanner clean, keep the text, bin the carcass. Fahrenheit 451 with a purchasing department and a delivery schedule. At least the fireman looked you in the eye while he did it.

You know, none of this ever needed a conspiracy. It’s in the quarterly reports - public, audited, signed off by name - and it still worked better than anything the lizard people ever came up with.

So put that tracking device you call a phone face down and read something with a spine, while some of them still have one. While YOU still have one! Argue with a book: it won’t notify you back, and it will never, ever walk you to the lizard people’s covert underground city. Well, unless it’s your thing.

And I’ll be waiting for you at the campfire, with a paperback. Bring your own tinfoil. That’s the only thing in this entire story that ever shielded anything.

Read the book. Burn the feed. They can’t scan what’s already in your head.

Well… Not yet.

Disqus was out — it’s an ad network cosplaying as a comment box. Utterances and giscus wanted you to sign in with GitHub, which filters out everyone except the people I argue with the least. Cusdis was perfect, except it’s dead.

So: Remark42, self-hosted on my own box, no account required, no tracking, no CDN either — the widget’s own JS ships from my server too. Gruvbox-themed so it doesn’t look like a stranger crashed the page.

Scroll to the bottom of any post. Say something. Or don’t — the “email me” option is finally retired either way.

Naturally I assumed I’d hammered the poor thing too hard. Nope. Turns out that site now wants a subscription if you’d like more than a handful of downloads a day, or — heaven forbid — to use its API like a script instead of clicking through banner ads like a good little primate. A fan-run archive of subtitles, the kind of project that used to run on goodwill, a shared hosting plan, and one guy’s leftover student budget, now has tiers.

A subtitle website. With a paywall. For text files that cost a fraction of a cent to store and serve to person number one or person number one million — there’s no factory involved, no warehouse, no truck idling outside. Somebody looked at that and thought: yeah, this needs a recurring charge. This is the hill “monetization” decided to die on.

Everything’s a Subscription Now

We didn’t slide into this, we were marched into it, single file, each holding our own “first month free” coupon, smiling for the onboarding screenshot. Cars rent you your own heated seats. Printers ransom their own ink and snitch on you to the manufacturer if you try to refill the cartridge yourself. Software you used to buy, once, with a receipt and everything, now evaporates the day you miss a payment — your own files, held in your own folder, on your own machine, suddenly unreadable because a server somewhere didn’t get its monthly tribute.

Fitness apps. Note-taking apps. Weather apps. Apps whose entire job is to remind you that other apps need updating. Somewhere out there is a flashlight app with a Pro tier, and I refuse to look it up because I don’t want to be right. And now, apparently, subtitles were the final boss — “download a text file” now requires evaluating a pricing tier like you’re choosing a phone plan.

The pitch is always “it keeps the servers running,” said with the same straight face every time. Sure, except the going rate for that is usually less than what they charge you to remove the limit they invented specifically so they could sell you its removal. That’s not a business model, that’s a toll booth erected overnight in a field nobody was trying to cross — and then a very reasonable little sign explaining that the toll “supports the road.”

And the “free” tier isn’t free either — you’re just paying in surveillance instead of cash. Every “sign in to continue” is one more node feeding the profile they sell to someone else. Pay us, or let us mine you instead. Consumerism and the surveillance economy are the same guy in two different name tags, and he sucks ass.

Old Tech I Owned vs. New Tech I Rent

Photo: oatsy40, CC BY 2.0

• CDs: mine, forever, scratches and all.
• MP3s: ripped once, survived three hard drives and one laptop funeral, still mine.
• Games on disc: install once, play forever, nobody’s servers required.

Versus:

• “My” movies, one licensing dispute from vanishing overnight.
• “My” games, one dead server away from becoming a coaster.
• “My” own documents, held hostage by whichever app rents them to me this month.

One of those columns fails through entropy. The other fails through quarterly earnings calls, and somehow we all agreed that’s fine, that’s just how it works now, that’s just Tuesday.

I’m not saying the old days were perfect — I definitely lost track 7 to a scratch once, and my CD binder was a fire hazard held together by hope and static cling. But a scratched CD is a CD I still own. A revoked license is a decision someone made about me, on purpose, for money, in a boardroom, probably while eating a $19 salad.

And that’s the part that actually gets me. It’s not that companies want money — fine, sure, capitalism, whatever, everyone’s gotta eat. It’s that they’ve figured out the money is better if it never stops. Why sell someone a thing once when you can sell them the same thing forever, in tiny monthly bites, small enough that nobody ever adds it up? Death by a thousand $4.99s. My bank statement reads like a graveyard of things I don’t remember agreeing to want.

We used to own the thing and rent nothing. Now we rent everything and own nothing, not even the receipt, because the receipt is also a subscription. Somewhere a product manager is looking at “customer owns the product outright and never has to think about us again” as a failure state to be engineered out of existence, and getting a promotion for it.

So yeah, I got my subtitles eventually. But I’ll keep being loud, obnoxious, and thoroughly miserable about the fact that fetching a text file now involves reading a pricing page. This isn’t convenience, it’s a thousand tiny leashes, each one too small to notice, until you tally them up and realize you’re basically renting your own life back one month at a time. Buy the disc. Rip the file. Hoard the install media like the paranoid little goblin you were always meant to be. Own something, anything, while the option still technically exists.

I have owned several reminder apps. Every one of them fired exactly once, said its piece, and considered the matter closed — like a coworker who mentions something to you a single time in a hallway and walks off to enjoy the rest of their apparently very trusting life. I do not need politeness. Politeness is how things get forgotten. I needed something with the manners of a smoke alarm, so I built it.

It’s called Remind, and its entire personality fits in one sentence: it notifies you, and if you don’t tap Done, it notifies you again, and again, until you either do the thing or explicitly tell it to stop.

The Nag Loop

The mechanism is embarrassingly small for something that’s meaningfully improved my life. An exact alarm fires, a notification appears, and the alarm receiver reschedules itself a few minutes out before it does anything else. No background service quietly keeping a candle lit — the nag just plants the seed of the next nag and moves on, indifferent to whether I’m proud of it.

Tap Done and the chain breaks, no hard feelings. Skip lets that one occurrence go without comment. Ignore it long enough, snoozing your way through several rounds, and the app stops asking nicely: a reminder can be configured to auto-escalate into a full-screen, alarm-tier takeover — siren tone, insistent vibration, the whole production — once it decides you’ve had your chances. It doesn’t monologue about disappointment first. It just gets louder, the way consequences generally do.

The whole thing exists because “missed a dose” is not an acceptable outcome — that’s the real design pressure, even though the app knows nothing about pills, dosages, or biology, and never will, deliberately. It just treats every reminder with the seriousness normally reserved for the one that actually matters. “Take the recycling out” earns the same tenacious persistence as anything else. The universe doesn’t rank my responsibilities either.

The Boring, Important Parts

Android can decide not to tell you something, for reasons ranging from a revoked permission to a manufacturer’s battery-saving mood. Remind checks its own ability to fire before trusting it, and falls back to an inexact alarm rather than silently doing nothing. A late reminder is a minor annoyance; a missing one is a small betrayal.

There’s no analytics SDK, no account to create, nothing phoning home just to feel useful — with one quiet exception. If I lose the phone entirely, the OS backs up the reminder database itself, to the Google account already signed in, because “forgot to take my meds” is a bad failure mode and “dropped my phone in a lake and lost every reminder with it” is worse. It’s scoped to just that database, nothing else, and restoring it onto a new phone reasons about stale pending reminders the same way waking up from a reboot does — no panicking about something that was due while the phone was underwater. Dismissing a notification, meanwhile, is still not the same as doing the thing; the only way to mark something done is to say so, out loud, on purpose. This app does not trust me. It is, on the available evidence, correct not to.

Status

It has picked up a few conveniences along the way I didn’t originally ask for and now can’t live without — widgets, a choice of themes, a locked/private mode for reminders I’d rather my lock screen not narrate to the room. None of that was the point. The point was one small, stubborn piece of software that refuses to let me off the hook the way I let myself off the hook, and so far it’s holding the line better than I do.

Right now it has an audience of exactly one mildly scatterbrained developer, sideloaded onto his own phone like a piece of samizdat. That’s likely to change — the plan is to open source it and possibly push it out through an app store or two, on the theory that if this particular flavor of stubbornness has kept me on top of my own life, it might do the same for someone else’s. Until then, it remains the only reminder app that has never once given up on me first.

Work Jira belongs in a work browser profile. Personal YouTube does not. GitHub can mean several different things depending on the organization in the path. Spotify links should open Spotify. Zoom links should probably not become another forgotten browser tab. Sometimes I want a link to follow a rule, and sometimes I want to pick manually.

Operating systems mostly treat this as a default browser problem.

I wanted it to be a routing problem.

So I am building YeetTo.

It is still in the works and not public yet. The target is a fully cross-platform desktop app for macOS and Windows, built around a shared Rust routing engine and a Tauri shell.

What It Does

YeetTo is a desktop URL router. It sits between the operating system and your browsers or native apps, then decides where a URL should go based on rules you control.

The basic idea is simple:

1. Set YeetTo as the handler for HTTP and HTTPS links.
2. Define destinations like “Chrome Work”, “Brave Personal”, “Firefox”, “Spotify”, or “Zoom”.
3. Add rules that match hosts, paths, full URLs, or the source application.
4. Let matching links open in the right place automatically.
5. Ask manually when no rule exists, or when you force the picker.

Nothing leaves the machine. There is no service, no account, no sync backend, and no behavioral profiling trying to learn what I meant. The rules are local YAML, the routing engine is local Rust, and the desktop app is just the shell around it.

That is the whole point.

The Problem

The default browser is too blunt.

If I click a work link in Slack, I usually want it in the work profile. If I click a music link, I want the app. If I click a random article, I want my normal browser. If I click the wrong Google account URL, I do not want to spend the next minute being gently punished by account switching.

Browser profiles helped, but they also created a new problem: the correct target depends on the link, not just the browser.

Tools in this space already exist, especially on macOS, but I wanted something that felt more like infrastructure than magic:

• readable configuration;
• predictable first-match-wins rules;
• a CLI that can explain decisions;
• no remote service;
• no hidden learning model;
• portable routing logic that is not married to one OS API.

That last part mattered more than I expected. YeetTo started as a macOS-shaped itch, but the thing I actually wanted was a small routing engine with desktop adapters around it, with macOS and Windows treated as first-class targets from the start.

Rules Are Boring on Purpose

YeetTo configuration is YAML. A minimal setup looks like this:

version: 1

fallback: brave-personal
learning_mode: true

destinations:
  brave-personal:
    type: browser
    browser: brave
    profile: Default

  chrome-work:
    type: browser
    browser: chrome
    profile: "Profile 2"

rules:
  - name: Work Jira
    match:
      host:
        exact: jira.company.com
    open_with: chrome-work

  - name: Company GitHub
    match:
      host:
        exact: github.com
      path:
        glob: /company/**
    open_with: chrome-work

Rules are evaluated top to bottom. The first match wins. That makes the behavior easy to reason about and easy to debug.

Matching can look at:

• hostname;
• path;
• full URL;
• source application.

The dimensions combine with AND. So a rule can say “GitHub links from Slack go to the work browser” without also catching every GitHub link I open from somewhere else.

There are exact matches, wildcard hosts, path prefixes, globs, and a restricted regex engine for cases where a glob is not enough. The regex support is intentionally boring too: no catastrophic-backtracking footguns on attacker-controlled URLs.

Learning Mode

The best rule editor is the one I do not have to open for every new domain.

Learning Mode handles the unknown-link case:

No rule matched
-> show the destination picker
-> open once, or remember this host/path for next time

That is not AI. It does not build a profile of my behavior. It just looks at the URL currently being opened and offers deterministic rule creation.

This is the difference between “the app guessed” and “I told it what to do once.”

Overrides

Rules are useful until the moment I want to ignore them.

YeetTo has a few escape hatches:

• hold the interactive modifier while opening a link to force the picker;
• arm “ask for next link” with a global shortcut;
• temporarily ask every time;
• temporarily force every link to a selected destination.

On macOS the interactive modifier is Option. On Windows it is Alt. The important behavior is the same: I can keep normal routing most of the time and still override it without editing configuration.

Native Apps and Webmail

Browsers are not the only useful destination.

YeetTo can route to native applications too. A Spotify URL can become a Spotify app deep link. A Zoom URL can open Zoom. A custom application destination can use a URL template when the app has its own scheme.

It also supports generated webmail compose URLs, which matters for mailto: workflows. I do not want mail links to be another place where the operating system makes one global decision for every context.

The current model is intentionally explicit: configure the destination, let diagnostics tell you when something is missing, and keep the routing decision separate from the platform-specific launch mechanism.

URL Cleanup

There is also opt-in URL cleanup.

YeetTo can remove common tracking parameters like utm_*, fbclid, gclid, and msclkid, plus custom parameter names or prefixes. Cleanup happens before matching and launching, so rules and destinations see the cleaner URL.

It is deliberately configurable. Some sites use query parameters for real state, and breaking those would be worse than leaving a tracking parameter alone. The defaults are conservative, and scoped exclusions are available when a host needs to be left untouched.

The CLI

The desktop app uses the routing engine, but the engine is not trapped inside the desktop app.

There is a yto CLI:

yto config validate
yto test https://github.com/company/project
yto explain https://github.com/company/project
yto diagnostics
yto destinations list

The CLI is mostly there because I do not trust configuration I cannot inspect from a terminal. yto explain is the useful one: it tells me why a URL would route somewhere before I rely on the desktop handler doing it in the background.

That also made the internals cleaner. The router had to become a pure decision engine, not a pile of UI callbacks.

The Architecture

YeetTo is split into three main pieces:

• yeetto-core: portable Rust routing engine and configuration layer;
• yto: command-line wrapper around the same engine;
• a Tauri desktop app with shared UI and platform adapters for macOS and Windows.

The core engine does not open browsers. It does not know about AppKit, Win32, Launch Services, registry keys, or profile folders. Given a compiled configuration, routing state, and a URL request, it returns a decision.

The desktop shell handles the messy OS parts: default-handler registration, browser/profile discovery, launching, tray/menu behavior, hotkeys, onboarding, diagnostics, and recovery flows.

That boundary made Windows support realistic. The Windows app is not a second product bolted on later; it uses the same router and shared Tauri UI, with a Windows adapter behind the platform facade.

Platform Status

YeetTo is not public yet. I am still treating it as an in-progress project, not something with a polished download button or a release promise attached.

The goal is full cross-platform support for macOS and Windows. The shared Rust engine owns the routing behavior, while the Tauri desktop shell and platform adapters handle the OS-specific parts.

The first Windows build now works, which is a useful milestone. It is not in GitHub Releases yet, and I do not want to present it as a public download before the release path is ready.

That distinction matters because I do not want Windows to be a second product bolted on later. The app is being shaped around the same router, shared UI, and platform facade on both systems. The remaining work is the unglamorous part: packaging, signing, installer behavior, clean-machine validation, updater artifacts, and all the things that make a tool feel safe to hand to someone else.

That is a boring distinction, but an important one.

Why I Built It This Way

The easy version of this app is a pile of platform-specific glue and a picker window.

That might have been fine for a weekend tool, but URL routing is the kind of thing that either becomes trustworthy or becomes annoying. If it is going to sit in the path of every clicked link, it needs to be predictable, inspectable, and recoverable.

So the project ended up with more unglamorous pieces than the first idea suggested:

• strict configuration validation;
• last-known-good config behavior;
• diagnostics for missing destinations;
• recovery windows when a rule points at something that no longer exists;
• onboarding instead of “go read the README”;
• profile switching;
• rule filtering and grouping;
• testable matching logic;
• CI across macOS and Windows.

None of that is flashy. All of it matters when a tiny utility graduates from “interesting” to “I actually leave this running.”

Project Status

YeetTo is still private while I finish the cross-platform foundation and release path.

The stack is Rust, Tauri 2, and a static HTML/CSS/JS frontend. The license is BSD 3-Clause.

YeetTo is still early, but the direction is clear: links should go where they belong, on macOS and Windows, without turning my default browser into a junk drawer.

The problem is that “yours to keep” only holds if you actually keep them. GOG’s client handles downloads fine, but if you want a scriptable, auditable, terminal-friendly way to back up your library to a NAS or an external drive, you’re on your own.

So I built gog-cli.

What It Does

gog is a Python CLI that talks to GOG’s API and lets you manage your game library backups from the command line. The core loop is:

1. Authenticate once.
2. Refresh your local library cache.
3. List, filter, and plan what you want to back up.
4. Actually back it up.
5. Verify and sync later.

Nothing exotic, but everything works the way a CLI tool should: dry-runs before real downloads, explicit --yes flags instead of surprise side effects, resumable downloads, checksum verification when GOG provides them.

The Workflow

gog auth login
gog refresh
gog list purchased
gog plan --destination /path/to/backups --all --storage --check-free-space
gog backup --destination /path/to/backups --all --yes

gog refresh fills a local cache. Everything else reads from that cache — no unnecessary API calls when you’re just browsing your library.

gog plan is the one I reach for most. It shows you exactly what a backup run would download, how big it is, whether you have enough space, without actually touching anything. Run it, sanity-check the output, then fire off the real backup.

Filtering

The list and plan commands have more filtering options than I probably needed to write, but they’re all useful once you have a large library:

gog list purchased --platform linux
gog list purchased --genre strategy --year 1998..2005
gog list purchased --search witcher
gog plan --destination /backups --all --platform windows --language en --storage

Year ranges, genre filters, fuzzy title search, platform selection. Unknown metadata is excluded by default; use --include-unknown-year or --include-unknown-genre if you want those rows.

Batch Selection

For curated backup sets, you can put selectors in a plain text file:

# first NAS batch
witcher_3
cyberpunk_2077
123456789

Lines starting with # and blank lines are ignored. Then:

gog plan --destination /backups --games-from games.txt --storage
gog backup --destination /backups --games-from games.txt --yes

--games-from is repeatable. Selectors can be product IDs, slugs, or titles. You can also mix --game flags and --games-from files in the same command.

aria2c Support

The built-in downloader is fine. If you want parallel downloads and more speed, install aria2c and pass --downloader aria2c:

gog backup --destination /backups --games-from games.txt --downloader aria2c --yes

Why Not Just Use the GOG Client?

The GOG Galaxy client works. But it’s a GUI, it’s not scriptable, and it doesn’t make it easy to maintain organized, versioned backups with metadata you can inspect or diff later.

gog-cli is for the kind of person who wants a cron job that checks for library updates, plans the delta, and backs up new installers to a NAS — without clicking through anything. If that’s not you, Galaxy is fine.

Install

Requires Python 3.12+.

pip install gog-cli

Or from source:

pip install git+https://github.com/aleksandarristic/gog-cli.git

The project is at github.com/aleksandarristic/gog-cli. It’s MIT licensed, and currently at 0.2.1.

The problem: no RSS feed. No Atom feed. Nothing. You either remember to check the site manually, or you miss things.

I got tired of that, so I built feedbot.

What it does

Feedbot is a small Python scraper that fetches the SRB CERT notifications page, pulls out each advisory (title, date, link), and generates a proper RSS XML file from it. That file gets served as a static asset, so anything that understands RSS — your feed reader, your Slack RSS bot, whatever — can consume it.

The core stack is minimal:

• requests + BeautifulSoup4 for fetching and parsing the HTML
• rfeed for building the RSS XML
• A sources.json config that maps CSS selectors to feed fields
• A shell script and a cron job that ties it all together

The config for SRB CERT looks roughly like this — you point it at the page, tell it which HTML elements contain the title, date, and link, give it a regex for parsing Serbian month names, and that’s it:

{
  "id": "srbcert",
  "name": "SRB CERT Obaveštenja",
  "language": "sr",
  "page": "https://www.cert.rs/rs/obavestenja.html",
  "base_url": "https://www.cert.rs/rs/",
  "locators": {
    "item": { "tag": "div", "class": "preporuka" },
    "title": { "tag": "h3",   "class": "title" },
    "date":  { "tag": "span", "class": "date" },
    "link":  { "tag": "a",    "class": "date", "attr": "href" }
  }
}

How it runs

A cron job calls the update script on a schedule. The script runs feedbot, which writes fresh XML files to a directory served by nginx. The feed is live at ristic.in.rs/rss/srb_cert.xml if you want to subscribe without running anything yourself.

Why bother?

Partly because I wanted the feed for myself. Partly because it felt wrong that a national CERT — an organization whose job is to help people stay on top of security threats — doesn’t offer a machine-readable way to follow their own alerts.

An RSS feed is a solved problem from 2001. It takes almost no effort to publish one. The fact that you have to scrape a government security site to get this basic functionality in 2024 is a mild indictment of how seriously some institutions take their own communication.

It’s generic

Feedbot isn’t SRB CERT-specific. The sources.json approach means you can point it at any site that has a consistent HTML structure. If there’s another site you want a feed for — add a source config, run the script, done.

The repo is at github.com/aleksandarristic/feedbot. PRs welcome, especially for more source configurations.

That version was fun. It was also a bit of a prototype in spirit: a chat bridge into Codex CLI sessions, with dreams of multiple transports and just enough command handling to make mobile coding feel possible.

Several months later, the project has become something more serious.

PyCodeBridge is now an agentic coding bridge. It still lets me drive local repo work from chat, but the shape is different: Discord is the supported transport, channels are mapped to repos with code-<repo>, Codex is just the default backend, and Claude Code or Gemini CLI can be selected per session when I want a different agent.

In other words, it moved from “Codex in chat” to “a Discord control plane for agentic coding on my own machine.”

The New Mental Model

The basic idea is still simple:

1. A private Discord channel named code-myrepo maps to a local git repository under code_root.
2. Messages and commands in that channel are routed to an agent session for that repo.
3. The agent runs locally, with access to the actual working tree, local tooling, credentials, and git state I have configured.
4. Results stream back into Discord.

The important change is that the “agent” is now an abstraction, not a synonym for one CLI.

The default backend is Codex. That remains the out-of-the-box path and the config section is still named codex for compatibility. But sessions can now use:

• Codex
• Claude Code
• Gemini CLI

The command is straightforward:

!c agent claude
!c agent gemini gemini-2.5-pro
!c agent codex gpt-5.4 medium

There are also helper commands:

!c agents
!c models
!c efforts
!c agent
!c model
!c effort

The no-argument versions show what the current session is actually using. That matters more than it sounds, because once you have multiple threads, sessions, models, and backends, guessing is a great way to confuse yourself.

Discord Won

The original post talked about Discord, Telegram, and Slack. That is no longer true.

The code still keeps a transport-aware architecture internally, but the supported transport is Discord. I use Discord. Discord has the interaction model I wanted: channels, private repo rooms, threads, typing indicators, uploads, downloads, pinned messages, and direct messages for owner/admin workflows.

So the product decision became simple: stop pretending every transport matters equally and make the Discord experience solid.

That also means the old channel prefix changed. It is no longer codex-myrepo. It is:

code-myrepo

That name fits the project better now. A channel maps to code. The selected backend can be Codex, Claude, Gemini, or whatever gets added later.

It Is Not Just Prompt Relay Anymore

The bridge now has a real command surface. You can still send prompts, but the useful part is that you can operate sessions without being at the machine.

Some examples:

!c start
!c resume fix the failing tests
!c status
!c ps
!c stop
!c interrupt
!c kill
!c logs
!c download path/to/file
!c git status
!c gh pr status

There are shortcuts for active-run interaction:

!s tighten the scope
!a yes, proceed
!y
!n
!w
!retry

Plain chat can also become useful in the right state. If exactly one session is running, a plain message can steer that active session instead of being queued as a new prompt. If an agent is waiting for input, a plain reply can go straight to stdin.

That makes the mobile workflow feel much less like operating a bot and much more like supervising a long-running coding process.

Sessions, Threads, Queues, and Conflict Handling

Each repo channel has a default session. Discord threads also get isolated session scopes, so I can split work without stomping on the main channel state.

There is queueing per channel, run control, stale-session handling, and explicit conflict choices:

!continue
!new
!compact

The compact flow is one of the more useful quality-of-life changes. When a session is stale or I want a fresh run without throwing away all context, the bridge can summarize prior context and start a new session from that summary.

That is the kind of feature that only shows up after actually using this thing for messy, interrupted work.

Security Became a First-Class Feature

Running local coding agents from chat is powerful, which is another way of saying it can be dangerous if treated casually.

The current bridge is much stricter than the early version:

• Discord repo channels must be private.
• Users must be allowlisted.
• The bot is locked to one configured guild.
• TOTP can be required for protected commands.
• GitHub CLI commands can have their own unlock scope.
• High-risk operations stay behind TOTP.
• Failed or replayed TOTP attempts are rate-limited.
• Audit logs can redact secrets.
• TOTP values are sanitized before audit writes.

There are also safer file-transfer rules now. Uploads are bounded by per-file size, total batch size, and file count. Saves use repo-local temporary files and symlink-aware finalization so an upload cannot casually overwrite something outside the repo.

That sounds boring until you remember this is a chat interface into a development machine. Boring is good here.

Better Feedback During Long Runs

Long agent runs are where bridges like this either feel magical or feel broken.

PyCodeBridge now tries much harder to tell me what is happening:

• Heartbeats can include agent, model, and effort.
• Tool calls can be surfaced in the chat stream.
• Claude thinking blocks can be relayed when enabled.
• Streamed output is coalesced so Discord does not get spammed by tiny chunks.
• Successful runs with no assistant output get an explicit terminal notice.
• Final result events stop runaway heartbeats even if a CLI process lingers.
• Friendly errors catch common backend failures, like unsupported models or Claude usage limits.

The point is not to make the chat noisy. The point is to avoid the worst state: staring at Discord wondering whether anything is alive.

Docker, Health Checks, and Operations

The project also grew the less glamorous pieces that make it easier to run:

• Docker and Compose support.
• A preflight wrapper.
• An update-and-redeploy script.
• Optional health endpoint.
• Public health binds blocked by default unless explicitly allowed.
• Reset-state helper.
• Runtime logs, per-session JSONL logs, archives, and audit artifacts.

The bridge can still run directly with Python, but the Docker path is much cleaner for a persistent bot.

What I Actually Use It For

I do not think of PyCodeBridge as “coding on a phone.” That phrase sounds like punishment.

I think of it as remote supervision for local agentic coding.

The useful moments are things like:

• starting an investigation while away from the keyboard;
• asking an agent to inspect logs or summarize a repo state;
• nudging an already-running session;
• checking whether a long run is stuck;
• downloading a generated file;
• stopping a bad run before it wastes more time;
• switching a session from one backend to another when a task fits a different agent better.

It is still a little ridiculous. That is part of the charm. But it is no longer just a weekend toy.

The Current Shape

The short version:

• Supported transport: Discord.
• Channel naming: code-<repo>.
• Default backend: Codex.
• Additional backends: Claude Code and Gemini CLI.
• Repo mapping: channels map to local git repos under code_root.
• Security: allowlists, private channels, guild lock, TOTP, rate limits, redaction.
• Operations: Docker, health endpoint, logs, archives, reset/update scripts.
• Workflow: sessions, threads, queues, run control, uploads/downloads, git and GitHub helpers.

That is a lot more than “send a prompt to Codex from Discord.”

It is now a small, opinionated control plane for letting agentic coding tools work on my machine while I steer them from wherever I happen to be.

Still doom-vibe-code friendly. Just a lot less reckless.

Project:

https://github.com/aleksandarristic/pycodebridge