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.

There are a wide range of social media logins provided by Auth0 - including the usual suspects like Facebook, Twitter, WordPress, Discord, etc. Sadly, there's no support for Mastodon⁰.

All is not lost though. The Auth0 documentation says:

However, you can use Auth0’s Connections API to add any OAuth2 Authorization Server as an identity provider.

You can manually add a single Mastodon instance, but that doesn't work with the decentralised nature of the Fediverse. Instead, I've come up with a manual solution which works with any Mastodon server!

Background

Every Mastodon¹ server is independent. I have an account on mastodon.social you have an account on whatever.chaos. They are separate servers, albeit running similar software. A generic authenticator needs to work with all these servers. There's no point only allowing log ins from a single server.

Fortuitously, Mastodon allows app developers to automatically create new apps. A few simple lines of code and you will have an API key suitable for read-only access to that server. You can read how to instantly create Mastodon API keys or you can steal my PHP code.

User Experience

The user clicks the sign-in button on OpenBenches. They're taken to the Auth0 social login screen:

The user clicks on Mastodon. This is where Auth0's involvement ends!

The user is asked to provide the URl of their instance:

In the background, my server contacts the Mastodon instance and creates a read-only API key.

The user is asked to sign in to Mastodon.

The user is asked to authorise read-only access.

The user is now signed in and OpenBenches can retrieve their name, avatar image, and other useful information. Hurrah!

Auth0

Once you have created a service to generate API keys, it will need to run on a publicly accessible web server. For example https://example.com/mastodon_login.

Here's what you need to do within your Auth0 tennant:

• Authentication → Social → Create Connection
• At the bottom, choose "Create Custom".
• Choose "Authentication" only.
• Give your connection a name. This will be visible to users.
• "Authorization URL" and "Token URL" have the same value - the URl of your service.
• "Client ID" is only visible to you.
• "Client Secret" any random password; it won't be used for anything.
• Leave everything else in the default state.

It should look something like this:

Click the "Create" button and you're (almost) done.

Auth0 Icon

You will need to add a custom icon to the social integration. Annoyingly, there's no way to do it through the web interface, so follow that guide to use the command line.

Done!

I'll admit, this isn't the most straightforward thing to implement. Auth0 could make this easier - but it would still rely on users knowing the URl of their home instance.

That said, the Mastodon API is a delight to work with and the read-only permissions reduce risk for all parties.

What if, we said, you could tip a journalist directly on social media? Or reward your favourite creator without leaving the platform? Or just say thanks by buying someone a pint?

Here's a trivial mock-up:

Of course, this hides a ton of complexity. Does it show your local currency symbol? Does the platform take a cut or does it just pass you to the poster's preferred platform? Do users want to be able to tip as well as / instead of reposting and favouriting?

But I think the real problem is the perverse incentives it creates. We already know that relentless A|B testing of monetisation strategies leads to homogeneity and outrage farming. Every YouTuber has the same style of promotional thumbnail. Rage-baiters on Twitter know what drives the algorithm and pump out unending slurry.

Even if we ignore those who want to burn the world, content stealers like @CUTE_PUPP1E5 grab all the content they can and rip-off original creators. At the moment that's merely annoying, but monetisation means a strong incentive to steal content.

When people inevitably get scammed, would that damage the social media platform? Would promoting a payment link lead to liability? Now that money is involved, does that make hacking more attractive?

And yet… Accounts add payment links to their profiles all the time. Lots of accounts regularly ask for donor and sponsors. GitHub sponsors exist and I don't see evidence of people impersonating big projects and snaffling funds.

It is somewhat common for platforms to pay for publishers to be on their site. If you're starting up a new service then you need to give people an incentive to be there. That might be as a payer or receiver.

Personally, I'd love a frictionless way to throw a quid to a helpful blog post, or effortlessly donate to a poster who has made me laugh. Selfishly, I'd like it if people paid me for my Open Source or (micro)blogging.

I don't know whether Mastodon or BlueSky will ever have a payments button - and I have no influence on their decision-making process - but I'd sure like to see them experiement.

You can read more discussion on Mastodon.

Or, feel free to send me a tip!

• Buy me a gift from my Amazon wishlist
• Sponsor me on GitHub
• Send me money via PayPal
• Support me on Ko-Fi
• Become a Patreon
• Join my Open Collective
• Donate using LiberaPay
• Pay with Wise

Me? I prefer to look at how many people visit my blog from each site. It is an imperfect measure - and a vain one - but lets me know where I should be spending my time. No point posting on a network which is just bots talking to each other, right?

Earlier this year I built a stats-counter for my blog. Every time someone clicks from a website which links to my blog, it records that visit in a database. I get to see which blog posts are doing numbers, and where those numbers came from.

Until fairly recently, the Mastodon social network didn't send referer details. I thought that reduced the visibility of the network and lobbied for it to change. As various Mastodon servers upgrade, and admins opt-in, it is becoming more apparent just how much traffic originates from the Fediverse.

Over the last few weeks, here's how many people have clicked from BlueSky and Mastodon to one of my blog posts.

Total	Source
1,607	bsky.app
752	mastodon.social

At first glance, it doesn't look good for our elephantine friends, does it? The butterfly sends over twice the traffic. Game over!

But, of course, while Mastodon.social is the biggest instance - it is far from the only one. What happens if we slide down the long tail? Here's all the Mastodon-ish instances which sent me over 10 clicks.

Total	Source
193	phanpy.social
120	android-app://org.joinmastodon.android/
106	infosec.exchange
62	mas.to
59	mstdn.social
55	social.vivaldi.net
49	wandering.shop
48	fosstodon.org
33	mathstodon.xyz
27	mastodon.online
26	mastodon.scot
24	app.wafrn.net
19	indieweb.social
18	social.lol
17	tech.lgbt
17	toot.wales
16	en.osm.town
16	feditrends.com
14	mstdn.ca
14	piefed.social
12	wetdry.world
11	c.im
11	mastodon.nl
51	Sites sending < 10 clicks

Ah! Add them all up and you get a grand total of 1,773 visitors from Mastodon-powered sites. That's more than BlueSky.

Now, there are some obvious caveats to the data:

• I have a smaller follower count on BlueSky than I do on Mastodon.
• My posts may appeal more to one demographic than another.
• People may have strict privacy controls which suppress the true volume of visitors.
• There's no way to measure how long someone spends reading my posts.
• RSS and newsletter visitors aren't counted.
• Clicks from apps may not always show a referer.
• Some people may be on multiple services.
• Fediverse users can follow the post directly, so don't need to visit the site to read it.

And yet… no matter how you slice it, Fediverse servers are sending as much traffic as BlueSky!

I think this is brilliant. Web services should be able to scale from small to big - and each ActivityPub-powered site helps power the open Internet.

Just for completeness, this is how Reddit, Facebook, LinkedIn, Twitter, and Lemmy do over the same period:

Total	Source
1,158	reddit.com
585	android-app://com.reddit.frontpage/
76	facebook.com
76	https://old.reddit.com/r/programming/
56	https://www.reddit.com/r/programming/
52	youtube.com
41	t.co
38	https://old.reddit.com/r/todayilearned/comments/1nsw7f4/til_in_mongolia_instead_of_a_street_address_a/
31	linkedin.com
27	android-app://io.syncapps.lemmy_sync/
27	https://www.reddit.com/r/todayilearned/comments/1nsw7f4/til_in_mongolia_instead_of_a_street_address_a/
22	https://old.reddit.com/r/programming/comments/1n96ftn/40_years_later_are_bentleys_programming_pearls/
22	lemmy.ca
17	android-app://com.linkedin.android/
16	lemmy.dbzer0.com
14	feddit.org
11	https://www.reddit.com/r/programming/comments/1n96ftn/40_years_later_are_bentleys_programming_pearls/
10	discuss.tchncs.de
10	l.instagram.com
8	lemmy.blahaj.zone
6	https://www.reddit.com/r/GrapheneOS/comments/1m2l84b/considering_making_the_switch_does_google_pay/
6	reddthat.com

If you add up all the Lemmy instances, they send about as much traffic as Facebook and LinkedIn combined. That's not a huge surprise - those platforms hate anyone clicking away to the wider web.

Twitter is basically the Dead Internet. I'm no longer on there, but I do occasionally search it to see who is sharing my posts. The popular posts I write get shared a lot - sometimes by accounts with huge followers - yet there are no comments or retweets and barely and clicks.

I don't do Instagram or Threads, and that might be reflected in their low numbers. But I'm not active on YouTube either - yet people there occasionally link back to me.

Final Thoughts

Firstly, my stats only represent my site. Your site might be very different.

Secondly, I've ignored search engine traffic, big blogs, newsletters, and other sources.

Thirdly, and most importantly, this isn't a competition! The desire for a "winner-takes-all" service is dangerous and disturbing. An ecosystem is at its most vibrant when there are multiple participants each thriving in their own niche.

I want a thousand sites, running a hundred different software stacks, some of which only serve a dozen people, or even a lone participant.

Diversity is strength.

If you've ever visited a foreign country's national history museum, I guarantee you've read this little snippet:

King Whatshisface was a wise and noble ruler who bought peace and prosperity to all the land.

Upon his death, his heirs waged bloody war over rightful succession which plunged the country into a hundred years of hardship.

The great selling point of democracy is that it allows for the peaceful transition of power. Most modern democracies have rendered civil war almost unthinkable. Sure, you might not like the guy currently in charge, but there are well established mechanisms to limit their power and kick them out if they misbehave. If they die in office, there's an obvious and understood hierarchy for who follows them.

Most Open Source projects start small - just someone in their spare room tinkering for fun. Unexpectedly, they grow into a behemoth which now powers half the world. These mini-empires are fragile. The most popular method of governance is the Benevolent Dictator For Life model. The founder of the project controls everything. But, as I've said before, BDFL only works if the D is genuinely B. Otherwise the FL becomes FML.

The last year has seen several BDFLs act like Mad Kings. They become tyrannical despots, lashing out at their own volunteers. They execute takeovers of community projects. They demand fealty and tithes. Like dragons, they become quick to anger when their brittle egos are tested. Spineless courtiers carry out deluded orders while pilfering the coffers.

Which is why I am delighted that the Mastodon project has shown a better way to behave.

In "The Future is Ours to Build - Together" they describe perfectly how to gracefully and peacefully transfer power. There are no VCs bringing in their MBA-brained lackeys to extract maximum value while leaving a rotting husk. No one is seizing community assets and jealously hoarding them. Opaque financial structures and convoluted agreements are prominent in their absence.

Eugen Rochko, the outgoing CEO, has a remarkably honest blog post about the transition. I wouldn't wish success on my worst enemy. He talks plainly about the reality of dealing with the pressure and how he might have been a limiting factor on Mastodon's growth. That's a far step removed from the ego-centric members of The Cult of The Founder with their passionate belief in the Divine Right of Kings.

Does your tiny OSS script need a succession plan? Probably not. Do you have several thousand NPM installs per day? It might be worth working out who you can share responsibility with if you are unexpectedly raptured. Do you think that your project is going to last for a thousand years? Build an organisation which won't crumble the moment its founder is arrested for their predatory behaviour on tropical islands.

I'm begging project leaders everywhere - please read up on the social contract and the consent of the governed. Or, if reading is too woke, just behave like grown-ups rather than squabbling tweenagers.

It is a sad inevitability that, eventually, we will all be nothing but memories. The bugs that we create live after us, the patches are oft interrèd with our code. Let it be so with all Open Source projects.

A user writes a status. The user can choose to make their statuses quotable or not. What happens when a quoter quotes that post?

I've read through the specification and tried to simplify it. Quoting is a multi-step process:

1. The status must opt-in to being shared.
2. The quoter quotes the status.
3. The quoter's server sends a request to the status's server.
4. The status's server sends an accept message back to the quoter's server.
5. When other servers see the quote, they check with the status's server to see if it is allowed.

I'm going to walk you through each stage as best as I understand them.

Opting In

An ActivityPub status message is JSON. In order to opt-in, it needs this additional field.

"interactionPolicy": {
  "canQuote": {
    "automaticApproval": "https://www.w3.org/ns/activitystreams#Public"
  }
}

That tells ActivityPub clients that anyone is allowed to quote this post. It is also possible to say that only specific users, or only followers, or no-one is allowed.

The QuoteRequest

Someone has hit the quote post button, typed their own message, and shared their wisdom. Their server sends the following message to the server which hosts the quoted status. This has been edited for brevity.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "QuoteRequest":   "https://w3id.org/fep/044f#QuoteRequest"
    }
  ],
  "type": "QuoteRequest",
  "id":     "https://mastodon.test/users/Edent/quote_requests/1234-5678-9101",
  "actor":  "https://mastodon.test/users/Edent",
  "object": "https://example.com/posts/987654321.json",
  "instrument": {
    "id":           "https://mastodon.test/users/Edent/statuses/123456789",
    "url":          "https://mastodon.test/@Edent/123456789",
    "attributedTo": "https://mastodon.test/users/Edent",
    "quote":          "https://example.com/posts/987654321.json",
    "_misskey_quote": "https://example.com/posts/987654321.json",
    "quoteUri":       "https://example.com/posts/987654321.json"
  }
}

All this says is "I would like permission to quote you."

The Stamp

The quoted server needs to approve this quote. First, it generates a "stamp".

This is a file which lives on the quoted server. It is proof that the quote is allowed. If it is deleted, the quote permission is revoked. When the stamp's ID is requested the stamp must be returned.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "gts": "https://gotosocial.org/ns#",
      "QuoteAuthorization": {
        "@id": "https://w3id.org/fep/044f#QuoteAuthorization",
        "@type": "@id"
      },
      "interactingObject": {
        "@id": "gts:interactingObject"
      },
      "interactionTarget": {
        "@id": "gts:interactionTarget"
      }
    }
  ],
  "type": "QuoteAuthorization",
  "id":                "https://example.com/quote-987654321.json",
  "attributedTo":      "https://example.com/users/username",
  "interactionTarget": "https://example.com/posts/987654321.json",
  "interactingObject": "https://mastodon.test/users/Edent/statuses/123456789"
}

If the quoted status is viewed from a different server, that server will query the stamp to make sure the share is allowed.

The Accept

This is the message that the quoted server sends to the quoting server. It references the request and the stamp.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "QuoteRequest": "https://w3id.org/fep/044f#QuoteRequest"
    }
  ],
  "type": "Accept",
  "to":    "https://mastodon.test/users/Edent",
  "id":    "https://example.com/posts/987654321.json",
  "actor": "https://example.com/account",
  "object": {
    "type": "QuoteRequest",
    "id":         "https://mastodon.test/users/Edent/quote_requests/1234-5678-9101",
    "actor":      "https://mastodon.test/users/Edent",
    "instrument": "https://mastodon.test/users/Edent/statuses/123456789",
    "object":     "https://example.com/posts/987654321.json"
  },
  "result": "https://example.com/quote-987654321.json"
}

The "result" must be the same as the stamp's URl.

And then?

You can follow and quote @colours@colours.bots.edent.tel on your favourite Fediverse platform.

I've written an ActivityPub server in a single file which is designed to teach you have the protocol works. Have a play with ActivityBot.

@Edent@mastodon.social

Terence Eden

Mastodon enforces a "noreferrer" on all external links.

I have mixed feelings about that.

As a blogger, I want to see *where* visitors are coming from. I also like to see (and sometimes join in) with the conversations they're having.

But, I get that people want privacy and don't want to "leak" where they're visiting from.

Is it such a bad thing to tell a website "I was referred from this specific server"?

---

When you click on this link - https://www.bbc.co.uk/news - your browser says "Hey! BBC! Please can I have your /news page? BTW, I was referred here by shkspr.mobi. THANKS!" This is called the "Referer" and, yes, it is mispelt.

One the one hand, sending the referer is good; it lets the linked-to server know who is linking to it. That allows them to see where traffic is coming from. On the other hand, this could be bad for much the same reason.

If you run a server anarcho_terrorists.biz, you probably don't want the FBI knowing that your members are sharing links to their pages. If you run a small personal server, you may not want anyone knowing that you personally linked to them. If you run a server for a marginalised community, you may not want a hate-site to know your members are linking to you.

But if you're a large-ish, general purpose, non-private site - like Mastodon.social - where's the harm in allowing referer headers?

Anyway, for historic reasons, Mastodon blocked the referer header. This, I believe, was sensible for smaller servers but a miss-step for larger servers. As I pointed out last week:

@Edent@mastodon.social

Terence Eden

Two years later.

Want to know one of the major reasons Mastodon didn't catch on with journalists and large website owners?

It is *invisible* in referrer statistics.

Here's my blog from the last month.

BlueSky now sends me more traffic than Bing.

How much traffic does Mastodon send? It is impossible to know due to the "noreferrer" header in all links.

(I'm not saying your privacy isn't important. But you can't grow a community if no-one knows you exist.)

---

I'm not the only one to make this point - it has been a popular complaint for some time.

A few days ago, Mastodon changed to allow this to be configurable.

This is excellent news. Website owners will be able to (somewhat) accurately see how much traffic Mastodon sends them. That way they can determine if there is a suitably large audience to engage with on the Fediverse.

It is, of course, slightly more complicated than that!

• Instance owners can opt-in to allowing Referer headers (it is off by default).
• The policy means that only the domain name is sent; not the full page.
• Mastodon is federated and there are thousands of sites. Even if they all opted-in, their statistics will be fragmented.
• Apps can set their own Referer header - leading to more fragmentation.
• Even if they do opt-in, users can set their browsers not to send Referer headers.

Nevertheless, I'm delighted with this change. Hopefully it will allow the Fediverse to grow and attract more users.

Fifteen years ago (fuck, I'm old) I started documenting what Twitter's nascent hashtags could and couldn't do.

Back in 2010, this is how the official Twitter site linked hashtags.

Notably, punctuation symbols didn't "count" as part of a tag.

How does modern social media handle something like #Fish&Chips?

• Mastodon links directly to #Fish&Chips
• BlueSky links directly to #Fish&Chips
• Threads links to a search for Fish & Chips

What about normalisation?

Should #Romeo link to #ROMEO and #rOMeO?

On all three of the major social networks, case is insensitive.

But what about the vagueries of Unicode normalisation?

Is #Ŕöméø&Jülíèt the same as #Romeo&Juliet?

Both Threads and Mastodon do some form of decomposition - turning the various accents into their accentless versions.

But BlueSky links to the literal version.

Is that the right thing to do? I don't know.

This literal interpretation of the text in hashtags allows for some interesting steganography - which can be fun, but I wonder if it is what users expect?

And that's what it comes down to. What is technically correct isn't always the same as what users need.

Perhaps most users prefer #ROMEO to link to the same posts as #romeo. Perhaps they think #Romeó should link there too. But no social network, as far as I am aware, has done any user research into the behaviour that users want when interacting with hashtags.

I'd love someone to do some actual research on how people expect a folksonomy to work.

What does that mean?

• You tell the service what your website is.
• The service gives you a secret code¹.
• You upload that secret code onto your website.
• The service checks the secret code is on the website.
• If it is, the service says your domain is verified.

On Mastodon, that gives you a green tick next to your link. On BlueSky, it gives you the ability to change your username to your website's name.

This is reasonably strong proof that you are the owner of that website. I don't have the ability to add the secret file I've been given to bbc.co.uk, so I cannot impersonate them.

But it isn't all sunshine and roses. There are some important issues with this process.

Revocation and Revalidation

Let's say an employee has validated alice.big_company.com - what happens when Alice leaves²?

Well, you just delete the secret code from your website, right?

In theory yes. But in practice, no.

From BlueSky:

We're working on adding the ability to revalidate these handles periodically.

And Mastodon:

Verified links are currently verified at each time the profile is updated, but they will only be verified once, when initially entered.

So, at the moment, there is a risk that revalidation isn't completed and revocation never happens³. Accounts which were once trusted may stay trusted, even when they're no longer trustworthy.

Copy Cat Domains

You're chatting with your credit card company's social media account. You see that they've verified the domain.

Wait?! Are they really mastercrrd.info ✅?

There are several practical attacks against humans trying to validate a domain name. A simple misspelling is easy to overlook. There are thousands of top level domains, and you may not be sure if your bank uses .com, .uk, .tech, or something else. It only costs a few quid for an attacker to buy a domain which contains a politician's name.

International domain names mean that homograph attacks are possible.

Humans aren't very clever

Recently, several prominent journalists on BlueSky embarrassed themselves by pronouncing fake accounts to be real. The journalists - with all their resources and contacts - didn't bother to actually verify if the person who registered @KemiBadenoch was really the Leader of the Opposition.

They could have checked her website to see if it linked to the new account. They could have rung up the Tory press office. They could have checked to see if she have verified her account. Or they could have done a dozen other things to verify the facts before posting. They didn't.

These aren't random users blindly reposting. These are highly educated, thoroughly trained fact-finders. Their mission is accuracy and their livelihood depends on being able to report the truth. And yet they just assumed that no one would lie on the Internet.

Would a journalist be able to spot that tailer-swift.fartotron.xyz was an impersonator? I highly doubt it⁴.

Hacks Happen

Even when Twitter was validating celebrities correctly, it didn't stop the accounts getting hacked.

An attacker might compromise your social media account or your domain name registrar.

Just because an account and domain appear verified, it doesn't mean they're legitimate. Is that politician you follow really posting about dietary supplements?

It might be too difficult for large organisation

I've written An Easy Guide To BlueSky Verification. It can be as simple as uploading a single file to your website. Although I have some sympathy for claims that managing the process for hundreds of employees might be difficult.

Based on my calculations around 5% of active BlueSky users have verified their domain.

The alternative isn't much better

Verification is hard. Can an over-worked verification team spot that I've photoshopped a passport so that it looks like someone else's?

There are hundred of famous people called John Williams - which one do you verify?

Also, what are you verifying? In my post on Rethinking Twitter Verification, I pointed out that the ambiguity of verification leads to some weird and non-obvious outcomes.

Final thoughts

There are no simple technological fixes to complex social issues.

But I'm naïve enough to believe that, with time, we can train people to be better at assessing the information they are given.

0. Create an account on the Fediverse using a domain you control
   • For example @user@bots.example.com
1. Follow the Fediverse-ATProto bridge @bsky.brid.gy@bsky.brid.gy
   • Your account will need to be over 2 weeks old and have a name, profile picture, etc.
2. You now have an account on BSky! Its name will be something like user.bots.example.com.ap.brid.gy
3. Get the DID of your account
   • https://public.api.bsky.app/xrpc/app.bsky.actor.getProfile?actor=user.bots.example.com.ap.brid.gy
   • Or https://fed.brid.gy/ap/@user@bots.example.com
4. Add the DID to your domain
   • I think the easiest way is sticking it in a plain text file at bots.example.com/.well-known/atproto-did
5. Use the BSky Debugger to make sure it was successful.
6. Send a Direct Message from the Fediverse to @bsky.brid.gy@bsky.brid.gy. The message must only contain username bots.example.com.
   • That's literally the word username. It isn't your account's username.
7. Wait a few moments.
8. Your bot will now be on BSky as https://bsky.app/profile/bots.example.com!

You can see that https://bot.viii.fi/bot is also available at https://bsky.app/profile/bot.viii.fi

Way back in the mists of time, we dealt with trolls on Usenet with the almighty PLONK - PLaced On Newsgroup Killfile. It meant your newsreader never downloaded their posts. They could rant at you all day long, and you'd never hear from them. It's what we would nowadays call "Mute".

But, whether you're on Usenet or a modern social network, muting someone doesn't actually stop them replying to you. The miscreant can still see your posts, interact with them, quote them. And everyone on that service can see their abuse. Perhaps they will also join in?

Most modern social networks now have the concept of "Block". When Alice blocks Bob, it means Bob cannot see Alice's posts. The service doesn't deliver her content to him. If he goes looking, he can't find it. She is invisible to him.

Except, of course, that's a lie. If Bob logs out of his account, he can see Alice's public content. If he logs into an alternative account, he isn't blocked.

The block is a social signal backed up with mild technical restrictions.

What do I mean by that? Ordinarily, you will have no idea that you have been blocked by someone. They will simply vanish from your screens. You do not receive an alert that you've been blocked. Technical restrictions mean you won't see their posts, nor replies to them. The only way you might know is if you deliberately look for the person blocking you.

Seeing that you have been blocked is a "social signal". It lets you know that your behaviour was unwanted, or that your contributions weren't valued, or that someone just doesn't like you. For most people, that sort of chastisement probably induces a little shame or grief. For others, it is enraging.

Again, it isn't impossible for a blocked user to see content - but technical restrictions means it takes effort. And, it turns out, for all but the most obsessive abusers - a mild bit of UI friction is all that it takes for them to stop.

On a centralised social media platform, like Twitter and Facebook, your blocks are private. The only people who know you have blocked Taylor Swift are you, the platform, and T-Swizzle herself.

On decentralised social media platforms, it is more complicated.

Mastodon / ActivityPub lets you block a user. In doing so, you have to tell that user's server that you don't want them seeing your messages. That means your server knows about the block, their server know, and the user knows. But, crucially, there's nothing to stop a malicious server ignoring your wishes. While your server can mute all the interactions from them, there are only weak technological restrictions on their behaviour.

BlueSky / AT Protocol takes a different (and more worrying) approach. BlueSky tells everyone about your blocks. If Alice blocks Bob - the system lets everyone know. This means that if Bob starts replying to your posts, other clients will know to ignore his interactions with you. I've written more about the dangers of public blocklists over on BSky.

But, crucially, none of these systems actually block users. This isn't like that Black Mirror episode where people are literally blurred out from your eyeballs.

In all cases, a user can log out and see your public posts. They can sign in with an alternative account. And, in the case of decentralised social media, they can choose to ignore the technological restrictions you impose.

Social networks have a responsibility to keep their users safe. That means having enough friction to prevent casual abuse.

But blocking is only a social signal. That's all it ever has been. It is a boop on the nose with a rolled up newspaper. It is a message to tell someone that they might want to adjust their attitude.

You should block - and block often. You should feel empowered to curate an environment that is safe for you. But you should also understand the limitations of the technical controls which underpin these social signals.

Terence Eden is on Mastodon

@edent

If the recent Twitter hack had exposed they way you voted on every Twitter poll, how would you feel?

(There is no suggestion that this has happened, I'm just curious about people's relationships to voting and privacy.)

---

Meh. So what?: (167)
167
Hmph. That's annoying.: (68)
68
Umm… This could be bad!: (32)
32
Delete account & run away: (8)
8

---

Most of the tech world that I interact with has moved to Mastodon and other ActivityPub-based social networks. Decentralised social media is great. It allows you to be fully in control of what you post, what you see, and how you interact with others.

Of course, there are downsides. No centralised authorities means verification is difficult. Abuse (of all sorts) can only be dealt with in a piecemeal fashion. And anonymity takes a bit of a nosedive.

When you block or mute someone, that information might leak to the offending user. By its nature, you need to send a message to someone else's server in order to interact with them.

So what about polls on the Fediverse? This poll, for example, is gathering sensitive personal information.

@farooqkz@blackrock.city

Farooq Karimi Zadeh

Let's see how many Muslims are out there on Fediverse. Are you a #muslim?

#Islam #Religion #God

Please boost it so we can have more accurate statistics.

---

I am a Muslim: (62)
62
Not a Muslim: (3,696)
3696

---

In order to vote on the poll, your server sends a message to the poll's server saying "I am user @someone@example.com. I wish to vote for option X. Here is an HTTP signature confirming my message."

Does the receiving server abide by GDPR? Who knows!

The specification around questions is a little ill-defined and the Mastodon documentation is also a bit vague. Neither of them discuss privacy.

There is an excellent blog post by Humberto Rocha looking at Mastodon Poll in ActivityPub. It shows quite clearly that a vote is just a normal message which is passed onto the receiving server.

Services like Mastodon won't let the poll's author see who voted for which option. But that's by convention. There's nothing technical to stop them. Indeed, I understand that the Akkoma social network does show users how users voted.

Of course, on a centralised service like Facebook or Twitter your vote is still recorded somewhere. It can be subpoenaed or looked at by unscrupulous engineers.

Privacy is, of course, a social construct. In some communities it might be sensible to have all votes on the public record. In others, it could be deadly. Some countries have laws mandating strong privacy protections, others less so.

Conduct yourself with that in mind!

One day we were summoned into a large conference room. Our CEO was on the speakerphone (I told you this was a long time ago) with an important update on our financial situation.

I think every arsehole in the room puckered. Were we about to be made redundant? No! Far from it. The business had just taken on a massive amount of investment from a prominent Venture Capital fund. The champagne flowed! With this money we could turbo-charge our hiring, build new products, and accelerate our growth.

At least, that's what I thought. In my naïveté, I congratulated our head of sales on the growth of his empire. More money meant more sales staff, yes?

He was glum. "That's not how it works," he explained.

Our large institutional investors had a vast stable of other companies. Each covered a different bit of the tech ecosystem and our advertising business was about to become part of an incestuous web. Every app that the VCs had invested in would now be "encouraged" to use our advertising solution. You don't need a sales team when your customers are your cousins in an arranged marriage.

Similarly, our approved corporate chat tool would be replaced by one from another stable-mate. Who, in turn, would buy advertising from us.

Over the next few months our growth rocketed and almost none of it was organic.

Eventually I left for pastures marginally more ethical than advertising. But I continue to see the same pattern repeat itself.

When you wonder why one social network grows and another doesn't - look at the investors.

For example, I'm sure a lot of Twitter's early growth was organic. But once rich and powerful companies can direct their investments to sign up and route all their customer service / product announcements through there, it exploded. When you have a financial investment at stake, finding ways to boost growth is a priority - and a little mutually reinforced reciprocation goes a long way.

I don't know if Mastodon (and other ActivityPub services) have reached their maximum organic growth. I suspect they have. To be clear, I'm not calling on Mastodon to take on a billion dollars of VC funding. But without sales teams and without a bunch of associated organisations forced to use it, I worry that the Fediverse will hit a natural limit.

And, again, I don't know if that's a bad thing per se - but if you're expecting big companies, governments, and your favourite VC-adjacent celebrities to join, you're likely to be disappointed.

The BlueSky social network has introduced "Reply Gating" - it looks like this:

You can write your hot take on Taylor Swift and not be inundated by weirdos replying to you. Nifty!

This is nothing new. Twitter has it. Facebook has the concept of "audiences" to restrict who your post is visible to.

And, of course, blogging has this! There is a comment form at the bottom of this page - and I moderate it. If you post something stupid, I don't have to subject my audience to your inanities. I can (and do) block users from commenting.

ActivityPub doesn't have this (yet). It's much more like a public mailing list. I can block or mute you - which stops me from seeing your abuse - but doesn't stop anyone else from seeing it.

Should ActivityPub have something similar? Yeah, I reckon so. I'd like to be able to say "Anyone I know want to go to the pub tonight" and only have mutuals reply. I want to prune away spam or repetitive replies. It would be helpful to have a conversation in public that other people can't interrupt.

The UI would be complex. And the social model needs a bit of work. And there are some technical challenges around syndicating which replies should be included.

But, ultimately, social media should respond to the needs of its users.

Messages in ActivityPub have two distinct ID strings. Here's a (truncated) view of what happens when I send a new message on Mastodon:

  "id": "https://mastodon.social/users/Edent/statuses/1234567890/activity",
  "type": "Create",
  "actor": "https://mastodon.social/users/Edent",
  "published": "2024-03-10T16:13:49Z",
  "object": {
    "id": "https://mastodon.social/users/Edent/statuses/1234567890",
    "type": "Note",
    "content": "Hello"
...

The "Note" has some human-readable content, some metadata, and an ID - in this case a URl ending with 1234567890

But that Note is wrapped in an Activity. In this case, it is a "Create" message, with some metadata, and it's own ID - in this case ending 1234567890/activity

What happens if I edit the post? Here's a truncated view of what the server sends:

  "id": "https://mastodon.social/users/Edent/statuses/1234567890#updates/1710087334",
  "type": "Update",
  "actor": "https://mastodon.social/users/Edent",
  "published": "2024-03-10T16:15:34Z",
  "object": {
    "id": "https://mastodon.social/users/Edent/statuses/1234567890",
    "type": "Note",
    "content": "I meant Goodbye!"
...

The "Note" has the same ID as before - but the activity has a different ID.

Further updates follow the same pattern:

  "id": "https://mastodon.social/users/Edent/statuses/1234567890#updates/1984651324",
  "type": "Update",
  "object": {
    "id": "https://mastodon.social/users/Edent/statuses/1234567890",
...

So what happens when I Delete a previously updated post?

Here's what's sent:

  "id": "https://mastodon.social/users/Edent/statuses/1234567890#delete",
  "type": "Delete",
  "actor": "https://mastodon.social/users/Edent",
  "object": {
    "id": "https://mastodon.social/users/Edent/statuses/1234567890",
    "type": "Tombstone",
...

Again, the Activity has its own, unique, ID. But it is the original ID of the Note which is to be deleted!

The spec says that all IDs must be URls - but it doesn't say what format they should be in. Mastodon helpfully makes the Activity's ID somewhat related to the object's ID - but not all software will do that.

So, if you're doing something like saving messages to disk or a database, use the object ID as the canonical reference. The ID of the Activity isn't particularly important when it comes to receiving updates, deletes, replies, or anything else.

This is a quick example to show how to verify these signatures using PHP. I don't claim that it covers every use-case, and it is no-doubt missing some weird edge cases. But it successfully verifies messages sent by multiple Fediverse servers.

Let's step through it with an example of a message sent from Mastodon to my server.

Headers

The HTTP request starts with these headers:

User-Agent:  http.rb/5.1.1 (Mastodon/4.3.0-nightly.2024-02-23; +https://mastodon.social/)
Host:  example.com
Date:  Sun, 25 Feb 2024 10:48:22 GMT
Accept-Encoding:  gzip
Digest:  SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=
Content-Type:  application/activity+json
Signature:  keyId="https://mastodon.social/users/Edent#main-key",algorithm="rsa-sha256",headers="(request-target) host date digest content-type",signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="
Connection:  Keep-Alive
Content-Length:  2857

Some of those you may be familiar with, some not. The first thing we'll do is a sanity check; was this message sent recently? Because clocks drift in and out of synchronisation, we'll check if the message was within ±30 seconds.

$headers = getallheaders();
if ( !isset( $headers["Date"] ) ) { return null; }  //  No date set
$dateHeader = $headers["Date"];
$headerDatetime  = DateTime::createFromFormat('D, d M Y H:i:s T', $dateHeader);
$currentDatetime = new DateTime();

// Calculate the time difference in seconds
$timeDifference = abs( $currentDatetime->getTimestamp() - $headerDatetime->getTimestamp() );
return ( $timeDifference < 30 );

That was easy! On to the next bit.

Digest

A message posted to the server usually has a body. In this case it is a long string of JSON data. To ensure the message hasn't been altered in transit, one of the headers is:

Digest:  SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=

That says, if you do a SHA-256 hash of the JSON you received, and convert that hash to Base64, it should match the digest in the header.

$digestString = $headers["Digest"];
//  Usually in the form `SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=`
//  The Base64 encoding may have multiple `=` at the end. So split this at the first `=`
$digestData = explode( "=", $digestString, 2 );
$digestAlgorithm = $digestData[0];
$digestHash = $digestData[1];

//  There might be many different hashing algorithms
//  TODO: Find a way to transform these automatically
if ( "SHA-256" == $digestAlgorithm ) {
    $digestAlgorithm = "sha256";
} else if ( "SHA-512" == $digestAlgorithm ) {
    $digestAlgorithm = "sha512";
}

$json = file_get_contents( "php://input" );

//  Manually calculate the digest based on the data sent
$digestCalculated = base64_encode( hash( $digestAlgorithm, $json, true ) );

return ( $digestCalculated == $digestHash );

But, of course, if someone has manipulated the JSON, they may also have manipulated the digest. So it is time to look at the signature.

The Signature

Let's take a look at the signature header:

Signature:
  keyId="https://mastodon.social/users/Edent#main-key",
  algorithm="rsa-sha256",
  headers="(request-target) host date digest content-type",
  signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="

This contains 4 pieces of information.

1. keyID - a link to the user's public key.
2. algorithm - the algorithm used by this signature.
3. headers - the headers which make up the string to be signed.
4. signature - the signature string.

Let's split them up so they can be used:

//  Examine the signature
$signatureHeader = $headers["Signature"];

// Extract key information from the Signature header
$signatureParts = [];
//  Converts 'a=b,c=d e f' into ["a"=>"b", "c"=>"d e f"]
               // word="text"
preg_match_all('/(\w+)="([^"]+)"/', $signatureHeader, $matches);
foreach ($matches[1] as $index => $key) {
    $signatureParts[$key] = $matches[2][$index];
}

Let's tackle each part in order.

Get the user's public key

You might think you can just get https://mastodon.social/users/Edent#main-key - but you would be wrong.

Firstly, you need to tell the key server that you want the JSON representation of the URl - otherwise you'll end up with HTML.

$publicKeyURL = $signatureParts["keyId"];
$context   = stream_context_create(
    [ "http" => [ "header" => "Accept: application/activity+json" ] ] 
);
$userJSON  = file_get_contents( $publicKeyURL, false, $context );

That gets you the JSON representation of the user. On Mastodon, the key can be found at:

I don't know how to automatically find the key, so I've hard-coded its location.

$userData  = json_decode( $userJSON, true );
$publicKey = $userData["publicKey"]["publicKeyPem"];

Get the algorithm

This is rather straightforward. It's just the text in the signature header:

$algorithm = $signatureParts["algorithm"];

Reconstruct the signing header

Let's take a look at the third piece of the puzzle:

headers="(request-target) host date digest content-type"

This says "The signature is based on the following parts in order". So we only care about the headers which make up the request, the host, the date, the digest, and the content type. Other servers may require different parts of the headers.

Again, let's tackle them in order.

(request-target)

This means the method of the request and the target it was sent to. In our example, this is a POST sent to the path /inbox.

host

This is the HTTP host the message was sent to. This should be retrieved from the server, not taken from the sent headers.

date digest content-type

These are the values from the headers which were sent with the request.

Putting it all together

Annoyingly, the HTTP headers are written in Title-Case whereas the headers in the Signature are in lower-case. So some conversion is necessary:

//  Manually reconstruct the header string
$signatureHeaders = explode(" ", $signatureParts["headers"] );
$signatureString = "";
foreach ($signatureHeaders as $signatureHeader) {
    if ( "(request-target)" == $signatureHeader ) {
        $method = strtolower( $_SERVER["REQUEST_METHOD"] );
        $target = strtolower( $_SERVER["REQUEST_URI"] );
        $signatureString .= "(request-target): {$method} {$target}\n";
    } else if ( "host" == $signatureHeader ) {
        $host = strtolower( $_SERVER["HTTP_HOST"] );    
        $signatureString .= "host: {$host}\n";
    } else {
        //  In the HTTP header, the keys use Title Case
        $signatureString .= "{$signatureHeader}: " . $headers[ ucwords( $signatureHeader, "-" ) ] . "\n";
    }
}

//  Remove trailing newline
$signatureString = trim( $signatureString );

This results in a string like this:

(request-target): post /inbox
host: example.com
date: Sun, 25 Feb 2024 10:48:22 GMT
digest: SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=
content-type: application/activity+json

Get the signature

The signature that we are sent is in Base64.

signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="

It needs to be decoded before we can use it.

$signature = base64_decode( $signatureParts["signature"] );

Verify the signature

We're nearly there! Luckily, we don't have to do any crazy cryptography by hand. We use PHP's openssl_verify():

//  Finally! Calculate whether the signature is valid
$verified = openssl_verify(
    $signatureString, 
    $signature, 
    $publicKey, 
    $algorithm
);

That takes the reconstructed string based on the headers, the signature which was sent, the public key we retrieved, and the algorithm.

If it all matches, it will return true. If not... time for some debugging!

But what about...?

This is not a complete solution. My code almost certainly contains bugs, unforeseen edge-cases, memory leaks, black holes, and poisonous frogs. This is intended to step you through the practical process of verifying an HTTP Message Signature.

Then you should get a properly tested and validated library and use that instead.

I wanted to create the simplest possible Fediverse server which can be used as an educational tool to show how ActivityPub / Mastodon works.

The design goals were:

• Upload a single PHP file to the server.
• No databases or separate config files.
• Single Actor (i.e. not multi-user).
• Allow the Actor to be followed.
• Post plain-text messages to followers.
• Be roughly standards compliant.

And those goals have all been met! Check it out on GitLab. I warn you though, it is the nadir of bad coding. There are no tests, bugger-all security, scalability isn't considered, and it is a mess. But it works.

You can follow the test user @example@example.viii.fi

Architecture

Firstly, I've slightly cheated on my "single file" stipulation. There's an .htaccess file which turns example.com/whatever into example.com/index.php?path=whatever

The index.php file then takes that path and does stuff. It also contains all the configuration variables which is very bad practice.

Rather than using a database, it saves files to disk.

Again, this is not suitable for any real world use. This is an educational tool to help explain the basics of posting messages to the Fediverse. It requires absolutely no dependencies. You do not need to spin up a dockerised hypervisor to manage your node bundles and re-compile everything to WASM. Just FTP the file up to prod and you're done.

Walkthrough

This is a quick ramble through the code. It is reasonably well documented, I hope.

Preamble

This is where you set up your account's name and bio. You also need to provide a public/private keypair. The posting page is protected with a password that also needs to be set here.

    //  Set up the Actor's information
    $username = rawurlencode("example");    //  Encoded as it is often used as part of a URl
    $realName = "E. Xample. Jr.";
    $summary  = "Some text about the user.";
    $server   = $_SERVER["SERVER_NAME"];    //  Domain name this is hosted on

    //  Generate locally or from https://cryptotools.net/rsagen
    //  Newlines must be replaced with "\n"
    $key_private = "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----";
    $key_public  = "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----";

    //  Password for sending messages
    $password = "P4ssW0rd";

Logging

ActivityPub is a "chatty" protocol. This takes all the requests your server receives and saves them in /logs/ as a datestamped text file.

    // Get all headers and requests sent to this server
    $headers     = print_r( getallheaders(), true );
    $postData    = print_r( $_POST,    true );
    $getData     = print_r( $_GET,     true );
    $filesData   = print_r( $_FILES,   true );
    $body        = json_decode( file_get_contents( "php://input" ), true );
    $bodyData    = print_r( $body,    true );
    $requestData = print_r( $_REQUEST, true );
    $serverData  = print_r( $_SERVER,  true );

    //  Get the type of request - used in the log filename
    if ( isset( $body["type"] ) ) {
        $type = " " . $body["type"];
    } else {
        $type = "";
    }

    //  Create a timestamp in ISO 8601 format for the filename
    $timestamp = date( "c" );
    //  Filename for the log
    $filename  = "{$timestamp}{$type}.txt";

    //  Save headers and request data to the timestamped file in the logs directory
    if( ! is_dir( "logs" ) ) { mkdir( "logs"); }

    file_put_contents( "logs/{$filename}", 
        "Headers:     \n$headers    \n\n" .
        "Body Data:   \n$bodyData   \n\n" .
        "POST Data:   \n$postData   \n\n" .
        "GET Data:    \n$getData    \n\n" .
        "Files Data:  \n$filesData  \n\n" .
        "Request Data:\n$requestData\n\n" .
        "Server Data: \n$serverData \n\n"
    );

Routing

The .htaccess changes /whatever to /?path=whatever This runs the function of the path requested.

    !empty( $_GET["path"] )  ? $path = $_GET["path"] : die();
    switch ($path) {
        case ".well-known/webfinger":
            webfinger();
        case rawurldecode( $username ):
            username();
        case "following":
            following();
        case "followers":
            followers();
        case "inbox":
            inbox();
        case "write":
            write();
        case "send":
            send();
        default:
            die();
    }

WebFinger

The WebFinger Protocol is used to identify accounts. It is requested with example.com/.well-known/webfinger?resource=acct:username@example.com This server only has one user, so it ignores the query string and always returns the same details.

    function webfinger() {
        global $username, $server;

        $webfinger = array(
            "subject" => "acct:{$username}@{$server}",
              "links" => array(
                array(
                     "rel" => "self",
                    "type" => "application/activity+json",
                    "href" => "https://{$server}/{$username}"
                )
            )
        );
        header( "Content-Type: application/json" );
        echo json_encode( $webfinger );
        die();
    }

Username

Requesting example.com/username returns a JSON document with the user's information.

    function username() {
        global $username, $realName, $summary, $server, $key_public;

        $user = array(
            "@context" => [
                "https://www.w3.org/ns/activitystreams",
                "https://w3id.org/security/v1"
            ],
                                   "id" => "https://{$server}/{$username}",
                                 "type" => "Person",
                            "following" => "https://{$server}/following",
                            "followers" => "https://{$server}/followers",
                                "inbox" => "https://{$server}/inbox",
                    "preferredUsername" =>  rawurldecode($username),
                                 "name" => "{$realName}",
                              "summary" => "{$summary}",
                                  "url" => "https://{$server}",
            "manuallyApprovesFollowers" =>  true,
                         "discoverable" =>  true,
                            "published" => "2024-02-12T11:51:00Z",
            "icon" => [
                     "type" => "Image",
                "mediaType" => "image/png",
                      "url" => "https://{$server}/icon.png"
            ],
            "publicKey" => [
                "id"           => "https://{$server}/{$username}#main-key",
                "owner"        => "https://{$server}/{$username}",
                "publicKeyPem" => $key_public
            ]
        );
        header( "Content-Type: application/activity+json" );
        echo json_encode( $user );
        die();
    }

Following & Followers

These JSON documents show how many users are following / followers-of this account. The information here is self-attested. So you can lie and use any number you want.

function following() {
        global $server;

        $following = array(
              "@context" => "https://www.w3.org/ns/activitystreams",
                    "id" => "https://{$server}/following",
                  "type" => "Collection",
            "totalItems" => 0,
                 "items" => []
        );
        header( "Content-Type: application/activity+json" );
        echo json_encode( $following );
        die();
    }
    function followers() {
        global $server;
        $followers = array(
              "@context" => "https://www.w3.org/ns/activitystreams",
                    "id" => "https://{$server}/followers",
                  "type" => "Collection",
            "totalItems" => 0,
                 "items" => []
        );
        header( "Content-Type: application/activity+json" );
        echo json_encode( $followers );
        die();
    }

Inbox

The /inbox is the main server. It receives all requests. This server only responds to "Follow" requests. A remote server sends a follow request which is a JSON file saying who they are. This code does not cryptographically validate the headers of the received message. The name of the remote user's server is saved to a file so that future messages can be delivered to it. An accept request is cryptographically signed and POST'd back to the remote server.

    function inbox() {
        global $body, $server, $username, $key_private;

        //  Get the message and type
        $inbox_message = $body;
        $inbox_type = $inbox_message["type"];

        //  This inbox only responds to follow requests
        if ( "Follow" != $inbox_type ) { die(); }

        //  Get the parameters
        $inbox_id    = $inbox_message["id"];
        $inbox_actor = $inbox_message["actor"];
        $inbox_host  = parse_url( $inbox_actor, PHP_URL_HOST );

        //  Does this account have any followers?
        if( file_exists( "followers.json" ) ) {
            $followers_file = file_get_contents( "followers.json" );
            $followers_json = json_decode( $followers_file, true );
        } else {
            $followers_json = array();
        }

        //  Add user to list. Don't care about duplicate users, server is what's important
        $followers_json[$inbox_host]["users"][] = $inbox_actor;

        //  Save the new followers file
        file_put_contents( "followers.json", print_r( json_encode( $followers_json ), true ) );

        //  Response Message ID
        //  This isn't used for anything important so could just be a random number
        $guid = uuid();

        //  Create the Accept message
        $message = [
            "@context" => "https://www.w3.org/ns/activitystreams",
            "id"       => "https://{$server}/{$guid}",
            "type"     => "Accept",
            "actor"    => "https://{$server}/{$username}",
            "object"   => [
                "@context" => "https://www.w3.org/ns/activitystreams",
                "id"       =>  $inbox_id,
                "type"     =>  $inbox_type,
                "actor"    =>  $inbox_actor,
                "object"   => "https://{$server}/{$username}",
            ]
        ];

        //  The Accept is sent to the server of the user who requested the follow
        //  TODO: The path doesn't *always* end with/inbox
        $host = $inbox_host;
        $path = parse_url( $inbox_actor, PHP_URL_PATH ) . "/inbox";

        //  Get the signed headers
        $headers = generate_signed_headers( $message, $host, $path );

        //  Specify the URL of the remote server's inbox
        //  TODO: The path doesn't *always* end with /inbox
        $remoteServerUrl = $inbox_actor . "/inbox";

        //  POST the message and header to the requester's inbox
        $ch = curl_init( $remoteServerUrl );
        curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );
        curl_setopt( $ch, CURLOPT_CUSTOMREQUEST, "POST" );
        curl_setopt( $ch, CURLOPT_POSTFIELDS,     json_encode($message) );
        curl_setopt( $ch, CURLOPT_HTTPHEADER,     $headers );
        $response = curl_exec( $ch );

        //  Check for errors
        if( curl_errno( $ch ) ) {
            file_put_contents( "error.txt",  curl_error( $ch ) );
        }
        curl_close($ch);
        die();
    }

UUID

Every message sent should have a unique ID. This can be anything you like. Some servers use a random number. I prefer a date-sortable string.

    function uuid() {
        return sprintf( "%08x-%04x-%04x-%04x-%012x",
            time(),
            mt_rand(0, 0xffff),
            mt_rand(0, 0xffff),
            mt_rand(0, 0x3fff) | 0x8000,
            mt_rand(0, 0xffffffffffff)
        );
    }

Signing Headers

Every message that your server sends needs to be cryptographically signed with your Private Key. This is a complicated process. Please read "How to make friends and verify requests" for more information.

    function generate_signed_headers( $message, $host, $path ) {
        global $server, $username, $key_private;

        //  Encode the message to JSON
        $message_json = json_encode( $message );

        //  Location of the Public Key
        $keyId = "https://{$server}/{$username}#main-key";

        //  Generate signing variables
        $hash   = hash( "sha256", $message_json, true );
        $digest = base64_encode( $hash );
        $date   = date( "D, d M Y H:i:s \G\M\T" );

        //  Get the Private Key
        $signer = openssl_get_privatekey( $key_private );

        //  Sign the path, host, date, and digest
        $stringToSign = "(request-target): post $path\nhost: $host\ndate: $date\ndigest: SHA-256=$digest";

        //  The signing function returns the variable $signature
        //  https://www.php.net/manual/en/function.openssl-sign.php
        openssl_sign(
            $stringToSign, 
            $signature, 
            $signer, 
            OPENSSL_ALGO_SHA256
        );
        //  Encode the signature
        $signature_b64 = base64_encode( $signature );

        //  Full signature header
        $signature_header = 'keyId="' . $keyId . '",algorithm="rsa-sha256",headers="(request-target) host date digest",signature="' . $signature_b64 . '"';

        //  Header for POST reply
        $headers = array(
                    "Host: {$host}",
                    "Date: {$date}",
                  "Digest: SHA-256={$digest}",
               "Signature: {$signature_header}",
            "Content-Type: application/activity+json",
                  "Accept: application/activity+json",
        );

        return $headers;
    }

User Interface for Writing

This creates a basic HTML form. Type in your message and your password. It then POSTs the data to the /send endpoint.

    function write() {
        //  Display an HTML form for the user to enter a message.
echo <<< HTML
<!DOCTYPE html>
<html lang="en-GB">
    <head>
        <meta charset="UTF-8">
        <title>Send Message</title>
        <style>
            *{font-family:sans-serif;font-size:1.1em;}
        </style>
    </head>
    <body>
        <form action="/send" method="post" enctype="multipart/form-data">
            <label   for="content">Your message:</label><br>
            <textarea id="content" name="content" rows="5" cols="32"></textarea><br>
            <label   for="password">Password</label><br>
            <input  type="password" name="password" id="password" size="32"><br>
            <input  type="submit"  value="Post Message"> 
        </form>
    </body>
</html>
HTML;
        die();
    }

Send Endpoint

This takes the submitted message and checks the password is correct. It reads the followers.json file and sends the message to every server that is following this account.

    function send() {
        global $password, $server, $username, $key_private;

        //  Does the posted password match the stored password?
        if( $password != $_POST["password"] ) { die(); }

        //  Get the posted content
        $content = $_POST["content"];

        //  Current time - ISO8601
        $timestamp = date( "c" );

        //  Outgoing Message ID
        $guid = uuid();

        //  Construct the Note
        //  contentMap is used to prevent unnecessary "translate this post" pop ups
        // hardcoded to English
        $note = [
            "@context"     => array(
                "https://www.w3.org/ns/activitystreams"
            ),
            "id"           => "https://{$server}/posts/{$guid}.json",
            "type"         => "Note",
            "published"    => $timestamp,
            "attributedTo" => "https://{$server}/{$username}",
            "content"      => $content,
            "contentMap"   => ["en" => $content],
            "to"           => ["https://www.w3.org/ns/activitystreams#Public"]
        ];

        //  Construct the Message
        $message = [
            "@context" => "https://www.w3.org/ns/activitystreams",
            "id"       => "https://{$server}/posts/{$guid}.json",
            "type"     => "Create",
            "actor"    => "https://{$server}/{$username}",
            "to"       => [
                "https://www.w3.org/ns/activitystreams#Public"
            ],
            "cc"       => [
                "https://{$server}/followers"
            ],
            "object"   => $note
        ];

        //  Create the context for the permalink
        $note = [ "@context" => "https://www.w3.org/ns/activitystreams", ...$note ];

        //  Save the permalink
        $note_json = json_encode( $note );
        //  Check for posts/ directory and create it
        if( ! is_dir( "posts" ) ) { mkdir( "posts"); }
        file_put_contents( "posts/{$guid}.json", print_r( $note_json, true ) );

        //  Read existing users and get their hosts
        $followers_file = file_get_contents( "followers.json" );
        $followers_json = json_decode( $followers_file, true );     
        $hosts = array_keys( $followers_json );

        //  Prepare to use the multiple cURL handle
        $mh = curl_multi_init();

        //  Loop through all the severs of the followers
        //  Each server needs its own cURL handle
        //  Each POST to an inbox needs to be signed separately
        foreach ( $hosts as $host ) {
            $path = "/inbox";

            //  Get the signed headers
            $headers = generate_signed_headers( $message, $host, $path );

            // Specify the URL of the remote server
            $remoteServerUrl = "https://{$host}{$path}";

            //  POST the message and header to the requester's inbox
            $ch = curl_init( $remoteServerUrl );

            curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );
            curl_setopt( $ch, CURLOPT_CUSTOMREQUEST, "POST" );
            curl_setopt( $ch, CURLOPT_POSTFIELDS,     json_encode($message) );
            curl_setopt( $ch, CURLOPT_HTTPHEADER,     $headers );

            //  Add the handle to the multi-handle
            curl_multi_add_handle( $mh, $ch );
        }

        //  Execute the multi-handle
        do {
            $status = curl_multi_exec( $mh, $active );
            if ( $active ) {
                curl_multi_select( $mh );
            }
        } while ( $active && $status == CURLM_OK );

        //  Close the multi-handle
        curl_multi_close( $mh );

        //  Render the JSON so the user can see the POST has worked
        header( "Location: https://{$server}/posts/{$guid}.json" );
        die();
    }

Next Steps

This is not intended to be used in production. Ever. But if you would like to contribute more simple examples of how the protocol works, please come and play on GitLab.

You can follow the test user @example@example.viii.fi

It seems bizarre to me that modern Internet services sometimes "forget" that there's a world outside the Anglosphere. Some people have the temerity to speak foreign languages! And some of those languages have accents on their letters!! Even worse, some don't use English letters at all!!!

A decade ago, I was miffed that GitHub only supported some ASCII characters in its project names. There's no technical reason why your repo can't be called "ഹലോ വേൾഡ്".

Similarly, I'm frustrated that Mastodon (the largest ActivityPub service) doesn't allow Unicode usernames and has resisted efforts to change.

So I built a small ActivityPub server which publishes content from an Actor called @你好@i18n.viii.fi - it is only a demo account, but it works!

Some ActivityPub clients report that they are able to follow it and receive messages from it. Others - like Mastodon - simply can't see anything from it. Take a look at the replies on Mastodon to see which services work. You can also see some of its posts on the Fediverse.

What Does The Fox Spec Say?

The ActivityPub specification says:

Building an international base of users is important in a federated network. Internationalization

I can't find anything in the specifications which limits what languages a username can be written in. But there are a few clues scattered about.

The user's @ name is defined by preferredUsername which is:

A short username which may be used to refer to the actor, with no uniqueness guarantees. 4.1 Actor objects

There's nothing in there about what scripts it can contain. However, later on, the spec says:

Properties containing natural language values, such as name, preferredUsername, or summary, make use of natural language support defined in ActivityStreams. 4. Actors

So it is expected that a preferred username could be written in multiple scripts. Which implies that the default need not be limited to A-Z0-9.

The ActivityStreams specification talks about language mapping.

Finally, the ActivityPub specification has some examples on non-Latin text in names.

So, I think that it is acceptable for usernames to be written in a variety of non-Latin scripts.

But What About...?

There are usually a few objections to "Unicode Everywhere" zealots like me. I'd like to forestall any arguments.

What about homograph attacks?

Well, what about them? ASCII has plenty of similar looking characters. I doubt most people would notice when a capital i is replaced by a lower L - and vice-versa. Similarly the kerning issue of an r and n looking like an m is well known. Are mixed language homographs more dangerous? I don't think so.

What if people make names that can't be typed?

Well, what if they do? Maybe not being found by people who can't type your language is a feature, not a bug. But, anyway, clients can let users search for other people, or copy and paste their names.

What about weird "Zalgo" text?

It is up to a client to decide how they want to render text input. The "problems" of strange Unicode combinations are well known. This is not a hard computer-science problem.

What about bi-directional text?

The spec makes clear this is allowed.

Do people even want a username in their own script?

I have no evidence for this. But I bet you'd get pretty frustrated if you had to switch keyboard just to type your own name, wouldn't you? In any case, why can't I have a username of @😉

What's Next?

If you build ActivityPub software, give some thought to the billions of people who don't have names which easily fit into ASCII.

If your software can see @你好@i18n.viii.fi and its posts, please let me know.

But it will happily send messages and allow itself to be followed.

This shows that it is totally possible to broadcast fully-featured ActivityPub messages to the Fediverse with minimal coding skills and modest resources.

Why

I wanted to create a service a bit like FourSquare. For this, I needed an ActivityPub server which allows posting geotagged locations to the Fediverse.

I didn't want to install a fully-featured server with lots of complex parts. So I (foolishly) decided to write my own. I had a lot of trouble with HTTP Signatures. Because they are cursed and I cannot read documentation. But mostly the cursed thing.

How

Creating a minimum viable Mastodon instance can be done with half a dozen static files. That gets you an account that people can see. They can't follow it or receive any posts though.

I wanted to use PHP to build an interactive server. PHP is supported everywhere and is simple to deploy. Luckily, Robb Knight has written an excellent tutorial, so I ripped off his code and rewrote it for Symfony.

The structure is relatively straightforward.

• /.well-known/webfinger is a static file which gives information about where to find details of the account.
• /[username] is a static file which has the user's metadata, public key, and links to avatar images.
• /following and /followers are also static files which say how many users are being followed / are following.
• /posts/[GUID] a directory with JSON files saved to disk - each ones contains the published ActivityPub note.
• /photos/ is a directory with any uploaded media in it.
• /outbox is a list of all the posts which have been published.
• /inbox is an external API endpoint. An ActivityPub server sends it a follow request, the endpoint then POSTs a cryptographically signed Accept message to the follower's inbox. The follower's inbox address is saved to disk.
• /logs is a listing of all the messages received by the inbox.
• /new is a password protected page which lets you write a message. This is then sent to...
• /send is an internal API endpoint. It constructs an ActivityPub note, with attached location metadata, and POSTs it to each follower's inbox with a cryptographic signature.

That's it.

The front-end grabs my phone's geolocation and shows the 25 nearest places within 100 metres. One click and the page posts to the /send endpoint which then publishes a message saying I'm checked in. It is also possible to attach to the post a short message and a single photo with alt text.

There's no database. Posts are saved as JSON documents. Images are uploaded to a directory. It is single-user, so there is no account management.

What Works

• Users can find the account.
• Users can follow the account and receive updates.
• Posts contain geotag metadata.
• Posts contain a description of the place.
• Posts contain an OSM link to the place.
• Posts contain a custom message.
• Posts autolink #Hashtags (sort of).
• Posts can have an image attached to them.
• Messages to the inbox are recorded (but not yet integrated).

ToDo

• My account only has a few dozen followers, some of whom share the same sever. Even with cURL multi handle, it takes time to post to several servers.
• It posts plain text. It doesn't autolink websites
• Hashtags are linked when viewed remotely, but they don't go anywhere locally.
• There's no language selection - it is hard-coded to English.
• The outbox isn't paginated.
• The UI looks crap - but it is only me using it.
• There's only a basic front-page showing a map of all my check-ins.
• Replies are logged, but there's no easy way to see them.
• Doesn't show any metadata about the place being checked-in to. It could use the item's website (if any) or hashtags for the type of amenity it is.
• No way to handle being unfollowed.
• No way to remove servers which have died.
• Probably lots more.

Other Resources

I found these resources helpful while creating this project:

• MVP ActivityPub in Python on Glitch
• Understanding ActivityPub Part 1: Protocol Fundamentals
• Activity Notes
• Federating with GoToSocial

What's Next?

I've raised an issue on Mastodon to see if they can support showing locations in posts. Hopefully, one day, they'll allow adding locations and then I can shut this down.

The code needs tidying up - it is very much a scratch-my-own-itch development. Probably riddled with bugs and security holes.

World domination?

Where

You can laugh at my code on GitHub.

You can look at my check-ins on a map.

You can follow my location on the Fediverse at @edent_location@location.edent.tel

Once Elon shat the bed on Twitter, I moved over completely. And, you know what, I don't regret it for a second.

I've found a lovely community of people. I get my parasocial fix without being inundated by cryptogrifters shilling shitcoins, nor by thought-leaders posting inflammatory takes for clout. There are no disingenuous politicians and remarkably few celebrities trying to sell me their bathwater. There's no advertising. There's a great API for bots. And - for now - people are generous with their time and expertise.

But, just to be contrary, let's list some of the bad points about it.

There are fewer people about

That does mean there are fewer arseholes⁰. But it doesn't yet feel as magical as Twitter did - when you could suddenly be in a conversation with a goat farmer from the other side of the planet and a world-famous astrophysicist.

The people who are about tend to be on the techy side of things. Which does mean putting up with some annoying pedantry and plenty of "jUSt InsTaLl LinUx aNd delETE facEbOoK."

There's a bit more ✨drama✨

Small, insular communities are fractious. A perceived insult or slight can rapidly descend into childish taunts of "well I'll defederate you first!"

There was drama on Twitter - and even more since Elon's full on conversion to the dark side - but because the community is smaller here, the drama feels bigger.

Fewer official accounts

This is a mixed bag. Frankly, Twitter should never have been a customer support channel. But businesses wanted to promote their goods and services, and customers took the opportunity to upbraid them in public. That led to all sorts of weird behaviours.

Nevertheless, I'd like to be able to see what's going on in local politics, and transport, and a dozen little services I used Twitter for.

Search (is getting better)

I've posted some thoughts on Mastodon search. It's now pretty good. But the federated nature of Mastodon means it'll never be as comprehensive as Twitter.

Perhaps momentum is slowing down?

I've seen plenty of waves of users over the years. But I think that the majority of people who wanted to leave Twitter have done so.

And... I think that's OK. I still use Facebook, I'm signed into a dozen different forums, I'm not particularly loyal to anything.

The Fediverse is about diversity. It would be nice if Twitter and Threads and BlueSky all federated with each other. But I think that Mastodon now has enough users to be self-sustaining. It doesn't need to become a giant killer. It mustn't become a de-facto monopoly.

I'm looking forward to the next 7 years here.