Re: Should the specs be forked and maintained elsewhere?

st 22. 3. 2023 v 17:36 odesílatel Pierre-Antoine Champin <> napsal:

> Dear all,
> chiming in as an ActivityPub enthusiast and as a member of the W3C team,
> I agree that regular meetings would be a good idea, but I don't think the
> specs necessarily need to be forked to be maintained, even though they're
> in TR status and don't see active updates.
> As a matter of fact, the W3C process has evolved in the past year, in
> order to allow a spec to be updated (under certain limits) without the
> existence of a working group:
> (see 2nd paragraph, "If there is no working group...)
> What it means is that you (the SocialCG) can definitely propose editorial
> changes to the existing specs, and reach out to a team member (as myself)
> to get the recommendation updated.
> This can only cover non-substansive changes, i.e. typos, clarifications...
> but nothing that would require implementers to change their code. In the
> case where technical issues have been detected, however, it is still
> possible to include notes about them, and pointers to proposed solutions
> (that would only be informative at this point, but at least would be
> visible to anyone reading the updated spec).
> The Community Group being the successor of the Working Group, I believe
> that we can arrange for providing permissions on the relevant github
> repositories ( and
> so that you can triage and clean up
> issues as you see fit.
> Finally, if the CG feels like a new version of ActivityPub is required
> (including substantive changes), we can also discuss the chartering of a
> new Working Group to take up this task.
> It's great to see this group active and motivated! If you start having
> regular meetings again, I can't commit to follow them all, but I'm more
> than happy to try and join every now and then, and discuss those
> opportunities with you.

An update.  This fruitful topic has sparked increased activity and a wide
range of discussions.

The CG is considering another attempt at resolving the issue backlog and
potentially enhancing documentation via a wiki or primer, possibly as a W3C
Note. Concurrently, the FEP process remains active, primarily propelled by
the activitypub social forum.

Meanwhile, individual projects continue their respective improvement plans.
However, outreach to other initiatives may require further work. As you may
be aware, Solid is working on a WG Charter, and I personally hope to see
interoperability efforts there. There have emerged new and existing
protocols in the social web, such as nostr and atp, which would imho
benefit from increased outreach. Despite its current focus on AS/AP, there
is significant room for interoperability enhancement, especially given the
vast majority of the social web operating outside of the fediverse.

There are also numerous original WG initiatives that were deferred,
including the concept of a social graph and the straightforward action of
adding a friend. These omissions might appear unusual to an external
observer of a social web.

I believe that the innovation from the AS/AP RECs has largely transitioned
to the FLOSS domain. Unless W3C can offer some form of concession regarding
participation in a future WG, it seems likely that new changes will
gravitate towards FLOSS, and errata towards the CG.

However, given the rapid pace of technological change, we should remain
open to potential game-changing developments over the next year.

>   pa
>  Very few suggestions have
> been made about actual practical improvements to the spec—the vast, vast
> majority of open Github issues are usage questions that have been
> addressed. Regarding the FEP process, while it has generated a lot of
> productive discussion, it's less clear to me that it's been effective at
> generating multi-implementor consensus, which is in my mind the most
> important goal of a specification workgroup. I'm not aware of any currently
> active FEP that got discussion from multiple implementers and then went on
> to have multiple interoperable implementations.
> Previously, the Community Group spent a lot of effort discussing and
> working on "outreach"-focused initiatives that didn't move the ball forward
> on technical integration. I think that's also a serious mistake that we
> made in the past that we should learn from going forward. To my mind, what
> we need to call a meeting is a concrete agenda of technical topics and an
> actionable plan on *what* implementers or organizations are going to put in
> the work to explore them or move them forward. We can't move forward as a
> specification body without implementer buy-in and consensus.
> I'm aware of implementer interest from Mastodon relevant to a few of the
> topics I can see discussing: Reply approval, Groups. What other specific
> technical topics do people feel like should end up on the agenda?
> On Tue, Mar 21, 2023 at 6:56 PM Evan Prodromou < <>> wrote:
> > Regular meetings would be great.
> >
> > On Mar 21, 2023, at 5:25 PM, Bob Wyman < <>> wrote:
> >
> > I've seen several suggestions that, due to inactivity in this group, it
> > would make sense to fork either or both of the ActivityStreams and
> > ActivityPub specs with the intent to develop them further and maintain them
> > elsewhere. The most recent suggestion
> > <>
> > that I've seen was made in one of the forums on the ActivityRocks site.
> >
> > My personal feeling is that the proper forum for maintenance of these W3C
> > specs is within this community. Am I correct? However, I sympathize with
> > others who feel that maintenance is simply not happening. There are now 55
> > open issues <> on ActivityPub's
> > GitHub repository and 58 open issues
> > <> on the ActivityStreams
> > repository. Who is responsible for addressing those issues, closing them,
> > or taking action on them? What is the process by which these decisions will
> > be made?
> >
> > Other W3C groups that I've worked with have regular Zoom or Jitsi meetings
> > to discuss issues. Why doesn't this group ever have such meetings?
> >
> > bob wyman
> >
> >
> >

Received on Monday, 15 May 2023 09:58:32 UTC