Social Web Working Group Teleconference
25 Jul 2017
See also: IRC log
- sandro, tantek, aaronpk, jaywink, ajordan, rhiaro, cwebber, eprodrom
- cwebber2, rhiaro
- Summary of Action Items
- Summary of Resolutions
<xmpp-social> [ajordan] h2b: I should clarify, I'm the admin of this _room_, not the entire XMPP server
<xmpp-social> [ajordan] I would poke around koderoot.net for some contact into
<xmpp-social> [ajordan] Telecon people: dialing in; I'll be present+ in a sec
<jaywink> cwebber2: heh thanks. was in the last meeting too ;) I think
<cwebber2> scribenick: cwebber2
Approve last two weeks' minutes
<tantek> PROPOSED: Approve 2017-07-18 and 2017-06-27 minutes
RESOLUTION: Approve 2017-07-18 and 2017-06-27 minutes
<Loqi> Rhiaro made 1 edit to Socialwg/2017-07-25 https://www.w3.org/wiki/index.php?diff=103965&oldid=103964
cwebber2: we don't have enough time it seems to be able to cancel, so I'd prefer to either reinstate meetings or switch to 90 minutes meetings
tantek: probably easier to do 90 min meetings, sandro said they may think that's what happens during times like this in other groups?
<tantek> PROPOSED: August telcons (as already scheduled per previous resolutions) extend to 90 minutes each
RESOLUTION: August telcons (as already scheduled per previous resolutions) extend to 90 minutes each
<tantek> chair: sandro
Post Type Discovery
tantek: feel like I'm making good progress on PTD, and there's feedback and a new implementation
<Loqi> [tantek] #25 Response Type: move "reply" to 2nd to last to enable p-summary fallback use-cases
tantek: one thing I wanted to go over was issue 25, eg how to handle replies and fallback, it talks about extensibility a bit, which is adding new features over time which we've done in general for PTD. So specifically for responses, any kind of response like likes, posts, shares, we almost always have text equivalent which is something we've seen when people post things to twitter, or facebook has an "all activity" page where you can
see everything you've done
tantek: that being the case, if some new response type comes up in the future, like you're bookmarking something or etc then you should always be able to say "hey this is a response" and then have text equivalent in summary property
... so any existing impls that don't know as response will be able to show something sensible, as in something author produced that shows something sensible
... I wanted to get feedback/observations on whether they agree/disagree, etc
sandro: tantek, are you looking for general feedback or a vote?
tantek: I feel pretty confident about this change so I wanted to bring to the group explicitly. other than objections and people saying "no you're wrong this will never work", I would like feedback on "this sounds reasonable", but I can accept lack of feedback. Ideally I'd like to say "accept my proposal and publish a new WD based on this change". that's my longest answer to you
sandro: anyone have any feedback? seems like that's your quiet answer for now
tantek: that's ok, figured this would be a group for feedback, but if people are fine I suggest we publish a new WD with this change
... I think that's a reasonable request to make?
<eprodrom> Hey friends
sandro: seems fine
<ajordan> heya eprodrom!
tantek: ok, should I do a PROPOSED..?
<tantek> PROPOSED: Publish new WD of Post Type Discovery with change as proposed by editor in https://github.com/tantek/post-type-discovery/issues/25
<Loqi> [tantek] #25 Response Type: move "reply" to 2nd to last to enable p-summary fallback use-cases
RESOLUTION: Publish new WD of Post Type Discovery with change as proposed by editor in https://github.com/tantek/post-type-discovery/issues/25
<Loqi> [tantek] #25 Response Type: move "reply" to 2nd to last to enable p-summary fallback use-cases
<eprodrom> I can't remember if I name checked you or not
<eprodrom> I'm pretty sure ajordan is in there.
<ajordan> eprodrom: not explicitly but you meantion "pump.io contributors", plural, which I thought was amusing
<sandro> even, audio?
<tantek> eprodrom: are you on the call?
<eprodrom> Well enough chat I'm supposed to be on a W3C socialwg con call right now
<eprodrom> ha ha
<sandro> eprodrom can you hear us>?
<eprodrom> I am here!
<tantek> chair: eprodrom
<rhiaro> I can scribe for the next 30 mins
<rhiaro> scribenick: rhiaro
cwebber2: This week I was going to have to have the test suite up, and I would if it weren't for that meddling language I am using
... Screenshot ^ of the test suite
... Tried against puckipedia's server and I had the very issue I was afraid of
... since I'm uisng a cool new bleeding edge non blocking async implementation, something isn't implemented yet, and I have to add something to the language
... hopefully over the next week I will fix the language and have this rolled out
... using Guile, a lisp-y Scheme thing
cwebber2: Sometimes when your'e o the bleeding edge, you're bleeding.
<ajordan> "edge" implies cliff
<ajordan> not "bleeding flat"
eprodrom: The test suite is close to completion, but we're seeing bugs because of the underlying platform
cwebber2: the client-to-server tests would be up
... That stuff is done
eprodrom: I have a couple of questions
... Looking at the screenshot, you have a number of 'OK's - are they not meaningful because of the async problem or is this something someone could run now?
cwebber2: All those tests are meaningful
<Loqi> Cwebber2 made 1 edit to Socialwg/2017-07-25 https://www.w3.org/wiki/index.php?diff=103966&oldid=103965
cwebber2: The failed one is a bug I introduced right before I ran the test suite
... The tests are doing their things
... they have caught legit things, like http status codes and headers
... They work, it's just this blocking thing
eprodrom: I'm wondeirng if there's any point in actually having people start using it immediatley?
cwebber2: I have a version running that people could look at but one single test that runs over https will pause the whole server
... so there's not much point
eprodrom: okay cool
cwebber2: Moving on..
... I have 4 issues on the agenda
<Loqi> [cwebber] #235 Add a Tag type
cwebber2: One is kicked out to an extension, but Evan was going to follow up
... Evan you said you'd catch up with jasnell and find out the histoyr of why we don't have a Tag type
... Mastodon just went ahead and added it to theirs
... Even though we agreed that vocab extensions should move tan extension, I was curious if you'd heard from james
eprodrom: I haven't talked to james, I will make a note
... Could you assign this issue ot me?
<tantek> is this like a tagging action?
<rhiaro> tantek: no, an object
<Loqi> [cwebber] #244 Accept / Reject a Follow
cwebber2: the next one is about the Accept/Reject stuff
... talked to evan last week about it.. then did some more reasearch
... Some servers think about Follow as 'hey I want to subscribe to your public updates'
... in AP you can address to Public and/or followers, but not necessarily both
... This is how twitter and mastodon have this concept
... in Mastodon you might follow someone. Usually the follow is just automatic, but if they have a private account, they manually accept and reject who they're following
... when they send stuff to followers that stuff is not public, it only goes to the followers collection
... they're using it as like a trusted friends collection
cwebber2: at the end of last meeting, evan suggested we can still use the followers thing for the public subscribe, and pointed out that AS2 has a way of doing this kind of subscription using Offer and Accept/Reject on offer to do friend requests
... I took a look and thought about it and unfortunately I think that's going to result in something disjoint, because we'll have two different mechanisms for follow
... you still might send a Follow request to somebody and yu would effectivley be a diferent system
... AJ raised a concern that maybe we won't get this specified in time
eprodrom: These are two very different ways that different social networks do the social graph
... The fact there are two different ways to do it is already out of the barn
... LinkedIn does it how facebook does it.. others don't have a two way relationship, instagram, snapchat, twitter
cwebber2: twitter for public accounts
eprodrom: Right. And twitter for private accounts is almost the same except it doesn't have the reciprical follow
... We are not going to be able to dictate that all social system should work a particular way, and that's not to our benefit
... We should be able to represent both
cwebber2: So we have a suggestion that I thoguth was pretty good, summarised in last comment on the issue
<Loqi> [cwebber] Amy suggested over PM that:
<Loqi> * If a server returns 200 or 201, assume the follow just went through
<Loqi> * If returning 501, the server doesn't support following
<Loqi> * If a server returns 202, then the server will send an Accept / Reject
... This would be backwards compatible
... This does introduce another state which maybe is why evan is -1ing it
eprodrom: We just tend to represent this kind of thing as activities not http replies
... if you have different types of social graph behaviours we tend to represent them explicitly as json structures
... Cant' we have two different mechanisms?
cwebber2: if we implemented two different kinds..
... a) if we add the Offer and relationship thing we're going ot have to add that like immediately and I'd need your help because I don't think I'd get it completely right
... we need to give implementors guidence
... and it needs to be in this draft
... THe other side of it is I"m not sure the Accept/Reject, aside from backwards incompatability, is so bad, because if you look at the case Mastodon supports both
... automatic public accounts, and private accounts
... The implementation just automatically returns an accept if it's a public account
... Evan. could you help with the text if we did the Offer thing?
... We can make it required to return an Accept or Reject
... The relationship is always uni-directional
... You can always structure that bidrectional using automatic requests
cwebber2: You can always add those other types of things later right?
eprodrom: Right. Alice wants to follow Bob, Alice sends a Follow to Bob and at that point the request is that their relationship is in a waiting state
... then Alice should receive either an ACcept or Reject
... While it's in the waiting state, Alice should not show up in Bob's list of followers, Bob should not show up in Alice's followees
... Maybe there's a third stream of like open invitations that are in waiting
... Might be useful for end users
eprodrom: There's if Alice's server receives any updates from Bob's server while in the waiting or Rejected state, it should reject them
... So no implicit acceptance becuase you start getting activities
cwebber2: I don't know about the reject thing because you can send activities to someone you're not following
cwebber2: Servers that want to do the automatic reply can just immediately fire an automatic Accept
eprodrom: and others can wait for a user input
cwebber2: that simplifies things
eprodrom: Let's do it
cwebber2: do we need a resoution?
<rhiaro> This sounds fine, totally fine with skipping the implicit Accept
<cwebber2> PROPOSED: Resolve issue #244 by having Follow be responded to with an explicit Accept / Reject as mandatory.
eprodrom: I thought you were going to write the text
<tantek> "mandatory" as must or should?
eprodrom: I mean not today. For discussion next week
cwebber2: Sure, that's fine
eprodrom: think through the edge cases, then come back with 'this part has been updated'
<tantek> +1 to what eprodrom just said
cwebber2: I'll make a note on the ticket
<Loqi> [puckipedia] #240 Document `Undo`ing Blocks, and maybe reading back Blocks
cwebber2: We have documentation about how to do some undos.. two proposals..
... 1. We add spec text on how to undo blocks
... 2. Should we have a collection fro blocks themselves
... We should do these one at a time
... So the first one is are people comfortable adding normative spec text about how to undo a block
eprodrom: We have general undo discussion already right?
eprodrom: This is a refinement of the instructions, not a change in the way you would do undo?
<tantek> "how to" sounds like guideline, not normative text
cwebber2: Right, the current undo phrase is very shrot and very general
cwebber2: It says look at these inverse .. and it's referign to the client to server behaviour.. it's kind of vague
... side effects should be undone to the extent possible
... so you can already imagine what an unblock looks like
... so actually it might be fine.. maybe we don't need to add text for that
... I would be okay actually saying the text is fine as is
eprodrom: I'm not sure I have an opinion
ajordan: are we sayng that the spec text is good for this issue, for for point 1?
cwebber2: for point 1 of the issue
... Not the reading back part
<eprodrom> "For example, Undo may be used to undo a previous Like or Follow." -> "For example, Undo may be used to undo a previous Like, Follow or Block."
cwebber2: I'm moderately convinced actually that the spec text does a good job, and we can move on if everyone else is okay?
... Evan I think that resolves it
... Thes econd part is whether we should expose a private blocks/blocked collection?
... I can't think of the right grammar..
... We could add a blocks property to actors and say hey it should be in this collection. Useful for client to server, but suepr weird because only the actor would be able to read that collection. So it would be weird to notice that on a person's profile
... Seems strange, but would be okay with adding it
<tantek> Flickr and Twitter both provide a viewable blocklist. Twitter provides API for reading it too.
eprodrom: Seems reasonable to me
cwebber2: I'll write wording and get this back next week
<rhiaro> cwebber2: I don't think it's weird, from an application standpoint (who is gonna be reading the data) seems fine
<Loqi> [cwebber] #242 sharedInbox / siteInbox type endpoint (publicInbox, but not just for public posts)
cwebber2: I'm just going for more group input on this cos nobody else was here
... Wiat I'm wrong, we discussed this
... Don't need to go over that again
... I think those are all the issues I wanted to review for this week
... Maybe I should make a new WD for next week?
<tantek> new ED or CR?
cwebber2: a new CR
... I think there have been a bunch of non-normative changes. I'll prepare a changelog for next week
eprodrom: We have one other item.. about schedule
cwebber2: we decided to move the ones we do have to 90 minutes
... Aaron and/or Julien?
<cwebber2> scribenick: cwebber2
<tantek> what's next for WebSub?
aaronpk: I don't think there's anything new from last week, which means that we've got a couple of implementation reports, but nothing new
<eprodrom> ben_thatmustbeme: are you here?
tantek: not on JF2 but on websub, I want to know what's next step on websub?
aaronpk: good question, I think we have enough implementation reports to have two of each role
sandro: last time we talked about this I think I said we also need implementation reports to major existing implementations? mastodon for example
tantek: pushback from postActiv
tantek: and mastodon we don't know of?
aaronpk: gargron not willing to submit it himself but suggested someone else could
tantek: didn't I see him do it live in #social?
aaronpk: oh you're correct, that's hilarious
... he ran through all tests and reported in irc, so I'll capture that into a report
tantek: should be acceptable because you can cite public logs
... no news on google yet
... what's drop-dead date on transition to PR?
sandro: we still have a while, I guess it's really like sometime in november
tantek: assuming we want to see Rec happen in-charter?
sandro: maybe Nov 1st
... 5 weeks before charter, + a week or 2 for holidaze
eprodrom: next step to collect, november timeframe for websub?
tantek: we believe websub reports exist, are waiting for reports?
sandro: I don't think we should wait that long if we don't have to, would be good to have wrapped up in september
... unless we have a real reason to wait
cwebber: just the stuff we discussed today about accept/reject follow, etc, and http signatures, meetings tomorrow
aaronpk: now that we're in Rec, if people find minor typos or larger possible issues (not adding features) what options might there be for normative issues?
<tantek> issue link?
<tantek> github issue link?
sandro: my understanding is that in the link you may point to errata, which could point to issues
aaronpk: what's the process of going from issue -> errata?
sandro: if there seems to be no disagreement, copy it over
... more like traditional FOSS'y stuff, just assume everyone speaks for themselves and nobody has authority over anyone else, just document if nobody disagrees, if disagreement then document that too
aaronpk: makes sense but looser than I expected
sandro: I've never handled a case where errata happens during WG
tantek: CSS WG does this all the time
... key part is you need to drive resolution of issues to PR
... that you should do issue by issue in WG
... I think that will help illuminate meta-discussion of how to move forward
eprodrom: specific to a specific issue?
<tantek> the "errata" link in the REC links to https://github.com/w3c/micropub/tree/master/errata
aaronpk: there is an issue but I wanted to understand what to do in general since we have a running WG
eprodrom: could I pose a suggestion, which is anything you don't feel comfortable unilaterally updating might not be an eratta? may be something normative or which needs to go into next version of spec?
... that may be a high bar right?
tantek: may be a bit too much burden to put on an editor, because it's a REC we have more bearing on what we need to do
... we resolve it on how we resolve any other issue
... since we have a link in the doc which links to an errata document, a WG resolution on an issue drives addition of stuff to that page. becomes a delta document of sorts
... if we get to the point saying this is a non-trivial amount of errata, there's a process for releasing 1.01 or etc. depends on if it's normative or non-normative changes
... we can cross those issues when we get there
eprodrom: I tend to think of errata to see non-normative changes...
<Loqi> [voxpelli] #101 Should string really be a MUST for non-HTML content?
aaronpk: I'm on board with typo issues just filing them without discussing them, but this one is technically normative but spirit of this was incorrectly converted into text for the spec
... the content property MUST either be an html object or a string
... intent was by default it's text, if html it's html text which allows for ability to do extensions in future we haven't thought of now
... way we have it now it's not technically possible to do extensions
... this would be normative, but would allow extensions to happen.
tantek: it's normative, but
aaronpk: it's extensibility, not a feature itself
... it's the ability to add features itself, not going to make it so you have to do things differently with current implementation to support features as-described in spec
tantek: that depends, what text do you have in terms of what to do when things aren't recognized?
... does the spec say what to do if there are additional keys or not in content property?
... if that's not explicit, there's work to do to research on right behavior and etc
... are we documenting mutual agreement or disagreement?
... that makes it basically a feature
... feature is for compatibility, essentially
... in that case you allow langugage that does
... that allows for extensions to happen , etc
... not a user-facing feature, but it allows interop
<Zakim> cwebber, you wanted to ask about as2 extensions
<ajordan> cwebber2: agenda+
eprodrom: I've gotten lost in the conversation... aaronpk you're asking for guidance on normative errata?
... if they're normative, I'm not sure if there's anything to do but make a new version?
... I'm confused as to next steps
aaronpk: for this particular issue, can this be filed as errata even though it's normative is question #1
<tantek> regardless, good to start processing open issues (consensus on spec text change, document spec text change on errata page) https://github.com/w3c/Micropub/issues
sandro: can be filed as a recognized problem, but we can't say here is the approved solution... we can only take a solution as far as what would be a working draft, but we can't have w3c recognition on approved solution
tantek: if we believe resolution is what's approved we can take it to CR directly without WD
sandro: in theory, I'm not sure that's part of approved use of time
tantek: if it's a non-breaking change, maybe can move to PR directly
sandro: before anything goes to AC, I need to see if it's in-scope for extension which is debatable
tantek: it's open for interpretation, but IMO maintenance is something any charter extension would/should support
... but before we try to answser the hard problem, if there are any typos or etc that you can resolve by proposing errata text to add to the doc etc and add to them, that would be a good start
... maybe cherry pick an easy one for the next telcon, try to reduce set of open issues down to harder ones
... can try to figure out least-impact path forward for those
... it'll keep you iterating with charter question
... to make it normative we have to go through process sandro suggested
eprodrom: sounds reasonable to me
<tantek> also notice there are open Webmention issues: https://github.com/w3c/Webmention/issues
eprodrom: all you needed for micropub?
<tantek> so it's maybe worth starting Webmention errata similarly
<ajordan> AS2 issues too: https://github.com/w3c/activitystreams/issues
<tantek> thanks ajordan
<tantek> also note, zero open LDN issues: https://github.com/w3c/ldn/issues therefore no need to errata anything
eprodrom: read through AS2 extension document first
cwebber2: sounds good
ajordan: I just wanted to point out that there's an open issue about submitting to IANA that seems particularly important to resolve
<Loqi> [dissolve] #424 register media type with IANA
eprodrom: that would be me, will look
... I think that's our last item, if there's anything else we have 10 more minutes I'd love to get back
<Zakim> tantek, you wanted to quickly mention Webmention issues https://github.com/w3c/webmention/issues and errata https://github.com/w3c/webmention/tree/master/errata
tantek: similar to micropub we have open webmention issues that are probably worth processing into webmention errata, so aaronpk maybe see if you can quickly document into errata etc
... vs request for new feature too, you can document separately, point is to process open issues
<sandro> mine too
phone decided meeting over :)
<aaronpk> oh good not just me
<eprodrom> We are close to done. I am still on the call.
seemed like a good place to stop
<aaronpk> ha can't dial back in
<eprodrom> OK, mine just stopped too
<ajordan> aaronpk: same
<eprodrom> OK, so, meeting over? Let's wrap now and we can discuss next meeting.
<eprodrom> tantek: did you have an additional point, or can we wrap?
<tantek> was dropped mid sentence
<tantek> point is to process open issues, and add to the errata accordingly, and close the issues hopefully, keeping the number of open issues at 0
<eprodrom> OK, let's wrap up.
<eprodrom> Thanks, tantek
<eprodrom> Thanks everyone
<eprodrom> trackbot, end meeting
<ajordan> thanks all
Summary of Action Items
Summary of Resolutions
- Approve 2017-07-18 and 2017-06-27 minutes
- August telcons (as already scheduled per previous resolutions) extend to 90 minutes each
- Publish new WD of Post Type Discovery with change as proposed by editor in https://github.com/tantek/post-type-discovery/issues/25
[End of minutes]