From W3C Wiki
Jump to: navigation, search

Social Web Working Group Teleconference

01 Nov 2016

See also: IRC log


aaronpk, tantek, annbass, rhiaro, sandro, wilkie, cwebber, julien
ben_thatmustbeme, csarven

<scribe> scribenick: rhiaro

<annbass> Hiya


Upcoming f2f

tantek: 6 people signed up
... and some remote
... not too bad

<julien> I am trying to call in

tantek: could use more

<cwebber2> oh yeah sorry

tantek: cwebber2, add yourself if you're coming

<cwebber2> I'll be there


<Loqi> Social Web WG Face to Face Meeting at MIT (F2F8)

<annbass> Regrets for F2F


approval of minutes 2016-10-25

<rhiaro> +1

<tantek> PROPOSED: approve minutes

<rhiaro> +1

<sandro> +1

<aaronpk> +1

<tantek> +1

<wilkie> +1

<annbass> +1

RESOLUTION: approve minutes

CR status for LDN

rhiaro: Approved and published

tantek: congrats, fastest to publication from FPWD
... Announcement should go out soon
... Spread the word

Webmention PR status

<Loqi> Rhiaro made 1 edit to Socialwg/2016-11-01

<Loqi> Rhiaro made 1 edit to Socialwg/ActivityPub wide review

<Loqi> Cwebber2 made 7 edits to Socialwg/ActivityPub CR Transition Request

<Loqi> Cwebber2 made 6 edits to Socialwg/ActivityPub wide review

rhiaro: Approved yesterday, published today

<Loqi> Cwebber2 made 1 edit to Socialwg/2016-11-17

tantek: this is our first PR, congrats

<annbass> wOOt!!!

tantek: The announcement goes out, to the AC for a vote

<Loqi> 😃

tantek: Composed of w3c members and assuming a sufficient number of them say yes, and no formal objections, it proceeds to rec
... I forget how many weeks they have to vote
... I think it's 4
... In particular I want to encourage everyone who has yet to file an implementation report to please do so
... And for LDN as well
... Instructions are in the drafts
... But for the PR, now it's going to every member of W3C that they need to vote on
... one of the things they look at is who is implementing it, how many there are
... These might be people who have never heard of it before
... So the more implementations we have, the more it looks like ther'es a community, it looks real


tantek: I would recommend that our other CRs look at that and see if they can use the pattern in terms of providing a summary
... aaronpk, any comments?

aaronpk: I don't think I have anything to add

<sandro> FWIW -- LDN FPWD -> CR in 98 days (aka 3.2 months aka 14 weeks)

tantek: It appears that there are more implementation reports than there are in the summary, correct? Is it behind?

aaronpk: I think the summary is up to date
... there are more things in that folder than are in the summary, but they're not all reports

tantek: I was seeing ten implementation reports

aaronpk: yeah there are ten in the summary and in the folder

AS2 CR-> PR status

<wilkie> evan sent regrets

tantek: Any sign of Evan or James?

<aaronpk> tantek disappeared

<aaronpk> back

tantek: okay, skip until james shows up

<aaronpk> maybe it was on my end then


cwebber2: We're ready!
... So let me link...


cwebber2: This is the transition req document

<sandro> ? down

cwebber2: The current Ed which we had discussed releasing a new WD of, with a changelog


cwebber2: I have the links to the implementation report and test suite, but they're not in place. I just registered the domain. They're is not actually anything there, I was told I need to get the stubs in there

sandro: but there will be at least a landing page?

cwebber2: There will be yeah
... No problem
... I just got that in place last night


cwebber2: In terms of wide review, I've collected in addition to issues the offlist feedback Iv'e had
... That I've requested I can make it public, there are very large amounts of detailed feedback here from people outside the group
... I think this is in a good state
... So I'll hadn off to tantek to ask what the next step is and if we can request a vote to move to CR

tantek: Open issues?


tantek: I know you've been working really hard on those

cwebber2: The only issues left open are all editorial, except for one which is postponed that we talked about last week
... one is get AP terms in the AS2 namespace
... and the test suite one
... Everything else in there is editorial

sandro: the non-editorial ones are todo list items?

cwebber2: Right

tantek: *sounds of thinking*
... Having links in the draft should satisfy the test suite and reporting section..

cwebber2: I'll close the issue then

tantek: I believe that's covered, not an issue against the draft

<annbass> (rhiaro's scribing makes me smile)

tantek: The AP terms and AS2 context, I'm not entirely sure what that needs

rhiaro: I took that as a todo, still haven't done it, will do



sandro: as extensions to AS2?

<Loqi> Cwebber2 made 1 edit to Socialwg/2016-11-17

cwebber2: rhiaro and I need to work on making sure that happens

rhiaro: I'm on it, just haven't done it yet

tantek: if you want to add that to the CR transition request as something that we'll call out so ralph can see we're taking care of it

<rhiaro> I'd hope to have that done before the transition call, but yeah

tantek: if we can get to CR before the f2f that would be great
... This is awesome, as far as I can tell you've checked off all the itmes
... Anyone else?

<tantek> PROPOSED: transition ActivityPub draft at to CR

<cwebber2> +1

<rhiaro> +1 :D

<sandro> +1

<annbass> +1

<wilkie> +1

<aaronpk> +1

I note that csarven added a +1 to this last week on the wiki

<annbass> Indeed, kudos to cwebber2

tantek: you've had more last minute issues than any other spec we've seen chris, so that's a lot of hard work, well done

<sandro> csarven: +1 by proxy

RESOLUTION: transition ActivityPub draft at to CR

<cwebber2> \o/

<annbass> Woohoo!

tantek: rhiaro, setup a transition call, let's make this happen
... I don't see any issues with the call based on our experience to date


cwebber2: another happy bit of news is we had someone external email me and plan to do an implementation and even put it on the site of the thing they're working on
... a federated hackernews/reddit alternative

<annbass> That's neat!

<annbass> Hehe

<cwebber2> ha

PubSub WD->CR status

tantek: julien?


julien: there are a lot of open issues, we've discussed and closed
... The naming issue is still bothering me. I don't know what to do here.

tantek: let's take that last
... Any other issues you might want our help with?
... Looks like there are 23 open issues. Are there any that you believe you could make faster pgoress on with input from the group?

<cwebber2> ohhh shoot

julien: fat pings vs thin pings... I was very confused by the turn of the discussion
... I thought fat pings were the way to go


julien: but obviously not everyone thinks that

<cwebber2> +q for after PuSH talk to vote on new WD of AP

julien: two issues around it
... also 27


<Zakim> cwebber, you wanted to discuss after PuSH talk to vote on new WD of AP

back to AP briefly

PROPOSAL: publish existing ED as a WD immediately

<cwebber2> +1

<tantek> PROPOSED: as a new WD of ActivityPub

<cwebber2> +1

<aaronpk> +1

<tantek> +1


<annbass> +1

<wilkie> +1

RESOLUTION: publish as a new WD of ActivityPub

back to PubSubSomething

tantek: back to fat pings and thin pings
... what's required and what's not


aaronpk: This is about issue 27, I created this to try to ask for help finding documentation on current behaviour of fat pings

<Loqi> Cwebber2 made 1 edit to Socialwg/ActivityPub CR Transition Request

aaronpk: In my research I was not able to find much about the actual payload that's sent in fat pings
... We have some links now

<csarven> Sorry.. was AFK. +1 :)

aaronpk: But I'm still not super happy with the state of this
... The main goal of this thread was if the spec is going to recommend or rquire that fat pings are used it absolutely must say what the payload is
... Otherwise it's not really useful as a suggestion
... So I was hoping to collect examples of what people are sending in order to turn that into the recommendation of what the content is

julien: for wordpress and google and superfeedr, we tried to point to the PuSH spec which we thought was giving a good description of the contents of the payload
... being a diff of what was being subscribed to
... this needs clarification in the spec now
... the hub MUST send fat pings, but we cna't prevent the subscriber from ignoring that fat ping

aaronpk: that makes sense
... the other source of confusion is the spec describes this vague idea of diffingw ithout actually saying it works

julien: that's a problem I've had for a long time
... diffing has different meanings based on the content type
... you could diff on the entry level... what does it mean for a json document?
... I'm not sure what's the right approach here
... I'd rather diff based on the capabilities of the content type
... rather than a dumb diff on the text level
... but if we have to do that to make the spec forward, but I'd rather not

aaronpk: that's why I wanted to collect examples of what is done with rss, atom, html, json, and looking at actual examples
... but I couldn't find any
... I totally agree having content type specific idffing is way more useful
... but I couldn't find what is being done right now

julien: We talk about diffing, maybe there's room for saying that rather than diffing by default the hub sends the full content of the resource and the client has to find what is new or different in the payload
... that would basically mean the hub doesn't have to deal with diffing
... the subscriber has to find a way to identify what's missing, new or updated

aaronpk: I think that's an acceptable solution

<wilkie> diff'ing as an extension

sandro: I'm a big fan of ... there are conflicting things between simplicity and efficiency
... simplicity would be just send the new content, but in some cases that would be painfully inefficient and we'd wish we could send a diff
... In terms of technology for diffs, within the general http stack I think that's mostly under patch, right?
... I dont' know how much the PATCH verb has caught on. I've seen a couple of media types, two different json patch media types
... that seems like th eright... however people are using PATCH
... if you're using json-patch to patch json,t hen presumably you should be sending that as your fat ping
... on a json resource

julien: then the spec would just leave ?? the right diffing mechanism to each content type
... if you're using json you us ejson-patch, if your'e using rss/atom then you do per entry

<tantek> good question re: PATCH (how much has it caught on?). IMO from a newish W3C process perspective, PATCH has been insufficiently incubated (not enough actual prototyping to show that it's worth depending on).

sandro: the problem with that is that there isn't one... there are at least 2 different json-patch protocols

julien: it's worse for images, how do you diff an image?

sandro: I think if you don't have a good diff mechanism... you could do it, complicates the protocol maybe, when you're sending a patch the way you're supposed to know what media type ot use is you get an accept-patch header earlier in the process
... if we can fit that in the hub could, if it gets an accept patch, and it knows how to do that media type,then it MAY or SHOULD send patches using that
... if it doesn't know that, it sends the whole content

julien: that's exactly how superfeedr works
... at the hub level we look at the accept header upon subscription
... if they accept json we do the conversion form rss to json
... and when the content updates we send the json rather than rss
... this could work for me, saying what the subscriber provides defines what the hub sends in the notification
... and we need a way for the hub to tell the subscriber that it doesn't understand the accep theader


sandro: There is this accept patch header in rfc
... we have to see what the logic there is, along with the logic pubsub uses, and see if they can fit together

tantek: sounds like you and aaron were coming to some common understanding?

julien: I'll start working on the summary and then aaron we can iterate from there

tantek: sounds good

<Zakim> tantek, you wanted to note need to separate what we *could* do with PubSub, vs. what documenting (specing) what we believe implementations *already do*

tantek: I think it's good to consider how pubsub could do this in ideal conditions, maybe in the future. However for the purposes of what we need to scope and ship in this WG we need to limit ourselves to what we believe implementations already do and use that as a very strong constraint
... If there is a potentially better solution with diffing or patch or something which we don't know or we don't know of any implementations, that may be worth opening as a separate issue, as like an enhancement request, but not necessarily for this version of pubsub
... which I believe pretty strongly we need to constrain to what we have implementations doing today
... so we can get it through the w3c process

sandro: I agree that makes sense
... it may be that diffs and patch are all a straightforward obvious extesnion and the part we standardise here is always about sending the whole content
... I'm prefectly comfortable with that
... and efficeincy being an extension

tantek: we're not trying to shut down discussion, its' good for us to keep an open mind
... and yes, document it
... if it ends up that solidifies into an extension that we can tell people to start playing with, that's great, but it's a different scope and timeline than the pubsub spec itself
... we might even manage to publish an extension as a note, but I don't think I'd want that to delay the spec itself
... just my opinion
... not a chair statement
... Sounds like we have a good understanding of issues 27 and 35
... sandro, could you open that as an enhancement request issue
... julien if you could separate the optimal way form what implementations to today

julien: will do

tantek: what next?

julien: most of the other ones are either fixes that are obvious or clear decisions, eg. the algorithms in the signature
... I don't think there are other significant ones, but maybe someone will disagree... one oabout the verbs but I don't thin it's worth changing what we've done so far
... 28


julien: The current spec was not 'rest' enough
... we were using GET and POST in ways that did not necessarily abide by the rest philosophy
... I think the current spec is fine
... makes a reasonable distinction

aaronpk: I agree no change is needed for that. Seems to be a slightly unusual use of a GET but not the end of the world, and it's what everyone does already

tantek: is there a security issue with potential misuse of get?

julien: one person also suggested that we use a signature mechanism for setting up subscription
... and I think that would solve security misuse of GET in that context

tantek: do you have a proposed resolution?
... I'm not hearing a lot of dispute

julien: what I"ll do is put a longer comment in the issue thread and maybe not close it right away, and ask for feedback

tantek: okay, we'll leave it open for now
... if it comes ot a point wher eyou're not making any progress but you feel like you have some consensus, then bring it back to the WG so we can close it and move forward

sandro: This is one of these cases where this comes up with a potentially breaking change. We're all tryign to do this without any breaking changes so that all existing implementatios remain conformant. If we have to do a breaking change we'll think long and hard about it. right?

julien: Definitely to try to maintain everything or at least provide only little change. This would be very significant

tantek: I tend to agree. I personally would need to see for a breaking change, a security flaw that would motivate the current implementations to update
... Anything short of that I'm not sure I would support

sandro: I'd be hesitant to do anything that would fork the community into people who are still using pre-w3c PuSH
... I want them to be on board without doing anything

tantek: maybe that's something we can resolve

sandro: I don't think we need to make a formal policy

tantek: okay

julien: and then... the naming.

aaronpk, you have twitter poll results in?


<aaronpk> current twitter poll results: Screen-Shot-2016-11-01-10-52-25.png

<aaronpk> PushCast is in the lead

I LOVE that hubbub got loads of vote

that was a joke

tantek: I don't really want to use twitter poll sfor this type of thing...

aaronpk: an interesting survey of people who are not us, not a deciding factor

sandro: one of the problems I have with pubsubhubbub as a name is the abbreviate of PuSH. This is not 'push' as a web developer understands it
... specifically server to client, which is not the webhook kind of thing that this is

aaronpk: that's true, and also server to phone, apple and google's push apis

sandro: push is all the way to the end user, not an internal node to node like pubsubhubbub is

<annbass> Seems like a good point, from a 'novice' Point of view

tantek: I guess I always thought of what you're calling push as server push... I can see your point

julien: this is just one of the problems with the naming

<annbass> (That would be me... the novice)

julien: pubsub also has a lot of other meanings
... all of the names have been used before for something else

<sandro> websub ?

julien: hard to find somehting both new and descriptvie

tantek: let me try to roll this back. We had a strong consensus to go with pubsub last time we discussed this, f2f in Lisbon
... to change that we're going to need new information that we did not come up with in the discussion
... We knew pubsub was generic backthen, we decided to go with it anyway

<cwebber2> aw phone disconnected :(

<cwebber2> ok, what I was going to say, I think we agreed on pubsub for the short name

tantek: we knew that it was superior to pubsubhubbub in terms of pronunctiation, especially for non-native English speakers

<cwebber2> for ids at least

totally, cwebber2

tantek: any actually new information?

sandro: I hadn't thought about the search problem when we had that discussion

<cwebber2> personally I don't care if we leave it as pubsubhubbub... at least people know what that is

sandro: like in regsitries, not just search engines, don't have smart search

julien: definitely, the name is taken everywehre

tantek: the web search arguement I'm not as worried about
... pubsubhubbub has a lot of history and uptake in the past so it's easier to find
... web search is a lagging indicator of uptake

sandro: the name pubsub is never going to be unambiguous
... in a respository or software directory
... eg. redis has a pubsub, their modules show up as well

tantek: so if it's already a problem why should we ..?

sandro: It's nice for us to steer clear

<rhiaro> I have

<rhiaro> I didn't think of the search/generic thing

<cwebber2> I don't have strong opinions but

tantek: anyone else changed their mind since f2f?

<cwebber2> I think pubsubhubbub is a fine choice

aaronpk: I have

<cwebber2> it has problems, but we have nothing better

<cwebber2> and at least it has well known history


<cwebber2> we can keep pubsub as w3c shortid

<aaronpk> "Use shortname of pubsub for shortname for now"

aaronpk: In our meeting minutes we did specifically resolve to use pubsub as the short name for now

sandro: it's not like we talked about it a whole lot at the f2f

<cwebber2> I'm also ok with pushcast

<rhiaro> I definitely don't think we agreed to use it as main name, only shortname

<cwebber2> my memory is only shortname too

tantek: My recollection was that we resolved on both

<annbass> Can we use pubsub, but w acronym different than 'PuSh'

sandro: one middleground is the same way pubsubhubbu is abbreviated PuSH we could keep using pubsub as a convenient reference to pubsubhubbub
... but the full name is pubsubhubbub
... but we refer to it as pubsub for convienience

<annbass> Approx the same as what I was suggesting

tantek: we could continue discussing
... The issue doesn't seem like a productive way to having this discusson
... Or we could open a wiki page that lists each of the serious proposals for a name, incluidng the original
... and people can document the pros and cons of each
... and that way we capture the current state of why any particular name is good or bad
... and also they could put a +1 or -1 and name next to any one

<annbass> Would it be a public discussion? Or only us?

<sandro> public

<annbass> K


tantek: use this wiki page for this discussion

<cwebber2> soudns

tantek: reasonable?

<cwebber2> sounds fine

tantek: We should document this in case in the future namechange comes up again

<annbass> If this isn't traditional push, then does that wiki name confuse things?

rhiaro: my recollection from the f2f is that we resolved only on the short name, and expected to change the spec name

<wilkie> push is the old name

<tantek> push is the old abbr

annbass: I think it's important not to bias the discussion, is calling the wiki page push going to confuse things?

tantek: push was the old short name

<annbass> Ok

cwebber2, you're cutting out

<cwebber2> arg

<cwebber2> ok, I'll type on here

<cwebber2> I think the wiki page is great, but naming also the ultimate bikeshed

<cwebber2> I suggest everyone get their stuff on the wiki

<cwebber2> and we don't spend more than another week on it

tantek: that's a perfectly reasonable proposal
... perhaps add as a comment on the issue and we can proceed from there
... is that the last thing?

<cwebber2> last thing from me!

julien: Anyone else have pubsub issues?



tantek: test suite plans for pubsub

aaronpk: I have a list of all of the componants to test and I have the framework now, website set up, will make progress on actually creating some of the tests

sandro: great
... julien, you understand aaron is working on it, have you been talking?

julien: we haven't been talking yet

tantek: is there a url?


aaronpk: best place to follow is the issues on this repo

<julien> feel free to share the repo aaron

aaronpk: If we rename the spec I'll get a new .rocks domain

sandro: do we somewhere have a list of implementations? at least hubs?

aaronpk: the only list I know of is on the indieweb wiki


tantek: julien?

<aaronpk> specifically

julien: I know there was one on google code, that's gone... I'll try to find one

sandro: looks like 5 hubs, which is great
... just wanted to figure out if we'll be able tog et through CR quickly

tantek: tons of publishers right
... half dozen hubs, subscribers?

sandro: not sure about subscribers


tantek: is that subscribers?

aaronpk: uh yeah

tantek: I think one of those is defunct?

aaronpk: that's my fault

tantek: so 3 we know of for 0.4

aaronpk: I'm sure there are tons more

sandro: publisher and subscriber are pretty easy

<rhiaro> unless subscriber needs to do diffing :p

tantek: we'll have tests for all three
... Test suite is i development
... Is that good enough to link to from the draft?

aaronpk: if you want to link to something from the draft link to the .rocks domain, or wait until we finalise the name

tantek: I guess we just file an issue on the spec to link
... Any other issues about pubsub?


tantek: new WD with updated statuses?

rhiaro: yes

<tantek> PROPOSED: published new WD of SWP with updated status of our drafts


<sandro> +1

<aaronpk> +1

<cwebber2> +1

<wilkie> +1

<annbass> +1

RESOLUTION: publish new WD of SWP with updated status of our drafts

Any other docs with updates?

tantek: next week we're meeting on the 8th, evan is chair, and all of our daylight savings should be gone by next week

<annbass> Don't remind us


trackbot, end meeting