16:58:57 RRSAgent has joined #social 16:58:57 logging to http://www.w3.org/2017/09/19-social-irc 16:58:59 RRSAgent, make logs public 16:58:59 Zakim has joined #social 16:59:00 tantek: yeah but we're biweekly 16:59:01 Meeting: Social Web Working Group Teleconference 16:59:01 Date: 19 September 2017 16:59:25 present+ 16:59:34 ajordan: lol 16:59:34 chairnick: eprodrom 17:00:01 Strugee made 1 edit to [[Socialwg/2017-09-19]] https://www.w3.org/wiki/index.php?diff=104469&oldid=104461 17:00:07 present+ 17:00:12 can scribe 17:00:44 present+ 17:00:53 present+ 17:00:54 though I did leave my typing gloves at the office 17:00:57 scribenick: rhiaro 17:01:41 present+ 17:03:05 TOPIC: last week's minutes 17:03:07 https://www.w3.org/wiki/Socialwg/2017-09-05-minutes 17:03:26 PROPOSED: Approve https://www.w3.org/wiki/Socialwg/2017-09-05-minutes as minutes for 05 Sep 2017 telcon 17:03:41 SV_MEETING_CHAIR? 17:03:43 0 I wans't here 17:03:48 +1 17:03:57 tantek: you chaired right? 17:03:58 +1 17:04:15 yes 17:04:33 +1 17:04:49 eprodrom: do we have people who were actually there? sandro? 17:04:54 [AJ Jordan] AJ Jordan AJ Jordan at 2017-09-19T17:03:06Z (As seen today on the SocialWG call) @Christopher Allan Webber: I'm here to clack keyboards and ... 17:05:05 RESOLVED: Approve https://www.w3.org/wiki/Socialwg/2017-09-05-minutes as minutes for 05 Sep 2017 telcon 17:05:08 present+ 17:05:32 present+ 17:05:40 TOPIC: October meeting schedule 17:05:58 eprodrom: We have a proposal from tantek to continue with our every other week unless we have runover 17:06:21 ... My concern I think we have a december ?? 17:06:47 ... We are far enough along that it's going to be up to us to mess this up. My feeling is we don't need to do more than two during October. Any objectiosn? 17:06:52 sandro: seems good for now 17:06:58 q+ 17:07:13 eprodrom: 3rd, 17th and 31st of October 17:07:19 sandro: hallowe'en meeting yay 17:07:24 eprodrom: when is tpac? 17:07:27 :D 17:07:30 tantek: the week after 17:07:35 PROPOSED: hold telcons on 3 Oct, 17 Oct and 31 Oct 2017 17:07:41 +1 17:07:48 tantek: so far we haven't decided to meet at tpac 17:08:03 ??: Burlingate 17:08:08 Burlingame 17:08:11 ... San Francisco 17:08:18 "San Francisco" 17:08:23 Burlingame 17:08:23 eprodrom: do we still have time to schedule for tpac? 17:08:48 tantek: I don't know that we have a reason to 17:08:57 cwebber2: I'm going, not specifically for swwg, but I'd love to hang out and talk about that stuff 17:09:05 ... tantek suggested I set up a cg thing but I didn't 17:09:29 ... but I'd love to if someone else organised it 17:09:43 eprodrom: I feel like if we booked a room and some time we would fill it up with work that we don't necessarily need to do 17:09:59 cwebber: a ?? meetup sounds good 17:10:02 Eprodrom made 1 edit to [[Socialwg/2017-09-05-minutes]] https://www.w3.org/wiki/index.php?diff=104471&oldid=104202 17:10:07 s/??/BoF/ 17:10:13 RESOLVED: hold telcons on 3 Oct, 17 Oct and 31 Oct 2017 17:10:15 q? 17:10:20 I can't make 10/3 FYI 17:10:32 tantek: I think I owe you one 17:10:54 cwebber: I'm going to be at rebooting web of trust on Oct 3rd. I can maybe step away to be at the meeting. I also want to set expectations that I might not have that much to say because I'm representing a client all next week in DC and then I'm at rebooting web of trust, so that's going to take up a bunch of my time 17:11:16 10/17 I have conflict W3C #ab meeting 17:11:25 People with loud keyboards, please mute 17:11:27 ?? *typing* 17:11:36 sorry 17:11:39 so I'm -0 17:11:42 oh well 17:12:24 tantek: can we consider the alternates? 17:12:27 eprodrom: I don't have a problem with that 17:12:31 or 10/10 and 10/24? 17:12:53 tantek: next week also if we feel like we didn't have enough time today 17:13:05 PROPOSED: hold telcons on 10 Oct, 24 Oct 17:13:17 +1 17:13:20 +1 17:13:22 +1 17:13:24 +1 17:13:33 +1 17:13:34 RESOLVED: hold telcons on 10 Oct, 24 Oct 17:13:49 eprodrom: and if we get to the end today and we need one on the 26th we can do that 17:14:04 eprodrom: 26 September you mean? 17:14:11 TOPIC: ActivityPub 17:14:58 cwebber: Update on the test suite is that I've been working onit, had an unexpected item pushed onto the queue for it. Since Mastodon has taken the lead and a couple of other implementations are using http signatures be mandatory for server-to-server, I had to implement that 17:15:03 ... in the process I found out the examples had a bug in them.. 17:15:12 ... but got that implemented and checked it is interoperable with another person in the channel 17:15:31 ... I'm working on trying to get the.. I think the remaining two sections of the tests will be done at the end of october realistically 17:15:38 ... There is one major issue that came up this week 17:15:41 ... May be considered normative 17:15:47 https://github.com/w3c/activitypub/issues/256 17:15:47 ... Seems like a clear thing to do but I'm not sure if it's normative 17:15:48 [erincandescent] #256 Content type of server-to-server request bodies unspecified 17:15:50 ... an ommission basically 17:16:06 ... we didn't specify the mime type in server to server 17:16:27 ... as far as I know every implementation did this. It was just omitted. Something we should add. Not sure if it is considered normative, technically it's a requirement, but it was a bug in the spec 17:16:36 q? 17:16:40 ack cwebber 17:16:45 ... does this sound normative? 17:16:59 eprodrom: it does sound like it would be normative 17:17:05 perhaps normative but not substantive unless impls are not compat? 17:17:15 ... however from a practical standpoint I don't think it would have the same sort of effect as a normative change 17:17:27 sandro: is anybody going to have to change any code? 17:17:34 cwebber: not as far as I know, I think this is what everybody is doing 17:17:47 sandro: this was the implication of the spec all along we just didn't spell it out? 17:17:53 cwebber: right, it was in a different section 17:18:09 sandro: that's not normative. our spec didn't clearly communicate our belief but we didn't change our belief 17:18:14 tantek: this shouldn't be a surprise to anyone 17:18:43 ... if anyone can raise an objection saying they didn't think this was a requirement we have to reassesss 17:19:01 sandro: http signatures. Are we talking about a normative change to require them? 17:19:17 cwebber: No, in practice some implementations ... we left open the auth method 17:19:48 ... I have implemented it [in the test suite] because actual implementations will ignore the content that I send 17:19:55 sandro: do we have a non-normative reference about this? 17:19:57 cwebber: we do 17:20:02 Eprodrom made 1 edit to [[Socialwg/2017-09-19]] https://www.w3.org/wiki/index.php?diff=104473&oldid=104469 17:20:02 Eprodrom made 1 edit to [[Socialwg/2017-10-10]] https://www.w3.org/wiki/index.php?diff=104474&oldid=0 17:20:06 https://www.w3.org/TR/activitypub/#authorization 17:20:41 cwebber: this was the result that we came to because it wasn't clear waht the future direction was. I'm still not going to say that the worl dhas completely ... basically we left two routes, one was oauth2, one was LD signatures and http signatures 17:20:55 ... in practice http signatures has become required and the LD signatures has become optional 17:21:04 ... it's the in-practice what's being used route that we're seeing 17:21:22 sandro: what do you mean the LD signatures part is optional? 17:21:46 cwebber: it's being used in mastodon for the use case where... say you're doing a share 17:21:59 ... how does that server know that if it's coming from you, the other person really said that thing 17:22:10 ... it might not be feasible for themt o go back and retreive the original easily because of complicated access control stuff 17:22:21 ... you just want to make sure that person really said the thing that was forwarded 17:22:41 ... in practice mastodon realised that to make this work with AP they need the signatures 17:22:55 ... they're only being checked in mastodon's usage when someone forwards to their followers cos it was the top post in the chain 17:23:07 ... no other case is the signature actually checked. It's not required unless you're doing that 17:23:14 ... maybe not everyone on the cal is familar with this probelm 17:23:36 ... it sometimes results in a problem where the top poster in a comments chain gets comments from other servers and people in the thread miss out on messages 17:23:40 https://www.w3.org/TR/activitypub/#inbox-delivery 17:23:59 ... we worked out this forwarding mechanism that makes sure messages get sent to peoples' followers 17:24:21 ... that use case uses LD signatures 17:24:34 ... it's comparitively small 17:24:49 ... I'm not sure if I'll need to implement that in the tests as well 17:25:03 sandro: sounds great in terms of interop. Trying to think of how to best help people who come along and read the spec right now 17:25:12 ... they'll probably be a bit confused about what they're supposed to do 17:25:35 cwebber: it sounds like you're saying if it seems like things ar econverging shoudl we be nudging people? 17:25:47 sandro: yeahh th e two main ways are that we could take the oauth part out and just use the one that seems to be being used 17:26:05 ... or just have section 8 be a pointer to some document maintained by the CG that can refine this going forward and maybe eventually put it into a separate spec 17:26:25 +1 sandro 17:26:27 eprodrom: I would be really surprised if taking out.. I know tha tmastodon doens't use the c2s part. I would be surprised to remove that 17:26:41 ... but for s2s we wouldn't have any oauth stuff, it's gonna be all signatures? 17:26:55 in general we need to be converging the spec on what we know interops so we can increase chances of exiting CR sooner 17:27:11 https://tools.ietf.org/html/draft-cavage-http-signatures-07 17:27:12 eprodrom: I would love having oauth for c2s and having signatures for s2s and having that be it 17:27:17 ... HTTP Signatures is a draft? 17:27:22 cwebber: ietf draft 17:27:32 I think I agree with eprodrom just proposed 17:27:34 eprodrom: that means we can't reference it normatively? 17:27:41 sandro: right this whole section is non-normative 17:27:45 ... we can't require http signatures 17:27:55 q+ there is something very odd with an entire non-normative section that we are depending on for interop of a specific set of features 17:28:02 cwebber: I think we should leave the section non-normative and just remove the options 17:28:07 q? 17:28:08 q+ to note there is something very odd with an entire non-normative section that we are depending on for interop of a specific set of features 17:28:14 q+ 17:28:26 sandro: I don't really like the hack of marking the section as non-normative and still telling you what to do 17:28:40 q? 17:28:45 ack tantek 17:28:45 tantek, you wanted to note there is something very odd with an entire non-normative section that we are depending on for interop of a specific set of features 17:29:12 \o/ 17:29:15 tantek: I'm trying to understand what we're trying to do with this section 17:29:30 ... It feels like we're trying to express an expectation of a feature and yet we're trying to do it via guidence instead of normative text 17:29:35 ... doesn't feel right 17:29:38 cwebber: we did already do that 17:30:21 tantek: the spec advertises a set of features you get if you interop. We're trying to capture features that are essential noted by folks like mastodon. Good we're listening to our implementors. But not good it's in non-normative text 17:30:24 ... I understand why 17:30:33 ... THe reality is that part of the spec is not the same level of security 17:30:42 sandro: the normal solution is to put that in a Note or more mutable text 17:30:49 cwebber: I would be fine with that 17:30:56 s/security/maturity 17:30:57 ... having a document maintained by the CG is fine with me 17:31:28 ... evan? How do you feel about having pointers to an auth doc written by the CG which is mutable but starts out recommending what's actually in practice? 17:31:34 eprodrom: that sounds fantastic 17:31:48 ... I feel like it would decouple the auth part of the spec from the api part 17:31:59 tantek: this is for private content right 17:32:22 cwebber: not just. The forwarding use case .. it's most likely to protect private content becuase that' swhen you can't necessarily look it up. There are two other cases where you still want it 17:33:05 ... you could dial back and look at it publicly if it is public. But this means you don't hav eto do that 17:33:13 ... you can use signatures as a uniform method 17:33:27 sounds to me like it's not required if everything is public though.. 17:33:37 tantek: sounds like a path to this ability in the spec is how to handle private content 17:34:11 cwebber: verification is important. It's right that it's not required if things are public 17:34:19 ... you could use another mechanism which is to go look at the content 17:34:36 ... but it sitll is important that i fyou get a post to your inbox that says here's some content, you have to make sure that the contnet really is from that server, and there are two ways to do it 17:34:40 ... if it's public you can look at it 17:34:46 ... or in eithe rcase you can use the signature check 17:35:21 It would make me cry, that's for sure 17:36:28 jankusanagi_ has joined #social 17:36:33 PROPOSED: Remove section 8 on Authentication and Authorization from spec, move to pointing from security considerations to a mutable document maintained by CG which includes current deployment practices (OAuth 2.0 bearer tokens for C2S, HTTP signatures and sometimes Linked Data Signatures for S2S) 17:36:58 ^_^ 17:37:04 o_O 17:37:10 +1 17:37:13 +1 17:37:22 +1 17:37:28 +1 17:37:36 +1 17:37:38 +1 17:37:39 +1 17:38:04 RESOLVED: Remove section 8 on Authentication and Authorization from spec, move to pointing from security considerations to a mutable document maintained by CG which includes current deployment practices (OAuth 2.0 bearer tokens for C2S, HTTP signatures and sometimes Linked Data Signatures for S2S) 17:38:16 please mute 17:38:26 q? 17:38:29 ack ajordan 17:39:10 question: 17:39:34 are we specifying what type of document the CG might publish? e.g. Note? 17:39:39 fine with this either way though 17:39:47 eprodrom: good question 17:40:08 sandro: cgs can't publish notes. I think they're called reports 17:40:36 ... if we wanted to solidify it at some point, some w3c member like mozilla could turn it into a member submission and get it formally archived at w3c 17:40:44 eprodrom: this seems liek the right way to do things 17:40:49 q? 17:40:50 ... anything more on AP? 17:40:57 cwebber: in my view we've exhausted it 17:41:02 tantek: the new CR got published right? 17:41:05 cwebber: oh yeah. Yay! 17:41:06 😄 17:41:28 sandro: I just want to confirm our timeline 17:41:34 ... particularly I'm worried about the test suite and test results 17:41:37 ... do we have a results matrix yet? 17:41:52 cwebber: i didn't do that yet... implementationr eports or actual running test reports? 17:42:00 sandro: I mean an easy way to see how many tests are passed by implementations 17:42:11 cwebber: we don't have all the test suite done and I havne't been pushing people to use it, so no 17:42:24 sandro: we have about a month and a half to get enough test results to prove implementations 17:42:30 cwebber: it's gonna be difficult 17:42:35 ... I guess I have no choice 17:43:12 sandro: there may be some alternative. one alternative is we don't necessarily use the test suite to prove interop. There are other ways, that's the usual one. I can imagine in the s2s thing that it might be more demonstrative to show these two systems federate by running them by hand with people watching 17:43:19 ... that I think would suffice an dmight be less work 17:43:23 ... make sense? 17:43:41 cwebber: makes sense as an option. DO you think we should hold off on this until midway through next month to say it's an optino on the table? 17:43:54 sandro: I'm saying don't spend all your time getting a s2s test suite if your'e afraid it's not even gonna get done 17:44:02 ... if you know you can do it that would be great 17:44:20 cwebber: if there was an option for me to focus on my implementation and encouraging people to test implementations that are already happening 17:44:33 ... that's hwo mastodon dev was mostly done, gargon and puckipedia were testing their implementations until they worked 17:44:40 sandro: if there are three implementations that interop that's good 17:44:47 ... three makes the case 17:44:56 tantek: I'm not entirely comfortable with that 17:45:20 ... if interop is defined by how two implementations happen to work together, there's no guarnatee we've captured those details in the normative spec 17:45:41 sandro: if you have three and one is written by the editor that.. that's the same guarantee as if the test suite aligns with the spec 17:45:55 ... if the editor is making an implementation and that interops with two external ones, that's a good case we have interop 17:45:58 ... and I think s2s testing is really hard 17:46:02 tantek: right about that 17:46:12 aaronpk: I would have beend one with websub and micropub a looottt sooner... 17:46:26 tantek: the big concern is because the editor is doing both there are assumptions that are not reflected 17:46:32 sandro: that's why you have those two other implementations 17:46:44 tantek: at that point the third implementation might as well be the test suite rather than a third implementation 17:46:59 sandro: if you want to call it the test suite sure, but it wouldn't be doing the same thing as what a test suite would do because it would be driven by hand 17:47:11 q+ 17:47:13 tantek: I don't think tha'ts accurate to call it a validator 17:47:21 ... we noted it as such as a distinction from a regular implementation 17:47:48 sandro: I think the AP s2s test suite / validator, we can think creatively about it 17:48:03 ... it doesn' thave to be a thing you can connect to and run automatically 17:48:09 tantek: I think driven by hand is fine. No requirement for automation 17:48:27 sandro: the standard I just specified is lower than what i was saying before because it doens't invovle puckipedia and mastodon talking to each other 17:48:57 tantek: you're saying we define interoperation by checking that these two interop. We need a textual description of what should happen when you runt wo implementatiosn against each other. That's a test suite. 17:49:06 ... You can't avoid documenting hte epxected result 17:49:08 sandro: agreed 17:49:12 cwebber: There's some good news 17:49:32 ... When I initially was working on the test suite, I implemented this promty thing that asked you questions 17:49:44 ... and the response was you don't want to give people that many prompts 17:49:57 ... I can start implementing and see if it can be automated, and if I can't I can have it be a bunch of questions that people can respond to 17:50:01 ... and accomplish that way faster 17:50:03 sandro: sounds good 17:50:12 tantek: that's a better approach 17:50:19 sure did 17:50:58 cwebber: knowing that I think we have a safe way forward 17:51:08 q- 17:51:09 ... I'll switch to the prompty question direction if automatiion doesn't work 17:51:15 q+ 17:51:25 ack ajordan 17:52:01 ajordan: if we're going down the prompty path, which seems fine, after we ship a rec I think it would be nice to go back and make that stuff automated, to make new implementations easier 17:52:15 cwebber: the path will still be left open to code i nthe automated tests 17:52:36 TOPIC: WebSub 17:53:25 eprodrom: status 17:53:35 Someone has background chatter going on 17:53:39 rhiaro: jinx 17:53:49 Please mute if you're not on 17:53:58 aaronpk: we have a couple of issues that popped up since ralph started looking 17:54:02 https://github.com/w3c/websub/issues/125 17:54:03 [sandhawke] #125 Hash Algorithm Selection 17:54:11 ... the biggest one is the hashing algorithm thing 17:54:24 OK I gotta go to class but just want to say that I've finally been sending stuff to ben_thatmustbeme 17:54:35 nothing major, lots of clarifications merged 17:54:35 ... essentially PuSH had only specified sha1 as the only valid hash algorithm. A while ago we had added other algorithsm and sha1 is mostly broken now 17:54:56 ... but then there was a concern that servers and the hub need a way to negotiate which algorithm to use, which is a rather large new mechanism to add 17:54:57 bye all! thanks for a good (partial) meeting 17:55:25 ... the current proposal is to drop all the new algorithms from the spec, goign back to the way it was in PuSH and then mention that we may add new algorithms as an extension so we can actually better specify how these algorithms are negotiated 17:55:31 ... is that fair sandro? 17:55:37 sandro: I was not proposing formally dropping the other 3 17:55:43 ... that struck me as hard to do without restarting CR 17:55:55 aaronpk: I guess I was assumign that the... oh you're right the proposed text doens't drop th eother three 17:56:03 ... that leaves it in the same sort of undefined state 17:56:14 sandro: i"m not thrilled with the undefined state but I think tha'ts the most expedient way forward 17:56:42 aaronpk: julien's comment is that it's not a big deal to use a weak hash beacuse if you're also using https there are a lot of layers to break before you can take advantage of a weak hash 17:56:50 sandro: and also if the callback url is secret that also protects you 17:56:53 aaronpk: yeah right 17:57:07 ... there's a bunch of layers that are useful even if you have no secret, no hash 17:57:17 sandro: julien's wrong though 17:57:25 ... *reads from issue* 17:57:33 ... the attacker is trying to alter the content 17:57:38 ... not read it 17:57:51 ... but as long as it's over https, you could put the secret in cleartext in the packet and it would be fine 17:57:57 ... you'd still have to break tls to get through that 17:58:26 aaronpk: the suggestion is to drop the undefined extension 17:58:30 ... makes sense to me 17:58:35 ... and we don't bother with the rest of the issue? 17:58:45 sandro: I think so. If somebody wants to go ahead and write otu that formal extension 17:58:57 ... I think the two reasonable options are my proposed text, or we specify the extension now and do another quick cr 17:59:05 aaronpk: that seems like a pretty drastic thing to be adding 17:59:11 sandro: my guess is nobody has the energy to do that 17:59:14 tantek: I lost track 17:59:26 sandro: I'm not advocating define the negotiation mechanism now 17:59:31 ... tha twould be too much work 17:59:35 tantek: which spec change are you advocating? 17:59:42 sandro: the one that's described in issue 125 17:59:49 ... remove one sentence and replace it with those two sentences 17:59:58 tantek: and that leaves an opportunity for a later spec to say something? 18:00:00 sandro: yeah 18:00:06 In the future, an extension may be specified allowing subscribers to indicate which algorithms they can use for validation. As of this writing, most hubs sign with SHA-1, despite its known cryptographic weakness, in order to be interoperable with older subscribers. 18:00:09 aaronpk: it explicitly says we should define the algorithm extension as an extension 18:00:17 s/algorithm extension/algorith selection 18:00:20 JanKusanagi has joined #social 18:00:29 tantek: aaronpk can you take that up as a CG item? Create an issue? make sure it continues 18:00:32 aaronpk: yeah 18:00:41 sandro: put the timeline as around the time TLS is broken.. 18:01:28 PROPOSED: Resolve websub #125 by accepting proposal as written 18:01:28 aaronpk: resolution on proposed text? 18:01:38 +1 18:01:40 +1 18:01:40 +1 18:01:43 +1 18:01:47 +1 18:01:58 +1 18:02:09 RESOLVED: Resolve websub #125 by accepting proposal as written 18:02:45 tantek: the text sandro put does touch on a security vulnerability, could you include a list item in security & privacy considerations that calls it out explicitly? 18:02:48 aaronpk: good idea 18:02:50 sandro: yeah 18:03:30 sandro: and I think if the CG puts together an editor's note type thing in github we could probably link to that as an example 18:03:36 ... when the rec actually goes out 18:03:56 ... that's a reason to write up a draft for the extension in the next few weeks if somebody feels motivated 18:04:32 sandro: 124. We have this content negotiation solution we came up with a while ago. Richard the i18n guy pointed out there's language negotiation too 18:04:37 ... and he's asking if we forgot or chose not to do it 18:04:40 ... and could we do something about it 18:05:05 ... I think the answer is we forgot and should include text saying for either content type negotiation or language negotiation you should be doing the same thing 18:05:08 ... I think that solves the problem 18:05:26 eprodrom: next step? 18:05:31 sandro: ben has suggested some text 18:05:38 aaronpk: I want to rephrase that slightly but it has the idea 18:05:46 sandro: sounds good to me 18:06:29 ... shall we delegate to aaron to adopt something similar to ben's text and say we'll try to also get richard's approval but I don't think we need to 18:06:57 PROPOSED: Resolved websub #124 with something like https://github.com/w3c/websub/issues/124#issuecomment-330580664 but actual working up to editors 18:06:57 [dissolve] Suggested text 18:06:57 For practical purposes, it is important that the rel=self URL only offers a single representation. As the hub has no way of knowing what mime-type or language may have been requested by the subscriber upon discovery, it would not be... 18:07:15 (it's non-normative -- it's explaining what's implied already) 18:07:37 s/working/wording 18:07:52 +1 18:07:53 +1 18:07:56 +1 18:07:58 +1 18:08:22 eprodrom: any objections? 18:08:29 ... anyone still thinking? 18:08:29 +1 18:08:29 RESOLVED: Resolved websub #124 with something like https://github.com/w3c/websub/issues/124#issuecomment-330580664 but actual wording up to editors 18:08:30 [dissolve] Suggested text 18:08:30 For practical purposes, it is important that the rel=self URL only offers a single representation. As the hub has no way of knowing what mime-type or language may have been requested by the subscriber upon discovery, it would not be... 18:08:55 sandro: can we have another resolution to request PR? 18:09:00 tantek: good idea, with the new approvals 18:09:03 +1 18:09:21 PROPOSED: Advance Websub to PR upon completion of issues #124 and #125 18:09:36 Hmm, why does #124 not propose the option of multiple hubs? :P 18:09:58 +1 18:10:01 +1 18:10:01 Tantekelik made 1 edit to [[Socialwg/2017-09-19]] https://www.w3.org/wiki/index.php?diff=104476&oldid=104473 18:10:04 +1 18:10:10 +1 18:10:13 +1 18:10:20 +1 18:10:51 RESOLVED: Advance Websub to PR upon completion of issues #124 and #125 18:10:56 sandro: aaronpk can you do these changes today? it would be nice to get this stuff off 18:10:59 aaronpk: yeah 18:11:05 tantek: and update the changelog 18:11:10 aaronpk: yep 18:11:20 eprodrom: that wrap sthings up for websub? 18:11:45 TOPIC: AOB 18:11:53 TOPIC: Post type discovery 18:11:55 tantek: nothing this week 18:12:04 TOPIC: jf2 18:12:31 tantek: I think ajordan submitted a bunch of patches and ben merged some of them but we dno't have aj or ben 18:12:34 TOPIC: SWP 18:12:51 rhiaro: Nothing to report 18:13:04 TOPIC: SWICG update 18:13:26 cwebber: only thing is that we have a new member of the group who is excited about anti abuse stuff 18:13:36 ... so we should discuss that next week 18:13:59 tantek: cwebber can you email Coralie Mercier requesting space and time at tpac for the social cg 18:14:38 coralie@w3.org 18:15:04 ... THe CG has enough stuff to discuss 18:15:09 ... We could also do a break out 18:15:12 eprodrom: I think that concludes 18:15:24 tantek: next meeting in 3 weeks, 10th October 18:15:43 trackbot, end meeting 18:15:43 Zakim, list attendees 18:15:43 As of this point the attendees have been eprodrom, rhiaro, ajordan, aaronpk, tantek, sandro, cwebber 18:15:51 RRSAgent, please draft minutes 18:15:51 I have made the request to generate http://www.w3.org/2017/09/19-social-minutes.html trackbot 18:15:52 RRSAgent, bye 18:15:52 I see no action items 18:15:52 rhiaro++ 18:15:52 rhiaro has 159 karma in this channel (278 overall)