Skip to content

FEDERATION.md

Latest commit

 

History

History
369 lines (318 loc) · 15 KB

FEDERATION.md

File metadata and controls

369 lines (318 loc) · 15 KB
Raw

Federation

Supported federation protocols and standards

Supported FEPs

FEP-ef61

Fedify supports a profile of FEP-ef61 portable objects: it accepts ap: and ap+ef61: IDs with did:key DIDs of Ed25519 keys, verifies their FEP-8b32 proofs, dereferences them through gateways, and acts as a gateway that serves portable actors, objects, collections, and hashlink media and accepts deliveries to portable inboxes. It deliberately differs from the current FEP text in two ways, which may change in Fedify 3.0:

  • Fedify canonicalizes and serializes portable IDs with the ap+ef61: scheme instead of ap:, but accepts both and compares them as equal.
  • Fedify verifies proofs nested in compound documents, such as a signed Note in a signed Create, with a map-local profile of its own, since FEP-8b32 does not define the boundaries of embedded proofs yet.

Fedify does not implement the FEP-ae97 gateway endpoints, gateway discovery, synchronization across gateways, key rotation, built-in resolution of DID methods other than did:key, or gateways with paths. Its interoperability with other implementations is described in the next section. See the Portable objects chapter of the manual for the full profile.

FEP-ef61 interoperability

Fedify accepts the portable Application actor captured from tootik v0.25.4 (commit 5ce4b7fe074d7c385808be387ffcda7040842a19), including its HTTPS compatible identifier and eddsa-jcs-2022 Object Integrity Proof. The actor omits the JSON-LD mapping for gateways; Fedify reads that list and requires JCS proofs to authenticate the original JSON. The unchanged response and capture procedure are recorded in the tootik fixture.

In a separate local HTTPS test, a freshly registered portable tootik Person sent a Follow to a Fedify inbox. Fedify independently verified the original Cavage RSA HTTP Signature, returned HTTP 202, and dispatched the activity to the Follow listener. The inbox authenticated the activity's original eddsa-jcs-2022 proof; proof-authenticated delivery does not itself check the HTTP Signature. The exact request, actor response, and procedure are recorded in the tootik Follow fixture. Offline replay uses the captured time to check the HTTP Signature's freshness; the live request used the normal current-time check.

In the reverse direction, tootik v0.25.4 accepted a Fedify-generated portable Create and stored its embedded Note with the expected ID, author, and content. Fedify generated the actor and object proofs and sent the activity through Context.sendActivity(). The first request received HTTP 401 with actor is too young; the automatic retry received HTTP 202, followed by database confirmation of processing. Changing the embedded note's content without updating its proofs received HTTP 401. The Fedify to tootik fixture records the original output, responses, and stored note.

This reverse test used HTTPS gateway origins without explicit ports: tootik v0.25.4 does not recognize compatible actor IDs with an explicit port. Its inbox authenticated the activity through its proof and skipped HTTP Signature verification. The request carried a gateway RSA signature, but this result does not establish independent acceptance of that signature by tootik.

Mitra v5.10.0 (commit 17340ef09d4a902f301acdcfde094f5778d72f35) accepted a Fedify-generated portable actor registration and processed its setup activities. A separate portable Fedify sender, which had no registered Mitra account, then delivered a Create to the registered actor's inbox. This used native Fedify objects, default signing contexts, and Context.sendActivity() with normalizeExistingProofs: true. Mitra returned HTTP 202 on the first RFC 9421 RSA request and its worker stored the sender's activity in the recipient's inbox. Corrupting the HTTP Signature returned HTTP 401. This required serializing gateways as origins without a trailing slash; Mitra rejected the previous spelling with invalid gateway URL.

Gateway registration used a separate scratch client for Mitra's FEP-ae97 endpoint; Fedify does not provide that client. Its setup Update used a compact context and Fedify's existing internal outgoing normalizer because Mitra's embedded-object limit rejected the default actor context. This setup workaround was separate from the native server-to-server delivery. The Fedify to Mitra fixture records the results and limitations, including the portless HTTPS gateway used for the sender because Mitra's WebFinger lookup drops explicit gateway ports.

In the other direction, Mitra forwarded a portable Create submitted to its gateway outbox by the Fedify client. Mitra signed the HTTP request with its Cavage RSA gateway key; the activity and embedded note retained the client's DID proofs. Fedify separately verified the HTTP Signature with the normal current-time freshness check, returned HTTP 202 from its proof-authenticated inbox, and dispatched the Create listener. The Mitra to Fedify fixture records this delivery. It tests Mitra's gateway transport of client-signed objects, rather than independent generation of DID proofs by Mitra. Mastodon compatibility remains unverified.

ActivityPub

Since Fedify is a framework, what activity types it uses is up to the application developers. However, Fedify provides a comprehensive set of ActivityPub vocabulary types that are commonly used in the fediverse.

Activity types

Actor types

Object types

Collection types

Link types

Extended types

Cryptographic types

Service types