nikclayton

If you're not sure about any of this you can contact the GoToSocial devs at https://codeberg.org/superseriousbusiness/gotosocial#contact -- there should be enough information here for them to determine if this is a misconfiguration of your server, a GoToSocial bug, or a Mastodon bug.

Your account name isn't displaying properly on Mastodon. It looks like this:

Note the :purplerabbit: in there.

This is because you have several emoji references in your account's display_name, but your account info doesn't include all the emoji details, so other servers can't show it.

nikclayton

Step 1. Get your authorization token

1. Open your account in the browser (i.e., open https://hachyderm.io and make sure you're logged in).

2. Open the inspector (Firefox: https://firefox-source-docs.mozilla.org/devtools-user/page_inspector/how_to/open_the_inspector/index.html, Chrome: https://firefox-source-docs.mozilla.org/devtools-user/page_inspector/how_to/open_the_inspector/index.html, Safari: https://developer.apple.com/documentation/safari-developer-tools/inspecting-safari-macos, then https://developer.apple.com/documentation/safari-developer-tools/web-inspector).

3. Make sure the inspector is showing network requests

nikclayton

[napkin sketch]

1. Create 1-N test bot accounts that follow different subsets of each other. Have them post predictable content on a regular schedule.

2. Monitor the bot posting software. Have it report errors and latency, and store the ID of each post when it's generated.

3. Write a client that, authenticated as each bot, fetches various permutations of the bot's home timeline with/without min_id/max_id/limit set. Because each bot's posts are predictable you can predict the timeline contents for each query, using the status IDs stored earlier. Have the client report good/bad results and latency to the monitoring system.

4. Alert on errors, and if latency exceeds some threshold.

nikclayton

To: Admins of tldr.nettime.org

Your server is configured with a reference to a URL on a server with an invalid SSL certificate.

To recreate this;

Fetch https://tldr.nettime.org/.well-known/nodeinfo

At the time of writing this has the following content (prettified):

nikclayton

Script to trigger the (possible) Dragonfly bug on a Mastodon account.

If this doesn't find any problems within the first limit=90 posts on your home timeline you can step back further by adjusting the first curl command in the script.

#!/bin/sh
#
# Assumes
#  - curl and jq are installed
#  - $TOKEN is your account's bearer token

nikclayton

Note

My previous post got some feedback from junior SWEs arguing -- roughly, and I'm paraphrasing -- the costs were way off and anyway this wasn't important because last year Hachyderm had "99.996% uptime" relying on a handful of volunteers.

This feels like a teachable moment, so here's an excerpt from the discussion that followed. I'm paraphrasing and removing names because the goal here is not to call out people earlier in their career, it's to highlight some of the things you need to think about when deciding if you want to run a service that people can rely on.

---

99.996% uptime or something

Right, but that's meaningless without knowing what the goal was, and an agreement on what "downtime" means. If the goal was higher then Hachyderm failed.

nikclayton

And it's still a largely meaningless number.

We don't set SLAs because we like setting SLAs.

We set SLAs because we're trying to capture an idea of "How badly can our service perform and our users are still happy?"

As an aside, what we're really talking about here are SLOs ("Objectives"). An SLA is the agreement you have with a customer if you break the SLO. But since we started with SLA as the term I'll stick with it.

They're not the only tool in our toolbox that helps with this. And like any tool, used as intended they can provide useful insight, but use them carelessly and they can be very misleading.

nikclayton

Mastodon service staffing

This is a somewhat hastily written reply to https://hachyderm.io/@esk/113793277371908181 .

I disagree a bit with Esk's finger-in-the-air estimates for number of staff required, their location, and their costs, and it didn't really fit in a single post or thread. In particular, I think it undercounts the number of people required to run the service, and ignores moderation.

As you'll see when you read this there are some big gaps in my knowledge around some best practices, particularly around moderation, so this is absolutely a draft. If you know more about this (or other topics) covered here and can suggest improvements then please do.

So, you want to launch a professionally run Mastodon service. How many people do you need?

nikclayton

• Date: 2024-07-28
• Status: Possibly incomplete / inaccurate

The client's goal during the OAuth sequence is to obtain a long lived access_token that can be used to authenticate future requests.

Data

Client managed

• domain
• The domain the user wants to log in to, e.g., mastodon.social

nikclayton

This is a very rough list of things to do in Pachli. Some of these are already filed as issues that may have more information, others aren't because I'm trying not to overwhelm the issue list with work that might be several months away.

This list is likely incomplete. See Issues · pachli/pachli-android · GitHub for more.

Finish code modularisation

What and why: Finish the work of splitting the code in to modules:

core:... modules with core functionality