Social Web Working Group Teleconference

25 Jul 2017

Attendees

Present: sandro, tantek, aaronpk, jaywink, ajordan, rhiaro, cwebber, eprodrom
Regrets Chair: Tantek
Scribe: cwebber2, rhiaro

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..?

<ajordan> +1

<ajordan> oops

<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

<ajordan> +1

<sandro> +1

+1

<rhiaro> +1

<aaronpk> +1

<eprodrom> +1

<eprodrom> Ha

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

<eprodrom> ha

<eprodrom> aspirational

<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

<ajordan> lol

<sandro> lol

<eprodrom> ha ha

<eprodrom> whew

<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

ActivityPub

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

<eprodrom> Wow

cwebber2: Sometimes when your'e o the bleeding edge, you're bleeding.

<tantek> 😂😂😂

<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

<cwebber2> https://github.com/w3c/activitypub/issues/235

<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?

cwebber2: sure

<tantek> is this like a tagging action?

<rhiaro> tantek: no, an object

<cwebber2> https://github.com/w3c/activitypub/issues/244

<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> https://www.w3.org/TR/activitystreams-vocabulary/#modeling-friend-requests

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

<cwebber2> https://github.com/w3c/activitypub/issues/244#issuecomment-317804296

<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

cwebber2: ^
... 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?

eprodrom: No
... 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

<ajordan> q

<ajordan> +

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

eprodrom: yep

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.

<ajordan> +1

<cwebber2> +1

<jaywink> +1

+1

<eprodrom> -0

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

<eprodrom> -1

<cwebber2> :)

<cwebber2> https://github.com/w3c/activitypub/issues/240

<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?

<cwebber2> https://www.w3.org/TR/activitypub/#undo-activity-inbox

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> https://www.w3.org/TR/activitypub/#undo-activity-outbox

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

<cwebber2> https://github.com/w3c/activitypub/issues/242

<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

eprodrom: great
... Aaron and/or Julien?

WebSub

<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

JF2

<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

(political)

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

SocialCG

cwebber: just the stuff we discussed today about accept/reject follow, etc, and http signatures, meetings tomorrow

MicroPub

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...

<aaronpk> https://github.com/w3c/Micropub/issues/101

<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?

aaronpk: yes

<tantek> so it's maybe worth starting Webmention errata similarly

<ajordan> AS2 issues too: https://github.com/w3c/activitystreams/issues

<tantek> thanks ajordan

<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

<ajordan> https://github.com/w3c/activitystreams/issues/424

<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

oh

<sandro> mine too

phone decided meeting over :)

<aaronpk> oh good not just me

<eprodrom> ha

<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.

+1

<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

<tantek> ok

<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]

Socialwg/2017-07-25-minutes

Social Web Working Group Teleconference

25 Jul 2017

Attendees

Contents

Approve last two weeks' minutes

Post Type Discovery

ActivityPub

WebSub

JF2

SocialCG

MicroPub

Summary of Action Items

Summary of Resolutions