As part of my grant from NLnet to improve my Fediverse bot project, I'm spending time making sure I understand all the fundamentals of ActivityPub. The problem with Internet standards is they're scattered all over the place. Abandoned forums, half-maintained wikis, mailing lists with obscure rules, and monolithic blocks of text.

Sometimes you just want one book which collates all the info and presents it in a consistent format. This is nearly that book.

Evan Prodromou has the unenviable task of making the whole ecosystem easy to understand. Thankfully he does that well. Things are logically laid out, there are comprehensive descriptions of even the most obscure parts of the spec, and it builds up nicely from the fundamentals. Oh, it's also surprisingly light-hearted.

This principle is so important and long-winded that web architects have given it an acronym, HATEOAS. (We often pronounce it “HATE-ee-OH-us,” which sounds like a breakfast cereal nobody wants to eat. This is one reason web architects aren’t allowed to name breakfast cereals.)

There's an excellent checklist for all the steps needed when building a minimal ActivityPub server.

As with all O'Reilly books, it is a beautifully typeset ePub. Even better, it was supplied DRM-free through Kobo.

About the only significant thing missing is details of how to verify RFC 9421 HTTP Signatures. That's understandable as they're pretty new, but a bit annoying as that's what a lot of servers are sending now. Similarly, there's a good write up of how to publish a poll, but not much about voting or publishing the results.

The "Far Horizons" chapter is particularly exciting - giving a speculative overview of what AP could be used for. I, for one, am particularly looking forward to putting my Internet Connected Fridge on social media 😆

Ultimately ActivityPub is a living and evolving set of standards. No book can possibly keep up with all the changes happening to it - but Evan does a brilliant job of bringing together all the moving parts and creating a coherent picture of the standard.

Highly recommended if you're interested in understanding the fundamentals of the Fediverse!

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:

1. A fully compliant ActivityPub server, running in a single PHP file.

2. A teaching tool to help developers understand the practical aspects of creating an ActivityPub server.

3. A practical method of publishing automated messages to the Fediverse.

4. A promotional tool to show how simple and easy ActivityPub development can be.

5. A secure and usable tool written in modern PHP.

6. 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 😆

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 🤖

You can read more about the project on the NLnet site.

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.

I've been banging on about this for a while so was delighted to be invited to chat with the GeoSocial Task Force on their monthly call.

But, before I start, please remember that these proposals are not mandatory. If you don't want to share your location, then please don't share your location. This is an optional feature which shouldn't be used by people with a strong need for privacy.

We were primarily discussing the nascent Geographical Microsyntax proposals.

Firstly, I love the idea of being able to share my location. I want my friends to know I'm in town for a gig. I want people to think I'm cool because I'm seeing some experimental theatre. I want to virtue signal that I'm giving blood.

Similarly, I want to be able to find social media posts by location. What's happening right now in Paris? Did anyone else hear that sonic boom in London? Which cool people are also at this gig with me?

But, I do think these proposals have some issues which need to be addressed.

User Research

The primary thing missing from the proposal is any form of understanding what users want to do with a geotagged post.

You see a post like:

Hanging out with friends. I just checked in to Leicester Square.

What do you expect to happen when you click that link?

• See who is at the location?
• Read more information about the place being discussed?
• Find all posts at that specific address?
• Discover posts which are close to there?
• Something else?

What other things do people want to do with geotagged posts?

• Find all posts within 5Km of me?
• Discover users who have posted near me?
• Get emergency alerts for the city I'm in?
• See what's trending in a specific country?

Without knowing what people might want to do with this information, it's rather hard to design a service which meets their needs.

To micro or not to micro?

Where I disagree with the proposals is the idea of using inline text as a form of microsyntax.

Proposals like "I am in /London/ eating ice-cream" or "Checked in to Leicester Square L:N123456" fail for a couple of reasons.

Things like #hashtags and @mentions developed organically on social networks before they were eventually adopted by the platforms themselves. It is rare that a top-down diktat can be used to tell people how they should be formatting their posts.

More importantly, people are crap at formatting things consistently! Every event I go to has people using #Event alongside #Event2026 or #Event26 or a hundred variations.

Even if users could format it consistently, names are ambiguous. Is 🌐:Paris the one in France or Texas?

I'm strongly of the opinion that text is for text, not syntax.

Openness 🆚 Centralisation

Saying that you're on a specific point on the globe doesn't always provide useful information. Even with altitude, it isn't always possible to work out if your in the Starbucks or the Costa next door. Do you want to say you're in a train station, or a distinct platform, or even a specific train journey?

There are various services which offer unique IDs per loosely-defined place.

Google Maps provides a Place ID for every thing that it knows about. There's a similar service from FourSquare. But both of those are closed and proprietary systems - they can only be updated by the company that creates them.

Wikipedia's Wikidata has IDs for lots of places, similarly OpenStreetMap has nodes with names which can be used to identify locations.

But all of these suffer from the same flaw; they are centralised.

If Google kills its service then all those Place IDs die.

This has happened before. Yahoo used to run the Where On Earth IDentifier service but discontinued it.

While OSM and Wikipedia are great projects, they're still centralised. If you're banned from OSM, you can't create a new node.

So, to my mind, the primary way of identifying a place has to use a fully open, globally agreed, and unrestricted standard.

Location Plus Plus

The obvious choice is latitude and longitude as defined by WGS 84. It allows for arbitrary precision anywhere on the planet.

No one can stop you issuing lat/long just because a country is under sanctions. The standards community can't revoke your access to it. The co-ordinates are well understood by almost all software.

There are some alternatives. Google's Plus.Codes build on top of lat/long to make something more human readable. But, crucially, human readability is not the issue here. This is metadata which should never be shown to a human. If a user interface wants to format a lat/long they can do so as a Plus.Code or any other format.

GeoJSON

There are dozens of competing ways to mark up a location.

It seems sensible to me that, given most major social media protocols use JSON, adding GeoJSON would be the simplest way to add geographic information to a post's metadata.

At its most basic, a single "Point" can be shared like so:

{
    "type": "Feature",
    "geometry": {
        "type": "Point",
        "coordinates": [-0.13005,51.5103]
    }
}

It can have as much or as little precision as needed.

If the place being checked into has a name, it can also be added - this could be used for display purposes within the message

{
    "type": "Feature",
    "geometry": {
        "type": "Point",
        "coordinates": [-0.13005,51.5103]
    },
    "properties": {
        "name": "Leicester Square"
    }
}

The properties can be as complex as the sender wants. For example it could add Wikidata references, OpenStreetMap IDs, telephone numbers, or some cool new thing which hasn't been invented yet.

Here's a maximalist example of checking in to a park:

{
    "type": "Feature",
    "geometry": {
        "type": "Polygon",
        "coordinates": [
        [
                [-0.1303791,51.5099976],
                [-0.1295305,51.5100444],
                [-0.1297077,51.510947 ],
                [-0.1308786,51.5105859],
                [-0.1308893,51.5105793],
                [-0.1303791,51.5099976]
            ]
        ]
    },
    "properties": {
        "name": "Leicester Square",
        "WikiData": "Q848912",
        "OSM": "4082589",
        "GooglePlaceID": "ChIJPcTFENIEdkgR94E58rgB69o",
        "PlusCode": "9C3XGV69+4X",
        "Quinfrob": "🌐89451_𰻝",
        "address": {
            "road": "Leicester Square",
            "neighbourhood": "St. James's",
            "quarter": "East Marylebone",
            "suburb": "Covent Garden",
            "city": "City of Westminster",
            "ISO3166-2-lvl8": "GB-WSM",
            "state": "England",
            "ISO3166-2-lvl4": "GB-ENG",
            "postcode": "WC2H 7NA",
            "country": "United Kingdom",
            "country_code": "gb"
        }
    }
}

What's Next

My personal opinion is that the following needs to happen:

• Talk to some users - find out what they might use this for.
• Work with privacy advocates to reduce possible harms (for example, being able to redact a location from a previously shared post).
• Discuss with developers about how they'd work with this metadata.
• Clients should start adding GeoJSON metadata to their posts, even if it can't be displayed yet.

You can read the minutes of the meeting and I'd encourage you to join the next call.

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.

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.

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.

Fool!

My first talk was at the Social Web Birds-of-a-Feather session. I told people about my ActivityBot social networking server and how I built it into a single file. In the spirit of minimalism, I only had 8 minutes to present. Time for a speed-run!

Sadly / Luckily there's no audio or video of the session (if you have some, let me know) so you'll have to make do with some slides. Speaker notes are included - read them rapidly for the full effect!

I built an ActivityPub bot server in 64KB of PHP. Sorry!

Feedback and Photos

@ioana@hachyderm.io

Ioana

Best start for the Social BoF with @Edent talk!
#Fosdem #fosdem2025 #fosdem25

---

@ioana@hachyderm.io

Ioana

@EdentLoved the
- I do not have time for applause. Please don't clap 😂
- I do not have time for reactions
- I do not have time for questions

PS for those reading this, it was fun and nice
😅

---

@liaizon@social.wake.st

wakest ⁂

First thing this morning at Social Web #BOF we have @Edent presenting their single file php #ActivityPub project that is entirely contained in one slide!

---

@Sascha@bonn.social

Sascha Foerster :bonndigital:

Wir lachen so viel, wir haben keine Zeit zum Posten. Fantastischer Vortrag über den kleinsten ActivityPub-Bot possible, made by @Edent.

---

@_elena@mastodon.social

Elena Rossini ⁂

@Edent your BOF talk was absolutely brilliant Terence! 👏👏👏👏👏

---

@redmer@typo.social

Redmer

@Edent I have a photo!

---

@mala@fosstodon.org

Davide Eynard (+mala)

@Edent here’s, sadly, the only photo I took - I regret not having more now and I’d love to see one of those “he is lying to you” moments again! 😂

---

Say… didn't I write my own ActivityPub server? Why, yes! Yes I did!

I took the code and stripped it down to the bare essentials. All you need to do is upload two files⁰ - index.php and .htaccess - fill in your details, and you're done.

Get the ActivityBot source code on GitLab.

There's no database, no containers, no caching. It is as simple as I could make it

This bot can do the following:

• 🔍 Be discovered on the Fediverse
• 👉 Be followed by other accounts
• 🚫 Be unfollowed by accounts
• 📩 Send messages to the Fediverse
• 💌 Send direct messages to users
• 🖼️ Attach an image & alt text to a message
• 🕸️ Autolink URls, hashtags, and @ mentions
• 🚚 Move followers from an old account
• 🔏 Verify cryptographic signatures
• 🪵 Log sent messages and error.

That's it! Here's what it doesn't do:

• ❌ Receive messages (other than follows and unfollows)
• ❌ Thread replies
• ❌ Delete or update a post
• ❌ Create Polls
• ❌ Attach multiple images
• ❌ Set focus point for images
• ❌ Set sensitivity for images / blur
• ❌ Set "Content Warning"
• ❌ Accurate support for converting user's text to HTML
• ❌ Cannot be discovered by Lemmy instances

Grab a subdomain (don't buy a whole new domain name!) and stick this code on it. You'll have an ActivityPub bot running in minutes.

You can follow one of my bots @colours@colours.bots.edent.tel

Feedback very much welcome.

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!

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.

Take, for example, this tale from museum-worker Aaron Cope:

I was out with a friend who worked for Twitter and I asked them whether it would be possible for the museum to “create 200,000 Twitter accounts, one for each object in the Cooper Hewitt’s collection”. My friend looked at me for a moment, laughed, and then simply said: No.

In that blog post, Aaron reveals that the San Francisco International Airport Museum is using ActivityPub to create automated social-media bot accounts for all its exhibits and, possibly, every object it hold.

And why not! That would be close to impossible to do on a centralised service. But on a decentralised service under your own control, it is relatively simple. Perhaps I only want to follow the museum's canteen, or I just want to engage with a specific artefact. The Fediverse makes that possible.

This reminds me of the Melbourne "treemail" phenomenon. Every tree in the city had an email address, ostensibly so residents could email maintenance issues for a specific tree. Instead, people started interacting with the trees and sending them little love notes!

Dearest Golden Elm Tree, I finally found you! As in I see you everyday on my way to uni, but I had no idea of what kind of tree you are. You are the most beautiful tree in the city and I love you

A few weeks ago, I read about Ben Smith inventing Tweeting trains. With a bit of code, every train line in the UK was suddenly represented on the web in a convenient format. Well… Convenient if you were on Twitter.

Museums, trees, and trains naturally brings me on to the Internet of Things. I think it is fair to say that IoT is in a bit of an odd place right now. Matter is a confusing mishmash of standards. Security and privacy issues dog the simplest devices. Many people don't even want their toaster online!

For the majority of domestic uses, people want an Intranet of Things. There's little need to have your light-bulbs controlled when you're outside of WiFi range. Similarly, it is probably a really bad idea to have your hydroelectric dam connected to the Internet.

Which brings me back to the Fediverse.

On the one hand, it would be nice to be able to follow @Yellow_Line@Transit_Authority.gov - or even @Bus_Stop_1234@bus_company.biz - that would allow for hyperfocused data getting to the right people. It seems feasible that every civic object could have a Fediverse account. From the individual streetlights to the municipal sewerage system. Perhaps people won't send love letters to overflowing drains - but a social-dashboard of your civic environment could be both practical and delightful.

And, as for your domestic gadgets? Why not give every room, or every light-bulb, in your home a private Fediverse account? You could send a message like:

Hey @thermostat@My_Home.example.com, please set the temperature to 19°C. Thanks!

That might be a bit much! But I like the idea of a private social network which consists of all my IoT gadgets talking to me and each other.

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.

HTTP Message Signatures are hard⁰. There are lots of complex parts and getting any aspect wrong means certain death¹.

In a previous post, I wrote A simple(ish) guide to verifying HTTP Message Signatures in PHP. It turns out that it was too simple. And far too trusting.

An HTTP Message Signature is a header which is separate to the message it signs. You might receive a JSON message like this:

{
   "actor":   "https://example.com/user/Alice",
   "message": "We strike at dawn!"
}

How do you know that really came from Alice? You look at the header of the message. It will be something like:

Signature: 
   keyId="https://example.org/user/Alice#main-key",
   algorithm="rsa-sha256",
   headers="(request-target) host date digest",
   signature="/AJ4Dv/wSL3XE1dLjFHCYVc7AF4f3+Q10G/r8+6cPsooiUh2K3YX3z++Nclo4qKHYr61yu+T4OMqUry1T6ZHmZqmNkg1RpVg=="

We want to check that Alice signed this message with her private key. So we grab her public key given by the keyId. From there, we do some fancy maths using RSA-SHA256 and conclude that, when you put together the (request-target) host date digest content-type and compare them to the public key, they can only have be signed by the private key. Hurrah!

Did you spot the mistake I made? It wasn't in the maths, or the complex ordering of the data, or the algorithm choice, or some weird Unicode problem.

I made an error in trust.

Take a look at the Signature again.

The keyId is from example.org. But the actor is from example.com.

This message is signed correctly. It is cryptographically valid. But it wasn't signed by the actor in the message!

In this case, the fix is simple. Get the public key from keyId. Then independently get the named actor's public key. If they match, all is well. If not, skulduggery is afoot.

I'm almost tempted to say that you should ignore the provided keyId entirely; the source of truth is the actor's key - and the best way to get that is directly from the actor's profile.

Please explain why I'm wrong in the comments.

After a bunch of feedback and testing, I've added a some features to make it slightly more useful.

• A single PHP file - 45KB of no-library goodness. Just add your details, upload, and done.
• No databases. Everything stored as JSON files on disk.
• Be followed. External users can discover and follow you.
• Send messages. You can send messages to all your followers.
• 🆕 Follow users. You can follow other Fediverse actors.
• 🆕 Read messages. You can read the messages sent to your Inbox. If media is attached, those will be displayed.
• 🆕 Verify signatures. ActivityPub messages can by cryptographically signed. This now verifies those signatures.

You can grab the code here - pull requests welcome. If you want to see what it looks like in action, visit https://example.viii.fi/ or follow @example@example.viii.fi.

Again, to re-emphasise what it says in the README - this is not suitable for production use. This is primarily a way to explain all the different functions of an ActivityPub server. It is adequately commented and I hope a moderately competent programmer could follow what's going on. It is almost certainly insecure and is considered harmful to aquatic life.

I would be delighted if you took the code and did something interesting with it. Perhaps create a single-file server in your favourite language?

ToDo

A few random things which I might add - or which you might consider making and sending a Pull Request:

• Better UI. It is deliberately bare-bones, see the /read interface. But perhaps there's a simpler way to make it look nice?
• No threading in the UI - and no ability to reply to messages.
• Support for reading hashtagged posts on the site.
• Reply highlighting - at the moment you can't see if a message was sent to you.
• Some Fediverse posts contain polls, content warnings, and other extended features. That could be fun to support - both for reading and writing.
• Support for reading custom emoji.
• Deletes, Updates, and Undos are received - but it currently doesn't remove the previously saved file.
• There's no way to unfollow a user - except for manually deleting data from the file-system.
• Only supports one image upload. Could support more? Or even other media?
• I don't think CC works properly.
• Message visibility could be useful.
• Boring stuff like better error handling.

If you have opinions, please let me know!

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.

Conceptually, they're relatively straightforward.

You send me a normal HTTP request. For example, you want to POST something to https://example.com/data

You send me these headers:

POST /data
Host: example.com
Date: Sat, 24 Feb 2024 14:43:48 GMT
Accept-Encoding: gzip
Digest: SHA-256=aaC57TDzM0Wq+50We2TkCsdMDvdqON92edg7KI+Hk8M=
Content-Type: application/activity+json
Signature: keyId="https://your_website.biz/publicKey",algorithm="rsa-sha256",headers="(request-target) host date digest content-type",signature="JGQ53kEoIiMWRp9By9jajVGCOCu4n7XBeiA1uY5xLcnAxL2Y1GIgU/...=="
Connection: Keep-Alive
Content-Length: 751

In order to verify the contents of the message, I need to do three things:

1. Check the SHA-256 hash of the message matches the content of the "Digest" header.
2. Check the timestamp is somewhat fresh.
3. Check the signature matches.

The first is simple: base64_encode( hash( "sha256", $request_body, true ) ).

The second is a matter of opinion. I might be happy to receive messages from the distant past or far in the future. For the sake of a little clock drift, let's allow 60 seconds either way.

The third gets complicated.

First, I need to get the public key published at keyId="https://your_website.biz/publicKey".

Next, I need to know which algorithm is being used to sign the headers: algorithm="rsa-sha256"

Then, I need to know which headers - and in what order - are being signed: headers="(request-target) host date digest content-type"

So I create a string using the received details which matches those headers in that specific order:

(request-target) POST /data
Host: example.com
Date: Sat, 24 Feb 2024 14:43:48 GMT
Digest: SHA-256=aaC57TDzM0Wq+50We2TkCsdMDvdqON92edg7KI+Hk8M=
Content-Type: application/activity+json

I can verify if the signature - signature="JGQ53kEoIiMWRp9By9jajVGCOCu4n7XBeiA1uY5xLcnAxL2Y1GIgU/...==" matches by:

openssl_verify(
    $headersString, 
    $signature, 
    $publicKey, 
    $algorithm
);

If that's TRUE then all is well.

But can you spot the implicit problem?

How do I get your server's public key?

I just GET https://your_website.biz/publicKey - but if your server uses something like Authorised Fetch then I have to sign my request to you.

Which means your server will need to validate my signature by obtaining my public key. Which it will get by signing a request and sending it to me. Which, before I return my public key, I will need to validate your signature by obtaining your public key. Which I will get by signing a request... and so on.

This deadlock loop is documented. The usual way around it is either for the sending server to use an instance-specific signature which can be retrieved by an unsigned request, or to allow any unsigned request to access a user's public key.

I get why things happen this way - I just wish it were easier to implement!

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.