Social Web Working Group Teleconference -- 05 Dec 2017

<eprodrom> chairnick: eprodrom

<eprodrom> Can I ask for a scribe?

I can scribe

but my internet miiiight be flaky, we'll see. Rural England.

<eprodrom> rhiaro, thanks

<eprodrom> cool

<eprodrom> hopefully there are eccentric veterinarians having heartwarming adventures in your rural England neighborhood

<eprodrom> scribenick: rhiaro

reviewing minutes

<tantek> sandro++ for the lols this morning

<Loqi> sandro has 54 karma in this channel (61 overall)

<eprodrom> PROPOSE: Accept https://www.w3.org/wiki/Socialwg/2017-11-21-minutes as minutes for 21 Nov 2017 meeting

<eprodrom> PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-11-21-minutes as minutes for 21 Nov 2017 meeting

<eprodrom> +1

<rhiaro> +1 I was only in irc I think but I trust sandro's scribing

<aaronpk> +1

<cwebber2> oh shoot

<tantek> +1

<ben_thatmustbeme> +1

RESOLUTION: Accept https://www.w3.org/wiki/Socialwg/2017-11-21-minutes as minutes for 21 Nov 2017 meeting

eprodrom: they are fine minutes

<ben_thatmustbeme> i can fix up removing -DRAFT- and the perl output after

<eprodrom> PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-11-28-minutes as minutes for 28 Nov 2017 meeting

<sandro> +1

<cwebber2> +1

<sandro> +1

<ben_thatmustbeme> +1

RESOLUTION: Accept https://www.w3.org/wiki/Socialwg/2017-11-28-minutes as minutes for 28 Nov 2017 meeting

<rhiaro> +0 I wasn't there

WebSub

<tantek> +1

eprodrom: There were some issues backed up on websub, some that need feedback from the group

<aaronpk> https://github.com/w3c/websub/issues/146

<Loqi> [aaronpk] #146 At risk: limiting the use of HTML <link> to the HTML <head>

aaronpk: there was some discussion on 146, after the call I added the paragraph we talked about to security considerations. We didn't get al ot of additional feedback on that afterwards
... I don't know if we need to continue waiting on that or if this paragraph solves it

sandro: this is 8.1?

aaronpk: yeah

sandro: is that exactly the text I wrote or did you change it?

aaronpk: I think i'ts exactly the text

<Loqi> Sandro made 3 edits to [[Socialwg/2017-11-21-minutes]] https://www.w3.org/wiki/index.php?diff=105297&oldid=0

tantek: I think maybe some grammar tweaks but that resembles what I remember sandro saying

sandro: there was then a comment on the issue that I meant to reply to and didn't
... what if a CMS comes along that only allows custom code at the ned of the body tag

tantek: sounds like an faq rather than a disagreement with the text

sandro: what's the answer?

tantek: that the spec still allows that behavious. You're not non-conformant by putting it in the body

sandro: as soon as you do that then you're giving people incentive to do the wrong thing for security reasons

tantek: unless you have to do it for the moment and you file an issue on that CMS
... and you can fix it eventually. Both sides of that dynamic are not static
... I feel like especially in recent years brwosers have tightened up security in certain areas, even sacrificing certain site functionality
... the ecosystem is cogniscent of the issue, which is what the security considerations section is for, so the ecosystem will evolve in the right direction

sandro: I'm not sure I agree but I don't see what else we can do at this point

eprodrom: I've spent a lot more time thinking about this issue than I'd have liked. I think with security considerations (??) we should move on to other parts of websub

<aaronpk> https://github.com/w3c/websub/issues/150

<Loqi> [billc] #150 Temporary vs Permanent Redirect

aaronpk: one new issue came in asking a question
... I'm trying to understand the question

<aaronpk> https://w3c.github.io/websub/#subscription-response-details

aaronpk: about hte difference between 307 and 308 redirects in section 5.2
... this is if the hub is trying to tell subscribers to move to a new hub
... I don't htink we have thought of any situations that are meaningfully different between 307 and 308. I don't think we have any additional text we need to add. What do others think?

eprodrom: would it be worthwhile to say what you just said?
... 307 and 308 are treated as normal for http?
... they have the same meaning?
... I don't know if that's even useful. Seems like the default

aaronpk: it doesn't hurt to add it? It's not normative text
... if people think it would be more explicit for people who are reading this section

tantek: I feel like 307 and 308 were added because people treated 301 and 302 this way in the past. I would advise against saying treat them the same

aaronpk: treating them the same as in 307 is temporary and 308 is permanent so you would not store the permanent redirect if you got a temporary one, but if you got a permanent redirect you'd update the hub url

tantek: can we just reference http here and say there's nothing new?

aaronpk: that's exactly what evan was asying

<eprodrom> I dropped; calling back in

<ben_thatmustbeme> it only makes sense if you are storing the URL anyway

sandro: I don't think i'ts great practice to say there's nothing to see here move along

<ben_thatmustbeme> and it doesn't seem to make any sense

sandro: if we're just doing exactly what you're supposed to do then I don't think we need to say that

<eprodrom> Hmm

sandro: where things would be interesting is if the machine understood 308 and made some change, but that's not what anybody does with 308 as far as I understand it, I don't think we want to go there

<eprodrom> I'm having problems re-connecting on POTS, trying the webex site

aaronpk: also this is the section about clients subscribing, so the client is only ever going to hit the hub url after it's discovered the hub url

<tantek> ok

aaronpk: after 1 redirect it's gonna either discover the same old hub url as the topic the next time or the topic is going to be updated to point to the new hub url
... I don't htink there is any difference in handling

tantek: this sounds like an faq not like we need to add text to the spec

aaronpk: I'll just reply on github?

ben_thatmustbeme: the difference only applies if they're storing the url somewhere internally
... for the spec it doesn't matter, it's just a redirect
... it's whether they store that url or not

aaronpk: what I mean is, even if they store it they're going to be discovering either the old or new url again the next time they subscribe because they have to go through discovery again

<sandro> NOISE

<ben_thatmustbeme> robot evan

<eprodrom> That was me connecting via the browser

<eprodrom> They are, but Webex is not my favourite

sandro: you can reply to him saying we don't think the spec needs to say anything

<eprodrom> ha

<eprodrom> back!

<tantek> PROPOSED: Close 150 with no change to spec, treat as FAQ.

<sandro> +1

<eprodrom> +1

<ben_thatmustbeme> +1 though i don't even think it needs a proposal

<tantek> chair: eprodrom

<cwebber2> +1

<rhiaro> +1

<aaronpk> +1

RESOLUTION: Close 150 with no change to spec, treat as FAQ.

eprodrom: Anything else?
... especially issues

aaronpk: nope

eprodrom: that means that without any new issues we had a revised draft, right?

<aaronpk> https://w3c.github.io/websub/

<Loqi> [Julien Genestoux] WebSub

aaronpk: correct. The current ED is up to date with everything and I believe..

tantek: what about issue 149?

aaronpk: except for that, that's non normative

sandro: I'm waiting for the final draft to recirculate to the AC memembers
... I'm not sure if we're there yet or we're waiting for the acknowledgements esction

tantek: do we have a draft with the changes aside from the acknowledgements?

aaronpk: yes that's the current ED
... it has a changelog

<eprodrom> https://w3c.github.io/websub/#changes-from-03-october-2017-pr-to-this-version

eprodrom: is it worth waiting for the ack section or do we go with what we've got?

tantek: I feel like every day counts at this point
... looming publication moratorioum, and w3c tends to get backlogged at this time of year
... do we have the PR for ActivityPub yet?

various: yep

eprodrom: it would probably make sense that if it's a non normative change for the acks, let's recirculate it asap
... let's circulate what we've got and continue working on non-normative changes
... especially to those who had comments

sandro: there's been a bunch of editorial changes right?
... all those waiting for commenter issues
... has anyone else read over all of those?

aaronpk: a lot of them we discussed in calls at some point

tantek: do we have html diff of the PR vs this rec draft?

sandro: I will make one
... that's goign to draw people's attention to it and they're more likely to note typos and stuff
... I'll look through it and hopefully there won't be anything

eprodrom: so are we waiting for acknowledgements?

sandro: I'd rather send it out now

<aaronpk> here's the diff https://github.com/w3c/websub/compare/63ee7b8eb8eadf347f8e4a9c822bd3a14353b346...master#diff-4bc8b9d21d1d1c119135d766f41dd388

<tantek> +1

eprodrom: is that it for websub?

aaronpk: I believe so

ActivityPub

cwebber2: We made it to PR

<tantek> hey I see a PR! today!

cwebber2: hoorayy
... I don't know if there's more to say
... we don't have any new issues
... although rhiaro informed me that we had a comment that the contrast on the images was not strong enough for accessibility
... this had come up before when the person drafted the images
... they didn't want to change the colours because the images are supplementary to the text, there's nothing in the images that isn't said by the text and the colours were chosen specifically to convey information that would not be as well conveyed if we changed the colours
... we could tweak them but we would make the person who contributed them unhappy

<cwebber2> https://www.w3.org/TR/activitypub/#Overview

<ben_thatmustbeme> facepalm

cwebber2: I see what they're saying about the colours being to convey information. I think it wouldn't look as nice if I adjusted the contrast. I know they also chose the colours to not specifically convey a racial profile on the characters
... anyway i don't know what to do about that
... there are no issues formally filed

<ben_thatmustbeme> i think its more of the dark green test on light green background

<ben_thatmustbeme> and same for blue

<ben_thatmustbeme> text*

eprodrom: that is not a.. the person who made the contribution said they weren't willing to make changes?
... it's inbox/outbox that are..?

cwebber2: maybe we could.. the inbox and the outbox are the only things where it really matters

<tantek> I see it, the background "light" blue is not really light enough

cwebber2: I feel like i tdoesn't really matter if you can't see the face on the character, that's not really a big deal
... you can see a shape of a person
... it's really only the text

eprodrom: I'm of two minds, this seems like a really small thing to be putting all this attention into, but putting attention into accessibility is always if i'ts not a problemfor you it seems like a small thing, but if it is a problem for you it is a big thing

<eprodrom> outline on words?

aaronpk: I agree with Chris. I think a simple solution is to use white for the letters of the text to increase the contrast. Would mean we don't have to change any colours

<ben_thatmustbeme> I just don't know if that will work with the green

<ben_thatmustbeme> white or black, either way would add more contrast certainly

tantek: I can see that th edesigner of the images was trying to use the same colour for the labels to make it clear when they are the same thing

cwebber2: I feel like this can go down a deep bikeshed. We do have all the relevent information in the surrounding area. It would b enice if we can resolve this and preserve the aesthetics

<eprodrom> DROP SHADOW

cwebber2: I could try aaron's suggestion. I could also try evan's suggestion of just increasing the contrast on the text specifically

<ben_thatmustbeme> HAHA

cwebber2: NO

<Loqi> rofl

tantek: lighten the light colours uniformly
... that way you're not adding any *additional* colours, but increasing the contrast
... look at the example background that's yellow, right next to the images
... see how light that is. I don't see what would be lost by making the light colorus as light as that
... keeping the hue
... anyway..

<ben_thatmustbeme> can we just collapse the bike shed

<h> this is helpful testing graphics for colour-blindness http://www.color-blindness.com/coblis-color-blindness-simulator/

eprodrom: can we ask the commenter for suggestions?

cwebber2: we could, but I would prefer we try to handle it out of band and see if they're happy with it, cos I'd prefer to not get a response like turn it black and white

eprodrom: anything else on this topic?

cwebber2: I don't need anything else

eprodrom: I saw the note about the video sharing software, did we end up with an implementation report from them?

cwebber2: we probably should, I will reach out

working drafts for notes

eprodrom: publication moratorium coming up
... JF2?

<ben_thatmustbeme> https://dissolve.github.io/jf2/#change-log

ben_thatmustbeme: there hasn't been any changes in jf2 recently, it's at a fairly stable point. I've started to prep some things ready for a note. I don't know that there's much else to do
... basically just relabelling
... removed the implementaiton section because it doesn't make sense in a note
... I feel like that would be better on an faq or a wiki

eprodrom: these are the first notes we will have finished, do we need to review and vote on these documents going to note status?

tantek: I think i'ts less seroius than an updated working draft because we're saying .. we do need to resolve on a change like saying it's no longer rec track, we're going to finish it as a note
... I think after that echidna allows publishing iterations

sandro: I think we just need working group resolution to publish it as a note

eprodrom: the current version, or..?
... our next meeting is on the 19th which is the day after the moratorium.. I guess we could publish in the new year i fwe had voted to do so previously?

tantek: we discussed this last week, we can do everything to publish, and issue the publication request before the WG closes, just the publication won't happen until the new year, I believe

sandro: that's right

tantek: I don't think echidna can update notes
... We can update the published working draft with echidna, up to the 19th
... We can do all of that before and during the moratorium. What we can't do is actually publish the thing as a Note
... we leave the request in the system and it gets taken care of in the new year

eprodrom: if there is still editorial work to do on JF2?
... it sounds like the work is to remove a section
... I feel like we should put it on the agenda for next meeting to vote to goign to a note, and that would be the last step
... and we get it into the system and it's published as a note next year

tantek: are there changes in the ED right now compared to the published WD?

ben_thatmustbeme: changing a single word, removing the implemneations section, and maybe a couple of other minor text changes

tantek: I would still think i'ts worth it to have the group resolve to publish an updated draft

eprodrom: you had mentioned taking out the implementations section and it looks like that's already been done, so are there changes that need to be done in the next couple of weeks or are we ready to go?

ben_thatmustbeme: i was prepping it to be ready today if needed

eprodrom: maybe that's what we need to vote on right now
... If we are comfortable with doing that I would propose that we publish..

<rhiaro> I haven't read JF2 for a long time, didn't realise we'd vote today or I would have

<eprodrom> PROPOSED: publish current Editor's Draft of JF2 as a Note

<rhiaro> I don't feel particularly comfortable voting on something I haven't read

<eprodrom> -1

DENIED: ..

<ben_thatmustbeme> haha

eprodrom: pushing it onto the agenda for the 19th

<cwebber2> sounds good

<rhiaro> thanks!

<cwebber2> ty

eprodrom: I don't know if the other two note track documents would have the same kind of fate? are we ready to vote on either PTD or SWP?

<rhiaro> nope for SWP

<ben_thatmustbeme> would also like to reread those too

<rhiaro> But I will ahve it before the 19th in time for people to read it

tantek: we need two votes for PTD
... one to take it to note track

<ben_thatmustbeme> i think the term is "non-rec-track"

<eprodrom> PROPOSED: take Post Type Discovery to Note track

<eprodrom> +1

<rhiaro> +1

<tantek> +1

<ben_thatmustbeme> +1

<aaronpk> +1

RESOLUTION: take Post Type Discovery to Note track

eprodrom: SWP is note track.. can we take these three items for the top of our agenda on the 19th?
... and taht the group takes it as a task for the next two weeks to review these documents and get any issues in
... so we can resolve them before we go to a vote

<rhiaro> I'll do SWP this weekend

<rhiaro> PROMISE

<tantek> https://github.com/tantek/post-type-discovery/issues

tantek: in particular since I was working on PTD for rec track I was being a lot more diligent about issue tracking and trying to make things properly normative text. If you feel like this is something you must properly review please take a look at the issues and comment on the issues that you care about taht you want to see resolved before publication
... I'm specifically making this request because i'm obviously working on the document and I'm hoping to either get folks to contribute to the issues, or i fyou don't care then I'm going to expect that you'll +0 this in two weeks or something, than raise an objection. Please raise objections of any kind now rather than in two weeks
... if you're going to ask for tiem to review it, review the issues. don't ask in two weeks

eprodrom: we want to make sure we cover the rest of our agenda
... in particular discussion about new notes and indieauth
... this is something that would be considered as a note for the end of the year?
... I'm not sure who put this on the agenda

<aaronpk> https://indieauth.net/spec/

<Loqi> [Aaron Parecki] IndieAuth

aaronpk: yes, there is a draft ready
... this captures what has been implemented over the last several years and is in use by micropub clients and servers
... from many many wiki pages on the indieweb wiki which were documenting tutorials and such and this is basically a note that captures the current state of things

eprodrom: we have not previously done any kind of document around indieauth. I'm not saying it's a bad idea, I just want to make sure this is really late in the game. The idea would be that we would take what... it is an important part of the stack that includes micropub. It makes it relevent to what we're doing. I guess .. I wonder if it's .. is there a reason that the SWWG needs to be the one to publish this instead of having it in the socialCG or something

later on?

aaronpk: I think the fact that it's actually in use and implemented by SWWG specs is one aspect of that. This is not an aspirational spec, it is literally capturing what has been implemented
... that also makes it relevent
... tantek points out that this was covered in last week's meeting

eprodrom: i knew we had talked about it previously

tantek: your larger question about if the WG should do it rather than the socialCG, that was minuted last week
... I would prefer to not redo that discussion and just ask folks to read the minutes

eprodrom: okay
... My seocnd question is that procedurally what we would be doing is that the group would be reviewing this and the other note track documents for the 19th
... and we would vote then?

aaronpk: nobody has had a chance to review it before today because it was published today

eprodrom: I'm not tryign to be resistent to it, it's obviously important, it just hasn't had the same level of discussion in this group as the others have had
... it's ad ifferent level of review
... I'm willing to put the time in to take a look at it
... hopefully we can feel it's been hardened in the next couple of weeks, or it already has a level of maturity that doesn't need as much review

tantek: the document is new, but we cited it in our original charter from 2013 as one of the things that the group was going to discuss
... it's not really new conceptually
... it's definitely well established
... what's new is everything put together as a spec
... which does mandate some pretty good review

eprodrom: I might separtae those two items. the protocol itself and the document
... the document is new, the protocol is not
... I guess that's where my concern is but I think we can put some time in on it

tantek: the question I would ask is does the spec distinguish between what's implemented interoperably, vs things that maybe only one implementation does
... the point of these notes for the WG is to capture what's already interoperalbly implemented
... my concern would be if there are features that are are not by at least two

eprodrom: I think best case in this situation is generating issues and resolving them, by the time we get to our 12/19 meeting we have a sense as a group that htis is a well thought out document that we're comfortable publishing as a note
... the two toher less satisifying situations is that we don't generate *any* issues, or that we have a number of unresolved issues
... in the second case it may not make sense to publish it
... if we feel like we get to 12/19 and we have 10 unresolved issues and there's still a lot of conversation I'm not sure it makes sense for the WG to publish it
... that's editorial timeline

tantek: I don't think that's a requirement we have to place on our notes
... we're not trying to make them like a CR where we have to close all open issues
... Assuming there are open issues on the notes, I would expect each note to describe exactly what happens to the material in the note. In other words, where is the note being maintained beyond the WG. In the CG? In indieweb.org? Or some other third party?
... is nobody going to maintain it? that's fine too
... I would just want maybe in the state of the document, something about the future of the publication
... or see here for the latest update
... which i think we can require for all of ours
... like SWP, I can see continuing in the CG
... just for example
... like PTD, I'd expect to maintain in the indieweb community
... More imporatnt to me than closing issues is indicating the maintenence plans

eprodrom: Okay that makes sense.

<sandro> PLEASE LOOK OVER: https://www.w3.org/People/Sandro/websub/diff-20171003-20171129.html

<Loqi> [Julien Genestoux] WebSub

eprodrom: ??? socialCG

AOB

<eprodrom> 10+

eprodrom: okay let's talk about errata

<aaronpk> sandro++ fancy diff

<Loqi> sandro has 55 karma in this channel (62 overall)

<ben_thatmustbeme> +1

Errata

tantek: have any of our recs received issues post rec? Have the editors determined we need to make changes and determine errata? And has anyone tried publishing errata anywhere?

aaronpk: some on webmention. Some typos, some editorial clarification requests
... I have not figured out how to deal with any of that yet

tantek: basically all we have is today and two weeks from now to figure that out
... and to figure it out in such a way that you can complete that work mode going in the CG

sandro: I don't understand what you think the WG needs to do there

aaronpk: my understanding is that it' snot possible to update recs

tantek: if anyone in the WG cares how this is handled, make this statement about it. Or just hand over complete authority to the CG

sandro: No you hand it over to the normal post-rec-track process which is how it's always been at W3C. We just do it
... Every rec has a link to something, in our case it has a link to github
... so then it's up to the editors and staff contact and anyone who cares that any errata end up there
... if we have a CG that wants to take care of that that's great, but it's not up to the WG, I've never seen that done before

tantek: there's no 'normal' way this is handled at w3c. Most recs just don't get maintained
... this is an issue that the AB as a whole has noted at w3c
... so doing it the normal way is not an answer. That's why the WG should care. The WG should want to have an impact on this

sandro: in my experience, in all the specs I've been involved with, it is handled
... it's handled by the staff contact on their own time, and the editors. Whoever *was* staff contact 20 years ago, is usually still consulted, and the editors
... somewhere between them
... nobody still has to be at w3c
... I tend to put it into wiki space. In this case we put it into github space

tantek: we could resolve that we'll track our errata in github

sandro: that's what we did
... that's what our links point to, we can't change them now

tantek: are we okay with leaving it up to the editors and staff contacts to resolve issues?

sandro: you're only leaving it up to the editor to document th eissue cos you can't make a normative change

tantek: you can document a fix in the errata

sandro: you can say this is what I think the fix is, but you can't say there's a consensus

tantek: I guess I haven' tseen errata with that level of detail. Only just a list of fixes

eprodrom: there is a question about when something rises above level of erratum to next version of the spec
... I think of errata as typographical errors, clarity, missing words

sandro: if you want to make a normative change, I'm used to those being flagged in the list of errata as an open issue
... obviously you can't have wide enough consensu sto actually make a change until you have a new WG

eprodrom: do we have anything to act on right now?

tantek: I think even for normative changes errata are still useful to maintain and document
... regardless of whether there's a WG
... this group should try to keep doing that
... I would like to at least be able to delegate that authority to the CG
... to document consensus and issues, even normative ones, and add them to our errata accordingly

<ben_thatmustbeme> +1. its not that we are requiring the CG to maintain the errata, but it is giving permission for them to

<tantek> right

eprodrom: I guess my feeling is I would expect that the CG would start treating these documents as historical artifiacts of the past to be built upon

<Zakim> tantek, you wanted to chat briefly about maintenance and other notes? Vouch?

<tantek> indieweb.org/Vouch

tantek: one of the things webmention implementaion report mentions is interoperable implemenations of the vouch extension. Is this a potential note? I don't have it written up now, just a wiki page
... are people okay with writing that up?
... as a note

eprodrom: just from aprocess standpoint w'ere at a point where we have 4 documents for the group to review for 2 weeks from now. Adding a fifth might be a little bit too much to ask
... If there is a document that is ready for review before next week that's circulated and we have had enough people have read it by two weeks from now that we consider it for voting, I think it makes sense. Otherwise it's something for the future
... I think it's important, I do know that vouch is an important part of security in the webmention universe. It's okay for stuff to get published after we finish :D

<cwebber2> I think what eprodrom said makes sense to me

cwebber2: I'm cochair of the CG, aaron also needs to address this. I'm happy to take on errata work in the CG along with extensions. I'm unclear as to whether that's the right thing to do process wise

sandro: I have no problem with that, sounds fine ot me

eprodrom: FIN, thanks everyone

<eprodrom> trackbot, end meeting

- DRAFT -

Social Web Working Group Teleconference

05 Dec 2017

Attendees

Contents

reviewing minutes

WebSub

ActivityPub

working drafts for notes

AOB

Errata

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output