hello!

Activitypub and notifications

irc-only meeting today

<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

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

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

tsyesika, no need to connect

we are doing irc only

<tsyesika> oh okaaay

<tsyesika> oh sorry

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

this also means that ASub will remain in APub :)

so as to not spread over too many documents

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

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)

but it'll be in same document

<rhiaro> and side effects

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

so AP does need its own stuff

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

tsyesika: do you have thoughts?

or is basically this all good to you?

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

tsyesika: yay

<rhiaro> :D

tsyesika: I'm also feeling good about it

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

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

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

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

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

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

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

annbass, :)

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

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

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

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

as the mimetype

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

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

since they can already understand that

<rhiaro> application/ld+json; profile=http://www.w3.org/ns/activitystreams#

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

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

tsyesika, how do you feel about this

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.

csarven, ACK

csarven, yes, I followed the tumultuous github threads ;)

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

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

+1

<csarven> +1

<tsyesika> +1

consensus!

<melvster> +1

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

haha: D

<Loqi> nice

so, I'm going to go through https://github.com/w3c-social/activitypub/pull/75 and merge it

is there anything else to discuss?

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?

csarven: yes

<csarven> Great

csarven, though I think if it *is* possible to get both LDN inbox and rest of AP terms to be added to AS namespace

that would be ideal

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

<rhiaro> cwebbe2: working on it..

though, whatever

we can do aliases to anything in the context ;)

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.

csarven, rhiaro, so a question about profiles

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

of the AS2 mimetype that we are no longer using

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

I guess we could just set it with profiles

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?

csarven: no :)

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

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 =)

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

<rhiaro> no, the not-full URI

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

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!

btw I'm running this by manu

csarven: no this would be *with* the profile

<rhiaro> *with* profile, without @context

<rhiaro> there is always a profile in this scenario

application/ld+json; profile=http://www.w3.org/ns/activitystreams#

{"type": "Note"}

implies doing a default context with the document loader :)

*that's* what the activitystreams mimetype gave us

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

if this is tricky

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

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

but, producers should do the right thing.

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

*work

<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')

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

alright well

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.

:)

ok well anyway

I think we have enough info to improve that

<csarven> Better ask in #json-ld

csarven, already doing so :)

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

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/LD folks/LD community 'in general' - and not exclusive LD folks from SWWG/
No ScribeNick specified.  Guessing ScribeNick: cwebber2
Inferring Scribes: cwebber2
Default Present: (no_one)
Present: (no_one)

WARNING: Fewer than 3 people found for Present list!


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 16 Aug 2016
Guessing minutes URL: http://www.w3.org/2016/08/16-social-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.