Re: A charter for the Social Web Working Group

Evan, thanks for kicking off the conversation!

(And, Pierre-Antoine, definitely appreciate the staff perspective.)

I like the idea of a carefully limited scope charter AP/AS2 1.1 Working
Group. It'll give us a chance to pay down some accumulated spec tech debt,
so to speak.
And just clarify intent, incorporate errata, yeah.

I agree with P.A. that adding coordination with the CG to the charter from
the start is a great idea (and yeah, Immersive Web sets a good example).

An HTTPSig document (Report or Recommendation) seems like it might be
helpful to people too.




On Fri, Sep 6, 2024 at 9:19 AM Evan Prodromou <evan@prodromou.name> wrote:

> One benefit of going from a report to a recommendation is that we could
> switch from primarily descriptive to primarily prescriptive language. We
> can also break new ground.
>
> I think the most acute need is to have an upgrade path for the HTTP
> Message Signatures and Web Security combo. Those specs have moved forward,
> and a W3C recommendation for the integration of the most up to date
> versions with AP would probably help get the fediverse to shift over.
>
> I think AP + WF is less urgent, although there are probably some
> guidelines and future work that could improve the flow.
>
> Again, with an emphasis on smooth, backwards-compatible upgrade paths.
>
> Evan
>
> On Sep 5, 2024 22:43, a <a@trwnh.com> wrote:
>
> > 1. Apply errata to ActivityPub and Activity Streams 2.0 recommendations.
> >
> > 2. Make backwards-compatible, clarifying text for ActivityPub and Activity
> Streams 2.0. Not new features or functionality, but clearer explanations
> for some of the terse and/or vague language in both sets of specs.
>
> This seems fine to me, assuming that we have a clear demarcation or litmus
> test for what is allowed and what is not. For example, consider cases where
> the “author’s intent” was not sufficiently conveyed, but clarifying the
> intent leads the stated requirements to change even slightly. How should
> the clarification be made?
>
> I think that any case where the stated requirements don't change at all is
> fair game -- adding non-normative notes about how certain functionality
> works or the implications of a certain requirement is fine. But anything
> touching a requirement's normative language should probably be brought to
> the CG for discussion.
>
> A more specific example is the current ActivityPub errata --
> https://www.w3.org/wiki/ActivityPub_errata has a list of them. The one
> about removing `preferredUsername` from the non-normative note about
> natural language support is uncontroversial, but more importantly, it
> doesn't touch any normative language. But the others *do* touch normative
> language, and are the kinds of changes I think shouldn't be made without
> feedback from the CG. You mention below that:
>
> > I think this WG could work with a limited membership -- ideally just
> the editors of each document -- and work with consensus from this CG. So,
> no independent meetings, decisions, etc. 🤞🏼
>
> Obviously the CG shouldn't need to decide every single thing, and the WG
> should have the authority to correct typos for example. But "consensus" and
> "decisions" need to be carefully scoped, because they might be useful in
> certain cases.
>
> Aside from that,
>
> > 3. Refine the recent CG report for ActivityPub + Webfinger into a
> recommendation.
> >
> > 4. Refine the recent CG report for ActivityPub + HTTP Signature into a
> recommendation, including an upgrade to RFC 9421, with backwards
> compatibility as a fallback.
> >
> > 5. As other new CG reports, like E2EE and LOLA, are published and
> implemented, refine the reports into recommendations.
>
> I'm a little wary of what this might entail -- what does a
> "recommendation" entail that a "report" doesn't? Or put another way, what
> is "insufficient" about a report that justifies the need for a
> recommendation? It seems to me like the current reports are fine as reports
> and I'm not sure what promoting them to a recommendation is supposed to
> accomplish.
>
>
>