That's thoughtful, thanks Tantek. I checked with @rhiaro, and we believe that maintenance on LDN can continue within its 'home' in this Social Web Maintenance WG charter, as it was developed in the Social Web WG and is also a normative reference in ActivityPub. As far as we know LWS is not expecting to have LDN as a deliverable.

Looks good, thanks for your work on this!

I'm at TPAC and can elaborate later, but based on experience in the SocialWG from 2013-2017, I strongly oppose a wide-scope SocialWG like this.

Instead, I encourage a focused ActivityPub Maintenance WG #2.

That wouldn't preclude other WGs to maintain the other SocialWG TRs that don't interoperate with ActivityPub, and it would allow appropriately relevant chairs/policies/participants/timelines/staff-contacts in each of the protocol-specific WGs.

For those of us in the last SocialWG that were working toward ActivityStreams and ActivityPub standardization and adoption (by digital publishing customers with quite a bit of money on the line), it was a big distraction to be sharing meeting time (almost always more than half the time in each meeting) with other work items and ecosystems that have different goals, use cases, opinions, working styles, meeting times preferences, and technical dependencies/architectures. That big-scope WG had to have its timeline extended several times due to competing focus/time for non-interoperating work items, and I don't want that to happen again with ActivityPub Maintenance.

With that said, I do like this repo's approach of being many 'potential-charters', so I don't have concerns about this being merged as long as some version of #2 is as well. I'm in favor of developing many potential charters for many groups. Thanks for setting this up and making the PR @dmitrizagidulin

Thank you for putting this together, @dmitrizagidulin. The document looks good to me thus far.

This may have already been discussed, but do we have a sufficient number of people interested in working on the scope defined in this proposed charter? I worry about defining a scope without +1s from the people who worked on the spec originally. We started with this on the W3C wiki, but the last discussion was several months ago: https://www.w3.org/wiki/SocialCG/WG_Charter_Discussion#Deliverables.

I am in support of having two WGs so that everyone can focus on the streams of work most relevant to them, per @gobengo's comment above.

The downside of multiple WGs is that there would be less opportunity to share ideas between the different specs. Feels like the social web will be worse off if people are just working in their own silos. I have implementations of every spec in this list, except Linked Data Notifications.

I'm particularly interested in the evolution of client APIs right now. We have ActivityStreams C2S on one side, and we have Micropub/Microsub on the other side. C2S is still not very widely deployed, so there is an opportunity to shape its future, maybe.

I worry about defining a scope without +1s from the people who worked on the spec originally.

Well, I'm not sure what value of "the people who worked on the spec originally" is useful here-- christine is not planning on contributing actively to a WG of any particular scope but had this to say, bengo did, evan did as well. dmitri did but i think he can't vote because he's chair? we could ping @erincandescent maybe?

i would actually defer not to who originally worked on the spec but who is going to contribute to it substantially if normative work spins up. with maybe a 1.5X vote-weight for people who are recidivist contributors 😏

Feels like the social web will be worse off if people are just working in their own silos.

Well, no one's talking about splitting up (or even de-emphasizing) the CG, and I think the CG still has a lot of ways to influence multiple WGs and throw input documents over the fence to them. The The distinction is more administrative than anything else-- what gets talked about in focused, "zoomed-in" meetings about each protocol, versus the cross-pollination that still happens in the non-normative CG (I am assuming everyone seriously active in the WGs would also stay active in the CG work items that overlap).

The downside of multiple WGs is that there would be less opportunity to share ideas between the different specs. Feels like the social web will be worse off if people are just working in their own silos.

@manton Are you sure there would be less opportunity to share ideas? If anything, in my view, there would be more opportunities and more time to share and develop ideas deep into the concrete edge cases of specific protocol interactions in focused topical meetings. It's great to share ideas between different specs, but IMO that is a different type of collaboration than the kind of 'spec issue triage' that often happens in a WG or other later-stage standards development. And it can be disorienting and subject to filibuster to share issue triage meeting time across too many specs like we tried to do in SocialWG 1.0. As I understand it since 2018, spec issue triage has not happened in one big group/meeting for all SocialWG-delivered specs , but instead in a network of groups/meetings each focused on particular work items or spec families, which is what I'm proposing continue in any future WG.

Nothing would/does prevent folks from participating in multiple WGs. Well, except the inherently exclusionary rules of all WGs at W3C. For ideas that want to be shared as broadly as possible, often because they're still being incubated, well that can still happen in the Social Web Incubator Community Group, for which there is an initial charter proposal at #1

Multiple WGs allows for choice: the choice for folks (and companies) to invest their time/energy only where it will help with their goals (and with maintained-spec-appropriate/aligned chairs overseen by W3C staff) and also the choice to participate in several WGs all at once. Having only one big WG doesn't allow the former choice.

I have implementations of every spec in this list, except Linked Data Notifications... I'm particularly interested in the evolution of client APIs right now. We have ActivityStreams C2S on one side, and we have Micropub/Microsub on the other side.

Yes, there are sides, and thus I think it makes sense for each side to have distinct WGs. Speaking from experience in old SocialWG times, my company spent tens of thousands of dollars of time in SocialWG and related repos, and hearing about micropub and microfomats so much was completely irrelevant to our goal of delivering a w3c standardized ActivityStreams2 based solution to customers ASAP and had real business impact for us and our customers, and it added more than a year of delay to the SocialWG deliverable timeline. ActivityPub and Microformats stuff should have separate delivery timelines and not be able to hold each other up, and by far the most straightforward way of ensuring this is separate WGs and charters.

I tend to agree with @github.com/manton’s comment and analysis.

As Manton points out, there are many of us now, many implementers and publishers that are implementing and supporting multiple protocols, and thus it matters to us that we at least maintain the level of compatibility and interoperability that we achieved in the initial Recommendations of these specifications.

I think we can continue to do that, especially if we scope the Working Group to being a maintenance WG for the existing specs. This is something that Evan has convinced me of, while previously I saw a renewed Social Web WG to work on new features. Given the progress with use of extensions, and the Fed ID CG/WG stages process (or something like it), that seems like a better way to pursue new features, in parallel in the Social CG.

Another benefit of one Social Web working group is that its scope is easier to determine and explain, both to prior participants, and to W3C Members who will be voting on its creation.

A renewal of a working group to do maintenance on all of its prior specs, both editorial and bug fixes, makes a lot of sense to W3C and to Members, who like seeing working groups that take up the responsibility of maintaining specs. This especially makes more sense when all those specifications have far more implementations now than when they were shipped by the prior working group!

As I saw in another blog post about the social web, we are all here on “team open”, and I think we suffer, collectively, by attempting to draw lines with any “ActivityPub-only” approach. Both because it unnecessarily divides a very diverse, mixed, and broader “ActivtyPub supporting” community, and because it’s much fuzzier, to the point of overlapping with adjacent and aligned efforts.

The rel=me specification is a good example of this overlap. Would that be included in an “ActivityPub-only” approach? Because it’s certainly used by communities beyond that.

We have a whole task force on HTML Discovery in the CG where some of us (myself included) is working on improving rel=author support when interacting between HTML representations of profiles, yes, often with microformats, and retrieving the JSON(-LD) Activity Streams 2 versions of those profiles. That sort of interoperability benefits from a more inclusive approach.

We have bridges (https://fed.brid.gy/) that have helped the “ActvityPub-verse” grow that we could only dream about during the prior Social Web WG, because that group put in the hard work of figuring out interoperability across protocols and formats. We already did that hard work so why squander it? A maintenance group for all our specs provides a venue for any marginal bits of small work we may (or may not) need to maintain the positive outcomes of all that prior hard work.

Lastly, @github.com/gobengo brings up important concerns that I think merit explicitly addressing, regarding “experience in the SocialWG from 2013-2017” (actually 2014-2018 per https://www.w3.org/wiki/Socialwg)

First, in summary I will say as the saying goes “Don't fight the last war”, or I prefer a non-violent expression instead: “Don’t argue the prior debates”.

We were in a very different situation at the start of the first Social Web Working Group, having emerged from an incredibly diverse “W3C Workshop on Social Standards: The Future of Business” (AKA osfw3c) in 2013.

The first Social Web WG had to evaluate numerous prior group efforts (17+) and different approaches (~15) that were proposed by members of the group for consideration before narrowing down to ~3 approaches. Lots of time was spent doing this, which we would obviously avoid by sticking to maintenance of existing specs.

We also found so much in common that we were able to leverage as building blocks and points of compatibility. HTTP & link rel discovery. URLs for profiles. Etc. the list goes on.

All of that is pointing out how the first Social Web WG was very different than what a similarly scoped Social Web WG could be like today.

Second, the other strong point of more recent evidence that we should use instead of fearing “the last war”, is how the Social CG has been conducted for the past 5-6 years, especially the past few years mostly chaired by Dmitri.

Every Social CG meeting I have been to has been incredibly positive & productive. Even when we disagree, we do so in very civil, polite, informed ways that consider each other’s use-cases, perspectives, opinions, with folks working on different projects and protocols! It has been an incredible experience and I am grateful to be a part of it, and especially grateful for Dmitri’s stewardship. I mentioned this briefly in a post after a recent meeting https://tantek.com/2024/216/t1/socialcg-telcon.

With the Social CG, under Dmitri’s chairing, we have found a new more harmonious rhythm, and frankly, broader inclusiveness of different efforts and communities than we ever had previously. We have proven we can have regular meetings that “continue[s] the work of the W3C Social Web Working Group” where agenda items are curated and prioritized in a manner that respects the time and interests of the participants.

I would expect the harmony of the Social Web CG to continue in a similar renewed Social Web WG, and would support Dmitri as a co-chair of that working group to keep our momentum going. In addition, I would ask anyone else wanting to co-chair to learn from and adopt Dmitri’s chairing workmode accordingly. I believe that is our best path to success for this community, and for all our collective goals.

References:

• https://www.w3.org/wiki/SocialCG
• https://www.w3.org/wiki/SocialWG
• https://indieweb.org/2013/osfw3c

(Originally published at: https://tantek.com/2024/278/t2/)

Good points, @tantek. And thanks for mentioning specs like rel=me, which fits into multiple protocols including ActivityPub-based platforms like Mastodon. The fact is that even when we talk about "only" ActivityPub, we're often talking about a suite of related specs. It feels right to me to have a broad approach that maintains everything that came out of the original WG.

First, in summary I will say as the saying goes “Don't fight the last war”, or I prefer a non-violent expression instead: “Don’t argue the prior debates”.

@tantek I think you misunderstood me, or we look at this differently. I'm not fighting in any war. I'm not arguing the past debate. I'm looking forward to continuing to improving ActivityPub and ActivityStreams and incorporate errata into the TR with no delay and with the ability to focus on the already hard enough work. Please let's not make this about fighting and war. Or if so, do it in another WG so I don't have to hear it.

The rel=me specification is a good example of this overlap. Would that be included in an “ActivityPub-only” approach? Because it’s certainly used by communities beyond that.

We have a whole task force on HTML Discovery in the CG where some of us (myself included) is working on improving rel=author support when interacting between HTML representations of profiles, yes, often with microformats, and retrieving the JSON(-LD) Activity Streams 2 versions of those profiles. That sort of interoperability benefits from a more inclusive approach.

It's not my strongest-held opinion, but I would argue that this work item (which I was planning to come to the meetings of, btw!) should stay in the CG because it's not a change to the protocol, it's a change to the software/websites on top of the protocol at the HTML/presentation-layer. If it needed to be normative, might WHATWG or some broader HTML WG be the right place to formalize an HTML discoverability mechanism that applies to many non-AP usecases? I feel like it's an HTML thing with consequences for microformats and AP/AS2 but not a part of either?

Multiple weeks review period passed; discussed it during WG call, also sent out notifications on mailing list, forum and fediverse. No objections from the community.
Since this is just an initial draft proposal, merging (to continue the conversation).