Resolved errata makes it possible to be fully compliant with "Federated Server" profile by doing nothing

[trwnh]

https://github.com/swicg/meetings/tree/main/2023-11-17#ap-issue-297

https://www.w3.org/wiki/ActivityPub_errata#Allow_servers_to_filter_delivery_when_activities_are_received_in_the_outbox

per CG resolution, the requirements ("MUST") to process outbox delivery and deliver to inboxes were both changed to mere recommendations ("SHOULD"). this was done to allow for spam filtering and blocking, but:

• you can include provisions for filtering and blocking without removing the requirement, by using language such as "you MUST deliver although you MAY filter" or "you MUST deliver unless the activity is not allowed for some implementation reason, which MAY include spam filtering or blocks"
• removing these two requirements leaves the entire S2S section (section 7) with zero requirements for delivery. the only requirement remaining in section 7 would be to HTTP GET with Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams", but servers do not generally have to GET anything (as this is usually the client's responsibility in most cases).

put simply, it is possible to be fully compliant with the "ActivityPub conformant Federated Server" profile by default, since there are no hard requirements.

proposed solution

revert this errata, change the two SHOULDs back to MUSTs (while maintaining the "exception" for filtering and blocking)

[TallTed]

mere recommendations ("SHOULD")

"mere"?

   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Granted, these were not reduced to "mere" suggestions (which I would consider "MAY" to mean), but understanding and carefully weighing implications of not doing as one SHOULD is no small requirement. I think it is important to be cognizant of what SHOULD is really meant to mean.

Changing (the original) from simply "MUST" to "MUST but MAY" is probably better than sticking with the current "SHOULD".

[trwnh]

sorry for my word choice but the reality is that a recommendation is a recommendation and it is possible to implement all requirements without ever encountering a recommendation. which is to say, requirements are the foundation on which recommendations are built. by “mere” i meant the denotation of “no more than what is required”, not the connotation of “insignificant”.

[TallTed]

The biggest reason to keep "MUST but MAY", is that "SHOULD" is too-often interpreted by implementers as meaning "MAY".

[evanp]

The group has agreed to use this text. I think the difference between a "SHOULD" and a "MUST" with unenumerated exceptions is so incredibly fine that I find it hard to imagine that it's worth taking the time of the group to re-consider it. But I hope that if there is some conversation it happens on this issue.

[trwnh]

There's a positioning / "setting expectations" argument here, which is that anyone scanning the spec for MUSTs is going to find basically nothing in S2S, aside from a handful of things that don't apply if you don't deliver.

I know that "compliance" is taken pretty loosely in practice, and as stated in issue triage "you don't get a sticker for it" (although I would argue that this is the role of a functioning test suite!), but the SHOULDs give too much wiggle room, in a way that a qualified MUST does not. The difference for clients is the difference between "I don't know what's going to happen" versus "I can generally expect this to happen".

Looking at other specifications in this regard:

• SMTP Section 2.1 says that servers MUST either attempt delivery or otherwise report a failure. Compared to AP, we are not required to report failure; silent dropping of activities is allowed.
• XMPP-IM Section 8 uses MUST throughout its requirements in subsections, but comes with this disclaimer in Section 8.1:

Security Warning: All of the stanza processing rules described below are defined with the understanding that they will be applied subject to enforcement of relevant privacy and security policies, such as those deployed by means of [XEP-0016] or [XEP-0191]. The conformance language (MUST, SHOULD, etc.) in the following sections is not meant to override any such local service policies.

In other words, instead of unenumerated exceptions, there could be a single exception: "the server MUST deliver unless the activity is considered undeliverable according to server policy; this server policy SHOULD include security considerations such as those laid out in Appendix B".

---

There's also one other consideration here, which is that 6.11 references 7.1.1 so a double-SHOULD is unnecessary. I think 6.11 should say "MUST deliver according to 7.1.1" to at least close the gap between the two sections. Otherwise, you leave open the possibility that the outbox endpoint will deliver according to some other completely different requirements not described in the ActivityPub spec at all... and then clients will have no idea if/when an as:outbox will behave according to the AP spec or if it will instead behave according to some other spec. (Arguably, we already have this problem, because it is already unclear whether any given as:outbox implements C2S, S2S, both, or none.)

[TallTed]

there could be a single exception: "the server MUST deliver unless the activity is considered undeliverable according to server policy...

I like that. I'd like it better if there were some defined way to discover the content of such a policy, even if privacy preservation considerations mean that some elements of a local policy are obscured (e.g., I can't discover that posts from me are blackholed, but I can discover that posts from some list of users are).