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

nikclayton

There's some weird stuff in some server responses to /api/v1/instance and /api/v2/instance.

Here's some I've seen in the wild. Format is:

• Heading with server type (e.g., "akkoma") and whether this was v1 or v2
• Then the error when trying to parse the data
• Then a list of all the servers that triggered the same parse error, with their reported version number

Some of these have been fixed in newer versions of the servers but the fixes haven't fully rolled out.

nikclayton

On frustrations with the Mastodon experience

This is a reply to https://social.polotek.net/@polotek/111973724539175076 which rapidly became too long for a single Mastodon post.

I'm a client developer. I'm largely[^1] building a client that meets my needs, and hopefully it meets others needs as well.

When I see someone having a bad experience (your problem statement was "I can't seem to find many interesting conversations"[^2]) I'm interested in understanding the problem because maybe the client can be changed to improve that. I'll benefit, and so will everyone else that uses the client.

For example, would your experience be better if it was easier to browse or follow the local timelines of servers that are for specific communities? This might show you more people that you would be interested in following because they share your interests.