I first started this personal website just about 20 years ago. It began as a couple of html pages, and spent time as a Wordpress blog, a Tumblr page, and is now a static blog generated by Jekyll. Through that time, it had always just had my name, alexonsager.com. This year, I’m rebranding it to Invisible Parade.

Being online then

When I started this site I had just entered university, got my first MacBook, and was excited to become a full-fledged citizen of the internet. At the time, I thought it was cool to publish as much of yourself as possible. Tag yourself and your friends in the photos you take, scrobble the music you listen to, check in to the places you go, tweet your thoughts. Since I was broadcasting myself to the world, it made sense to put my name on my website. That’s how people would know me.

At the same time though, Daring Fireball was a cool site with the coolest name. Daring Fireball man, how do you top that?

Envious, I found a site that generates random adjective + noun combinations and hoped for inspiration. The second or third result I got was “invisible parade,” and I immediately loved the oxymoron. The whole point of a parade is to be seen by all of the people. What then, is the point of an invisible parade?

The name stuck in my head, and I think at one point I may have bought the .net. But I didn’t have anything to do with it, and eventually let it expire.

Being online now

It feels less in fashion to use your full name as a brand now. There is the risk of bad attention following you around, but also it’s just more useful to have a persona. There are literally a gazillion people online, so “hey I have a website” is not enough to make you interesting. You have to let people know people what you’re about, show some personality.

My real-name domain feels like showing up to a costume party with a name tag that just says “Hi, my name is Alex”. It doesn’t feel fun anymore!

The rebranding

On a whim I looked up the invisibleparade domain, and it was available. It felt right, so I nabbed it, and here we are. And it is kind of a perfect name for the site.

I’m creating this parade of posts, if you will, and I’m putting in a real effort to make it interesting and nice to look at. But who’s even looking at it? What is the point of an invisible parade, or an invisible blog?

Well, it’s fun! I like putting it together. And if anybody happens to stumble across it, I’ll be happy to show it off. So here’s to another 20 years of parading.

Following up to my earlier post about the fediverse, I discovered GoToSocial. Compared to Mastodon which required a fair amount of server overhead (more than I could justify for just playing around online), GoToSocial is very lightweight: 1 CPU, 1GB memory, and 15GB-20GB of storage space for the first year or so. Sold!

This would let me set up my own single-user server, which solves all of my misgivings about Mastodon.

I have a VPS with Coolify to manage the multiple apps I have running, and all things considered it makes things very easy.
I used a docker-compose file to deploy GoToSocial, and their example file was almost perfect as-is.

Port settings

Coolify acts as a reverse proxy, so I used that part of the configuration:

services:
  gotosocial:
  ...
    ports:
      # - "443:8080"
      ## For letsencrypt:
      #- "80:80"
      ## For reverse proxy setups:
      - "127.0.0.1:8002:8080"

8002 was just an open port that I chose, and Coolify is smart enough to use that port to route traffic from my GoToSocial domain.

File permissions

Robb Knight’s blog post showed me how to fix the sqlite database being unable to load because of a permissions issue. I had a similar issue with the Wazero compilation cache directory not being created, but I ended up just commenting that line out because it works without.

Shooting myself in the foot

I knew I had to mount a volume to make the database persist across redeploys and not be wiped fresh every time. Coolify’s documentation made it very clear,

The base directory inside the container is /app. So if you need to store your files under storage directory, you need to define /app/storage as the destination path.

So, I changed the settings to make sure that things were stored under /app

services:
  gotosocial:
    ...
    environment:
      ...
      GTS_DB_ADDRESS: /app/storage/sqlite.db
    volumes:
      - ~/gotosocial/data:/app/storage

Which worked, except!
I hadn’t realized that media storage also defaulted to the same (first) /gotosocial/storage directory. Since this directory was no longer being bound, it was wiped clean after every redeploy. Remote media was fine because it could be fetched again, but images I uploaded were lost.

I poked around in the terminal and saw that both /app/storage and /gotosocial/storage were being created and used with no issues, so I just switched the database address back to the default /gotosocial/storage… and everything worked as expected.

So, I don’t quite understand what the Coolify docs were trying to tell me.

End

Things seem to be working fine now, and I’m using mostly Semaphore to interact with the instance.
You can follow me here!

For some reason, some sites would not load in Safari. Certain assets, often hosted on a CDN but not always, would hang forever and keep the page from loading. Other browsers worked, curl worked, so it didn’t seem like a DNS issue. It was driving me crazy.

I think I finally caught the culprit: Adguard’s network filtering.

Adguard gives you the option to filter all of your internet traffic for various apps on your computer. By default, it does so through a “Network Extension” that registers a local VPN to filter all traffic.

For some reason, this was tripping up just Safari and stopping certain assets from loading. An alternative mode called “Automatic Proxy” is available to avoid conflicts with other VPN applications and such, and switching to this mode seems to have fixed the problem for me. Good!

See Adguard’s documentation here.

From the repository:

Litestack is a Ruby gem that provides both Ruby and Ruby on Rails applications an all-in-one solution for web application data infrastructure. It exploits the power and embeddedness of SQLite to deliver a full-fledged SQL database, a fast cache , a robust job queue, a reliable message broker, a full text search engine and a metrics platform all in a single package.

I’ve been learning Python for my small projects recently, but for something that wants a full stack I’ll definitely be checking this out.

But it’s just not doing it for me.

The main selling point of Mastodon is its federation I think, and I tend to agree with Tim Bray’s points that some kind of decentralized, protocol-based network for social exchange is what will endure. Having one service run by one group of people is brittle. Having many services run by many groups of people is resilient.

People explain that Mastodon and the Fediverse are similar to email. You can make an account with any provider, and it lets you speak to anyone on a different service. You can have a Gmail account and still send emails to a Fastmail account.

But for me, the analogy is not apt, mainly because of server rules and moderation.

Moderation of Mastodon

Each Mastodon server has its own set of rules and moderation guidelines. There are things you can’t say on certain servers, and servers can even blacklist other servers if they notice a strong trend of bad activity. Let’s be clear, I prefer keeping angry Nazis away. But it’s not the same as an email provider.

Imagine if Gmail didn’t allow you to send emails that made derogatory comments. Or emails that contained copyrighted images. Or if Fastmail stopped allowing you to send emails to Hotmail users because there was too much spam coming from it.

The point is not whether those are good or bad decisions, but that it does matter who you sign up with.

Who do I want moderating my experience?

When comparing Bluesky to Mastodon, one point brought up often is that it is venture-backed. The service needs to generate money, and in the long run, for-profit services will go to shit. This is probably true.

Honestly, I’m OK with staying while it’s good and getting out when it gets bad. That’s what I’ve done with Facebook and Twitter and Instagram and whatever else. That’s life online.

The more pressing issue in the short term is who I want to be running the service I sign up for. The unpaid volunteers of a particular Mastodon instance who want to keep the service good because they care? Or paid employees of a publically scrutinized company who want to keep the service good for a strong salary?

Am I crazy to say that the latter feels more stable and reliable?

Passion projects fizzle out when the passion dies, but money keeps the wheels turning. Bluesky’s mission now is agreeable to me, so I’ll stay on their service and feel peace of mind. As the service strays from this ideal in the future, as it most likely will, I’ll look around for whatever better option is available then.

The actual best solution

If I want freedom and permanence together, the best solution is probably to run my own Mastodon server. And that does seem like the answer I’m looking for. I’m in control of my data and can do with it as I please. I can connect to other Mastodon instances and participate in the larger community. And while the small details may change, I can bet on a federated future that continues to let me maintain a node that plugs into a larger network.

The only problem, and it’s kind of a big one, is the price and the hassle. Setting up a Mastodon server is still kind of a lot of work, and the cost of upkeep is significant. I hope that entry costs will continue to go down because that is the future that I am most excited to see.