Social Web Working Group Teleconference -- 18 Jul 2017

<jaywink> (irc only though)

<cwebber2> scribenick: cwebber2

<ajordan> ;)

<ben_thatmustbeme> i'll try to scribe the the AP section if needed, i don't know if i'll have to leave early or not though

review previous meetings' minutes

eprodro57: looks like we have two weeks of minutes to review. I think for the 6-27 we have the wrong minutes... looks like the CG minutes...

ajordan: we do have some CG minutes that are missing

<eprodrom> https://www.w3.org/wiki/Socialwg/2017-06-27-minutes

cwebber2: I think the CG can deal with the CG's missing minutes part

ben_thatmustbeme: I volunteer to track down the minutes for later

eprodrom: ok instead of proposing to review the minutes for 6-27 let's review the minutes for 7-11

<eprodrom> PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-07-11-minutes as minutes of the 2017-07-11 meeting

<ajordan> +1

<eprodrom> +0

<ben_thatmustbeme> +1

<rhiaro> +1

RESOLUTION: Accept https://www.w3.org/wiki/Socialwg/2017-07-11-minutes as minutes of the 2017-07-11 meeting

<rhiaro> I'll chase down those

eprodrom: so we have to shake down the 6-27 minutes and I guess we'll have to do that

<rhiaro> I thin kthat was a sandro scribing week

eprodrom: one thing about minutes we can see who did what

<ben_thatmustbeme> its clearly the 6/28 minutes there

<ben_thatmustbeme> from the CG

eprodrom: do we have the raw minutes?

<rhiaro> Give me 5 mins I'll find it

eprodrom: I'd like to move forward

<ajordan> rhiaro++

eprodrom: let's talk about the next item which is august dates

August meeting dates

<rhiaro> Last week everyone voted, and we have results, but for a couple pending Evan's opinion

<rhiaro> :)

eprodrom: in august we have 5 tuesdays, we talked about doing every other week?

<rhiaro> <sandro> CANCELING July 18, ug 8, Aug 22

<rhiaro> <tantek> for sure: 7/25, 8/15, 8/29. 8/1 contingent on Evan chairing

cwebber: I propose we do meetings every week because we seem to wanting to cut down meetings and are not able to

<ben_thatmustbeme> -1 as i feel like most of the meetings are things that should be done async anyway

eprodrom: it's just at tough time to have frequent meetings, but

<eprodrom> PROPOSAL: cancel meetings for 8/9 and 8/22

<eprodrom> PROPOSAL: cancel meetings for 8/8 and 8/22

<rhiaro> +1 and +1 from sandro in absentia

<ben_thatmustbeme> +1

cwebber2: -0 but i won't fight it

<eprodrom> +1

<ajordan> +0

RESOLUTION: cancel meetings for 8/8 and 8/22

PTD

eprodrom: tantek is not here yet, so I'd like to push PTD to the end of the agenda
... let's talk about bridging

<rhiaro> https://www.w3.org/wiki/Socialwg/2017-06-27-minutes minutes are corrected

bridging ActivityPub and IndieWeb stack

ajordan: I guess that's me

<ajordan> https://indieweb.org/bridge#ActivityPub

ajordan: this is something that came out of indieweb summit, and basically we think we can find a semi-decent way to bridge activtiypub and the indieweb stack
... so the simplest by far is micropub, because we think it can be possible to write a website that can transform microformats into an ap activity
... the tricky thing is mentions, there are two parts of this; AP->IW sites, and IW->AP
... so AP->IW, my theory is that IW sites should be able to put a static paage on the root of the site
... so any time an AP site mentions the actor at that site
... all mutation and stuff will resolve to a bridge service that will construct things on the fly
... that sort of makes sense

eprodrom: for it would be a facade server doing AP on one side or IW on the other? C2S is simple on this system, you use your preferred provider, and the bridge does transformations
... for S2S, what you're saying is that IW servers, if IW servers that support webmention, they should also have a way to expose AP server to server by handing that off to a bridge. that bridge would take anything coming to an inbox and translate it back
... so yeah

ajordan: exactly
... this does require the IW site to put the JSON file at the root
... I should make it clear we put this at the root and then set the server to ?

<ben_thatmustbeme> JSON file at the root, would be a problem for some

ajordan: if the IW site does not do this, you can have a situtation where you prefix this url with the bridge url, then you query the bridge url and get an actor back and all that
... so that's a worse UX but it should work
... even if the IW site hasn't opted in

eprodrom: from my point of view of discovery, if we're not solving on discovery, maybe we could have another discovery mechanism such as link headers, etc
... if my site returns html you can do antoher discovery method
... you should be able to get the json descriptor currently in AP
... so could we expand AP to say in the erroneous situation where they return HTML instead of JSON, this is what you will do

ajordan: what would you do in that case

<cwebber2> jaywink, I agree

eprodrom: so link rel=inbox, href=url of bridge, etc

ajordan: if you're already going to do this if you're already adding this?

<ben_thatmustbeme> evan covered it

eprodrom: if you're adding something with just html but can't do content negotiation
... there's a big jump between them, I think

ajordan: I can file an issue about this

cwebber2: I think it would be nice, but it could be a MAY, it's already a lot of work

eprodrom: it could be an extension
... also you could do rdfa or something similar
... you could grab out the AS2 data
... probably not the most exciting thing for MF2 folks, but a possibility

<rhiaro> the link rel would parse as rdfa

<rhiaro> LDN already got that covered

ajordan: seems like we're agreeing it's either a MAY or an extension

<tantek> wait why are we talking about theoreticals? ("or even"?)

ben_thatmustbeme: if you implement it as a MAY, doesn't it break federation?

<tantek> At this point, it doesn't make any sense to include anything in the spec that's not at least semi-widely implemented / deployed like that

eprodrom: yeah I think that's absolutely right and if that's not something we want to do let's not build two diferent stacks

<tantek> rather than trying to be politically correct (or we can be politically correct in informative Notes)

ben_thatmustbeme: I don't think this is specific to bridging
... if you're going to support it it should be required

<rhiaro> 1) This bridging stuff can go in SWP if we settle it, not needed in AP

<rhiaro> 2) Can we timebox this discussion and end it imminently because there's lots of AP stuff to go through?

<Zakim> rhiaro, you wanted to say (typing on irc only)

<rhiaro> ^^^^

<rhiaro> No

<tantek> I think it can be in SWP if it's figured out, the point of the discussion is spec impacts

<tantek> it's not figured out AFAIK

cwebber2: I think this shouldn't be rdfa, it could be embedded as json-ld as is done in schema.org things etc

tantek: +1 on not doing rdfa, we shouldn't do normative text that's not deployed
... I agree with moving to SWP when it's figured out
... that's what I'm interested in, if it requires spec changes then it needs to be figured out asap

<eprodrom> call dropped

<Loqi> Rhiaro made 1 edit to [[Socialwg/2017-06-27-minutes]] https://www.w3.org/wiki/index.php?diff=103817&oldid=103706

<tantek> bridging++

<Loqi> bridging has 1 karma

eprodrom, you dropped out, tantek is temporarily saying we're moving on

<eprodrom> Let's move on to the next topic

CR to PR items

<eprodrom> cwebber2: yep

<ajordan> eprodrom: we didn't discuss IndieWeb -> ActivityPub (the other direction) but it's at https://indieweb.org/bridge#ActivityPub and pretty clear if you want to look at it

https://github.com/w3c/activitypub/issues/242#issuecomment-315645158

<Loqi> [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit

<Loqi> Someone correct me if I'm wrong but I believe this was the consensus:

<Loqi> 1. sharedInbox is used only for public and followers delivery, ev...

<ben_thatmustbeme> scribenick:ben_thatmustbeme

cwebber2: we are basically seeing DB / storage issues bleed in to spec
... we have a public inbox vs shared inboxes

to allow for delivery to large sets of users

<jaywink> :D

cwebber2: i would like to rename to shared inbox

(request coming)

<cwebber2> PROPOSAL: Rename publicInbox to sharedInbox and allow it to both post public posts and posts to followers

<tantek> ajordan: which summary in github?

<ajordan> tantek: https://github.com/w3c/activitypub/issues/242#issuecomment-315645158

<Loqi> [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit

<Loqi> Someone correct me if I'm wrong but I believe this was the consensus:

<Loqi> 1. sharedInbox is used only for public and followers delivery, ev...

<cwebber2> https://github.com/w3c/activitypub/issues/242#issuecomment-315645158

<Loqi> [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit

<Loqi> Someone correct me if I'm wrong but I believe this was the consensus:

<Loqi> 1. sharedInbox is used only for public and followers delivery, ev...

sandro: my one concern is if someone posts to this, thats malformed, it doesn't end up public when they didn't want it to
... the implicit action that creates, is that also true on this

cwebber2: thats only on client to server

sandro: no problem then

<cwebber2> PROPOSAL: Rename publicInbox to sharedInbox and allow it to both post public posts and posts to followers

<ajordan> +1

<cwebber2> +1

<jaywink> +1

<aaronpk> this is a breaking change to all implementations, right?

<rhiaro> all implementatins that implemented publicInbox which I don't think is required..? (correct me..)

<ajordan> aaronpk: not technically

<ajordan> we're changing semantics but we're also changing the name, and the existing publicInbox is a MAY

tantek: where is the actual change to the spec here

cwebber2: this is allowing for if you are posting to all of your (millions of) followers but not posting publicly

<tantek> is this implementable? prototyped?

cwebber2: the receiving server will see that this is to their followers collection and it knows who the followers are on your server
... you can already do that, but you currently also have to post it publicly

<ajordan> tantek: I'm not sure about implementations but Mastodon has made it clear that they need this

<ajordan> and are planning to do it

tantek: i'm a little concerned that we are making changes to a CR that no one has implemententd

cwebber2: mastodon is already implmenting it, and puckipedia is implementing it

tantek: thats a good thing to capture in an issue, not to make it a change in the CR

<jaywink> before it was all just theory

tantek: you think this is a change to existing functionality, not adding?

cwebber2: it is a slight add of being able to not post publicly
... it is breaking

<eprodrom> tantek: I'm back, can chair from here

ajordan: afaict its not breaking
... it was a may before and its a may now
... so any that didn't do it before, it doesn't matter, and anyone who did it before will still be compliant (just without that feature)
... we both shared the same concerns as you (tantek) had, but its really just refining this feature

tantek: i am not questioning the Why at all, i am just trying to make sure we do the right thing for our CR

sandro: your concern is that we are making this change but we are going to have to change it back

tantek: i think we may need to change it again
... in order to minimize issues, its better to implement it before it goes in to the CR

<rhiaro> If we made this change now and had to fix it in a month, or if we wait a month and make it then, it doesn't make any difference to CR.

<rhiaro> tantek cwebber2 ^^?

tantek: you can land the text in the ED of how this will work
... but before it lands in CR, it should have prototypes

<ajordan> rhiaro: by "make this change" do you mean the WD or the published CR?

<eprodrom> PROPOSED: for https://github.com/w3c/activitypub/issues/242 rename publicInbox to sharedInbox and allow sending to followers only

<rhiaro> ajordan: CR

<ajordan> right

<ajordan> +1

<eprodrom> PROPOSED: for https://github.com/w3c/activitypub/issues/242, group supports renaming publicInbox to sharedInbox and allowing sending to followers only IFF implementation support

<cwebber2> +1

<ajordan> +1

<jaywink> +1

tantek: in general thats a good bar for AP changes at this point

<eprodrom> +1

<cwebber2> sandro: +1

<jaywink> but it can still land in the editors draft to not confuse current wip version?

<eprodrom> tantek: thank you

eprodrom: is it okay if we defer 244?

<ajordan> tantek++

<Loqi> tantek has 66 karma in this channel (370 overall)

<Loqi> [cwebber] #242 sharedInbox / siteInbox type endpoint (publicInbox, but not just for public posts)

<rhiaro> I can't stay

<ben_thatmustbeme> i cannot stay late on audio

WebSub

<cwebber2> scribenick: cwebber2

aaronpk: I think the only topic is the one in the notes

<ben_thatmustbeme> rejoining

<eprodrom> https://git.postactiv.com/postActiv/postActiv/issues/139#note_1690

aaronpk: the person does not want to submit an implementation report because they're unhappy with EME

sandro: I think there's not a lot we can do about it and we should move on

ben_thatmustbeme: on another point, as in terms of websub implementation reports, an fyi that diaspora did an implementation of websub but might not submit an implementation report because they may drop OStatus

sandro: I think it would be nice to have impl reports that speak to just that it's compatible with classic PuSH
... for me that's valuable

tantek: good point

eprodrom: that sounds reasonable

<tantek> sandro++ for seeing the positive. thank you

<Loqi> sandro has 47 karma in this channel (54 overall)

<rhiaro> Adding for the minutes that sandro said he will report the EME thing to Team and tantek will report to AB

eprodrom: do we have ways in impl report template for 3rd party supporters?

aaronpk: there's nothing in the template right now but I know there's a line with author / etc
... nothing else for websub

<ben_thatmustbeme> http://dissolve.github.io/jf2/#changes-from-27-june-2017-wd-to-this-version

JF2

ben_thatmustbeme: looking for more info for impl reports

<eprodrom> PROPOSED: publish new working draft of JF2 based on editor's draft at http://dissolve.github.io/jf2/#changes-from-27-june-2017-wd-to-this-version

<ajordan> +1

<eprodrom> +1

<aaronpk> +1

tantek: I'm seeing validator, sample set, implementation reports linking to jf2.rocks, is that right?

ben_thatmustbeme: that's the landing page for now that links them all

tantek: ok just checking

<tantek> +1

RESOLUTION: publish new working draft of JF2 based on editor's draft at http://dissolve.github.io/jf2/#changes-from-27-june-2017-wd-to-this-version

tantek: 30 sec update, I'm successfully using JF2 to do social embedding on my site
... just as an FYI
... it's working very well as a transport format
... that's how I'm showing rsvp's on my site

PTD

<Loqi> [tantek] #25 Response Type: consider "reply" for 2nd to last for fallback use-cases

<ajordan> scribenick: ajordan

cwebber2: this one's big but it's short

https://github.com/w3c/activitypub/issues/244

<Loqi> [cwebber] #244 Accept / Reject a Follow

cwebber2: people want to be able to accept and reject followers
... we propose that everyone always sends an accept/reject
... for people that always want to accept, you just automatically send an accept back
... this makes it mandatory that you always send an accept/reject to a follow request

eprodrom: what happens to existing impls that don't send an accept or reject
... can you say they're default accepted?

cwebber2: so this is why we need to make it mandatory...
... so if you don't hear back you'd know
... you could possibly check the followers list

sandro: it could take a couple weeks right?

cwebber2: if you don't hear back you'd see a "waiting" type interface
... I agree that this is a big backwards-breaking change

eprodrom: three states: waiting, accepted, rejected

<ben_thatmustbeme> this sounds like a mix of network stack levels

eprodrom: what if I get an update from someone I'm waiting on
... what if I've been rejected and I receive something

cwebber2: this is tricky because I can add you to my friends list but not my followers list

<ben_thatmustbeme> are we talking about an ACK as i receieved the request?

cwebber2: diaspora-style aspects

eprodrom: maybe if you reject a follower just don't send them anything
... you've got a lot of cases here and I'm not sure what that complexity buys us

sandro: it buys you a good UI
... I clicked mastodon's follow button and I was frustrated because it didn't provide any feedback
... but it was really in the waiting state

cwebber2: there's another reason that we need this in a sense
... other social networks provide this
... Facebook provides this

<eprodrom> https://www.w3.org/TR/activitystreams-vocabulary/#connections

cwebber2: I think it's necessary

???: the whole relationship schema is for that

scribe: follows/unfollows are for this

<eprodrom> https://www.w3.org/TR/activitystreams-vocabulary/#connections

s/???eprodrom/

cwebber2: that could work...
... I didn't realize this was in the spec, this seems kind of reasonable
... I'd move towards figuring out how to do this in the spec
... it'd be a normative change but wouldn't break backwards compat
... it'll take time; I'll work on this

<jaywink> isn't a Follow nothing to do with friend request? it's jsut "I follow that person if they send me something they will"

eprodrom: it lets you have a regular following mechanism like other social networks have
... without all the acks and nacks and stuff

cwebber2: 5 minutes late, I want to get to the one other related thing
... big debate in e.g. Mastodon/AP as to whether you federate a Block
... Mastodon *has* to federate a Block because they don't explicitly ???
... we had a conversation and realized we were kind of overloading Block
... there's disallowing side effects, and there's basically a "request to unfollow"

<eprodrom> https://www.w3.org/TR/activitystreams-vocabulary/#dfn-block

<cwebber2> https://github.com/w3c/activitypub/issues/242#issuecomment-315645158

cwebber2: "I don't want to deliver to you anymore"

<Loqi> [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit

<Loqi> Someone correct me if I'm wrong but I believe this was the consensus:

<Loqi> 1. sharedInbox is used only for public and followers delivery, ev...

cwebber2: I want to get a sense as to what people, especially eprodrom, think about this
... is this reasonable to put in the spec, should we do this with an Undo, a Reject, etc.

eprodrom: we have an activity type called Block which is specifically to implement social media block
... it seems to me what would happen in that situation
... on the sender's server you'd expect to have that kind of mechanism
... on the receiving server things get trickier, it's advisory
... if alice and bob are both on example.com and charlie is on foo.example and charlie blocks bob
... foo.example will still be sending updates to example.com because of alice
... the expected behavior for example.com is that it not show that info to bob, but if it's hostile it could do that

<cwebber2> https://public.etherpad-mozilla.org/p/activitypub-implicit-explit

cwebber2: you've got it exactly
... one of the things we discussed on this call is that there are two separate things covered by Block and they're separate
... some people want to send a Block-type thing across the wire to say "don't send my stuff to this person"
... some people don't want to send something across the network for safety reasons
... we separated out an ignore-style block and retroactively undoing a follow
... we want to separate these cleanly into two different things

<cwebber2> https://github.com/w3c/activitypub/issues/242#issuecomment-315645158

<Loqi> [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit

<Loqi> Someone correct me if I'm wrong but I believe this was the consensus:

<Loqi> 1. sharedInbox is used only for public and followers delivery, ev...

cwebber2: if you look at the issue summary it'd make it so you never have to federate a Block
... the only thing you'd end up federating is the other one (the "don't forward stuff to the follower's inbox" type thing)
... and you could choose whether to do that or not
... does that make sense that there's two separate actions here?

eprodrom: no
... I don't see the point in teasing out two different things when there's already Block
... it's a single activity type and you could just do it
... I don't see what the additional complexity buys you

cwebber2: scenario from Gargron:
... people push the block button and then unclick it
... they call this a "soft-block"
... it stops the soft-blocked person from following them but still allows them to interact with posts
... the scenario here is that you don't want them to see the private messages you're sending out to friends and family, but you don't mind if they interact with your posts

eprodrom: currently sends a block and an undo block right?
... I've been writing social software for 10 years and I don't care about this usecase

cwebber2: the motivator is that currently in our spec for a reason we decided to say don't federate a Block
... we don't want to put people in danger of knowing that they're blocked by somebody
... this is a problem because of the way Mastodon does delivery
... it's an explicit vs implicit problem

eprodrom: my opinion is not only should you federate blocks this is not a good idea
... complicated and messy and I don't get it
... I don't see why you wouldn't federate blocks
... wait

<eprodrom> +0

<ajordan> my audio is totally screwed

<sandro> eprodrom: I don't want to think about this

<ajordan> I'm gonna have to redial

<sandro> eprodrom: you want to make a proposal?

<sandro> cwebber2: not a lot of people on the call

<sandro> eprodrom: I think I understand why you're trying to not federate blocks, but I don't find it motivating

sandro: you implicitly asked my opinion
... my opinion is that Mastodon users are the bulk of decentralized social media
... by 10 to 1
... so we should pay attention to their usecases

eprodrom: that's a compelling argument sir
... cwebber2 what do you want to do here

cwebber2: I'd like to draft up an actual PR to describe how this is done
... I got a sense about how you feel about it which was my main goal here
... I'll just draft up a PR, we'll see how it is after it's drafted
... I'll also need to draft up a PR given the accept/reject convo we had earlier

sandro: I hope you mean pushing something to the editor's draft with a note so people don't have to dig through GitHub

cwebber2: uhhh yeah I could do that

eprodrom: thanks for taking extra time here, let's plan on talking next week
... cwebber2 do you feel like we need a bit of extra time next week?
... I'll circulate 90 minutes

cwebber2: that would be appreciated

eprodrom: I'll do that then

<cwebber2> trackbot, end meeting

- DRAFT -

Social Web Working Group Teleconference

18 Jul 2017

Attendees

Contents

review previous meetings' minutes

August meeting dates

PTD

bridging ActivityPub and IndieWeb stack

CR to PR items

WebSub

JF2

PTD

https://github.com/w3c/activitypub/issues/244

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output