Social Web Working Group Teleconference

21 Nov 2017

Attendees

Present: tantek, cwebber, rhiaro, ajordan, eprodrom, aaronpk, bengo, sandro, tsyesika, csarven
Regrets Chair: tantek
Scribe: sandro

"Hubs may provide an additional HTTP [RFC7231] Location header (as described in section 7.1.2 of Hypertext Transfer Protocol [RFC7231]) to indicate that the subscriber may retry subscribing to a different hub.topic. This allows for limited distribution to specific groups or users in the context of social web applications."

sandro: Can we try hard to find out if anyone cares?
... it's kind of a back-door MUST on the subscriber library, as worded.
... I think it'll be easier to drop if we can find evidence no one has implemted it

aaronpk: impl rep fro twitch.tv

<ajordan> sandro: it seems backwards-compatible to me despite the quasi-MUST?

sandro: aaronpk can you ask everyone who has filed an impl report

tantek: Okay, that's the best we can do for now

ActivityPub

<cwebber2> https://activitypub.rocks/implementation-report/

cwebber2: We're doing really well
... 8 impls, 2+ yes on every item

<cwebber2> https://github.com/w3c/activitypub/issues

cwebber2: no open issues

<cwebber2> https://w3c.github.io/activitypub/#changes-31-october-14-november

cwebber2: relaxed from SHOULD to MAY on Liked property

<ajordan> a-

cwebber2: which we've had be a non-restart change
... also ld+json type thing, as in AS2
... also Forwarding mechanism, said you need to remove bcc

(but that never occurs)

scribe: no need to say what's stored
... those are all non-normative changes
... That's everything

tantek: any comments/questions on changes?

eprodrom: the only change that's a bit challenging is the "Liked" property, which was a SHOULD in one spot and MAY in the more detailed spot, so we just resolved it to a MAY. It was an error in previous version.

tantek: good to clarify in change long, that you made it consistent

sandro: column for number-of-yes's which turns green when it's 2 or more

cwebber2: sure

tantek: we had empty cells in websub report

+1 lets vote

<tsyesika> +1 on the voting :)

tantek: any more comments?

<eprodrom> +1 let's vote

<Loqi> [Christopher Allan Webber] ActivityPub

<tantek> PROPOSED: AP to PR with the non-normative changes https://w3c.github.io/activitypub/#changes-31-october-14-november

<cwebber2> +1

<rhiaro> +1

+1

<eprodrom> +1

<tsyesika> +1

<ajordan> +1

RESOLUTION: AP to PR with the non-normative changes https://w3c.github.io/activitypub/#changes-31-october-14-november

<aaronpk> 🎉

<Loqi> 😃

<ajordan> whoohoo!

<tsyesika> wooo! ^_^

<eprodrom> Wow

<eprodrom> BRAVO

<eprodrom> cwebber2++

<Loqi> cwebber2 has 103 karma

<tsyesika> cwebber2++

<Loqi> cwebber2 has 104 karma

<ajordan> cwebber2++

<Loqi> cwebber2 has 105 karma

sandro: REC will be past Jan 1

<ajordan> alright, gotta go, sorry! thanks all, and woot! we did it

tantek: so, we'll want to closely track issues that might come up until then

Back to WebSub

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

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

aaronpk: We didnt have an issue to track At-Risk

tantek: Do any implementations parse it outside the head?

aaronpk: We don't know

sandro: shocked we let an At Risk feature get published in a PR

tantek: Any evidence of subscriber implementations?

aaronpk: check suibscriber librariesa
... and check where it's published

tantek: what do webmention and micropub say about this?
... and LDN

aaronpk: webmention has no limitation

sandro: We have to find either (1) a major publuisher putting it outside the head, OR (1) a major subscriber that doesn't look outside the head.

aaronpk: Homework for me?

tantek: Looking at one library I know, ....
... Is there a test for this?

aaronpk: (don't remember)
... There is one HTML tag discovery for subscribers, and it's in the head
... there is NOT a separate test for it showing up in the body
... webmention also lacks a test for link outside head

tantek: procedurally, I feel like because no one commented on this, it should be dropped.

sandro: agreed, but what if there is a major subscriber / library which doesn't look outside head
... so it may be that everyone publishes in the head, so subscribers might just be looking in the head

aaronpk: This is HTML, but *most* implementations are for RSS and/or xml/atom, so this doesn't even come up

tantek: ask Ralph?

sandro: We should at least look / ask

aaronpk: Three reported looking in HTML. I'll ask them if they look only in head.

tantek: Any other proposals? Anyone want to keep the restriction-to-the-head ?

<cwebber2> +0

<tantek> PROPOSED: Resolve 146 as if the at-risk feature was dropped in CR to PR per no data on any known implementations of it.

<cwebber2> +0

+1 contingent on the three respsonses aaronpk said he'd get. If they have a problem then we re-consider

<aaronpk> +1

<eprodrom> +1

eprodrom: I was surprised to see HTML allowed link elements in the body

<csarven> oh shot.. i got disconectde

sandro: true, most publishers probably wont use the <body>

RESOLUTION: Resolve 146 as if the at-risk feature was dropped in CR to PR per no data on any known implementations of it, contingent on aaronpk asking for three responses regarding it.

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

<Loqi> [aaronpk] #143 hub vs subscriber in section 8

aaronpk: Kind of outside of scope of spec, because it's about publish-hub relationship.

sandro: SHOULD subscribers re-check?

aaronpk: they'll have to on expiry, and not until then

sandro: So, take this out? Since it's out-of-scope

aaronpk: I guess it's in there because the headers may be different than the subscriber originally found.

sandro: that sounds terrible

aaronpk: yeah, except the spec says the subscriber MUST NOT use the link headers to identify subscription (must use capability URLs)
... Or at least distinct URL

sandro: let's take out the sentence, more confusing than helpful

aaronpk: remove sentence about hub/discover, and change to the topic-url-may-be-different

tantek: Is it a ref to something elsewhere in spec?

sandro: No, because that's out-of-scope

aaronpk: Right
... Important part is to warn subscribers that topic may be different

sandro: Why send it? It seems bad

aaronpk: Agreed

sandro: May/Must/Should include it?

aaronpk: MUST

ajordan: The topic might still be useful, for dereferencing

sandro: Let's rephrase it as "topic url may be different", and see if commenter and julien are okay. this isn't normative,

aaronpk: right, this sentence is just providing a (confusing) example of WHY it might change

<cwebber2> thanks! bye everyone! :)

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

aaronpk: these were the tough ones, lots of easier ones

<tantek> hmm we need a PROPOSED

PROPOSED: delete problematic sentence "A hub MAY use discovery from time to time to detect changes in a topic's canonical URL and Hub URLs." and instead explain topic URL might change

<aaronpk> +1

+1 contingent on commenter and julien

<tantek> +1 with making it a Note:

<cwebber2> +0

aaronpk: green Note box seems too prominent

tantek: "for example"

<tantek> +1 with preceding it with "For example, "

RESOLUTION: delete problematic sentence "A hub MAY use discovery from time to time to detect changes in a topic's canonical URL and Hub URLs." and instead explain topic URL might change

<eprodrom> whew

<eprodrom> That was a long one

<tantek> sandro++ for scribing

<Loqi> sandro has 51 karma in this channel (58 overall)

<tantek> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

resolve 142 with comment that LINK header is not disallowed by 7231 or 5988, and informally, the author of 5988 (Web Linking) intended it to be allowed.
AP to PR with the non-normative changes https://w3c.github.io/activitypub/#changes-31-october-14-november
Resolve 146 as if the at-risk feature was dropped in CR to PR per no data on any known implementations of it, contingent on aaronpk asking for three responses regarding it.
delete problematic sentence "A hub MAY use discovery from time to time to detect changes in a topic's canonical URL and Hub URLs." and instead explain topic URL might change

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/11/21 19:34:47 $

Socialwg/2017-11-21-minutes

Social Web Working Group Teleconference

21 Nov 2017

Attendees

Contents

review minutes

websub issues

ActivityPub

Back to WebSub

Summary of Action Items

Summary of Resolutions