16:59:18 <RRSAgent> RRSAgent has joined #social
16:59:18 <RRSAgent> logging to http://www.w3.org/2016/08/16-social-irc
16:59:20 <trackbot> RRSAgent, make logs public
16:59:20 <Zakim> Zakim has joined #social
16:59:22 <trackbot> Zakim, this will be SOCL
16:59:22 <Zakim> ok, trackbot
16:59:23 <trackbot> Meeting: Social Web Working Group Teleconference
16:59:23 <trackbot> Date: 16 August 2016
17:01:11 <cwebber2> hello!
17:01:14 <rhiaro> TOPIC: Activitypub and notifications
17:01:18 <cwebber2> irc-only meeting today
17:01:41 <rhiaro> So this morning cwebber2 and I refactored AP Notifications and Delivery to Targeting and Delivery, with the LDN reference: http://rhiaro.github.io/activitypub/#targeting-and-delivery
17:01:53 <rhiaro> feedback from the likes of tsyesika and csarven would be welcome :)
17:02:00 <csarven> Sorry for that. My situation is reliable for audio. I can listen but may not respond that well. So, IRC is most suitable.
17:02:13 <cwebber2> csarven: we were preferring irc only today also :)
17:02:17 <csarven> rhiaro Should I respond to that now or wait?
17:02:28 <rhiaro> as convenient, if you can read it now
17:02:33 <csarven> i.e., read and respond.. or read later and you summarise now
17:02:38 <cwebber2> tsyesika, no need to connect
17:02:40 <cwebber2> we are doing irc only
17:02:42 <tsyesika> oh okaaay
17:02:43 <tsyesika> oh sorry
17:02:53 <cwebber2> np :)
17:03:07 <csarven> Probably bes tthat you summarise since this is AP specific
17:03:07 <rhiaro> I think you know the summary csarven, we've discussed in the past, so this is the materialisation of the general idea of pointing to LDN from AP, and clarifying some of the AP notifications stuff
17:03:16 <rhiaro> it's not a long section
17:03:23 <cwebber2> this also means that ASub will remain in APub :)
17:03:29 <cwebber2> so as to not spread over too many documents
17:03:37 <cwebber2> instead, we'll separate activitypub into client to server and server to server
17:03:43 <cwebber2> with the server to server relying on LDN
17:04:04 <rhiaro> But server to server additionally specifies targeting (ie. deciding who to send to which isn't in LDN)
17:04:06 <cwebber2> but it'll be in same document
17:04:06 <rhiaro> and side effects
17:04:10 <cwebber2> yes
17:04:11 <rhiaro> and the actual subscription request part
17:04:19 <tsyesika> i like that we're now pointing at LDN :)
17:04:21 <rhiaro> which is essentially a side effect
17:04:23 <cwebber2> so AP does need its own stuff
17:04:29 <cwebber2> but can *rely on* LDN for the bulk of it.
17:04:35 <csarven> Okie
17:05:00 <csarven> Sounds good
17:05:07 <csarven> 3.7.2 being clear
17:05:21 <csarven> i.e., 3.7.1 and 3.7.2 being distinct
17:05:37 <annbass> annbass has joined #social
17:07:02 <cwebber2> tsyesika: do you have thoughts?
17:07:07 <cwebber2> or is basically this all good to you?
17:07:16 <cwebber2> esp since you're co-editor on AP :)
17:08:10 <tsyesika> indeed, i'm actually reaaally happy to see this, the LDN document which i read back when rhiaro first brought it up seemed like a good more general version of wht we're doing in AP
17:08:19 <cwebber2> tsyesika: yay
17:08:24 <rhiaro> :D
17:08:27 <cwebber2> tsyesika: I'm also feeling good about it
17:08:42 <cwebber2> I was dreading the APub / ASub refactor
17:08:46 <tsyesika> glad we're now linking in the relevant parts, it reads well. I should go re-read LDN but i liked my first read of it
17:08:57 <cwebber2> this will allow us to clearly distinguish between pub and sub parts but without me feeling like I will run out of time
17:09:08 <cwebber2> and will allow us to have the generalized federation as part of another document
17:09:14 <cwebber2> while keeping our own specific things (esp side effects)
17:09:21 <rhiaro> I'm hopeful that AP Delivery being a specific version of LDN will also help AP systems to at minimum exchange notifications with broader LDP-based systems
17:09:29 <cwebber2> rhiaro: yes that would be good
17:09:33 <tsyesika> i'm also glad we're sticking with one spec, two would have been fine but my preference is on one, i think it will make things easier to manage both for us and also be easier to understand for the reader it not being split into a bunch of documents
17:09:39 <csarven> Extra ++ if AP is comfortable with these based on technical clarification and dedicating resources
17:10:06 <cwebber2> csarven, not totally clear on what that means but I think yes? :)
17:10:09 <annbass> sounds like you guys are converging on a good plan!
17:10:15 <cwebber2> annbass, :)
17:10:38 <csarven> cwebber2 If you are happy, we're all happy =)
17:10:56 <cwebber2> tsyesika, ah yes one thing we need to discuss that happened on the last call
17:11:36 <cwebber2> tsyesika, so we had discussed switching from primarily the application/activity+json to the more general json-ld version with a profile
17:11:44 <cwebber2> though I am blanking on the other one right now  :)
17:11:58 <cwebber2> as the mimetype
17:12:07 <cwebber2> it's possible to specify json-ld with a profile
17:12:20 <cwebber2> and then that makes it clear with AP, but adds no extra work for LDP type folks
17:12:24 <cwebber2> since they can already understand that
17:12:29 <rhiaro> application/ld+json; profile=http://www.w3.org/ns/activitystreams#
17:12:37 <rhiaro> except it might need to be /activitypub#
17:12:42 <cwebber2> and since nobody is using application/activity+json yet, it's not like we have to get old implementations to fix it
17:12:49 <cwebber2> tsyesika, how do you feel about this
17:13:00 <cwebber2> it would simplify interop dramatically and wouldn't really lose anything IMO
17:13:45 <tsyesika> yep, all for it, seems like no work for us for better interop
17:14:07 <csarven> cwebber2 If it matters, the LD folks are strongly in favour of the profile approach. From the LDN's perspective, we wanted ot at least acknowledge the (dis)advantages to AS2's new mime type. It is part of the reason we thought that SWP may be best place to address that. However, if AP goes ahead with the profile approach, that'd probably be better for implementations since there is only one treatment of the content-type.
17:14:23 <cwebber2> csarven, ACK
17:14:55 <csarven> s/LD folks/LD community 'in general' - and not exclusive LD folks from SWWG
17:15:17 <cwebber2> csarven, yes, I followed the tumultuous github threads ;)
17:15:30 <cwebber2> csarven, anyway, yes it's no extra work for us
17:15:31 <cwebber2> so all is well
17:17:10 <rhiaro> For process sake:
17:17:21 <rhiaro> PROPOSAL: Keep AP and ASub as one document, with reference to LDN in ASub
17:17:22 <melvster> melvster has joined #social
17:17:25 <rhiaro> +1
17:17:26 <cwebber2> +1
17:17:31 <csarven> +1
17:17:39 <tsyesika> +1
17:17:52 <cwebber2> consensus!
17:17:53 <melvster> +1
17:17:59 <rhiaro> RESOLVED: Keep AP and ASub as one document, with reference to LDN in ASub
17:17:59 <cwebber2> haha :D
17:18:05 <Loqi> nice
17:20:19 <cwebber2> so, I'm going to go through https://github.com/w3c-social/activitypub/pull/75 and merge it
17:20:27 <cwebber2> is there anything else to discuss?
17:20:49 <cwebber2> I guess one more thing that needs to be done then is to separate the pub and sub sections in AP
17:20:50 <csarven> cwebber2 ARe you okay to alias inbox to whatever LDN ends up using for ns?
17:20:57 <cwebber2> csarven: yes
17:21:06 <csarven> Great
17:21:34 <cwebber2> csarven, though I think if it *is* possible to get both LDN inbox and rest of AP terms to be added to AS namespace
17:21:34 <cwebber2> that would be ideal
17:21:52 <cwebber2> but I guess that will require policy changes or somethin :)
17:22:04 <rhiaro> cwebbe2: working on it..
17:23:16 <cwebber2> though, whatever
17:23:22 <cwebber2> we can do aliases to anything in the context ;)
17:23:40 <cwebber2> we'll alias to a wiki page.  Living namespaces!
17:24:34 <rhiaro> yeah so LDN can talk about ldp:inbox, but if AP implementers use as:inbox and that is aliased to ldp:inbox in the json-ld context, it all works out the same in the end
17:24:46 <rhiaro> So AP implementers don't have to care about ldp:inbox and ldp implementers don't have to care about as:inbox
17:24:50 <rhiaro> but they accidentally interop anyway
17:24:53 <rhiaro> ... I think.
17:25:05 <cwebber2> csarven, rhiaro, so a question about profiles
17:25:14 <cwebber2> one nice thing about the mimetype is that you could then infer a json-ld context
17:25:29 <cwebber2> of the AS2 mimetype that we are no longer using
17:26:06 <cwebber2> is something like that possible with profiles?  I'm guessing not?
17:26:17 <cwebber2> I guess we could just set it with profiles
17:26:27 <cwebber2> but what would happen to LDP things that were ignorant of that
17:26:55 <rhiaro> So the scenario is: an AP sender sends a notification without an @context, but with the profile, to an LDP receiver
17:27:00 <rhiaro> Does the LDP receiver handle it correctly?
17:28:03 <rhiaro> Or more generally: if you have a JSON blob without an @context, but with a profile in the media type, can you use that profile as the @context?
17:28:14 <csarven> If no context, I suspect that it is JSON-LD expanded?
17:28:24 <csarven> So, JSON-LD expanded + profile?
17:28:41 <cwebber2> csarven: no :)
17:28:46 <rhiaro> okay, not expanded and no context, but with profile
17:28:47 <cwebber2> csarven: compacted
17:29:09 <rhiaro> I'm not entirely sure if profile is meant for this. I feel like maybe, but we need to consult an expert
17:29:40 <rhiaro> going to re-check what annotations is doing
17:29:53 <csarven> profile can be anything. it is not specified as long as the semantics don't change by including it.
17:29:58 <csarven> if you remove the profile, it should still make sense
17:31:24 <csarven> cwebber2: Sorry, right, compacted. Whatever gives the full URI =)
17:31:51 <cwebber2> csarven, compacted is the human readable, without the full URI :)
17:31:54 <rhiaro> no, the not-full URI
17:32:00 <cwebber2> csarven, so the goal of using the activitystreams mimetype
17:32:03 <rhiaro> we dont' have this problem if it's expanded
17:32:15 <csarven> If you don't have context and there is no full URI, those keys are just arbitrary strings
17:32:22 <csarven> application specific at best
17:32:23 <cwebber2> csarven, was so that if a "dumb" participant sends documents, you know how to infer a context
17:32:32 <rhiaro> that's why we're trying to figure out if profile can tell you how to expand the strings
17:32:46 <csarven> OK, but the semantics shouldn't change is what @profile is saying
17:33:08 <rhiaro> So I figure that if profile == inferred @context, the semantics aren't actually changing
17:33:10 <csarven> What's the "semantics" if there is no context and no full URI?
17:33:19 <rhiaro> there's agreement between sender and receiver, via the profile
17:33:38 <csarven> Without the profile!
17:33:38 <cwebber2> btw I'm running this by manu
17:33:49 <cwebber2> csarven: no this would be *with* the profile
17:33:50 <rhiaro> *with* profile, without @context
17:34:00 <rhiaro> there is always a profile in this scenario
17:34:36 <cwebber2> application/ld+json; profile=http://www.w3.org/ns/activitystreams#
17:34:36 <cwebber2> {"type": "Note"}
17:34:54 <cwebber2> implies doing a default context with the document loader :)
17:35:10 <cwebber2> *that's* what the activitystreams mimetype gave us
17:35:34 <cwebber2> so that dummy user who just sent json and had no idea what that @context thing was could still be interpreted
17:37:03 <cwebber2> if this is tricky
17:37:18 <cwebber2> what we could do is one of those "liberal in what you accept but conservative in what you produce" things
17:37:54 <cwebber2> by always providing the "@context" but say "consumers SHOULD process with an implied context" in a non-normative section, giving clarity on how to accept content from people who don't quite do the right thing
17:38:00 <cwebber2> but, producers should do the right thing.
17:38:13 <cwebber2> that way an AP <-> LDP thing will still workl.
17:38:15 <cwebber2> *work
17:38:33 <csarven> My reading of https://tools.ietf.org/html/rfc6906#section-3 is that, if you don't have the profile, it should still make sense as JSON-LD (given 'application/ld+json')
17:38:53 <csarven> And if you don't have context or a full URI in there, I'm not sure if that does. Unless I'm misinterpreting something here.
17:43:10 <cwebber2> alright well
17:43:25 <cwebber2> at the very least, we can switch to providing an @context in all examples....
17:43:25 <rhiaro> like chris said, the liberal-in-what-you-accept thing is probably still good
17:43:34 <rhiaro> but yeah, we should put @context in examples as a good start
17:45:34 <csarven> Just to be clear: I'm not 100% sure about it, so just raising it for caution.
17:45:46 <cwebber2> :)
17:45:49 <cwebber2> ok well anyway
17:45:54 <cwebber2> I think we have enough info to improve that
17:46:00 <csarven> Better ask in #json-ld
17:46:06 <cwebber2> csarven, already doing so :)
17:46:13 <cwebber2> well the freenode one
17:47:45 <csarven> And.. I'm okay with the robustness approach. Is that SWP territory?
17:47:49 <rhiaro> Okay, I think we have enough to be going on with with AP. Anyone else have anything to add?
17:48:11 <rhiaro> csarven: possibly, or it might be some carefully negotiated combination of AP and LDN (or all of the above)
17:49:14 <rhiaro> Okay, then wrapping up. I'll dump this chat on the wiki page.
17:49:24 <rhiaro> trackbot, end meeting
17:49:24 <trackbot> Zakim, list attendees
17:49:24 <Zakim> As of this point the attendees have been (no one)
17:49:32 <trackbot> RRSAgent, please draft minutes
17:49:32 <RRSAgent> I have made the request to generate http://www.w3.org/2016/08/16-social-minutes.html trackbot
17:49:33 <trackbot> RRSAgent, bye
17:49:33 <RRSAgent> I see no action items