Mark Tomczak @mtomczak@qoto.org

Alright. :)

New server's been up and stable for a week, so I think it's time to move out. Time to test the account migration part of this system.

Catch y'all at @mark :)

Self-hosting a Mastodon server, thus far: the good, the bad, the ugly.

**The good:**

- Migrating from another server is very straightforward. Pieces of your account can be exported as CSV and consumed by another Mastodon server.

- Hackable server. I'm running a variant that adds some features (I've also bumped my character limit, because that's a function of the server features and not the protocol). Although it's Ruby on Rails with JavaScript as the UI layer, it's not deeply, deeply difficult to hack around on.

**The bad:**

- Setup is a chore. You can use Docker, but at the end of the day it's far from what most people without server admin experience would consider "turnkey." You'll still have to do the part where you push a bunch of nginx rules up and set up some security certificates by hand. In my case, I'm behind Cloudflare and that adds a bit of additional complexity because it's off the getting-started script (though other people have blazed this trail and helpfully put together guides for it).

**The ugly:**

- Stuff I think of as "par-for-the-course open-source usability sharp edges" are there. Little things that won't stop you from using it but indicate that nobody's paid to do the UX, like the fact that in the import UI and the export UI, the order of the "block list" and "mute list" options are flipped, increasing the odds that if you're ripping down CSV files by hand and then slamming them into the other UI, you'll swap the two. Fixable? Probably easily. But with all these eyes on the product nobody empowered to fix it has noticed or cared.

... all in all though, this is *way* low on the list of most painful open source projects I've ever tried to set up an install of, and I'm very, very impressed.

I am trepidatiously setting up my own account on my own Mastodon node: @mark. Not officially switching over yet because I want to confirm it won't set itself on fire, but feel free to toss me a follow.

... I was excited about this until I compared notes with a friend who does "say potato" to distinguish humans from AI voice recognizers and we realized we were inventing CAPTCHAs for voice callers because **this is hell the future is hell we're in hell.**

New strategy for identifying robocallers is hitting them with a #bluey quote.

If they continue on-script right past "Coconuts have water in them," the next message they get is "Add this number to your do-no-call list."

A "You wouldn't download a car" dedicated meme editor.

https://youwouldntsteala.website/editor.html

When you try and build someone else's full-stack web app for the first time.

(... yes, this includes you, #mastodon. ;) I see you in there with your four package managers and your curl-into-bash shortcuts.)

I may have to add to my list of reasons to discourage people from moving to Texas "No seriously, the state is becoming lethally hot, and "burning fossil fuel to run air conditioners to keep the lethal heat outside" is going to be about as long-term effective as cooling a room by leaving the refrigerator door open." https://journa.host/@w7voa/110704004711909429

Anyone have some good leads on how #docker networking works?

I think I need the ELI-5 hand-puppet version. Trying to wrap my head around whether I need to set different ports for every postgresql container I'm bringing up in a parallel dev / prod deployment on the same machine; I'd expect "they're in separate networks so they should be invisible to each other" but then these containers are also exposing the port in the host's network it seems? Because when I set the `networks` to `- backend` and `ports` to `5432:5432`, I can access that postgresql DB at localhost:5432 from the host environment.

Trying out some experiments.

Successfully got a #RaspberryPi visible on the public Internet for the first time in a long time.

#Cloudflare tunnels don't mess around yo.

"But a DSL would make it easier to represent the problem in..."

My blessed sibling in software... If it's a personal project, go nuts. If you're working in a group or for an employer, a DSL replaces one problem (representation complexity) with another problem (work grinds to an absolute halt when the one guy who knew how the DSL works quits and the team has to reverse-engineer the implementation of the DSL to understand what it does in an undocumented corner-case).

Make your decisions accordingly, with an eye towards the *engineering* part, not the *software* part.

@lauren Question: I'm thinking of setting up my own Mastodon node. What configuration are you running for yours? Did you host in the cloud somewhere or do you have a DNS name tied to an on-prem server?

I've got a home connection via Verizon to the Internet, and I"m weighing my options between paying for cloud service, upgrading to internet service that would give me a static IP, or mounting my instance on a Raspberry Pi at home and using some dyndns or no-ip service to account for the occasional IP address change.