From W3C Wiki
Jump to: navigation, search

socialwg Informal Editors' meeting 2016-08-16

Tuesdays at 10am US/Pacific, 1pm US/Eastern time for 60 minutes

Previous Meeting




cwebber2, csarven, tsyesika, rhiaro, annbass, melvster


Activitypub and notifications

<cwebber2> irc-only meeting today

<rhiaro> So this morning cwebber2 and I refactored AP Notifications and Delivery to Targeting and Delivery, with the LDN reference:

<rhiaro> feedback from the likes of tsyesika and csarven would be welcome :)

<csarven> Sorry for that. My situation is reliable for audio. I can listen but may not respond that well. So, IRC is most suitable.

<cwebber2> csarven: we were preferring irc only today also :)

<csarven> rhiaro Should I respond to that now or wait?

<rhiaro> as convenient, if you can read it now

<csarven> i.e., read and respond.. or read later and you summarise now

<cwebber2> tsyesika, no need to connect

<cwebber2> we are doing irc only

<tsyesika> oh okaaay

<tsyesika> oh sorry

<cwebber2> np: )

<csarven> Probably bes tthat you summarise since this is AP specific

<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

<rhiaro> it's not a long section

<cwebber2> this also means that ASub will remain in APub :)

<cwebber2> so as to not spread over too many documents

<cwebber2> instead, we'll separate activitypub into client to server and server to server

<cwebber2> with the server to server relying on LDN

<rhiaro> But server to server additionally specifies targeting (ie. deciding who to send to which isn't in LDN)

<cwebber2> but it'll be in same document

<rhiaro> and side effects

<cwebber2> yes

<rhiaro> and the actual subscription request part

<tsyesika> i like that we're now pointing at LDN :)

<rhiaro> which is essentially a side effect

<cwebber2> so AP does need its own stuff

<cwebber2> but can *rely on* LDN for the bulk of it.

<csarven> Okie

<csarven> Sounds good

<csarven> 3.7.2 being clear

<csarven> i.e., 3.7.1 and 3.7.2 being distinct

<cwebber2> tsyesika: do you have thoughts?

<cwebber2> or is basically this all good to you?

<cwebber2> esp since you're co-editor on AP :)

<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

<cwebber2> tsyesika: yay

<rhiaro> :D

<cwebber2> tsyesika: I'm also feeling good about it

<cwebber2> I was dreading the APub / ASub refactor

<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

<cwebber2> this will allow us to clearly distinguish between pub and sub parts but without me feeling like I will run out of time

<cwebber2> and will allow us to have the generalized federation as part of another document

<cwebber2> while keeping our own specific things (esp side effects)

<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

<cwebber2> rhiaro: yes that would be good

<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

<csarven> Extra ++ if AP is comfortable with these based on technical clarification and dedicating resources

<cwebber2> csarven, not totally clear on what that means but I think yes? :)

<annbass> sounds like you guys are converging on a good plan!

<cwebber2> annbass, :)

<csarven> cwebber2 If you are happy, we're all happy =)

<cwebber2> tsyesika, ah yes one thing we need to discuss that happened on the last call

<cwebber2> tsyesika, so we had discussed switching from primarily the application/activity+json to the more general json-ld version with a profile

<cwebber2> though I am blanking on the other one right now :)

<cwebber2> as the mimetype

<cwebber2> it's possible to specify json-ld with a profile

<cwebber2> and then that makes it clear with AP, but adds no extra work for LDP type folks

<cwebber2> since they can already understand that

<rhiaro> application/ld+json; profile=

<rhiaro> except it might need to be /activitypub#

<cwebber2> and since nobody is using application/activity+json yet, it's not like we have to get old implementations to fix it

<cwebber2> tsyesika, how do you feel about this

<cwebber2> it would simplify interop dramatically and wouldn't really lose anything IMO

<tsyesika> yep, all for it, seems like no work for us for better interop

<csarven> cwebber2 If it matters, the LD community 'in general' - and not exclusive LD folks from SWWG 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.

<cwebber2> csarven, ACK

<cwebber2> csarven, yes, I followed the tumultuous github threads ;)

<cwebber2> csarven, anyway, yes it's no extra work for us

<cwebber2> so all is well

<rhiaro> For process sake:

<rhiaro> PROPOSAL: Keep AP and ASub as one document, with reference to LDN in ASub

<rhiaro> +1

<cwebber2> +1

<csarven> +1

<tsyesika> +1

<cwebber2> consensus!

<melvster> +1

RESOLUTION: Keep AP and ASub as one document, with reference to LDN in ASub

<cwebber2> haha: D

<Loqi> nice

<cwebber2> so, I'm going to go through and merge it

<cwebber2> is there anything else to discuss?

<cwebber2> I guess one more thing that needs to be done then is to separate the pub and sub sections in AP

<csarven> cwebber2 ARe you okay to alias inbox to whatever LDN ends up using for ns?

<cwebber2> csarven: yes

<csarven> Great

<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

<cwebber2> that would be ideal

<cwebber2> but I guess that will require policy changes or somethin :)

<rhiaro> cwebbe2: working on it..

<cwebber2> though, whatever

<cwebber2> we can do aliases to anything in the context ;)

<cwebber2> we'll alias to a wiki page. Living namespaces!

<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

<rhiaro> So AP implementers don't have to care about ldp:inbox and ldp implementers don't have to care about as:inbox

<rhiaro> but they accidentally interop anyway

<rhiaro> ... I think.

<cwebber2> csarven, rhiaro, so a question about profiles

<cwebber2> one nice thing about the mimetype is that you could then infer a json-ld context

<cwebber2> of the AS2 mimetype that we are no longer using

<cwebber2> is something like that possible with profiles? I'm guessing not?

<cwebber2> I guess we could just set it with profiles

<cwebber2> but what would happen to LDP things that were ignorant of that

<rhiaro> So the scenario is: an AP sender sends a notification without an @context, but with the profile, to an LDP receiver

<rhiaro> Does the LDP receiver handle it correctly?

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

<csarven> If no context, I suspect that it is JSON-LD expanded?

<csarven> So, JSON-LD expanded + profile?

<cwebber2> csarven: no :)

<rhiaro> okay, not expanded and no context, but with profile

<cwebber2> csarven: compacted

<rhiaro> I'm not entirely sure if profile is meant for this. I feel like maybe, but we need to consult an expert

<rhiaro> going to re-check what annotations is doing

<csarven> profile can be anything. it is not specified as long as the semantics don't change by including it.

<csarven> if you remove the profile, it should still make sense

<csarven> cwebber2: Sorry, right, compacted. Whatever gives the full URI =)

<cwebber2> csarven, compacted is the human readable, without the full URI :)

<rhiaro> no, the not-full URI

<cwebber2> csarven, so the goal of using the activitystreams mimetype

<rhiaro> we dont' have this problem if it's expanded

<csarven> If you don't have context and there is no full URI, those keys are just arbitrary strings

<csarven> application specific at best

<cwebber2> csarven, was so that if a "dumb" participant sends documents, you know how to infer a context

<rhiaro> that's why we're trying to figure out if profile can tell you how to expand the strings

<csarven> OK, but the semantics shouldn't change is what @profile is saying

<rhiaro> So I figure that if profile == inferred @context, the semantics aren't actually changing

<csarven> What's the "semantics" if there is no context and no full URI?

<rhiaro> there's agreement between sender and receiver, via the profile

<csarven> Without the profile!

<cwebber2> btw I'm running this by manu

<cwebber2> csarven: no this would be *with* the profile

<rhiaro> *with* profile, without @context

<rhiaro> there is always a profile in this scenario

<cwebber2> application/ld+json; profile=

{"type": "Note"}

<cwebber2> implies doing a default context with the document loader :)

<cwebber2> *that's* what the activitystreams mimetype gave us

<cwebber2> so that dummy user who just sent json and had no idea what that @context thing was could still be interpreted

<cwebber2> if this is tricky

<cwebber2> what we could do is one of those "liberal in what you accept but conservative in what you produce" things

<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

<cwebber2> but, producers should do the right thing.

<cwebber2> that way an AP <-> LDP thing will still workl.

<cwebber2> *work

<csarven> My reading of is that, if you don't have the profile, it should still make sense as JSON-LD (given 'application/ld+json')

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

<cwebber2> alright well

<cwebber2> at the very least, we can switch to providing an @context in all examples....

<rhiaro> like chris said, the liberal-in-what-you-accept thing is probably still good

<rhiaro> but yeah, we should put @context in examples as a good start

<csarven> Just to be clear: I'm not 100% sure about it, so just raising it for caution.

<cwebber2> :)

<cwebber2> ok well anyway

<cwebber2> I think we have enough info to improve that

<csarven> Better ask in #json-ld

<cwebber2> csarven, already doing so :)

<cwebber2> well the freenode one

<csarven> And.. I'm okay with the robustness approach. Is that SWP territory?

<rhiaro> Okay, I think we have enough to be going on with with AP. Anyone else have anything to add?

<rhiaro> csarven: possibly, or it might be some carefully negotiated combination of AP and LDN (or all of the above)

<rhiaro> Okay, then wrapping up. I'll dump this chat on the wiki page.

<rhiaro> trackbot, end meeting

Summary of Resolutions

  1. Keep AP and ASub as one document, with reference to LDN in ASub


  • Chair: Amy

Discussion Items

Next Meeting


Chair to close the meeting with the following command:

trackbot, end meeting

If you forget, trackbot will close the meeting for you when the activity dies down.

back to socialwg