Upgraded to v2.3.0

Free Radical is now on Mastodon v2.3.0.

Admin tip: if you’ve set UID and/or GID in your .env.production, be sure to update Dockerfile with ARG UID=... and ARG GID=.... If you don’t, you’re going to get lots of permission errors in the docker-compose run --rm web rails assets:precompile part of the upgrade process. Don’t be me.

That’s what I log about you

I deliberately log as little as possible about my users. My nginx logrotate config is configured to store one week’s worth of access and error logs:

/var/log/nginx/*.log {
    ...
    rotate 7
    ...
}

As of this moment, that looks like:

-rw-r-----  1 www-data adm     443615 Jan  5 08:29 freeradical.zone-access.log
-rw-r-----  1 www-data adm    5405613 Jan  5 06:25 freeradical.zone-access.log.1
-rw-r-----  1 www-data adm     395094 Jan  4 06:24 freeradical.zone-access.log.2.gz
-rw-r-----  1 www-data adm     407455 Jan  3 06:24 freeradical.zone-access.log.3.gz
-rw-r-----  1 www-data adm     375444 Jan  2 06:24 freeradical.zone-access.log.4.gz
-rw-r-----  1 www-data adm     474143 Jan  1 06:24 freeradical.zone-access.log.5.gz
-rw-r-----  1 www-data adm     344550 Dec 31 06:25 freeradical.zone-access.log.6.gz
-rw-r-----  1 www-data adm     452215 Dec 30 06:25 freeradical.zone-access.log.7.gz
-rw-r-----  1 www-data adm          0 Jan  5 06:25 freeradical.zone-error.log
-rw-r-----  1 www-data adm       1461 Jan  4 23:10 freeradical.zone-error.log.1
-rw-r-----  1 www-data adm        349 Jan  3 18:43 freeradical.zone-error.log.2.gz
-rw-r-----  1 www-data adm        458 Jan  3 03:35 freeradical.zone-error.log.3.gz
-rw-r-----  1 www-data adm        314 Jan  1 13:49 freeradical.zone-error.log.4.gz
-rw-r-----  1 www-data adm        428 Dec 30 16:01 freeradical.zone-error.log.5.gz
-rw-r-----  1 www-data adm        409 Dec 29 18:01 freeradical.zone-error.log.6.gz
-rw-r-----  1 www-data adm        387 Dec 29 05:47 freeradical.zone-error.log.7.gz

To be explicit: these are not usually processed in any way and are never used for analytics or tracking. I’ll occasionally (but rarely) use standard local Unix commands (grep, awk, etc.) to examine them directly on the server for troubleshooting, but that is their sole use and the only time they’re ever accessed.

Mastodon itself records a timestamp of each user’s most recent activity and IP address. I never access this information except in the course of investigating reports.

I have not enabled logging in S3, so I have no specific record of what media assets a user might have accessed. Amazon provides some aggregate statistics (“this many objects were accessed”, “we’ve served this many gigabytes of images”, “you owe us six bucks”, and so on) but nothing more granular.

Suspending domain 2.distsn.org

One of my users complained that they received spam from @mastodon_user_matching@2.distsn.org, whose timeline currently looks like:

@mastodon_user_matching@2.distsn.org spam

It turns out this whole instance is screaming with spam red flags:

  • It doesn’t verify email addresses1,
  • The site that the spambot is advertising, MastodonUserMatching.tk, is a redirect to vinayaka.distsn.org (which is on the same domain as the Mastodon instance2), and
  • The bot’s source has the same name (“vinayaka”) as the subdomain it’s spamming ads for.

I conclude that this instance is specifically deployed to allow and assist spamming, and as such, I’m suspending the 2.distsn.org domain effective immediately.


  1. Thanks to @kaniini@mastodon.dereferenced.org for pointing this out! 
  2. Thanks to @href@soc.ialis.me for pointing this out! 

When good people disagree

I kind of fell into a heated argument between well-intentioned people. While I actively do not want to become involved in every disagreement in the fediverse, enough people ended up participating that I wanted to offer my outsider’s take on events.

What happened

A new user, Pat, joined Free Radical a few days ago. They were active on birdsite but had heard about our growing community and wanted to check it out. I had a few chats with Pat about what makes the two networks different, and they were eager to get started exploring.

Some time last night, Pat found another user, Jan. Jan believes that people in Pat’s demographic have caused a lot of political and societal problems for people in Jan’s demographic. Pat, fresh from birdsite, saw this as an invitation to debate the point.

Things got a little heated.

At 3AM I woke up because our new comforter only has one temperature – “infernal” – and I thought I’d drop in to see what was happening online. Turns out quite a bit was happening and I was hearing about it. Pat and I had another chat about the social differences between birdsite and Mastodon. I went back to sleep.

This morning I woke up to more, ahem, discussion and a request from Pat: “Mastodon isn’t the place for me right now, please delete my account, and best wishes”.

I deleted their account.1

Observations

I’ve received no moderation reports on either party, and this post isn’t my reaction to anything external to my own thoughts. I’m just piecing together the implications of an unusual situation.

I read what Pat wrote. I think they’re a good person with good intentions who ended up in a disagreement. They felt like they were being attacked and responded to it. Their mistake – if you can call it that – was engaging in an argument with someone who wasn’t offering to argue with strangers. Pat came in from a network where such random arguments are much more common and accepted as normal.

I read what Jan wrote. I think they’re a good person with good intentions who ended up in a disagreement. They felt like they were being attacked and responded to it. Their mistake – if you can call it that – was accepting the offer to argue instead of ignoring an unwanted message. I truly understand that it’s easier said than done, though, especially when Jan had no intention of talking directly to Pat in the first place and almost certainly had no wish to have someone explain how they were “wrong”.

Mastodon truly isn’t “birdsite but on a different server”. This was largely built by and for minorities who’ve had a raw deal and want someplace safe to hang out. “Safe” does /not/ mean “echo chamber”! I’m continually exposed to opinions I don’t share, /and that’s great!/ It means I’m reminded that decent people I enjoy talking to sometimes have opinions significantly different from my own. It does mean that when you hear something you dislike2 that the best course of action is usually to try to listen, understand the speaker’s point of view, and then move on.

Even though Pat made the first mistake, in my opinion, I think they left on a high note by realizing that they weren’t in their element and bowing out gracefully. I would welcome them back as long they were willing to act within Mastodon’s social mores.


  1. I didn’t really delete their account because Mastodon doesn’t support that. I did disable their login and delete all their toots. 
  2. I’m talking about run-of-the-mill political disagreements, etc. I don’t expect anyone to keep quiet when they experience harassment, oppression, or other speech that actively seeks to make others feel unwelcome. 

Mastodon makes the internet feel like home again | The Outline

Mastodon makes the internet feel like home again, by @srol@mellified.men

Having been on the service for nine months myself, I can confirm Mastodon is not a replacement for Twitter. It’s much better. It is the first place on the internet where I have felt comfortable in a long time.

S3 URLs have changed; update your Content-Security-Policy

I’m serving Free Radical’s images etc. from S3. When I updated to Mastodon v2.1.0, I noticed that all the page’s images were missing. Safari’s Show JavaScript Console menu revealed a lot of errors like:

[Error] Refused to load https://s3-us-west-2.amazonaws.com/freeradical-system/accounts/avatars/000/014/309/static/91f9782fad3f6284.png because it does not appear in the img-src directive of the Content Security Policy.

Turns out that some time between the releases of v2.0.0 and v2.1.0, the Mastodon switched from generating S3 URLs like:

https://freeradical-system.s3-us-west-2.amazonaws.com/...

to

https://s3-us-west-2.amazonaws.com/freeradical-system/...

Because I’d jumped through the hoops of setting up a Content-Security-Policy header, Safari wasn’t allowing those images to render. I had to change my CSP header in Nginx from:

add_header Content-Security-Policy "default-src 'self'; img-src 'self' https://freeradical-system.s3-us-west-2.amazonaws.com/ data:; style-src 'self' 'unsafe-inline'; connect-src 'self' wss://freeradical.zone/; media-src 'self' https://freeradical-system.s3-us-west-2.amazonaws.com/";

to

add_header Content-Security-Policy "default-src 'self'; img-src 'self' https://freeradical-system.s3-us-west-2.amazonaws.com/ https://s3-us-west-2.amazonaws.com/freeradical-system/ data:; style-src 'self' 'unsafe-inline'; connect-src 'self' wss://freeradical.zone/; media-src 'self' https://freeradical-system.s3-us-west-2.amazonaws.com/ https://s3-us-west-2.amazonaws.com/freeradical-system/";

so that both the old and new S3 URLs are permitted.