See also: IRC log
<scribe> scribenick: rhiaro
<annbass> Hiya
<tantek> https://www.w3.org/wiki/Socialwg/2016-11-01
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
<tantek> https://www.w3.org/wiki/Socialwg/2016-11-17#Participants
<Loqi> Social Web WG Face to Face Meeting at MIT (F2F8)
<annbass> Regrets for F2F
<tantek> https://www.w3.org/wiki/Socialwg/2016-10-25-minutes
<rhiaro> +1
<tantek> PROPOSED: approve https://www.w3.org/wiki/Socialwg/2016-10-25-minutes minutes
<rhiaro> +1
<sandro> +1
<aaronpk> +1
<tantek> +1
<wilkie> +1
<annbass> +1
RESOLUTION: approve https://www.w3.org/wiki/Socialwg/2016-10-25-minutes minutes
rhiaro: Approved and published
tantek: congrats, fastest to
publication from FPWD
... Announcement should go out soon
... Spread the word
<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
<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> https://github.com/w3c/webmention/tree/master/implementation-reports
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
<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> https://www.w3.org/wiki/Socialwg/ActivityPub_CR_Transition_Request
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> http://w3c.github.io/activitypub/#changes-from-04-october-2016-to-present
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> https://www.w3.org/wiki/Socialwg/ActivityPub_wide_review
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?
<cwebber2> https://github.com/w3c/activitypub/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
<tantek> https://github.com/w3c/activitypub/issues/132
^^^^^^
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
<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 http://w3c.github.io/activitypub/ 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> http://hackertribe.io/
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
tantek: julien?
<tantek> https://github.com/w3c/pubsub/issues
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
<tantek> https://github.com/w3c/pubsub/issues/35
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
<tantek> https://github.com/w3c/pubsub/issues/27
<Zakim> cwebber, you wanted to discuss after PuSH talk to vote on new WD of AP
PROPOSAL: publish existing ED as a WD immediately
<cwebber2> +1
<tantek> PROPOSED: http://w3c.github.io/activitypub/ as a new WD of ActivityPub
<cwebber2> +1
<aaronpk> +1
<tantek> +1
+1
<annbass> +1
<wilkie> +1
RESOLUTION: publish http://w3c.github.io/activitypub/ as a new WD of ActivityPub
tantek: back to fat pings and
thin pings
... what's required and what's not
<aaronpk> https://github.com/w3c/pubsub/issues/27
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
... 28
<tantek> https://github.com/w3c/pubsub/issues/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?
<tantek> https://github.com/w3c/pubsub/issues/10
<aaronpk> current twitter poll results: https://aaronparecki.com/uploads/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
<aaronpk> https://www.w3.org/wiki/Socialwg/2016-09-23-minutes#Pubsubhubbub
<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> https://www.w3.org/wiki/Socialwg/push-name
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> https://github.com/aaronpk/pubsub.rocks
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> http://indieweb.org/PubSub
tantek: julien?
<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> http://indieweb.org/PubSub#Consuming_Implementations
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
+1
<sandro> +1
<aaronpk> +1
<cwebber2> +1
<wilkie> +1
<annbass> +1
RESOLUTION: publish new WD of SWP with updated status of our drafts
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
o/
trackbot, end meeting
<annbass> Kudos galore to rhiaro and Tantek!
<annbass> Ciao
<cwebber2> tantek++
<Loqi> tantek has 48 karma in this channel (309 overall)
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/julien/tantek/ Succeeded: s/poing/point/ Found ScribeNick: rhiaro Inferring Scribes: rhiaro Default Present: aaronpk, tantek, annbass, rhiaro, sandro, wilkie, cwebber, julien WARNING: Replacing previous Present list. (Old list: aaronpk, tantek, annbass, rhiaro, sandro, wilkie, cwebber2, julien) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ aaronpk, tantek, annbass, rhiaro, sandro, wilkie, cwebber, julien Present: aaronpk tantek annbass rhiaro sandro wilkie cwebber julien Regrets: ben_thatmustbeme WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 01 Nov 2016 Guessing minutes URL: http://www.w3.org/2016/11/01-social-minutes.html People with action items:[End of scribe.perl diagnostic output]