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!

Fedify, an ActivityPub framework, has finally released its first stable version, 1.0.0! Here are key changes:

Deprecation of the term handle

From this version, the term handle across Fedify will only be used to refer to fediverse handles (e.g., @hongminhee@fosstodon.org). An actor's internal unique ID (e.g., b379dbdc-3b4f-4ef4-88c2-fc25632d1c22) is referred to as an identifier, and the WebFinger name (e.g., hongminhee) is referred to as a username.

The term handle in the API will be maintained for a while for backward compatibility, but deprecation warnings will be logged, and it is planned to be removed in the future.

For more details, please refer to the related documentation.

Linked Data Signatures

Linked Data Signatures is an outdated standard, but it's still relied upon by major fediverse implementations such as Mastodon.

In addition to HTTP Signatures and Object Integrity Proofs, Fedify now supports Linked Data Signatures from this version, thus supporting all types of signature methods used in the fediverse. This makes Fedify an ActivityPub implementation with the best interoperability.

However, Fedify users don't need to do anything special to use Linked Data Signatures. If an incoming activity has Linked Data Signatures, it automatically verifies the signature, and all outgoing activities will have signatures in three formats: HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs.

For more details, please refer to the related documentation.

Activity forwarding

From this version, you can forward activities received in the inbox to other actors using the InboxContext.forwardActivity() method.

At first glance, you might think that you could just resend an activity received in the inbox using the Context.sendActivity() method. However, if you do this, the original signature is removed before the activity is delivered to the inbox, and when sending it, the signature of the forwarding actor is attached instead, causing the receiving side of the forwarded activity to not trust it.

On the other hand, when using the InboxContext.forwardActivity() method, the activity is forwarded with the original signature preserved, avoiding this problem. (Of course, the original activity itself must be signed with Linked Data Signatures or Object Integrity Proofs.)

For more details, please refer to the related documentation.

Sending Delete(Application) on fedify inbox termination

From this version, fedify inbox will send a Delete(Application) activity to all peer servers it encountered when terminated. This is typically an activity sent when deleting an account, which will help prevent residual data related to temporary actors from remaining on other servers.

PostgreSQL drivers

The @fedify/postgres package, which implements PostgreSQL drivers for the KvStore and MessageQueue interfaces, has been released alongside this version.

The PostgreSQL driver is a backend that can be sufficiently used in production, especially recommended for projects already using PostgreSQL.

Additionally, an option to select the PostgreSQL driver has been added to the fedify init command.

Celebrating Fedify 1.0.0

With the release of version 1.0.0, Fedify will now maintain API backward compatibility as much as possible. (Of course, in the long term, there may be a 2.0.0 that breaks backward compatibility.) This should be good news for those who have been hesitant to use Fedify because there hasn't been a stable version until now!

So, hoping that more services will support ActivityPub in the future, I conclude this post!

#Fedify #ActivityPub #fedidev