andrés ignacio torres

Connect Ozone to your PDS

2025-12-16T00:00:00Z

If you are self-hosting both a PDS and an Ozone instance, you will want to set up these environment variables on your PDS so that your PDS and Ozone can correctly talk to each other, in particular so Ozone can send email notifications via your PDS SMTP settings, as well as act as its "moderation service".

# on your pds.env or your PDS container environment
PDS_MOD_SERVICE_DID="<your Ozone's service account DID>"
PDS_MOD_SERVICE_URL="<URL to your Ozone deployment>"
# note that even if you have PDS_EMAIL_SMTP_URL and
# PDS_EMAIL_FROM_ADDRESS set, these will not be used
# by Ozone unless you also set these two
# (you can reuse the same values):
PDS_MODERATION_EMAIL_SMTP_URL="<SMTP server to send emails from>"
PDS_MODERATION_EMAIL_ADDRESS="<email address to send moderation emails from>"

Thanks to @baileytownsend.dev for helping troubleshoot and figure this out, and to @thisismissem.social for calling it out as well on this helpful thread!

Just realised many self-hosted PDSes likely don't have moderation emails enabled because email config doesn't cascade to moderation email config, so you have to specify both 🤔
— Emelia (@thisismissem.social) November 13, 2025 at 4:15 AM

On Kubernetes volumes

2025-11-27T00:00:00Z

This week I had to recreate a Kubernetes cluster to mitigate an incident on a side project.

waking up to find the whole nodepool unexplicably down! oh no!
— andrés ignacio torres (@andresitorresm.com) November 24, 2025 at 8:17 AM

As I'm still learning my way through Kubernetes concepts, I thought it'd be useful (to myself!) to write a quick note on what I've learned about volumes in Kubernetes and how they relate to each other.

Persistent Volumes Claims (PVCs) #

Essentially, this is a request for storage. You request a given amount of storage, and a storage class for it, and Kubernetes will manage that for you so you don't have to provision the disk yourself (at least in a managed Kubernetes environment).

As long as the persistent volume claim exists, the storage volume will be kept around (persistent), even if no pod is using it, or if the pod using it is deleted.

Check your cluster's persistent volume claims with:

kubectl get pvc

Persistent Volumes (PVs) #

This is the actual storage volume that gets created automatically to comply with a persistent volume claim, or it can also be created manually.

If it was created automatically, it will also be deleted automatically when the claim is deleted. Important!

Check your cluster's persistent volumes with:

kubectl get pv

Volume Attachments #

This is a resource that Kubernetes creates and uses to track which volume is attached to which node. When a pod that uses a given persistent volume claim is scheduled to a node, Kubernetes will create a volume attachment to signify that the volume is attached to that node.

Check your cluster's volume attachments with:

kubectl get volumeattachments

Can I delete...? #

A persistent volume claim? Yes, but if the volume tied to it was created automatically, the volume will be deleted too.

A persistent volume? Only if no persistent volume claim is using it, and this will delete all data stored on it.

A volume attachment? Yes, but you most likely won't need to. Unless you're me, a few days ago, and had to force a volume to detach from a node because it was stuck. In any case, deleting a volume attachment will NOT delete the volume itself, or the data on it.

I went to FediCon 2025!

2025-09-01T00:00:00Z

Welcome speech at FediCon 2025.

What if the Fediverse met... in real life?

Last month, I had the pleasure of attending FediCon 2025, a local conference for "decentralized social networks and the social web", held here in Vancouver, Canada.

I learned about FediCon a while ago through my Mastodon feed, and I signed up for it right away (I didn't have to think much about it, given that the conference chose a venue just a few minutes from home!).

Even though I've gravitated mostly towards Bluesky in recent months, my journey through decentralized and federated social networks started with Mastodon and ActivityPub, so it's got a soft spot in my heart.

Johannes Ernst on his talk "From Millions To Billions: a Plausible Narrative for How to Grow the Open Social Web".

And what a great experience it was! I got to learn from some amazing speakers and prominent personalities in the Fediverse space, including one of ActivityPub's co-creators (Evan Prodmorou).

Contrary to what I originally expected, the conference didn't just focus on ActivityPub (although the protocol took a central role in most talks); one of the speakers was Anuj Ahoooja, who spoke about bridging decentralized platforms based on his experience working on Brid.gy, as well as an amazing survey of unique, innovative and creative ATProto applications that go beyond just microblogging by our local star, Boris Mann.

Boris Mann on his talk "Beyond Microblogging: AT Protocol for Building Unique Social Apps".

Another highlight for me was hearing first-hand experiences on how ActivityPub and the Fediverse are being used in local contexts for community building, data sovereignty and digital self-determination, with talks on how CoSocial and SocialBC (two Mastodon instances tailor-made for Canadians on a provincial and federal level) came to be and are managed, and even a non-technical talk about the Fediverse as a digital third space that can enable "community (re)connection".

These talks, as well as the rest, were all refreshing and inspiring, with a mix of historical background around the Fediverse, and projections towards the future by looking at a lot of creative uses of the Fediverse in order to empower communities and individuals.

I left the conference with a lot of ideas and motivation to keep exploring how to build and contribute to a decentralized and social web, no matter the underlying platform or protocol (or, more specifically, not limited by them).

You can watch all the recorded sessions on FediCon's official Spectra Video (PeerTube) channel.

Looking forward to FediCon 2026!

Small spaces

2025-07-29T00:00:00Z

From a short trip to Port Moody, B.C. (2023)

A couple months ago, I went to a poetry workshop offered for migrants by Vancouver Writers Fest, led by Evelyn Lau. We read, we laughed, we talked, we cried, but most importantly, within those four hours we created a bond, built a community and met others who, for one reason or another, shared at least two threads in common with me: being a writer and being a migrant.

Since last year, I've attended multiple creative writing workshops, but this one hit different. For the first time, I've found myself meeting some of the participants again a few days later, at another event. Then again, and again. And little by little, they have helped me cultivate a small space of belonging in a city that doesn't belong to me, and to which I don't belong either, not entirely.

Between verses and books and laughter and tears (and fingers snapping), I have found a breathing room, a subterfuge from the daily grind, to which I cling and in which I find a push, sometmes very much needed, to put my eyes on the sund beyond the grayest of the clouds.

So it seems that the pieces, little by little, end up falling into place.

Getting OVH Public Cloud multi-region connectivity to work

2025-07-14T00:00:00Z

I've been working on a very cool passion project recently that involves setting up cloud infrastructure on OVH Public Cloud for data sovereignty. As part of the infrastructure design, I needed to set up one resource in a given region and another resource in a different region, and allow them to communicate with each other over private IPs.

This is a common use case for cloud networking and I've had to do this many times before on other cloud providers (Azure, AWS, GCP...), but my intuition and previous experience did not help me much when I tried to replicate this on OVH Public Cloud.

i suspect dns is at fault. it’s always dns.
— andrés ignacio torres (@andresitorresm.com) July 4, 2025 at 12:05 AM

Naively, after skimming OVH's documentation, my first attempt looked something like this (on Terraform):

# One private network
resource "ovh_cloud_project_network_private" "network" {
  service_name = "abc123"
  name         = "multiregion-network"
  regions      = ["GRA1", "BHS1"]
}

# Two subnets in the same private network, one
# in each region
resource "ovh_cloud_project_network_private_subnet" "subnet1" {
  service_name = "abc123"
  network_id   = ovh_cloud_project_network_private.network.id
  region       = "GRA1"
  start        = "10.0.1.1"
  end          = "10.0.1.255"
  network      = "10.0.1.0/24"
  dhcp         = true
  no_gateway   = false
}

resource "ovh_cloud_project_network_private_subnet" "subnet2" {
  service_name = "abc123"
  network_id   = ovh_cloud_project_network_private.network.id
  region       = "BHS1"
  start        = "10.0.2.1"
  end          = "10.0.2.255"
  network      = "10.0.2.0/24"
  dhcp         = true
  no_gateway   = false
}

This seemed to me like it would work, and I didn't get any errors when applying the Terraform configuration. However, the resources deployed in each region's subnet could not communicate with each other over their private IPs. This was confusing and I didn't find any multi-region examples in OVH's documentation or Github.

Among other things, I tried separating the private network into two different resources, one for each region (similar to how AWS would require two VPCs) but that didn't work either (and it didn't make sense, since OVH's documentation allowed you to create a single private network across multiple regions).

After a lot of digging and reading through OVH's documentation, I found one key line that explained the issue (emphasis mine):

Multi-region private networks: To achieve resource interconnectivity between regions, the same vRack/VLAN/subnet should be used to create a private network in each region. Please note that different DHCP IP ranges must be used in different regions.

Aha! The implication here is that I needed to use "the same subnet" in each region, and this translates to using the same network CIDR in each region's subnet resource, while keeping the start and end IPs different in each region to avoid conflicts.

My updated Terraform configuration looks like this:

# One private network
resource "ovh_cloud_project_network_private" "network" {
  service_name = "abc123"
  name         = "multiregion-network"
  regions      = ["GRA1", "BHS1"]
}

# Two subnets in the same private network that share
# the same network CIDR, but have different DHCP ranges
resource "ovh_cloud_project_network_private_subnet" "subnet1" {
  service_name = "abc123"
  network_id   = ovh_cloud_project_network_private.network.id
  region       = "GRA1"
  start        = "10.0.1.1"
  end          = "10.0.1.155"
  network      = "10.0.1.0/24"
  dhcp         = true
  no_gateway   = false
}

resource "ovh_cloud_project_network_private_subnet" "subnet2" {
  service_name = "abc123"
  network_id   = ovh_cloud_project_network_private.network.id
  region       = "BHS1"
  start        = "10.0.1.156"
  end          = "10.0.1.255"
  network      = "10.0.1.0/24"
  dhcp         = true
  no_gateway   = false
}

This change was enough to get the resources in each region to communicate with each other over their private IPs!

Self-hosting Bluesky's Ozone alongside other services

2025-05-19T00:00:00Z

Shoutout to Casey Primozic (@ameo.dev) for the wonderful and detailed PDS-alongside-other-services self-hosting guide that inspired this post!

It's alive!

I've been tinkering with Bluesky for a few months now through several projects, and naturally I've been drawn towards self-hosting (some of) its pieces, given Bluesky's modular and open-source nature.

My first step was to self-host a Personal Data Server (PDS), but the official guide involves deploying a full set of services, including caddy as a reverse proxy, running on the host network.

Since I wanted to re-use an existing server that already had nginx running, I followed @ameo.dev's guide to set everything the PDS and, after a few tweaks, I managed to get it working.

My next step was to self-host Ozone, Bluesky's labeling application. Like the PDS instructions, Ozone's official hosting guide implies running a Docker image in the host network with caddy and postgres. With a bit of work, I adapted the steps to work with an existing nginx setup and without interfering with an existing postgres installation.

For future reference, here are the tweaks I made to deploy Ozone.

Start with the official guide #

Ozone's self-hosting guide is a great starting point to ensure your server has all the prerequisites and dependencies installed, and enough resources as well.

You will need the service account for the labeler, the domain pointing to your server and to open the firewall ports as described.

Directory structure and config setup #

I kept the directory structure similar to the one in the official guide, but instead of creating the base directory in my server's root, I put it somewhere else. This is where the data for ozone and the postgres database will live.

You can skip the caddy directory since you're already using nginx.

# Navigate to wherever you want to put
# ozone data, this is an example
cd /opt

# Create the directory structure
mkdir ozone
mkdir ozone/postgres

Skip the Caddyfile as you will not be using caddy to serve anything.

Create the postgres config file in the ozone directory that you created (not necessarily in /ozone/postgres.env if you put it somewhere else).

Then create the ozone.env file in that directory as well. The only thing to tweak is the OZONE_DB_POSTGRES_URL variable. I set it up like this (note that localhost was replaced with postgres):

OZONE_DB_POSTGRES_URL=postgresql://postgres:${POSTGRES_PASSWORD}@$postgres:5432/ozone

Since the Docker containers will share the same network (and not the host network), we can use the Postgres container name as the hostname.

Ozone container setup #

The next step in the official guide would be to download the compose.yaml file and run it. However, doing this means running everything in the host network, including caddy, which we don't want to do.

I tweaked the compose.yaml to look something like this:

networks:
  ozone:
    driver: bridge
services:
  ozone:
    container_name: ozone
    image: ghcr.io/bluesky-social/ozone:0.1
    restart: unless-stopped
    networks:
      - ozone
    depends_on:
      postgres:
        condition: service_healthy
    ports:
      - '1235:3000'
    env_file:
      - /opt/ozone/ozone.env
  postgres:
    container_name: postgres
    image: postgres:14.11-bookworm
    networks:
      - ozone
    restart: unless-stopped
    healthcheck:
      test: pg_isready -h localhost -U $$POSTGRES_USER
      interval: 2s
      timeout: 5s
      retries: 10
    volumes:
      - type: bind
        source: /opt/ozone/postgres
        target: /var/lib/postgresql/data
    env_file:
      - /opt/ozone/postgres.env

Note that:

The caddy and watchtower containers are gone. A consequence of this is that you will need to manually update the ozone container when a new version is released.
The paths were adjusted to match the directory structure we created earlier (in this example, /opt/ozone/).
Containers are set to use ozone as their bridge network, without being exposed to the host network.
Host port 1235 is bound to container port 3000, which is the port that Ozone listens on. You can change this to any other port you want, but make sure to update the nginx config accordingly.

Save the file as compose.yaml and run docker compose up -d to start the containers.

Create, enable and start the systemd service file as instructed in the official guide, make sure to set the WorkingDirectory to wherever you saved the compose.yaml file. That takes care of starting ozone on boot.

At this point you can verify that Ozone is online by curling http://localhost:1235/xrpc/_health. If everything is working, the only step remaining is to expose the service to the outside world through nginx.

Nginx setup #

I created a new ozone.conf file within nginx's config directory, similar to this:

server {
  listen 80;
  server_name labeler.example.com;

  location / {
      proxy_pass http://localhost:1235;
      proxy_set_header X-Forwarded-Proto https;
      proxy_set_header Host $host;

      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "Upgrade";

      proxy_buffering off;
  }
}

Adjust the domain and port as needed, and note that the proxy_set_header lines are imporant to ensure websocket connections are properly handled.

Enable the config and reload nginx.

Then, to add SSL support, use certbot:

certbot --nginx -d labeler.example.com

And you're set!

I hope this brief guide helps you set up your own Ozone labeler, and feel free to reach out on Bluesky if you have any suggestions for this post!

To listen to a book

2025-05-04T00:00:00Z

One of my readings the other day. Trying to imagine Sisyphus happy.

All my life I have loved reading. Ever since I was a kid, I've always kept a book close by. Although I stopped reading constantly for a few years, I recently returned to it as a daily habit.

At first, I read physical books and couldn't fathom the idea of reading digitally. Then, I realized that e-books allowed me to carry an entire library with me wherever I went. So, I embraced digital books.

However, despite this change, I'd never considered the idea of listening to a book. How could I enjoy a story if I didn't read it, if I couldn't see every symbol, letter, every single decision the author made on a page? This way of thinking, perhaps shaped a bit by the type of poetry I enjoy (which doesn't easily translate from paper to voice), made me reject the idea of audiobooks.

This year, bit by bit, I've opened up to the idea of listening to read. I spent a big part of last year listening to podcasts, and a few months ago, I tried my first audiobook, partly thanks to the Vancouver Public Library's catalogue.

Although I still prefer reading on paper or digitally, I haven't had a bad experience with audiobooks. I like that I can listen to the story while doing other mechanical tasks, like cooking or cleaning. And even, since I need to consciously pay attention to the narrator's voice, it forces me to concentrate on the story, to be present in what I'm listening to, instead of getting lost and drifting between letters and pages.

I will continue experimenting with different formats, and maybe one day I'll incorporate another sense into this quest for knowledge, stories, and worlds. In the meantime, I'll split my reading time between digital books and audiobooks.

Handling monetary values in code

2025-04-13T00:00:00Z

Photograph by Rashed Paykary on Unsplash.

Every developer will eventually have to deal with monetary values in their code some time. This is a tricky thing to get right, and it is absolutely necessary to do so.

My two cents (no pun intended) on the matter are:

Don't reinvent the wheel #

There are many libraries (e.g. dinero for Python) out there that have been built to handle monetary values and their edge cases. They're usually tried and tested and will consider a lot of scenarios that you might not have thought of. Highly recommended!

Use the right data type #

For storage and transport, the right data type is key. Avoid floating point numbers, as they can introduce rounding errors when adding, substracting or otherwise making calculations with money.

Consider using fixed-point numbers (e.g. Decimal in Python), or integers (e.g. treat money as cents instead of dollars, like Stripe does). This will help avoid rounding errors by design.

Always consider localization #

Different countries and regions have different ways of formatting monetary values. For example, three dollars and fifty cents would be written as $3.50 in Canada but $3,50 in France (note the comma instead of the full stop).

This is particularly important if you are working on code that sends or receives monetary values to another system, or that parses monetary values from user input (e.g. from string). Make sure there is a clear contract between the two systems or the user input and the code for the format of the monetary values. Consider how your code will behave if deployed in a different region or country, and if the system locale can change at runtime.

Log everything! #

Or, at least, log the most important things to the extend you're allowed to. That way you can reconstruct any operation when needed and find out what, if anything, went wrong (and things will go wrong).

Test, test, test! #

Finally, test everything thoroughly. Add unit tests for all the testable code, add integration tests for the components that interact with each other, and perform end-to-end tests every so often.

A new step as an open source project maintainer

2025-03-23T00:00:00Z

Photograph by Chris Ried on Unsplash.

I've been working visibly on open source projects for a few years now.

I started while I was doing my undergrad, participating in the Hacktoberfest in 2019. From there, I moved to contributing a couple of minor changes to random projects I found on the internet. At the same time, I worked on my undergrad thesis openly on a public Github repository, as well as on other big projects on my final year.

One of my favorite moments (so far) was when I contributed my first (and, so far, only) commit to the mybb repository, a piece of software with a special place in my heart, especially during my teenage years. It wasn't a big change, just a missing >, but it was another symbolic step for me: being able to give something back to a community that I held dear.

I then moved onto creating my own projects. A lot of them didn't go beyond a couple commits made in an afternoon or two, and have been left behind. For others, however, I've dedicated more time: a program to send public domain books to a Kindle via email, an assistant to find outdated packages in Python projects, a bot that sends dog pictures in Telegram chats... In general, a variety of projects that, for the most part, arose to cover at least one of the following needs:

Learning how to use a new tool, or
Solving a personal need

For these reasons, and although in recent years I've put the same effort into my personal projects as I have into my professional ones (unit testing, changelogs, continuous validation, documentation, clean code...), all of them have been a sort of bottle to the sea: the exercise of solving my own problems in the open, with the idea that at some point someone else might find it useful.

And a couple of weeks ago, that day came.

I received my first feature request! #

The other day, a user on Github opened an issue in the barkr repository, my cross-posting tool for social media, with a request: to add support for Discord.

It's the first time I receive a request of this kind, which makes me think the following:

I finally did something that is useful to someone else!
And not only is it useful to them in its current state, but also in its future state (to the point of taking the time to write to ask for a change)

This is most probably an insignificant thing in the grand scheme of things, but added to the fact that the number of stars on the Github project has gone up (and by this I mean: it's not 0), it made my day, my week, my month, and reinforced my motivation to keep working on barkr, improving it little by little, not just for myself but also (maybe) for someone else.

How nice it is to do open source! :-)

I lost my voice

2025-03-02T00:00:00Z

This blog post was originally written (and intended to be read) in Spanish. I tried my best to convey the same meaning in my translation below, but your mileage may vary!

Photograph by Andrew Neel on Unsplash.

For a while, so long that I can't measure, I've felt like my voice is missing.

I don't know where I left it last time I saw it, I used it.

My fingers dance atop the keyboard, my hand grabs the pen that swipes over the notebook. And I can see the lines, the traces,the pixels that light up forming symbols that I can read.

But I don't recognize myself.

For the past few months, I've consciously grown back my reading habit, partially due to me getting a new Kobo. When I created this website, I set another goal for myself: to recover my writing habit. But this one's been way harder to do.

Even though, objectivelly, I've been practicing more than before —I've forced myself to write at least a couple paragraphs each day, about anything, like the hamster that comes back to the wheel that he's used to—, I don't feel completely comfortable with my output.

And, to be fair, I've never been. Not completely. But even within the walls of my self-doubt, I could find parts of myself engraved within the texts that I used to write years ago.

Now, if I put my words in front of a mirror, it is not me whom I see.

I find writing to be essential to my identity. I like recognizing myself as a writer, but my writing these past few years has not met my standards by far.

I'm not sure if it's because of the time that has passed, or the immense change in my circumstances and environment since 2023 —starting with the obvious: migrating to a new country, leaving behind the Caribbean sand and instead finding myself trapped within the white confines of the snowy mountains that I can see from my windows.

Something is not working.

But within this self-disagreement, I also find a wish: to improve, to be better, and to go back and find myself again within the role of a writer.

I will find the way, I will find the time.

In the meantime, I will continue pursuing my identity as a writer, just as much as I pursue all the other bits of whom I am.

And I will keep finding myself in the role of a reader, surfing endless reminders of all that's possible, of the thousands of realities that we can live, that we can buid, that we can create.

Why I don't bother with self-help books

2025-02-02T00:00:00Z

A few days ago, as I was cooking (and mindlessly watching YouTube in the background), a book recommendation video caught my eye. A YouTuber was describing her experience reading "The Dip" (Seth Godin, 2007), and how the message behind this book had pushed her into accomplishing several milestones in her path as a content creator and businesswoman.

I've never been fond of self-help books, but I gave "The Dip" a try. It was a quick read, I read it in one sitting during a lunch break.

And it reminded me of why I don't really like self-help books.

Now, I know that 1) no two books are the same, even if they're sold / promoted as part of the same genre, and 2) no two readers are the same, so what doesn't work for me can potentially work for someone else and that's alright.

However, if you ask me, self-help books fail to reach me because:

They're usually overly simplistic. Self-help authors tend to reduce problems and situations into one box with a fixed outcome. Everything tends to be black or white.
They're deterministic. The authors ignore that everyone's circumstances are different and aim to provide a rigid formula for success (in business, in love, in finances, you name it). Do what they say and you'll succeed. Don't, and you'll fail.
They're pompous common sense. Most of the messages and guidance are very basic, rarely new advice, and they're inflated with fancy words, terms, charts to make it look like they're new or revolutionary. Granted, common sense isn't actually common and sometimes a reminder is fine, but still...

Maybe this has to do with the tendency to attempt to turn "success" into a process on extremely subjective areas. We want to have an easy-to-follow guide, a "follow these steps and you'll do it without fail", but life doesn't usually work that way.

This being said, "The Dip"'s message (that can be shortened from 80-pages to one or two lines) was a curious, albeit simplistic, premise. I'm not sure if it'll change what I do or how I act, but I don't regret reading it.

At least I got a blog post out of it ;)

Some notes after DMing my first Dungeons and Dragons campaign

2025-01-27T00:00:00Z

Facing a dragon for the first time! (image: Wizards of the Coast)

Between October and December, I took on the role of Dungeon Master (DM) for the first time to host a short (lv. 1 to 3) introductory Dungeons and Dragons campaign for two close friends, Germán and Gustavo.

This was not only my first time as a DM, but my first real taste of a Dungeons and Dragons game overall, as my only other time playing was on a 2-hour one-shot tutorial a few weeks before. But the game felt so creative and attractive to me that, after a few failed attempts to find more experienced players to guide our first campaign, I read through the whole campaign and most of the Dungeon Masters Guide and hosted it myself.

We had a lot of fun! Besides the source materials, my only other preparation was watching countless YouTube videos with tips and tricks for new DMs, and browsing some reddit posts for campaign-specific tips. I was nervous at first, but thanks to my friends getting into their roles, each session felt rewarding and fun. It helped that we chose to start with the current Starter Kit, Dragons of Stormwreck Isle, which is perfect for newcomes to Dungeons and Dragons.

Now that the campaign is over and about a month has passed, I've had some time to look back and think of a few extra tips that I will take into account for my next campaign as a DM (and that I surely read somewhere but completely ignored!).

In no particular order:

Notes, notes and more notes #

Being a DM means improvising a lot: creating NPCs on the fly, addressing backstory or plot holes with the first thing that comes to mind, remembering whether or not you already mentioned that the statue next to the room is shining...

It's important to actively take notes of what you do, where you're at, what's your next step and what your players have done. You can involve your players in your note-taking process by encouraging them to do so and share important notes when a session ends and / or before a session starts.

Be ready for the unexpected #

You can plan a whole session-long storyline, and the first thing your players do is decide they want to do something else. It's impossible to be prepared for every possible outcome, but you should help your future self by at least considering what other actions could your players do if they decide they don't want to pursue your main story plot just yet.

For example, you can have some campaign-appropriate creatures and maps ready so that, if they adventure somewhere new, you're ready to add an unplanned encounter. This can even help you figure out how to tie what your players are doing with your original ideas!

Help control the course of action #

Tied to my point above: a Dungeons and Dragons campaign is a storytelling exercise where your players take decisions to drive the story forward, but they do so based on your guidance as a Dungeon Master.

Don't be afraid to suggest different ways to solve an incident or address an encounter, to help the players understand all the possibilities they have without taking agency from them.

Players don't know what you know, so help them see #

If there's a suspicious-looking plank inside a room, say so!

If there's five columns but one seems to shine, say so!

If there's some mechanism that depends on the players taking a given action, find a way to let them know without throwing the fact into their faces. Invite them to examine or investigate, or be more detailed describing the things you want to draw them upon.

New players might not have the impulse to investigate every place they find themselves into, so try to bring awareness to what they could do in those places.

Remember to have fun #

Preparing and hosting a session can be stressful. There's a lot of work behind-the-scenes, calculations on the go, plans that can change every second... But remember to have fun! If your players and yourself are having fun, that's all that matters.

Port forwarding through SSH

2025-01-19T00:00:00Z

While working on my undergraduate senior thesis a few years ago, I made a small web application to visualize certain patterns as my daily experiments went through. This application was running inside a remote server and was not getting exposed to the public internet, so it was a hassle to check its content.

After trying to figure out a way to make it easier to access said application, I stumbled upon the port forwarding functionality of ssh. I'm writing this brief explanation many years later to prevent myself from forgetting it again.

As per ssh's man page, you can use the -L flag to specify "that connections to the given TCP port or Unix socket on the local (client) host are to be forwarded to the given host and port, or Unix socket, on the remote side".

Practically speaking, if your remote server is located at example.com and is running an application that listens for connections on port 8001, you can run this command on your local machine:

ssh user@example.com -L 3000:localhost:8001

You can read the 3000:localhost:8001 part as "connections to (my local) port 3000 is to be forwarded to the remote server, to the localhost host and the 8001 port". Adjust the ports and host to suit your use case.

While this ssh session is running, you can access localhost:3000 on your local machine and you should be greeted by whatever is available on localhost:8001 on the remote machine. Nice!

I love building bots (and bot craftmanship)

2024-12-19T00:00:00Z

A few months ago, I received notice that the botsin.space Mastodon instance was going to shut down by December this year, after more than 7 years of service. I hope bot-makers are able to migrate their bots to other instances and keep them running, to keep the online bot craftmanship alive.

While I only found my way into the fediverse a couple years back, I've loved making online bots (e.g. on Telegram, formerly on X (formerly Twitter)) and also stumbling upon these small creations made by other people ever since I started college more than ten years ago.

These toy bots are by no means a technological feat: most of the ones I refer to just post short pieces of text to social media, or respond to triggers on instant messaging apps. But no matter how advanced they are, I find it wonderful to connect to a bot creator and understand the creative intent behind the bot.

I remember a few bots that inspired me to start creating my own: among others, there was a bot on Twitter that posted imaginary news headlines for a fictional RPG setting, and another one that posted ASCII-art of small boats sailing through the nights. There's also a lot of bots that post excerpts of poets and short stories, and the more useful variety (weather, real headlines, earthquake warnings, etc).

Due to the botsin.space closure, I had to migrate one of my bots (@caracasadjetivo) to another instance. Originally on Twitter, I decided to move it to a self-hosted, barebones instance at caracasadj.aitorres.com, made possible by ActivityBot. While I've had a few other bots in the past (a weather bot, a few poetry-related bots...), this is the only one I currently keep active. That might change in the (near) future, as I go back to my old files and re-deploy other bots in the fediverse.

I don't really have a bottom line or conclusion here, other than inviting you to explore small-sized social interactions on Mastodon or other similar places through the creation of bots. You don't need AI, or LLMs, or any fancy technology for that. Just a few lines of code, an idea and a spark to bring it to life.

Happy botting :-)

Building a game out of spite

2024-11-10T00:00:00Z

So, I just built a (very simple) web game: Number Sum.

The game is a brief number guessing game, in the same vein as Sudoku and others. You have to complete a partially-filled grid with number guesses to ensure that certain conditions are met, namely that all columns and rows sum to the respective hints given on the grid.

It took me about two hours to build (plus a few weeks of wanting to build it but not moving a finger), and I did for two reasons:

The main, technical reason is that I wanted to practice my Svelte skills. I've been eyeing out Svelte for some time and this seemed like a perfect opportunity to build a small web app encapsulating scripts, styles and markup in the same file. Plus, I don't practice my Javascript / Typescript as much as I would like to on my day-to-day job.
I played a similar game on my phone and I hated it. It was one of these games full of obnoxious, intrusive ads that you can't skip and that pop out at every. single. opportunity.

So thanks to these two reasons (mostly the second one, to be honest), you can now play an ad-free, open source version of the game!

Now, to work on actually productive things...

Getting a Kobo rekindled my passion for reading

2024-11-08T00:00:00Z

When I was younger, I used to read a lot. I used to cram in reading at every possible moment, dashing through trilogies and series in a matter of days. I would consistently start reading a novel, a short story collection, a series of essays and get through the end without getting bored or tired in the process, even if whatever book I had picked didn't fully peak my interest. Physical books, ebooks, fan fiction, blog posts, RSS feeds: you name it, I probably read it.

And then I grew into adulthood.

At some point after my first year of undergraduate studies, I stopped reading as much as I used to. More and more of what I read was content I had to read: textbooks, problem sets, required reading for my courses; not that I didn't like what I was reading (most of the time at least), but mandatory reading certainly overpowered recreative reading to the point that I could spend months without even opening a book.

While these Goodreads stats are not the most accurate as I don't track everything that I read, they serve to illustrate my point.

A certain dystopic event that marked the start of the 2020s (sigh) gave me a lot of free time trapped inside a house that I shared with eight other friends, so in order to not go crazy, I decided to turn back into my passions and hobbies, and in the case of reading I made an investment that initially proved fruitful.

I bought a Kindle.

Earlier this year, taking my Kindle for a walk along the Vancouver seawall to catch-up on a Spanish translation of 'Gender Trouble' by Judith Butler

Initially, the Kindle did wonders for my reading habits. In 2020 alone I read 28 books according to my Goodreads stats, which is 25 more books than the previous year (!!). I felt pushed into the future by the usual wonders of an e-reader: its practicality, being able to carry a sizable collection of books in my pocket, not having to choose which book to carry with me on a walk or when going to a coffee shop, etc.

But, once again, I found myself reading less and less. In 2021 I read 15 less books than the year before, and the number dropped to just two books over all of 2022.

Earlier this year, after finally settling from an international move and a new job with lots of things that were new to me, I decided to re-engage with my passions, pushed in part by the warm and welcoming literary scene in Vancouver. Armed with library cards for the different libraries of Metro Vancouver, I started checking books out and working on my reading once again.

While partially successful, I got caught in the same issues that I used to avoid by reading digital: either I forgot the book I was reading at home, or took the wrong one on my trips and halfway through an hour long commute decided that I actually wanted to read something else.

I then tried getting back into my Kindle, but for some reason, I started noticing some drawbacks from the model I had. My Kindle Paperwhite (2019) felt sluggish whenever I tried to navigate its UI, and changing pages took long enough to break my immersion as a reader. I assumed it was a fault of e-readers in general, of the eInk technology or something similar.

And then I stumbled upon a Kobo stand in an Indigo bookstore.

Up until this point, I knew there were other e-reader manufacturers besides Amazon, but I had assumed that Amazong, by virtue of being the biggest name, had the best technology. This stopped making sense once I started playing around with the different Kobo models on display at the bookstore. I found out that there were color e-readers! This was completely new to me! However, as I don't usually read anything that's not in black and white, I shifted my attention to the other models.

The Kobo Clara BW caught my attention. I liked its small form factor, similar to the Kindle that I had already grown used to. I liked that it didn't have any buttons (contrary to what is apparently the popular belief, I'm more fond of touching the screen to change to the next page). But what really sold it for me was the page change speed. It was years ahead of my Kindle. Everything felt extremely smooth, and in a snap of the fingers I could move from a page to the next to the next to the next.

I went to YouTube and Reddit, watched and read reviews and articles and comparisons, went to the Indigo bookstore a dozen more times to test the devices, meditated over a few more weeks and finally I did it.

I bought a Kobo.

Behold, the Kobo Clara BW! Thanks to 'Malosito' for holding the box while I took the picture.

After almost two months of being a Kobo owner, I can happily say that it has served a purpose in increasing the time I dedicate to reading. Besides the fast page turning speed, I also love that I can link my Kobo to my library account (which is not possible for Canadian residents using a Kindle). This lets me access my library's more than eight thousand ebooks and manage my holds and loans directly from my device.

I've used my Kobo to read poetry, short fiction, essays and manga so far, and it's outperformed the Kindle in all areas. That's why, if you go back to the first image of this post, the year 2024 is the year I've read more books in Goodreads (granted, most of those are manga volumes, but it's still a lot of pages to turn and read!).

Reading some manga on the Kobo Clara BW on a five-hour long train trip.

Indirectly, just having the ability to read in a comfortable way that doesn't break immersion, and also to procure books so easily thanks to the link to my library, has motivated me to get organized and do more reading. I've gone back to reading literary blogs to find recommendations, I've taken part of literature events and creative writing classes and workshops, I've written down notes on what I am currently reading.

In general, I am enjoying consuming books again, and I don't have to force myself to read anymore. Instead, I crave finishing all my other tasks of the day as early as possible to dive into my Kobo and pick up my stories where I last left them. This has also helped reduce my doomscrolling time (although, I won't lie, I still lose time every day wandering the backdoors of TikTok and the like).

So, all things considered, I'm happy with my Kobo. So long, Kindle, you have been dethroned!

Block malicious user agents via nginx config

2024-10-05T00:00:00Z

Bots are everywhere, and so are malicious agents. They crawl, they scrape, they read... and sometimes (or most? of the times),they abuse.

A few times now, I've observed increased CPU / RAM consumption on servers where I wouldn't expect any usage on non-peak hours, and after browsing through access logs, I find out the cause is that certain bots are crawling my sites over and over again.

This has been made worse, for example, by certain WordPress plug-ins that generate links with unique GET parameters on each page load, making these not-so-smart crawler bots get stuck on an endless loop. What a waste of bandwidth and compute resources.

To put an end to this, I've now blocked by default certain user agents from accessing any of the websites I host, directly on nginx config. This ensures that malicious actors are stopped even before they can trigger any server execution or load static content. You can follow similar steps or even swap user agent for any other identifier you define to block agents from accessing your servers.

Create a list of blocked user agents #

Create a new file in /etc/nginx with the following content and any name you want.

I'll use blocked_user_agent.rules here:

map $http_user_agent $blocked_user_agent {
    # Requests are allowed by default
    default 0;

    # `~example` will match any user agent strings
    # that have `example` anywhere inside them.
    # Some examples:
    ~Amazonbot 1;
    ~openai 1;
    ~chatgpt 1;
    ~gptbot 1;
}

This list can get as short or as long as you need, and you can change it (whether to add or remove blocked user agents) anytime you need.

Block requests based on `$blocked_user_agent` #

Now that you have an easily-accessible map of user agents, it's time to make this variable available to nginx and block unwanted requests.

On /etc/nginx/nginx.conf, add the following at the end the http block:

http {
    # Skipping over content...
    # (...)

    # Include file with map of blocked user agents
    include /etc/nginx/blocked_user_agent.rules;
}

Finally, on the config files for each of your sites (inside /etc/nginx/sites-enabled/) add the following inside the server block, before you start matching for any locations:

server {
    server_name aitorres.com;

    # Blocking undesired user agents
    if ($blocked_user_agent) {
        # `444 No Response`, nginx specific HTTP status code.
        # You can choose to return other standard HTTP
        # status codes, like `404 Not Found` or `403 Forbidden`
        # base on your needs
        return 444;
    }

    # Rest of your usual file, unchanged
}

One more thing: reload or restart your nginx server from your shell.

# Ensuring config is valid
nginx -t

# Reloading the server without downtime, you can choose to restart as well
nginx -s reload

All done! Your server will start blocking these requests, and you should start seeing reduced resource consumption. If you have access logs enabled for your server, then you'll see the requests from blocked user agents logged with the HTTP status code you chose to return.

One final note: if you ever modify the list of blocked user agents, remember to reload or restart nginx for the changes to take effect.

This method is not infalible as it depends on the bot (or the malicious agent behind it) to consistently use the same user agent, but it's a start and just takes a couple minutes to add. Hopefully one day bots will stop misbehaving completely, but until then... ;-)

Handle errors on custom Elementor Form Actions

2024-09-22T00:00:00Z

If you're using the Elementor plug-in for WordPress, you might eventually need to customize one or several submit actions for Elementor Forms. For example, you might need to call a specific API on form submission or create custom rows in your database when the built-in actions (such as sending emails or saving submissions) fall short.

The official Elementor Form Actions documentation contains an introduction to form actions, including two code samples for creating new ones. However, none of the examples (or the rest of the documentation) showcase how to handle errors (e.g. how to inform the front-end that you can't process the data any further and the user must review their answers).

To achieve this, you can try the following code snippet:

public function run( $record, $ajax_handler )
{
  // This is the function that runs your custom action
  // to handle an Elementor Form submit

  // Let's try to do something that (we know) can fail
  try {
    action_that_can_fail();
  } catch (Exception $e) {
    // Adding the exception message to the AJAX handler
    $ajax_handler->add_error_message($e->getMessage());

    // You can also set the error to a specific field
    $ajax_handler->add_error(
      'username',
      $e->getMessage()
    );

    return false;
  }
}

Note that this code and its behavior are similar to those in the Elementor Form Fields documentation which I discovered after starting to write this blog post. However, since it's not mentioned on the Form Actions documentation, I hope this post serves as a bridge between the two for anyone wondering how to gracefully handle errors on form submission for their custom actions.

A fresh start

2024-09-08T00:00:00Z

Hello there! If you're reading this, welcome! And thanks! (And also: why!?)

This is (hopefully) my definite attempt to run a blog as a space to drop random thoughts, ideas and ramblings in public, and to improve my online presence. Or, at least, try to.

This first post doesn't have much content by itself, but is a testament to the day I finally got around to writing some minor code and (re-)starting my blog... after adding a task to my to-do list almost four years ago.

I guess I've been planning on doing this for quite some time...

I expect to expand on both the blog posts and the personal sections in the next few days (but if I had to set a due date, I'd pick December 2028, just to be consistent).

So, again, thanks for taking the time to explore my little outpost in the cyberspace! Hope to catch you again around here soon!