You already know how that ended.

Maintaining the same post in two places, by hand, is exactly the kind of chore I quietly abandon around week two. So instead of pretending I'm more disciplined than I am, I automated it. This is the story of how that automation grew — from a single scp to a little bridge that keeps both blogs in sync on its own, and even lets me publish by sending an email.

This is the part I love, so let me start here. prose.sh has no admin panel. You write a markdown file and copy it to the server over SSH:

scp my-first-post.md me@prose.sh:/

The file is just text with a tiny bit of frontmatter on top:

---
title: My First Post
date: 2026-06-27
---

Hello from a plain text file.

That's the whole thing. Your editor, your files, zero lock-in.

Doing this once is delightful. Doing it for every post — remembering the filename, the frontmatter, the exact scp line — while also keeping a Ghost blog alive, on a week where work ate every evening... the friction adds up. And friction is where my good intentions go to die.

I wanted to write once and have it show up in both places. That's it.

First I did the obvious thing and wrapped the boring parts in a small CLI. List my posts, create a new one, publish — all over the same SSH the manual way used, just without me typing the incantation every time.

blog publish my-first-post.md

There was one genuinely annoying detail worth mentioning: my SSH key lived on a network share, and OpenSSH flat-out refuses keys with "loose" permissions. So the script learned to copy the key to a safe local spot and lock it down before connecting. Small thing, but it's the difference between "works on my machine" and "works on every machine."

This already made my life better. But it still meant I had to run something, and it still treated the two blogs as two separate chores.

The real shift was a decision, not code: Ghost is canonical, prose is a mirror. I write in Ghost, and prose should just... follow.

This is an old idea with an ugly acronym — POSSE: Publish on your Own Site, Syndicate Elsewhere. You keep one home for your writing and let copies flow outward automatically.

The two halves were already there, waiting to be introduced:

• Ghost can fire a webhook the moment you publish.
• prose accepts markdown over SSH.

All that was missing was a small translator in the middle.

So I wrote one. A tiny service in a container. When I publish in Ghost, it:

1. catches the webhook,
2. converts the post's HTML into clean Markdown,
3. writes the frontmatter for me (title and date — I don't even bother with excerpts),
4. and scps the file to prose.

   Write in Ghost
        │  webhook: "post published"  (HTML)
        ▼
 ┌───────────────────┐
 │   bridge service  │   HTML ──► Markdown ──► add frontmatter
 └───────────────────┘
        │  scp
        ▼
    prose.sh  ──►  notes.example.com

I publish in one place. A few seconds later the same post is sitting on prose, formatted correctly, no copy-paste, no second chore.

Plot twist: posting by email

Then I got greedy. Some of my best ideas show up when I'm nowhere near a laptop — in line somewhere, on the couch, on my phone. I wanted to fire off a quick post the laziest way imaginable: send an email.

So I added one more door. I email a plain message — the subject becomes the title, the body becomes the post — and it lands on both blogs.

The trick that made it clean: the email doesn't talk to prose at all. It just creates a Ghost post through Ghost's API. Then Ghost's normal webhook does the rest, exactly like a post I'd written by hand. One road to prose, not two.

   Write in Ghost ───────────────┐
                                 │ webhook
   Send an email                 │
        │                        ▼
        ▼                ┌────────────────┐
  inbound email  ──POST─►│ bridge service │──API──► create post in Ghost
   (mail provider)       │                │◄─webhook─┘
                         └────────────────┘
                                  │ scp
                                  ▼
                              prose.sh

One more wrinkle: my little box sits at home behind a connection with no public IP, so a stranger on the internet (Ghost's webhook, the mail provider) can't reach it directly. I tunnel those requests in through a cheap VPS, which terminates HTTPS and forwards them down to the container. The box never has to be "on the internet" — it just keeps a quiet outbound tunnel open.

  internet ──► tiny VPS (HTTPS) ──tunnel──► home box ──► bridge service

Few things that only became obvious after building it:

• One source of truth saves you from sync hell. The moment you have two "originals," you have a merge conflict waiting to happen.
• Make every feature funnel through the same path. Even the email trick ends as a normal Ghost publish, so there's exactly one place that can break — and exactly one place to fix.
• Verify signatures. The open internet will happily POST garbage at any URL it can find. Both the webhook and the inbound mail are checked before I trust a byte.
• Only mirror what's public. Members-only drafts stay where they belong.
• Convert, don't paste. Turning the rendered HTML back into Markdown keeps prose clean instead of full of editor cruft.

It's the kind of boring magic I like: invisible when it works, and it mostly just works.

And yes. It's working.

See you around.

I’m writing this down before I forget. Less changelog, more diary.

The theme of the week wasn’t installing things. It was fixing them.

Looking back, almost none of what I did was “spin up a new service.” It was mostly figuring out why something was wrong and fixing the cause instead of treating the symptom. That pattern repeated itself so often that it became the thread running through the whole week.

The cleanest example was the GoToSocial theme. There was a readability bug in the admin panel: almost-white text on a light gray background, basically unreadable. I spent too much time theorizing about which selector was painting the text the wrong color, when the real problem was the background. The --almost-white variable in GoToSocial is not a text color; it is a surface color. I had mapped it to a light value, so the whole panel was getting a light background from there. The fix was one line. Same old lesson, learned again: when text “disappears,” the first thing to check is background-color in DevTools’ Computed panel, not whatever theory your brain just invented.

That pattern — stop guessing and read the actual state — showed up again in Unraid, PeerTube, and pretty much everything else.

The servers

Nyx (Unraid / Ryzen 5800X)

I started with a boring permissions problem while moving qBittorrent downloads — the container UMASK was set to 022, so I changed it to 002 — and somehow ended up investigating CPU temperatures. The dashboard temps were way too high.

My guess was a process. Claude’s guess was hardware. Both were partly right. vmstat showed a constant 91% idle, so load wasn’t the issue. The main culprit was the frequency governor being stuck on performance, holding the cores at 4641 MHz even while idle. I switched it to powersave with EPP set to balance_performance through amd-pstate-epp, and the clocks dropped to around 3710 MHz. But the temperature only improved a little. That tells me there’s also a physical cooling limit involved — probably dried-out thermal paste, which is a known pain point with the 5800X. That stays on the list: open the machine and check it properly.

I made the governor and EPP settings persistent in /boot/config/go, in the right order — governor first, EPP after — otherwise the file locks up.

skullserver (Debian / Contabo)

This was the heaviest day. Four fronts: security, cleanup, MOTD, and IRC.

The discovery that annoyed me the most: UFW had the correct default-deny policy, but Docker injects its own iptables rules and bypasses UFW. Result: around thirteen containers were exposed to the internet even though the firewall made it look like they were not. I moved everything from 0.0.0.0 binds to either 127.0.0.1 for services behind a proxy, or to the Tailscale IP for direct access. I also found a Shadowsocks service running as init.d that I didn’t even remember anymore — gone. Cleaned up nine orphaned UFW rules too.

I rewrote the MOTD from scratch because the Debian 13 pt_BR locale was breaking the parsing of free — it returned Mem.: instead of Mem:. The new version reads directly from /proc and forces LC_ALL=C. I also gave it the look I wanted: monochrome editorial style, oxblood accent, a thin ruler instead of a box-drawing frame.

The IRC client that kept dropping wasn’t the server after all. It was the residential connection’s NAT timeout. Solved by routing the client through Tailscale with a single line in the Windows /etc/hosts.

murad.chat (Debian / Contabo)

This one was about load average, which had gone up after I added more federated services — Funkwhale, BookWyrm, Pixelfed, Lemmy, Iceshrimp. But the truth is the load average was lying to me: constant 82–99% idle, zero I/O wait. The high number wasn’t a real problem.

Still, I managed to tighten three services. Funkwhale Celery went from 6 workers down to 2. BookWyrm went from 100 threads down to 12, and Flower was shut off. Pixelfed Horizon was the annoying one — balance=auto enforces at least one worker per queue, so limiting processes didn’t help. The fix was HORIZON_BALANCE_STRATEGY=false with a fixed pool. Horizon RAM dropped from 1.19 GB to around 247 MB.

OpenBSD

Intermittent network drops that only came back after a reboot. The log gave it away immediately: duplicate IP address. ARP conflict — another machine had the same static IP, probably a cloned VM that inherited the config. I moved it to a free IP outside the DHCP pool. No drama.

The visual side

GoToSocial — “Fediverso IDEA” theme

Besides the admin bug I mentioned earlier, the constant challenge here is the 10,000-character limit in the custom CSS field. It forces you to write tight CSS, with no spare comments or junk left behind. The final version landed at around 3,500 characters. Dark space-like background, cyan/violet/lavender palette.

Unraid WebUI

I first tried a vaporwave/synthwave theme and wasn’t happy with it — the selectors were too generic and created bordered boxes around everything. I ended up adopting a Nord theme I found and liked better, so the work became filling in the gaps. The theme was written for an older Unraid version and used ID selectors where 7.3.1 uses classes. The dashboard is table-based, and there were some .stopgap elements that are transparent spacers — the theme was painting them, which made the widgets visually bleed into each other. I made them transparent again and unified the cards with matching border radius.

PeerTube — pablo.tube

I reinstalled the PeerTube instance I had previously shut down because of resource usage and unwanted federation. This time the rules were clear: federation off, transcoding limited to one job, and a hard 480p ceiling regardless of upload size. Along the way I found a broken acmetool hook that was causing all certificate renewals for all domains to silently fail the nginx reload — it was trying to restart dovecot, which does not even exist there anymore, with set -e enabled. Fixed with || true. I also gave the instance a “YouTube 2008” look with CSS and a MutationObserver that wraps “Tube” in a red box to make the logo read Pablo.[Tube].

Kubuntu

The Dell XPS 13 running Kubuntu was choking on Google Drive — a known KDE bug where Online Accounts authenticates correctly, but Dolphin throws “Access denied” because Google blocks the shared OAuth client used by kio-gdrive. I gave up on kio-gdrive and switched to rclone with FUSE. I mounted two remotes — personal and skull — using a single systemd service template with %i substitution, plus enable-linger so it comes up at boot. I also created my own OAuth client in Google Cloud and published it to production to avoid the trap of tokens expiring every 7 days.

I took the opportunity to clean things up: removed snaps I don’t use anymore — Firefox, Element, Thunderbird — replaced Thunderbird with Melia, and fixed Portuguese spell checking. The system itself was healthy: 5.4s boot, zero failed services, TRIM active. More hygiene than repair.

And the project that wasn’t about servers

In the middle of all that, I worked on a family video from 1989 — around 200 minutes of celebrations, including a first birthday. I wanted to improve the quality.

After testing several upscale tools, I learned an annoying truth: the problem with the video is not recoverable noise, it is intrinsic blur from the original capture. Detail that was never recorded cannot be reconstructed by upscale magic. What actually worked was CodeFormer, focused on face restoration — it detected the four faces in the frame and produced something visibly sharper and more recognizable. The honest caveat is that it reconstructs a plausible face; it does not recover the lost pixels. The -w 0.7 parameter strikes a decent balance between quality and identity fidelity. Good enough to make running it on the whole video worth it.

A small ActivityPub instance was up, the profile was public, the account had posts, and the RSS option was enabled in the settings. The URL was exactly where it should have been: the profile path followed by feed.rss. A feed reader should have seen it, fetched it, and moved on with its quiet little life.

Instead, the feed existed but had no posts.

At first glance, everything looked normal. The endpoint returned 200 OK. The content type was application/rss+xml. The XML was valid. The channel had a title, a link, a description, a build date, and even the profile image. But there were no <item> entries. Not one. The feed was technically alive, but empty.

That is the kind of bug that wastes time because it does not fail loudly. A 500 error gives you a direction. A 404 tells you the route is missing. Invalid XML gives you a parser problem. But a valid RSS feed with no items politely tells you: “There is nothing to see here.” And then you have to prove that it is lying.

The first suspects

The obvious place to look was the reverse proxy.

The instance was behind Nginx, and feeds can be sensitive to headers, redirects, hostnames, and content negotiation. So we checked the public endpoint first, then bypassed the proxy and hit the service locally with the same Host and forwarded headers. The result was the same in both places. That ruled out Nginx pretty quickly.

Next we looked at the RSS setting itself. The feed was enabled in the user interface, and when enabled it returned a valid RSS document. But after toggling the setting off and on again, the feed briefly disappeared entirely and returned an HTML 404 page. That was the first useful clue: the checkbox in the interface and the value in the database were not always telling the same story.

When the setting was disabled in the database, the feed route returned 404. When it was enabled, the feed came back as RSS. So the route was not broken. The feed feature was not missing. It was being gated by the account setting exactly as expected.

But even with RSS enabled, the feed was still empty.

The visibility rabbit hole

The next theory was visibility.

GoToSocial has a few different visibility levels, and its defaults are not always what people coming from other Fediverse software expect. We wondered whether the posts were not truly public. Maybe they were “unlisted” or “unlocked,” visible on the web profile but excluded from RSS.

That seemed plausible for a while. The public profile showed the posts, the account settings allowed public and unlisted posts to appear, and the RSS documentation focuses on public posts. It would have been a clean explanation: the posts were visible, but not eligible.

So we checked the database.

The statuses were local. They were federated. They were not replies. They were not boosts. They were not pending approval. They had normal text content. Their visibility value matched the public visibility enum for that version of GoToSocial. In other words, the posts were not the problem. They were exactly the kind of posts the RSS feed should include.

That theory died there.

Trying versions, chasing behavior

We also pinned the GoToSocial image instead of relying on a moving tag. The instance had been running a recent 0.21.x build, and we tried to remove uncertainty by using a specific version. The behavior did not change.

That mattered. It meant we were not just fighting a bad container pull or a half-updated image. The problem survived restarts and version pinning within the same release line. We were dealing either with persistent state in the database or a behavior in the application that depended on that state.

At this point the RSS endpoint was doing something very specific:

• If RSS was disabled for the account, the route returned 404.
• If RSS was enabled, the route returned valid RSS.
• The feed included channel metadata.
• The feed did not include any posts.
• The public web profile could still find and render the posts.
• The database query for obvious RSS-eligible posts returned all of them.

That narrowed the field. The posts existed. The web view could query them. The RSS route was active. Something between “account has posts” and “RSS should render items” was deciding that the account had no eligible latest status.

The clue hidden in account stats

The real clue was not in the statuses table.

It was in the account statistics table.

The account had a nonzero status count. The posts existed. But last_status_at was NULL.

That was the contradiction:

statuses_count: several posts
last_status_at: NULL

For an account with public posts, that should not happen.

Once we saw that, the empty RSS feed made sense. The RSS generator appeared to rely on account-level cached/statistical metadata to decide whether there was a recent eligible status for the feed. Since last_status_at was empty, the feed could be generated as a valid channel with no items, even though the posts themselves were perfectly eligible.

The public web profile did not suffer from the same problem because it queried the statuses directly. That explained why the web profile worked while RSS did not. They were not failing through the same code path.

The fix

The fix was deliberately small.

We backed up the SQLite database. Then we updated last_status_at for the account to the created_at value of the newest eligible public status. After restarting the service, the RSS feed immediately populated with all the expected items.

No proxy change. No rewrite rule. No client workaround. No fake feed. No downgrade.

The feed went from a valid-but-empty XML document to a normal RSS feed with every public post listed.

After that, we published more test posts. They appeared in the RSS feed as well. The channel dates also started making sense once last_status_at was corrected.

So, was it a bug?

In practical terms, yes.

Whether it is best described as a GoToSocial bug, a migration edge case, an account stats initialization issue, or stale derived state, the result was the same: account statistics said the account had posts, but also said it had no last status. RSS trusted that derived state and produced an empty feed.

The important part is that the underlying posts were fine. The RSS feature was fine. The URL was fine. The proxy was fine. The broken piece was cached account metadata.

That is also why the problem was so slippery. Every normal check passed. The profile loaded. The posts were public. The feed endpoint responded. The XML validated. The database contained the posts. Nothing looked catastrophically wrong.

Only one field was wrong, and it was not in the first table we looked at.

In GoToSocial, the public profile and RSS feed may use different internal paths and different assumptions. If the profile shows posts but RSS is empty, checking only the statuses is not enough.

Its that account-level derived data matters. Fields like statuses_count and last_status_at are not just decorative. They can influence what other parts of the application think exists.

A 200 OK response with valid XML can still be wrong. Sometimes the bug is not that the endpoint failed. Sometimes the bug is that it succeeded with the wrong idea of reality.

In our case, the fix took one small database correction. Finding that correction took a few hours of chasing ghosts: headers, visibility, settings, version tags, profile behavior, API behavior, and finally the stats row that gave the whole thing away.

On a personal level, I’m planning to move everything I currently run on VPSs back home, locally. My goal is to do a large-scale migration, which will probably be exhausting, especially for my home network. But I want to take custody of my own data. I’m moving away from big tech as much as possible and giving more attention to small technology companies, self-hosted tools, and open-source software.

To start this process, I’ve put together a small catalog of the services I currently have available in Murad World (https://murad.world). This nice little catalog was built with Kiki, a system by Tomotama, which you can find here: https://tomotama.itch.io/kiki. Its blog was also adapted from another system called Zonelets, available here: https://zonelets.net.

Manual, simple, and easy. It turned out to be an interesting adaptation.

In Murad World, I’m listing everything personal that I run. A small portion of these services is already hosted on local servers, while the remaining ones are still on Contabo VPSs. By the end of the year, I intend to leave only company servers running on their proper VDSs.

There isn’t much more to say for now. These are mostly everyday updates, the kind where one small change can take a long time. Further ahead, though, I’ll write about a few other projects that are already finished.

I adapted my whole system so I could tap into the benefits of the small web, and then the idea came to me: why not create a theme that is 100% compatible with the IndieWeb?

And here I am.

Download Here.

I already had a theme. pablawn was my home: a tiny blog in a retro directory style, a dense list of posts where each text is a single line — date on the left, title in the middle, reading time on the right, and a dotted line stitching the two together like the table of contents of an old book. And underneath that lean aesthetic, I had taught Ghost how to speak IndieWeb: an invisible h-card proving who I am, posts marked up as h-entry, and webmentions arriving from across the web.

It worked beautifully — for me. The problem is that it worked only for me. My name was in the HTML. My photo, hosted on my own server, was in the HTML. My eleven rel="me" profiles, my webmention endpoint, my emails, even the array of “owned identities” that filters out the echo of my own publications: everything was hardcoded into the templates. It was a theme for one person only.

The idea driving us was simple to state and stubborn to execute: what if that same theme could be freely distributed, and anyone could configure their own IndieWeb identity directly inside the Ghost admin — without needing to know how to edit Handlebars, without touching CSS, without touching code? The free theme would be called indawn.

Ghost allows a theme to declare panel options — but with strict constraints. There are only a few types (select, boolean, color, image, text); text fields are single-line only; there is no list or repeatable field; and there is a practical ceiling of around twenty options in total.

Then came the first punch of reality: pablawn had already spent fourteen of those twenty options on font choices, navigation layout, color scheme, and homepage sections. That left six slots. Six. To fit an entire identity plus an arbitrary list of social networks.

And there was a second punch, subtler and more technical. rel="me" — the thread that stitches “this domain and these accounts are the same person” together — needs to be in the HTML delivered by the server. IndieWeb validators fetch the raw HTML; they do not run JavaScript. That killed the clever route every programmer tries first: store all the links in a single text field and split them with JS at runtime. No dice. Each rel="me" link has to come from a named field, rendered by Handlebars on the server. And Handlebars has no way to split a string. In other words: one social network = one panel field. No shortcut.

Six slots. One entire identity. The math simply did not work — until we stopped trying to fight Ghost and started using it in our favor.

The piece that unlocked everything was realizing that Ghost already stores a large part of the h-card — just in the native fields everyone fills out without thinking:

• the name (p-name) is the site title;
• the photo (u-photo) is the site icon;
• the canonical URL (u-url) is the site URL;
• the bio (p-note) is the site description.

None of that costs a slot. The central identity of the semantic business card started assembling itself from things the user configures in Settings → General without even knowing they are feeding microformats.

And there was an almost indecent bonus: Ghost natively has two Social accounts fields — X/Twitter and Facebook. Two rel="me" links for free, without spending any of the budget. Along the way, we replaced the old {{twitter_url}} helpers with the modern {{social_url type="..."}} helpers — gscan complained, and a distributable theme cannot be born with a warning.

The six fields that remained

With the identity coming for free, the six remaining slots were available for what truly needed its own field. We spent them like this:

• webmention_endpoint — where the person pastes their own webmention.io address;
• social_github, social_mastodon, social_bluesky, social_linkedin, social_youtube — one complete URL per network.

Five named networks, plus the two native ones, make seven in total. The choice was not random: GitHub, Mastodon, and Bluesky are the core of the open web, where rel="me" can actually verify back; LinkedIn covers the professional side; YouTube covers people who create video. Instagram, Threads, and TikTok were left out on purpose — they are walled gardens where rel="me" almost never closes the loop, so they would be decoration, not verification.

Two design decisions hold this arrangement together. The first is the rule “empty means off”: no field has a separate on/off switch — if you do not fill it in, it simply does not appear. That saves precious slots and makes the panel self-explanatory. The second is that every network is a complete URL, not a “username” — because on Mastodon the instance varies, and asking only for the handle would break half the cases.

Each filled field feeds two places from a single source: the hidden h-card at the top (what robots read) and the discreet footer icons (what humans see). One truth, two appearances.

What we chose not to do

A large part of the work of a free theme is having the discipline to cut. We consciously left out: the h-card extras (job title, organization, region, country) — too niche; the self-mention filter, which we reset and left commented for anyone who might want it one day; the exotic networks that did not fit the rule; and the sending of webmentions, which was never the job of a theme — it is an external service that watches the RSS feed and notifies other sites for you. The theme only needs to deliver an honest h-entry, and it already does that.

We also cleaned up the personal residue that was not IndieWeb: an old JavaScript trick that swapped the sample texts of the members portal, the hardcoded author photo in posts, the three fixed footer links. Everything that said “Pablo” in the HTML came out — only the author signature in package.json and the README remained, which is exactly where it belongs.

How it ended up inside

Once the design was clear, the fork became mechanical: copy the theme, rewrite package.json (name indawn, version 0.0.1), replace the h-card block with dynamic fields, condition the <link rel="webmention"> on the existence of the endpoint, make the footer dynamic, reset the personal array in JavaScript, and rewrite the documentation.

The verdict came from gscan, Ghost’s official validator: compatible with Ghost 6.x, zero warnings. One final search pass confirmed that neither the sources nor the rebuilt files carried any trace of personal identity. Then all that remained was packaging it: indawn.zip, ready to be uploaded to any Ghost site in the world.

The most useful lesson was not technical — it was attitudinal. For quite a while, we fought Ghost, trying to force into it a list of links it was never meant to have. Progress only came when we stopped wanting Ghost to be something else and asked: what does it already know how to do that I am ignoring? The answer — “it already stores your name, your photo, your URL, your bio, and two networks” — solved half the problem before we wrote the first line of configuration.

The other lesson is about the ceiling. indawn is born exactly at twenty out of twenty options, right up against the limit. There is no spare room, and that is honest: I left it recorded, both in the guide and in my head, that gaining a sixth network one day will mean giving something else up. Constraint is not a failure of design; often, it is the design itself.

from the front, instead of coming with it already written on the wall.

So I added the account. It authenticated. The entry showed up. I clicked it — Access denied.

Not "wrong password." Not "try again later." A flat, permanent denial. Every folder, every time.

It's not you, it's kio-gdrive

If you go digging in the logs instead of staring at Dolphin, the real message is uglier and a lot more honest:

org.kde.kgapi: Requested resource is forbidden

Here's what's actually happening. KDE's Google Drive integration runs through kio-gdrive, which talks to Google using the kgapi library and a shared OAuth client ID that belongs to the KDE project. Google has been tightening the screws on apps that request "sensitive" scopes — like full Drive access — without going through their verification circus. The KDE project's client got caught in that net. So the authentication step still works (the account adds fine, the entry appears), but the moment you try to read anything, Google slams the door.

It's not your machine. It's not a misconfiguration. It's a credential the whole KDE userbase shares, and Google decided it's had enough.

There's a workaround floating around the forums: register your own OAuth client in Google Cloud and somehow feed it into kio-gdrive. I'd skip it. The people who actually tried it report that it either still fails outright, or — worse — it lists your files but refuses to copy anything down to disk. A file manager that shows you files it can't open is more frustrating than one that just admits defeat.

So I stopped trying to resuscitate kio-gdrive and did the thing everyone who's been burned by it eventually does.

rclone, and a real folder

rclone mounts your Drive as an actual filesystem over FUSE. That distinction matters more than it sounds. This isn't a KDE-only protocol that lives inside Dolphin — it's a plain folder on disk that every app on the machine can see. Your terminal, your editor, your scripts, your image viewer. All of them.

First, install rclone and FUSE. The version in Ubuntu's repos tends to lag, so I use the official installer:

sudo -v && curl https://rclone.org/install.sh | sudo bash
sudo apt install -y fuse3

Then create the remote:

rclone config

It's an interactive wizard. Pick n for a new remote, name it something you'll recognize (I went with gdrive-pablo), choose drive as the type, leave the client ID and secret blank for now, and pick scope 1 for full Drive access. When it asks to use auto config, say yes — it pops open your browser, you log in, you authorize, done. Confirm and quit.

Test it:

rclone lsd gdrive-pablo:

If it lists your top-level folders, you're already further than KDE ever got you.

Make it survive real use

You can mount it by hand:

rclone mount gdrive-pablo: ~/GoogleDrive --vfs-cache-mode full --daemon

That --vfs-cache-mode full is not optional, and it's the flag most people forget. Without it, editing or writing files that are already open breaks in ugly ways. With it, rclone uses a local disk cache and behaves like a normal disk. It's the single setting that turns rclone from "technically works" into "actually usable."

But mounting by hand every login is a chore, and I had two Drives to deal with. So I let systemd handle it — as a user service, not a system one, because the mount belongs to my session and my credentials.

Rather than write two near-identical service files, I used a systemd template — one file with an @ in the name. Whatever you put after the @ when you enable it becomes the %i variable inside. One file, any number of drives.

~/.config/systemd/user/rclone-gdrive@.service:

[Unit]
Description=rclone mount (%i)
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
ExecStartPre=/bin/mkdir -p %h/GoogleDrive/%i
ExecStart=/usr/bin/rclone mount %i: %h/GoogleDrive/%i \
  --vfs-cache-mode full \
  --vfs-cache-max-size 2G \
  --dir-cache-time 12h \
  --poll-interval 15s \
  --umask 022
ExecStop=/bin/fusermount3 -u %h/GoogleDrive/%i
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

Then enable one instance per drive, and turn on lingering so the mounts come up even before I open a graphical session:

systemctl --user daemon-reload
systemctl --user enable --now rclone-gdrive@gdrive-pablo.service
systemctl --user enable --now rclone-gdrive@gdrive-skull.service
loginctl enable-linger "$USER"

Now both Drives mount themselves at boot, restart if they crash, and live as ordinary folders under ~/GoogleDrive.

The part nobody tells you: your own client ID and the 7-day trap

When you left the client ID blank earlier, rclone fell back to its shared client — the one bundled with the tool and split across millions of users. It works, but under any real load you'll start hitting userRateLimitExceeded. With two drives competing for the same shared quota, it gets old fast.

The fix is to register your own OAuth client in Google Cloud. The short version: create a project, enable the Google Drive API, set up the consent screen with audience External, and create an OAuth client of type Desktop app. Copy the client ID and secret, drop them into each remote, and reconnect.

And here is the detail that will save you a confused afternoon a week from now.

When you set up the consent screen, Google leaves the app in Testing mode by default. In that mode, your refresh token expires after seven days. Everything works beautifully — until exactly one week later, when every mount silently dies and you have no idea why.

So before you walk away, publish the app to production. Google will warn you that production normally requires verification; ignore it. For a personal app you use yourself, it works fine unverified, and — critically — the token stops expiring. That one toggle is the difference between "set it and forget it" and "re-authenticate every Monday forever."

To apply the new credentials without nuking your config:

rclone config update gdrive-pablo client_id "YOUR_ID" client_secret "YOUR_SECRET"
rclone config reconnect gdrive-pablo:

The same client ID works for every drive — it identifies the app, not the account, so each remote authorizes its own Google account separately.

Two rough edges worth sanding down

A couple of things surfaced once the mounts were live.

The first was log spam — endless lines like Dangling shortcut "..." detected. Those are broken shortcuts inside Drive itself, pointing at files you've since deleted or lost access to. They're harmless, but rclone tries to resolve each one, which costs API calls and slows down the first listing. Tell it to stop bothering:

--drive-skip-dangling-shortcuts

The second was Dolphin freezing hard enough to ask me to restart it. The culprit turned out to be thumbnails. Because the mount is FUSE, Dolphin treats it as a local folder — so when it tries to generate a preview for a 4 GB video, it dutifully downloads the whole file to make a thumbnail. Open a folder full of those and it grinds to a halt. The fix lives in Configure Dolphin → General → Previews: uncheck the generators that read entire files (video, archives) and drop the maximum file size to something small like 10 MB. Small images and PDFs still preview; the giant stuff no longer drags everything down.

Two Google accounts, mounted as plain folders at ~/GoogleDrive/gdrive-pablo and ~/GoogleDrive/gdrive-skull, coming up automatically at boot, on my own API quota, with a token that doesn't quietly expire. Every app on the system can read them, not just Dolphin. The local disk cache makes editing feel native.

KDE's Online Accounts still shows a Google Drive entry. It still throws Access denied. I just don't click it anymore.

It began with a feeling, which is the worst possible way to begin anything technical.

The server felt like it kept falling over. Every so often the load average would drift past two, the terminal would repaint its banner, and some old reflex would mutter there it goes again, rebooted. I believed that reflex for longer than I'd like to admit.

The honest first move in any optimization is to stop trusting the symptom and go look at the number underneath it. Load average might be the most misread figure in all of Linux. People read it as a CPU gauge. It isn't. On a twelve-core machine, a load of two means the box is half asleep — better than eighty percent of its cores idle, waiting for something to do. The figure that actually mattered was idle time, and idle time sat at ninety-four percent. The machine wasn't drowning. It had never been drowning. And those reboots I was so sure about? The uptime counter climbed the entire time. Machines that reboot don't count days; they start again from zero.

So there was no performance problem. That's a real result, not a disappointment. "Nothing is wrong here" is a legitimate answer, and hunting for phantom gains on a healthy machine is just a more sophisticated way of breaking it.

But once you stop asking why is it slow and start asking what is this thing actually doing, a different picture shows up. This was a server that had grown, without my quite noticing, into doing everything — a handful of websites, a git forge, an IRC bouncer, a small app or two I'd forgotten I installed, a sediment of services laid down over years. And every one of them had, at some point, opened a door.

So I listed what was listening, and it was not a short list. A database bound to 0.0.0.0 — every interface, the public one included. A second database doing the same. A container-management dashboard, the kind of thing that hands you the entire host if its password ever leaks, answering cheerfully on a public port. File sharing. A proxy I'd set up for some reason that had long since died and taken its justification with it. Each of these had been opened deliberately, once, for a purpose that no longer existed, and then simply left.

Here's the part that catches almost everyone, and it caught me: a firewall is not enough when you run Docker.

The mental model most of us carry is that the firewall is the bouncer at the door and nothing gets past it. But Docker writes its own packet-forwarding rules to make published ports reachable, and those rules are consulted before your tidy firewall policy ever gets a vote. You can have a deny-by-default firewall, feel completely safe, and still have a dozen container ports wide open to the internet. I did. The policy said one thing; the actual path a packet would take said another. That gap is the single most useful thing I relearned this week: trust the path, not the policy.

The fix wasn't clever, only disciplined. Anything that already sat behind the reverse proxy didn't need a public port of its own — the proxy reaches it over loopback, on the same machine — so I rebound those services to 127.0.0.1 and the outside door quietly closed. Nothing changed for visitors; they were always arriving through the domain and the proxy. The direct shortcut, the one only an attacker would ever bother with, just stopped existing.

Everything else — the databases, the dashboards, the things only I ever touch — moved onto the mesh. I already run a WireGuard-style mesh VPN across my machines, and once you have one of those, the public internet stops being the place you administer anything. A service bound to its mesh address is invisible to the world and a single hop away from me. The database that had been sitting exposed for who-knows-how-long became reachable from my own devices and from nowhere else on earth.

Then I deleted things, which is badly underrated. The app I never opened. The proxy with no purpose. A couple of accounts belonging to people who'd moved on long ago. Every one of them was surface area I'd been defending for no reason. Removing a service you don't use is worth more than hardening one you do — there is no more secure version of a thing than its absence.

The remainder was housekeeping of the small, dignified sort. A login banner that had been quietly lying about half its fields, because a language setting had broken the way it parsed memory and processor, got rewritten to read straight from the kernel instead of from translated labels. Stale accounts trimmed. The kind of work nobody thanks you for and everybody quietly benefits from.

And then, near the very end, the original ghost finally showed its face.

The thing that had convinced me the server was falling over wasn't the server at all. It was the IRC link — my client, at home behind an ordinary router, talking to the bouncer across the open internet. Home connections are restless animals. The router's translation table forgets an idle conversation; the next packet lands on a socket that's already dead; the link snaps; the client reconnects; and from the outside it looks exactly like a machine that keeps collapsing. It wasn't. The machine's uptime was measured in serene, uninterrupted days. The road to it was what kept washing out.

The remedy was the same idea as all the rest: stop driving on the public road. I pointed the client at the bouncer through the mesh instead of across the open net. The tunnel keeps itself awake, the translation-table timeouts stopped mattering, and the connection that used to die on the hour simply held. One steady thread where there had been a churn of dying ones.

None of this made the server faster, because the server was never slow. That was the lesson folded inside the whole exercise. We reach for the word optimization and picture squeezing more speed out of something, but most of the real work on a mature system is subtraction: closing doors you forgot you opened, deleting what no longer earns its keep, and learning to read the instrument that tells you the truth rather than the one that merely tells you something.

The machine had been fine the entire time. I just hadn't been looking at it honestly.

A server, in the end, isn't so much optimized as it is tended. And most of tending is knowing what to take away.

I’ve owned a couple of iPads before, and the main thing they did was collect dust on my shelf, which tells you exactly how important they were to me. But then the day came: I needed to sign some company documents quickly, and I was not happy with my drawing tablet anymore. I probably should have bought a newer one with a screen, but I’m a terrible enough artist that owning something that “advanced” felt almost insulting. Also, I wanted something portable.

That was it, I thought. I’m buying a tablet.

I walked into the store already sulking because I didn’t want to be there, saw the first one on the shelf for R$1,400, and without thinking too much, threw it into the cart.

I knew I was being robbed, in a way. I knew it cost more than it was worth. I knew our taxes are murderous. I also knew I didn’t even like tablets.

But I needed one.

All I needed was for Noteshelf to work.

In practice, the tablet quickly showed me the cruel reality of entry-level devices: a heavy system, bloatware, background services, unnecessary animations, built-in ads, duplicate apps, and an interface trying very hard to look premium on hardware that has absolutely no breathing room for that kind of nonsense.

The device in question is a Redmi Pad SE, running Android 15 / HyperOS. It has 4 GB of RAM, and it comes with that lovely marketing phrase: “4 GB + 2 GB,” meaning memory extension. It looks nice on the box, but in reality those extra 2 GB use internal storage as virtual memory. On a tablet with slower storage, that can become micro-stuttering.

And micro-stuttering is exactly what destroys the experience of writing with a stylus.

My disappointment had proven itself correct: I had bought a piece of crap. I had thrown money away, and I was pissed.

I tested the pen and noticed the delay. That killed me. So I went back to using the drawing tablet.

But this thing kept staring at me from the table, looking pathetic and saying: use me.

I had to do something.

The goal, then, was not to turn this tablet into an iPad or a top-of-the-line Galaxy Tab. That would be fantasy. The goal was more realistic: remove the system’s dead weight, reduce interference, cut useless processes, and make the tablet as fluid as possible for handwriting.

This article is the record of that process.

The Real Problem

The problem was not simply “the tablet is weak.”

That would be a lazy explanation.

The problem was the sum of several things:

• 4 GB of RAM for a heavy modern system;
• HyperOS packed with Xiaomi services;
• duplicate apps for video, music, browser, notes, weather, scanner, and so on;
• telemetry and advertising;
• useless notifications;
• battery saving interfering with writing apps;
• system animations;
• memory extension using internal storage;
• the natural limitations of the Redmi Pad SE screen and pen.

In other words: the tablet does not have much muscle to begin with, and the system still wastes part of it on useless junk.

The idea was simple: if the hardware is limited, the system needs to be leaner.

Before Even Thinking About a Custom ROM

My first idea was: “Can I install a lighter operating system on this thing?”

Yes, technically. The Redmi Pad SE uses the codename xun, and there are custom ROMs for it, including LineageOS and other unofficial builds.

But that comes with risks: unlocking the bootloader, wiping data, relying on a compatible recovery, and accepting possible bugs with touch, pen input, audio, camera, rotation, or battery.

And here is the important part: switching ROMs can make the system lighter, but it can also make the pen experience worse. On Android tablets, stylus performance depends a lot on the kernel, firmware, drivers, and manufacturer-specific tweaks.

So the decision was sensible: before going down the custom ROM route, I would debloat the system through ADB and tune what could be tuned.

No root.
No bootloader unlocking.
No irreversible hackery.

Confirming the Model with ADB

First, I connected the tablet to Windows using ADB. Since I was using WSL, ADB inside Debian could not see the USB device directly. The simplest solution was to use PowerShell on Windows.

With USB debugging enabled on the tablet, I ran:

adb devices

At first, it showed up as unauthorized. That is normal. The tablet displays a window asking you to authorize the computer’s RSA key. After accepting it, the result looked like this:

List of devices attached
1c5e93eb        device

Now ADB was working.

Then I confirmed the model:

adb shell getprop ro.product.device
adb shell getprop ro.product.model
adb shell getprop ro.product.name
adb shell getprop ro.build.version.release
adb shell getprop ro.miui.ui.version.name

Result:

xun
23073RPBFL
xun_global
15
V816

So:

• device: Redmi Pad SE;
• codename: xun;
• variant: global;
• Android: 15;
• interface: HyperOS/MIUI V816.

This confirmation is essential. Debloating or looking for ROMs without knowing the device codename is asking to do something stupid.

Saving the Package List Before Touching Anything

Before removing anything, I saved the complete list of installed packages:

adb shell pm list packages > "$env:USERPROFILE\Desktop\pacotes-redmi-pad-se.txt"

That creates a file on the Desktop with all packages. It is not exactly a system backup, but it helps a lot if I need to remember what was there before.

I also listed packages related to Xiaomi, MIUI, video, music, browser, games, ads, and similar junk:

adb shell pm list packages | findstr /i "miui xiaomi msa analytics browser video music game getapps yellowpage"

That is when the trash collection showed up.

What I Decided NOT to Remove

This part matters.

Good debloating does not mean deleting everything like an animal.

Some packages look useless, but they control critical parts of the system. Remove the wrong thing and you can break permissions, battery management, the launcher, touch behavior, system features, or even the pen experience.

I decided not to remove these packages:

com.miui.powerkeeper
com.xiaomi.touchservice
com.miui.securitycenter
com.miui.securitycore
com.lbe.security.miui
com.miui.securityadd
com.miui.core
com.miui.core.internal.services
com.miui.system
com.miui.home
miui.systemui.plugin
com.miui.notification
com.miui.permissioncontroller.overlay
com.xiaomi.account
com.xiaomi.finddevice
com.xiaomi.xmsf
com.xiaomi.xmsfkeeper
com.xiaomi.bluetooth
com.miui.misound
com.miui.daemon
com.miui.misightservice
com.android.systemui.overlay.miui
com.android.settings.overlay.miui
com.android.networkstack.overlay.miui
com.android.wifi.resources.xiaomi
com.google.android.wifi.resources.xiaomi
com.android.inputsettings.overlay.miui
com.miui.settings.rro.device.systemui.overlay
com.miui.system.overlay
com.miui.systemui.devices.overlay
com.miui.systemui.overlay.devices.android

The most important one in that list is this:

com.xiaomi.touchservice

If the goal is to improve handwriting, messing with something called touchservice would be idiotic. Maybe it is not directly responsible for the pen, but it is too close to the critical area to play games with it.

I also chose not to remove the wallpaper components:

com.miui.miwallpaper
com.miui.miwallpaper.overlay
com.miui.miwallpaper.overlay.customize
com.miui.miwallpaper.config.overlay
com.miui.wallpaper.overlay
com.miui.wallpaper.overlay.customize
com.miui.aod

Could I have been more aggressive? Yes.

But the likely gain is small, and the chance of creating some annoying system behavior is not worth it.

The Main Debloat

The removal was done with:

adb shell pm uninstall --user 0 package.name

This method removes the app only for the current user. It does not physically delete the app from the system partition. That is good, because it usually allows restoration later.

The main block was this:

adb shell pm uninstall --user 0 com.miui.analytics
adb shell pm uninstall --user 0 com.miui.msa.global
adb shell pm uninstall --user 0 com.miui.miservice
adb shell pm uninstall --user 0 com.mi.globalbrowser
adb shell pm uninstall --user 0 com.miui.videoplayer
adb shell pm uninstall --user 0 com.miui.player
adb shell pm uninstall --user 0 com.miui.yellowpage
adb shell pm uninstall --user 0 com.xiaomi.payment
adb shell pm uninstall --user 0 com.xiaomi.barrage
adb shell pm uninstall --user 0 com.xiaomi.ugd
adb shell pm uninstall --user 0 com.xiaomi.discover
adb shell pm uninstall --user 0 com.miui.thirdappassistant
adb shell pm uninstall --user 0 com.miui.bugreport
adb shell pm uninstall --user 0 com.xiaomi.mtb
adb shell pm uninstall --user 0 com.xiaomi.miralink
adb shell pm uninstall --user 0 com.xiaomi.smarthome
adb shell pm uninstall --user 0 cn.wps.xiaomi.abroad.lite
adb shell pm uninstall --user 0 com.miui.fm
adb shell pm uninstall --user 0 com.miui.fmservice
adb shell pm uninstall --user 0 com.miui.screenrecorder
adb shell pm uninstall --user 0 com.miui.weather2
adb shell pm uninstall --user 0 com.miui.notes
adb shell pm uninstall --user 0 com.miui.qr
adb shell pm uninstall --user 0 com.xiaomi.scanner
adb shell pm uninstall --user 0 com.google.android.apps.youtube.music
adb shell pm uninstall --user 0 com.google.android.videos

Not everything was removed. Some packages returned this error:

Failure [-1000]

That happened with a few apps like screen recorder, weather, notes, and scanner. It is not the end of the world. It just means the system blocked the removal of those packages for the current user.

The important stuff did come out:

• analytics;
• MSA/advertising;
• Mi Browser;
• Mi Video;
• Mi Music;
• Xiaomi payments;
• extra services;
• bug report tools;
• preinstalled WPS;
• FM;
• YouTube Music;
• Google TV.

That already clears out a decent amount of garbage.

What to Do When Failure [-1000] Shows Up

My decision was not to push too hard.

You can try disabling instead of uninstalling:

adb shell pm disable-user --user 0 com.miui.screenrecorder
adb shell pm disable-user --user 0 com.miui.weather2
adb shell pm disable-user --user 0 com.miui.notes
adb shell pm disable-user --user 0 com.xiaomi.scanner

But if the system refuses, fine. The performance gain from those idle apps is small. Fighting protected system apps can quickly become a waste of time.

Debloating needs a goal. The goal here is handwriting fluidity, not winning a holy war against every Xiaomi package.

Rebooting the Tablet

After removing the packages, I rebooted:

adb reboot

This is mandatory. Testing after debloating without rebooting is a bad test.

Settings That Actually Matter

Removing bloat helps, but it does not solve everything.

For stylus writing, some system settings are just as important as debloating.

1. Set the Refresh Rate to 90 Hz

On the tablet:

Settings → Display → Refresh rate

Select:

90 Hz

or:

High

If the tablet is running at 60 Hz or using a conservative automatic mode, handwriting can feel more delayed. For pen input, predictability matters.

2. Disable or Reduce Animations

First, enable Developer Options:

Settings → About tablet → tap "OS version" several times

Then go to:

Settings → Additional settings → Developer options

Change:

Window animation scale: 0.5x
Transition animation scale: 0.5x
Animator duration scale: 0.5x

If the system still feels heavy:

Off

This does not directly change pen latency, but it removes that dragged-through-mud feeling from the system.

3. Turn Off Memory Extension

On the tablet:

Settings → Additional settings → Memory extension

or:

Settings → About tablet → RAM → Memory extension

Disable:

Memory extension

Then reboot.

This part is counterintuitive, because marketing sells “more RAM” as a good thing. But on a device with slower storage, virtual memory can create micro-stutters.

For handwriting, micro-stutters are worse than an app reloading.

Better to have less multitasking and more immediate response.

4. Remove Battery Restrictions from the Writing App

For Noteshelf:

Settings → Apps → Manage apps → Noteshelf → Battery saver

Select:

No restrictions

This also applies to Squid, JNotes, Nebo, OneNote, or Xodo.

If the system tries to save battery while you write, the experience can become bad. Fluid handwriting needs fast response, not aggressive power saving.

5. Disable Battery Saver While Writing

On the tablet:

Settings → Battery

Disable:

Battery saver
Ultra battery saver

If there is a performance mode, use it while writing.

You cannot demand low latency while the system is trying to cut processing.

6. Reduce Useless Notifications

On the tablet:

Settings → Notifications & status bar → App notifications

Disable notifications from apps that do not need to wake the system:

• Themes;
• Weather;
• Xiaomi Notes, if you do not use it;
• Scanner;
• Gallery, if you do not need it;
• Security, except important alerts;
• any useless preinstalled app.

A notification is an interruption.
An interruption wakes an app.
A woken app competes for resources.
On a weak tablet, that matters.

7. Clean Up the Home Screen

I removed unnecessary widgets and avoided live wallpapers.

Recommended setup:

• static wallpaper;
• no weather widget;
• no side feed;
• no news cards;
• no visual nonsense.

The tablet does not need to look like a carrier store demo unit. It needs to open the notes app and respond to the pen.

Tuning Noteshelf

The original idea was to use Noteshelf. It is beautiful, organized, and good for digital notebooks.

But beautiful usually costs resources.

So the configuration needs to be conservative:

• use simple pages;
• avoid heavy templates;
• avoid too many huge notebooks;
• avoid massive PDFs;
• split large PDFs by chapter;
• avoid constant syncing;
• avoid recording audio while taking notes;
• avoid real-time handwriting recognition if it feels heavy;
• avoid AI features or extras that process things in the background.

The rule is simple: fluidity first, decoration later.

Alternative Apps Worth Testing

Noteshelf may work well, but I would not treat it as the only option.

For fluid writing on limited hardware, I would test in this order:

1. Squid;
2. JNotes;
3. Noteshelf;
4. Nebo;
5. OneNote;
6. Xodo, mainly for PDFs.

The correct test always starts on a blank white page.

If a blank page stutters, the problem is the system, screen, pen, app, or hardware. If the blank page works fine but PDFs stutter, the problem is probably the PDF or the way the app renders the document.

Final Test After Debloating

After everything, the test needs to be clean:

1. reboot the tablet;
2. wait about two minutes;
3. close recent apps;
4. open only the notes app;
5. create a simple blank page;
6. write quickly for five minutes;
7. repeat in Squid, JNotes, and Noteshelf;
8. only then test PDFs.

If Noteshelf stutters but Squid and JNotes behave well, the problem is the weight of Noteshelf on this hardware.

If all of them stutter, the limitation is deeper: screen, pen, touch layer, hardware, or HyperOS.

How to Restore a Removed Package

If something breaks, you can try restoring a package with:

adb shell cmd package install-existing package.name

Example:

adb shell cmd package install-existing com.mi.globalbrowser

That is why I used pm uninstall --user 0. It is much less dangerous than deleting system partition files with root.

Automated Script

After the manual process, I also created a PowerShell script to automate this debloat on Windows.

The idea of the script is to:

• check whether ADB exists;
• try to install Platform Tools through winget, if needed;
• confirm that the tablet is connected;
• check whether the codename is xun;
• export the package list;
• apply the recommended debloat;
• offer extra options;
• generate a log;
• allow package restoration.

This makes it easier to save as a Gist and repeat the process without relying on memory or copying loose commands around.

Expected Result

This process does not perform miracles.

The Redmi Pad SE remains an entry-level tablet. It does not become an iPad Pro. It does not become a Galaxy Tab S with an S Pen. It does not gain a premium digitizer, and it does not suddenly have RAM to spare.

But the process removes a lot of junk, reduces useless services, cuts ads, removes duplicate apps, and leaves the system less burdened.

The goal is simple:

less bloat,
fewer useless processes,
fewer interruptions,
less micro-stuttering,
more focus on writing.

If, after all this, the tablet still cannot deliver acceptable handwriting, then the conclusion is harsh but honest: the limit was not only software. The hardware and pen experience of the Redmi Pad SE may simply not be good enough for heavy handwriting use.

In that case, the next options would be:

1. test a lightweight custom ROM, such as LineageOS, accepting the risk;
2. change the writing app;
3. use lighter PDFs;
4. or accept that, for serious handwriting, the right path is a tablet with a proper active pen and better hardware support.

The good part is that ADB debloating is the best first step: it improves what can be improved without unlocking the bootloader, without root, and without turning the tablet into a paperweight.

Summary of the Main Commands

Confirm device:

adb devices

Confirm model:

adb shell getprop ro.product.device
adb shell getprop ro.product.model
adb shell getprop ro.product.name
adb shell getprop ro.build.version.release
adb shell getprop ro.miui.ui.version.name

Save package list:

adb shell pm list packages > "$env:USERPROFILE\Desktop\pacotes-redmi-pad-se.txt"

Main debloat:

adb shell pm uninstall --user 0 com.miui.analytics
adb shell pm uninstall --user 0 com.miui.msa.global
adb shell pm uninstall --user 0 com.miui.miservice
adb shell pm uninstall --user 0 com.mi.globalbrowser
adb shell pm uninstall --user 0 com.miui.videoplayer
adb shell pm uninstall --user 0 com.miui.player
adb shell pm uninstall --user 0 com.miui.yellowpage
adb shell pm uninstall --user 0 com.xiaomi.payment
adb shell pm uninstall --user 0 com.xiaomi.barrage
adb shell pm uninstall --user 0 com.xiaomi.ugd
adb shell pm uninstall --user 0 com.xiaomi.discover
adb shell pm uninstall --user 0 com.miui.thirdappassistant
adb shell pm uninstall --user 0 com.miui.bugreport
adb shell pm uninstall --user 0 com.xiaomi.mtb
adb shell pm uninstall --user 0 com.xiaomi.miralink
adb shell pm uninstall --user 0 com.xiaomi.smarthome
adb shell pm uninstall --user 0 cn.wps.xiaomi.abroad.lite
adb shell pm uninstall --user 0 com.miui.fm
adb shell pm uninstall --user 0 com.miui.fmservice
adb shell pm uninstall --user 0 com.miui.qr
adb shell pm uninstall --user 0 com.google.android.apps.youtube.music
adb shell pm uninstall --user 0 com.google.android.videos

Reboot:

adb reboot

Restore package:

adb shell cmd package install-existing package.name

The Redmi Pad SE is not absolute garbage, but it comes loaded with too much crap for what it offers. HyperOS tries to sell a feature-rich experience, but on a device with 4 GB of RAM, that has a price.

For anyone who wants to use a pen and write smoothly, the smartest path is to cut weight:

• debloat through ADB;
• enable 90 Hz;
• turn off memory extension;
• reduce animations;
• remove battery restrictions from the writing app;
• disable useless notifications;
• use lighter writing apps;
• use smaller PDFs.

This does not turn the tablet into another device. But it removes a lot of the dirt that was in the way.

And sometimes optimizing a cheap tablet is exactly that: stop expecting miracles and start removing everything that gets in the way.

And that was it. I had a little Cessna-style jet in my hands. It was not the most powerful thing in the sky, but it flew.

Script link: https://gist.murad.host/pablo/568220483839436d99c97861ad2d5a03

The other sites in the same vein followed the same path: they were destroyed and rebuilt, tested, adjusted, and remade. Nothing stayed. Everything was temporary.

And I have to confess, this has been very interesting. I’ll probably keep testing things for a while longer until I find myself in this whole “indie” world. The truth is, I don’t want to talk about myself. I want to create, and to create, maybe I need to understand first.

Personal websites follow a different logic than systems. I don’t keep changing systems, and my systems stay intact. They are things I consider good enough, and I’m not arrogant enough to touch them unless it’s to fix small bugs.

Anyway, the truth is that I don’t think I want to talk about myself. Don’t trust the creature, trust the creator. If you’re reading this post on this blog right now, maybe in a week it won’t even exist anymore.

To talk about the next steps, I first need to talk about what I’ve been up to.

I rented another VPS from Contabo — I really like them, first-class service in my opinion, and the best part is that it’s raw: do it yourself — and turned this small, simple VPS into a Pangolin server, to escape Cloudflare’s claws. But I ran into some problems, as I wrote about in Exposing self-hosted streaming behind CGNAT.

I also took the opportunity to bring my blog, the one you’re reading right now, closer to the IndieWeb without changing its core, only its theme, as I explained in Teaching Ghost to speak IndieWeb.

On that VPS running Pangolin, I placed a few services that are hosted behind CGNAT so they could be exposed to the internet, such as Noctem Café, which is an absolutely experimental pubnix running on OpenBSD — my first time messing with this OS.

I also managed to turn a port-scanning tool, ncat, into a posting tool using the SOLED/2 protocol. You can check out the small and pleasant result at Soledade City.

I could list all the services I’m exposing and hosting, but I don’t know, it doesn’t make much sense right now, and there’s quite a lot of stuff — I’m feeling lazy. Maybe I’ll write a post in the future exclusively about self-hosting and how I manage it all.

I also finally found the courage to stop the specific attacks I was receiving on my servers by moving a good part of my infrastructure into the Tailnet, as I wrote in The night we put Forgejo behind the Tailnet.

Even though the article talks about Forgejo, it was just the first service I pulled away from the surface. After that, I took a whole bunch with it. 😊

Anyway, everything was created, destroyed, and rebuilt several times, in several different ways, so I could learn. And that’s fine. I’ve learned a lot, and the more I know, the more I want to know.

All I know is that it’s hard to reconcile my work time with my experiments. At least sleeping very little is already something I do, hehe, and in the dead of night, the lab comes alive.

When I say the administration is rough, above are some servers I manage and others I help manage, covered up and censored.

That’s it. Let’s go, because there’s more coming.

I like Ghost. It's lightweight, open source, writes well, and stays out of the way. But Ghost was born as a publishing and newsletter platform — not as a citizen of the IndieWeb. It doesn't publish an h-card for my identity, doesn't mark up my posts with h-entry, and has no idea how to send or receive webmentions. To a machine, my site was just nice-looking HTML: humans could read it, software understood almost nothing.

The idea behind this experiment was simple: keep Ghost exactly as it is — no plugin, no fork, no extra server humming away beside it — and still get my site talking to the open web. Everything you see here lives in the theme (Handlebars plus a little CSS and JavaScript) and in one free hosted service. Not a single line of server code.

And I gave myself one non-negotiable rule: don't lose 1% of the look. The blog is a lean little list, almost a retro directory. Anything I added had to be either invisible or as understated as everything else.

Identity first: the invisible h-card

Everything on the IndieWeb starts with proving who you are. You do that with microformats — a handful of class names you bolt onto your existing HTML so software can pick out your name, photo, URL, email, and profiles. The h-card is the semantic business card.

In my case, I didn't want a card showing up on screen; I wanted only machines to read it. The solution was a hidden h-card block at the top of every page, using the hidden attribute. Readers see nothing; IndieWeb parsers read the HTML just fine, because they ignore CSS.

Alongside it, I scattered rel="me" links to my profiles (GitHub, Codeberg, SourceHut, Mastodon, and so on). That's what cements "this domain and these accounts are the same person." The detail almost everyone forgets: rel="me" only closes the loop if the profile links back to your domain too. Without the return link, the verification never happens.

Posts machines can read: h-entry

Identity sorted, the posts were next. h-entry is the microformat that marks each post as an "entry" — with a title (p-name), content (e-content), publish date (dt-published), canonical URL (u-url), author, and categories.

The beauty of it is that, again, it's just class names added to elements that were already there. The <article> got h-entry, the <h1> got p-name, the body got e-content. The post's tags became p-category. The author sits embedded as a hidden p-author h-card, reusing the same photo from my card.

The one technical thing that needed care was the date. dt-published wants an ISO 8601 format with a timezone, and the theme only showed day/month. The fix was to split the two apart: the datetime attribute holds the full machine-readable date, while the text on screen stays exactly as it was. The reader sees "05 Jun"; the parser sees 2026-06-05T23:51:21-03:00. Zero visual change.

I marked up both the individual posts and the home listing — because IndieWeb feed readers consume both.

Receiving conversations: webmentions with no server

This is where it gets interesting. Webmention is the open web's way of doing what likes and comments do inside social networks — except between independent sites. When someone replies to or mentions one of my posts from their own site, I get notified, and it can show up as a comment here.

The catch: receiving a webmention, in theory, needs a server to validate and store each notification. I didn't want to run that. The way out was webmention.io, a free hosted service that does all the heavy lifting. On my end, all it took was announcing its address with a single invisible line in the <head>:

<link rel="webmention" href="https://webmention.io/yourdomain.com/webmention">

That's it. From there on, any mention of my site gets received, verified, and archived by them. One elegant detail: logging into webmention.io happens through my own domain, using exactly the rel="me" links I'd already added. The pieces clicked together.

(I made a deliberate choice not to enable legacy pingbacks — they pull in way too much spam.)

Displaying it my way

Receiving is half the story; I wanted to show these conversations — but in my own style, not in some generic third-party widget fighting the blog's look.

I went with a small bit of my own JavaScript. It reads webmention.io's public API by the post's URL (no key needed), splits reactions (likes, reposts) from replies, and builds the markup by hand. Reactions become a compact row of avatars; replies become a clean list with the same monospaced date and the same dotted line I use on the home page. The commenter's name lights up in the brand color on hover.

And the part that mattered most for the aesthetic: if there are no mentions, the section just doesn't exist. No "0 comments," no empty box. Silence, the way it should be on a minimalist blog.

This is where I closed a funny little loop: I'd turned off Ghost's native comments because I didn't want "discussion" locked inside a membership platform. Webmentions are the open version of that — the conversation happens across the whole web and only echoes here.

What still lives outside

Technical honesty: one half of webmention — sending — still isn't inside the theme, and it doesn't need to be. When I link to another IndieWeb site, I have to fire off a notification to it. That's handled by an external service (like Bridgy or webmention.app) that watches my RSS feed and sends them automatically. The theme only needs solid h-entry markup — which is already there — for those notifications to go out correctly formed.

So: the "passive" half (being an identity, having readable posts, receiving and displaying conversations) all lives in the theme, invisible or understated. The "active" half (reaching out to notify other sites) is a service wired to RSS, no code.

In the end, none of this changes how the blog looks. A distracted visitor won't notice a thing. But underneath, the site stopped being an island. It now introduces itself, proves who it is, marks up its writing in a way any open tool understands, and is ready to receive conversations from any corner of the web — without leaning on Ghost for it, without leaning on any social network.

Ghost is still Ghost. I just taught it a second language — the one the open web speaks — and did it without Ghost (or the reader) ever noticing.

The unpleasant surprise was finding out TIM doesn't give you a public IP, and there was no room to negotiate either. After a string of completely failed attempts, I decided to find another way to expose a few streaming services.

Lucky for me I have a decent grasp of networking, which saved me a lot of grief. But I'd still need to learn more if I wanted the whole thing running properly.

When you're on CGNAT — the famous shared IP — the streaming experience (upload especially) tends to be pretty rough, for two main reasons:

1. Badly configured MTU.
2. UDP ports recycling at absurd speeds.

There are a few other causes out there, but those two are the ones that really make it miserable. It's also why so many people try to negotiate a public IP with their ISP, and the same reason FPS gamers get the headaches they do.

So here's what I tried, and what actually worked.

First attempts: Cloudflare and Tailscale

The first thing that came to mind was exposing the services through Cloudflare, using Tunnel, or through Tailscale. I never got around to testing Tailscale.

Cloudflare worked perfectly well — fast, robust, with an excellent keep-alive for dealing with UDP's abrupt changes. But it had a problem, and it was the same one Tailscale had (which is why I didn't bother trying it): under both companies' policies, you can't serve streaming. If you wanted to, you'd have to use their servers, meaning you'd pay for it. The risk is high — they can ban you from the service with no real explanation.

I've got a bunch of services running through Cloudflare and I couldn't take that risk. Moving to Tailscale Funnel was off the table for the same reason. And I didn't want to keep a closed WireGuard-style network where only I had access: my cousins and relatives aren't exactly tech people, and that would cost me setup time. What I wanted was to hand them a domain and have them just open it.

So what now?

Pangolin: good, but only good

Then I remembered Pangolin. Maybe if I grabbed a dirt-cheap VPS and ran Pangolin on it, I could "emulate" what Cloudflare Tunnel offered at a similar level.

The Pangolin container image looked perfect: it runs on Docker and ships with Traefik, Gerbil, and CrowdSec out of the box. Just spin it up, configure the domains, install Newt on the local machines, and done. I'd be streaming from home, behind CGNAT and exposed to the world. Problem solved — or so I thought.

I left it running for about two months, but the sluggishness was getting on my nerves. I hadn't dug into the real causes yet, until I finally had no choice. The setup was good — but only good. And I wanted excellent.

My first move was basic testing: checking routes, DNS, MTU, and so on. Funny enough, even though that wasn't the heart of the problem, I fixed a few unrelated issues along the way. So it did have some minor influence.

But cleaner logs and more precise tests showed what I'd already suspected: UDP and ping/keep-alive. UDP was recycling extremely aggressively, on very short intervals, and for streaming that's pure hell. Picture trying to load video, the player, range requests, a chat WebSocket... all of that needs to flow smoothly.

A new problem that would take some creativity to solve. The decision was to stop trying to make a UDP tunnel behave on an aggressive CGNAT and swap the core of the architecture for a persistent TCP tunnel. But how? I had no idea. So I left it on standby. I didn't have time to mess with my streaming anyway, and it was already up — even if in a less-than-ideal state.

A few weeks went by.

Stumbling onto FRP

I was on the Unraid dashboard, browsing the apps in the store. Then, completely by chance, something caught my eye: FRP. Honestly, I'd never used it, and to me it was just another proxy service like any other. I opened the image out of pure curiosity — you know when you look at something but don't actually see (read) it? I wasn't even thinking about my streaming anymore, and one thing grabbed me: the "F" at the start of FRP, which stands for Fast.

That made me more curious. Why would this one be different? Why fast?

After reading up a bit, the explanation was simple.

FRP (Fast Reverse Proxy) was built specifically to expose local services sitting behind NAT/firewall, using a public server as a relay. The architecture is:

• frps = the FRP server on the VPS with a public IP.
• frpc = the FRP client on the local machine, behind NAT/CGNAT.

The local machine opens an outbound connection to the VPS. The VPS then exposes public ports (temporary or internal), which Traefik later uses as HTTP backends.

Pangolin (Newt/Gerbil) uses a more complete architecture: Traefik + identity + WireGuard/Gerbil/Newt tunnels. It's great as a "platform," but it adds more moving parts. Pangolin's own docs describe Gerbil as the WireGuard tunnel manager and Newt as the edge client.

FRP was made for exactly this — exposing a local service behind NAT/firewall through a public relay server — and it supports TCP, UDP, HTTP, and HTTPS.

In my case, that was the advantage. The two setups boiled down to:

• FRP = a persistent TCP connection going out from the local network → public VPS → Traefik.
• Pangolin = a more sophisticated tunnel/overlay → more dependent on how the tunnel behaves.

The FRP route was better not because FRP is "superior" to Pangolin across the board, but because it solves the actual bottleneck: it stops you from fighting UDP on a bad CGNAT.

The final architecture

External user
  ↓ HTTPS
Traefik on the VPS (Pangolin)
  ↓ internal HTTP to the FRP port
frps on the VPS (Pangolin)
  ↓ persistent TCP tunnel
frpc on the local machine
  ↓
Local media service

On the VPS that already had Pangolin, I basically installed and configured frps (the server) along with a token. Each machine that would act as a client got frpc (the client) with the server's token.

The config was actually simple: bind the IP/port, set the token, validate, and start it.

There was one catch, though: I had to do something slightly different with the Traefik already running on the server. Instead of recreating the resources through the Pangolin UI, I used the dynamic File Provider. The result was striking — the practical gain was immediate.

Before, access through Newt/Pangolin suffered from high TTFB and instability caused by the CGNAT. After switching to FRP, the services started responding instantly and with rock-solid stability.

And yes. It's working.

The change worked because the problem was never just "slow proxy." It was architecture.

Cloudflare Tunnel was fast, but unsuitable as the main solution for heavy self-hosted streaming if you stay within the proper policies. Newt/Pangolin was elegant for exposing private services, but the aggressive CGNAT was wrecking the stability of the UDP path. FRP solved the exact pain point: it created a persistent TCP tunnel between the local machines and the public VPS.

Traefik kept doing what it does well: terminate HTTPS, apply rules per domain, and forward to the internal backends. FRP took over the transport. Each tool ended up in its proper role.

I'll put together a short tutorial soon on how this was set up and how you can do it on your own network.

See you around.

Then, as usually happens on the internet, someone looked at that system and thought: “What if I put files in here?”

And that is exactly what happened.

Usenet does not serve files the way HTTP, FTP, or BitTorrent do. It was not designed to say: “Here is video.mkv, download it.” What Usenet does is store and distribute articles. So the solution was to turn files into articles.

It sounds like a hack, and it is. But it is a very clever hack.

The file is not uploaded as one piece

When someone posts a large file to Usenet, the file is not uploaded as a single block. That would be impractical. Instead, the file is split into many smaller pieces. Each piece is encoded into a format that can travel inside an NNTP message, and those messages are posted to specific newsgroups, usually under alt.binaries.*.

A single file can become hundreds or thousands of separate messages.

The simplified flow looks like this:

original file
→ split into parts
→ encoded into a message-friendly format
→ posted as multiple NNTP articles
→ stored by Usenet servers
→ downloaded by a client
→ decoded
→ reassembled
→ final file

So the Usenet server is not “serving a file” in the traditional sense. It is serving articles. The client understands that those articles, together, form a file.

That distinction matters.

yEnc: the boring but essential magic

In the early days, encodings like uuencode were common. Later, yEnc became the de facto standard for binaries on Usenet.

The role of yEnc is to take binary data and encode it in a way that works inside Usenet messages. It is more efficient than older methods because it wastes less space. When you are dealing with millions of messages and very large files, that difference matters.

So when a file is posted, it is broken into chunks, and each chunk is encoded with yEnc. Each chunk becomes an NNTP article whose body may look like nonsense if you view it raw. But to a Usenet client, it is a perfectly valid piece of a larger file.

The regular user does not need to see this process. The download client handles it automatically.

The alt.binaries.* groups

The file-sharing side of Usenet became strongly associated with the alt.binaries.* hierarchy.

Examples include:

alt.binaries.movies
alt.binaries.multimedia
alt.binaries.sounds
alt.binaries.pictures
alt.binaries.ebooks
alt.binaries.software

The name gives away the purpose: these groups are meant for binary content, not just text conversations.

Technically, a binary file could be posted to other groups too, if the server allows it. But in practice, binaries concentrated in these hierarchies. That also helped servers decide what to accept, what to reject, and how long to keep each kind of content.

Because text is cheap. Binary data is not.

Keeping text discussions for years is relatively easy. Keeping large files for years requires a lot of disk, bandwidth, and administrative discipline.

Why so many RAR files?

Anyone who has dealt with Usenet binaries has probably seen sets like this:

file.part001.rar
file.part002.rar
file.part003.rar
file.part004.rar
...

That is not random. RAR became common because it helps split large files into smaller volumes. If something fails, you do not necessarily need to download everything again. These volumes also fit nicely into the Usenet workflow, where everything is already being broken into many smaller parts.

So the original content is often compressed and split into multiple RAR volumes before being encoded and posted as articles.

In the end, you have layers on top of layers:

original file
→ RAR volumes
→ smaller pieces
→ yEnc articles
→ NNTP messages

It may look excessive, but it solves real problems.

PAR2: insurance against missing pieces

Usenet does not guarantee that every article will arrive intact on every server. One server may miss a part. Another may expire older articles. Another may have corruption. Another may not carry a certain group at all.

That is where PAR2 files come in.

.par2 files are recovery files. They use parity data to rebuild missing or damaged parts. In simple terms, they are mathematical backup material for repairing a download.

A set may look like this:

file.part001.rar
file.part002.rar
file.part003.rar
file.part004.rar
file.vol000+01.par2
file.vol001+02.par2
file.vol003+04.par2

If one or two pieces are missing, the client can use the PAR2 files to repair the set. Of course, there is a limit. If too much is missing, there is no magic fix.

Still, this repair layer is one of the reasons Usenet worked so well for large files. Without PAR2, downloading large binary posts would be much more frustrating.

NZB: the treasure map

Now comes a central piece: the NZB file.

Imagine a file split into 3,000 NNTP articles. How would a user find all those articles manually? They would not. It would be impossible.

The .nzb file solves this. It is basically an index, or a manifest. It lists the Message-IDs of the articles needed to reconstruct a given file.

The client reads the NZB and thinks:

“Alright, I need to fetch these 3,000 articles from the NNTP server.”

Then it connects to the server and starts requesting article after article. Once it has the pieces, it joins them, decodes them, repairs them if needed, and gives the user the final file.

In short:

NZB = map of the articles
NNTP = protocol used to fetch the articles
Usenet server = where the articles are stored
client = software that downloads, repairs, and rebuilds everything

The NZB does not contain the file itself. It contains the instructions for finding the file’s pieces inside Usenet.

It is similar to the difference between a .torrent file and the actual torrent data. The .torrent is not the movie, book, or program. It only tells the client where and how to find the pieces. NZB plays a similar role, but inside the Usenet ecosystem.

Does the server know what it is delivering?

Most of the time, the server does not need to understand the final file. It only stores articles.

An NNTP client asks for something like:

ARTICLE <some-message-id>

The server responds with the corresponding article. The body of that article contains an encoded chunk, usually in yEnc. To the server, it is just a message. To the client, it is part of a larger file.

That separation is the whole trick.

The intelligence is mostly on the client and indexer side, not in each individual server.

The role of commercial providers

Today, when people talk about downloading from Usenet, they are usually talking about commercial providers. These providers sell access to servers with high retention, high speed, multiple connections, and SSL/TLS.

The key word here is retention.

Retention means how long the provider keeps articles available. For text groups, keeping years and years of material is relatively cheap. For binary groups, keeping years of content requires massive infrastructure.

When a provider says it offers thousands of days of binary retention, it is saying that it keeps old binary articles for many years. That is expensive, because the amount of data in binary groups is enormous.

That is why modern binary Usenet is not exactly a garage hobby. A text-only server can run on a small VPS. A serious binary server requires huge storage, heavy bandwidth, and a very clear abuse policy.

Usenet is not torrenting

People often compare Usenet with BitTorrent, but the logic is very different.

With BitTorrent, users download pieces from each other. A file exists as long as there are seeders. You participate in a peer-to-peer swarm.

With Usenet, you download from a server. You do not need to upload pieces to other users. Availability depends on the retention of the server or provider, not on seeders.

Put simply:

BitTorrent:
- users share with each other
- depends on seeders
- decentralization lives in the peer swarm
- you usually upload while downloading

Usenet:
- you download from NNTP servers
- depends on provider retention
- decentralization comes from the old server federation model
- you do not need to upload to other users

Usenet ends up feeling more like downloading from a premium server, even though underneath it all there is this older structure of articles, groups, propagation, and retention.

Can you run a server like that?

Technically, yes.

Practically, that is a different conversation.

Running a text-only NNTP server is completely realistic. You install something like INN, create a few groups, control access, configure TLS, and use it with an NNTP reader. For learning, small communities, or internal projects, it is a great experiment.

Running a public or federated binary server is much heavier. You need to deal with:

huge storage requirements
heavy bandwidth
short or expensive retention
spam
abuse
problematic content
legal notices
authentication
peering
queues
constant monitoring

If you accept groups like alt.binaries.*, data growth can become brutal. This is not something you throw onto a cheap VPS and forget about.

If the goal is to learn, the smart path is to create a small private binary group, for example:

local.binaries.test

Then you can post small files, see how yEnc works, generate NZBs, download with a client, and understand the whole flow without drowning in terabytes of data and legal headaches.

The short version

Usenet serves files without really being made to serve files.

It stores articles. People learned to break files into pieces, encode those pieces, post them as NNTP messages, and reconstruct the file on the other side.

The complete process looks like this:

original file
→ compression/splitting into RAR volumes
→ yEnc encoding
→ posting as NNTP articles
→ storage on Usenet servers
→ NZB indexing
→ client download
→ PAR2 repair
→ final file reconstruction

It is old, strange, and a little underground, but it is also incredibly clever. The modern web tries to hide complexity behind polished buttons. Usenet does not. Usenet shows the gears. And maybe that is exactly what makes it so interesting.

That is the world of debrid services.

But the name is a little misleading. “Debrid” is not one single technology, like “PostgreSQL” or “Docker”. It is more like a bundle of things: cache, high-bandwidth servers, file-hoster integration, remote downloading, temporary storage, APIs, and a convenience layer on top. At the core, these services are intermediaries: they sit between you and external file sources, turning an ugly experience — slow, limited, broken, full of friction — into something direct.

The short version is this: a debrid service takes a link or magnet, resolves it on its own infrastructure, downloads it or reuses an existing cached copy, and gives you a fast HTTP link or stream.

The interesting part is what happens underneath.

Debrid services do not “have everything”. They resolve and cache.

The first common mistake is thinking that a debrid service is some hidden pirate Netflix with a neatly organized internal library. Not exactly. Technically, most of these services do not start from an editorial catalog of their own. They work from what users submit.

You send a file-hoster link, a magnet, a torrent, an NZB, or a URL. The system checks whether that exact content is already cached. If it is, the response can be almost instant. If it is not, the service queues the job, downloads the file on its own servers, and then makes it available to you.

That is why sometimes you click something and it “appears” immediately. It is not because the server downloaded 80 GB in three seconds. It is because someone, at some point, requested the same thing before, and the service kept a reusable copy.

That is the economic heart of the business: shared cache.

The cost of downloading and storing a popular file once can be spread across thousands of users. An obscure old file is the opposite: it costs more, relatively speaking. It consumes storage, burns bandwidth, and may never be touched again. These services live by balancing retention, popularity, disk cost, and traffic cost.

The basic architecture

If I had to describe a debrid service in a simple but honest way, it would have these parts:

1. Frontend
   Website, app, browser extension, or integration with Stremio, Kodi, Plex, rclone, JDownloader, Radarr/Sonarr, and similar tools.

2. API
   Almost everything runs through an API. The user submits links, checks status, lists files, generates direct links, and removes items. Real-Debrid, AllDebrid, Premiumize, and TorBox all expose public or documented APIs at some level.

3. Queue system
   When a link or magnet is not ready, the service has to queue the work: download, verify, extract, maybe rename, maybe prepare metadata, maybe publish links.

4. Download workers
   Machines specialized in fetching content. They may use BitTorrent clients, multi-connection HTTP downloaders, Usenet clients, direct download handlers, or source-specific modules.

5. Cache and deduplication
   The system tries not to store the same thing ten times. Torrents have hashes. Files can be identified by size, checksum, piece hash, metadata, origin, or internal signatures.

6. Storage
   Cheap HDD storage for bulk volume. SSD/NVMe for hot cache, metadata, databases, in-progress chunks, and high-IOPS workloads.

7. Delivery
   Direct HTTP, streaming with range requests, WebDAV, apps, web player, CDN, or edge servers. For video, the key is seek support: you jump to minute 50 and the server needs to deliver that part without making your device download the entire file first.

8. Abuse control
   Per-user limits, per-hoster limits, rate limits, blocked links, takedown handling, operational logs, fraud controls, and compliance mechanisms.

None of this is exotic. The hard part is running it at scale without bleeding money on bandwidth and disks.

How do you program something like this?

You can build a small, legal, limited home version with common tools: aria2 for HTTP/FTP/SFTP/BitTorrent, libtorrent or qBittorrent for torrents, a Usenet client for NZBs, a database, a queue like Redis or RabbitMQ, local or S3-compatible storage, and an API written in Go, Rust, Python, Node, or any solid language.

But that would only be a cloud downloader. A commercial debrid service is more annoying.

Downloading a file is not the hard part. Any script can do that. The hard part is:

• controlling thousands of concurrent downloads;
• avoiding useless duplication;
• prioritizing hot cache;
• dealing with broken sources;
• monitoring each hoster’s limits;
• generating secure temporary links;
• making streaming seek work properly;
• keeping speed predictable;
• preventing one user from destroying the whole infrastructure;
• deciding when to delete files;
• handling legal complaints;
• running payments, support, fraud, and chargebacks.

A typical backend would probably be split into multiple services. One receives the request. Another validates and normalizes the link. Another checks the cache. Another schedules the download. Another executes it. Another verifies integrity. Another publishes the file. Another generates signed URLs. Another handles statistics and quotas.

A modern implementation could look roughly like this:

API Gateway
↓
Auth / Billing / Quotas
↓
Link Resolver
↓
Cache Lookup
↓
Queue
↓
Download Workers
↓
Storage Layer
↓
Streaming / Direct Download Edge

Could this run on Kubernetes? Sure. Does it have to? Not necessarily. Many companies in this space can run perfectly well on dedicated servers, simple queues, strong databases, and custom automation. Sometimes the “ugly but predictable” architecture beats whatever is trendy.

The real secret is cache

Cache is the difference between a profitable service and a money-burning machine.

Imagine one hundred users request the same 40 GB file. If the service downloads it one hundred times, it is stupid. If it downloads it once and serves it one hundred times, the math starts to work.

That is why these services love popular content. Popularity is efficiency. The more people request the same thing, the better the margin.

The retention logic probably works something like this:

• frequently requested content stays longer;
• recently requested content gets priority;
• rare content expires quickly;
• incomplete or broken files are removed;
• expensive storage, like NVMe, is reserved for hot cache;
• large HDD pools hold colder bulk data;
• metadata lives in a fast database;
• user-generated links expire.

We cannot know the exact retention policy of each company. But operationally, it is almost impossible for it not to be something close to this.

How do they “get” content?

This has to be said carefully, because the wording can give the wrong impression.

Debrid services usually do not go out “looking for content” like an editor or a streaming platform. They receive user input. The user provides a link, magnet, torrent, or NZB. The service then tries to fetch it from the indicated source or return an already cached copy.

For file hosters, the service may rely on premium accounts, partnerships, technical integrations, link-resolution infrastructure, or other methods allowed under whatever rules apply to them. For torrents, the content comes from the BitTorrent network: peers, seeders, trackers, and DHT. For Usenet, it comes from Usenet servers and indexers, depending on how the service is built.

The gray area — and the legally sensitive part — is that many users use these tools to access material they do not have the right to access. That does not change the technical architecture, but it completely changes the risk. A service can be used to download a Linux ISO, a public dataset, a personal backup, or copyrighted material. The tool is generic. The use case is what can become a problem.

So, technically, they get content through user-submitted input + external sources + shared cache. Not because they own some magic internal library.

File hosters, torrents, Usenet: three different worlds

A modern debrid service usually relies on three major source types.

1. File hosters

These are file-hosting websites. Many limit speed, require waiting, show captchas, or push users toward paid accounts. The debrid service works as an intermediary: it resolves the link and gives the user a more convenient delivery path.

This is the classic debrid model.

2. Torrents

Here the service behaves like a simplified seedbox. It takes the magnet or torrent, downloads it in a data center, and then delivers it to the user over HTTP or streaming. If the torrent is already cached, the result is instant.

This model is very strong for media players and streaming apps.

3. Usenet

Some services also support NZB/Usenet. In that case, the download comes from Usenet servers, not from BitTorrent peers. It is a different ecosystem, with its own providers, retention windows, indexers, and rules.

Average infrastructure: what kind of servers are we talking about?

There is no universal number here. Real-Debrid, AllDebrid, Premiumize, TorBox, put.io, Seedr, and commercial seedboxes do not publish complete infrastructure blueprints. But we can estimate from comparable services and public seedbox specs.

Public seedbox providers often advertise 1 Gbps, 10 Gbps, 40 Gbps, 50 Gbps, and even 100 Gbps shared networking, depending on the plan and provider. Whatbox, for example, lists HDD plans with shared 40 Gbps networking and NVMe plans with 100 Gbps in public plan listings. Ultra.cc advertises NVMe-powered servers on a 25+25 Gbps / 50 Gbps shared network. Those numbers do not mean each user gets that speed alone; they are almost always shared capacity.

For storage, there are two worlds:

• Large HDD storage: 2 TB, 4 TB, 8 TB, 16 TB, 20 TB+ per plan or server, good for bulk storage.
• Smaller but fast NVMe storage: hundreds of GB to a few TB per plan, good for hot cache and fast operations.

For CPU, the main bottleneck is usually not processing power unless video transcoding is involved. For direct downloads and direct streaming, network and disk matter more. For Plex/Jellyfin-style transcoding, CPU and GPU suddenly matter a lot.

A typical machine for this kind of operation could look like this:

Dedicated storage/cache server:
- CPU: Xeon, EPYC, or server-grade Ryzen
- RAM: 64 GB to 256 GB
- Disk: multiple 12-22 TB HDDs or an NVMe pool
- Network: 10 Gbps or more
- System: Linux
- Role: cache node, download worker, streaming edge, or storage node

For a large commercial service, it is not “one server”. It is a fleet. Some nodes download. Some store. Some serve. Some handle metadata. Some sit at the edge to deliver traffic.

Data centers: where does this run?

This type of service usually likes data centers with three traits:

1. Cheap bandwidth
2. Good international connectivity
3. Operational tolerance for heavy traffic

Europe appears a lot in this world, especially the Netherlands, France, Germany, and other countries with strong data center markets and competitive transit pricing. The United States also appears, but the legal and copyright environment can be more aggressive. Singapore and other regions come into play when a service wants better latency for Asia.

This does not mean “lawless territory”. It means bandwidth, cost, and jurisdiction matter. A lot.

Why does the user pay?

The user pays because the service buys three difficult things for them:

• bandwidth
• storage
• convenience

You are not paying only for the file. You are paying to avoid maintaining a server, configuring a torrent client, dealing with file hosters, leaving a PC on, suffering with residential upload, waiting for captchas, or building a media pipeline.

It is the difference between “I can do this myself” and “do I really want to administer this?”

For a technical user, debrid can look like laziness. But operational laziness is a perfectly valid product. Half the SaaS world exists because of it.

Debrid vs seedbox vs put.io

The honest comparison:

Debrid:
best for fast links, cache, Stremio/Kodi, cheap convenience.

Seedbox:
best for private trackers, ratio, control, FTP/SFTP, apps, Plex/Jellyfin.

put.io / Seedr / Bitport:
best for a simple cloud downloader with a temporary library.

Self-hosted VPS:
best for people who want full control and accept maintenance.

Debrid is more of a fast bridge. A seedbox is more like your own remote server. put.io is more like a cloud downloads folder. A VPS is “do it yourself and accept the consequences”.

The business model

The model only works if most users consume less than they think they will.

Like any “unlimited” or “almost unlimited” service, this is a statistical game. Many users pay and barely use it. A few users hammer it. The service applies limits, quotas, short retention, fairness rules, queues, variable speeds, or hoster-specific restrictions to keep the whole thing alive.

The margin comes from:

• reused cache;
• controlled overselling;
• temporary storage;
• negotiated bulk traffic;
• plans with explicit or implicit limits;
• occasional users subsidizing heavy users;
• strong automation to reduce support load.

If every subscriber suddenly decided to download tens of terabytes per month, the math would break quickly.

The legal and ethical part

There is no point pretending this market is squeaky clean. Debrid, seedboxes, and cloud downloaders have legitimate uses, but they are also widely used to access copyrighted material. That is the elephant in the room.

The technology itself is neutral: downloading a Linux ISO through a debrid service is not the same thing as downloading a newly released film without a license. But technical neutrality does not erase legal responsibility. Operators have to deal with takedowns, abuse, payments, payment processors, copyright pressure, and unstable hosters.

For the user, the rule is simple: if the content requires a subscription, purchase, or license, using an intermediary to get around that can put you in ugly legal territory. And for the operator, building this kind of service without legal counsel and abuse policies is asking to get hit.

Why is this so interesting?

Because debrid is sophisticated duct tape. It combines heavy infrastructure with an extremely simple user experience. From the outside, it looks like “paste link, get file”. Under the hood, it is queues, cache, networking, disks, quotas, APIs, state polling, workers, storage, and cost engineering.

It is the kind of service that exposes an uncomfortable truth about the internet: sometimes the difference between a bad experience and a good one is not the content itself. It is the delivery layer.

The file may already be somewhere. The problem is getting to it without wasting time, patience, and bandwidth. Debrid services sell exactly that: a cleaner route through a mess that already exists.

It is not magic. It is not always elegant. And it is not always defensible. But technically, it is fascinating.

That's it... see you.

As usual — and honestly, it couldn’t have been any other way — I had a week packed with work. And of course, I mixed that with personal projects, which left me with almost no time to... sleep. Truth is, I haven’t been sleeping much for a long time now.

This week, I decided to put the ordinary worries of corporate life aside for a bit and focus on organizing everything I had created during whatever “free time” I managed to find.

I started by opening the folder where I had dumped EVERYTHING I had written. And everything I had researched.

The idea had been simple: I would create a text file for each research topic, each exercise, each translation, each piece of writing, and so on.

My surprise was realizing that the folder itself had become a monstrosity — something I had let grow completely out of control over the past two years. At that point, I would probably need more time to organize it than I had spent creating it.

So I decided to pay for one month of Claude and put my friend over there to work organizing my files. A way to save time. And no, I’m not possessive about what I create, nor am I afraid of being “stolen from.”

Once my little monster — the archive — was finally organized, I had an idea. I asked it to generate some stats on what had been produced, and one number really stood out:

8.2 million words.

Kind of terrifying, right?

But that’s it.

I’m very tired today. I’d like to talk more about it, but I’ll leave that for sometime next week.

At first glance, the usual suspects appeared: Nginx workers, database processes, Docker containers, and a few background services minding their own business. But one process kept standing out from the crowd: Forgejo, along with several Git-related commands. The server was not merely busy; it was being worked hard.

The first move was blunt but effective: bring the Forgejo stack down with Docker Compose. Almost immediately, the load began to fall. That was the smoking gun. Forgejo was not just involved; Forgejo was the center of gravity.

From there, the investigation split into two questions:

1. Why was Forgejo consuming so much CPU?
2. How could it be locked down without making it useless?

The answer to the second question shaped the whole plan: Forgejo should not be public. There was only one real user, so leaving a Git service exposed to the entire internet made no sense. Bots, crawlers, scanners, and opportunistic traffic were all invited to knock on the door, and some of them were clearly doing more than knocking.

The goal became simple:

Keep Forgejo fully usable, but only inside the Tailscale network.

First, the Docker Compose configuration was inspected. The web interface was already bound safely to localhost, but the SSH Git port was still exposed publicly. That was a problem. The SSH mapping was changed so it listened only on the server’s Tailscale IP. After recreating the containers, the public Git SSH port was gone, and SSH access was limited to the Tailnet.

Then came the Nginx side of the story.

At first, the wrong Nginx site file was edited. The configuration looked right, but requests still returned 200 OK from the public internet. That was the clue: Nginx was not using the file that had just been changed. A full configuration dump revealed the real active virtual host, generated under a different filename. Once the correct file was found, the fix was applied properly:

allow 100.64.0.0/10;
deny all;

That single rule changed everything. Public requests to the Forgejo domain began returning:

HTTP/2 403

Perfect. The internet was locked out.

But access through Tailscale still worked. A forced test resolving the Forgejo domain to the server’s Tailscale address returned:

HTTP/2 200

That proved the architecture was correct:

Public internet -> blocked
Tailscale network -> allowed

The CPU confirmed it too. Forgejo dropped from hundreds of percent of CPU usage to almost nothing. The server began to breathe again.

The last challenge was DNS.

Editing every client’s hosts file would have worked, but it was ugly. Nobody wants to maintain a pile of manual host overrides across several machines. The better solution was split DNS through Tailscale.

A small dnsmasq service was installed on the server and configured to listen only on the Tailscale interface. It answered one important question:

Forgejo domain -> server Tailscale IP

Testing directly against that DNS server worked. Then the Tailscale admin console was configured to use the server as a custom nameserver for the Forgejo domain. After refreshing the Tailscale clients, machines inside the Tailnet could resolve the Forgejo domain internally, without touching local hosts files.

At the end of the adventure, the setup looked like this:

Forgejo web:
  available only through Tailscale

Forgejo SSH:
  bound only to the server’s Tailscale IP

Public domain:
  blocked by Nginx unless the client comes from the Tailnet

Internal DNS:
  resolves the Forgejo domain to the Tailscale IP

Git clone, pull, and push:
  work normally from Tailnet devices

Random internet bots:
  get a 403 and go bother someone else

The important lesson was simple: exposing a private Git server to the public internet is usually unnecessary risk. Even if registration is disabled and there is only one user, bots can still hammer expensive Git endpoints, trigger pack generation, request archives, crawl diffs, and generally waste CPU.

The clean solution was not to harden the public door forever.

It was to remove the public door.

Forgejo stayed fully functional, but became private to the Tailnet. The server load dropped, the attack surface shrank, and Git access became exactly what it should have been from the start: available to trusted machines only.

Um bom dicionário não deveria apenas matar uma dúvida. Ele deveria abrir uma porta.

Foi essa a provocação que tornou tão interessante o ensaio de James Somers, “You’re probably using the wrong dictionary”. O texto, publicado em seu site, parte de uma reclamação simples e poderosa: boa parte dos dicionários modernos ficou pobre demais para quem se importa de verdade com linguagem. Eles cumprem a tarefa mínima de explicar uma palavra, mas frequentemente falham em mostrar sua vida interior: sua história, seu peso, seus vizinhos, suas diferenças sutis, seu brilho.

Este artigo nasce dessa inspiração. Não é uma tradução do texto de Somers, nem pretende copiá-lo. O crédito, porém, é claro: foi o artigo dele que reacendeu a questão. A partir dali, vale olhar com mais calma para uma ideia estranhamente prática: talvez o melhor dicionário de inglês para carregar no Android seja um livro de 1913.

O problema dos dicionários que apenas “funcionam”

O dicionário comum de hoje é eficiente. E eficiência, neste caso, é parte do problema.

Quando você procura uma palavra em muitos dicionários digitais, recebe uma definição compacta, direta, desenhada para velocidade. Isso é útil quando o objetivo é apenas decodificar uma frase. Mas escrever bem, ler melhor ou pensar com mais precisão exige outra coisa. Exige nuance.

Há uma diferença enorme entre saber mais ou menos o que uma palavra significa e entender quando ela deve ser usada. Uma definição pode dizer que duas palavras são sinônimas. A linguagem real, porém, raramente respeita sinônimos perfeitos. “Coragem”, “bravura”, “audácia”, “ousadia” e “temeridade” moram na mesma vizinhança, mas não são a mesma casa. O mesmo acontece em inglês com centenas de palavras que os dicionários rápidos tratam como se fossem peças intercambiáveis.

Somers chama atenção para isso usando exemplos memoráveis. A força do Webster antigo está menos em listar equivalências e mais em discriminar sentidos. Ele mostra a palavra em movimento, em contexto, com exemplos, citações e uma espécie de inteligência literária embutida. Em vez de reduzir a palavra a uma etiqueta, ele tenta cercá-la por todos os lados.

Esse é o ponto essencial: um dicionário ruim empobrece a relação com a língua sem que você perceba. Ele não apenas oferece respostas fracas. Ele treina o leitor a esperar pouco das palavras.

John McPhee e o dicionário como ferramenta de escrita

Um dos personagens importantes do ensaio de Somers é John McPhee, mestre americano da não ficção literária. McPhee não usava o dicionário só para procurar termos desconhecidos. Ele o usava no processo de revisão, quando queria trocar palavras gastas por expressões mais exatas, mais vivas, mais surpreendentes.

Essa mudança de uso é decisiva.

O leitor comum consulta o dicionário quando tropeça em uma palavra difícil. O escritor sério consulta o dicionário também quando está diante de uma palavra fácil. Na verdade, talvez principalmente aí. Palavras comuns são perigosas porque parecem transparentes. “Flash”, “intention”, “sport”, “power”, “sense”, “field”: termos assim dão a ilusão de já estarem resolvidos. Mas um dicionário bom mostra que não estão.

A utilidade real do Webster de 1913 aparece nesse ponto. Ele transforma o dicionário em uma oficina de precisão. Você vai procurar uma palavra que já conhece e volta com três alternativas melhores, uma distinção que não tinha percebido, uma origem inesperada ou uma formulação que muda o ritmo da frase.

Esse tipo de consulta não é nostalgia. É técnica.

Por que o Webster de 1913 continua importante

O Webster’s Revised Unabridged Dictionary, edição de 1913, pertence a uma linhagem que remonta ao trabalho monumental de Noah Webster. A edição de 1828 do American Dictionary of the English Language foi um marco da lexicografia americana. Webster começou esse projeto no início do século XIX e produziu uma obra com cerca de 70 mil palavras, incluindo milhares que ainda não tinham aparecido em dicionários anteriores. Fontes históricas registram também o esforço de Webster com etimologias e línguas antigas e modernas, algo que ajuda a explicar o caráter ambicioso de sua obra.

A edição de 1913, revisada e expandida dentro da tradição Webster, acabou se tornando especialmente valiosa por outro motivo: está em domínio público. Isso permitiu que fosse digitalizada, redistribuída, adaptada e transformada em formatos úteis para computadores, leitores digitais e celulares.

O Project Gutenberg disponibiliza versões do Webster 1913 sem custo, e há também cópias pesquisáveis na web, como projetos dedicados exclusivamente a tornar esse dicionário mais acessível. Em outras palavras: não estamos falando de uma relíquia trancada numa biblioteca. Estamos falando de uma obra antiga, sim, mas surpreendentemente portátil.

E aqui vem o detalhe curioso: justamente por ser antigo, o Webster 1913 muitas vezes parece mais vivo do que seus concorrentes modernos.

Isso não significa que ele seja perfeito. Não é. Ele é datado em vários aspectos. Algumas palavras mudaram de sentido; outras surgiram depois; certos exemplos carregam marcas de época; e qualquer dicionário do início do século XX precisa ser lido com consciência histórica. Usá-lo como única autoridade para vocabulário contemporâneo seria burrice. Mas usá-lo como instrumento de leitura, escrita e exploração vocabular é outra conversa. Aí ele brilha.

Um dicionário antigo para uma mente moderna

A maior virtude do Webster 1913 é que ele não trata a definição como um recibo. Ele a trata como uma pequena peça de pensamento.

Muitos verbetes são longos, discriminativos, cheios de gradações. Ele separa usos, distingue sentidos próximos, oferece exemplos e, às vezes, entrega formulações tão boas que fazem o leitor parar. É um dicionário que parece ter sido escrito por alguém que acreditava que definir bem uma palavra era uma tarefa intelectual séria.

Hoje estamos cercados por ferramentas que respondem rápido. Mas velocidade não é profundidade. O problema de uma definição curta demais é que ela pode ser correta e ainda assim ser insuficiente. Quem escreve precisa de algo mais do que “significa X”. Precisa saber se a palavra carrega ironia, solenidade, aspereza, delicadeza, pedantismo, vulgaridade, antiguidade, energia, precisão técnica ou sabor literário.

Um exemplo simples: quando uma palavra é definida apenas como “pomposo”, você aprende pouco. Quando ela é definida como linguagem inflada além da dignidade do assunto, você aprende uma relação. Aprende que o problema não está só na grandiloquência, mas na desproporção entre estilo e matéria. A palavra deixa de ser uma etiqueta e vira uma ferramenta crítica.

Esse é o tipo de diferença que muda a escrita.

Por que instalar no Android?

Porque o melhor dicionário é aquele que está perto quando você está lendo.

No computador, é fácil abrir uma aba, pesquisar, comparar fontes. No celular, a preguiça vence. Se a consulta exige muitos passos, você simplesmente não consulta. Por isso, ter o Webster 1913 instalado offline no Android muda o jogo. Ele deixa de ser uma curiosidade de navegador e passa a virar uma ferramenta de leitura diária.

Imagine três situações.

Você está lendo um romance em inglês e encontra uma palavra que conhece vagamente. O dicionário moderno te dá uma equivalência apressada. O Webster antigo te mostra a família de sentidos e talvez uma citação literária. Você volta ao parágrafo entendendo melhor a frase.

Você está escrevendo um artigo, uma legenda, uma análise ou um texto acadêmico em inglês. Quer trocar uma palavra frouxa por outra mais precisa. Em vez de pedir a uma ferramenta qualquer um sinônimo genérico, você consulta o dicionário como quem afia uma lâmina.

Você está estudando inglês em nível intermediário ou avançado. Já não precisa apenas traduzir palavras. Precisa perceber diferença de registro, intenção, uso. Nesse estágio, um dicionário rico vale mais do que uma lista infinita de flashcards.

Instalar o Webster 1913 no Android é menos sobre fetiche vintage e mais sobre criar um atrito produtivo. Você passa a conviver com definições melhores.

O caminho recomendado: ColorDict 3 e formato StarDict

A recomendação prática inspirada no artigo de James Somers é usar o ColorDict 3 no Android, porque ele aceita dicionários no formato StarDict. O StarDict é um formato bastante usado para dicionários offline e compatível com diferentes programas em computadores e dispositivos móveis. O próprio ColorDict se apresenta como um aplicativo compatível com StarDict, com busca em múltiplas fontes, histórico e dados armazenados localmente.

O procedimento geral é este:

1. Instalar o ColorDict 3 no Android.
2. Baixar uma versão do Webster 1913 em formato StarDict.
3. Extrair corretamente os arquivos do pacote.
4. Copiar os arquivos do dicionário para a pasta usada pelo ColorDict.
5. Abrir o aplicativo e conferir se o dicionário foi reconhecido.

O ponto crítico é a extração. Em pacotes StarDict, é comum encontrar arquivos com extensões como .dict, .idx e .ifo. Às vezes eles vêm comprimidos em camadas diferentes, como .tar, .bz2, .dz ou .tgz. Não adianta jogar o arquivo compactado na pasta e esperar milagre. O aplicativo precisa enxergar os arquivos finais do dicionário.

Em instalações tradicionais, esses arquivos ficam em uma pasta chamada:

/dictdata

Dependendo da versão do Android, essa pasta pode ficar no armazenamento interno ou no cartão SD. Mas há uma pegadinha importante: no Android 11 e versões superiores, as regras de acesso a arquivos ficaram mais restritivas, e a própria página do ColorDict na Google Play avisa que a localização dos dados de dicionário mudou por causa de limitações do sistema operacional. Ou seja: se o método antigo não funcionar, provavelmente o problema não é o dicionário. É o Android moderno fechando portas que antes ficavam abertas.

Nesse caso, vale abrir o ColorDict, verificar as instruções internas do próprio aplicativo e observar onde ele espera encontrar os dados. Outra saída prática é usar um gerenciador de arquivos mais competente, como ZArchiver ou similares, para extrair o pacote e mover os arquivos para o local correto.

Usando com leitores de e-book

O uso mais interessante não é abrir o ColorDict isoladamente. É integrá-lo ao ato de leitura.

A recomendação original menciona o FBReader, que permite configurar um dicionário externo. A lógica é simples: você lê um livro, segura uma palavra, e o leitor chama o ColorDict. Assim, o Webster 1913 aparece no fluxo natural da leitura.

A experiência ideal é esta:

• abrir um livro em inglês;
• tocar ou pressionar uma palavra;
• consultar o Webster 1913 sem sair mentalmente do texto;
• voltar à frase com uma compreensão mais fina.

Esse detalhe parece pequeno, mas é decisivo. Ferramentas boas são aquelas que aparecem no momento certo. Um dicionário excelente que fica escondido em uma aba abandonada é menos útil do que um dicionário razoável acessível com um toque. O objetivo é colocar um dicionário excelente onde ele possa ser usado sem cerimônia.

Alternativas e observações práticas

ColorDict 3 é uma recomendação tradicional, mas não é a única possibilidade. Há outros aplicativos Android que lidam com formatos de dicionário offline, como GoldenDict, Aard2 e leitores compatíveis com StarDict ou SLOB. O melhor aplicativo pode variar conforme a versão do Android, o aparelho e a tolerância do usuário a anúncios, limitações ou interfaces antigas.

O importante é entender o princípio:

• você precisa de um aplicativo de dicionário offline;
• esse aplicativo precisa aceitar o formato em que o Webster 1913 foi empacotado;
• os arquivos precisam estar extraídos corretamente;
• o leitor de e-book, se usado, precisa conseguir chamar esse aplicativo.

Se alguma dessas quatro etapas falhar, a instalação vira frustração.

Também é bom dizer o óbvio: o Webster 1913 é um dicionário de inglês. Ele não substitui um bom dicionário português-inglês para quem ainda está aprendendo vocabulário básico. Ele também não substitui dicionários contemporâneos quando o assunto é tecnologia, gíria recente, cultura pop, ciência atual ou termos que ganharam sentido novo depois do século XX.

A escolha inteligente não é abandonar todos os outros dicionários. É adicionar o Webster 1913 como uma camada mais profunda.

Use um dicionário moderno para o inglês vivo de hoje. Use o Webster 1913 para mergulhar no corpo das palavras.

O que se ganha com isso

A resposta curta: precisão.

A resposta longa: você começa a perceber que palavras não são blocos de Lego. Elas têm temperatura, idade, gravidade e direção. Algumas são secas. Outras são cerimoniosas. Algumas servem à conversa. Outras pertencem ao ensaio, ao sermão, ao poema, ao relatório técnico, à piada ou à acusação. Um bom dicionário mostra essas diferenças.

Para quem escreve, isso é ouro.

Escrever mal nem sempre é errar gramática. Muitas vezes é escolher palavras que funcionam, mas não ferem o ponto certo. A frase passa, mas não acerta. O leitor entende, mas não sente a precisão. O Webster 1913 ajuda porque força uma convivência mais exigente com os termos. Ele convida você a trocar aproximação por escolha.

Para quem lê, o ganho é outro: densidade. Textos bons costumam carregar palavras em camadas. Um dicionário pobre nivela essas camadas por baixo. Um dicionário rico devolve profundidade ao texto.

Para quem estuda inglês, o ganho é maturidade. Há uma fase em que o estudante quer saber “o que significa”. Depois vem uma fase mais importante: “por que essa palavra, e não outra?”. O Webster 1913 é especialmente útil nessa segunda fase.

A crítica necessária: não romantize demais

Aqui é preciso ser honesto. Nem tudo que é antigo é melhor. Há muita porcaria velha no mundo, assim como há muita ferramenta moderna excelente. O Webster 1913 não é bom porque é antigo. Ele é bom porque foi feito com um tipo de ambição lexicográfica que hoje nem sempre aparece em produtos digitais rápidos.

Também não convém transformar James Somers, John McPhee ou Noah Webster em santos de altar. A lição não é “volte ao passado”. A lição é mais dura e mais útil: escolha ferramentas que aumentem sua percepção, não apenas sua velocidade.

O melhor arranjo é híbrido. Um bom leitor pode usar:

• um dicionário contemporâneo para usos atuais;
• o Webster 1913 para nuance e profundidade;
• o Wiktionary para etimologia colaborativa e variações;
• corpora e exemplos reais para verificar uso moderno;
• bons tradutores apenas como apoio, nunca como autoridade final.

A inteligência está em saber qual ferramenta responde a qual pergunta.

Instalação resumida no Android

Para quem quer apenas o roteiro prático, fica assim:

1. Instale o ColorDict 3.
2. Baixe o Webster 1913 em formato StarDict.
3. Extraia o pacote até chegar aos arquivos finais, normalmente .dict, .idx e .ifo.
4. Copie esses arquivos para a pasta de dicionários usada pelo ColorDict, tradicionalmente chamada dictdata.
5. Abra o ColorDict e veja se o Webster aparece na lista de dicionários.
6. Coloque o Webster 1913 como prioridade, se o aplicativo permitir.
7. Configure um leitor como FBReader para usar o ColorDict como dicionário externo.
8. Teste com uma palavra simples, não com uma palavra rara. Se palavras comuns funcionarem, o dicionário foi indexado corretamente.

Se não funcionar, verifique nesta ordem:

• os arquivos ainda estão compactados?
• os arquivos .dict, .idx e .ifo estão na mesma pasta?
• a pasta é realmente a pasta que o ColorDict está lendo?
• o Android bloqueou acesso ao diretório?
• o aplicativo precisa de permissão de armazenamento?
• a versão do Android mudou a localização dos dados?

Não complique antes de checar isso. Na maioria das vezes, o erro está em pasta errada ou arquivo não extraído.

Conclusão: um dicionário como instrumento de atenção

Instalar o Webster 1913 no Android parece uma pequena excentricidade. Não é. É uma decisão sobre o tipo de relação que você quer ter com as palavras.

A internet nos acostumou a respostas rápidas, e respostas rápidas são úteis. Mas nem toda pergunta merece uma resposta mínima. Às vezes, procurar uma palavra deveria nos fazer demorar um pouco. Não por nostalgia, mas porque a demora certa educa o olhar.

O artigo de James Somers acerta porque nos lembra que dicionários não são apenas ferramentas escolares. São instrumentos de atenção. Um dicionário fraco resolve dúvidas. Um dicionário forte melhora o leitor.

Carregar o Webster 1913 no Android é carregar uma pequena biblioteca de precisão no bolso. Ele não vai escrever por você, não vai substituir leitura séria, não vai transformar ninguém automaticamente em estilista da língua. Mas vai fazer algo talvez mais importante: vai colocar definições melhores no caminho das suas perguntas.

E isso, para quem lê e escreve, já é muita coisa.

Créditos e referências

Este texto foi inspirado pelo ensaio de James Somers, “You’re probably using the wrong dictionary”, publicado em seu site pessoal: https://jsomers.net/blog/dictionary.

Fontes consultadas e úteis para aprofundamento:

• James Somers, “You’re probably using the wrong dictionary”: https://jsomers.net/blog/dictionary
• Instruções de James Somers para usar o Webster 1913 no Android: https://gist.github.com/jsomers/9dd78c8dc7fab071993c
• Project Gutenberg, Webster’s Unabridged Dictionary 1913: https://www.gutenberg.org/files/669/669-h/669-h.htm
• Webster’s Revised Unabridged Dictionary 1913 pesquisável: https://websters1913.timcieplowski.com/
• ColorDict, site do desenvolvedor: https://www.socialnmobile.com/colordict.html
• ColorDict na Google Play: https://play.google.com/store/apps/details?id=com.socialnmobile.colordict
• FreeDict sobre formatos e aplicativos de dicionário: https://freedict.org/downloads/
• Britannica sobre o American Dictionary de Noah Webster: https://www.britannica.com/topic/An-American-Dictionary-of-the-English-Language
• JSTOR Daily sobre o Webster de 1828: https://daily.jstor.org/websters-dictionary-1828-annotated/
• Wiktionary sobre o Webster 1913 em domínio público: https://en.wiktionary.org/wiki/Wiktionary:Webster's_Dictionary,_1913

SOLED/2

The Soledade publishing protocol

Plain text over TCP for citizenship, Markdown, and editorial autonomy

Executive summary

SOLED/2 is a plain-text application protocol that runs over TCP on port 1915. It was created so that citizens of Soledade can register an identity, publish Markdown, validate drafts, list their files, delete content, and recover access without depending on a web dashboard, REST API, WordPress, or a relational database.

This document presents SOLED/2 as a deliberate architectural component: simple enough to fit inside a terminal, strict enough to preserve operational safety, and symbolic enough to turn remote publishing into an act of citizenship inside soledade.city.

1. What SOLED/2 is

SOLED/2 is the official write contract between simple clients — such as ncat, automation scripts, and terminals — and the soledade.post_server server.

It does not try to be an IETF standard. It is not a public RFC. It does not compete with HTTP. Its role is narrower and more honest: it transports commands and Markdown into Soledade's content/ tree, where the static site is rebuilt after validation.

The name SOLED comes from Soledade. The /2 suffix marks the second generation of the posting protocol. Before it, there was only the legacy mode: an administrative token, a file path, and a body terminated by a single dot. That worked, but only for a city governed by one key.

2. Why it was created

The original problem was simple: publish remotely without a web dashboard.

For a single administrator, a secret token was enough. But Soledade stopped being a personal blog and started adopting a more ambitious metaphor: a textual city with citizens, houses, districts, documents, and rules of coexistence.

In that new scenario, a single shared token became both a bottleneck and a risk. It does not separate authorship. It does not create individual identity. It does not provide a solid basis for moderation. Worst of all, it turns every authorized client into something too powerful.

Bluntly: a shared secret is acceptable for personal automation; it is bad architecture for a community.

SOLED/2 was created to solve that scaling problem without betraying the philosophy of the project. The answer was not to add a dashboard, a heavy web stack, or a JSON API. The answer was to design a small, textual, explicit protocol in which each operation says who is speaking, what they want to do, and which file they are acting on.

3. The real need: citizenship, not just login

The protocol had to solve something larger than authentication. It had to allow entry into Soledade's citizenship model.

That means allowing a person to:

• register a handle;
• receive a secret identity;
• write only inside their own file territory;
• validate drafts before publication;
• list their own Markdown files;
• delete authorized content;
• recover access if their identity is lost.

The choice of plain text is part of the need itself. Anyone with ncat can understand, assemble, and send a request. The packet is readable. The error is readable. The response is readable. That reduces dependence on SDKs, libraries, or official clients. The city accepts humble tools.

But simplicity is not naivety. SOLED/2 defines boundaries: allowed paths, citizen status, maximum payload size, preview without writing, recovery with invalidation of the previous identity, IP-based rate limiting, and synchronized build execution to keep the site coherent.

4. Design principles

5. How the protocol works

Every SOLED/2 message begins with a fixed first line:

SOLED/2

That line is the boundary between the second-generation parser and the legacy parser. If the first line is not SOLED/2, the server interprets the packet as legacy mode.

After that, headers follow the format:

KEY value

A blank line ends the headers and, when applicable, begins the Markdown body. The packet ends with a line containing only a single dot:

.

This convention makes the protocol easy to transmit manually from a terminal and easy to parse on the server.

Example preview request:

SOLED/2
ACTION PREVIEW
CITIZEN maria
IDENTITY <citizen-secret>
PATH citizens/maria/posts/note.md

---
title: "Note"
district: centro
---
Markdown publication text.
.

The operation above validates a draft without writing it to disk. Replacing ACTION PREVIEW with a normal publication action — or omitting ACTION when publication is treated as the default — changes the intention: the Markdown becomes a candidate for real writing into content/.

6. Main actions

7. Citizenship registration

Registration is the symbolic gate of the city. The client sends ACTION REGISTER, a HANDLE, and optionally a name. The server decides whether the handle is valid, whether it is reserved, and whether it has already been taken.

On success, the server responds with a secret identity and a recovery code.

SOLED/2
ACTION REGISTER
HANDLE maria
NAME Maria Silva

.

The response includes IDENTITY and RECOVERY. The identity should be stored locally. The recovery code should be treated as an emergency document.

The server does not store the identity in clear text. It stores a hash and compares future proofs against that hash.

8. Publishing Markdown

To publish, the citizen provides CITIZEN, IDENTITY, and PATH.

The PATH is not arbitrary. It must remain inside the permitted space, usually something like:

citizens/<handle>/

Validation blocks directory escapes, forbidden paths, oversized payloads, nonexistent districts, and inconsistent front matter.

When everything passes, the server writes the file into content/ and runs the site build. The final visitor does not talk to SOLED/2. They see HTML served later over HTTPS from the regenerated public folder.

Example publication:

SOLED/2
CITIZEN maria
IDENTITY <citizen-secret>
PATH citizens/maria/posts/first-post.md

---
title: "My first post"
district: centro
---
This is a publication sent directly from the terminal.
.

9. Preview: the brake that prevents disaster

PREVIEW exists because direct publishing to production is too powerful to be blind.

It runs validation, reports warnings or errors, and writes nothing. In practice, it is the safe mode for scripts, assistants, and humans to check whether a packet is publishable before touching the disk.

This action also separates transport from editorial judgment. The protocol carries the file; the validation layer decides whether that file respects the city's model.

10. Identity recovery

RECOVER solves an unavoidable failure in simple systems: people lose secrets.

Instead of relying on email, passwords, OAuth, or an administrative dashboard, Soledade issues a recovery code during registration. Whoever holds that code can request a new identity. The previous identity stops working.

This keeps the design coherent: the city remains textual, the terminal remains sufficient, and the server does not need to store a reversible password.

11. Operational security

SOLED/2 is not transport encryption. If port 1915 is exposed, the operation needs appropriate external protection: firewall rules, an SSH tunnel, IP policy, or an explicit decision to make the port public.

The protocol authenticates identity at the application level. It does not promise connection secrecy by itself.

Operational safeguards include:

• IP-based rate limiting to contain registration and publishing spam;
• citizen status such as active, suspended, or banned;
• blocking dangerous paths, including attempts to escape content/;
• build locking to avoid regeneration races;
• logs containing protocol, citizen, action, and IP for basic auditing;
• preservation of legacy mode without mixing administrative privilege with ordinary citizenship.

12. Relationship with legacy mode

The first generation does not disappear. It remains available on the same port as legacy mode, identified by the absence of the SOLED/2 first line.

Its format is direct:

<path>
<administrative-token>
<body>
.

This preserves older scripts and allows mayor-level operations without forcing immediate migration.

But legacy mode is not citizenship. It is administration. That distinction matters: SOLED/2 was born for many authors with their own scope; legacy mode exists for centralized trusted automation.

13. What SOLED/2 is not

SOLED/2 is not:

• REST, JSON-RPC, or GraphQL;
• a universal standard;
• a replacement for Git;
• an HTML-serving protocol;
• the read protocol on port 1900;
• a substitute for firewall policy, exposure decisions, or operational hygiene.

It is the official write protocol of Soledade.

14. Why this choice makes sense

The choice behind SOLED/2 is stubbornly simple, and that is its virtue.

For a project like Soledade, adopting a conventional web stack would solve publishing, but it would erase part of the system's identity. The protocol makes the form match the content: a textual city, governed by files, accessible through a terminal, and understandable by direct reading.

The gain is not only technical. It is cultural.

Publishing stops being a click inside an invisible form and becomes the act of sending a formal letter to the city. The server reads it, validates it, records it, and rebuilds the public showcase. That minimal friction creates ritual without becoming bureaucracy.

In short: SOLED/2 exists because Soledade needed to grow from blog to city without losing its plain-text soul.

15. Quick specification

16. One-sentence pitch

I created SOLED/2 so that Soledade could publish Markdown through port 1915 as a textual city: each person registers a handle, receives a secret identity, sends terminal-readable packets, and the server validates, writes, and rebuilds the site without WordPress, without a web dashboard, and without abandoning the simplicity of TCP.

17. Future evolution

If SOLED/3 ever exists, the correct path is to preserve predictability: a new first line, temporary compatibility with SOLED/2, updated documentation, new tests, and old responses preserved whenever possible.

A protocol change without a clear contract is just a bug with marketing.

Until then, SOLED/2 can evolve through new ACTIONs and optional headers, as long as it does not break existing clients or change the meaning of fundamental responses.

Appendix A — Mental model of the flow

ncat/script client
 |
 | TCP :1915, UTF-8, packet terminated by dot
 v
soledade.post_server
 |
 |-- first line == SOLED/2 -> SOLED/2 parser
 |   |-- REGISTER / RECOVER -> citizens and identity
 |   |-- LIST -> permitted files
 |   |-- PREVIEW -> validation without writing
 |   `-- publication -> validation, writing, and build
 |
 `-- otherwise -> legacy parser with administrative token

content/*.md -> build_site() -> public/*.html -> Caddy/HTTPS

Appendix B — Common errors

Final note

SOLED/2 is intentionally small. Its purpose is not to impress through complexity, but to create a clear, auditable contract that fits Soledade's technical aesthetic.

There was something deeply pleasant about the whole thing. The design, the layout, the restraint — everything seemed to belong to another internet, one that had not yet been buried under dashboards, feeds, pop-ups, infinite scrolling, and algorithmic noise. It reminded me a little of Pico, another place that once made me want to participate simply because it felt human.

But what really caught my attention was not only the visual style. It was the way the blog itself worked.

Well, well.

It was a Nex/NPS-style blog.

And honestly, I got ridiculously excited.

I had not seen something like that in years: a blog that could be read like a small textual place, where paths mattered, where the terminal felt welcome, where publishing did not require a bloated interface or a database pretending to be necessary. It felt old, but not obsolete. Small, but not poor. Technical, but strangely warm.

I even sent a few emails to the creator, just to say congratulations. I never received a reply — which, somehow, only made the whole thing more charming. So I thought: why not build one for myself?

And that was how soledade.city began.

The name Soledade is an old Portuguese word meaning “solitude” or “loneliness.” It has a quiet, archaic beauty to it. But it is also the name of my own little city, the place where I was born, in the south of Minas Gerais, Brazil. A small town with fewer than seven thousand people, but one that has my heart completely. Soledade is not just a word to me. It is a memory, a landscape, a place of origin.

So I created a Python virtual environment and started building.

The idea was simple: no CMS, no database, no admin panel, no framework, no unnecessary machinery. Just text, files, and a small set of Python scripts doing exactly what they needed to do.

At its core, soledade.city is a tiny Python system built almost entirely on the standard library. pathlib keeps the project’s paths clean and readable, separating content/, public/, templates/, secrets/, and logs/ without turning the code into a mess of string manipulation. The only meaningful external dependency is markdown, used by build.py to transform .md files into static HTML pages. I enabled small comforts like extra, toc, and sane_lists, enough to make writing pleasant without letting the project become a full-blown publishing platform.

The generated site lives in public/. That is the whole public face of the project: static HTML, RSS, sitemap, health check, and a custom 404 page. Caddy takes care of serving those files on the web and handling HTTPS. Python does not pretend to be a web server here. It writes files, rebuilds the site, and steps aside.

For safety and correctness, the code uses html when escaping HTML content and xml.sax.saxutils when generating XML for the feed and sitemap. datetime and email.utils handle proper dates for health.txt, RSS, and sitemap entries. The project is small, but I wanted the boring details to be right.

The more peculiar part is outside the static generator.

Soledade also runs two small TCP services using Python’s socketserver. One listens on port 1900 and behaves like a minimal reading protocol: the client sends a path, and the server returns the raw Markdown. The other listens on port 1915 and handles publication: send a path, a token, the Markdown body, and a final line containing only a dot. If the token is valid, the server writes the file into content/ and rebuilds the site.

For the publishing token, I used secrets.compare_digest, because even a tiny system should not be careless when checking secrets. The publication service is still intentionally plain — no login screen, no session, no browser interface — but it respects the basics: path validation, token validation, size limits, logs, and firewall rules.

That is the strange little heart of the project: internally, it is just a static site generator; externally, it behaves like a small textual city. You can visit it in a browser like a normal website, subscribe to the RSS feed like it is 2005, or talk to it from the terminal with ncat.

Reading is asking for a path.

Publishing is sending a path, a token, a body, and a dot.

That is all.

And that is exactly the point.

Soledade is not trying to become WordPress, Medium, Substack, or yet another “content platform.” It is intentionally small. It is a place for Markdown files, static pages, terminal rituals, and quiet publishing. A little city of text, named after another little city, built against the obesity of the modern web.

The project is already alive at soledade.city, though there is still plenty to improve. But that feels right. Small places should grow slowly.