ActivityPub 模糊测试:改进联邦宇宙中的测试
ActivityPub Fuzzer: Improving Testing in the Fediverse

原始链接: https://asml.cyber.harvard.edu/2025/10/01/introducing-the-asml-activitypub-fuzzer-improving-testing-in-the-fediverse/

## ActivityPub 模糊测试工具:简化 Fediverse 开发 ActivityPub 模糊测试工具是一个新工具,旨在简化 Fediverse(一个由 Mastodon、Threads 和 Pixelfed 等平台组成的去中心化网络)中的社交媒体软件开发。Fediverse 基于 ActivityPub 协议构建,允许不同服务之间的互操作性,但也因此带来了复杂性。不同的软件存在 ActivityPub 的“方言”,这意味着开发者需要确保与各种平台众多版本(目前超过 660 种组合!)的兼容性。 该模糊测试工具通过本地模拟这些方言来解决这个问题,使用来自 Fediverse Schema Observatory 的数据。开发者无需连接到实时服务器进行测试,可以直接在开发环境中模拟来自特定软件版本(例如 Mastodon 4.2.0 或 WordPress 6.7.1)的消息。 这简化了测试,可以快速识别兼容性问题(例如 Hometown/NodeBB 渲染修复),并避免了启动连接性有限的新服务时出现的“空房间”问题。该工具有意设计为本地运行,以防止被滥用于垃圾邮件或 DDoS 攻击。ActivityPub 模糊测试工具现已开源并可供使用,在线提供安装说明。

哈佛大学研究人员开发了一种新的ActivityPub模糊测试工具(cyber.harvard.edu),旨在改进Fediverse的测试——该去中心化社交网络协议为Mastodon等平台提供支持。Hacker News的讨论强调了对ActivityPub创新和工具的更多可见性的需求。 用户分享了几个有趣的Fediverse生态系统项目,可以通过Mastodon上的#Fediverse标签发现。这些包括Bandwagon.fm(一个音乐平台)、Bonfire(一个模块化社区服务器)和write.as(一个极简主义写作/博客工具)。 模糊测试工具的存在本身引发了讨论,表明该协议需要更强大的测试工具,这表明Fediverse正在不断发展和完善。 讨论强调了去中心化社交媒体中充满活力但有时未被充分宣传的创新格局。
相关文章

原文

I’m happy to announce the release of the ActivityPub Fuzzer.

The ActivityPub Fuzzer is a small program to help developers build social media software on the Fediverse with the ActivityPub protocol. It uses data collected by the Fediverse Schema Observatory to emulate known Fediverse software, solving the problem where developers have to manually test compatibility with dozens of other projects. The Fuzzer runs in a local development environment. You can tell it to locally emulate a public fire hose, or to send you messages formatted from every known version of a specific software project.

The problem

The Fediverse is a decentralized, interoperable network of social media sites like Mastodon.social, Threads.net, and Pixelfed.social. These apps and services are built on the ActivityPub protocol. What this means for users is that accounts on different social media services can do social media interactions like subscribe, reply, and like each other’s posts across services. Critically, users have the choice to move from service to service without losing contact with anyone. This way there’s no lock-in: if you don’t like the policies on one service, you can move to another and keep your friends and feeds. An account on Threads.net can talk to an account on Mastodon.social can talk to an account on Pixelfed.social. They’re able to do this because they all speak the same technical language. That language is called ActivityPub.

ActivityPub is very flexible by design, and different software packages put their own spin on the kind of content that goes out there in the world. I like to say that if ActivityPub is a language, then every social media service in the Fediverse speaks its own dialect of the language. Like linguistic dialects, they are mostly mutually understandable to one another, but there are some pieces that don’t make sense. That’s not a problem for humans, but we have to remember that this is computers talking to computers, and that computers take things very literally. Imagine a British person asking an American to put something in the boot of their car, and the American frantically looking for footwear. We need to be literal when dealing with computers, otherwise errors will happen and messages will fail to be delivered.

Let’s say I’m building a new social media service and I want it to be able to talk to other services via the Fediverse. If I want my software to be compatible with Mastodon, Threads and Pixelfed, that’s tricky but not impossible to do. When I’m making my software, I can hook it up to accounts on the websites mastodon.social and threads.com and pixelfed.social and see what works and what breaks.

But the big problem is that there aren’t just three services I need to be compatible with. The Fediverse Schema Observatory has observed 70 software projects out there in the Fediverse. Different servers will run different versions of those software projects, so if we want to support every known version of every known software project, that is 663 potentially different ActivityPub “dialects” out there.

We want to support as many software versions as possible so the users of our new social media service can talk to as many users of other services as possible. This is good for users because it solves the “empty room” problem of showing up to a new service without a lot of users on it. It’s good for developers because it lets us work around the network effect that keeps users on entrenched platforms.

So how do we make our software compatible with hundreds of dialects? 

The solution

Since September 2024, the Applied Social Media Lab has been running the Fediverse Schema Observatory. It has been collecting data on the different dialects that are used in ActivityPub and knows which software version speaks each dialect. Since we know how each message is shaped, we can fake data that is shaped like a message from Mastodon 4.2.0, or Misskey 2024.10.0, or WordPress 6.7.1.

So instead of having to hook our in-development software up to a WordPress 6.7.1 server, or to run a WordPress 6.7.1 server of our own, we can just run the Fuzzer and say, “Please pretend to be WordPress 6.7.1 and send me some data.”

The ActivityPub Fuzzer lets you emulate software that you are likely to encounter in the wild. And you can do it without having to connect to public servers.

The other day, I tried to improve Article rendering in Hometown. I was running a local Hometown server—not connected to the Internet—I ran the Fuzzer and said, “Send me all known message formats that contain an Article object.” It sent me dozens of different messages from Bookwyrm, Bridgy Fed, Friendica, WordPress, WriteFreely, NodeBB, Ghost, and Hacker’s Pub.

And then I just looked at the feed that my software was rendering. I could see immediately that messages from WriteFreely and Ghost looked good, but there was a weird duplication error with messages from NodeBB. At that point, I was able to go to the ActivityPub Fuzzer and inspect the JSON of the messages that were not rendering well, and I determined there was an issue with how I was displaying summary vs content. I made a post to an ActivityPub developer discussion community and we came up with a reasonable solution to my display problem. (I even got help from Julian Lam, the author of the NodeBB ActivityPub code.)

I did that all on my laptop, without having to connect my work-in-progress code to the wider Fediverse.

Design safety considerations

This is a piece of software that can create a fire hose of fake data. When designing it, I thought, “Could this be used for a DDOS attack or spam?” But all it’s doing is posting JSON data to an HTTP endpoint. A programmer could run:

while true
do
  curl -XPOST -H "Content-type: application/activity+json" -d '{"foo":"bar"}' '<https://social.example/inbox>'
done

and it would have the same effect, as far as bad behavior goes. So this isn’t really increasing risk or providing new capability to bad actors.

The other problem was: if we provided this as an online service, then we’d also be providing a low-effort tool for people to spam arbitrary inboxes on the Fediverse. Or we’d need to implement abuse-prevention measures. The solution here was to simply not provide it as an online service. The Fuzzer runs on your computer, so if you want to be a bad actor and have your IP banned for running a low-effort and easily thwarted spam campaign, that’s on you.

So generally speaking, this tool on its own does not increase attack capabilities on the Fediverse.

How to use it

The ActivityPub Fuzzer is now open for use, as well as open sourced for continued improvement. You can go here for installation instructions. It’s meant to run as a basic, tiny JavaScript server. The overall flow is:

The Fuzzer will continue to be actively developed, and issues and pull requests can be filed on the project’s Github repository.

联系我们 contact @ memedata.com