Gonçalo Valério

Tag: fediverse

  • Optimizing mastodon for a single user

    I’ve been participating in the Fediverse through my own mastodon instance since 2017.

    What started as an experiment to test new things, focused on exploring decentralized and federated alternatives for communicating on top of the internet, stuck. At the end of 2024, I’m still there.

    The rhetoric on this network is that you should find an instance with a community that you like and start from there. At the time, I thought that having full control over what I publish was a more interesting approach.

    Nowadays, there are multiple alternative software implementations that you can use to join the network (this blog is a recent example) that can be more appropriate for distinct use cases. At the time, the obvious choice was Mastodon in single user mode, but ohh boy it is heavy.

    Just to give you a glimpse, the container image surpasses 1 GB in size, and you must run at least 3 of those, plus PostgreSQL database, Redis broker and optionally elastic search.

    For a multiple user instance, this might make total sense, but for a low traffic, single user service, it is too much overhead and can get expensive.

    A more lightweight implementation, would fit my needs much better, but just thinking about the migration process gives me cold feet. I’m also very used to the apps I ended up using to interact with my instance, which might be specific for Mastodon’s API.

    So, I decided to go in a different direction, look for the available configurations that would allow me to reduce the weight of the software on my small machine, in order words, run Mastodon on the smallest machine possible.

    My config

    To achieve this goal and after taking a closer look at the available options, these are the settings that I ended up changing over time that produced some improvements:

    • ES_ENABLED=false — I don’t need advanced search capabilities, so I don’t need to run this extra piece of software. This was a decision I made on day 1.
    • STREAMING_CLUSTER_NUM=1 — This is an old setting that manages the number of processes that deal with web sockets and the events that are sent to the frontend. For 1 user, we don’t need more than one. In recent versions, this setting was removed, and the value is always one.
    • SIDEKIQ_CONCURRENCY=1 — Processing background tasks in a timely fashion is fundamental for how Mastodon works, but for an instance with a single user, 1 or 2 workers should be more than enough. The default value is 5, I’ve used 2 for years, but 1 should be enough.
    • WEB_CONCURRENCY=1 — Dealing with a low volume of requests, doesn’t too many workers, but having at least some concurrency is important. We can achieve that with threads, so we can keep the number of processes as 1.
    • MAX_THREADS=4 — The default is 5, I reduced it to 4, and perhaps I can go even further, but I don’t think I would have any significant gains.

    To save some disk space, I also periodically remove old content from users that live on other servers. I do that in two ways:

    • Changed the media cache retention period to 2 and user archive retention period to 7, in Administration>Server Settings>Content Retention.
    • Periodically run the tootctl media remove and tootctl preview_cards remove commands.

    Result

    In the end, I was able to reduce the resources used by my instance and avoid many of the alerts my monitoring tools were throwing all the time. However, I wasn’t able to downsize my machine and reduce my costs.

    It still requires at least 2 GB of RAM to run well, even though with these changes, there’s much more breathing room.

    If there is a lesson to be learned or a recommendation to be done with this post, it is that if you want to participate in the Fediverse, while having complete control, you should opt for a lighter implementation.

    Do you know any other quick tips that I could try to optimize my instance further? Let me know.

  • You can now follow this blog on the fediverse

    The possibilities of the ActivityPub protocol, and what it can bring to the table regarding interoperability in the social media landscape, are immense. It is specially welcome after a decade (and half?) plagued by the dominance of centralized walled gardens that almost eradicated the diverse ecosystem that previously existed.

    It is used by many software packages, such as Mastodon, Peertube, Lemmy and others. For all of them, you can run your own instance if you don’t want to sign up for the existing providers (just like email).

    By speaking the ActivityPub “language”, these services can communicate with each other, forming a network that we call the Fediverse.

    Recently, WordPress joined the party by adding support through a plugin. Since this blog runs on WordPress, its content is now available to be followed on any of those networks.

    Together with the existing RSS feeds, that you can add to your newsreader, you now have another way of getting the latest content without having to directly visit the website.

    To accomplish that, you just have to search for content@blog.ovalerio.net on any instance in the Fediverse.

    Keep in mind that my “real” account on that network is still dethos@s.ovalerio.net, where I share, much more frequently, short form content, such as links, that I find interesting.

  • Cleaning my follow list using “jacanaoesta”

    Last year we saw the rise of the Fediverse. Mostly because of a series of external events, that ended up pushing many people to try other alternatives to their centralized platform of choice.

    Mastodon was clearly the software component that got most attention and has been under the spotlight in the last few months. It wasn’t launched last year, in fact, mastodon instances (servers) have been online since 2016, managed by its developers and other enthusiasts.

    I’ve been running my own instance since 2017 and since then, I’ve seen people come and gone. I started following many of them, but some no longer are active. This brings us to the real topic of this post.

    Since I couldn’t find a place in the Mastodon interface that would allow me to check which users I follow are inactive, I decided to build a small tool for that. It also served as a nice exercise to put my rust skills into practice (a language that I’m trying to slowly learn during my spare time).

    The user just needs to specify the instance and API key, plus the number of days for an account to be considered inactive if the default (180 days) is not reasonable. Then the tools will print all the accounts you follow that fit that criteria. 

    Find people that no longer are active in your Mastodon follow list.

Usage: jacanaoesta [OPTIONS] <instance>

Arguments:
  <instance>

Options:
  -k, --api-key      Ask for API key
  -d, --days <days>  Days since last status to consider inactive [default: 180]
  -h, --help         Print help information
  -V, --version      Print version information

    And this is an example of the expected output:

    Paste API Key here:
Found 171 users. Checking...
veracrypt (https://mastodon.social/@veracrypt) seems to be inactive
...
fsf (https://status.fsf.org/fsf) seems to be inactive
38 of them seem to be inactive for at least 180 days

    Without the -k option, the program tries to grab the API key from the environment variables instead of asking the user for it.

    Problem solved. If you want or need to give it a try, the code and binaries can be found here: https://github.com/dethos/jacanaoesta

    Note: After publishing this tool, someone brought to my attention that Mastodon does indeed have a similar functionality in its interface. The difference being it only considers accounts that don’t publish a status for 1 month as inactive (it’s not configurable).

    You can find it in “Preferences → Follows and Followers → Account Activity → Dormant”

    Screenshot of where to find the "dormant" functionality.