A New Social Web Working Group at the W3C

One of the outcomes of the W3C worldwide technical conference, TPAC, this year, was a suggestion from W3C staff that we consider forming a new Social Web Working Group (WG) for revising the ActivityPub and Activity Streams 2.0 standards. There has been some controversy about this idea, which I wanted to address with a blog post.

Why a working group?

First, there is currently a group at the W3C for maintaining these two standards. It’s called the SocialCG or “Social Community Group”. It meets regularly, maintains a mailing list and some GitHub repos, and takes on responsibility for interesting developments in the fediverse like standardised testing and data portability.

So, why would we need a new group? The main reason is that official technical recommendations published at the W3C have to be edited by a working group. This is a different structure than a community group, and it has specific stages in its work process that are different than a community group’s.

Do we need new versions of the ActivityPub and Activity Streams 2.0 standards? Yes and no. No, because they’re already full recommendations of the W3C. And no, because they have a really robust extension mechanism built in, so you can make different kinds of social applications with AP and AS2 as a base. And, no, because AP and AS2 only provide one part of the social web stack; different parts of the stack, like shared blocklists, probably should be defined in different venues, or at least with different specs.

But, yes, because it would be nice to have slightly clearer and easier-to-use specifications. We have some editorial errors in the documents, and although we maintain errata documents separately, it would be nice to just fix those changes in the documents themselves.

And yes, because there are actually some parts of the documents that are unclear as to what the rules are. For example, the followers list for an actor in AP is defined as the collection of people who follow that actor. All well and good! But the question has come up, can there be duplicates on that list? What would it mean if there were? Specifying that the entries have to be unique adds a new requirement to the specification, even if every implementation that exists already does it that way, which is what we call a normative change in the standardization world. We’d need a working group to make that change.

Why not a working group?

There has been some concern on the fediverse about starting a new working group for ActivityPub and Activity Streams 2.0. The main concern has been participation. For the W3C, joining a Community Group like our SocialCG only takes a quick online application — you have to agree that your contributions to the group will be freely licensed, not subject to patents, that kind of thing. But other than that, anyone can join up and be part of the conversation.

A working group, on the other hand, has stricter requirements. Any W3C member organization can nominate representatives to join the working group. Anyone who isn’t a representative of a member organization needs to be approved by the chairperson of the working group as an “invited expert”.

So, the concern is that this restricted level of participation will skew the working group’s activity towards the needs of W3C members, to the detriment of the wider community. Because many of the members are commercial software organisations, and some of them are commercial social networks, there’s a concern that a members-focused WG would do harm to the fediverse by making a bad spec.

I think this is a valid concern, and it’s worth considering. However, my experience with the W3C in work on social standards has been that “invited experts” or “IEs” do a lot of the work, and represent the actual developer community pretty well. For the original versions of Activity Streams 2.0, for example, 50% of the editor team were IEs (me). For ActivityPub, 4 of the 5 authors were IEs. One of the three chairs (also me) was an IE.

I’d also note that the SocialCG is open to anyone, including W3C members, and including representatives of commercial social networks. So far, that hasn’t been a problem, and the consensus process has meant that we don’t have a big threat to ActivityPub so far.

Keeping the WG Participative

So, how do we keep the upcoming working group participative and responsive to users and the developer community? I have a few suggestions for making this work.

• Keep the working group focused only on the work that the community group can’t do. This means, the WG should only focus on backwards-compatible, iterative updates to AP and AS2, with an emphasis on existing practice. Developing new technologies and new standards should be done in the more participative and active CG.
• Ask potential WG members to also join the CG. The WG should be a subset of the CG, not a completely separate group.
• Editors and chairs that are well known to the community. I’ve been doing a lot of editorial work for AS2 and AP this year, and I’d happily continue in that within a WG. Hopefully, whoever takes chairperson roles would be someone known in the fediverse.
• Keep the working group minimal. The working group could probably just be a chair and one or more editors. Other participation could happen in the CG.
• Use the W3C’s process to keep things transparent and participative. The W3C process is designed to be transparent to outside review and feedback (see below); it doesn’t (usually) happen behind closed doors. Members of the CG and the general fediverse should be able to watch, and comment on, the development of the revised specifications.

Community Input on Working Group tasks

So, what review and input does the community have on the Working Group tasks? Quite a lot, actually!

• Issues on existing documents. Anyone can submit a GitHub issue for the existing published documents for AS2 and AP. These get reviewed by the CG (usually by me!), and they can turn into errata for the existing docs. They also will provide important sources for work to do for the Working Group.
• Reviewing minutes. W3C groups publish their meeting minutes for review, including decisions made during that meeting.
• Reviewing working drafts. Working groups publish working drafts of their recommendations on a regular basis. These are supposed to be widely reviewed, inside and outside the W3C. As with the existing versions, anyone can open a GitHub issue on the working draft documents (and later drafts, too).
• Implementing candidate and proposed recommendations. As the specifications develop, they go through stages: candidate recommendation, proposed recommendation, and then final recommendation. These get more and more stable, so that developers can depend on implementing them. This is a great time for the broader community to look over what will likely become the new standard, file GitHub issues, or otherwise provide feedback.
• Implementing, or not, the final recommendation. Standards aren’t software; nobody can push a new version to your computer without your permission. Developers will have to decide if the final recommendation makes sense technically and for their users’ needs. Nobody can make them implement anti-features that hurt their users.

It would be hard to inject bad ideas into ActivityPub through trickery. It’s a pretty transparent protocol, and there aren’t a lot of places to hide backdoors or sneaky tricks. Even cursory review of the spec by non-technologist can give a good idea of what’s actually going on. But having smart and privacy-aware fediverse reviewers can help avoid any problems introduced by accident.

What next?

We’ll be having further discussions about chartering a working group in the SocialCG mailing list and in-person meetings over the coming weeks. We don’t actually get the final say; but we can suggest a possible charter to the W3C staff, for member approval.

As you can tell, I’m in favour of chartering a WG. I think it would be great to have clearer, cleaner documents for developers to look at when trying out ActivityPub. It will mean we have more and better implementations with better compliance and interoperability. If we keep focused and keep our scope tight, I think we can make changes with low risk.