Meeting minutes
<nightpool> my money for an irc client that has working mobile push notifications
<aaronpk> Glowing Bear just added iOS PWA push notification support
<capjamesg> Meeting starts in 6 minutes: https://
I see a '400 Bad Request' from jitsi. Anyone else?
<dmitriz> seems fine for me
<dmitriz> what address you using?
Cleared my cookies and it worked!
<dmitriz> oh good
(I forget how to work the bot)
(I like how in CCG the chairs just start asking experienced people 1 by 1 to scribe and make them say 'no im not willing to')
<dmitriz_> ahahah yeah we should get a scribe list
capjamesg: <is reading from the FAQ posted earlier>
capjamesg: is there anyone with feedback on whether a WG is a good idea
<capjamesg> bengo I'm reading my private notes on Notion :D
nightpool: I have a question. You said CG is empowered to present errata for AP/etc standards
<snarfed> are we using Jitsi hands or Zakim for floor control?
<dmitriz_> either is fine
<dmitriz_> we can do just jitsi
nightpool: There is not a super clear path forward to getting the documents updated with errata. does anyone have thoughts on that? I personally dont think there is a huge need for a new WG. BUt getting that power we have clarified could be helpful
<snarfed> sure
<capjamesg> w3c process: https://
tantek: It depends on nature of errata. W3C process from FAQ links to it
<Loqi_> [preview] [Elika J. Etemad / fantasai] W3C Process Document
tantek: If errata is editorial, w3c team can confirm that, and they are able to update specs on w3.org.
tantek: If there are meaningful changes to features, that needs to be a WG and it could be existing, new, rechartered WG
tantek: That could be one use case for a WG would be to incorporate errata and update specs accordingly
eprodrom: the process we have to update the doc without charting a WG. We can incorporate errata in an editor's draft and submit that to the staff of the w3c.
eprodrom: They have offered to update the document for editorial suggestions
eprodrom: spelling errors, mistaken syntax in examples, things like that
nightpool: Which we don't have an inconsiderable number of
eprodrom: Last I checked 5-10 known errors
eprodrom: That's an estimate. I can give full number if needed
dmitriz: As evan mentioned, we have the ability to update documents w/ errata by handing a draft over to the w3c staff. What we don't have is the ability to make substantive changes or breaking changes.
<capjamesg> +1 re: documenting unclear parts
dmitriz: It would be great to document some of the unclear parts of the as2/ap spec that reflect the years of experience since then
dmitriz: Evan can explain more. That would be one reason to do a narrowly scoped WG
<tantek> FYI: last week's Social CG meeting minutes as context for new folks: https://
dmitriz: Also to update based on implementation experience of ap/as2
eprodrom: I'd like to reply. We do have some recorded issues with AP/AS2.
eprodrom: They are technically normative. For example, the followers collection. spec doesn't say those elements should be unique
eprodrom: Assumption has been made that it should be unique. BUt there is a question. Having spec and guidance may be normative but may reflect actual use. could be helpful
capjamesg: I think goal of the WG is making the job of implementors as easy as possible based on the experience we have over the years
tantek: +1 to what evan said. I think it would be very useful to capture the substantive changes we've learned from impl experience and deployments. It would help readers.
tantek: I +1 what evan said about ap/as2 updates
tantek: There are also changes for webmention et al
tantek: There are extensions that are interoperably implemented that could be rolled into the core spec
aaronpk: There have been minor updates to micropub spec itself
<capjamesg> https://
aaronpk: IndieAuth was a note published by group, not a full on rec. But it has gone through many changes since published. there is another opportunity there
<tantek> note: substantive features include but are not limited to "breaking" features. you can have plenty of substantive changes like new features that are not breaking in any way
dmitriz: I'd love to hear from other members of the community.
dmitriz: We have new faces. This topic has spread to socialhub, fediverse, etc.
Lisa: I am professionally working on portability. Personally a fediverse user and enthusiast.
Lisa: I think it's great to look at errata, rel=me, indieauth. plenty and very useful
Lisa: Then maybe after that we can work on portability. Let's do easy stuff first
<tantek> +1 Lisa
Manton: Thanks everyone for work that got us to this point
Manton: Don't think we should be too narrow. I think I've implemented every recommendation and note
dmitriz: I'd like to provide a counter proposal for specifically a narrow scope
dmitriz: consider holding off on a WG right now. Just incorporate errata using CG process outlined.
dmitriz: OR only charter a WG with narrow scope of errata + clarifications
aaronpk: My understanding from what I've heard of changes is that they would not fall under errata scope
<capjamesg> bengo: strongly prefer not having a large social web working group, didn't lead to collaboration vs. competition over limited air time
<capjamesg> bengo: provide implementation guidance -- the best way on a timeline and avoiding competitive dynamics is to do it in an AP working group charter
<capjamesg> bengo: this pattern has worked for high stakes specs
thanks james
<nightpool> capjamesg++ for scribing
<Loqi> capjamesg has 2 karma in this channel over the last year (129 in all channels)
tantek: As a minor correction. SocialWG was not a large group. We typically had under a dozen people that came to meetings regularly
<dmitriz_> ben means large in the specs / communities sense, not people sense
<bumblefudge_> also the vcwg does lots of it's work in ccg task forces
tantek: We did have small subsets of the group work on different things
tantek: And in the group we had cross-technology and bridging discussions. It worked quite well
<bumblefudge_> it also outsourced one big time suck to rdf canonicalization wg
<capjamesg> Bob in chat: "I strongly support a "SocialWeb" Working Group. If that hasn't worked in the past, we should be trying to make it work in the future."
<bumblefudge_> portability task force could stay in cg? it probably won't neednormative changes, could just be extensions
tantek: WG will often create a task force to work on a specific technology so that if people want to work on only one or two specifications can work in a TF which is empowered to work in the WG. That way people can pick there own level of participation. It empowers folks to get work done where they want, esp those who want to work on both
<dmitriz_> +1 to portability TF to stay in CG
<bumblefudge_> we have an extension mechanism that seems to work well to allow staggering adoption across large userbase implementations
<dmitriz_> exactly the kind of things CGs are useful for
tantek: I would say that one output of the group was a high degree of semantic interop between AP and webmention. It has enabled bridgy (sees snarfed) which has enabled things like micro.blog which seamlessly suppose multiple protocols without forcing the user to decide
<bumblefudge_> rather than major version forced sunsetting
tantek: It's hard to emphasize how important that was to keep things working
tantek: I would like to see more collaboration ongoing, not competition
capjamesg: I'd like to see that too
dmitriz: I'd like to +1 to what bengo said that it might make a lot of sense for IndieAuth to charter a WG specifically for that or other IndieWeb specs narrowly focused on the indieweb specs.
dmitriz: There is a lot of benefit to separating the streams into narrow WG
dmitriz: +1 to what ben said
<tantek> dmitri, point being you can create Task Forces to do such narrow focuses, without losing the collaboration of a broader Working Group
<capjamesg> https://
manton: I was going to say this anyway but it also responds. One concrete example in favor of more broad is IndieAuth. For example, Evan proposed an Oauth2 profile for ActivityPub. To me there is a lot of overlap
manton: I feel they should be discussed at the same time
<dmitriz_> auth should absolutely stay out of scope, of any wg...
manton: I feel benefits of everyone talking together
(bengo notes that more people can talk together in SWICG without a WG)
Aaron_Gray: We should generalize the auth. There could be a generalized indieauth for indieauth, did auth. Maybe there could be a common API for all of them as a subgroup
(aaron gray)
aaronpk: With my oauth hat on. I am editor of oauth 2.1 spec and in IETF groups on it. I know there is a lot of discussions about keeping auth out of group
aaronpk: There are views about keeping auth out of specs
<capjamesg> +1 re: inventing new things
<capjamesg> *not inventing new things
aaronpk: oauth is great. You kind of need to profile it to work with indieauth and other social web things. You have to profile it if you're going to use it
aaronpk: IndieAuth and evan's profile do have a lot of similarities already
<dmitriz_> that seems like a job for the IETF OAuth WG. (or the IETF GNAP wg)
aaronpk: Those similarities are making their way into the IETF discussions as well
aaronpk: Those discussions should be done in concert with the oauth discussion at IETF and any auth work here should cooperate with that gruop
aaronpk: I disagree with aaron gray with making a broader scope for auth. This works as is with what mastodon is doing and its on the right track but we need to better formalize
<tantek> +1 aaronpk, solidify how Mastodon uses OAuth and IndieAuth uses OAuth
bumblefudge_: there is a slight difference between a CG writing a profile as a note and a WG saying 'this is what AP is'
bumblefudge_: it brings auth into scope to do it in WG
bumblefudge_: I agree having auth profiles soon is a good idea. Everyone agrees hardening and having eyes on authn profiles. But that's different than doing auth in a social wg that could pick one way. It would be nice if implementations could choose which makes sense for them from CG profiles
bumblefudge_: Evan at TPAC proposed to choose things that get implemented by large implementations from the CG profiles. Are those then candidates for future WG
bumblefudge_: there was a period where those were happening in isolations without hope of being blessed as official options. If we open a path for extensions that take off and trickly through major implementations, that would be my preferred way of doing auth. There should not be WG fiat made by 10 members of a WG. I'd rather see extension processes be open and forified and taken seriously
bumblefudge_: everyone who started a note or FEP and didn't know this would happen should have at least a few months to update their note for consideration by SWICG
bumblefudge_: I want this to be community driven and adoption driven vs expertise driven
bumblefudge_: that's a reason I prefer to stay in the SWICG. I dont want this to just go into w3c WG and have techniques be done because W3C say so, vs process of community consideration and implementation
bumblefudge_: I worry about 'pre design'
capjamesg: IndieWeb is an example of a good community
capjamesg: where people implement and collaborate
<bumblefudge__> honestly I was at fediforum yesterday and lots of people had never heard of FEPs or NOTES :(
nightpool: with authn, one thing important to remember is that the original wg left authn out because it wasn't clear what would lead to adoption or be practical
<capjamesg> Evan in chat: "I have to drop. I support a WG with scope of errata plus clarification . I oppose any editor's draft with normative changes. "
<bumblefudge__> we have some outreach to do to bring people (back) in
<capjamesg> [tantek] in chat: "Evan, clarifications can be normative though, presumably curious how you are distinguishing those "
<bumblefudge__> elk.zone might get widely deployed?
nightpool: to some extent that has happen. there are two major s2s auth implementations. there are less c2s interop implementations of auth
nightpool: there are clear extensions in teh spec we have for community extensions for authn. I just want to point out we have extension points in the spec open for CG notes
nightpool: we dont need to make a spec change for auth. We just need CG notes for community guidance
<bumblefudge__> +1 to guidance and profiles and documentation of all kinds !
nightpool: I also want to note wrt FEP protocols. I agree with fact that we need to look at what's deployed and feasible. Another dynamic at play is there is low incentive to implement an FEP when there's no clear guidance on whether that will be the most interoperable solution
<bumblefudge__> well if no second implementation adopts it, sure
nightpool: in some ways a FEP is punting interop. i.e. standardize with what one project has done vs coming to consensus on what others could/should do
nightpool: Observation of process in the past is that it is lacking in that
<dmitriz_> an FEP being opened is just a start of the conversation, though
<bumblefudge__> the point of a FEP is that no input from other implementations is a guarantee it'll stay single implementation...
nightpool: Whats holding up and hurting FEP process right now is its single implementor discussion/profile. So then its 'which 10 FEPs do you support and how do they conflict with each other' so then there is no guidance for implementors because it didn't seek consensus
<bumblefudge__> that's a fair critique honestly it takes a lot of nudging to improve the process
nightpool: from pure technical perspective I dont think FEPs are providing clarity as much as documenting what exists
<tantek> +1 to both nightpool's concerns and what bumblefudge__ said about allowing experimentation to continue in FEPs
capjamesg: I'm just starting to impl AP so I am in that bucket now
<bumblefudge__> we need to PR the contributing.md with that guidance Maybe
dmitriz_: I think authentication is a really good time to highlight the role of a Community Group, which evan and tantek mention is to produce reports and hand them off to Working Groups. There are already authn Working Groups, including IETF oauth and OpenID and OpenID Foundation
dmitriz_: It would be possible for SWICG to produce authn notes and hand those to existing qualified groups. There is no need for a WG for auth
<bumblefudge__> but huge +1 to Aaron helping us harden both profiles!!!
dmitriz_: From what I've seen, FEPs are just a way of starting a discussion about what worked for someone, discuss, make PRs for a FEP
<manton> Just wanted to clarify for people reading the transcript later, that above (:24) I meant to compare Evan's FEP (also linked above) with the IndieAuth note, and potential overlap that could be discussed if the scope isn't too narrow to only one spec.
dmitriz_: It is very much a living/start of implementor conversation
tantek: +1 nightpool's concerns about single implementor extensions
tantek: I want to preserve the broad community participation around FEPs and other communities
<bumblefudge__> I meant aaronpk sorry
tantek: one thing we discussed at TPAC was how w3c has evolved since SocialWG
tantek: one pattern that has emerged is one CG that incubates, looks at relevant things, and uses some criteria like multi-implementor interest, multiple prototypes, or especially interoperable implementations to propos uplifting to the WG.And a WG that looks at the work of the CG, especially such uplift proposals, and decides by consensus whether to uplift proposed specs or incorporate extensions into core specs in the WG
<tantek> https://
tantek: A participant in last week's Social CG meeting brought up the Immersive Web where they have both a CG and WG and are able to do the best of all worlds
tantek: They are able to keep creative experimentation in CG, but once there are multiple implementors interested, they can lift to WG
tantek: then people dont have to wonder what to implement, they can just look at the core spec authored by the WG
kevin: WG specs are documentation not legislation
kevin: the goal is to document what has been done not to specify how new people should implement
<tantek> +1 Kevin_Marks
kevin: people who have done the work bridging lots of things
<capjamesg> +1 -- implementers ultimately decide whether to implement part of a spec.
kevin: A big chunk of what happened last time but wasn't always visible was looking at 17 different APIs and looking at how they abstractly did things
<snarfed> eg https://
kevin: that was a big chunk in activitystreams was abstracting amongst common patterns at big sites
<capjamesg> (I think) the doc authored by Amy to which Kevin is referring: https://
kevin: Sometimes it is boring and involves bickering
kevin: but at the end there is good content and ways of accomplishing those use cases
kevin: We can do convergence at the spec level
kevin: It's like classic xkcd about 14 probelms and then 15. Except in the SocialWG there were 17 and we got them down to 3
kevin: People can say there was fighting at the end. But I'd say we did as good as we could by the end
kevin: e.g. something the group got right was a way for people who really like RDF and people like really like JSON to each have their way
aaronpk: I think we might be talking about different things on authentication
aaronpk: I'm not saying the WG should be inventing new mechanisms
aaronpk: There is not a scenario where you can just use oauth or just use openid
aaronpk: you have to make more decisions and those concerns sometimes overlap with wider communities
aaronpk: in those cases those discussions should be bridged
aaronpk: but there will also be some cases where narrow scoping things are only relevant to activitystreams/activitypub/micropub
<tantek> +1 aaronpk, good opportunities for noting liaison relationships with other groups/communities
aaronpk: sometimes those other groups dont care
aaronpk: I've done this before. I worked with FDX on open banking
aaronpk: but there are some things they need and specific conerns they need about regulated banking that dont apply anywhere else. and in some cases they have developed their own profiles for their use cases
<lisarue> I'm sure we can get good review from oauth WG contributors
<dmitriz_> just to clarify - I wasn't suggesting we'd invent new things from scratch. just the opposite - the CG can come up with the Authn profile
aaronpk: it's not that we are inventing new things from scratch. but we should document how to use them in our protocols
<dmitriz_> and check it against / liaise with the IETF authn WGs
snarfed: oauth profile is 1 profile. one example is authn in activitypub itself. it's imfamously unspecified
snarfed: community has settled on HTTP Signatures (cabbage not httpbis) for s2s
<dmitriz_> HTTP Sig is another great example - there's already an IETF WG working on it! :)
<dmitriz_> (finally)
<capjamesg> As a new implementer, I have been confused by HTTP Signatures.
<capjamesg> We shouldn't invent it, but I think I'm asking for more docs :)
<dmitriz_> 100%, it's super confusing. and yeah, definitely docs are needed
nightpool: on legislating vs documenting. I want to be clear that it is always going to be a balance because there will always be implementors that will await clear guidance. The goal of the group should always be to document and work with what is out there already, and at the end there also needs to be editorial guidance
<dmitriz_> which the CG can provide; WGs have no monopoly on better docs :)
nightpool: you have to do the work about coming from 15 standards to one
<bumblefudge__> to be fair Evan did offer to mature the FEP process a week ago
nightpool: To me the FEP process is too far on the documentation side because there's no room for simplifying approaches and editorial guidance
<snarfed> dmitriz: right! my point isn't that we'd work on HTTP Sigs independently, only that we'd work on saying _in AP_ that it uses HTTP Sigs, details, etc
<bumblefudge__> huge +1 to Evans proposal
capjamesg: one point brought up on Mailing List was inclusion.
<aaronpk> FYI http signatures are well on the way to RFC status at IETF now, just going through last reviews https://
capjamesg: to the extent we can all make people aware of the channels where people are talking about this stuff, that is all the better
<bumblefudge__> yay!
<Loqi> 😄
<tantek> +1 nightpool
capjamesg: when I've been implementing it hasn't been clear to me where FEPs apply vs the spec. Where should I be focusing my time? what's normative? as an aspiring implementor it's hard for me. Invite your friends to the gruop
<dmitriz_> ooh, +1 to that, Tantek (CG to help w FEP discussion)
capjamesg: I'm hoping we can create a forum where all can discuss things. Good topic calls like the CSAM topic call earlier this year
capjamesg: also meeting with other communities like indieweb. i think we should all be working together
tantek: good points nightpool I am glad you're here. I have also observed what you expressed. There is this broad spectrum between super bold implementors who write one FEP and that's there thing vs implementors who jump forward on things.
tantek: and yes there will be implementors who stand on the sidelines and wait for things in core
tantek: i have seen that over 20-30 years of standards work
tantek: Let's consider. Can we encourage folks for people to use the SWICG to get people to advocate for FEPs in a multi-stakeholder interop
tantek: I wonder what would be a good FEP/socialcg interaction or am I off base there
tantek: there are a lot of discussions in a broader sense happening at w3c beyond who is in this room. There are 40 odd groups and new ones proposed all the time
tantek: one use case is personal data stores
tantek: Some may be aware of solid
tantek: It was originally about social web hence the name solid is short for "social linked data" but now it seems like it has shifted to personal data stores
<bumblefudge_> yeah the FEPs range from "here's what i did" to very collaborative from the first issue. we should clarify only the latter will ever make it to main :)
tantek: I met with a few Solid folks last week at TPAC and noted how existing technologies work for the personal data store use-case also, like you can use ActivityPub with other vocabularies, you can use MicroPub with other vocabularies
tantek: e.g. you could use ActivityPub or Micropub to edit any URL potentially
tantek: while we are interested in social use cases, these technologies may also address other use cases. I'm looking for a path to harmonizing these efforts
<bumblefudge_> evans proposal was great can we all review it and 3xpand it and ratify it?
tantek: I dont want to pick a winner but i want to harmonize semantics that might allow for interop e.g. protocol verb semantics property semantics etc
tantek: this happens at w3c. groups are chartered to solve use cases and problem areas, rather than specific technologies
tantek: I encourage that. Keeping it broad. calling it social wg or something else. not specific to a technology
dmitriz_: +1 tantek on how CG can help with FEP process
dmitriz_: and helping get some to consensus
dmitriz_: I want to add that HTTP signatures is an excellent example of rthe power of CGs. There is already an existing WG at IETF bringing HTTP Signatures to a standard
<bumblefudge_> normative versus nonnormative distinction
dmitriz_: It doesn't need to be in scope for a Social Web WG. But the CG can make better example of where HTTP Sigs where before, where now, how to use them for max interop with social software. No WG is needed for that item
aaronpk: the way HTTP Signatures work is that its a framework. It defines how to pick parts of the message to sign. I'm a fan of the approach and its good
<snarfed> aaronpk++
aaronpk: You have to decide which things to sign. And that needs to be written down as a profile and decided upon and agreed to by community
<Loqi> aaronpk has 1 karma in this channel over the last year (100 in all channels)
<Zakim> tantek, you wanted to reply to bumblefudge__ and give example of Immersive Web CG/WG as noted in last week's meeting: https://
aaronpk: So to use it in activitypub we need a spec on how to sign the messages. Can't only delegate out to IETF. CG does need to do some publishing too
tantek: I want to propose some next steps
<nightpool> we also need backwards-compatibility guidance.... upgrading the network from draft-cavage is a very tricky problem without a straightforward solution.
<trwnh> +1
<dmitriz_> +1 nightpool, yeah. upgrade guidance
tantek: one step forward might be starting a wiki page in SocialCG wiki. Listing specific items for consideration
tantek: WG usually has to talk about its scope, deliverables, liaisons
<trwnh> i've seen it said that http sigs alone are a reason for activitypub to fail
tantek: I suggest starting a wiki page that is not definitive
tantek: get it down in one place and gauge support for various items. that's one proposal for how we can move forward
capjamesg: people interested in contributing to a WG should put their names forward
<tantek> we can capture scope (areas), deliverables (specifications), liaisons (which other orgs we should coordinate with)
<BobWyman> I suggest that the Working Group should be "broad but shallow." It should be a SocialWeb WG, not just ActivityPub, but it should be limited to eratta and clarifications, not addressing new issues (i.e. not deep).
capjamesg: rather than focusing on specific scope, we talked of so many things, i'd like to know whos interested in being in a WG
tantek: anyone should be able to access wiki
tantek: there shouldn't be a problem of access but if there is we'll fix it
capjamesg: No time made for TF discussion on list
capjamesg: I'll make sure minutes are posted in right place
capjamesg: If you have messages for chairs, message us
tantek: Thanks for those who woke up early.
nightpool: Thanks james for running meeting
<capjamesg> Thank you bengo for taking notes throughout!
<ckolderup> thanks james and thanks ben! thanks everyone!
<aaronpk> bengo++ for scribing
<Loqi> bengo has 1 karma over the last year
<capjamesg> bengo++ that was a _big_ help!
<Loqi> bengo has 2 karma over the last year
<nightpool> bengo++
<Loqi> bengo has 3 karma over the last year
<capjamesg> And thanks to everyone who attended! The notes will be distributed via the mailing list, GitHub, and W3C website.
<capjamesg> Thank you tantek.
<bengo> Thanks.
<tantek> bengo++ for scribing!
<Loqi> bengo has 4 karma over the last year