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

My objection isn't about formality for its own sake - it's about transparency and actually resolving the ambiguity.

The core issue: The original problem in #289 is that the outbox definition can be misinterpreted as forbidding URI references. The proposed CFC just copies that same ambiguous text structure to inbox without resolving the issue that is was misinterpreted as ‘heavily implying’ outbox must not be a string.

What's missing: Any erratum should include:
    • Error description - explaining that both inbox and outbox allow URI references OR objects
    • Explicit clarification - refuting the interpretation that these must be embedded objects
    • Better wording - not just copying problematic text

The one-sentence CFC doesn't address why @cjslep misinterpreted the spec in the first place, so it risks perpetuating the same confusion.

I've proposed text at https://github.com/w3c/activitypub/issues/289#issuecomment-2954178865 that includes an error description and clarification. I solicited input from the OP of that issue and Evan too.

@a - please confirm I haven't misrepresented your position that outbox values can be URI references, and I’d love any input on the error description I suggested to address cjslep’s issue.

Can we agree on the error description first, then work out the candidate correction? I think we have consensus on the interpretation - we just need to document it clearly so future readers won't make the same mistake. It would also inform ideation on candidate corrections to address the agreed-upon error description.

Hoping to take this to the issue tracker now that it’s fully clear that’s what the goal of the proposed erratum is.
@Evan thanks for clarifying that, being flexible on the exact approach, and being willing to include an error description that we can solicit input from the issue author on it. Tagged you on the gh issue.

> On Jun 7, 2025, at 2:52 PM, a <a@trwnh.com> wrote:
> 
> Hi Ben,
> 
> I'm a little confused at what the specific objection is here. It seems like the errata was proposed with insufficient formality and rigour?
> 
> At the very least, from the perspective of the issue filed and the discussion within, the errata seems to address the issue: https://github.com/w3c/activitypub/issues/289#issue-289370075
> 
> > Please either omit "reference" when describing the inbox, permitting implementors to inline the OrderedCollections or not, or standardize "reference" to mean inlining the actual ActivityStream data is not permitted.
> 
> Omitting "reference" addresses the issue. The resolution to the issue is to remove the word "reference" which is currently present in the description for `inbox` but not for `outbox`. There isn't a good reason or justification to prevent embedded representations for either `inbox` or for both `inbox`/`outbox`, so the alternative resolution of adding "reference" to the description of `outbox` isn't a good idea. Nor would it make sense to say that `inbox` is always a reference while `outbox` might be either.
> 
> >  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 [the] intention? [...] the text [Evan] proposed is likely to be interpreted like these values may not include uri references, which generally would make it a normative change and not an errata
> 
> I don't think this is true. Stating that it is a "reference" is likely to be misleading, but the absence of this word does not imply that a "reference" is disallowed.
> 
> If you believe that removing the word "reference" is insufficient to resolve the issue (despite the issue proposing exactly this as a solution), then let's work on a better resolution. Maybe we can come up with better wording? Possibly it could be done as a separate errata.
> 
> ---
> 
> Finally, I want to address the following refrain:
> 
> >  I also wonder if we should solicited input from the author of issue 289 before CFCing any candidate correction [...] let’s solicit feedback on the erratum (not necessarily any candidate solution) from the author of issue 289
> 
> The author of the issue has been inactive on GitHub, the fediverse, etc. for over 3 years now, and for all we know, they might well be dead. Addressing the issue would ideally take the issue author's input into account, but this cannot be a strict requirement or the issue will never get resolved. I think the 2 week / 14 day CfC period generally suffices since it in theory includes the issue author.

Received on Sunday, 8 June 2025 17:44:54 UTC