Social Web Working Group Teleconference
25 Apr 2017
See also: IRC log
- tantek, aaronpk, eprodrom, cwebber, ben_thatmustbeme, csarven, rhiaro, sandro, dmitriz
- cwebber, rhiaro
- Summary of Action Items
- Summary of Resolutions
<cwebber> it's about that time right?
<tantek> cwebber: yes it is
<csarven> meeting now??.. did i get my tz wrong?
<csarven> I thought it'll be in an hour
<tantek> csarven: yes now
<csarven> okie dokie
<cwebber> I can scribe
<tantek> scribenick: cwebber
tantek: let's get started with first item, which is to review minutes from last week, had a brief telcon to discuss activitypub issues
... let's see what the rest of the folks who were here, see if the minutes are good
<ben_thatmustbeme> needs to remove the DRAFT header and we usually remove the footer stuff too
/me would it be safe to do PROPOSED now?
<aaronpk> i can do that
<sandro> PROPOSED: approve https://www.w3.org/wiki/Socialwg/2017-04-18-minutes
<ben_thatmustbeme> majority of those that were there are here
tantek: with excepttion of last week we've done them every other week, that would place next telecon on May 9th
... how does that sound for folks?
<rhiaro> I won't be here but y'all can carry on without me
evan: I think it makes sense
sandro: I'd propose doing every week
evan: could we do half hour every week instead of an hour?
sandro: I don't think we've been wasting time in meetings
evan: I'm happy to do a full hour I just don't want to take up more of peoples' time than we need
<rhiaro> we can always finish early if it happens..
evan: and we are down to one to two specs at this point
sandro: we only need the people who are there
... maybe we can wait till the end of this meeting and see how we're doing
tantek: I'll offer my opinion, the key thing I think is to actually have progress on the things we've made progress on
... if we don't have a test suite that's ready, a meeting is not going to change that
... so that's why I have my doubts about meeting every week
<ajordan> gotta drop out, forgot I had something else right now. sorry!
tantek: I'd like to allow people to have their time to focus
... maybe I should ask chris and aaron
... do you think it'll be done in 2 weeks? or will it be done in a week?
aaronpk: I don't think I can guarantee having it done in a week... two weeks yeah
<sandro> cwebber: Probably two weeks for the test suite, realistically, probably.
evan: we also need to get implementations done, 2 weeks sounds right
sandro: if I remember right last week we decided to do breaking changes on ActivityPub
... and the absolute final deadline for doing breaking changes is 3 weeks from now
... so there's a lot of deadline pressure
... maybe we're not doing any more deadline pressure
tantek: let's at least put up the we need to do in two weeks or three weeks
sandro: if there are any open issues in AP, we should do it next week
tantek: why not in two weeks
sandro: in theory we could do it in two weeks
... in a four hour meeting in two weeks? some of these take a while
tantek: here's the other side of that... if we're seeing a rate of normative substantiative issues come in, then it might make more sense to give chris and others more time to wrap them up
... that was going to be the second question I was going toa sk
<rhiaro> We're using a lot of meeting time talking about scheduling meetings.
tantek: if we have a high rate of substantiative meeting
<sandro> *23* open issues need to be closed
tantek: not all these issues need to be discussed in the telcon
... if editors and people who raised them can resolve them, we can quickly knock them out
rhiaro: in the interest of this meeting to use this week to do things, can we agree to do a meeting next week and see if we need it
<ben_thatmustbeme> +1 to schedule it and can always cancel
tantek: you're right, let's do a straw poll to see
... just enter into irc
<rhiaro> +1 all the weeks
cwebber: I'd prefer a meeting next week
<sandro> +1 to long meetings for the next three weeks, until all issues are dealt with
cwebber: all weeks :)
<aaronpk> i don't mind every week in general, but i can't make next week's call
<csarven> +1 sandro said.. in the interest of minimising risk. show up for those that need to get their stuff moving.
<ben_thatmustbeme> do we want to schedule it as an activitypub meeting next week then?
<rhiaro> i also think i'ts useful to have more than just core spec people in the meetings for better consensus making, but we can't force people to show up..
<rhiaro> perspectives etc
RESOLUTION: will hold meetings on may 2nd and may 9th
<csarven> Same bat channel
tantek: please try to resolve issues outside of the call on github
... quick PR update status
<sandro> but PLEASE try to keep time available after call so we can go long.
tantek: we do have PRs for AS2 and MicroPub (congrats)
... any calls for changes or objections?
rhiaro: we have mostly positive comments (?)
tantek: we have until may 11th for people to review the PRs
rhiaro: so that goes to the last one which is WebSub
tantek: oh ok, can you give us a summary of the end date
sandro: AP and WebSub don't have deadlines there because thye haven't gone to PR yet
... from the perspective of this, it's only the PR that gives us a deadline
<sandro> (this = W3C AC Review)
tantek: last I looked at it I saw a bunch of positive votes saying they like LDN, want to give it their support
... last I saw we could use a few more AC reps voting on AS2 and MicroPub
... so if you know member organizations, reach out
... encourage them to at least say hey, this is a good idea, make this recommendation
<sandro> https://www.w3.org/Member/ACList List of W3C companies and their representatives
tantek: they have till May 11th, so
... so that's something everyone can do
... that'e enough on that...
tantek: any comments from the AC on websub and activity[streams]?
... it didn't sound like it, but figured I'd explicitly ask
... I assume rhiaro is muted or checking
rhiaro: no explicit comments
tantek: we'll assume if they are they're filing them in github, etc
Social Web Protocols
tantek: there's been revisions, suggesting publishing new version
rhiaro: need to pull up changelog
... so I brought all of the websub stuff up to date
... I'd appreciate it if aaron, etc did so
... looked at it
rhiaro: I also tidied it up a bit
tantek: aaronpk, julian, did you look at it recently?
aaronpk: I have reviewed it recently but not specifically for websub, I can go through that
<aaronpk> micropub status PR, this still says CR
tantek: let's give you a few minutes to do that; we'll come back to social web protocols
... we'll give a few minutes to do that
tantek: I don't have any updates on post type discovery, we'll skip for this week
... we don't have julian on the phone do we?
... no, ok
... chris is minuting and has to do AP ;)
<rhiaro> I can
<rhiaro> scribenick: rhiaro
tantek: Walk us through the issues. Important ones first
cwebber: I've been focussing on the test suite
<Loqi> [jaywink] #203 Linked Data Signatures + public key URI
cwebber: this one I'm not going to address what he said, but will discuss in the abstract
... this is something that there's a lot of stuf fhappening in this area, and actula convergence between linked data signatures and jose stuff
... so that seems useful to capture becuase I know we keep getting asked about how to handle signatures
... it's non normative
... one concern I have is people want us to address it in the spec, which means we'd need it in the test suite
... worried this will use a lot of time
... This is something I"ve been thinking about. I have some concerns.. we already knew the auth stuff was not going to be a permanent recommendation by the end of the group but i feel like this may be one of the things that needs to be updated as fast as possible
tantek: sounds like a process question
sandro: seems like the best we can do is claim this is a feature that's orthogonal to AP. The way people do auth may change over time. Over here is where you see guidence about what people seem to be currently doing
... 'over here' can be managed by the CG, on a wiki page or something
... that can reflect our bes tunderstanding of what people are doing in practice based on implementation reports and changes over time
... if next year something better comes along, it doesn't change AP at all
... we just try to give people advoice, or point them to a place to help them find out what is going on
cwebber: that makes sense
... this is in the spec currently, the endpoints section
... we got the oauth stuff wrong, we're missing an endpoint
... but we do provide endpoints for some of these things
... one possible option is to move the auth endpoint stuff to an extension
... a wiki page seems like a bad idea
... I'm wondering whether we should leave this in the normative part of the spec of giving these endpoints. On the other hand, people need them
... But as you said i tmight not be necessarily correct for the future
... Should we include those endpoints actually in there?
... or is there a better place?
eprodrom: if we're not sure how we're gonna use them I don't see a good reason to include them in the spec
... that doesn't seem like we should be throwing things into the spec that we're not actually using
... I agree with sandro. I think there is a big advantage to keeping those specs simple without auth being part of it
... There are two different kinds of auth that would be required, c2s and s2s, both important
... and part of the problem with combining the c2s and s2s in one spec is that we did complicate that a bit
... is there a way we could just kick it over to say oauth?
... use oauth2 discovery and there you go?
tantek: I completely agree with what Evan just said
... specifically the endpoint question
... we should only include an endpoint if we are going to define precisely the implementaiton behaviour for that endpoint
... both for the person with the endpoint and the person discovering it
... kicking this to an extension or an example spec, ie wiki page or github
... if there's some part of a spec where we don't have the precise method defined, we should modularise that out of the spec
... saying that as me not as chair
cwebber: I have a suggestion on how to handle this
... two sections that reference this. The actor endpoints part. Sounds like there's rough consensus that we shouldn't be defining those cos we'll possibly get them wrong and we can handle that in the CG or external to the AP as this spec process
cwebber: there's also a whole auth section
... I could just keep that there but dilute it heavily
... refer to the kind of directions that are possible, and very vaguely say how they might be used
... how do people feel about that?
... removing the endpoints and referring to the possible directions but saying to look elsewhere?
sandro: why not cut a little more than that, and just say this is out of scope, here's some places you might look for how to do it?
cwebber: that's what I mean
... we could remove it as a whole header.. currently it's a whole section. We could jjust move it to the security considerations section just pointing at the things
tantek: I like the general approach
... How did micropub address this issue in terms of keeping the auth bits orthogonal? I don't quite remember
... is there some way to reuse similar text to indicate that it's something that's defined elsewhere?
... and point to a couple of specific approaches informally as what other implementaitons are looking at
aaronpk: one, micropub does explicitly say that bearer tokens are used for authentication
... that avoids having to have multiple different options. What it doesnt' say is how you get the access token, because that's outside of the scope of micropub
... that cleans that up
... where micropub and activitypub differ is that AP is also a server to server protocol, which means there's untrusted content going between the two, so a bearer token may not be the best approach for that
... this doesn't apply for micropub because we're not using it to federate between servers
tantek: I have this vague recollection of resolving to use bearer tokens in both? we can reconsider. What do you think of using th emicropub approach for the client to server piece of AP?
cwebber: we could reuse it, it's a lot more normative in micropub that it currently is in activitypub
... in micropub it's much more specifically baked in there
... we could try to bake in bearer tokens for c2s, but that doens't sovle the question people are asking the most which is about s2s
... we might patch over a part of it, but we're leaving just a big of a gap anyway
... at that poing i'd like to encourage the bearer token usage and describe how it's done in the more diluted security considerations section that we're talking about
... but I think since the spec does say you have to... we can probabyl borrow some of it and pull it inot the non-normative section that we're talkinga bout here. Would that make sense?
tantek: what do you think is right for AP?
cwebber: I think that removing the endpoints, have the watered down portion in the security considerations section, and borrowing some of micropub's terminology about how to use bearer tokens is probably the best way forward
eprodrom: cwebber, could we instead of taking this call, could we go over how pump.io does this process before we make this decision, and see if that's something we could translate into AP?
... pump.io started 4 yeares ago, uses early versions of oauth2 discovery, but the concepts are still the same
... should be possible to point out simply to use oauth 2 discovery or openid connect discovery to make this work
... and that should be sufficient
... but we'd need to step through it
... the other thing is saying 'it may be possible to use these for c2s, along with other auth systems'
cwebber: we can talk, do you immediatley after this call want to follow up?
eprodrom: stay on irc
tantek: important issue, time well spent
... sounded like we were close to consensus from teh group's perspective
... eprodrom, would you have any objection to resolving what chris said
... remove the endpoints, move the watered down portion of auth to the non-normative security considerations section, and borrow some of micropub's terminology about how to use bearer tokens, with details left up to editor
... that's the rough proposal
eprodrom: I'd like to more carefully walk through the possibilities for pointing out the features we could use at each stage of the server to server and client to server before we just punt on it
... i feel like this will take more work
tantek: I'll leave it to the two of you to follow up in the issue
... hopefully you'll resolve it in a way the commenter agrees to, or if we need to explicitly approve a proposal we can do that next week
... but we're not resolving it now
eprodrom: aaronpk, if you're not in a rush at the end of the call if you could stay on with us to discuss that would be helpful
<cwebber> scribenick: cwebber
aaronpk: I have two issuses open on it, and I do think they should be addressed before publishing
tantek: those are new issues, so instead of discussing them in realtime, I'd like rhiaro to look at them
... would you be okay with delaying a decision to public next week
rhiaro: would publishing with these issues be enough to keep a version from november up
... would you object with these issues aaronpk
aaronpk: I guess I'd be willing to publish even with these issues
PROPOSED: publish an update to Social Web Protocol with current draft
tantek: one issue is to note the issues inline, or we could try to do another draft next week
aaronpk: let's just do another draft
RESOLUTION: publish an update to Social Web Protocol with current draft
tantek: appreciate the update rhiaro, and let's do more rapid updates too
tantek: where are we at with normative issues aaronpk ?
aaronpk: I believe we haven't had any issues come in
tantek: as in terms of group decision issues, do you have any editorial issues that require republishing?
aaronpk: one thing that came up two weeks ago, I'm trying to remember if this needs any editing of the text, just gimme a sec
<Loqi> [kevinmarks] #98 Subscription migration is unclear
tantek: basically is the editor's draft disparate from the CR
aaronpk: I don't think there's any difference in the ED right now
... just trying to remember if this issue requires any editorial changes
... I remember it doesn't have any functional changes
tantek: could you give us an update on the test suite
aaronpk: no updates on the test suite yet, will work on it in the next 2 weeks
tantek: ok in the issue of moving forward, we're done with websub issues this week
... I think we can re-address this next week with whether to update with CR updates
... that brings us back to AP
<rhiaro> scribenick: rhiaro
<Loqi> [annando] #196 How to differentiate between posts and private (direct) messages?
cwebber: this is a big ... there's been this whole thread about whether to differentiate between posts and direct messages basically
... there has been discussion, but not clear progress since last week
... sandro what's your current understanding?
... I think I clarified what the issue was and then other people said what the solutions were... but I'm still confused about them
tantek: sounds like we need a specific proposal
<Loqi> [donpdonp] #204 activitypub profile discovery
cwebber: this one is shorter, 204
... what it sounds like is he wants some sort of way to use a rel link from html to what would be their activitypub profile in activitystreams
... I'm not really sure.. the usual way we have this described is that probalby someone's homepage uses content negotiation to grab the activitystreams equivalent of what that page is
... we could add rel links to a page but that opens up the question of whether we should also add text to the page about whether you have to do further discovery
... feels like it would make it more complicated
cwebber: I'm not against having a way to jump from someone' shomepage to their AP profile, but I'm hesitant about having an alternate way for somebody to have their profile linked in addressing or something like that
... but I also have not done the most amount of things with rel links of people in this group
tantek: I think the same reasonsing we used for the security endpoint discovery applies here
... if we're not going to have it well defined, we probably should not be adding it
... could be done in an extension
eprodrom: chris, this rel="alternate" is a fine way to do it, I think you should respond and say it's a common way
... but that it's usually conneg
cwebber: do we add something to the spec?
"To make content available as ActivityStreams 2.0 JSON, one could do so directly when requested with an appropriate Accept header (eg. application/activity+json or application/ld+json), or indirectly via a rel="alternate" type="application/activity+json" link . This link could be to a different domain, for third-party services which dynamically generate ActivityStreams 2.0 JSON on behalf of a publisher."
cwebber: No more normative issues
cwebber: Last week I linked this tutorial with ascii art
<sandro> +1 amazing graphics !
cwebber: somebody provided amazing vector graphics to replace the ascii art
... I'm thinking of putting the tutorial with those graphics at the top of AP as a short introduction to all the concepts
tantek: this is an editorial change as far as I'm concerned
tantek: up to rhiaro and sandro to deal with contributor agreement stuff
cwebber: they just need to indicate that it's okay to be the same copyright
tantek: congrats with 0 normative issues!
... goal to publish new cr next week
... Any other items?
... See you next week, great work
<eprodrom> cwebber, aaronpk : let's stay on the channel
<aaronpk> cwebber: eprodrom: I will brb, need to make another coffee
<tantek> cwebber++ for minuting!
<Loqi> cwebber has 7 karma
<aaronpk> give me like 3 minutes
<tantek> rhiaro++ for minuting
<Loqi> rhiaro has 139 karma in this channel (255 overall)
<Loqi> cwebber has 8 karma
<eprodrom> I'd like to walk through the flows that we might need to execute to get some basic tasks done
<cwebber> eprodrom, sounds good
<Loqi> slow down!
<tantek> trackbot, end meeting