☰

Fediverse Enhancement Proposals

ChangingGraph contributes to the Fediverse Enhancement Proposal process — the public review track for protocol-level additions to ActivityPub. This page summarises the FEPs authored under the ChangingGraph umbrella that are currently submitted to the upstream Codeberg repository and under review.

This page is a structured summary, not a mirror of the canonical FEP texts. For the full normative documents follow the "Read the full spec" link at the end of each section. FEPs are kept English-only — FEP titles and the interop community are canonically English, and a parallel German translation of the specs would add churn without reaching a different audience.

Contents

FEP-34c1 — Collection Filtering using TREE Hypermedia Vocabulary

Submitted Under review at Codeberg

ActivityPub defines collections like inbox and outbox but gives clients no standardised way to request a filtered view of them. FEP-34c1 introduces a filter endpoint that a collection advertises via tree:search. Clients POST a FilterRequest carrying TREE relations (EqualToRelation, GreaterThanRelation, …); the response is a standard OrderedCollectionPage, so clients without filter support fall back cleanly. Two server-resolved placeholders — fep34c1:myFollowees and fep34c1:myAudience — make home-timeline and audience filters expressible portably, without hard-coded actor lists. Uses ActivityPub, ActivityStreams 2.0, TREE and SPARQL-compatible operator semantics.

Read the full spec: fep-34c1.md on Codeberg

FEP-34ec — Notification Collection Endpoint

Submitted Under review at Codeberg

Every Fediverse server today (Mastodon, Pleroma, GoToSocial, Misskey) exposes notifications through a proprietary REST API — there is no ActivityPub-native answer. FEP-34ec adds a single notifications property under the actor's endpoints block (ActivityPub §5.7) pointing to an OrderedCollection of notification-worthy activities. The collection is a view, not a separate delivery channel; the activities still live in the inbox. Read/unread state is modelled by presence and absence, so dismissal uses the standard Remove activity (§7.5), batch dismissal uses FEP-db70's RemoveAll, and selective filtering reuses FEP-34c1 — no new vocabulary beyond the one endpoint property.

Read the full spec: fep-34ec.md on Codeberg

FEP-db70 — RemoveAll Collection Activity

Submitted Under review at Codeberg

ActivityPub's Remove activity requires the client to name every object it wants to remove from a target collection — fine for one or two items, but a round-trip flood for "mark all as read" or "clear an old collection". FEP-db70 adds a RemoveAll activity type that addresses a target collection and optionally carries a FEP-34c1 FilterRequest to select which items to remove. Without a filter, the server removes everything in the target. With a filter, the full expressiveness of TREE relations is available ("older than X", "of type Like", "from a specific actor", or any AND/OR combination). It's deliberately generic: works with any ActivityPub collection, not just notification collections.

Read the full spec: fep-db70.md on Codeberg

Interested in implementing one of these, or collaborating on a draft?

Discussion is on the SocialHub forum (threads are linked from each FEP on Codeberg), or write to office@gsund.rocks.