Explore FEPs

All Status Draft & Final Draft Final Withdrawn All Topics Collections & Filtering Content & Objects Conversations & Messaging Discovery & Capabilities Federation & Delivery Governance & Process Identity & Authentication Interoperability & Protocols Migration & Portability Social Features All Protocols C2S S2S All Types Implementation Informational All Authors Adam R. Nelson André Menrath Angus McLeod AvidSeeker Ben Pate Bumblefudge CJ Calvin Lee Claire Daiki "tesaguri" Mizukami Diogo Peralta Cordeiro Dmitri Zagidulin Dmitry Skavish Don Marti Erin Shepherd Evan Prodromou Felix Ableitner FenTiger Fred Hauschel Gregory Klyushnikov Helge Helge Krueger James Smith Jennifer Moore John Livingston Jonny Saunders Julian Lam Lynn Foster Manton Reece Marcin Czachurski Marius Orcsik Mauve Signweaver Michael Puckett Nik Clayton Phablulo Joel Rimu Atkinson Ryan Barrett Steve Bate Tim Bray Zack Dunn a bengo bumblefudge helge ilja les potato pukkamustard silverpill

FEP	Author	Status	Topic	Type	Protocol	Date
▶FEP-a4ed: The Fediverse Enhancement Proposal Process	pukkamustard	Final	Governance & Process	Informational		2020-10-16
A Fediverse Enhancement Proposal (FEP) is a document that provides information to the Fediverse community. The goal of a FEP is to improve interoperability and well-being of diverse services, applications and communities that form the Fediverse. This document describes the scope, format and process of publishing Fediverse Enhancement Proposals.
▶FEP-8fcf: Followers collection synchronization across servers	Claire	Final	Federation & Delivery	Informational	S2S	2020-10-24
In ActivityPub, follow relationships are established, updated and removed by sending activities such as Follow, Accept or Reject, which are assumed to be correctly and promptly processed upon receipt. However, due to incompatible protocol extensions, software bugs, server crashes or database rollbacks, the two ends of a Follow relationship may end up out of sync. This can be especially damaging when a remote instance has outdated information about follow relationships that should have been revoked, as some implementations may deliver activities addressed to the sender's followers collection by using the sharedInbox mechanism and letting the recipient use the sender's followers collection for local delivery and access control. This proposal describes an optional mechanism for detecting discrepancies in following relationships across instances, with minimal overhead and without loss of privacy.
▶FEP-f1d5: NodeInfo in Fediverse Software	CJ, silverpill	Final	Discovery & Capabilities	Informational		2020-12-13
NodeInfo is a protocol intended to standardize upon a way to provide server-level metadata to the public. This enables tools and clients to utilize this metadata to assess server health or facilitate end-users choices about servers and software to use on the Fediverse.
▶FEP-400e: Publicly-appendable ActivityPub collections	Gregory Klyushnikov	Final	Collections & Filtering	Informational	S2S	2021-02-16
In social media, it's a frequent pattern when there's a collection owned by someone that other people can contribute to. Examples include: - Walls where others can post - Forums as well as topics within - Photo albums in groups where group members can add photos Currently, there is no generic way to signify that an object was created as part of a collection and should only be considered in its context. This proposal describes how ActivityPub servers and clients could specify collections to which objects created by their actors belong.
▶FEP-8c3f: Web Monetization	Diogo Peralta Cordeiro, Phablulo Joel	Withdrawn	Social Features	Informational	S2S	2022-01-18
Web Monetization federation via ActivityPub.
▶FEP-2100: Unbound Group and Organization	Diogo Peralta Cordeiro	Withdrawn	Governance & Process	Informational	S2S	2022-03-31
Historically, after the sudden death of a popular instance, one could neither target groups hosted at it anymore nor contact the whole followers collection to let them know of the new instance housing a certain group. If we always have absolute knowledge of the complete followers collection (or good enough), we can automate based on which instance has more local followers which server would become the new house. Another alternative would be to automatically archive the old group and start again from scratch. This FEP, on the other hand, discusses something very different of automatically moving an actor from one server to a different one. It is about collaboration between different group or organization actors to promote an unified experience between the participants of the linked group actors. We think this may be easier, more flexible, and promote a better UX than only notifying the actor that the house of a certain group has moved, but both solutions would probably achieve similar results in the above use case. This proposal introduces an interpretation of a Group following another Group and the gs:unbound attribute. This allow two groups (or organization) to "act as one" (not exactly, but elaborated afterwards). This primarily aims at effectively removing a central point of authority for groups, but offers more than that. With this, @alice@undefinedhackers.net can mention a group named hackers (!hackers) or even address an activity To !hackers@instance.gnusocial.test (C2S) and let her instance's !hackers announce to other instances' !hackers. Finally, this proposal is general enough to allow a server to simultaneously have !lug@server (without links), !lug-unbound@server (with the greatest links collection it can grow), and !lug-with-some-links@server (with only some links). It doesn't require linked groups to have the same preferredUsername.
▶FEP-e232: Object Links	silverpill	Final	Content & Objects	Informational	S2S	2022-08-01
This document proposes a way to represent text-based links to ActivityPub objects which are similar to mentions. One example of such link is inline quote within the value of the content property, but this proposal is not limited to any particular use case.
▶FEP-5624: Per-object reply control policies	Claire	Withdrawn	Conversations & Messaging	Informational	S2S	2022-08-23
Sometimes, users may want to share an information or a story without inviting replies from outside their circles or from anyone at all. In particular, individuals may want to restrict who can reply to them in order to avoid “reply guys” or limit outright harassment, while instutions may want to disable replies on their posts to provide information without having to deal with a moderation burden. This can be broken into an advisory part advertising what sets of actors are expected to be able to reply, and a collaborative verification process where third-parties check with the actor being replied to that the reply is indeed allowed.
▶FEP-1b12: Group federation	Felix Ableitner	Final	Governance & Process	Informational	S2S	2022-11-12
Internet forums are one of the oldest forms of social media. This document describes how they are implemented in existing Activitypub platforms using Group actors. It also introduces a new property to indicate that a given object belongs to a group.
▶FEP-8b32: Object Integrity Proofs	silverpill	Draft	Identity & Authentication	Implementation	S2SC2S	2022-11-12
This proposal describes how ActivityPub servers and clients could create self-authenticating activities and objects. HTTP signatures are often used for authentication during server-to-server interactions. However, this ties authentication to activity delivery, and limits the flexibility of the protocol. Integrity proofs are sets of attributes that represent digital signatures and parameters required to verify them. These proofs can be added to any activity or object, allowing recipients to verify the identity of the actor and integrity of the data. That decouples authentication from the transport, and enables various protocol improvements such as activity relaying, embedded objects and client-side signing.
▶FEP-c390: Identity Proofs	silverpill	Draft	Identity & Authentication	Implementation		2022-11-23
This proposal describes a mechanism of creating verifiable links between Decentralized Identifiers and ActivityPub actor profiles. Potential applications include: identity verification, end-to-end encryption and account migrations.
▶FEP-cb76: Content Addressed Vocabulary	a	Withdrawn	Content & Objects	Informational		2022-11-29
JSON-LD context definitions typically live at some URI which gets used as a namespace. It is generally expected that the URI is long-lived, and often the context document is retrievable from that URI, but sometimes these links break due to technical errors, expired domains, and other such issues. This FEP proposes adopting a solution proposed by CAV for any extension terms defined within other FEPs, as well as optionally for standard vocabulary.
▶FEP-fb2a: Actor metadata	a	Draft	Content & Objects	Informational		2022-12-09
It is useful for actors to publish additional structured information about themselves without necessarily defining an extension property or additional vocabulary. This FEP describes a way for actors to publish generic key-value pairs representing their metadata.
▶FEP-c118: Content licensing support	Tim Bray	Draft	Content & Objects	Informational		2023-01-16
Currently, popular Fediverse software does very little to establish the legal status of posts. Controversy over indexing and scraping the Fediverse is common. The hope is that providing a legal framework to express the desires of users as to how their content may be re-used might bring order to this debate.
▶FEP-2e40: The FEP Vocabulary Extension Process	Helge Krueger	Withdrawn	Governance & Process	Informational		2023-02-13
Current usage of ActivityPub relies on the ActivityStreams namespace AS-NS combined with custom extensions Mastodon NS. As far as I can tell, no best practices exist or a formal process to add new namespaces. This FEP will - Create a FEP Vocabulary based on identified best practices - Define a process to add new entries to this FEP Vocabulary without a risk of Term collision - Define a process to elevate Terms to be common - Define a process to create specialized Vocabularies - Using FEP-61CE as an example how this process can be used. Note: Withdrawn as no longer compatible with the FEP repository structure, see this issue(https://codeberg.org/fediverse/fep/issues/134).
▶FEP-7888: Demystifying the context property	a	Draft	Conversations & Messaging	Informational	S2SC2S	2023-03-14
ActivityStreams Vocabulary defines the context property, but it is "intentionally vague". Unfortunately, this makes the definition so vague as to be practically useless. This FEP aims to provide more guidance on possible uses of the context property, as well as formalizing some best practices.
▶FEP-d767: Extend ActivityPub with Valueflows	Lynn Foster	Withdrawn	Social Features	Informational	S2S	2023-04-02
A standard method to extend ActivityPub/ActivityStream with Valueflows vocabulary, to enable varied economic networking activity in the fediverse.
▶FEP-5bf0: Collection sorting and filtering	Michael Puckett	Withdrawn	Collections & Filtering	Informational	C2S	2023-04-10
This proposal would allow Collections to have a streams property, as Actors do. The streams would be of the type CollectionView, a proposed vocabulary extension that represents a sorted and/or filtered version of a Collection. ActivityPub clients could then render CollectionViews without having to perform such filtering or sorting operations themselves. Metadata about how the sorting or filtering has been applied would be applied using new proposed vocabulary extensions that leverage SHACL for describing constraints.
▶FEP-888d: Using https://w3id.org/fep as a base for FEP-specific namespaces	a	Draft	Governance & Process	Informational		2023-04-10
It is considered best practice in the linked-data ecosystem to have IRIs be HTTPS URIs that resolve to a definition of the term being used, and it is desirable to define such terms in a JSON-LD context file that is referenced by its IRI rather than having the full @context object embedded in every single document. ActivityStreams 2.0 and ActivityPub do this with the normative context and namespace provided at https://www.w3.org/ns/activitystreams, but this namespace is not generally open to extensions or to experimental terms. This FEP therefore proposes using https://w3id.org/fep as a base IRI for the FEP process, allowing sub-namespaces for each FEP.
▶FEP-0ea0: Payment Links	silverpill	Draft	Content & Objects	Implementation		2023-04-18
This FEP describes a way to attach payment information to ActivityPub actors and objects. That information might be a link to donation page, a link for buying an artwork, or anything else that can be represented with a URI.
▶FEP-612d: Identifying ActivityPub Objects through DNS	Helge	Withdrawn	Discovery & Capabilities	Informational		2023-04-18
In ActivityPub, objects are identified through their id, which is a dereferenciable URI. For this, one adds a TXT record to DNS with name apobjid and value corresponding to the URI of the ActivityPub object. If a domain name is then passed to a FediVerse application, it can then perform the DNS lookup, and resolve it to the ActivityPub object.
▶FEP-fffd: Proxy Objects	Adam R. Nelson, Ryan Barrett	Draft	Interoperability & Protocols	Informational	S2S	2023-04-29
A proxy object is an \ActivityPub object that is semantically identical to another entity, which may exist on another, non-ActivityPub protocol. For example, an ActivityPub-to-Nostr bridge creates Actors and Notes that are proxies for Nostr users and notes. This document describes a data format to identify proxy objects and to specify the ActivityPub and non-ActivityPub entities they are equivalent to, with the intention that multi-protocol clients will automatically merge objects with their proxies, hiding the implementation details of bridges and cross-protocol publishing from users.
▶FEP-4adb: Dereferencing identifiers with webfinger	Helge	Draft	Identity & Authentication	Informational	S2S	2023-05-13
In this FEP, we will formalize the process of dereferencing an URI using webfinger in order for usage in ActivityPub. The main goal is to enable the usage of URIs of the form acct:user@domain or did:example:12345 as ids for objects used in ActivityPub. While this FEP only discusses this in the context of actors, it should be applicable for general objects. In order for a smooth introduction, it is recommended to start deployment with actor objects. This FEP first presents the algorithm and examples, then discusses the usage in the context of the Fediverse. This means the first two sections are for people wanting to implement this FEP, the following sections are for people wanting to decide if this FEP is a good idea.
▶FEP-a070: Ordered properties for plain JSON consumers	a	Draft	Content & Objects	Informational		2023-06-13
In a Github-issue filed against the normative AS2 context, it was pointed out that attachment and tag are unordered by default, although some implementations of "fediverse" software blindly assume them to always be ordered. This can be made unambiguous by using @list in JSON-LD, but for plain JSON consumers, a separate shorthand term must be defined. This FEP attempts to disambiguate between unordered and ordered arrays for those plain JSON consumers.
▶FEP-c648: Blocked Collection	Evan Prodromou	Draft	Collections & Filtering	Informational	C2S	2023-06-14
Users need to review and revise the list of actors they have blocked. This FEP defines a new collection property, the Blocked Collection, which contains the actors that a user has blocked. It also defines a collection of Block activities, which can be used to undo blocks. Finally, it defines inverse properties for both collections, to aid in navigating between the collections and the actors that own them.
▶FEP-bad1: Object history collection	a	Draft	Collections & Filtering	Informational	S2SC2S	2023-06-15
AS2-Core provides examples 18, 19, 32 which represent the "history" of an object. Particularly in example 32, we see an object being Created, Updated, and Deleted. However, there is no property dedicated to advertising a collection fit for this purpose. This FEP attempts to define one.
▶FEP-4ccd: Pending Followers Collection and Pending Following Collection	Evan Prodromou	Draft	Collections & Filtering	Informational	C2S	2023-06-21
This ActivityPub extension defines two collections, pendingFollowers and pendingFollowing, with which users can review and manage their pending follow requests.
▶FEP-d36d: Sharing Content Across Federated Forums	Zack Dunn	Draft	Conversations & Messaging	Informational	S2S	2023-07-01
New instances on the threadiverse (servers that implement ActivityPub with FEP-1b12) are often seeded with forums for common interests, leading to multiple servers having similar forums. Users may dislike having to follow what they perceive to be "duplicate" forums or keep up with multiple discussions on the same topic across multiple servers. This document describes a method for allowing Group actors to share content to reduce posting of a single link multiple times, which reduces what users see as "duplicate" posts and fragmented conversations across multiple forums.
▶FEP-1970: Chat Links	John Livingston	Draft	Interoperability & Protocols	Informational		2023-07-04
This FEP describes a way to attach a chat room to ActivityPub(https://www.w3.org/TR/activitypub/) actors and objects. The chat room itself can be a web page, a XMPP room, a Matrix room, an IRC channel, ... The chat itself does not necessarily publish messages using ActivityPub.
▶FEP-521a: Representing actor's public keys	silverpill	Final	Identity & Authentication	Implementation		2023-07-08
This proposal describes how to represent public keys associated with ActivityPub actors.
▶FEP-ae97: Client-side activity signing	silverpill	Draft	Identity & Authentication	Implementation	S2SC2S	2023-08-14
Existing Fediverse servers manage signing keys on behalf of their users. This proposal describes a new kind of ActivityPub client that lets users sign activities with their own keys, and a server that can distribute client-signed activities to other servers.
▶FEP-0837: Federated Marketplace	silverpill	Draft	Social Features	Implementation	S2S	2023-08-17
This document describes a minimal implementation of a federated marketplace based on ActivityPub protocol and Valueflows vocabulary. In such marketplace actors can publish offers and requests, respond to offers and requests published by other actors, enter into agreements and exchange information necessary to complete these agreements.
▶FEP-67ff: FEDERATION.md	silverpill	Final	Interoperability & Protocols	Informational		2023-09-05
FEDERATION.md is a file containing information necessary for achieving interoperability with a federated service. It was originally proposed by Darius Kazemi on SocialHub forum in Documenting federation behavior in a semi-standard way?(https://socialhub.activitypub.rocks/t/documenting-federation-behavior-in-a-semi-standard-way/453) topic.
▶FEP-5feb: Search indexing consent for actors	Claire	Draft	Discovery & Capabilities	Informational		2023-09-06
This FEP introduces an actor-level attribute that can be used to explicitly express an actor's consent (or lack thereof) to their public objects being indexed for search purposes. Akin to robots.txt and noindex meta tags, this attribute is advisory and relies on the indexers respecting the directive, as public objects can not technically be prevented from being indexed.
▶FEP-dc88: Formatting Mathematics	Calvin Lee	Draft	Content & Objects	Informational	S2S	2023-09-12
This FEP recommends a method for formatting mathematics in ActivityPub post content in MathML Core. Furthermore, this FEP describes how to sanitize and convert such mathematics to plain text, if an implementation does not wish to support mathematical formatting.
▶FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API	Evan Prodromou	Draft	Identity & Authentication	Informational	C2S	2023-09-17
This FEP defines a mechanism for using an ActivityPub object ID as the clientid in the OAuth 2.0 authorization code flow. (An earlier version defined a full profile for using OAuth 2.0 with the ActivityPub API, but this version has been abbreviated to focus only on the client ID mechanism. The title has been retained to accommodate FEP tooling.)
▶FEP-7628: Move actor	silverpill	Draft	Migration & Portability	Informational	S2S	2023-09-20
Migration of followers from one ActivityPub actor to another.
▶FEP-07d7: A Custom URL Scheme and Web-Based Protocol Handlers for Linking to ActivityPub Resources	Jennifer Moore	Withdrawn	Interoperability & Protocols	Informational		2023-09-22
This specification addresses sometimes difficult interactions with ActivityPub resources hosted on remote servers. It defines a custom URL scheme which can be used by custom web-based protocol handlers to route hyperlinks to those resources to the user's preferred server. It additionally advises when ActivityPub servers can include these links in HTML views they generate, and how clients and servers can implement those web-based protocol handlers.
▶FEP-37f2: a policy for calls for consensus on SWICG group decisions	bengo	Draft	Governance & Process	Informational		2023-09-28
A FEP proposing that W3C Social Web Incubator Community Group harmonize(https://en.wikipedia.org/wiki/Harmonization(standards)) its process with other W3C Groups as well as the Fediverse Enhancement Process on socialhub.activitypub.rocks by: posting Calls for Consensus on the SWICG mailing list public-swicg@w3.org engaging other SWICG fora like socialhub.activitypub.rocks (linked to as "Forum" from the SWICG Webpage(https://www.w3.org/community/socialcg/)) having a shared response period
▶FEP-2677: Identifying the Application Actor	Helge	Draft	Discovery & Capabilities	Informational	S2S	2023-10-14
It is a common pattern in Fediverse applications to have a special actor of type Application. This is for example the actor at https://mastodon.example/actor for Mastodon or at https://pleroma.example/internal/fetch for Pleroma. This application actor can be fetched with an unsigned request, so it is possible to use it to fetch public keys. The goal of this FEP is to provide an explicit mechanism of identifying the application actor, with the goal of making it usable for further tasks, e.g. - Allowing for application to application communication by having application actor send activities to another application actor's inbox. - Having an object one can attach further information to. This means, one could attach a list of implemented FEPs to the application actor.
▶FEP-03c1: Actors without acct-URI	helge	Draft	Identity & Authentication	Informational		2023-11-10
Most current Fediverse applications use an acct-URI as unique display name for actors. Usually, this display is done by displaying acct:user@domain.example as @user@domain.example. This FEP states that if there is no acct-URI associated with an actor, the actor should be displayed as its id. So the actor with id https://actor.example/path will be displayed as https://actor.example/path. In addition to the example below, we wish to point out that further independence of webfinger will enable new features such as using domain names as handles.
▶FEP-ef61: Portable Objects	silverpill	Draft	Migration & Portability	Implementation	S2S	2023-12-06
Portable ActivityPub objects with server-independent IDs.
▶FEP-7502: Limiting visibility to authenticated actors	a	Draft	Federation & Delivery	Informational	S2S	2023-12-24
Some servers require authentication for all requests made via ActivityPub, even for GET requests on public objects addressed to as:Public. This violates the requirement that anything addressed to as:Public is made available without requiring authentication. This FEP proposes an alternative addressing that may be used in such scenarios, signaling that the object is not fully public but is otherwise available to any actor.
▶FEP-2c59: Discovery of a Webfinger address from an ActivityPub actor	Evan Prodromou	Draft	Identity & Authentication	Informational		2024-01-04
Webfinger is used on the fediverse to abstract out variations in ActivityPub actor URL formats, giving a uniform way of addressing an actor. With a Webfinger address, a client can discover the actor's ActivityPub actor URL. This specification defines an explicit way to reverse the process, and discover a preferred Webfinger address from an ActivityPub actor URL.
▶FEP-d556: Server-Level Actor Discovery Using WebFinger	Steve Bate	Final	Discovery & Capabilities	Implementation	S2S	2024-01-20
Server-level ActivityPub actors support server-wide functionality rather than representing a user or the software equivalent (sometimes called a bot). This proposal describes how to discover a server-level actor's URI using WebFinger.
▶FEP-3264: Federated Work Coordination	Lynn Foster	Draft	Social Features	Informational	S2S	2024-01-31
This document describes an implementation of project planning and work coordination based on ActivityPub(https://www.w3.org/TR/activitypub/) protocol and Valueflows(https://valueflo.ws/) vocabulary. It includes planning what people want to do, and (optionally) recording what is done.
▶FEP-c5a1: To-do's	Lynn Foster	Draft	Social Features	Informational	S2S	2024-01-31
This document describes an implementation of simple to-do's or tasks based on ActivityPub(https://www.w3.org/TR/activitypub/) protocol and Valueflows(https://valueflo.ws/) vocabulary. A to-do is a simple work commitment, and can be created for oneself or another person. Optionally, when the to-do is done, that can be recorded also.
▶FEP-61cf: The OpenWebAuth Protocol	FenTiger	Draft	Identity & Authentication	Implementation	S2S	2024-02-06
OpenWebAuth is the "single sign-on" mechanism used by Hubzilla, (streams) and other related projects. It allows a browser-based user to log in to services across the Fediverse using a single identity. Once logged in, they can be recognised by other OpenWebAuth-compatible services, without third-party cookies and often without any explicit user interaction. This is not a specification, a proposal, or a "best practice" document. The aim is to describe the existing protocol in detail as an aid to implementers, evaluators, and anyone who wants to understand its operation. It is mostly based on reverse-engineering the existing implementations and focuses on the minimal requirements for basic interoperability. In OpenWebAuth, each user is identified by a public/private key pair. The protocol relies on there being a mechanism for other nodes on the network to discover a user's public key. This document assumes that ActivityPub actor objects will be used for this purpose. OpenWebAuth can also work with other protocols such as Zot6 and Nomad but these are not considered here.
▶FEP-73cd: Migration User Stories	Bumblefudge	Draft	Migration & Portability	Informational		2024-02-07
In the interest of clarifying and aligning on the problem-space of user account migration, multiple-account management, and export/import/migration of content/activity history, these user stories are offered to organize discussion and solution-sharing.
▶FEP-96ff: Explicit signalling of ActivityPub Semantics	Erin Shepherd	Draft	Federation & Delivery	Informational	S2S	2024-02-17
A number of vulnerabilities have occurred in ActivityPub implementations due to "type confusion" attacks - where unrelated files on the same hostnmae as an ActivityPub implementation are processed as obejcts with ActivityPub semantics. Such attacks have been mitigated by carefuly validating the Content-Type header (and by implementations ensuring that users cannot create files with the application/activity+json or application/ld+json content types), but it would bolster such defences if messages intended to be processed with ActivityPub semantics Additionally, ActivityPub nominally supports transfer syntaxes other than JSON-LD (such as any other RDF syntax like Turtle; or potentially a more bandwidth efficient syntax such as a hypothetical CBOR-LD). Strict content type filtering permanently prevents usage of such syntaxes in the future The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
▶FEP-6481: Specifying ActivityPub extension support with NodeInfo	James Smith	Withdrawn	Discovery & Capabilities	Informational		2024-03-12
Many FediVerse services extend ActivityPub and ActivityStreams to add their own behaviour, such as custom object types. In order to interoperate with other servers running different software, the service needs to know whether or not the remote server supports these same extensions. This FEP defines a standard method of specifying support for particular extensions in the server's NodeInfo file (as described in FEP-f1d5), so that compatibility information can be automatically discovered.
▶FEP-9fde: Mechanism for servers to expose supported operations	Nik Clayton	Draft	Discovery & Capabilities	Informational	S2SC2S	2024-03-14
This document proposes an extension to the NodeInfo schema(http://nodeinfo.diaspora.software/) (FEP-f1d5(https://codeberg.org/fediverse/fep/src/branch/main/fep/f1d5/fep-f1d5.md)) that would allow developers of Mastodon and Mastodon-like servers to unambigiously communicate the operations their servers support, and allow developers of software that interoperates with those servers to detect those features, promoting interoperability and easier adoption of new features.
▶FEP-e229: Best practices for extensibility	a	Draft	Interoperability & Protocols	Informational		2024-04-02
Current popular implementations of ActivityPub do not handle extensibility very well. This FEP seeks to highlight some basic requirements for extensibility, and offer suggested advice to implementers who wish to avoid compatibility issues, particularly for LD-unaware consumers.
▶FEP-3b86: Activity Intents	Ben Pate	Draft	Discovery & Capabilities	Informational	C2S	2024-04-19
"Activity Intents" extend the capabilities of an ActivityPub server beyond a user's outbox, and enable direct interactions with content on the wider social web. They do this by publishing a machine-readable list of public URLs where users can perform key activities (such as Follow, Like, or Announce) allowing other websites to initiate remote social interactions without cumbersome copying/pasting of URL strings.
▶FEP-7458: Using the replies collection	a	Draft	Conversations & Messaging	Informational	S2S	2024-04-26
Replies are not defined in ActivityPub, as there are no specified side effects for simply encountering objects or activities with inReplyTo set. Most current implementations implicitly reconstruct replies at consumption time, and may silently and implicitly maintain the replies collection at the producer's side. This FEP provides guidance for explicitly using the replies collection, and explicitly managing it.
▶FEP-0391: Special collection proofs	a	Draft	Collections & Filtering	Informational	S2S	2024-04-29
Some properties represent special collections, such as: - outbox (ActivityPub) - inbox (ActivityPub) - followers (ActivityPub) - following (ActivityPub) - liked (ActivityPub) - likes (ActivityPub) - shares (ActivityPub) - replies (FEP-7458) - context (FEP-7888) Verifying that any given object is part of a special collection is usually only possible by resolving that collection and checking its items one-by-one until the current object is found. This can be inefficient to verify. It would be easier if there was an inverse claim for each claim made about an object being part of a special collection. This FEP aims to define some properties that can be used to make those inverse claims.
▶FEP-db0e: Authentication mechanism for non-public groups	Gregory Klyushnikov	Draft	Identity & Authentication	Informational	S2S	2024-05-03
This proposal addresses the problem of authenticating access to the content of non-public groups. It is mostly intended to supplement FEP-400e. Only the server that hosts the Group actor knows for sure who can and can not access the content in the group. However, due to each object being hosted on the server of the actor that created it, it is not ordinarily possible for those other servers to restrict access to that object only to those actors who have the permission to see it. This FEP defines an authentication mechanism, "actor tokens", that allows an actor to issue tokens that serve as a temporary proof of group membership for other servers.
▶FEP-cd47: Federation-friendly Addressing and Deduplication Use-Cases	Bumblefudge	Draft	Migration & Portability	Informational		2024-05-31
A proposed taxonomy of ways to make various kinds of ActivityPub data identifiable across locations to simplify higher-order functions like moderation receipts, tracking for trust and safety purposes, data migration, compliance, etc. This is intended as a light-weight and informational/meta-technical design document, not a specification or an extension.
▶FEP-c7d3: Ownership	silverpill	Withdrawn	Identity & Authentication	Informational	S2S	2024-06-04
In this document we discuss the concept of ownership, as applied to ActivityPub objects. >!WARNING >This FEP has been superseded by FEP-fe34(https://codeberg.org/fediverse/fep/src/branch/main/fep/fe34/fep-fe34.md).
▶FEP-5e53: Opt-out Preference Signals	Don Marti	Draft	Content & Objects	Informational	S2S	2024-06-09
Some users have concerns about how their content and/or personal information are used. For example, some users do not want the content they created to be used for training generative AI systems, and some users do not want to have their personal information shared or sold. Several opt-out preference signals (OOPSs) have been standardized or proposed in the form of HTTP headers that can apply to a connection between a user and a central server. In some jurisdictions, companies that administer web sites are required to process and act on OOPSs. This FEP extends ActivityPub to support passing OOPSs along with the content and user information to which they may apply. This FEP refers to existing OOPSs that have already been documented, and does not propose new ones.
▶FEP-7952: Roadmap For Actor and Object Portability	Dmitri Zagidulin, bumblefudge	Draft	Migration & Portability	Informational	S2SC2S	2024-06-20
Portability: A set of design choices, data models, and protocols, that enable an end-user to automatically migrate from one service provider to another with the least amount of data loss and service disruption, including loss of or disruption to the user's social graph (Followers and Following collections, etc). We focus on automated migration because the option of fully manual migration always exists, such as re-typing all of one's messages and content, manually re-adding everyone to one's following collection, manually contacting everyone on one's former followers list and asking them to re-follow, and so on. However, that's an extreme failure state in usability terms; we want to avoid that. This FEP targets two main categories of migration, covering user stories 1A-1F and 2 + 3 in FEP-73cd: User Migration Stories, respectively. It also draws inspiration from an earlier information document, FEP-cd47: Federation-friendly Addressing and Deduplication Use-Cases.
▶FEP-e3e9: Actor-Relative URLs	Dmitri Zagidulin, bumblefudge	Draft	Migration & Portability	Informational	S2S	2024-06-29
> "All problems in computer science can be solved by another level of indirection" (the "fundamental theorem of software engineering") -- Attributed to: Butler Lampson (src(https://en.wikipedia.org/wiki/Indirection)) This FEP introduces an ID scheme for ActivityPub objects and collections that has the following properties: IDs remains stable across domain migrations. That is, allows the controller of the objects to change object hosting providers without changing the object IDs. IDs are regular HTTP(S) URLs that are resolvable via an HTTP GET request (provided the client allows following 302 redirects). The proposed mechanism identifies objects by adding query parameters to existing Actor profile URLs. ActivityPub clients wishing to fetch the objects make an HTTP GET request to this URL, as usual, carrying whatever authentication mechanism is required currently, and then follow the HTTP 302 status code redirect in the response to the current storage location of the object. Example Actor-Relative URL: https://alice-personal-site.example/actor?service=storage&relativeRef=/AP/objects/567 An AP client, encountering an Object ID with this URL makes an HTTP GET request just as it would with any other Object ID: http GET /actor?service=storage&relativeRef=/AP/objects/567 HTTP/1.1 Host: alice-personal-site.example The server responds with a 302 redirect (which all HTTP clients are able to automatically follow) pointing to the current storage location of the object. For example: http HTTP/1.1 302 Found Location: https://storage-provider.example/users/1234/AP/objects/567 This redirection mechanism is enabled in all existing HTTP clients by default (see https://developer.mozilla.org/en-US/docs/Web/API/Request/redirect), and requires no additional re-tooling of ActivityPub client code.
▶FEP-d9ad: Create Conformance Tests for Fediverse Enhancement Proposals	bengo	Draft	Governance & Process	Informational		2024-07-02
This is a proposal to enhance the fediverse by creating test cases for FEPs. The proposal describes a Conformance Test Rule format that FEP authors and testers may find useful when creating tests cases as proposed.
▶FEP-e965: Move Activity for Migrations and Announce Activity for Tombstone Events	bumblefudge, bengo	Draft	Migration & Portability	Informational	S2S	2024-07-05
This FEP normatively specifies exactly one narrow step in almost all the migration user-stories defined in FEP-73cd: User Migration Stories: the updates to an Actor object made after a migration and/or deactivation event, and the Move activity which a source server propagates to inform followers of said Actor object update Our proposal clarifies semantics and behavior of the earlier FEP-7628 on which it strictly relies. It also proposes a simple, additive approach to use the above to express "deactivated" Actors by "tombstoning" their Actor objects, i.e. adding "Tombstone" to their type array (already afforded by the Activity Streams vocabulary). It also accomodates migrations to new forms of Actor object, such as "Nomadic"-style Portable Actors as described in FEP-ef61: Portable Objects and "Independently-hosted" Actor objects as described in FEP-7952, both for conforming and non-conforming consumers. As such, fully implementing all optional features of this proposal would require implementing FEP-521a: Representing actor's public keys, which adds terms to the Actor object for publishing a verification method to verify assertions about the Actor independently of domain.
▶FEP-9091: Export Actor Service Endpoint	Dmitri Zagidulin	Draft	Migration & Portability	Informational	C2S	2024-07-08
This FEP defines an API endpoint used to initiate the "Export Actor" operation. The output and semantics of the result of the export operation is out of scope, and left to subsequent FEPs. The endpoint only specifies how to start the operation, and by extension, how to tell if a given Actor's server supports this operation.
▶FEP-6fcd: Account Export Container Format	Dmitri Zagidulin	Draft	Migration & Portability	Informational		2024-07-11
This FEP describes a lightweight general purpose account export container format, with the following properties: General purpose, allowing for easy adaptation of existing ActivityPub, social media, and cryptographic key material export formats Extensible, upgradable, and self-documenting (in the human-readable sense) Works with FEP-7952: Roadmap for Actor and Object Portability(https://codeberg.org/fediverse/fep/pulls/334/files) Serves as a concrete serialization of the result of the Export operation described in FEP-9091: Export Actor Service Endpoint(https://codeberg.org/fediverse/fep/pulls/353) Out of scope: Encryption -- handled in a separate layer Compression -- handled in a separate layer (how to turn a .tar file into a .tar.gz is well known)
▶FEP-c551: Use ECMAScript Modules to Create Conformance Tests for Fediverse Enhancement Proposals	bengo	Draft	Governance & Process	Informational		2024-07-11
This is a proposal to enhance the fediverse by creating test cases for FEPs as ECMAScript Modules. <!-- TOC -->
▶FEP-a5c5: Web Syndication Methods	AvidSeeker	Draft	Interoperability & Protocols	Informational		2024-07-15
This document proposes a standard for web syndication methods across the Fediverse by appending .rss or .atom to object URLs. This will allow users to easily subscribe to feeds of timelines, posts, and other objects. Additionally, this proposal addresses whether syndication methods should be applicable to mirrored profiles across the Fediverse, recommending optional but preferred implementation.
▶FEP-c4ad: Viewership History	AvidSeeker	Draft	Collections & Filtering	Informational	C2S	2024-07-15
This document proposes a standard for managing viewership history across the Fediverse. It addresses the common issue of posts being repeatedly shown to users on different clients. The goal is to enable servers to track which posts have been viewed by individual users and ensure that clients do not display these posts again. This proposal aims to enhance user experience by preventing the redundant display of already seen posts, commonly requested as "Hide already seen posts" or "stop repeating already seen posts".
▶FEP-c893: DOAP	AvidSeeker	Draft	Discovery & Capabilities	Informational		2024-07-15
This proposal introduces a standardized method for describing Fediverse projects using the Description of a Project (DOAP) format. The proposal outlines the creation of doap.jsonld file that includes details about implemented federation protocols and supported Fediverse Enhancement Proposals (FEPs). This makes it easier for developers and users to understand the capabilities and compatibility of various Fediverse projects.
▶FEP-eb48: Hashtags	AvidSeeker	Draft	Content & Objects	Informational		2024-07-16
This proposal introduces a standardized method for identifying and displaying hashtags in posts across the Fediverse. The rules define what constitutes a hashtag and how it should be parsed and displayed, ensuring consistency and predictability across different platforms and clients.
▶FEP-eb22: Supported ActivityStreams types with NodeInfo	Manton Reece	Draft	Discovery & Capabilities	Informational	C2S	2024-07-25
Servers can advertise what features of the API they support, such as creating a poll or boosting a post. Clients can recognize if a server doesn't support a feature and hide it from the UI.
▶FEP-c0e0: Emoji reactions	silverpill	Draft	Social Features	Implementation	S2S	2024-08-08
This document describes how emoji reactions are implemented in ActivityPub network.
▶FEP-c16b: Formatting MFM functions	ilja	Draft	Content & Objects	Informational	S2S	2024-08-10
This FEP recommends a method for formatting MFM in ActivityPub post content using HTML with custom classes and data- attributes. Furthermore, this FEP provides a new extension term to indicate that this HTML representation is used.
▶FEP-0499: Delivering to multiple inboxes with a multibox endpoint	a	Draft	Federation & Delivery	Informational	S2S	2024-09-30
This FEP introduces a server-wide endpoint for delivering activities to multiple inboxes. sharedInbox currently allows for doing this, but it requires the remote server to know how to deliver the activity based on its addressing properties. However, the remote server might not know how to deliver the activity to private recipients, or recipients within a collection. The multibox endpoint removes this knowledge requirement from the receiving server and instead makes the sending server responsible for marking inboxes to explicitly deliver to.
▶FEP-76ea: Conversation Threads	Evan Prodromou	Draft	Conversations & Messaging	Informational	S2S	2024-10-04
This FEP defines a way to identify the conversation thread of an object with Activity Streams 2.0.
▶FEP-1985: Signaling how an OrderedCollection is ordered	a	Draft	Collections & Filtering	Informational		2024-10-10
OrderedCollection is defined as an ordered set in the Activity Vocabulary, but the precise ordering is not defined. The ActivityPub specification requires that instances of OrderedCollection MUST be ordered reverse chronologically by insertion order, but a later errata was proposed to relax this restriction by only applying it to properties defined as OrderedCollection within the ActivityPub specification. Consequently, this allows for some collections to be presented forward chronologically by insertion order, and some collections to be presented reverse chronologically by insertion order. This FEP introduces an orderType property and two vocabulary terms ForwardChronological and ReverseChronological to explicitly signal the ordering of a collection.
▶FEP-268d: Search consent signals for objects	Daiki "tesaguri" Mizukami	Draft	Content & Objects	Informational		2024-10-12
This FEP documents an extension property for Activity Streams 2.0 to signal the consent for an object to be searched by a given actor.
▶FEP-ae0c: Fediverse Relay Protocols: Mastodon and LitePub	Steve Bate	Final	Federation & Delivery	Informational	S2S	2024-10-19
Relays are important components within the decentralized Fediverse architecture. They act as intermediary servers that facilitate communication between different instances, enabling users on Fediverse platforms to share public content without requiring actor following relationships. These relays benefit small instances by enabling them to effectively participate in the federated social network, both as consumers and producers of Fediverse content. Several styles of relays existing in the Activity Fediverse. This FEP describe two popular styles of relays: Mastodon-style relays(#mastodon-relay-protocol) LitePub-style relays(#litepub-relay-protocol) NOTE: This is an informational FEP documenting the current status quo. It uses RFC-2119 requirements keywords only as a convenience. Also, these are not standardized protocols. They will generally not be conformant with the ActivityPub standard although they use some concepts from it.
▶FEP-b2b8: Long-form Text	Evan Prodromou	Draft	Content & Objects	Informational	S2SC2S	2024-11-07
Multi-paragraph text is an important content type on the Social Web. This FEP defines best practices for representing and using properties of a long-form text object in Activity Streams 2.0.
▶FEP-fe34: Origin-based security model	silverpill	Draft	Identity & Authentication	Implementation	S2S	2024-11-15
Developing a comprehensive ActivityPub security framework based on the concept of web origin.
▶FEP-171b: Conversation Containers	silverpill	Draft	Conversations & Messaging	Implementation	S2S	2024-11-23
This document specifies a model for managing conversations in ActivityPub network. It is based on the implementation of Conversation Containers in Streams(https://codeberg.org/streams/streams). In this model conversations are represented as collections controlled by a single actor. Such conversations take place within a specific audience and may be moderated.
▶FEP-6606: ActivityPub client to server collections addressing conventions	Marius Orcsik	Draft	Collections & Filtering	Informational	C2S	2024-12-04
This document tries to describe a simple set of conventions to better enable the adressing of ActivityPub objects on servers that support Client to Server Interactions. Its main purpose is to formalize a basic vocabulary for defining subsets of IRIs RFC-3987 for collections in a way that can be generalized to both servers and clients. It builds upon the definition of query parametrs RFC-3986, by introducing a set of additional operators that can be applied to values.
▶FEP-1311: Media Attachments	Helge	Draft	Content & Objects	Informational		2024-12-08
Media Attachments are ubiquitous in the Fediverse. My quick investigation into the explore tab on mastodon.social yields that about half the posts contain an image attachment. The mechanism for these is poorly documented. For example, it is not mentioned in ActivityPub. My goal in this FEP is to document current usage, and issue recommendations on how to improve it. These recommendations are based on the support table Recommended Media Attachment Format available at FunFedi.dev. For developers that enjoy making their keyboards smoke, I believe that the above link combined with the content of Testing(#testing) should be enough to adapt their Fediverse applications. The other parts are meant for people, who which to improve the situation related to media attachments.
▶FEP-7d8c: Documentation: Automation of FEP	Helge	Draft	Governance & Process	Informational		2025-01-20
This FEP discusses scripts and woodpecker configuration used to automate parts of the FEP process. The FEP process is described in FEP-a4ed. As FEP-a4ed, this is a living document, and should be updated as the FEP process evolves.
▶FEP-9967: Polls	silverpill	Draft	Social Features	Implementation	S2S	2025-01-23
How to make polls in ActivityPub network.
▶FEP-2277: ActivityPub core types	silverpill	Draft	Content & Objects	Informational		2025-01-31
Classification of ActivityPub objects based on their shape.
▶FEP-a974: All Actor types should be followable	James Smith	Draft	Federation & Delivery	Informational	S2S	2025-02-05
In order to foster interoperability and good semantics, any valid unblocked Actor should be visible and followable on any platform when searched for. The type of the Actor should not matter for initial following, though can be used later as appropriate.
▶FEP-efda: Followable objects	a	Draft	Collections & Filtering	Informational	S2S	2025-02-13
ActivityStreams Vocabulary defines a Follow activity, and ActivityPub defines its side effects of manipulating a followers collection, but ActivityPub does not specify a full algorithm for how to follow something. This FEP aims to provide guidance on which objects can be followed: - The object MUST have a followers collection present. - If the object does not have an inbox, then you MAY recurse upwards through attributedTo until you find a resource with an inbox. The maximum recursion depth SHOULD be 1. A Follow activity can then be constructed for that object and delivered to the discovered inbox. Additional requirements for the structure of the Follow activity are out-of-scope.
▶FEP-f228: Backfilling conversations	silverpill	Draft	Conversations & Messaging	Implementation	S2S	2025-02-17
The most common conversation backfill method is based on recursive retrieval of posts indicated by inReplyTo property and posts contained in replies collections. This is inefficient and stops working if any node in the reply tree becomes inaccessible(https://community.nodebb.org/topic/18844/backfilling-conversations-two-major-approaches). FEP-7888: Demystifying the context property suggests using the context property for grouping related objects (such as posts in a conversation). This property can resolve to a collection, which can be used for efficient backfilling without recursion. Two different implementations of context collection exist: collection of posts and collection of activities.
▶FEP-f06f: Object observers	silverpill	Draft	Collections & Filtering	Implementation	S2S	2025-02-18
Object observer is an ActivityPub actor that can be followed to receive object updates. This proposal is intended to complement FEP-bad1: Object history collection.
▶FEP-dd4b: Quote Posts	Evan Prodromou	Draft	Content & Objects	Informational	S2S	2025-02-21
This FEP describes the mechanism defined in Activity Streams 2.0 and the Activity Vocabulary for making quote posts, that is, Announce(https://www.w3.org/TR/activitystreams-vocabulary/#dfn-announce) activities with additional commentary.
▶FEP-c180: Problem Details for ActivityPub	Evan Prodromou	Draft	Federation & Delivery	Informational	S2SC2S	2025-03-11
ActivityPub is a RESTful API and HTTP-based protocol for standards-based social networking, but does not specify an error format. This document provides a profile of the Problem Details for HTTP APIs specification (RFC 9457) for use with ActivityPub.
▶FEP-2931: Representing context with a Collection	a	Draft	Conversations & Messaging	Implementation	S2SC2S	2025-03-22
FEP-7888 attempts to lay out clarifications for the use of the context property based on rationale and history, in which context is used primarily to logically group objects related by their "context", or in other words, stating that some object "was created in relation to" another object, where the latter object denotes some purpose for the first object. In response to FEP-7888, and motivated by the desire to backfill entire conversations, various softwares wishing to federate have chosen to directly represent context as a Collection of objects acknowledged to be "within" some canonical context collection. This FEP describes this approach, its usages, and some drawbacks.
▶FEP-5711: Inverse Properties for Collections	Evan Prodromou	Draft	Collections & Filtering	Informational	S2SC2S	2025-03-24
This FEP defines inverse properties for collections that are important in ActivityPub.
▶FEP-044f: Consent-respecting quote posts	Claire	Draft	Content & Objects	Informational	S2S	2025-04-03
This document proposes a representation of quote posts that allows verifying consent of the quoted user, through a revocable authorization mechanism, as well as a representation of the user's choice regarding whetheir their posts can be quoted and by whom. The approval mechanism defined in this document is systematic and required for all quotes except self-quotes, but as with Follow and Accept, approval can be granted automatically depending on the user's choice.
▶FEP-1042: Peer to Peer Fediverse Identities	Mauve Signweaver	Draft	Interoperability & Protocols	Informational	S2S	2025-04-03
<!-- A short summary (no more than 200 words) of the proposal. --> ActivityPub's federated model allows for flexibility in referencing data between different instances. However it requires that these instances be always online and do not allow for non-internet or locally published identities outside of the HTTPS/DNS based web. This document describes how implementors can extend ActivityPub to link to objects hosted on Peer to Peer protocols and how compatible clients should detect this support and load each others' content.
▶FEP-4f05: Soft Deletion	Julian Lam, Angus McLeod	Draft	Content & Objects	Informational	S2S	2025-04-15
The standard CRUD (Create, Read, Update, Delete) behaviours in ActivityPub specify a single Delete activity for use in all cases. This is insufficient to describe two-stage deletion, often referred to as "soft" and "hard" deletion. Not all software implements two-stage deletion, and so the behaviours described here progressively enhance the functionality for those supporting it, while retaining backward compatibility otherwise.
▶FEP-8a8e: A common approach to using the Event object type	André Menrath, les	Draft	Social Features	Informational	S2S	2025-04-23
ActivityStreams defines the Object Type Event(https://www.w3.org/TR/activitystreams-vocabulary/#dfn-event). In real-world applications, the event object immediately showed the need for extension. Applications featuring Event objects have often chosen to add additional attributes and clarifications (i.e., interpretations) in order to implement their particular use case. This proposal clarifies and extends the ActivityPub standard to address the needs that have arisen in real-world implementations. This includes guidelines for the minimal interoperable event, handling of RSVP ("répondez s'il vous plaît", i.e., attendee management, and side effects), attendee capacities, physical location addresses, virtual locations, timezone, and clarification of how to control the visibility of events in federation. These differences in how the aforementioned features are implemented have led to fragmentation in how events are published, discovered, and managed across platforms.
▶FEP-0151: NodeInfo in Fediverse Software (2025 edition)	silverpill	Final	Discovery & Capabilities	Implementation		2025-05-12
NodeInfo is a protocol intended to standardize upon a way to provide server-level metadata to the public. This enables tools and clients to utilize this metadata to assess server health or facilitate end-users choices about servers and software to use on the Fediverse. This document is a revised version of FEP-f1d5: NodeInfo in Fediverse Software, which was published in 2020.
▶FEP-82f6: Actor statuses	Gregory Klyushnikov	Draft	Content & Objects	Informational	S2S	2025-05-12
This proposal describes an ActivityPub extension to allow actors to publish a short status text, with optional expiration, link attachment, and history. Some centralized communication services provide their users with the ability to set a status on their account, which is usually displayed on their profile and sometimes next to their name in other places in the UI. These are distinct from regular posts because they can not be interacted with in any way whatsoever, can't contain media attachments, and usually have a short character limit on the order of several hundred characters at most. Statuses are always visible to anyone who can see the actor itself.
▶FEP-844e: Capability discovery	silverpill	Draft	Discovery & Capabilities	Implementation	S2SC2S	2025-06-14
Capability discovery for ActivityPub applications. This document is based on the idea described in FEP-aaa3: Listing Implemented Specifications on the Application Actor.
▶FEP-b06c: ActivityPoll	Evan Prodromou	Draft	Federation & Delivery	Informational	S2SC2S	2025-06-25
ActivityPoll is a proper subset of ActivityPub that excludes activity delivery, making it easier to implement for static Web sites or content management systems. It meets an equivalent need to RSS or Atom feeds.
▶FEP-9098: Custom emojis	silverpill	Draft	Content & Objects	Implementation	S2SC2S	2025-07-06
A custom emoji is a small image used to express an idea or emotion. Custom emojis are different from Unicode emojis, which are sequences of characters. This document describes how custom emojis are implemented in the ActivityPub network.
▶FEP-11dd: Context Ownership and Inheritance	Julian Lam	Draft	Conversations & Messaging	Informational	S2S	2025-09-11
▶FEP-8967: Generating link previews for attached links	a	Draft	Content & Objects	Informational	S2SC2S	2025-09-16
A common feature in social applications is to show users a rich preview of a link included in the content of a message or post, before the user clicks the link. Currently, applications like Mastodon generate link previews for the first link found in the content, without considering the publisher's possible intent. This FEP allows publishers to explicitly signal which links are intended for special processing, using the existing attachment model. Optionally, publishers can include their own link preview information so that trusting consumers can skip generating their own previews.
▶FEP-1580: Move Actor Objects with a `migration` Collection	Jonny Saunders	Draft	Migration & Portability	Implementation	S2S	2025-10-09
(This section is non-normative) Prior FEPs (FEP-7628(https://codeberg.org/fediverse/fep/src/branch/main/fep/7628/fep-7628.md), FEP-E965(https://codeberg.org/fediverse/fep/src/branch/main/fep/e965/fep-e965.md)) describe an ability for an Actor to move to a new id, often hosted on a different server instance, however they do not describe a mechanism for moving objects that are owned^ownership by that actor. This FEP describes a mechanism of migrating objects owned by a moved Actor to the target instance using two OrderedCollections created by the target instance: - a migration collection that contains a mapping from source object URIs to new URIs on the target instance, and - a moves collection that contains the actor Move activities that prove a migration has taken place and allows verification of object signatures in the case the source Actor is no longer available. This FEP attempts to balance effectiveness, performance, security, and ease of implementation by allowing 3rd-party instances to gradually update their local copies of the affected Objects. This FEP describes a "Push"-style migration^push-pull initiated by a source instance followed by a "pull" of objects by a target instance, as well as a "Pull"-style migration initiated by a target instance given a prior export of actor data. The migration operation is agnostic to the type of the Objects being migrated, supporting protocol evolution to unanticipated Object types across instances with varying support for them. Collection-based object migration is orthogonal to, and compatible with content-addressed or other portable object schemes (e.g. FEP-ef61(https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md)). tl;dr: to migrate objects, create a mapping from the old to new objects on the target instance, and let 3rd-party instances gradually migrate their local representations using that map.
▶FEP-d8c8: BitTorrent `Torrent` Objects	Jonny Saunders	Draft	Content & Objects	Informational		2025-11-03
The BitTorrent protocol is a p2p protocol for distributing data described as a series of hashes and file metadata contained in .torrent files. This FEP describes a JSON-LD representation of .torrent files as an extension of an ActivityStreams Object.
▶FEP-19b3: Specifying Properties of a Service	Helge	Draft	Discovery & Capabilities	Informational		2025-11-04
Actors of type Service are used in the Fediverse to represent automated process. In this FEP, we suggest some property values to use to convey further information about the underlying automated process and the responsible parties for the automated process.
▶FEP-22b6: Linking an ActivityPub Object to a HTML page and back	Helge	Draft	Discovery & Capabilities	Informational		2025-11-12
Links are a fundamental part of the internet. This FEP describes how to use links to link a HTML page to an ActivityPub object. The mechanisms described in this document are not new and are used to link to RSS feeds (see alternate, second example).
▶FEP-f15d: Context Relocation and Removal	Julian Lam, Felix Ableitner, Rimu Atkinson	Draft	Conversations & Messaging	Informational	S2S	2026-01-12
Threaded applications often have the need to move and remove content between groups/communities for curation purposes (i.e. resolving miscategorization, spam, etc.) This is an extension of the Resolvable Contexts tree of FEPs.
▶FEP-ee3a: Exif metadata support	Marcin Czachurski	Draft	Content & Objects	Informational	S2S	2026-01-13
The exchangeable image file format (Exif) family combines file formats such as JPEG, TIFF and WAV with structured metadata. Exif records camera (e.g., lens data, focal length, exposure time) and audio (e.g., channel count, sampling rate) recording parameters. The standard originally focused on photography but was expanded with version 2.1 to cover sound recordings. This proposal defines a Fediverse-wide mechanism for conveying Exif metadata using the exifData property from the Schema.org vocabulary.
▶FEP-34c1: Collection Filtering using TREE Hypermedia Vocabulary	Fred Hauschel	Draft	Collections & Filtering	Informational	C2S	2026-02-19
This FEP proposes using the TREE Hypermedia Vocabulary for client-initiated filter requests on ActivityPub Collections (especially Inbox). Clients can send a filter as a JSON-LD object via HTTP POST to retrieve a filtered subset of the collection. This enables use cases such as: - Home Timeline: Content lifecycle activities (Create, Update, Delete, Announce) from followed actors, visible to public or followers - Mentions: Activities addressed to the actor via as:to or as:cc - Private Messages: Activities not addressed to as:Public (DMs, followers-only, group messages) - Media Filter: Only activities with images or videos
▶FEP-a427: Server Domain Migration	Dmitry Skavish	Draft	Migration & Portability	Informational	S2S	2026-02-25
This FEP defines a best-effort protocol for migrating an entire ActivityPub server from one domain to another when the operator controls both domains and can keep the old domain online. Example scenario used throughout this document: - Old server: sunset.social - New server: dawn.network - Remote peer: forest.instance This proposal introduces: - A ServerMigration manifest (a durable migration description object). - A ServerMigrationAcceptance object (destination confirmation). - A ServerMove activity (notification to peers). - Deterministic mapping rules for rewriting identifiers. - A verification model that prevents identity hijacking. This FEP is explicitly best-effort. It does not guarantee preservation of all follows across all peers.
▶FEP-fc48: Generic ActivityPub server	silverpill	Draft	Federation & Delivery	Implementation	S2SC2S	2026-02-27
Generic ActivityPub server is a server that implements standard ActivityPub client API or FEP-ae97 client API, and can process any activity (including activities those behavior is not defined in the ActivityPub specification).
▶FEP-3ab2: ActivityPub Event Streaming API	Steve Bate	Draft	Federation & Delivery	Informational	C2S	2026-03-14
This FEP specifies a lightweight, cookie-authenticated Server-Sent Events (SSE) streaming API that ActivityPub server implementations can expose to their authenticated clients. The API provides: 1. A session-control sub-API for issuing and revoking short-lived, singoe-use streaming tickets, and for managing per-user topic subscriptions. 2. A stream endpoint that delivers a multiplexed, real-time event feed for all topics the authenticated to which the user is subscribed. The design intentionally separates authentication (handled by the server's existing mechanism, e.g. OAuth 2.0, session cookies, or HTTP Basic) from streaming authorization (a short-lived ticket stored in an HttpOnly cookie), so that the SSE connection never carries user credentials. This proposal addresses two issues related to SSE event streaming in an ActivityPub context. Credential leaks: Since the SSE browser EventSource API does not allow sending HTTP headers when opening an SSE event stream, some proposals recommend sending credentials in the streaming URL. However, this is not desirable because of the risk that the credentials may be exposed in logs of servers (including proxy server outside the control of the the AP server operator). SSE Concurrent Connection Limits: Browsers enforce a small per‑origin limit on concurrent HTTP connections (often around 6), and each SSE stream occupies one of those connections for as long as it stays open, which can block other requests to the same origin. This proposal multiplexes multiple subscriptions on a single SSE connection rather than creating a stream per subscription.
▶FEP-34ec: Notification Collection Endpoint	Fred Hauschel	Draft	Collections & FilteringSocial Features	Informational	C2S	2026-03-15
This FEP defines a standardized notification collection for ActivityPub actors. A new notifications property under endpoints (ActivityPub §5.7) provides an OrderedCollection containing Notification objects that inform the actor about relevant activities. Unlike the inbox, which receives raw activities, the notification collection holds server-generated notification objects. Notifications only exist within the collection — read notifications are removed. Batch removal is supported via FEP-db70 (RemoveAll) with optional FEP-34c1 filtering.
▶FEP-c07e: add product type to object	potato	Draft		Implementation		2026-03-15
add a new type "Product" into "Object", alongside with "Note", "Article", etc.
▶FEP-db70: RemoveAll Collection Activity	Fred Hauschel	Draft		Informational		2026-03-15
This FEP defines a RemoveAll activity for batch-removing items from an ActivityPub collection. While the ActivityPub specification defines Remove for removing items from a collection, it requires the client to know the identity of every item to remove. RemoveAll fills this gap. It supports an optional FEP-34c1 filter to selectively remove items matching specific criteria (e.g. by type, by date, or by actor). Without a filter, all items are removed. RemoveAll is a generic collection operation — it can be used with any collection type, not just inboxes or notification collections.