- 1 Social Web Working Group Teleconference
- 1.1 01 Nov 2016
- 1.2 Attendees
- 1.2.1 Upcoming f2f
- 1.2.2 approval of minutes 2016-10-25
- 1.2.3 CR status for LDN
- 1.2.4 Webmention PR status
- 1.2.5 AS2 CR-> PR status
- 1.2.6 AP WD->CR
- 1.2.7 PubSub WD->CR status
- 1.2.8 back to AP briefly
- 1.2.9 back to PubSubSomething
- 1.2.10 SWP
- 1.2.11 PubSub
- 1.2.12 SWP
- 1.2.13 Any other docs with updates?
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
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
<tantek> PROPOSED: approve https://www.w3.org/wiki/Socialwg/2016-10-25-minutes minutes
RESOLUTION: approve https://www.w3.org/wiki/Socialwg/2016-10-25-minutes 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 https://www.w3.org/wiki/index.php?diff=100643&oldid=100614
<Loqi> Rhiaro made 1 edit to Socialwg/ActivityPub wide review https://www.w3.org/wiki/index.php?diff=100657&oldid=100653
<Loqi> Cwebber2 made 7 edits to Socialwg/ActivityPub CR Transition Request https://www.w3.org/wiki/index.php?diff=100656&oldid=100344
<Loqi> Cwebber2 made 6 edits to Socialwg/ActivityPub wide review https://www.w3.org/wiki/index.php?diff=100653&oldid=100288
rhiaro: Approved yesterday, published today
<Loqi> Cwebber2 made 1 edit to Socialwg/2016-11-17 https://www.w3.org/wiki/index.php?diff=100658&oldid=100610
tantek: this is our first PR, congrats
tantek: The announcement goes out, to the AC for a vote
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
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> ? https://activitypub.rocks/implementation-report 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?
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 https://www.w3.org/wiki/index.php?diff=100659&oldid=100658
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 http://w3c.github.io/activitypub/ to CR
<rhiaro> +1 :D
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 http://w3c.github.io/activitypub/ to CR
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!
PubSub WD->CR status
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
<tantek> PROPOSED: http://w3c.github.io/activitypub/ as a new WD of ActivityPub
RESOLUTION: publish http://w3c.github.io/activitypub/ 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 https://www.w3.org/wiki/index.php?diff=100660&oldid=100656
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> https://tools.ietf.org/html//rfc5789 ACCEPT-PATCH
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
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
julien: and then... the naming.
aaronpk, you have twitter poll results in?
<aaronpk> current twitter poll results:
<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
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?
tantek: use this wiki page for this discussion
<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
cwebber2, you're cutting out
<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
... 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
<aaronpk> specifically http://indieweb.org/PubSub#Hubs
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?
<tantek> PROPOSED: published new WD of SWP with updated status of our drafts
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