FEP-9f9f: Collections

Standards Fediverse Enhancement Proposals
1

This is a discussion thread for FEP-9f9f: Collections.

The proposal describes the current best practices for implementing and using ActivityPub collections.

1 Like
2

@silverpill What is the rationale for “Clients MUST NOT embed non-anonymous collections in objects”?

I see the potential for cache poisoning etc. if we inline collections owned by someone else, but what's the harm in inlining my own collections?

3

Clients can create collections by publishing a Create activity where object is a collection. The server MUST ignore reserved collection properties such as items, totalItems and pagination properties.

What does “reserved collection properties” mean? It’s possible to manually maintain items and pagination properties:

{
  "id": "posts",
  "first": "posts/2026"
}

{
  "id": "posts/2026",
  "next": "posts/2025"
}

Some special collections, such as inbox and outbox are created automatically by a server.

This isn’t always true. It depends on the server.

Clients MUST NOT embed non-anonymous collections in objects.

Why not? This is up to the publisher. There might be a separate trust model that determines whether you accept such statements or not.

Collection IDs SHOULD NOT contain query parameters.

Why not? This is up to the host/authority to mint resource names however they wish.

The contents of a collection are modified either directly by Add, Remove and Move activities, or indirectly by side-effects of other activities.

Which other activities? I assume this is referring to Accept Follow, but it would be better to give explicit examples here.

A client can update other properties of a collection by generating an Update activity. The server MUST NOT overwrite reserved collection properties such as items, totalItems and pagination properties.

Again, “reserved collection properties” is neither defined, nor enumerated, nor justified as a MUST NOT.

Filters are specified using query parameters that are appended to a collection ID.

Not necessarily. Query components of URIs have no special meaning in https: and are simply part of the resource name. Any or no convention may be adopted by the publisher on how to use them. Filtering collections can be done using only the path component, such as for example collection/page/1/ or /posts/2026/.

Collection page IDs are usually created by appending query parameters to a collection ID

Only in some softwares / by some publishers. I would explicitly say which softwares implement which parameters.

However, a collection itself usually doesn’t have an audience and is treated as public by default.

This is both not always true and also not always relevant. When filtering the response based on some Authorization, the access control is applied per item and not (only) on the collection resource itself. If the request is authenticated and the access control mechanism is “the authenticated user is in the audience”, then the audience of the item is used rather than (only) the audience of the collection. Access control is a complex subject and the access control could be done on the level of individual statements in some deployments (possibly merging in statements from various subgraphs based on what the request is authorized to see/know).

An object can be addressed to a collection. When determining delivery targets and regulating access to an object, the server SHOULD expand collections by replacing them with actors they contain (if any).

This is unclear – by “the server”, do you mean the delivering outbox, or the receiving inbox? Also, “replace [the collection] with actors [the collection] contain[s]” isn’t a safe operation because it changes the addressing. It could leak members of a collection, and it could also makes the audience no longer retroactive (since new audience members would need to be added to old resources).

More generally, I feel that the title “Collections” is too simple for what the FEP contains, and future FEPs on collections might not necessarily agree with or depend on this FEP. It would be better to call it something like “Best practices for using Collections in 2026” or something else more specific.

1 Like
4

@silverpill I've finally got off my butt, and put my suggestions for the FEP into a ticket: https://codeberg.org/silverpill/feps/issues/20

5

This is one of the “current practices” FEPs, so I am focusing on what implementers are doing, not on what is possible. If there are counter-examples to practices described in the FEP, I could include them (but there has to be some significance threshold; a software needs to have users).

These properties are listed in the text you quoted. They are “reserved” because their values are controlled by the server.

Query parameters are used for filtering and pagination. The presence of query parameters in a base ID may cause conflicts.

Any other activities. Only Add, Remove and Move directly change the collection items.

page seems to be widespread. after, before and maxItems are used in GoActivityPub (also, I started using after in Mitra).

I don’t want to name every implementation in the FEP.

Both.

The phrase you’re referring to explains what “expansion” means. I don’t see how a server can function without expanding collections.

I think the title is appropriate because this is the first FEP about collections.

6

I am making some changes based on feedback: https://codeberg.org/fediverse/fep/pulls/811

7

The first sentence describes it as “the current best practices”. I don’t believe there’s a meaningful consensus that this is true (or that some of the practices are even good or correct). If it were described as “some collection implementation decisions” it would be more accurate (and potentially more useful if the primary implementation for each recommendation or claim were identified). I understand the “best” judgment may be your personal opinion, but I think it would be better to be clear about that.

I suggest that the FEP shouldn’t use requirements key words it’s only documenting implementation decisions.

ActivityPub requires OrderedCollection to be presented in reverse chronological order

This only applies to ActivityPub-defined collections. In the AP spec section you referenced:

ActivityPub defines several collections … some of these [AP-defined] collections are specified to be of type OrderedCollection specifically, while others are permitted to be either a Collection or an OrderedCollection. An OrderedCollection MUST be presented consistently in reverse chronological order.

I agree with several of points made by @trwnh (e.g., related to query parameters). In addition, the claim that “reserved properties” like items is only controlled by the server is unclear. You seem to be saying that a authorized client can’t Update a collection’s items or Create a collection with an initial set/list of items. Is that true? If so, why?

Isn’t some of the information, like collection expansion during delivery, already covered by the AP specification (in more detail)?

I also agree that the title of the FEP is too general.

I count 17 prior FEPs with the word “collection” in the title. You must know this is not actually the first FEP about collections, so I’m baffled why you are making this claim.

8

Some statements in the FEP are purely informational. Others are recommendations, which I highlight using RFC-2119 key words. This is what makes it a “best” practices FEP (yes, “best” is mostly based on my personal opinion).

I discussed this FEP with other people while it was in pre-DRAFT stage. There were no strong objections.

I agree that given the context, the requirement sounds ambiguous. But I tend to read it as

Any OrderedCollection MUST be presented consistently in reverse chronological order.

Yes, it is true. Server is responsible for filtering and pagination, therefore it must control values of those reserved properties. Even if it can accept and store values provided by a client in Create, it will have to replace them each time the collection is rendered. I think that doesn’t make sense.

I would appreciate any pointers.

None of those other FEPs are about the behavior of collections in general.

9

I don’t think it’s a good idea to take a sentence like that out of context and draw conclusions from it.

There was never any intention for this requirement to apply to any other collections besides the ones defined in section 5 (“Collections”). – Evan Prodromou

Relaxing the requirement for OrderedCollection to always be reverse-chronological? · Issue #376 · w3c/activitypub · GitHub

I agree it doesn’t make sense. Why would that be required? Do you have an example? By “rendered”, do you mean serialized to JSON-LD? What’s the difference between a Create with [Item1, Item2] and a Create with no items followed by two Add activities for the items? (Other than the latter requiring more HTTP requests?)

7.1 Delivery
If a recipient is a Collection or OrderedCollection, then the server MUST dereference the collection (with the user’s credentials) and discover inboxes for each item in the collection. Servers MUST limit the number of layers of indirections through collections which will be performed, which MAY be one.

Assuming this is what you were describing, it’s more general than what you are recommending since it expands both actors and nested collections.