Re: AS2/AP tasks for a chartered social web working group

I am in full agreement with regard to maintaining existing specifications being a primary focus of the group. To be clear, this would be:


1.  ActivityPub
2.  ActivityStreams
3.  Linked Data Notifications
4.  Micropub
5.  Webmention
6.  WebSub


W3C Notes, such as jf2, should also be included.

> Here would be the two main things I think we could do with a WG:

-   Incorporate editorial fixes from the ERRATA, like fixing incorrect examples. Many people read the recs and never see the errata, so getting those documents updated would really help them a lot. We might b

-   Eliminate some of our "AirBud" issues, where the documents refer to standard practices in social networking, but we did not specify clearly in the specification itself. For example: the collection of followers should be unique. An actor should have only one followers collection. These would need to be carefully done to avoid making changes that aren't backwards compatible, but I think for a lot of them there's clear consensus in the implementations, and we'd just need to document them.


We should discuss how many people would constitute the WG to get a better sense of the size of our scope.

There was early experimentation in the IndieWeb community with Microsub (https://indieweb.org/microsub), a draft specification for feed readers. Microsub has several integration points with Micropub and is a way to progress from the one-way paradigm associated with RSS readers to a two-way, social reader system. With Micropub, Webmention, and Microsub, you can read content, post likes/comments/replies to your website, and send those replies. The draft Microsub specification has at least two close to interoperable implementations of clients and servers, meeting the bar set by the former Social Web WG on interoperability prerequisites for a specification to be considered for Standards Track. I would be interested in working on this if there is continued interest in advancing Microsub at this time.
Another interesting candidate is the "web action" (https://indieweb.org/webactions), a standard way of representing social actions on the web (i.e. likes), that would integrate with the Micropub specification to some extent. This concept, too, has several implementations in the wild, and I have had discussions about what could be done to expand on this concept.

Whether including the reservation that we want to write new standards is prudent given the amount of work that maintaining existing standards would involve is a question for us to consider, however. The above notes are suggestions on which I invite more discussion.

> I think we could help the ActivityPub implementer community with new versions of the specs.

+1 on this. A WG should work closely with implementers, documenting feedback and using that to inform new specification additions and amendments.

James


------- Original Message -------
On Friday, September 15th, 2023 at 15:52, Evan Prodromou <evan@prodromou.name> wrote:


> One of the topics that came up at last week’s TPAC was the possibility of having a new iteration of the Social Web Working Group.
> For those unfamiliar with the structure of the W3C: working groups are necessary for making normative versions of standards documents. Many areas of interest at W3C have standing working groups that just stay around indefinitely working on particular topics. The Social Web Working Group, by comparison, had 3 deliverables (social data standard, social API, social federation protocol) and a fixed time frame.
> 

> In order to create this working group, the W3C would have to make a list of tasks for the group, and would need to put that list in front of the W3C members. Then, the members vote on it, and if they agree, a new working group would be born.
> 

> W3C staff asked if we, the SocialCG, wanted to suggest a list of tasks for that charter. They don’t have to use that list verbatim, but my guess is that they wouldn’t edit it much.
> 

> I’d like to suggest that we keep the scope of the WG limited to maintenance of the existing recommendations. Other work that we’ve been discussing, like the extension policy, testing, data portability, and other topics should stay as part of the CG.
> 

> I also think we could and should commit to a) strict backwards compatibility and b) hewing closely to current practices. I would call any new specs “1.1” or “2.1” to show that these are iterative, compatible changes.
> 

> Here would be the two main things I think we could do with a WG:
> 

> 

> -   Incorporate editorial fixes from the ERRATA, like fixing incorrect examples. Many people read the recs and never see the errata, so getting those documents updated would really help them a lot. We might b
> 

> -   Eliminate some of our "AirBud" issues, where the documents refer to standard practices in social networking, but we did not specify clearly in the specification itself. For example: the collection of followers should be unique. An actor should have only one followers collection. These would need to be carefully done to avoid making changes that aren't backwards compatible, but I think for a lot of them there's clear consensus in the implementations, and we'd just need to document them.
> 

> 

> Here are a couple of things I think we could do that would be a stretch:
> 

> 

> -   An OAuth 2.0 profile for ActivityPub API. We left authentication out of the original spec, and I think it’s made it harder for implementers. That said, I think this should probably be a FEP first before being part of the spec.
> 

> -   Document the use of HTTP Signatures. This might be the only place I’d suggest an upgrade; the AP world mostly uses an old draft of HTTP Signatures that is not compatible with the current versions. It would be nice to figure out an upgrade path for this and make it easier for developers to move forward. 
> 

> 

> We’d need to make sure that it was clear that any auth stuff is only a mapping, and that you could use other auth types if you want and can get interoperability.
> 

> I think we could help the ActivityPub implementer community with new versions of the specs.
> 

> I hope this helps with the discussion.
> 

> Evan