8.2 KiB
Federation
Supported federation protocols and standards
- ActivityPub (Server-to-Server)
- WebFinger
- Http Signatures
- NodeInfo
Supported FEPs
- FEP-67ff: FEDERATION.md
- FEP-f1d5: NodeInfo in Fediverse Software
- FEP-8fcf: Followers collection synchronization across servers
- FEP-5feb: Search indexing consent for actors
- FEP-044f: Consent-respecting quote posts
- FEP-3b86: Activity Intents: offer handlers for
ObjectandCreate(with support for thecontentparameter only), has support for theFollow,Announce,LikeandObjectintents - FEP-521a: Representing actor's public keys: starting with Mastodon 4.7, we support RSA and Ed25519 keys exposed through FEP-521a, but we do not expose our keys this way
- FEP-8b32: Object Integrity Proofs: starting with Mastodon 4.7, we support top-level Object Integrity Proofs using the
eddsa-jcs-2022cryptosuite, but we do not emit any Object Integrity Proof
ActivityPub in Mastodon
Mastodon largely follows the ActivityPub server-to-server specification but it makes uses of some non-standard extensions, some of which are required for interacting with Mastodon at all.
Required extensions
WebFinger
In Mastodon, users are identified by a username and domain pair (e.g., Gargron@mastodon.social).
This is used both for discovery and for unambiguously mentioning users across the fediverse. Furthermore, this is part of Mastodon's database design from its very beginnings.
As a result, Mastodon requires that each ActivityPub actor uniquely maps back to an acct: URI that can be resolved via WebFinger.
HTTP Signatures
In order to authenticate activities, Mastodon relies on HTTP Signatures, signing every POST and GET request to other ActivityPub implementations on behalf of the user authoring an activity (for POST requests) or an actor representing the Mastodon server itself (for most GET requests).
Mastodon requires all POST requests to be signed, and MAY require GET requests to be signed, depending on the configuration of the Mastodon server.
Before Mastodon v4.5.0, Mastodon only supported HTTP Signatures such as defined in the draft-cavage-http-signatures-12 specification draft.
Starting with Mastodon v4.5.0, Mastodon supports requests signed using HTTP Message Signatures (RFC9421) with the rsa-v1_5-sha256 algorithm in addition to the old draft-cavage-http-signatures-12 draft. Mastodon v4.7 also supports verifying signatures using the ed25519 algorithm, and uses RFC 9421 in outbound requests when draft-cavage-http-signatures-12 requests are met with a 400 or 401 error code.
| Mastodon version | Support for draft-cavage-http-signatures-12 |
Support for RFC 9421 |
|---|---|---|
| v4.4.0 (EOL 2026-12-17) | rsa-sha256 inbound and outbound |
No |
| v4.5.0 | rsa-sha256 inbound and outbound |
rsa-v1_5-sha256 inbound |
| v4.6.0 | rsa-sha256 inbound and outbound |
rsa-v1_5-sha256 inbound |
| v4.7.0 (unreleased) | rsa-sha256 inbound and outbound |
rsa-v1_5-sha256 and ed25519 inbound, rsa-v1_5-sha256 outbound as a fallback |
Optional extensions
Embedded signatures
Mastodon supports embedded signatures through either Linked-Data Signatures or Object Integrity Proofs.
| Mastodon version | Support for Linked Data Signatures | Support FEP-8b32: Object Integrity Proofs |
|---|---|---|
| v4.4.0 (EOL 2026-12-17) | RsaSignature2017 inbound and outbound |
No |
| v4.5.0 | RsaSignature2017 inbound and outbound |
No |
| v4.6.0 | RsaSignature2017 inbound and outbound |
No |
| v4.7.0 (unreleased) | RsaSignature2017 inbound and outbound |
top-level eddsa-jcs-2022 or mldsa44-jcs-2024 inbound |
Additional documentation
Size limits
Mastodon imposes a few hard limits on federated content. These limits are intended to be very generous and way above what the Mastodon user experience is optimized for, so as to accommodate future changes and unusual or unforeseen usage patterns, while still providing some limits for performance reasons. The following table summarizes those limits.
| Limited property | Size limit | Consequence of exceeding the limit |
|---|---|---|
| Serialized JSON-LD | 1MB | Activity is rejected/dropped |
Profile fields (actor PropertyValue attachments) name/value |
2047 | Field name/value is truncated |
Number of profile fields (actor PropertyValue attachments) |
50 | Fields list is truncated |
Poll options (number of anyOf/oneOf in a Question) |
500 | Items list is truncated |
Account username (actor preferredUsername) length |
2048 | Actor will be rejected |
Account display name (actor name) length |
2048 | Display name will be truncated |
Account note (actor summary) length |
20kB | Account note will be truncated |
Account attributionDomains |
256 | List will be truncated |
Account aliases (actor alsoKnownAs) |
256 | List will be truncated |
Custom emoji shortcode (Emoji name) |
2048 | Emoji will be rejected |
Media and avatar/header descriptions (name/summary) |
10000 | Description will be truncated |
Collection name (FeaturedCollection name) |
256 | Name will be truncated |
Collection description (FeaturedCollection summary) |
2048 | Description will be truncated |