Re: A charter for the Social Web Working Group

I agree with going forward with the WG proposal.  I think that having a WG
and moving docs to Recommendation also has an undefinable but important PR
and moral suasion effect.  It's harder for likely implementers to argue
unawareness or incompleteness or simply remain on the sidelines without
justification.

Lisa

On Fri, Sep 6, 2024 at 6: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.
>
>
>