Socialwg/2015-12-01-minutes
01 Dec 2015
See also: IRC log
Attendees
- Present
- Arnaud, rhiaro, aaronpk, sandro, kevinmarks, wilkie, eprodrom, jasnell, cwebber, tantek, Rob_Sanderson
- Remote
- ben_thatmustbeme, tsyesika, rene
- Guest
- bengo
- Regrets
Chair - Arnaud, tantek, eprodrom
- Scribe
- various
Contents
Summary of Resolutions
- All JSON-LD related details should go into a separate section (e.g. Appendix: Considerations for JSON-LD similar to the section in Annotations WG spec, but open to Editor alternatives) and also allowed in the Extensions section. Both typical publishers and developers should not have to worry about JSONLD.
- Keep AS2 work going on the Recommendation track.
- Everyone will try to have substantive issues (on AS2) raised by two weeks (Dec 15) or at least will ask for an extension by then
- Close ISSUE-46 as redundant according to jasnell. Yes, there might be paging at multiple levels of the protocol.
- Close ISSUE-46 as redundant according to jasnell. Yes, there might be paging at multiple levels of the protocol.
- CLOSE ISSUE-4 addressed by http://www.w3.org/wiki/Post-type-discovery which can proceed on its own
- Close ISSUE-37, as is - no alignment
- Close ISSUE-38, leaving that to be decided later on, when a new version of the spec is developed, if deemed necessary
- Close ISSUE-45, as "good enough", PRs to be submitted for any further improvements
- Close ISSUE #248, renaming displayName to name
- Close ISSUE #247, removing title attribute
- Close ISSUE #245, keeping both url and href separate, clarifying the spec
- Accept jf2 as an editor's draft with no commitment to rec track or even note track, but rather as a means to improving AS2
- make any FPWD- issues on Social Protocols Comparison visible by next telecon 12/8
- Move MicroPub to Editor's Draft status
- accept ActivityPump as editor's draft
<sandro> scribe: sandro
<aaronpk> Audio should be better once I get there with my mic.
<ben_thatmustbeme> i can hear tantek great, i could hear arnaud, but faint
<rhiaro> aaronpk: there is coffee
intros
tantek: i'm hosting
cwebber2: I'm Chris Webber, mediagoblin
rhiaro: I'm Amy Guy
<tantek> remote folks, if you could say if you can hear people as they introduce that would be good!
wilkie: I;m Wilkie
jasnell: James Snell
evan not on IRC yet
azaroth: Rob Sanderson
Arnaud: Arnaud
azaroth: liason with Annoation
bengo: Ben G at Livefyre, implementing AS1, observing
sandro: Sandro Hawke, MIT and W3C staff contact
<ben_thatmustbeme> he is unmuted
<ben_thatmustbeme> i could hear
rene: ... no audio
<kevinmarks> I heard rene
(debugging speaker)
<kevinmarks> I cna hear rené
<kevinmarks> and ben
<kevinmarks> you won't be able to hear me as I am muted
<rene> obviously it's a problem in SF with the sound.
<ben_thatmustbeme> i guess we'll just have our own private F2F online :P
sound works!
<kevinmarks> are you nodding ben?
rene: speaking from Germany
ben_thatmustbeme: Ben Roberts, in Massachusetts
kevinmarks: calling from caltrain
tsyesika, you on audio?
<tsyesika> I'm here but don't have audio connected right now
<tsyesika> will do shortly
<wilkie> o/
<kevinmarks> I'm in the front train carriage, so you'd get the 'ding ding ding' as we go through level crossings
agenda review
Arnaud: morning today is on activity streams. any suggested changes?
sandro: agenda+ cloising github issues
eprodrom: agenda+ testing framework
<azaroth> tantek++
<Loqi> tantek has 263 karma
tantek: I'll try to put these on the agenda
<bengo> I propose https://hypothes.is/a/28iF2d2ESHu55ZMRLnFOfw
<jasnell> Current open github issues: https://github.com/jasnell/w3c-socialwg-activitystreams/issues
<Loqi> Kmarks2 made 1 edit to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86956&oldid=86955
<tantek> pause - editing!
<azaroth> +1 to Arnaud's agenda suggestion
<kevinmarks> can someone scribe?
<kevinmarks> lot of background noise here
<tantek> I'm behind on updating agenda now in realtime
<tantek> adding items from proposed to in-line
arnaud: lets do the added agenda items in the block where they fit
... like, syntax items this morning
tantek: skipping items where the person's not here
Arnaud: yes
<tantek> now looking at https://www.w3.org/wiki/index.php?title=Socialwg/2015-12-01&action=edit#Liaison_with_Annotations_WG
<tantek> not that one
<tantek> this one: https://www.w3.org/wiki/Socialwg/2015-12-01#Proposed_technical_items
<ben_thatmustbeme> rene, kevinmarks asks if you can turn off video when not talking that would help connection
in general, it's nice to have remote video on, though, once kevinmarks is off the train.
Activity Streams
<kevinmarks> I'm trying to work out how to just get audio
Arnaud: a few weeks ago, the editor said it seemed stable and maybe it was time to go to CR. the chairs challenged the group
... I think we were happily surprised to see a significant increase in activity
... inclusing from folks who weren't engaged in AS2
... two issues
... where do we stand in terms of moving toward REC, going to Candidate Recommendation
<Loqi> Tantekelik made 2 edits to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86958&oldid=86956
Arnaud: CR means we've closed all the issues, we're basically done, and we're asking the world to implement and make sure it works
<tantek> all proposed agenda items from those present have been incorporated into agenda time slots per chair request
<jasnell> we have 21 open issues in github
Arnaud: Then the other level is
... there are still open issues
... can we close the remaining issues
sandro: can we be clear about where issues are being tracked?
<jasnell> http://www.w3.org/Social/track/issues/raised
eprodrom: also are the fundamental structural objections, like using JSON, or Subject/Verb/Object framing, ... or other fundamental objections that haven't been captured
<jasnell> http://www.w3.org/Social/track/issues/open
<Zakim> tantek, you wanted to encourage prioritization of high level AS2 issues/problems that would benefit more from in-person discussion
Arnaud: RIght, do we have all the issues recorded at this point? Would closing all issues mean we're ready to go to CR? Or are there people still waiting in the wings?
tantek: nice summary Arnaud
... When we brought it to the group, saying I think we're done, I think we realized we were seeing apathy
... from folk who didn't believe in it, but just disengaged
... We've gotten a lot more activity
<bengo> Silence can also mean agreement
tantek: During the F2F, I'd like to prioritize the ones that need more nuance
... If there's a fundamental issue, F2F is the best time to bring that up.
<kevinmarks> humming can mean agreement
tantek: That's the best time to acheive consensus on things like that
<azaroth> +1 to Tantek
tantek: I went back and did a naive re-reading of the AS2 specs
... I'll share those comments later
jasnell: A quick summary. 21 open issues in github, 4 in W3C tracker
... 1 raised issue in W3C tracker
tantek: jasnell what workflow would you like with issues?
jasnell: github
... editorial changes, pull request is nice
sandro: clarifying --- "I'm not sure what this sentence means" -- should be open an issue?
jasnell: Yes
tantek: If you have issues with AS2, dont just talk about them in irc or something
sandro: refined to: it's you job to make sure each of your issues is open in github
arnaud: except the five on the W3C tracker
tantek: right, let's record that.
<rene> one issue that needs clarification from my point is the "this can be easily done with an extension" argument
<kevinmarks> a high level concern is AS1 compatibility - need AS1 implementers feedback
<azaroth> proposed RESOLUTION: All new issues for ActivityStreams should be raised in github or via synchronous communication, and then captured in github
Arnaud: We're trying to produce a Recommendation that the world solve this problem with this technology. If you have issues, speak up....
<rene> I've raised that in the github discussion. James should know about this. I think today would be a great time to talk about that
<Loqi> Cwebber2 made 1 edit to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86959&oldid=86958
bengo: In the charter, it mentions a social syntax deliverable. Is there a reason this is the only one? What about Turtle or something?
tantek: There's nothing that makes AS2 the only spec. It's just the most mature and active of the inputs.
... Re turtle, the charter does say JSON
bengo: If there are completely left-field concerns ....
(scribe didnt follow that)
<bengo> (not advocating turtle)
eprodrom: One of the architectural concerns, brought up by people not here, that's it's not PURELY JSON-LD. There's an expectation that it will be useful if parsed by a regular JSON parser.
... I think that's something regulars from AS1 are used to, but it's a culture clash.
<tantek> aaronpk you can walk in 7 minutes from Embarcadero station to MozSF!
<aaronpk> Still on the Oakland side
eprodrom: things like language support,
... have been acrimonious discussions
Arnaud: Is there a specific issue on this?
tantek: We resolved this ages ago. That all JSON-LD support was to be optional.
cwebber2: We resolved this in Boston
tantek: I'd prefer not to re-open that unless there's really new information
azaroth: Could someone clarify?
cwebber2: AS is a JSON document, with an implied json-ld vocab, so if you run it through a json-ld processor with the right context, you'll get out triples.
<kevinmarks> not sure you can bike over the bay bridge
cwebber2: but you can work on it with a normal json processor
... cf mime type discussion
... with a couple of potential exceptions, it's json data with an implied context.
jasnell: The only exception is when dealing with extension.
... Because json-ld is the extensions mechanism
... so to do extensions, you need json-ld.
tantek: It's the chairs responsibility to uphold resolutions
<eprodrom> https://www.w3.org/wiki/Socialwg/2015-03-17#Day_1_-_Tuesday_17_March_2015
Arnaud: we don't do a good job of gathering up the resolutions
eprodrom: problem with minutes from Boston F2F
Arnaud: the charter calls for JSON
... james suggested json-ld in a way that's not intrusive
... json-ld is designed for that
<azaroth> Thanks for the clarification, and +1 to the existing resolution that JSON-LD specific processing is not required, but still possible for people who want it. Using JSON-LD as intended :)
<aaronpk> can we collect all the resolutions on a single wiki page or something?
Arnaud: not productive to say let's go json-ld all the way, forgetting the compromise
<tantek> aaronpk, we need minutes to reflect RESOLUTIONs at the top in order to do that
Arnaud: trying to pull the rug your way is non-productive.
<Zakim> tantek, you wanted to raise general re-reading feedback on AS2 and to also follow-up to eprodrom and to object to "JSONLD is designed for that"
tantek: I agree the marketing pitch is JSON-LD is designed for that. But in practice we've seen in the group, "because it's json-ld, we must do this...." THere have been so many threads in that direction, it's really unproductive.
... I'd say it's a failure on the part of the chairs not to stop those discussion. We should be drawing that hard line.
... It should not be the problem of this WG to adapt to JSON-LD, since the promise of JSON-LD was that it wouldn;t get in the way
Arnaud: Agreed!
... it represents a compromise
tantek: I'd like the chairs and staff to agree to enforce that, summarily dismissing arguments based on the idea needing to do things for the LD part of JSON-LD
... I've been seeing folks saying "because I'm using a JSON-LD processor, you must do X"
... I'd like us to reject those.
... (something about a subset)
<tantek> scribe: tantek
sandro: this gets tricky around extensions
... it's a hammered out compromise
<scribe> scribe: sandro
<kevinmarks> is this the issue of JSON-LD rejecting some kinds of JSON, eg lists of lists, which means geojson is incompatible?
azaroth: +1 having a compromise that makes our job slightly harder is more work for the WG, but fulfils the goals, where a JSON-LD processor is optional
<tantek> kevinmarks - sort of - that's the "publishers must use a subset of JSON" issue
cwebber2: Yes, it only gets complex in extensions, but still you can think in dumb json.
... it's only if you want to be able to consume from everybody, that's when you need json-ld.
... so it's only if you want to be able to robustly handle every extension.
<tantek> interesting, so even for extensions, if you have special knowledge of particular extensions, you don't need JSONLD?
cwebber2: a lot of people are saying they don't want to do that, and that's fine, they don't have to do that.
<kevinmarks> but if I nest lists the JSON-LD processor will fail?
cwebber2: it's not that much of a challenge.
Arnaud: Back to my point, any other issues not recorded?
<rene> As I said before: I'd like to talk about the "this can be easily implemented as an extension" argument. We should have a rule on that
tantek: I proposal all mentions of json-ld in AS2-core go into a section, "Considerations for JSON-LD".
<azaroth> Annotation WG JSON-LD appendix: http://www.w3.org/TR/annotation-model/#json-ld-considerations
<azaroth> And we intend to move it out of the Model and into a document more like -core
<tantek> PROPOSAL: All JSON-LD related details should go into an Appendix: Considerations for JSON-LD (similar to the section in Annotations WG spec), both typical publishers and developers should not have to worry about them.
<azaroth> Sorry, more like as-vocabulary
cwebber2: I'd be fine with that, but maybe an easier approach, with less major re-architecting, is to add it to a pre-amble, -- this whole spec can be deal with like that.
<bengo> My colleagues don't even know what JSON-LD is. Appendix better than preamble
tantek: I think the work is worth it.
... expecting the editor to say "Great, send me pull requests"
Arnaud: How much work would that be?
jasnell: There are several mentions where I could s/json-ld/json/ without harm.
<rene> @bengo: colleagues not knowing about certain technologies seem no argument to me
<tantek> mostly I'm seeing it in section 1.2 of AS2 Core
jasnell: I don't think it would take much.
... not an appendix, but in extensions, and in a section at the top.
<bengo> rene: Just relevant because barrier of adoption for JSON publishers
tantek: Specifically, the proposal was about 1.2, serialization notes.
<rene> I have to leave for approximately 1,5 hours and try to catch up after 11:30 a.m. your time
<tantek> sandro I agree your modification of my proposal with Appendix Considerations for JSONLD + Extensions sections
<rhiaro> +1 to only JSON... we could put the rest in another document
sandro: I like the idea of hiding everything but plain-old-json from people, putting them into a particular couple sections.
<rhiaro> I thought it was resolved to keep them *for the time being*
jasnell: I'd like to leave the tabs in, they;re useful, and we agreed in the past.
<tantek> rhiaro: it was resolvd
eprodrom: Not sure there's much value to talking it through more.
<tantek> eprodrom: we did already talk this through and decided to keep all the tabs
cwebber2: This seems like a useful thing, but I'm concerned about whether this is a CR blocker. It's an editorial change. This meeting, my goal is to see how many CR-blockers we can knock off the queue. Let's kick those boulders off the path!
Arnaud: it's not a blocker, although it's a big change.
... If it doesn't change compliance, we can do it later.
<Zakim> azaroth, you wanted to ask about testing of multiple syntaxes
azaroth: If there are four syntaxes in the document, testing them will be really hard. So that's a blocker for CR.
<Zakim> tantek, you wanted to note I think we're talking about two different things. my proposal (+ sandro re: Extensions), and the examples tabs
Arnaud: All these other tabs are informative.
<tantek> PROPOSAL: All JSON-LD related details should go into an Appendix: Considerations for JSON-LD (similar to the section in Annotations WG spec) and also allowed in the Extensions section. Both typical publishers and developers should not have to worry about JSONLD.
tantek: two things. My proposal was to move json-ld to an appendic, which I think IS cr-blocking.
<cwebber2> -1 if as a CR blocker
<cwebber2> +1 if not a CR blocker
cwebber2: I think this is a great proposal, but I don't see how it will change implementations. So how is a CR blocker.
<bengo> +1
tantek: If people see it as a JSON spec, they can jump right in. If they think it's JSON-LD, they'll think they need all that tooling.
... I think we'll get more implementations faster if we move JSON-LD to an appendix.
... I have specific issues I could raise on this.
<cwebber2> -q
jasnell: counter-proposal -- I don't think adding an appendix would help too much. Give me an opportunity to come up with a counter proposal.
<tantek> UPDATED PROPOSAL: All JSON-LD related details should go into a separate section (e.g. Appendix: Considerations for JSON-LD similar to the section in Annotations WG spec, but open to Editor alternatives) and also allowed in the Extensions section. Both typical publishers and developers should not have to worry about JSONLD.
eprodrom: We have a section, relationship to AS1, it may be simple to to lay out rel to json-ld, express our simple expections, that you should be able to produce and consume as without knowing about json-ld
... my only reluctnance is that we have json-ld spread throughout the doc
... so a lot of editorial work
+1
<tantek> tantek: I found it confusing reading it as a JSON developer, all the LD bits sprinkled around
<jasnell> +1
<jaywink> +1 for the proposal, find json-ld parts could be gathered into a separate appendix
<rhiaro> +1
<kevinmarks> +1
<aaronpk> +1
<ben_thatmustbeme> +1
<melvster> 0
<cwebber2> +1
<eprodrom> +1
<azaroth> +1 to moving JSON-LD details to a section, appendix or otherwise
<azaroth> And +1 to eprodrom for expressing the intent in the intro in an informative sense
<wilkie> +1
sandro: key point is: no more sprinking of json-ld through the document
<tsyesika> +1
<azaroth> +1 to sandro :) It should be skippable if you don't care... +1s all round
<bengo> +1
RESOLUTION: All JSON-LD related details should go into a separate section (e.g. Appendix: Considerations for JSON-LD similar to the section in Annotations WG spec, but open to Editor alternatives) and also allowed in the Extensions section. Both typical publishers and developers should not have to worry about JSONLD.
<tantek> aaronpk: Hi I'm Aaron Parecki, I got here from Portland
<tantek> kevinmarks: Hi I'm Kevin Marks and you saw me on the train.
<aaronpk> Good to see everyone!
sandro: does it make sense to try to make a deadline for new issues from the WG?
Arnaud: Yeah, we want all the issues on the table as soon as possible, not at the last minute
<Zakim> tantek, you wanted to discuss deadline vs. other approaches
<cwebber2> sandro, how about, +1 to deadline for CR blocking issues
<cwebber2> but non-blocking CR issues of course can happen at some point
tantek: I've seen multiple approach to convergence for CR. "I better get my issue in by this point". Or "waht is the rate of new issues coming in" then say hey, apply a deadline
... right now it feels like we're still in the post-chair-threat, with lots of new issues coming in.
jasnell: let's see, new issue 1 hour ago, then 7 days, then 21 days
tantek: I think we'll get a burst of new issues at this meeting
eprodrom: On that note, I think as we get more into implementations phase, we'll see new issues
... one question I have, we seem to have a rough process of submitting github issue when we see something wrong, we leave it up to editors to make decisions, if not palatable then take it to group. Deeper issues go to group.
sandro: clarifyiong, thje "issue" that matter for going to CR are Substantive Issues -- things needing a WG decision
Arnaud: github allows for more a agile approach, but there are some issues.
cwebber2: I like having a deadline for putting issues in
... AS2 core hasn't change much in the past year. THe vocab doc has had a lot of tweaks
... what big changes have their been? It seems very stable.
<bengo> put on agenda for telecon
tantek: I suggest waiting a week before setting a deadline.
... to see if we get a boost.
<Zakim> sandro, you wanted to ask about process and to clarify goal for this meeting
tantek: if the thought of spec going to CR or NOTE scares you, you need to speak up right away.
<bengo> +1 azaroth
<cwebber2> I did an implementation over the last month :P
tantek: we're unlikely to go CR today, but we're also unlikely to drop it down to a NOTE.
<cwebber2> I do like tantek's suggestion though
<cwebber2> set a deadline at next's meeting
<cwebber2> could we make that into a real proposal?
Arnaud: unlikely to go to NOTE
... The next hurdle is whether we can meet the exit criteria. We need sufficient implementations. We can discuss this. Two is the minimum, but seems like of ... lame...
<Zakim> sandro2, you wanted to ask about core moving separately
<rhiaro> jasnell: quick question (hopefully), answer at leisure - is there a branch more up to date than master/gh-pages? Noticed to and bto are still there and displayName isn't name in core (both of which I thought were resolved, but correct me if I'm wrong!)
<Zakim> azaroth, you wanted to propose discussing issues and return to timeline after that
sandro: Can core move ahead of vocab?
<jasnell> rhiaro: there will be after today
jasnell: not really, core normative refers to vocab for things like object
<rhiaro> great :)
<jasnell> the current published WD is the reference poit for discussion today
<bengo> rhiaro: https://github.com/jasnell/w3c-socialwg-activitystreams/pull/253
cwebber2: cage rattling worked, but lets not have cage rattling for its own sake.
<rhiaro> Aha thanks bengo, didn't look at that PR, was the next tab I had open to switch to
<bengo> melvster https://www.w3.org/wiki/Socialwg/Activity_Vocabulary
<azaroth> cwebber2++
<Loqi> cwebber2 has 59 karma
<kevinmarks> +1 on that 253 pull that fixes names
<eprodrom> PROPOSED: Social WG will continue working on Activity Streams 2.0 in order to get it to Candidate Recommendation.
tantek: that's the default state
<cwebber2> should I write up a proposal for the deadline next week?
<tantek> PROPOSAL: Keep AS2 work going on the Recommendation track.
<eprodrom> tantek++
<Loqi> tantek has 264 karma
<cwebber2> +1
<azaroth> +1
<eprodrom> +1
+0
<wilkie> +1
<bengo> +1
<jaywink> +1
azaroth: We'd like to be able to refer to AS2 collections from Annoations soon, so please keep it moving along!
PROPOSAL: Everyone will try to have substantive issues raised by next next week (Dec 15) or at least will ask for an extension by then
RESOLUTION: Keep AS2 work going on the Recommendation track.
PROPOSAL: Everyone will try to have substantive issues (on AS2) raised by two weeks (Dec 15) or at least will ask for an extension by then
<tantek> +1
<aaronpk> +1
<cwebber2> +1
<wilkie> +1
<bengo> +1
<eprodrom> +1
+1
<azaroth> +1
RESOLUTION: Everyone will try to have substantive issues (on AS2) raised by two weeks (Dec 15) or at least will ask for an extension by then
<cwebber2> \o/
<kevinmarks> +1
<tantek> who is remote? ben_thatmustbeme ?
<azaroth_> rhiaro++
<rhiaro> scribenick: rhiaro
<Loqi> rhiaro has 187 karma
Arnaud: Time to get into the issues
<ben_thatmustbeme> yes dealing with a screaming baby atm
Arnaud: Asked james to look at issues during the break to come up with a list we should start with
... Suggested to start with tracker
jasnell: Will we have time to talk about testing this morning?
Arnaud: We'll keep the last hour
... Issues for an hour, test suite for an hour
tantek: We've finished the first item - CR vs note
... One other item on there, didn't capture testing framework
eprodrom: I'd like to present the testing framework that chris and I worked up, get comment on it, talk about what to do next, what makes sense
... as we have more implementations, make sure we're working towards that test suite
Arnaud: My proposal is to use next hour for tackling issues on AS2
<tantek> added AS2 testing framework present, feedback, architecturally what next - Evan to agenda
Arnaud: Then switch to other two items - jf2, and test suite
... Work for everybody?
<eprodrom> Good
<bengo> tantek: I'd like to add a (perhaps brief) agenda item for sometime today or tomorrow, which is "Does the Social WG expect to draft a 'client-side API' specification as described in the charter?" (and what does that mean? HTTP API or WebIDL API?)
jasnell: We have 4 open issues in the w3c tracker and one raised issue
<sandro> http://www.w3.org/Social/track/products/1
jasnell: We should get those out of the way, then go to github issues
... On github, we start with ones that primarily effect core, just a handful
... Then there's another group which deal with vocabulary
<kevinmarks> that's one way to mute
tantek: do you only want to look at old issues, or look at new ones from today?
Arnaud: tackle ones recorded already
jasnell: if you came up with new issues reading through it, open a new one in github and we'll get to it as we have time
eprodrom: Makes sense. Rather not have issues come up in person that we don't record as github issues
... Record first
<Loqi> Tantekelik made 2 edits to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86966&oldid=86959
jasnell: What I'd like to do is go through w3c tracker first, then go through github oldest to newest
... Then hopefully as we're going through we get through them fast enough we can get to new ones
... Start with raised issue on tracker
<Arnaud> issue-46
<trackbot> issue-46 -- AS2.0 tries to address some Social API responsibilities -- raised
<trackbot> http://www.w3.org/Social/track/issues/46
jasnell: Raised by elf-pavlik
... Believe this is specifically with regards to thinks like paging
... We've had prior resolutions about paging and links, I propose we don't open this
Arnaud: related issues on github too
... So close issue-46 as is
sandro: deferring to github issue
jasnell: we've dealt with this several times already, to no longer discuss
... Paging model in the spec is what we're going with
<azaroth> +1 to closing issue-46
sandro: so paging at two levles of the protocol
jasnell: yes
PROPOSAL: CLose issue 46
<bengo> +1
<eprodrom> +1
<wilkie> +1
<azaroth> +1
<tantek> +1
<jasnell> +1
<cwebber2> +1
<sandro> PROPOSED: Close ISSUE-46 as redundant according to jasnell. Yes, there might be paging at multiple levels of the protocol.
<tantek> +1
RESOLUTION: Close ISSUE-46 as redundant according to jasnell. Yes, there might be paging at multiple levels of the protocol.
RESOLUTION: Close ISSUE-46 as redundant according to jasnell. Yes, there might be paging at multiple levels of the protocol.
jasnell: issue-4, longest standing
... Last discussed about a year ago, raised by tantek
tantek: Now an editor's draft
Arnaud: what do we need to do to close this issue?
tantek: We could close the issue as we accepted an ED that resolves the issue
... My goal is to publish that
<azaroth> Link to the ED please?
Arnaud: has no impact on the spec?
tantek: I agree it has no impact on the spec in good faith
sandro: Doesn't it say you can leave out the types
tantek: I Don't know how you would interpret that as a change
... My draft allows for types to be omitted
jasnell: CUrrent spec doesn't require types
tantek: my spec says if types *are* omitted, here's how to get one
<kevinmarks> http://www.w3.org/wiki/Post-type-discovery
jasnell: fine with that
<kevinmarks> is the draft tantek is talking about
<azaroth> kevinmarks: Many thanks
sandro: even if your spec becomes a rec, people will be able to do conforming AS2 without post-type discovery
<sandro> tantek: yes
tantek: yes, it's a building block
<sandro> :-)
<tantek> PROPOSAL http://www.w3.org/wiki/Post-type-discovery addresses Issue-4.
<jasnell> +1
<wilkie> +1
<ben_thatmustbeme> +1
<azaroth> +1
PROPOSED: http://www.w3.org/wiki/Post-type-discovery addresses Issue-4.
<aaronpk> +1
<wilkie> aww
<Loqi> :)
<sandro> and so ISSUE-4 can be closed, safe in the belief that post-type-discovery will proceed as warranted.
<kevinmarks> are you going to +present your babies ben?
<ben_thatmustbeme> kevinmarks, haha
<sandro> +1
<kevinmarks> +1
<cwebber2> +1
<wilkie> I'm happy the working group discussion is so lulling
<eprodrom> +1
<wilkie> +1
<kevinmarks> he can +present them when they wake up
<cwebber2> tantek: college students everywhere attempt to refute your assertion
<cwebber2> (note I said attempt)
<cwebber2> :)
<kevinmarks> as:wokeUp as:fellAsleep
RESOLUTION: CLOSE ISSUE-4 addressed by http://www.w3.org/wiki/Post-type-discovery which can proceed on its own
<jasnell> if those are activity types it should be as:Awoke and as:Sleep
<cwebber2> kevinmarks: you need an extension for that one ;)
jasnell: issue-37, raised by elf
... LPD and AS2 paging alignment
... Believe we just resolved this by not opening other issue
... Current model already accepted
<Arnaud> PROPOSED: Close ISSUE-37, as is - no alignment
jasnell: If we want to go with LDP Paging we can look at that at API level
<eprodrom> +1
<azaroth> +1
<bengo> +1
<wilkie> +1
<jasnell> +1
<sandro> +1
<cwebber2> +1
+1
RESOLUTION: Close ISSUE-37, as is - no alignment
jasnell: Next, issue-38, do we need to add a version number to context uri
... rasied by sandro
- sandro looks guilty*
sandro: I thik the answer is yes
Arnaud: the answer is always no.
sandro: How do you deal with... if you ever add a term to AS2 and somebody has made an extension that uses that same term..
jasnell: Is there any expectation that once this WG is done and we've published this, that they would want to do another version later?
Arnaud: We don't know
sandro: Yes! Vocab is clearly not completelyd escriptive
jasnell: Can these new terms be introduced by extensions?
sandro: Where would they be? Wouldn't be standard?
cwebber2: At this point you can go JSON-LD crazy and add your own
<kevinmarks> descriptive of entire human existence - this is Maciej's critique
sandro: But if someobdy does it outside of w3c, what's the point? We lose the interoperability
jasnell: If we're only talking about adding new terms, that can be done in a backwards incompatible way
<cwebber2> add AS2 gold pro edition levelpack
jasnell: Existing implementations can already ignore anything they don't understand
... If a new term is added they can ignore it
<cwebber2> wilkie you're with me right
<kevinmarks> maceij's critique http://blog.pinboard.in/2011/11/the_social_graph_is_neither/
sandro: Some large players comes up with something they like, called Loves - the loves extension gets deployed cos likes aren't strong enough
... Gets deployed across some large subsection
... So they want to go standardise it
... And it might conflict with extensions already otu there
jasnell: Depends on json-ld context
<kevinmarks> my response to maciej's critique http://epeus.blogspot.com/2011/11/our-brains-make-social-graph-real.html
jasnell: We say you cannot redefine anything in context
... It could conflict later on
... As far as... whether we should care about that conflict? I'm not convinced
tantek: all @context handling is completely optional
... So to maintain backcompat if we're adding or changing term sin AS2, the requirement is even stricter than worrying about context versioning, but worrying about spec versioning
<azaroth> +1 to tantek
tantek: And breaking json implementations that literally follow vocab hard coded in spec
... That constraint already constraints us sufficiently that version numbers in context is irrelevant
... To solve this problem we need to look at the spe cand make sure it doesn't conflict with any existing terms
... So implementations can handle it
sandro: The only solution is to have a registry used by all extensions
... Any prominent extensions have to claim a keyword
tantek: just about core spec, not extensions
... We don't need to version context, as we're already overconstrained by json-only requirement
... If you want to change a term in the spec, you can only do so in a back compatible way with the spec, the spec is the registry
sandro: but you can add
... html uses the hyphen so people can add elements
... but html WG doesn't have to do that
tantek: Feel like that's a different issue, agree that that is an issue
kevinmarks: you only need a version number if you're going to break things
<tantek> we are breaking AS1 right?
<jasnell> tantek: AS2 is not compatible with AS1
eprodrom: I wanted to point out that the reason we may need to break thing sin the future is not apparent to us right now
<kevinmarks> we are breaking AS1, yes
<tantek> jasnell, but they have different mime types right?
<jasnell> AS1 can be processed as AS2 but not vice versa
eprodrom: Sometimes, seeming emergency situations, if we have wide enough deployment of AS2 that it becomes important for security or other considerations that we're not seeing from our vantage point now
<tantek> jasnell, that's better than I thought then.
eprodrom: We will be glad to be able to do breaking backward compatible changes
<jasnell> AS1 has no official mime type actually. there is an informal mime type that has been used by convention
eprodrom: That said, those are rare occasions, usually are security issues
<kevinmarks> AS1 can only be processed as AS2 if you mung it to JSON-LD and back, right?
<tantek> AS2 processors can consume AS1 then?
<tantek> what is the informal mime type for AS1?
<jasnell> application/stream+json
<wilkie> application/stream+json?
eprodrom: Does end up causing a lot of compatibility problems for implementors, where they have to be aware of different contexts
<tantek> can JSON-only AS2 processors consume AS1? or do they require @context processing to alias things?
<Zakim> azaroth, you wanted to note that would be as3
eprodrom: Personal feeling, if there's not a strong reason not to do it, I'd love to just throw a 2 in there andhope we never have to use it
<tantek> versioning--
<Loqi> versioning has 0 karma
azaroth: If we were going to change something normatively, surely that would be an AS3 rather than AS2.1
... at which point, future selves can decide what the new uri for the new context is
sandro: current one doesn' thave a 2 in it
<tantek> please don't set 1 - that will be confusing with AS1
Arnaud: good point, decide later on if we keep same uri or create a new one
<eprodrom> azaroth++
<Loqi> azaroth has 6 karma
jasnell: also possible if we do produce a new version with this context, with its own url/namespace, can import the existing one and add teh existing terms
... So the existing normative context doesn't have to change
... Just import and extend
<scribe> ... New implementations can use that, assuming you're using LD processing
UNKNOWN_SPEAKER: If you're not using that, we already say you're going to run into problems with extensions anyway
... Already clear that LD is the extension mechanism
... If you're not doing that and new things are introduced that you don't understand, you're on your own
<azaroth> luxuryproblems++
<Loqi> luxuryproblems has 1 karma
<kevinmarks> bengo, could your as1 context be used to make a JSON compliant as2 version of an as1 stream?
cwebber2: If AS2 adoption grows so well that the world converges around a new set of terms that ar eso good that everybody just wants them in an official recommended way, couldn't we make a new vocabulary that's called ActivityStreams-Foo, where Foo is whatever super cool hot new thing in the future that we have no capacity to envision
... This is a bit different from the security issue
... For most extensions, there's nothing blocking us from doing AS-whatever
<bengo> kevinmarks My Livefyre ontology? Maps to As2 not at1
cwebber2: AS-Pro, I dunno..
jasnell: We already have a few of those terms starting to collect, things pulled out vocab recently
<bengo> kevinmarks our implemented product is AS1 with no context
jasnell: that I'm starting to put in extension vocab to serve that purpose
<kevinmarks> I thought it mapped from as1 to as2-LD
<Arnaud> PROPOSED: Close ISSUE-38, leaving that to be decided later on if deemed necessary
<bengo> kevinmarks no but james made that
sandro: there is a version number now
<sandro> http://www.w3.org/TR/activitystreams-core/activitystreams2-context.jsonld
sandro: I was confusing namespace and contet
... the context has a 2 in it
jasnell: that's the file, i'ts not the URI
<eprodrom> http://www.w3.org/ns/activitystreams is used in the spec
<cwebber2> +1
<jasnell> http://www.w3.org/ns/activitystream
<wilkie> +1
<jasnell> http://www.w3.org/ns/activitystreams
<jaywink> +1
<sandro> "@context": "http://www.w3.org/ns/activitystreams",
jasnell: Last year when we minted this url, the question of whether we should put a year in it, and decided not to do that
... related prior resolution
<bengo> +1
Arnaud: Can vote on proposal?
eprodrom: this sounds like we're leaving the issue to be decided on later?
Arnaud: the issue gets closed
<eprodrom> +1
<azaroth> +1 to closing for AS2
Arnaud: for this version of the spec
... What 'later' refers to is for future *versions*
<sandro> -0 I don't think this is well enough understood, but whatever.
<jasnell> +1 for closing 38
<jasnell> sandro: noted, fwiw I understand the concern that you're voicing but I'm just not convinced that it's a problem we need to solve right now
<sandro> this sentence is misleading: Following are three examples of activities with varying degrees of detail. Each of the examples uses an implied JSON-LD @context equal to that provided here.
<sandro> (which links to http://www.w3.org/TR/activitystreams-core/activitystreams2-context.jsonld )
<tantek> +1 close 38, no action needed
RESOLUTION: Close ISSUE-38, leaving that to be decided later on, when a new version of the spec is developed, if deemed necessary
<eprodrom> That's clear to me
<jasnell> sandro, as an editing point, I plan to update the links to the context in the document to the official URL once it's been fully updated
<eprodrom> q
<Zakim> tantek, you wanted to note that that incorporation of popular extensions into a revision of the spec is something other specs in this space have had trouble with, e.g. RSS, Atom
<jasnell> I'm not sure if the document served by http://www.w3.org/ns/activitystreams currently points to the right version of the document
tantek: trying to do editor requested workflow, to capture a different point that sandro brought up
... THe notion of lifecycle of extensions
... If extensions become popular..
... We assume AS2 succeeds, becomes popular, and industry starts to develop widely implemented extensions
... Such taht we have convergence that people want to standardise extensions
... How do we ensure that that lifecycle proceeds smoothly?
... Now, in this space, we have prior examples of failures, RSS and Atom
... extensions never got standardised
... never made it to the popular extensions became a standard, thing
... never a mechansim defined for how your extension got to transition to becoming official
<kevinmarks> conversely, OpenSocial did incorporate them
tantek: in RSS there was actually resistance
... Would encourage this group to think more in terms of optimisitc extensions becoming popular and being added to the spec
... Similarly, html wg had process which in some cases worked (I don't know what that is)
<bengo> tantek is there a github issue for this?
tantek: Sandro had the straw proposal that here's a naming convention
<rene> back in the irc and also on talky,io
tantek: Only going to raise the issue as a need, don't have a proposal
... Only raising that because sandro brought it up
Arnaud: one more in tracker
... issue-45
<Arnaud> issue-45
<trackbot> issue-45 -- Conflicts between json-ld and mf2 examples -- open
<trackbot> http://www.w3.org/Social/track/issues/45
jasnell: Goes back to the non-normative examples, discrepencies
... THere have been quite a few updates
... to microformats examples. They're closer, but still not a normative mapping between mf2 and as2 model, still not one-to-one
... I would prefer to handle this as an editorial issue
... If folks want to make continued improvements to make a closer match, open a PR
... But before submitting, double check you don't introduce other errors
... So many changes, difficult to review and catch all those errors
... So just double check that if you're changing syntax stuff that everything is correct
... Or break it down to fewer changes per PR
<Arnaud> PROPOSED: Close ISSUE-45, as "good enough", PRs to be submitted for any further improvements
jasnell: But I prefer ot handle this as an editorial issue and close in the tracker
<bengo> +1
jasnell: Not a blocker
<eprodrom> +1
<jaywink> +1
<tantek> +1
<jasnell> +1
<cwebber2> +1
<ben_thatmustbeme> +1
<wilkie> +1
<rene> +1
RESOLUTION: Close ISSUE-45, as "good enough", PRs to be submitted for any further improvements
<kevinmarks> +1
Arnaud: that takes care of w3c tracker, switch to github
<ben_thatmustbeme> though i wonder if jf2 replacing mf2 in serializations might be better
jasnell: there are a numer. 14 marked as proposals
... I would prefer to start with syntax
<ben_thatmustbeme> but can discuss in jf2 discussion
jasnell: Start with 248
<jasnell> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/248
jasnell: Received +1s in the thread
jasnell: Seems to be preferred
... It is a breaking change as far as as1
... Does anyone have an objections?
<tantek> +1 to "name" instead of "displayName"
<Arnaud> PROPOSED: Close ISSUE #248, renaming displayName to name
eprodrom: as someone who implemented as1, since we are doing a lot of backwards compat breaking, I don't see us using name for anything else, so this makes a lot of sense
<cwebber2> +1
<tantek> +1
+1
<bengo> 1+
<aaronpk> +1
<wilkie> +0
<tsyesika> +1
<ben_thatmustbeme> +1
bengo: I know there's part of the spec that compares with as1..
<azaroth> +1
jasnell: will do the same for this
<kevinmarks> +1
<eprodrom> +1
jasnell: for anyone who wants to process an as1 document as as2, there's a supplemental context that would map displayName to name
bengo: does that also reserver displayName?
jasnell: Yes, it should. I'll make that change.
<cwebber2> +1
<cwebber2> oops
<cwebber2> I already +1'ed!
kevinmarks: the history of this was that displayName was a function in open social so we had to call displayName to join first name and last name
<bengo> +1
kevinmarks: old piece of code we should get rid of
RESOLUTION: Close ISSUE #248, renaming displayName to name
Arnaud: sounds not controversial
jasnell: *and* I already did it
<tantek> Aside: is this the right format for new CR blocker issues? https://github.com/jasnell/w3c-socialwg-activitystreams/issues/261 cc: sandro
<wilkie> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/247
jasnell: Next, removing title
tantek: quick question, I filed issue regarding lifecycle/naming. Quick thumbs up / thumbs down for naming convention, of issue. Right method of filing?
jasnell: yeah it's fine
<Arnaud> PROPOSED: Close ISSUE #247, removing title attribute
jasnell: Okay, so renaming title. Short summary, name has always been plain text, default if they don't support markup. Title was always supposed to be marked up version of name
... Equivalent except it allows markup
... Aaron suggested we remove title and just have name, summary and content
<tantek> As someone who has historically included HTML markup in his Atom entry titles and has broken TONS of Feed Readers - in my experience implementations get this WRONG
jasnell: Simplifies vocab, but we lose ability to specify markup version of title, but I have never seen an implementation that actually uses that
<azaroth> +1
<jaywink> +1
<kevinmarks> +1
<tantek> +1
<aaronpk> +1
+1
<bengo> +1 iff 'title' is reserved in future and equivalencies set up in context and AS1 interpretation (non-normative) bit
<ben_thatmustbeme> +1
<cwebber2> +1
<rene> +1
<eprodrom> +1
<tsyesika> +1
<cwebber2> maybe +0
RESOLUTION: Close ISSUE #247, removing title attribute
cwebber2: would this end up taking over... if you look at pump.io, we put name where title currently is
... that content would still hold the main content?
<cwebber2> +1
cwebber2: Right, fine with me
jasnell: already have a commit for that
... Another opened by aaron: as Link object
... 245
<wilkie> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/245
jasnell: Describes an indirect link to that resource
... There has been some confusion
... Link object allows us to describe properties of the Link, not the resource it's pointing to
... Within that object we use href to point to the resuorce bieng referenced
... We use url elsewhere as a way of pointing to a link
... value of url is either a string or a Link Object
... Link Object can have href to point to actual url
... Aaron suggests using in both places
... But that creates ambiguity
... My preference would be to keep one distinct meaning for url
kevinmarks: Examples are images and things. Would it be src rather than href?
... The other thing is, we now have the ability to link to multiple variations o fthings. How do we represent that?
jasnell: The url property can have multiple values
... If I have an image object with a url, I can describe image in abstract way,a nd use url to point to multiple representations, resolutions
... Each one of those values within url is an as:Link
... with the href property used to actually point to the actual location
kevinmarks: But doesn't necessarily catch all things in source?
<Zakim> azaroth, you wanted to question mediaType as property of the /link/
azaroth: Clarification - the link allows us to describ eproperties of the link, but not resource it's pointing to
... Seems that the majority of properties actually describe resource
jasnell: Would be hints, just like what you can do with an anchor tag or a link header
... Hints to what you're looking at, but not necessarily true
... You'd have to follow url to resource
azaroth: Doesn't seem clear to me. Can we clarifiy?
jasnell: Can you open an issue to clarify that?
azaroth: yes
aaronpk: Specific example. I agree that the examples all given here seem to be describing the resource. The most common case being width and height of images
... What's getting common now with high res displays, is double resolution image at the url, and image tag is served with width and height
<tantek> there's also src-set, and <picture> element that solve this in HTML
aaronpk: Link object might have width/height of 100 but the image might actually be 200px
<tantek> would prefer not to do this in a completely different way
<kevinmarks> that's what i was getting at
jasnell: that's what I was getting at
<kevinmarks> though srcset is more complex in that it has both 2x and width targetting
aaronpk: I think the wording is misleading
jasnell: issue to describe that, then will take as editorial
<jasnell> actually, we ought to be able to use the existing issue comments: https://github.com/jasnell/w3c-socialwg-activitystreams/issues/245
bengo: a part of the existing language, if hyperlinked to qualified link relation documentation might clarify
<Zakim> tantek, you wanted to note src-set, and <picture> element that solve this in HTML, would prefer to re-use one of those approaches/structure rather than have something halfway
<aaronpk> azaroth, are you drafting that issue right now?
<Arnaud> PROPOSED: Close ISSUE #245, keeping both url and href separate, clarifying the spec
Arnaud: seems like we're getting convergence to spec being clarified
<cwebber2> I'm kind of confused as to what solution we're looking at
tantek: challenge I have with this issue is that it's hitting the wrong middle ground
... Rather than specifiying width and height (because it's informative)... I don't think it's helpful
<bengo> width and height is red herring. mediaType hints are really where this is nice
<bengo> for srcset
tantek: You need to take an approach that's already been solved, like html with srcset on image and picture element
... So, two directions. One, drop width height stuff and literally have image b ea url. 'This is an image, no claims about dimensions'
... Other side is, if your intent is to provide images of a particular resolution and hav ea particular behaviour, lets reuse solutions that have been implemented, with srcset and picture element
... Rather than trying to have something half way
Arnaud: AMP are doing the opposite, requiring width and height for performance purposes
aaronpk: I don't think AMP is a good example
<rene> +1 on not making any suggestions on display size
<azaroth> aaronpk: Yes
<tantek> I think AMP example is a bad example
<azaroth> Sorry, was listening to tantek's concern :)
<rene> I consider that part of formatting and that should be kept outside of AS2
jasnell: What I would ask, about the basic idea, is take a stab at a concrete example of what it would look like in this syntax: I have an image object, I want it available at multiple resoultions. What would that look like in the json? A strawman would make it a lot easier to work out what to do.
tantek: reasonable
... I do think there's value in havin gan value of image that's a single url
... Both useful to have image as a url, and also a solution for the use case you described
<bengo> tantek { image: 'url' } is valid
tantek: I don't want one to stop the other
jasnell: righ tnow they don't
... The value of url can just be a url
... You don't have to use as:Link model
... If you want to provide an additional metadata then the value of url can be an object that describes that link
... You ahve either choice
... Most common case, the value of url will be a string
bengo: also Image
jasnell: right
aaronpk: I didn't realise what was happening with the use of the two terms and that it was intentionally different
<bengo> http://patterns.dataincubator.org/book/qualified-relation.html
<Arnaud> PROPOSED: Close ISSUE #245, keeping both url and href separate, clarifying the spec
aaronpk: Now it's been clarified, it makes sense
eprodrom: we were just talking about in Atom and other places, where 99% there would be no markup
... then 1% it would break consumers
... Are we setting up something like this for our url property?
<azaroth> aaronpk: I added https://github.com/jasnell/w3c-socialwg-activitystreams/issues/263 -- please edit to fix if I've misunderstood
eprodrom: Mostly it's just a string, but there are legitmate use cases. JSON objects could blow up consumers that are looking for strings.
<tantek> +1 to eprodrom
jasnell: The response to that is, we know for a fact we have this use case wher emutliple resolutions of the image need to be provided
... We know that's not hypothetical at all
... The spec currently deals with that and allows for that use case
... If we want to refactor that part to make it follow the most common case, we need a proposed solution to address the other case
<tantek> if we want to refactor the complex case, let's please base it on src-set
<rene> @rhiaro: I don't understand how we can talk about breaking anything. I didn't know we are supposed to be backwards compatible to anything
jasnell: A concrete strawman is what I suggest
<eprodrom> +1
<Arnaud> PROPOSED: Close ISSUE #245, keeping both url and href separate, clarifying the spec
<jasnell> +1
<jaywink> +1 for closing issue 245
<bengo> +1
<eprodrom> +1
<rene> +1
<wilkie> +1
<azaroth> +1
<tsyesika> +1
+1
<cwebber2> +1
<aaronpk> +1
<ben_thatmustbeme> +1
<tantek> +0 I don't understand it enough to disagree. trust rest of wg consensus.
understanding++
<Loqi> understanding has 1 karma
RESOLUTION: Close ISSUE #245, keeping both url and href separate, clarifying the spec
<bengo> url: [Link(), Link() ] useful for specifying linkRelation of those urls
Arnaud: we're out of time based on what we agreed earlier
... Switch gear, then we can go back to this if we have more time before lunch
eprodrom: Could we instead reserve half an hour to discuss testing?
Arnaud: no, tesing and jf2
... Rather we stick with agenda
... We can always come back
jasnell: most remaining are vocabulary not syntax
<tantek> propose 30 min each on agenda items for 12:00-13:00
<rene> I would be glad if we could talk about the issues raised by me before lunch, because after your lunchtime it's 11 p.m. in Germany
Arnaud: big part of getting to CR is developoing a test suite
... Several efforts, but not quite there yet
... To get to CR we don't have to have a full fledged test suite
... We have a link to the test suite, call for implementations and ask them to run against the test suite
... And a link for people to provide implementation reports
<bengo> Test suite of just Social SYntax? or are we talking all?
Arnaud: Someobdy will have to have the task of gathering these reports and putting them together
<eprodrom> bengo: just AS2
Arnaud: So we can present to w3c management when we claim we have met exit criteria
tantek: if we're going to reorder, that should be an explicit action, due to timezone of remote participants
Arnaud: does ben have to drop off?
<bengo> PROPOSAL: reorder agenda to keep AS fresh in our brains without loading new context of jf2
ben_thatmustbeme: half an hour is fine
<Zakim> tantek, you wanted to ask point of order re: rene's issues, jf2 testing framework
<azaroth> kevinmarks: I can't be here tomorrow, so would be good to discuss admin item re Annotation WG this afternoon if possible
rene: I have a hard time following the audio, so following in irc
... not sure if it's my turn to speak on issues, or still talking about agenda?
Arnaud: we'r enot talking about AS2 issues any more
<kevinmarks> OK, I'm here all day
rene: makes more sense to talk about the rule before
eprodrom: which rule?
rene: the question is that james often argues that things could be easily implemented as extensions. My question is whether this arguement is a group one, or when it can be applied?
... My main concern for a standard like AS2 is assuirng some kind of interoperability, the worst thing that can happen is we have two implementations that all pass th etests, but they dont' interop with each other
<azaroth> rene++
<Loqi> rene has 2 karma
<tantek> note related issue: https://github.com/jasnell/w3c-socialwg-activitystreams/issues/261
<Loqi> Tantekelik made 1 edit to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86971&oldid=86966
rene: would new types improve on interop, or an extension mechanism that falls back to default type doesn't improve interop, this would be a good criteria to decide whether to integrate an additional object type or activity type or not
<tantek> rene, is this filed in github? it does seem worthy of capturing
rene: as far as I understood it, that makes it easier for object types to postpone them to extensions
<bengo> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/265
rene: my preferred way of doing that would be to keep an appendix of proposed object types, so people can reuse extensions
Arnaud: goign to have to interrupt, we have moved on to another topic
... This seems to be worth time and discussion
... Don't mean to imply otherwise. Do we have an open issue on this?
<cwebber2> rene: we could also discuss next week if worst comes to worst right?
Arnaud: This should be recorded as an open issue so we can get to it eventually
... Unfortunately we don't have time, trying to keep up with agenda
test suite
<tantek> rene could you capture that concer in a new github issue? https://github.com/jasnell/w3c-socialwg-activitystreams/issues/
eprodrom: testing - two levels of interop for AS2
... One is at application level
<tantek> and please reference issue#261
eprodrom: Applications that are publishing AS2 on the web
... And applications that are consuming
... That's an interesting level to attack
... The second is implementation libraries
... With the guess that there will probably be many more applications that use aS2 than libraries
... We have one test tool already which is the validator that was put together by JP
<bengo> link?
eprodrom: I believe that uses the javascript implementation already, and just takes a url and parse and dump out the information about that url
... If it's a valid as2 document
... Sorry, if it's an okay as2 document, not valid
... My suggestion is we continue to keep that running and keep it useful
... For applications implementations
... THe implementations that we're going to see over the next few months, mayb enext 6-12
... are going to be libraries
... we have a python library recently done
... we have js libraries that have existed before, as well as a currently bitrotting java library
... all of these are the first line of implemenations that we need to test
... probably the most valuable places for us to put our test effort
<jasnell> btw, it doesn't have the fancy formatting applied, but everyone can track my almost live edits to the spec as we've been discussing / resolving here: https://rawgit.com/jasnell/w3c-socialwg-activitystreams/next-round/activitystreams-core/index.html
eprodrom: one question for those who have been through this process before, is whether testing at that level is what we're looking for in implementation tests?
... Testing a library that produces and consumes as2
... Without necessarily publishing it on the web
<jasnell> there are some changes that have not yet been fully discussed (re: the revised language around the JSON-LD requirements)
Arnaud: absolutely
eprodrom: good
tantek: necessary but not sufficient
kevinmarks: what is it translating from and to?
eprodrom: expectation that it would be using an internal representation for programming language it's using
... eg. js one parses into objects, python into in-memory objects, in that programming language
... But there is an interesting quesiton of if we are trying to test it, how do we test that internal representation
... The tack that chris and I took is that we would have a commandline interface as inteface between the test suite and the implementation
... that the testing suite would basically be spawing out a stub commandline programme that we assume uses the library implementation
... it calls it with certain commandline options
... so will expect certain output back from the stub
... the question is, do you understand this json?
... if you understand this json, you will be able to tell me the type of this activity
... and it will return the type of this activity
... so it is testing any level of understanding on the part of that library
<eprodrom> https://github.com/w3c-social/as2test
eprodrom: This is the link to the test framework
... There may be some libraries that only implement one or other sides of this conversation
... Some that only produce, some that only parse
... There's an interface listed for waht those stubs need to do
... They'll eitehr get as2 json as standard input, and a request in commandline interface
... or they will be for the producer, it will be passed all the information as commandline activity and it should output as2 json on stdout
... that's not the only way that this could work
... We could do a web interface rather than commandline
... good parts and bad parts
... overhead of producing commandline input and output is a lot lower than web
... so good sides and bad sides to that
... but what I'd like to do is get us to a point where we agree that this mechanism makes sense, or if we think another mechanism makes sense, that we get to that, because I'd like to put more time into putting more test cases into this framework
... but don't want to do that if this is not the right way to go
Arnaud: I do want to point out that there are two aspects to this
... At the end of the day, what does it mean to be compiant with the spec? It's a format
... Being able to produce an dconsume
... It's kind of.. the challenge is how do we test compliance without requiring a specific API
... We can choose to provide a test harness or not
<tantek> it's a question of what is an implementation, for the purposes of exiting CR
Arnaud: We could have a collection of them in different languages, and people can use them or not
<tantek> *also a
cwebber2: I think this is also one fo the things proposed is that ther eare different formats that might be pushed forward
... Presumably what we're going to do is what we demand that everyone do
<bengo> +1
cwebber2: so we have some structure for tests, it would be interesting to get a sense, even if you're not an as2 person and might go in another direction, we could still use your help about direction of tests
... Because that's probably the direction that we'll hope everybody goes
... (including testing for alternatives to as2)
kevinmarks: two models - universal feed parser test suite
... Python based, defines a very rich test suite with several thousand test cases for mapping things
... it defines here's the input, output should look like this
<tantek> universal feed parser test suite: https://pypi.python.org/pypi/feedparser#testing
<bengo> -1
kevinmarks: Other pattern that we foudn useful was defining a set of test cases for mapping microformats into parsed json. Doing this on the web was really useful, we could cross test between implementations
... Check round trips
... Wrapping a web server around the commandline thing is really valuable
<bengo> sorry
kevinmarks: If you can do it on the web so we can just feed urls, that's really useful
<azaroth> +1 to having web front end
<Zakim> azaroth, you wanted to suggest json-schema ?
<kevinmarks> https://github.com/microformats/tests
<cwebber2> +q
azaroth: json schema - should be possible to describe requirements
jasnell: for core that would be possible
... but json schema, most of the implementations currently available do not implement 100% of json schema spec
... and some aspects of json-ld serialization, and we support some propertis with either or, many json schema implementations don't understand that
... they don't do union values
<kevinmarks> my fork of feedparser is at https://github.com/kevinmarks/feedparser
jasnell: in theory that should be possible, in practice it's not
azaroth: json schema is a json document that describes what another json document should look like
<kevinmarks> the mainline one has been stripping tests out and dropping support
azaroth: with various advanced features
... can ignore, must not ignore etc
... the python implementation that I've used does support union
eprodrom: so what we would do is say a producer has produced some as2 json, we would use json schema to validate it, but it would not test parsers
<kevinmarks> you have tests like this: https://github.com/kevinmarks/feedparser/blob/develop/feedparser/tests/wellformed/atom/entry_author_homepage.xml
cwebber2: when I first started working on first version, the thing that ended up becoming my implementaiton of as2, I started writing a validator, and evan pointed out a validator is not the same thing as what we need
... json schema is a validator
... but we actually want to see whether some sort of action is correct right?
azaroth: but the actions taken by user agents in response to the format is not normatively testable?
cwebber2: that starts to become api territory
... as2 is api neutral
... I made that mistake initially
... Theoretically we're writing a format test suite, not a validator, not an api test suite
... that's why it gets tricky
bengo: json schema useful building block, but it only does json
... wanted to express support of general idea of test suite shell interface to facilitate many language implementaitons
<kevinmarks> the mf2 ones have parallel html and json files like https://github.com/microformats/tests/blob/master/tests/microformats-v2/h-card/hcard.html https://github.com/microformats/tests/blob/master/tests/microformats-v2/h-card/hcard.json
<tsyesika> err, is talky still running at your end?
bengo: there's something either in npm or node core, a test suite that is a series of shell scripts with exit code 0 or 1, works or doesn't
... Really easy to add test cases
<eprodrom> tantek: is talky broken?
<kevinmarks> looks like it is tsyesika
<tsyesika> hum okay, thanks, must be my end
sandro: You have a framework. Do you have a list of tests?
eprodrom: a few tests right now from core
... Idea would be.. issues to start adding the rest of them
... So all the examples from the document should be in there
... Then also if there are other interoperability problems that come up, we should add as test cases too
... That would be the point of having tests in this framework
... Does that answer the question?
... For other document formats, say css or html, there are tests for interoperability means parsing as well as producing
... if we ignore parsing, that simplifies our effort in testing quite a lot
... but not sure if that's somethign we can do
Arnaud: good segue for what I wanted to bring up
... Primary goal is to be able to report implementations that are compliant
... First level to achieve that is to let people make claims
... We should try to provide some way to test this so we can report to w3c management with some facts
... In this regard, you could have a list of documents that you say to be compliant you should be able to consume all of this
... could just be that
... how they do it is left up to them
... we could have a validator that says if you're producing an as2 document it should be validating against this
... the validator goes so far, if you validate then you're compliant
<bengo> https://github.com/w3c-social/as2test/issues/17
Arnaud: other aspect is, we might want to have test suite to help developers to figure out compliance
... they may not be usre
... so they can test if they got it right
... whether we develop a harness, that's another level
... the more we do the better, but in terms of what is required, it's this notion of being able to report on implementations
... Bringing that up because I don't want us to lose sight of that
... WGs vary in how they do this
... Some are easier to test than others
... Want to go beyond just being valid json
... Try to find sweet spot
tantek: the importance of keeping that focus in mind cannot be understated
... Reality check of implementations
... By exiting CR we are making the claim that everything in the spec has been implemented by at least two or more implementaitons
... Not necessarily all in one implementation
... Could b eoverlaps
... That's largely a judgement call
... There's no definition of 'implementation' - is it a lbirary, is it a parser?
... Would encourage the group to consider real world implementations as possible
... To say, hey we have an implementation that meets an early use case is a bar to aim for to be taken seriously
... Libraries ar eunlikely to meet end user use cases
... There were plenty of different xml formats that did exactly what arnaud said - it's xml, we already have a parser so it already passed
... But they were useless. Haven't implemented something real.
... Want to warn against being overly confident of only having libraries and parsers
... To clos ethe loop to real world use cases
sandro: agree with arnaud and tantek
<bengo> https://www.w3.org/wiki/Socialig/Use_Case_TF/Social_Data_Syntax
sandro: What comes to my mind .. I don't know how to do an automated test
eprodrom: we have it
sandro: that doesn't achieve tantek and arnaud's goals
... all it shows is that you have a library
... So the test I'd like see - here's an example feed form the WG. it gets displayed through some software. I as a human read that. I re enter at by acting in software, to recreate the same feed
... That way I've tested the consumer and producer software
... Every possible thing in the feed is a thing can see and understand. Everything you can produce is a thing that a human can do.
cwebber2: you're making a human API
<jasnell> time check: we're over the half hour mark
cwebber2: This stuff is really useful once you get to the api level
sandro: the entering stuff I'm going out on... let's just test the consumer
... the consuming software should be able to take any kind of feed and give something to a human
<bengo> https://github.com/gobengo/activity-phraser
Arnaud: not realistic
<jasnell> AS2 does not define any normative requirements that can be tested by a user agent
sandro: what's the alternative? That's what html and css did
<jasnell> it doesn't define any display requirements, any use requirements
tantek: at the end of the day you have to have a human look at it
Arnaud: what does html do?
tantek: html5 has a test suite, it is manually testable, most of it is automatable, but a human can go to any test case in their browser and see if their browser can pass this test or not
sandro: the tests were cleverly designed. Took many years to figure that out
... I can't think of how to do that for AS2
<jasnell> for instance, it does not say, "this like activity should be displayed like this, implementations must pay attention to these properties, and present the information in a particular way"
tantek: if AS2 is 'just a format' like html, I can direct my AS2 browser (aka a feed reader) at an activity stream, you should see x
<bengo> https://github.com/gobengo/activity-element
cwebber2: still requires an api implementation
tantek: not necessarily
eprodrom: so testing some kind of AS2 to renderer that shows object in reader/browser
<azaroth> cwebber: You could read off of disk, rather than pull from online?
eprodrom: Interesting, valuable use case... I'm not sure all implelmentors will be generating human readable feeds that are supposed to be something you look at
<bengo> https://github.com/gobengo/activity-mocks
sandro: what are they going to be generating?
Arnaud: we need to focus direction, we're out of time
cwebber2: evan built something, is that a good direction? If not, is somebody willing to help something better?
<bengo> Relevant libraries for human-reasable phrasing, HTML rendering. Both of those required a set of 'valid' AS2 Objects
<bengo> SO I think 'isValid' is a useful building block
<jasnell> a format validator is the best we can do without a defined API or documented display requirements
cwebber2: We can talk about pie in the sky , but the goal, for me, AS2 is an intermediate step. What I really want to build is stuff on top of AS2
... I don't want to spend ages writing renderers, I want to build applications people can use
tantek: not pie in the sky, we have feed readers
<jasnell> Atom never had a test suite
<jasnell> Atom had a validator
<jasnell> RSS had a validator also
tantek: Even if all you did was copy an existing rss feed reader ui and use for AS2, that's one simple example, that would resemble the browser equivalent of AS2
<jasnell> there is no "test suite" for RSS or Atom beyond validating syntax and best practices for syntax
<Zakim> azaroth, you wanted to suggest extracting all examples from specs to act as input for parser testing
cwebber2: is pump.io already fulfilling this if it uses as2?
<bengo> https://github.com/gobengo/activity-phrase-feed
<cwebber2> tantek: https://identi.ca/cwebber
azaroth: just to suggest that we have a really good doc.. if somethign is in there and there's no way it can be tested, be good to ahve that in there
... how to test each feature
<cwebber2> literal rendering of AS1
<cwebber2> well, literally mapping to your suggestion
Arnaud: could we develop one document where every feature of the spec is at least used once. Bare minimum for test suite.
<kevinmarks> the feedparser test suite is an atom/rss test suite
<tantek> cwebber2: right - if we can show that every feature is shown/used in something visual like that - that would be a great start
<cwebber2> so in a certain extent, building the api / federation tools helps us achieve that?
Arnaud: And validator should be able to validate against this
<kevinmarks> the atom validator was built on feedparser as well
sandro: A feed that has everything in the AS2 vocabulary... a system has to handle eg. TentativeReject. The author of the system needs to tell us they're implementing TentativeReject
... Displaying them to the user in a way that the user can distinguish them is good enough
jasnell: spec does not say how they're used
sandro: conveying it ot the user in some way that the user understands...
jasnell: someone would need to write up what that means
<cwebber2> https://identi.ca/cwebber
cwebber2: sounds like ... I pointed to pump.io .. this is a rendering of as1
... simialr to an rss feed
... so if we move onto api and federation things and build applications, that will come for free
... because that's literally building those tools
... Can we at least say that we should be moving forward on those other things
<eprodrom> psych!
<jasnell> boo Zakim!
cwebber2: And agree that building the things that implement api and federation is ueful
jasnell: validator has test suites. nothing for atom that says it must be rendered this way, or even interpreted this way. Just valid or not
<snarfed> (another test suite example: https://github.com/snarfed/granary/tree/master/granary/test/testdata , along with https://github.com/snarfed/granary/tree/master/granary/test/ )
jasnell: Absent api or application use cases, there's literlaly nothing else we can test
... Is it valid syntax or not
<cwebber2> azaroth: haha
<tantek> jasnell I disagree - this is why Feed Readers failed to handle e.g. my markup in my entry titles
<eprodrom> azaroth++
<Loqi> azaroth has 7 karma
<cwebber2> azaroth: I have an IRC bot that does fate dice rolls
<cwebber2> azaroth++
<Loqi> azaroth has 8 karma
<kevinmarks> snarfed++
<Loqi> snarfed has 176 karma
<tantek> jasnell - necessary but not sufficient
jasnell: We have to have a document that describes expected behaviour when you receive one of these activity statements. That's separate from saying is that statement valid or not. We need a document to describe those things to be able to test them.
Arnaud: we're going to have to move on
<Zakim> eprodrom, you wanted to remind that current level of implementations is probably going to be libraries
Arnaud: Clear we're not going to finish this today. Will continue on next call.
eprodrom: the implementations that are going to be done are going to be libraries
... Useful to implementors to give a test suite for those libraries
... A test suite for libraries maeks sense right now
... Id' like to ocntinue working on it
<cwebber2> :)
eprodrom: Not sure if it will be our ultimate test suite
Arnaud: haven't haven't heard anyone disagree with that
<kevinmarks> eprodrom: have a look at the granary link snarfed posted
Arnaud: Useful to have docs with valid input to provide to devs to test their implementations
... And we have a validator that allows people to test what they're producing is reasonable
<bengo> https://github.com/gobengo/activity-mocks#mocks
Arnaud: Anything beyond that is bonus
<snarfed> (also https://github.com/snarfed/granary/issues/64 for running eprodrom's as2test on granary)
jf2 serialization
ben_thatmustbeme: aaron and I started playing with this idea of bringing microformats to a simpler serialization
<cwebber2> tantek: sandro: just rendering won't be enough though, because we have to show the side effects
<cwebber2> tantek: sandro: for delete etc
ben_thatmustbeme: There's a standard that microformats parses out to alraedy, we wanted to simplify it to something closer to AS2
<cwebber2> so it has to be mutable
ben_thatmustbeme: because it is difficult to work with that format
... jf2 is much more useful
<cwebber2> sandro: tantek: which really means api implementation, with renderer
<kevinmarks> https://github.com/w3c-social/Social-Syntax-Brainstorming/wiki/jf2
ben_thatmustbeme: Direct, from microformats here's how we get to something somewhat close to as2
<tantek> cwebber2, agreed - which is why I asked sandro to capture his proposal - e.g in a github issue - so you can comment on it like that!
ben_thatmustbeme: I think it's a big setp forward in unifying microformats community in getting to as2
<cwebber2> tantek: :)
ben_thatmustbeme: Definitely still differences
... Based on what is most useful to use
<cwebber2> sandro: please link it to me when it's there
ben_thatmustbeme: I think aaron and amy are already using it
Arnaud: when you say more useful, than what?
ben_thatmustbeme: More useful than the current serializaiton of microformats
... Not covering all of as2, because microformats works with posts not activities
... When james looked at it he said it might be possible to do this as some alternative serialization... can't remember exact wording
... If that's the case, we're two steps away from unifying everything
... Which is the ultimate goal of this
... The other thing is I think it might actually be a better comparison to AS2
... I would be in favour of replacing the microformats serializations with this, so we're comparing apples to apples - two json formats
Arnaud: What do you want from us?
ben_thatmustbeme: I don't know. I created the serializaiton. Aaron, you originally added it to an agenda that got dropped for 3 or 4 weeks?
... So carried voer to f2f
... What I want, ideally I'd like it to be a profile of AS2
<cwebber2> profile of AS2 would be interesting
<cwebber2> new tab on the standard! :)
eprodrom: my question is - are we looking to replace as2 as social syntax? publish it parallel? examine it abstractly? have it be compatible?
... sounds like of those four, have it be something compatible, or a part of as2
ben_thatmustbeme: ideally yes
... Worst case, something to publish as a note, how to get from microformats to as2, and possibly back
<Zakim> azaroth, you wanted to confirm that as only JSON is normative per -core, that this doesn't block progress?
azaroth: JSON as the only normative serialization of AS2, this doesn't block anything. This is a separate process?
<tantek> and this is another JSON Social Syntax, so it is covered by the charter
azaroth: Potential straw person, we're blitzing through CR and got the AS2 doc to TR, and work was done in jf2, we would not want to go back and change anything about AS2 core or vocab?
Arnaud: is this a subset of as2 or not?
ben_thatmustbeme: Just a subset? Part of it is. I think it's implementation experience that's useful input to possible changes to AS2
Arnaud: that's what we'd need to know
<sandro> jf2 pointer?
Arnaud: If this motivates changes to AS2 we need to know that soon enough
aaronpk: it already has
... The issues I filed came from that
Arnaud: is there more?
aaronpk: don't know yet
jasnell: positioning jf2 as an extension makes sense
<kevinmarks> ben - can hear your kbd
jasnell: In the original writeup there wer esome things that overlapped with as2 syntax
... that proposal for changing displayName to name. So we've already been making some of those changes based on that experience
... Whatever parts in jf2 currently have that overlap we need to look at as change proposals in the syntax
... Please open as proposals
... Everything else makes perfect sense as an extension
... could be done fairly transparently, but doesn't require any substantive changes to as2 in order to make that happen
<tantek> scribenick: cwebber2
rhiaro: I just wanted to add that I haven't followed the most recent updates to JF2 but I think JF2 maps more closely to AS2 content objects than anything else, potentially could converge on being the same
... if they eventually converge to AS2, we could dissolve JF2 and eveyone's happy, but at the very least converging on content objects might help
<Zakim> tantek, you wanted to note re: AS2 Core model of "Activity/Action" is useful for "Notifications" but not the simplest that could expressed for publishing / consuming streams of
<rhiaro> scribenick: rhiaro
<jasnell> pulling Content objects out into a separate spec is an interesting idea
tantek: this has resulted in the really productive outcome, started with what's a different way of doing this. We got improvements in AS2 with specific issues, and I apprecate james for driving that
<eprodrom> aaronpk++
<eprodrom> ben_thatmustbeme++
<Loqi> aaronpk has 13 karma
<eprodrom> jasnell++
<Loqi> ben_thatmustbeme has 122 karma
<eprodrom> Nicely done
<Loqi> jasnell has 35 karma
tantek: The specific followup that I wanted to provide was, in re-reading AS2 with the contetx of 'I'm a naive json developer, dabbled with rss or atom' - the entire model of AS2 is it's very verb centric
... We dropped verbs but they resurfaced as types
<cwebber2> verbs AND noun
<cwebber2> s
tantek: It's fine, and maps really well to the real world use case of notifications
<cwebber2> there's verbs and nouns both
tantek: on almost every single social network
... often at /notifications
... where you literally get a stream of activities worded just like activities in AS2
<bengo> my employer's AS1 implementation is what-tantek-is-saying-as-a-service http://answers.livefyre.com/early-access/personalizedstream/personalized-streams/
tantek: Want to call that out because real world implementations have found a distinct example that is different frome a news feed / homepage feed, which is just a stream of posts
... Social networks have both - streams of actions and nouns
... Interesting input we need to take
... Jf2 is the evolution... RSS and Atom are post/noun centric
... Jf2 is a modern updated json equivalent of atom
... Here are a bunch of posts
... In addition to converging with the content object model in AS2, it may have application on its own
... It's a very short path to go from publishing an Atom feed to parsing jf2
... An excellent way to get people on the road to implementing activitystreams
<aaronpk> well said tantek
tantek: Would like to see this effort contineu potentially as a seperable module
Arnaud: I don't hear much controversy
... This is good news, everybody seems to agree this is helping with convergence
<tantek> a specific proposal could be to consider this as an editor's draft
Arnaud: Don't know that there is much to discuss beyond that
kevinmarks: I think the origianl motivation for activities was the assumption that they were a database query. In opensocial, where this spawned from, I have an application embedded in a social network and I need to know what the user has done recently
... Database query saying give me everytin grelevant in this context
... Original implementation did shoot them into atom
<tantek> scribenick: rhiaro
kevinmarks: eventually became activitystreams
... It was more of a logfile format for a computer than a plublication for a human
... That distinction got lost, and the aim is clariifying that again
... The distinction between the post - human readable - and the logfile version which is as2
... And I think jf2 is a good representation of those core content pieces
cwebber2: I just wanted to point out that in as2 in a certain sense, the whole make-things-more-content-centric, has been done, because verbs are nouns in AS2. Activities are subclasses of Objects
<sandro> +1 kevinmarks as2+jf2 has a chance of being a sensible, clear model of all this stuff
In pump.io there are two streams that you are talking about - main stream of posts, and secondary stream of notification
scribe: in as2 already, verbs are nouns. We're already on that track.
eprodrom: I really liked tantek's analysis of the two different kinds of streams. You can't actually have a Collection of Objects currently.
Arnaud: find out where there is misalignment between two approaches. I don't see any reason to change the way we are dealing with this. Note definitely a possiblity down the line. We don't need to agree on this. THe conversions can keep on going.
... So what's left is empty bag and then we have absolute convergence and everybody's happy. If not, at some point we decide we have this chunk of material which has nowhere to be put in this spec, and we can look into having an ED and publishing as a Note or Rec
tantek: The question of what do we do next
<Zakim> tantek, you wanted to note a specific proposal could be to consider this as an editor's draft to formally accept it as a working group item (since we agree that work on it is a
tantek: Since we agree that this work is useful and has been productve, we should accept it as an editor's draft
... That does not commit us to anything further than that
... Does not commit us to publishing as a WD or a Note or anything
... Just that we think this work is worth continuing in WG
... propose we adopt jf2 as ED with no further implications for it's track
Arnaud: I think it's premature to do this
... Status quo seems to be working
... I disagree with your assessment of implication of turning a document into ED
... i think it's premature. For now, it seems to be working material that's useful for some people to help them instrument their comments and feedback to AS2
<ben_thatmustbeme> I would prefer to have it as a document within the group
Arnaud: We should keep it that way
... We could revisit in the future
<tantek> ben_thatmustbeme, what do you mean by "a document within the group"?
Arnaud: Once aaron tells me we have finished this process of evaluating we can revist... but for now I don't see the point
<kevinmarks> isn't it still being edited the definition of an editors draft?
tantek: point to adopt it as a working item
... I think that's all an ED implies
<ben_thatmustbeme> a work item
Arnaud: I didn't hear people want to do this
tantek: I'm saying that, ben is saying that
... Trying to label the consensus that we've arrived at
... Any objections?
<eprodrom> ben_thatmustbeme: it was a doozie too
<aaronpk> if "editor's draft" has implications other than "we're working on it" then isn't that an issue with the term "editor's draft"?
<tantek> PROPOSED: Accept jf2 as an editor's draft with no commitment to rec track or even note track, but rather as a means to improving AS2.
<Arnaud> -1
<cwebber2> 0
<aaronpk> +1
<ben_thatmustbeme> +1
<bengo> 0
<eprodrom> +0
<kevinmarks> +1
<wilkie> +0
<azaroth> +0
<jasnell> +1
<cwebber2> I definitely, on the record, think that the JF2 work is awesome
<cwebber2> and worthwhile, though
<sandro> +0
<cwebber2> though if JF2 becomes an editor's draft and acitvitypump doesn
<cwebber2> t
<cwebber2> heads up
<cwebber2> tableflip coming ;)
RESOLUTION: Accept jf2 as an editor's draft with no commitment to rec track or even note track, but rather as a means to improving AS2
<eprodrom> ha ha
<tantek> cwebber2: I prefer activitypump to become an ED
<ben_thatmustbeme> enjoy lunch
<tantek> cwebber2: AS-IS EVENT
LUNCH!!
<tantek> EVEN :)
<cwebber2> :)
<kevinmarks> you can have high tea, ben_thatmustbeme
<ben_thatmustbeme> time to take the girls to see santa actually
<tantek> ben_thatmustbeme++ thanks for leading the jf2 discussion
<Loqi> ben_thatmustbeme has 123 karma
<kevinmarks> ben_thatmustbeme++
<Loqi> ben_thatmustbeme has 124 karma
<melvster> I know it was said in jest but comments like 'evan said he'd vote for whatever gets us to lunch fastest' are not the best advert for people following this conversation from outside the F2F
<tantek> ben_thatmustbeme: are you coming back for remote participation?
<tantek> we may re-use the projection screen for demos etc.
<kevinmarks> he has to take his babies to visit santa eh said
<tantek> ok
<tantek> anyone else from the doc?
<kevinmarks> tsyesika: do you want to reconnect to talky?
<aaronpk> we can keep people on talky and just not project them too. they'll just be a tiny face over at this end of the table.
<wilkie> scribenick: wilkie
eprodrom: we have 3 agenda items: micropub, activity pump, amy's doc
... baring objections, I'd like to put amy's doc first to drive discussion of others
tantek: rob is on the queue regarding agenda
<Zakim> azaroth, you wanted to discuss agenda
<Arnaud> trackbot, status
azaroth: kevin put on agenda for tomorrow for annotations. I'm not going to be here tomorrow, so if we could do that today that would be appreciated
eprodrom: I don't have a problem with that
... first I will make the change to put Amy earlier
... tantek: if you could move annotations to after api
... last question is about dinner
... is anyone not coming to dinner. and if not can we get a head count to make reservations
tantek: I did get dinner catered here
... I'm happy to take people on a tour if they would like
<cwebber2> o/
eprodrom: ok, if you can update the agenda about dinner that'd be great. thank you to tantek for hosting
tantek: next thing I saw activity pump had aaron? I'm going to change that to chris.
aaronpk: yeah, that's because I added it
<Arnaud> trackbot, draft minutes
<trackbot> Sorry, Arnaud, I don't understand 'trackbot, draft minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
tantek: I have amy, liason with annotations, micropub and activitypump
eprodrom: only other question is about rene's question, but it is late there and we could move this to tomorrow
... I want to make sure things are handled and it gets on the agenda at some point
<tantek> agenda updated https://www.w3.org/wiki/Socialwg/2015-12-01#Agenda
eprodrom: it might be courteous to our european participants to move it to tomorrow morning
<kevinmarks> talky is back up tsyesika ben_thatmustbeme
eprodrom: can we add a morning agenda item for rene's question on extensions (for as2)
... is that fair? to handle it tomorrow morning
<aaronpk> hopefully the audio is better on the talky this time
tantek: I'll put that before federation protocol. earlier is better for europe
eprodrom: any other agenda modification?
<tantek> who is on the talky?
<tsyesika> I am
eprodrom: we have about 4 hours in order to get through social api and annotation.
<tsyesika> tantek: I'm only talk y
eprodrom: we could do an hour a piece. is there anything that may take longer?
<tsyesika> *talky
<azaroth> +1 to further AS2 issues if time allows
eprodrom: if we reach the end of our agenda, should we try to address as2 issues or any better ways to spend our time?
<azaroth> (if we get there)
sandro: let's see when we get there
eprodrom: yes
... if that's it, amy, take the floor
<rhiaro> https://w3c-social.github.io/SocialAPI/socialapi
rhiaro: I'm not going through the whole document because it is required reading and I've already gone over it prior and not much has changed
<tsyesika> sandro: talky.io / socialwg
<bengo> annos: https://via.hypothes.is/https://w3c-social.github.io/SocialAPI/socialapi
<tsyesika> sandro: don't type the full url out, don't want it indexed by search
<tsyesika> errr or something :P
<Loqi> Eprodrom made 1 edit to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86974&oldid=86971
<Loqi> Tantekelik made 4 edits to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86978&oldid=86974
<tsyesika> shepazu: talky.io / socialwg
<tsyesika> sorry tab completion failure
Amy's Social API document
rhiaro: rather than a spec, this is a document that tries to point at the different ways of doing things
... I've broken it down based on the social requirements we did a while ago
... I shuffled it around in the last couple of weeks
... the top you'll see three links to other specs. it will have a small summary of each.
... what would be useful is filing issues or what we find important for each concept
<kevinmarks> hypothesis was clearly designed by someone with very good eyesight
rhiaro: I like multiple specifications that connect together instead of a huge spec, I know some would disagree
... what I am saying this is useful for filing issues against it to use to discuss the various areas to refine those sections
... if anybody has feedback or questions or confusions...
<tantek> +1 on the document
cwebber2: the document is awesome and I've already given you feedback
... amy also already did something converting activitypump stuff into this
rhiaro: it is not linked yet
<tantek> on http://w3c-social.github.io/SocialAPI/socialapi in particular
cwebber2: I already gave feedback
... it is most interesting to me to hold off on separating the specs for now. I have a hard time reading through all of them.
... [amy] already wants to have each section be independentally implementable
<azaroth> +1 to cwebber2 re not splitting up prematurely
rhiaro: yeah, this includes federation and social api and it is a badly named document
... maybe "Social Protocols"
<Zakim> tantek, you wanted to ask what do you need to publish this as a FPWD?
bengo: I read the charter as it is a javascripty thing
eprodrom: no, we've settled to be a REST-ful api
cwebber2: (to amy) it is just activitypump that has the conversion?
<sandro> or "Social Data Distribution Protocols"
rhiaro: no. I have all of them. they are linked yet.
eprodrom: I just acked tantek
tantek: I like the document and Amy's approach to converge the various concepts.
... we had a ton of API candidates at our meetings in the past and had a huge discussion to widdle them down
... I want a draft sooner rather than later to show value and progress toward many aspects of our charter
... amy, what do you need from us to make this a first working draft
rhiaro: what I need is to understand what this document is for
<tantek> if we're renaming, possibly "Social API Comparisons" ?
rhiaro: when I started, I thought each section would have a spec you would just implement, but now we have various specs to pick between
... what should I do
tantek: the point is there is something here worth broader discussion and to at least show that the WG has converged onto 3 different approaches (even if it is not just one)
<Loqi> Tantekelik made 1 edit to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86979&oldid=86978
tantek: it will say "hey, we made progress" and that's worth publishing and why I'm driving this discussion
bengo: I think it is useful right now as a survey of relevant protocols
<tantek> we do have the agree on user-stories
bengo: and looking at the use cases, this document can show how those use cases can be done and which use cases cannot be done
<kevinmarks> wseltzer: do you want the av feed?
<tantek> rhiaro, consider linking to https://www.w3.org/wiki/Socialwg/Social_API/User_stories perhaps in a requirements section ?
cwebber2: I think what is most useful, considering the feedback I and others have given, is that you can break down all these different schmes and how they overlap
<rhiaro> tantek: links to https://www.w3.org/wiki/Socialwg/Social_API/Requirements which in turn links to user stories
<tantek> I think user stories deserve a direct link
<rhiaro> PR/issue? :)
cwebber2: so, hopefully people can help you determine the pattern and how to merge them all, if possible, to one coherent document
<tantek> though maybe not, not a FPWD blocker
<Zakim> sandro, you wanted to ask if we're going to mix-and-match or pick-one-and-refine
<tantek> rhiaro, good point, this is probably good enough: https://www.w3.org/wiki/Socialwg/Social_API/Requirements#Requirements_by_story (excellent work btw)
cwebber2: so, it maps the space and highlights convergence. so hopefully the various spec groups help you with that feedback toward that goal.
sandro: are we going to mix and match or pick one and refine?
rhiaro: excellent question
sandro: looking at the doc, there is a different tone in the description section where there are various different ways to do pub/sub yet very similar ways to do 'delete'
... so maybe we have some simple explanation about delete but you can't do that for subscriptions
rhiaro: it is useful to note the indieweb set of specs which are already broken down. and they use pubsubhubbub, but we can't link to it??
eprodrom: there were patent issues with google about PuSH. another issue is that it doesn't private distribution.
aaronpk: but nothing does. so we could extend it to do that.
eprodrom: right. many ways to do it. we could say 'this is aaronpk's feed to tantek and only those two can use it' etc
... and the PuSH implementation can decide and be implemented to do that
rhiaro: would it be useful to pull out how activitypump does it and not have it dependent on anything else in activitypump etc
<aaronpk> I'm all +1 for splitting up activitypump into smaller specs
sandro: when I read the activitypump spec yesterday I thought 'this is such a nice coherent whole' and the indieweb spec is also nice and coherent.
... mixing them together... I dunno... it seems easier to just flip a coin and then take the things the other doesn't and just ask 'how do we improve it'
<Zakim> tantek, you wanted to discuss PuSH "status"
sandro: I don't want to make a frankenstein
tantek: right, me too
... wrt PuSH: harry asked if we could link it and he got blocked trying to get the editor at Google's lawyers to allow it
... I and a few others were contacted quite angrily by Julian, the PuSH group at w3c, which we apparently have
sandro: harry didn't know
tantek: we assume no malice there, right
... so, we should contact Julian as a chair and ask about the status of PuSH and cc wendy and see if we can get to a point where we can at least reference it
<sandro> https://www.w3.org/community/pubsub/
tantek: or maybe bring it into the WG if it comes to that
eprodrom: sounds great. I'm making that action.
... it is a good option for us to follow. there are some good things about PuSH that makes sense to pursue.
... it may also be reasonable of us to consider other options, like implementing just the web hook part of PuSH.
ACTION eprodrom contact Julian as a chair and ask about the status of PuSH and cc wendy and see if we can get to a point where we can at least reference it or possibly incorporate into this WG.
<trackbot> Created ACTION-80 - Contact julian as a chair and ask about the status of push and cc wendy and see if we can get to a point where we can at least reference it or possibly incorporate into this wg. [on Evan Prodromou - due 2015-12-08].
<cwebber2> sandro: :)
<tantek> wilkie++ thanks! :)
<Loqi> wilkie has 23 karma
<kevinmarks> well, not just for big publishers, fro small publishers that might get takeoff
<Zakim> aaronpk, you wanted to reply to sandro
eprodrom: I want to make sure if we are fighting for PuSH that it is really the best tool for the job
aaronpk: I want to follow up sandro's comment about flipping a coin.
<eprodrom> wilkie: thanks
aaronpk: I agree activitypump is a coherent spec that does everything it needs to do and you look at indieweb and they are a bunch of smaller specs that are equivalent
... instead of choosing one and changing it as needed, we can look at the functionality of each spec: how does activitypump describe X, how does indieweb describe X
<kevinmarks> activitypump seems to combine reading and mentioning?
aaronpk: and like PuSH, maybe it isn't the best option, but maybe we can see it as a good web-hook pattern and just use that
<tantek> agreed, no need to flip a coin
<cwebber2> kevinmarks: mentioning is one type of thing you can deliver
aaronpk: my point is that we shouldn't start with either spec and work from there; look at functionality.
<kevinmarks> is the inbox endpoint in activitypump the same for mentions and posts your subscribed to?
rhiaro: that document already has a summary comparison as I understand each spec
... the next step would be to weigh up pros and cons, is that what you mean?
aaronpk: yeah
rhiaro: yeah, that's what I need help and feedback for.
sandro: I thought that was what we would do
tantek: I object. this document is about convergence and lists of pros-and-cons may bring up more disagreement
... I think descriptions are better that pros-and-cons
cwebber2: pros and cons could bring contention as opposed to unity
rhiaro: in terms of moving each section forward, I don't know how to progress
... I have written out in each section a description and you can go to an expanded form of that
<eprodrom> azaroth2 clever queue-hacking there
sandro: so maybe start with delete and do as I suggested. just describe delete and where they diverge, just list that as an issue and list the divergance
<tantek> disagree with sandro re: separating out separate specs at this point, I think the cohesive Social API Overview is useful as is
sandro: and then looking at PuSH, yes, maybe we can all agree that the commonality is 'web-hook' and figure it out from there
cwebber2: in response to sandro's comment about frankenstein: we don't want a frankenstein but rather a frankenstein's lab
... what I would want to do is to actually make Amy's restructured version of things to eventually be the official doc
... [of activitypump]
<azaroth> working_together++
<Loqi> working_together has 1 karma
cwebber2: if we can get to that point in all of these documents, we are that close to convergence
... and if we can't get there, we learned a lot
... and we will know regardless in the future where to go
rhiaro: if you had 3 different specs, they wouldn't always overlap, but you could use parts of them and combined get all behavior
<Loqi> Wseltzer made 1 edit to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86980&oldid=86979
cwebber2: [to aaronpk] is this something you would be interested in?
aaronpk: you mean the structure amy proposed?
cwebber2: yes. and there may be disagreements but we can have the goal of unifying them.
rhiaro: if you look at the indieweb restructuring you'll see it is short because I've just linked to existing specs
<Zakim> azaroth, you wanted to suggest a feature matrix as input to way forwards?
azaroth: a feature matrix as a summary would be valuable
rhiaro: most of the specs do most of the things so it would be a fairly full grid. you may file an issue
<Zakim> azaroth2, you wanted to suggest gh issues, re moving sections forward :)
azaroth: as far as gh issues, are those ok?
rhiaro: yeah
eprodrom: at the risk of causing conflict
- room laughs*
eprodrom: would it be good to list out differences among candidates we have to determine which are fundamental and which are unimportant
<tantek> eprodrom, maybe as issues rather than in the spec?
sandro: we did that in a way. as we said we would suggest weaknesses in our proposals and strengths in others
<rhiaro> The whiteboard from Paris:
<tantek> eprodrom, I think perhaps azaroth's proposal of a feature matrix overview would help with that?
<bengo> What is the canonical 'restructured' doc?
eprodrom: I thought we could more easily reach consensus if we determined this
... I agree that a feature matrix would be good there
<Zakim> sandro, you wanted to propose rephrasing as a proposal with knobs
sandro: there is an alternative to what azaroth proposed
... if we could, and not much work, to have a spec with knobs than a bunch of interlinking specifications
<kevinmarks> that paris whiteboard is very good, nice process
cwebber2: we could have just one specification. it is one thing to say "Amy, great specification" and another to say this is something I will definitely do.
sandro: so you can see the various forms
cwebber2: you want tabs? like JSON-LD, etc?
sandro: so you could see a knob for activitypump, indieweb etc and have it show you directly how they work
... to pick one, row files. what would be nice is basically a feature matrix: here are the fields that matter to each
rhiaro: that makes for some things but not all things
<Zakim> tantek, you wanted to propose name change from "The Social API" to "Social APIs Comparison and Overviews" and publishing as a FPWD
tantek: I deliberately labeled my queue item to be angsty
rhiaro: I already renamed it
tantek: ok
... I'm hearing some proposals for good additions to the document such as azaroth's feature matrix
... and eprodrom did too
eprodrom: yeah, differences between the proposals
<jasnell> FYI: Updated pending AS2 editor's draft based on today's conversations and resolutions at the F2F: http://rawgit.com/jasnell/w3c-socialwg-activitystreams/next-round/activitystreams-core/index.html
<jasnell> this isn't yet pushed as the current editor's draft
tantek: ok. I say give in a week for amy to consider these additions
cwebber2: I cannot do that within a week
tantek: ok. the question is whether or not there are any FPWD blockers?
rhiaro: also, I read the definition of FPWD is that it doesn't need consensus
eprodrom: since this is a process document about determining among a few API recommendations, is it an internal document? or what do we expect to publish it?
tantek: broader feedback and a show of progress
... today we have shown 0 public progress on social API and I want to change that with this document
bengo: the way the charter is worded, this document doesn't fulfill it but it pushes us there
... this sounds like a usecase document, which is also in the specification
sandro: I don't understand
bengo: because the title says social API
sandro: she changed the title
bengo: ah
sandro: now it says social api and federation protocol
bengo: yeah, it seems it says what you can do for various use cases
<Zakim> bengo, you wanted to talk about how feature matrixes are not normative and usually APIs are
sandro: yeah, and what I would want is to make issues out of any divergence and fix them. tantek would still publish as is?
tantek: yeah
<eprodrom> azaroth: I'm watching it, going to try to spread our agenda-building time out over the three
<eprodrom> azaroth: (but thanks)
<azaroth> eprodrom: +1
<eprodrom> azaroth: so I'm going to get us to sometime around 15:03 or 15:05
tantek: I don't think these are FPWD blockers
<cwebber2> as long as they're flashing like a diner sign
<cwebber2> well there you go
eprodrom: I want to check to see if we have made progress on the convergence of the social api. is it a single spec? is it two or more specs?
... is one or more of them a candidate recommendation? or too early to decide?
tantek: I think it is too early to decide that
sandro: I guess the question is when do we decide? do we want to have a recommendation by the end of the WG (around a year from now)?
... maybe we don't have a recommendation and we do enough work to get the group extended
tantek: by trying to force a methodology is flawed and not something that is going to work
... I think a different approach is to allow multiple documents publicly iterate and try to converge than prepick
rhiaro: that is what has happened since Paris
tantek: yes. and this implicit method is working.
... the waterfall pick-first approach has failed. let's admit that and move on.
<bengo> revisit (very real) charter timeline constraints in January?
eprodrom: I'm good with that. I just want us to be able to visualize an end-point that's good for us.
... if we think we will not be able to publish anything right now, I would like to have my free-time back and not spend a lot of time on it
sandro: that's if we don't get to Rec or even notes?
eprodrom: even notes. I'd be happy with publishing a few notes and some explanation why we didn't get to Rec. I would love a Rec.
... if we learn a lot and we all become better people, that's great too, but maybe not worth the time and effort.
sandro: the lowest bar there is we end up publishing an activitypump Note and a set of indieweb specs also as Notes and we can totally do that within a year
... given that is our lowest thing and that's so clear, we aren't wasting our time?
<bengo> social data syntax convergence was prereq to other parts and there are still outstanding issues
eprodrom: that seems like reasonable goals.
<tantek> bengo - and I think that "convergence prereq" was in many ways counterproductive
sandro: if we fail on all other counts, we will have those notes at least
<bengo> fair
eprodrom: if we are converging well and amy is happy being the point person, that's good
sandro: what is amy's thing about
tantek: writing a useful summary and providing a place for feedback
cwebber2: my feeling on this WG has been rollercoaster-y and I'm at the top
... a couple of months ago I was all 'this group sucks etc etc'
... the pressure to get ready for this meeting has been really useful
... I think I want to see what happened between last [f2f] meeting and this meeting again
... all of this push to make progress on specs but also implementation push
... in two months I'll probably feel awful again, but hopefully I'll feel great
<bengo> wrt feature matrix, just saw this again https://github.com/w3c-social/social-ucr#social-web-use-cases-and-requirements (good start)
tantek: that'll be the goal for the chairs then, to make cwebber2 happy
<Zakim> rhiaro, you wanted to discuss potential definitions of success
eprodrom: we are a little over the time, so last comments
rhiaro: wrt eprodrom about definitions of success and I had three options
... 1. we produce one spec that does all the things.
<aaronpk> bengo - oh wow, I forgot about that page! it hasn't been updated in quite a while. tho I also would like to see a feature matrix more at the level amy's spec breaks things out
rhiaro: 2. we produce 5 specs that overall do all the things but do not all need to be implemented on a whole
... 3. I don't remember
<Zakim> tantek, you wanted to state I'm much more of an optimist than eprodrom ;) and believe we will not only publish a draft, but multiple working drafts, iterating on them, converging
<eprodrom> I'm really liking the idea of using aspects and FATE points for running a meeting
tantek: like sandro said, the lowest possible situation is not at all terrible
... I think we should publish all the specs so we can all improve and find convergence
... and maybe all of the specs will be great and work, so who knows
<bengo> aaronpk I agree and think that's the next step. e.g. "This is how webmention fits into Responses use case 1"
tantek: I would like rhiaro's document to get to FPWD by next tele-con
<azaroth> And tag with FPWD in the issue title?
tantek: so, I propose if you have a block/issue on rhiaro's document to raise it as a github issue
<bengo> Will the document stay as 'socialapi' repo or also have name changed?
tantek: and if none, we can potentially publish as a FPWD next week
azaroth: how do we say 'this is a blocker for FPWD?' as opposed to another type of issue
tantek: just say 'FPWD-whatever' in the title
<azaroth> +1 to tantek
<bengo> FPWD of "Social Protocols Comparison"
eprodrom: sounds good. wanna make it a proposal?
tantek: yes. that was my intent
<kevinmarks> tantek: if you're going to -1 next tuesday you'd better have filed an issue
<eprodrom> PROPOSED: make any FPWD- issues on Social Protocols Comparison visible by next telecon 12/8
on github
<eprodrom> shepazu: later afternoon, 17-18 local
<eprodrom> +1
<tantek> +1
+1
<cwebber2> +1
<azaroth> +1
<bengo> +1
<rhiaro> +1
<tsyesika> +1
<aaronpk> +1
<kevinmarks> +1
<sandro> +1
RESOLUTION: make any FPWD- issues on Social Protocols Comparison visible by next telecon 12/8
<sandro> suggested shortname w3.org/TR/social-web-protocols
eprodrom: so we have slipped a bit so let's keep moving
<tantek> +1 on sandro shortname
<rhiaro> +1 on sandro's shortname
eprodrom: so maybe we take our 10 min break at 4pm?
... next on the agenda is to discuss ED of micropub
<rhiaro> If someoen wants to bikeshed about naming (in the nicest way possible) can yo uopen an issue and keep to one thread?
tantek: where is liason?
<tsyesika> heh :) night rhiaro
eprodrom: oh is it? I thought it was last
... let's stay in order as we have it
... so, let's discuss Liason with Annotations WG. I think we have doug in IRC
Liasion with Annotations WG
<eprodrom> I am pleased that that worked
kevinmarks: I asked if I could be IE on annotations and shepazu said no
... so I've been a bad liasion since I'm not a member of the group
tantek: that feels like a process error
shepazu: nope
... we didn't have any IE at first and wanted to ensure we were implementer-heavy and wanted to get the group going before letting in IE
<tantek> didn't we have a resolution for kevinmarks to be the liason?
shepazu: IE are only specifically people doing duties in the WG, all are welcome to the mailing list
<tantek> joint wg resolution?
shepazu: that's what we wanted our policy to be, and it is normal within the w3c
tantek: can you note then that kevinmarks is liaison and get this clarified
... it was a joint-resolution at TPAC to have kevinmarks be liaison
<bengo> so what now?
shepazu: I don't recall that resolution that there would be a specific liaison. I thought it was just to be resolved by the chairs.
tantek: no
shepazu: ah. it was not clear that he would be liaison.
<tantek> minutes from the joint Social Web / Annotation WG meeting TPAC 2014?
azaroth: I recall the IE request and recall discussion around it and I remember the resolution was to not have IEs and not a strong reason
... and since there was no strong reason, it was rejected and this was just some clerical error and hopefully the two groups didn't suffer from this
... hopefully this has been mitigated somewhat now that we have IEs more officially supported in Annotations
... I think we would look more favorably now than months ago
tantek: ok. let's assume a mistake and move on.
... do we still need a specific liaison? kevinmarks, you were nominated, are you ok with it now?
kevinmarks: I will look at annotations and coordinate now with some of the other specs I'm working with
azaroth: yeah. having a path forward to look at how annotations would look with webmentions etc would be good.
rhiaro: I'm also in the webmentions WG but not sure how much I can contribute
<kevinmarks> wilkie: fragmentions as well as webmentions
eprodrom: our queue is empty. do we have any more to discuss?
<kevinmarks> (I regret that name)
shepazu: sorry, was this just discussion about a person who would be liaison or about the technology?
tantek: more admin process than tech.
<bengo> If anyone can deliver an update on joint work...
<tantek> great - totally fine with informal liason especially with azaroth now participating directly in social web wg
kevinmarks: yeah, it was just to clarify because this wasn't together. if you want to discuss tech, do it.
jasnell: yeah, I would like to see if Annotations, as an implementor of as2, has any concerns
tantek: more so, any CR-blockers
azaroth: as far as I know, we are quite happy with what AS2 is looking like
... there are some overlapping and similarity but we think it can be managed
shepazu: I think it would be useful for azaroth to discuss what happened at TPAC
<cwebber2> activityvectors
shepazu: I think it would be useful to discuss the resolutions at TPAC
azaroth: there was a resolution that the work for AS2 would progress toward CR and the timeframe with the two groups is reasonable that we can use AS2 collections instead of a clone of them
... if there was a desire to have a separate collections spec, we can do that too
tantek: is there a issue to pull collections out of core to a new spec?
jasnell: elf has requested this, but no real issue
tantek: then, I ask the WG if there is anyone that wants this that they should make an issue on github for that
jasnell: it has been discussed many times and we've always resolved that what we have is what we want
<cwebber2> not me
eprodrom: I think tantek is proposing that it would be the same but a separate document that is linked separately
tantek: to be clear, I'm not proposing this. just that people should bring that up.
eprodrom: do we have more to discuss about liaison to annotations?
... if that is the case, then we I say we take a 10 minute break and come back to micropub discussion
... ok. let's take a 10 minute break and come back at 3:45pm
<Loqi> I added a countdown for 12/1 3:45pm (#5770)
3: 40pm
<eprodrom> Oh, I didn't know that worked
<aaronpk> me either haha
and come back at 3:40pm
<azaroth> Annotation side of the protocol issue: https://github.com/w3c/web-annotation/issues/118
<Loqi> I added a countdown for 12/1 3:40pm (#5771)
<aaronpk> wilkie figured it out
<Loqi> and come back
<Loqi> Countdown set by wilkie on 12/1/15 at 3:34pm
<Loqi> eprodrom: ok. let's take a 10 minute break and come back
<Loqi> Countdown set by wilkie on 12/1/15 at 3:28pm
<azaroth> scribenick: azaroth
eprodrom: Group photo. If we have everyone here till the end, can do it when we finish the agenda. Before dinner
<aaronpk> i have a camera and tripod for group photo
<tantek> agenda 2 done
eprodrom: good. Any other agenda items?
... if not, aaronpk can you take the floor on next steps for micropub
<tantek> scribenick: azaroth
aaronpk: Getting back to Micropub, we've been making progress and would like to continue developing it
... push it forward as ED and with a goal of making it align with activity pump
<kevinmarks> http://micropub.net is the spec discussed
aaronpk: lots of hope for that. If you've been reading the draft, there's lots of things that are different from March
... obviously still needs work
... most fleshed out part is creating objects, other operations happy to keep getting feedback on, and changing.
... would like to propose as ED to continue to work on in the WG
... What else would people like to see?
eprodrom: Chris?
cwebber2: I read it over. Two major things - one was that the MF encoded form says ...
aaronpk: A discrepancy got fixed between should and must
cwebber2: You fixed it :)
... Now you've changed to must handle it which is great
<Loqi> Tantekelik made 1 edit to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86981&oldid=86980
cwebber2: Main thought was, have you thought about server to server?
... WebMention does it for a specific set of things
... specifically about mentioning you and informing about that. It doesn't do stuff like posting baby photos
<tantek> both Quill and Woodwind do server to server Micropub right?
cwebber2: Or not specifically mentioning you
<kevinmarks> and ownyourgram
cwebber2: Looks like it could do federation, which would advance the group
... we would get a better understanding of where we are. Looks like most of S2S is already there
aaronpk: server to server has always confused me
<kevinmarks> the silo.pub federation stuff kyle has been discussing covers that too
aaronpk: no good lines for what a client is, chrome might talk to an application server that posts to a web server
... most apps send data to their own server, which sends data to another server
... which is acting as a client ... so now where's the server?
cwebber2: Specifically about sending client to a server to create on the server
... Use android app to check latest things, but there's also updating the graph amongst other servers
... webmention updates the graph of what servers know about
... micropub could do the same thing with very little adjustment
rhiaro: like side effects?
cwebber2: Even the non side effects part of describing what happened on the other server
aaronpk: Advantage?
cwebber2: could convey webmention over something like this
<tantek> I've got a pretty good idea why webmention and micropub are distinct and separate (differen trust pre-requisites and user models).
cwebber2: one thing the doc doesn't speecify that IWC doesn't have an answer for
aaronpk: Is the combination of micro + webmention missing something?
cwebber2: Private notifications
aaronpk: Nothing in spec form yet, but some experiments with PuSH and WebMention
cwebber2: You can convey the same type of terms, like RSVP ... all the same things can be done?
... via webMention
... the same set of functionality can be done, or is about linking document based web?
aaronpk: I need to think about that :)
<kevinmarks> o/
aaronpk: first reaction is that private experiments, the answer is yes, but not sure if it's the best way to do it
... have also involved the server acting on behalf of the user and getting a Bearer token
... to fetch private content
... fits in reasonably, not necessarily the best way
cwebber2: asked for One thing you can't do. That kind of subscription model doesn't seem to fit in between the two specs now
kevinmarks: Abstraction between the two models is where we're colliding
... webmention is purely this site links to you, it may mean something
... and micropub which is post something to a site
... activitypump combines the two
... so webmention is an outbox post which relates to someone else
... sense is that there's an intermediary that does it for you, but there's something else that handles it
<sandro> 1. Profiles
<sandro> 2. Reading
<sandro> 3. Subscribing
<sandro> 4. Mentioning
eprodrom: AS all the way through. Posting to a client server endpoint is the same as server to server
<sandro> 5. Publishing
cwebber2: If we can get things to a certain point, it would help to get more overlap and convergence
eprodrom: to the queue ... being me ... :)
<eprodrom> https://indiewebcamp.com/post-type-discovery
eprodrom: My question is about post-type-discovery
... what extent is the work being synchronized, and what extent is that work influencing micropub, or already aligned?
aaronpk: Haven't considered PTD -- one is for reading, the other writing
... vocab is all vocab, so related to PTD
<tantek> I don't understand the PTD question?
sandro: You can remove the type and infer it
eprodrom: Interested in keeping the vocab aligned, if it already is, great
aaronpk: Not creating its own vocab, it uses the microformats vocab
... would tie into PTD
... if you don't know anything about micropub and you get a request you could use PTD to decide what to do with the request, per Amy
eprodrom: Good principle to follow
kevinmarks: Sense of separation here. We are using micropub to route things between systems
... one example is ownyourgram that uses instagram and micropub
another example is silo.pub that maps from MF to various things
scribe: it wraps blog in an envelope to post to blogger, or finds the image to send to flickr
... mostly individual things we've built
... lots of targeted protocols that are moving together, whereas you have a bigger suite
... partly where the mappings get odd
Tantek: different kind of answer. What drove the different protocols. WebMention happened first.
<Zakim> tantek, you wanted to note why webmention (federation) and micropub (API) are distinct and separate (different trust pre-requisites, user models, canonical data).
<kevinmarks> azaroth: ownyourgram.com you sign into instagram and it posts your photos to your own site
Tantek: different user model between federation and users.
... Conceptually defend the distinction. Federation standpoint it's FYI. THe receiver is not required to do anything on any timescale
... other than how you validate it. After that there's suggested things you can do. If it has X content, then it's a comment and you should copy it to your post as a reply
... but the ultimate decision of action is on the receiever. It has its own agency
... all the boundaries for federation are corssed
... for an API scenario, both ends are under the control of the same user
... so the user issues a command to create something, then the server MUST create it
... it's a hard requirement, so very different from auth and user agency perspective, permissions, trust, number of actors etc.
... don't do auth for federation, you just send it
... Maybe wrong with drawing the difference, but lots of differences?
sandro: Clear to me
tantek: User 1 vs user 2, rather than one user and thing 1 vs thing 2
cwebber2: Same technical design could do both
... webmention is cool in that it's very minimal
tantek: a different contract
cwebber2: You could emulate in activity pump, nice that it doesn't require a lot of work
... if I run my own pump io server, I know that I'm posting to my thing. The same design and serialization.
... little distinction between what is a client and a server
... don't always control the server. Might decide that you're a spammer even if you have an account, so might still filter
... if I set up my own server, better not do that to myself
... same concepts could be accomplished with same tech, more usable in the long run
... even with lack of distinction, it's not as big a division as you might thing
think
rhiaro: my micropub endpoint when it receives a post sends a webmention
... webmention and mf completely separate so no requirement but that's how I hooked it up
... with activity pump you must do it
cwebber2: The receiving server might reject it
... what happens if you do mpub post to a third party? Do you have to "own" the micropub endpoint?
tantek: You have to be oauthed up
... but not in webmention
... which is essential for lightweight federation
<kevinmarks> try silo.pub with twitter
cwebber2: Right not saying it's not useful, but that it would also be useful if mpub also did federation
aaronpk: another difference
... mpub as a way to create content, the content is part of the request
... the bearer token is prearranged
... webmention is only by reference, content is not in the request
... don't say here's my photo etc
... that would be trackback, and garbage because it's unauthenticated
... only way to send content is if it's authenticated
cwebber2: or go back and verify it, but then you might as well not send it
eprodrom: activity pump does two legged oauth
... so server to server
aaronpk: for mpub there's no URL until the request is handled
... if you used the same protocol for webmentions, you're delivering the contents of the post
... but unless you authenticate there's no way to trust it
... and they probably want to verify it anyway
... so just send the url
... so it's just what we have now :)
sandro: You might auth once every long period of time?
eprodrom: So because of pingback style of webmention, there's something here you might be interested in, it doesn't make sense to use the same interaction
... if it was PuSH service, ala activity pump, it would make sense?
aaronpk: Interesting. Pretty sure most PUSH systems dont' send the contents in the broadcast
... that would look more like micropub
... if PuSH has too many limitations, then may it's just micropub and that's where it fits in
... not the same use case as micropub
cwebber2: suggesting that it's easy to drop into an existing blog which is hard with activity pump
aaronpk: extending to also handle distribution of content for subscribers is different from webmention
cwebber2: spec is well written. Main concern is that it shouldn't talk about specific silos
aaronpk: Also anchors it in time
tantek: +1 :)
kevinmarks: presumption for sending stuff out is that it's replication
... might be a way to couple the two together
<Zakim> tantek, you wanted to note some brainstorming attempts to do site-to-site micropub
tantek: to argue against myself ... we have had some experiments and one production use of webmention like an api and webm for federation
... sending a copy somewhere is like federation, for federation-hostile people
... with webmention we have bridgy, that built a protocol for publishing on top of it
... it acts like micropub in a way
... if you send a particular mention to one place it'll publish content to another server
... take this specific action that is triggered by a webmention
... brainstorming on server to server, with distinct users
... didnt' scale well. If you're one someone's website and they have a comment box, you want it to post to YOUR site not just their site
... so it should act like a micropub client and then use webmention to get it back
<cwebber2> eprodrom: I'm staying shut up but you should mention what pump.io does here ;)
tantek: if you auth in ... no you might not want to give out arbitrary permissions
... so walked down the path a bit and it didn't seem like a good trust design
kevinmarks: have web actions via client side voodoo
tantek: without auth
kevinmarks: looks like it's going to one site, actually to others
tantek: federation of all the little buttons on posts like like, reply, bookmark, etc. a way to have sites take actions to a different site
... users configure their client to handle them
... built a shim with web components
... a protocol handler that makes it work
... your site will take over the functionality of those buttons on the remote site
... UI federation? not sure how we conceptually captured it
kevinmarks: The example of it working is woodwind
tantek: with micropub?
kevinmarks: with all of them
tantek: woodwind is a reader that you sign into with your own domain and it tracks what you're reading
<kevinmarks> woodwind is reader.kylewm.com
tantek: if your own site supports micropub you can sign in there and it posts to your site
... if you don't, it can fall back to other options
<Zakim> bengo, you wanted to ask about separation of request semantics and resource representation
bengo: Maybe controversial, but keeping the object representation separate from what to do with the object. Curious why edit this or post this or delete this is in the body, rather than the method?
<cwebber2> to respond
aaronpk: Reason is to allow delegation of functionality, rpc-style.
... where you might have a static website other than GET, but you can delegate to some other endpoint
... but you can't delete that endpoint
... the objects don't live under the micropub endpoint
... thus the RPC style
... Could say that the endpoint could delete based on a query string, but seems contrived for no particular reason
eprodrom: to answer that for other things... for activity pump... pump.io does do that. One way to follow someone is to post your id to their following list
... you add yourself to their followers
... or deleting an object directly
... managing some of the life cycle of the social graph works that way.
... Some things are harder to do like that. If I like something, posting to a list of likers might make sense
bengo: Unliking a thing seems either deleting a like resource, or posting an unlike, could try different ways until something works
... but could be just one way
eprodrom: we would concentrate on the one way of using AS as written
... always been a logging style format we repurpose as a command langage
... how that happened. Interesting to reconsider purely from a REST mechanism without a command language
bengo: having it all in the message is useful for websockets based things too not inherently bad, might just hear that's not restful over and over again
eprodrom: expectation has been there'd be a stream of activities, natural to think in atompub style of posting an activity to the feed
cwebber2: couple of CRUD activities, but also others like join ... no HTTP verb
eprodrom: COuld have a members resource and posting an ID to it
cwebber2: I think this group resolved ... should we use all these verbs...everyone was using the AS verbs not HTTP methods
... so do AS first
tantek: I recall that as well. Don't want to have the argument again :)
eprodrom: wrap up with micropub? anthing to discuss in next 10 minutes?
cwebber2: ready to go to ED?
... I think we should propose it?
<cwebber2> PROPOSED: Move MicroPub to Editor's Draft status
<cwebber2> +1
<tantek> +1
<kevinmarks> +1
<wilkie> +1
<aaronpk> +1
<rhiaro> +1
<eprodrom> +1
+0
<sandro> +1
<bengo> +0
jasnell, et al: Make it explicit regarding moving to WD in the status section
RESOLUTION: Move MicroPub to Editor's Draft status
<cwebber2> whoooooo
eprodrom: Resolved :)
... have 90 minutes left, one more item on agenda
<aaronpk> jasnell, what was your specific wording?
eprodrom: everyone in late afternoon doldrums. Dinner at 7.
... hopefully group photo will not take half an hour
tantek: 7th floor with bay bridge
[temporarily adjourn]
<aaronpk> scribenick: aaronpk
ActivityPump
cwebber2: talking about bringing activitypump to editor's draft
... i'm assuming everyone's familiar with it by now. sandro said before basically AP is ActivityStreams in API form
... so, in that sense, if there's things peopel want to talk about specifically i'm happy to talk about them
... i have a few things i'd love to go over while we have people her
... but it might be more useful to have people who are not me say things
... github is being used for issue tracking
sandro: can you paste the link to that?
<Zakim> azaroth, you wanted to say it looked very good :D
<cwebber2> https://github.com/w3c-social/activitypump
azaroth: looked really good to me
<cwebber2> https://github.com/w3c-social/activitypump/issues
tantek: one request is to link to the issues from the document header
cwebber2: sure i'll make an issue for that right now
... so there are issues on it right now but i don't know if any of these are blockers to take this to editor's draft and if there ar ei'm happy to talk about them
... i think activitypump is probably unsurprising right now
... the first question is is there anything specific someone wants to raise in person or should i start
bengo: i think it's generally pleasant to read. i filed a bunch of issues. i think that the general part that's hard to wrap my head around is how to initiate crud operations around activities
... would be good to have more specific error responses defined
... if i say update facebook.com what should happen? 401? or maybe I did actually change whatever that was and am trying to record it
... i'm having a hard time rationalizing triggering activities and recording activities in the same outbox
<Loqi> Tantekelik made 1 edit to Socialwg/2015-12-01 https://www.w3.org/wiki/index.php?diff=86982&oldid=86981
bengo: one way of resolving it is to have different endpoints for triggering activities vs recording them
eprodrom: we were talking about this during the break. maybe having CRUD processes happen through posting and updating the object itself and how that would work
... you'd keep a collection of everything you publish, once you hav ea permalink for hte thing you can read/update/delete really easily
... would you maintain one single feed/collection of everything you publish? would you keep different collections by type?
... one collection of videos, of images, of text, or does it not matter?
... the meechanism we use is also how opensocial does activities
... most of the crud mechanism was handled by the rest of the opensocial api
... it would be an interesting exercise, chris, if we were to think about that as our mechanism for crudding stuff that lives on the server
cwebber2: i'm not sure what...
eprodrom: having a collection/feed of "stuff evan published", evan's outbox of stuff he made, not activities, but text, videos, etc
... and so the primary way you'd create things is to post to that feed and manage it that way instead of using activitystreams as a command language for crud
cwebber2: i think that sounds mostly fine, but only create should be replaced by that
... kind of what james was saying, when you are distributing it to everyone else you still wrap it in a create, but for creating it initially yes
... but for updating and deleting using the existing verbs
eprodrom: right now we have get put and delete on objects which should do ...
cwebber2: we talked about removing those http verbs an hour ago
... i'm still referencing owen's thing from a long time ago
... if the initial thing you're creating isn't wrapped in a create it simplifies things
<eprodrom> B-)
cwebber2: we should test it in an implementation
sandro: doesn't delete have the same thing?
cwebber2: you use post for everything, but if you're creating something you just put the object somewhere
sandro: what about the other crud operations?
cwebber2: update and delete are pure side effect and then become a log
... you're creating the object in your database that is the log, but you're only putting it there as the side effect
eprodrom: i don't like making it an exclusive thing
... i don't like posting something to a feed that then changes in the feed
... i expect if i post something i don't want it to change
... even though i had posted the object it would then come back wrapped in a create
... i'm saying i post an object to the feed and i see a bunch of activities, what happened to the object? oh its actually a property of one of the activities
... i think if you post an object to a feed then it should come back in the feed
cwebber2: i understand in principle
... it's also not the biggest detail in the world if we don't do this
... it doesn't change things fundamentally. i can live with whatever
... amy you were saying if we moved activitystreams to a more content distribution then that would bring it closer to micropub
<tantek> bengo - could you restate your concern?
sandro: this seems like a place where activitypump is a complete coin flip between using http verbs or not
<bengo> Does GET /outbox mean
<bengo> List the things I triggered to create their side effect?
<bengo> Or List the understand hows I've done (feed)
<bengo> I don't think it can be both
cwebber2: micropub is closer to what we're doing, where if create is not wrapped in a thing it just makes it
sandro: let me rephrase. it often seems like the entire industry is in love with restful apis. i don't know why personally.
tantek: because the term is ambuguous
sandro: specifically with HTTP PATCH to update and that is a thing that's really popular
... evan you did that survey across a bunch of apis
... i don't know why that's so popular, and i hesitate to go in a different direction
cwebber2: there ar e3 things being proposed here
... activitystreams - everything is wrapped in an activity
... REST - you use http verbs
... the current indieweb style - closer to what owen suggested, don't wrap create in an activity
<bengo> I can weigh in as to why command semantics outside of request body is useful (caching intermediaries like varnish can't easily understand semantics)
evanpro: i don't understand what the advantage is
cwebber2: i'm not sold on either of these but
... two reasons. one is the ACL thing, when you post the initial thing you attach the ACL to the initial object
eprodrom: you can do that right now
cwebber2: the second is trying to move towards a more content-centric version of things
eprodrom: which is what i was saying, have a feed of content things
cwebber2: ironically, if we end up doing what i suggested, the activity stream of what other people are reading is activity centric but the client-server thing is content centric
... but now we have to move to a model where anything that doesn't have a side effect we wrap in a create
... it's a shift in the complexity, but we have these separate things and wehave to make a decision
eprodrom: we don't have to make a decision right now, we can mark it as an issue
cwebber2: i'm adding a note to my previous todo that evan hates it and we should discuss
<Zakim> tantek, you wanted to ask if the intent is to keep ActivityPump use of terms like "displayName" in sync with AS2 changes e.g. displayName->name ?
tantek: is your intent in AP to keep terminology in sync with activitystreams? so do the displayName -> name change?
cwebber2: yes because it's just the API version of activitystreams
<Zakim> kevinmarks, you wanted to state issues with over-literal REST CRUD
cwebber2: 'whatever man just go with the flow of activity streams'
kevinmarks: following sandro's point about rest and crud. the issue is that the crud assumption is you are the owner of the resource completely
... when people go to the contacts app in their phone and see a bunch of emails they delete them and then wonder why gmail autocomplete doesn't work
tantek: there's an additional semantic that the http verbs didn't capture
cwebber2: we aren't planning on using http verbs anyway
<Zakim> bengo, you wanted to request answer to my orig question "What happens if I POST /outbox update facebook.com"?
tantek: a key design feature of using POST for everything was that you can exercise the whole protocol via a simple HTML form
... which is easier than figuring out procedural stuff
bengo: i still think it's unclear, if we're triggering crud operations, what happens if i put an update activity where the object is facebook.com in my outbox? what should I expect?
cwebber2: so you're saying we should document responses when you do something screwy?
eprodrom: i think pump.io silently accepts as long as it's not an object in its own domain
bengo: does outbox mean always do this thing if you can?
eprodrom: that's a tricky part of it, once things are outside the server's control to what extent does it accept things or say "you can't update facebook.com" or does it just accept it
sandro: your feed can say "you became president, you deleted facebook, etc"
bengo: i would recommend not accepting it if it's a command that didn't work
eprodrom: i think that makes the most sense, if this is a thing you're going to execute then try to execute and give back an answer. if it's something you don't understand because you can't do it, then assume the user is talking about something that happened somewhere else.
sandro: what about adding a flag that says who is expected to perform the action
bengo: now that i'm talking about it out loud that may not even be necessary.
cwebber2: i think we just need to document how side effects work more
<bengo> To record your own activities, post to your /inbox
cwebber2: activitypump has strong opinions about what to do about side effects
... i have things i want to talk about with people in the room
... i'm going to start with things least likely to explode
sandro: section 9 includes things about binary data but then talks about reply objects
cwebber2: that looks like it's mis structured
... okay i don't think that any of these things are blockers on hitting editor's draft
... but there are some things that are underspecified in activitystreams or other things
... the first is activitypump, discovery and profile stuff
... suggests something that i don't think anyone suggests implementers to do
... in the paris meeting i threw in something stupid.
... previously pump.io did webfinger-type things. it seems like with the agreement with follow-your-nose, then at the very least webfinger-like things will be handled in a follow-your-nose way
... so what are we going to do
<bengo> define inbox, outbox, feed as linkRelations
<bengo> get html, link response header, webfinger support for free
eprodrom: that's a good question. one thing we could do is define ... how many endpoints do we have for a user? 4-5?
cwebber2: you can get the ednpoints for a user once you have their profile
<rhiaro> rel=inbox ~ rel=webmention, rel=outbox ~ rel=micropub ... maybe??
eprodrom: there are 4-5? followers, following, inbox, outbox? we could define link relations for all of those
<bengo> profile == link rel me?
<tantek> rhiaro, I'd suggest clustering them with a prefix, like ap-outbox ap-inbox etc.
eprodrom: you could use whatever discovery mechanism you wanted, links, rels on a elements, or webfinger, or http headers, or...
... that might be an easy way to punt on this
<tantek> whereas rel values normally express links to *user* semantics
<tantek> like a user's inbox
azaroth_: that seems like a lot of link rels to register
<tantek> like a URL a browser could load and display, not an API endpoint
cwebber2: another suggestion, do a follow your nose thing that takes you to a json document that describes your profile
... what do peopel feel about that?
eprodrom: that seems fine
azaroth_: (thumbsup)
<kevinmarks> things have lots of endpoints already
<azaroth_> +1 to linking to a profile, not linking to potentially many endpoints
cwebber2: i shouldn't say JSONLD, i should say activitystreams with implied context
tantek: it sounds like you have an issue defined.
cwebber2: okay i'll file an issue on this and cc evan
<kevinmarks> linking to many endpoints is common
eprodrom: okay i like that a lot better
<kevinmarks> try looking at any wordpress site
<Zakim> azaroth_, you wanted to express concern :)
tantek: if you're going to define a suite of link rels, then prefix them with ap- or something so that you don't conflict
cwebber2: maybe ap-profile or something?
eprodrom: i'll also open an issue, i'm not sure discovery is part of the API document
... for example if i was twitter and implementing activitypump, you wouldn't have to discover it
cwebber2: along with amy's idea of implementation levels could this be a thing that is an optional implementation level
<kevinmarks> on a wordpress blog I see pingback, alternate, EditURI and https://api.w.org/ as rels
eprodrom: yeah that's fine
bengo: in the times where it says go to a uri and it returns a json document. but if you send it an accept header with HTML only then it shouldn't be required to return JSON. leave room in the spec for content negotiation.
cwebber2: authentication
... this group has said it's not in scope, but by necessity is part of the specs. so far micropub and activitypump put OAuth 2 in the spec.
tantek: strictly speaking, the charter does not include specs for authorization and identity
eprodrom: yeah that makes sense
tantek: that's the restriction, but that doesn't mean we can't reference other specs
... we're all encouraged to make that modular
<azaroth> +1
eprodrom: yeah i think that doesn't make sense to include a full dependency on any particular
<azaroth> Section X: Security Concerns. You should do authentication.
cwebber2: both actiivtypump and micropub, but not solid, say OAuth 2.0 bearer tokens and the specifics are not beyond that
... or do we want to say it's definitely OAuth 2 bearer tokens or should we say we recommend that and leave it open to replace it
tantek: maybe if it's an aspect in common between actiivtypump and micropub it's worth highlighting in the social web protocol document, and if there's enough critical mass that's a point forward
cwebber2: we adopted it mostly becasue the indieweb documented it
... buti'm not sure this is the best way forward but it seems to be a solution
sandro: the important thing is to say we need fthis sort of functionality and then one possible solution is OAuth 2
eprodrom: OAuth 2 is not a simple thing
sandro: should we spell that all out?
eprodrom: NO
bengo: oauth is a framework. it has things like client credentials for client authentication. i'm implementing openid connect, and yeah it's complicated.
eprodrom: and if you're not using SSL with bearer tokens that's bad
cwebber2: so then what do we do?
... how do we get interoperability?
eprodrom: are we talking about client-server or server-server interop? server-server interop doesn't belong here
... so client-server interop happens with documentation
cwebber2: so is this so complicated that it doesn't belong in these specs?
... what is the group's policy on this then?
bengo: if you don't specify it, then there are other good things that will fill the gap
... if you say 'it must use bearer tokens' then it doesn't really say much
eprodrom: another possibility is putting it in security considerations at the end and say authentication must be present
sandro: we can say we're intentionally not specifying that because it's a continually evolving space
tantek: we can say we're actively looking for implementer feedback
Arnaud: generally working groups stay away from this issue
... unfortunately it hurts interop because you can't have interop without specifying this
eprodrom: at the risk of asking for crazy proliferation of specs, could it be a separate specification?
tantek: unlikely in this group because it would be outside the charter
cwebber2: i don't know what to write, anyone want to help?
eprodrom volunteers
<jasnell> FYI: AS2.0 Editor's Drafts updated to reflect today's resolutions and editorial comments discussed at the F2F (http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams-core/, http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams-vocabulary/ )
<tantek> jasnell++ amazing
<Loqi> jasnell has 36 karma
<Arnaud> here is what the LDP WG did: http://www.w3.org/TR/2015/REC-ldp-20150226/#security
cwebber2: i have a feeling this will come up again when we look at interop between the specs
<bengo> let it come up as an issue
<melvster> Arnaud++ good text
cwebber2: we're going to hit this again, and we can't pretend we won't have to talk about it again
<Loqi> Arnaud has 29 karma
<jasnell> FYI: implementation for Node.js has been updated as well (npm install activitystrea.ms), as has the working copy of the JSON-LD context document at http://asjsonld.mybluemix.net
<azaroth> jasnell++
<Loqi> jasnell has 37 karma
tantek: i did just pull up our charter to double check, the word identity is not in our charter. the reference to "auth" is one of the inputs from the indieweb community is IndieAuth.
... so it's an input but not part of the scope and goals
sandro: i remember it being specifically out of scope but can't find an explicit reference in the charter
... i'm more confused about identity since it ties to profile
tantek: i woudl argue that that aspect of identity is in scope
... if it's not in the charter, you have to argue why it's relevant
<bengo> Activity Pump inboxes apply equal well to my house or plant or Thing as to my personal profile
sandro: activitystreams has the notion of identity, actors have a URL
<bengo> activitysteams does not have identity anymore
tantek: profile URL or ID string is different from the notion of a profile with attributes
<melvster> aaronpk: sadly, you cant have a social web without identity
jasnell: the activitystreams spec has the notion of actor which has an ID, it has the "person" object type, and it says that if you are going to describe specific properties of a person then you should use vcard.
<cwebber2> we're having an identity crisis
<cwebber2> :O
jasnell: additionally there is profile object type which is a nebulously defined thing that describes something else
<bengo> jasnell Profile isn't in here? http://www.w3.org/TR/activitystreams-vocabulary/#actor-types
<eprodrom> ack cwebber?
<bengo> fwiw http://www.w3.org/TR/activitystreams-vocabulary/#dfn-profile thanks jasnell
<sandro> sandro: bottom line: we're going to leave identity/profiles fuzzy
cwebber2: what i was going to bring up was transient and private activities?
sandro: would it be okay to leave it out of the first version?
cwebber2: yeah the current version says you have to keep a link and for deleted things you have to keep a tombstone
... i'm curious about people's thoughts, but not required for bringing to editor's draft
<Zakim> aaronpk, you wanted to propose accepting ActivityPump as an editor's draft
PROPOSED: accept ActivityPump as editor's draft
<bengo> +1
<melvster> +1
<tantek> +1
<cwebber2> +1
<azaroth> +1
<rhiaro> +1
<wilkie> +1
+1
<eprodrom> +1
<sandro> +1
<ben_thatmustbeme> +1
sandro: with the intent of putting it on the rec track
RESOLUTION: accept ActivityPump as editor's draft
<azaroth> :)
tantek: i'd like to thank aaron and chris for their hard work, it shows in these drafts
FIN
<wilkie> aaronpk++
<Loqi> aaronpk has 14 karma
<wilkie> rhiaro++
<Loqi> rhiaro has 188 karma
<wilkie> azaroth++
<tantek> wilkie++
<Loqi> azaroth has 9 karma
<Loqi> wilkie has 24 karma
trackbot, end meeting