17:03:50 <RRSAgent> RRSAgent has joined #social
17:03:50 <RRSAgent> logging to http://www.w3.org/2017/07/18-social-irc
17:03:52 <trackbot> RRSAgent, make logs public
17:03:52 <Zakim> Zakim has joined #social
17:03:53 <cwebber2> present+
17:03:54 <trackbot> Zakim, this will be SOCL
17:03:54 <Zakim> ok, trackbot
17:03:55 <trackbot> Meeting: Social Web Working Group Teleconference
17:03:55 <trackbot> Date: 18 July 2017
17:03:59 <jaywink> present+
17:03:59 <ben_thatmustbeme> present+
17:03:59 <rhiaro> present+
17:04:07 <eprodro57> present+
17:04:16 <jaywink> (irc only though)
17:04:17 <cwebber2> scribenick: cwebber2
17:04:38 <ajordan> present+
17:04:51 <ajordan> ;)
17:05:06 <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
17:05:48 <cwebber2> topic: review previous meetings' minutes
17:06:08 <cwebber2> 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...
17:06:31 <cwebber2> ajordan: we do have some CG minutes that are missing
17:06:46 <eprodrom> eprodrom has joined #social
17:06:53 <eprodrom> https://www.w3.org/wiki/Socialwg/2017-06-27-minutes
17:07:03 <cwebber2> cwebber2: I think the CG can deal with the CG's missing minutes part
17:07:53 <cwebber2> ben_thatmustbeme: I volunteer to track down the minutes for later
17:08:06 <cwebber2> eprodrom: ok instead of proposing to review the minutes for 6-27 let's review the minutes for 7-11
17:08:38 <eprodrom> PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-07-11-minutes as minutes of the 2017-07-11 meeting
17:08:42 <ajordan> +1
17:08:42 <cwebber2> +1
17:08:44 <eprodrom> +0
17:08:47 <ben_thatmustbeme> +1
17:08:57 <rhiaro> +1
17:09:15 <eprodrom> RESOLVED: Accept https://www.w3.org/wiki/Socialwg/2017-07-11-minutes as minutes of the 2017-07-11 meeting
17:09:34 <rhiaro> I'll chase down those
17:09:38 <cwebber2> eprodrom: so we have to shake down the 6-27 minutes and I guess we'll have to do that
17:09:41 <rhiaro> I thin kthat was a sandro scribing week
17:09:45 <cwebber2> eprodrom: one thing about minutes we can see who did what
17:09:48 <ben_thatmustbeme> its clearly the 6/28 minutes there
17:09:52 <ben_thatmustbeme> from the CG
17:09:53 <cwebber2> eprodrom: do we have the raw minutes?
17:10:00 <rhiaro> Give me 5 mins I'll find it
17:10:17 <cwebber2> eprodrom: I'd like to move forward
17:10:18 <ajordan> rhiaro++
17:10:26 <cwebber2> eprodrom: let's talk about the next item which is august dates
17:10:27 <eprodrom> TOPIC: August meeting dates
17:10:42 <rhiaro> Last week everyone voted, and we have results, but for a couple pending Evan's opinion
17:10:44 <rhiaro> :)
17:10:56 <cwebber2> eprodrom: in august we have 5 tuesdays, we talked about doing every other week?
17:10:58 <cwebber2> q+
17:11:09 <eprodrom> ack cwebber
17:11:20 <rhiaro> <sandro> CANCELING July 18, ug 8, Aug 22
17:11:20 <rhiaro> <tantek> for sure: 7/25, 8/15, 8/29. 8/1 contingent on Evan chairing
17:11:53 <cwebber2> cwebber: I propose we do meetings every week because we seem to wanting to cut down meetings and are not able to
17:11:55 <ben_thatmustbeme> -1 as i feel like most of the meetings are things that should be done async anyway
17:12:10 <cwebber2> eprodrom: it's just at tough time to have frequent meetings, but
17:12:22 <Loqi> Loqi has joined #social
17:12:58 <eprodrom> PROPOSAL: cancel meetings for 8/9 and 8/22
17:13:10 <eprodrom> PROPOSAL: cancel meetings for 8/8 and 8/22
17:13:15 <rhiaro> +1 and +1 from sandro in absentia
17:13:17 <ben_thatmustbeme> +1
17:13:25 <cwebber2> cwebber2: -0 but i won't fight it
17:13:29 <eprodrom> +1
17:13:52 <ajordan> +0
17:14:10 <eprodrom> RESOLVED: cancel meetings for 8/8 and 8/22
17:14:46 <eprodrom> TOPIC: PTD
17:15:10 <cwebber2> eprodrom: tantek is not here yet, so I'd like to push PTD to the end of the agenda
17:15:19 <cwebber2> eprodrom: let's talk about bridging
17:15:22 <rhiaro> https://www.w3.org/wiki/Socialwg/2017-06-27-minutes minutes are corrected
17:15:30 <eprodrom> TOPIC: bridging ActivityPub and IndieWeb stack
17:15:36 <cwebber2> ajordan: I guess that's me
17:15:51 <ajordan> https://indieweb.org/bridge#ActivityPub
17:16:12 <cwebber2> 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
17:16:38 <cwebber2> ajordan: 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
17:16:53 <cwebber2> ajordan: the tricky thing is mentions, there are two parts of this; AP->IW sites, and IW->AP
17:17:21 <cwebber2> ajordan: so AP->IW, my theory is that IW sites should be able to put a static paage on the root of the site
17:17:39 <cwebber2> ajordan: so any time an AP site mentions the actor at that site
17:17:53 <cwebber2> ajordan: all mutation and stuff will resolve to a bridge service that will construct things on the fly
17:17:57 <cwebber2> ajordan: that sort of makes sense
17:18:41 <cwebber2> 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
17:19:17 <cwebber2> eprodrom: 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
17:19:20 <cwebber2> eprodrom: so yeah
17:19:22 <cwebber2> ajordan: exactly
17:19:32 <cwebber2> ajordan: this does require the IW site to put the JSON file at the root
17:19:53 <cwebber2> ajordan: I should make it clear we put this at the root and then set the server to ?
17:20:00 <ben_thatmustbeme> JSON file at the root, would be a problem for some
17:20:21 <cwebber2> 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
17:20:27 <cwebber2> ajordan: so that's a worse UX but it should work
17:20:32 <cwebber2> ajordan: even if the IW site hasn't opted in
17:20:58 <cwebber2> 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
17:21:20 <cwebber2> eprodrom: if my site returns html you can do antoher discovery method
17:21:28 <cwebber2> eprodrom: you should be able to get the json descriptor currently in AP
17:21:49 <cwebber2> eprodrom: so could we expand AP to say in the erroneous situation where they return HTML instead of JSON, this is what you will do
17:21:55 <cwebber2> ajordan: what would you do in that case
17:22:05 <cwebber2> <cwebber2> jaywink, I agree
17:22:15 <cwebber2> eprodrom: so link rel=inbox, href=url of bridge, etc
17:22:19 <eprodrom> <link rel="inbox" href="URL of bridge">
17:22:34 <ben_thatmustbeme> q+
17:22:51 <ben_thatmustbeme> q-
17:22:53 <cwebber2> ajordan: if you're already going to do this if you're already adding this?
17:22:56 <ben_thatmustbeme> evan covered it
17:23:04 <cwebber2> eprodrom: if you're adding something with just html but can't do content negotiation
17:23:10 <cwebber2> eprodrom: there's a big jump between them, I think
17:23:22 <cwebber2> ajordan: I can file an issue about this
17:23:59 <ben_thatmustbeme> q+
17:24:14 <rhiaro> q+ (irc only)
17:24:24 <cwebber2> cwebber2: I think it would be nice, but it could be a MAY, it's already a lot of work
17:24:26 <rhiaro> q- (irc only)
17:24:28 <cwebber2> eprodrom: it could be an extension
17:24:42 <rhiaro> q+ to say (typing on irc only)
17:24:45 <cwebber2> eprodrom: also you could do rdfa or something similar
17:24:55 <cwebber2> eprodrom: you could grab out the AS2 data
17:25:06 <cwebber2> eprodrom: probably not the most exciting thing for MF2 folks, but a possibility
17:25:09 <tantek> present+
17:25:10 <rhiaro> the link rel would parse as rdfa
17:25:17 <rhiaro> LDN already got that covered
17:25:23 <cwebber2> ajordan: seems like we're agreeing it's either a MAY or an extension
17:25:26 <tantek> wait why are we talking about theoreticals? ("or even"?)
17:25:29 <eprodrom> q?
17:25:36 <eprodrom> ack ben_thatmustbeme
17:25:51 <cwebber2> ben_thatmustbeme: if you implement it as a MAY, doesn't it break federation?
17:26:06 <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
17:26:10 <cwebber2> 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
17:26:30 <tantek> rather than trying to be politically correct (or we can be politically correct in informative Notes)
17:26:33 <eprodrom> q?
17:26:54 <cwebber2> ben_thatmustbeme: I don't think this is specific to bridging
17:26:55 <cwebber2> q+
17:27:05 <cwebber2> ben_thatmustbeme: if you're going to support it it should be required
17:27:06 <rhiaro> 1) This bridging stuff can go in SWP if we settle it, not needed in AP
17:27:06 <rhiaro> 2) Can we timebox this discussion and end it imminently because there's lots of AP stuff to go through?
17:27:07 <eprodrom> ack rhiaro
17:27:07 <Zakim> rhiaro, you wanted to say (typing on irc only)
17:27:11 <rhiaro> ^^^^
17:27:29 <rhiaro> No
17:27:43 <tantek> I think it can be in SWP if it's figured out, the point of the discussion is spec impacts
17:27:51 <tantek> it's not figured out AFAIK
17:27:53 <tantek> q+
17:27:57 <eprodrom> q?
17:28:01 <eprodrom> ack cwebber2
17:28:05 <eprodrom> ack cwebber
17:28:46 <eprodrom> ack tantek
17:28:52 <eprodrom> q?
17:29:04 <cwebber2> cwebber2: I think this shouldn't be rdfa, it could be embedded as json-ld as is done in schema.org things etc
17:29:14 <cwebber2> tantek: +1 on not doing rdfa, we shouldn't do normative text that's not deployed
17:29:27 <cwebber2> tantek: I agree with moving to SWP when it's figured out
17:29:54 <cwebber2> tantek: that's what I'm interested in, if it requires spec changes then it needs to be figured out asap
17:30:02 <eprodrom> call dropped
17:30:02 <Loqi> Rhiaro made 1 edit to [[Socialwg/2017-06-27-minutes]] https://www.w3.org/wiki/index.php?diff=103817&oldid=103706
17:30:06 <tantek> bridging++
17:30:06 <Loqi> bridging has 1 karma
17:30:17 <tantek> q?
17:30:27 <cwebber2> eprodrom, you dropped out, tantek is temporarily saying we're moving on
17:30:30 <eprodrom> Let's move on to the next topic
17:30:39 <cwebber2> TOPIC: CR to PR items
17:30:40 <eprodrom> cwebber2: yep
17:30:52 <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
17:31:13 <cwebber2> https://github.com/w3c/activitypub/issues/242#issuecomment-315645158
17:31:13 <Loqi> [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit
17:31:13 <Loqi> Someone correct me if I'm wrong but I believe this was the consensus:
17:31:13 <Loqi> 1. sharedInbox is used only for public and followers delivery, ev...
17:31:24 <ben_thatmustbeme> scribenick:ben_thatmustbeme
17:31:59 <ben_thatmustbeme> cwebber2: we are basically seeing DB / storage issues bleed in to spec
17:32:20 <ben_thatmustbeme> ... we have a public inbox vs private inboxes
17:32:39 <ben_thatmustbeme> to allow for delivery to large sets of users
17:32:51 <ben_thatmustbeme> s/private/shared/
17:33:26 <jaywink> :D
17:34:13 <ben_thatmustbeme> cwebber2: i would like  to rename to shared inbox
17:34:42 <tantek> q?
17:34:42 <ben_thatmustbeme> (request coming)
17:34:45 <cwebber2> PROPOSAL: Rename publicInbox to sharedInbox and allow it to both post public posts and posts to followers
17:34:49 <tantek> ajordan: which summary in github?
17:35:00 <ajordan> tantek: https://github.com/w3c/activitypub/issues/242#issuecomment-315645158
17:35:01 <Loqi> [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit
17:35:01 <Loqi> Someone correct me if I'm wrong but I believe this was the consensus:
17:35:01 <Loqi> 1. sharedInbox is used only for public and followers delivery, ev...
17:35:02 <cwebber2> https://github.com/w3c/activitypub/issues/242#issuecomment-315645158
17:35:02 <Loqi> [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit
17:35:03 <Loqi> Someone correct me if I'm wrong but I believe this was the consensus:
17:35:03 <Loqi> 1. sharedInbox is used only for public and followers delivery, ev...
17:35:14 <ben_thatmustbeme> 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
17:35:39 <ben_thatmustbeme> sandro: the implicit action that creates, is that also true on this
17:35:47 <ben_thatmustbeme> cwebber2: thats only on client to server
17:35:52 <ben_thatmustbeme> sandro: no problem then
17:35:55 <cwebber2> PROPOSAL: Rename publicInbox to sharedInbox and allow it to both post public posts and posts to followers
17:36:03 <ajordan> +1
17:36:06 <cwebber2> +1
17:36:08 <jaywink> +1
17:36:41 <aaronpk> this is a breaking change to all implementations, right?
17:37:01 <rhiaro> all implementatins that implemented publicInbox which I don't think is required..? (correct me..)
17:37:04 <ajordan> aaronpk: not technically
17:37:17 <ajordan> we're changing semantics but we're also changing the name, and the existing publicInbox is a MAY
17:37:47 <ben_thatmustbeme> tantek: where is the actual change to the spec here
17:38:13 <ben_thatmustbeme> cwebber2: this is allowing for if you are posting to all of your (millions of) followers but not posting publicly
17:38:32 <tantek> is this implementable? prototyped?
17:38:39 <ben_thatmustbeme> cwebber2: the receiving server will see that this is to their followers collection and it knows who the followers are on your server
17:38:52 <ben_thatmustbeme> cwebber2: you can already do that, but you currently also have to post it publicly
17:38:52 <ajordan> tantek: I'm not sure about implementations but Mastodon has made it clear that they need this
17:38:55 <ajordan> and are planning to do it
17:39:25 <ben_thatmustbeme> tantek: i'm a little concerned that we are making changes to a CR that no one has implemententd
17:39:46 <ben_thatmustbeme> cwebber2: mastodon is already implmenting it, and puckipedia is implementing it
17:40:17 <ben_thatmustbeme> tantek: thats a good thing to capture in an issue, not to make it a change in the CR
17:40:34 <jaywink> before it was all just theory
17:41:02 <ben_thatmustbeme> tantek: you think this is a change to existing functionality, not adding?
17:41:11 <ajordan> q+
17:41:17 <eprodrom> q?
17:41:22 <ben_thatmustbeme> cwebber2: it is a slight add of being able to not post publicly
17:41:23 <tantek> ack ajordan
17:41:29 <ben_thatmustbeme> cwebber2: it is breaking
17:41:30 <eprodrom> tantek: I'm back, can chair from here
17:41:43 <ben_thatmustbeme> ajordan: afaict its not breaking
17:41:55 <ben_thatmustbeme> ... it was a may before and its a may now
17:42:28 <ben_thatmustbeme> ... 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)
17:42:55 <ben_thatmustbeme> ... we both shared the same concerns as you (tantek) had, but its really just refining this feature
17:43:11 <ben_thatmustbeme> tantek: i am not questioning the Why at all, i am just trying to make sure we do the right thing for our CR
17:43:27 <ben_thatmustbeme> sandro: your concern is that we are making this change but we are going to have to change it back
17:43:43 <ben_thatmustbeme> tantek: i think we may need to change it again
17:44:03 <ben_thatmustbeme> ... in order to minimize issues, its better to implement it before it goes in to the CR
17:44:09 <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.
17:44:26 <rhiaro> tantek cwebber2 ^^?
17:45:15 <ben_thatmustbeme> tantek: you can land the text in the ED of how this will work
17:45:38 <ben_thatmustbeme> ... but before it lands in CR, it should have prototypes
17:45:56 <ajordan> rhiaro: by "make this change" do you mean the WD or the published CR?
17:46:08 <eprodrom> PROPOSED: for https://github.com/w3c/activitypub/issues/242 rename publicInbox to sharedInbox and allow sending to followers only
17:46:17 <rhiaro> ajordan: CR
17:46:22 <ajordan> right
17:46:23 <ajordan> +1
17:46:49 <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
17:46:53 <cwebber2> +1
17:46:54 <ajordan> +1
17:46:58 <jaywink> +1
17:47:05 <ben_thatmustbeme> tantek: in general thats a good bar for AP changes at this point
17:47:06 <eprodrom> +1
17:47:07 <ben_thatmustbeme> +1
17:47:16 <cwebber2> sandro: +1
17:47:50 <jaywink> but it can still land in the editors draft to not confuse current wip version?
17:47:53 <eprodrom> tantek: thank you
17:48:00 <ben_thatmustbeme> eprodrom:  is it okay if we defer 244?
17:48:01 <ajordan> tantek++
17:48:03 <Loqi> tantek has 66 karma in this channel (370 overall)
17:48:04 <Loqi> [cwebber] #242 sharedInbox / siteInbox type endpoint (publicInbox, but not just for public posts)
17:48:04 <Loqi> [cwebber] #242 sharedInbox / siteInbox type endpoint (publicInbox, but not just for public posts)
17:48:19 <rhiaro> I can't stay
17:48:21 <ben_thatmustbeme> <ben_thatmustbeme> i cannot stay late on audio
17:49:03 <eprodrom> TOPIC: WebSub
17:49:10 <cwebber2> scribenick: cwebber2
17:49:26 <cwebber2> aaronpk: I think the only topic is the one in the notes
17:49:28 <ben_thatmustbeme> rejoining
17:50:18 <eprodrom> https://git.postactiv.com/postActiv/postActiv/issues/139#note_1690
17:50:21 <cwebber2> aaronpk: the person does not want to submit an implementation report because they're unhappy with EME
17:50:43 <cwebber2> sandro: I think there's not a lot we can do about it and we should move on
17:51:05 <ben_thatmustbeme> q+
17:51:56 <eprodrom> ack ben_thatmustbeme
17:52:47 <cwebber2> 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
17:53:15 <cwebber2> sandro: I think it would be nice to have impl reports that speak to just that it's compatible with classic PuSH
17:53:20 <cwebber2> sandro: for me that's valuable
17:53:22 <cwebber2> tantek: good point
17:53:29 <cwebber2> eprodrom: that sounds reasonable
17:53:33 <tantek> sandro++ for seeing the positive. thank you
17:53:34 <Loqi> sandro has 47 karma in this channel (54 overall)
17:53:35 <rhiaro> Adding for the minutes that sandro said he will report the EME thing to Team and tantek will report to AB
17:53:41 <cwebber2> eprodrom: do we have ways in impl report template for 3rd party supporters?
17:53:57 <cwebber2> aaronpk: there's nothing in the template right now but I know there's a line with author / etc
17:54:08 <cwebber2> aaronpk: nothing else for websub
17:54:14 <ben_thatmustbeme> http://dissolve.github.io/jf2/#changes-from-27-june-2017-wd-to-this-version
17:54:14 <cwebber2> TOPIC: JF2
17:54:35 <cwebber2> ben_thatmustbeme: looking for more info for impl reports
17:55:28 <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
17:55:31 <ajordan> +1
17:55:35 <cwebber2> +1
17:55:35 <cwebber2> 
17:55:42 <eprodrom> +1
17:55:53 <aaronpk> +1
17:56:16 <cwebber2> tantek: I'm saying validator impl reports linking to jf2.rocks, is that right?
17:56:21 <cwebber2> ben_thatmustbeme: that's the landing page for now that links them all
17:56:24 <cwebber2> tantek: ok just checking
17:56:28 <tantek> +1
17:56:40 <tantek> s/saying/seeing
17:56:50 <eprodrom> RESOLVED: 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
17:56:54 <tantek> s/validator impl reports/validator, sample set, implementation reports
17:57:33 <cwebber2> tantek: 30 sec update, I'm successfully using JF2 to do social embedding on my site
17:57:36 <cwebber2> tantek: just as an FYI
17:57:46 <cwebber2> tantek: it's working very well as a transport format
17:57:53 <cwebber2> tantek: that's how I'm showing rsvp's on my site
17:58:07 <eprodrom> TOPIC: PTD
17:58:58 <Loqi> [tantek] #25 Response Type: consider "reply" for 2nd to last for fallback use-cases
18:02:27 <ajordan> q+
18:02:32 <eprodrom> ack ajordan
18:03:42 <ajordan> scribenick: ajordan
18:03:49 <ajordan> cwebber2: this one's big but it's short
18:03:58 <eprodrom> TOPIC: https://github.com/w3c/activitypub/issues/244
18:03:58 <Loqi> [cwebber] #244 Accept / Reject a Follow
18:03:59 <ajordan> ... people want to be able to accept and reject followers
18:04:03 <sandro> present+
18:04:08 <ajordan> ... we propose that everyone always sends an accept/reject
18:04:18 <ajordan> ... for people that always want to accept, you just automatically send an accept back
18:04:29 <ajordan> ... this makes it mandatory that you always send an accept/reject to a follow request
18:04:44 <ajordan> eprodrom: what happens to existing impls that don't send an accept or reject
18:04:49 <ajordan> ... can you say they're default accepted?
18:04:57 <ajordan> cwebber2: so this is why we need to make it mandatory...
18:05:14 <ajordan> ... so if you don't hear back you'd know
18:05:15 <ajordan> ... you could possibly check the followers list
18:05:24 <ajordan> sandro: it could take a couple weeks right?
18:05:35 <ajordan> cwebber2: if you don't hear back you'd see a "waiting" type interface
18:05:42 <ajordan> ... I agree that this is a big backwards-breaking change
18:05:52 <ajordan> eprodrom: three states: waiting, accepted, rejected
18:06:06 <ben_thatmustbeme> this sounds like a mix of network stack levels
18:06:06 <ajordan> ... what if I get an update from someone I'm waiting on
18:06:17 <ajordan> ... what if I've been rejected and I receive something
18:06:29 <ajordan> cwebber2: this is tricky because I can add you to my friends list but not my followers list
18:06:32 <ben_thatmustbeme> are we talking about an ACK as i receieved the request?
18:06:34 <ajordan> ... diaspora-style aspects
18:06:53 <ajordan> eprodrom: maybe if you reject a follower just don't send them anything
18:07:08 <ajordan> ... you've got a lot of cases here and I'm not sure what that complexity buys us
18:07:14 <ajordan> sandro: it buys you a good UI
18:07:31 <ajordan> ... I clicked mastodon's follow button and I was frustrated because it didn't provide any feedback
18:07:41 <ajordan> ... but it was really in the waiting state
18:08:00 <ajordan> cwebber2: there's another reason that we need this in a sense
18:08:01 <aaronpk> present+
18:08:04 <ajordan> ... other social networks provide this
18:08:08 <ajordan> ... Facebook provides this
18:08:09 <eprodrom> https://www.w3.org/TR/activitystreams-vocabulary/#connections
18:08:14 <ajordan> ... I think it's necessary
18:08:23 <ajordan> ???: the whole relationship schema is for that
18:08:32 <Loqi> Loqi has joined #social
18:08:35 <ajordan> ... follows/unfollows are for this
18:09:08 <eprodrom> https://www.w3.org/TR/activitystreams-vocabulary/#connections
18:09:27 <ajordan> s/???eprodrom/
18:09:32 <ajordan> cwebber2: that could work...
18:09:43 <ajordan> ... I didn't realize this was in the spec, this seems kind of reasonable
18:09:54 <ajordan> ... I'd move towards figuring out how to do this in the spec
18:10:03 <ajordan> ... it'd be a normative change but wouldn't break backwards compat
18:10:11 <ajordan> ... it'll take time; I'll work on this
18:10:17 <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"
18:10:24 <ajordan> eprodrom: it lets you have a regular following mechanism like other social networks have
18:10:29 <ajordan> ... without all the acks and nacks and stuff
18:10:36 <ajordan> cwebber2: 5 minutes late, I want to get to the one other related thing
18:10:48 <ajordan> ... big debate in e.g. Mastodon/AP as to whether you federate a Block
18:11:02 <ajordan> ... Mastodon *has* to federate a Block because they don't explicitly ???
18:11:12 <ajordan> ... we had a conversation and realized we were kind of overloading Block
18:11:26 <ajordan> ... there's disallowing side effects, and there's basically a "request to unfollow"
18:11:33 <eprodrom> https://www.w3.org/TR/activitystreams-vocabulary/#dfn-block
18:11:38 <cwebber2> https://github.com/w3c/activitypub/issues/242#issuecomment-315645158
18:11:41 <ajordan> ... "I don't want to deliver to you anymore"
18:11:43 <Loqi> [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit
18:11:47 <Loqi> Someone correct me if I'm wrong but I believe this was the consensus:
18:11:51 <Loqi> 1. sharedInbox is used only for public and followers delivery, ev...
18:12:00 <ajordan> ... I want to get a sense as to what people, especially eprodrom, think about this
18:12:17 <ajordan> ... is this reasonable to put in the spec, should we do this with an Undo, a Reject, etc.
18:12:29 <ajordan> eprodrom: we have an activity type called Block which is specifically to implement social media block
18:12:41 <ajordan> ... it seems to me what would happen in that situation
18:12:48 <ajordan> ... on the sender's server you'd expect to have that kind of mechanism
18:12:56 <ajordan> ... on the receiving server things get trickier, it's advisory
18:13:09 <ajordan> ... if alice and bob are both on example.com and charlie is on foo.example and charlie blocks bob
18:13:22 <ajordan> ... foo.example will still be sending updates to example.com because of alice
18:13:36 <ajordan> ... the expected behavior for example.com is that it not show that info to bob, but if it's hostile it could do that
18:13:38 <cwebber2> https://public.etherpad-mozilla.org/p/activitypub-implicit-explit
18:13:42 <ajordan> cwebber2: you've got it exactly
18:13:59 <ajordan> ... one of the things we discussed on this call is that there are two separate things covered by Block and they're separate
18:14:19 <ajordan> ... some people want to send a Block-type thing across the wire to say "don't send my stuff to this person"
18:14:29 <ajordan> ... some people don't want to send something across the network for safety reasons
18:14:46 <ajordan> ... we separated out an ignore-style block and retroactively undoing a follow
18:14:56 <ajordan> ... we want to separate these cleanly into two different things
18:15:06 <cwebber2> https://github.com/w3c/activitypub/issues/242#issuecomment-315645158
18:15:07 <Loqi> [strugee] Link to the Etherpad from the Mumble call: https://public.etherpad-mozilla.org/p/activitypub-implicit-explit
18:15:07 <Loqi> Someone correct me if I'm wrong but I believe this was the consensus:
18:15:07 <Loqi> 1. sharedInbox is used only for public and followers delivery, ev...
18:15:10 <ajordan> ... if you look at the issue summary it'd make it so you never have to federate a Block
18:15:30 <ajordan> ... the only thing you'd end up federating is the other one (the "don't forward stuff to the follower's inbox" type thing)
18:15:37 <ajordan> ... and you could choose whether to do that or not
18:15:44 <ajordan> ... does that make sense that there's two separate actions here?
18:15:46 <ajordan> eprodrom: no
18:15:57 <ajordan> ... I don't see the point in teasing out two different things when there's already Block
18:16:12 <ajordan> eprodrom: it's a single activity type and you could just do it
18:16:18 <ajordan> ... I don't see what the additional complexity buys you
18:16:25 <ajordan> cwebber2: scenario from Gargron:
18:16:34 <ajordan> ... people push the block button and then unclick it
18:16:40 <ajordan> ... they call this a "soft-block"
18:17:00 <ajordan> ... it stops the soft-blocked person from following them but still allows them to interact with posts
18:17:30 <ajordan> ... 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
18:17:40 <ajordan> eprodrom: currently sends a block and an undo block right?
18:17:51 <ajordan> ... I've been writing social software for 10 years and I don't care about this usecase
18:18:15 <ajordan> cwebber2: the motivator is that currently in our spec for a reason we decided to say don't federate a Block
18:18:32 <ajordan> ... we don't want to put people in danger of knowing that they're blocked by somebody
18:18:46 <ajordan> ... this is a problem because of the way Mastodon does delivery
18:18:52 <ajordan> ... it's an explicit vs implicit problem
18:19:02 <ajordan> eprodrom: my opinion is not only should you federate blocks this is not a good idea
18:19:07 <ajordan> ... complicated and messy and I don't get it
18:19:15 <ajordan> ... I don't see why you wouldn't federate blocks
18:19:24 <ajordan> eprodrom: wait
18:19:35 <eprodrom> +0
18:19:38 <ajordan> <ajordan> my audio is totally screwed
18:19:52 <sandro> eprodrom: I don't want to think about this
18:20:05 <ajordan> <ajordan> I'm gonna have to redial
18:20:21 <sandro> eprodrom: you want to make a proposal?
18:20:39 <sandro> cwebber2: not a lot of people on the call
18:21:24 <sandro> eprodrom: I think I understand why you're trying to not federate blocks, but I don't find it motivating
18:21:28 <ajordan> q+
18:21:33 <eprodrom> ack ajordan
18:22:21 <ajordan> sandro: you implicitly asked my opinion
18:22:31 <ajordan> ... my opinion is that Mastodon users are the bulk of decentralized social media
18:22:35 <ajordan> ... by 10 to 1
18:22:40 <ajordan> ... so we should pay attention to their usecases
18:22:47 <ajordan> eprodrom: that's a compelling argument sir
18:22:55 <ajordan> eprodrom: cwebber2 what do you want to do here
18:23:03 <ajordan> cwebber2: I'd like to draft up an actual PR to describe how this is done
18:23:11 <ajordan> ... I got a sense about how you feel about it which was my main goal here
18:23:23 <ajordan> ... I'll just draft up a PR, we'll see how it is after it's drafted
18:23:50 <ajordan> ... I'll also need to draft up a PR given the accept/reject convo we had earlier
18:24:03 <ajordan> sandro: I hope you mean pushing something to the editor's draft with a note so people don't have to dig through GitHub
18:24:07 <ajordan> cwebber2: uhhh yeah I could do that
18:24:20 <ajordan> eprodrom: thanks for taking extra time here, let's plan on talking next week
18:24:31 <ajordan> ... cwebber2 do you feel like we need a bit of extra time next week?
18:24:35 <ajordan> ... I'll circulate 90 minutes
18:24:44 <ajordan> cwebber2: that would be appreciated
18:24:48 <ajordan> eprodrom: I'll do that then
18:25:29 <cwebber2> trackbot, end meeting
18:25:29 <trackbot> Zakim, list attendees
18:25:29 <Zakim> As of this point the attendees have been cwebber, jaywink, ben_thatmustbeme, rhiaro, eprodro, ajordan, tantek, sandro, aaronpk
18:25:37 <trackbot> RRSAgent, please draft minutes
18:25:37 <RRSAgent> I have made the request to generate http://www.w3.org/2017/07/18-social-minutes.html trackbot
18:25:38 <trackbot> RRSAgent, bye
18:25:38 <RRSAgent> I see no action items