A Call for Better Activity Signatures in the Fediverse
Why Major ActivityPub Implementations Should Adopt Object Integrity Proofs
Let's say you have accounts named alice@bar and bob@baz that don't follow each other, but they both follow john@foo. When alice@bar replies to john@foo's post, how can bob@baz see this reply?
This problem applies not only to replies, but also to things like likes and emoji reactions. One of the ways that ActivityPub implementations solve this problem is through inbox forwarding. The idea is to forward the reply received by john@foo to bob@baz as well.
Fedify makes inbox forwarding easy and convenient with its forwardActivity() method. But the question is, can bob@baz trust the activity forwarded by john@foo?
Because HTTP Signatures sign the HTTP request that contains the activity, not the activity itself, john@foo can't sign an activity created by alice@bar when it's forwarded by him, because forwarding requires creating a new HTTP request. (The HTTP request includes things like the Host header, so a new signature is required for each new recipient.)
So, alice@bar needs to sign her activity in a way that allows john@foo to forward it. In the fediverse, there are two ways to do this: Linked Data Signatures and Object Integrity Proofs. Fedify automatically attaches all three types of signatures (HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs) to every activity it sends, so activities are free to be forwarded between ActivityPub software created with Fedify.
However, major ActivityPub implementations such as Mastodon and Misskey still sign activities with HTTP Signatures only, or only some activities with Linked Data Signatures. (Note that Linked Data Signatures is an outdated standard, and Object Integrity Proofs are recommended.)
So, why are we talking about this at length? We strongly urge major ActivityPub implementations to adopt Object Integrity Proofs, or at minimum Linked Data Signatures, for activity signing!
スタンドアロンのActivityPubボットを作成するためのTypeScriptフレームワーク、
