Re: My priorities for revising AP and AS2

To the first and last bullets, some non-social-web AS2 based specs with a
lot of implementations to please not break backwards compatibility with:

The closest case is:
* https://iiif.io/api/discovery/1.0/

It uses AS2 pretty much verbatim to create a feed of changed resources for
synchronization.
It has all but completely replaced ResourceSync (NISO Z39.99):
    https://www.niso.org/publications/z3999-2017-resourcesync

And some other related specs that use, especially, Collections:
* https://www.w3.org/TR/annotation-model/#collections
* https://iiif.io/api/presentation/3.0/#51-collection
* https://iiif.io/api/search/2.0/
* https://linked.art/api/1.0/search/

Hope that helps,

Rob


On Wed, Jan 21, 2026 at 1:39 PM Evan Prodromou <
evanp@socialwebfoundation.org> wrote:

> One question that came up on the Social Web Community Group is what
> exactly this WG should do with the ActivityPub and Activity Streams
> specifications. I don't think that's up to me, but I wanted to share some
> priorities I have.
>
> - Backwards compatibility. Implementations of .1 version should
> interoperate with implementations of .0 versions.
> - Clarity. Some of the sections of AP and AS2 are hard to read. It would
> be nice to focus on what's important in the section. We also use some
> vague, undefined terms.
> - Explicitness. Some behaviours on the ActivityPub network, such as
> maintaining the `replies` collection, are not described explicitly in any
> of the documents.
> - Specificity. We could really help implementers by getting more specific
> on how to apply optional properties to AS2 objects.
> - Fallback representations. If a consumer receives an activity it doesn't
> recognize, how can it represent the activity to a user? There
> are properties specifically to help with this.
> - Authorization model. We should document the (admittedly loose)
> authorization model for reading, writing, and interacting with ActivityPub
> objects.
> - Connection with other standards. Webfinger, HTTP Signature, and OAuth
> are all pretty instrumental to AP implementations. We should at least
> mention them in the spec, and possibly include profiles for their use.
> - Extensibility to new application areas. We should make it clearer how to
> use the AS2 and AP building blocks to create new kinds of applications on
> top of the social API and federation protocol.
>
> Here are some important things I'd like to avoid:
>
> - Required features that are too resource-intensive for small servers,
> such as handling terabytes of data.
> - Required features that are too inefficient to implement at large scale.
> - Required features that are too complex for small development teams to
> implement.
> - Restrictions that block innovation and experimentation.
> - Models that don't recognize the diversity of humans on the network, and
> in particular that preclude different privacy needs or relationship types.
>
> I hope that's helpful and informs some of our conversation.
>
> Evan
>
>

-- 
Rob Sanderson
Senior Director for Digital Cultural Heritage
Yale University