ActivityBot – Terence Eden’s Blog

I paid people to try and follow my README

Terence Eden — Sun, 11 Oct 2026 11:34:39 +0000

Developers suck at writing documentation. We like to say RTFM but often there ain't no FM to R. At best we have a half-arsed collection of notes, some obsolete tips, and a link to a desolate forum full of people asking the same questions again and again. That's no way to treat our users.

I naïvely believe there's a better way. As I've written before, you should sit down and actually test your readme. Spin up a fresh Virtual Machine, go through what you've written, and see if it makes sense.

But it is really hard to ignore your own biases. Of course you know that certain commands require sudo and obviously when you wrote -foo you meant --foo and everyone knows that you have to reboot afterwards.

How do you get rid of those biases? I paid people!

As part of my NLnet grant application for ActivityBot, I said I wanted to test the install experience with real users and I was prepared to pay them €25 for an hour of their time. I stuck out the call on Mastodon, gathered a few people, and had a video call with them.

The format was simple. I explained that I was looking for feedback on the first-run experience. I knew that it wasn't perfect and actively wanted constructive criticism. I asked the volunteer to share their screen and, crucially, to speak aloud. Tell me what they were doing. What they didn't understand, what confused them, what delighted them, what frustrated them, etc.

I took notes by hand (fuck feeding the machine) and spent several hours being told what incorrect assumptions I'd made.

Amongst the highlights I discovered were:

The link to the demo tool was wrong.
Some people read a README in the terminal.
What does it actually mean to rename a file?
How do you rename a hidden file?
Should a demo tool be available on the web or just the user's local machine?
Why does some text explicitly need to be quoted and some not?
My jokes aren't funny and are actively confusing.
Some of the technical terminology needed explaining.
The ordering of the different sections was confusing.
I hadn't actually explained what the software would do.
A whole section which was technically interesting to me was utterly confusing to everyone else.
Not all web servers use permissions in the same way.

And on it went!

After each session I updated the README based on what people found difficult, then I re-tested it with the next person.

In total, I paid out around €150 to have a bunch of people criticise me to my face. Hey, cheaper than therapy, right?

I know someone is going to say "why not just ask an LLM to simulate a range of users?" The answer is very simple - I want to speak to real people. People are brilliant! They can make you laugh, you can see their cat when it wanders on to the call, they bring a unique perspective to the problem, and they're really happy when you give them a €25 voucher. Some will gladly do it for free and make you happy!

When I was doing technical writing for GOV.UK, all my beautiful prose was given a second-eye by another human. They eviscerated all my flowery phrases and turned the document into something more readable. They were the ones who caught the mistakes that no spell chequer could. They were able to have a proper conversation with me. More importantly, I could hear the frustration in their voice - that's the thing which lets you know a mistake needs to be corrected.

I don't claim that ActivityBot's README is now perfect - far from it - but it is now demonstrably easier to follow. Developers need to talk to real people. You don't have to pay them if you can't afford it - but find a few people who will talk aloud while they try to follow your instructions. I guarantee you that your README will become much better for it.

Some quick thoughts on Unit Testing ActivityPub

Terence Eden — Sat, 10 Oct 2026 11:34:15 +0000

I'll be radically honest here - I never really got the idea of "Test Driven Development". I'm much more of a "telnet into production and damn the consequences" kind of guy. Look, it's much more fun and my cardiologist recommends severe shocks every now and again.

The essence of unit testing is pretty simple:

Feed a function some data
See how it responds

Send it good data and if it returns "true" the test passes. Send it bad data and make sure it returns false. Easy peasy lemon squeezy.

As part of my NLnet funded work on ActivityBot, I'm writing some proper tests for my bot framework. I am hopeful that some of them will be useful to other projects doing similar things.

There are four major classes of tests - here are the problems I've found while writing them.

Basic text validation

A basic test might be how to validate that an ActivityPub username is valid. Typically it would be something like @edent@mastodon.social - what assumptions do we make with that? It starts with an @ and has another @ somewhere in it, dividing into two parts, the user and the server. The server has to be a valid domain name - but that can include non-ASCII Internationalised Domain Names and Emoji domains.

What about the user part? Is it just A-Z and 0-9? Can it have dots? What about apostrophes like an email address?

Basically, how easy is it find the specifications for all the various component parts of ActivityPub? Not very!

Message validation

What does a WebFinger response look like? Which parts are mandatory and what values can they contain?

With any message that your project generates, how can you be sure that other ActivityPub servers will understand it?

Similarly, when we receive a follow message from an external server, what should it look like?

There are some JSON Schemas which can be used to validate some type of messages.

But, again, there are many scattered specifications.

Signature verification

As I've written about before, HTTP Signatures are difficult. There are two main problems. The first is verifying signatures.

In order to do that, you need to gather a bunch of signatures and then find a way to replay them into the test. So I'm in the process of saving signatures which I can then share with others.

The second problem is generating signatures. Sure, you can run tests on the signatures - but there's only one real way to test whether they're acceptable…

Communicating with others

Passing tests means nothing if you can't communicate with others and they can't communicate with you.

Some tests are easier than others. Sending a signed request should be easy and repeatable. But receiving messages isn't easily automated. It requires being able to control an external server and asking that to send messages.

With the Mastodon API it is possible to make requests which will interact with your server - but only if it is a public server.

Putting it all together

I'm putting all my tests online. I'm also sharing a collection of messages and signatures which you can use in your tests.

I'd love to know if you find them useful.

ActivityPub - How to send an updated user profile to Mastodon and the Fediverse

Terence Eden — Sat, 12 Sep 2026 11:34:02 +0000

Let's suppose you've updated the description of your ActivityPub account from "World's Number 1 Taylor Swift Fan" to "This account is now a Nickleback Truther". How do you let the rest of the Fediverse know that you've changed your allegiance?

By default, most Mastodon instances won't periodically poll your account information just to see if you've updated it. So how does the information get from your server to your followers' servers?

This wasn't immediately obvious to me, but I got a clue from reading Evan Prodromou's book on ActivityPub:

The Update activity type is for updating the properties of an object represented by the object property.

The most common types of objects that can be updated are content objects, like Note or Image. Actor types (like Person) and Question activity types can also be updated.

Aha!

You need to craft an Update message which has as its object the new user information. That needs to be sent to the inbox of all your followers.

Something like this:

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "actor": "https://example.com/user",
    "id": "6a9162a6-a8e5-ca0f-9c08-8e6b814acef8",
    "published": "2026-08-31T12:34:56+01:00",
    "to": "https://www.w3.org/ns/activitystreams#Public",
    "type": "Update",
    "object": {
        "@context": [
            "https://www.w3.org/ns/activitystreams",
            "https://w3id.org/security/v1"
        ],
        "id": "https://example.com/user",
        "name": "My new name",
        "summary": "A brand new description!",
        …
    },
}

Obviously the full user information is a bit more than that - it will include inbox details, public keys, avatars, etc. The published property in the Update activity should be when you changed your details - not when the account was created.

Once that was sent, Mastodon immediately reflected the changes.

Thanks to NLnet

This blog post was funded in part by the work I'm doing for my NLnet NGI0 grant to develop ActivityBot.

ActivityPub - Is it worth defending against replay attacks and message/signature time skew?

Terence Eden — Tue, 08 Sep 2026 11:34:51 +0000

Here's a problem that I've found with ActivityBot - my little ActivityPub server. Sometimes it receives messages which were originally sent months ago. Why does that happen and is it risky to accept and process them?

My tl;dr is that it probably isn't worth worrying about. But I'd love someone to tell me why I'm wrong.

Here's my thinking:

Causes

All ActivityPub messages should have a "published" timestamp in their body. Some will have an "updated" timestamp. That tells you, unsurprisingly, when the message is alleged to have been originally published or updated. That time might be very different to the time you receive the message.

There are, I think, three different reasons why a server might receive a message which has an out-of-date timestamp.

The first is that sometimes servers are just slow. Processing thousands of messages at the same time means that some of those messages take a while to send. ActivityPub is one big chain-mail so it can take several minutes for a message to be sent to all your followers.

Similarly, your server might be slow. If it doesn't acknowledge receipt of a message, the original server will try sending it again. Sometimes that can take a while.

Finally, some servers take a relaxed view of standards. They send an update to an old message but keep the original publication date. Ideally, they'd use an "updated" timestamp but quite often they don't.

For the purposes of checking the legitimacy of the message, you do not need to check when a message says it was published or updated. You might want to check it isn't an obviously bogus date like far in the future or impossibly far in the past - but that's up to you.

It is normal that your server receives messages which appear to have been published at a totally different time from now.

Is that a problem?

Probably not.

As described above, there are various reasons why a message may be delayed in transit - or may appear to come from the distant past.

What we can check is when the message was cryptographically signed by the sending server. This is independent of its published or updated timestamp.

HTTP requests to your server will have a date header which looks like Tue, 01 Sep 2026 15:54:21 GMT - this is in the slightly peculiar and Anglocentric RFC 5322 format.

New style RFC 9421 headers will also have a signature-input header which will contain something like created=1788278061. That uses the slightly obscure UNIX / POSIX time which counts seconds since the "Epoch" of 1st January 1970.

If you convert the UNIX time to something more modern, you should get an identical value to the date header.

But that isn't always the case. For example, the RFC 9421 standard gives this example:

Date: Tue, 20 Apr 2021 02:07:55 GMT
"@signature-params": ("@method" "@authority" "@path" \
  "content-digest" "content-length" "content-type")\
  ;created=1618884473;keyid="test-key-rsa-pss"

Converting 1618884473 to normal time gives Tue, 20 Apr 2021 02:07:53 - a two second difference.

If the date and created values differ significantly - that may indicate that the message is untrustworthy. Or that there was a delay between the signing and the sending.

The spec says:

The Date header field value represents the timestamp of the HTTP message. However, the creation time of the signature itself is encoded in the created signature parameter. These two values can be different, depending on how the signature and the HTTP message are created and serialized. Applications processing signatures for valid time windows should use the created signature parameter for such calculations. An application could also put limits on how much skew there is between the Date field and the created signature parameter, in order to limit the application of a generated signature to different HTTP messages.

7.2.4. Choosing Signature Parameters and Derived Components over HTTP Fields

But, of course, it doesn't tell you how much skew is problematic. It's up to you how much skew you're prepared to accept.

So that's the difference between the sent time and the signed time. The next time to check is your own. As we've discussed, sometimes servers are slow sending things out. Would you accept a request that was signed five minutes ago? Five days ago? Five months ago? What amount of difference is dangerous?

Here's what various services and sages have to say:

Mastodon

The request contains a Date header. Compare it with current date and time within a reasonable time window to prevent replay attacks.

How to make friends and verify requests

What is "reasonable"? The source code suggests one hour.

Grishka

Time in the Date header must differ from the recipient server’s clock by no more than 30 seconds

A bare-minimum ActivityPub server from scratch

Evan Prodromou

static #maxDateDiff = 5 * 60 * 1000 // 5 minutes

activitypub-bot

SWICG

The standards don't give a concrete time window to use for this comparison. In practice, an hour plus a few minutes buffer in either direction may be a good value, to account for both clock skew and differences in time zone/daylight savings time configuration across systems.

How To Verify a Signature

Others

Without naming names, it looks like a bunch of popular servers don't check whether there's a significant difference between the date the request was signed and the date it was received.

Summary

Various documents and implementations recommend anything between 30 seconds to "a bit more than 60 minutes". Or they just ignore any date difference.

What's the right answer? What happens if the signed date is significantly different from the current date?

What are we trying to protect against?

Replay Attacks. Suppose someone is listening to the communications between the sending server and your server. They copy the message that is sent to you. Later they send it again!

At this point, you might be thinking "so what?" and… I'm inclined to agree with you!

What's the worst that could happen if you received the same message multiple times? Two things that I can think of.

Firstly, it might not be the same message. It is possible to send a new message but with old headers. An attacker could make someone post "I hate Taylor Swift" against their will and watch as legions of fans disembowel the victim.

Except, I don't think this is likely. The signature in the header contains a hash of the message being sent. If you are properly validating the signature, a changed message will have a different hash from the one in the original message. You don't need to check timestamps, you just need to check if the hashes match.

Secondly, idempotence. That's a fancy word for "pressing the button multiple times should only result in one action".

What happens if a user appears to send you multiple "like" messages for a single post? You only record one like.

What if they send multiple messages with the same content? Well, each will have a unique ID in the message - so you only post it once.

What if they send multiple anythings? I can't think of any ActivityPub action which would not be idempotent.

About the worst thing I can think of is this:

Alice sends a message to you saying "I want to follow Bob".
Mallory intercepts this message.
You record Alice is now following Bob.
Alice sends a message to you saying "I want to unfollow Bob".
You record the severed relationship.
Mallory replays the original follow message.
You record Alice is now following Bob.

It's also possible the following could happen:

Alice posts a message saying "I love The Beatles".
You record Alice's message and display it on the timeline.
Alice updates her post to say "I love the Rolling Stones".
Mallory intercepts this message.
You record Alice's updated message and display the new version on the timeline.
Alice updates her post yet again to say "I love the Spice Girls".
You record Alice's updated message and display the new version on the timeline.
Mallory replays the original update message.
You now display that Alice loves the Stones rather than Spice Girls.

Perhaps the same can happen with like/unlike, block/unblock, boost/unboost.

But none of that is significantly prevented by checking the date.

Ultimately, it is up to your sever to check the unique ID of each message and refuse to action any repeated messages. You may not want to trust the unique ID which is sent with the message. If that's the case, you can calculate your own - perhaps using a hash of the contents, the signature, or some other process which will generate an ID based on the message.

Putting it all together

Here's what you need to do to prevent replay attacks:

Independently calculate the hash of the message received.
Validate that your calculated hash matches the hash sent in the message's HTTP headers.
- If not, this is a potential replay attack and the message must be ignored.
Verify that the signature received in the message's HTTP headers includes the message hash and is cryptographically valid.
- If not, the signature is invalid and the message must be ignored.
Has the received message's unique ID already been processed?
- If so, refuse to process it again.

I don't see what checking the timestamp of the HTTP signature has to do with anything. Someone who has access to the original messages and their headers could send them milliseconds after the original delivery.

I think it is probably pragmatic to give messages 60ish minutes grace before dropping them. Delays happen, but anything more significant than an hour might indicate a attack. But, equally, might just mean that the Internet is having a slow day.

If you are correctly checking signatures and hashes, I don't think you need to worry about skew between signature date and delivery date.

No! You're wrong and I can prove it!

Please tell me where I have erred! Stick a comment in the box or drop me an email. If I've made a massive or subtle mistake, I'd love to know what.

A reasonably practical guide to validating RFC 9421 HTTP Signatures for ActivityPub in PHP

Terence Eden — Thu, 03 Sep 2026 11:34:12 +0000

If you're reading this, you've probably been hitting your head against a brick wall trying to parse and decipher the new HTTP Signatures sent by Mastodon and other Fediverse servers.

This is a basic and somewhat incomplete guide to accepting these signatures. I'm sure there are various gotchas, but it works with the signatures I've seen in the wild.

Shut Up And Show Me The Code!

OK, wow, no need to be a dick about it! Here's how I validated a real signature that my server received. This requires PHP 8.4 or newer.

$verified = openssl_verify(
    data:       '"@method": POST
"@target-uri": https://example.viii.fi/inbox
"content-digest": sha-256=:tFdB/ENGczHMlZMDb66pXoUi2d0OqH2iBHdnN/WV1mc=:
"@signature-params": ("@method" "@target-uri" "content-digest");created=1787780262;keyid="https://mastodon.social/users/Edent#main-key"',
    signature:  base64_decode( "sIfmNsM/Q8iG6AJlne1IkZVjQSVFDEYIPsnoSOXQY+W3Eb4+SOn9o4J5SQmFOP+Jecjf3ioFwUdsrFjAGkUUOHPvSbNWkGKtNuGm+C6r3aI3JBCFGPqX3ITgZYV76CF7JJJ5hPGaG8YH/XdmxVIeFfD3M39FQCncMyyq7xJJvwKKP1mzS5s1vNQie8hbQ9owRjtqvoWcmM9GEYCUHNcMPLjZc+CBrj8sfBbNTYgIFI4UtirOaRJvYymxXjmXuzeVYxQujMjAjgobxQ8QFv0zlYsHk+gS5EYyafpJG9zmfCFSoF9+ZwqKNADmuADbISD9LZIH/bmkPoNXhxaeFPqYog==" ),
    public_key: "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsYMEs4waqk/6gaS+xn1T\nYygElTtNIFNkBcEdEBMaeoGVhyZiVKtSjJCS4z+X+394PKvcfSTcFILIt2GI2jOB\nHD0M2fFgxc8mmdSdCQkgEh9jF3bFI3kopDvzYf726iioYKlHXKpfPKvFt7EJgKH7\naCtS25NQkek3YUd6y3VBcT3R6Xhze9P3QNoZMIsFXklgXDKj+EllfbUqLf1vxt3s\nmD9ETxy2bJi9FheE0uY2WhARn49XAvwczM5Wzt+zqxVEtgpi5v2+ZZAVKhDnJkiC\nCCuI6hrSnKNIx/5mSlX0a0S5h5d03djrCkYsqmwelu01rhOXP2grsz4BXp0y2wrO\n3QIDAQAB\n-----END PUBLIC KEY-----\n",
    algorithm:  "sha256"
);

echo $verified;

Copy and paste that into PHP and you should see that $verified is true.

NOW EXPLAIN THE CODE

Say please.

PLEASE!!!

Along with the message sent to your server, you will have received HTTP headers like this:

content-digest: sha-256=:tFdB/ENGczHMlZMDb66pXoUi2d0OqH2iBHdnN/WV1mc=:
signature: sig1=:sIfmNsM/Q8iG6AJlne1IkZVjQSVFDEYIPsnoSOXQY+W3Eb4+SOn9o4J5SQmFOP+Jecjf3ioFwUdsrFjAGkUUOHPvSbNWkGKtNuGm+C6r3aI3JBCFGPqX3ITgZYV76CF7JJJ5hPGaG8YH/XdmxVIeFfD3M39FQCncMyyq7xJJvwKKP1mzS5s1vNQie8hbQ9owRjtqvoWcmM9GEYCUHNcMPLjZc+CBrj8sfBbNTYgIFI4UtirOaRJvYymxXjmXuzeVYxQujMjAjgobxQ8QFv0zlYsHk+gS5EYyafpJG9zmfCFSoF9+ZwqKNADmuADbISD9LZIH/bmkPoNXhxaeFPqYog==:
signature-input: sig1=("@method" "@target-uri" "content-digest");created=1787780262;keyid="https://mastodon.social/users/Edent#main-key"

The signature-input tells you how to construct a "Signature Base". You have to build a text string which places the various components in the order specified and separated with a newline:

"@method": POST
"@target-uri": https://example.viii.fi/inbox
"content-digest": sha-256=:tFdB/ENGczHMlZMDb66pXoUi2d0OqH2iBHdnN/WV1mc=:
"@signature-params": ("@method" "@target-uri" "content-digest");created=1787780262;keyid="https://mastodon.social/users/Edent#main-key"

Where @method is the HTTP method used to send data to your server (usually GET or POST), and @target-uri is the URl the message was sent to (usually your inbox).

The publicKey is slightly trickier. As you can see, the signature-input ends with keyid="https://mastodon.social/users/Edent#main-key

If you make a signed request to that URl, you'll get back an ActivityPub Actor document. It will look something like this:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/security/v1",
  ],
  "id": "https://mastodon.social/users/Edent",
  "webfinger": "Edent@mastodon.social",
  "type": "Person",
  "name": "Terence Eden",
  "publicKey": {
    "id": "https://mastodon.social/users/Edent#main-key",
    "owner": "https://mastodon.social/users/Edent",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsYMEs4waqk/6gaS+xn1T\nYygElTtNIFNkBcEdEBMaeoGVhyZiVKtSjJCS4z+X+394PKvcfSTcFILIt2GI2jOB\nHD0M2fFgxc8mmdSdCQkgEh9jF3bFI3kopDvzYf726iioYKlHXKpfPKvFt7EJgKH7\naCtS25NQkek3YUd6y3VBcT3R6Xhze9P3QNoZMIsFXklgXDKj+EllfbUqLf1vxt3s\nmD9ETxy2bJi9FheE0uY2WhARn49XAvwczM5Wzt+zqxVEtgpi5v2+ZZAVKhDnJkiC\nCCuI6hrSnKNIx/5mSlX0a0S5h5d03djrCkYsqmwelu01rhOXP2grsz4BXp0y2wrO\n3QIDAQAB\n-----END PUBLIC KEY-----\n"
  },

The publicKeyPem is the string you need. There's no need to convert the \n to literal newlines.

Is that it?

Not quite! All we've done so far is verify the headers. It is possible that these are genuine headers but attached to a fraudulent body.

This takes us back to the header "content-digest": sha-256=:tFdB/ENGczHMlZMDb66pXoUi2d0OqH2iBHdnN/WV1mc=:

That says that the body of the message sent has a Base64 encoded SHA256 hash of tFdB/ENGczHMlZMDb66pXoUi2d0OqH2iBHdnN/WV1mc=.

To calculate your own content digest in PHP:

$input = file_get_contents( "php://input" );
$digestCalculated = base64_encode(
    hash(
        algo: "sha256",
        data: $input,
        binary: true
    )
);

Does your digest match the one sent along with the headers? If not, something dodgy is going on.

Putting it all together

The steps are:

Get the headers.
Get the body.
From the headers' content-digest extract the algorithm and hash.
Using the body, calculate your own hash using the algorithm from content-digest.
Does your hash match the sent hash? If not, stop. If so, proceed.
From the headers' signature extract the base64 encoded signature.
From the headers' signature-input extract the signature-input string.
From the signature-input string extract the order of the Signature Base.
Construct the Signature Base.
From the signature-input string extract the keyid.
Get the Public Key from the keyid.
Use openssl_verify() to verify the Signature Base and the base64 decoded signature, against the Public Key using SHA256.

Note, Mastodon only uses SHA256. I think it should explicitly say which algorithm it is using and have raised the issue.

In Code Form

This is how you do it in PHP. Please read this carefully as there are some hard-coded assumptions.

<?php

//  Validate the Digest.
//  It is the hash of the raw input string, in binary, encoded as base64.

//  The format is content-digest => <algorithm>=:<base64 encoded hash>:
$digestString = $headers["content-digest"];
//  The Base64 encoding may have multiple `=` at the end. So split this at the first `=`.
$digestData = explode( separator: "=", string: $digestString, limit: 2 );

//  Hashes are in lowercase, but have a `-` in their name.
//  This is not what hash_algos() expects.
$digestAlgorithm = str_replace( search: "-", replace: "", subject: $digestData[0] );

//  The hash is surrounded by `:` characters.
$digestHash = str_replace( search: ":", replace: "", subject: $digestData[1] );

//  Check if the hash algorithm is one known about to PHP.
//  If not, reject and record an error.
if ( !in_array( needle:$digestAlgorithm, haystack: hash_algos() ) ) {
    return false;
}

//  Manually calculate the digest based on the data sent.
$digestCalculated = base64_encode( hash( algo: $digestAlgorithm, data: $input, binary: true ) );

//  Does our calculation match what was sent?
if ( !( $digestCalculated == $digestHash ) ) {
    return false;
}

//  The signature format is signature => <signature name>=:<base64 encoded hash>:
$signatureString = $headers["signature"];
//  The Base64 encoding may have multiple `=` at the end. So split this at the first `=`.
$signatureData = explode( separator: "=", string: $signatureString, limit: 2 );
$signatureName = $signatureData[0];

//  The signature is surrounded by `:` characters.
$signatureB64 = str_replace( search: ":", replace: "", subject: $signatureData[1] );

//  The signature-input format is complicated!
$signatureInputString = $headers["signature-input"];

//  Get the parameters. Assume there is only one signature.
$signatureParamsString = explode( separator: "=", string: $signatureInputString, limit: 2 )[1];

//  Get the different elements of the signature.
$signatureInputData = explode( separator: ";", string: $signatureInputString );

//  Construct the data.
$signatureInput = [];
foreach( $signatureInputData as $signatureInputParts ) {
    $partsData = explode( separator: "=", string: $signatureInputParts );
    //  Strip quotes from keyid and parentheses from sig1.
    if ( "keyid" == $partsData[0] ) {
        $partsData[1] = str_replace( search: "\"", replace: "", subject: $partsData[1] );
    }

    if ( $signatureName == $partsData[0] ) {
        $partsData[1] = str_replace( search: ["(", ")"], replace: "", subject: $partsData[1] );
    }

    $signatureInput[ $partsData[0] ] = $partsData[1] ;
}

$signatureStructure = $signatureInput[$signatureName];
$signatureKeyID     = $signatureInput["keyid"];

//  Remove quotes.
$signatureStructure = str_replace( search: "\"", replace: "", subject: $signatureStructure );
$signatureStructureData = explode( separator: " ", string: $signatureStructure );

//  https://www.rfc-editor.org/info/rfc9421/#section-2.5
$signatureBase = "";
foreach ( $signatureStructureData as $signatureStructureParts ) {
    if ( "@method" == $signatureStructureParts ) {
        //  https://www.rfc-editor.org/info/rfc9421/#name-method
        $signatureBase .= "\"@method\": " . $_SERVER["REQUEST_METHOD"] . "\n";
    }
    if ( "@target-uri" == $signatureStructureParts ) {
        //  https://www.rfc-editor.org/info/rfc9421/#section-2.2.2
        //  Change the domain name to your own.
        $signatureBase .= "\"@target-uri\": https://EXAMPLE.COM" . $_SERVER["REQUEST_URI"] . "\n";
    }
    if ( "content-digest" == $signatureStructureParts ) {
        $signatureBase .= "\"content-digest\": $digestString\n";
    }
}

//  https://victoronsoftware.com/posts/http-message-signatures/#how-the-signature-is-created
$signatureBase .= "\"@signature-params\": $signatureParamsString";

//  Get the signing user's public key.
//  This is usually in the form `https://example.com/user/username#main-key`
//  This is to differentiate if the user has multiple keys.
//  This may need to be a signed request. You will need to write your own getDataFromURl() function to get the sending user's key.
$userData  = getDataFromURl( $signatureKeyID );
$publicKey = $userData["publicKey"]["publicKeyPem"];

//  Verify the request
$verified = openssl_verify(
    data:       $signatureBase,
    signature:  base64_decode( $signatureB64 ),
    public_key: $publicKey,
    algorithm:  $digestAlgorithm
);

//  Convert the result to boolean.
if ( $verified === 1 ) {
    $verified = true;
} elseif ( $verified === 0 ) {
    $verified = false;
} else {
    $verified = null;
}

return $verified;

Thanks to NLnet

This blog post was funded in part by the work I'm doing for my NLnet NGI0 grant. Thanks!

ActivityBot is the recipient of an NLnet grant!

Terence Eden — Sun, 30 Aug 2026 11:34:55 +0000

Back in February, I applied for NLnet's Next Generation Zero grant. They were looking for Fediverse projects to help rewild the social media landscape. Or, as they describe it:

Reclaim the public nature of the internet

Small and medium-sized R&D grants between 5.000 and 50.000 euro, with the possibility to scale up.

I run ActivityBot - it is a single-file ActivityPub server suitable for launching automated accounts and designed as a learning tool for those who want to understand how the protocol works. Several people have told me how useful it is, but I haven't had the time to make it better. So I decided to stick in a last-minute application to the fund.

I really didn't know how much to apply for - or even if my project would be suitable for funding - so I cheekily asked for €10,000. After a few months of back-and-forth, I'm delighted to announce that I was successful!

In the spirit of openness, this blog post details how the NLnet grant process worked for me and what I'll be using the money for.

The Process

The application was delightfully simple. Here's what it asked for, along with my answers. If you apply, please don't copy these verbatim; use your own words.

Abstract : A single file server for ActivityPub. Designed for write-only bots. Allows any project to quickly and easily start publishing automated content to the Fediverse. Uses PHP, no other dependencies.
Experience : I am the sole developer of Single File ActivityPub - https://gitlab.com/edent/activitypub-single-php-file
I was formerly the UK Government's representative to the W3C and have contributed to various ActivityPub projects and specifications.
Amount : € 10000
Use : The fund will be used for development, testing, promotional activity (including conference travel).
I anticipate this will fund 6 months of development. I have funded all previous development.

Comparison : Most ActivityPub services are complex. They implement a full specification and are designed for multi-user environments. Other projects allow reading and writing. ActivityBot is deliberately designed to be as simple as possible. A single file to upload, one user, publish only.
This will enable more projects to be able to instantly start publishing with low development cost and close to zero hosting cost.
Challenges : Formal spec verification and a security audit will be the main technical challenges. The ActivityBot software has been running well for over a year. The funding will allow for better compatibility and security.
Ecosystem : The project has mostly targeted individuals who want to run small bots. After further development, the project will engage with IoT providers, smaller publishers, open source projects who wish to publish updates, and other relevant parties.

I was told there was intense competition. After a couple of months, I received word that I'd made it to the 2nd round.

What then followed was a very polite interrogation about my ideas, how I would develop the project, what I would use the money for, and what my AI usage policy was. They also wanted a breakdown of the main tasks - with the understanding that this would be a provisional document subject to change.

I was on a train through Europe when I wrote this. I don't claim it to be a brilliant document - but it got the job done!

1. User Research
Recruit 2 - 5 potential users. Offer an incentive (approx £20ea) to participate in a user research session. Study design will take 1 - 2 days. Each interview and write up to take 1 day. Consolidation and report 2 days.
Total effort 3 - 4 weeks.
2. Standards Research
Participate in ActivityPub user communities and standardisation groups. Attend virtual conferences (or any local to the UK). Approx 1 day per week for 6 months.
3. Test Driven Development
Create modern test harness, write test suite, iterate design based on tests. Anticipated effort 2 days per week for approx 3 months.
4. Security Testing
Work with the community and security professionals to test the resultant code. This will use human testers and normal fuzzers - this will not use AI tools. Anticipated effort 2 days per week for approx 2 months.
5. User Acceptance Testing
Recruit 2 - 5 potential users (ideally different to the research participants). Offer an incentive (approx £20ea) to participate in a user acceptance session. Study design will take 1 - 2 days. Each interview and write up to take 1 day. Consolidation and report 2 days.
Total effort 3 - 4 weeks.
6. Updates Based on Research, Testing, and Security
While it would be lovely to anticipate getting everything right first time, the reality is that changes will need to be made based on the findings of the above. This will take up the remainder of the allocated time.

Again, there was a little more back and forth. But a few weeks later I was informed that I was at the final stage, pending review. And, a few weeks after that, I was told my project had been given the green light.

I was invited to a group call where the very friendly team discussed the practicalities of the grant, what it could and couldn't fund. I also met a bunch of other people who'd also won.

The final stage was writing a proper Memorandum of Understanding. With the help of one of the team (thanks Victoria!) I was able to turn my scrappy plan into something a bit more formal. The project tool NLnet uses made it easy to build up a plan and put € amounts by each task.

The idea is that I will invoice against the grant whenever I have completed a task or sub-task. Obviously I don't want to leave invoicing until the end of the project, but I also need to be mindful of the foreign exchange fees charged by my bank for receiving Euro payments.

Final Project Plan

This is the plan I submitted. It represents what I hope to accomplish and how I'll draw down on the grant. I suspect this will change as the months go on.

ActivityBot is an Open Source project which aims to develop, maintain, and improve a minimum viable ActivityPub server in a single PHP file.

The project is run by Terence Eden (trading as @edent); a developer residing in England.

This project is expected to run for approximately 6 months. All of the deliverables will be openly licenced using either an OSI approved software licence or a Creative Commons licence.

The high-level aims of the project are for ActivityBot to be:

A fully compliant ActivityPub server, running in a single PHP file.
A teaching tool to help developers understand the practical aspects of creating an ActivityPub server.
A practical method of publishing automated messages to the Fediverse.
A promotional tool to show how simple and easy ActivityPub development can be.
A secure and usable tool written in modern PHP.
Written by humans, with no AI/LLM generated code.

In light of NLnet's non-profit status, costs assume a discounted rate of €330 per day (£280). Incidentals such as hardware, software, travel, or sundries will be charged at cost with receipts provided.

Prepare for initial release

Ensure that the project is in a suitable state for initial release and future development.

Deliverable: Updates published to GitLab.

€495 Prepare initial release. Clarify licencing, solicit community engagement, include example usage.
€495 Standards Research. Collation of standards websites. Ensure code comments refer to specific standards. Publish blog post(s) about findings for others to reference.

User Research

Recruit up to 10 participants for a user-research study. Participants should represent the diversity of the Fediverse.

Investigate what participants want from a tool like ActivityPub. The project plan may be adapted following the results of this study.

Deliverable: Study plan and results will be published and given a Creative Commons licence. Changes based on the results will be pushed to GitLab.

€660 Study Design and recruitment of participants (blog post published as deliverable).
€990 Two days of user interviews, write up and publish results as blog post.

Test Driven Development

Create a modern test harness, write test suite, iterate design based on tests.

Deliverable: Tests published to GitLab. Blog posts published about the process and results.

€330 Set up test suite
€330 Write tests
€330 Fixes based on test results

Security Testing

Working with NLnet's security offering, ensure that the project meets modern security requirements.

€720 Work with security team to assess security risks and possible mitigations. Fixes based on security team feedback

Deliverable: Updates published to GitLab. Blogs published about the process and results.

User Acceptance Testing

Recruit up to 10 participants for a user-acceptance study. Participants should represent the diversity of the Fediverse.

Investigate whether participants are able to use ActivityBot. See which aspects need improvement. The project plan may be adapted following the results of this study.

Deliverable: Study plan and results will be published and given a Creative Commons licence. Changes based on feedback will be published to GitLab.

€660 Study Design and recruitment of participants (blog post published as deliverable).
€990 Two days of user interviews, write up and publish results as blog post.

Conferences and Standards Work

Open Source participation often depends on attending conferences, either in person or virtually. Getting involved in the standardisation process ensures that future versions of ActivityPub and associated standards will be suitable for the community.

Deliverables: Presentations material (slideware), speaking at conferences (may be published as video), conference outputs. Where possible, these will be available under a suitable Creative Commons licence.

€700 Travel and accommodation to one EU conference
€330 Publishing blog posts about ActivityPub standards work.
€330 Publishing blog posts about ActivityPub standards work.

Final release

Creating a final release for this phase of the ActivityBot project. This will involve incorporating all feedback received so far, improving documentation, and publishing code.

Deliverable: Updates published to GitLab. Blog post written. Release announcements.

€330 Phase 1: Process and implement feedback from users
€330 Phase 2: Bug fixes
€330 Phase 3: Features
€330 Phase 4: Bug fixes
€330 Phase 5: Features
€330 Phase 6: Remedial work
€330 Process and implement feedback from accessibility scan
€330 Final release

Next Steps

I've already begun work on updating the code. If you'd like to get involved, or have suggestions or bug reports - please take a look at ActivityBot on GitLab.

I'll be putting out a call for user-research participants once I've had a chance to catch my breath 😆

[RSS Club] I got an NLnet grant!

Terence Eden — Sat, 08 Aug 2026 11:34:15 +0000

Pssst! This post is only available to RSS/Atom subscribers. Tell your friends to subscribe 😊.

Just a quick one today, a more detailed blog coming soon - but I thought I'd give RSS Club Members (you!) a sneak peek.

A few months ago I saw a post on Mastodon from NLnet - they were looking for Open Source projects to apply for grant funding. The deadline was less than 24 hours away, so I rushed in an application.

There was a ping-pong of emails where I detailed more about what I planned to do, and where they kept me abreast of their timescales.

Finally, after about 6 months, I received the most delightful email confirming my place in the programme!

I'm officially part of the NGI0 Commons Fund.

So, what's the project? Regular readers will remember that I created ActivityBot as a lightweight, single-file, fully featured ActivityPub server. The grant will enable me to improve the code, test the usability, have a security audit, do some accessibility work, and make it more robust.

I'm also going to need a logo 🤖

Because this is an RSS-only post, it doesn't support comments. You can get in touch with me if you'd like to say something nice.

Some updates to ActivityBot

Terence Eden — Mon, 16 Mar 2026 12:34:57 +0000

I couple of years ago, I developed ActivityBot - the simplest way to build Mastodon Bots. It is a single PHP file which can run an entire ActivityPub server and it is less than 80KB.

It works! You can follow @openbenches@bot.openbenches.org to see the latest entries on OpenBenches.org, and @colours@colours.bots.edent.tel for a slice of colour in your day, and @solar@solar.bots.edent.tel to see what my solar panels are up to.

This is so easy to use. Copy the PHP file (and a .env and .htaccess) to literally any web host running PHP 8.5 and you have a fully-fledged bot which can post to Mastodon.

Grab the code and start today!

Features

Over the years I've added a few more features to it, so I thought I'd run through what they are. Note, this is all hand-written. No sycophantic plagiarism machines were involved in this code or blog post. I just really like emoji, OK⁉️

🔍 Be discovered on the Fediverse

This is the big one, you can find @example@example.viii.fi on your favourite Fediverse client. This is thanks to its WebFinger support.

👉 Be followed by other accounts

No point being discovered if you can't be followed. This accepts follow requests and sends back a signed accept.

🚫 Be unfollowed by accounts

Sometimes people want to unfollow. Too bad, so sad. Again, this will accept the undo request and delete the unfollowing user's information.

📩 Send messages to the Fediverse

If a bot can be followed, but never posts, does it make a sound? This sends a post to all of your followers' (shared) inboxes. Includes some HTML formatting.

💌 Send direct messages to users

Not every message is for the wider public. If you want a bot which sends you a private message, this'll set the visibility correctly.

📷 Attach images & alt text to a message 🆕🆕

A picture is worth a thousand words. But those pictures are meaningless without alt text. Attach as many images as you like. Note, most Mastodon services only accept a maximum of four.

🍿 Video Upload 🆕🆕

No transcoding or anything fancy. Upload a video and it'll be sent to your followers.

🔊 Audio Upload 🆕🆕

Same as video. Raw audio posted to your followers' feeds.

🕸️ Autolink URls, hashtags, and @ mentions

Including URls, tags, and mentions are mostly autolinked correctly. There's a lot of fuzziness in how it works.

🧵 Threads

You can reply to specific messages in order to create a thread.

👈 Follow, Unfollow, Block, and Unblock other accounts

It might be useful for you to remove followers or follow specific accounts.

🗑️ Delete posted messages and their attachments 🆕🆕

We all make mistakes. This will delete your post along with any attachments and send that delete message to everyone. Note, because of the federated nature of the Fediverse, you cannot guarantee that a remote server will delete anything.

✏️ Edit Posts 🆕🆕

If you don't want to delete and re-post, you can edit your existing posts.

🦋 Bridge to BlueSky with your domain name via Bridgy Fed

Not everyone is on the Fediverse. If you want to bridge to BlueSky, you can use the Bridgy Fed service.

🚚 Move followers from an old account and to a new account 🆕🆕

Perhaps you started as @electric@sex.pants but now you want to become @chaste@nunslife.biz - no worries! You can tell followers you've moved and what your new name is.

Similarly, if ActivityBot is no longer right for you, it's simple to tell your existing follower to move to your new account.

🗨️ Allow quote posts 🆕🆕

Rather than just reposting your message, this sets the quote policy to allow people to share your message and attach some commentary of your own.

👀 Show followers

Your follower count isn't just a number, it is a living list of who chooses to follow you.

⚠️ Content Warnings 🆕🆕

Perhaps you want to hide a bit of what you're saying. Add a content warning to hide part of your message.

🔏 Verify cryptographic signatures

HTTP Message Signatures is hard. I think I've mostly got it sorted.

🪵 Log sent messages and errors

This is primarily a learning aide, so have a rummage through the logs and see what's going on.

🚮 Clear logs when there are too many

ActivityPub is a chatty protocol. Your server can easily fill up with hundreds of thousands of messages from others. This regularly prunes down to something more manageable.

#️⃣ Hashed passwords for posting 🆕🆕

Bit of a guilty moment here. I was originally storing the password in plaintext. Naughty! Passwords are now salted and hashed.

💻 Basic website for showing posts

A nice-enough looking front end if people want to view the posts directly on your domain.

Some Deficiencies

Not every piece of software is perfect. ActivityBot is less perfect than most things. Here are some of the things it can't do and, perhaps, will never do. If you'd like to help tackle any of these, fork the code from my git repo!

⏳ Retry Failed Messages

A proper Mastodon server will keep trying to send messages to unresponsive hosts. ActivityBot is one-and-done. If a remote server didn't respond in time, or was offline, or something else went wrong - it may not get the message.

🔄 Reposts / Announce / Quote

You cannot boost other posts, or even your own. Nor can you send quote posts.

🤖 Act On Instructions

This is a basic bot. It contains no logic. If you send it a message asking it to take action, it will not. You will need to build something else to make it truly interactive.

📥 Receive Messages

In fact, other than the follow / unfollow stuff, the bot can't receive any messages from the Fediverse. It doesn't know when a post has been replied to, liked, or reposted.

😎 Set Post Visibility

Your posts are either public or a DM. There's no support for things like quiet followers.

📊 Create Polls

Everyone loves to vote on meaningless polls - but this is quite a hard problem for ActivityBot. It would need to keep track of votes, prevent double voting, and probably some other difficult stuff.

🗨️ Change Quote Post Visibility

As quote posts are still quite new to Mastodon, I'm not sure how best to implement this.

🔗 Proper HTML / Markdown Support

Autolinking names, hashtags, and links just about works - but not very reliably. In theory the bot could parse Markdown and create richly formatted HTML from it. But that may require an external library which would bloat the size. Perhaps posting raw HTML could work?

🖼️ Focus Points for Images

Perhaps of less use now, but still of interest to people?

❓ Other Stuff

I don't know what I don't know. Maybe some stuff is total broken? Maybe it is wildly out of spec? If you spot something dodgy, please let me know or raise a Pull Request.