Social Web Incubation Community Group

12 September 2023


bengo, bkardell_, btsavage, Chris_Needham, cwilso, Dan_Appelquist, dmitriz, eprodrom, Juan, miriam, pfefferle, plh, rhiaro, tantek

Meeting minutes

eprodrom: this is the first in person meeting we've had since the CG started. Thanks everyone for being here
… dmitri and james our regular chairs are not available, so I'm going to chair
… reliving old glories
… and I have some fine grained questions I'd like to work on
… our agenda is going to be very focussed on existing specs
… I shared an agenda on the mailing list this morning

<tantek> https://lists.w3.org/Archives/Public/public-swicg/2023Sep/0004.html

extension policy: extension policy

eprodrom: this remains an open issue, there's a draft extension policy to discuss
… and there a number of issues in the repo which need input from the group
… to me they seem relatively minor, editorial issues
… but changes to the errata are up for the group to discuss
… any additional agenda items?


dka: Dan Applequist, cochair of the TAG, and one of the original chairs of the social web incubator group way back when before social web was cool
… what's the current status of .. there's been a lot of talk on the fediverse about the need to recharter the WG. What's the status?
… Curious from a W3C process perspective, and as a denizen of the fediverse

eprodrom: It has changed significantly in the last 10 minutes

tantek: queued for the agenda

eprodrom: we can move this up in the agenda
… any other topics?

tantek: relatedly, I'd like to talk about possible rechartering as well, specifically in scope of a bunch of the specs we have produced have advanced, had adoption and patches and fixes and gained critical mass. We've also seen several other protocol stacks emerge, I think there's an opportunity for bridging and enhancing interop across those stacks
… that's a proposed agenda item

<Loqi_> [preview] [Tantek Çelik] going to the #SocialWeb CG meeting @W3C #w3cTPAC tomorrow (2023-09-12) at 09:30 CEST.

<Loqi_> Looking forward to seeing @evanp.me (@evan@cosocial.ca @evanpro) and many others!

<Loqi_> So many advances in #ActivityPub, #Webmention, Micropub, #IndieAuth etc. that it...

eprodrom: reminder that we do have two breakouts tomorrow about data portability, and interop and testing
… Any other open questions?

extension policy

eprodrom: background. When we originally created ActivityStreams Core and Vocab documents we included a section on extensibility
… the section covers the technical aspects, and somewhat the process aspects
… suggesting we maintain a registry of well known extensions to the activitystreams vocab
… and also that we have a process for including those extensions into the context document for AS2 itself
… Assuming some understanding of JSON-LD in this case
… you can import and reuse other schemas within the context
… we do that already with AS2 for a couple of different vocabs, and we said we'd have a mechanism for that in the future, but we deferred on creating that process

<pfefferle> there is already a community process: https://codeberg.org/fediverse/fep

eprodrom: we've had two (I think?) major additions to the AS2 context since we finished the REC
… the first was including the activitypub specific vocabularly and the second was addnig the alsoknownas from the did vocabularly
… during this time AP has been actively used and developed on the social web, and consequently there are a number of different extensions out in the world
… the idea is having a structured process for including those vocabularies within the activitystreams context doc to make it easier for developers to just use one context

<pfefferle> tantek I already joined

eprodrom: Any questions about the goals of this discussion?

dka: can you give me an example of a user need serviced by an extension so I have more context?

eprodrom: common use case on the social web - playing games across the network. Eg. words with friends across the social network using your identity, being able to make guesses at words etc. Being able to create an extension that wasn't built into activitystreams at the time that supports the new functionality in a new way

<eprodrom> https://www.w3.org/ns/activitystreams/

eprodrom: this is our namespace doc for activitystreams
… the html representation is an ED of a NOTE that describes the terms that are in activitystreams
… the core activitystreams vocabulary, we have the AP extensions and the DID Core extensions

<Loqi_> [preview] [Amy Guy] ActivityStreams 2.0 Terms

eprodrom: there's also a reference in this doc that says approval of extensions will be by the CG.. process and criteria is being finalised. The suggestion is to finalise that and link it here

<Zakim> pfefferle, you wanted to note there is already a community process: https://codeberg.org/fediverse/fep

eprodrom: community process for creating FEPs
… for creating extensions.. Fediverse Enhancement Proposals
… a light community oriented process that mirrors a lot of programming language enhancement processes
… I think it's based on PEPs the python process
… there are some very interesting extensions built with this mechanism
… there's a lot of interesting process here
… it's loosely connected to this community group through the socialhub forum
… suffice it to say I'm not sure there's a part of the FEP process that includes the process of including terms within the AS2 context document
… because the loose affiliation of people involved don't have access to modify that document
… we as the CG are responsible for maintaining that document and doing these extensions
… I'm not sure that the idea that there is this FEP process is entirely related to how we included extensions in activitystreams 2.0
… does that answer the questions?

<pfefferle> I only wanted to mention it, to not have two different processes

eprodrom: JSON-LD lets anyone include thier own vocabularys, many implementers do.

<pfefferle> I can hear you but its very noisy

eprodrom: Those are the major sources of extensions and we should encourage all of that

<pfefferle> was there a question for me?

eprodrom: the question si when do we take those extensions and include them in the activitystreams context document?
… What is the criteria for including them in the AS2 context document

<eprodrom> https://w3c.github.io/activitystreams/draft-extensions-policy.html

eprodrom: this is a draft extensions policy
… it's very light

tantek: how many AP implementers we have here that would be participating in this kind of process?
… how many people today can contribute to this discussion?

bumblefudge_: how are you defining implementer and participation? I'm working on FEPs with people

tantek: we're not directly implementing AP per se but we have launched a mastodon instance at mozilla.social and we've been making lots of modifications to that implementation
… not to its ap functionality yet, but we are touching code that is touching activitypub
… anyone else?

btsavage: Ben Savage, Meta. We may well at some point need to add extensions for various things

bumblefudge_: I'm working on the test suite, and not on a specific implementation, but specifically on the FEP process
… hoping to help this be the on ramp to extensions

eprodrom: I'm also implementing activitypub in various ways, clients and servers

<mro> I am implementing for Seppo.Social.

Casey: I'd potentially be interested in using extensions for postmarks which is early stage

<Zakim> tantek, you wanted to ask how many in meeting AP implementers do we have?

Casey: and at glitch.com, we're exploring AP integration, we might be exploring extensions for that but don't know yet

tantek: pfefferle is implementing ActivityPub for WordPress
… that answers my question, some people here who can give feedback

eprodrom: I'll discuss the suggested process
… Section 2. Several step process. the first is encouraging publication, so publish extension for review
… Noted a few places including the FEP system, NOTES on socialcg. Also publishing anywhere else.
… Publish so it can be implemented
… It needs to be implemented, have to have it in use
… third is that we have a registry where we list existing extension
… there's no barrier for that whatsoever
… any extension can be listed
… the fourth step is proposing the extension for inclusion
… justification why it's important for this extension to be part of the AS2 vocabularly document
… having a vote within the CG
… Our group would decide whether or not to include that document
… create a draft of the context document, including the new terms
… we test that draft, and then it becomes official
… I think that this is a fairly standard mechanism for making changes to an existing document
… and for building extensions that become part of the core system

eprodrom: the criteria for including extensions in AS 2.0 .. the extension must have its own context, describes terms and usage, has an IPR policy that's compatible with w3c
… asking for 2 independant publishers and consumers regardless of whether it's c2s or s2s
… a publisher and consumer might be the same software
… that's the minimum for interoperability. Hard to make a case for interop happening with only one implementer

bumblefudge_: this seems really straightforward. There's something a little implicit which is what happens if my work is msasively overwhelmingly successful and there's 20 FEPs that have been implemented twice that each have testable context files attached in the FEP repo
… and the WG has to timeline them, prioritise them, pick which are worth foisting on all implementers
… there's a gating thing that isn't mentioned at all
… once lal the criteria is met, there's a deliberation process?

eprodrom: good point. One option is we just put every extension into the context, and that we don't make any decisions
… two reasons we wouldnt' do that
… conflicts of terms, terms that are used in multiple vocabs, that makes it difficult to do inclusions so we need to resolve those
… second is size
… the context document is not large. 10s of kb
… but there i sa point at which it can get very large
… and it's hosted on the web. There may be size issues to be concerned about
… Third, the process. How do we queue things coming in from FEPs and other systems?
… the fact that we would vote on it within the CG before including something, is that the point at which we'd use that discretion?

bumblefudge_: I can imagine a couple of of ways of doing it that have strengths and weaknesses. I don't have an answer I prefer
… I've seen extensions in other processes are welcome, but merging into the main context is almost like making it a required feature
… some processes do that only at major versions
… extensions now are eligible to be in the context in the next major version
… that's one form of governance I've seen for these kinds of processes
… in some contexts the testability is debated for a while
… you have to provide an extesnion to a test suite that proves you can work with someone who didn't implement the extension for example
… Just positing that it maybe forces other issues abot what's a major version, what's the WG/CG division of power?

eprodrom: interesting question. Because we've already done this twice since the major version of AS2, we at least have some precedent for doing it between major versions
… I would not see that we need a version change in order to do this
… I also think this is a backwards compatible process if we're doing it additively
… if we were to add the security vocabularly that we use for http signatures in AP and is widely used, but the vocab has to be included each time you create an AP document
… that's a strong candidate

eprodrom: Any examples of other vocabs, system, with a similar process of inclusion of extensions?
… where extensions are built and then filtered into a core system?

<Zakim> tantek, you wanted to ask about test cases for extensions

tantek: this is a great minimal start to a process. The one suggestion I'd have is in the criteria ...

<tantek> https://w3c.github.io/activitystreams/draft-extensions-policy.html#criteria

tantek: it mentions demonstrate implementation
… I think for that .. how do we .. what are the test case requirements for that?
… usually you demonstrate a test suite that can validate for a publisher, or a for a consumer a set of test cases that produces a user visible result
… I think it would be useful for the criteria to be explicit about that, and give an example
… In the microformats community we came up with a change control process for adding vocabulary terms

<tantek> https://microformats.org/wiki/h-entry#change_control

tantek: once people are depending on it and systems are interoperating it's a different process
… it's very similar
… the difference is we have a few stages. Proposed, draft, stable
… we've found that's useful to give people an idea of where a proposal is in the process, and how to move it to the next stage
… one difference is we settled on 3+ publishers/consumers
… people would get excited about an extension, you could easily get 2, and those wouldn't necessarily last
… asking for 3 has been enough that 2 will continue existing over time

eprodrom: that makes sense
… Test cases do raise the bar there
… a testable behaviour
… not necessarily a bad thing ,but it would slow down that process

tantek: would help to say is there an implementation

eprodrom: would it be worthwhile to .. "required" and "desired" eg in a job description
… don't request without 2 implementers, better with 3

<Zakim> dka, you wanted to ask about i18n, a11y, privacy, etc...

dka: recognise that you're trying to keep the process lightweight
… in the TAG we do review of specs, and we ask for explainers. Document the user needs
… have you done accessibility review, security and privacy review
… i know some of these things are going to be quite small
… but it does feel like criteria.. if you're expecting some to be part of the core spec they'll need to go through that level of rigour at that point
… better to catch those issues ahead of time
… especially around a11y, i18n, privacy and security
… we have assets in the TAG that can help people reivew their specs

eprodrom: it's a good point, but a heavier process

tantek: support the horizontal review in the TAG, that's important. the vocab in AS2 predates the registry process in w3c
… the way evan is proposing is much closer to the way registries are handled in in w3c now
… closer than a new feature
… but it's kind of a mix
… the AS2 context is kind of a registry
… however there's usually some interesting piece of user functionality which comes with each function

<bengo> https://www.w3.org/2021/Process-20211102/#registries

tantek: that user functionality would hep to have some kind of horizontal review

dka: eg. the words with friends example - there'd be a microsyntax, and does it take accessibility into account?

tantek: right now, WGs can add things to registries without any review
… somewhere in the middle

<Zakim> tantek, you wanted to react to dka to answer dka

<Zakim> bumblefudge_, you wanted to differentiate vocabulary changes (which should be backwards compatible) from features or behavioral changes (which require test cases/suite support)

bumblefudge_: some of the things that are currently FEPs include .. if something is only adding something to the vocab... a vocab change should be backwards compatible, deosn't break implementations
… but most of the time they're not just semantic extensions, they're semantic and behaviour
… we're dancing around the fact that the semantic extension part should always be backwards compatible. But there's a behavioural extension motivating adding the extension
… the context is just a registry, but there's almost always a behavioural extension attached
… if the behavioural extension is big enough to maybe break implementations that haven't implemented it, then you need a test suite.... that's a totally different beast
… maybe this is too complicated?
… but some thoughts

<Loqi_> bumblefudge has 1 karma over the last year

bumblefudge_: Also, there isn't currently a single robust test suite that is easy to extend as a fep is to write
… if you coudl just write a fep and then add some test cases to an existing test suite it would be much easier to make a testability requirement
… but until we have that we're laying tracks in front of a moving train

btsavage: I like the suggestion from tantek that to be included there need to be test suites
… I think it's helpful for new activitypub implementers
… for all of the official extensions to have a test suite to work with
… part of the incentive, to be part of the official list there need to be tests, seems like it would create a nice outcome

eprodrom: also one of the reasons we create test suites is so we don't have regressions or problems when we make additions

eprodrom: the question I have is how we move forward with this process
… I'd like to propose we adopt the process document as presented as a draft to be maintained and developed by the CG
… this would be a first draft note and we continue with modifications to this draft

tantek: does that include adopting it as process, or adopting it as something to publish?

eprodrom: the latter
… not adopt the process yet

tantek: cg publish reports, but not NOTEs

<eprodrom> PROPOSED: use https://w3c.github.io/activitystreams/draft-extensions-policy.html as a draft of a report for an extensions policy for SocialCG

tantek: do you want suggestions for improvements filed as issues on that repo?

<dmitriz> +1

eprodrom: yes
… eg. versioning, test case requirements, etc

<tantek> +1 to publish that as a CG report, and file our suggested improvements as issues on the repo linked in the draft

<bengo> +1


<bumblefudge_> +1

<dka> +1

<bengo> wrt "cg publish reports, but not NOTEs", I would like a citation on that

RESOLUTION: use https://w3c.github.io/activitystreams/draft-extensions-policy.html as a draft of a report for an extensions policy for SocialCG

<tantek> bengo, it's in the W3C Process, I bet plh can dig up a citation there

<Loqi_> [preview] [Tantek Çelik] going to the #SocialWeb CG meeting @W3C #w3cTPAC tomorrow (2023-09-12) at 09:30 CEST.

<Loqi_> Looking forward to seeing @evanp.me (@evan@cosocial.ca @evanpro) and many others!

<Loqi_> So many advances in #ActivityPub, #Webmention, Micropub, #IndieAuth etc. that it...

group status and rechartering

<bengo> wrt rechartering, that seems like something that should have been on the agenda 2 weeks ago

<bengo> (per process doc)

dka: So... what's going on?

eprodrom: we were originally chartered in 2015 and worked for 3 years with some generous extensions, published 6 RECs

<tantek> correction 7: https://www.w3.org/wiki/Socialwg#Recommendations

eprodrom: the off ramp for that WG was the idea that this cg would do ongoing maintenance of those documents
… The current state of play is that the CG does some work in that area, we do meet fairly regularly
… we do issue triage
… however we're not able to update the rec track documents

<plh> Social Web Working Group - Charters

<Loqi_> [preview] [Elika J. Etemad / fantasai] W3C Process Document

eprodrom: one reason for us to recharter is for us to be able to move forward with those documents and take them to next versions
… There have been, since the publication of activitystreams and activitypub and the others, there have been a lot of development use, real world experience
… there may be some value in applying those to iterations on those documents

<Zakim> bengo, you wanted to discuss whether the w3c process generally requires f2f meetings to have agenda items like rechartering to be published two weeks before f2f meetings (https://www.w3.org/2023/Process-20230612/)

<Loqi_> [preview] [Elika J. Etemad / fantasai] W3C Process Document

bengo: I noticed there was an agenda published before the meeting but it didn't include anything about rechartering
… wrt to process it would normally the agenda for f2f meetings would be published 2 weeks in advance, especially to discuss something as serious as rechartering a group

eprodrom: I think this is a discussion, not a decision
… but that's a fair point
… if we feel comfortable with it, we'll not make any decisions in this morning's meeting

tantek: the process doesn't have that requirement for CGs, only for WGs
… second, a common process is to do agenda gardening as the first thing in the beginning of the meeting, people are given an opportunity to suggest or prioritise items

bengo: sounds good. Just worth having future discussions and not making resolutions without a bigger quorum

<Zakim> tantek, you wanted to react to bengo

<plh> Revising a Recommendation: Editorial Changes

plh: we don't need a WG to make editorial changes to docs, you can come to the Team for that
… but for substantive changes, we need a WG
… The way the current process.. the short version is the team propose a charter to the AC. We're looking for a group to tell us what they like for a charter, and we'll send it to the AC
… I'd be looking for, if we're going to create a WG to work on ActivityPub, I'd be looking to this community to tell the Team what you'd like to see in the charter because you know better than us
… I'm very supportive of relaunching the social web WG for the simple reason that we have a rec and I'd like to have a WG to maintain it
… when we closed the WG back then, we didn't have this process
… Nowadays we dont' close the WG, they're in charge of maintaining the rec as a maintenance WG
… Now there's interest in actively maintaining the rec

<bengo> (for posterity, it is very hard for remote attendees to hear)

plh: for ActivityPub

<tantek> +1 plh

tantek: agree with plh
… we have seen a huge amount of substnative functional improvements to AP and AS2 by implementers

<dmitriz> fwiw, so far there's been fairly significant community pushback to rechartering

tantek: which has been largely self governed and operating fairly well
… getting some of that into the core rec would be a good thing
… we've had 7 recs come out of social web wg
… some have updates already
… maintained as living standards by the indieweb community
… eg. micropub. Would be great to get iprovements rolled into the w3c spec
… we published a NOTE for indieauth because it was outside of the scope of the charter. We have a lot more implementations since then
… I'd requst it was considered in scope for a rec track document based on the NOTE
… lastly, there are a few new related specs that have been implemented, like microsub
… multiple implemenations there
… clients and servers
… to add to the scope of a new WG
… example - bridgy.fed - interesting unintended successes of the previous WG
… evan and I worked really hard with the staff contacts and chairs to take 15 or so approaches to the social web and narrow them down to 2.5 to 3
… we decided instead of trying to fight that out down to 1, we'd allow those communities to develop their technical approachs, and use the wg as a forum to develop interop across them
… in terms of semantics, minimising friction when coverting between them
… now we have services like bridgy fed that can connect between these different stacks
… on tantek.com I publish html, I use webmentions, and I use bridgyfed to connect directly with the fediverse
… I haven'tw ritten a single line of ap myself, and send bridgyfed a webmention, it delivers them ap inboxes across a number of people
… there's a dashboard
… I'd like to replicate that with the other technical approaches we're seeing, some are not in this room
… eg. BlueSky

<bengo> bsky is going to IETF

tantek: and Nostr
… blockchain based, also growing in adoption
… we're at this interesting moment for the social web
… people want to invent a bunch of approaches, and w3c could serve a role here to bring together a bunch of different approaches
… that's my suggestion for scope
… to define it in such a way to be welcoming to those other groups
… to build bridges and allow for interop

<bumblefudge_> nostr<>AP bridging is already happening in the wild (somewhat chaotically for the moderation system of AP that is, as yet, underspecified...)

dka: if you do recharter a WG that you keep the CG running as well - having that dual mode approach I've seen work very well with other things

<bumblefudge_> and i have also heard from the bsky team that IETF is being targeted for some specs

dka: eg. the immersive web

<cwilso> +1

dka: keeping the WG lightweight and focussed around what it needs to do to update the rec
… and having most of the technical work happen in the CG is probably the right balance
… you probably already know that

<tantek> +1 dka

<Zakim> tantek, you wanted to ask where are the errata to ActivityPub and note living spec updates to Webmention, Micropub, IndieAuth etc.

<Zakim> dka, you wanted to recommend dual CG/WG approach.

eprodrom: I'm concerned about opening specifically AS2 and AP to normative changes fo r a couple of reasons
… it's going through a period of explosive growth
… if we establish a process for treating an AS2.0 potentially breaking changes that may put a damper on implementation
… why would I implement AP1 today? I should wait until AP2 comes out and it's not done and it's taking years..
… may have potential for inhibiting uptake right now, unless it was well messaged, backwards compatible
… I will also say that there are ... with aset of recommendations that exist right now that are available for developers to use right now, I'm less supportive of more protocols being built right now
… I'd probably not think that adding BlueSky to socialcg makes sense
… it's an effort to build a proprietary protocal separate from existing standards
… I'm not sure having an array of standards is helpful for developers or users
… it's a different world than it was in 2017
… considerably more people, more implemenations, more infrastructure
… I would not necesssarily encourage other experimentation at this point that isn't compatible

<plh> [actually, the right answer is 2014 :) ]

btsavage: if we are going to charter a wg, my recommendationw ould be to keep the scope quite limited
… this is based on my experience in the private advertising technology cg
… we've been attempting to create a wg for nearly 2 years
… faced a lot of challenges
… one set has been pushback on scope
… it could potentially slow us down
… in getting a wg chartered

<dka> +1

btsavage: I'd love any advice to avoid a situation where it takes years

<bengo> is bsky pbllc even a w3c member company?

<Zakim> tantek, you wanted to note we can be explicit about keeping AP compatibility in the Charter scope and to also note rechartering a previous WG is very different than chartering a new WG

tantek: sympathise with the potential problems with divergance in this space, we share a lot of values there
… it took a lot of hard work to come to the balance that we did in the original social web wg
… I think there is a social componenent to this..
… maybe we don't need to get those discussions into the cg - maybe a liason effort
… someone mentioned bluesky going to ietf? Maybe a liason opportunity there

<bumblefudge_> +1 to btsavage -- each additional function we assign to this maintenance group is additional risk of falling into the charter swamp

tantek: I strongly agree that we should keep AP compatible. Against breaking changes against what's been implemented
… we might make changes to reflect what implementations decided to do
… charters can say we'll work on this spec, but out of scope are breaking changes as far as what is implemented
… tha twould be one guardrail
… we could put other guardrails in place
… to not break momentum

<bengo> What if we made an activitypub CG?

tantek: a WG can help reinforce what you're asking for
… to btsavage's challenge... it's a different istuation rechartering vs chartering a new wg, to update recs that have taken off in the market
… agree a new wg should have a narrow charter
… a lot of things to establish
… wouldn't suggest adding a bunch of new things
… but maintaining what we know has been widely adopted
… taking the things with multiple implementations which are not recommendations yet
… and including those
… eg. indiauth

plh: we can make the charter of the wg about only fixing.. not allowing new features. Only modify normative aspects of specs if it's already deployed and reflects reality
… we can make the charter as tight as possible
… we're not working on a new version of AP, just making sure the spec reflects reality
… PNG is an example of that
… and we want new implementers to implement reality
… we can set that as a goal in the charter

eprodrom: strong goal
… As ben pointed out, we're not going to try and make decisions today, but it sounds like from this conversation that there is... can we do a straw poll?
… sounds like we have support for exploring a charter

dka: gotta go, but +1, feel like this is necessary

eprodrom: suggest we defer this to the next cg meeting in 2 weeks
… consider a proposal for starting a charter process

tantek: a good idea for the wg to do refinements
… but there's a much broader set of participants here at tpac
… what belongs in a charter, what belongs in a w3c charter
… even a straw poll from the people in this room and on the channel would be a useful opinion to take
… we can keep iterating on that
… we should iterate in socialcg meetings

<bengo> a straw poll would be misrepresentative of the broader cant-afford-to-attend-TPAC-on-company dime ecosystem

<tantek> PROPOSED: Explore rechartering the Social Web WG to do updates on existing RECs with wide implementations, consider adopting NOTEs with interoperable implementations as WDs, and consider incubations with interoperable implementations for WDs

<Zakim> tantek, you wanted to suggest a proposal

<bumblefudge_> PROPOSED: Explore rechartering the Social Web WG to do updates on existing RECs with wide implementations, designate a core suite of testing strategiesconsider adopting NOTEs with interoperable implementations as WDs, and consider incubations with interoperable implementations for WDs

<bumblefudge_> oops sorry

<bumblefudge_> strike that

plh: are you proposing that the WG has new features in scope?

tantek: yes because implemenations have added new features that are beyond the scope of the spec right now. Eg. extensions. I'd like the WG to consider a similar process for improving AP and AS2 specs

<tantek> bumblefudge_: +1 on including testing strategies

<tantek> +1

<bengo> -1 not all RECs are worth working on hand-in-hand

<dmitriz> -0.5 (needs broader conversation w community first)

bengo: I don't think it's a good idea to charter working on all of the different recs that came out of the WG in the past
… people look in the minutes of the days we voted on those TRs that there were some surprise things inserted in and voted on things that were published before even AS2

tantek: which things?

bengo: would make sense to narrow it to only AS2 and AP if that's where by far the most adoption has happened vs other recs

<bumblefudge_> (slight adjustment, not really alternative)

bengo: we could clarify what we mean by wide adoption and enumerate exactly what we mean

<bumblefudge_> PROPOSED: Explore rechartering the Social Web WG to do updates on existing RECs with wide implementations, designate a core suite of testing strategies, and integrate it with the FEP process and/or additional independent/community processes. Maybe adopting NOTEs with interoperable implementations as WDs, and incubation of interoperable implementations for WDs could stay in CG for now, until the test suite has consensus that would be t[CUT]

bumblefudge_: laying tracks before moving train... if a maintenance group could take as its target defining a set of test tools that would be the basis for interoperable things
… and bengo's comment about defining what's wide enough adoption

<tantek> +1 defining a set of test tools

bumblefudge_: I feel like those are slightly downstream
… you could maintain what there already is and have a foundation for deciding which specs can be declared provably interoperable
… is there any way to stagger it, or do you have to recharter?
… Maybe a layering thing. I'd love some time to have a test basis before moving testing into scope

<eprodrom> PROPOSED: Explore rechartering the Social Web WG

<tantek> +1

eprodrom: proposal that takes out what we'd be exploring. Explore means we're going to spend time in the cg over the next multiple meetings now that we have this on the table, to discuss what that would actually entail, and work with staff and members to decide about what that is

<tantek> +1 from dka as well who had to leave who gave general support for rechartering a Social Web WG

+1 exploration without specifying detail yet

<eprodrom> +1

<bengo> is this a proposal or a straw poll

<bumblefudge_> +1

<pfefferle> +1

tantek: as a CG we don't make formal decisions. This is the same thing

<dmitriz> +0 (doesn't seem urgent, given the overall lack of interest in it in

<dmitriz> the wider community)

eprodrom: seeing some concerns

<bengo> 0 - this should have more notice for more votes to be registered

eprodrom: will reach out to participants who aren't here today

<bumblefudge_> yeah i thought i was +1ing defining a few scopes and strawpolling them at the next meeting

eprodrom: we can defer the rest of the agenda for today

plh: come back to me with the conclusion, I'm interesting in the outcome of this conversation

eprodrom: what would we come to you with?

plh: bullet points, whatever you want
… we can turn that into a charter, and send it back for iteration

tantek: I'd suggest listing what we want to work on standards track, updating or new

eprodrom: thanks everyone, ajourned
… reminder of two breakout sessions tomorrow

bumblefudge_: at 1215 and 1430

Summary of resolutions

  1. use https://w3c.github.io/activitystreams/draft-extensions-policy.html as a draft of a report for an extensions policy for SocialCG
Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).


Succeeded: s/TOPIC/extension policy/

Succeeded: s/tantke/tantek

Succeeded: s/to b eincluded/to be included

No scribenick or scribe found. Guessed: rhiaro

Maybe present: bumblefudge_, Casey, dka

All speakers: bengo, btsavage, bumblefudge_, Casey, dka, eprodrom, plh, tantek

Active on IRC: bengo, bkardell_, btsavage, bumblefudge_, cpn, cwilso, dka, dmitriz, eprodrom, Loqi_, miriam, mro, pfefferle, plh, rhiaro, tantek