Re: [CfC] Erratum for ActivityPub on the definition of `inbox` the property

Hi Evan,

Thank you for initiating the call for consensus as outlined in our charter's decision policy. I'm supportive of maintaining an erratum for this ambiguous `outbox` and `inbox` definitions to clarify that the original consensus was to allow the values of inbox and outbox to include a URI reference as a JSON string and/or an embedded JSON Object of type Collection.

However, I need to raise a concern with the current proposal. I'm not able to support the CFC because it doesn't fulfill the W3C Process requirement to describe the error separately from the proposed correction, and the omission of an error description prevents me from understanding the intention of your proposal and CFC. Additionally, it's unclear whether your suggested text is a possible solution or a candidate correction - I'm not comfortable consenting to a candidate correction until we establish consensus (or at least a proposal) on the erratum error itself. With that caveat that there is no erratum description, so I may be misunderstanding, I also share some concerns and ideas below about the exact candidate correction you did include.

Per W3C Process S6.2.4, erratum must have both the error description and affected spec text identified. The error description is particularly valuable for implementors e.g. testers - it provides context about why we consider this an error and helps avoid similar issues in the future, building institutional knowledge beyond just providing corrections. But I don’t see an error description in your proposal, only a possible amendment to the spec itself.

Could you please update this proposal to satisfy the W3C Process erratum requirements (error description that explains the rationale for the erratum)? This separation helps ensure transparency and due process in our open standards <https://www.w3.org/2005/09/dd-osd.html> by first establishing what the error is, then creating space for community input on possible solutions.

I also wonder if we should solicited input from the author of issue 289 before CFCing any candidate correction. Your proposal highlights that issue as context for the erratum, so I want to make sure I understand whether the goal of your proposed erratum is to address the error reported by author of issue 289, or is it to address some other error inspired by it? This also affects how to assess possible solutions to the erratum, i.e. whether the following suggestion visavis issue 289 is germane to your proposal

I think your proposed amendment may work, but there also may be room for improvement. For example, issue 289 seems to focus on the OP being unsure whether `inbox` and `outbox` properties both allow values that are strings (interpreted as uri reference to the collection) AND allow values that are embedded JSON objects representing the collection. Your proposal to change the definition of inbox to this new text that doesn't mention URI References at all does not make it more obvious to me that inbox MAY be a URI reference. Without more context, it actually reads to me like it's trying to say the inbox will always be an embedded object and not a uri reference, which I don't think is your intention? However, I propose we focus on publishing the erratum with a description of the error before we can best decide how to craft text to address any particular erratum.

Lastly, would you also please clarify whether your CFC is for consensus on an erratum with candidate correction, or an erratum without a candidate correction but with a description of a possible solution? See example erratum in WCAG 2.0 Errata <https://www.w3.org/WAI/WCAG20/errata/>. Note that these include more explanation about the original text, why it was an error, etc., informing but not constraining possible solutions and usually not including candidate corrections.

Evan, is the you’re proposing is intended to be in line with this?:
> the values of inbox and outbox properties may include a URI reference as a JSON string and/or an embedded JSON Object

I think so, right? If I’m understanding correctly, I suggest we either:
1. Don’t propose any candidate corrections right now. Agree to describe an erratum about ambiguity in the allowed values of both `inbox` and `outbox` due to their differing definitions
2. Do #1 and then agree on a candidate correction that updates both inbox and outbox definitions to both properties to clarify their values may include objects (e.g. Collections) or strings (i.e. URI References).

In summary, my feedback is:
* I have concern this proposed erratum does not describe the error in the text or explain it, and only includes a candidate description.
* It’s not clear whether the CFC is for an erratum that includes a candidate correction, or one that does not include a candidate correction, but describes a possible solution to the (as yet described) erratum.
* the proposed spec text does not address the original issues’ concern about whether inbox and outbox allow uri references, because the proposed spec text could reasonably be interpreted to not allow uri references as values.
  * instead spec text could update both definitions with clearer definitions about allowed values. My suggestion is that we postpone discussion of possible solutions until the required elements of the erratum have been articulated, which will inform the assessment of any possible solutions such as the one in this proposal.
* if the goal of the proposed amendment is to address issue 289, let’s solicit feedback on the erratum (not necessarily any candidate solution) from the author of issue 289, if/when an erratum description is proposed. If the candidate correction is meant to address other than issue 289 or in addition to, please include that in the erratum description.

Thanks again for the CFC. I think we can definitely get consensus on an erratum about issue 289 and the different definitions between inbox/outbox.
Please consider amending it to describe the error in the spec and related rationale so the erratum can conform to w3c process.

> On May 23, 2025, at 9:32 AM, Evan Prodromou <evan@prodromou.name> wrote:
> 
> Issue #289 of the ActivityPub GitHub repository notes the inexact and asymmetrical language used for defining the `inbox` and `outbox` collections:
> 
> https://github.com/w3c/activitypub/issues/289
> To resolve this, there is a proposed erratum for Section 4.1 to bring the definition of the `inbox` property closer to that of the `outbox` property:
>     • In section 4.1 "Actor objects", the definition of "inbox" should read, "An OrderedCollection comprised of all the messages received by the actor; see 5.2 Inbox."
> We usually handle approval of errata in our synchronous meetings, which takes a lot of time and focus away from other topics that require more immediate presence and conversation. In speaking with the chairs and others in the issue triage meeting, we think that handling this task through the CFC decision-making process will be more efficient.
> So, I am seeking consensus to add this erratum to our errata page for ActivityPub. Please reply either to the GitHub issue or here on the mailing within 14 days of this message.
> Evan
>

Received on Friday, 6 June 2025 20:12:50 UTC